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.

Designed for big

I attended the local CMAP (Central Maryland Association of .NET Professionals) this evening. I attended despite the efforts of the WMATA metro and the BAL MTA MARC trains, both of which had delays.

The CMAP meetings start at 6:30 but there is usually some preliminary announcements and then possibly a few minutes for a sponsor. I arrived late, but in time for the main speaker. I was disappointed that I had missed the early business/network informal chats.

The talk was about Entity Framework, an ORM for .NET. The speaker knew the material well but was an average speaker, rushing though some examples and not repeating questions from the audience. I learned a lot about the ORM, which says something.

The one thing that sticks in my mind is the work needed for this ORM. The speaker made it sound like Entity Framework is an improvement over other ORMs (and possibly it is -- I am not familiar with them) but it still seemed like a lot of work to configure and run a simple application. I might be biased for Ruby on Rails, which does things for you.

The other impression I have is that Entity Frameworks, like other .NET things, is built for large-scale projects. It's designed to fit into the enterprise application life cycle, not for a one-person shop building low-cost quick-and-dirty apps.

It turns out that I didn't need to worry about missing the business/network session. I talked with two folks after the meeting. One is a former co-worker, the other a person I know from CMAP. Both are struggling with the challenge of independent work, asked questions, and also gave advice.

I'm glad that I went.

Fun with Cocoa

I experimented with the Apple development tools today.  Even my old OSX 10.4 system included the Interface Builder tool for creating applications. And with the O'Reilly book "Building Cocoa Applications", it was easy.

I did less than I wanted, due to the sinus headache of this morning. Yet headache and all I felt productive and the tasks were fun!

Windows 7 - the morning after

Windows 7 has an update hang-over on the day after the install. Today was the second day that I used Windows 7 on the Systemax PC, and as Windows booted I was greeted to a flurry of "applying update X of Y" messages. The 'Y' in the messages was the total number of update operations, and it was a whopping 33,769.

Yes, that is thirty-three thousand operations. The entire set was completed in less that five minutes, so I expect that an "operation" may be as simple as changing a single registry entry.

Why Microsoft was compelled to display such messages and organize operations at such a granular level is open to speculation. Perhaps they have seen problems with updates crashing, so the last update operation would be displayed and useful for diagnoses. It is a thought that inspires little confidence.

On the plus side, Windows 7 the "real" edition knows how to talk to my mouse through the KVM switch. The eval copy of Windows 7 did not, forcing me to use a separate mouse attached directly to the PC. Oddly, Windows 7 *would* talk to the keyboard through the KVM switch. (And Linux would talk to both keyboard and mouse through the KVM switch, so I knew it was not a hardware problem.)