Archive for the 'Uncategorized' 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.

Halloween 2007

Ralph is a goth punk rocker.

For the Cleveland Browns fans: Bye, Bye, Charlie Frye

(Chorus sung to the tune of “American Pie”)

So bye-bye, mister Charlie Frye.
Was the player but sometime later,
he took a nose-dive.
And our hometown boys were drinking Miller and sighed
Saying, Brady’s gonna be our guy.
Brady’s gonna be our guy.

My First Real Ruby Program

I have been trying out Ruby for the past week or so. I finally had a need to create a quick script and I decided to use Ruby.

I like the comic strip Dilbert. In my Google Personal Homepage, I used Google’s internal link to add Dilbert to my feeds. However, I really hate the site. The advertisements drive me nuts. So, I decided to see what I can do to create my own feed.

So, my first real Ruby script basically:

  • Prepares a hash table, with dates (last 7 days) as keys and image URLs as values.
  • Connects to dilbert.com and get each day’s page.
  • Screen-scrapes image URLs for the comic, stores them in the hash table.
  • Use the hash table to generate an RSS XML document.
  • Connect to a web store via FTP and upload the RSS.

It’s not the greatest script, but it works:

#!/usr/bin/ruby

#
# dilbert_raw.rb
#
# Ralph Allan Rice
# ralph.rice @ gmail.com
# June 13, 2006
#
# Generates a raw RSS feed where entries point directly to the raw 'dilbert' strip.
#
# This source code is public domain.  Do what you want with it, but there is no warranty
# and I cannot be held responsible for what you do with this code.
#
#

require 'net/http'
require 'net/ftp'
require 'date'

# set scrape parameters
title = "Dilbert (Raw)"
description="Raw comic strip feed for dilbert.com"
webmaster="[Your Email Address]"
filename="dilbert.rss"
scrape_domain = "www.dilbert.com"
url_format = "/comics/dilbert/archive/dilbert-%Y%m%d.html"

# set up ftp parameters
ftp_domain="[your ftp server]"
ftp_directory="[your remote directory]"
username="[your ftp username]"

# Yeah, Yeah  encoding passwords in script is bad.
password="[your ftp password]"

# set up timing factors
now  = Time.now()
landing_map = Hash::new()
image_map = Hash::new()

# Create an array of the last five dates
dates = [0, 1, 2, 3, 4, 5, 6].collect { |x| now - (x * 86400) }

# Format a URL to scrape for each date.
dates.each { |x| landing_map[x]=x.strftime(url_format) }

h = Net::HTTP.new(scrape_domain, 80)

# Scrape the web, put results in new hash.
landing_map.each_pair do |key, value|
  resp, data = h.get(value, nil)
  if resp.message=="OK"
    found = data.scan(/\/comics\/dilbert\/archive\/images\/dilbert[0-9]+\..../).uniq
    if found.length > 0
      image_map[key] = "http://" + scrape_domain + found[0]
    end
  end
  # Don't take down the site, we can wait a few cycles.
  sleep(1)

end 

# Now create a rough RSS file.

File.open(filename, "w") do |rss|
  rss.print '<?xml version="1.0" ?>'
  rss.print '<rss version="2.0"><channel>'
  rss.print '<title>'+ title + '</title>'
  rss.print '<description>' + description + '</description>'
  rss.print '<pubDate>'+ now.strftime("%a, %d %b %Y %H:%M:%S %z") + '</pubDate>'
  rss.print '<webMaster>' + webmaster + '</webMaster>'

  # Print items
  image_map.keys.sort.each do | keydate|
    rss.print '<item><title>' + keydate.strftime("%A, %B %d, %Y") + '</title>'
    rss.print '<link>' + image_map[keydate] + '</link>'
    rss.print '<pubDate>' + keydate.strftime("%a, %d %b %Y %H:%M:%S %z")+ '</pubDate></item>'
  end

  rss.print '</channel></rss>'
end

# Now FTP the file up to the site

Net::FTP.open(ftp_domain) do |ftp|
  ftp.login(username, password)
  ftp.chdir(ftp_directory)
  ftp.puttextfile(filename)

end

A couple of the things you may notice about this code:

  • My use of blocks was not by accident. It is pretty straight-forward and acts alot like lambdas in Lisp. I like it.
  • I did not use any XML libraries to generate the RSS feed. I just like plunking down a XML stream by hand.

Not bad for my first attempt at Ruby.

Did I invent the idea of the XBox?

