Cygwin .bashrc goodness

Well, it's been a while since I wrote a blagoweb entry; the new job's been keeping me busy. But then Jon Micklos had to go and write an entry about how to add an ssh:// protocol to the Windows registry, and clearly I can't let him be the only recent Purdue grad in the PNW providing Windows tips on his interblag. Or something. Anyway.

For various reasons, I've found myself using Cygwin rather heavily of late. And by "rather heavily", I mean "eight hours a day". So I've hacked up some Cygwin-specific .bashrc snippets that make life a little easier. Before that, though, a recommendation: don't use Cygwin under cmd.exe. It works, but let's face it, cmd.exe just isn't a very good terminal emulator. Copy/pasting is painful. It's rather slow. And it doesn't play nice with a lot of Cygwin programs. PuTTY is a much better terminal emulator, and there's a hacked-up version here that lets you use it with Cygwin.

The problem now is that a lot of the Windows command-line tools don't play nice under PuTTY. They expect a cmd.exe terminal. And sometimes you might want to run a .cmd or .bat file; there may be some shebang magic you can do, but what I've done is add this to my .bashrc:

function winsh() {
 if [ "x${1}" != "x" ]; then
     P=${1}
 else
     P=.
 fi
 cmd /c start cmd /k "cd `cygpath -aw ${P}`"
}

This will open a new cmd.exe window at the specified directory, or the current directory if you didn't specify one. If you just run cmd, it will run inside the PuTTY window; cmd /c start cmd is the magic that opens up a new cmd.exe window, and the /k option is to send it to the directory of your choice.

The other snippet I put together is based on a useful utility available at OS X's command-line called open, which basically acts like you double-clicked on its argument (if you specify a directory, it opens it in Finder). I just wrote a Windows-equivalent:

function open() {
     explorer `cygpath -aw "$1"`
 }

With this you can do open /path/to/my.doc and it'll open up in Word just as if you'd double-clicked it.

That's all for today. I'll try to update more often. Until next time, adios!

Prince of Persia, First Impressions

Background
So Ubisoft came out with a new PoP game on Friday, and of course I had it on preorder. Sands of Time is one of the few games I've ever played to completion without playing with someone, let alone multiple times. I wasn't particularly fond of the sequels, however, for two reasons.

Firstly, they gutted the original Prince's character. Prince 1 was British, funny, and guileless. Then, apparently, their focus groups told them they wanted more 'dark'. So they took a broad paintbrush, dipped it in a vat of dark, and then dumped the vat all over the game. Prince 2 was American, emo-looking, and very, very angry. They did the same thing with the game as a whole, almost running out of black or near-black pixels as opposed to the colorful art style of the original, and they got rid of the girl, Farah, entirely. The music went from generic but cool Middle-Eastern to angry heavy metal. Prince 3 dialed all of this back a bit, but Prince 1 was far and away the best.

Secondly, the focus group apparently told them that combat in Prince 1 was too simple. Which it was, admittedly. But their solution was to essentially tack on a Soul Calibur minigame with a billion different unintuitive combos, which meant I did what I do in Soul Calibur -- button-mash like a fiend. Not much fun. Again, Prince 3 was better, but not by much.

But then Assassin's Creed came out and I figured Ubi must've gotten some of their mojo back because that game rocked. So when I heard there was a new Prince coming out, with no connection to the previous series, expectations were high. So with no further ado...

The Art
The new PoP engine is based on the one that was developed for Assassin's Creed, which definitely boded well for the game. In this game, they use a cel-shaded version of the engine, to great effect. The graphics are, quite simply, gorgeous. Watching the tiny-ass YouTube trailer I was a little worried that the cel-shaded Prince was a little hard to follow, but on a 50" TV at 720p there is no such concern. And the art is fantastic. There's a wide variety of environments, ranging from focus-group-tested dark and scary to lush verdant green gardens to cold blue ice. It's not the Arabian Nights art of Sands of Time, but it's at least as good.

The Characters
New girl. New Prince, for that matter. There's a code you can enter to change the models to the Sands of Time ones (although, obviously, updated for the new engine and the 360), but why? It's a new game.

