What's it all about, Alfie?

This evening I decided I wanted to get out of the house a little, so I went with Liza to the Naperville North Women's Lacrosse Board Meeting and sat at a little table for two in the corner and did a bit of coding. I can see why Wil Shipley and so many others do the exact same thing. It's so nice to have a simple little break from the home office where I've been hammering on this same problem for quite a while. Just the change of scene… the different background music… the different table and surroundings - all makes for a really wonderful experience.

Now I don't think I'd do this over the home office, but it's certainly nice to have the change of scene. If I went indie, I'd be doing this a few times a week. Maybe Starbucks, Panera, and other similar places would be where I spent my afternoons. Hard to say, but it's a lot of fun. I can see myself doing a lot more coding here if Liza's going to stay on this board.

Very nice change of pace.

And I got a lot of coding done too!

When putting work up on GitHub, it really pays to have a nice Markdown previewer or editor for building your README.md file as it's the first thing a new user sees when coming to your project page on GitHub. You want to make a nice impression on the user, have good introductory docs, and even the license on the project, and all this is going to be rendered in Markdown - at least GitHub's version of Markdown.

When I was initially doing this, I was using BBEdit, and while it had a preview that worked with Markdown, it didn't support the GitHub CSS that it was going to be rendered in, and it still required that I edit the file, check it in, push it up to GitHub, and then I could see if I liked what it looked like. Not a great workflow, really.

So this morning I was on the hunt for a decent Markdown editor for Mac OS X. I knew there were several available in the Mac App Store, so I was willing to buy one, but I wanted to search the web first, to see what the opinions were out there of the best one to get. I've seen several, and there are two that seemed likely candidates, and I decided to try one, but I'm not really sure that it's what I am looking for. Still, it appears to be a lot closer to what I'm looking for than what I'm doing now.

Mou is a free app that does a split-pane view of source and rendered text. The position of the split pane isn't really resizable like a lot of Mac apps, but it is moveable in the sense that it can be moved by some menu commands to change the split from 1:1 to 1:2 or 2:1, and such. It's not ideal, but it's free. It's certainly a very nice start in the right direction as it currently support GitHub flavored Markdown.

BBEdit can work with Markdown, and even preview it, but it doesn't really use the GitHub style for the preview, and try as I might, I was totally unable to get some CSS file for BBEdit's preview that would work. There were perl and PHP versions, but that's far too much, and the Mac App would then be far better.

The problems with Mou are that it's taking up a ton of space on the screen. There's another application called Valletta 1.0, and it's got a unique take on the two-pane system: it keeps it all in one by having the line with the cursor in input mode and the rest of the document in display mode. This is a good idea, but if you're moving between different sized text, you're going to be having your text move all over the place. What I want is a great preview.

Mou does the preview good enough, and it's got a simple editor built in. Not bad for free. There's another app that does just the previewing, and it's on the Mac App Store for $4 - Marked. I might end up going for this as it's exactly what I'm looking for. I can edit in BBEdit all I want, and then preview in a good GitHub renderer and then check it in and push it all up to GitHub.

[4/10] UPDATE: I ended up getting Marked from the Mac App Store. They updated it to 1.4, and included the color syntax highlighting on GitHub. It's exactly what I'm looking for. $4 well spent. I can edit it in BBEdit, save, and it's automatically updated in Marked. Very nice indeed.

This morning I noticed that Google Chrome dev 19.0.1077.3 was out with a few little updates and a few known Mac issues. Interestingly, the new V8 javascript engine is there, but there are a few incorrectly drawn icons in the Mac version. Odd little combination of changes, but I'm guessing it's a merge that needs to be done, and then things will clear up. There's also a fix for the Flash plug-in, but it's going to be interesting to see what becomes of Flash now that Adobe is all but giving up on it. Google may go back to HTML5 and the more widely supported codecs. Hard to say.

Well… today has been an interesting day for one open source project that I've been working with for about the last year or so - ZeroMQ. Today I learned that two of the key developers in the group have "jumped ship" and forked the codebase, and are calling themselves Crossroads I/O. Their project, libxs, is really just a fork of the ZeroMQ code, and they are off to the races with a new Open Source company/project, and without the backing and support of a lot of the ZeroMQ community.

