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!

I’ll be presenting HighTechCville to the Neon Guild next Monday, September 15.

I’ve been looking forward to this for months because most of the people information in HighTechCville comes from the Neon Guild public membership database. My initial success in finding Communities of Interest came about by looking at the over 200 people in the Neon Guild and finding 8 folks who were all technical writer folks! I would never have guess that there are enough people in the Neon Guild who do technical writing to do a group dinner together!

See you’all there!

Here are directions from Debra Weiss:

Location:
Inova Solutions
110 Avon Street
Charlottesville, VA 22902

Directions from downtown Cville:
Take Market Street E to Ninth/Avon St, turn right.
Go over the bridge, get in the left lane.
Look for Spudnuts on the left.
Turn Left at Spudnuts, and then another immediate left.
Follow around, you’ll see a large brick building. That’s Inova.
Go around to the front of the building and park.
Take the elevator to the second floor. We’re in the café.

I love CruiseControl.rb, but one of the things I’ve found is that it exposes via the web interface a lot of what is potentially confidential data. From the cruise_config.rb containing accounts on our SVN server, to being able to browse source files, which would include database.yml, again, exposing usernames and passwords.
(more…)

We’ve been using RimuHosting.com’s VPS servers for a couple of small prototype style RoR applications that don’t warrent the “full” treatment of their own dedicated servers in a clustered, redundent, scalable, etc environment. An example is my side project learning about the Semantic Web and Microformats: HighTechCville.

One of the parts that I really like about RimuHosting is there very complete use of the Webmin administrative console. The more I work with it, the more I like it. While the GUI isn’t anything incredible, it is very serviceable. And you can pretty much do most SysAd tasks from it, from installing packages, which really surprised me, to setting up log file rotation.

So here, in no specific order are some tips for folks doing a fairly plain jane RoR deployment on a RimuHosting VPS:

1. Don’t forget Log Rotation! We did some load testing for a day on one app and generated a 1.2 GB production.log! Webmin provides this under System -> Log File Rotation. You can easily rotate all your mongrel logs by doing /opt/apps/hightechcville/shared/log/mongrel.800*.log. By gzipping them you get much smaller files, and they will be pruned after 4 rotations. I did have an issue with BackgroundRB not being happy with the log file being moved under it, however I get so little output from that that when BackgroundRB restarts it resets the file.
2. Process Monitoring! Under Others -> System and Server Status is the ability to monitor how your server is working. You can do both local monitoring, for database, processes, memory usage, but also you can check if you RoR app is up and running by adding a Remote HTTP Check, and just supply the url of your application. What’s nice is you can add a text pattern to look for, or to ensure isn’t there, so you can check and verify you are NOT getting the usual Service Down or An Error has happened page. Of course, if your box goes down in a bad way, then you may not be notified, but it’s at least a quick and easy first step.
3. Cron related tasks. Often we need timed processes to do a bunch of work. Before investing in the complexity of integrating something like BackgroundRB, can you do what you want via a Ruby script or write a Rake task? The invoke it from Cron. Alternatively, if you don’t want something external to your Rails app, just add the periodic task code to some sort of RecurringJobController, and invoke it from cron via wget localhost:3000/recurring_job/run call! Sure, your mongrel will block, but if you have a cluster, who cares. You can also schedule this via a HTTP Remote Process check
4. Tweak Postfix? We really like the ExceptionNotification plugin for RoR, getting immediate notice of errors on lower traffic sites is great. However, we found that we had to tweak the local_recipient_maps setting to get email to be sent out, otherwise you get a 550 server error. Just go to Servers -> Postfix and choose edit config files. You want to edit the main.cf and set local_recipient_maps= so it is blank.

Got your own tips for easily setting up a reliable RoR app on a VPS, please let me know in the comments!

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.

Today I’m attending beCamp at the offices of CBIC on the downtown mall in Charlottesville.  There have been some very interesting sessions already and attendance is great.  I suggested one session, which we just had this morning.  I titled the session “How to choose languages - .NET vs Ruby vs Java vs Php vs ?”.

At OpenSource Connections, we have a wide range of skillsets covering all the major languages, and we have the pleasure of working with a wide variety of clients where we get to use all those different skillsets.  It’s a lot of fun and something I really like about OpenSource.  Often times for our projects, the client’s needs specifically dictate a particular language, but other times they have no preference or are building a system from the ground up and we get to help choose the language.  I have my ideas of the various benefits and disadvantages of the languages, but I proposed this session to hear other people’s feedback as well.

