1. Using a commercial FIX engine is 16 time faster than open source
2. The spread of the jitter was a narrow 2 micros for commercial engines and wide 50 micros otherwise.
3. Using Low Latency networking for non-LL code had no effect.
4. Well written Java code works as well as compiled native code.

There was a very interesting talk from David Ingham, Microsoft, regarding the Azure Service Bus and their work supporting AMQP 1.0,

However, the best is often left to last, and in the case of the my-Channels posting on Nirvana 7, the final paragraph is a must read:

Nirvana EA2 will be released soon. It includes a new shared memory driver for intra-host communications. This will allow Nirvana communications between processes on the same machine to bypass the network stack and considerably improve performance. Current benchmarks of this functionality are showing that a sustained throughput of over 800,000 messages per second is possible with latencies of sub 5 microseconds.

Very interesting.

The important properties of Storm are:

1. Simple programming model. Similar to how MapReduce lowers the complexity of doing parallel batch processing, Storm lowers the complexity for doing real-time processing.
2. Runs any programming language. You can use any programming language on top of Storm. Clojure, Java, Ruby, Python are supported by default. Support for other languages can be added by implementing a simple Storm communication protocol.
3. Fault-tolerant. Storm manages worker processes and node failures.
4. Horizontally scalable. Computations are done in parallel using multiple threads, processes and servers.
5. Guaranteed message processing. Storm guarantees that each message will be fully processed at least once. It takes care of replaying messages from the source when a task fails.
6. Fast. The system is designed so that messages are processed quickly and uses ØMQ as the underlying message queue.
7. Local mode. Storm has a “local mode” where it simulates a Storm cluster completely in-process. This lets you develop and unit test topologies quickly.

Node.js vs *choose your last mile messaging product* is a common debate these days. Drew provides a Socket.io benchmarking view and framework which offers some interesting data points. my-Channels.com Nirvana offers its own view on benchmarking. If you throw in Lightstreamer and a few other paid products, coupled with maybe Caucho Resin, you soon realise that you can’t compare published benchmark, and hence you are back to a bake-off.

So where am I going with this posting? Well, in a nutshell, make sure you understand the use cases prior to selecting your technology stack to solve your business problem. A combination of OS and paid product maybe the solution, but make sure you compare apples with apples. my-Channels.com for example offers some nice fail-over features, but you need to paid for the product. Node.js will possibly require you to write more code to cover the fail-over use case (maybe using Redis).

Async tests in Jasmine

For a long time, most of our tests used the standard prescribed procedure in jasmine, which is describe() with a bunch of it()s. This worked well for the most part until we switched to RequireJS as our script loader. Then there was only blood red on our test pages.

Clearly jasmine and RequireJS have no mutual contract, but there is a way to run async tests in jasmine with methods like runs(), waits() and waitsFor(). Out of these, runs() and waitsFor() were the real nuggets, which complement each other when running async tests.

waitsFor() takes in a function that should return a boolean when the work item has completed. Jasmine will keep calling this function until it returns true, with a default timeout of 5 seconds. If the worker function doesn’t complete by that time, the test will be marked as a failure. You can change the error message and the timeout period by passing in additional arguments to waitsFor().

runs() takes in a function that is called whenever it is ready. If a runs() is preceded by a waitsFor(), it will execute only when the waitsFor() has completed. This is great since it is exactly what we need to make our RequireJS based tests to run correctly. In code, the usage of waitsFor() and runs() looks as shown below. Note that I am using CoffeeScript here for easier readability.

— Short CoffeeScript Primer —
In CoffeeScript, the -> (arrow operator) translates to a function(){} block. Functions can be invoked without the parenthesis,eg: foo args is similar to foo(args). The last statement of a function is considered as the return value. Thus, () -> 100 would become function(){ return 100; }
“With this primer, you should be able to follow the code snippet below.”

