While people still try to find some drama an in hypothetical war between rails and merb.

The Rails team and the Merb team announced working together on a joined version of the 2 frameworks. This is so exciting, nobody believed it could ever happen (I personally, had my serious doubt).

Yehuda had a great post laying down the plan and explaining things in details. Check out David’s post explaining why he wants us to work together and his vision of a better Ruby world.

I have to say that I have been impressed by the Rails core team and especially David (DHH).

I’ve known David for few years now and we had long/heated discussions on topics like i18n/l10n for Rails. David is known to be a very opinionated person. But if you come up with the right arguments, he can be convinced and when that happens, he is willing to move forward and shake things up.

This merge is a concrete example that David and the rest of the Rails team cares about Rails and the Ruby community more than we usually give them credit for. As a unified team, we are going to change the way web development in Ruby is done!

But what does it mean for you?

I put together a FAQ video here is the transcript:

Hi, I’m Matt Aimonetti from the merb core team and as you might have heard, a big announcement was made earlier today.

I did this video to hopefully answer the questions you might have.

Q: So what’s the big news?

• merb and rails team will work together on the next version of their frameworks
• merb 2.0 and rails 3.0 share the same common endpoint
• we realized we now have the same objectives and agreed on all the key principles.
• merb will provide Rails with agnosticism, modularity, improved performance and a public API.
• The end product will be called Rails 3.0 but what real matters is that it’s a huge gain for the entire community.

Q: What??? I thought there was a war going on between Rails and merb, what happened?

• There was no war between rails and merb
• We created merb because rails was not fitting us
• We wanted better performance, more choices/ more modularity and a Public API.
• The Rails team now embraces these concepts and want Rails to follow them, so why not work together?

Q: Wait, does that mean that merb is dead?

• Absolutely not!
• merb development won’t stop, we are going to keep on releasing updates until rails 3.0
• clear migration path, and upgrading to rails 3.0 will be as trivial as upgrading from rails 2.x to Rails 3.0

Q: What does the timeline look like?

We just started getting together and discuss the technical details. We are shooting for a release at RailsConf 2009. However it’s hard to estimate this kind of things so again, that’s just an estimate

Q: I just started a merb project, so what now?

I’m sure you had valid reasons to use merb, you needed modularity, performance and a solid API.

Keep on using Merb, we won’t let you down. The good news is that the next version of merb (rails 3.0) will be even awesomer!

Q: What about my client who was looking at using merb for his new project?

If your client is going to be using merb for valid reasons (and not, just because it’s not rails) he should still use merb, but with the full understanding that he/she will end up using Rails in 6 months or so. Again, Rails 3.0 will have what pushed you to use merb.

Q: I’ve been involved with the merb-book, what will happen with this project?

• rails 3.0 won’t get released right away
• still need awesome documentation
• if we look at rails 3.0 as merb 2.0, we can easily imagine how the current work can be extended to the new version.
• rails team will also include an evangelism team which I will be part of, so will be able to focus more on projects like the book.

Q: I’ve been working on a merb plugin, what should I do?

Keep working on it! We’ll assist you with the migration process and the new solid API.

Q: What if I still have questions?

Come talk with me, or any members from the new team. We’ll be open to hear your questions, worries, frustrations.

merb always valued its developers and we will continue to do so but at a bigger scale.

Lori Holden worked on merb_sequel and we should release a 1.0 release of the plugin in a few days.

I’m sure this news comes as a shock for many of you, but try to not see Rails 3.0 as the way Rails is right now. Imagine a version of Rails with true modularity and agnosticism (sequel, DM and AR will still be supported) and the same type of performance as what you get with Merb. In other words, the rails world is about to discover the power of merb!

Here is what Yehuda explicitly says in his blog post:

• Rails will become more modular, starting with a rails-core, and including the ability to opt in or out of specific components. [...]
• We will port all of our performance improvements into Rails. This includes architectural decisions that are big performance wins.[..]
• As of Rails 3, Rails will have a defined public API with a test suite for that API. [..]
• Rails will still ship with the “stack” version as the default (just as Merb does since 1.0), but the goal is to make it easy to do with Rails what people do with Merb today.
• Rails will be modified to more easily support DataMapper or Sequel as first-class ORMs. [..]
• Rails will continue their recent embrace of Rack, which [..] will improve the state of modular, sharable logic between applications.
• In general, we will take a look at features in Merb that are not in Rails (the most obvious example is the more robust router) and find a way to bring them into Rails.

