Speaking at Velocity next week

Posted by ezmobius Thu, 19 Jun 2008 23:25:00 GMT

I’m going to be speaking at Oreilly’s Velocity conference next week on Monday June 23rd. Velocity is a conference about Web Scale operations and performance, lot’s of stuff about infrastructure and cloud computing.

I’ll be giving a short talk on Vertebra at 4:45pm on Monday and I will also be on a panel called “Getting into the Clouds” with some guys from Amazon, 3terra, Rackspace and joyent at 3:45pm. Should be fun.

Come see it if you’re in the area or already coming to the conference.

Velocity Conference

Tags  | 2 comments

Engine Yard Express

Posted by ezmobius Fri, 06 Jun 2008 22:47:00 GMT

I’d like to point folks to our new Engine Yard Express VMWare image. This is a replica of an EY slice that you can download and use locally whether you are an EY customer or not. When you boot it up it will autotune mysql to use the proper amount of ram, boot up a merb and a rails app along with nginx and monit et all. It will give you a user/pass and show you the IP address as part of the boot process. So just boot it up and peek at the IP address on port 80 and port 81, the index pages of the rails and the merb app have detailed instruction on how to get a deploy.rb and deploy your own code.



Introducing Vertebra

Posted by ezmobius Mon, 02 Jun 2008 02:46:00 GMT

Here are the slides from my talk at RailsConf 2008. I’m too tired to write much more right this instant so I’ll let the slides talk. Rest assured you will here more about vertebra in the near future…

Here is a PDF of the slides if you are having trouble with the flash slideshare version:




Posted by ezmobius Wed, 21 May 2008 22:13:00 GMT

There is a great tutorial/screencast about a new merb feature that I really like a lot called merb-slices. This is now part of merb-more, contributed by a long time friend of mine, Fabien Franzen(worked on ez-where with me)

merb-slices are “Little slices of MVC cake”. These are self contained merb apps with models, controlers, views and assets that you can distribute as rubygems. You can mount a merb-slice at a specific point in your router definition and you can override any part of the slice up in your main app. So in a way these are similar to what Rails-Engines promise, except merb-slices are built into the framework and will not break when merb itself is updated.

Check out the tutorial/screencast for a peek at how merb-slices work.

Tags  | 5 comments

Does it have to be a competition between Rails and Merb?

Posted by ezmobius Wed, 21 May 2008 20:12:00 GMT

It seems like a lot of folks out there want there to be a battle royal between Merb and Rails. I just wanted to dispel this myth.

Merb was written because it scratched an itch that I and many of my hosting customers had, mainly memory footprint, speed, concurrent requests and simple maintainable code. This does not mean that Merb has to be thought of as a Rails competitor. Merb stands on its own merits just as Rails does.

I feel that both of these frameworks have great strengths and weaknesses and that they compliment each other in many ways. Face it Merb would never be around if Rails had not come first. And I see Merb as a great experimentation playground for exploring web framework functionality while learning a great many things from Rails and building a fresh view based on Rails strengths and weaknesses.

There is no reason that a lot of the goodness in Merb cannot be applied back to Rails, but it is no small feat to trim down rails size without breaking backwards compatibility.

I view it like this, more choices make the Ruby ecosystem a better place. So let’s just stop with the Rails VS Merb stuff. How about people choose what framework they want to use based on the frameworks merits and features rather then religious arguments about how my framework can beat up your framework.

The Ruby community in general has been exceedingly nice as long as I have been a part of it. I wrote Merb for a reason, if Merb’s philosophies agree with your tastes then great, use Merb. If Rails is your thing then that’s great too! We do not need a monoculture.

Rails has been Ruby’s killer app and has brought Ruby to the masses. But Ruby is growing up, there are many alternate Ruby implementations now and they all work together for the common good of Ruby.

I’d like the same thing to happen with Rails, Merb and all the other ruby web frameworks. Let’s all work together to make the Ruby ecosystem stronger. We do not need to fight amongst ourselves when there are plenty of other Programming language communities to fight with :P

I guess what I am saying is that I see the proliferation of ruby web frameworks as a sign that Ruby itself has “arrived” and is here to stay. So can’t we all just get along in Ruby web framework land?