We had a great group of about a dozen people in the session, with skill sets that covered c, c++, perl, .net, php, java, ruby on rails, cold fusion, and even Delphi.  This wide range of experience brought some interesting perspectives.

I started the conversation by stating that all development languages are just tools, and the important thing is what we build at the end.  The important thing is not necessarily did we build it in .NET or Ruby, but did we meet the customer’s needs?  I prefer to be technology agnostic, and most everyone in the session seemed to agree with that sentiment.

One of the first things said in the session was probably the most observant:  the choice of language is often presented to us as developers, and that decision is actually made by the business, not development.  I think David from the Darden Business school at UVa was the one who pointed that out first, and it’s certainly very true.  The group seemed to agree with that, but with some reservation that we wish we could have more control over the language used.

Mike from Fabjectory pointed out that in reality, the framework may be more important than the language chosen.  Ruby on Rails may be the best example of this, because it’s an easy to use framework that encourages you to do good development practices.  Microsoft has release the MVC framework to accomplish a similar goal. 

There was some discussion at the beginning when Caleb expressed a hope that there would be fewer different development languages in the future so that developers don’t have to try and keep up with so much, but others pointed out that competition and having many diverse languages is part of what encourages innovation and new features.  For example, Jim pointed out that Ruby on Rails is great for web development in part because it’s geared specifically towards that process, whereas ASP.NET has procedural carryovers in the language from the old classic ASP and VB days.  Likewise, Jim expressed the opinion that C# has become a better language than Java because it is more fresh and doesn’t have as many legacy features as Java.

Your final deployment server will also drive the choice of language naturally.  If you company will only run Windows servers, then you probably don’t want to try and run Ruby on Rails on top of SQL Server on a Windows server.  You should probably stick with .NET.  Likewise, if you are going with an Apache server, you should probably consider Ruby on Rails or PHP.

Who will maintain your application after it has been deployed?  If you are a consultant, than the skills of your client need to be considered.  How much do they want to modify it themselves, and what skill sets do they already have that will make this easier.  I suggested that because of the development tools and the fact that it’s a compiled language, I feel .NET is a much more scaleable and better language than PHP.  However, if a client wants to tweek small parts of the code themselves, then Php may be a better choice because it’s easier to modify and perhaps easier to understand to a non-developer but tech savvy person.  But with that ability to make changes easily also comes risk:  If the people making the changes don’t know the whole system as a whole or good development practices, then the easily “hackable” nature of PHP may actually get them in trouble.  A more object oriented structure in .NET that needs to be compiled may be more stable and less susceptible to mistakes.

Considering how to make modifications in the future is also important.  David from Darden expressed his opinion that when using Java web development frameworks, Struts is easier to make modifications to than Tapestry.

Towards the end of the session, we also briefly touched on a few other topics which I will quickly summarize people’s opinions here.  So here are more random thoughts from the session:

•   .NET is the best option for building windows based desktop applications, but you should consider QT if you want a more cross platform compatible application.  Java Swing according to one anonymous attendee “still sucks 15 years later.”
• One of the great things about Ruby on Rails is the built in testing and framework scaffolding.
• Mono can be used to make .NET applications run on other OS’s.  Though there wasn’t much experience with actually doing that in the room, that is what some major companies are doing like MySpace.
• Building webservices is very easy in .nET, REST based applications are also easy in Ruby.

We ended the session on a funny note, when Jim made the statement that a lot of very large companies still use C for development.  Though the people he is thinking of are older developers and so they may just be tied to older languages, they are still some of the brightest minds he’s known.  I believe it was pointed out that Amazon’s services are built with C.  So we’ve come full circle through C to .NET, Java, and Ruby, and perhaps ultimately back to C!  (just to be clear, I state that with sarcasm.  Although you can undoubtedly do all kinds of things with C, the value of all these newer languages and frameworks is how much easier they make it).

Thanks to all those who attended for a great discussion (completely devoid of any fist fights about which language is best), and I’m looking forward to the rest of beCamp this afternoon!

You can see a slideshow of my pics from beCamp 2008 here