The main reason why I cared is not because I’m a diehard soccer fan, but because we just expected to be able to watch the games. Live. Wherever we were at that moment. In good quality. With good audio (vuvuzelas notwithstanding). And a host of other features to keep us interested. And we did. Online. Over the phone. It’s amazing how quickly we’ve come to expect that we can consume a live event of the magnitude of the World Cup online. I mean – that is cool.

But does it matter to your business? How does this relate at all? In some ways, of course, it doesn’t. Sports have been a driver for many of the mega-events in recent online video history, primarily due to the nature of the events themselves. But outside of the media world – what does this mean for your online video strategy:

Go global. If your company has a global presence this event certainly confirmed what you may already know….that audiences around the globe have the capability and desire to consume online video. But don’t just throw anything out there. Make sure you provide the proper translations and content to fit the needs of the region you are targeting.

Interactivity = engagement. The majority of the implementations had a high level of interactive features woven into the experience. The ESPN3 player allowed the ability to switch between games, languages, get stats, chat with others. It’s not just about providing the moving pictures. The ability to customize players with interactive details and hot spots is growing quickly and provides many businesses with the ability to create more engagement and calls to action towards your ultimate business goal.

Be where your users are. The success of online video with an event like the World Cup hinged directly on providing fans the ability to get their fix wherever they were – at work, on the road, at home. This means thinking not just about video on your website but also how to syndicate your assets externally and how you might leverage mobile platforms to deliver your message to your users.

1. Generating the app

> rails new sprinter --database=mysql

> cd sprinter/

> rm public/index.html

> rm public/images/rails.png

> git init

> git add .

> git commit -m "Initial creation of the Sprinter app"

> mate .

As you can see, I didn’t even think about a .gitignore file.  Since the Rails community has fully embraced git as the source control system of choice, Rails 3 provides a default .gitignore file for you.

Side note: if you haven’t gotten up to speed on using git yet, you should.  GitHub has a nice crash course.

2. Configuring the app

The first place to start is the Gemfile.  This is the new place to declare all your gem dependencies (it used to be in “config/environment.rb”, which, by the way,  is now “config/application.rb”).    Once you open it up, you’ll see it’s pretty much the same as how you declared gems in environment.rb, except you wont be typing “config” over and over.

Here’s the Gemfile I use for this project:

source 'http://rubygems.org'

gem 'rails', '3.0.0.beta4'

gem 'mysql'

gem 'mongrel'

group :test do

  gem "shoulda"

end

Normally, I would include a few more gems here (specifically: HAML, friendly_id, authlogic, and paperclip), but this is just a quick starter app, so I omitted them for now.  I included “shoulda” in the test group simply to illustrate how to include gems purely for a test environment.  Plus, you should be using shoulda.

3. Bundler

Now that the gems are defined, I can use Rails 3’s new bundler to make sure all required gems are installed.  This is how you can guarantee every system is using the right gems for the project.  It’s similar to requiring gems in environment.rb, but bundler allows you to package the gems in the deliverable.  Also, bundler is far smarter than the previous system.  Previously, gem dependencies were read linearly out of config/environment.rb which had the propensity to cause issues.

For example, consider the following scenario.

Since you have version “1.2.4″ installed, the “>= 1.2.3″ requirement would use the version “1.2.4″ installed on your system (because it is the latest, greatest version).  However, when it later reads that version “= 1.2.3″ is required, it fails since it already loaded version “1.2.4″.   It’s an edge case, but Bundler will prevent this from happening.

Anyway, I got a bit off subject there.  The next step is to use bundler to make sure all those gems are installed.

> sudo bundle install

You’ll see it fetch the correct versions of all the gems defined in the Gemfile.

4. Using jQuery

One of the best features of Rails 3 is that all the javascript is unobtrusive, thus being fairly framework-agnostic.  Since I’m a big fan of jQuery, and less so of Prototype, let’s swap in jQuery by doing the following:

Believe it or not, you now have everything you need to use jQuery.  To make things more seamless though, you should create file “config/initializers/jquery.rb”, and paste the following inside:

module ActionView::Helpers::AssetTagHelper

  remove_const :JAVASCRIPT_DEFAULT_SOURCES

  JAVASCRIPT_DEFAULT_SOURCES = %w(

    http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js 

    rails.js

  )

  reset_javascript_include_default

end

This will include the Google CDN hosted jQuery (saving you some bandwidth and speeding up your pages) when you use the “:defaults” javascript include tag.

Side note: Because all the javascript is unobtrusive,  some of those fun helpers like “link_to_function” no longer exist.  However, “link_to_remote” still exists, but you call it as a regular “link_to” with “:remote => true” as an option.

