Flash Player 10 Mobile for iPhone?

I was viewing the video of the Day 1 Keynote by Mark Anders at 360Flex where he made a reference to a mobile Flash application build in Flex. Mark just skinned a desktop app which turned in into a very iPhone like application which just happen to have the iPhone screen dimensions and behavior. It's 56 minutes in the presentation. Check it out and let me know what you think. I've included a video extract here after (without the sound): <script src="http://www.apple.com/library/quicktime/scripts/ac_quicktime.js" language="JavaScript" type="text/javascript"></script> <script src="http://www.apple.com/library/quicktime/scripts/qtp_library.js" language="JavaScript" type="text/javascript"></script> <link href="http://www.apple.com/library/quicktime/stylesheets/qtp_library.css" rel="StyleSheet" type="text/css"/> <script type="text/javascript"> </script> <noscript> <object width="246" height="385" classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B" codebase="http://www.apple.com/qtactivex/qtplugin.cab"> <param name="src" value="http://onrails.org/files/20080827_flexiphoneskin_action-poster.jpg"/> <param name="href" value="http://onrails.org/files/20080827_flexiphoneskin_action.mov"/> <param name="target" value="myself"/> <param name="controller" value="false"/> <param name="autoplay" value="false"/> <param name="scale" value="aspect"/> <embed width="246" height="385" type="video/quicktime" pluginspage="http://www.apple.com/quicktime/download/" src="http://onrails.org/files/20080827_flexiphoneskin_action-poster.jpg" href="http://onrails.org/files/20080827_flexiphoneskin_action.mov" target="myself" controller="false" autoplay="false" scale="aspect"> </embed> </object> </noscript> That's when he changed the skin:

Porting xgps to Qtopia for the Freerunner

I was getting bored waiting for Trolltech to release the next version of Qtopia for the Freerunner, so I ported the xgps client from gpsd's distribution to Qtopia.

As you may know by now, Qtopia does not have X11 so none of the existing X11 based or GTK based GPS clients work. I was exploring GPSD because I wanted to to be able to get a one time position for my sunset calculator which requires your current latitude and longitude. Although GPSD is not well suited for that (thats a whole other blog entry), I did notice you can connect to it over the ethernet, so I was playing with cgps and xgps that you find in the GPSD tar file, running on my desktop, talking to gpsd running on my Freerunner.

So wanting to dust of my Qt skills (which were so ancient I barely even recognize Qt4) I decided to port xgps to Qt.

I first did a pretty straight forward port to my Desktop Qt4/X11.

I designed the form using designer, then plugged in the code taken as closely as I could from xgps. This was not 1:1 by any means as XLib and Qt are not similar ;) I ended up just taking the ideas and algorithms from the xgps program and recoding.

So that took a day or so, as I was relearning Qt as I went, I have to say the documentation for Qt is excellent, unlike another graphics library I could mention (I'm looking at you GTK).

I got the basics working, and as my GPS fix inside was not very good (works about 50/50), I found you could also point any gpsd based client at gpsd.rellim.com and always get good data from there, this is great for testing.

So I had qtgps (for want of a better name) running on my desktop, looking pretty much the same as xgps, with the satellite list the sky view and of course the basic Fix data.

Now the trick to port it to FR, so I could run this on my FR.

The UI wasn't going to fit on the FR screen so I revamped the UI in Designer, by basically dragging all the views into a tabbed frame. So the satellite list, the sky view, the position information and the movement information all had their own tab, this fits pretty well on a tiny screen.

Other than that I didn't have to do much. I had to create a new qtgps.pro file for Qtopia, as the qmake qt one is somewhat different. I had to use the skeleton main.cpp that all Qtopia apps seem to use, but the bulk of the code remains the same.

I did have an interesting time trying to figure out how to emit a signal from the gps callback thread to the main window, not sure if I chose the right way to do it but it worked... I created a singleton QObject based class, and allowed it to be called statically, then that does the emit. This is used to signal the main display thread that new gps data has arrived. (Note this won't work if the singleton can be called concurrently from multiple threads, Google c++ singleton pattern to see how to do that).

// Singleton for sending signal from a callback
class ExtSig : public QObject
{
    Q_OBJECT
    public:
        static ExtSig *self();
        void send(struct gps_data_t* p, char* buf);

    signals:
        void sendit(struct gps_data_t* p, char* buf);

    private:
        ExtSig();
};

// Singleton defns for emiting a signal from a callback
ExtSig::ExtSig(){}
ExtSig *ExtSig::self()
{
    static ExtSig inst;
    return &inst;
}

void ExtSig::send(struct gps_data_t* p, char* buf)
{
    emit sendit(p, buf);
}

// in callbeck call...
// signal the GUI thread we have new gps data
    ExtSig::self()->send(p, buf);

Ok so how can you write your own Qtopia applications? There are at least two ways, 1) use the VMPlayer based Toolchain that Trolltech provide, or 2) setup your Linux workstation to use the toolkit. 1) is easier, and just works on pretty much anything that runs VMPlayer and has a lot of memory. 2) is faster and used less memory. I chose 2) but I did play with 1).

