I am one of those fellows that tend to run on the trunk.

What does it mean?  It means that I am using the latest version of the source for my projects. So, I am on the trunk for Boo, NHibernate and Castle (which can be tricky, since Castle isn't on NHibernate trunk).

This has significant advantages for an active OSS project, NHibernate's trunk has the multi criteria support, MonoRail's trunk has the testing support, and since stuff is moving in response to the needs of the users, it is evolving fast. Sean Chambers was impressed by how fast this can happen in many cases. (In others, it is a slower process, but still mostly visible.)

There are some disadvantages, people (recently it was mostly me, sadly) can break the trunk, or commit functionality that breaks your code. In general, I have not found this to be the case for the projects that I am working on. A lot of the committers are running on the trunk as well, and there is a big pressure to make sure that the trunk is stable (ready to ship) because I, at least, do ship from it.

The major disadvantage here, from my point of view, is using a piece of code that is still under development or review. The recent case was Criteria cloning in NHibernate, which has gone through some modifications to get to its current form. Personally, I don't find it onerous to do so, and those are usually rare.

The big advantage is that you get continiously improvements. I does reviews of the changes every now again (now limited to scanning the logs and looking at what has changed) and it keep amaze me how much good stuff is going in there.

Alex has caught me red handed, opps, I went home last night and dropped to bed, doing only the necessary minor email preventance. I actually have something prepared that I want to post, but I just couldn't find the strength to finish it. (Later today, I promise.)

(Yeah, I got the joke)

This month I am at 114 posts (likely more when today is finished), which translate to ~3-4 posts a day, every day.

Do people actually read them? I have an unusual "is it worth a post" standard, and it is likely that I am producing noise.

I have been thinking about doing some delay posting, so you will get a post every time interval, rather than whenever I feel like posting. Thoughts?

Jamie Cansdale has just published the email corrspondance between him and Microsoft about TestDriven.Net on the Express SKU. Among other things, this has led to him losing him MVP status, pulling the TD.Net express, and more than a bit of angst. The clause that they are using is: "You may not work around any technical limitations in the software."

I strongly suggest reading the entire set of emails, and considerring that the clause they choose to use, that includes everything that they don't like, from key shortcuts to VS Macros.

In an eerily similar timing, Fowler manages to hit a lot of the stuff that I am feeling, and he is doing it much better than I could.

This paragraph has certainly hit a note:

That is one of the more frustratinng points in working in the Microsoft space, Microsoft is actively competing against its own community, and that diminishes the entire community (and Microsoft as well).

Okay, here is another exampe of using Cecil, but I think that you can figure out what I think about having to deal with raw IL.

Feel free to figure out what this does, and why I would be interested in such a thing. BTW, in Boo to Boo, that sort of thing so painless. Having to deal with the raw IL takes all the fun out of it.

I know about Cecil.FlowControl, but as far as I can find, this is mostly (only?) for reading assemblies. I am looking for a way to have a reasonable AST over cecil. This is not scalable no matter how you cast it.

Chris, compiler!

No, it is not a rant against some non OSS tool.

When I was at DevTeach, I talked with a few people that mentioned that their compnay has an... aversion to OSS and they wanted a way around that. Beind technical minded and a "rules, what rules?" types of guy, I suggested that they would take an OSS project (assuming the license allows it), and just rename the namespaces.

This is a possible approach, but it may be too much work in many cases. I suggested post compile weaving, and people looked at me as if I have grown two heads ( I didn't, I checked ). I just now remember this conversation, and wrote this little script with Boo and Mono.Cecil, which would take an existing assembly and rename everything from an old value to a new one.

Usage:

booi AsmReplace.boo Castle.ActiveRecord.dll Castle Tower

Now enjoy your Tower.ActiveRecord.dll :-)

Oh, and written in notepad on the command line while I waited for #Develop to be installed on a new machine.

Okay, I mentioned that I am working on fairly complex piece of query code, something that is completely off the charts, even for me. As such, I have completely test driven that. How do I Unit Test a complex query? By using in memory database (in this case, SQLite). NHibernate makes it very easy to switch databases, and I never gave it much thought after making it work for the first time.

Until today, where it was time to do an additional tweak to my query. It worked perfectly on the tests, running against SQLite, but failed when running the application against SQL Server. Here is the query that demonstrate the problem:

The generated query looked like:

This fails which unknown "addresses0_.Street" error, I run into the problem before, and I looks like a bug in SQL Server, or a nasty (appernatly undocumented) surprise.

This was my critical query, I had to run it. In desperation, I opened NHibernate source, and started debugging into it, in order to see how the query is being composed. Haven't looked very closlely at this area in a while, and things have changed somewhat, but I had that sinking feeling that it was one of those really big changes that I am really not ready to make close to the time that I want to go home.

Then I did something that I was sure would fail, I changed the query to:

It worked, produced SQL that would make SQL Server happy, SQLite was able to process this SQL without any issues either. Problem solved, and will hopefully remain in memory for the next time that I need it.

Oh, and if you didn't notice, today was a jumpy day. I am going to do some deep end stuff to relax.

Chris, this looks like it can take a long time :-) Keep it up, I enjoy the debate.