The new girl is not quite as biting and sarcastic as Farah, but not entirely two-dimensional either. Perhaps she will be further developed as the game goes on -- so far most of her talk has been exposition. The new Prince is fantastic. He's American, but he's hilarious. A bit of a reluctant hero -- one of his lines is, "I'm not here. Someone else is here, doing these crazy things," and another: "I had gold! Lots of gold! I could've had wine. And women! And carpets this thick!". Also sarcastic, more so than Sands's Prince. I've only been playing for an hour and a half, so obviously not that much character development yet, but so far, very promising.

Combat Mechanics
Ubi really knocked it out of the park here. The combat mechanics are superb. There's a combo system, but rather than arbitrary combos, they make a tree of sorts. And each branch in the tree is punctuated by a pause wherein you can hit the next button, and the options make sense. For example, when you knock the enemy up into the air, the game pauses, and obviously your only move at that point is to hit A and join him there. Then you can hit X or B depending on if you want to use your sword or your fist. It's well done -- complex enough to not be the same four moves over and over (a la Sands), but not quite a button-mashing minigame.

Movement Mechanics
Now here, I am a little ambivalent. I liked the old game's system where the right trigger was associated with the game's characteristic acrobatics -- wall-running, swinging from a beam, etc. In an effort to streamline the controls, the A button now does almost everything, though you still have to hit it at the right time to do exactly what you want, and where you have the stick pointed determines the move. Hit A while moving to a wall, you wall-run. Hit A while moving towards a gap, you jump across the gap. Obviously there's a little more room for error than in the old system, and there are a few things that use the B button, like using a ring to extend your move, which is a little counter-intuitive.

Overall, it's usable, and within an hour I was using it almost as naturally as the old system, so overall no complaints. Cool new mechanics include: the aforementioned move-extending rings, using your claw-gloves to slow a fall by scraping down a wall, climbing around on vines, and an interesting mechanic wherein the girl, who has magical powers, can help you across a jump if you manage to hit Y before you start falling.

Worth mentioning is the fact that the old turn-back-time-when-you-realize-you-messed-up-a-move trick no longer works. Instead, the girl uses her magic to catch you and pull you back, so you can't actually die. Instead, you get to try over and over again until you make the move. It's kind of like always having enough sand to turn back time, and always remembering to use it. Unfortunately, it does mean you can't turn back time to right before the point of death, you always start from what the game decides is "the beginning of the move". Which can be quite a way back, at times.

Overall, my first impression of this game is overwhelmingly positive. It looks set to deliver on the promise that the trailers made, of a sequel that lives up to the original Prince. You'll notice I've said nothing about the story -- not much has been uncovered yet, and I'm totally withholding judgment until I've seen the rest of it. Until then, I'm going back to the game. Peace.

McCain: Yellow.

So earlier this week we saw the Obama doctrine, i.e. Obama's strong counter-punch to McCain's smear attacks as an indication of how an Obama presidency would manage foreign policy: never start a fight, never lose a fight. And now we have a great showcase for how McCain's foreign policy might work. It goes something like this: start a fight you can't win, realize your enemy is willing and perfectly capable of fighting back and fighting hard, and back the fuck down. I think I've seen this movie before. Isn't it called Afghanistan?

The Obama Doctrine

By this time, you don't need to be a political junkie to have heard of http://keatingeconomics.com. In case you haven't, however, here's the short version of the story: around the middle of last week, the McCain campaign, in one of a series of moves of desperation, announced that they would be launching a series of smear attacks on Obama, starting with Palin's claim that he "pals around with terrorists." She's referring to Bill Ayers who happens to live in Obama's neighborhood in Chicago, and whose group was responsible for bombings of the Pentagon when Obama was 8 years old. He's since become a professor at UIC, a mainstream political activist, and has expressed remorse for the actions of his youth. Obama, for his part, has unequivocally condemned Ayers' actions as part of Weather Underground. In short, not much to see here but a Swiftboat-style attempt to tarnish Obama's image in the public consciousness with a guilt-by-association attack.

Almost immediately, the Obama campaign came out with the website http://keatingeconomics.com, which includes a documentary on McCain's involvement with the S&L crisis as a member of the Keating five. I'll let you read the site and watch the documentary, but the short version is: the S&L crisis has strong parallels to the economic crisis facing us today, and provides a good showcase for how a McCain presidency would handle the crisis (hint: poorly). According to CNN, the documentary is pretty solid. A few days later, the Obama campaign also came out with the website http://mclobbyist.com/, detailing the McCain campaign's intimate involvement with lobbying organizations. Read the websites and judge for yourself; what I want to address is what these websites say about the Obama campaign.

