Cappuccino: the jake branch


Those steps assumes you have already setup your Cappuccino source similarly to my environment.

If not, please read previous articles.

Keep in mind that the “jake” branch will be merged into master at some point, and the switch should happen sometime in the upcoming weeks; at least I’ve been told this way so take this information with a grain of salt.
Therefore: those instructions can turn obsolete at any time and probably are.

If you read my previous article you already know that I’m running Snow Leopard.
At any point do not close the Terminal window until you did every step.

Download Narwhal from GitHub.

cd ~/src/
git clone git://github.com/tlrobinson/narwhal.git

Activate paths and use tusk to install required packages.

source ~/src/narwhal/bin/activate
tusk install jake browserjs narwhal-jsc jack

Build Narwhal JSC:

cd ~/src/narwhal/packages/narwhal-jsc
make webkit
export NARWHAL_ENGINE=jsc

Build Cappuccino:

# if you don't already have a cappuccino source remember to have a CAPP_BUILD defined and
# git clone git://github.com/280north/cappuccino.git ~/src/cappuccino_source
cd ~/src/cappuccino_source
git checkout -b jake origin/jake
rm -rf $CAPP_BUILD
jake
jake debug # if you want also the Debug build
jake docs # if you want up to date local xml/html documentation, requires doxygen

20091024-d7sqyb241537a5fcbjd5i5sui9

Building Cappuccino with jake instead of rake will take some minutes to compile.

I read about some people reporting that the process gets stuck, this didn’t happened to me (well it did, but because I was compiling against master by mistake); the jake building process took about 4 minutes to complete on a 2,53 GHz Unibody Intel Core 2 Duo Macbook Pro.

We are going to tweak our $PATH in order to find the new Cappuccino Tools and Narwhal binaries like jake.
Keep in mind that you probably already have them in /usr/local/bin so we must adjust our PATH with some precedence.
Old utilities in /usr/local/bin aren’t modified by this procedure, since the jake task that should install them is currently commented.

Here is my .bash_profile related code:

# CAPP_BUILD, directory for built Cappuccino framework.
export CAPP_BUILD="$HOME/src/cappuccino_framework"
 
# Cappuccino jake branch.
PATH="$CAPP_BUILD/Release/CommonJS/objective-j/bin:$PATH"
PATH="$HOME/src/narwhal/bin:$PATH"
 
# Finalize PATH
export PATH=$PATH

This will make capp, nib2cib and press available on command line.

Reopen Terminal and test:

03:52 ~ $ which capp
/Users/kain/src/cappuccino_framework/Release/CommonJS/objective-j/bin/capp
22:42 ~ $ cd Sites/
22:42 ~/Sites $ capp gen MySecondApp -t NibApplication
/Users/kain/src/cappuccino_framework/Release/CommonJS/objective-j/lib/capp/Resources/Templates/NibApplication -> MySecondApp
# ...

Have fun!

$1.99 domains with SSL purchase!

On Cappuccino spriting and why it matters, part 1

sheets4qx
The first working builds of sprited Cappuccino were released around 14th October.

If you’re familiar with Cappuccino this means frameworks that include images/themes and also entire applications can be sprited.
This will be the default behaviour for Cappuccino applications, we’ll talk about advantages in a bit, first, a word about spriting if you’re wondering what is it.

Developed around mid-1970, spriting is a technique still used today; if you’re into CSS you might have used it.
If you’re old enough and curious you may have also dug into a videogame’s resource files and you may have seen images composed of multiple little images in a grid.

In fact spriting mostly consists in placing images into a larger image grid, and display the image we are requesting by supplying its correct position in the grid.

What that means in Cappuccino?

Simply put, by using spriting, Cappuccino can squeeze all your project’s images in a single file, thus reducing the number of requested/served files.

This is a big gainer, since Cappuccino also makes intensive use of themes; Aristo, the now default theme, counts around 111 files.
They will be only 2 after spriting kicks in for all users in master branch.

The wonderful thing is that it’s built-in, you are not required to do this kind of stuff. Couple that with the fact that will be using Narwhal-JSC soon, Cappuccino will be *really* fast.

I will discuss with Francisco Tolmasky (tolmasky) of 280 North about how spriting works in Cappuccino and as usual will report my findings here, in a second part of the article.

Foundation.j and AppKit.j 404

During some Rails integration with Cappuccino I noticed that my Rails’ logs were filling fast with 404s.

At first I thought I did something wrong in including my Frameworks, however it turns out that’s a normal behaviour by design.

I won’t go into the details here on why it’s happening, but here’s a solution:

Ruby on Rails

To avoid the stack trace generation overhead in Rails simply put down those routes:

  map.connect '/Frameworks/Foundation/Foundation.j',
    :controller => 'application',
    :action     => 'handle_cappuccino_404',
    :conditions => { :method => :get }
  map.connect '/Frameworks/AppKit/AppKit.j',
    :controller => 'application',
    :action     => 'handle_cappuccino_404',
    :conditions => { :method => :get }

Then in your handle_cappuccino_404 method you can simply render :nothing => true:

class ApplicationController < ActionController::Base
  def handle_cappuccino_404
    render :nothing => true
  end
end

I think we can’t rescue_from ActionController::RoutingError at this point.
Please also read another solution involving Rails Metal below.

Rails Metal

I was thinking about using Rails Metal to avoid even the extra bits:

script/generate metal cappuccino

Then in app/metal/cappuccino.rb:

require(File.dirname(__FILE__) + "/../../config/environment") unless defined?(Rails)
 
class Cappuccino
  def self.call(env)
    if env["PATH_INFO"] =~ /^\/Frameworks\/Foundation|AppKit\/Foundation|AppKit.j/
      [200, {"Content-Type" => "text/html"}, []]
    else
      [404, {"Content-Type" => "text/html"}, ["Not Found"]]
    end
  end
end

No need for the method described above: you can safely remove routes and the 404 handling method from your controller.

Sinatra

To avoid it in Sinatra:

# from http://github.com/mchung/cappuccino_sandbox
get "/Frameworks/AppKit/AppKit.j" do
  [404, {}, "Look elsewhere"]
end
get "/Frameworks/AppKit/Foundation.j" do
  [404, {}, "Look elsewhere"]
end

obj-j bits

Gotcha bits, taken from obj-j tutorial.

  • Objective-J has two types of objects, native JavaScript objects and Objective-J objects
  • The beginning of a class is always the keyword @implementation, followed by the class name
  • Each method signature starts with either a dash (-) or a plus (+)
  • Dashes are used for instance methods
  • One pattern you’ll find in Objective-J and Cappuccino is the idea of passing a method as an argument to another method
  • The alloc class method is analogous to the “new” keyword in many languages
  • The init instance methods are like the constructors in those languages, in that they perform initialization on the newly created instance
  • Some classes specify their own custom init method
  • “self” is the Objective-J equivalent to JavaScript’s “this”
  • There are two types of import statements. The angle brackets indicate framework code, while the quotation marks indicate local project code
  • JavaScript is garbage collected, and so is Objective-J, so you won’t see any calls to retain or release in Objective-J code as you would in Objective-C
  • Categories allow you to add methods to a class without needing to create a new subclass or modify the class’s source code
  • The syntax for the category is @implementation, followed by the class you’re adding to, followed by the name of your category in parentheses
  • Technique called toll-free bridging which allows any JavaScript object like an array or a string to act both as a JavaScript object and a Cappuccino object at the same time
  • Variables not specifically declared with var become globals

Rails vs. Tarantula

There are times when you, as a lone developer, simply don’t have time to write tests.

It’s bad but can happen, but I can guarantee that even if your application is small or simple it probably does contains some bugs, especially if you are forced to write it on the fly and fast (which should be the only reason to excuse your lack of tests).

Sending an application straight into production without running tests is bad, I can’t stress it enough.

However there’s a solution to have some little tests running prior in distributing your app: Tarantula.
Continue reading

Safari CTLoader errors?

CTLoader
Toolbar has not been tested on this version.
Toolbar bundle will not be loaded

Try this:

  1. Open a new finder window.
  2. Click on Applications.
  3. Open the Toolbars folder.
  4. Open the Vuze folder.
  5. Double click on Uninstall.

From the Vuze FAQ:

If you installed the Vuze Toolbar for Safari and are getting an error when launching Safari (an error about CTLoader), you can fix the issue with an updated toolbar. Download it here:

http://ct1609479.ourtoolbar.com/sf

If you didn’t want the Vuze toolbar installed for Safari, you can remove it with these instructions:

http://faq.vuze.com/?View=entry&EntryID=346

Reminder: Outlook vs. Snow Leopard server’s postfix

Snow Leopard server implements some good anti-spam measures, on top of all Greylisting.

But there’s a subtle issue with sending emails from Outlook, many users will get an error on the lines of:

helo command rejected: need fully-qualified hostname

In order to solve this open up:

sudo nano /etc/postfix/main.cf

Find this line:

smtpd_helo_restrictions = reject_invalid_helo_hostname reject_non_fqdn_helo_hostname

and change it to:

smtpd_helo_restrictions = permit_sasl_authenticated permit_mynetworks reject_invalid_helo_hostname reject_non_fqdn_helo_hostname

Restart the mail service.