Tests gone bad: antipatterns of automated testing

I’ve got a series of blog posts on what you can do wrong with automated tests, and what to do about it on the Zühlke blog.

Tagged with: ,
Posted in Coding, Testing

REST API Design Rulebook – a waste of e-ink

REST API Design RulebookREST API Design Rulebook by Mark Masse
My rating: 1 of 5 stars

The book tries to establish a set of rules for REST interfaces – I’m OK with that, it’s what its title says. When you define rules, you take an opinion, that’s fine. And most of what is defined as a rule is something I’d support as a good practice. A possible benefit of this rule book would be to provide some compact, memorizable, and clear guidance on good practices.

But then there’s this obsession about WRML.

WRML is a proposed way of defining the content types and schemas of REST APIs – see http://www.wrml.org/about. And what do we find as the sole literature on WRML: the REST API Design Rulebook. WRML has about zero industry acceptance; I never heard of it, and it does not even have a wikipedia page. And yet the REST API Design Rulebook puts it into the heart and center of every halfway advanced topic. Now a “rule” that is centered around an obscure standard proposal is totally void, and so this book is a simple waste of e-ink (even if that was its only fault, which it isn’t).

Posted in Uncategorized

JavaScript for Metro-style apps: now I get it.

I’ve spent the last few days at the Microsoft //build/ conference where the first preview version of Windows 8 was shown (and everyone got a tablet PC, which I like, and – and this is going to be important for the rest of the post – has built-in 3G network).

I really quite like the new Metro-style UI for touch applications. I’ve liked the Metro UX framework from the start when it first came into view on Windows Phone 7. I’m not sure if it’s a good idea to go to the full-screen home screen for launching apps when in desktop mode, but that’s a different story, and you can still install Launchy anyway.

What I didn’t really understand was why JavaScript and HTML were integrated into the platform in such a deep way. You have three independent language systems for creating applications that use the new Windows Runtime (“WinRT”): native C++ code with XAML as markup, .NET with XAML as markup, and JavaScript with HTML as markup. Each of them is anchored into the system at the same level. Access to the WinRT is provided to each of these systems in a different way using “projections”: translations of type systems and conventions to make working with the WinRT feel like you did not. Repeat; JavaScript has been anchored AT THE SAME LEVEL AS C++ AND .NET.

Phase 1: Writing it off

Seeing actual code written in HTML/JS however was quite a downer. I had hoped for a more semantic way of expressing layout than XAML provides. XAML is basically a 1-to-1 representation of an object graph, while HTML expresses layout more as an intent. I normally find working with XAML a lot less productive than it should be. However, to make use of the controls that the platform provides, you need to drop concrete class names into your markup, making HTML for Metro-style applications more concrete than it should be.

As for JavaScript, there is an extra JavaScript library called the WinJS to provide access to platform specifics. And there are some: since an HTML application is, well, and application instead of a web site, it needs to care about process lifecycle and state management. It’s really hard to put this in words – do you know the feeling when something looks all reasonable, but just does not feel right? That’s it with me and the WinJS.

But my main problem with the whole HTML/JS stack was that I could not understand WHY. Everyone I talked to stated that the HTML path for building Metro-style apps existed so that web developers could bring their existing skill set and write great apps from the get-go. I don”t quite buy this. Because first of all, an existing skill set might not be so important. The enormous success of the iOS platform proves that if something is attractive enough, you even write Objective-C. I think it’s an underestimation of developers who master modern web site development when you assume they could not learn some C# or VB on a level that makes you perfectly productive at the level you need for UI programming.

And secondly, you actually have to extend your skill set anyway: WinRT controls, WinJS, process lifecycle management…

So what I concluded is that the HTML/JS stack was basically an oversized technological approach to solve the business problem that for the platform to succeed, it’ll have to launch with a fully stacked app store.

Phase 2: and then I got it.

I have two days left in California before I head back to Germany. I’m going to take a shower, pack my things, and drive south to the beach once this blog post is finished. Which will cause me my favorite problem: I tend to get lost. And the car does not have GPS.

