Archive for the 'software' Category



Got Burned On Application Performance

It is hard to believe that after 6 years or so, I still find a bugs in legacy code. In this case, a database connection is not closed after finishing the request. To make a long story short, forgetting to close the connection really slows down the application, and performance goes to the toilet. Who would’ve thunk that?

The interesting fact is that I have been in the code a couple years ago to fix another issue, I missed the blatantly obvious flaw back then. As I think back, the reason that I missed it basically boils down to priority. I was not looking for a fix for a performance issue, but a bug in domain logic. The primary driver to address issues is usually something tangible or visible.

In these past few years, scalability takes a back seat to business needs. That is, until the application performance sinks to the point were users start to notice. That tends to put everyone under the gun and brings scalability immediately to the forefront. Suddenly, people start to pay attention to these issues and new initiatives start.

What I learned: always consider performance and scalability in mind as you start developing your application, no matter how much resistance you get.

Starting Python Again

After almost a three year break, I am starting to write some Python code again. I am experimenting on developing a RESTful part catalog web service. I last used Python when it was in version 1.5.2. I think that there have been many changes, because the page holding version 1.5.2 states quite frankly:

Do yourself a favor and get a more recent version!

Fair enough. I picked up version 2.5.1 for Windows. The install was quite painless. The most improved thing that I noticed was the revamped python.org web site. There is a lot more information now. I find this quite refreshing. I should have no trouble picking it up again.

So, why did I pick Python? Well, it was a tough decision. For the most part, Python was the right tool for this job. It was a written in a language that I am somewhat familiar with, it is portable, and gave the flexibility that I needed. I love other languages, but I found that the others did not quite fit the mold. For example:

  • I rejected Java right away because Java would take a lot more time that C/C++ in my case. The language is certainly as good as C#, but I am not as familiar with it as Python or C/C++. Additionally, the core framework is significantly larger than I remember. Like Python, Java has added features since inception. I have not touched Java in about eight years, so my learning curve will be very high. Today, there seems to be a lot better tools and frameworks to have ease the development pains, but it is not enough for me to give Java consideration.
  • I use C# and ASP.NET for my day job, so why did I not pick them? Frankly, it is damn tough to make a truly RESTful web service in ASP.NET. ASP.NET likes SOAP web services. Forcing ASP.NET to do a RESTful web service is like fitting a square peg in a round hole while having a root canal. In retrospect, it’s a blessing in disguise to me, because I prefer to use open source tools anyway. I do not want to give the impression of bias. I honestly did try to make it happen fairly recently. It was just not meant to be. Again, the tool was not right for this job.
  • C/C++ requires more investment in time. I have been programming in C family for years. I love it for it’s speed of execution and it is right against the metal. If I was creating Unix tools where execution speed is critical, C/C++ will be my absolute first choice. However, the compile cycles and the debugging become a deal killer for a web prototype. When I am rapid prototyping, I have a need for development speed, rather than saving a few cycles. Like many other high-level languages, Python still gives me many options to integrate and optimize using C/C++. So, if I need it, I will use this feature.
  • What about Lisp? I’ve coded a lot of Lisp for other applications and experiments. I have been writing a lot about Lisp in this blog. It was my second language that I learned.  So, it would be natural for me to just use Lisp, right? Well, not in this case.  Most likely, the code for this experiment will be sent to other developers.  They are more likely to be receptive to Python than Lisp.  There I said it.  I still believe that Lisp is the best language out there. But, being the best language is not the only reason to use it. Sometimes, you need to give in for the greater good.
  • Ruby and it’s poster child framework, Ruby on Rails, came a very close second. I said that my choice in Python was a tough decision. I like the Rails framework.  Rails is very RESTful.  I was blown away when I first encountered it.  The framework make development easy.  So, why did Python win?  Again, I am more familiar with Python than Ruby…and that is it. Python has a similar framework to Rails, called TurboGears. I give props to the Ruby clan to developing a great framework. It is so innovative that many languages have came up with clones.  So, it boils down to language familiarity.  Python won by a nose.

So, there you have it.  I picked Python for this project.  Hopefully, it won’t let me down. I’ll try to keep regular updates for everyone who is interested.

An Emacs-like Editor for .NET?

Douglas Purdy recently mentioned on his blog that his team was hiring testers for a project within Microsoft informally described as Emacs.NET. I am going to take a step back and think about that for a second. In this stage, why would Microsoft invest in such a project? Microsoft products did have some basic capabilities before, like Emacs-style key bindings in Visual Studio to named commands and such. There must be something more.

