What's it all about, Alfie?

After talking to my soon-to-be manager on Monday, I learned that the initial code they are building is in JRuby, as there's a ton of Ruby code in The Shop, and yet JRuby allows you to drop down into the JVM should performance be an issue. I know next to nothing about Ruby or JRuby, so it made sense to install JRuby and see what's up. Turns out, it was pretty simple, if they had the installer package working a little better.

The first thing was to get the disk image from the JRuby site. There are several ways to download it, and I picked the dog as it had installers and uninstallers - should that prove to be necessary. In any case, it installed fine, but I could not find the jruby executable.

I looked in the installer's package contents, and it turns out that the entire thing is a simple Framework, and everything can point to a simple path and we're good to go. This process took me a few minutes, and could have been cleared up with a simple README in the disk image, but hey, what's a few minutes between friends?

In order to get the path correct, I took advantage of the /user/libexec/path_helper script and placed into /etc/paths.d/ the file jruby that looks like:

  /Library/Frameworks/JRuby.framework/Versions/Current/bin

and on the next shell start, we'll pick this up in the path. Now if the JRuby guys are smart, they will have been careful to make sure that when they call commands like irb, they are doing it within the Framework directory. And here's why…

The install script added a few lines to my .tcshrc, but it added Bash script. Easy fix, but they put the JRuby path at the end of the PATH. This means that when I use the /usr/libexec/path_helper to add in the JRuby path, I get:

  peabody{drbob}7: echo $PATH
  /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/git/bin:
  /Library/Frameworks/JRuby.framework/Versions/Current/bin:.:/Users/drbob/bin:
  /usr/local/qt/bin:/usr/local/xerces/bin:/usr/local/groovy/bin

and we can see that the path for JRuby is after /usr/bin where the Mac OS X install of rib is located. I'm going to leave it like this for a while in the hopes that they did it right (I would have), and I won't have to force the path addition to the front of the PATH. We'll see.

At this time, we can now check that JRuby is successfully installed:

  $ jruby -v
  jruby 1.7.0.preview1 (ruby-1.9.3-p203) (2012-05-19 00c8c98)
  (Java HotSpot(TM) 64-Bit Server VM 1.6.0_33) [darwin-x86_64-java]

Good enough. Now I need to start reading up on JRuby and see what I can see. It's going to be exciting!

The Google Chrome Team has once again bumped the major version number on Chrome, and we're now on 22.0.1201.0 with an incredibly short set of release notes. No matter, the V8 javascript engine is now 3.12.9.0, and I'm sure there are a batch of security and stability fixes for this guy as well. They have done one thing on the Mac client - the minimum OS X release is now 10.6 (Snow Leopard) and that's nice in that it means they can expect certain minimum from the OS that makes it easier/nicer to build on.

Keep up the nice work, guys.

This afternoon I've been doing quite a bit of coding and documenting on LKit. Specifically, I've put in quite a few examples of the language constructs to the README.md so that I had something to work against for the parser::compile() method. I wanted to have a few things straight before I started coding things up.

Secondly, I noticed that I only had max, min, and sum defined as functions, but what I really needed was to include all the arithmetic operators: +, -, *, and / as well as the comparison operations: ==, !=, >, <, >=, and <=. I built the comparison operators as a single class with a constructor argument (enum) for the type of operation to be performed, and then just added them to the default set with different names and constructor args. Nice and clean.

I did the same for the binary operators and, or, and not. Very clean, and it really keeps the lines of code down.

With this, I'm about to the point that I need to really get the tokenizing and parsing together. I still need to be able to have user definable functions, but that's a big next step, and I'll tackle that after I get the basic parser going with what I have.

Lots to do, but it's getting more exciting as there are lots of things to work on and get going. Closer and closer… I'll get there.

It's common to hear, the company you are interviewing with wants you to take a test on the language you say you're proficient in - just to make sure that you are what you say you are. It sounds very reasonable: You say you've been doing C++ coding, then taking a little test for an hour should be no big deal, right? Java, Ruby, anything can be tested, right? And this will let the employer know if you're really good at this. Right?

Not so much.

I've been taking and writing tests for many years, and I've no problem with tests of any kind - so long as the results of the test are balanced against other factors. For example, are you going to hire an architect for your house based on his ability to take a 60 min test on the loading of certain structures? Or the standard lengths of commercially available lumber? No. You want to see what he's done. That's what's impressive (or not).

You want to look at what a person has done, and can do, in order to know if you want to hire them. It's possible that a one-hour test is a good measure for that, but I'm guessing not. I've taken too many of these tests in the past couple of years to think that any web-based test can be a good, complete, and accurate measure of a person's ability to write real-world systems.

