Hi, my name is Oren, and I am stupid. I forgot that select() ain't broken holds even if I wrote the select().

Let me tell you the story. We are using Rhino ETL to do ETL stuff, and one of the tasks that we had to do was importing an 80 MB file into the CRM, including all sorts of transformations and joins along the way. Until we got to that part, it was working very well, but with the 80 MB file, it read that and then appeared to be hung.

Rhino ETL is a new project, and it is heavily multi threaded. Since the only way that I know to test multi threading is by test of time, I wasn't overly confident that it got it perfectly right, and it looked like the 80 MB file was triggerring some threading issues. After debugging the issue futilely for a while, and after careless applying of lock() with reckless abandon also failed to do the trick, I decided that I had no alternatives, but to rip out the homegrown threading solution that I had there in favor of something with more robustness.

I choose Retlang for that, and I am really happy with the library, but that isn't the story that I have to tell today. As any who dealt with threading knows, they are complex, nasty and hard. Trying to follow ten threads at the same time in not helpful by any meaning of the word. And trying to replace the threading solution with a radically different model is hard. I have a post or two on big refactoring as a result of that, but again, this isn't the story that I have to tell.

After basing Rhino ETL on Retlang, and getting enough of the tests to pass in a satisfactory manner, I turned back to the real issue at hand, and tried to run the 80 MB file through the new Rhino ETL.

It. Showed. The. Exact. Same. Problem.

At that point, I was on the phone, speaking with the hiring managers about getting a thousand monkeys to type the information in, but I kept tapping the keyboard, probably out of a force of a habit. I couldn't believe that two such radically different implementations would exhibit the same problem. I added logging and tracked down everything. I even added color coded logs, just to be sure that I am seeing everything.

I tracked it down to a log statement that basically said:

Join CustomerWithFoodTypeLookup out 0 rows, Left 103,123 rows, Right 0 rows.

Take a look at this, and try to tell me what the problem is. 

We are joining an empty set to a non empty set, giving... an empty set.

The fix, if you can call it that, was to change the join to:

if Left.FooTypeId = Left.OldFoodTypeId or Right.FooTypeId is null

I rewrote the threading layer because I couldn't track down the root cause of a inner join instead of an left outer join. When I found that, I literally got up and started choking the developer responsible for the script. Then I went and hit myself on the head, repeatedly.

I am reading the Erlang book right now (post coming as soon as I finish it), but so far I have managed to grasp the idea of heavy use of recursion and functions for everything. It is very different from imperative languages, but I think I can make the shift.