I won't go into how to do 1) as it is pretty much straight forward, just download the iso, and install it (either from a loopback device or from a burned CD).

The second method is not so well documented (if at all) so here is what I did to make it work on a Ubuntu Hardy i686 32-bit workstation with KDE installed..

Download the toolchain and install it into /opt/toolchains, it seems it must be there otherwise it doesn't quite work.

Then download the latest qtopia snapshot and put that in a working directory and set QTOPIADEPOTPATH to that directory.

Then create a build directory for the qtopia build and set the QPEDIR environment variable to that path.

In my case I have QTOPIA_DEPOT_PATH=/opt/QtopiaSDK/qtopia-opensource-src-4.3.2-snapshot-20080815 and QPEDIR=/opt/QtopiaSDK/build/qtopia-4.3.2

Now we need to build the qtopia snapshot, you can use the result to copy to /opt/Qtopia on your FR, or not, but you need to do this to get the tools to build your own apps.

Now follow these steps to build Qtopia:-

> cd $QPEDIR
> $QTOPIA_DEPOT_PATH/configure -device ficgta01
> make
> make install

Go get some coffee or Dinner :) this will take a while.....

Now you will have a full Qtopia build in $QPEDIR/image

You can use the following script to copy this to your FR, it is modified from Trolltechs update script. It will keep your settings. However you will have needed to have flashed to the 0808 version of Qtopia and kernel for this to work.

#!/bin/sh
QTOPIA_DIR=$QPEDIR/image
QTOPIA_IMAGE=qtopia.tar.gz
PHONEIP=192.168.0.200
# sudo ifconfig usb0 192.168.0.200 up

tar -C $QTOPIA_DIR czvf $QTOPIA_IMAGE
cat $QTOPIA_IMAGE | ssh "root@$PHONEIP" '(set -x;rm -f /tmp/restart-qtopia;killall qpe; mkdir -p /opt/Qtopia;rm -rf /opt/Qtopia/*; cd /opt/Qtopia;gunzip |tar xvf -;/etc/init.d/qpe start &)'

Whether you do that or just keep the Trolltech released image you are now ready to write your own apps. I recommend you study the Qt docs Qtopia is pretty much Qt4.3 at the moment.

As an example you can use the qtgps.tar.gz as an example app or use $QTOPIA_DEPOT_PATH/examples/application

I created a build/myapps directory, and then tar xvfz qtgps.tar.gz into that directory. Then...

> cd build/myapps/qtgps
> $QPEDIR/bin/qtopiamake
> make

This will create a qtgps excutable that you can copy to your FR and run.

A nice trick I found is to run a GUI app from the ssh into FR you can do this...

> ssh 192.168.0.200
> . /opt/Qtopia/qpe.env
> ./qtgps

The app will popup on the FR screen, you could also run it from the terminal on the FR or from the file manager on the FR.

To create a new application you can do this..

> cd build/myapps/mynewapplication
> ... edit some .cpp and .h files
> $QPEDIR/bin/qtopiamake -project
> ... edit mynewapplication.pro appropriately
> $QPEDIR/bin/qtopiamake
> make

The skeleton main.cpp should look like this...

#include "mynewapp.h"
#include <qtopiaapplication.h>