But what I do have is a tablet PC with GPS and a 3G connection. So when I woke up at 4AM (the jet lag never left), I sat down and wrote myself a Metro app that displays a map full screen, and puts my current position into the center, and puts a pin at it.

And how do you display a Google Map? Yeah. Exactly. All you need is some HTML and JS. (I ended up using Bing Maps because it works better with the pinch-to-zoom gesture).

Here’s the app.

The thing that sets apart the HTML/JS way of writing Metro-style apps over using XAML markup is not that it’s easier to write, or yields better results. In fact, I believe that for larger apps, the robust type system and patterns like MVVM give .NET a clear edge.

HTML/JS Applications that integrate with web resources intensely have a lot less friction. You don”t need to write an adapting SDK to translate between a service like Maps. HTML and JavsScript are the native language of the web, and when you go there, it’s better to speak that language well.

Tagged with: , ,
Posted in Coding

Take the Stoic Test

An underestimated developer superpower: Keep calm and focused with a juicy geek discussion exploding in the office/Twitter/Comments/Yammer around you. You get one point for each question that you can claim to keep your head down and your mouth shut:

  • Is this an entity or a value object?
  • Does Apple provide open software system?
  • Does using Open Source Software pose a risk?
  • Is Google evil?
  • Is this interface really RESTful?
  • Is Java dead?

If you score higher than five, you get an official hand-drawn STOIC badge to attach to your CV.

I doubt that I ever get one.

Posted in Team

Pipes, valves, and social networks

This is a chat room.
The tube is a message bus. When a sender pushes a message into it, it just comes out on the other side, and everyone receives it.
This is e-mail.
We’ve added a valve on the sender’s side. It lets the sender control to whom the message goes out. On the receiving side there’s nothing, you can get messages from everyone – look into your spam folder for proof.
This is Twitter.
Now there’s a valve on the receiver’s side. Everything you publish is public, but you only get messages from senders you follow.
This is Facebook.
The two valves on both sides are interlocked. Opening them to someone enables sending and receiving messages.
This is Google+ Circles.
The valves are independent. The red valve controls the receivers of message; this is the circle a message is published to. The green valve is a circle of of the recipient. The message only gets through if the sender is also in the receiver’s circles.
Posted in Uncategorized

Beware of the dreaded passive arbiter!

The setup seemed simple enough: Two application servers running ASP.NET MVC, and a MongoDB replica set with two standard nodes and an arbiter.

If you’re familiar with MongoDB replica sets, feel free to skip the following paragraph:
When using MongoDB in a productive environment, two servers and an arbiter is much of the absolute minimum requirement. You cannot seriously run on a single server; MongoDB is not designed to provide good durability on just one machine. A two-node replica set provides replication of changes to a second machine. It also provides a failover server should one server go down. A replica set works much like classic master-slave replication, but the master is elected automatically: if the node that currently holds the master role (the “primary”) does not respond to a heartbeat, another node (a “secondary”) becomes the new primary. Which secondary is promoted is quite an interesting ceremony. An important aspect is that for a primary to be elected, it needs to “see” the majority of nodes in the replica set – otherwise, a broken network link could split the replica set in the middle, and there’d be two primarys (see a popular piece of fantasy literature on what happens in such a situation). A result of these rules is that a replica set with just two nodes cannot work – when one server goes down, the other won’t see a majority; even when the secondary node fails, the primary demotes itself because it finds itself alone.
This is where an arbiter comes in. An arbiter is a MongoDB instance that does not hald any data. It does not take part in replication. Its sole purpose is to provide a majority for the election of a new primary. In a two-node setup with an arbiter, one server can fail and the other still has a majority of two thirds of the replica set.
And then there’s priority. Priority is a MongoDB server setting that determines the order in which nodes are elected primary – a node with a higher priority wins. The most useful setting for priority however is 0. Setting a node’s priority to 0 makes it a “passive” node – it will never become elected the primary. This is useful if a machine is e.g. used just for backups, or if it’s in a remote data center. Otherwise, a passive node acts like a normal member of the replica set – data is replicated to it, and it can be used for running queries against it.