Joe Functional, however, may have some trouble on the other way around. The following were found on production (but I'll not comment any further on their origin):

public static int CharCount(string strSource, string strToCount, bool IgnoreCase)
{
    if (IgnoreCase)
    {
        return CharCount(strSource.ToLower(), strToCount.ToLower(), true);
    }
    return CharCount(strSource, strToCount, false);
}

Let us ignore the inconsistent naming convention, the misleading function name are really think what this does...

public static string ToSingleSpace(string strParam)
{
    int index = strParam.IndexOf("  ");
    if (index == -1)
    {
        return strParam;
    }
    return ToSingleSpace(strParam.Substring(0, index) + strParam.Substring(index + 1));
}

The pattern continue, but at least I can hazard a guess about what this does, but I wouldn't want to pipe this post through it.

public static string Reverse(string strParam)
{
    if ((strParam.Length != 1) && (strParam.Length != 0))
    {
        return (Reverse(strParam.Substring(1)) + strParam.Substring(0, 1));
    }
    return strParam;
}

"Reverse a string" is something that I like to ask in interviews, but I don't suppose that this implementation will be found sufficient.

As I said, after the email exchange with Babylon, I was left with a sour taste regarding them. I have restored my key from a backup, and I have put the episode behind me, until a few minutes ago, when I go this dialog on my system. I was shocked, because I couldn't believe that someone like Babylon would get to these kind of tactics.

As you can see (the dialog below), I am a registered  user, so it is not "reminding" me that I need to register. This is an invasive advertising on my desktop and without my permission! 

There is a word for that, and that is called a spyware! 

You may notice the link at the bottom of the dialog, where it says that I can opt out by going to their site. I did, and it too me here (with a bunch of query strings that I stripped) where it asked me for a CATPCHA to un-register from this!

 WTF!?!?!

.

Just got (after three weeks) a response to my issue with them:

So, basically they are saying it is my fault (correct) and that I should deal with it (wrong). I am talking wrong in making me a happy customer. Every other company that I did business with was more than happy to resend me the license details, sometimes several years after the fact. The fact that Babylon is treating a customer like this is amazing.

Hiding behind "it cost a lot of money" is a sad excuse for someone who know how this stuff works. My response:

I would preface by saying that I am using Web Forms at my current project because the client insisted. They are paying, they get to make the decisions, end of story.

This is a rant, plain and simple. I don't do those often, but I have too much annoyances lately to not do it.

I have several years of working with Web Forms, in projects of various sizes, I have committed my Sins Against the GridView, and have memorized the page lifecycle, I have walked the path of Page.ProcessRequest, and learnt at a distant monastery about the mysteries of the ViewState, I have studied the intricate play of control's events and the secrets of Data Binding.

I get Web Forms. I know how they work.

I have detailed elsewhere what I don't like about WebForms (trying to be stateful, complex, lying, etc). Today it had gotten to the point when I have given up on trying anymore. This was after we have been hitting, repeatedly, obstacle after obstacle with using Web Forms.

Today we had no less than three such incidents, all of them related to various intricate ways that the whole messy pipeline is working together to create a results that is more complex than the sum of all its parts and the legacy systems on the next door. Today was far from being an exception.

We didn't even try to do anything complex. Take a bunch of objects, bind them to a GridView, rinse-repeat. There was a set of pages that were almost literally forms over data, exactly the use case for WebForms, or so I have thought. In a set of about a dozen pages, with really minor differences between one another, we had at least one serious problem at each page. Invariably it was related to some weird way WebForms expected me to work.

In order to get the data from the request, I need to bind the data again in page load, and in a later event, I need to process it, after the Web Forms engine had magically filled the values from the request. And woe upon you if you dare to mix a data source with a call to this.DataBind(); for you are heretic and deserve to lose the user's input without warning, and only by the grace of the good lord will you be saved.

At one point today I resorted to an http handler and a set of calls to Response.Writer(), because that was easier than trying to get the functionality from the WebForms engine.

At this point, I feel like I am trying to build on top of a house of cards, with the slightest movement will send everything crumbling down. I found a bug that was totally my fault today, and we had about five minutes of hilarity about finally finding something that we could easily fix. While this is a very instructive in terms of knowing how the internals of the WebForms engine works, it is a complete waste of time otherwise. When I need to be absolutely aware, at all times, about all the implications of what is going on all around me, I can't really do anything at all.

I have learned my lessons from past projects, thou shall not try to be smart with the WebForms framework, it will be smart right back at you and bit you in the ass. I am not trying to do anything smart here. I am literally scaling down everything that I do on the UI layer to the set of what is wholly approved and blessed by Microsoft. I am not even trying to workaround technical limitation, I am just trying to build working software.

At this point, I am more willing to debug Dynamic Proxy's IL generation engine than my pages, because at least with Dynamic Proxy, I have some control over what is going on, hard as it may be. The WebForms engine gives the illusion of control, but it does things in completely arbitrary ways, contrary to the principal of least surprised and common sense.

I am sick of it.

I just tried to visit this URL: http://pauloquicoli.spaces.live.com/Blog/ in FireFox, I get this message:

In IE, it works as expected. WTF?!

Update:

There are some things that programmers really shouldn't do. I was once called to help figuring out why a batch process would run for a few hours at 100%. The previous guy has claimed that this was a natural occurance of the task at hand (loading XML file to DB), and that he had already optimized it as far as possible.

After de-optimizing the code, I managed to get 10,000% performance improvement, and you could actually use the server for more than a single task.