• Sign in and out of Gmail
• Clear the cache and data for the Market App / Download App

I was not quite ready to perform a factory reset to sort this out, so I connected the phone over USB and ran adb logcat to get some pointers. I tried updating an app and saw this in the log output:

E/Volley ( 6766): [263] BasicNetwork.performRequest: Unexpected response code 403 for https://android.clients.google.com/vending/api/ApiRequest E/Finsky ( 6766): [1] 1.onErrorResponse: Error when attempting direct download of asset [com.linkedin.android]. Error=[com.android.volley.toolbox.AuthFailureError]

As this suggested some kind of authorisation failure I thought I’d check my account details. I opened up my google account settings page and noticed that I had 2 email addresses listed against the my account, and the account I was signing in as on the phone as was not using the primary email address. I added a new account to my phone using the primary email address and removed the old one. I then force-quit / cleared the data and cache files for the Market and Download Apps and tried to install an application again. This time the application download and installed just fine.

Changing over to the primary email address also fixed another problem I had with my contacts not syncing from my Google account.

1. Create a new Facebook application
2. Specify the icon, logo, canvas page, site url and domain
3. Wait a while to make sure the new app is rolled out over their servers
4. Generate your plugin code here using the id of your new application
5. Drop the code on your web page

For some reason although the generated code will display a live stream box, posts made through the box do not appear on Facebook!

After some trial and more error I eventually managed to track it down to the always_post_to_friends=true parameter in the iframe source URL. If you remove this, it springs into life and comments get posted to Facebook unless the user unchecks the box:

<iframe src="http://www.facebook.com/plugins/live_stream_box.php?app_id=109494315784346&amp;width=440&amp;height=300&amp;via_url" scrolling="no" frameborder="0" style="border:none; overflow:hidden; width:440px; height:300px;" allowTransparency="true"></iframe>


The code generator includes always_post_to_friends=true whether you choose this option or not, which is odd. The example on the page also doesn’t post through to Facebook if this option is selected. Perhaps the parameter is misnamed and should be never_post_to_friends=true. Perhaps it is some kind of permission problem. Anyone got this option to work?

1. Download the current stable version of the Aptana IDE
2. Launch the Aptana IDE (and choose a workspace location)
3. Install the Aptana RadRails plugin from the Aptana Start Page
4. Restart Aptana
5. Choose Window … Preferences, then Install/Update and enter the following policy url: http://update.aptana.com/update/rails/beta/3.2/policy.xml
6. Click Ok, and restart Aptana
7. Choose Help .. Software Updates … Find and Install then “Search for Updates of currently installed features”. If you expand the Rails plugin option you should see the following version listed: 0.8.0.200706111240
8. Install it.
9. I’m sure you could skip installing two versions of the plugin if you really knew the score …

The deadline is fast approaching, and Matthew and I have been coding hard to meet it. Last week we were discussing what seemed to be a fairly generic problem – what’s the best way to HTML escape content you put in the flash?

We turned up this answer via google, which suggests escaping it when you render it in your view, i.e.

<%=h(flash[:notice])%>

All well and good, but sometimes you want a mixture of HTML and user generated content in the flash, e.g.

Sinbad has sent you a message

So escaping the lot is not really an option.

One solution is to use render_to_string with a partial as shown below:

Controller

def index
  if current_user.messages.any?
    flash[:notice] = render_to_string :partial => 'message', 
      :object => current_user.messages.first
  end
  # rest of action ...
end

Partial

<%= h(message.sender) %> has sent you a 
<%= link_to "message", :controller => 'messages', 
  :action => 'show', :id => message %>

Layout

<div class="notice">
	<%= flash[:notice] %>
</div>

I imagine :inline would also work, if a partial for a flash message seems like overkill.

I fought off buying my MacBook Pro just long enough for the hardware problems to surface, but not quite long enough for them to be addressed. In retrospect I think I faired reasonably well: Sure the screen is bent, and so doesn’t sit flush when closed. OK the machine gets a bit toasty under load, but that’s kind of handy on a cold winter’s night. And yes, there is the annoying buzz when it’s idling on battery power. Essentially all minor faults which you might have expected to be weeded out during QA, but it was a first generation machine and so always a bit of a gamble.

Over the past year, numerous solutions to these various ills have emerged, preying on the insecurities of the betrayed early adopter Apple fanboys. Bear with me whilst I recollect this period of false hope.

The whine

Remember the saga of the SpeedIt kernel extension – promising an end to the processor whine, improved battery life and thereby entrance to paradise? SpeedIt development was sporadic and poorly communicated. Countless deadlines for the “next beta” were announced with much fanfare and then broken without a word, leading to tumultuous flame wars in the discussion forums. Those who dared question whether the developers could pull it off were attacked in case they dissuaded them from continuing their heroic work. There was the special license agreement, where registered users were asked to email the company boss on her birthday to say thanks for sponsoring this important work. Then finally, in a plot seemingly lifted from Home and Away, two core staff members were injured in a motorcycle accident. The emotional outpourings were reminiscent of another crash, and I have to say I tuned out at this point. Coming back to it now, I can’t find any trace of this snake oil at increw, although the source code is still available via their trac, development seems to have stalled.

The furnace

The SpeedIt guys did manage to provide a method to read the temperature of the Core Duo processor, and consequently MBP owners become even more aware of the inferno raging beneath their finger tips. This led the truly desperate to crack open their laptop and improve the thermal efficiency of the CPU+GPU heat sinks by carefully reapplying the thermal paste.