Personal perspective

I’m personally really excited about this opportunity. I had a hard time believing that we could work together but I was proved wrong. We have many challenges in front of us, but watching the two teams working together is very reassuring.

I’m also glad to see that we will have a Rails Evangelism team that I will be part of. I strongly believe that one of the many reasons why merb has been so successful is because we work and listen to our community. We have put a tremendous amount of energy trying to understand what you guys need and what you like and dislike. In return, we saw many people working hard on the wiki and the merb-book.

Can you imagine doing that with almost 4 Million Rails developers?

I’m also looking forward to working with a team and reaching to even more people.

Other news related to the merge:

• The RubyOnRails website will keep a trace of this historical moment: http://rubyonrails.org/merb
• The merb training scheduled for Jan 19-21 in partnership with Integrum will still take place, and if you want to get a head start and learn about the things that will make Rails 3.0 totally kick ass, I’d suggest you join us.

If you have any questions, or if you want me to publicly answer questions on your blog please contact me. I’ll do my best to get back to everyone.

Anyways, I have been quite busy preparing courses for classes I gave to a bunch a great Engineers at one of the Fortune 100 companies based in San Diego. I was also planning my big vacation trip to Europe and wrapping up few projects.

However, during my exile overseas, I came to the conclusion that Rubyists don’t scale. Since Twitter became stable again, we don’t hear many people ranting about Rails not scaling anymore. With one of my clients’ app handling around 7 million requests/day I can tell you Ruby/Merb do scale quite well! But ruby developers don’t seem to scale for some reason.

Maybe saying that we(Rubyists) don’t scale isn’t technically correct but that’s basically what one of my client told me.

Let’s go back in time a little bit and follow my client who we will call clientX.

• ClientX has a great concept and wants to conquer the internet.
• ClientX hears that Rails is the way to go.
• ClientX hires a contractor/mercenary/freelancer/guns for hire/consultant (aka Me)

• Me builds a killer app using Merb (killing framework)

• ClientX raises loads of $$$

• ClientX wants to hire a team because Me doesn’t want to become a FTE

• ClientX and Me look for Rubyists wanting to relocate and get a decent salary

• ClientX *can’t find someone they consider good enough and who would accept their package

• Many JAVA guys are available on location and accept lower packages

• Ruby app gets ported over to JAVA
• Me sad

So is it really the Rubyists’ fault if we don’t want to relocate and only accept higher packages? Should I blame Obie for telling people to charge more and teaching how to hustle? Or should we just tell clients that it’s time to get used to working remotely?

Honestly, I don’t think any of the above explanations are valid. Ruby is the new/hot technology and very few people have the skills and experience to lead major projects. These people make a good living and enjoy their “freedom” and dream of building their own products. Most of them/us value their work environment, family and are reluctant to move.

At the same time, companies do need people locally(at least a core team) and can’t always afford the cool kids.

ClientX, quite frustrated by the whole hiring process told me once: “you Ruby folks are too unavailable and difficult to work with! We need a committed team that actually cares about the company/product.”

That hurts when you worked hard on a project and just can’t satisfy the client by finding guys willing to relocate and work for them. It gets even more painful when your code gets entirely ported over to JAVA!

But at the same time I understand ClientX’s motivation, PHP guys are cheaper, JAVA guys are more available, why in the word did we go with Ruby and are now struggling finding people?

Once again, there is positive and negative side in everything, by choosing Ruby and a “great contractor” ClientX was able to catch up with the competition and even pass them in no time. They quickly raised good money and got everything they needed to become #1. I don’t believe it would have been possible to do the same thing so quickly with JAVA for instance. However choosing a cutting edge technology means you need to look harder for talented people.

It’s too bad the code gets rewritten in a different language but at the same time, I do my best to facilitate the process and to keep a good relation with my client. There was nothing personal in the decision, it’s just too bad we were not able to keep on using the latest/coolest/awesomess technology available

To finish on a positive note, here is the solution to scale your Ruby task force provided to you by the #caboose wisdom:

Based on my conversations with other #caboosers who hire other devs, the word in the street is that you just need to get one or two great ruby guys (who will probably cost you a lot) and find a bunch of smart people to train. You’ll end up with an awesome team of scalable rubyists

• RailsConf 08. Great conference, probably my last Rails Conf though. I’ll be in Orlando for Ruby Conf 08 and I’ll focus on 1 or 2 local conferences (probably mountain west and another one).

