Time Cockpit Blog

Recently, Microsoft launched their hosted Team Foundation Service which includes the ability to use customized workflows including custom code activities. Last week, I gave the feature a spin and here’s a few things that I tripped over.  Read more ...

In the first entry discussing C++ inheritance, I covered how basic inheritance works: A hidden pointer to a virtual function pointer table is used to dispatch to the correct method. I pointed out that the addresses of the objects, no matter how I casted them around stayed the same. Now this was pretty straightforward for single inheritance, but you will see why this becomes quite special with multiple inheritance.  Read more ...

Quite a while ago - still working with Rarebyte - I was designing a class library for game related stuff. Naively ensured that OOP was the only real solution to scaling software, we did a lot of (multiple) inheritance and packed stuff into the library, most of what we never needed anyhow. At one point the question came up on how this was implemented and if we actually knew what this (multiple inheritance especially) meant to the data structures. With self-competence I garbled something about function pointers and tables and a hidden pointer in every object etc. What it meant exactly, I didn't know.  Read more ...

For a Microsoft event we have been hired to do a full-day workshop about news in Visual Studio 2012 for C++ developers. The workshop took place at Microsoft's Innovation Center in Vienna last Friday. In this blog article you find the slides and the samples that I have used in the workshop  Read more ...

In cloud computing scenarios latencies between the application and database server are usually higher compared to an on premise scenario. With the rise of node.js I/O driven web hosts are becoming more familiar and ADO.Net 4.5 aids this by providing Async methods to I/O bound functions.   Read more ...

Those of you who know me, also know my appreciation for c++. Those of you knowing time cockpit will also know that nearly all of it is written in c#/.net with its service hosting infrastructure running in Windows Azure. There is one particular part of time cockpit that will, at some point in the future, receive a native rewrite and due to the nature of it, storing its data in windows azure is a key requirement. Windows Azure, up to now, does not offer a developer story for C++ development, especially considering access to its storage subsystem. This is where Casablanca comes in to play:  Read more ...

So today finally came that day, we put our first steps into moving to SQL Server Compact Edition 4.0 for our offline database. I was delayed by a day by introducing a new way of managing references to third party components in our build system because I didn't want to replace the Version for the assembly in every project file. How I did that is the content of another blog post though.  Read more ...

Even though our core dev team is quite small, time cockpit's code base has grown quite a bit. It has grown in such a way, that having all of the code in one solution file and working with it from a day-to-day basis is not a feasible solution. As we have three different areas we work on, Data Layer (DL), Signal Trackers (ST) and the User Interface (UI) itself, we have created seperated solutions for each area. This would work fine just as it is, but the problem is, that ST depends on DL and the UI depends on the ST and DL Layers.  Read more ...

We have been experimenting with automated testing of our services against windows azure lately. Our goal was to deploy a service in the build process, run a unit test, and then undeploy the process. Assuming that you have a hosted service ready (something.cloudapp.net) and a solution with a unit test running locally against a service (running locally, when executing the unit test, there are a few steps one needs to take in order to test against an azure-deployed instance of this.  Read more ...

After having released time cockpit 1.0, we decided to finally upgrade to Team Foundation Server 2010. The upgrade seemed to have worked without any problem and day-to-day work continued as normal with checkins, branching and merging working at least as good as before. If you read of the changes between TFS 2008 and TFS 2010 (here) you may have noticed that TFS Build 2010 is based on WorkFlow 4.0 (WF4).  Read more ...