20. Mai 2011

Technologie und idiotische Investoren

Gerade komme ich wieder mal von einem Barcamp/Conference/Unconference zurück. Da gab es wieder allerlei interessante Vorträge über Technologien und Arbeitsmethoden. Dabei haben wir (ehemalige Mitarbeiter von Weblin) festgestellt, dass das was wir vor 3-5 Jahren gemacht haben, jetzt für die Masse der Entwickler interessant ist. Wir haben damals Probleme erkannt und gelöst, die immer noch aktuell sind und inzwischen wenigstens von den meisten anderen Teams auch angegangen werden.


Bei Weblin hatten wir ab 2006:
und vieles mehr. Frag' doch mal heute - zu Zeiten von NoSQL - wer for 4 Jahren schon "Avoid SQL" gesagt hat.

Das waren schon damals alles bekannte Technologien - die aber nur 3 % der Startups verwendet haben. Heute völlig normal, keine Kunst. Die Kunst ist es das Richtige zu tun, wenn es noch nicht alle machen. Mit der Auflösung von Weblin wurden eine Menge Entwickler rausgeschickt, die die Technologien in ihre neuen Teams getragen haben und jetzt damit viel Geld verdienen.

So gut waren wir.

Technologie zählt. Alle Firmen, die Erfolg haben, haben super Teams im Hintergrund. Werft das Technik-Team weg und ihr habt nichts. Facebook, Zynga, Bigpoint kaufen Firmen nur, um an die Technik-Teams zu kommen. Für alle, die es noch nicht gemerkt haben: die Zeiten ändern sich.

_happy_ranting()

8. März 2011

Simple Dependency Injection

Dependency injection (DI) is very useful for isolated tests. In short:

Assumed you have a user table in the database. Assumed, that the user table is accessed through a class UserDatabase. Your application wants to cache users for quicker access. This means, that there is at least a list of users in memory. Usually you would wrap this list into a class UserManager. The typical code of UserManager will instantiate a UserDatabase, like:

class UserManager {
UserDatabase DB = new UserDatabase();
UserManager() {}
public UserId CreateUser() {
return DB.CreateUser();
}
...
}

If you want to test UserManager.CreateUser(), then the method needs a UserDatabase instance which will access the real database. This is not what you want, because it is not isolated. You want to test UserManager without activating UserDatabase. It rather would be cool if the UserManager would use a dummy database class which just simulates the behaviour of UserDatabase without actually writing to the real database.

So, we want to equip the UserManager for the test with a MockDatabase, but for the real operation it should use the real UserDatabase. We want to decide which database class the UserManager will be using under which circumstances. Means: we make the proper database and hand it to the UserManager. We inject it. Example:
class UserManager {
UserDatabase DB;
UserManager() { // real constructor
DB = new UserDatabase();
}
UserManager(UserDatabase db) { // test constructor
DB = db;
}
public UserId CreateUser() {
return DB.CreateUser();
}
...
}

The test code will create a new MockDatabase() and use UserManager(UserDatabase db) to inject it. The real code will use the default constructor, which makes its own normal UserDatabase. Not pretty, but possible. If there are more dependencies, then things get nasty with large contructors which are only used for tests and have different code from the real constructor. Not pretty.

There are better ways. For example DI frameworks, which provide sophisticated methods for injecting dependencies without bloating constructors. They use extensive configuration, if you like. I used StructureMap. It works, but I do not like, that I have to learn it. I spend a few hours reading, learning, trying, and even a few hours on it's unexpected limitations. Now I can use StructureMap, but I do not recommend it, if you do not already know it.

Dependency injection can be simpler. Here is my take: we want, that UserManager uses either MockDatabase or a UserDatabase. Why not just tell the UserManager to Use() either database:
class UserManager {
UserDatabase DB { get; set; }
UserManager Use(UserDatabase db) { DB = db; return this; }
public UserId CreateUser() {
return DB.CreateUser();
}
...
}

The test code will then look like:
var um = new UserManager().Use(new MockDatabase());

The production code will be very similar:
var um = new UserManager().Use(new UserDatabase());

The return this; part in Use() takes care, that the configuration can be written in a single line. If there are multiple dependencies, then I can do:
var um = new UserManager()
.Use(new MockDatabase())
.Use(new DummyWebService())
.Use(new TestController());

