Coding in Istanbul 3: Pair Coding with a Friend is Fun

Helping Jeff with his PHP work was a chance to practice some pair coding. I don’t get to do this at work!

I know Jeff since the engineering school. We graduated from the same place in Paris. At the time (about 14 years ago) we were always coding in pairs: nothing to do with agile, we simply had to! The school labs were equipped with one PC/Solaris station for two people at best. We often had to finish projects late at night. Eating pizza at someone’s place, three or four people on the same computer. Of course we couldn’t afford laptops. I even remember having to carry around my tower PC to a mate’s flat in order to finish a late project! Those were tough times… and pairing with people was natural: it didn’t look like an exotic feature from a new methodology. It was just what all students did. 

During our excursions in the coffee-shops and restaurants of Istanbul we both have our netbook. We tried phases where we worked separately, Jeff coding and me looking up some info. But what turns out to work best is to code on the same netbook taking turns at the keyboard. Less chances to get distracted this way. If one loses focus, the other puts him back on track. If one does a typo the other spots it immediately. If we both loose focus we just order another Latte.

We can sustain the pace for about two hours before we become useless.

Quite a good laugh actually…  Just like good old times! Too bad we don’t do that at work…

Coding in Istanbul 2: Reverse Engineering a LAMP Project

We had a salad at Belvu restaurant, Fenerbahçe then carried on coding in True Blue, a cafe overlooking the Sea of Marmara with a nice view to the Princes Islands.

The stack of Jeff’s site is based on PHP/MySql/Apache. I’m more used to the world of C#/ADO.NET/Linq/T-SQL/SQL Server.

It’s funny how web development differs from enterprise apps!

I got into the habit of encapsulating everything and separating layers but the approach used by some PHP devs is more pragmatic. Business logic, data retrieval, building SQL queries and presentation: everything is done in the same .PHP file!

In Windows client development you typically let a data layer retrieve some data objects (via ADO.NET, Linq or something else) then you assign the data object to a grid control. The control takes care of displaying the content of the object, dynamically creating columns and adding rows… In the PHP files I saw the data layer bit (building the SQL, performing the query, retrieving data) appears just a few lines before a while loop that echoes  <td> tags to generate a table for each row of the result set. All layers in the same place.

Also in the code I saw SQL queries were always built on the fly. The first downside of building SQL queries with string concatenation is vulnerability to SQL injection (followed by performance loss due to always rebuilding the query plan and no transactional integrity)… The devs protected the code from injections by using specific PHP functions that parse all user inputs. Why not use stored procedures? Apparently stored procedures are a new thing in MySql: they arrived only in version 5. So I guess they got into the habit of doing away without them.

Regarding the development tools, when working with PHP in Dreamweaver -apart from a bit of color coding- you get absolutely ZERO compiler support. Indentation is manual and there is no intellisense. Comes pretty close to handcarving on stone tablets.

Another funny thing with MySQL: it comes with a large choice of database engines, each one having its pros and cons. It turns out that the default db engine in MySQL is optimised for speed and does not support foreign keys. So by default you work in a system where you can delete parents without deleting childrens and where children can contain a reference to a non existing parent. You’d better be sure that’s what you want, most of the time it’s not…

Coding in Istanbul 1: PHP in Turkey

I’m having a çoban kavurma in a restaurant with my old mate Jeff who lives in Istanbul. We stopped for lunch in one of the busy pedestrian streets of Kadiköy on the Asian side of the city.

We spent most of yesterday coding on Jeff’s doctors appointment website. We added a small admin functionality that will save him time when mailing doctors. He’s currently working on getting more doctors registered: it involves finding their details and emailing them one by one. Obviously spamming them all in one go is out of the question so each email is slightly personalised (quoting the doctor’s own website). Yet they all follow the same template so there is some room for automation.

Jeff also needs to track how doctors open and view the campaign emails. Each email contains a number of links: to the appointment’s website, press articles, facebook and to twitter. Pretty clever: each link calls a php on his website that logs the doctor’s identifier along with the identifier of the link. Then he can run a report that shows various stats about who clicked what link…

Good places to take the netbooks out in Turkey include a growing number of restaurants, Starbucks, Gloria Jeans… and Wifi is almost always free!

Gloria Jeans is a great place to sit down with the laptop: more comfortable than Starbucks and less crowded. The one in Ortaköy is perfect: beautiful view to the Bosphorus, 3 levels, smoothies, cheesecakes, tosts (paninis) and free wifi.

View Istanbul in a larger map

Setup, TearDown, When to Mock?

 

I’m writing this while eating at the Launceston Place, a very comfy restaurant near Gloucester Road. Warm decor, soft lighting and excellent service.

• Setup and TearDown

Only use those to respectively initialise then destroy mock objects. Methods with [Setup] and [TearDown] attributes are called before and after each test so they’re the only methods that guaranty that things get cleaned up.

