Something Smells

If you recieve the "Invalid type owner for DynamicMethod" error while initializing you NHibernate SessionFactory then it's pretty likely that you are using generic methods on some of your lazy loaded/proxied classes. Nhibernate incorporates a reflection optimization that speeds up the creation of proxy classes. This reflection optimization does not play well with generics. The error it throws is "Invalid type owner for DynamicMethod". Not very friendly. So, to fix this you must either stop using generic methods OR turn off the optimization. To turn off the optimization you must run the following code before you initialize your SessionFactory. NHibernate.Cfg.Environment.UseReflectionOptimizer = false;

Not sure if I posted my interview done by Rustici: http://scorm.com/blog/2011/04/interview-with-dan-pupek-chief-systems-architect-at-advanced-systems-technology/

I was very pleased to find this. Been using it as a reference: http://www.albahari.com/threading/

Been playing with FFMpeg and Mencoder to create videos from a list of Images and an audio file. Here is the command I used: ffmpeg -loop_input -vframes 50 -f image2 -i foo-1.png -r 10  foo1.avi ffmpeg -loop_input -vframes 50 -f image2 -i foo-2.png -r 10  foo2.avi ffmpeg -loop_input -vframes 25 -f image2 -i foo-3.png -r 10  foo3.avi ffmpeg -loop_input -vframes 25 -f image2 -i foo-4.png -r 10  foo4.avi mencoder -audiofile foo.wav  -oac copy -ovc copy -o output.avi foo1.avi foo2.avi foo3.avi foo4.avi

So, if you are using the ActiveRecord/NHibernate stack I highly recommend switching to query over. The syntax is cleaner and it's type-safe. Here is an example of a criterion based query: Here is an example of the same query in QueryOver: Unlike the Linq language for Nhibernate QueryOver is just a translation layer for Criterion.

I was having some trouble getting my ListBox items to stretch across the entire ListBox. I did not want to get into the game of dropping into code to fix layout issues. Here is what I had to do. This first attempt did not work: I had assumed that the HorizontalContentAlignment attribute would do the trick. For most controls it does. I was wrong. Here is what I finally had to do: Notice the addition of the container style. As far as I can tell this is a bug. I found the original answer here .

Recently our [BelongsTo] relationships in ActiveRecord with the Lazy = FetchWhen.OnInvoke have stopped lazy loading. This caused some massive performance problems. Suddenly entities that were not supposed to be loading unless invoked were loading all of the time.  I've been struggling with this for a couple days and just now found the answer. Here is the property definition in question: Normally, when retrieving an instance of "SomeEntity" the HomePage property would not load until it was accessed by some code. Two days ago, using the Nhibernate Profiler, I noticed that HomePage was being loaded...all of the time. I tried so many possible solutions and searched for a possible answer until I came across this article . It turns out that when you set NotFoundBehaviour=NotFoundBehaviour.Ignore on a BelongsTo relationship it circumvents the lazy loading and loads the entity anyway. I also found a bug that has been posted for this as well. Although the link rarely...

Some time ago, I was reading a great page on the C2 Project Wiki about Death March Values . This is in no way implying that we have this problem here...but these are habits we should not fall into. The basic concept is that some organizations have a subculture that continues to employ self-destructive values over and over again. Here are a few indicators that you may be in one of these organizations:  Business Value Desicion Makers (BVDMs) want the "magic" of software without considering the work involved, "ProductWithoutProcess".  BVDMs reward the guy who stayed up all night fixing a bug while the guy/gal who's code always works the first time gets little recognition. The Hero Programmer Young Hotshot Programmers fall in love with a product "Project Love Affair", take little time to consider the broader picture and fail to employ the Practices. In most organizations you can insulate against the Death March Values by not accepting the status quo...