...because all the different Use() Methods have different parameters types and automatically know what to do. That's it. Use() is my DI framework.

And here comes my favorite single line of dependency injected configuration for a unit test. An ItemCore which uses a RezMockConnection and an ItemRepository which itself uses a MemoryItemStorage.Factory:
var rep = new ItemCore().Use(new ItemRepository().Use(MemoryItemStorage.Factory)).Use(new RezMockConnection()).Repository;


_happy_using()

27. Februar 2011

A Busy Spaceport in Earth Orbit

This is not Science Fiction:


There is a big space station in earth orbit. It spans 2 soccer fields. It has the weight and pressurized volume of a Boeing 747.

The station has a current population of 12 people.

There are 6 (!) spacecraft docked:
  • 2 russian soyuz crew vehicles
  • 1 russian progress transporter
  • a japanese HTV transporter
  • a european ATV transporter
  • an american space shuttle

2 x Soyuz
TMA-20 & TMA-01M
Russia
Progress
M-09M
Russia
HTV-II
Kounotori 2
Japan
ATV-2
Johannes Kepler
Europe
Space Shuttle
Discovery
USA










Never again will there be so many spacecraft including a shuttle docked. This is mostly due to the shuttle's retirement. Only two more shuttles will visit the ISS. Other craft will replace the shuttle.

With the Space Shuttle retiring and no improved reusable craft following, it looks like there has not been much progress in the last 30 years. But the completed ISS with 6 craft attached and 12 people is a much larger and developed space operation, than during the single-module days of Skylab and Salyut. A different order of magnitude:

Skylab
SalyutISS






_happy_undocking()

2. Februar 2011

2 1/2 Zi. Wohnung in Freiburg zu vermieten ab 1.4.2011

Anzeige:


2 1/2 Zimmer 41 qm ab 1.4.
1. OG, 2 1/2 Zi, EBK, Bad, Flur, Wohnzimmer, Schlafzimmer, Keller, Aufzug, Bauj. 1995, Tennenbacherstr. 50, 79106 Freiburg, Nähe Institutsviertel, Straßenbahn Haltestelle vor dem Haus, 420,- € KM, 160,- € NK, Kaution 3 x KM, keine Provision, wolf.heiner@gmail.com, Tel. 0171 / 2848461




2. Januar 2011

OAuth for TwiX

I finally added OAuth to TwiX, the Twitter-XMPP gateway.

Since August 2010 Twitter requires OAuth for API access. This is extremely stupid for background daemons like TwiX which do not have a user interface and especially no browser based UI.

TwiX is my C# playground. So, I needed an OAuth library for C#. TwiX runs on mono and .NET. I am running my instance of TwiX on a Linux server. Luckily almost all .NET libraries run without modification on mono.

A quick research returned several OAuth libraries, some are for ASP.NET, which I do not use, because TwiX is a faceless server daemon, not a Web application. I zeroed in on Shannon Whitley's implementation which comes with a handy sample project.

This example project has
- an OAuth core implementation
- a Twitter OAuth adapter
- a sample desktop app with embedded browser
= cool thing

I used the 2 OAuth classes in TwiX and converted the sample desktop app into a Twitter OAuth token generator tool (see screen shot). 1 hour of work, thanks Shannon.

This is a general Twitter token generator. It is not just for TwiX. The OAuthTwitterDesktopTool generates a twitter token and token secret for every Twitter app, if you know the app's consumer key and consumer secret. The OAuthTwitterDesktopTool is part of the TwiX distribution.

You can find TwiX with OAuth and the token generator on the TwiX homepage.

_happy_authorizing()

1. Dezember 2010

Science Fiction Comes True

This looks like an image from a Science Fiction movie. But it is not. It is reality.

The image shows a real astronaut in a real space station and a real earth through real windows.

We see astronaut Tracy Caldwell Dyson inside the cupola of the ISS space station. The cupola has been installed during Space Shuttle mission STS-130 on 15 February 2010. It is the largest window ever deployed in space.

The Space Shuttle era comes to an end. It seems to the public, that not much progress has been made. But there actually is development. The cupola image is one indication. And more than 100 Space Shuttle missions result in unprecedented operational experience in space. Another sign for advance is the fact, that the Space Shuttle was not the only one. There are other "returnable" launch systems in active operation (X-37B) created by organisations with a budget, that is larger than NASA's.
_happy_spacing()

19. Oktober 2010