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 merb, rails | 33 comments
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.
5 comments
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.
5 comments
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(-)
Read more...
9 comments
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 erlang | 4 comments
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 rack | 40 comments
Posted by ezmobius
Fri, 18 Apr 2008 06:20:00 GMT
There is a classic tradeoff between threaded servers and event driven servers. Event driven servers tend to be much faster than threaded servers when all the requests are fairly fast. But the event model falls down if you have long requests like file uploads or reporting actions. This is because the long action blocks the event loop, effectively keeping other requests from running.
There are two new event driven ruby webservers at your disposal these days, Thin and Ebb. Both of these servers support the Rack web server interface that merb uses. Until now both of these servers were not the best choice for file uploads or long blocking actions but that’s all changing.
Both ebb and thin have added a deferred?(env) method to their rack adapter interface. Both webservers will call this method on your Rack @app object before they call your call(env) method. This allows your rack adapter to determine if the request should be run in its own thread if it’s slow.
I’ve just committed support for this deferred_actions construct in merb-core. If you want to run on thin or ebb but you have say a file upload action and some slow reporting actions you could add this to your init.rb in your app:
Merb::Config[:deferred_actions] = ["/uploads/create", "/reports/longaction"]
What this means is that all of your actions will run in fast event driven mode except for requests to /uploads/create and /reports/longaction. Any request for either of these urls will be served from a newly spawned thread, all other requests will be served by the main event loop.
This allows us to have the best of both world. Combining threaded and event driven styles to use the strengths of both makes a lot of sense here.
Cheers to the authors of ebb and thin for making the same interface. All of this requires the HEAD versions of ebb or thin so if you want to play along at home you will need to build thin or ebb from source on github: ebb and thin
Tags deferred, ebb, thin | 18 comments
Posted by ezmobius
Fri, 11 Apr 2008 06:59:19 GMT
Jed Hurt and Lance Carlson made a nice wiki engine in merb that we’ve thrown up at http://wiki.merbivore.com. Thanks Guys!
You can get the source to the wiki app on github: Collective Wiki Engine
There are the starts of some good information published already, please feel free to add to it!
1 comment
Posted by ezmobius
Thu, 10 Apr 2008 19:46:00 GMT
GitHub has officially launched! No more invites required to sign up.
In preparation for their launch we set them up on a shiny new Engine Yard cluster. With all the adoption of git/github as well as Rails itself about to switch to github we wanted to make sure everyones favorite git repo hosting can scale as far as folks want to take it.
So go Sign Up already and fork your favorite projects to your hearts desire!
Tags github | no comments
Posted by ezmobius
Sat, 29 Mar 2008 21:38:33 GMT
Confreaks has done a great job of recording Mountain West Rubyconf and getting the video online quickly. You can go see my talk here:
Strengthening the Ruby Ecosystem: Merb
9 comments
Searching...