After 2004, it would have been idiotic of the Obama campaign not to expect a Swiftboat-style attack. It was inevitable, sooner or later. But the standard Democratic "preparation" would have been to merely debunk the attacks. Maybe even forcefully. But the Obama campaign did far more. They had up their sleeve not one, but two, strong, debilitating counter-attacks. Make no mistake: they're going in for the kill. It seems to me that this response provides a fantastic showcase for how an Obama presidency would conduct foreign policy. They didn't start this dirty war, but they sure as hell are going to win it. I think we should call this the Obama Doctrine: never start a fight, never lose a fight.

Dear Apple, please make the Music app more like Remote

Seriously, why does the Remote app have more features than the Music app, when the latter is the flagship on the iPod Touch and second only to the phone on the iPhone? A quick list from using Remote for all of ten minutes:

• Text search. Along with Playlists, Songs, etc., Remote has a Search button. It lets you search your library using the virtual keyboard. Super-handy when you can only remember a few words in the middle of a title/album. For me, in many cases I find text search more efficient than navigating menus. It could be even better if you could search inside a playlist, but even as is this would be a welcome feature in Music.
  
• Scrollbars. In Remote, a long playlist of songs has a scroll bar to the right, to quickly navigate to the middle or the end. In Music, no such thing. Admitted, song, album, and artist lists do have an alphabetical scrollbar, but I want a (non-alphabetical) one on playlists too, because I use long playlists a lot.
  
• Extended item info. The lists in Remote use smaller text, and this allows two lines per item. For playlists, you see the number of songs per playlist. Marginally useful. For song lists, you see the artist as well as the title. HUGEly useful, especially when someone else is navigating your iPod.
  

After making this list, it almost seems as though Music were straight-ported from the old iPod and then forgotten about, because ALL of these features are enabled by the hardware of the Touch/iPhone. Get your act together, Apple.

Java idea: @Compile annotation?

This one's a quickie while I wait for my cab to take me to Cryptic Studios (woot!). I've been reading Implementing Fast JVM Interpreters Using Java Itself, a topic of interest to me since it partly mirrors some of the work I did at Sun last summer. As an aside, it's nice to see some of my design decisions on that project borne out by the fact that these guys did things the same way; for example, having the new bytecode just push a placeholder object onto the stack, deferring both allocation and initialization until the constructor is invoked. It's also interesting to see where they differ: my stack and local variable table both consisted only of objects, boxing primitive data types, whereas theirs consist of arrays of Cell objects, each of which contains an int, a long, and a reference.

Anyway, they run their interpreter on HotSpot, but the idea is it would be incorporated into a compile-only JVM (e.g. JikesRVM) to "provide low-latency execution for non performance-critical code": the interpreter would be compiled by the underlying VM, and then invoked on non-performance critical bytecode. But since they're running on HotSpot, the initial runs of the interpreter are themselves interpreted, resulting in double-interpretation, an issue they bring up but dismiss, since over multiple runs their interpreter should get JITed. However, in another section, they note that initially their switch over bytecodes was so large that HotSpot refused to compile the method at all.

All this made me think: Java has had annotations since version 5. Most of the ones that come with Java out of the box (@Override and @Deprecated are the ones that come to mind) are meant for compile time, but according to the Wikipedia page, annotations can be processed at runtime too, by the JVM. Why not have an @Compile annotation, which tells the JVM you'd like this method to be compiled if at all possible? That way, if you know a method is going to be hot, you can skip the initial interpretation and compile it straight away. Furthermore, if whatever warning flags are turned on, the JVM can notify you if a method you've annotated cannot be compiled for some reason. Note also that this isn't entirely without precedent: you can pass HotSpot the -Xcomp flag, which instructs it to compile all methods before running them.

That's my thought for the day. Off to Cryptic!

On the Tech Job Interview Process

I'm escaping graduating from Purdue in December, so I've been doing a lot of interviews lately. Previously, I had been under the impression that all tech companies have a roughly similar interview process, but it seems that this is, in fact, fact from the case, and I feel compelled to make some observations about the differences among them, including which strategies I think are better than others.