It’s one thing for the framework to try and enforce unobtrusive javascript, but we should also set up our code to enforce it as well.    At this point, I usually create the following helper methods in “app/helpers/application_helper.rb”:

def stylesheet(*args)
  content_for(:stylesheets) { stylesheet_link_tag(*args) }
end
def javascript(*args)
  content_for(:javascripts) { javascript_include_tag(*args) }
end

These functions help me group all the stylesheet and javascript includes together.  With that, I then update the application layout file like so:

<!DOCTYPE html>

<html>

<head>

  <title>Sprinter</title>

  <% stylesheet :all %>

  <% javascript :defaults %>

  <%= yield(:stylesheets) %>

  <%= csrf_meta_tag %>

</head>

<body>

  <%= yield %>

  <%= yield(:javascripts) %>

</body>

</html>

Another side note:  Rails 3 spits out pure HTML5.

Moving the javascript include tags to the bottom does several things:

5. Rails 3 Routes

Now that all the required gems are installed, we’re ready to roll.  I like to start by creating a simple “Welcome” controller for the app.  One thing to note is that all the Rails 2 “script/” commands are now part of the “rails” command.

> rails generate controller Welcome index

Followed by an update to the “config/routes.rb” file to set the “welcome” controller as the root of the project.

root :to => "welcome#index"

In Rails 2, you would have declared the same thing with something like:

map.root :controller => 'welcome', :action => 'index'

