Home avatar

Thoughts and code

Code Leader – The Book

On my flight I had a chance to finish reading “Code Leader” by Patrick

image
image
Cauldwell. The book is a good source for ideas and concepts that “solid” developers should employ on a daily basis. Topics such as TDD, build vs. buy, CI, choosing the right tool for the right job, contract driven development, and much more.

The book goes over subjects showing tidbits of everything, and could be probably expended and extended at least several times more. But then it would probably become “Clean Code” and “Agile Principles, Patterns, and Practices” clone, which author probably didn’t want to create.

Quality Software

I am on my vacation, and not suppose to brag about software, but something has happened on my way to Israel, that just couldn’t go away silently. To get from Calgary to Tel-Aviv, I had to fly with Lufthansa for 9 hours first. The Airbus 340 is a decent plain. It’s flying, and it’s as comfortable as a Economy class can be. What blew me away was the entertainment system. Let me break this down.

Once You Have Tasted Flight, You Will Walk the Earth With Your Eyes Turned Skywards

Today, my friend Ran (no blog – boo!), has gave me a chance to feel what it is like to fly. Unfortunately, the weather conditions were not the best, and we could not do a lot, but the time spent up there was awesome. Feels great, and I wish I could do it more. Who knows, maybe I am discovering a new hobby in exploring the Z dimension :) Either way, a few pictures worth a long blog post.

With Power Comes Responsibility

In software like in a real life, not always everything can be extremely simple. One example I can think of right away is Inversion of Control container (IoC). In a simple application, it’s not a big deal, and normally achieved easily. The dependent component leverages some sort of Static Gateway container to resolve the dependencies based on contacts.

MIME Header - Content-Disposition

I am trying to figure out something on MIME header, and just can’t understand who is standing behind the RFCs. Are they trying to read it on their own and realize if it makes sense?!

The problem I am facing is attachments in another standard, RosettaNet, that is leveraging MIME for attachments. We are using a third party component to parse a RosettaNet message and load all the attachments. Attachments original filenames are supposed to be in the “Content-Disposition” property, marked as “Content-Disposition: attachment; filename=some_filename” according to the this WIKI. “But WIKI is not RFC” you say, well, read RFC 2183. It says

Wise Manager Words

The task then is to refine the code base to better meet customer needs. If that is not clear, the programmers should not write a line of code. Every line of code costs money to write and more money to support. It is better for the developers to be surfing than writing code that won’t be needed. If they write code that ultimately is not used, I will be paying for that code for the life of the system, which is typically longer than my professional life. If they went surfing, they would have fun, and I would have a less expensive system and fewer headaches to maintain.

NHibernate SessionFactory Lesson

Anyone who worked with NHibernate knows that SessionFactory is an expensive object, that better to be constructed once, cached and re-used to build lightweight and disposable NHibernate sessions. It’s always shows up as a warning in books (NHibernate in Action, page 35), WIKIs, blogs, etc.

Today our team had a chance to experience what a wrong handling of SessionFactory can turn into – a huge memory leak. SessionFactory is a heavy object, it’s initialization and allocation is not a trivial one. Each time SessionFactory is constructed, it uses a significant amount of recourses and holds to those. If SessionFactory is not cached as a single instance, each allocation causes to the overall memory leak. Combine that with luck of Session disposing generates a very interesting result – more than a gig of  memory for something that is barely 20 megs.