• MerbCamp 08 in San Diego this Fall organized by SD Ruby. Details are not finalized yet but Yehuda Katz announced it during his Merb talk at RailsConf.

• Moved this blog to a new Joyent accelerator with git support and finally have the possibility to use Ambition! (planning on moving from Mephisto to Feather)

• Launched a client’s Merb app and getting around 3 million hits/day. Merb is just awesome. (more info when the client’s app gets out of beta)

• I’ll join Gregg Pollack from http://railsenvy.com/ during Qcon and take part in the Ruby for the Enterprise track. My talk will focus on Merb usage in real life.

• Renamed my github username, new repo url: http://github.com/mattetti (sorry about that)

If you follow my blog, you already know what Merb is.

I love Rails and I truly believe it has changed web development. At least it has changed the way I do web development.

But Merb looks slick, apparently is way faster than Rails, and has less “fluff” and less magic.

Now that we are getting really close to a Merb 1.0 (scheduled for Rails Conf ‘08) it’s time to evaluate if Merb is the good choice for some of my clients’ projects.

However, according to Merb’s author, Ezra, at MountainWest RubyConf 2008, Rails will get you there faster. In a client’s case, they don’t need to build a huge app but need a lot of speed and the ability to easily handle a heavy load right away without using caching. Also most of the traffic will go through an API so we won’t have to manage too many views.

Let’s see how fast Merb really is.

To test Merb’s speed, I built the very same prototype using Merb 0.9.2 and Rails Edge (pre 2.1). Both apps use ActiveRecord and are connected to a UTF8 MySQL database, both apps have exactly the same views. (Note that Merb would run way faster using DataMapper, but I don’t feel that DM 0.9x is production ready yet, also, using a rack handler would certainly be way faster but my goal was really to compare ActionPack vs Merb.)

Both apps use the same ActiveRecord class, their controllers are a bit different but basically do the same thing.

Here is what was tested:

• The Merb/Rails app should receive a GET request with a JSON object in the query.

• The Merb/Rails app should route the request to a controller and pass the JSON object to an AR class.

• The AR class should parse the JSON object (which contains an array of objects), extract each object, and try to find them in the database using one of the attributes. If the object isn’t found, it should be created, otherwise it should return the AR object. The amount of hits should be incremented by 1 and the object should be saved back to the database.

• A simple HTML view should be rendered

Quick Merb benchmark

I setup Merb to run locally on my MacBook 2.16Ghz Core Duo 2, 2Gb Ram. To test the raw performance, Merb is started in production mode.

I then used httperf to make 10000 connections to the server at a rate of 500 (–rate=500 –send-buffer=4096 –recv-buffer=16384 –num-conns=10000 –num-calls=1)

Here are the results:

Maximum connect burst length: 29
Total: connections 4377 requests 4221 replies 2932 test-duration 41.629 s
Connection rate: 105.1 conn/s (9.5 ms/conn, <=1022 concurrent connections)
Connection time [ms]: min 41.0 avg 1920.4 max 35390.8 median 898.5 stddev 4887.3
Connection time [ms]: connect 2118.1
Connection length [replies/conn]: 1.000

Request rate: 101.4 req/s (9.9 ms/req)
Request size [B]: 321.0

*Reply rate [replies/s]: min 0.0 avg 73.3 max 143.0 stddev 65.8 (8 samples)*
Reply time [ms]: response 809.0 transfer 18.1
Reply size [B]: header 121.0 content 557.0 footer 0.0 (total 678.0)
*Reply status: 1xx=0 2xx=2932 3xx=0 4xx=0 5xx=0*

CPU time [s]: user 0.35 system 36.54 (user 0.8% system 87.8% total 88.6%)
Net I/O: 78.4 KB/s (0.6*10^6 bps)

Errors: total 7068 client-timo 0 socket-timo 0 connrefused 0 connreset 1445
Errors: fd-unavail 5623 addrunavail 0 ftab-full 0 other 0

What we care about is the reply rate/s. We have an average of 73.3 requests per second with a standard deviation of 65.8 using 8 samples.

We also make sure that all the replies were successful. (status == 2xx)

I also checked the database, made sure my AR object was created and that the hits were increased. AR object hits: 2932, which matches the amount of replies reported by httperf.

We don’t care so much about the rest of the httperf. Let’s move on to the Rails benchmark.

Quick Rails benchmark

Rails is set the same way, running locally in production mode, same httperf settings.

Here are the results:

Maximum connect burst length: 44

Total: connections 2923 requests 2825 replies 1672 test-duration 37.418 s

