Programming

My Erlang Religious Moment

Ayende Rahien — Sat, 20 Mar 2010 10:00:00 GMT

It is not often that a piece of code cause me to have a religious moment, but this one managed to:

Challenge: What does this code do?

Ayende Rahien — Fri, 19 Mar 2010 10:00:00 GMT

What language is it? What is it doing? Why?

You can’t learn the basics from the pros

Ayende Rahien — Fri, 12 Mar 2010 10:00:00 GMT

There was a question recently in the NHibernate mailing list from a guy wanting to learn how to write database agnostic code from the NHibernate source code.

While I suppose that this is possible, I can’t really think of a worst way to learn how to write database agnostic code than reading an OR/M code. The reason for that is quiet simple, an OR/M isn’t just about one thing, it is about doing a lot of things together and bringing them together into a single whole. Yes, most OR/M are database agnostic, but trying to figure out the principles of that from the code base is going to be very hard.

That leads to an even more interesting problem, it is very hard for a beginner to actually learn something useful from a professional. That is true in any field, of course. In software, the problem is that most pros would simply skip whole steps that beginners are thought to be crucial. It isn’t from neglect, it is because they are going through those steps, but not in a conscious level.

Very often, I’ll come up with a design, and when it is only when I need to justify it to someone else that I actually realize the finer points of what have actually gone through my own head (another reason that having a blog is useful).

I think that there is a reason that we have names like code smells, you can immediately sense a problem in a smelly codebase, although it may take you a while to actually articulate it.

Getting code ready for production

Ayende Rahien — Sat, 06 Mar 2010 10:00:00 GMT

I am currently doing the production-ready pass through the Rhino DivanDB code base, and I thought that this change was interesting enough to post about:

public void Execute()
{
    while(context.DoWork)
    {
        bool foundWork = false;
        transactionalStorage.Batch(actions =>
        {
           var task = actions.GetFirstTask();
           if(task == null)
           {
               actions.Commit(); 
               return;
           }
           foundWork = true;

           task.Execute(context);

           actions.CompleteCurrentTask();

           actions.Commit();
        });
        if(foundWork == false)
            context.WaitForWork();
    }
}

This is “just get things working” phase. When getting a piece of code ready for production, I am looking for several things:

If this is running in production, and I get the log file, will I be able to understand what is going on?
Should this code handle any exceptions?
What happens if I send values from a previous version? From a future version?
Am I doing unbounded operations?
For error handling, can I avoid any memory allocations?

The result for this piece of code was:

public void Execute()
{
    while(context.DoWork)
    {
        bool foundWork = false;
        transactionalStorage.Batch(actions =>
        {
            var taskAsJson = actions.GetFirstTask();
            if (taskAsJson == null)
            {
                actions.Commit();
                return;
            }
            log.DebugFormat("Executing {0}", taskAsJson);
            foundWork = true;

            Task task;
            try
            {
                task = Task.ToTask(taskAsJson);
                try
                {
                    task.Execute(context);
                }
                catch (Exception e)
                {
                    if (log.IsWarnEnabled)
                    {
                        log.Warn(string.Format("Task {0} has failed and was deleted without completing any work", taskAsJson), e);
                    }
                }
            }
            catch (Exception e)
            {
                log.Error("Could not create instance of a task from " + taskAsJson, e);
            }

            actions.CompleteCurrentTask();
            actions.Commit();
        });
        if(foundWork == false)
            context.WaitForWork();
    }
}

The code size blows up really quickly.

Nice process, but what about the engineering bits?

Ayende Rahien — Sat, 20 Feb 2010 01:23:00 GMT

Software processes has always been a popular topic of discussion in our industry. Those can get quite heated, with advocates of the “stable / stale” Waterfall method pointing fingers toward “rapid / rabid” Agile methods, with the CMMI people throwing documents around and Lean people standing on the sidelines muttering about Waste.

This isn’t a post about a specific software process, I’ll defer that to another day. Instead, I want to focus on a flaw in the basic building blocks in many* software building processes.

They ignore the actual building the software.

That may sound ridiculous on the face of it, after all, how can a software process ignore the act of building software. But take a look at the following diagrams:

If you’ll pay attention, you’ll notice that those processes talk about everything except how to actually build software. They talk about people, about requirements, about managing customers, about a whole lot of things, but not about the part where you have people sitting down and writing code. In most of those, in fact, that part is usually defined as one of those:

Why is that a problem? After all, isn’t there a big distinction between software engineering (we know what to do, now let us do it) and project management (getting to know what we need to do, and verifying that we did it right). Those processes deal primarily with project management and leave the engineering part to be defined in a way that fit that particular project. Surely that is better, right? In theory, it might be. But there is a big problem when you have a software process that ignore the software engineering aspects of building software.

