What's it all about, Alfie?

This morning I noticed that Björn has released MacVim Snapshot 50 which is now Intel-only and 10.5 or later. I can understand his reasons, and completely agree - it's what most people have, it's the future, and the code still compiles on the older machines and OS versions, it's just not something that he's going to spend time building.

It's wonderfully fast on Snow Leopard on my laptop, and I have to say, if I only had one editor to use for the rest of my professional life, I'd be happy using Vim. It's just that good.

Interesting that this morning I read that Apple has released a new version of the iPhone OS: 3.1.2. The low-down on this update is that it adds no new features, but contains several bug fixes that were causing a lot of grief to some users:

The code adds no new features, and instead fixes bugs, such as one preventing sleeping iPhones from waking. Also targeted are crashes during video streaming, and a bug which interrupts cellular connections until a phone is rebooted.

The report I read goes on to say that I'm also getting an AT&T carrier update:

American iPhone owners are being given a parallel AT&T carrier update, v5.6; it is unknown what changes the code makes.

Interesting. Tethering?

This morning I noticed that iTerm 0.10 was finally out, and I have to say, it's been ages since a real update to this guy. It's nice, but they are still missing the ability to have workspaces, and the one thing they have that I like is the ability to remove the scrollbar. I've come to terms with this and Terminal.app seems OK to me. Wish I could turn off the scrollbar, though.

I saw that DrawIt 3.10.1 is out and the big change is in how the files are saved. I've seen this on several other apps moving to Snow Leopard, so I'm guessing that this fact, combined with the micro release number means that it's just one little thing and yet it's important. Good enough for me.

Today has been interesting, and even a little fun. I've been pushing my web app through QA and they have interestingly come up with some issues - primarily UI issues, but ugly nonetheless. Also, there were a few issues with the new sliding median filter on the data, and I needed to take care of that zippy pronto.

A Set Means Unique Elements

Seems obvious, no? But I forgot it. I was looking to make a clever median filter and rather than continually sort the array with Collections.sort(), I thought Hey! I'll use a TreeSet and then get the middle element. Clever idea, if it worked. But the TreeSet is, after all, a Set, and that doesn't allow for duplicate values. This meant that when I put in a new value that was the same, numerically, as one already in the list, I was loosing it as only unique members can be in the set. When I then removed a value from the set, I ended up removing the one value, but that might have stood for multiple originals. Nasty.

In the end, I needed to replace the TreeSet with a simple ArrayList and then after I added the new point and removed the old, I sorted the List<Double> using Collections.sort() and then picked out the middle value and that was the median.

When I did this, the data started making a lot more sense.

Big Duh on my part.

Migrating to New Hardware

It's not glamorous, and there's a ton of things that can go wrong, but I think they are all working put pretty well on the migration from the old linux VMs to the new linux hardware. Four servers in all at this time - one I did several weeks ago in London, but they all had to be phased in smoothly.

For the two web servers for my main visualization app, I also set up mod_proxy and proxy_ajp.conf on the apache servers for these boxes. It was a little time-consuming because I had to see the changes, tell the admins what to change, and then iterate. It took a few times, but that's not too bad. The advantage here is that I don't have to hassle with the maintenance, and can enlist them when things go south.

The vanity URLs that I set up are making the access to the sites a ton easier. The long, drawn-out URLs for a typical Tomcat app are just too clumsy for users to really remember. The vanity URLs are just what the doctor ordered.

I've been asked to re-write my coding nemesis. It needs to do a lot more in the next cut, and there's just no way the existing version is going to be able to "stretch" to fit these needs. What I needed to do was to get the broad brush strokes down... the main ideas... on paper so that I was sure things would fit together and I'd be able to get the project working in a reasonable timeframe.

That's why I was looking at the embeddable web servers, among other things.

There's a lot to do, and dividing up the work between myself and the other guy working on the project needs to be worked out as well. Again, just the big broad strokes.

I was reading the web this morning and ran across this post by Guy English, and it perfectly expresses my beliefs on the subject of coding:

Programming is an exercise in overcoming how wrong you’ve been in the past. At first you’ll overcome the syntax errors, then you’ll overcome the structural errors, and then you’ll come to align your code with the standards of a greater community and you’ll feel safe and like you’ve made it. You haven’t – you’re still wrong because you’re always wrong. You are playing a game you cannot win. And let’s face it – if it was a game you could win you’d not be playing at all.

I read that, and it's exactly what I feel. There's always a better way to do it. But the beauty of it is that you can always make it better. Spend the hour and make that method better. Spend the day and refactor that mess and make it clean. You can do it. Always.

I've been working on a web app that's a very heavy JavaScript page, and as such, I've had to force users to run it in Google Chrome as that's the only browser that has a decent JavaScript Engine (on Windows) that can handle the load. It doesn't hurt that I'm using a lot of the Google AJAX libraries, and so they are sort-of made for each other.

This morning I took a whack at the new Google Chrome Frame. This slick IE plug-in is the complete Google Chrome environment in a plug-in frame for IE. This means that pages that run in Chrome will run in the Chrome Frame without modification.

That's big news. I was stunned.

So I decided to try it out. First, you need to put the meta tag in your pages to tell IE to use the Chrome Frame plugin:

  < meta http-equiv="X-UA-Compatible" content="chrome=1" />