Connection rate: 78.1 conn/s (12.8 ms/conn, <=1022 concurrent connections)
Connection time [ms]: min 382.7 avg 5635.4 max 36384.5 median 1887.5 stddev 10103.1
Connection time [ms]: connect 3631.2
Connection length [replies/conn]: 1.000

Request rate: 75.5 req/s (13.2 ms/req)
Request size [B]: 319.0

*Reply rate [replies/s]: min 0.0 avg 43.4 max 75.2 stddev 30.8 (7 samples)*
Reply time [ms]: response 1568.1 transfer 36.7
Reply size [B]: header 471.0 content 581.0 footer 0.0 (total 1052.0)
*Reply status: 1xx=0 2xx=1672 3xx=0 4xx=0 5xx=0*

CPU time [s]: user 0.25 system 31.31 (user 0.7% system 83.7% total 84.4%)
Net I/O: 69.4 KB/s (0.6*10^6 bps)

DB hits: 1672

First thing, the database object was created properly and the hits incremented to 1672 which matches the amount of replies reported by httperf.

Then, we notice that on this test, we only got 7 samples, that’s more than enough though. The standard deviation is 30.8 which is better than Merb’s 65.8. That means that in our benchmarks, the reply speed difference in Merb’s requests was bigger than Rails’. Not a big deal, this is not a scientific test but it’s good to acknowledge it.

What we really care about is the average reply rate: 43.4

Let’s also note that all the replies had a 2xx status, so everything went well.

Results

Based on this really basic benchmark, my Merb app had an average reply rate of 73.3 requests per second against Rails’ 43.4 requests per second.

That means that in this very specific case,

Merb is 69% faster than Rails! Sexy!

In other words, my Merb prototype could handle 69% more requests than the Rails prototype in the same amount of time.

I heard people reporting than Merb was 3 to 5 times faster than Rails. Honestly, it really depends on what you do. By using ActiveRecord on both prototypes, I limited the speed difference since AR is not multithread and therefore Merb can’t run as fast as it would using Sequel or DataMapper. By actually hitting the database on every single request, I also made sure to really compare ActionPack vs Merb.

Conclusion

The conclusion is simple, I recommended that my client go with Merb. Merb 1.0 is almost ready, the public API has been frozen. My client needs speed and simplicity. Using Merb I get exactly what I need and nothing more. Actually, we’ll probably increase the performance by writing a rack handler and bypassing the entire framework for API calls (that should be wicked fast!). Also, as soon as DataMapper becomes production ready, we’ll switch to DM and should get way better performance!

Am I suggesting to give up Rails and switch to Merb?
Absolutely not! First off, Merb is a “lower level” framework. It requires a deeper understanding of Web Development in general and being more than just ‘acquainted’ with the Ruby language. So, unless you are an advanced developer or have time to learn, I would suggest to keep on using Rails (start using Merb on personal projects, it’s a perfect way of learning).
If you have a lot of views and/or use loads of AJAX, RJS, built-in helpers, you probably want to stick to Rails and start looking at how you can do all of that from scratch. By default Rails uses nasty helpers that create inline javascript, and is something you really want to avoid. RJS is fun, but it goes against Merb’s philosophy, so you need to make sure you can live without it (note that you can reproduce the same behavior in Merb rendering JS, it just requries more work). If you rely a lot of Rails plugins, you might want to delay your switch, Merb is pretty new and doesn’t have a mass-load of plugins yet.

Finally, Merb doesn’t have a lot of documentation and changed a lot when 0.9 got released. To understand how Merb works, you will need to go through the source code, specs, Google, and ask on the Merb IRC channel.

It turns out that in our case we have experienced developers, a great need for speed, not too many views and are following Merb’s development really closely . I honestly think it’s the best choice for my client and I’m excited they accepted to use Merb.

Merb is addressing different issues than Rails and doing it well. I think there is a bright future for Merb. And don’t even think that Rails is going away, that won’t happen anytime soon!

Recently, Sony Playstation even posted a job post looking for a Rails/Merb developer. This is very promising for the Merb community!

A few clarifications:

• Rails is an awesome framework, and to be honest I really like the fact that it’s accessible to newbies while offering great tools

• Rails Plugins that I like calling Duplo blocks are great and I use a bunch in most of my projects

• I, myself wrote a bunch of plugins and gems never as great as the one mentioned in my post though

• No, I don’t think you are dumb if you don’t have a clue how Rails or Rails plugins work

