jrmehle.com

My mind has been racing with thoughts about Apple’s latest and greatest new device, the iPad ever since the announcement Tuesday. There has been so much speculation and hype that there was no way that the actual device was going to live up.

iPad © Apple

Apple has put together some top notch hardware as usual. The iPad sports their standard aluminum and glass exterior and is manufactured to be environmentally friendly.  The most surprising part is the A4 CPU. The workhorse of the device is the first of it’s kind that we’ve seen from Apple. Gizmodo has an article stating it runs at 1GHz. It’s been deemed an ARM chip (as opposed to a mobile chip). The chip has to have come out of Apple’s 2008 acquisition, PA Semiconductor. The A4 is a low-power mobile chip, so I wouldn’t expect to start seeing iMacs and Mac Pros being powered by it any time soon, but could we see a variant at some point? Absolutely. I have to believe that Apple is exploring the idea. It would make even more sense that we’d see a future iPod or iPhone making use of the A4.

In addition, there is the standard array of components such as touchscreen, a mic, a compass, an accelerometer, GPS, and wifi. A mid to high end model will also have 3G wireless which requires a monthly contract with AT&T. The wifi variant will be making it’s debut in “60 days” while 3G models won’t go on sale for “90 days” because of  they are awaiting FCC approval. Leo Laporte and gang on MacBreak Weekly quipped that Steve has found a way to make us each buy two. I figured AT&T must have got on their knees and begged and promised they’d beef up their network. I fully expected them to announce a different wireless partner.

The wireless plans available are either $15 or $30 per month for 250MB or Unlimited data respectively. So much for the idea that the wireless would be subsidized with each purchase/download. The contracts can be terminated at any time, but it’s still painful to think that some people out there will be paying $30 for unlimited data on both their iPhone AND this new iPad device. Even so, most of the iPads sold will end up being the 3G models. The sim chip is swappable, so evidently it will be possible to chose a different data provider.

The iPad runs iPhone OS 3.2. There are the standard set of applications you’d imagine for email, web browsing, playing or viewing various media types. The device quickly was nicknamed the “giant iPod Touch,” for it’s resemblance in both hardware and software to its smaller cousin. Just like it’s next of kin, the iPad runs all the existing AppStore applications. There was some speculation that it would be very easy to port existing iPhone applications to the tablet device when it came out. It will be interesting to see what kind of app purchasing frenzy the initial set of iPads sets off. A large part of the success of the iPad will depend on the apps that are available. You’re going to need to see a different breed of apps as well. Things that work on the iPhone won’t always translate and vice versa. It may take some time to get everyone on board. There will be new gold rushes in the AppStore.

Apple also announced it has ported all of it’s iWork apps over to the iPad. The total cost to get a spreadsheet, word processor, and a presentation app is $30. Not too bad. They almost had to do iWork on the iPad or the analysts would say there was no way to do “real work” on the device. To a certain portion of the population, that is still true. As a developer, I’m not going to be coding on the thing.  Graphic designers aren’t going to be using them as workstations either.

A prominent feature of the announcement was the new book store. The books will be in epub format, which should make the publishers happy. They are already used to producing books in that format. Apple announced a number of big names as partners. The general sense is that this will be the Kindle-killer. Apple is claiming a 10 hr battery life even while playing fullscreen video, so it will be able to go quite awhile displaying text.  What it may come down to is preference. Some people get more fatigued when viewing backlit screens.

iTunes Bookstore © Apple

Of course Apple leaves the price for last. They even were quick to acknowledge that the iPad had been rumored to be a $1000. Depending on how you look at it, that could be way off or that could be pretty close. The iPad comes with either 16, 32, or 64 GB of storage and as previously mentioned, you can opt for a 3G model or not. This equates to a price range of $499 – $829 with the higher end models also carrying that 3G contract. Certainly a bit lower than expected and in line with Apple’s existing device pricing structure.

In addition there were a number of accessories shown. There is a plain old dock, a dock with a keyboard (which basically looks like their small wireless keyboard), a snazzy looking cover, and a camera connection kit. All of these items are extra. Once you throw in one or two, some apps, you are pretty much at that $1000.

What would an Apple release be without the critics. There are plenty of things the iPad was supposed to have or was rumored to do which it doesn’t. Because it uses the iPhone OS, it can’t run multiple applications. No playing music while you are web surfing on the couch (or toilet).

As I already mentioned, if you have an iPhone with an unlimited contract, you’re going to be paying the same amount to get a 3G data plan on the iPad.

There is no camera, so there is no way to do video conferencing. Maybe a camera could be made to attach to the dock later?