First, though, I should point out that I have a long history of choking on tech interviews. The first time this happened was in 2005 or 2006, in my senior year at Rochester. I had applied to Google as my one real-job option (my other options all being grad schools), and after a quick phone screen they flew me down to NYC to join a batch of on-site interviewees. I flubbed it, horribly. I forget the questions they asked now, but I remember a lot of umm-ing, err-ing, and hmm-ing on my part, and clock-watching on the interviewer's part. At the end of the day, I stepped out of the building, and almost immediately, I knew the solution to every single problem. More recently, I had a phone interview with Facebook, in which the first, easy problem I was asked to solve was to write a function to reverse a linked list. It took me a half hour, the length of the entire interview, to write a piece of code that under normal circumstances I could write in my sleep.

Every time I mention this, either to friends in the industry who conduct interviews, or in desperate postmortems with actual interviewers, the response is the same: "Yeah, programming interviews are a terrible way to figure out if a person is qualified for the job, but they're the best we've got." And so, for a long time, I believed that it was, indeed, the only available method for determining if an applicant were qualified for a programming job. The formula is pretty standard: a 15-minute phone screen by a recruiter to make sure you're not psycho, some number of programming phone interviews by developers to make sure you can code and solve problems, and then some number of on-site interviews of a similar nature, to make sure, before a decision is made.

The first real tech interview I had where I did well went very differently. It was with Sun Microsystems, and I was applying for an internship at Sun Labs. Since it was a Labs, and since I was interviewing with people relatively close to my own field of graduate work, after the phone screen, they could just go a few doors down and find someone who had done work in my area (STMs). They brought him on the line, and he and I had a very pleasant, detailed conversation about my work. Turns out I can talk about my work for hours, or at least, an hour, and well enough to convince someone that I'm worth hiring -- within a week I had an offer. I think my personality profile in this regard is pretty common among CS geeks: we can solve problems perfectly well (or better) away from the spotlight and discuss them at length afterwards, but put us on the spot to solve a problem and suddenly self-confidence issues come into play and we choke. Obviously, however, not every job I'm interested in has someone who's done STM work a couple doors down the hall, so even after this experience I figured that the standard formula I described above would be the one I most often experiences -- a less than happy thought, for me.

In the past few weeks, however, I have encountered a third variety of interview process, which, to me, is by far the best option, when the Sun option is not available. I'll describe in detail Cryptic's process, since I think it solves all the logistical problems neatly (Dear Cryptic: If I'm giving away too much of the plot, let me know, I'll edit this), but the basic gist is that there's an off-line coding interview prior to the main phone interviews. Obviously, this immediately brings to mind a few concerns, all of which basically center around preventing cheating. Cryptic solves the problem neatly as follows: once you submit your resume online, you're sent an automated email that tells you you that as part of the application process, they require you to complete a coding assignment. It is timed. You hit a button and you're shown the problems, and the amount of time between hitting the button and submitting solutions is timed; you're not expected to take more than five hours. You only get two problems, but they're both pretty difficult: my solutions were multiple hundreds of lines, and I took all five hours.

Both problems were definitely not of the cookie-cutter sort (e.g. "implement an aligned malloc"); the odds of finding solutions online would have been very low. Add to that the fact that you're only given two problems, which are probably selected from a pool of 10+, and the odds of finding a solution online are even lower. Since it's timed, you can't really post it to a forum and hope for a solution either, and every minute you spend trying to cheat comes of your final score. The only real way to cheat is to find someone willing to help you, arrange a time, and work on the problems together. And there is a subsequent programming interview on the phone to weed out anyone willing to do that.

The beauty of this solution is that, besides selecting potential applicants without the pressure of a spotlight while still making it very hard to cheat, the subsequent phone interview is much easier, because you've already passed the first stage. It's a huge confidence-booster. For my part, I didn't notice any of the choking issues I'd had in previous phone programming interviews. For a bigger company it might be harder to prevent the problems from getting out, but a big enough pool of problems to choose from plus some automated crawling and checking for online solutions should still keep the odds pretty minimal. Dear Google, Amazon, Facebook, etc: please, implement this interview process ASAP. Seriously, you're missing out on a large class of really valuable potential employees.

Finally, a tip to anyone who does find themselves in a more conventional programming interview. Everyone in my position hears this advice: don't try to come up with a fully-formed solution instantly, work the problem out out loud, etc. It's good advice, but here's a magic phrase that helped me actually do it: "This isn't going to be a final solution, I'm just going to think out loud for a while..." For me, that magic phrase was like permission to be wrong. As soon as I said it, I was able to say things I was unsure of. It's helped my phone interviews go a lot better.

Alright, that's all I have for now. Peace.