Data Constellation: Comments

Data Constellation: Comments http://dataconstellation.com/blog en cjh@dataconstellation.com (Clifford Heath) Copyright 2007-2008 60 Fri, 31 Oct 2008 23:09:16 GMT Agile Information Management and Design Wow I googled something about... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c25 Fri, 31 Oct 2008 23:09:16 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c25 Hmmm <p>Wow I googled something about Rails dev log and this article came up. That sucks.</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> Chui: Absolutely. Any time you... http://dataconstellation.com/blog/older/2008/4/23/there_are_no_attributes/#c24 Thu, 15 May 2008 23:31:48 GMT http://dataconstellation.com/blog/older/2008/4/23/there_are_no_attributes/#c24 Clifford Heath <p>Chui: Absolutely. Any time you capture more semantic information about your business domain, there’s the chance for increased automation, whether that be through scaffolding or merely validations.</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2008/4/23/there_are_no_attributes/">There are no attributes</a> I’d read about ORM a... http://dataconstellation.com/blog/older/2008/4/23/there_are_no_attributes/#c23 Wed, 30 Apr 2008 06:26:08 GMT http://dataconstellation.com/blog/older/2008/4/23/there_are_no_attributes/#c23 Chui Tey <p>I’d read about ORM a few years ago, and I’m intrigued at CQL’s possibilities. There is a great deal of impedance mismatch between master-detail type data and SQL, which tend to think of these type of relationships as a JOIN rather than something more intimate.</p> <p>I also wonder if the additional metadata in ORM makes it possible for RAD tools to have more built-in smarts. e.g. validation messages. </p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2008/4/23/there_are_no_attributes/">There are no attributes</a> Great talk at the Ruby... http://dataconstellation.com/blog/older/2008/4/23/there_are_no_attributes/#c22 Fri, 25 Apr 2008 10:12:26 GMT http://dataconstellation.com/blog/older/2008/4/23/there_are_no_attributes/#c22 Clinton Forbes <p>Great talk at the Ruby group tonight, Cliff. I wish I had read this blog post beforehand. It was a pity you were cut short - I’m sure ten more minutes away from the bar wouldn’t have killed everyone.</p> <p>Anyway, I will have to order that doorstop book on information modeling now!</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2008/4/23/there_are_no_attributes/">There are no attributes</a> You: “Things like not adding... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c21 Thu, 10 Jan 2008 22:09:59 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c21 David Sidlinger <p>You:</p> <p>“Things like not adding indexes until they’re needed, and not enforcing FKs… these things are definitely part of Rails culture and recommended in the Agile Web Development book.”</p> <p>Agile Web Development with Rails, 2nd Edition:</p> <p>“It’s worth noting that this migration doesn’t deﬁne any foreign key constraints. The intertable relationships are set up simply because the developer will populate the columns product<em>id and order</em>id with key values from the products and orders tables. You can also choose to establish these constraints in your migrations (and I personally recommend that you do), but the foreign key support in Rails doesn’t need them.”</p> <p>“Migrations can (and probably should) deﬁne indices for tables.”</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> Excellent Article. I believe it... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c20 Wed, 09 Jan 2008 19:52:04 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c20 phillc <p>Excellent Article.</p> <p>I believe it would have been even better if you linked to articles which discussed such things, especially #8 (since it slightly confused me)</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> It seems like the majority... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c19 Sun, 06 Jan 2008 13:30:54 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c19 David Jeffries <p>It seems like the majority of rails developers are in the code and fix mentality which is exactly the problem I have with rails: it supports bad behavior.</p> <p>I remember watching a podcast interviewing the founder of Twitter (which is written in rails). This was a couple weeks after twitter came out, and when asked about the scalability of rails he merely replied, “we have an aggressive caching policy.” I’m sure everyone has heard of the uptime problems with Twitter since the release…</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> I’d definitely had to agree... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c18 Sun, 06 Jan 2008 07:45:33 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c18 Shanti Braford <p>I’d definitely had to agree with many of these.</p> <p>It’s clear, though, that you come from a very DB-centric worldview.</p> <p>Linking to a tutorial on Foreign Keys in MySQL 5.0, for example, might be a nice touch.</p> <p>Re: indexes - if there’s a 99% chance you’ll need them, then of course you might as well add them when creating the app. I’ve taken to doing this. The thin line between overoptimizing can be a tricky one though… =)</p> <p>Most of the rest are, as you said, “people problems” endemic of many teams, not just those using Rails.</p> <p>All in all, even taking over a poorly written Rails app is still much less painful (to me) than when I used to do the same with PHP, ASP, etc.</p> <p>(Circa 2003 php/asp/etc - Model View Controller??? HAHAHAHAH good one… ;))</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> The author’s point is exactly... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c17 Sun, 06 Jan 2008 07:19:46 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c17 Fernando Correia <p>The author’s point is exactly that: some people find these concerns boring, then sites melt down.</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> Wow! So much boring bullshit.... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c16 Tue, 20 Nov 2007 13:54:50 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c16 Jeff <p>Wow! So much boring bullshit. A more proper title would be “How to ruin a blog post”.</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> Hey, c’mon people! Laziness and... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c15 Wed, 31 Oct 2007 07:33:31 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c15 Lucas Húngaro <p>Hey, c’mon people! Laziness and unprofessional attitude isn’t Rails specific, but Clifford made a valid point when saying that some parts of Rails culture ends up encouraging some mistakes. For instance: foreign keys, indexes and some checks and defaults are really a good measure, even more when your database will be shared with other applications/services. Some very important people of the Rails world are against this measures and encourages people to be against too. That’s the point, it’s not about Rails itself.</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> Ah, I thought so. Seems... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c14 Wed, 31 Oct 2007 01:14:16 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c14 Ryan Allen <p>Ah, I thought so. Seems like a lot of nasty duplication doesn’t it? :( But I guess that’s the price you pay for a really robust system.</p> <p>Unless you like, generate code from say, fact based modelling, right? :)</p> <p>I’ve read somewhere you can write triggers and whatnot in PostgreSQL in Ruby, I wonder what that is like!</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> You can do a lot... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c13 Sat, 27 Oct 2007 22:26:00 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c13 Clifford Heath <p>You can do a lot with CHECK constraints and triggers, but the big problem with business rule enforcement is that the same rule needs to be enforced at the UI, logic and data tiers, or in Rails, the browser JS, the controller, the model, and the database - and synchronizing all the enforcement code with the original rule requires great discipline.</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> What about enforcement of business... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c12 Sat, 27 Oct 2007 02:53:23 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c12 Ryan Allen <p>What about enforcement of business logic that is more complicated than fk or unique constraints?</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> I like Rails, but there... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c11 Thu, 25 Oct 2007 15:15:29 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c11 eeby <p>I like Rails, but there are valid points in this article. In this community, you often see demos like “watch as I build this blog platform in five minutes.” I just saw such a demo last night at a Rails meetup. I think that’s really the wrong message to send. It encourages laziness and ridiculous expectations, and it’s annoying bragging.</p> <p>The cool thing about Rails though is that if you use it carefully, and the apply same care and precautions you always have to apply with any technology, it can save you a huge amount of time.</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> Clifford Comment above: Sentence #1:... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c10 Wed, 24 Oct 2007 16:44:43 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c10 Eric <p>Clifford Comment above:</p> <p>Sentence #1:</p> <p>“Sorry you thought I was complaining about Rails. I wasn’t, the problem is always people, of course.”</p> <p>Sentence #2:</p> <p>“My premise was that some facets of the Rails culture seem to me to engender bad practices.”</p> <p>The Rest:</p> <p>“Rails sucks”</p> <p>You may want to edit sentence #1 to be more accurate:</p> <p>“Sorry you thought I was complaining about Rails. I was, the problem is rails, and the people around it.”</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> Sorry you thought I was... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c9 Mon, 22 Oct 2007 22:08:13 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c9 Clifford Heath <p>Sorry you thought I was complaining about Rails. I wasn’t, the problem is always people, of course. My premise was that some facets of the Rails culture seem to me to engender bad practices. Things like not adding indexes until they’re needed, and not enforcing FKs… these things are definitely part of Rails culture and recommended in the Agile Web Development book. And then there’s still the problem that the Rails log doesn’t usually include enough to reconstruct an event stream… and model.Transaction not reliably doing what transactions should… and… still think there’s no content?</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> This is totally wrong. It... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c8 Sun, 21 Oct 2007 11:55:00 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c8 Dejan Dimic <p>This is totally wrong. It had nothing specific with rails projects.</p> <p>You can always have unprofessional and lazy developers and / or management. Developers and managers can be neglecting about their work no meter what programming language, framework or technology they use.</p> <p>Why should lack of general specification, database design, referential integrity, indexes, unit tests, general testing, performance measurements, exception handling or any other thing you mentioned be specific about Rails but not to Php, ASP, Java or …</p> <p>For the same reason most the desktop application project will collapse. And to be truthful any kind of project in any domain will collapse if everybody involved do not perform as professionally and competent as they should be.</p> <p>Beside the bombastic title, emptiness.</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> Frank, I spent half the... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c7 Sat, 20 Oct 2007 20:27:13 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c7 Clifford Heath <p>Frank, I spent half the 80’s and all the 90’s developing high-productivity development environment products, and I couldn’t get over how utterly perverse our customers were. I mean, these people were running nuclear power stations, top-ten banks, even major US stock exchanges, yet the more we offered simple and straight-forward ways to do things, the harder they tried to find an utterly wrong way to do everything. Sigh. Lead a horse to water…</p> <p>Anyhow, thanks for the boost. I have a whole article series coming entitled “Out of Vietnam” that I hope you’ll find valuable, so please subscribe (either at feedburner or here) and keep reading!</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a> “Of course, most of the... http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c6 Sat, 20 Oct 2007 16:28:01 GMT http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/#c6 EmmanuelOga <p>“Of course, most of the Rails users are hardly professional programmers anyways.”</p> <p>Mmmm that statement seems pretty tough to deny. After all, you cite solid, well proved statistics of scientific rigour…</p><p>Posted to: <a href="http://dataconstellation.com/blog/older/2007/10/18/how_to_ruin_a_rails/">How to ruin a Rails project</a>