I'm not sure how alone I am here, but I really dislike comments in code. I don't mean at the top of a method or file for documentation, but scattered throughout all of the code base.

Ever since I started using ruby/rails, I have been spoiled with code that's very readable all because of great conventions. Even tried to bring those practices into other languages for different projects.

Code should be almost as readable as a book. You should be to read without pausing too much as well as skimming. It's a sign of clean and understable code. I rather a new developer on the project understand well-written code than needing comments everywhere.

Comments are almost like an annotation in a book. So use them sparingly.

Moving a production site to Rails 3 is no small feat. I've been putting it off since its release a year ago. I wasn't convinced that everything was stable yet, but you get to a point where you don't want to feel left behind. Most gems and libraries I'm using have stopped supporting anything older than Rails 3. To give some perspective, Radio Javan's site has been running since the Rails 1.x framework, which means there's a lot of embarrassingly old code still there. Here's some of what I found most interesting.

• rails_upgrade gem - This is a great starting point, and you can use it to update your routes and your application config files.

• MySQL with UTF-8 - Since the site is old, my database is still set to latin1_swedish_ci encoding (default for MySQL). This is probably before most of anything in Rails or Ruby even talked about UTF-8. With Rails 3 upgrade, it's recommended to use the mysql2 gem, which is much faster than the previous one. But this forces all text in UTF-8 resulting in ugly, unreadable text everywhere. Took me a while to figure out that the new gem was the culprit, and looks like I have to run some big conversions to get the DB to real UTF-8. Again, because of the massive amount of data and everything being in production, I have held off on this and just went back to the original mysql gem.

• cookies - Any existing session cookies from a Rails 2 app become corrupted and unusable. There are some hacks people have tried, but you still run into problems. What this means is that when you deploy to Rails 3, then all users will have to get a new cookie. So all existing sessions, logged in status, etc are lost. This becomes even a more pain if you have other Rails 2 apps running in a subdomain -- I had to upgrade those too. I really would have thought it would have been seamless for users, but I guess they have to suffer too. For example, if you are running the iPhone/iPad app, the session is broken until the app is restarted (not just resumed from background).

• html_safe - All string outputs in views now escape HTML by default for security, and there's no way to disable that. It was rather challenging to find all the spots where you need to call html_safe, I'm still finding missed places. And I'm not even going to talk about to_json.

• bundler - Bundler is way cool, I'm glad I'm using it now for deployment. No more making sure that each server has the proper set of gems installed.

• sphinx - I've used ultrasphinx for the longest time for search and it's worked great for everything I needed it to do. But it's admittedly been a dead project for a while. So I moved over to thinking_sphinx.

• will_paginate - Wow, so the new Rails 3 compatible gem for will_paginate basically doesn't do any pagination on Arrays or Collections by default. You can get it back for Arrays if you require 'will_paginate/array', but not for Active Record collections. Small things like that meant I had to reimplement methods like next_page.

• background tasks - I've used backgroundrb for all my cronjobs and long tasks. But even the new version which is Rails 3 compatible had issues. So I switched over to using whenever, which does cronjobs but not long tasks. Seems to work ok but they are no longer "workers" doing things in a queue, so you need to be careful since you can have multiple same type of tasks running.

• geokit - There's a fork on github for Rails 3 compatibilty (thank you!) but it does require using the new Active Record chaining.

I could go on, but you get the point. Most upgrade guides suggest updating your Mailer, Active Record, and routes are the biggest tasks. But it's not, those are the easy ones. There's a bunch of small gotchas that I still keep finding (timezones, rmagick, etc).

A few hours were spent on Ruby 1.9 (mostly when trying to figure out the UTF-8 issues). But even more gems were broken in 1.9 and there were no fixes available.

What about performance? Most of what you read says that Rails 3 is not any faster, and most likely slower. That's true. But at the same time I did update to the latest REE and Passenger 3 (previously running Passenger 2). And I did spend time fine-tuning the Ruby garbage collector. Perhaps the HTTP streaming stuff in Rails 3.1 will help out (on the user side).

I get the impression that Rails 3 and Ruby 1.9 is definitely what you want to do for starting a new app. It's pretty scary to update big sites to it, but I'm glad I did it now instead of waiting even longer. I'm not totally sure on how many big sites have moved to Rails 3 (Twitter? 37 Signals even?). The Rails community isn't much for backwards compatibility, and I'm all fine with that if the new stuff is much better. We'll see.

I have a few years experience with iOS, but recently I decided it was time to take up Android. I never really got into it, mostly because I didn't have an Android device, but also because I wasn't sure what to expect. However, I just finished up the first version (with more to come) of the Radio Javan app and here's some of my experiences.

1. The layout XML stuff is actually not that bad. If you use it properly, you'll get it displayed on different resolutions fine.
2. If you think that the Android OS version will guarantee what the device is running, think again. I decided to use the Android MediaPlayer libraries, which since Android 2.2 support progressive downloads for streaming audio. But I learned that the underlying required Stagefreight framework is not enabled on Verizon Droids so I can't count on Android 2.2 to have that support. Undoubtedly, there are more things like this that I don't know about yet.
3. It's way too easy to kill the battery. If you're not careful, it's easy to write an app that will drain the battery but also not give any good notice to the user on what app is the culprit. For example, if I download 5 apps from the Android Market and they all have something running in the background, it's pretty much trial & error figuring out which one is killing your battery that day. To this, I think Apple got it right with the background & multitasking in iOS.
4. The Eclipse tools and debugging is nice. But I've noticed as your project gets bigger, builds take forever as 1 small change will trigger a rebuild on all the XMLs that it needs to compile.
5. Forget running the emulator as it's too slow. You need a real device.
6. The overall framework makes sense. You just have to be really careful because different devices will do things differently (when does the OS decide to destroy vs pause your Activities, restarting Services in the middle of the night, and so on). Definitely implement all clean up methods.

I was also surprised that it only took a very short time to write the app. I think the UI layout stuff helped with that. But fragmentation of Android devices is a real world problem. Not only are there different devices with different Anroid OS's but there are also different carriers that change the OS. I'm sure I will discover more "bugs" in the app just because of that reason.

Introducing Playlists for Music Videos on Radio Javan (coming soon)

The last few weeks, I've been working on writing the RJ for iPad app. The design of the app was done by Roozbeh Meghdadi as he worked on helping to bring our iPhone app to the iPad's big screen.

You might ask, why iPad? How many people really have an iPad? 

The answer is: a lot more people than you really think. But really the point is to keep doing better and newer things for Persian music market, because we all know it needs a lot of work. And so why not do something like this that let's people discover music so easily?

As we first started, the focus was on the radio, videos, mp3s, and podcasts. The iPad is great for viewing content, so our goal was to make sure it's the best experience possible for browsing through all the different music content quickly and easily.

And I really do think this is the best way of watching music videos, so much more than on a computer. Once you give it a try, it's really an amazing thing.

The app took about 2 weeks to design, 3 weeks to develop and do the coding, and then about another 2 weeks of cleaning up the design, code, and features. The hardest part of the project, at least for me, was supporting both landscape and portrait modes. But this was a must for all iPad apps, I can't imagine one without that support.

Of course, just like always, this is the first version. We're definitely planning on supporting background and multitasking soon in November when the new iOS is released.

So check out Radio Javan for iPad, and let us know what you think.