The problem is that that in many cases, there are hidden assumptions that are going to hammer you down the road if you use a certain process with engineering practices that doesn’t fit it. Take a look at the following chart, showing a team velocity over time, does this look familiar?

The term I heard used for this is Scrum Wall, but I have seen similar results in other processes as well. The best description for that is Allan Kelly’s:

You hit the Scrum wall when you adopt Scrum and everything goes well, then, after a few Sprints things don’t work any more - to use an English expression, they go pear shaped. You can’t keep your commitments, you can’t release software, your customers get annoyed and angry, it looks like Scrum is broken.

This is what happens when you adopt Scrum without technical practices such as Test Driven Development, continuous integration and refectoring. When teams adopt the Scrum process, they go faster, show progress, things look good... and then the quality becomes a problem. Now the team are fighting through quick sand.

The code quality is poor and developers are expected to continue to make progress. Maybe the Scrum Master/Project Manager reverts to past behavior and demands overtime and weekend working. Maybe the team start busting a gut to keep their commitments. Either way the team is heading for burn-out.

The major issue is in focusing so much effort and time on project management with what amounts to willful ignorance of the technical and engineering practices will inevitably leads to disaster. The process of building software is intractably linked to the engineering practices involved in building the software. Moreover, some technical practices are actively harmful in some scenarios and life savers in others.

Many Agile and post-Agile processes focus on short cycles, each of them producing something with a distinct value to the customer. That may be an iteration, a commit or a feature, where the goal is to increase the velocity over time so we can provide as much value to the customer in as short a time as possible. What those processes ignore are things like technical debt, large scale refactoring and non functional efforts. Oh, you see those things mentioned on the edge, but they aren’t something that is dealt with heads on, as a core issue to consider.

There is a bit more to that, actually. The software engineering practices and the project management strategies are linked and of paramount importance when the time comes to decide how the software should actually be built. No, this is not tautology. We just need to take into account Conway’s law and expand on it a bit.

Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure.

Part of the design process of a project should include design the team(s) structure, the project management strategy and the software engineering practices in order to align the end result with what is desired. Ignoring this leads to imbalance in the project, and if that imbalance is big enough, and goes on for long enough, the project is going to rip itself apart.

* Nitpicker corner: I said many, not all. Don’t bother to list me software process that deals with it. I had a reason to explicitly list the processes that I did.

WPF WebBrowser and JavaScript interaction

Ayende Rahien — Fri, 15 Jan 2010 10:00:00 GMT

I found myself needing to interact with JavaScript API in a WebBrowser hosted in a WPF application. That turned out to be quite a challenge to figure out, but I prevailed :-)

Given the following XAML:

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Grid>
      <WebBrowser x:Name="Browser" />
    </Grid>
</Window>

You can interact with the JavaScript API using this code:

public partial class Window1 : Window
{
    public Window1()
    {
        InitializeComponent();
        Browser.LoadCompleted += BrowserOnLoadCompleted;
        Browser.Navigate(new Uri("http://example.com"));
    }

    private void BrowserOnLoadCompleted(object sender, NavigationEventArgs navigationEventArgs)
    {
        var doc = (HTMLDocument)Browser.Document;
        var head = doc.getElementsByTagName("head").Cast<HTMLHeadElement>().First();
        var script = (IHTMLScriptElement)doc.createElement("script");
        script.text = "alert('hi');";
        head.appendChild((IHTMLDOMNode)script);
        script.text = "alert('bye');";
    }
}

This allow you to inject JavaScript commands to the browser by manipulation the script.text property. It isn’t generally useful, I’ll admit, but for my scenario, it seems to be doing the job.

My Java Experience

Ayende Rahien — Thu, 14 Jan 2010 10:00:00 GMT

As I mentioned before, I am actively trying to find what I don’t know, and plug it. As part of that endeavor, I spent the last week learning Java EE. I decided that in the interest of saving time I am going to invest some money and I took a week long course in it. That allowed me to kill several birds in a single stone, I got to experience Java in an environment that had an instructor that I could call on for help, it allowed me to learn Java EE and it allowed to me experience how people using Hibernate Profiler feel like.

Now that it is over, I can say that the course has met my expectations to a T. But that isn’t the point of this post. I wanted to talk about what I learned and my experience.

Nitpicker corner: please note that I am talking only about Java EE and EJB 3.0. I am well aware of the existence of frameworks that build on top of that (and earlier versions), but right now I intend to discuss Naked Java EE.

From language perspective, working with Java was incredibly frustrating. I had not really realized how much I come to rely on such things as object initializers, the var keyword or null coalescing operators.

As a platform, I have a much better understanding for how the Java EE eco system developed. Basically, it works like this (the concepts does not translate exactly, mind you):

