What's it all about, Alfie?

This morning I read this on Slashdot about the new features coming in PostgreSQL 9.0. I have to say, it's really quite impressive. I remember when I was researching an open source database for the work I was starting to do at First Chicago, and still think I made the right decision all these years later. It's just an amazing database.

The features it has, and the comparisons it's making - to say it's more like Oracle and beats SQL Server 2003/2008 is pretty darn impressive. I have to say that I'm glad The Shop is using it as an alternative to either of these - it's just a nice tool to work with.

I'll have to wait and see when KyngChaos gets the build up for Mac OS X that I've taken to using. It's a good package he's putting together.

My old favorite, Cyberduck, has jut released a new version - 3.5, and I did a quick glance at it to see what had changed that might make me come back to this old favorite. Seems the big thing is adding the Google Docs storage which includes OCR. That's interesting, but I'm not exactly sure how OCR fits into a file transfer app... seems like a bit of a stretch, but I'm willing to let them go there.

The addition of Google Docs storage is nice in that Amazon S3 has been out there for quite a while, and this evens the bar, but I haven't done a lot with either, so it's OK for now. But it's nice to know that it's there, if I need it.

This morning I noticed that Google Chrome (dev) 6.0.427.0 for the Mac is out and did a quick update to get the latest version. I haven't heard what this new version brings, but I did hear that Google was trying a little harder to get WebM, their video codec, into the open/standards realm so that they could counter the claims of Apple about WebM vs. H.264. I'm not that big into this, but the arguments heating up between Apple and Google are very interesting to watch.

It's still the first week of my new job at The Shop, and when my sole co-worker left me alone two jobs ago, I started to maintain an RTF file on my Mac of all the little things I might need to pass on to the next guy. It started with what he gave me, and I really expanded it. What I didn't realize until long afterwards, was that I should have been using VoodooPad, Acorn and FlySketch to build up this document.

Thankfully, I do learn from my mistakes, and at my last job I started with VoodooPad and it turned out wonderfully. Well, I'm only a day and a half into this new job, and already I have a lot of important information in the VoodooPad document for the new job. It's simply amazing how easy VoodooPad makes this. It's like TextEdit with linking and embedding and then to augment it with Acorn for graphics and images... well... it's just amazing.

The last time I did a lot of multi-media writing is the papers I wrote as an Asst. Professor at Auburn, and even that was on a Mac - just different tools. With the tools available to me now, it's amazing to think how wild and impressive my papers could have been. Sure, they really don't publish based on the "cool stuff", but documentation is writing for an ignorant user (you, in the future) and as such, the nicer and easier you make it to read the happier your user will be.

It's just about the most perfect development/documentation generation system I've ever used. It just takes my breath away. I have to giggle every now and then.

O happy days! Yesterday at WWDC in the Safari Series of talks, Apple announced that Safari 5.0 was going to be released, and this morning it has shown up in Software Updates! Fantastic news. The big improvements are in HTML 5 support, the Nitro Engine (JavaScript), adding the Bing search as an option, and probably biggest of all are the extensions.

Now you can write extensions in a manner similar to Firefox and Chrome. In fact, the talk had Cabel from Panic showing a new extension - Coda Notes, that allows you to 'mark up' a web page, and then send it all to an email address where the reader can see what you saw, and the marks you made. Very neat looking.

Well, it's great to see Safari keeping up with the improvements in Chrome. The competition is good for both.

I added a little twist to my Cocoa CryptoQuip solver - I made sure that the PuzzlePieces were unique, and then I sorted them in the Quip by the number of possible plaintext words that each had. Why? Well, the duplicates are just unnecessary work, and in my test quip, I had one. Just no need to do that. The sorting by the number of possible plaintext words is meant to reduce the number of iterations by "pinning" the most complete Legend as early as possible. If I have to cycle through 30 words first, and then 1 word, it's faster to pin the one word, and then search the 30. Not a lot faster, but as the searching grows, it makes a difference.

The way to guarantee uniqueness amongst the PuzzlePieces is to change the code for initialization of the Quip to look for duplicates first, and then only add the unique ones:

- (id) initWithCypherText:(NSString*)text where:(unichar)cypher
  equals:(unichar)plain usingDict:(NSArray*)dict
{
  if (self = [self init]) {
    // save the important arguments as ivars
    [self setCypherText:text];
    [self setStartingLegend:[Legend createLegendWhere:cypher equals:plain]];
    // now let's parse the cyphertext into puzzle pieces
    PuzzlePiece*   pp = nil;
    for (NSString* cw in [text componentsSeparatedByString:@" "]) {
      if ([cw length] > 0) {
        if ((pp = [PuzzlePiece createPuzzlePiece:cw]) != nil) {
          [self addToPuzzlePieces:pp];
        }
      }
    }
    // if we have a dictionary of words, use them
    if (dict != nil) {
      for (NSString* pw in dict) {
        for (PuzzlePiece* pp in [self getPuzzlePieces]) {
          [pp checkPlaintextForPossibleMatch:pw];
        }
      }
    }
  }
  return self;	
}

to:

- (id) initWithCypherText:(NSString*)text where:(unichar)cypher
  equals:(unichar)plain usingDict:(NSArray*)dict
{
  if (self = [self init]) {
    // save the important arguments as ivars
    [self setCypherText:text];
    [self setStartingLegend:[Legend createLegendWhere:cypher equals:plain]];
    // now let's parse the cyphertext into puzzle pieces
    PuzzlePiece*   pp = nil;
    for (NSString* cw in [text componentsSeparatedByString:@" "]) {
      if ([cw length] > 0) {
        if ((pp = [PuzzlePiece createPuzzlePiece:cw]) != nil) {
          if (![[self getPuzzlePieces] containsObject:pp]) {
            [self addToPuzzlePieces:pp];
          }
        }
      }
    }
    // if we have a dictionary of words, use them
    if (dict != nil) {
      for (NSString* pw in dict) {
        for (PuzzlePiece* pp in [self getPuzzlePieces]) {
          [pp checkPlaintextForPossibleMatch:pw];
        }
      }
    }
  }
  return self;	
}

which works wonderfully because we have already built the -isEqual: method for the PuzzlePiece:

/*!
 This method returns YES if the argument represents the same puzzle piece
 as this instance. That is not to say that they are identical, but that
 they have the same cyphertext, and same list of possible plain text words.
 */
- (BOOL) isEqual:(id)obj
{
  BOOL   equal = NO;
  if ([obj isKindOfClass:[self class]] &&
    [[self getCypherWord] isEqual:[obj getCypherWord]] &&
    [[self getPossibles] isEqualToArray:[obj getPossibles]]) {
    equal = YES;
  }
  return equal;
}

Now to do the sorting we needed to add a little more code. The trick is to use the NSMutableArray's ability to sort it's content with the -sortUsingSelector: and then the key is to have the right selectors for the objects. I decided to make it pretty simple, and I implemented two versions of the -compare: method:

/*!
 This comparison method will compare the lengths of the cypherwords so that
 you can use this method to sort the puzzle pieces on the lengths of the words
 for some attack.
 */
- (NSComparisonResult) compareLength:(PuzzlePiece*)anOther
{
  NSUInteger	me = [[self getCypherWord] length];
  NSUInteger	him = [[anOther getCypherWord] length];
  if (me < him) {
    return NSOrderedAscending;
  } else if (me > him) {
    return NSOrderedDescending;
  } else {
    return NSOrderedSame;
  }
}
 
 
/*!
 This comparison method will compare the number of possible plaintext matches
 for the argument and this instance to see who has more. This is useful in
 sorting the puzzle pieces on the number of possible matches in the attack.
 */
- (NSComparisonResult) comparePossibles:(PuzzlePiece*)anOther
{
  NSUInteger	me = [self countOfPossibles];
  NSUInteger	him = [anOther countOfPossibles];
  if (me < him) {
    return NSOrderedAscending;
  } else if (me > him) {
    return NSOrderedDescending;
  } else {
    return NSOrderedSame;
  }
}

With these, I'm able to easily sort the puzzle pieces by the number of their possible plaintext matches with:

  // sort the puzzle pieces by the number of possible words they match
  [[self getPuzzlePieces] sortUsingSelector:@selector(comparePossibles:)];

With these changes, the time to solve my test case went from 0.21 sec to 0.18 sec. Not quite what I'd hoped, but I'm not done, either. I believe I'm on the right track, but I need to further limit the search space, and when that is done, I hope to be well under the 0.10 sec mark. Now that would be cool!