Today in IRC, it was a real surprise to hear Pieter talking about all the grief that was hidden from me, at least, in 2011. Trying to keep the group together was his job - and in the end, he realized that it just wasn't possible. So away Mato and Martin went, and the group is now light those two major developers.

I look at this with a lot of curiosity. When they had 2.1.x, it was good, decent, and while not perfect, it could have used a lot of improvement. Rather than do that, they started a 3.0 branch, with a completely different API, and all of a sudden, the upgrade path to me wasn't clear. I didn't mind it so much as we were moving away from it as the delivery transport in the project, but it still bothered me that they wanted to have a new API and a re-write of large sections of the code so soon after they just got 2.x out the door.

Dynamic and flamboyant individuals are nice to really move a project, but I can see that they can also be the worst liability to a project like ZeroMQ, as well. If they want to take the project in directions that the majority of users don't want, then they are going to make the project appear to be run by lunatics. But without them, you may face the problem that fixing the bugs they made are near to impossible in any reasonable timeframe.

So on the whole, I hope things work out for ZeroMQ, I really do. I think it's got a good idea that needs a little work to make it a really robust and reliable messaging system. But it's going to need to attract a few key, strong, developers to make it work.

Since I've been looking for a job, I haven't been doing a lot of posting because not a lot has been happening - except all the stuff associated with getting a new job. But one of the things I wanted to do this time around was to create a GitHub project that could showcase a little bit of my coding skills as well as being generally useful for folks - me included, and just get something out there. So I created DKit.

The idea behind DKit is simple - it's a very specialized C++ library with classes and templates, that contains atomic and lockless data structures for very efficient C++ coding. I've used classes like these in projects at previous employers, but I started fresh, and expanded the classes significantly so that the atomic integers paralleled those in the stdint.h header - signed and unsigned, 8, 16, 32, and 64 bit sizes. These will make counters trivial as they are all atomic and so you'll get great counts even if you don't go through the overhead of locking.

I also added in two groups of containers, so far: single-producer/single-consumer, and multiple-producer/single-consumer. To the first, I put in a simple circular FIFO, and to the latter I put in a linked FIFO and a circular FIFO. These were ideas I had at a previous job, but I wanted to make them fresh so as not to get into any IP issues.

All told, it's a nice start. I want to keep it free of the issues that I might have had in the past, and just keep it OPen Source. I picked the MIT license as it seems to be the most liberal while protecting the original copyright and the removal of any liability. I think it's the start of something really nice.

This morning a good friend messaged me about something I might want to keep in mind as I do more massively parallel projects in the future, and that's a C++ library that fits in will with the STL, and is written by a couple of engineers at NVIDIA - Thrust. This looks very interesting.

The idea is that with the CUDA nvcc compiler, and a little pre-processing and some templates, they have made the STL std::vector equivalent for GPU/CPU usage. You can say where you want this vector to be held, and then process a functor on it to get things done very quickly. It's not as clean as OpenCL, in my opinion, but it's far more likely to be used as throwing NVIDIA cards into boxes - even server boxes, and using GCC/nvcc is a lot more likely in the typical business use-case.

Macs still aren't getting significant penetration there, but it's getting better.

So this is something to keep in mind, for sure. Thankfully, it'll run on Macs as well - so I just need to get a Mac Pro with NVIDIA card(s) and then I can start playing with it. Sweet.

This morning, sometime, I noticed that Google Chrome dev 19.0.1068.0 was released and the release notes seem focused on the Android stack and a few side things, but I guess not every release can come up with a new way of doing things, or a massive speed improvement. But progress is progress.

This morning I noticed that Google Chrome dev 19.0.1061.1 is out and it's got a few nice things in it. Like a new V8 javascript engine (3.9.13.0), and support for remote file systems - could be interesting stuff. Glad to see they are still making improvements in V8 - that's something that I think I'm going to end up in sooner than later, and it'll be nice to have some improved performance there.