Tags ,  | 33 comments

A few cool developments

Posted by ezmobius Sat, 17 May 2008 23:29:00 GMT

My Deploying Rails Applications Book has shipped in print form! This book has been two years in the making and was rewritten a few times as the Rails deployment landscape shifted. I’m so glad it is finally in print \m/ Big thanks to all my co-authors and beta readers who gave valuable early feedback.

And in other amazingly beautiful news, Rails runs on Rubinius as of last night!. A huge round of applause for Evan, Wilson, Brian, Ryan, Eric and Eero, the rubinius core team and also to all 150 rubinius contributors. This is a huge milestone for the project. Being able to run rails, which is one of the largest and most complex ruby programs out there is huge. This means that rubinius is now ruby compatible for the most part. Now the team can start to steer their focus on speed improvements like JIT , polymorphic inline caching, LLVM and various other techniques for making rbx smoking fast.


Cool visualization of merb's framework load process

Posted by ezmobius Thu, 08 May 2008 04:51:00 GMT

Michael Klishin made a sweet mapping of a merb server’s boot process. Hopefully we can get stuff like this made for other parts of the framework as well as I think it can really help you find your way around the source code of merb-core.


Merb-0.9.3 released

Posted by ezmobius Mon, 05 May 2008 02:36:00 GMT

Merb 0.9.3 is mostly (but not only) a bugfix release. We’ve not only added several features very useful for developers who want to use Merb for web services, but fixed many bugs, greatly improved spec coverage and quality, made documentation better, and did some performance-related work.

diffstat shows 95 files changed, 3359 insertions(+), 837 deletions(-)



Engine Yard needs Erlang Programmers

Posted by ezmobius Thu, 01 May 2008 23:26:00 GMT

Engine Yard is looking for one or two kick ass Erlang programmers to help work on our next generation cloud computing platform. Knowledge of ruby/xmpp/ejabberd/linux is a plus.

If you think you fit the bill then please email me directly at ezra@engineyard.com.

Tags  | 4 comments

Hey Rails, nice Rack!

Posted by ezmobius Fri, 25 Apr 2008 00:34:00 GMT

So i’ve spent this week hacking on Rails, specifically going spelunking in ActionPack and porting Merb’s rack machinery to rails. I figure that merb is a very nice experimentation ground and decided it was time to give some love back to the framework that inspired merb.

While still not complete, I have made significant headway on racking up rails in my github fork of Rails. I’ve added rack adapters for mongrel, eventedmongrel, thin, ebb and webrick. All of this is controlled via ./script/rackup in a rails app. So to start a cluster of 5 thin servers you would run this command:

./script/rackup -a thin -c 5 -e production

I do have to say that parts of ActionPack haven’t been touched in a long time and had accumulated some cruft, with the rails rack adapter that thin and ebb use there was a dogpile of wrappers going on. A web request was wrapped in many layers like this(the → means ‘wrapped in’)

raw request -> rack env -> Rack::Request -> CGIWrapper -> CgiRequest

That was far too many wrappers, it also turned out that some of these wrapper were making duplicates of all the CGI headers, meaning quit a bit of wasted memory on every request. I’ve slimmed it down to this now:

raw request -> rack env -> ActionController::RackRequest

With no more duplication of CGI headers, win!

I’ve also changed the giant mutex lock to be much smaller, it used to lock around the dispatcher callbacks, route recognition, controller instantiation, filters and action dispatch. Now it only locks around filters and action dispatch, Dispatcher callbacks, route recognition and controller instantiation all happen outside of the lock. This makes for a nice little speed boost with standard mongrel under concurrent load.

Of course this doesn’t work so hot in development mode when you have concurrent requests, it falls apart due to route set reloading and class reloading done in dev mode. But if you are just using your browser to test the app in dev mode you won;t ever notice since you won;t be making concurrent requests. In production mode the route recognition appears to be thread safe, more extensive testing and stressing will be needed to be 100% certain though.

All in all I feel like these are some big wins for Rails. And I’m not done yet, I plan on beating up ActionPack quite a bit more until it submits ;)

Tags  | 40 comments

Older posts: 1 2 3 4 5 ... 15