Chris responded to my tools post, where he said:

I disagree with this statement, leaving aside the fact that I am dealing with compiler stuff on a routine basis (NHQG, Brail, Dynamic Proxy, NHibernate - all have some aspect of compilers in them)*, I think that learning something by going to the lowest level of abstraction that can be had is the best way to really learn something, and this is regardless of whatever you are doing it on the academia or at work.

I should qualify that with saying that I am also a lazy person by nature, therefor I would tend to learn just enough to get myself out of problem. The problem is that I appear to be a contrary person as well, so I run into a lot of problems :-) I am trying to learn WPF for the last two months, can't find the stregnth to go through an excellent book when I already know the basics. (XAML has routing events and dependencies properties, everything else is lazy learned).

That is usually a reflection of the precentage of time that I need to devote to something, usually, and I am not doing a lot (any) WPF.

Also:

I seem to recall several episodes where the computer took things too literally, and things got really bad. Do you feel that you would like to be the person on call to debug this?

* Yes, I do know that I am probably not a representive sample of the developer population. I was already told to REPENT.

I just had left work with a potential big issue left open (big defined as - "we may need to re-write the entire UI layer"), I was very pissed off, to say the least. I had a problem with the ASP.Net Session not working in Ajax call back. I just made a significant architecture change that require that I would store some information in the ASP.Net session, and I didn't feel like having to either re-write it or the UI layer.

Googling wasn't really helpful, which only made me angier. At that point, I got sick of it and went home, thinking very bad thoughts about some @#$#@%%. On the ride home, I suddenly had the answer. The issue was only happening when I made a CascadingDropDown call to the server, everything else was behaving normally. CascadingDropDown is using a WebService to get the data from the server. Now I can't think of a good reason that a Web Service should have an ASP.Net session by default.

The moment I knew what the underlying problem was, it was seconds to find what the solution was, until then, it was nearly impossible.

Chris Holmes commented on my thinking for tools, but I think that he missed a crucial distinction that I made (but not clear enough).

If you require a tool in order to work effectively with something, this is an issue. By requiring a tool I mean something beyond VS + R#, which are the bare minimum stuff that you need to be effective in C# (it does says something on C#, doesn't it?). The Entity Framework Designer is a good example for something where I think that the dependence on the tools indicate a problem. I have been corrected about requiring the SCSF to work effectively with the CAB, which was good to hear.

Tools can make you more effective, but I think that you should always learn without them. Case in point, I am currently teaching people about .Net (I'll have a seperate post about it soon, I promise) and teaching them stuff like NHibernate or Active Record would be actively harmful for them at this stage, when they don't understand the basics of ADO.Net completely yet. In my opinion, it is always a good idea to know what the tool is doing, why, and where its shortcomings are.

Oh, and about the program in notepad thing, I don't program C# in notepad (usually), but I have written fully fledged applications in Boo from notepad and the command line. Boo makes it easy & painless to do so, and it is a pleasure (and painless) to work with it.