Java EE	.NET
Servlet	Http Handler – but with singleton semantics & with threading issues.
JSP	ASPX – but without any code behind.
Listener	Http Module

One of the things that really drove me crazy is the notion of making everything a singleton. I wonder if there was a time where object creation in Java was very expensive, that might result in this design. The problem in making everything a singleton is that it become shared state, which means that you need to handle concurrency yourself. This is a bad thing. In fact, I would go further and say that any framework that requires users to handle concurrency for standard scenarios is flawed.

When I learned that you had to wire each independent servlet in the web.xml, I was quite shocked. The sheer friction that this is going to add to a project is mind numbing. Imagine the camera unzooming, and the full picture showing up. There are usually very few servlets in an application, often only one. They handle the request by sending the data to an EJB to handle the business end and a JSP to handle the HTML generation end. If it sounds a lot like MVC, it should. The interesting bit is that I don’t think that all the Java MVC frameworks came out because of anything unique in the Java sphere. They came out of sheer self defense out of the amount of toil & trouble that you have to go through using what the bare bones Java EE gave you.

Moving on to what I would call the controller side of things, we have EJBs, Enterprise Java Beans. There are Session Beans and Message Driven Beans. The MDB reminded me quite strongly of a very basic service bus. Considering something like Rhino ServiceBus or NServiceBus, it looks very similar in concept and execution, but without a lot of the things that the those two do for you. Session Beans are supposed to handle requests, they are divided into stateful and stateless beans. In general, I seems that you would generally use the stateless beans.

A stateless bean is a class implementing a specific interface, and that is where a lot of the interesting things are happening, dependency injection, automatic transaction management, session management, etc. It is interesting to note that with .NET we have gotten to the same result, but without having the overreaching presence of the container everywhere. I really like the fact that there is no attempt to disguise how they are doing things, the Java’s language decision to make everything virtual by default has really paid off in here.

Still, I can’t say that I like the default architecture, it seems very inflexible. I do like the ideas of full blown servers that you can just deploy a file into. It is a very nice concept, but it has some sever downsides, the time that it takes to do a modify-deploy-test cycle is significantly larger than what I noticed on the .NET side of things. And keep in mind that I am talking about projects that had about 5 classes in them all told.

During the course, the instructor said something that I found very insightful, “the tooling help you deal with… [wiring the xml, inheriting from the appropriate interfaces, etc]”. I found this very telling, because up until then I was quite puzzled by the behavior of all the standard wizards in Eclipse. They seem to violate the KISS principle, especially after getting used to the Yes, Dear experience when using R# on VS. It was only after I realized just how much work those poor wizards had to do for me that I understood what was going on.

After the course, I took a look at some of the MVC frameworks in the Java market. Just reading the tutorials is fascinating, from a code archaeology perspective. You can clearly see that Struts came early on, since while I am sure it is an improvement over Naked Jave EE, the amount of XML you have to deal with is not funny.

All in all, I find myself unimpressed by the amount of work that was shuffled to the tools, it doesn’t seem right. And it seems like a justification of a bad practice. When I consider my own design principles (Zero Friction!) in light of this, I am much happier that I am mainly working in the .NET world. But I think that having this understanding is going to be very helpful moving forward.

As to the methods there may be a million, but principles are few

Ayende Rahien — Mon, 11 Jan 2010 10:00:00 GMT

I run across the following quote a while ago, and I found it quite interesting.

“As to the methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.”

- Ralph Waldo Emerson (1803-1882)

I have been programming, in one form or another, for about fifteen years, but I can put my finger on the precise moment in which I moved from a mere dabbler to a professional. That was in 1999, and I decided that I had enough of toying with Pascal, VB6 & Java Applets. It was the height of the bubble, and I wanted to learn just enough to be able to get a job doing something that I enjoyed. I had about a year opened to me, and I registered myself to a C/C++ course in a local college.

In hindsight, that was one of the best things that I have ever done. That course taught me C and pointers, and then C++ and OO. I also introduced me to concepts that I have been using ever since. Admittedly, I don’t want to look at any of my code from that time period, but that is probably a good thing :-) The most important part of the course was that it taught me how computers work, by introducing C first and forcing me to write my own implementation of any system call that I wanted to make.

I studied programming in High School as well, and I distinctly remember being utterly and completely baffled by strange things like dynamic memory and pointers. I mean, why don’t you just allocate a bigger array. During that course I actually grasped pointers for the first time, and even looking back over the last couple of weeks, a lot of my performance work recently is directly based on things that I learned there.

After completing that course, I got several books to help me understand the fundamentals better. Operating Systems Design and Implementation, Modern Operating Systems and Operating System Concepts to understand how an operating system works, not just a single program. Win32 System Programming, which I read mainly to understand the environment in which I was working and Windows Sockets Network Programming, from which I learned the basic concepts of networking.

