Windows Phone 7: Initial Impressions

I was at PDC in Redmond last week and the cool swag was an LG E900 Windows Phone 7 phone. I dropped in my SIM Card and have been using it as my primary phone for the last couple of days. What follows are my initial impressions.

The Good

  • The hardware is really responsive. This may be because I'm comparing it to a year+ old myTouch running Android 1.6, but the phone seems really, really fast.
  • The Facebook app is pretty awesome. How you feel about this depends on where you fall on the sliding scale of idealism versus cynicism with regards to Facebook.
  • There are actually games available (Yay XNA, I guess).
  • The design of the home screen is really nice.

The Bad

  • When the phone runs low on power, it just shuts off. No warning, one minute you're playing Bejeweled, the next you're staring at a black screen. Trying to turn it on again, results in an LG logo followed by a black screen. I would have thought that the: "Your phone is about to run out of power. You should plug it in now." warnings would be standard by now.
  • The mail client. Other people like it, but I don't. To be fair, that's because GMail has ruined me for all other mail clients forever. The reality is that if it showed me conversations instead of messages and had an archive button instead of a delete button I'd probably love it.
  • The device is a little awkward to hold. The search/back keys occupy the entire bottom bezel and I find myself accidentally pressing them while typing with disastrous results (... as disastrous as interrupting any Facebook interaction can be, that is). The power/lock switch is on the top of the phone making it difficult to lock/unlock the phone one handed.
  • Bing Maps < Google Maps.

The Ugly

  • The browser. It's some hybrid of IE7 and IE, but I gues you can't just jam WebKit on there if you're on Microsoft team.
  • The name: I've got a Windows 7 Phone 7 phone. Come on!1


I need to update my myTouch and get something fast and sexy that runs Froyo ;)

More seriously, since checking my email on the subway into work and using Google Maps to find my way around the city are why I have a phone, it's probably not going to be displacing my Android in the immediate future (I'll still play Bejeweled on it though).

[1]Quick, which seven is the one that's not supposed to be there? It's easy to pick on names, but it's always good to remember that nobody could say Wii with a straight face for months, but Nintendo ignored them all while sitting atop the largest pile of money every assembled in all of human history.

Initial Impressions of Ruby on Rails: An Excess of Magic [1]

After a solid 24hrs of working on a school project involving Ruby on Rails I've decided that RoR relies on more magic that I really feel comfortable with. Admittedly, I've only been working with the language/framework for a short time so it's unlikely that I've "got it" yet, but it just seems that magically choosing the template and then magically packing up the controller's instance variables to provide context is just too much magic. The fact that the session and request objects are magically present and that the response materializes out of a method that as far as I can tell returns @user bothers me. Sure it makes getting that initial CRUD application running dirt simple, but once you want to actually start programing you have to figure out where this stuff comes from and goes to anyway (And then there's the generated code2). That being said, once I got a handle on the basic stuff, I essentially started writing Django applications using RoR :D. The fact that I've basically reverted to writing Django applications using a slightly different syntax and API probably says more about my relative level of comfort with Python+Django vs. Ruby+Rails than anything else.

One thing that does stand out as cool is RoR's use of Ruby as a template language. After all, if I'm a Ruby programmer and I like Ruby, using Ruby to write templates sounds like a great idea. This is exactly the reason that I'm not particularly fond of RoR's approach to ORM. If I'm a Ruby programmer and I like Ruby, wouldn't it be great to define my database schema using Ruby. Except that I don't. At least, not if I'm using Rails+ActiveRecord. I define my schema as a series of diffs, serialized as ActiveRecord calls. This approach provides some cool features, except that if I want to know what instance variables an object has I don't look at it's class, I look at the DB which doesn't feel quite right.

I think both Ruby and Rails could provide a productive application development environment on par with what I'm used to with Python+Django; however, RoR does not inspire a profound sense of "Oh-my-god!-I've-been-doing-web-apps-wrong-all-along." but that might just be the fact that I write MVC web apps whether I'm writing Python or Ruby or even Java. That being said, the project's not over yet, I may yet stop worrying and learn to love Rails.

[1]I fully realize that writing about Ruby on Rails was cutting edge about 3 years ago; however, I've only just started using it, so I only have initial impressions now.
[2]I don't really like generated code. Not all code generators obviously. I like compilers and JIT compilers and even it's-a-code-generator-that's-logically-equivalent-to-a-compiler, but I'm really not a fan of here-I'll-generate-this-boilerplate-code-for-you which works fine until you realize that you should have generated the boilerplate code with option Y. Now you have to decide are you going to port your changes to a freshly generated template or are you going to port option Y to your current code? Neither of which is particularly attractive. In the case of Rails, I find that the code generation doesn't get you much and at the same time obscurs how the framework actually works.