found originally at  Courtney Hentz (CHentz@spinner.com) Specifications are for the weak and timid! This machine is a piece of GAGH! I need quad PowerPC processors if I am to do battle with this code! You cannot really appreciate Dilbert unless you've read it in the original Klingon. Indentation?! I will show you how to indent when I indent your skull! What is this talk of `release'? Klingons do not make software `releases'. Our software `escapes' leaving a bloody trail of designers and quality assurance people in its wake. Klingon function calls do not have `parameters' - they have`arguments' - and they ALWAYS WIN THEM. Debugging? Klingons do not debug. Our software does not coddle the weak. I have challenged the entire quality assurance team to a Bat-Leth contest. They will not concern us again. A TRUE Klingon Warrior does not comment his code! By filing this bug you have challenged the honor of my family. Prepare to die...

*** UPDATE Dec 20, 2010, We ended up using the tool MadCap Flare . I'll post some pros and cons later *** So, we just hired a new documentation specialist. We're looking at a tool named Help Studio . If anyone has any suggestions please let me know. I intend to treat her as any other developer ( a pig ). Currently our workflow is: Engineer Resolves Case to QA and QA Closes case. The new workflow that we will try out is: Engineer resolves case to Documentation, who then resolves to QA, who then closes. Over the next couple of weeks I will write more about how things work out.

Recently, we have begun dividing our work amongst several teams on different branches. This prompted us to start moving from Subversion ( SVN ) to Mercurial . We have actually had great success with Subversion (SVN). We moved from CVS several years ago and have never regretted it. With it's improved rename and move support and cleaner branching SVN was an easy decision. Now we find ourselves, once again, pinning for the capabilities of a Version Control System that we don't have. We are also in the throws of moving build servers from Luntbuild to Hudson . So, over the next few posts I'll discuss our experiences with moving from SVN to Mercurial.

Just read an article about COBOL.Net .....who would really want to subject themselves to this horror. Let's take the sample code in C#: private void button1_Click(object sender, System.EventArgs e) { button1.Text = "Call COBOL"; } Now here is the same method in COBOL: METHOD-ID. button1_Click PRIVATE. DATA DIVISION. LINKAGE SECTION. 01 sender OBJECT REFERENCE CLASS-OBJECT. 01 e OBJECT REFERENCE CLASS-EVENTARGS. PROCEDURE DIVISION USING BY VALUE sender e. SET PROP-TEXT OF button1 TO "Call COBOL". END METHOD button1_Click. Am I the only one that finds this maddening. OK, OK, for the record there are still more lines of COBOL running then any other language. It could be that COBOL is just that great or it could be the fear of re-engineering systems are working just fine. Any thoughs?

First, I see 2 reasons to refactor: Improve performance Make code easier to maintain (and extend) Most other " reasons " that people use to justify refactoring are only a means to one of the 2 ends stated above. If you aren't ultimately reaching one of those ends, then reconsider refactoring. If your changes are to the detriment of one of these 2 means, then don't refactor . In fact cargo cult refactoring can be more harmful than helpful. Think about these: Not all duplication is bad. Some blocks of code are more self explanatory then an oddly named method that wraps it. Saving 6 lines of code may come at the cost of flexibility and higher levels of coupling. Overly abstract code can become highly unmaintainable, even cryptic. In an effort to write more concise code we inadvertently write less concise code. Specialization can be a good thing. Astronaut APIs can be bad. and of course... premature optimization is the root of all evil ! Just a few things to think about...

I'm not sure if I agree with this " article " but, it is somewhat related to a discussion my boss (Dr. Rob Miller) and I were having earlier today. Ideally, we would like to focus every third (I just picked a number) release on "bug hunting" or finding and fixing bugs. Unfortunately, bugs are often a debt we live with for a long time, in the face of progress and new features. I have known few products that didn't have some glitch and the promise of new features often takes some of the edge off of these glitches. Conversely, some bugs can leave users with such a bad taste that they never quite trust your software again. In the article above the author describes a bug that was reported fixed but still remains broken....after 2 years. Furthermore, as more bugs slip through the cracks a system can slowly become more and more unstable. This suggests that, when planning product releases, stakeholders should balance the need for new features with the need for a sta...

I recently purchased 4 licenses of Ayenda's excellent Nhibernate Profiler for my office. The tool truly is amazing. The real time metrics provided by the profiler have already helped us improve the performance of our applications and identify some not very efficient database calls. Here are a few features that we really like: Realtime view of queries being sent to the database. This information includes a stack trace and properly formated SQL! You also get to see if the entities were pulled from the query cache, level 2 cache or directly from the database. The SQL view can really expose some nasty databse calls. Number of sessions opened. The queries are broken down by session. You can see how many queries each session makes and a mirad of statistics. Unique Query statistics. NH Profiler offers an aggregate view of how often each query was called and the average time it took. This is invauable information for improving performance. This tool offers a ton of other features that we...

A while back Oren wrote about the Arrange, Act, Assert syntax for unit tests. I've seen several other discussions on this and I am not sure if he is the originator but I'll attribute him either way. The syntax I most commonly use ressembles an Arrange, Assert, Act and Assert (AAAA) pattern. Arrange the system in it's initial configuration. Create any collaborators and mocks you may need. Initialize services. Assert that the initial state is correct. For me this is important since so many layer of dependencies exist in modern applications. This is analogous to a control group in the scientific method. In this step I would also test the inverse of later assertion such as the non-existence of objects that should only exist after the Act step. Act on the system by creating/deleting/updating new objects or invoking services. Assert again that the system is in it's expected state. I've caught a lot of bugs using this method. Asserting the initial state may also be a good...

Memcached for Monorail is a session replacement for the Castle::Monorail framework. It uses memcached on the back end for distributing the session across a web farm. I have added some additional notes about Memcached for Monorail . I have also uploaded a binary release . Although I recommend getting the source . No time to discuss much more but feel free to ask questions and I'll answer them. The Memcached session provider is currently being used in a production environment with great success but it definitely has room for improvement. It's aimed squarely at extending the Castle::Monorail session so if you are looking for something more generic than please look else where...or consider switching to MVC with Castle::Monorail ;-)

Installing Castle::Monorail on 64bit IIS7 proves to be much easier than I thought. You must use the 64bit handlers. To make this easy you can just add the handlers to your Web.Config: 136 system.webServer > 137 handlers > 138 add name = " IconHandler " path = " *.ico " verb = " * " modules = " StaticFileModule " resourceType = " File " /> 139 add name = " Monorail-64 " 140 path = " * " verb = " * " 141 modules = " IsapiModule " 142 scriptProcessor = " %windir%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll " 143 resourceType = " Unspecified " /> 144 add name = " Monorail " 145 path = " * " verb = " * " 146 modules = " IsapiModule " 147 scriptProcesso...

Javascript has 2 basic forms of comparison operators : === and == . == is the standard equality operator while === is the identity operator. The equality operator will perform casting and usually test both sides as strings. The identity operator compares the value each side the type, but it does not work like instanceof. Recently we did some experiments with the different return values. The Expressions Expression Result "test" == "test" true "test" === "test" true String("test") === "test" true new String("test") == "test" true new String("test") === "test" false new String("test") === new String("test") Before Firefox 3.0.1: true After: false new String("test") === String("test") false Here are some type tests we performed Expression Type typeof("test") "string" typeof(String("test")...

I believe my team of engineers has been very successful. This is no accident. I look for, and like to, surround myself with smart people. I'm not being egotistical. I don't consider myself the sharpest tool in the shed, but I do know a sharp tool (smart engineer) when I talk to one. Hiring the right person is harder than it sounds. The top two impediments, in my experience, to hiring the right person have been " Hiring People that are Non-Threatening " and " knowing nothing about the job you are hiring for ." Non-threatening can mean a lot of things. A non-threatening person can be a yes-man. Yes-men will agree with you on everything and never make you uncomfortable by pointing out flaws in your plan. Yes-men are often hired on the basis of philosophy rather than actual skill. Non-threatening people can also be that dull-tool that won't outshine the person who hired them. In both cases the company is stuck paying wages to an under performer. More often, ...