After reading the twitter feed from the WWDC Keynote, it sounds like the iPhone 4 is going to be a very sweet machine, indeed. The display, the camera, the case... it's all about really upgrading the phone to be more of a serious device and less of a smart phone. The accelerometers for gaming and such - amazingly cool. No question - next month is an iPhone upgrade month for me. Yeah, it'll be expensive, but that's what you get for being a huge fan of this technology.

This morning I noticed that while I was "between jobs", MarsEdit 3.0.2 was released with a few fixes for certain special cases. Nothing I've run into, but it's still nice to see an update in this week of WWDC, as I'm sure the news will be focused on the keynote today and what that means for all the folks out here. Interesting stuff.

Looks like Google is pushing their new WebM video support out a bit early. The most recent edition of Chrome 6.0.422.0 supposedly has the WebM codec for HTML5 built in. Very interesting. It's getting to be an interesting race now. Safari is still my favorite browser - period. But Chrome is really getting up there. It's got all the goodies that I need, and speed for JavaScript that's better than all but Safari.

Amazing improvements. Great work.

I just got my Cocoa version of my CryptoQuip code working, and I have to say, I'm impressed - but then I knew I'd be. I can solve the standard puzzle in about 0.21 sec on my MacBook Pro - which is pretty darn speedy. I'm not completely happy with the results, as I think there are a ton of improvements I can make in the attack, and now that I have a really nice domain model, I can make these changes very easily. It's sweet.

I also decided to use git as the source control - and it was a little bit of a debate within myself on this issue. I'm normally a CVS guy, and I've gotten very good at making CVS do all that I've ever needed. But I don't have tethering on my iPhone, and at the prices AT&T are talking about, I'm not sure I will for a while. Still, I wanted to have it in source control, so git was it. Plus, it's clean, fast, local, and with Time Machine, it's as safe locally as it can possibly be.

Still, I'll probably put it up on my home git server, just so I can have a remote pull if I need it.

To get it all going, I needed to do just a few things for decent Xcode integration. I say decent because there's really no Xcode integration at this time for git - it's all on the command line. However, because I always have a terminal session open to the project directory, the really important issue is how the files are treated in git. Thankfully, git is wonderful at this.

I first went into the project directory Xcode made, and created the git repository:

  $ cd ~/Developer/CryptoQuip
  $ git init

then I needed to set up my project-based .gitignore and .gitattributes based on this posting that is a great place to start if you don't already have some decent defaults for git. I created two files in the root project directory. First, .gitignore:

  build/*
  *.pbxuser
  *.mode1v3
  profile

and then .gitattributes:

  *.pbxproj -crlf -diff -merge

When I started looking at the new layout of the project directory that Xcode uses, it's far cleaner than the older project layout of NeXTSTEP-era projects (yes, I still have a few of them). The lines in the .gitignore make a lot of sense, and it's very nice how they have moved the old bundles into files that can be put into generic source control very easily.

Then I needed to put it on my home gitosis server so I could have a backup and remote pull. First, I needed to check out the gitosis-admin project:

  $ git clone git@git.themanfromspud.com:gitosis-admin.git

then in the newly created gitosis-admin directory, edit the gitosis.conf file to add the new repository to the group I've created for everything:

  [group everything]
  members = drbob@sherman
  writeable = JiGV CryptoQuip

then I need to check it back in and push it back to the server:

  $ git commit -a -m "Added CryptoQuip project to the main group"
  $ git push

and it was all ready for the project.

To add the project, I simply went into the project directory and add it's new origin and then push it to the server:

  $ cd ~/Developer/CryptoQuip
  $ git remote add origin git@git.themanfromspud.com:CryptoQuip.git
  $ git push origin master:refs/heads/master

and it's all up on the server and ready to go!

At this point, when I want to sync my local git repository to the main server-side one, I'll just have to do a push:

  $ git push

and git will remember where I pushed it last and sync it up with the server repository. Very nice.

One final style point: on the server, a new repository is created but from the web server, the description is lacking any color. What I did was to login to the server, go to the newly created repository directory, and then edit the file called description. I changed it to a decent little one-liner and that was it. Done.