More recently a less invasive option has emerged, whereby you can run the fans more aggressively than the profile provided by Apple. Both Fan Control and smcFanControl allow you to accomplish this, no doubt allowing some proud MBP owners to use their built in keyboard for day to day use for the first time. Thankfully, although toasty, mine has never quite blackened flesh.

The contender

I think CoolBook first launched in late 2006. It’s angle was to lower the heat generated by the CPU by undervolting it. The general idea is that the voltage + frequency pairs that the CPU are set to operate at by Apple are chosen to be stable for as wide a sample of CPUs as possible. By tuning the pairs for your particular CPU, you may be able to run it at a lower voltage for any given frequency. This will cause it to generate less heat, and so hopefully result in a cooler system.

Although CoolBook is free to download, you can only experiment with its undervolting capabilities once you have paid the $10 registration fee. This was enough to put me off for 6 months, but I finally weakened – it’s cheaper than therapy after all, and has recently hit version 2, now boasting a new frequency throttling feature.

The manual recommends that you begin undervolting your machine by determining 2 base frequency/voltage pairs: The lowest stable voltage for the highest frequency, and the highest stable frequency for the lowest voltage. The process used to determine these was as follows: First set the frequency to the maximum for your machine (2GHz in my case), and then reduce the voltage to the lowest stable setting. Too low and you’ll get a kernel panic, so it pays to notch it down one step at a time. Once I thought I’d identified the lowest stable voltage, I ran at 10min CPUTest session, which loads the CPU presumably by carrying out a number of processor intensive calculations with known results. I had to edge the voltage up a few steps to get the tests to complete successfully. My lowest stable voltage for the highest frequency result was as follows:

Default and lowest stable voltage for the highest frequency

So a reduction of 0.125V (9.9%) from the default setting. The next step is to find the highest stable frequency for the lowest voltage. Setting the voltage to 0.95, I edged the frequency up a step at a time, following a similar process to before:

Default and highest stable frequency for the lowest voltage

This time I’m able to run clock the CPU 50% faster than the Apple default at the lowest available voltage. Seems pretty good, but what difference does it make to my every day work activities?

Temperature

Having identified these two pairs, I plugged them into the Mains Adapter profile setting and chose the medium throttle setting. This would cause the machine to idle at the lower setting, but ramp up under load:

Adapter profile used for temperature comparison

To see what difference this made to the operating temperature when connected to the mains, I ran some real world tasks and recorded the temperature profile and fan speed over a 5 minute period once they had stabilised. For comparison I performed the same tasks with the “Normal” energy saving profile in system preferences with CoolBook disabled:

Average temperature and RPM under various loads

These results suggest that undervolting the CPU does result in a cooler system. For the Java unit test suite the temperature difference is 1.8°C, but the fans are spinning ~500RPM slower. For the Rails tests the fan speeds are similar, but the CPU temperature is 3.9°C lower. It’s worth remembering that when under load the machine will still be running at 2GHz so there should be little difference in performance between the two, although I didn’t try to confirm this.

Battery Life

The CoolBook documentation suggests that battery life might be extended by locking the CPU to the lowest voltage + lowest frequency pair, in my case 1002MHz/0.9500V. To see what impact this would have on battery life, I performed my daily Rails development chores, interspersed with some web browsing and important client email digestion – bien sur. I recorded the time taken for a fully charged battery to run down with the normal energy saving setting and CoolBook managing the processor throttling. Each setting was repeated twice, and the times averaged:

Average battery life in the salt mine

So no improvement in terms of battery life, which seems a little disappointing but may just be because my daily activities don’t cause enough load to step up the CPU for significant amounts of time. No doubt I could load the machine up and see how quickly it ran down in each case, but for me that result is not of interest, since it doesn’t reflect my real world use.

Conclusion

After investing an hour or in locating the base frequency/voltage pairs for my CPU, I was able to reduce the temperature of my MBP under load by up to 4.0°C. In some circumstances the fans also ran slower, and noticeably quieter. Sadly I had no luck in extending the battery life beyond 2.5 hours, ho-hum!

Buoyed by my new found productivity, released from my shackles of indecision (which MVC framework? What about transactions? How will this work in a cluster?) I could just jump right it and get on with building the site. Every line of code was going to the customer. No need to worry about the tricky stuff, it’s a full stack framework and there’s a plugin for everything.

But what has working with Rails done for me, as a former Java developer? Well the project timescales are generally tighter and the work productive yet stressful. But these are subjective measures, what about the cold, hard cash?

Figures are 3 month averages, source

I’ve included a variety of technologies which fit within the web development domain because I’m conscious that there aren’t that many Rails jobs listed. The lower salary may just be a result of lower demand – I don’t have any numbers for the supply side of the equation. Currently Rails does seem to sit more towards the PHP rather J2EE end of the salary scale.

Less filthy lucre == less snowflake moments

At the moment, Rails is great if you are in the product development business and you want to get Wet Dream 2.0 to market on a budget. It’s great if you’re a small company aggressively bidding to win work at open tender. It’s great if you are a lot smarter than me, on the lecture circuit with a cool blog and a bunch of plugins under your belt.

But if you are an average Joe Coder, choose wisely. Perhaps ruminating over application architecture decisions and marshaling endless XML files was overpaid – or maybe “convention over configuration” makes web development easier, and cheaper. Either way I’d better raise my game: If I’m going to install acts_as_french_fries I at least want to have written it.