How are you going to test their ability to design solid thread-safe code? You can ask them questions about it, but that's not the same. You can ask about immutability, but that's not the same as knowing when to apply it, and when not to.

The problem is that these tests are billing themselves as an authoritative measure of the quality of an individual, and they can't possibly be. They are far too narrow. How can you possibly measure a person in an hour? No way.

So I had to take two of these today, and it just wiped me out. I got "decent", but not "great" scores - as I'd have expected, and that's about as good as I can expect. But I guess I need to look at these tests in a slightly different light -- if the employer is taking these ay face-value, then maybe that's telling me something important about their hiring policies, and maybe that's the critical take-away for me.

In all my years, I'd never inflict this on someone. It's just not a useful metric for hiring a person. Going into a place that requires them means that I'll be forced to ask for them. Not necessarily a good thing, in my book.

UPDATE: I got a mid-40's percentile on the C++ test. From this, you'd think there are a ton of developers that are better than I am. As such, the employer that was asking me to take the test said I wasn't qualified. It hurts, I won't kid you, but in the end, I honestly believe it's saying more about them than me, and that's really what's important to me.

I finally got enough of LKit done to push it all up to a new GitHub (public) repo, and it's nice to get past that first hurdle. I have the value, the function, and the expression all done, and even have a few basic functions defined - sum, max and min. While I know there's a lot more to do, I wanted to get a little something up there so that I can start to show it to folks, and get some important feedback.

I went onto Google, and found a neat little tux/ninja-turtle icon I'll use for LKit for free - can't beat that. And I'm off to the races.

What I've really got up to this point is the basics of the language - in structure, but no parser at this point. I need to start work on more functions as well as the parser, and then start to look at optimizations on the updating of values. For example, if all the arguments to an expression haven't changed, then there's no need to recalculate the expression - it's value will remain unchanged.

There's a lot more to do, But it's nice to get the first cut up there so I can get a sense that it's real.

I'm working on my latest new project - a simple lisp-like language in C++ that is intended to be fast to execute and very memory efficient. In the past, I've built something like this, but it was more of an interpreter, and this time I'm heading for a more JIT-style system where I'm going to be creating in-memory data structures and then running them over and over as the values come in. This matches up more with what the use case is: data stream processing.

What I'm realizing that as I build the code in LKit, I'm really building a new language based on C++ and the objects and operators that I define in C++ for this problem domain. Think about it: C++ has only the basic data types of C, but it ships with the ability to deal with complex data - yeah, a + bi complex data.

You can create these as if they were simple data values, add, subtract, multiply them… even stream them out. For all intents and purposes, the shipping compiler really supports complex data types. But it's really all just built on top of what's there, and that's the real power of C++ to me - the ability to really augment the language to be able to add in data types and operations that make perfect sense in the domain, but aren't in the initial cut of the compiler.

I've create a value. This value can be a bool, an int, a double, or a time stamp. I can add these, compare them to one another, and to the data types they represent. They look, act, and process exactly like they were part of the language. That's really quite incredible. But it comes at a cost: you have to code it all up.

You have to code up the operations. You have to code up every little thing about how to handle these new data types, and if you don't, then it's not there. It's a lot of code to throw down, and I can see why a lot of people shy away from it, but it's got a lot of power, and there's reason to be careful with what you are doing.

But in defining this language, I really have a tremendous power. I get to define how all this works, and what it all does. I can make my resulting C++ code look incredibly simple and clean by making sure all the operators and functions are there to support what one would naturally want to do with these data types.

This makes the language almost domain-specific. And that's one of the things that makes coding in C++ so amazing to me. Great tools.

Today I've spent a good bit of time working on a new project - a lisp-like language in C++ for processing scripts in as efficient manner as possible. The idea was really from some work I've done in the past as well as talking to some nice guys at a start-up that are looking to do the same kind of thing. What I was thinking was that I'd put something together, and point them to it so they could get an idea of how I'd do it. Then, they are free to use it or not, and I've done my part to help them out.

I interviewed with them, but I don't think I'm going to be getting an offer, or taking the offer, as it's likely to be lower than what I have from another place, and it's a small shop, and therefore, a significantly greater risk. But I want to help them, and this is what they were hoping I'd be doing if I joined the group.

The first steps were pulling up the ideas I had from the original code, but there were a lot of things about that code that I didn't like - specifically in the area of performance. I'd like this version to be as fast as possible as it's going to be working on very large data sets - typically time series data, and so the type of data is somewhat restricted, but the amount is enormous.

