Booish is a command interpreter for the Boo language, this means that it gives you the full power of Boo and the .NET framework at your finger tips.

I just needed to find the number of methods in mscorlib:

The result:

Continuing with the theme of showing off and building clones of the Microsoft's demos in hours, Anders Norås has just posted Mean Fiddler, an implementation of REST API for NHibernate, similar to Microsoft's Astoria project. Nice work.

Just run into this project, another port from the Java Land, which looks really interesting. Basically, it is a job scheduling framework. I have need of that in a previous application - which meant that I had to write a simple version of that, and I was very happy with it, until I realized that I had a convoy issue that was so severe that it killed the application under heavy load (discoveed 6 months into production, naturally).

In my current project, there are quite a few things that I mark as "TODO Later", which are all sorts of maintenance tasks that I would like to run. I can probably build something simple based on Timer, but that has already proven to be problematic at times. I don't know about the level of the project (or much about it, frankly), but it looks like there are some interesting things there, such as the possibility for persistent jobs, which would make my life easier. It looks like it is not implemented yet, but work on porting has started.

From cursory look, it looks interesting enough to take a deeper look, and the site has good documentation.

No mailing list, though :-(

Craig Freedman has a few posts that explains some of the pitfalls of the different isolation levels, very interesting stuff:

• Read Committed Isolation Level
• Query Plans and Read Committed Isolation Level
• Repeatable Read Isolation Level

A developer really should understand the implications of this, it is tripped me in the past, rather painfully.

There are many tools that tends to work only with DataSets, the most often cases are reporting tools or data driven systems. I consider this an issue with the tool, usually, but this is a fact of line. Case in point, I want to display a report of customer objects, I say objects here because I retrieve them through an NHibernate query + business logic that can't really be done in a stored procedure.

At the end, I get a collection of customer objects, and I need to pass that to a reporting tool that can only accept a DataSet, this means that I need to translate an object graph to tabular format.

Here is my secret technique to do this:

Sorry that it isn't magic, just the simplest solution that could work without writing a whole new data source adapter for the tool.

Just finished writing some fairly complex reports. The reports are complex enough that I decided that it isn't worth my time to try to build a stored procedure to do it, and I simply used NHibernate to get the data. The simplest report had 14(!) parameters, but the main issue was handling security and running business logic as part of the report. (Specifically, a lot of date calculations).

To be clear, I am talking about using NHibernate as a data source for a report, not generating the report itself. That is done with reporting services, which is talking to an NHibernate backed Web Service. Of course, this has the predictable result of:

I had a chat with a pal of mine recently, about why he would recommend working with Web Forms over MonoRail.

The short answer was that he didn't want to end up with an ungooglable exception. The reasoning is that there isn't any nook or crany in Web Forms that hasn't been discovered, talked about, solved, and most importantly than all, indexed by Google.

I don't agree with this approach, but I recognize that this is a valid way of operating. The major reason that I don't agree with this is that I have run into issues with ASP.Net that were essentially un-googlable and undebuggable.

Castle currently has four or five major projects ( I was surprised myself, I expected it to be at least a two digit number ).

Learning each of them by itself is not hard, at least not in the "good enough to work with and learn on the job". Getting to a master level isn't any harder than in any other technologies, it just takes time and experiance.

There are certainly quite a few more experts in Web Forms than about MonoRail, but I find that I have to struggle to get what I want a lot less in MonoRail, and I get into far less situations that require the use of an expert. One of the core principals of Castle is that it should be simple. And by simple I don't mean the implementation, but the usage. It takes a minute to explain how SmartDispatcherController works, and any programmer can grasp how it can be used from three sentences. The implementation of the Smart Dispatching is quite complex, but you never need to see it.

One of the main differences between OSS and Commercial software is the amount of time that is invested in the frills. Active Record and NHibernate has a designer, which is nice, but it is not a level 1 priority to any of the people using either Active Record or NHibernate. The reason is that both those frameworks were built knowing that a designer is not something that you should need in order to work with them.

WebForms has a huge task on developing custom controls. Not only must the control play nice in the page life cycle dance, they also need to jump through many many hops in order to work in the designer. MonoRail's ViewComponents, on the other hand, are literally HTML generators, with no extra complexity on top of them. Again, the simple outward interface makes it easy to work with the frameworks.

Some of those things require a fair shift in thinking, but once you get comfortable with MonoRail, there is no steep learning curve until you get to Windsor integration, which simply require that you understand how IoC works. Instead, there is a lot of discovery going on, mostly with helpers, filters, and such.

Now, Castle's is built of many projects that are designed to be used independantly. But, they are also designed to work together. This means that the Whule Is Truly Greatly Than The Sum Of Its Parts. Taking Active Record, MonoRail and Windsor for a spin is a fun ride, but that require that you understand all three, and their interactions. The nice thing about it is that it is not that big of a jump from knowing them to working with them together.

To summarize, a basic working knowledge of Castle is probably something that you would want to have before you would start building applications with it. There are numerous getting started guides out there right now, which can help you grok what you are trying to do. I don't believe that you need an expert on hand to solve problems, looking at the forums or asking in the mailing list will usually get you the answers that you seek. There is also a lot of effort in making the exceptions detailed and self explenatory.

Naturally, I am biased, so I am not sure that my opinion in this matter counts, what do you think?

Just looked at the download page:

• First release: 02/07/2005
• 55 releases so far
• 26,339 downloads
• Most popular releases:
• Rhino Mocks 2.9.6 - probably because it was stable for so long
• Rhino Mocks 3.0.1
• 4,748 downloads for the Rhino Mocks screen cast
• 560 tests
• 10,069 lines, but:
• Only 4,436 lines of code.
• 4,684 lines of comments (98% of which are XML documentation comments)
• 13,193 lines of test, 8,635 lines of pure test code.
• Average full test run - 13 - 14 seconds.

Hm, only 4,436 lines of code for Rhino Mocks? I had met ASPX pages that had more code in them :-)

At least this time I managed to last a week. New release with a bunch of new features:

• Stubs are obvious in, here is my previous post about them and the documentation
• Added logging support for Rhino Mocks - this means that you can now get clearer information about what is going on, you can configure the logging using:
  
  RhinoMocks.Logger = new TextWriterExpectationLogger (Console.Out);
  Right now the implementation would simply write the method calls, but it is possible to generate "Expect.Call" syntax from the information (patches are welcome :-) ).
• Applied patch from Stefan Podskubka - adding List.Count and List.Element constraints.
  

  Expect

  .Call(query.SetParaemters()).Constraints(List.Count(Is.GreaterThan(5)))

  And:

  Expect

  .Call(query.SetParaemters()).Constraints(List.Element(2, Is.Equal(null)))
• Fixed an issue where the wrong count of expected calls is reported.

You can get the code and the binaries here.

From Wikipedia:

It may be because I am not a native English speaker, but to me the word innovation also carry the idea that the new thing that was created was novel, something beyond a mere evolutionary improvement of the existing.

Given that definition, it drives me crazy to hear Microsoft talk about innovation. The main issue that I have with that is that they seem to equate innovation with work:

Yes, they do some really cool stuff, but do they really need to use the word innovation for everything? Microsoft is doing a lot of things that I would consider as hard-code innovation, the problem is that they apply this word to anything from spell checking to a new icon to rounded corner on a grid.

</rant>