Rails 3 routes are built to be  more extendable and require a lot less typing (notice the “controller#action” naming convention).  Let’s make sure everything’s working:

> rake db:create

> rails server

The site should now be visible at “http://localhost:3000″.  When you’re satisfied, stop the server with Ctrl+C.

6. Scaffolding

So far, I think this is a great starting point for quickly getting up and running on a new Rails 3 project.  However,it really doesn’t do anything yet.    So, let’s make it into a simple blog.

> rails generate scaffold Post title:string body:text published:boolean

This looks pretty standard, but a few key things have changed for Rails 3.  One, the scaffold generates a “_form.html.erb” partial instead of repeating the form in the “new” and “edit” views, making things much DRYer.

This also sets up the routes like so:

resources :posts

Just to close the discussion on routes, consider if posts belonged to a user and also featured a “comment” action.  We could set the routes up like so:

resources :users do

  resources :posts do

    member do

      get :comment

    end

  end

end

Pretty clean, isn’t it?

Anyway, back to the app.  Let’s see how things are working.  Run:

> rake db:migrate

Starting the server and checking out “/posts” gives you the standard Rails scaffolding page.  All is good here.

7. And finally, Arel

Now I can introduce my favorite part of Rails 3: Arel.

In a nutshell, Arel is an ORM-agnostic framework based on Relational Algebra (what the SQL language is based on).  I’m sure I’ll be blogging about it in far more detail shortly, but it essentially allows you to make all your Rails queries chainable (much like “named_scope” in Rails 2 – in fact, it was written by the same guy).

Open up app/controllers/posts_controller.rb and we’ll give it a shot.

In the “index” action, you can see that it grabs the blog posts in the standard Rails way:

@posts = Post.all

Normally, to only show the latest 25 published posts, we’d change this to be:

@posts = Post.all(:conditions => { :published => true }, :limit => 25, : order => "posts.created_at DESC")

With Arel, we can make this awesome by writing it as:

@posts = Post.where(:published => true).order("posts.created_at DESC").limit(25)

You should notice that, apart from a new naming convention, there is one major difference:  in Rails 3, we don’t call “.all”.  This is by choice.  We could call .all on that line and everything would work as expected (and in some cases, you want to call it).  However, calling “.all” forces the query to be run immediately.  But, thanks to Arel, if we leave it off, the query is only run when we actually use the data.

So, our query is only run when the view hits:

<% @posts.each do |post| %>

...

<% end %>

I don’t know about you, but I think that’s awesome.  It’s cleaner, and far more extendable.  For example, say we wanted to have a toggle switch for published and unpublished posts.  Our “index” action could be something like:

@posts = Post.order("posts.created_at DESC").limit(25)

if(params[:draft])  

  @posts = @posts.where(:published => false)

else  

  @posts = @posts.where(:published => true)

end

Gorgeous, isn’t it?

Well, that’s it for now.  I hope this post helps you hit the ground running with Rails 3.  I’ll be sure to post more about Rails 3 as I discover it, but so far, I’m extremely excited about it.  I hope you feel the same way.  Leave your thoughts/gripes in the comments.

These posts are the best posts I’ve seen yet on the subject, with real, nitty-gritty details about implementing I-AP.

Executive summary: 1 FTE for 1 month to convert an existing, fully operational app to one enabled for in-app purchases.

While the full list of iPhone OS 4.0 features is yet to be publicly disclosed, there are a number of iPad OS features (referred to by Apple as “iPhone OS 3.2″) that could conceivably show up on our iPhones in the future.  Some examples:

• The ability to email an app-specific file to a friend, and have them open it up on their own device in the proper app (Document Support)
• The ability for an app to generate a PDF with text and images (PDF Generation)
• The ability to easily move app-specific files back and forth from your mobile device to your laptop (File Sharing Support)

None of these features is earth-shattering in its own right; certainly it would be possible to accomplish any or all of these behaviors today by using the iPhone app as a “thin client”, and pushing the hard work like generating PDFs, sharing documents, and managing files up to a web app server.

What is significant about having these capabilities on the device itself is how much easier it will be for developers to build apps that enable these behaviors, and for consumers to adopt them:

• App Developers won’t have to lease a server and pay bandwidth fees to enable these types of apps
• App Developers won’t have to leave the comfort of their chosen programming language and tools (XCode / Cocoa)
• Consumers will be able to leverage familiar collaboration and file management paradigms like email, attachments, and copying files to and from the desktop

Most apps today are focused around consumption – consuming content, data or interactive entertainment for a short period of time, and then closing the app.  Features like those above could enable creation and collaboration behaviors – where the activity spent in the app yields some tangible artifact, which can be exported, transformed, or shared with other app users.

The possibilities exposed for consumer apps are intriguing, but the biggest impact may be felt in the enterprise arena – where creation and collaboration are more fundamental to day-to-day operations.  This is a point that others have pondered with the iPad, where the large touchscreen presumably makes it a better fit for content creation.

Definitely will be an interesting area to watch.  Please comment if you’ve heard of particularly clever mobile collaboration apps in the enterprise.

Techcrunch just wrote a great article on how we’re shifting away from pages and into streams.  I think the article raises a great point that this is a huge opportunity for start-ups to really change the status quo and start developing applications that work in real time.

So, the question I would raise is how can your company shift it’s products toward a real time web?  Think about the big internet brands and what would happen if they had to live in the real time web.  What if companies like Amazon, Ebay, and Google had real time services?  We also know that every time our economy has gone through a shift, new companies and ideas emerge that make us re-think our perception of the web.  In other words, if you’ve got an idea for the real time web, this is your chance to go out and build it.

From a time perspective (you have to exclude RegOnline because it was a nights a weekend project) it takes on average about 5 months to launch one of these applications and you need roughly 3 or 4 engineers to get it done.  My guess is that most of these companies boot strapped their development but current estimates say developing a web application costs anywhere from 50k to a few hundred based on complexity.  It’s also great to see these rapid development frameworks, such as Ruby on Rails, are accelerating development and time to market.

Lastly, I would also emphasize their focus on business processes. Many early stage companies completely neglect support needs, such as returns, customer compliants, etc.  It can end up costing you a lot of time and money if you don’t have systems on the back end to handle customer support issues.

The Grails release in particular is significant as the framework has finally emerged from "in development" status which removes one more barrier for web project teams and IT departments to using the framework.  We’ve had success with the Grails framework particularly due to the fact that it sits very well in the Java enterprise ecosystem, including the relatively straightforward integration of existing Java-based Hibernate models.  This integration with Hibernate, which is a key factor in Grails’ ability to be a contender for new IT projects with teams that are Java EE and Spring/Hibernate-oriented, is a fairly straightorward process that involves dropping in your existing mapping XML and Java POJOs.  As if by some magic, you get all the benefits of GORM on your existing Java POJO data model, including dynamic search methods and the criteria builder DSL.

• Groovy on Grails 1.0: http://grails.org/1.0+Release+Notes
• Groovy/Grails Zone on DZone: http://groovy.dzone.com/
• Ruby on Rails 2.0: http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

First things are always first, and in the spirit of blogging as a new form of journalism (not http://en.wikipedia.org/wiki/New_Journalism) let’s get the main questions that any reporter would ask out of the way:

Who

We’re a new boutique internet technology shop specializing in whatever it takes to effectively produce web things (see About section).

What

What do we do? Well, sometimes it involes banging our heads against the wall, but at the end of the day we make great web sites and applications using best of breed practices and technologies (yes, you can read Web 2.0 in there).

When

We’ve been doing this for over 15+ years combined, but the blog starts today.

Why

We often ask ourselves that same question, but in the end, we love what we do!

How

Using some of these: agile methodologies, iterative design and development, rapid development frameworks and lots of testing.

In the process of doing what we do, we end up figuring some things out, and as part of the open source credo of “share what you know” (which sometimes comes in the form of “patch it if it’s broken”), we decided to start blogging about our little victories against buggy code. We hope that you find at least something that we’ve written here useful, and who knows, maybe someday we can do business together.