There is a dock connector and a 3.5mm headphone jack. While there is a vast amount you can do with a 30-pin cable, it really makes it a one-at-a-time deal for accessories. It would have been interesting to see 2 mini USB ports on the side. Almost not worthing noting is that there is no optical drive or ethernet port. However, you can get an existing iPhone video out cable to drive an external monitor.

The iPad Side View © Apple

During the demo, Steve loaded Time.com and it clearly showed that Flash wasn’t supported. A lot of pundits are saying that this is a deal-breaker for that size device. If the iPad is meant to replace a laptop, it must do the web just as well as a laptop and that basically means Flash.

There is no handwriting recognition. While a large touchscreen like that begs to have a natural handwriting interface, maybe the keyboard will be enough. I’m not convinced we’re going to care about that.

There are also a contingent of people lashing out at Apple for making the iPad a closed, proprietary system. I ask them, would you expect anything else from Apple? Take one look at their history with iTunes, the iPod, and iPhone. The iPad was never going to be an open device.

It must be said that this is a first generation device. There has been a history of Apple’s first gen devices not living up to expectations. To Apple’s advantage, there is much they can do in software to add to the already solid product. There will likely be enough inertia generated by this initial foray into the tablet space for them to continue tweaking the iPad. It’s not so much the iPad I’m interested in. What I really want to know is what will iPad version 2 look like? What will the world that has acclimated itself to the iPad look like.

As most have said, the iPad is not a device for the geeks. It’s mainstream appeal comes in the familiar iPod interface and the simplicity. The fact that it doesn’t have Flash or an open operating system truly does not matter to a large portion of the audience for this thing. Everyone that is frustrated by having a computer and the complexity of it will find the iPad a joy to use. If you can afford a Kindle, you can afford the iPad and it does so much more. There are also a myriad of other applications. Imagine your doctor having applications for charts and to show patients information. Think about an application that does statistical analysis based on input. You could take an iPad out in the field with you to crunch numbers on. Or how about just as a generic touch interface. I’ve heard of dumb industrial machines being made “smart” by connecting an iPod Touch and writing a specialized application. There are literally millions of tasks that could be done with a large, precise touchscreen interface. This is why I am so excited to see what the future will bring.

Safari's Top Sites

If you do more than a minimal amount of work on a number of Ruby web projects, you’ve more than likely sat down to figure out how to use Phusion Passenger in development. It makes switching between several projects a snap. Ruby and Rails developers have also been known to disproportionately favor Apple machines for their development workhorses. Continue reading if you fit the mold.With the release of Safari 4 came the nifty “wall of screens” feature known as Top Sites. This feature takes your most visited sites and displays them in a nice grid. It’s more pretty than useful, but I’d be lying if I didn’t use it at least once a day.

Lately, the combination of the previously described tools have been causing me pain. One of the things developers tend to do when developing sites is refresh them; A LOT! So typically there are at least a couple of my projects that wind up as Top Sites in Safari. The problem with this is Safari likes to go update those pretty looking screenshots every time you view the Top Sites screen (and randomly at other times). Because I have this set to display when a new tabs open, this is every time I open a blank tab. In other words, very often.

If you haven’t put two and two together by now, what happens when I open a tab is Passenger spawns processes to handle the requests Safari makes (just so it can update it’s screenshots). This ends up consuming several hundred megs of RAM and spikes the CPU load. If you happen to have a memory leak in your application, be prepared to launch Activity Monitor in a hurry to kill the ruby process that is spiraling out of control.

Delete/Pin Button

As a solution, you can easily hit the edit button and blacklist the worst offenders, but you have to do so for each unique URL. There is no way to say don’t ever list pages from “localproject.dev” or even “*.dev”. There is also a way to temporarily stop Safari from trying to update the images, ‘Command + .’

Dear RA,

We’ve had some good times. You were my first and only authentication plugin. I’ll always remember you, but it’s time to move on. There’s this hot, young plugin on the block named AL that I’ve fallen for. So long. *tear*

Rick Olsen’s restful_authentication is out and Ben Johnson’s authlogic is in as the hot Ruby (and/or Rails) authentication module these days. No disrespect to Rick and restful_authentication. It’s got sound security principles behind it, but dealing with the implementation can be a headache. If you’re unfamiliar with restful_authentication, the first thing you would do after installing the plugin is run some generator scripts. These scripts create a bunch of code in your Rails project. Where that becomes a problem is if you have to modify the code and then later want to run the generator again.

Authlogic takes the stance that you should never have to run a generator. It also has a lot of auto-configuration (based on the fields found in your user model). Sessions in authlogic make use of the familiar, standard RESTful controller. The gem itself is also very well organized with things being broken down into modules. The only downside I’ve comes across is I can’t find a page to show me all of the configuration options at once; hardly something to pick on.