Best to avoid the [SetupFixture] attribute (to mark a class that contains Setup and Teardown methods called just once before ALL tests), as well as [TestFixtureSetup]/[TestFixtureTeardown] (called once only before all tests in a fixture). I tried to be clever and used them and ended up having to debug nasty side effects. Unit tests are supposed to run in isolation, so just one [Setup] before and one [TearDown] after each of them, that’s it.

• What should be mocked?

Yesterday while writing a UT I bumped into this question: should I bother writing a mock for that object or can’t I just use the real thing?

One answer: objects that access external systems (DB, hard-drive, client API to some server-based system, …) should always be mocked (for unit-tests that is, not integration tests), otherwise the test is not repeatable, and it’s slow…

If a method under test accesses an injected object and this object does only in-memory stuff, then no need to mock it. It would make sense to mock it because after all this injected object is not actually the thing you want to test… Still, the more real objects are covered by the test, the better. As long as they all run in-memory and do not prevent the test from being repeatable, all is well. So no need to waste time writing a mock in that case.

Got to Treat Yourself

I bought myself a Christmas present. Next week I’ll receive this neat little thing:

It’s a VAIO X-Series.

This is a replacement for the VGN-SZ5 that I carried around every day in a rucksack for more than two years. Now the rucksack will disappear to be replaced by a tiny messenger bag.

Premium carbon finish, SSD drive, embedded 3G. Extremely thin and less than 900g. This is going to be pure pleasure.

In 2007 netbooks were not around yet and I needed something to write code on the go, not just in my lounge. I got the VGN-SZ5 and a Wenger SwissGear rucksack, both of which I’m still using today. I went everywhere with them: Hertfordshire, TechEd Barcelona, Egypt, the French Pyrenees (picture), Paris, Istanbul… In London I use the Vaio in the tube, in Starbucks, Costa, in pubs, in restaurants (which is extremely annoying to people I go out with).

Last year the rucksack felt a bit heavy on my shoulders so I started looking around for a netbook. I read reviews and benchmarks in magasines, tried out all sorts of models in the shop… Samsung, Asus Eee, Acer, Lenovo, MSI Wind… It wasn’t quite that. Either the 3G card was not embedded, or the thing was too bulky… Not sexy enough.

The first time I saw the X-Series in a Sony shop (in October last year two days before the official UK launch), I immediately thought “I want that”. I gave myself some time to think it over (it’s a bit of an investment). In its October 2009 review, PC Pro said:

But the real problem for the X-Series is its price. (…) Who, though, can lavish £1,130 exc VAT on a vanity laptop such as this?

I just ordered one.

 

Cheap IoC in native C++

In a 2008 episode of dnrTV James Kovac describes how to create a very simple IoC container. All the container does is mapping the name of an interface to an instance of this interface.

Easy to do in .NET with a generic Dictionary, but what about native C++? It turns out it's not that much more difficult: all you need is a STL map and C++'s typeid. 

What is an IoC container?
A class that given an interface ISomething returns the concrete object implementing ISomething.


Why do you need an IoC container ?

It's one way to do dependency injection.

Let's say you want to unit-test some business layer that relies on a data layer. The business layer sees the data layer through an interface (let's call it IDataLayer). The actual instance of IDataLayer is created by either:

• the entry point of the code that uses the business layer (an executable for instance). This is production code and it has to create the object connecting to the real database.

 

int _tmain(int argc, _TCHAR* argv[])
{
    // Create the concrete DataLayer object
    DataLayer dataLayer;

    // Register it with the resolver
    Resolver::Register<IDataLayer>(dataLayer);

    BusinessStuff businessStuff;
    businessStuff.DoStuff();

    return 0;
}

• the unit-test code. The IDataLayer object in that case is a fake object that doesn't connect to the real database and therefore makes unit-tests easily reproducible and fast.

void BusinessStuffTest::DoStuff_Nominal_DoesNotRaiseException()
{
    // Arrange

    // Create the concrete DataLayer object
    FakeDataLayer dataLayer;

    // Register it with the resolver
    Resolver::Register<IDataLayer>(dataLayer);

    BusinessStuff businessStuff;

    // Act
    businessStuff.DoStuff();

    // Assert
    dataLayer.AssertStuffWasDone();

}

Implementation of the Resolver class
The Resolver class has two methods Register and Resolve. Here is the code for the Resolver class (very straightforward):

#pragma once

#include
#include

using namespace std;

///
/// Allows you to Register and Resolve global objects
///
class Resolver
{
    static map<string, void* > typeInstanceMap;

public:

    template<class T> static void Register(const T& object)
    {
        typeInstanceMap[typeid(T).name()] = (void*)&object;
    }

    template<class T> static T& Resolve()
    {
        return *((T*)typeInstanceMap[typeid(T).name()]);
    }
};

This is a just a starting point. In production Resolver could do with methods such as Unregister(), IsRegistered(), UnregisterAll()...


An IoC container is one way to do dependency injection. Other ways include:

• pass the injected object using the constructor
• pass the injected object using a setter method

