The big dummy moment and first remote pairing

May 19, 2009 at 8:47 pm (Java, Javascript, Ruby, Week 9) (, , , , , , , , )

This morning I finished up most of a task from our biggest story, with some pointers from Micah. The big dummy moment came at the end of the morning, when I spent about an hour debugging why Javascript wasn’t working properly in our customized Webkit browser, and after going through everything I could think of, I realized that the browser had cached the Javascript file! Ack. So, my choices were to figure out where the cache was and clear it, or to do what Rails has always done for me behind the scenes to prevent caching: append a question mark and a big number to the filename. We’re using Sinatra, so I wrote a simple helper that does the latter:

def no_cache

Pretty simple, but I’m not sure I like the way it looks tacked onto the end of the filename in the Erb templates; that may need to change to take a parameter…

I spent a little time in the afternoon working on a JRuby bug that the JRuby team posted on their Twitter feed. The problem was with Array#pack, which I’d never used before (and quite honestly, still don’t entirely understand). It takes a formatting string and packs an array into a string. There was a problem when the asterisk (*) was used in a format string like “A4N*” – it’s supposed to take all the rest of the parameters from the string, but it was taking too few. I tracked it down to a change in value of a local variable (listSize). It was hard to spot, because I wouldn’t have expected the list size to change, so I wasn’t looking for that. Lots of System.out.println’s and compiling ensued. It really gave me an appreciation for Ruby’s interpreted nature. I’m sure there’s a way I could’ve streamlined things, but it was taking me 30 seconds to build the project each time, which is an eternity when you’re just debugging and adding print statements (and especially if you’re not too sure of what you’re looking for).

Micah and I did some remote pairing in the late afternoon, which I’d never done. We used iChat, which was really pretty awesome. We had some problems with audio volume and crashy programs, but all in all, I think it was pretty successful. Micah came up with a new data structure to eliminate some network traffic in our application, and we implemented it, simplifying code and adding a feature along the way. This was code I hadn’t seen before, but it felt a bit easier to get around – partly because it’s just simpler, and (hopefully) partly because I’m getting better.

Permalink Leave a Comment

Using Javascript to order the client around

May 17, 2009 at 10:00 pm (Java, Javascript, Ruby, Week 8) (, , , , , , )

Micah and I spent most of Friday working on a lightweight messaging system that’s going to allow us to push messages from server to client, even though the client is basically a web browser. Since HTTP is basically stateless, we’re doing it with AJAX requests (Javascript, with some help from JQuery). And in order to keep it really simple and flexible on the client side, we’re developing something like a message queue on the server, which builds up Javascript for the client to execute whenever it’s ready (this way the server keeps track of time-sensitive issues, and the client doesn’t really have to hammer the server to stay updated). It’s a pretty cool idea that Micah had; he likens it to us putting food on a plate (at the server), and when the client’s hungry, he comes along and takes the food that’s there and eats it (executes it in the browser). We’re using the command pattern to fill up the plate of Javascript.

The lunch & learn was a bit more technical this week (after last week’s great Star Trek excursion), but still great fun. Doug presented a prepared code kata: TDD factorials in C++. I had already seen a little of CppUTest from pairing with Doug earlier in the month, but he went a little more in depth explaining the syntax, which we had just kind of touched on before. He’s teaching a TDD class this week, which I’m sure will be awesome for anyone lucky enough to attend.

Eric Meyer presented the development of a story using acceptance test driven development (ATDD) with Cucumber. He and I had worked with it a good bit while developing our Rails app (which by the way has been live for awhile now): a job board for software craftsmen, so I knew the syntax and structure already. Eric used a great technique to get the story done quickly and correctly while doing a good bit of live coding as well: git tags. He had about 8 steps to the development of the story that he had practiced, and each one was tagged, so that he was free to code in a normal way and know that we could fast-forward to the next step at any point. I’d like to learn more about version control (both Subversion and Git), but it’ll just have to go in the bucket of stuff to learn with everything else!