This morning I wanted to try to get some of my CVS repos converted to Git so that I could have the complete repo on my laptop and not have to worry about internet connectivity. I'm a big fan of CVS, and it's simplicity, but Git is the clear next-generation of CVS, and it doesn't need the connection to the server that CVS does.

Recently, I'd read that there was a simple git command: git cvsimport that would convert a repo, and I just had to try. The first thing was that I needed to have a program called cvsps. This is some other tool - not part of CVS, not part of Git, that I needed to get. I realized this as I tried to convert my first repo, and failed saying it couldn't find this app. So first things first, get the tools I need.

Getting cvsps

A simple google search revealed that the source code for cvsps was held in a very simple web site: http://www.cobite.com/cvsps/. I downloaded the latest stable code, and read the README. It's a simple make; make install, and I'm on my way:

  $ cd cvsps-2.1
  $ make
  $ sudo make install

The cvsps executable is now in /usr/local/bin and /usr/local/share/man. That's all we need - over and above Xcode 4.3 and it's command line tools (cvs, git).

Get a Local Copy of the CVSROOT

While I've read that this can be done using a remote pserver $CVSROOT, it's a good idea to just get a local copy of the complete CVSROOT to work from. Since I'm in a stable state with that, it was pretty easy to copy it to my TimeMachine external drive:

  $ cd /Volumes/Reststop
  $ scp -r frosty:/usr/local/CVSroot .

It only took a few minutes, and now I've got all the "source material" I need.

Migrate a Single CVS Repo

The process is pretty simple - you have to act as if you're starting a new git repo, but instead of the git init command, you issue the git cvsimport command. It's got a few arguments, but it's pretty simple to use.

For this example, I'm calling the new Git repo the same name as the old CVS repo, but I'm guessing if you want, you can change the names.

  $ cd git
  $ mkdir MyProj
  $ cd MyProj
  $ git cvsimport -p x -v -d /Volumes/Reststop/CVSroot MyProj

At this point, you have a new git repo but the origin is not set, so it's not "going" anywhere if you try to push it. Since I'm using gitosis on my home git server, it's a simple process to update that to add in the project(s) I'm migrating into the proper groups, and then push those changes up to the server before I try to set the origin of the new git repo.

Setting the Origin

Assuming that you have the server set up, and it could be that you're using GitHub and not gitosis, then all you need to do is to set the origin and push it up:

  $ git remote add origin git@git.myplace.com:MyProj.git
  $ git push origin master:refs/heads/master

Final Steps

It's possible to now go in and mess with the git config to set the master right, but I've found is just as easy to remove this new repo, and clone it again from the server. If I got it right, the history will be there, and I'll be sure it works. If not, I can start over. Simple.

It's been a lot of fun getting these guys over to git. Now I can use all the tools and fun I've had with git in the last year to these projects. Very nice!

One of my favorite things is to work with databases in code. Persistence and database hits are a blast as they get you a place to save stuff that, if you design it right, you can view from just about any tool on the planet. Can't say the same for redis or mongoDB. My Greek Engine gets it's instrument data from a local replica copy of a master postgres database, and should the local copy fail - or be down, it should auto-reconnect to the master and just function off that one. If he's dead… well… that's when it's time to get serious about getting things working.

The first thing I needed to do was to consolidate all the database activity to as few a number of places as possible. Thankfully, I had a simple execute() method that did about 90% of what I needed. It just took a few minutes to make that the only way to hit the database, and then I could focus on making that a little more fault-tolerant.

The idea is simple, really: put it in a retry loop, limit the number of retries, and then for each retry, hit The Broker for the correct database connection parameters to use. If the Broker is wrong, then I'm in real trouble, but it's not, so I'm OK. (Famous last words.)

Add a little logging, remove some error codes, and we're ready to go. It really didn't take me all that long, and the results are much better. When, and if, the database goes down, we'll fail over to the master. When we get the local copy up, we can issue an IRC command to repeat the process, and the local one will again be used. Simple. Clean.

Great.