QTOPIA_ADD_APPLICATION(QTOPIA_TARGET,MyNewApp)
QTOPIA_MAIN

The rest of the files are up to you. I like to create the UI using designer...

> $QPEDIR/bin/designer mynewapp.ui

look in either example.cpp or qtgps.cpp and qtgps.h on how to initialize a designer based UI.

There are lots of example apps on the Trolltech docs site.

If you want to run the app locally rather than on your FR, you can use $QPEDIR/bin/qvfb you will need to do this to make the size correct...

> export QWS_DISPLAY=QVFb:mmWidth43:mmHeight58:0
> $QPEDIR/bin/qvfb -width 480 -height 640 &
> sleep 2
> ./qtgps -qws gpsd.rellim.com

This will run qtgps on the local workstation in a simulation of the FR screen (without qtopia), using gps data from gpsd.rellim.com.

You can also run Qtopia in that screen but you will need to build a native version of qtopia to do that, in that case I would use the VMPlayer version of the toolchain as it has it all built in.

I haven't quite figured out how to build an ipkg of the Qtopia apps yet. Although this seems to work...

> make packages FORMAT=ipk

I can't install the resulting ipk with opkg. Qtopia likes to build qpk files and only install them over the internet, that would probably work and is how the VMPlayer version of the SDK does it.

Internationalization features in Rails edge

The development version of Ruby on Rails has cool new internationalization features. Although the framework itself doesn’t provide a lot of I18N functionality, it does provide the necessary hooks for plugins to implement I18N however they see fit. Simon Tokumine has written an I18N demo application to show you what Rails is capable of, when used in combination with the localized_dates plugin.

We’ve deployed the demo application at http://i18n-demo.phusion.nl/. Check it out.

Umbrella Today?

The Lone Star Ruby conference is about a week away. Chad, Jon, Matt, Tammer, Jared, and I will be running a training session on Thursday.

Our approach to teaching thoughtbot’s Rails Best Practices is to go through our development process for a real application called Umbrella Today?, which we began building two weeks ago. After each 45 minute lecture, we’ll give participants the chance to feel the process in 15 minute hands-on workshops.

The concept of the app is simple: enter your zip code, get a yes or no answer to the question “Do I need an umbrella today?”

Sign up to receive SMS alerts on days when you’ll need an umbrella.

Hidden complexity

Seems like a simple app, right? Famous last words. Simple enough to take from concept to launch in a few weeks there’s always hidden complexity until development begins.

For Lone Star purposes, we’re happy about the complexity. In addition to best practices like CI, TDD, MVC, and TLC, it gives us a chance to share many small but collectively powerful topics such as:

• attr_readonly
• Rails template to get things like Factory Girl “for free”
• modules vs. classes
• security bugs
• shoulda_macros directory
• timezones
• SMS
• rake tasks and cron
• confirmation codes that don’t suck
• the importance of database indexes

Lone Star to Boston

thoughtbot’s Ruby on Rails training formally kicks off October 14th in Boston. We’ll be building upon our Lone Star/Umbrella Today experience so if you can’t join us in Austin next week, come visit Boston, which is beautiful in the fall. I recommend making a week of it and staying for the Head of the Charles.

Note: register for Boston training by August 31st and get $100 off.

Interview: Nick Sieger on JRuby

In this interview recorded at RubyFringe, Nick Sieger talks about the future of JRuby, Java Integration, and his work on JEE deployment tools for Ruby on Rails like Warbler. By Werner Schuster

A Fresh Look at 'Technical Debt'

A Technical Debt Workshop was recently held to improve our industry's understanding of and approach to "technical debt", resulting in some interesting ideas. Among them, changing our perception of the problem to focus on "assets" rather than "debt", an idea now receiving quite a bit of attention by people such as Michael Feathers and Brian Marick. By Mike Bria

Ruby developers don't scale

Wow, it's been a while since I blogged. With all the cool kids saying that spending time reading RSS feeds is overrated (see Defunkt's keynote for instance) I even wonder if people will ever read this post!

Anyways, I have been quite busy preparing courses for classes I gave to a bunch a great Engineers at one of the Fortune 100 companies based in San Diego. I was also planning my big vacation trip to Europe and wrapping up few projects.