That, in itself, will make things work, but if you wanted to verify that the plug-in was installed, then you can add the following to your page to do the check and redirect the user to the Google Chrome Frame download page if it's not installed. First, you need to load the script in the head of the page:

  < script type="text/javascript"
  src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js" ></script>

Then in the body of the page, you need to define a div that will be the target of the download prompt frame:

  < div id="chrome_check" />

just make the id unique and you'll be fine.

Next, have the JavaScript code in the initialization of your page:

  CFInstall.check({ node: "chrome_check" });

The CFInstall.check() function checks to see if Chrome Frame is installed, and if not, will display at the div indicated by the node property a download page hosted by Google. The user can then download Chrome Frame and that's it. It's ready to go.

The docs on Chrome Frame say that the page should automatically reload, but I haven't found that to be the case. It could be just me, I've only tried it once, but even that isn't bad. It's something that allows users to send links in emails and have their default browser (IE) render the project's pages in a Chrome environment.

Super sweet.

I'm looking at the plans for my next project, and the guy I'll be working with side-by-side is pretty much set on C++ for his project, and since it feeds into mine, I really would need a spectacular reason not to pick the same thing. So I started looking at the current version of the project I'll be updating and seeing what it had that I might find difficult to get my hands on in C++. The key components I could come up with were:

• Good Database Tools - with SQLAPI++, there's no problem there. We can connect to MS SQL Server which is the "standard" at the shop.
• In-Memory Database - it might be very nice to have something like H2 in C++ so that should I choose to go down that path, it would be as easy to use as an external database, but much faster.
• Web Server - the current project does a lot of serving of requests via 29 West and http requests (it's a Tomcat web app). If I"m going to make the transition as simple and easy as possible, then I need to be able to handle http requests.

When I started looking at the in-memory database, I realized that SQLite can be used to create in-memory databases, and since it's also supported by SQLAPI++, it's a perfect solution for what I might need. You only need to open a connection the the special file named :memory: and the connection returned will be to a blank, in-memory database. Close the connection, however, and the database goes away.

Additionally, if you open another connection to the same special file, you'll get a completely different in-memory database. This is really interesting in that it allows the user to create as many unique in-memory databases as they wish. Unfortunately, it's not as nice as H2 in that the connection can be set to stay open, but it's a reasonable compromise for an in-memory database.

Even if I didn't use the in-memory database, the SQLite filesystem database is strong enough to not corrupt the file through power outage, and it's very fast for a single system to hold data - so should I want to use it to hold configuration details or parameters, it's certainly more than up to the task.

So I think I have more than enough on the database front for this project in C++. But the real question was the web server interface. I needed to have an embeddable web server that was going to be reasonably fast, small, easy to interface to, and handle all the things I needed. I had to hit Google for this one.

After a lot of poking around, I found several that might fit the bill. The most interesting is Lighttpd - pronounced "Lighty" by the author, and it's goal was to be able to handle 10,000 connections on a single server. Admirable goal, and it's being used by some heavy hitters out there. The big problem seems to be that it's a complete web server with CGI capability. That means that I'd need to create something to use as CGI and then put that into the web server. Not a lot different from using Apache, except the loading capable with the server. So I kept looking.

I found a GNU project: libmicrohttpd which is a C library that you can embed and gives you tons of the goodies you'd need - and far more than I'd need in this application. It's in C, which means it's going to need to be wrapped at least a bit, but it's a strong possibility in my mind because it's a GNU project, and they tend to be pretty bug free.

Probably the most promising candidate seems to be mongoose hosted on Google Code. It appears to be a nice C/C++ library that runs on a ton of platforms and handles all the things I need a web server to do. Additionally, it boasts a simple, clean API to plug into for request processing.

After looking at mongoose, I think I have enough to get started - technically, on this project. It's not necessarily ideal, but I have to say that if I ported my Google DataTable code from Java to C++ and put it in CKit, I think there's not a lot I couldn't do in the existing project. The real problem is that there's a ton I want to do in the new project that's a lot more complex than what's being done in the current project that I'm still going to need to think about it.

I just don't want to get to the point that I have to re-write huge chunks of functionality from one language to C++ in order to get things working. It's a waste of time and a maintenance nightmare.

This morning I decided it's been almost a year since I've gotten the latest FORTRAN compiler from the HPC for Mac OS X web site. They typically update ever couple of months, and with the release of Snow Leopard, I was in for a wonderful treat - they had a Snow Leopard version that generated 64-bit executables. This is fantastic news!

I downloaded the package, updated my uninstall script based on the tarball's contents, and then gave it a whirl.

  peabody{drbob}275: gfortran --version
  GNU Fortran (GCC) 4.5.0 20090910 (experimental)
  Copyright (C) 2009 Free Software Foundation, Inc.
 
  GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
  You may redistribute copies of GNU Fortran
  under the terms of the GNU General Public License.
  For more information about these matters, see the file named COPYING
 
  peabody{drbob}276: 

Sweet.

I love that they build this package with auto-vectorization and OpenMP built in. This is just one of the most wonderful treats of life: to be able to work with such a wonderfully simple programming language on such wonderfully complex problems. Face it - there's no GUI for FORTRAN, it's standard out. Period. That means that you're not going to be making a cool web browser in it. It's not meant to do that. It's meant to push bits around and solve problems like never before.

There's no doubt that FORTRAN was one of the things that drew me into computers back in the 70's. It's just that incredible. I feel incredible joy in being able to use it. Thanks to the HPC on Mac OS X guys for making my day.