I was searching through Google Groups and found an old post responding to a person about his “game operating system”:

Good concept, but as a commerical product, I don’t see a reason for it. Why would anyone pay for a $1500 computer just to install a game OS. It is just as easy to buy a console, save $1300, and play ready made games. Now let say, you build a prototype console that used, let say a 486 processor, that was modified with built-in sound and had a port that was able to broadcast to a television (like a console) maybe we can find a use for all those old 486 chips that have been ousted from the homes of new computer users with Pentium and Windows 95 in their minds. Who knows.

Doesn’t my idea sound so familiar? It sounds like an XBox, right? This was way back in 1998! Well, I guess that’s what happens when good ideas go to the wrong people! 😉

How I Spent the Holidays

I am so sorry that I have not posted in a while. I have been so busy trying to finish up many projects at work before the long holiday. It has not been such a nice holiday for me, though. First, my boy Ethan has been sick with a viral infection, and the remainder of my family has been sick with colds.

So, I had a lot of time here and there. I decided to finally read Peter Seibel’s Practical Common Lisp. This book is also available online, but I recommend buying the hardcover (I think it’s worth it).

The book has 32 chapters of the basics of LISP and provides current and relevent examples. Hey, this is exactly what I expect from a book if it’s going to have the word practical in it’s title! The learning chapters was a great reminder of what I missed during the standardization process. The last time I really used LISP, the language was about to be standardized (circa 1992?). By that time, I was using two different LISPs. The first one, which I really do not remember the name of it, I was using in high school on one the few MacIntosh computers. I do not think it was MCL, because of the timeframe. If anyone has any ideas, I am willing to listen. Anyway, the second LISP was AutoLISP, which was the primary extension language of the popular CAD tool AutoCAD. I use to create a lot of useful functions with that LISP when I was working as a fire suppression engineer in the mid-90’s. So, when I started to get back into the LISP game, I was so flabbergasted that there were many standardized functions and concepts that were very new to me. All of them were addressed in this book.

For example, I read on the web that Common Lisp incorporates object-orientation via the Common Lisp Object System (CLOS). When I started to learn about it, I just kept on feeling that it was just going to be similar to the other statically-typed languages like C++ or Java. However, when I read the book, it gave me some great insight on how to really use classes. Not to just model real-life objects with physical properties and operation, but to do it dynamically via the use of macros. Chapter 24, entitled Practical: Parsing Binary Files is a great example of how Peter demostrates this. It really blew my mind!

But, I digress. I downloaded the source code from the book’s web site. However, I could not use the source code right away. I had a trouble using the code using CLISP, which I downloaded a couple months ago to hack around. I could not get the packages to load properly, so I searched around for a useful LISP system. Luckily, I was using Gentoo Linux and it uses a port of the Debian’s Common-Lisp-Controller (CLC) framework. I also decided to try another LISP implementation, Steel Bank Common Lisp (SBCL), because CLISP does not compile into native code. Once I got the CLC and SBCL installed, I was able to load the book’s packages right away. Awesome!

So, I spent my offline time reading the book and my online time hacking some LISP. I am still trying to (re)think like LISP, rather than trying to apply concepts from C++ or Java back to LISP. I just do not think it will work like that. Hopefully, I can start creating some neat new applications with LISP in the near future.

Calling a .NET ServicedComponent from VB6

I had some interesting problems this week. I have a series of .NET ServicedComponents that were hung up in the COM+. The client, written in VB6, calls a ServicedComponent via a COM interop multiple times, everything seems to work. However, the number of objects and activations increase with the number of calls. COM+ seems to keep the references active.

Apprently, after Googling the problem, it looks like it’s the client’s responsibility to call the overridden Dispose() method (from IDisposable) to have COM+ deactivate the object and destroy it. However, in the VB6 client, the interop on ServicedComponent occurs on a user-defined interface. The IDisposable interface is not available, so the client cannot explicitly call Dispose(). I personally think that this is a COM interop bug. So what can I do?

Well, lucky for me that my interop interface is very simple:

...
public interface ISomething {

 void DoCommand(string command);
}
...

I only expose one method in the interface, so I tried this little trick suggested by my friend Josh.

..
public MyComponent : ServicedComponent, ISomething
{
...

 public void DoCommand(string command) {

  ...
  ...

  // Final line:
  this.Dispose();
 }
}

That’s right. Self-destruction. For a simple, one-method interface, it works well. It gets more complicated after that. However, this method will need to work until Microsoft fixes the COM interop.

Single .NET Application Instance using Named Mutexes

