Nescafe Tasters Choice instant Coffee Reviewed

They were giving out these instant coffees at the PATH station. Just to be clear, I've never been a big fan of Tasters Choice coffee or any of the other big coffee makers however I did like Starbucks instant coffee but found the price a bit steep.

I chose a normal size mug, not an over sized mug, to pour one of these packets into as the higher ratio of water to instant grounds will make it weaker.  The coffee produced from this packet was pretty good, at least the Columbian Roast was. The body was even, low acidity but strong for an instant coffee.

Overall about as good as the Starbucks instant and at a fraction of the cost. Amazon has both brands as cheap as 70 cents per packet for the Starbucks instant compared to 17 cents for the Nescafe. Verdict: recommended as alternative to mediocre work coffee or on the go.

Getting Started: Programming Objective C on Windows

Why Learn Objective C?

Objective C has made C programming cool again and it's making a comeback. I've been interested in learning Objective C for many reasons: iPhone Development, statically compiled language with dynamic features and to brush up on my C programming.

It's been many years since I've done any C or C++ programming. If the C language gave birth to C++ then Objective C would be its sibling. Current versions of Objective C is basically the C language sandwiched with Smalltalk sprinkled with the goodness of dynamic programming and syntactic sugar.

Many people struggle writting iPhone applications in my opinion because they neglect the fact that Objective C is a first class language and like C# (.Net) or Java require time and patience to learn it first before learning the frameworks and paradigms. This would be akin to trying to learn C#, HTML & JQuery for the first time on an ASP.Net MVC project.

I will be treating Objective C like a first class language and I will be learning it on Windows first because I want to focus on the language first and not the frameworks (such as Cocoa). My first goal is to get a running development environment on Windows for Objective C programming, write a simple "Hello World" app and compile it using both gcc and a make file.

Setting up Development Environment on Windows from scratch

GNUstep is the cross platform, free & open source version of Objective C. First download and install GNUstep Core, GNUstep System, GNUstep Development Environment and your favorite text editor such as Notepad++. After installing this a group will be added to your Start menu in Windows named GNUstep, beneath it is a shortcut to a "Shell". Once open, you will be in a full command shell (BASH) you will be able to compile Objective C code files using make or gcc but we will first have to create a class file

The gcc that comes with GNUstep can compile C or Objective C apps. We will first start with a Hello World app that uses C header files and then tweak it to use Objective C header files to make sure everything is lined up and configured correctly in your development environment. Create a file called main.m and paste the following into it.

Within the GNUstep Shell navigate to the same folder and compile it (within GNUstep shell C:\YourProject would be /c/YourProject) by typing the following:

Then test the output in shell by running the app and make sure the output is correct before continuing.

Next we will modify the helloworld source to use Objective C library and make a build file for it so that it will compile. First, update main.m to below:

GNUstep provides makefiles which include the references to the libraries and folders that you will need. Create a file named GNUmakefile in our project directory and put the following into it.

Now to build it is simple, just type the following into our shell.

Some warnings should appear from the compiler but it should compile. Run the output which should be in a folder named obj and verify the output. There we go, our first Objective C app. For more info on make files within GNUstep see the reference manual.

Tips for Surviving NY Transit

Transit in the NY Metropolitan can be an exhausting nightmare or it can be a fun adventure.  Like most things in NY it all depends on your reaction to it.  Through a series of trial & error below is a list of things to do to make your way about NY area transit more enjoyable or at least less unenjoyable  ;-)

Plan ahead
Even simple trips doing from one part of Manhattan to another can turn into an hour if you get lost or have to walk 20 long blocks.  Manhattan is a deceptively large place and just because it looks like a short walk on the map doesn't mean it is.  Take the subway as many connection to get as close to your destination as possible.  Trust me, you will get plenty of exercise going up & down stairs and walking a few blocks from the subway.

Google Maps (web & mobile version) do an excellent job of providing directions & connections through NY transit but don't rely entirely on it because you will find yourself underground without a signal and if you cannot read a subway map then you will have to resort to begging complete strangers for help.

Streets in Manhattan are like a grid and they are very straight and consistent.  Numbered streets are positioned North (higher numbers) to South (lower numbers) and avenues are positioned East (lower numbers) to West (higher numbers).  You can use these numbers as a compass and easily figure out which subway to go on since most subway lines in Manhattan run North (Uptown/Bronx) to South (Downtown/Brooklyn).

Don't Rush
It's tempting when going into the subway to be coming down the stairs and hear "Ding... Ding" and think: "That's my train".  It may be the completely wrong train or the right line in the wrong direction because remember each line goes in two directions (unless you are at the end of the line).  You will find yourself on a train on occasion after rushing onto the wrong one, always double check yourself and make sure you are on the right line and going the right direction.  It's not a big deal to get off at the next stop and go the other direction.

Avoid the Bus
If you live right near a bus stop that drops you off within walking distance of your destination then you cannot complain too much.  For everyone else the unpleasantness of the stop & go driving on top of the unreliability of the bus makes it a terrible way to travel not to mention the Manhattan Bus Terminal being a daunting place to learn the NYC bus system by.  Stick to the subway for simplicity & affordability.