In less technical news, I finally got a Cubs hat. Look out Chicago, now you might have to hear me say “Y’all” before you know I’m not from around here.

Permalink Leave a Comment

More fun with JRuby (but for real this time)

May 14, 2009 at 10:19 pm (Java, Ruby, Week 8) (, , , , , )

Well, I knew I would see some benefits from my seemingly unproductive work yesterday, but I didn’t imagine that I’d be able to have a patch together today. It turned out that with the knowledge I gained yesterday, along with some smarter strategies, I was able to fix the issue with spaces in directories housing jarred gems that was haunting me. It wasn’t easy, but I tracked my way through the JRuby source and submitted a tested patch to the JRuby issue tracker. We’ll see; maybe it’ll get accepted, or maybe there’s something I haven’t thought of that’ll hold it back. Either way, I gained a lot of confidence, and I’m excited about taking up Charles Nutter’s call to fix RubySpecs in JRuby. Very timely!

I was also in on some meetings with the rest of the development team Micah and Doug are working with. They’re based remotely (Doug just flew back into town after working onsite with them), so we did some teleconferencing using Skype for video chat and Adobe Connect for screen sharing. It’s pretty amazing technology, and while I can’t discount the great value you see from working side-by-side all the time, I’m impressed that it’s so easy.

Micah and I did some CSS and Javascript (JQuery) work towards the end of the day. He’s not a fan of the CSS float attribute, so I had to convince him that it was worthwhile for the layout we were working with. Of course, there are generally multiple options, this case included, but I think we ended up with a good starting point for a screen we were laying out. JQuery’s AJAX capability is pretty awesome. We used JQuery.getScript(), which fetches a script from a URL and then loads and executes it (with an optional extra function parameter to run afterwards). It basically does the work that we would’ve had RJS do in a Rails application, but it seems much cleaner to me. We still have some thinking to do about how the performance is going to be in our particular case (1 web request per second will almost certainly be too heavyweight), but it’s a great start. The other big question mark for our current task is to what extent we’ll be able to test it. Luckily, resident TDD Javascript expert Jim Suchy is going to help us out with that. Thanks Jim 😉

Permalink Leave a Comment

JRuby struggles yield rewards

May 13, 2009 at 9:21 pm (Java, Ruby, Week 8) (, , , )

