RailsConf, My thoughts

I have just got home from two very exciting days at the rubyconf conference in London. Here are a few observations and just a few things I have learnt.

I am not sure why, but I had a distinct impression that the majority of attendees would have been from Europe. However I seemed to come across people from the US or Canada. People who have come over from the states especially for the conference or people who are making it part of their vacation. Not that this is a bad thing. In fact it showed me that they were really committed to Rails and to Ruby. I have to say if my company was not paying for my ticket, I would never have dreamed of going to the conference. Maybe I need to get more involved šŸ™‚

As this is my first conference, I was not sure what to expect. It was an entire new experience. I was pleasantly surprised by the organisation of the conference by skillsmatter and also by the excellent calibre of the speakers. As I am new to the ruby world, I did not know the speakers (apart from David H), this conference allowed me to put faces and personalities to these very influential people within the Rails / Ruby community.

I got to see the Rails core team. This was a real eye opener for me, as I had no idea who they were or what their thoughts were for the future of Rails (I know I should read more).

Then comes David H’s talk. I have to say that I was impressed with David’s ideas and the way he presented himself. I really like the RESTFUL stuff and ActiveResource and also the Simply Helper. For those of you that don’t know, this is a way of putting conventions into the view layer like he has just done for the controller using REST.

Things I learned

Overall I have to say that I did learn allot (especially about Ruby)

  • Rails 1.2 is to be released very soon and is going to depreciate a whole bunch of methods.
  • In Rails 2.0 these deprecated methods will be removed.
  • 1.2 is going to heavily push the REST stuff.
  • Routing has completely been rewritten as it was a bottleneck. This is to be released in 1.2
  • The goals of ActiveResource, It is not going to ship with Rails 1.2, maybe 2.0 ?
  • With all the restful work on the controllers, the view started to look dated, so they have developed SimplyHelper, which is a convention for views.
  • Rails speaks ‘C’ – This was a talk I attended. I think things like this are very important. If we have a very complex algorithm or we have some legacy C systems, we need to be able to call C code from Ruby. In the Python CMS world Zope does this for a lot of complex operations (as far as I remember, correct me if I am wrong). 4 different approaches were mentioned. I noted that SWIG seemed to be one of the better options (and it supports c++).
  • If you are using C to do a big CPU intensive task, or a task that will take a while to complete, then you need to use BackgroundDRB. This allows you to spawn requests in the background (surprise,surprise). So in a web app the client gets a response straight away, so he knows something is happening , a progress bar would be a good indicator in this situation.
  • I really enjoyed the talk about high performance. I always wondered if anyone had deployed Rails apps, which had to handle over a million hits per day. Well James Cox seemed to have allot of experience in this field, and he shared some tips with us. I will mention a few here.
    • Speed Perceived – This is to use Ajax to make the app perceive fast to the user. The user will not know.
    • Always use :select, :limit and :offset in your queries.
    • Try and use lazy loading (:include).
    • MEMCACHED – Basically always use this as much as possible, he really emphasised this point.
    • Avoid shared hosting (obvious).
    • Page Caching – BAD – Avoid this as it is a nightmare to clean up.
    • Fragment Caching – Is better then page caching, but their are scalability issues
    • 8 server Gem (server architecture) – 2 x Proxy / Web static servers, 4 x Application servers, 2x Database servers with database replication.
    • Session management – use memcache, not the database store
    • If you have one server use Apache (fcgi), but this does not scale well, so for multiple machines use mongrel.
    • Put Google Analytics in its own iframe, this will avoid your app waiting to show the page because it is retrieving the js from google.
  • Django
    • Really cool!
    • Has built in user and groups in the framework
    • Uses python code to define database schema. This allows them to add rich data models. So you can define an upload field or a url field, the system will automatically know what to do with this field. This allows them to auto generate the admin interface to such a high level and what streamlined is trying to replicate for Rails.
    • Reusable template views with hierarchy functionality.
    • Try and not use AJAX in the admin section, as you do not know what kind of PC your publishers are going to publish from (old, etc.)

I have a lot more to write. Which I should be doing over the weekend.


Please comment if you found this useful or not.


2 comments so far

  1. happygiraffe on

    Regarding C extensions, I have used both SWIG and (a little bit) of native Ruby. SWIG takes a while to get going with, but when you get the hang of it, it’s really powerful. Especially in combination wiht C++.

    Ruby’s native C interface is quite pleasant to use, especially compared to Perl’s XS or Java’s JNI.

  2. Hamza on

    Thanks for the comment.

    I will definitely look into SWIG if I come accross a project that needs it.

    I really enjoyed your unicode talk by the way.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: