The phone platform of the future
» Posted on 14 Feb 2010You may have heard that my 1st gen iPhone broke only recently. This is why I got an iPhone 3GS today, but not without an ache in my stomach. That is not only because of the big heap of money I needed to hand over to get an unlocked phone. It’s more because I have a strong doubt whether the iPhone will continue to attract developers and thus be the phone platform of the future, given the App Store rules won’t change significantly in the near future.
While many iPhone developers are of the opinion that developing for the iPhone is a joy compared to all other mobile devices, the waiting time between submission and approval is horrible. That is especially true in an agile world, where you have a dozen bugs fixed and two features added in the 2-week timespan that Apple needs to review the “new” version of your application.
So what’s the advantage of reviewing stuff? A quick review of an application won’t guarantee it’s not malicious. There has been malicious software in the App Store before. Only a review of the source code could prevent malicious software, but of course Apple does not have access to all the source code of all the applications in the App Store. And if it had, it would not have the time to review it properly.
Next, Apple promises that the reviewing process makes sure that applications are more reliable. I think the opposite is true. By delaying application updates by roughly two weeks, more stable versions of the same software could better be shipped via snail mail.
So what should Apple do?
Well, that’s easy. Just take a look at how the operating system works that I am currently using to write this post, and that as served me so well in the past years. I can install any kind of software in my local MacBook Pro running Mac OSX. Have I ever had problems with malicious or unstable software? Not any more than on the iPhone. So Apple should open its doors for any kinds of applications, without the cumbersome and unreliable reviewing process.
I’m not trying to say that rejecting or pulling an app is essentially a bad thing. If users complain about a software being malicious, pull it. If lots of users complain about an app crashing all the time, give the developers a deadline, then pull it. What I’m trying to say is, the strict rules of the App Store, and the delay caused by Apple for each new version of a software will eventually kill the innovation that drives the iPhone platform. The innovation that is currently still inherent among iPhone developers. So it is time to give up those unnecessary rules before the innovation has died.
The 100-year language
» Posted on 13 Feb 2010We know that Java must be pretty good, because it is the cool, new programming language. Or is it? If you look at the world of programming languages from a distance, it looks like Java is the latest thing. (From far enough away, all you can see is the large, flashing billboard paid for by Sun.) But if you look at this world up close, you find that there are degrees of coolness. Within the hacker subculture, there is another language called Perl that is considered a lot cooler than Java. Slashdot, for example, is generated by Perl. I don’t think you would find those guys using Java Server Pages. But there is another, newer language, called Python, whose users tend to look down on Perl, and another called Ruby that some see as the heir apparent of Python.
– Paul Graham, Hackers and Painters, p. 183
He’s right.
Why you can't run Rails 2.3 applications on Ruby 1.9
» Posted on 06 Jan 2010The recent release of Rails 2.3.5 has fixed some Ruby 1.9 related bugs – which is nice. So I thought this is the right time to try porting an existing Rails 2.3 app to Ruby 1.9. Again, I was out of luck. The encoding problems present in Rails 2.3 are just unbearable. Let me show what I mean with a little example. We will build a little example app and use some special characters to see if things go wrong.
First, in order to set the default external encoding to UTF-8 for Ruby 1.9, we add this line to our .zshrc, .profile or whatever file is loaded by your shell:
export LANG=en_US.UTF-8
Then, we either need to open a new shell window or re-source the file:
source ~/.zshrc
After that, we can check if everything worked by running irb.
irb(main):004:0> Encoding.default_external
=> #<Encoding:UTF-8>
Notice that this will only work with Ruby 1.9, because Ruby 1.8 does not know anything about encodings. So if you are getting a NameError: uninitialized constant Encoding error, you are running a wrong version of irb.
Now we come to the Rails part. Assuming you have Rails 2.3.5 and rvm installed, we do the following:
rvm use 1.9.1 # or whatever you have to do to select the ruby 1.9 interpreter
rails sample_app
cd sample_app
script/generate scaffold article title:string description:text
script/server
Then point your browser to http://localhost:3000/articles and play around a little. Everything seems to work fine, even when saving articles with special characters. Next, try to put in special characters in the template itself. For example, try replacing “Listing articles” by “Listing cööl articles”. BAM! You’ll get a:
incompatible character encodings: UTF-8 and ASCII-8BIT
Now, this is not Rails’ fault. Our DB adapter (in this simple case sqlite3) does not properly support string encodings in Ruby 1.9. This means you will get ASCII strings from the database, no matter what you set in your database.yml. Using umlauts in the template sets the template encoding to UTF-8 automatically, so merging in ASCII strings from the database will fail. As a solution, you can install an encoding aware DB adapter. For MySQL, you’ll need to uninstall the mysql gem and install sam-mysql-ruby instead. If everything worked, you can check Article.last.title.encoding.name in irb, and get “UFT-8”. For this little example, we’ll just fake it and force the encoding of the strings returned by the database:
<td><%=h article.title.force_encoding("UTF-8") %></td>
<td><%=h article.description.force_encoding("UTF-8") %></td>
This should be working now. Next, we will use an umlaut in the label of the Rails link_to helper:
<%= link_to 'New cööl article', new_article_path %>
The next reload will show the feared mixed encoding warning, and I promise you won’t get rid of it. It’s there because the string ‘cööl’ is UTF-8 encoded, but the url that is implicitly generated by the url_for() method is ASCII encoded. You would have to hack deep into the guts of Rails to fix this. Setting the default internal encoding won’t help either, just in case you were wondering. So if you want to use umlauts or other special characters in Rails helpers, you are out of luck in many cases. As I am German, I have umlauts all over the place. Not using them is not an option for me, like for nearly everyone who lives outside of an English speaking country.
But don’t get too depressed about this, as Rails 3 is maturing and already looks very promising. So let’s just try the same as above with Rails 3 for a change. First, we check out a very bare sample application. It’s basically the same if you would have gone through the app creation, git initializing and gem bundling process yourself, so this is really very bare boned:
git clone git://github.com/ralph/sample-rails-3.0-project.git
cd rails_3_sample_app
gem bundle
script/generate scaffold article title:string description:text
script/server
If you have an encoding aware database adapter and play around here, you will see that everything works great. Again, we add a random umlaut to the index template, and everything still works. We change the helper text to include an umlaut, and everything still works. The only thing we need to take care of is installing an encoding aware database adapter, like sam-mysql-ruby, in order to be able to save special characters in the text fields. Finally, Rails 3 looks like a release I would like to use with the Ruby 1.9 interpreter.
I don’t know about you, but I can’t wait for Rails 3 to be released. I think it’s a great step forward and will help to spread the adoption of Ruby 1.9. That said, you should really try to port your apps over as soon as Rails 3 is released. I am really hoping to see an increased adoption of Ruby 1.9 instead of people sticking to 1.8. Ruby has so many advantages, and if you don’t port your stuff over, you are not helping. So be a good Rubyist, give something back to opensource. Test your stuff on 1.9 and report any errors back to the maintainers of the libs that you use. Then we can make 2010 the Ruby 1.9 year. :)
Older posts:
- 18 Dec 2009 » Trying Rails 3.0.pre today
- 14 Dec 2009 » Rails 3.0 XSS Protection in ERB
- 07 Jul 2009 » Migrating our search from Ferret to SOLR
- 11 Jun 2009 » Slides of my Rails usergroup Hamburg talk
- 02 Jun 2009 » Slides of my RailsWayCon short talk about front end performance
- 01 May 2009 » Encoding issues with Ruby 1.9 and Rails 2.3
- 14 Mar 2009 » The sense and nonsense of following on Twitter