Cocoa

I want to keep developing in Cocoa. I’m quite impressed with the Objective-C language, the Cocoa framework, and the XCode IDE. So far I’ve stuck to the basic classes. I’m hoping to expand into Core Data and eventually Core Animation to build some nice iPhone (and maybe desktop) apps.

Scala

I figure that I should get some experience with a language for building concurrent software. I was looking at Erlang last year and decided it wasn’t for me. I’m not a fan of LISP like languages. That’s not a knock against the language, it’s just my personal preference. What excites me about Scala is that it supports Object Orientation Programming, can use existing Java classes, and runs on the JVM.

Adobe Flex

Not much to say except that Flash is a widely used platform. I’ve had to integrate with it a little bit now and I assume I’ll need to write some code in it this year.

That’s my list so far. What’s yours?

Rapid Application Development

One thing I talked about was rapidly putting together a website or web based API to test a concept or demonstrate functionality. While some people use Rails, I find that I can use a Sinatra stack much more quickly.

When putting together a concept site, I like to use Sinatra, HAML/Sass, JQuery, DataMapper, and SQLite.

For most of the apps I build for fun or test a concept, I find that Rails is overkill. I only need a few routes and a few views, so for me, Sinatra fits the bill. I can put all of my routes in a single file and all of my views in a single views/ folder.

JQuery and HAML/SASS are solely my preference. I find that I write my markup and styles in HAML & SASS faster than if I write them in HTML and CSS. I also find that JQuery selectors pairs up nicer with the markup I write in HAML.

I like using DataMapper connecting to a SQLite3 in-memory database. I’ve seen several example of this with Sinatra and think its brilliant. Since DataMapper lets you define the schema for your database in the models, you can generate a new database everytime your app is loaded by setting up the database connection to a memory database in the Sinatra ‘configure’ block and then calling DataMapper.auto_migrate!.

# lib/pet.rb
class Pet
  property :id, Serial
  property :name. String
end

# app.rb
require 'rubygems'
require 'sinatra'
require 'dm-core'
require 'lib/pet'

configure do
  DataMapper.setup(:default, 'sqlite3::memory:')
  DataMapper.auto_migrate!
end

get '/'
 ...
end

...

Rails Unit Testing

Nothing against RSpec, but it’s just not my cup of tea. I prefer Test::Unit, but I augment it with several libraries.

First and foremost, I always add in Shoulda. Shoulda allows you to set contexts (to group similar tests and setup test data) and has several assertions that, among others, simplify testing redirects and model associations.

Next up are FactoryGirl and aiwilliams-dataset.

Even though foxy fixtures made fixtures less brittle, they can still be problematic to work with. Fixtures map back to database inserts so none of those lovely model filters will get hit when the record is created. As an example, a fixture for a User model would need you the developer to set the crypted password manually instead of having the model generate it on creation. This is where FactoryGirl comes into play. FactoryGirl allows you to define a Factory object which generates a new Object with default values through the Object’s create method. In this example, the Factory for a User would have a default password and password_confirmation that would get crypted at creation.

Factory.define :user do |u|
  u.login 'george'
  u.password 'pass123'
  u.password_confirmation 'pass123'
end

Factory.define :car do |c|
  c.model 'Generic'
end

Adam Williams’ Dataset app can leverage your Factories to ease creating sample data. Dataset allows us to create specific sample data for a use case than a blanket amount of fixtures. I use the name_model with Factories to create sample data.

class UsersDataset < Dataset::Base
  name_model Factory.create(:user, :login => "quentin"), :user_quentin
end

class CarsDataset < Dataset::Base
  uses :users

  name_model Factory.create(:car, :model => "Jazz", :owner_id => users(:user_quentin).id ), :car_jazz
end

So when we’re testing our CarsController, we only load the sample data to test for Cars instead of all fixtures.

class CarsControllersTest < ...
  dataset :cars

  context "A CarsController" do
    context "on GET to show" do
      setup do
        get :show, :id => cars(:car_jazz).id
      end

      should_render_template :show
      ...
    end
  end
end

I also recommend Mocha for mocking and stubbing objects. I know some people use mocks and stubs to force branching conditions in unit tests (i.e. on save fail, object should generate such and such error message). Personally, I prefer to use real data to force those conditions. The exceptions comes when talking to 3rd party systems / APIs. When unit testing, I don’t want my tests trying to talk to another server. I want my tests to be self contained; i.e. I don’t want to run multiple applications just to make my tests pass.

My last note on testing is a bit of advice. I recommend not testing private methods. Searching on Google returns hundreds of different articles on the matter; some for and some against testing private methods. I encourage you to pick a few articles and come to your own decision. At least at this point, I prefer grey box testing. Since you know the underlying structure of the code, you can pass in the right data to pass information through the public methods without resorting to hacking classes to get directly at the private methods.

AHAH

AHAH is form of AJAX. In lieu of parsing an XML response, we receive HTML from our webserver and insert onto our page. I prefer this since it keeps my JavaScript simple and, since we’re generating markup anyways, keeps the HTML generation in the application.

Progressive Enhancement

The simplest way (and probably over simplifying it) I can describe progressive enhancement is to allow a webpage to work with and without JavaScript functionality enabled. There are several schools of thought on why this is done. Accessibility. Semantics. Etc.

I use this approach for browser compatibility. On a recent internal project, I found that half of my customers are security minded and turn JavaScript off. The other half want a rich Web 2.0 interface. By designing for the first half and then using JQuery or other libraries to add behaviors to the static pages, I can then satisfy those looking for a richer experience.

The Example

The JQuery example I posted on Github is by no means an exhaustive study of both Progressive Enhancement and AHAH. However, I believe it’s a clean simple example of both concepts.

Additional Reading

JQuery AJAX

Technologies Used

CSS

First and foremost, I’m passable at CSS and will take any help I can get. So the major lifting of the CSS of my site is provided by Blueprint CSS. This allows to me quickly structure my site and all thats left for me is to tweak my colors , my floats, and whitespace.

JavaScript

I realize I’m barely using JavaScript on my site. The exception is the rounded corners on the bottom of my blog. This is built using JQuery UI. It’s as simple as add “ui-corner-bottom” to the element I want to style. Simple.

CMS

I have updated my blog to RadiantCMS 0.8. I’m happy the Radiant team has moved their product to Rails 2.3.2 and updated their HAML version. We’re migrating our sites at work to Radiant and I’m happier with this release than the previous ones. It’s a bit easier to create extensions this go around. I’ve still run into some problems with writing unit tests for the extensions, but overall its an improvement.

Development

I spent 2008 learning a lot of new technologies. On top of my head, I learned Git, RSpec, Shoulda, RadiantCMS, a little JQuery, some Erlang, CouchDB, Sinatra, and webby. A lot of Ruby stuff mostly, which is great, but I need some variety.

In 2009, I’m going to learn Objective-C 2.0. I’m a developer and a Mac user. It seems only natural to start learning Apple’s language of choice.

I haven’t put the time into it too far. I’ve made some purchases from Pragmatic Programmers that I’ll be consuming very soon.

Personal

Gotta get in shape. Working as a programmer is a sedentary life. I got in really good shape as a freshman in college. But as college progressed and I started working part-time then full-time, on came the pounds. But that’s starting to change.

Working for Sourcefire allows me to get to the gym everyday for at least a half hour. I’m hoping by summer time, I’ll be back in good shape. Then by the winter, I’ll be in great shape. I gotta prep to look good for vacation. :)

My big goal for the year is taking my wife to Walt Disney World. She’s never been, so I get the pleasure of showing her around. If all works out, we’ll be going in December and I couldn’t be more psyched.