Go watch (or at least listen)

Krzysztof Cwalina – MSR Technical Education Series: Designing .NET Class Libraries

You can leave a response, or trackback from your own site.

I have been re-reading Designing Interfaces. Good book for designing user interfaces as the name implies. The author had a lot of this info on the web, but the book has much, much more. Anyhow I was going over the ‘behavioral patterns’ and though they were woth mentiong here:

Safe Exploration “Let me explore without getting lost or getting into trouble.”

Instant Gratification “I want to accomplish something now, not later.”

Satisficing “This is good enough. I don’t want to spend more time learning to do it better.”

Changes in Midstream “I changed my mind about what I was doing.”

Deferred Choices “I don’t want to answer that now; just let me finish!”

Incremental Construction  “Let me change this. That doesn’t look right; let me change it again. That’s better.”

Habituation “That gesture works everywhere else; why doesn’t it work here, too?”

Spatial Memory “I swear that button was here a minute ago. Where did it go?”

Prospective Memory “I’m putting this here to remind myself to deal with it later.”

Streamlined Repetition “I have to repeat this how many times?”

Keyboard Only “Please don’t make me use the mouse.”

Other People’s Advice “What did everyone else say about this?”

 All great stuff. Most UIs are bad ! The section in this book on presenting complex data are excellent – I highly recommend it.

-Chris

You can leave a response, or trackback from your own site.

I spent a lot of time doing non-bank automated trading. Most of my efforts were working with TradeStation for several consulting clients. I also did more auto-trading work with prop trading individuals, direct to some API – like PatsSystems, Interactive Brokers, etc. These are all good tools for the non-institution. After several years of using SmartQuant on and off, I met a guy and started talking to him about potentially collaborating on some .net based trading technology. I had done lots of work in the optimization/ machine learning space, he has spent most of his effort doing data feed adapters. He eventually combined his small firm with these folks; NinjaTrader.

These guys seem to have continued on well enough. NinjaTrader seems to be adding features and be progressing nicely. It is an inexpensive way to develop C# based automated trading systems.

 -Chris

You can leave a response, or trackback from your own site.

StreamBase slides from Algorithmic Trading 2007 Conference

Look At the picture on slide 4. This IS what I also believe is the future state of real trading infrastructure.

• Event Driven Architecture – because it really is an event driven business.
• Stream Processing engine to clean and normalise data feeds.
• N Automated trading strategies
• Real Time event driven risk management
• N automated, event driven execution strategies

This is what it is all about folks. Get me in the game I have had notes about this stuff for a few years now, and this is the best total picture that I have seen… OK I have to screenshot this … Read the slides anyhow – but here is th slide.

-Chris

You can leave a response, or trackback from your own site.

One of the items that I have not gotten to talk about in my recent sessions on test driven development is in the area of integration testing. I have been focusing on ‘core developer values’ that work hand in hand with unit testing for the most part.  In particular, at my last consulting project before coming to my current role, I did quite a lot of automated integration testing using NUnit. The pattern is common:    

• Client Application – talks to N services.   

• Each server application has it’s level of volatility and own release schedule.   

• The quality of the server applications varies (sadly, depending on where you are!).   

• Client application has some kind of client side facade or proxy that hides the mechanics of dealing with the service/ server application.   

Not only is it important to have unit test style code testing automation, but actually doing the integration testing in an automated way can bring great value. Typically – it is ‘nasty’ to talk to a database, messing service, web service, etc. from a proper unit test. Unit tests want to make sure that you are dealing with the abstractions immediately adjacent to your class under test. Any real external dependencies like databases etc are normally stubbed or mocked out.  At some point you need to ACTUALLY test the real interaction of the tiers however. Thankfully – the unit testing tools are excellent at containing the automated tests and running them. There is a common model then between your unit tests and your integration tests. In practice what I have done is to have an extra package for integration tests. This extra package is not deployed of course. It may be 1 package per target assembly or 1 package for several assemblies depending normally on how the binaries are used – if 3 binaries are used together always then you can have 1 integration test package for example. I am generally in favor however of 1 target assembly, 1 unit test assembly (with internals visible to) and one integration test assembly (also with internals visible to). Now I have my clean core code, my unit tests and my integration tests.  Server side applications need to deploy some regular ‘integration builds’ that can be run again for integration testing. Server applications in practice may also have other service applications they depend on. In this scenario -they will also benefit from an automated integration testing strategy.    

You can leave a response, or trackback from your own site.

I hope everyone enjoyed themselves at the New York Code Camp  ‘07 today. Thanks Don. For the connection today. I enjoyed myself -there was a great bunch of interested people today. A few of us noted how popular the ‘agile room’ was. It was a ’standing room only’ set of sessions in the agile room. I wish I could of stayed for some of the afternoon chats – particularly the pairing session and the mocks session. Alas, I can only get babysitters for so long and my wife had an agenda today too

Anyhow – I got excellent feedback regarding my chat today on scaling agile practices. There is never enough time to go over some of this stuff – but we did alright today. The audience was engaged and asked lots of great questions. At the end of the event, as I was talking with a bunch of people – a developer came up to me and said something like the following:

 ”You know – I have been hearing about this agile stuff for some time, and trying to get a grasp on it. I have not truly appreciated the value of ‘Test First’ until today – thanks - that was great and so helpful.”

This was just what I was looking for. I hoped today to set people up to succeed at trying to ‘go do the agile thing’. Delivering the correct worldview and set of paradigms, along with a set of pragmattic, day to day, code level tools goes a long way.

Anyhow – attached is the slide deck from today - along with the example code.

Code Camp Demo Code

Slides Office 2007

Slides Pre Office 2007

-Chris

PS - I will be doing some serious work on sorting out my top ‘core developer values’ and I will post it in a series here. I will also be posting it for my current employer. These ‘core developer values’ are a big part of what it takes to be successfull with unit testing – having the right mindset and accompanying practices!

PPS - You guys who asked to come work with us – CONTACT ME- WE ARE TRYING TO HIRE C# DEVELOPERS – LOTS OF ‘EM!

 

You can leave a response, or trackback from your own site.