However, during my exile overseas, I came to the conclusion that Rubyists don't scale. Since Twitter became stable again, we don't hear many people ranting about Rails not scaling anymore. With one of my clients' app handling around 7 million requests/day I can tell you Ruby/Merb do scale quite well! But ruby developers don't seem to scale for some reason.

Maybe saying that we(Rubyists) don't scale isn't technically correct but that's basically what one of my client told me.

Let's go back in time a little bit and follow my client who we will call clientX.

• ClientX has a great concept and wants to conquer the internet.
• ClientX hears that Rails is the way to go.
• ClientX hires a contractor/mercenary/freelancer/guns for hire/consultant (aka Me)

• Me builds a killer app using Merb (killing framework)

• ClientX raises loads of $$$

• ClientX wants to hire a team because Me doesn't want to become a FTE

• ClientX and Me look for Rubyists wanting to relocate and get a decent salary

• ClientX *can't find someone they consider good enough and who would accept their package

• Many JAVA guys are available on location and accept lower packages

• Ruby app gets ported over to JAVA
• Me sad :(

So is it really the Rubyists' fault if we don't want to relocate and only accept higher packages? Should I blame Obie for telling people to charge more and teaching how to hustle? Or should we just tell clients that it's time to get used to working remotely?

Honestly, I don't think any of the above explanations are valid. Ruby is the new/hot technology and very few people have the skills and experience to lead major projects. These people make a good living and enjoy their "freedom" and dream of building their own products. Most of them/us value their work environment, family and are reluctant to move.

At the same time, companies do need people locally(at least a core team) and can't always afford the cool kids.

ClientX, quite frustrated by the whole hiring process told me once: "you Ruby folks are too unavailable and difficult to work with! We need a committed team that actually cares about the company/product."

That hurts when you worked hard on a project and just can't satisfy the client by finding guys willing to relocate and work for them. It gets even more painful when your code gets entirely ported over to JAVA!

But at the same time I understand ClientX's motivation, PHP guys are cheaper, JAVA guys are more available, why in the word did we go with Ruby and are now struggling finding people?

Once again, there is positive and negative side in everything, by choosing Ruby and a "great contractor" ClientX was able to catch up with the competition and even pass them in no time. They quickly raised good money and got everything they needed to become #1. I don't believe it would have been possible to do the same thing so quickly with JAVA for instance. However choosing a cutting edge technology means you need to look harder for talented people.

It's too bad the code gets rewritten in a different language but at the same time, I do my best to facilitate the process and to keep a good relation with my client. There was nothing personal in the decision, it's just too bad we were not able to keep on using the latest/coolest/awesomess technology available :)

To finish on a positive note, here is the solution to scale your Ruby task force provided to you by the #caboose wisdom:

Based on my conversations with other #caboosers who hire other devs, the word in the street is that you just need to get one or two great ruby guys (who will probably cost you a lot) and find a bunch of smart people to train. You'll end up with an awesome team of scalable rubyists ;)

Rails Envy Podcast - Episode #044: 08/27/2008

Episode 044. We've decided to stop living the lie and are just letting OS X system speech say all names for us from now on.

The Rails Envy podcast is brought to you this week by NewRelic. NewRelic provides RPM which is a plugin for rails that allows you to monitor and quickly diagnose problems with your Rails application in real time. Check them out at NewRelic.com.

Call Us! You can reach the podcast voicemail line at 407 409-8440.

Subscribe via iTunes - iTunes only link.
Download the podcast ~16:00 mins MP3.
Subscribe to feed via RSS by copying the link to your RSS Reader

• Yahoo's BOSS Web Service - Bossman Gem
• Ruby Hoedown Videos
• Ruby 1.9 Sandbox on Leopard
• Amazon Elastic Block Store
• JDBC Connection Pooling for Rails on Glassfish
• Neverblock and Neverblog PostGres w/ ActiveRecord
• whatlanguage gem
• Scripted GUI Testing with Ruby
• Agile Project Management Tools
• RSpec: It should behaive like
• Telling a good story - RSpec Stories
• Interview with DHH
• Rails has Continuous Integration
• How to fix your Rails Helpers