I also agree that the metaphor is very limited and doesn’t stretch… but who cares.. it’s funny.

What did I mean to say

• Rails plugins are useful, use them and ABUSE them. Even though most of them are very well written I strongly believe you would become a better developer if you understand how they work.

• A Duplo doesn’t do exactly what you want it to do, don’t bitch about it. Try submitting a patch or if you can write your own plugin.

• If you are using a plugin on a regular basis, give it some love. Submit some documentation, write a blog post, send a thank you email.

• A great framework and a bunch of nice plugins are awesome tools for developers but they won’t replace your brain.

So, there you go, this time around I tried to be more straight forward and I even apologize if I offended you.

Finally, I don’t believe the Rails community is a bunch of obnoxious-arrogant-wannabe-rockstars, and certainly not a ghetto. We all started as newbies and I hope a lot of newbies will join the fun and learn through Rails and later provide the community with a lot of awesome Duplos!

Duplo bricks are eight times the size in volume, twice the length, height and width of traditional Lego bricks, and are easier to handle for younger children. Despite their size, they are still compatible with traditional Lego brick.

Duplos are great to introduce kids to the concept of Lego bricks and to get them to think about building their own creations. However you would freak out if your kid would grow up and not want to start playing with Legos and building more advanced/custom stuff.

Unfortunately, that’s exactly what’s going on in the Rails community right now. We created a generation of Duplo developers.

Rick Olson, AKA Technoweenie fathered a great majority of this Duplo generation. Rick is a Rails core member and a prolific Rails plugin developer. He has written very popular plugins and Rails apps such as:

• restful-authentication
• attachment_fu
• acts_as_versioned
• permalink_fu
• mephisto blog engine
• Beast forum

If Rick is the father, the mother of this generation would obviously be David Heinemeier Hansson, creator of the Ruby on Rails framework. David has always wanted to make our lives easier, providing us with tools to avoid repeating ourselves and a mass-load of tools to create web apps in no time.

Rick, David and others worked hard to provide the community with tools that cut our development times by 20% to 30% and that’s just awesome. They basically took their meccano applications and extracted Duplo blocks you can play with.

from to

The problem is that a generation of Rubyists has grown up being used to getting everything pre written for them. They haven’t yet passed the “Duplo stage” and basically write applications putting a few blocks together, only writing 10 to 20% and barely understand 5%.

On top of that, what really annoys me is that, these very same developers complain about the existing plugins, always ask for more and don’t give anything back to the community.

The problem is that it’s always the same people giving and helping. Relatively quickly, the community grows and people supporting it get tired. I won’t go as far as Zed and his funny rant but we need to wake up. We need to evolve, learn how Rails magic works, give up the cargo culting and start giving back.

The first thing would be to stop complaining about plugins you use on a daily basis and write your own or fork existing ones. GitHub is a good place to start forking existing projects, if you are a Rails/Ruby beginner, you can help with documentation or submit small patches. Josh Susser wrote a nice tutorial on how to commit changes (patches/documentation).

Why not blog about issues you have just faced and how you resolved them. Start writing small plugins/gems. Try helping people on the various mailing lists.

And finally, drop the Duplos and start playing with Legos – don’t use plugins just because they are available to you, make sure you fully understand what the plugins you use do! Learn more about Rails guts and start using it in a way that makes sense to you.

Why not even switch to meccano and take a look at Merb

Simple concept and great team. When Ari Mir and Ophir Tanz approached me to work on their app I was impressed by their understanding of Web Business. It was not their first start up and as a consultant, you usually prefer to work with some experienced clients. Ari, GumGum’s CPO was great at defining realistic expectations, and limit the scope of the application which was great since I’m an Agile/XP fanboy. I believe that really helped us meeting our dead line without feature creeping the app.

We were finally ready to enter a public beta phase, we were running our production server on a godaddy VPS (no comment) and were on the process of migrating to slicehost where we were running our staging environment. The plan was to go public on Tuesday 12 and have a feel for the load. We also setup an EC2 image to handle some of the background tasks and were thinking of moving to Engine Yard within few months.

Everything was ready for a launch, when the day before D Day, Ari calls me telling me: “Good news Matt, TechCrunch is going to publish a blog post about us!”. While he sounded really excited, I couldn’t believe me ears.

1. The app wasn’t optimized, darn it all, I hadn’t even properly indexed the database, no caching, nothing. (it was in the backlog, things I was planning on doing after the public beta launch)
2. We would never be able to handle the load. Running an app like ours definitely needs more than a 256Mb shared CPU shared host.
3. Ari asked me if they could embed one of our license object in TechCrunch home page.
4. I had 12 hours to get stuff ready.