1
2
3
4
5
6
7

    it "should do something nice", ->
        waitsFor ->
          isWorkCompleted()

        runs ->
            completedWork().doSomethingNice()

Jasmine meets RequireJS

waitsFor() along with runs() holds the key to running our RequireJS based tests. Within waitsFor() we wait for the RequireJS modules to load and return true whenever those modules are available. In runs() we take those modules and execute our test code. Since this pattern of writing tests was becoming so common, I decided to capture that into a helper method, called ait().

1
2
3
4
5
6
7
8
9
10

ait = (description, modules, testFn)->
    it description, ->
        readyModules = []
        waitsFor ->
            require modules, -> readyModules = arguments
            readyModules.length is modules.length # return true only if all modules are ready

        runs ->
            arrayOfModules = Array.prototype.slice.call readyModules
            testFn(arrayOfModules...)

If are wondering why the name ait(), it is just to keep up with the spirit of jasmine methods like it for the test case and xit for ignored test case. Hence ait, which stands for “async it”. This method takes care of waiting for the RequireJS modules to load (which are passed in the modules argument) and then proceeding with the call to the testFn in runs(), which has the real test code. The testFn takes the modules as individual arguments. Note the special CoffeeScript syntax arrayOfModules... for the expansion of an array into individual elements.

The ait method really reads as: it waitsFor() the RequireJS modules to load and then runs() the test code

To make things a little clear, here is an example usage:

1
2
3
4
5
6
7

describe 'My obedient Model', ->

    ait 'should do something nice', ['obedient_model', 'sub_model'], (ObedientModel, SubModel)->
        subModel = new SubModel
        model = new ObedientModel(subModel)
        expect(model.doSomethingNice()).toEqual "Just did something really nice!"

The test case should do something nice, takes in two modules: obedient_model and sub_model, which resolve to the arguments: ObedientModel and SubModel, and then executes the test code. Note that I am relying on the default timeout for the waitsFor() method. So far this works great, but that may change as we build up more tests.

So given the above, coupled with QuantLib or JQuantLib together with a github repository, we have enough to build a Proof of Concept (PoC)

Sidebar: Bitemporal reading here.

Bitemporal pattern offers an elegant and sophisticated way of dealing with most temporal issues. The bitemporal pattern implementation offered by DAO Fusion builds upon a bitemporal framework created by Erwin Vervaet and Christophe Vanfleteren

Code and framework available here.

…when someone starts swearing in technical discussion, showing emotion, that’s a strong indicator that I’m about to receive wisdom. Wisdom is earned the hard way, and it is permanent, not like some statistically shaky performance benchmark that we’ll all forget about next week.

• Install the latest XCode to get a C++/C compiler – g++
• Install Boost – 1_48_0 in the version I have installed
• Build Boost.Python and test
• A number of Python samples exist on CodeSampler.com, specifically “Creating C++ objects from Python derived classes”
• Be aware of the OSX LDLIBRARYPATH madness
• Assuming you have the sample code from the above, then on OSX I found the following build the code, generating an executable: g++ -I /Library/Developer/boost_1_48_0/include/ -I /usr/include/python2.7 -L /Library/Developer/boost_1_48_0/lib/ -lpython2.7 -lboost_python -Wall -o pyc_python_derived pyc_python_derived.cpp
• With the above all in place, you probably want to check out Python decorators

Here’s a great Hello Android tutorial:

Hello World (Android)

Following the video, I got my own Hello Android app working.  Cool.

DroidDraw is a nifty wysywig layout designer. It may be outdated but it keeps me out of Eclipse. Last time I used Eclipse, it was horribly slow, but with all the cool Android support it has, I’m likely to give it a try again.

Now the app shows up in my emulator and I even added some checkboxes that I’ll be using later.

All in all, this tiny bit of Android development is looking very xamly.

The only hitch was that the emulator doesn’t like spaces in the names of virtual phones.

