What is a PS/2?

I assembled the pieces of my latest found PC tonight. I found the PC (a Dell GX280) a few weeks ago, without memory or disk. I ordered the missing items including the special drive mounting rails. They all arrived prior to my trip to OSCON, but I did not have time to work on it until now.

Things went together, although not smoothly. The drive rails have these little rubber guards on them, and you have to press hard to screw in the mounting screws. The drive itself had a few issues sliding into the bay.

The memory went in with no problems.

I even had a spare KVM cable set and open port on my PS/2 KVM switch. I plugged in the video and then tried to attach the keyboard cable.

There is no keyboard port on a GX280. More specifically, the Dell GX280 has no PS/2 keyboard and mouse ports. I guess everything was attached through USB ports. I'll need to acquire the necessary adapters.

Hooking up a temporary USB keyboard and mouse, the unit refuses to boot the SuSE Linux DVD. It boots the Ubuntu Linux CD. I'll check the drive; it might be a CD reader and not a DVD reader. (Do I have a spare DVD reader?)

So close. A little more work, and I will be ready.

C++, STL, and brick walls

Two problems in one program today. Problem one: the program crashes on certain input files. Problem two: the program runs slowly.

I spent a good part of today tracking the crash problem in the spreadsheet libraries. The symptoms were easy to describe: the program works for small spreadsheets but not for large ones, where "large" is a number of about 200 MB. The cause was the use of "sizeof()" when I should have used "_countof()". (A subtlety of the Windows API for wide characters.) The investigation took much longer than I think it should have.

On the other hand, I did find the problem. The true problem. I made a correction that solves the problem and doesn't simply mask it. Go me!

The second problem is a harder one. The performance of C++ and STL is disappointing. It is much slower than I would like. It takes about four minutes to load a file, where the old libraries can load it in less than thirty seconds. The old libraries don't use STL; they use custom structures full of C++ pointers and other opaque techniques. The code is impenetrable and we don't understand how it all works.

The new code is understandable but slow.

Are these the only two possibilities? We want fast code that is maintainable. I need to think more about this problem.

OSCON 2010 day 2

More good sessions today. I split each of the tutorials in two, attending the first half of one and then attending the second half of the second. By jumping between sessions, I got to see four and not two.

The morning sessions covered mobile web app development and performance improvements for Python. The mobile web app session was a bit disorganized. It was clear that the presenters had not practiced the talk before the show. But despite the problems, I learned a lot. The key thing I took away was that development for mobile web apps is fragmented along hardware lines. The big platforms (iPhone, Android, Blackberry, Meego, and Windows) all have their tool suites and on over-arching tool is quite challenging. For now, building a web app for multiple platforms means building multiple web apps.

The afternoon sessions talked about Grails (Java's Groovy on Rails) and Smalltalk's Seaside web development environment. I was impressed with both. Grails is a not a direct port of Ruby on Rails but it is fairly close. Anyone familiar with RoR will pick it up quickly. Seaside is a different approach to web apps, in which small modules generate fragments of HTML pages and you combine the modules to build an application. It is an interesting take on web apps, one that is not like the JSP/ASP pages of yore or the Rails concept of today.

Tonight will see the OSCON Ignite talks and the O'Reilly Open Source Awards. And then maybe some sleep!

OSCON 2010 day 1

I attended two sessions today. Today's sessions are the longer tutorial format, so we get only two (unless we jump out of one and into another).

The first was "QA in PHP", which covered a lot of quality concepts. It included testing (automated testing, since OSCON is a conference on modern techniques) and more. Beyond testing, the speaker covered code complexity (from lines of code to complexity). I was impressed with the number of tools (and the variety of tools) available for PHP programs.

The second session was "Moose is Perl", which covered the object-oriented extensions for Perl 5. The package allows for mixins (like in Ruby) to provide multiple and targeted inheritance. I've stayed away from O-O programming in Perl because the techniques I've seen are ugly. Moose makes things palatable -- at least to my mind.

I've also had a number of good conversations. They started at breakfast, continued during the morning break, then at lunch, and at the afternoon break. It may seem I talk with people only while eating, but that's when we're not in class.

Plugging the leak and talking to strangers

I tracked down a memory overwrite issue today. These are still difficult problems to solve. For this one, I was lucky: the problem was repeatable, and the code had diagnostic routines that would trip the Microsoft run-time checks.

Solving a problem in software consists of the following steps:

1) Make the problem repeatable

2) Identify the point of failure

3) Understand the problem

4) Devise solutions

5) Pick a solution and implement it

6) Run tests to verify that you did not break something else

With step one as a "freebie" and diagnostic routines, identifying the point of failure was easy. I found it in less than an hour, pin-pointing the exact line of code.

Understanding the problem took more work, and in fact required the experience of a colleague, someone who has worked on the software for a while. Together we built an understanding: me saying "this line of code does bad things" and him saying "that line of code should not be run, nor should its function be called (with this particular data)". With that information, I could track upwards in the call stack to find the true problem.

It is a pretty good feeling, solving this kind of problem.

* * * *

On the homeward commute, I got out the "Starting FORTH" book, and the guy across the aisle on the train commented on the book. We talked for the entire trip home, discussing programming, technology, project management, and society in general.

I hadn't thought of Lee Brodie's book as a conversation-starter, but it was.

The $100 PC -- part 1

Last week, I found an abandoned Dell GX280 PC. It was in the "giving place", that small area in my apartment building behind the elevators which holds junk and items to be thrown into the local landfill.

The PC was in pretty good shape. The case had a few scuffs but overall the case and components showed no signs of abuse. The previous owner had removed the hard drive and memory, but had left the CD drive, the floppy drive, and the CPU and fan assembly.

I can use this PC. I can install Linux and use it as a server, hosting a database, version control, and things for Ruby on Rails.

The PC was free (it was in the giving place, after all). The missing components (memory, hard disc, and rails to mount the hard disc) cost just about $100. I ordered them yesterday, using the power of the internet. They should arrive later this week.

When credit is due

I've spent some time during the past two days developing a C#/.NET application. And the experience has been, mostly, a good one.

The program is perhaps more of a utility that an application. It reads some text data and presents it in a GUI. The data itself represents the changes between two spreadsheets. The 'diffs', if you will.

The one frustrating aspect was the C# language. After working in Perl and Ruby (and even C++), I found C# to be a bit of a straightjacket, due to its strong typing. At multiple points in the code, I had to insert extra lines (or what I consider extra lines) to convert data from one type to another. The only reason I can see is the type checking in the compiler. Yet Perl and Ruby can perform the same operations without the extra code.

Languages are about expression, and I find myself more comfortable with Perl and Ruby. But that's beside the point.

We're using C#/.NET for the GUI portion, and here the language and framework perform well. I was able to create the GUI using standard controls (this is a Windows application, so no Silverlight or ASP magic was needed) and present the data. I spent more time on organizing the data in the program and less time fiddling with the user interface. And that's what I expect of a good framework and IDE.

So I give Microsoft credit. Visual Studio, C#, and .NET made it possible to deliver the goods.