Trying to be ready:

TechCrunch has 688k RSS subscribers! Even though I asked Ari not to embed one of our protected object inside TC’s home page, I knew he couldn’t say no to Mike Arrington. (little did I know, they would end up embedding 2 licenses)

I hurried up and started properly indexing the database, ask advice to some of my cabooser friends, did some quick re-factoring but obviously didn’t have enough time to rewrite the way we handle tags and tooltips (the overlay popup window that displays when you rollover a picture in our browse page). Rob helped me getting ready and we transformed our staging environment into a secondary production server hoping we would split the load.

Since we didn’t have a load balancer, we tried to cheat by setting up two A records for gumgum.com. The idea was that browsers would pick an ip randomly and since we were only using 1 database, everything should be fine. That was the theory, during our tests we realized that our Flash object was not using the same IP than the webpage and that was creating random issues with our licensing system.

We were running out of time, I turned on page caching on few actions (home page) so even though my mongrels would die, I knew we would at least be able to display something. Because of our complex authentication system, I couldn’t cache much and I didn’t have time to re-factor a lot of my code or to setup memcached. (on top of that I knew the product was stable and I didn’t want to mess up with it).

The Storm:

The article got published and in seconds we saw the load on the main box going from 0.2 to 2.0! We were still dealing with the DNS issues and some pictures were not getting loaded. When Rails got above 60 req/s we started dropping some requests and returning 500s. That was bad, really bad. Our browse page (not optimized) was down and we handled around 80k requests in a matter of few hours. What you don’t know is that each of our flash object generates a couple of requests, and that TechCrunch decided to embed 2 objects on their home page.

Remember, it was our launch, which was not meant to be a big launch, we were not prepared for that!

Dealing with the load:

The good thing is that my code didn’t leak memory, Rails was stable and it was a good sign. We all know that “Rails CAN scale”, but we also know that you need to have a proper hosting to do that. Godaddy was not handling the load and it was just the beginning. So what do you do when you have to scale and that your code isn’t total junk? You call a real hosting company like EngineYard or Joyent. I was lucky Ezra was online. I quickly explained to him the situation, we discussed the reason why our site was not doing so great and defined the bottlenecks. It was simple, we needed more humph. The normal waiting time to get a slice on EY was around 2 weeks back then. Ezra knew that we couldn’t wait 2 weeks :p He was simply awesome, managed to find us 2 slices, set them up for us and setup our app in less than 2 hours. He even helped us configuring our old server to get NginX to bounce the requests to EY while the DNS was propagating.

As soon as the switch was done, everything loaded perfectly, not a single request dropped, it was simply great.

Since we are talking about scaling, hosting and facing issues, I’d like to make a simple point: $349.00 a month for a slice is NOT expensive for what you get. First off, EY slices are setup superbly, you get awesome performances out of them, they come ready for your app and you don’t have to do much. Secondly, I’m not a sys admin, I really hate dealing with servers, packages, configuration, compiling crap that won’t compile because I’m lame… etc…

EY has a bunch of experts (both Ruby and Sys admin experts) available 24/7 that always go the extra mile to help you. Last time I checked I couldn’t hire a good sys admin for, let’s say the price of 3 or 4 slices. Now, we get a team of guys, available, knowing their stuff and helping me for way cheaper than hiring a sys admin dude. The other thing is, I’m a consultant, I don’t want to deal with servers and charge my clients for that. I also want them to be reassured and know that “yes, we can scale”. The price of an EY/Joyent slice is the price you pay to be confident you can take the load.

So what now?

We have a lot of optimization to do, we are working on moving more of our stuff to EC2 to avoid being charged for bandwidth twice (user => EY => S3), we are setting up a queuing system and we have a lot of nice features to deploy. But one thing for sure, I can focus on my code since I know EY has my back and I don’t have to worry about our servers.

p.s: GumGum is doing great, a lot of people are really interested in the product, new features are coming up (we already auto import content from some major Paparazzi agencies) and we are getting a good press coverage

• Rails default database is now sqlite3. If you are running Leopard, everything is already setup for you. As DHH mentioned, just “rails -d mysql yourappname” if you want to generate a new app preconfigured for MySQL.
  Sqlite3 is great and if the only reason why you didn’t give it a try is because you have to use CocoaMySQL, then check out sqlitebrowser