Instead of trying to write the be-all end-all guide, this will be more of a case study.  The nature of using a configurable generator, as restful_authentication provides, is that it would be tough to cover all cases. In addition, my app had some closely related components, such as password resetting, that needed to also be changed.

The first thing I did was install authlogic as a gem and pull it into my application. If you’ve spent any time with Rails 2.2 or higher, then this should be old hat for you by now.

sudo gem install authlogic

Then add the following to your config/environment.rb file:

config.gem 'authlogic'

In your user model, add the following:

acts_as_authentic do |c|
  c.transition_from_restful_authentication = true
end

With authlogic in place, you can remove restful_authentication. The plugin directory can be removed from vendor/plugins. You will also need to remove the lib/authenticated_system.rb and lib/authenticated_test_helper.rb files as well as the includes for them. These should be in application_controller.rb and test_helper.rb respectively if you followed restful_authentication’s instructions.

From here, a number of things still need to happen and it doesn’t much matter the order. There need to be some database changes to the users table. A controller for sessions needs to be added or an existing one needs to be modified. The test suite will be severely broken with a large number of tests failing or generating errors. There is also a lot of code to clean up in the user model and controller. As mentioned earlier, there may also be some related pieces which need clean up or conversion such as password resets.

What I ended up doing was half-following Ben Johnson’s guide for setting up Authlogic and adapting it to the existing code. In this process I stripped out all of the generated code from the user model and controller, generated a transition migration, and copied a few views for the users_controller.rb from the sample application.

The sessions_controller from restful_authentication could be modified, however, I found it easier to start from scratch. I copied the controller and views from the authlogic setup guide and made some small changes to the views to adapt them to my layout. You will also need the following model at minimum:

class UserSession < Authlogic::Session::Base
end

Because you inherit from Authlogic::Session::Base, there is no actual code in the session model. Some people like to work with the session variables through a model, you can add this code if you’d like but the default should get you all you need to begin.

A popular feature to add to any authentication system is a method to request a forgotten password. Ben also provides a guide for how to handle this with authlogic. As with the sessions, password resets were a concise and contained component. It was easier to wipe out what was existing and start fresh with the aforementioned guide.

Authlogic follows Rails’ convention over configuration idea and will pick up functionality based on the fields that exist in your model. Of course this means changes to the database and in Rails, that means a migration. Below is what mine looks like:

class TransitionToAuthlogic < ActiveRecord::Migration
 
  def self.up
    change_column :users, :crypted_password, :string, :limit => 128, :null => false, :default => ""
    change_column :users, :salt, :string, :limit => 128, :null => false, :default => ""
 
    rename_column :users, :salt, :password_salt
    rename_column :users, :activation_code, :old_activation_code
    rename_column :users, :password_reset_code, :old_password_reset_code
    rename_column :users, :remember_token, :old_remember_token
    rename_column :users, :remember_token_expires_at, :old_remember_token_expires_at
 
    add_column :users, :login_count, :integer, :null => false, :default => 0
    add_column :users, :failed_login_count, :integer, :null => false, :default => 0
    add_column :users, :last_request_at, :datetime
    add_column :users, :current_login_at, :datetime
    add_column :users, :last_login_at, :datetime
    add_column :users, :current_login_ip, :string
    add_column :users, :last_login_ip, :string
 
    add_column :users, :persistence_token, :string, :null => false
    add_column :users, :single_access_token, :string, :null => false
    add_column :users, :perishable_token, :string, :null => false
 
    add_column :users, :active, :boolean, :default => false, :null => false
 
    # set active users to active.
    User.update_all("active = 1", "state = 'active'")
 
    add_index :users, :perishable_token
  end
 
  def self.down
    remove_column :users, :active
    remove_column :users, :perishable_token
    remove_column :users, :single_access_token
    remove_column :users, :persistence_token
    remove_column :users, :last_login_ip
    remove_column :users, :current_login_ip
    remove_column :users, :last_login_at
    remove_column :users, :current_login_at
    remove_column :users, :last_request_at
    remove_column :users, :failed_login_count
    remove_column :users, :login_count
 
    rename_column :users, :password_salt, :salt
    rename_column :users, :old_activation_code, :activation_code
    rename_column :users, :old_password_reset_code, :password_reset_code
    rename_column :users, :old_remember_token, :remember_token
    rename_column :users, :old_remember_token_expires_at, :remember_token_expires_at
  end
end