Alright. So we’ve got passive nodes, and arbiters. This is mutual exclusive – an arbiter cannot be a passive node. Passive nodes can be used for queries, arbiters can’t, they don’t hold data.

To query the status of a node in a replica set, you can run the command db.isMaster() against it. It returns a document that describes the shape of the replica set, and the role the queried server plays within it. Two fields that are returned are if the node is a passive, and if it’s an arbiter.

The C# driver for MongoDB (and probably other drivers as well) use the isMaster command to determine which servers are available, which is the primary, and qhich ones can be used for queries. If a query is allowed to be executed against a read-only replica of the database by setting the slaveOk setting, the driver looks for secondary and passive nodes. Which is correct. But this is where things start to go wrong – using this sequence of in itself harmless details.

MongoDB up to and including the current version 1.81 allow setting the priority on an arbiter node.

If you set the priority to 0, a node will report itself to be a passive. Yes, this includes arbiters. Ouch.

The driver looks for secondaries and passives to run queries. It does not exclude arbiters, because these normally aren’t secondaries or passives. Except when the server claims to be one, because someone set the priority to 0. Second ouch.

If you run a query against an arbiter, it will return an error that it’s neither primary nor secondary, and cannot be read from: { "$err" : "not master or secondary, can't read", "code" : 13436 } .Luckily, the driver recognizes the connection as faulty and removes it from the connection pool.

So what kept me busy for about ten working hours was this: an application server was reporting a MongoDB error once every time the IIS application pool had restarted. It turned out it was connecting to an arbiter, and the reason for that was that a DBA had set the priority on the sorry arbiter to 0, which was a leftover of its configuration before it became an arbiter.

First conclusion: don’t set the arbiter’s priority to 0. Just don’t. Arbiters don’t need a priority setting, or in fact, mostly no settings at all.

Second conclusion: I really love MongoDB for its simplicity, the data modelling possibilities, and its performance. But things like the dreaded passive arbiter really raise a question mark on its maturity – the problem would have been easily avoidable on either the server or the driver (or both, for better). What also needs to be admitted that 10gen is extremely responsive and helpful. They promised to fix the C# driver within a week(!) in release 1.2, and scheduled a fix for the server for version 1.92 – all within one day reaction time.

Tagged with: , ,
Posted in Coding

C# Enum Quirks

I’ve been slashing out C# code since 2000. Just today I discovered something totally new to me.

Would you reckon that this test is valid?

public enum Direction

public class EnumQuirks
	public void Cast_any_number_to_enum()
		Direction direction = (Direction)5;
		Assert.AreEqual(5, (int)direction);

In fact, it is. An enumeration can be casted to its underlying data type, of course; by default, this is an Int32. What I hadn’t realized is that the conversion works the other way too. Any integer value can be assigned to an enum, whether the values are defined or not. In order to safely assign a numeric value, the result of Enum.IsDefined can be evaluated.

But it gets weirder. In order to convert a string value into an enum, there’s the TryParse method. But when it tries parsing really hard, look what it can do:

public void TryParse_accepts_any_number_in_string()
	string value = "5";
	Direction direction;
	bool canParse = Enum.TryParse(value, out direction);
	Assert.AreEqual(5, (int)direction);

This is even documented:

Enum.TryParse: Converts the string representation of the name or numeric value of one or more enumerated constants to an equivalent enumerated object.

It converts the numeric value too. And since there is no check if there is a constant defined for any numeric value, any string that can be parsed to a number is valid.

Lesson learned: you can’t trust assignments to enumerations without checking Enum.IsDefined. And if there’s code out there that parses string coming from an insecure source (like an web request), you can’t rely on Enum.TryParse.

Posted in Coding
%d bloggers like this: