Ruby DCamp is the first conference, of any type related to ruby or my recent work with Ruby on Rails, I have attended since graduating from UVa. I have been awaiting this opportunity for a while now because my colleagues at OSC have been raving about the kind of people that will be present. People like Rich Kilmer, Brian Marick, Jeremy McAnally, Lucas Cioffi, David James and many more. Being new to the Ruby community, it is very important to meet the people who are responsible for the development of the Ruby ecosystem.

It was very convenient that the first topic that we discussed on the first day of the conference was the Ruby ecosystem. One of the key points that I got from that discussion was how people got introduced to Ruby through different ways and different circumstances but the majority got in through Rails. But a consensus between the “expert Rubyists” was summed up by one of them in the sentence “Came in for Rails, stayed for Ruby” which indicates that although Rails is the reason why people start learning Ruby, it is in itself not as appealing as Ruby is. This is why during one of the discussions we had, people were interested to find out more about the different technologies out there that leverage Ruby and give the developer the same functionality as Rails such as Merb. It was really cool to get the input of the people at the conference on their experiences with the language and the community itself.

There were two interesting things I want to mention specifically from the first day. The first one is that I found out that I am not as much a beginner as I thought myself to be.  I came to this conclusion from the Beginner Talk discussion I listened in on. During that talk, a few people who have been working with Ruby for a long time and one of them even teaching it were giving an outline of the language and mentioning things to look out for. Surprisingly enough, I already had experience with all that stuff unlike a few others who have a lot of experience with other programming languages but are new to Ruby. This was interesting to me because I came in thinking that I was the least knowledgeable person attending RubyDCamp in terms of Ruby and Ruby on Rails, but that was not true (much to my relief). The other thing would have to be the fact of how smart some of the Rubyest at the conference are. I heard all about it from my coworkers but I had to see it for myself to believe it and it was very apparent the moment I observed those people planning to patch ruby gems to add a functionality they figured to be important. This was not just it, as people were mentioning ideas of what needs to be done, one person in particular was already done implementing some things and the best part was how he had it all done before everyone even reached a consensus about it.

Saturday was great in the sense where I got to meet a bunch of new people and get an idea of what kind of projects everyone is working on. Sunday on the other hand was great to get into more detail. The first session I attended was titled “CouchDB hack session” and as the title indicates, it was a session focused on CouchDB. I think it was the most popular session of the morning because there were a lot of talks about it during the first day but most of the people had no idea what it was. It was a good session with a lot of discussion about CouchDB and its uses.

The next session I sat through was a session about SproutCore. I already had an idea of what SproutCore is because I had considered using it to develop one my apps, but ended up not using it. So it was interesting for me to get the perspective of someone who had already used it and also contributed to it. What distinguishes SproutCore is how it is modeled on Rails and allows the developer to use Ruby in development but then generate JavaScript and Json to be deployed once the application is done. This allows developers to keep using Ruby even in environments that limit them such as developing an application for OpenSocial. The main thing I got from this session was some sort of validation that SproutCore is a technology that can be trusted and used, which is a fear that I had because I did not want to develop an application using a new technology that will not be supported in the future, but I learned from the conference that Apple used SproutCore for their MobileMe application and also contributed to the project. This gives me some sort of relief that it will be around in the next few years.

At lunch we started sharing our “ruby experiences” and our “favorite tools” and here’s some of those tools: git-bisect, limelight, hpricot, mechanize, jruby… So if you haven’t heard of these tools before, make sure you do your research!

Oh… and one more thing that I should mention: We at OSC need to do a bit more pair programing!

All in all, it was a great conference and special thanks to Evan Light for organizing the event. Hopefully we will be able to build on this to grow and improve the Ruby community.

Last week four of us from RubyCodeJam took the trip over the mountain to Harrisonburg, VA to join ShRUG for the evening. Alex Herron had arranged for Rich Kilmer and Marcel Molina from InfoEther to come speak. I pretty much took notes on Marcel’s presentation:
(more…)

Ruby DCamp is around the corner, and Youssef will be representing OSC at the event.

The event details are:

What: Ruby DCamp
When: Saturday, October 11, 2008 at 09:00 am to Sunday, October 12, 2008 at 05:30 pm
Where: Holiday Inn, Arlington
4610 Fairfax Dr
Arlington, VA 22203

For more event details, visit the event page: http://rubydcamp.eventbrite.com.

Hope to see you there!

For an agile web developer two frameworks are available for quick and easy deployment of a new website: Ruby on Rails for the Ruby fans and Django for the Python fans. These two tools should provide the same functionality and as someone who’s been working on two projects for the last month, each using one the frameworks, I have had the experience of starting from scratch on both of them and trying to learn both in parallel (or at least one right after the other without acquiring more experience in one and becoming biased for one over the other). So what has this experience taught me?

Deployment
It is very easy to start an application using both Rails or Django:
rails myapp vs. django-admin.py startproject mysite
even though one is wordier than the other it is pretty simple to start the project with all the directories and files needed automatically generated.

Starting the Server
This task is as simple as the previous one:
ruby script/server vs. python manage.py runserver
in both cases there is a call to the language in use, then passing a command. In Rails’ case the command is an executable found in the “script” directory whereas in Django’s case the command is an argument passed to the Python manager.

Configuration
Both frameworks provide a place to configure the application. Rails provide an entire directory to configure the database setup and the Rails environment whereas Django provides a settings.py file where all the configurations can be present but also provides the option of having a config directory for multiple personalized configurations.

Updating the Database
Yet another simple task:
rake db:migrate vs. python manage.py syncdb
In this case we notice that with Rails the call is actually to “rake” whereas for Django it is still consistent with the previous format. But we’ll see that Rails is also consistent where “rake” is called for everything relating to the database.

Creating Models
Where some of the differences begin:
With Rails you create one application that can have multiple controllers, models and models and link to each other using ruby script/generate * (where the * differs depending on what needs to be generated).
Whereas in Django you create multiple applications which each has its own models and views using python manage.py startapp myapp

Documentation
It seems that Rails is more widely used which results in more available resources online for documentation and help. None the less, the Django documentation site is very extended and provides sufficient help.

The Dirt
In the case of Rails I started the project from scratch by first following with the example in the book Agile Web Development with Rails, Third Edition and then applying what I learned to the project I was working on. Whereas in the case of the Django project, I was put on it late in the development process and tried to learn the language and at the same time understand what was already done on the project. My experience with both has been limited and what I have found is that the Rails magic seems to be the difference maker for most people. The majority are not comfortable with that “unknown” but I have seen some magic done with other languages like Java, although it is not the same type but in either case there is something in the background that is doing some sort of work for the programmer. And I have become comfortable with such a setting and because I have seen a bit of how programming languages interpreters work I understand and appreciate the Rails magic.

Even though I was more productive using Rails than I was using Django, which may have influenced my opinion about them, I am still willing to give Django a chance. Both are great tools for developing web applications in an agile manner. My recommendation though, if I have to make one, will go for Ruby on Rails, just because I was more comfortable with it.

Recently, I completed my first Ruby on Rails application, which you can see here. It’s not a complex application, basically it’s a survey of political candidates with three data models: candidate, question, and answer. Pretty straightforward.

I built the Ruby app using Scaffolding, which was very easy and I liked alot. Scaffolding gives you the nice pre-configured classes and pages for adding, editing, and deleting records, but my survey doesn’t line up exactly to that model (ie, I don’t want anyone to go edit or create the questions on the survey, and I wanted to create a flow from creating your candidate record to then answering each question in the proper order). With some help from Eric, I soon got into the REST mindset and got the application working properly. That was cool.

I didn’t consider deployment too much until I had the app completed and working on my local instance. My plan was to just deploy it to my DreamHost account, which I assumed would be easy. I’m used to deploying .NET applications, which is extraordinarily simple, and it didn’t occur to me at first that Ruby might not be as easy. After copying my files out to DreamHost, I found this wiki page of theirs. I was a little bit annoyed at first after reading that, because I realized I would have to run a bunch of commands to get rails running and the permissions correct.

Fortunately, as Eric pointed out to me, DreamHost already has a solution. Now they use mod_rails, and all you need to do is copy out your code, check the box for mod_rails, and then use their configuration panel for that domain to point to the public directory used by ruby on rails. After doing that, everything worked great and I have to say that I am now pretty sold on Ruby on Rails. One thing I’ve always liked about .NET is that it’s pretty easy to deploy. Now that I’ve seen Ruby on Rails can be easy to develop and also easy to deploy (at least with DreamHost), it’s a much more attractive language to me.

Last night Joe Meade and I road tripped up to the Shenandoah Ruby User Group (ShRUG) meeting in Harrisonburg, Virginia, hosted at the RosettaStone offices.

We went there to find out why there is a hotbed of Rubyists in rural Virginia! There were 20+ people at the meeting which was hosted in a conference room at RosettaStone. RosettaStone sponsors the group, kindly providing great sandwiches and soft drinks.

This week’s meeting was based around a Lightening Talk approch, so I of course spoke up and said I’d be happy to do one!

Lightening Talk 1: Learning Rails
Lynda.com is a good resource for beginners to Ruby and rails.. Most books deep dive into Ruby very quickly, and this site provies some simpler materials. Also some vidoes, including free ones…

Heroku.com is an online IDE plus platform for Ruby… So don’t fight with the installation, just go through web interface to get that first hit of coding Ruby on Rails!

He had setup an account for us, the username is shrug.friends@gmail.com, and I have the password, however not sure if he wanted to publish it.. Email me and I can share it. You can see the deployed application at http://shrug.heroku.com/, right now it’s just an empty shell.

The idea of using Heroku as a learning tool really worked for me. I know anytime I teach someone Ruby on Rails we have the initial battle in getting SQLLite to work, or the right gems in place. And I always have to say: trust me, the rest is much easier. Especially when showing some on Windows Ruby for the first time… With Heroku they can get something up quickly, and get over the “I Suck” stage quicker.

I didn’t catch the name of the presenter…

Lightening Talk 2: Open ID
I talked about OpenID, starting with Code Monkey, because I like the line about “Maybe manager wanna write goddamn page himself” which is at second 28 of the clip. I did a demo of how HighTechCville uses OpenID, and showed a bit of the Ruby on Rails OpenID plugin, and how easy it is to integrate.

Lightening Talk 3: Prototype
“Snuggs” did a presentation about how simple Prototype is, and showed us how he used it to quickly create a gallery of pictures that allows paging via Ajax and Javascript that is on his media site MonstarOnline The photowidget javascript all based on Prototype is at http://www.monstaronline.com/global/ecma/photowidget.js.

Lightening Talk 4: IRB
JeffMo talked about what IRB is and what we can use it for… He did a great session showing IRB and demonstrating how you can do things like spelunk what methods are available on your objects:

s = String.new
s.methods

or search for a specific method

s.methods.grep /reverse/

We also learned a bunch about how to use method_missing to catch methods that aren’t defined, and make intelligent decisions on what to do with them, as well as defining methods on the fly.

Lastly we saw a Domain Specific Language for playing Tic-Tac-Toe, all using dynamic methods and method missing! You can download the files and try it yourself from JeffMo’s site: http://www.jeffmo.us/shrug/
.

So, to sum up, while the Charlottesville RubyCodeJam has beer and cool shirts, and ShRUG has softdrinks, clearly we’re doing something wrong as they have double the turnout we usually do! It was great to meet some new people, and I hope some of them make it down to beCamp, which is THIS weekend!