text:
A part of Joel on Software
The Joel on Software Discussion Group (CLOSED)
A place to discuss Joel on Software. Now closed.
This community works best when people use their real names. Please register for a free account.
Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot
The Old Forum
Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones
I recently finished using Ruby on Rails to write a simple bug tracking application. I thought I'd take this new RAD environment for a spin, having heard all the hype.
It kind of blew.
Don't get me wrong: I have to admit, it was a fun experience. There's a thriving community around Rails, and I get more email in an hour on from the Rails mailing list than on all five of my Perl lists in a day.
Rails doesn't do anything any other framework hasn't done. BUT, I admit it integrates all the bits and pieces bloody well and sprinkles the whole thing with some smart marketing. A light webserver, ORM, templating language, code generator and pre-built templates are nothing new, but a killer viral 5-minute video demo of all those things working together brilliantly IS.
But Rails also annoyed me. A lot. The developers have taken a brilliant idea -- brilliant -- such an incredibly short distance. Insert sports metaphor here.
Rails lived up to most of the hype, but who wants to hear about that?
As an entitled American who contributed not one line of code to Rails and has used it for all of one project, I am of course brilliantly qualified to bitch about it.
Here's what SUCKED about using Rails:
Basically, Rails groks tables and columns well, but relations are second class citizens.
This is so stupid. Rails is smart enough to look at my database's entrails and build accessors, craft templates and generate controllers to handle the whole thing. I can Create, Edit, Update and Delete without writing any code.
As long as I don't leave the table. DO NOT LEAVE THE TABLE!
In fact, don't even glance outside the table, like to get some labels for some ids in a popupmenu.
If Rails is already taking a latex glove to my db schema, how about feeling up those foreign key constraints I set up? Kind of a good hint about how to arrange has_many and belongs_to associations, ain't it?
OK, forget foreign keys. Let's pretend I'm too amped on Mtn Dew to care about imposing data intergrity at the data level.
There's still no excuse. Because Rails insists I name my foreign key columns table_id if I want to live the good life. When I do so, I shouldn't have to declar has_many and belongs_to.
Perl's Class::DBI::Loader is smart enough to autodetect relationships, and has been for some time. There's no reason Rails can't do this as well.
This isn't some minor feature. Any halfway decent data model is going to have tables that RELATE to one another. That's why we keep them in Postgres or Oracle or Mysql or SQLite instead of a flat file.
It gets really really old retyping the same type of popup onto a template and a has_many for every belongs_to and a belongs_to for every has_many.
Rails should be able to do this. After all, it makes three-way outer joins look effortless with the :include attribute to Class.find. Not even Class::DBI is there yet.
-Rails detects relationships from foreign keys or column names.
-Rails automatically sets up has_many and belongs_to associations at the model level.
-Rails creates some extra @instance_variables at the controller level to pull data from other tables in.
-Rails uses popup menus at the scaffolded view and generated view level to select foreign data. For example, user_id becomes a popup menu of users, resolution_id becomes a popup menu of bug resolutions.
The cool thing about the Rails demo is the guy, I think it's that Scandinavian guy who invented Rails, is sort of playing. He says "woops" about every three seconds. He changes things in a text editor and BOOM -- the application changes.
But do you remember that moment in the demo when the play turns ugly with a big ole error page? It's when he tried to update his db schema or model or something. It doesn't work because he has to reboot the webserver before those changes take effect. Which he says and moves on quickly.
Well, it turns out that webserver rebooting requirement really sucks when you're trying to, um, Rapidly Application Develop.
Now, I understand why this restriction exists. If Rails has to look at your schema on every request, you're going to take a performance hit.
But having to reboot the webserver makes Rails feel like a step backward from even CGI Perl in terms of speed. At least in that environment you can just reload the script to see if your changes worked.
Why can't Rails adopt the smart middle ground? The webserver does not need rebooting, until you set a :fast flag somewhere, in which case Rails caches the schema info.
Since Rails already differentiates development from production, this should be pretty painless to implement.
--->Rails also doesn't play well because it will overwrite your code. Here's the scenario: you started a project in scaffolding mode because you were learning Rails and this is Rails' coolest and easiest mode.
You made some slight modifications to the models and controllers as you associate your models with one another.
Then you discovered you wanted to depart slightly from the scaffolding. So you backed out and figured out how to ruby script/generate scaffold Thing. Except -- Woops! -- this overwrites your old code, your models and controllers.
In the case of controllers, you may be safe because the scaffold generator will use the plural form. But your model is probably toast.
Rails allegedly will ask permission first but, um, it didn't.
The solution is to stop playing and start over at the beginning and DO THINGS RIGHT THIS TIME, DAMMIT! Here is an actual entry from the Rails FAQ:
"Q012:That stinks... I want the scaffold code without starting over!
Too bad. Start a new rails project, run scaffold, then manually add the missing stuff to your new project from your old project with copy and paste."
Are we having fun yet?
--->This "back to square one" technique returns again and again in using Rails. When I installed the login-engine plugin for Rails -- which is really cool, by the way, even Perl's CPAN does not have libraries operating at this high a level yet -- there was no documentation on how to make it work with my existing user table. Fine. I let it build its own table, made a new user and logged in.
But then when I went to install user-engine, which adds access controls on top of login-engine, it again did not want to integrate my existing data. The user I had created 5 minutes earlier in login-engine was useless. I had to let user-engine autogenerate a new user named "admin" with an insecure default password.
Rails has no manual.
Let me repeat that: Rails has no manual.
If you haven't used Rails, you may not believe me. Well, go visit the Rails documentation page:
Hmmm ... We have APIs, Tutorials, HowTos, Snippets, but no manuals. There's a section called "manuals" but that's documentation for side projects, like a standalone utility called SwitchTower, or how to upgrade rails, or "Routing," whatever that is (odd place for a networking primer).
You do have "API," at api.rubyonrails.com, which is a nice reference. Actually, no, it's a baffling, messy, ugly, confusing jumble of documents with a fairly useless introduction. Once you figure out that all key classes are annoyingly prefixed with the word "Action" and that the base classes are actually named Class::Base instead of just Class, you can pretty much usually find what you want if you know what you're looking for.
But this is a terrible way to learn the framework.
Which brings us to the section "Books." Ah, the REAL manual.
Let's set aside that it feels a little slimy to start in on a "free" application framework and a very slick "free" video demo and read a bunch of free O'Reilly tutorials only to find out, when it gets down to brass tacks, you're going to have to shell out $35 for a linear, rational, comprehensive overview of the language.
Ya, let's set that aside. Fine. Harumph, but fine.
What gets me is I am just *not* going to pay to read 570 PAGES about a framework! I'd actually pay twice as much if they could boil this sucker down to 200 pages or less!
If I am going to waste time, I might as well go online, where the information is free and up to date.
If you want to sell me a book on a rapid development framework, keep it tight! The whole point of my paying for the book is that my time is valuable. And the whole point of you, framework developer, writing the book is that you can most elegantly and efficiently summarize the framework because, well, you know the whole story!
Rails knows which column is varchar(40) and which is int(11), but don't expect it to do anything with that information other than maybe size the text fields in your scaffolded HTML form.
If you plop 80 chars of data into a 40 char field, Rails goes ahead and passes it along to the database this way. A certain extremely popular "database" will silently amputate data in this situation. Rails inserts the data and raises no error.
This is especially silly since a> Rails already incorporates methods to validate input for particular columns and b> Rails is already recording column types.
Rails has lots of important rules that you need to follow if you want things to work easily and to really flex the power of the framework.
But all the demos I saw, including the Onlamp.com tutorial, were so busy hyping how easy Rails is that they glossed over the rules, even though they are pretty simple.
The trouble with that approach is that people end up trying the framework, and use techniques from elsewhere that can really gum up the rails works. Like naming database tables in singular form (ala Philip Greenspun) or naming a foreign key "user" instead of "user_id" (ala Class::DBI). And then they become unnecessarily frustrated with the framework.
Rails needs to put a set of simple rules in a place where most newbs will see it. Things like:
-name your tables in the plural
-foreign keys should always be named like so: tableNameInSingularForm_id
So: user_id (foreign key) -> users (table)
-models are named singular
-controllers are plural, at least in some cases
-many-to-many jump tables should be named: alphabeticallyFirstTablePlural_alphabeticallySecondTablePlural
So: axes_users
-columns in many-to-many jump tables should be named like other foreign keys
So: axe_id and user_id
-columns named created_on and updated_on will automatically be populated correctly
You want to setup some kind of configuration for some particular rails package. You:
A. modify your existing code, which will use the package
B. modify code in the package itself
C. specify when you install or bootstrap the package via ruby script/* and the command line
D. modify -APPBASE-/config/environment.rb
E. modify -APPBASE-/app/controller/application.rb
F. modify -APPBASE-/config/environments/-ENVIRONMENT-.rb
I had one engine that needed four of those.
Anyway, those are all the headaches I can remember. I'm pretty sure I've forgotten a few, but oh well.
I only say all this because Rails is the first framework worth criticizing.
Oh, not really. Who am I kidding? I say this because I like to complain.
But hopefully more people will start learning Rails, if only so they go back to their home platform all charged up to do it one better.
Wow, that's a most excellent rant!
The rails lack of support for relations is a mystery. Normalized tables are a major part of development. Hibernate is much better for this sort of thing. Nitro for ruby is supposed to be nice too.
son of parnas
Wednesday, February 15, 2006
++++ for quality of Rant.
I am going to mail David (Rails author) to get his response. Should be interesting. :)
I would normally just tune out a rant of this length but it was very well written. I ended up reading it all!
I've never used Rails and have been meaning to give it a look. But I think that your rant has helped me to understand what Rails is all about. I'm not a big fan of OR mappers and frameworks that just try to put together simple CRUD style forms for you. The real world never fits into the basic CRUD style. But developers always think having simple forms generated for you is such a great thing. Too bad those simple forms never end up being good user interfaces.
I'll still give Rails a look. But I think I already know what I'll find.
Turtle Rustler
Wednesday, February 15, 2006
Huh. Auto-generated forms, eh?
I have a question...
Let's say I want to have city/state/zip inputs on one of my forms. Is it possible to have the form laid out like this:
...or does it have to be like this...
If it's possible to customize the layout of the auto-generated forms, then what aspects of the auto-generation make it simpler than just manually creating the forms with the appropriate layout?
Wednesday, February 15, 2006
I digged the story. ;)
BTW, knowing RoR fans, this story is surely going to land up on Digg and Delicious top page. JoS servers, get ready for some action!
I think I'll stick with Zope.
Ta very much.
Simon Lucy
Wednesday, February 15, 2006
> The rails lack of support for relations is a mystery.
Rails supports relations in the same way that Hibernate supports relations. The posters complaint was that table relations aren't automatically detected along with the rest of the table.
> I'm not a big fan of OR mappers and frameworks that just
> try to put together simple CRUD style forms for you
Rails doesn't "put together forms". You can do anything in Rails that you can do in, say, Java's Webwork and Hibernate. Rails has a feature where you can generate stub code for CRUD operations. Nothing more.
I develop in Rails when I think it is appropriate and the client gives the go ahead. I also develop in Java (Spring, Hibernate, Webwork) and ASP.NET if I have to. Rails has its place -- yes there is lots of hype, and conversely, FUD; but I have found it to be a very productive environment.
Rhys Keepence
Wednesday, February 15, 2006
Excellent rant.
I absolutely agree that Rails should take better advantage of database metadata. Philip Greenspun argued for this a long time ago, and I think it makes a lot of sense. Rails is 9/10ths of the way there already, but ignoring foreign keys and column definitions is silly. I think it reflects a certain MySQL-imposed myopia. So does Rail's "database agnostic schemas" -- aka, lowest common denominator schemas, aka, why should I use Oracle when I can use SQLLite?
David Heinemeier Hanson actually argues that this is a feature. http://www.loudthinking.com/arc/000516.html
Regarding your #2 issue, this isn't totally true. By default Rails always has to reload your database schema on every request because Rails is exec'd as a CGI on every process. To fix this, you need to set up FastCGI. Are you using WEBBrick and "development" mode (which turns off all caching)? It might make your development easier.
Re: #5: Rails magic. This goes along with the documentation which I agree is not organized very well. I ended up buying the book and it is pretty good.
There are some cheat sheets out there that are worthwhile though:
These rules are all changeable, but before you can change the rules you need to know they exist.
All this being said, I think Rails does almost everything right. I'm hopeful that DHH will at least allow foreign key patches for those of us who actually use our database.
I think there's material here to write many tickets to Rails' Trac but the author preferred, instead, to write a rant.
Lorenzo Bolognini
Wednesday, February 15, 2006
If this was your schema:
Ranter table
- id
Rant table
- ranter_id
how should Rails guess about the relationship? Is it 1-1? 1-Many? Can a single JoS Fan have more than 1 rant?
Why did you have to restart your web server? Rails has several modes, and when in "development" mode, it reloads the schema with each request. In "production" mode it does not for performance reasons. You can guarentee your server starts up in development mode by "ruby script/server -e development"
There is a bunch of stuff online but if that isn't enough there is an excellent book called "Agile Web Development with Rails" by Dave Thomas and DHH
If you want to write a validator, Rails has a straightforward framework for that. But largely Rails follows the DRY principle and doesn't repeat the job of the DB.
Wednesday, February 15, 2006
"If you want to write a validator, Rails has a straightforward framework for that. But largely Rails follows the DRY principle and doesn't repeat the job of the DB."
If this were actually true, Rails would keep DRY by following the column definition that I laid out in my schema. Instead, it forces me to repeat myself by writing my own validator.
Oh, I know, I'll just declare all my columns varchar(255) and manage the validation in my model. Why use a database at all in this case?
Granted, this is a nitpick. Every other framework has the same problem, and usually much worse.
Rails would be a much better environment if the 'scaffolding' feature was removed altogether. While it was possibly intended as a feature for rapid prototyping, too many Rails newcomers (many who appear to not have had experience with any previous frameworks) seem to think that this is how you go about building a production quality app.
I agree that the documentation needs work. I'm used to reading javadocs so I'm ok with api.rubyonrails.org. But sometimes you just need a sense of how things fit together.
wiki.rubyonrails.org is a great resource, but one needs to be aware that the quality of information does vary.
Nonetheless, after using RoR for 2 months, I've accomplished things that would have taken 5 months in j2ee and I've been working with that stack for 6 years now.
Anon ISV Owner
Wednesday, February 15, 2006
Some of your points are very true, some seem to be a little misled. Maybe because of the poor documentation.
Even though some of the things in rails are quirky or not 100% done yet don't make light of the excellent integration of tools rails provides.
I am currently developing multiple applications in rails for enterprise contracts for systems costing upwards of $2mil for the client.
I have beem able to help the company I work for jump in and create wonderful prototypes to help win contracts. Then take the prototype and deliver working enterprise systems in rails.
Granted, I've read over a LOT of the rails code and am quite familiar with how it works and I don't use all of the features. But I'm telling you having everything in one place with the wonderful language that is ruby makes this a breeze.
Some things are a pain, but the quirks in rails don't compare to other systems out there.
nothing but love for that, hackerman.
I also checked it out a bit (but not ina anywhere near this depth) and ended up not really being bothered enough to go further. I can see that it is a step up for people whi have used various java based frameworks til now. But when you already have CGI::Builder, Catalyst, Maypole, or even webgui if you want to get really filthy ... why change?
revert my buffer
Wednesday, February 15, 2006
Good rant. If only for the fact that its a display of enthusiasm for making something you like better. Naturally, I don't really agree with most of the technical points, but that's besides the point. I certainly do agree that the documentation could be better organized. Especially that we could have an easier flow for newcomers. The API is indeed intimidating for first-time users.
Anyway, just to quickly comment on the technical points.
1) Foreign keys are not rich enough to represent most associations. Not only can't they distinguish between 1-1 and 1-M, but they can't hold any customization. So there's no way to specify has_many :active_clients, :conditions => "active = 1".
And if you can't represent the vast majority of all associations through introspection, I'd much rather be explicit about the few that could have been guessed for the sake of consistency and coherence.
Note that the reverse is the case for attributes. The vast majority of all attributes accurately describe how we want them presented in the code since type casting happens automatically. So we only have to specify the exception.
2) This is simply not true as others have noted. The only time you need to restart the web server is when you either upgrade Rails or change your database configuration (password, host, IP, etc). You certainly don't have to restart the server to reflect the database schema changes. That would totally and utterly suck.
It's not true either that Rails overwrites existing files if you use script/generate scaffold. It will actually inspect those files and skip those are either identical or already there.
3) I agree. Newcomer documentation could be organized better. The problem, of course, is that writing good newcomer documentation is hard, so its tough to find contributors willing to help on such a big task. Which is of course why commercial entities, such as publishers, step in to do the work.
4) Again, validations are very often more complex than what the database gives us. For example, it's not easy to say that the password field should be between 6 and 20 characters. The schema can't capture that. And when the schema can't capture the majority of validations, I prefer to have them all explicit and coherent.
That being said, there are people working on allowing auto-validation. I don't know the status of that work, though.
5) I agree. Please do help us get better at that. Newcomers are the ones with the most frustration around this, thus best equipped with motivation to deal with it. I was a newcomer to Ruby once, the frustrations lead me to create Rails. Cherish that newcomer-enthusiasm for improvement for good, please ;)
6) All configuration should happen in the environment. If its not for some package that you're using, please do encourage the creator to streamline it.
David Heinemeier Hansson
Wednesday, February 15, 2006
What's with the hating on scaffolding? I've been using Rails for a few months and I still use scaffolding. Even if you blow away the internals and re-write your own, it still saves many keystrokes and mouse clicks. You still need a model, controller and view, and if you can create them with one command vs. 3+, I say bring it on.
My only gripe so far is that Rails isn't robust on Windows servers. Many of us .NET-ers are locked in to Win servers, but when (hopefully not if) it becomes a reasonable production platform for Rails, many more shops may consider integrating Rails. I know, Apache+SCGI and a cool compile of lighttpd exist for Windows, but they're not quite there yet.
The key for me (a .NET developer) is that Rails makes things fun, and I can actually think about the user's experience rather than 50 lines of code to call the db, create a DataTable, etc. Don't give up on it!
Wednesday, February 15, 2006
The polite (useful) thing for an ORM to do is at least offer to make a many-to-one in each table with a foreign key, and a one-to-many in the other direction along the same link. A touch more clever is an ORM that will auto-detect many-to-many relationships based on the number and nature of foreign keys in each table, and the naming convention of the mapping table. Make all of these things optional, and everyone is happy.
The total removal of literal SQL from complex queries and a database-agnostic interchange format for all column values would be nice too. Various Perl ORMs offer some or all of these things. (FWIW, Class::DBI is a poor example, IMO.) But, you know, the $ and @ signs and all...so gauche.
re the non-free docs,
It seems that this is something of an accepted convention in the Ruby world: if you want (English) docs on Ruby itself, the pickaxe book is pretty much your only choice. The Rails book merely follows this tradition.
Jonathan Ellis
Wednesday, February 15, 2006
I'm left wondering what the hype about rails is all about. We developed internal frameworks five years ago that were far more powerful than this. It doesn't do *relations*!?! I heard its data backend was minimal, but that's ridiculous. Precisely what is it good for then? I haven't seen much criticism of the templating, so that must be solid. But there is *so so so* much more to web app development than templating! This article has inspired me to try and build something with it now, though.
Wednesday, February 15, 2006
Craig -- Rails *does* do relations; it just doesn't magically figure them out from the database. It forces you to describe them in your model classes, which is different than how it handles some other types of metadata.
Rails doesn't do anything particularly groundbreaking. But it does it in a way that involves less coding, *exponentially* less configuration, and just makes the whole process feel more fun and rewarding. It's like a breath of fresh air.
Wednesday, February 15, 2006
I would argue that the vast majority of foreign key relationships are one-to-many. One-to-one relationships can be usually normalized into a single table, and so should be an exception. Many-to-many relationships require a join table, which could also be detected. The exceptional case where you want to add conditions would be explicit in the code.
Similarly, the vast majority of the time, I would like the framework to validate that the size of the string I'm putting into the database isn't larger than the column. Above and beyond that, the model must validate more complicated logic ("this is an email address"). And, of course, with constraints you *can* express "length 6 to 20 characters".
Anyway, as David has said many times in the past, Rails reflects his opinion of how software ought to work. I mostly agree with that opinion, but I have more faith in my database.
Dude, it amazes me how simplified your database schemas seem to be. Anyone count tables in the hundreds?
Lost but recovering
Thursday, February 16, 2006
Hey, can somebody, why one could need hundreds of tables? I've heard there are some internal industry management app beasts that have tens of thousands of tables. What for?
I can't think of any application, where i would need more than 10 or 20 tables.
Thursday, February 16, 2006
The best thing about RoR was that it really introduced me to Ruby. Not so enamored with Rails, but once I got my head around Ruby, it just strikes me as the most elegant & powerful scripting/programming tool…
Rails, OTH, is nice, but seems to go overboard in locking the developer into a far too set manner of design & development. And, while there is the ability to override "convention" behavior, it generally detracts from the lure of RoR. And some things, really force you into a lot of extra rewiring work. For instance, as an exercise to increase my comfort with Ruby on Rails, I attempted to port an application over where some of the tables are keyed by unique strings, not the auto_increment integer key deal like is the default Rails behavior. I faced a dilemma over whether or not to shift the schema (and application impacts) to the Rails "convention" or deliberately override this (with all the little gotchas that accompany such as strategy). It zapped all the benefit out.
Then I had struggles with the enviornment deal - it seemed I would experience odd behavior with differences between 1st execution after server refresh and subsequent class invocations. And the cookie mechanism worked differently than the DT/DHH RoR book described. I posed these questions to more accomplished RoR gurus, but received no answer before finally figuring out that by plugging in a different environment parameter on WEBrick, those pesky issues disappeared.
Finally, the documentation for RoR (and Ruby in general) is extremely poor. Perl has volumes of man pages with examples where you can get instant help and examples when stumped. PHP has an annotated manual packed with user contributed comments with an easy pretty URL pathway. Ruby, OTOH, has API reference listings, and even some of the standard library modules are sparsely detailed (Lord forbid finding comprehensive documentation on additional libraries).
Thursday, February 16, 2006
"Hey, can somebody, why one could need hundreds of tables? I've heard there are some internal industry management app beasts that have tens of thousands of tables. What for?
I can't think of any application, where i would need more than 10 or 20 tables."
--well I think you pretty much summed up the rails audience.
Try building apps that aren't todo lists, or personal information managers then. Or actaully, any sort of app that adds value other then store something, and retrieve it later on when you have forgotten it.
Not quite yet a fan
Thursday, February 16, 2006
It's funnier to want the perfect ORM for 20 tables and a simple schema overall.
Lost but recovering
Thursday, February 16, 2006
I agree with Not quite yet a fan -- an application I'm making seems to constantly keep sprouting new tables...
Anyway, the main audience that Rails appeals to are former Java (and .NET, I presume) developers who are blown off their feet by a non-compiled platform.
Convention over configuration? In PHP, I've done things like this for ages:
$controller = ControllerFactory::get($controllerClassName);
I think when things are complex enough, the framework to some extent just gets in the way if it is too restrictive or not-fit for *your* purpose.
There is always some substance to hype, but I don't think RoR is the next big thing, whatever that means. I don't think its a new way of doing things at all.
If you had to say a next big thing, it will be something around functional programming paradigms. Which worries me, as I have a hard time getting my head around them (lisp especially) - but you see what things like UncommonWeb can do, its quite amazing.
Personally I hope that a lot of these best ideas can be built in to the boring "mainstream" - be it java or .net, where I feel a little more at home. I don't want to have to learn another way to do threads again, for the first time.
I have only seen limited application of RoR so far, and in all cases it has not gone well. Being replaced. And in all cases it was something which, and I hate to say it, woudl have been fine/better as a MS access client with linked tables to whatever back end RDBMS it was.
Its 2006, why are we still getting excited over CRUD aspects?
I think the way you can do ajax stuff really nicely in rails is awesome, but that doesn't really get talked about as much as the stupid active record pattern.
Not quite yet a fan
Thursday, February 16, 2006
I'm perplexed as to why the schema in a reasonable DB can't be interrogated to discover relations. Yes you couldn't have a generic interface that did it but you could have a generically defined interface that did with DB engine specifics behind that interface.
Simon Lucy
Thursday, February 16, 2006
"$controller = ControllerFactory::get($controllerClassName);
I assume you can get special PHP ready keyboard that have reinforced shift keys for all the hammering it gets.
Perhaps along with a reinforced "$" for when you need to drop into perl.
Not quite yet a fan
Thursday, February 16, 2006
How are you going to do it using Mike's example (reproduced below)? -
"If this was your schema:
Ranter table
- id
Rant table
- ranter_id
how should Rails guess about the relationship? Is it 1-1? 1-Many? Can a single JoS Fan have more than 1 rant?"
A powerful database will use Views, Stored Procedures, Triggers, UDFs, etc. If all you care about is foreign keys, primary keys and 20 tables, then you kill the opportunities to use well the database.
Lost but recovering
Thursday, February 16, 2006
You haven't answered the question. For better or worse, those features you mention don't figure in the Rails' philosophy, as DHH has explained numerous times.
Actually I don't disagree with you, John. I think different problems sometimes demand different solutions, just like most of you do, I'm sure. My only issue is with the folks who think that they need the perfect ORM to their simple solutions. For example, someone who thinks that he needs Hibernate for his 10 tables problem. I believe Rails ORM solution is quite realistic about its reach, because it gives you plent of opportunities to use SQL directly if you need to. On the other hand, the "perfect ORM" that people dream about would possibly shield them of thinking that there is an RBDMS which needs SQL for commands and etc.
Realistically, once your tables tend to the millions of records, you are supposed to worry about how to access and use those records. No excuse of "I'm a web-designer and I don't need to worry about the database" will save your program from stalling if you don't know what you are doing. An example of this problem is the Ian Bicking's blog experimentation:
Another issue that I'm seeing is how poorly people plan for further use and extensions of their databases. For instance, if you need to access the same database from different applications, I wonder if your current solutions will handle it? What if the database is updated by other processes? Will if be reflected in your WebApp instantly or will some race condition happen?
Lost but recovering
Thursday, February 16, 2006
"I assume you can get special PHP ready keyboard that have reinforced shift keys for all the hammering it gets."
LOL. It gets even worse -- on Croatian keyboard many characters -- that are on plain keys on a US keyboard, like [];'\/=` -- are under shift-key (or even altgr-shift-key). :)
In any case, Perl and Ruby are even more shift-intolerant, with all the @, @@, $, %, \$, & and other symbols. PHP also have it too many, I agree, and I much prefer simple syntaxes like Python.
Essentially, my dream language would have syntax of Python and features of Javascript, Lisp and Smalltalk.
One of the things I like about Rails is that it's never been presented as a panacea to all our Web application development problems. The people behind it are upfront about its limitations and what it can do and also what it will never do.
Another thing I like is that there are no XML configuration files (my background is J2EE) but that's a different story!
--"Routing," whatever that is (odd place for a networking primer)--
Routing does not refer to networking in this case. Routing is Rails-speak for specifying how the elements of a clean url map can map directly to your web apps. Routing is like url rewriting for Rails.
Thursday, February 16, 2006
John, while the people behind Rails are indeed honest about its capabilities, like many cool technologies it suffers from the messiah complex: many less well-informed users will get carried away and start advocating it _without_ realising or acknowledging that it has any limitations, or that it isn't ideally suited for domains other than the one they're using it in.
I most certainly have seen Rails touted as the solution to all web development tasks. Not by anyone whose opinion I would be inclined to listen to, but it does happen a lot, particularly on sites like Slashdot where the quality of debate is generally poor. So the unwary new user is very likely to come in without any idea that the people behind the technology are honest about its limitations, which leads to inevitable frustration.
Thursday, February 16, 2006
>I can't think of any application, where i would need more than 10 or 20 tables.
That is the crazeist post I have seen since Joel shut down the Off Topic Forum.
Bill Rushmore
Thursday, February 16, 2006
You can figure out everything you need from a schema for one-to-many and one-to-one, assuming you're actually enforcing it at the database level, which you should be. A unique constraint on the foreign key is all you need. Otherwise it's one-to-many at the database level, no matter what you say higher up. Rails should be able to pick it up from there. Now, at the time that Rails development started, it doesn't surpise me that this wasn't included, because it was all based on MySQL 4.x, which was hardly a database. I might just be twitchy because I used PostgreSQL, which understands foreign key constraints and such properly. Maybe with MySQL 5.x out there they'll add it.
I believe MySQL5 still ignores FKs in the default MyISAM table type.
Jonathan Ellis
Thursday, February 16, 2006
Regarding the use of database metadata in the rails model I had a discussion on the RoR mailing list.
The basic point there was that the db is considered somewhat evil and that other than then table and column names, no information is extracted from the db schema.
Regarding the server restart. It was necessary to restart the server, because the config what database to be used has been changed. David shows later on to change a table structure without restarting the server and still picking up the changes.
And yes, from what I understand rails reads the table metadata on each request, but I might be wrong.
Mariano Kamp
Thursday, February 16, 2006
I've been working with rails on and off for a few months, and I'm impressed.
There are some real advantages past the first 15 minutes, that I've slowly discovered as I've gone looking for constructs I'm used to from other web development environments.
Sure, it's evolving, and nothing is perfect, but there are a few good things that no one's mentioned:
0) (ruby is simply a pleasure as a language. It's the most fun I've had since tcl.)
1) The framework is pretty good at getting out of your way. Every reasonable default I've wanted to change has a simple way to override it with something else. Not having to break the framework to sidestep its defaults is HUGE.
2) The focus on testing and deployment is strong. This is often ignored if you're building a "15 minute" app, but it's critical for real-world development. I've done massive web app deployments, and I like what I see here. It's powerful without being overly complicated.
3) The natural and semi-automatic mapping of urls to object methods is clean. There are some other options I'd like to see here (and they may be available - I haven't yet had opportunity to dig as deeply as I like), but what's there is easy to use.
Perhaps it won't spit out the perfect application for you without any work, but for someone who's built a lot of web applications and already knows what they want, rails takes away a lot of the drudgery in an elegant way. I still think java is more appropriate for large projects, and php is handy for single pages, but rails fits a nice niche for fast development of everything in between.
Adam Fields
Thursday, February 16, 2006
"I still think java is more appropriate for large projects, and php is handy for single pages, but rails fits a nice niche for fast development of everything in between."
Even though the language can be a pain, I have yet to find a platform that has a simplicity of implementation comparable to PHP.
I do all of my development on the .Net platrorm, and you know what....it all works. Why people have to go out and try to create all of these .Net alternatives that suck, when they can spend their energies trying to make .Net perform the way they want to is beyond me.
I can do some really amazing things with asp.net, c# etc. and I'm happy to do them, happy with the tools, and happy with the developer community, the support, the updaes....I just don't get the anti Microsoft crowd at all. The whole rant mentioned mysql, perl, all of the free stuff that's been out there, without mentinoning anything microsoft....as if it was an unspoken type of word.
I'm glad your frustrated with rails, try c#...it's actually pretty cool and well documented
Why don't you use JScript for .NET development?
Hank L., by what I have seen of C#/ASP.Net, they are kind of reinventing the wheel here and there as well. For example, while in ASP.Net people have access to DataSource components, some folks are looking for and creating their own semi-working Data Mapping solutions (ORM or DAO). So, the grass is not necessarily greener over there as well, unless all you need is a good paying job. :-)
Lost but recovering
Thursday, February 16, 2006
If you're the DBA of a large database with dozens (or hundreds!) of tables you come under pressure to maintain the integrity and accuracy of the data as it is pounded by dozens (hopefully not hundreds) of applications.
So you wish for a place to put code to protect the data from the one or two (or three) apps that have errors in them. Two or three different apps written by two or three different teams can have mere inconsistencies at the "Philosophical" level about the same data and big conflict eventually arises. And the DBA is tasked with finding a solution. So the DBA asks for tools to protect the data and surround it with cushions of logic and integrity.
That's how we got here. The DBA tools, however, are not object-oriented software and generally the "Software" is not under source code control and the evolution through time of the integrity constraints is different from that of the applications and big meetings are held. And the people at the meetings Do Not Understand the Problem. I promise you.
Microsoft, in it's wisdom, it plunking it's entire frigging application toolset into the database and stuffing an orm-like thing called LINQ into the C# language. And we'll see how that works. Clearly they have identified a MARKET for tools to entangle the data with the software in new and complex ways. You might choose to pray that they are wrong and go bankrupt but YOU TOO will be subject to those same pressures...
Thursday, February 16, 2006
Oh, and the Rails documentation sucks like a thermonuclear Hoover and I have finally realized I was supposed to read the dang source. Of Rails. In Ruby. Which I will now proceed to attempt. In my copious spare time. Oh, the horror.
Thursday, February 16, 2006
I personally had great success with Rails, despite being extremely inexperienced. However, the Book -- which is the de facto response to, "how do I learn Rails?" -- was a miserable waste of money.
By the time I had a chance to read it, I'd already learned 99% of what it could tell me, just by building a quickie and following one or two demos. To get anything real done, the API is the only way -- that, and fiddling around with stuff and hoping it works.
The chapter on test-driven-development in the book was better, and more useful, but like the other chapters, it was keener on showing off the basics (which I could figure out on my own) than in helping me Get Stuff Done.
Nick Ragaz
Thursday, February 16, 2006
I'm glad David came in to address the fallicious points made by the ranter regarding the technical aspects of Rails. In particular, I would like to echo the sensibility of why certain things like relationships and validation are relegated essentially to the application code. Namely a) the inability of the schema to cover all the bases, and b) fucking consistency! The latter is a hallmark of Rails that is beautiful in this mess of a world. Convention over configuration, follow the rails and you'll go really fast, etc.. basically get off your ego, and either work with a good idea the way it was meant to work, or shut up and go pick another tool already. Or, of course, a la all open source, make it better maybe?
"Who am I kidding? I say this because I like to complain."
No shit? But who am I kidding, so do I. ;)
At the same time, I would say that the rant's author made the classic mistake of freaking out prematurely before actually learning about key facets of what he's using. It has seemed to me that many Rails newbies suffer needlessly because they did not take the time to learn basic facets of Ruby and/or Rails, the former especially so.
I have little pity for this. I feel too much pity by my fellow hackers for this kind of incompetence will lead to a lapse in standards and quality that is wholly unecessary. I recall Obie Fernandez telling me at a Rails presentation in Minneapolis that the best way to get going was to read over the API. I sorta thought this sucked at the time, as the API was massive and didn't direct me along a certain course. Well, I now feel that attitude is just the all too common laziness associated with growing up in a culture where we expect everything to be instant, automatic, and handed to us. Personally, I picked up Pickaxe Dos last summer and read it cover to cover before I wrote a line of Ruby code period.
I'm glad I've done more learning how to fish than accepting fish as charity.
> do relations; it just doesn't magically figure them
> out from the database.do relations;
It's not just that, relations that have attributes aren't updated or deleted correctly. I finally figured out you are supposed to create a model for each relation with attributes, which to me doesn't make sense.
son of parnas
Thursday, February 16, 2006
A few points:
1. The 'restrictions' aren't. Most of what you're ranting about wrt table names and key names is completly overridable. Rails doesn't say you must name your table authors, only that if you name your table authors it will be found by the model Author auto-magically. Call it _AU_egomaniacs for all Rails cares you'll just have to specify that. Play according to Rails' philosophy and you'll be rewarded with less work to do, but you're ultimately free to do whatever the heck you want.
2. A lot of the assertions wrt how to use the database (lots of views, triggers, stored procs) reflect a point of view that is hotly debated in the software development community. DBA-types often advocate using stored procs and triggers extensively where many programmers (especially those building apps that should run on MULTIPLE RDBMSs) prefer to keep their logic in the application, thank you very much, rather than their storage medium. As for data integrity, Rails is a Web Application Framework, not a replacement for a good DBA. Guess what, it takes 90% of the work out of building your tables with Migrations, but it doesn't absolve you of the responsibility to protect the integrity of the data layer or of creating appropriate indexes for your data. Stop confusing the issue.
Rails isn't perfect. No software is. But let's be fair and talk about it's actual deficiencies (multiple databases and multi-database transactions, easy localization, doc/literal web services, better newbie docs) instead of things that have nothing to do with the problem space it's trying to address.
Christian Romney
Thursday, February 16, 2006
"One of the things I like about Rails is that it's never been presented as a panacea to all our Web application development problems. The people behind it are upfront about its limitations and what it can do and also what it will never do."
What? DHH presents the damn thing as the solution to every single problem in the world. Get real.
ashes to ashes
Thursday, February 16, 2006
Warren: If you're the DBA of a large database with dozens (or hundreds!) of tables you come under pressure to maintain the integrity and accuracy of the data as it is pounded by dozens (hopefully not hundreds) of applications.
This is the difference between an Integration Database ( http://www.martinfowler.com/bliki/IntegrationDatabase.html ) and an Application Database ( http://www.martinfowler.com/bliki/ApplicationDatabase.html ). Rails is focussed entirely on the Application Database.
There are places where Integration Databases are appropriate (billing systems are probably one, but even those could be handled with chained Application Databases), but "modern" thinking is that each application should have its own database or be talking to another application via a Web Services model.
Austin Ziegler
Thursday, February 16, 2006
The main issue with RoR is not its own technical merits -- it's just all the hype that has recently appeared about it, with people referring to it as a be-all-end-all of Web development etc.
The point that should be kept in mind is that it is just another Web development framework, which is written in Ruby and uses Ruby as its own internal language. That fact alone gives it some advantages over similar frameworks written in, say, Java, but we would need to compare all the available frameworks to make the best judgment.
And we would probably end up with a conclusion that while it is better in some areas it sucks badly in others -- just like any other framework. The point of frameworks is to automate and simplify certain aspects of development -- I mean, everyone can write a Web application from scratch as a CGI-based application in any non-specialized language, such as C or Lisp -- and no single framework covers all of the aspects in a perfect way. For example, PHP (essentially a specialized Web development framework implemented in C and using its own language for internal scripting) does a great job of integration with various HTTP servers and integration with HTML; however when it comes to automated ORM -- an area where Rails excels, even if not perfectly -- it sucks big time.
Again, the main problem with Rails is the hype that surrounds it. Developers looking into it should consider carefully all its facets, and decide for themselves whether it fits their needs or not. I've looked into Rails and while it looks like areally wonderful achievement, I find it quite inappropriate as a base for my future Web development.
This seems to me a good example of a bad attitude. You want everything done up nicely for you but aren't interested in lifting a finger about it.
It seems to me in the world of software, there are users and contributors. There is only a certain ratio that can be maintained. In the case of a company, as you add users you add employees. In the case of open source, you attract contributors.
RoR is generating lots of hype and attracting more users. IMO the barriers to entry should be left high so that the casual users and whiners give up and go home to the tools they are used to.
That was one thing that was incredible about the Ruby community a couple of years back when Rails was just a seedling. Lots of professionals, contributors and great folks.
Perhaps the only good complaint about Rails should be that it attracted the masses.
And one more thing: Seth states that the best way to learn RoR is to read API. This is true in a way, because you will never need all the features of a framework at the same time, but just because this is a framework the documentation itself must be much more than a laconic Javadoc-like collection of method descriptions. Again, for an example for how to write a framework documentation I point you to the PHP "manual", as they call it; MSDN is also great, but as it covers all Microsoft technologies (except Flight Simulator, as someone once said), it is a bit too all-encompassing and easy to lose oneself in.
I would like a way to autogenerate validators in the model to prevent the 80 character entries being cut off for a 40 character database field as well. It does feel ridiculous to constantly specify everything in the database and again in the model.
And if you can't do it perfectly with foreign keys, that's ok. Some kind of 'infer as much as you can' script would be nice, and then we could go in and tweak all the non-obvious ones. But this is less important than the fields validations, as settings up the relations in the models doesn't take very long at all anyway.
Thursday, February 16, 2006
"You want everything done up nicely for you but aren't interested in lifting a finger about it."
Is that a response to my post? If so, it is both short-sighted and insulting. If not, I apologize.
I am very interested in lifting a finger about that, thank you very much -- up to the point of writing an expanded framework based on a platform I have chosen as having the set of features that best fit my needs. Please note that this is a purely personal decision, and I have no intention to force my choice to anyone else.
I won't apologize that Rails simply isn't that platform, for various reasons that I won't go deeply into (while some coincide with the OP's experiences). If it was, I would happily expand onto it and offer my contribution to the open-source community behind RoR. As it isn't, I'm doing the same somewhere else.
Luke, you missed one of the coolest cheatsheets:
I love cheatsheets for learning. I think you could fit the essentials of rails into 3 or 4 dense pages, including tiny examples and whatnot. A single place to gather up all the unwritten rules and conventions that trip up people when learning the system.
Thursday, February 16, 2006
I don't think I implied that reading the API is the "best" way to learn the framework at all. I did mean to imply that many could surely benefit from reading it at all, or at least before they start blindly hacking or wasting their time on forums and mailing lists.
Thank you, Seth, I stand corrected.
So Seth, you are basically going for the Slashdot Standard(tm) "you dont like it, FIX IT, jerk!!" reply?
You dont like x-windows? It's open source! Fix it your self!
Dont like Firefox's memory leaks? It is open source! Fix it yourself (jerk!).
Dont like the lack of XYZ in ABC? It is open source! Quit whining and fix it!!! (jerk!)
Here is my slashdot reply:
-1, Troll
Cory R. King
Thursday, February 16, 2006
"What? DHH presents the damn thing as the solution to every single problem in the world. Get real."
Bollocks. He's always said that if it doesn't fit your particular situation then use something else.
No, I would not say that is an accurate appraisal of my commentary, either. You'll note that the point you're emphasizing was tacked on at the very end with no further emphasis on my part. It was a light suggestion that is entirely relevant to the situation at hand.
I don't really ever read Slashdot, though, so I can't be certain that I'm not emulating their behavior. Either way, I think you have me inaccurately pegged.
I'm sorry, the Rails Sentient Engine Project has been delayed due to too much DoD:Source playing.
Nano-Rails Ninjas -- or -- the Rails Sentient Engine ® Project
* These will be embedded under your skin and behind your cerebral cortext.
* Will write your Rails applications for you (even more than standard Rails), in your sleep.
* TODO: Figure out a way to turn off the nano-rails when they become self-aware.
But in all seriousness, if you're interested in checking out Rails, I suggest the following:
- build a basic rails app (follow along w/ the video demo at home, for example)
- build a "medium-sized" web app (whatever that means). 10 tables or so.
- learn Ruby along the way / at the same time.
Yes - it's a good idea to invest in the Ruby Pickaxe, and even the Rails book. But if you build your apps before reading through the Rails book, one commenter was correct that you'll have learned 80% of what the book says already. You'll at least pick up some really handy tips you might not have learned about yet. ("rake --tasks" for example)
I just have one anti-rant to go right back atcha:
If you have _not_ given Rails a chance (as outlined above), it can be really annoying trying to talk to you about it. Sure, vice versa may be true as well. But I've tried _your_ frameworks / languages. (J2EE, ASP.Net/C#, OO PHP MVCs, etc)
Trust me - I know what you're thinking about Rails if you haven't tried it yet. ("What is all this FUD? Why is it garnering all this media attention by such big names? I've been burned before by the 'Next Big Thing' so this surely isn't any big deal." Or "Oh, it's just an MVC written in Ruby. My framework's got that." etc)
Just give it a try, a chance (10+ tables or so here, with lots of relations and all that jazz), and then make your judgements.
If you have tried Rails (built a 10-table+ app using it), disliked it, and go back to php/j2ee/asp.net, great! It's not for you. I have no problem with that. But at least you can now discuss the topic intelligently instead of the Ranter above (who could have instead had many of his questions answered in about 2 minutes by a quick stop on the #Rubyonrails IRC channel).
Shanti Braford
Thursday, February 16, 2006
Rails is good. Rails is bad. Things we create are optimized, consciously or not, towards some goal, to fit some purpose or vision: Apache towards standards. AOLserver towards speed. Perl towards text manipulation. Java towards platform independence (and very large development projects :). Ruby towards simplicity in understanding. Sometimes we optimize well, sometimes not. Sometimes we cannot optimize as well as we would like because what we are creating sits on top of something else (Unix, Windows, Java JVM, ...) and we choose to work within those constraints.
Rails' creator had specific goals in mind, a specific problem area he wanted to tackle, and he continues to make choices in an attempt to keep Rails true to his vision. Some of those choices make Rails an inappropriate tool for some applications, but those same choices also make it an excellent tool for others. Some of the restrictions mentioned above are only ridiculous with respect to somebody else's vision of what "Rails" should be. The rant does point out some issues with Rails which look like they would be improvements, but to try and make Rails fit a much wider application space in ways that violate its core vision would, I think, be a tremendous mistake.
Full disclosure: Although I am experimenting with Rails, I don't use it now and have no plans to use it in the future. I do like many of the concepts that are inherent in the Rails implementation and will be applying those to my own set of tools where they fit.
Rails seems like a cult to me, and I don't want to be at RailsConf Jonestown when DHH orders everyone to drink the cool-aid.
Anyway, for a different approach that solves some of the problems addressed in the rant, check out Qcodo:
I believe the rails demo in the 'slick 15 minute presentation' was running in Production mode for speed. In the 15 minute demo he did not want to wait 2 seconds every time he did a page refresh, and so he had customized it to skip some time-consuming reflection processing.
It's also possible that this was an old constraint that no longer exists.
In normal Development mode, you don't have to restart the web server for any changes.
For those missing a Rails manual, there is a rails manual at http://www.railsmanual.org
My suggestion to everyone new to this would be, spend a few hours or a day getting to grips with the Ruby language itself, I would assert this is the major learning curve. After that, Rails is pretty straightforward to grasp, although it takes a little getting used to.
I first came across the Rails thing over a year ago but only started using it much later. As programmers, most of us don't jump on a 'bandwagon' too easily. However, the kind of momentum it has gained, and so many developers reporting gains in productivity and enjoyment is JUST PLAIN EVIDENCE.
I can see where you are all coming from, dear doubters. You have been burned before. You see, most 'hypes' are corporate-driven: Java and .NET got picked up not because these technologies were incredibly cool to work with, but because Sun and Microsoft could afford to invest millions in pitching it to the 'deciders'. DHH, or the public domain for that matter, cannot create this kind of 'hype' artificially, so those developers feeling pressurized all over again don't really have a reason to. Just ignore it if you don't like it, or improve it. I can understand people complaining about stuff pitched by MegaCorp Inc. that they paid 10K+ for, but surprisingly, many are more inclined to complain about stuff developed by a community of volunteers free of charge. Indeed, like children they complain like something they have asked or paid for doesn't quite fit their mood.
There are two ways to slide easily through life: to believe everything or to doubt everything. Both ways save us from thinking.
~ Alfred Korzybski
Wow, I'm genuinely surprised by the strong response. I went from zero to DHH in like four hours.
Here's what I've decided after reading the comments: I don't think anyone really understands the Rails phenomenon, not even DHH.
After all, if you go watch the Rails video demo, you'll hear DHH talk about how scaffolding was never intended to be an important feature of Rails, much less a key selling point. It was just an entry in the appendix of the Rails spec, DHH says.
Sorry to talk about you like you're not here, DHH. I know that's rude.
Anyway, this thing, this framework, has gotten away from all of us. It defies easy understanding. Scaffolding has become a crucial, central feature of the framework -- even though DHH had it in the appendix. Most of us wouldn't have tried it out if not for scaffolding.
So the users of rails clearly have a different conception of rails from many top rails developers.
Why? Well, for one, Rails is not on, well, rails. Not really.
It _is_ on rails in the sense DHH seems to have intended -- some opinionated choices have been made for the developer, who trades some freedom for speed. Just like taking a railroad instead of driving a car.
This explains why certain features are missing or underplayed. Scaffolding does not represent a Serious Development Choice, so why emphasize it? And when we look at relationship setup as a Serious Development Choice, we are reluctant to make a default choice on behalf of the user, because that could lead to a Serious Mistake.
Like specifying a relationship as one-to-many when it is *really* one-to-one. How awful would that be?! I get cold sweats just thinking about it!
OK, that was snide. I apologize.
We're talking about code, not steel. That's the trouble with taking the Rails name too literally. Rails is actually *really* flexible. It's just some Ruby code, after all. I'm pretty sure that makes it a Turing machine, or, if not, something that sounds similarly smart.
I argue Rails, the framework, is actually a lot more like a scaffold, the stuff used to prop up buildings as we work on them, than like rails, the parallel iron bars used to convey trains.
I'm sure DHH will just *love* that metaphor. ;->
Here's what is so brilliant about Rails, and it goes WAY beyond Rails being "opinionated": The payoff for your programming work comes fast.
You, programmer, create your database tables based on your data model. This is a very very common first step for Web developers. But, before rails, most Web developers had no immediate payoff from setting up the db. There was more work to do, at the very least writing some model subclasses against an ORM and some basic templates against the models and then a simple controller. That could take hours.
Rails says, "Forget that, I ain't waiting." You make the database schema -- BOOM -- you can play with it. You can immediately take a "look" at it through scaffolds and generated models. You can look at something in the Web browser.
This gives programmers a hard on.
Maybe not literally, but it gives them pleasure right from the brain stem.
After all, why do you program? What makes it so fun and rewarding? Unlike almost any other profession, you can get concrete and immediate feedback _as_you_build_. The real architect will wait YEARS to see the results of his craft, but the code "architect" can have something to play with in weeks, days -- or minutes.
A real author will wait days or weeks or longer to publish his words and then hear back whether they did anything for the readers. The software "author" can find out in an instant if his writing worked. Does it compile? Does it past tests? Does it run? Does it WORK?
This, I believe, is the real reason programmers can stand to work 16 hour days during crunch periods. The work tickles something deep in the primordial mind. There is a basic, essential pleasure that comes from doing work, testing it, getting feedback, and doing more work based on that feedback.
Edit. Compile. Test. Edit. Compile. Test.
When you compress that cycle to hours rather than days weeks or years, it can feel even more euphoric. Hours become minutes, minutes become seconds.
Setup database. Scaffold. Test.
Setup relationships. Test.
Generate templates. Test.
Tweak templates. Test.
Alter controller. Test.
Add authentication via plugin. Test.
Setup user roles. Test.
Other languages or frameworks, especially pre-rails, require the programmer to do three or four or all of those steps *before they can test once*. How tiring. Might as well go into architecture! The real kind.
The point of all this is that developers sould start thinking of Rails as crack and stop thinking of it as rails.
That sounds wrong, I know.
But when you think of Rails as a enabler of frequent testing, sort of like a drug enables frequent brain stimulation or a scaffold enables out-of-sequence construction work, it starts making more sense to emphasize the generated "scaffold" templates rather than treating them like bastard stepchildren.
Or to make some guesses about setting up relationships, even if they might be wrong.
In Perl there's a saying: "Make easy things easy and hard things possible."
Ironically, I think Rails accomplishes that better than any framework in Perl. (Disclaimer: That may not technically be ironic. Offer void where prohibited.)
People are saying you just can't guess relationships. Well, go figure out how Class::DBI::Loader in Perl does it, or go read Randal Schwartz's February 2005 Linux Magazine column, where he does it before Class::DBI::Loader learned how.
I am not sure exactly how they figure relations, but my guess is, they go ahead and guess at 1-to-many in ambiguous cases. After if all, if that guess is wrong, what is lost? You don't LOSE any constraints that would have been there, and yet you make huge gains in ease of use for the common case.
The user is still free to explicitly specify one-to-one in cases where such constraints are important. Autogenerated relations would be overridable.
Easy things become easy, hard things become hard. The crack gets a little stronger, because when you hit the Rails pipe after setting up your db schema, you get a bigger payoff. Baking Soda Free, to quote the rapper Kokane.
Especially if you amp up the scaffolding to examine relationships and autogenerate intelligent popup menus.
And if you autogenerate field validation. Yes, developers will need to override with special validations for passwords and other fields, but that's a lame reason not to do it in the first place. (If you had said "not enough time to implement," I'd have said, "well, of course, that makes sense.)
If rails is crack, all of a sudden you have a logical way to write your documentation. You already walk the user through the first few hits, what with the video demo and onlamo tutorials.
Just keep writing tutoials for the next step, and the one after that, and the one after that. Assume a hugely complex project, but start on the easy bits that everyone needs to know. Users who need more complexity can just keep reading.
Next thing you know, you have a sort of crude manual. Maybe even something you could bind and sell to those of us who ride the subway each morning and don't like hauling 570 PAGE BOOKS!!
Sorry, got a little upset again.
I don't know where I got the idea, by way, that I had to restart to see my database schema. I obviously misinterpreted both the rails video demo and the onlamp article, which has a somewhat vague statement about a change to Rails that requires a reboot.
I swear I made a controller change once and *had* to reboot. But since I tried and failed to reproduce this, you probably shouldn't believe me.
Mea cupla. Which is Latin for, "I'm sorry, but afraid to say so in English."
I stand by my assertion that models are toast. I lost some work setting up relationships, and I certainly went looking for it.
But my point about play still stands, even if I was wrong about reloading and the toast issue has been fixed. Rails should invite play and reward it, and one of the ways to do that, in addition to detecting relationships and beefing up scaffolding, is to respect and integrate data generated by both the developer and the users.
Hopefully Rails and its engines will get better at this as the framework matures.
Thanks for reading and all the kind words.
Oh, and to the people who sounded like they were using my rant as an excuse not to try Rails: I created my rails project, Bugbook, January 27. It was my first ever rails project. I started creating bugs Feb 5, the app was feature complete Feb 12.
It basically apes FogBUGZ in terms of tracking bugs and features and inquiry, tracking bugs by product, priority, etc, allowing assignment of bugs, only allowing creator of bug to close, allowing a variety of resolutions, allowing reopening of closed bugs, keeping a history of all comments and resolutions and reopenings and closings of a bug, all shown chronologically on one page with the bug. It's multiuser.
Of course the comparison stops there. It does nothing with email or discussion forums, no Bayesian filters, no screenshot capture, no custom user-generated views.
Anyway, had I done this project in Perl, I think it would have taken at least twice as long. Not because it's all that hard to write Class::DBI classes or simple templates. But in writing the templates, I would have been distracted trying to make them too fancy, something you don't think about when a machine does it for you.
In hacking together the code, I would have been much more easily distracted by the bekoning warm winter weather here in the Bay Area, because I wouldn't be on Rails crack, I'd be coding for hours before my first test.
The controllers would have been a pain.
And no I don't use Catalyst. It bucks the truism that Perl code tends to be
very well documented. It makes api.rubyonrails.com read like the Economist.
So do consider for Rails for your next project, especially if it's a pretty simple CRUD app that should really not eat much of your time.
Hey, just after I post my two tiny cents, you come along with another _multi_page_essay! Don't you have a blog? :)
Actually, I'm left wondering why you would fear a 570-page long book ... and I though _I_ would write too long comments! :)
Apart from this, aren't 50% of the pages in technical books appendices where you just look up stuff rather than reading them chronologically?
Hey Philipp, thanks for the links. Your documentation project came up and time and time again when I was Googling to find answers to my questions, so you must be doing something right!
I was confused and scared by the title "Edge Documentation," which is why I didn't read your site more. Even after I found out that, in railspeak, this refers to development versions of rails (I think). On quick inspection, your site does look like a more narrative and guided version of api.rubyonrails.com, which is a GOOD THING.
I still want a real narrative linear manual. Why don't I want to read 570 pages?
It just seems to long for a framework manual. I want something more concise.
Investing in learning a framework, first of all, has always been riskier than investing in learning a full fledged language, for a variety of reasons. So, less willingness to invest time.
Also, the whole reason I decided to try Rails is I have a project I need done now, today, now, I need it now, to quote Henry Hackett. I'd like a manual I could read quickly.
If you want a more empirical reason, here's a thought I had the other day in the shower (ya I think about rails in the shower, I'm a winner):
The definitive reference for the entire Perl programming language -- a language not known to be simple to document -- is 1092 pages. This means one of the following must be true, based on the length of the rails tome and assuming the rails tome adequately documents the framework:
1. The Rails framework is 52 percent as complex as the entire Perl programming language. Yikes.
2. Rails is more than 52 percent as complex as Perl, but Larry Wall and his coauthors are weaker writers than DHH and his coauthors.
3. Rails is less than 52 percent as complex than Perl, but DHH and his coauthor are weaker writers than Larry Wall and his coauthors.
4. The Perl Programming language cannot be adequately documented in 1092 pages, therefore we can draw no conclusions comparing the two deadly weapons aka "books."
My money is on 3, but only because DHH is a busy guy or has a misguided publisher.
Not my site :)
I vote that Rails is less than 52% as complex as the Perl language, but the documentation couldn't decide its target audience. The first third of the book was designed as a walkthrough (tutorial), with the belief that at the end of the walkthrough you would know enough about Rails that you could skip the rest of the book. It was also meant to prostletyze(I don't need no stinkin' spellchecker!) a development methodology.
The belief that a walkthrough will leave someone competant to hack Rails is flawed, but Rails comes closer to that ideal than any other framework I have tried. Why is it flawed? Not because of the design of Rails...
Because of the lack of well organized documentation.
If there was a better API reference for Rails, clearer and better written, then that walkthrough WOULD have been sufficient. I think they should have had a walkthrough, and then abandoned the rest of the book to a better organized API reference. Too much was rehashed and repeated... you could SKIP the walkthrough and lost nothing. That was redundant. I think they could have created a far better book by creating an effective reference for the last half of the book. That would have saved 200 pages right there.
They did mention how Rails was under active development, and any documentation would be out of date immediately... but that's what errata is for? They coulda put a website up with their organized API reference. Heck, make it login based (you gotta buy a dead-tree version to get to it), I'd do that. Make it free when it gets out of date, and sell $14.95 PDF updates when major new Rails versions come out.
But Rails needs a better reference. The documentation, as yet, is quite poor, and I believe this is its strongest failing. Far worse than lack of auto-validation and auto-relations. Far worse than generators that clobber existing code (that is only a problem until the short learning curve passes and you don't need generators anymore). Lack of clear, accurate, comprehensive documentation is the biggest albatross Rails is carrying around right now.
I hope it gets addressed. But, you know what? I like Rails anyway. I've been working with it for under a month... and it has already significantly sped up web development for me. I love Ruby. I like Rails. I can live with the forced convention changes. And I think it's the best RAD web framework out there.
Some things are pure bliss... the caching system is a dream. Ruby itself is so fun to work in. It has flaws, but it has more truly gleaming sparkles that I have not seen anywhere else.
a Hack,
You are using bad logic to draw out concrete data about the complexity of Rails and Perl.
I have an english dictionary here that is about 1070 pages. Therefore Perl must be about equally complex as the english language.
Sorry. Doesn't it work that way? Maybe there are many other factors involved. For example, what is the purpose of the book, how many diagrams does it use, how much narrative .. how many code snippets?
Not the least of these considerations is who the book is written for. A scientist could explain a complex theory to another adequatly in one page but would have to write a three volume dissertation to explain it to a freshman in college.
So you ultimately can't infer anything about the complexity of either Perl or Rails. You also cannot infer anything about the writing skill of anyone.
On the other hand, we may be able to come to a few conclusions about your logic.
Someone said the a foreign key can't distinguish between 1-many, 1-1, or many-many relationships.
Thats not true. If the key is unique it's a 1, if not it's a many. Primary keys are always unique so that side is a 1, the other side usually is a many - but if it's unique then it's a 1-1 relationship (rare, but you can do it). And if you are relating two fields that are not unique it's a many-many - which is semi useless, but it's there.
Thursday, February 16, 2006
Rails != Scaffolding
It was a nifty little feature to get you up and running.
Christian Romney
Thursday, February 16, 2006
a Hack, and whomever else it may apply,
Of course the scaffolding was used as a selling point... but I believe you are confused about the subsequent step back from that.
It seems to me that it was because of so many people deriding it as useless because they failed to grasp that it was called "scaffolding" not "just add water."
If people were using their inaccurate interpretation of something I created against me like that, I'd try to shift the emphasis as well, since apparently simple statements using clear language do not suffice.
But, of course, I could be wrong there. Either way, what I said about the essential nature of scaffolding applies. Don't act like it's supposed to be something it's not.
After using Rails for 1+ year, I've got some concerns too. I love Ruby (although even it could be improved). And I've got to say, Rails really makes me productive. But it could be so much better.
1) The Rails documentation does really suck. I've been using Rails for over a year now, and I still have a hard time finding the info I need. The book helps, but doesn't get into the really gnarly stuff much. Hopefully this will improve over time.
2) ActiveRecord is just OK. I know I could replace it with something else; I just haven't gotten around to it. The FK issue is a pain. Worse is the abysmal handling of many-to-many relationships, especially when these tables have their own attributes. It's really difficult to update these tables.
How about tables with primary keys that are not auto-increment integers? DHH hates these, so he hasn't implemented them in Rails. So you have to hack your way around them. And God forbid you should have a M-to-M join table where one of the PKs is a character field - yikes!
And in general, God forbid you should have to work with a pre-existing database schema.
3) DHH is sometimes Rails' worst enemy. OK, he's built some good software, and he's obviously got a knack for publicity. But could he be any more arrogant? Jeez, his response to everything is 'That's a terrible idea. My way is the right way. No logic in the database! You shouldn't do it that way, so Rails doesn't.' I guess he's entitled to his opinions, but come on. Who wants to use software led by a guy like that? Plus I get the feeling he just doesn't have a lot of experience in the *real world*. His opinions are sometimes, shall we say, not well informed.
4) ActionView could use a lot more helpers to assist with building standardized pages easily. I think this will improve as people write their own and contribute them.
5) I'm beginning to think that the whole MVC framework is a bit too simplistic. Maybe it needs about two more layers. I've got a lot of application-specific stuff in my models (because they're specific to the model). I think there should be a layer between the controller and the model, for model-specific code that is not shared between apps.
Likewise, try as I might, my views get junked up with code too. I'd like to keep the view as close to clean presentation code as possible. So I'd probably put a layer between the view and the controller to handle stuff like getting and organizing the data for the view. Then I could make the controllers just handle navigation and dispatching.
6) I have a hard time componentizing stuff in Rails. Components don't seem to work as well I hoped for this. My apps have so many reused components, but sometimes I have to cut-and-paste way more than I should. I'd really like to define sections of views once, with their supporting code, and drop them in anywhere I need to use them. Sometimes you can do this, but often getting things like navigation to work right across many pages is a major pain.
I think Rails is great, especially for small to medium-sized web apps. But for larger, more complex apps, I get bogged down trying to overcome its limitations (we've got 79 models, 33 controllers, and 289 view templates in one app). Now they've probably got too much legacy code to drastically rework things. Maybe it's a great first take, and someone will write a new framework that addresses all Rails' problems from the start.
Scaffolding isn't very useful on actual projects, but it's quite nice when you sit down to learn rails for the first time. It's like a built in mini-tutorial.
Thursday, February 16, 2006
> Who wants to use software led by a guy like that?
Logic in the database doesn't scale. You can easily add more load balanced web machines, you can't easily scale the database.
That's pretty real life. Though in general I agree with your statements.
son of parnas
Thursday, February 16, 2006
> Logic in the database doesn't scale.
I totally agree. I almost never use stored procedures and triggers. Stuff like DB defaults and validation I sometimes use, if it's very important that it always be done on the data, and if it won't hurt performance too badly. But DHH takes this to the extreme. I think he'd rather not have the database enforce integrity rules. Sometimes it seems like DHH would rather toss the database and just use the filesystem...
"Plus I get the feeling he just doesn't have a lot of experience in the *real world*."
The 'real world' of using overly complex frameworks to build overly complex 'enterprise' solutions that, as projects or as software, fail over 50% of the time.
Of course Rails isn't designed for such scenarios. Look at where it's coming from: 37signals don't seem to believe in the all-encompassing, complex enterprise application that everyone and their dogs have tried to build for the last couple of decades, and still didn't quite get right.
Small is beautiful, and if a single application indeed uses over 100 interconnected database tables, you can flex your geeky muscles about how you're managing (suffering from) the 'complexity' (complications) --- or you might want to seriously question some design decisions that were made earlier on.
Out of intense complexities, intense simplicities emerge.
~ Winston Churchill
As complexity rises, precise statements lose meaning, and meaningful statements lose precision.
~ Lotfi Zadeh
"Who wants to use software led by a guy like that?"
- Some guy who has been using software led by a guy like that for "over a year"
"Rails allegedly will ask permission first but, um, it didn't."
Um... it does for the rest of us. Sucks to be you.
Trejkaz Xaoza
Thursday, February 16, 2006
If this was your schema:
Ranter table
- id
Rant table
- ranter_id
how should Rails guess about the relationship? Is it 1-1? 1-Many?
If this is all the metadata in your db, then there is no relationship. Just because you have a ranter_id does not imply any relationship to a Ranter table. However, there can be much more metadata in the database. First off, an explicity foreign key relationship can be defined. No relationship between tables should be guessed at, there should be a foreign key. Now to the question of 1-1 vs. 1-M. If the foreign key column is not declared as unique, then you have a 1-M relationship. No guessing involved here. The database would allow the many part, and it's foolish to assume that your app is going to be the only thing that ever writes to the database. If there is a uniqueness constraint on the foreign key column, then clearly you have a 1-1 relationship. Again, no guess work needed.
Is it too much to assume your database is setup correctly? Is it too hard to get to all the metadata in Ruby?
Thursday, February 16, 2006
I don't think I've worked on an app that has less than 100 tables in probably ten years. Nothing wrong w a large number of tables. Probably means that you've got a well-normalized database for handling complex real-world problems.
I'd be more concerned about the app w/ 289 view templates. They should probably break that thing up. That's the nice thing about web-apps: since there's (usually) no state, it's far easier to break up applications than in client-server apps. One could argue the term 'application' doesn't even matter to web-apps.
Saying that Rails gets tough to manage once the app gets big isn't surprising at all -- that's what happens to most frameworks. Maybe once more big apps get built on Rails, it will acquire those capabilities.
Admittedly there are plenty of problems that call for less than 100 tables, but the number of tables in an app is fairly irrelevant.
Yeah and David Hansson is both a big plus and a drawback. Kind of like that guy who runs JBoss. Hopefully he won't stick his foot in his mouth and hurt Rails.
Thursday, February 16, 2006
Yeah, DHH is a big plus because he is determined, focussed and opinionated. He envisioned something specific (brilliant?) and actually MADE it.
He's a big drawback because he is opinionated, focussed and determined? Primarily because his opinion != your opinion?
So are people fed up bashing on the creation and now moving on to bashing on the creator? Perhaps this trend should be stopped now.
It takes heart and soul and strength to create, but only mindless energy to tear down.
I think the root of this argument isn't "is Rails good or bad," it's "is Rails the end all of web frameworks."
The answer is obviously no. No, Rails can't serve everyone's purpose every time and no one is saying that it can or should. Obviously it has some merits in some circumstances though.
I'm not sure what kind of complex applications you're all writing, and maybe in your case it'd be better to use Struts or Qcodo or .NET or what have you, but for me, and apparently thousands of other developers, Rails does what it says it will do, and does it well. It all comes down to picking the best tool for the job.
Thursday, February 16, 2006
I await the open-source zealots' mantra: It's not Micro$oft, It's not Micro$oft! It must be good since it's not Micro$oft!
I looked at RAILS and read over Ruby's syntax for edification yet I will remain with ASP.Net and C# - these micro-languages are proliferating like rabbits.
Nicholas de Lioncourt
Thursday, February 16, 2006
Well my application is an online blog post management system with over 1400 database tables and I was pretty annoyed when Rails wouldn't let me use VARCHAR(400) as primary keys. We ended up ditching Rails for PHP 3.2 and I'll have to say I'm so happy now that I don't have to drink the kool-aid of DHH and all these Rails "n-00-bs". Perhaps people should think harder before becoming so arrogant and preachy about things like YAML and Dane Driven Development (DDD).
incoherent programmer too close to the UPS
Thursday, February 16, 2006
When I just, this last weekend, tried using CakePHP for the first time to build something apparently suited to it - a civic info lookup, preferably with a nice ajaxy thing on the front to cut on full-page loads, it was a bloody nightmare.
They say CakePHP is like Rails. I know find out how true that is.
A list of functions is not a manual.
A wiki with code snippets from an older, incompatible version of the framework is also not a manual.
David, at least, doesn't come out shouting and abusive and insisting you didn't read the """"manual"""" when you ask questions. So that's one-nil to Rails, I guess.
John Handelaar
Thursday, February 16, 2006
"Dane Driven Development (DDD)"
Although some Danish (as in cookies) Driven Development might actually work...
I've written up a fairly lengthy response to this Rant, as I felt it is completely without merit. You can find the post <a href="http://zifus.blogspot.com/2006/02/regarding-rails-restrictions.html">here</a>
Doug Tolton
Thursday, February 16, 2006
I've been developing web apps for years, in both PHP and Java.
You really notice how much stuff is repeated and unnecessary. How many times to you enter the same variable or field name in the database, in the classes, in the HTML/view? It's a waste of time.
I had developed some helper utilities that are basically a crude form of ActiveRecord.
I used to do a lot of Java development. J2EE crap. Servlets, entity beans, etc. The amount of garbage you have to go through just to get something deployed made me angry.
Seeing Rails was wonderful. It was all my "good ideas" implemented cleanly with none of the PHP hacks or Java verbosity.
Incoming: http://reddit.com/info?id=1zke
Matthew Lock
Thursday, February 16, 2006
Great review. OR mappers are great but only when you can FULLY control and configure them to your styling of code. Other than that they become annoyances. Plus there needs to be a layer before presntation that allows you to take action on the item returned such to the point of your message. Directly mapping to the database works in only a few real-world instances. Why have layers of code if you can't manipulate it once its pulled from the database. This framework reminds me of Jakarta struts in a way on the front end. i.e. if you don't like doing it their way, tough!
Ryan Christensen
Thursday, February 16, 2006
the real problem with rails is that it trys to build an application based on the schema, which doesn't contain enough info, as David HH points out above.
If you built the same framework around an XML file, you could generate the schema and the app at the same time - and - you could include in the xml file all that useful meta data that you need. no more problems with validation or relations, meaningful labels could be specified, etc.
These same complaints could be made about any language, framework, or tool from anyone with a lack of experience with that tool. Spend some time reading the APIs, reading the wikis, read some of the excellent new books, and even inspecting the source to learn how things work and why. Every framework has a learning curve. I agree that Rails could be improved with better documentation, but I'm tired of lazy developers expecting things to be handed to them on a silver platter.
Fact is, Rails solves a large number of web development problems in a very elegant way. Personally, after doing Perl, PHP, Java, and .NET web development at different times over the past 8 years, I find Ruby and Rails a breath of fresh air.
Thursday, February 16, 2006
Hullo. Someone posted about http://railsmanual.org earlier in the conversation. I wrote the code that it runs on (although someone else has deployed it there.) The system is called Rannotate and it allows you to generate documentation with searching, commenting and versioning for any Ruby code with RDoc comments.
If you are looking to help out with improving the Rails API documentation I'd reccomend comng and contributing to the Rannotate project on rubyforge: http://rannotate.rubyforge.org/
Conor Hunt
Thursday, February 16, 2006
DHH says:
"Foreign keys are not rich enough to represent most associations. Not only can't they distinguish between 1-1 and 1-M, but they can't hold any customization."
I've seen him make this claim a few times and every time he does so someone points out that you can define 1-1 relationships with a combination of a foreign key and a unique index. He continues to make this (obviously wrong) claim tho'.
"So there's no way to specify has_many :active_clients, :conditions => 'active = 1'."
So create a view with your conditions and create a relationship to that view. Oh, but wait, most people are using a version of MySQL that doesn't support views. So encourage them to upgrade to a decent version.
Dave Cross
Friday, February 17, 2006
Joel, Rails book is very well written, I read it.
It has some big appendix, so it is huge. But you got all rails in about 200 pages.
There are some good tutorials, at least to start up.
So be carefully to attack rails on documentation side.
As open source products, a lot of info must be acquired asking on the mailing list but ruby/rails api is definitely well written.
Some of your points are right, but the ovall quality or rails is vert very hight!
Giovanni Giorgi
Friday, February 17, 2006
"Sometimes it seems like DHH would rather toss the database and just use the filesystem..."
It worked for Paul Graham when they built Viaweb. See Note 2 in http://www.paulgraham.com/venturecapital.html
John Topley
Friday, February 17, 2006
That was an excellent info-rant piece and equally informative reponse from David-the-rails-guy. Thanks heaps!
Simon Hobbs
Friday, February 17, 2006
Sigh, it's just amazing how many people just won't RTFA. Lots of people don't even realize Joel didn't write this rant!!
Also, this type of idiocy just cracks me up:
Sorry, I won't go to joelonsoftware for anything. That guy is famous in sort of the same way Paris Hilton is famous. Never done anything to speak of, but all the dumbasses will worship him/her.
Friday, February 17, 2006
> Paul Graham when they built Viaweb.
Ask Yahoo if that's how they do it now. The answer would be no because it doesn't scale.
son of parnas
Friday, February 17, 2006
"I await the open-source zealots' mantra: It's not Micro$oft, It's not Micro$oft! It must be good since it's not Micro$oft!
I looked at RAILS and read over Ruby's syntax for edification yet I will remain with ASP.Net and C# - these micro-languages are proliferating like rabbits."
The entire terms of the discussion here are Rails vs. maybe Java, Perl, PHP, et al, and C# and ASP have barely entered the radar screen. Cheesy hackwork like "It's not Micro$oft" hasn't come close to being uttered, and I think it's hilarios that you have to erect a strawman that sorry to knock down.
"Micro languages"? Only if you think there are only a couple or 3 real languages (C++, C#, and Java perhaps), and everything else is a "micro language" regardless of market share. Ruby has been around for going on 2 decades, and Rails is skyrocketing it to make it a first tier language.
Personally, I've done major projects in C# and a smallish project (the proverbial 20 tables mentioned above) in Rails.
In a major project -- my day job is as the architect of an application with hundreds of tables and hundreds of forms, all of which need to be customized for various clients and to share all of the customizations transparently between both a desktop client and a web client... well, ASP.Net comes in pretty handy for that one.
But for the more ordinary 20-table project, Rails was incredibly fast to develop with. Completely dusted what I could have done in ASP.Net in the same time period. I like ASP.Net a lot, but I believe in the right tool for the right job.
>> Sorry, I won't go to joelonsoftware for anything. <<
And yet, here you are.
Cory R. King
Friday, February 17, 2006
"Ruby has been around for going on 2 decades..."
Let's try to keep things accurate, shall we? Ruby first came out in 1995. Even by my dodgy maths, that's nowhere near two decades!
John Topley
Friday, February 17, 2006
I just get a headache!
I think all web framework developpers never will solve the problem.
Because theyre trying to solve the wrong problem.
The real problem is the web standards which are not initially intended for app development.
We place focus and effort on rendering the interface instead of the business logic.
Why are desktop apps much easier, cheaper to develop and more reliable than web-apps??
Stop frameworking and make a good GUI RAD tool for the web, and you'll bee a verry rich person in a few months.
You can't do it (with todays standards).
Because they are for information publishing and not apps.
So please don't waste youre life on frameworks for the web.
Unless you like the idea that people will laugh at you in future historybooks.
RoR sucks big time, as annything else than a fun hobby.
>> >> Sorry, I won't go to joelonsoftware for anything.
>> And yet, here you are.
Or am I...
Just to clarify, *I* didn't say that. That was a comment on digg that a user left. One of many funny comments.
Friday, February 17, 2006
"Why are desktop apps much easier, cheaper to develop and more reliable than web-apps??"
Luke Francl
Friday, February 17, 2006
How many posts does it take to make the point that Joel did not write the rant?
Saturday, February 18, 2006
> Stop frameworking and make a good GUI RAD
> tool for the web, and you'll bee a verry
> rich person in a few months.
A proper RAD tool for the web is hard to do. Why?
So.. if such a RAD tool existed, one had to write code in both JavaScript AND the server-side language. This kind of sucks.
Wednesday, February 22, 2006
Here's the silver bullet: It's called Defining The Problem
We constantly are getting these frameworks/languages/products/methodologies shoved at us without rhyme or reason. Finally a razor to cut through it all. At the end of the day you have to fix the problem. Chances are nobody has bothered to define what it is.
Friday, February 24, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz


text:
Get To Know Gorgeous Babes in Louisville, Kentucky
Admit it dating Gorgeous Women in Denver, Colorado is a nightmare. You can waste countless amounts of time and all of your hard earned money going out to nightclubs and bars desperately trying to find that perfect someone. However, it always ends the same. You spend tons of cash to just compete with a bunch of dudes who are all trying to hit on the same hot babe in the place. Why not improve your chances on meeting a sexy girl by using MeetGirls?
On MeetGirls, you'll find a ton of websites for web dating and find a woman in your city. They make it super easy to find Gorgeous Women in Denver, Colorado and anywhere in the U.S.A.. Forget about wasting any more time searching blindly and start exploring some of the best websites for meeting Gorgeous Women in your city.

subset: commoncrawl


text: Considered one of the great portraitists of the 16th century, Hans Holbein came from a family of artists; his father, Hans Holbein the Elder, and his uncle Sigmund were renowned for their late Gothic painting. While living in Basel, Switzerland, Holbein the Younger gained recognition for his woodcut book illustrations, and met the famous Dutch scholar Erasmus, who invited him to illustrate his satire The Praise of Folly. Holbein also illustrated Martin Luther's German translation of the Bible and produced a famous set of 41 woodcuts depicting the medieval Dance of Death. He later moved to London, where he became court painter to Henry VIII. Epitomizing the Northern Renaissance with his meticulously detailed style, Holbein produced more than 100 miniature and full-size portraits at Henry VIII's court, of subjects including Thomas More, Thomas Cromwell, and the king himself.