• Other new feature: rake secret to generate a key used to encrypt your session. Really useful task when you’re migrating an app to 2.x

• To improve performance, some changes were made to the template caching and you have to restart your production server after a template modification.

• Validates acceptance of still works for non-existent tables . (sorry Josh, I won’t post after 2am, especially when I forget your life changing bug fix )

• Added option to pass proc to ActionController::Base.asset_host for maximum configurability. Example:

1
2
3
4
5
6
7

    ActionController::Base.asset_host = Proc.new { |source|
      if source.starts_with?('/images')
        "http://images.example.com"
      else
        "http://assets.example.com"
      end
    }

• Finally, I added 2 new rake tasks: db:migrate:redo and db:migrate:reset
  
  db:migrate:redo rolls back your database and then migrates it up. You can define the STEP constant to specify the amount of steps you want to rollback. This task is very useful in development mode when making a modification to the latest migration(s).
  db:migrate:reset will drop your database, re create it and migrate it up. Only use this task if you really have to and only in development/test environment. Use db:reset in production mode since it uses the schema.rb file and won’t go through the hundreds of migrations you might have.

Changeset

2.0.2 (December 16th, 2007)

• Changed the default database from mysql to sqlite3, so now running “rails myapp” will have a config/database.yml that’s setup for SQLite3 (which in OS X Leopard is installed by default, so is the gem, so everything Just Works with no database configuration at all). To get a Rails application preconfigured for MySQL, just run “rails -d mysql myapp” [DHH]

• Turned on ActionView::Base.cachetemplateloading by default in config/environments/production.rb to prevent file system stat calls for every template loading to see if it changed (this means that you have to restart the application to see template changes in production mode) [DHH]

• Introduce rake secret to output a crytographically secure secret key for use with cookie sessions #10363 [revans]

• Fixed that local database creation should consider 127.0.0.1 local #9026 [parcelbrat]

• Fixed that functional tests generated for scaffolds should use fixture calls instead of hard-coded IDs #10435 [boone]

• Added db:migrate:redo and db:migrate:reset for rerunning existing migrations #10431, #10432 [matt]

• RAILSGEMVERSION may be double-quoted also. #10443 [James Cox]

• Update rails:freeze:gems to work with RubyGems 0.9.5. [Jeremy Kemper]

• Added deleteviaredirect and putviaredirect to integration testing #10497 [philodespotos]

• Allow headers['Accept'] to be set by hand when calling xmlhttprequest #10461 [BMorearty]

• Added OPTIONS to list of default accepted HTTP methods #10449 [holoway]

• Added option to pass proc to ActionController::Base.asset_host for maximum configurability #10521 [chuyeow]. Example:

  ActionController::Base.asset_host = Proc.new { |source|
  if source.starts_with?(‘/images’)
  “http://images.example.com”
  else
  “http://assets.example.com”
  end
  }

• Fixed that ActionView#fileexists? would be incorrect if @firstrender is set #10569 [dbussink]

• Added that Array#toparam calls toparam on all it’s elements #10473 [brandon]

• Ensure asset cache directories are automatically created. #10337 [Josh Peek, Cheah Chu Yeow]

• render ml and :json preserve custom content types. #10388 [jmettraux, Cheah Chu Yeow]

• Refactor Action View template handlers. #10437, #10455 [Josh Peek]

• Fix DoubleRenderError message and leave out mention of returning false from filters. Closes #10380 [Frederick Cheung]

• Clean up some cruft around ActionController::Base#head. Closes #10417 [ssoroka]

• Ensure optimistic locking handles nil #lock_version values properly. Closes #10510 [rick]

• Make the Fixtures Test::Unit enhancements more supporting for double-loaded test cases. Closes #10379 [brynary]

• Fix that validatesacceptanceof still works for non-existent tables (useful for bootstrapping new databases). Closes #10474 [hasmanyjosh]

• Ensure that the :uniq option for has_many :through associations retains the order. #10463 [remvee]

• Base.exists? doesn’t rescue exceptions to avoid hiding SQL errors. #10458 [Michael Klishin]

• Documentation: Active Record exceptions, destroyall and deleteall. #10444, #10447 [Michael Klishin]

LowPro is the best solution for doing Unobtrusive Javascript using Prototype.

With the help of LowPro, you define behaviors that get triggered by the user. This is great, however, you’ll notice that some behaviors are used all over the place (a date chooser for instance) and some complicated behaviors only get used on very specific pages.