I had a problem today where I needed to ensure that only one instance of a particular C# application was running. After trying some arcane methods, like using files or probing the Process list, I remembered a technique was back when I was programming in the WinAPI: Using Mutexes.

Here’s the general workflow. A named mutex in Windows is system-wide (as far as I know). So, one of the first things my application does is to create a mutex object. I happen to do this during static initialization:

using System;
using System.Threading;


public class EntryPoint
{
 static Mutex mutex = new Mutex(false, "MyApplicationMutex");

 ...

}

Now, inside the Main method, I would need attempt to wait using the WaitOne() method. But, I want this method to return right away instead of blocking, so I specify the timeout parameter to 0. The return value will tell me whether the my process was signaled or not. If it has not been signaled, this means that there is another process using the mutex. So, code-wise:

...

if (!mutex.WaitOne(0, false)) 
{
 Console.Error.WriteLine("Application is already running.  This 

process will exit!");
 return;
}

...

Finally, I need to ensure that the mutex is properly released:

...

 mutex.ReleaseMutex();

...

Viola!

Apple switches to Intel, my wife is pissed.

Apple Computer recently made the announcement that they will be switching from PowerPC chips to Intel chips starting in 2006. My wife is very pissed. You see, she hates PCs. She used to use the WinTel computers, but got sick of the viruses, spyware, and the overall feel of Windows. Her computer just kept on crashing. I had do everything in my power to stop her from throwing her computer out of our bedroom window.

So last year, We bought the 12″ Powerbook G4 laptop. She originally wanted the desktop model (Silversteam) with the cool flat-screen monitors, but the price was a little high. Plus, she was a grad student at the time and I suggested that the portability was an advantage. After praising the PowerPC architecture, the sleek design, and the operating system, she was hooked.

When I told her about Apple switching to Intel chips, she asked about how it would affect her. After thinking about it, I said “Well, nothing unless you buy a new computer”. Then I remembered why Apple was unique. Apple has a unique approach to user-oriented computing, but since they had a lock-down on hardware specs, nobody was able to clone them. It was almost destroyed by the WinTel monopoly, but bounced back because of their innovations. So, this switch leaves one question on my mind: OS X.

Apple claims that OS X is portable (because of it’s Unix base), but because of their proprietary roots, they will not release it to the PC crowd. Again, they want OS X to run on Apple-only hardware. They are taking the same ill-fated route that almost kill them. If Apple wants to gain share, then they need to attack both sides of the WinTel monopoly. Offer OS X to the generic PC, innovate the desktop with great software, then try to sell Apple hardware. Otherwise, other systems, like Linux and FreeBSD, will eventually take over. Do the right thing, Apple!

SOAP is a wolf in sheep’s clothing

A colleague of mine was working with a .NET client connecting to a .NET web service. The web service basically looked up images given a key value and the data was downloaded back to the client. He used a C# struct on the server side that contained the name of the image and the binary data. He also had a couple of methods defined in the struct, and he was expecting these methods to be exposed on the client end.

What can I say? In other RPC mechanisms, like CORBA and (D)COM, you can pass object references back and forth. You can invoke methods on those objects, and the architecture makes the remote call transparently. So I do not blame my colleague for thinking along the same lines.

When I explained to him that it’s the SOAP protocol that does not support object references like that, it was clear to him that he needed to adjust the structure to be plain, data-oriented structures.

The fallacy that SOAP & the web services architecture is object-oriented really bugs me. The fact is it’s about as object-oriented as the C-language. It’s just a method of RPC. Just like IIOP in CORBA, DCE-RPC in (D)COM, or RMI in EJB, but it is very verbose and clunky.

Many proponents of SOAP tout that since SOAP is XML, it can be human-readable. Why in the world would a human would want to read an RPC message? Other proponents state that SOAP can be recreated by any client, making it very usable by third parties. OK. I could have easily created a IIOP message or a DCE message in binary. The purpose of RPC architectures is to abstract all of those nitty-gritty details and let me create remoteable objects fairly quickly. I admit that the .NET framework does do that well, but XML under-the-covers still is a waste of bandwidth and processing time.

The last advantage that the SOAP gurus throw down our throats is the fact that SOAP is over HTTP and port 80, making it very web friendly. OK, I’ll admit that, but with some caveats. If I want to expose an API for third-parties to that will help integrate their products with mine, it makes sense. However, implementing web services as a middleware replacement for COM, EJB, or CORBA is simply distributed-computing suicide.