The common thread throughout all of them is that initially I focused on understanding the technical environment in which I was working, getting to understand how things are working at a very low level. And while it may appear that understand those low level details would be nice in terms of general education but have little relevance to where I am spending most of my time, that is quite inaccurate. The recently built serialization system built for the profiler was heavily influenced from my reading of the OS books, for example.

For that matter, other good books are Practical File System Design, talking about the BeOS file system, which I found utterly fascinating or Virtual Machine Design and Implementation C/C++ which is a horrible book, but one that gave me the confidence to do a lot of things, since I saw how trivially simple it was to build such things.

Coming back to the quote in the beginning of this post, understanding the underlying principles has allowed me to do approach a new technology with the confidence that I understand how it must work, because I understand the environment in which it works. Oh, there are a lot of details that you need to get, but once you have the conceptual model of a technology in mind, it is so much easier to get to grips with it.

Interestingly enough, I only got to software design books at a much later stage, and even today, I find the low level details quite fascinating, when I can get new material in a subject that is interesting to me.

The problem with compression & streaming

Ayende Rahien — Sun, 10 Jan 2010 10:00:00 GMT

I spent some time today trying to optimize the amount of data the profiler is sending on the wire. My first thought was that I could simply wrap the output stream with a compressing stream and use that, indeed, in my initial testing, it proved to be quite simple to do and reduced the amount of data being sent by a factor of 5. I played around a bit more and discovered that different compression implementation can bring me up to a factor of 50!

Unfortunately, I did all my initial testing on files, and while the profiler is able to read files just fine, it is most commonly used for live profiling, to see what is going on in the application right now. The problem here is that adding compression is a truly marvelous way to screw that up. Basically, I want to compress live data, and most compression libraries are not up for that task. It gets a bit more complex when you realize that what I actually wanted was a way to get compression to work on relatively small data chunks.

When you think how most compression algorithm works (there is a dictionary in there somewhere), you realize what the problem is. You need to keep updating the dictionary while you are compressing the stream, and at the same time, you need the dictionary to uncompress things. That make it… difficult to handle things. I thought about compressing small chunks (say, every 256Kb), but then I run into problems of figuring out when exactly I am supposed to be flushing them, how to handle partial messages, and more.

In the end, I decided that while it was a very interesting trial run, this is not something that is likely to show good ROI.

Production profiling security considerations

Ayende Rahien — Mon, 04 Jan 2010 19:06:00 GMT

I am currently in the process of building support for the production profiling. The technical part (how to reduce the footprint of the profiler when not profiling) is pretty easy, and I spiked it out in a matter of a few hours. The non technical part has been driving me mad for days.

One of the major issues that I have to deal with with regards to production profiling is the issue of security. There are actually multiple levels to this issue. The most obvious one is that we want to secure who can start profiling. Initially I thought that providing a password and limiting IP range that can connect to the profiling endpoint would be enough, but I quickly realized that I am being overly naive.

The idea that someone can just hook into all the communication that goes on with the database is something that will give any security analyst heart palpitations. Not only do I need to secure access to the endpoint, I also need to ensure that no one can sniff this traffic, as it might very well include sensitive information. Beyond that, just to make sure that the aforementioned security analyst doesn’t show up at my door armed & pissed, it is important that only the system administrator (and not the developers) can turn that on.

That one isn’t so much to catch maliciousness, as much as to prevent people from deploying to production with their debug configuration enabled, but will also stop malicious acts of trying to open up holes in the application.

After some investigation, I decided that I probably want to use SSL (and the SslStream implementation in the BCL) to do that. This has several advantages, it means that the network traffic is encrypted and I can ignore that aspect. It also means that I can take advantage on mutual authentication to ensure that the client is really authorized to do connect to me. Finally, I can also require that the certificate will be installed on the server machine, thus meeting the requirement of the system administrator having to take an explicit step to allow it.

From design perspective, it looks nice, so the next question was to write some code to spike it. I should preface everything that follows with the admission that I have only rudimentary knowledge of the actual details of SSL and certificates. But basically, what I thought was to have the following:

Server certificate – self signed, server auth, bound to a particular hostname, not CA.
Client certificate – self signed, client auth, bound to a particular hostname, not CA.

The client certificate would need to be added as a trusted root on the server. That would allow mutual authentication between the two parties. The server will reject unknown certs or ones that do not bind to the same hostname as the server cert. I am not sure if I should require that the server cert would have to be installed on the client machine, but I am leaning on not requiring that.

Thoughts? Anything else that I might need to think about? Is this scheme really secure? Is it going to cause the ops people to go mad?