How DI works? In simple words, it is sometimes called an implementation of "The Hollywood Principle". Hollywood Principle is named after response given to amateur wanna-be actors after audition: "don't call us, we call you". But contrary to Hollywood producers, DI frameworks will keep the promise. Imagine class Car and its close collaborator, Engine. In old times, you would create one class, and in Car's constructor for example, one will create a instance of Engine. And it works perfectly, but only in programming book examples. Often you will have many more collaborators, and soon you will need to provide the same instance of Engine to other classes.

And here devil starts smiling and whispering to your ear: "Dear developer, having trouble with this network of connections between classes? Try singleton pattern, you won't have to worry about passing once created instance to all interested parties". And until recently, most Objective-C developers listened to Singleton Devil.

And here comes the

Syringe Framework

Truly agile Dependency Injection for Objective-C. Ready to grab from GitHub. Featured on SoftPedia. Fast and lightweight. And very simple to use.

I designed Syringe inspired by best parts of Spring Framework and Google Guice, and tried to make it lightweight and simple. First of all, Syringe is

Annotation-driven

You're right: there are no annotations in Objective-C, but there are Protocols (called "interfaces" by Java/.NET guys). So any class you wish to be injected should be marked by implementing Injectable protocol. Like in this example:

@interface Car : NSObject <Injectable> {
   …
}

Since then, all ivars of Car type in classes that are managed by Syringe will be assigned by reference to cached instance of Car. And if Car has ivars of other types that are marked with Injectable protocol, they will be populated too.

Most difficult part is start

Not in Syringe case: on very beginning there is object not managed by Syringe that has to start everything. Convenient C macro makes it clean and simple:

Car *car = inject(Car);

And that's all. No XML configuration, no container to configure and start. Syringe starts automatically upon first use of inject macro. If you want more control, you can start rolling everything manually:

[BeanFactory bootstrap];

Sometimes after Syringe-managed instance is created you may want to run some initailization code, and be sure that all collaborators are connected. This is possible by

Post-initialization

and simply adding InitializingBean protocol:

@interface Car : NSObject <Injectable,InitializingBean> 
 
    -(void) afterPropertiesSet {
        …
    }

and implementing protocol's only method: afterPropertiesSet.

Inverse Spider-Man Principle

With great simplicity, there comes low flexibility. I am aware of that, but Syringe is a idea that I had on my mind for months. It was meant to solve my problem. But if it does not solve yours - let me know and feel free to fork me.

Common choice of environments I see everyday is development, integration, certification (or staging) and production. Possibilities are almost endless, and depend on creativity of  your enterprise architects Suppose we want adapt light web framework to heavyweight corporate standards:

Adding custom environment is simple. Open Config.groovy and add new section id Grails' DSL:

environments {
    production {
        grails.serverURL = "http://localhost:8080/${appName}"
    }
    staging {
        grails.serverURL = "http://localhost:8080/${appName}"
    }
    development {
        grails.serverURL = "http://localhost:8080/${appName}"
    }
    test {
        grails.serverURL = "http://localhost:8080/${appName}"
    }
}

You can do exactly the same thing in DataSource.groovy and add database url for new enviroment:

environments {
    //    ...
 
    integration {
        dataSource {
            dbCreate = "update"
            url = "jdbc:hsqldb:file:intDb;shutdown=true"
        }
 
    }
}

Finallly, run grails application with usual command line option:

grails -Dgrails.env=integration run-app

or, even better, add this command line switch to your favorite servlet container environment options.

I want more

Adding custom environment with just another database setting is trivial use case. You may want to have additional per-environment configuration settings, different for each environment. For example, while developing eBay auction sniper, you would like to publish production like instance, but connecting to "sandbox" API. Thanks to Grails' flexibility it is plain simple. Go back to Config.groovy and add anything you with to environment blocks:

environments {
    production {
        grails.serverURL = "http://localhost:8080/${appName}"
        ebay.url = "http://open.api.ebay.com/"
    }
    staging {
        grails.serverURL = "http://localhost:8080/${appName}"
        ebay.url = "https://api.sandbox.ebay.com/"
    }
    development {
        grails.serverURL = "http://localhost:8080/${appName}"
        ebay.url = "https://api.sandbox.ebay.com/"
    }
    test {
        grails.serverURL = "http://localhost:8080/${appName}"
        ebay.url = "https://api.sandbox.ebay.com/"
    }
}

You can access variables defined inside braces via ConfigurationHolder singleton:

ConfigurationHolder.config.ebay.url

Telling current configuration from code

You may want to show running environment name somewhere on page, to make sure application your testers are playing with is not connected to production ebay environment Grails offers a way to obtain current running configuration:

Environment.getCurrent()

Environment is actually enum type and getCurrent() returns value for current configuration. There is one catch: this is enum, so it lists only factory-defined configurations: PRODUCTION, DEVELOPMENT, TEST, and for everything else: CUSTOM. Casting this enum to string will effectively return "CUSTOM" for all custom configuration. However, if you make call like this one:

Environment.getCurrent().getName()

You will find that getCurrent() method is smart enough to alter CUSTOM enum's name property and set it to right value.

This is why people love Grails: it is simple, yet flexible. Have fun!

I'm happy to annouce update of my little Phocus! app. Version 1.1 brings a cool new feature: calculating optimal aperture and focus point to achieve given depth of field. Everything else (including delicious UI is left unchanged.

• Phocus in App Store
• Phocus! website.

Phocus! Depth of field priority.

Phocus! Depth of field

There is simple solution for that: and there's again nice, but obscure feature that is included in the box, but just not activated. Let's edit the .hgrc in your home directory, and make sure there is something like this:

[extensions]
purge =

and once it is, just type

hg purge

to send unwanted files to /dev/null.

Just key in a magical command:

defaults write com.macromates.textmate AppleScrollAnimationEnabled -bool NO

And scrolling is back sraight!

[via http://lists.macromates.com/textmate/2011-January/032098.html]

It's still an EAP, but it is quite impressive. It fills the gaps in places I missed so much: refactoring, quick fixes, and on-the-fly code analysis. I played with it just a little, but definitely:

• rename works
• extract method works
• change method signature works
• @class and #import is added automatically when class is used
• you can generate ivars and @properties

and many more. Great job, JetBrains!

I only wish Apple not making some stupid decision about banning or blocking other IDEs. I hope I'm paranoid in that case.

echo '{ "Japko.net" : "Rulez" }' | python -mjson.tool

vim ~/.hgrc

And add some magical lines:

[extensions]
color =
highlight =
graphlog =

color and highlight enable colored output of diff and stat. graphlog adds new command, glog, which will just try to draw revision graph using ASCII-art alongside with normal log output. There's a lot of extensions to be discovered, I just started with bringing some life to dull default interface.