During rush hours avoid them empty seats
Choosing a seat with empty seats next to you just allow anyone to sit next to you and during rush hour the entire place it going to be packed and face it you don't want the smelly guy that takes up two seats sitting next to you.  Men, if your choice in seating is between an attractive young lady or an unknown quantity (and the possibility of overweight & smelly sitting next to you) you know what you are going to pick.  Ladies may choose to sit next to a young clean guy or choose the empty seat and stand the risk of sitting next to a bum rambling to himself or mole lady.

Choose the Train (heavy rail) for Long Distances
The train is blazing fast over long distances.  I swear I don't have time to even do small amounts of work before arriving at destination.  Train rides will cost about double the fair of the subway but if your time & comfort is more important than choose the train.

Sidenote: La Guardia Airport Sucks
La Guardia is an awful airport.  Commuting to it is terrible because you cannot take a train or subway without having to transfer through a slow ass city bus.  Also the terminals are disconnected which means if you get dropped off at the wrong one you cannot walk through corridors to get to your desired terminal.  Choose JFK (my 1st pick) or Newark (in NJ). Sidenote's sidenote: also JetBlue rocks if you have a chance to fly them, they make flying pleasant again).

I have a terrible sense of direction and I've gotten lost plenty of times, went the wrong way on the wrong line and wound up in Brooklyn instead of uptown, just work smart not hard in the NY transit system and you will be finding your way around in no time.

Relocation to NY

I haven't blogged lately, mostly because over the summer I took a job at Infusion Development to work as a consultant in New York.  Development in New York is mostly centered around financial services which provides inherently more complicated business processes than most industries.

For the previous two years I had worked at Loomis in Houston and I have enjoyed my time there.  We worked with many banks and retail establishments which offered a lot of opportunity for integration and working with cash management systems.  I also had the opportunity to work with some people in IT that I really appreciated and

In my short time here, I have enjoyed myself working on a project with one of the banks, developing on a trading platform.  Some of the challenges working on a WinForms trading application are: multiple threads & concurrency, separation of concern in a traditional WinForms app and the performance on a real-time system.

Relocating a family and settling in takes time but as things return to normal I'd like to blog about some of the following things I've been thinking of:

• Learning Objective C on Windows
• A fluent API for UI development
• Surviving a .Net 2.0 Project and enjoy it

Infusion is hiring Senior .Net programmers if you are interested in relocating to NYC and have a passion for development send me a message.

NDepend 3.0 analysis of NAsserter

NDepend is an effective tool for analyzing .Net assemblies and provides information so that you can have an idea of whats going on. There are use cases for this in our development cycles.  For the purposes of simplicity I'm going to show the usage based on analyzing NAsserter.

I recently posted some code to Google Code called NAsserter. NAsserter started off as a proof of concept for prototyping something I had been able to do within Unit Tests (being able to make fluent style assertions in code) except for the purpose of throwing exceptions in code. This is the first fluent API I have written.

The API for NAsserter started as a small simple class and grew bit by bit. I tried to refactor as much as it made sense to me. I didn't model my internal constructs after any other fluent library as most of them have a need for much more extensibility than this. The biggest inspirations were NUnitEx, NUnit's constraint based model and Fluent Validation. These three projects provide exactly what they aim to, in which NAsserter is not intended to overlap. NAsserter is NOT a Unit Testing or Validation framework. It's simply for throwing exceptions in a predictable manner, including the messages. Thanks to Tuna (NHibernate & Castle contributor) constructive feedback.

Upon getting a version of NAsserter (0.1) released that I am comfortable with, I proceeded to analyze it with NDepend; which I am still learning.

One of my favorite sections of the report is the assembly metrics which shows how abstract, stable, complex and well commented the code is.  I think the metrics of what you are looking for may be a little different based on if you are developing a framework (even the type of framework) or enterprise systems.  For instance, often times frameworks developers will make compromises in design for simplicity of use which is pragmatic:  use common sense.

NAsserter is a simple codebase which shows through the analysis (the only dependency is mscorlib the .Net CLR) and doesn't really do NDepend justice. NDepend is nice on large projects with a number of dependencies, especially for keeping track of different design metrics. I am still learning the tool myself and I am finding new uses for it continually. You can track your project's progress on different metrics since it keeps a baseline of the metrics. NDepend is also very helpful for code reviews to be able to have an objective analysis of code, reducing some of the human element.

Generic Singleton Factory

Not too long after writing and blogging about a generic singleton base, I changed the code to use a Factory - a singleton factory to be specific. Below is a factory which can be used to create a singleton instance of any class. The original singleton base class implementors needed to be sealed or have unintended consequences of getting an instance of the wrong class. This caused me to reflect and conclude that the design was deceptive as it was almost in essense a factory.

Below is a refactored version which is a little more genuine. This is my first crack, and requires generics. I do not use this everywhere I use singletons but where the usage of a Factory fits better than a singleton such as when you have many implementors of the same interface and you want singleton creational behavior.

Jon Skeet's has a great article on some different singleton designs in his blog.

Automatically mapping objects of same derived types