Most important are the two change_column calls at the top. Authlogic needs 128 characters to store the crypted_password and salt fields whereas restful_authentication only provides 40. It doesn't really matter if they are still 128 characters when the migration is run down so I didn't bother changing them back. Besides, you'd never do that in production anyway.

As mentioned previously, there is an active column being added to the user model. Restful_authentication has an option to enable user states. This is done to allow tracking of activation. Authlogic doesn't come with anything such as this built in. It's simple enough to add and someone has written a tutorial already. The migration handles carrying the active status over from restful_authentication with a single update_all call.

Notice the rename_columns; the idea is that those columns are essentially flagged for later removal. This is a somewhat cautious approach. It would be possible to handle the removal of these columns in a later transaction.

The final piece to the puzzle is making your test suite happy again. If you are at all serious about testing, you will now have a number of failing tests after making such widespread changes to your application. In my application, much of the functional testing involved logging in user with a specific role. To do this in authlogic is simple.

First, add support for authlogic in tests by requiring the authlogic test module in test_helper.rb.

require 'authlogic/test_case'

Then, add the following to any functional or integration test you need to log in to test:

setup :activate_authlogic

Finally, you can initiate the actual login by calling UserSession.create and passing in your user object like so:

assert UserSession.create(users(:admin))

Notice we can even assert that the result of this login is true so we know it actually happens. The example happens to pass in a user from a fixture, but you could just as easily use a factory to generate your user object. Authlogic doesn't care where the user comes from.

Assuming all of your tests pass and you've done enough manual testing to be satisfied, you can go ahead and declare your switch from restful_authentication to authlogic complete. Changing over to a new authentication module can be a scary thing, especially when you are changing encryption methods for your passwords. It has the potential to lock out every single user in your system if you get something wrong. Remember, TATFT. A solid test suite and thorough manual testing will give you confidence when it comes to launching this into production with your application. If you do your due diligence, your transition will be smooth.

I created this post based on the work I did for DecoyMusic.com. It is now happily chugging along on Authlogic. Now that the transition is done, it's time to start using authlogic's plugin architecture to add OpenID and Facebook Connect support.

If you’ve been on Twitter over the past couple of weeks, you may have seen some tweets using the #fixoutlook hash tag. This is a reference to the Fix Outlook campaign headed up by the Email Standards Project. The group is trying to get Microsoft to stop using Word as the renderer for HTML email in Outlook.

Some backstory will make things clearer. Outlook 2000 (two versions previous to Outlook 2010) used Internet Explorer to render HTML inside of email. If you crafted some HTML for an email, you could expect it to look exactly the same in Outlook as it did in Internet Explorer. In 2006, Office 2007 was released and instead of using IE for rendering HTML inside of Outlook, Microsoft had changed to using Word. Word has a very very simple (and far from standards compliant) HTML rendering engine in it. So where your nicely crafted HTML email might look great in Outlook 2000, it now looked awful in Outlook 2007 due to Word’s poor HTML support.

Things of the Microsoft front have remained quiet until now. William Kennedy, Corporate Vice President, Office Communications and Forms Team (long enough title?), made a post the Office team’s blog explaining that there would be no change to Outlook 2010’s HTML rendering and some reasons why the team chose to stick with Word. It’s all a bunch of bullshit.

We’ve made the decision to continue to use Word for creating e-mail messages because we believe it’s the best e-mail authoring experience around, with rich tools that our Word customers have enjoyed for over 25 years.

Why is he bothering to trumpet authoring capabilities when what this is really about is rendering? People craft emails in a lot of different ways, both inside and outside of Outlook. Is it handy that I could type up a nice formatted document with graphics, paste it into Outlook, and have it look the same? Yes, of course. However if Microsoft made Outlook and Word render standards compliant HTML correctly, you could still do that.

Word has always done a great job of displaying the HTML which is commonly found in e-mails around the world. We have always made information available about what HTML we support in Outlook; for example, you can find our latest information for our Office 2007 products here. For e-mail viewing, Word also provides security benefits that are not available in a browser: Word cannot run web script or other active content that may threaten the security and safety of our customers.

This paragraph is wrapped in so much spin that I’m dizzy after reading it. What he’s basically saying is that Word can handle <b>, <i>, <center>, <table>, and that’s about it. Guess what? Standards compliant HTML renderers also do a great job of displaying HTML commonly found in email! Using Word is more secure because it doesn’t run scripts? Bullshit! Thunderbird, which uses the same rendering engine as Firefox, simply turns off scripting in email. Ditto for Apple Mail (uses Webkit). Why can’t you do this with Internet Explorer, Microsoft?