Both methods above can become tedious very quickly in a big project.
I tried all 3 methods and I find the IoC approach scales rather well. I've used it for 10 months in a production project and it works nicely with unit tests.

Resources:

Jean-Paul Boodhoo on the gateway pattern
Roll your own IoC container (dnrTV)
The Art of Unit-Testing where Roy Osherove tells everything about dependency injection and fake objects.

Windows 7 and the Press

I was replacing Windows 7 beta with Windows 7 Release Candidate on my laptop a few months ago... And I was joking with colleagues about the future success of this new version. Having used Vista for two years
Windows 7 didn't strike me as an earth-shattering evolution. Yet we predicted that people would rush on Windows 7 like bees on cupcakes for two main reasons:

• the press was very positive about Windows 7 after it slaughtered Vista
  
• the Release Candidate was as good as the final thing and free to use until March 2010. In other words people could use a fully working OS for free for 10 months.
  

I don't think Vista deserved the bad press it received. I used it for two years: RC1 and RC2 on an old PC then the RTM 32-bit and eventually 64-bit on my main machine.
Driver issues? A bit at the beginning but nothing that couldn't be overcome.
Speed issues? Desktop: nothing that I could notice on a 4GB dual-processor Dell with raid-striped 15000rpm SAS drives. Laptop: browsing the web was fine, Visual studio was slow. After I moved to Windows 7 browsing the web was still fine and Visual Studio still slow.

When I removed Vista 32-bit from my Vaio and installed Windows 7 RC, it indeed felt a bit snappier. But again, ANY version of Windows feels snappier after a fresh install.

Whether you run XP, Vista or Windows 7 the OS you're running on a machine does not matter as much as the following factors:
- how fresh the install is: re-install your OS often, with a bit of organisation it can be quick.
- the amount of RAM: install more than you think you'll need.
- the hard drive speed: one 15000rpm drive is good, two are better.


I might oversimplify a bit, still I think there are mostly two reasons why you want to upgrade to a new OS:

• the untold one: it looks better than the previous version.
• the one you tell people to look clever: the OS is faster, contains bug fixes and new useful features.
  

Thanks to unbalanced press opinions Windows 7 at last gives people an excuse to cave in to the first reason while being covered by the second.

Books I currently flip through #7

Technology

• Effective REST Services via .NET: For .NET Framework 3.5
• Programming WCF Services, 2nd Edition

Methods

• Apprenticeship Patterns, 1st Edition
  

Finance

• The (Mis)behaviour of Markets (Benoit Mandelbrot)
  

 

Others

• Blink (Malcolm Gladwell)
  
• The Black Swan (Nassim Nicholas Thaleb)
  
  

Trying out TeamCity and CruiseControl

A few teams use Cruise Control at work. It seems to be a fairly standard choice when it comes to continuous integration. Roy Osherove recommends TeamCity over CruiseControl because he doesn't like getting his hands dirty with XML configuration (can't blame him).

I tried both to get a feel of what you can do with them. I ran TeamCity of my main machine and CruiseControl on a VM to avoid clashes.

I managed to get a build running in TeamCity without too much difficulty. I installed the tray notifier.

CruiseControl is a bit more tricky. After I edited the config files I kept getting exceptions when trying to startup ccnet.exe. Had to go through several install iterations before getting something running.

Installing TeamCity:

• Install Tortoise SVN
• Install VisualSVN Server
  
• Run the TeamCity installer
• Start the build agent manually (rather than through a Windows service).
  
• Install the TeamCity Windows tray notifier
  

Installing Cruise Control inside a virtual machine.

• Windows Virtual PC RC, wich is a new version of Virtual PC for Windows 7.
• Install Virtual Server 2008
• Install SVN command line  
  
• Edit the ccnet.config file
• Added a project block
• Added a source control block
• Added a tasks block. Good news: you can add task where you simply run devenv.exe against the solution file. 
• Get the Web Dashboard working:
  
• Install IIS: under Windows Server 2008, it's not a Windows feature any more, it's a server role. You have to go to Server Manager > Roles > Add Roles and follow the wizard to add IIS.
• Run the CruiseControl.Net installer
  
• Create a new application in IIS for the ccnet webdashboard. In Server Manager, go Roles > Web Server (IIS) > Internet Information Services, open Sites > Default Web Site. Right-click Default Web Site and choose Add Application. Set Application Pool to Classic .NET AppPool.

How to re-build your PC in less than 2 hours

Pre-requisites:

• Your data on D:, the OS on C:
• Your backup ready (nothing to do because you have an automatic full D-drive incremental back-up scheduled to run every day )
• Your CD case with all legally acquired original CDs for software and drivers
  
• Access to the spreadsheet where you carefully store all serials for the above.

Go:

1. Boot from DVD
2. Format C:.
3. Click Next, OK, next, Ok, I agree, OK, Next, London GMT
4. Install your favorite software. For me it is:
   
1. Kaspersky
2. Office
3. Chrome, Firefox
4. Skype, Live Messenger
5. Visual Studio
5. Check the time: if it took you more than 2 hours, start all over again.