That said I have always felt/hoped there was a better paradigm, something with a more integrated approach for understanding the problem and allowing for the code/structure of a project to accumulate almost as a result. Such a silver bullet probably doesn’t exist, but after watching this presentation given by Dan North I am intrigued by what the author himself admits is nothing new, but merely an agglomeration of existing ideas into a new way of thinking about the problem.  I would recommend watching it to anyone who is adverse to TDD but like me hopes for something better.

It’s my opinion that BDD has very real potential and I hope to find a way to work it into my day job or at least a side-project to give it a proper shake to find out.

Style=”{StaticResource {x:Type BaseClass}}”

Of course in Silverlight, there is no x:Type.

The solution I used was to make an attached behavior that takes the class that has the style, finds the style in the resources and applies it.

The problem

Using a TextBox as an example, here’s some default styling that doesn’t get applied to the subclass:

It ends up looking like this:

The Solution

With an attached behavior, it can look like this (the bottom TextBoxSubclass has the default TextBox style applied):

    <StackPanel>

The attached behavior is pretty simple:

Conclusion

I think its exceedingly obvious how you could apply this universally as a default style on the subclass.  This looks like it has potential to be a pattern to compensate for other Silverlight omissions too.

You can download the full tiny demo on GitHub.

Project definition and build

Neither maven or the scala build tool (sbt) are completely satisfactory.

This maven **archetype** (what .Net folks would call a VS project template)

mvn archetype:generate `-DarchetypeGroupId=org.scala-tools.archetypes `-DarchetypeArtifactId=scala-archetype-simple  `-DremoteRepositories=http://scala-tools.org/repo-releases `-DgroupId=org.SW -DartifactId=BuildBreakPredictor

gets you started right away with “hello world” code, unit tests demonstrating a number of different testing approaches, and even a ready made `.gitignore` file – nice! But the Scala version is behind at v2.8, and more seriously, compiling and testing was painfully slow. So much that a rapid edit – test – edit cycle was not practical. So Lab49 colleague Steve Levine tells me that I can either adjust my pom to use fsc – the fast scala compiler, or use sbt.

Sbt has some nice features

• It’s fast – it uses fsc by default
• It has a continuous mode, so  `> ~test` will compile and run your unit test each time you save a file
• It’s can consume (and produce) Maven 2 dependencies
• the build definition file can be much shorter than the equivalent pom (about 1/5 the size, as repos and dependencies can be declared on a single line)

And some real limitations

• Limited support for 3rd party integration – for instance out of the box, TeamCity doesn’t speak sbt, nor does IntelliJ IDEA
• Steeper learning curve for build steps outside the default

Side note: If a language has a fast compiler, why keep the slow compiler around? Even worse, why make it the default?

I choose sbt, for the faster development speed it offers.

Syntax

Scala APIs really like to use punctuation – sometimes this works well, as in the following

 map1 |+| map2 

The `|+|` defines a merge operator which does addition on the `values` of the maps.

It’s less useful here:

http(baseUrl / url >- parseJson[BuildStatus]

sure you can probably guess what `>-` does from the context, but how about `>~` or `>+`?

Language features

I’m still learning, so not much to say just yet. However case classes are quite usefull, implicits scare me, and type constructors have lots of power.

Community

A number of projects, such as https://github.com/scalala and https://github.com/scalaz/scalaz are split between github and google code – github for the src, and google code for the docs. Not sure I understand the motivation here.

• How the ‘Off the Shelf’ Surveillance Industry Has Grown
• Document Trove Exposes Surveillance Methods
• DocumentCloud

The architects wanted the windows to open. Jobs said no. He “had never liked the idea of people being able to open things. ‘That would just allow people to screw things up.’

• Reset a user’s password in single user mode
• How To Re-Download Mac OS X “Lion” & Create a Bootable Install DVD
• If You Can’t Log In To OS X After Restoring From A Time Machine Backup…