I was a bit cranky when I left work today, because I wasn’t able to track down the problem I was working on. I spent hours looking for the solution(s) to some outstanding JRuby issues with jarred gems, (one related to spaces in directories and one related to nested jars (like Hpricot and Limelight both have). And I got nowhere. Nothing to show for my efforts. I went down a ton of paths, tried logging, and added stack traces, but to no avail. The solution exists in the code, but the codebase is large, and I just wasn’t able to wrap my brain around the problem. And that sucks.

But in every situation, there’s an opportunity for learning. Eventually, on the way home, I relaxed and looked for the lesson in my failure today. I didn’t fix the issues, true. There’s no metric that I know of that says something positive came out of my work today. But I introduced myself to most of the filesystem-related components of the codebase, and I saw the mappings JRuby provides from Ruby methods to Java methods. (Annotations to the rescue for those Ruby methods like []= whose names would be illegal in Java!) I really internalized some keyboard shortcuts in IntelliJ. I learned a new trick where you press Command and hover over a method call to see information about it and the object it’s defined on.

Most of all, I learned what not to do when presented with a big codebase and a specific-sounding problem. I just jumped in, looking at the first place I saw referenced in the issue comments, and logging things, working at a micro level basically all the time. It wasn’t I got home that I realized I needed to step back and look at what was really happening on a larger scale – the context. I should have realized my problem during the day when I tried to explain the problems I was having and couldn’t really do so – next time I’m having these kinds of frustrations I’m going to pull the old rubber-duck trick (explaining the problem to a rubber duck or other inanimate object). If I can’t, something needs to change in my process.

Permalink Leave a Comment

Crazy Java/Windows problem and some Scheming

May 12, 2009 at 8:34 pm (Java, Limelight, Ruby, Scheme, Week 8) (, , , , , )

As soon as I came in this morning, Micah asked for my help with a bug he’d been working on tracking down in some Java JNA code in the Limelight source. The gist of the code is that it was calling some native code in Windows DLLs, and about half the time, one of the API hooks didn’t get properly installed. We looked and looked, eventually doing some print statements looking for threading issues and other possibilities. Take a look at the code and see if you can spot the problem:

new Thread()
  public void run()
    W32API.HINSTANCE appInstance = Kernel32.INSTANCE.GetModuleHandle(null);
    final User32.HHOOK keystrokeHook = User32.INSTANCE.SetWindowsHookEx(User32.WH_KEYBOARD_LL, new KeyboardHandler(), appInstance, 0);
    hookThreadId = Kernel32.INSTANCE.GetCurrentThreadId();

Well, if you knew right away that the new KeyboardHandler() might sometimes get garbage collected before the Windows code gets around to calling it, then you’re lying. Just kidding! I am very impressed if so. Once we looked back on the problem, we could see how the problem might have happened, but it was really bizarre. The idea is that because we don’t hold onto a reference to the new KeyboardHandler() that we create, the garbage collector could think we’re all done with it, even though the Windows code really needs to hold onto it. We didn’t look in depth into how JNA translates the Java code into native Windows code, but Micah understands it, and I think he said it passes a function pointer to the Windows code in this case, so when Windows tries to callback to our Java code residing in that pointer, that code is no longer there. Wacky.

We also made an installer using install4j, which seemed really easy. I’m not sure how much setup Micah had already done, but we were able to drop in some custom icons and a splash screen really easily for our application, and it looks good on both Mac and Windows. I did my first work in Photoshop CS 3, and it was weird not so have the Save Optimized As.. option that I’m used to from Photoshop/ImageReady CS.

I spent some time this afternoon practicing recursion by writing methods to identify palindromes. I did it in Scheme, Ruby, and Java (in that order), all TDD, all in different editors. Of course, Ruby was the easiest and clearest by the end (negative array indexing helped out!), but Scheme wasn’t as hard as I’d expected. Things may be getting easier!

By the way, if anyone else is going through SICP and feeling like you need some more interesting assignments than reading the online book and watching the lectures, check out the sample programming assignments on the website. Even the first one (Exercise 11) might blow your mind if you’re like me and not so used to functional programming.

Here’s a taste:

(define foo6
  (lambda (x)
    (x (lambda (y) (y y))))

Give a Curried application of foo6 that evaluates to 3. Keep in mind this means that at some point you have to evaluate an expression which is a function applied to itself! Yikes. I’ll post my solution later, if anybody’s interested, but I don’t want to give it away too easily. I probably spent a good hour thinking this last one over, and learned to think in a different way in the process.

I need to find a new way of embedding code in this blog. Since it’s hosted on WordPress, I can’t include Javascript embeds of a Gist or Pastie, and I also don’t really have control over the styling. Any suggestions?

Permalink 1 Comment

Cleaning XHTML & jarring gems

May 11, 2009 at 9:30 pm (Java, Limelight, Ruby, Week 8) (, , , , )

Back to my beloved XHTML 1.0 Strict and CSS today. I took some code that came from a client as a quick MS Word-generated web page, grabbed the important things, and deleted. And deleted. And deleted. Always a great feeling to get rid of redundancy. Code like this:

<td bgcolor="#FFFFFF">&nbsp;&nbsp;&nbsp;</td>
<td bgcolor="#FFFFFF">Some Text</td>
<td bgcolor="#FFFFFF">&nbsp;&nbsp;&nbsp;</td>
<td bgcolor="#FFFFFF">&nbsp;&nbsp;&nbsp;</td>
<td bgcolor="#FFFFFF">Some More Text</td>
<td bgcolor="#FFFFFF">&nbsp;&nbsp;&nbsp;</td>

makes me want to laugh and cry at the same time. Maybe it should start its own Broadway musical. At any rate, it’s a bad laughing and a bad crying, so it had to be fixed.

I got to check out Sinatra a little bit in the process, which was pretty cool. It took me a little bit to figure how to get Sinatra serving up images and stylesheets, but it’s very clear once you know!

set :public, File.dirname(__FILE__) + "/views"
set :views, File.dirname(__FILE__) + "/views"

Public and Views here have similarly-named analogues in Rails. They’re basically what you’d expect.

Micah, Doug, and I worked some more on jarring up gems, and despite some current limitations, we now have a great start on an idea for distribution. If you’re looking for answers on how to do it, check out Nick Sieger’s blog, the best source we’ve found on the topic. Be sure you know what commands and options you’re using, and how they relate to gem directory structure. I had a lot of trouble understanding how gem directories are laid out, and how that related to the jar directory structure, but now I have a good basic idea.

On an unrelated note, if you walk outside real quick to pet the cute new puppy next door, it’s great that you remembered to take your jacket, but it would be best to bring at least one of the following, since you locked the door on the way out: (1) keys, (2) phone, or (3) wallet with ID and spare key. This will avoid embarrassing encounters with neighbors you hadn’t met (although this is one good way to meet people). Not that it happened to me… just sayin’.

Permalink Leave a Comment

Some Limelight refactoring and Java learning

May 10, 2009 at 10:33 pm (Java, Limelight, Week 7) (, , , , )

Micah and I paired most of the day on Friday on adding a kiosk mode to Limelight. Since the codebase is a mix of Java and Ruby, we were moving back and forth between the two languages (and JUnit/RSpec), but our changes were mostly in Java. There weren’t really too many big surprises along the way, and we worked incrementally enough that, in most cases, I was able to figure out what kind of tests to write. Of course, I did get stumped a few times, but rather than just write the tests himself (which I know he could’ve done in a few seconds), Micah helped me to see the bigger picture of what exactly we were trying to test, and the tests themselves came soon enough after that.

Our Friday Lunch & Learn went in a very different direction than usual – we took a little field trip out to the movie theater and caught the new Star Trek movie. Good stuff; I recommend it!

This weekend, I’ve been finishing up reading the book I’m reviewing, and I’m really enjoying that. It’ll be a good read when it’s done, and it’s already really interesting and helpful (it’s on agile coaching). The other book I’m working on is Thinking in Java by Bruce Eckel. I’ve been pecking at Java since I arrived in March, but I feel like I’d be much better off armed with a more solid understanding of the language, like I have with Ruby. This book is great. I have it checked out from the library right now, but I may actually still end up buying it just because it clarifies so many things. One particular thing I loved when reading this morning Eckel’s coverage of polymorphism, edge cases where you might expect late binding but don’t get it, and the fact that you shouldn’t encounter these edge cases often because there are better ways to design your code. I’m reading in this book a lot of the same OO design principles I read and hear about everywhere else, but with different words, which kind of hammers it home even more.

I watched Uncle Bob’s RailsConf keynote and enjoyed it. I know that a few have pooh-poohed the talk (though many more loved it), and I do agree that the tongue-in-cheek testosterone / estrogen metaphor is outdated, but who can disagree with the crux of his argument? We should drive development with tests, have some humility, and take on tough problems like legacy codebases. Being a professional means different things to different people (one of Uncle Bob’s descriptions), but to most it means you’re good at what you do and that you’re serious about being good (but not necessarily serious about yourself and wearing a 3-piece suit all the time; that’s an entirely different meaning).

Well-tested code means you don’t have to be afraid of change. I worked on a larger project on my last job that took forever to change, because there were virtually no tests. Any change I made to the code (and on any big project, there are plenty of changes) meant I risked breakage. Luckily, the code wasn’t hammered by users or mission-critical, but it is so embarrassing to have bugs in your code, especially when they’re discovered by the client. If I had the skills at the time to get more of that project under test (and I have a good idea of what to do thanks to my apprenticeship experience so far, along with Michael Feathers’ book), things would have gone differently. Changes might not have been that much easier just because of the tests (there are also OO design issues to consider), but they would have been verifiable. I would have known when I had it right.

Permalink Leave a Comment

Understanding a larger application

May 7, 2009 at 8:17 pm (Flex, Java, Ruby, Week 7)

After a couple of hours this morning going through the web, searching for a way to make native OS calls from ActionScript (in Adobe AIR), I’ve come to the conclusion that right now, the only way to do it is to wrap AIR in another application like Shu. Mike Chambers also has a proof of concept for another wrapper called CommandProxy. I’m not sure yet whether we’ll go in that direction or not, but this seems like a big strike against using AIR. The idea is that for this application, we’d need to completely control the desktop, eliminating things like Cmd-Tab (or Alt-Tab on Windows), Alt-Cmd-Esc (Ctrl-Alt-Delete on Windows), etc.

It’s always frustrating to dig around on the internet looking for a way to do something and in the end coming up short. What kills me about it is that there’s always that chance that the solution you’re looking for exists, but it’s difficult to find. I can’t imagine being a programmer before Google; I can see myself getting stuck for days on things. On the other hand, at a company like 8th Light, my best (and quickest) bet is usually just to ask around. But in this case, there are no confessed ActionScript gurus here. At any rate, whether the work I’ve done gets used or not, I’m impressed to realize that I don’t really have to spring for the $249-$699 Flex Builder application to play around with ActionScript and Flex.

The rest of the day, Micah, Doug, and I worked through some story work (even looked briefly at some Objective-C code) and ran into some issues with bundling JRuby gem files in a jar. I’m inspired to try and recreate the problem here at home, so I’m looking forward to a fun evening of learning about java -jar (and JRuby), with the off-chance that I’ll actually figure something out. It was really cool to see the way Micah and Doug reacted to the problems. Basically, after exhausting all of the permutations and possibilities we could think of, we took a step back, evaluating what we were trying to do at a higher level, and realized that while we need a solution for this problem eventually, we were OK for now and didn’t need to bash our heads against a wall. The solution will come, and tomorrow it will be easier than today.

Permalink 2 Comments

Prime factors and the first client project

May 6, 2009 at 6:34 pm (Flex, Java, Limelight, Ruby, Scheme, Week 7) (, , , , , , )

I worked with Doug almost the whole day today, which was great. This morning when I came in, I happened to mention that last night, I’d done the prime factors kata, inspired by tweets from Doug and Caleb, but I used Scheme: the results are in a Gist. It was pretty frustrating trying to do this in a functional style, purposefully avoiding defining anything other than functions, but I sure learned how poorly I understood Scheme’s list-building constructs (cons, cdr, and car). I have a feeling there are clearer ways to do this, and I’ll definitely try again at some point to make it more fluid (I was completely stumped several times).

So, we spent some time in the morning working through the kata in C++, which was awesome. I hadn’t written any C++ since my only CS course in college, around 10 years ago, and what I wrote then was of course very simple. We used CPPUTest as our unit testing framework, but luckily, Doug already had the tests constructed, so we uncommented one at a time and concentrated on the implementation. I’d like to look into testing C++ a bit more at some point, but it may be awhile, considering all the other things I’m learning. We found several variations on the process of solving this problem, and the process of solving it became clearer, slowly but surely, as we worked through it several times. Then Doug said I should “perform” the kata for Caleb, which I did in Java (and in the process learned how much I rely on my IntelliJ Live Templates when I’m writing JUnit test code!) At some point I may try my hand at screencasting and record myself performing it, but I think I need a little more practice first!

Later on, after I struggled through setting up FlexUnit for the small AIR/Flex I’m building, Doug helped me get my bearings in the client project I’m working on now. We were writing Ruby, HTML, and JavaScript code most of the day, though Objective-C is also part of the project, and Flex/ActionScript may be eventually. It was awesome to be working on a bigger project and finding myself able to figure our what’s going on relatively quickly. My Limelight experience with Tic-Tac-Toe definitely paid off – if I hadn’t spent some time with that, there’s no way I would’ve known what was going on today. Of course, the technology itself wasn’t the sole aim of the Limelight Tic-Tac-Toe project – visual design was a big part of that, too.

At any rate, I’ll obviously have to be a bit more vague about project details now, but I’m excited to be getting into some client work, and I know I’m going to learn a lot from seeing Doug and Micah code on a regular basis.

Permalink 2 Comments

Week 5, Friday

April 25, 2009 at 10:22 am (Java, Limelight, Ruby, Week 5) (, , , , , , )

I took the steps necessary to have no parameters in the constructor for my Tic-Tac-Toe view class, so that we could implement the interface in JRuby during our Randori session over lunch. I’d spent a little time thinking about what it would take, so it wasn’t too bad. I had three parameters initially: a Controller, a PlayerFactory, and a Board.

Well, the PlayerFactory was only really being used in one method, and all we really needed there was an array of Strings that showed the types of games that were available, like “Computer (X) vs. Human (O)”. So I changed that method to take an array of strings, and changed uses of that method to pass in information from the PlayerFactory (they were all in the Controller, so no new package dependencies resulted).

Also, since the Controller already had a reference to the same Board object as the View, I just added a getter called getBoard() on the Controller, and used that to set the Board on the View rather than the constructor.

The last thing was taking the controller out of the constructor. The View needs the Controller, for sure, so I added a setter on the View, which any class that instantiates a View would need to call right after creating it. I don’t much like this, since I had to change all my test class setups, and it’s more work for anyone wanting to implement a View, but I think it’s necessary to make the connection to Ruby code.

I also started with the Limelight props and styles being built already, so for the Randori, we focused on implementing the View interface in Ruby. We worked in IntelliJ, and there were a few tongue-in-cheek complaints about that (from Textmate fans). I definitely don’t know IntelliJ as well as I know Textmate or even Vim, but the big plus it has for me is the ease of refactoring, and the color-codification of things that are not going to compile or run properly. At any rate, we got a lot done. After a bit over an hour, with rotation of pairs every 5 minutes, we almost had a running Limelight application that used two computer players. I just had to change a couple lines right afterwards to get it to work as expected.

I have to say, I was initially skeptical when Micah told me we could use my Ruby version OR Java version of Tic-Tac-Toe to implement it in Limelight. I knew my Ruby version worked, but looking back, I knew its OO design was weak; I don’t think there was any kind of display class at all, so I’d have had to change a lot – I may still do that. But to use Java classes in Ruby code? That sounds crazy, but honestly, it wasn’t too bad. But I guess the person showing us how to do this has written a framework using Java and Ruby, so you’ll have to decide for yourself:

require '/Users/colin/IdeaProjects/TicTacToe/tttt.jar'
module Board
def scene_opened(e)
@view = new View(self)

class View
include Java::trptcolin.baseGame.View
# implement methods

Now, it may only be this easy because we’re doing it through Limelight, but either way, I think it’s pretty nifty.

I felt a lot less embarrassed about my abilities during this Randori than at the last one, where I was basically useless. This time I had a lot of domain knowledge to offer (since I wrote the Java code and the Limelight props), but more importantly, I had a better idea of what to test when I was at the keyboard. I still felt slower than everybody else, but at least this time I felt like we were more or less on the same page.

Permalink Leave a Comment

Next page »