See last week post here.

May 28 – June 4, 2009 Edition

There have been 23 commits in the master branch.

• CPEvent gets some optimization for mouse event handling. The commits : here and here.
• CPJSObjectCreateJSON and CPJSObjectCreateWithJSON have been deprecated. You now have to use : JSON.stringify() and JSON.parse() instead. The commits : here and here.

As mentioned in an earlier post, Cashflow App is now hosted on Heroku.

The main repository for my code is still hosted on Github. This is where I manage/version it.

When you create an application on Heroku, it is automatically associated with a git repository hosted on Heroku. Deploying changes to your application is as simple as pushing your code to the associated git repository.

Here is a schema of what I want to achieve :

In this post, I will explain how I use Github to version my code and Heroku to deploy it, with 2 different environments. You may also read this article that explains how to deploy your application on Heroku and this one that also explain how to deal with multiple environments.

Setup different environments on Github

On Github, I want to work with 2 branches : a master branch for production and a staging branch for testing. The master branch is what you get when you first clone your repository :

git clone git@github.com:account_name/repository_name.git
cd repository_name
[master]$

To create a staging branch, just do :

[master]$ git checkout -b staging
Switched to a new branch "staging"
[staging]$

Then push your local staging branch to Github :

[staging]$ git push origin staging
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:account_name/repository_name.git
* [new branch]      staging -> staging
[staging]$

You should now have 2 branches on Github

Create the Heroku Staging App

Now, I will create a Staging app on Heroku. This will create a git repository. I will only push code to this repository when I want to deploy modifications to the Staging app.

[staging]$ heroku create myapp-staging --remote heroku-staging
Created http://myapp-staging.heroku.com/ | git@heroku.com:myapp-staging.git
Git remote heroku-staging added
[staging]$

You’ll notice that I specified a custom remote name : heroku-staging. It will allow you to specifically deploy your code to the Staging app.

Your .git/config file should now look like this :

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[remote "origin"]
url = git@github.com:account_name/repository_name.com.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[remote "heroku-staging"]
url = git@heroku.com:myapp-staging.git
fetch = +refs/heads/*:refs/remotes/heroku-staging/*

Create the Heroku Production App

Go back to the master branch :

[staging]$ git checkout master
Switched to branch "master"
[master]$

Create the heroku prod app :

[master]$ heroku create myapp-prod --remote heroku-prod
Created http://myapp-prod.heroku.com/ | git@heroku.com:myapp-prod.git
Git remote heroku-prod added
[master]$

Your .git/config file should now look like this :

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[remote "origin"]
url = git@github.com:account_name/repository_name.com.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[remote "heroku-staging"]
url = git@heroku.com:myapp-staging.git
fetch = +refs/heads/*:refs/remotes/heroku-staging/*
[remote "heroku-prod"]
url = git@heroku.com:myapp-prod.git
fetch = +refs/heads/*:refs/remotes/heroku-prod/*

Deploy the Staging app

The Staging app on Heroku is linked to the heroku-staging remote. You’ll want to push the code from your staging branch to the heroku-staging/master branch, as show in the first schema :

[master]$ git push heroku-staging staging:master
...
To git@heroku.com:myapp-staging.git
* [new branch]      staging -> master
[master]$

staging:master means that you push your staging local branch to the master remote branch. Here, the remote branch is heroku-staging, which is linked to the staging app.

Migrate the staging db :

[master]$ git checkout staging
Switched to branch "staging"
[staging]$ heroku rake db:migrate --app myapp-staging

Deploy prod app

[staging]$ git checkout master
Switched to branch "master"
[master]$ git push heroku-prod master
...
To git@heroku.com:myapp-prod.git
* [new branch]      master -> master
[master]$

Migrate the prod db :

[master]$ heroku rake db:migrate --app myapp-prod

Make some changes in staging and deploy them

First, switch to the staging branch, and make your changes.

[master]$ git checkout staging
Switched to branch "staging"
[staging]$ make your change
[staging*]$ git commit -a -m "test staging modification"

Then push your modifications to the staging branch on Github :

[staging]$ git push origin staging

Finaly, deploy your modifications to the heroku staging app

[staging]$ git push heroku-staging staging:master

Make some changes in production and deploy them

Switch to the master branch, and make your changes.

[staging]$ git checkout master
Switched to branch "master"
[master]$ make your change
[master*]$ git commit -a -m "test production modification"

Then push your modifications to the master branch on Github :

[master]$ git push origin master

Finaly, deploy your modifications to the heroku prod app

[master]$ git push heroku-master master

Feel free to comment this solution and to share your tips here.

See last week post here.

May 21 – May 27, 2009 Edition

There have been 20 commits in the master branch.

• CPPanel is in the pipe. The commit : here.
• Theme improvement. The commits : here, here, here, here and here.

For those of you who were asking, here’s a quick update about the Cashflow App development.Things are going well, we took some infrastructure decisions, the presentation Website and the logo are almost done, we’re refining the UI and we hope to have something to show at WWDC in 12 days.

About infrastructure

Initially, both Cashflow App’s servers (Staging and Production) were 256Mb slices hosted at Slicehost set up with Ubuntu Machine. And then, a few weeks ago, we heard about Heroku announcing their commercial launch.The timing was perfect and Heroku’s technology seemed too interesting not to give it a chance. After some initial testing, I’ve migrated the 2 slices to 2 Heroku applications (Staging/Production). Even though Heroku offers git repository hosting, I do prefer to keep things separated, so the code is still hosted at Github. I’ll explain in a later post how I manage the different git branches with the different Heroku applications.

Talking about Github, we also migrated our issues from Lighthouse to Github, with this small piece of code I wrote some weeks ago. Github issues is a very simple and flexible solution that better suits our needs.

Presentation Website and Logo

We were lucky enough to work with a great designer who really understood our strong desire for simplicity. He did a great job with our logo and presentation Website.

You’ll soon be able to see it live and to signup for our beta release (we don’t have a date yet).

Features and User Interface

It’s interesting and hard at the same time to select the features that will made it to the first release.

Scott Stevenson, from Theocacao had this interesting quote : “Once you’ve come up with a UI concept for a 1.0 version, try to imagine how 2.0 would look and work better, and consider making that 1.0.”

Our aim for the first release is to provide a well thought app with a clean user interface and enough features and polishing so that people will find it useful and pleasant to use. We have many ideas about the app functionality, but we do not want to make too many assumptions before people really start to use it.

We are really excited about the early feedback we will receive.

A preview release at WWDC?

We are working really hard to try to have a preview release at WWDC on June 8th. We’ll first give access only to a few selected people, then we’ll send some beta invitations in batch.

In the meantime, follow us on Twitter : @cashflowapp or @tbalthazar to stay tuned.

See last week post here.

As you surely have noticed, Cappuccino 0.7 has been released. This means that 0.7 is now in the master branch.

May 14 – May 20, 2009 Edition

There have been 55 commits in the 0.7b master branch.

• CPBezierPath has been added to the repository. The commits : here and here.
• Support for radion buttons and checkboxes has been added. See Francisco’s announcement for more information. The commits : here, here, here, here, here and here.
• CPURLConnection now has support for app: protocol, for use with Titanium, and it’s delegate methods are now optional. The commits : here and here.
• The capp command gets some new options. Read Fancisco’s announcement for more info. The commits : here and here.
• HUD has been added to Aristo. The commits : here and here.

See last week post here.

May 7 – May 13, 2009 Edition

There have been 32 commits in the 0.7b branch.

• CPSegmentedControl has been added to Aristo. This class implements a horizontal button made of multiple segments. The commits : here, here, here, here and here.
• CPSecureTextField gets some love in IE. The commit : here.
• nib2cib gets some fixes too. The commit : here.
• The theme API has been finalized. The commits : here and here.
• The build tools now run on an abstraction layer called Narwhal. More information can be found in Tom’s announcement and of course in the commits : here, here, here and here.
• The capp command now uses CAP_BUILD if present. It still checks for STEAM_BUILD if CAPP_BUILD is not found. Can you feel 0.7b coming? The commit : here.
• CPURLConnection was calling didFailWithError for HTTP responses other than 200. didFailWithError is now called only if the request fails completely. The commit : here.

See last week post here.

April 30 – May 6, 2009 Edition

There have been 20 commits in the 0.7b branch.

• CPTexField gets some love : the placeholder string for CPSecureTextField no longer shows up as bullets, controlTextDidChange is now correctly fired, and there is also some bugfixes for IE (text selection) and Firefox. The commits : here, here, here and here.
• MainMenu.cib is now loaded automatically. The commit : here.
• CPDictionary has 2 new methods : initWithObjectsAndKeys and dictionaryWithObjectsAndKeys. The commit : here.
• Windows are now forced to stay in the bounds of the browser window. The commit : here.
• Hilight state and broken images resources have been fixed for CPMenu. The commits : here and here.
• CPButton now has a sizeToFit method. The commit : here.

Tickets have been migrated from Lighthouse to Github, so, from now, browse them and report bugs on Github.

See last week post here.

April 23 – April 29, 2009 Edition

There have been 5 commits in the 0.7b branch.

• An incredible job has been done on the Webkit JavaScript profiler. The Webkit profiler now allows you to identify resource-consuming code much more acurately. Read the extensive and very interesting article from @tolmasky for more information. It really helps to understand these 2 commits : here and here (this second commit was originally posted 2 weeks ago).
• Menu bars created in Interface Builder now show up when converted with nib2cib. The commit : here.