Making money off facebook

Here’s an article from VentureBeat waving about some figures about how much money can be made with Facebook apps. Although the figures are a bit anecdotal, and I hope for their sake that no VC’s ever invest based on such hand-waving mathematics, the real gem is at the end:

Either way, the many naysayers suggesting that it’s impossible to make money on Facebook might want to think again.

I don’t know if anyone’s ever suggested it’s _impossible_ to make money from Facebook. The main backlash against Facebook applications as a business model has really been against the gold rush mentality of the early Facebook app “golden age”. In those days, the mental processes went a little bit like this:

1. Facebook has lots of users
2. Facebook is inherently viral
3. If I make a Facebook application, it will be easy to reach millions of people
4. An application that can reach millions of people is bound to make money.

That’s a nice story, and it explains why some many people (myself included) rushed into Facebook application development last summer. Since then, most of them have pulled out, and for very good reasons.

1. Facebook became much more protective of its users (and quite sensibly). A large part of the changes to Facebook in the last years have been to protect its users from over-greedy and spammy applications
2. Many changes entirely nerfed the virality, making it much, much harder for an application to magically spread from 10 users to a million within a few weeks
3. Therefore, it’s become very hard to reach any large number of people on Facebook
4. Even applications that did benefit from the early “golden age” conditions didn’t manage to make that much money. Their business models are still being proven. Slide and RockYou may have a few very successful apps, but they also have many developers, and it’s unlikely that their Facebook revenues cover their costs yet (though I’d love to hear some hard numbers on that).

The truth is, yes, it’s possible to make money with a Facebook app. But, and this is the key, it’s no easier than making money with a non-Facebook app. In many ways, it’s harder. Working with the Facebook platform and its many limitations is a challenge in and of itself. Even if you’re a consummate start-upper outside of the Facebook bubble-world, you’ll have to learn application development all over again in this new, different environment. That’s not a huge deal, but it should give pause to people who think they can just “make a Facebook version” of their otherwise successful application.

More importantly, building a Facebook application puts you in the thrall of Facebook. That is a huge deal, because Facebook is their own business, and they will always do things to their own advantage, even if that involves doing something that will completely destroy your business. The internet is fickle enough as it is. Do you need the extra risk?

Deploying from a Subversion Tag using Vlad

On the Rails project I'm currently working on, the team decided to use Vlad for deployment. If you're not familiar with Vlad, it's just like Capistrano with 2 big architectural differences.

(1) Vlad uses the command line ssh client instead of using net/ssh.
(2) Vlad uses Rake for tasks, and Capistrano has its own task system.

Deploying from a subversion tag using Capistrano is pretty easy: all you have to do is set the repository to the tag you want to deploy from. We can use the same approach in Vlad, but we need an additional step.

Before we get there, the first step is to write a task to prompt for the tag to use.

namespace :vlad do
  task :set_repository do
    tag = Readline.readline("tag to deploy (or trunk): ")
    if tag == "trunk"
      set :repository, "http://repo/trunk/"
    else
      set :repository, "http://repo/tags/#{tag}"
    end
  end
end

We then need to make the update task depend on the set_repository task.

namespace :vlad
  remote_task :update => %w[set_repository]
end

Due to how Vlad checks out the code, there's one more step. Vlad makes deployments faster by having an scm directory where the code is checked out. It does a checkout to the scm directory and exports from there to a release directory. The problem is if we had previously deployed trunk, but are now trying to deploy a tag, Vlad will try to checkout the tag on top of the trunk checkout, which subversion complains about.

svn: '.' is already a working copy for a different URL

We can fix this by modifying the update task to do an svn switch on the scm directory.

namespace :vlad do
  namespace :svn do
    remote_task :switch, :roles => [:app] do
      run "if [[ -d #{scm_path}/.svn ]]; then cd #{scm_path} && svn switch #{repository}; fi"
    end
  end
  
  remote_task :update => %w[set_repository svn:switch]
end

The if statement is there so that this task doesn't fail on the very first checkout to the scm directory.

I looked through the code, but couldn't find a built-in way to make this easier. But perhaps I overlooked something. This is using Vlad 1.2.0.