I got the first two classes built: value and then variable (a value with a name). Now I need to step back a bit and work on the rest of the component design: expressions, functions, etc. The question will be: Should I break out the evaluation methods from value into a different base class? I'm not sure if I need to do this, or if it's really going to benefit the design in any way.

Certainly, it'd be nice to have all the "evaluate-able" objects based off one super class, but I'm not sure that I need that level of flexibility. After all, a function takes a series of values as arguments, and produces a value. An expression is really a function and/or values in some relation to one another. It's not like I need to have this all that different from what it is now.

For instance, I can base the function on the value and have the result value put into the ivar for the value as a cached value to speed up the resulting calculations. That would be nice. Then expressions are something else… maybe they are just relations of values. Not sure.

In any case, I've got a start, and it's going to take a lot more work to get something ready to put on GitHub and show to the guys at the start-up. But I'll get there.

I have been wishing that GitHub for Mac would properly show my Gravatar since the first release so long ago. The problem is that on GitHub, my Gravatar shows up just fine:

but on GitHub for Mac, it's all the default I have no idea who you are… image:

The problem stems from the issue that Gravatar assumes that the email is all lower-case before it's sent to Gravatar for image lookup. This is compounded by the fact that Gravatar does not allow you to have two emails registered for the same Gravatar that only differ by the case in the email. This means that drbob@themanfromspud.com and drbob@TheManFromSPUD.com are totally different Gravatars, and the latter will never be found.

This is highlighted by the PHP code snippet that I found for successfully getting a Gravatar:

  $out = "http://www.gravatar.com/avatar.php?gravatar_id=".md5(strlower($email_addr));

I'm willing to bet that GitHub for Mac is not doing the lower-casing of the email address before it's taking the MD5 hash and sending that to Gravatar. To test this, I changed the user.email parameter on my MacBook Pro and did a few checkins:

The commits I did today have the lower-case version of the user.email setting in the commits, but the older ones don't. This is a clear indication that I'm right. Now it's possible, I suppose, to go back and completely update all the repos I'm using, but I think that's a bit excessive. I'd like Gravatar to allow for mixed-case, but they just take the gravatar_id, and it's already MD5 based at that point.

Nope, this is a GitHub for Mac issue, and they need to lower-case the email address before they send it to Gravatar and then all will be well. I've sent in the request to GitHub, and we'll see what they have to say. I'm hoping they fix this, I do hate to see the little grey shadow for all my checkins.

UPDATE: Great News! I heard back from the GitHub for Mac guys:

  From: Josh Abernathy (GitHub Staff) 
  Subject: GitHub for Mac - Gravatar Mixup

  Hi Bob,

  Ahh, thanks for tracking that down for me. I've created an issue for it.

  Thanks!

so it looks like it's going to get fixed in an upcoming release of GitHub for Mac. That's such wonderful news as it means that all my avatars will be me and not the gray shadow. Super nice!

This morning I was putting together a GitHub pull request for the XMLRPC library I'm using in SyncKit, and I realized that I'm really tired of the tab size on the git diff being 8 when all my code uses a tab size of 4. So I finally started googling to find an answer, and it turns out that the presentation of the git diff is really nothing more than the Unix command less. Interesting. Makes sense.

So you can make the tab size 4 by simply running:

  $ git config --global core.pager 'less -x4'

and if you omit the --global argument, it'll set it just for the repo you are in. This will be great when I have a repo with a tab size of 2, for instance. I can set the global to 4, and then override it as needed in the repo. Very nice.

Once again, Git rules.

I have taken to using Safari for my GitHub views, and the problem there is that I'm typically looking at landscape pages in Safari, and not wide screen pages. But for GitHub, it's much nicer to look at things wide screen so that we get the entire width. What I'm left with is two different preferred sizes, and Safari will remember the last size you had, so it make sense to look into a way to make things a little easier for setting these sizes. Enter AppleScript.

It's actually pretty simple, once you know the things you can ask for, and get. The script to put the front-most Safari window into landscape mode is:

  tell application "Safari"
    activate
    set myPos to bounds of front window
    set x to item 1 of myPos
    set y to item 2 of myPos
    set bounds of front window to {x, y, x + 601, y + 629}
  end tell

placed into your ~/Library/Scripts/Applications/Safari/ directory.

To set the front-most Safari window to wide screen mode, I simply used a different geometry:

  tell application "Safari"
    activate
    set myPos to bounds of front window
    set x to item 1 of myPos
    set y to item 2 of myPos
    set bounds of front window to {x, y, x + 678, y + 468}
  end tell

With these in the aforementioned directory, I can use them to resize the front Safari windows very nicely. Sweet.

I'm not sure if I'm going to be doing a lot of AppleScript, but it's nice to have when you need to throw simple things like this together.