Could be that Emacs is the most versatile editor out there? Emacs users know all too well how flexible Emacs is. Many hack their favorite programming language in Emacs, some like to use Emacs as an application interface, while the elite execute shells that make them never have to leave Emacs. Users can customize their key mappings, customize the look, or even code their own custom commands. There are hundreds of different modes out there that help users create and edit even the most arcane file types. It is available for Unix, Windows and MacOS X and most modes and extensions are very portable.

The absolutely coolest aspect of Emacs is the interactive programmable environment. Emacs the only editor that I know at this time that allows you to create extensions for editor from within the editor itself and apply them immediately the current session. This flexibility within Emacs is made possible it’s powerful, built-in Lisp execution environment. Here is a quick example that I hacked up in a minute. In the scratch buffer in Emacs, I create a simple function:


(defun my-hello (msg)
"Prints hello message"
(interactive "sDestination:")
(message "Hello %s" msg))

then I select the region containing the function and execute M-x eval-region. The function my-hello is now applied and I can now execute it using M-x my-hello.

My big question: would a .NET version do the same thing? I doubt that there any Lisp involved, but interactively applying extensions in .NET seem to be tricky to me. So, I would imagine that extensions will be compiled to IL assemblies. If Emacs.NET contains an interactive compiler, things in the Windows world could get very interesting.

Paragent on Agile Development in Lisp

On the Paragent blog today, the authors of the newly open-sourced IT organization software talked about agile Lisp development for an article on InfoQ. Common Lisp provides a unique environment for creating software fast, especially if you have the right tools. For me, the super code ninja editor GNU Emacs with SLIME works very well. The system allows me to edit, compile, and test Lisp code fairly quickly. Paragent, on the other hand, created Cusp, an Eclipse plug-in for Lisp development. It basically has the same functionality as SLIME with some interesting additions.

One subtle item that I realized while reading the post is the speed of executing tests in Lisp. The relative quickness to execute a complete test cycle in Lisp is very fast compared to the mainstream environments such as .NET or Java. On those environments, compiling still takes a relatively long time, even though compiler may use techniques such as incremental compilation. Using SLIME, I could compile and test particular functions or regions fairly quick. On top of that, the unit test execution on traditional environments takes time to start up and tear down. I notice that a lot when I am coding in Visual Studio .NET 2005 at work. The code-edit-test cycle can be painfully slow. So slow that I feel the need to lengthen my edit time to avoid performing the tests. It’s not very encouraging, in my opinion.

So, the post made very good points about Agile programming in Lisp. It looks like Paragent is going to be a shining poster child in both the Lisp community and the Agile community.

Binary Code

What in the world does this mean?

00001001
11111001
00010001
00000010
10011101
01110100
11100011
01011011
11011000
01000001
01010110
11000101
01100011
01010110
10001000
11000000

Starting to Payback the Design Debt

For the past few months, I have been working on an extensive project
to “internationalize” one of our flagship products. This product is
slated to be released to the Canadian market by the end of this year.
Being a very old web application (going on five years now), this
product, at the time, exhibited some of the best qualities of what is
now known as AJAX: some form of XML handshaking, asynchronous
communication, and good responsiveness.

But, with a lot of legacy software, this product is suffering from a
very large design debt. I first heard this term from an
associate at work, and I am glad that I can associate what I been
feeling over the past couple of year to actual words. Essentially, a
design debt is a metaphor that describes the cost software incurs
when hurried (or outright bad) decisions are made because of time,
money, or other constraints, sacrificing the overall quality of a
design in the long run. Like any other debt, someone has to pay the
debt down.

Well, I am paying a lot of design debt right now. I have been
refactoring a lot of code over the last month or so. Because code is
shared across most of our applications in our product line, the risk
is somewhat high. Luckily, I had five years to think about it. Just
as I start to pay the debt down, it starts to go back up. Once again,
time constraints forced others to make some tough decisions in other
parts of the application.

I now come to the realization that we cannot completely dig ourselves
out of design debt without a significant change in our development
lifestyle. Just like a credit card with a high interest rate, we seem
to get trapped by the situation, feel like there is nothing we can do
about it, and eventually give up. Companies with a large accumulation
of design debt eventually will declare “design bankrupcy”. The toss
out the legacy application altogether and start fresh. For me, it’s
happening right now.

Since my employer uses only Microsoft technologies, design bankrupcy
was inevitable. ASP and COM is being replaced with .NET. Visual Basic
6.0, the language of which most of the backend code for products is
created, is now officially unsupported. A significant amount of code
was created in a proprietary language, and now we are scurrying to
create our next-generation versions of our product line using the
latest “killer framework”. No doubt that more design debt is
incurring, especially as Microsoft releases newer versions of their
.NET framework. So, it’s a vicious and endless cycle that needs to
be understood and controlled.