I had a need to automatically map all properties from one class to another class. These two classes had the same derived type, this was by design and not by accident. FYI: this example's Unit Test uses NUnit (2.5), NBuilder, both are optional as the test below can be easily adapted.

The scenario goes like this: you have a base class called BaseTransaction with derived classes DebitTransaction and CreditTransaction. Often where there are many properties from the base class to map, it's redundant to write and tedious. This bit of reflection below iterates through each property of the base class and maps it to a new object that it creates and returns this object.

The following unit test shows the usage of this function, as well as outputs to the console showing that the bases members were in fact mapped. Each derived class has unique properties of the same name (TransactionId), neither of these were mapped - otherwise an exception would have been thrown during the reflection code (prop.SetValue...).

DRY is dead, long live MOISTURE

DRY has become a big buzzword these days that puts emphasis on reusability. While there are some advantages to reuse, I'm going to look at the downside; having DRY applications which are rigid crack over time due to the lack of Moisture.

What is Moisture? It is the syntactic sugar that makes procedural languages like JScript, VBScript, FoxPro and T-SQL powerful and fast. Unless you've been hiding in a cave, you have started migrating from an ORM (such as NHibernate) to more future-proof constructs like Stored Procedures or DataSets.

In the past, the only downside to Stored Procedures was that Refactoring them took a lot of effort. However, JetBrains has recently announced ReProcedural to which lets you refactor code written in VBScript, Microsoft JScript or T-SQL

Once you have moved all of your business logic to stored procedures, just plan on having an average of 4 stored procedures per table (for insert, update, delete and select). In a medium sized system with 50 tables, it's completely acceptable to have an upwards of 200 stored procedures or more. At this point, your team should have enough T-SQL work to justify having a DBA letting you focus on increasing system Moisture with procedural programming

Finally, you will want to rewrite any aspects (AOP) as table triggers. For non-DBAs out there, triggers are essentially AOP for databases. For instance, if you wanted to implement logging your pointcut will either be your Stored Procedure or your Trigger.

Remember the basics of Moisture: the more OO code you can migrate to a procedural language, the better. While you can do procedural programming in C# or Java, it's not something enforceable as there is nothing stopping some n00b developer from creating an Interface or an Abstract Class. As a general rule, all methods should be public and static

April Fools!!! :-)

Utility function to facilitate Domain AddChild functions

As I make certain domain models more rich, one of the first things I will do is make the property of Child lists on the target domain model to a setter that is internal or public:

There's nothing wrong with this code, it's short & concise. My only problem with it is that there is a repeatable pattern here, we are always going to check to see if the child is null, we will always need to check for the nullability of the target list, etc, etc. If we could centralize this pattern, then if it changes we could change it there too. The silver lining being that if we can reduce it to one line of code and that is always a good thing :-).

Utility Function for Adding Child to Parent: Usage:

It works pretty well and I've ran unit tests against it for both generic lists and non-generic lists. I first started off thinking I could do this with delegates, but I concluded that this code was not a proper use of delegates. Feel free to sound off if I've gone completely mad or if there is a better way to do this.

Unit Testing Daos with NHibernate with SessionScopes Version 2

In a previous post I outlined how to modify Ayende's post to support contextual sessions. With Contextual Sessions in NHibernate instead of injecting a Session into each DAO you will be injecting a SessionFactory in which the caller will invoke the SessionFactory's GetCurrentSession() in order to get the session tied to the context. The previous example I mocked the SessionFactory and stubbed the GetCurrentSession() to return one session that would have been open for the life of a TestFixture.

This really isn't necessary if you bind the SessionFactory to a context. This is very easy with NHibernate and the only requirement is that you tell NHibernate through it's configuration the scope of your session context.

Something else I've thought about was that each TestFixture should only every test one DAO. The tests in said fixture should also only ever reference one DAO to be an independent test. Therefore if you are testing and a function from your DAO and need another object from persistence it would be better to call get the persisted object directly from your Session than from a separate DAO. Too often I see people trying to reuse objects in their Unit Tests which violates the integrity of the tests because they would no longer be independent.

Therefore it would be nice if the InMemoryDatabaseTest exposed the target DAO to the TestFixture to make it easier, it could also set the SessionFactory of the DAO. We can do this easily with Generics:

I have extended my existing base test fixture InMemoryDatabaseTest so that I don't break compatability with existing tests. All my new DAO TestFixtures will inherit from the new Generic version. I have also added some overloads for debugging. If you pass a true debug flag to the constructor it will output the SQL to the output Window. Also you can pass in a path to an actual SQLite file/db which will let you save the changes. This is helpful for complicated tests where you want to see what is being saved to the database and test the queries NHibernate is executing against SQLite.

BaseDao that all your DAOs inherit from to facilitate contextual sessions. This code should be in a separate assembly I call (rootnamespace).Data.Common InMemoryDatabaseTest that your test fixtures would inherit from. This code should be in a separate assmebly I call (rootnamespace).Testing.Common Usage

As you can see, the DAOs Unit Test didn't have to instantiate an instance of the target DAO since it already specified it as a Generic paramter. While this only eliminates 2 lines of code it more importantly enforces one DAO per test.