There was a presentation at railsconf in 2007 by Bruce Williams where he speaker talked about DRYing up your views. Now, I wasn't personally there but I've read an overview of the talk and I realized something. There were several template systems he compared but there was only one, maybe two, that someone who know html/css could use. That was DRYML and, maybe, Haml.
That right there is the fundamental problem with all of the templating systems, and even the presentation. They were all aimed at ruby developers. Now, if you are doing a small project, this is good. The team probably won't have many people on it and all of them are probably ruby developers. And you want your ruby devs to program in ruby. That's what they know. But this argument falls apart when you work on a large project with actual interface developers.
Working on a large project with many rails developers and a couple of html developers will cripple your development time if you have to use ruby for templating. It means that when your interface devs create a moderately complex site, one or two of your ruby devs have to translate it to whatever templating system you're using and get all the glue between your controllers and views. If your system is very complex, using a lot of javascript and css, then the problem gets worse.
This is why I'm interested in DRYML. I want a template that I can give to someone who knows html/css and be able to write in it. Then, every so often, have one of the rails developers put in the glue between the controller and view to have it working.
Saturday, January 26, 2008
Wednesday, January 23, 2008
Is TDD useful?
I have heard a lot about testing lately. First I was told you need tests. I don't disagree with that at all. Companies wouldn't devote entire departments to testing if doing it was trivial or useless. Automated testing is ideal since you don't have to hire an entire department for this task but this can be difficult and hints at the heart of this post.
Then I was told that behavior driven development (BDD) was important. That you would create automated test cases that try to stress the way certain behaviors of the system should act. This has always seemed very nebulous to me and so close to test driven development that there really isn't a big difference between the two.
Which gets me to test driven development, TDD. The whole idea about this is that the developer really thinks about the method/function/module he/she need and writes tests first that express what that method should do. Supposedly this creates stronger and more robust code. Some developers have really hammered this thought into the agile development world about how testing first WILL create better code and more productive programmers.
Then I read this article. Basically, it says that testing does help but the number seem to show that testing a method after it is written actually creates better code. It says that tests are still really useful but writing tests first don't actually create better code and may actually be worse than testing methods after the fact.
What does this say to you about my development practices? Well, I will continue to write automated tests but the jury is still out on TDD. And, personally, I don't see any compelling reason to change my, or my teams, current development practices based off of some shaky numbers. Especially if it's true that testing after a method is written is better. Change isn't always for the better.
Then I was told that behavior driven development (BDD) was important. That you would create automated test cases that try to stress the way certain behaviors of the system should act. This has always seemed very nebulous to me and so close to test driven development that there really isn't a big difference between the two.
Which gets me to test driven development, TDD. The whole idea about this is that the developer really thinks about the method/function/module he/she need and writes tests first that express what that method should do. Supposedly this creates stronger and more robust code. Some developers have really hammered this thought into the agile development world about how testing first WILL create better code and more productive programmers.
Then I read this article. Basically, it says that testing does help but the number seem to show that testing a method after it is written actually creates better code. It says that tests are still really useful but writing tests first don't actually create better code and may actually be worse than testing methods after the fact.
What does this say to you about my development practices? Well, I will continue to write automated tests but the jury is still out on TDD. And, personally, I don't see any compelling reason to change my, or my teams, current development practices based off of some shaky numbers. Especially if it's true that testing after a method is written is better. Change isn't always for the better.
Monday, January 21, 2008
Merb, this isn't your dad's framework!
I found a pretty cool ORM for ruby a little while ago call datamapper. It looks pretty good and I would love to try it. Unfortunately, if you are using Rails it's pretty hard to use something besides ActiveRecord. In fact, Rail's is pretty tightly coupled and it's pretty hard to use anything but the default gems.
This led me to a framework called Merb. I pointed one of my friends in the direction of Merb and he also blogged about it. Merb is basically a MVC framework for ruby developers that prefers to use gems to add functionality then one monolithic framework. For example, you are allowed to use any of several ORMs for your project. Or templating engines. Merb is also smaller and faster than Rails. That alone is reason enough for me to check it out.
But, there are some downsides. Merb is still very young. It's not even at a 1.0 stage yet. But this post does give me some hope. Also, there isn't a lot of documentation on it yet. Still, there seems to be a lot of promise there.
Personally, I would love to try a combination of Merb, datamapper and DRYML. It would be great to throw DRYML at a good web developer and let them go to town while your ruby developers focus on creating a tight backend with datamapper. There is still an issue with routes but I'll blog about that later.
This led me to a framework called Merb. I pointed one of my friends in the direction of Merb and he also blogged about it. Merb is basically a MVC framework for ruby developers that prefers to use gems to add functionality then one monolithic framework. For example, you are allowed to use any of several ORMs for your project. Or templating engines. Merb is also smaller and faster than Rails. That alone is reason enough for me to check it out.
But, there are some downsides. Merb is still very young. It's not even at a 1.0 stage yet. But this post does give me some hope. Also, there isn't a lot of documentation on it yet. Still, there seems to be a lot of promise there.
Personally, I would love to try a combination of Merb, datamapper and DRYML. It would be great to throw DRYML at a good web developer and let them go to town while your ruby developers focus on creating a tight backend with datamapper. There is still an issue with routes but I'll blog about that later.
Sunday, January 20, 2008
Rails custom formbuilder
Is there no better way to create custom tags than with your own formbuilder? So far, I'm not impressed. I've read through a couple examples and neither one has really satisfied my needs.
http://www.aldenta.com/2006/09/19/writing-a-custom-formbuilder-in-rails/
http://www.railsonwave.com/railsonwave/2007/5/2/create-a-color-picker-helper-with-formbuilder
The first one is fine if you create your own namespace so that all your form_for, fields_for work correctly. I really don't want to start tacking a bunch of names on to my form_for, fields_for. It just leaves a bad taste in my mouth.
What about the second example? You create a class and then use :builder => MyFormBuilder. Well, then you have to start creating the same methods for fields_for and for all the ajax methods. This isn't isn't DRY.
I'm probably missing something obvious here but my real argument is that I have to much around with rails at all to create my own custom tags. Why do I have to jump through a bunch of hoops to create my own special tags to be used in my forms? Why is Rails tying y hands rather than making it easier for me like the framework should?
I really only bring this up because I've used some of Hobo's features. It builds on top of Rails and adds some pretty great stuff. My favorite is DRYML. Basically, DRYML lets you define your own tags to be used as you need. You can override what is already there and create new tags based off of tags that already exist.
One of the best things is that the code that you write looks like HTML. Actually, it is a bit like XML but I forgive the devs. This is good because I can create a library of custom tags and then hand it off to our HTML developer to code to his hart's content. If, at some point, he comes up with some new HTML/JavaScript tag, then that can be added to the library and used pretty quickly.
If you are interested in creating web pages quickly I suggest you take a look at Hobo. It has some blemishes (bad documentation, a lot of coupling, still a new project) but I think that it has a lot of promise. The developers are working hard to fix some of the current problems one of them being the coupling. I'm seriously considering moving over to DRYML when they finally make a gem/plugin out of it.
http://www.aldenta.com/2006/09/19/writing-a-custom-formbuilder-in-rails/
http://www.railsonwave.com/railsonwave/2007/5/2/create-a-color-picker-helper-with-formbuilder
The first one is fine if you create your own namespace so that all your form_for, fields_for work correctly. I really don't want to start tacking a bunch of names on to my form_for, fields_for. It just leaves a bad taste in my mouth.
What about the second example? You create a class and then use :builder => MyFormBuilder. Well, then you have to start creating the same methods for fields_for and for all the ajax methods. This isn't isn't DRY.
I'm probably missing something obvious here but my real argument is that I have to much around with rails at all to create my own custom tags. Why do I have to jump through a bunch of hoops to create my own special tags to be used in my forms? Why is Rails tying y hands rather than making it easier for me like the framework should?
I really only bring this up because I've used some of Hobo's features. It builds on top of Rails and adds some pretty great stuff. My favorite is DRYML. Basically, DRYML lets you define your own tags to be used as you need. You can override what is already there and create new tags based off of tags that already exist.
One of the best things is that the code that you write looks like HTML. Actually, it is a bit like XML but I forgive the devs. This is good because I can create a library of custom tags and then hand it off to our HTML developer to code to his hart's content. If, at some point, he comes up with some new HTML/JavaScript tag, then that can be added to the library and used pretty quickly.
If you are interested in creating web pages quickly I suggest you take a look at Hobo. It has some blemishes (bad documentation, a lot of coupling, still a new project) but I think that it has a lot of promise. The developers are working hard to fix some of the current problems one of them being the coupling. I'm seriously considering moving over to DRYML when they finally make a gem/plugin out of it.
Subscribe to:
Posts (Atom)