We are focused on creating a great e-mail experience for the end user, and we support any standard that makes this better. To that end, Microsoft welcomes the development of broadly-adopted e-mail standards. We understand that e-mail is about interoperability among various e-mail programs, and we believe that Outlook provides a good mix of a rich user experience and solid interoperability with a wide variety of other e-mail programs.

Again, Mr. Kennedy seems to be focused on the authoring experience when this is more about rendering. On top of that, it assumes that everyone uses Microsoft products inside of a Microsoft environment. News flash; even people who live exclusively inside the Microsoft universe of products often interact with people who don’t. The words above are trying to say different, but they really aren’t saying anything.

There is no widely-recognized consensus in the industry about what subset of HTML is appropriate for use in e-mail for interoperability.

Why do we need a consensus specifically for HTML email? HTML already has a standard! Use that! If Mr. Kennedy welcomes these standards, why don’t they try to be proactive about it instead of giving their customers what amounts to a downgrade? Contact this Email Standards Project and strive for a more (for lack of a better term) bi-partisan effort.

The biggest problem here with Outlook using Word’s rendering engine is for people authoring email that is viewed in Outlook. Anyone who is in charge of their company’s email campaigns can attest to the frustration of trying to craft a message that looks good in the most commonly used email clients (it’s not possible to please everyone). It’s especially punctuated by the fact that Microsoft seems to be one of the only ones lagging behind. Thunderbird, Apple Mail, and most webmail clients support much more HTML and CSS in a more standards compliant way than Outlook does. On top of that, Microsoft seems to be denying that there is a problem in the first place. If the thousands of tweets are any indication, there is a problem Microsoft. Step up and join the conversation, work with not only the Email Standards Project, but also others in forming a standard.

This post was inspired by a blog post from: Ben Ward. Some of the arguments he makes I’ve reused here.

If you’ve got a great idea for the next big web framework, the first thing you should do is not write a douche-y blog post bashing other web frameworks. Here’s some ideas for things you could do instead:

• You could make a website promoting the advantages of your framework over other existing frameworks.
• You could improve the framework itself.
• You could document the framework so that others can easily begin using it.

The point is by attacking others, you don’t accomplish anything other than branding yourself as a grade A asshole. It’s fine if programming in C and doing all that memory allocation, dealing with pointers, and calling functions validates your skill as a programmer. I happen to like Ruby because I don’t have to do those things. What’s great is that we can co-exist. You can have your fast framework written in C and serve thousands of pages a second. I’ll stick to my ’slow’ framework written in Ruby. Chances are the people visiting the sites will never know the difference anyway.

Drop the ego. Realize that there can be more than one approach to solving a problem and yours isn’t always going to be the best one.

It seems that the Rails core team is so busy building awesomeness into Rails that they don’t have much time to improve the documentation. This is why docrails was started. The new Rails Guides are immensely helpful, and quite the improvement over the old wiki. However, you’ll still find a few surprises if you dig around in other people’s code like this handy feature I’ve found in ActionMailer.

ActionMailer let’s you specify the from address on emails sent out, but did you know you could also set a nice name in addition to that? You might have a basic mailer method like this.

  def my_email(to_email, to_name)
    from 'myname@example.com'
    recipients to_email
    subject "Hello There #{to_name}"
    body(:to_email => to_email, :to_name => to_name)
  end

We pass in an email address to send to and the person’s name. The from name is simply hardcoded as a string. If that email showed up in your inbox, it would probably say it’s from myname. Depending on the email client, it may just show the address it came from. That’s great, but it doesn’t look very nice.

Enter the undocumented syntax I’ve stumbled on.

  def my_email(to_email, to_name)
    from 'My Pretty Name <myname @example.com>'
    recipients to_email
    subject "Hello There #{to_name}"
    body(:to_email => to_email, :to_name => to_name)
  end</myname>

All you need to do is add the name you want to appear in the from field before your email address, then add a space, and finally wrap the email with angle brackets. That’s it! Now when your email arrives in someone’s inbox, it will show that it’s from My Pretty Name.

The syntax leaves a bit to be desired in my opinion. It doesn’t feel very Rails-y or even like the rest of ActionMailer. When specifying the recipients in ActionMailer for example, you can pass in either a single email address as a string or an array of string email addresses. The syntax should be similar with the from name and address. Here’s my proposed syntax.

  def my_email(to_email, to_name)
    from ['My Pretty Name', 'myname@example.com']
    recipients to_email
    subject "Hello There #{to_name}"
    body(:to_email => to_email, :to_name => to_name)
  end

Seems like a logical addition, eh? Pass in the from name as the first item in an array and the email as the second. Using a hash instead would also be acceptable. Maybe I’ll dig into Rails and submit my first ever patch.