First things first, let’s look at the header in my application.html.erb file (located in app/views/layouts).
This is the default layout used by all my views, I rarely use more than 5 layouts per app and always use a default layout.

Please note that I’m using Rails 2.0 so some features you’ll see in my file won’t work in Rails 1.2.x. (if you want to know about all the new Rails sexiness, check on this awesome Peepcode PDF.

Here we go:

1
2
3

  <%= javascript_include_tag 'prototype', 'effects', :cache => true %>
  <%= javascript_include_tag 'lowpro', :cache => true %>
  <%= javascript_include_tag  'application', :cache => true %>

The first thing you might notice is that I don’t use

  <%= javascript_include_tag :defaults %>

The reason? I don’t want to load prototype.js, effects.js, controls.js, dragdrop.js, and application.js all at once. I almost never use drag’n'drop and seldom use Autocompleter and InPlaceEditor so why loading them in each and every single page of my apps? I’m not saying they are bad libraries, I’m just saying that in more than 80% of my page, I don’t use them, so they should not be in my default page load.

The second thing you might notice, I use :cache => true. Asset caching is a new feature in Rails 2.0 which combines related assets into a single file (works with css and js and only in production mode)
Note that the above code is untested, but everything should be loaded properly, otherwise, make sure proto gets loaded first, then lowpro, then application. (and you can probably create a one-liner)

All the default behaviors are defined in the application.js file, so they get loaded on all page. However to handle action specific behaviors, I use another Rails trick right in the header:

 <%= yield :javascript %>

Why? Very simple, I want to load some custom JS in the header depending on the action that is used. For instance, when a visitor goes to my fancy ajax photo editor, I want to load the content editor javascript right in the header where it belongs.

For that, I simply need to add the following to my view:

1
2
3

  <% content_for :javascript do %>
    <%= javascript_include_tag "photos_show" %>
  <% end %>

If content_for :javascript isn’t define, noting is yield in my header and therefore nothing is included but whenever I need, I can access my header directly from the view and insert javascript code in a very clean way.

photos_show.js is the javascript defining all the behaviors related to the photos controller and the show action. I usually only have few actions with a lot of custom behaviors so, these structure works well for me.

1
2
3
4
5

  javascripts
    \controller_action.js
    \controller_another_action.js
    \another_controller_action.js
    ...

However in the case of an app with a lot of custom behaviors, I recommend using the following structure:

1
2
3
4
5
6

  javascripts
    \ controller_name_
            \action_name_.js
      \another_controller_name
              \action_name_.js
  ...

That’s it folks, I’m not a javascript expert, and if you know better, don’t hesitate to leave me a comment. What I know for sure, is that since I started using LowPro and behavior driven with Prototype, I have much more fun. Adding a bit of structure is a simple way for me to keep my code clear and help other people who have to work with me. (more on that later)

Rick being really busy with ActiveReload he didn’t spend too much time maintaining attachment_fu.

On my side of things, I’ve been using attachment_fu on a lot of projects and I’ve been fixing bugs and adding new features.

My first contribution to attachment_fu is a fix for the ImageScience processor.

Attachment_fu is very flexible and let you use your favorite image processor:

• RMagick based on ImageMagick and GraphicsMagick(known to leak memory and being a pain to setup)
• minimagick based on ImageMagick
• ImageScience based on FreeImage.

Like many rubyists, I like ImageScience for its simplicity and efficiency. However, attachment_fu had few problems when being used with ImageScience.

• File sizes for thumbnails were not saved correctly in the database. Fixed
• Thumbnails based on a gif files were not processed properly. So, this was the big problem. FreeImage has issues dealing with resizing gif files because of the gif palette limitation (256 colors). to avoid this problem thumbnails of gif files are converted to png. However the thumbnail content type info in the database was not saved properly. That’s now fixed.
• Because of the gif bug reported above, any thumbnail link was broken since it was trying to link to the thumbnail version with a gif extension instead of a png one. Fixed

I also fixed a small bug related to S3 storage and the fact that a_fu had issues loading the config file. (Fixed)

I’ll also try be able to add some of the S3 features I’ve been working on. As well as maybe enhancing the validation process.

In the mean time, you might want to read this blog post about better validation with attachment_fu.

If you are heavily using attachment_fu or starting using it and think that a google group would be great idea, please let me know in the comment and I’ll try to convince Technoweenie that we need to set that up

Ooohh I almost forgot, if you fixed some bugs you found while using afu, please contact me so we can get afu bug free.