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

Flex, AIR, and ActionScript, oh my!

May 5, 2009 at 6:00 pm (Flex, Week 7) (, , , )

I’ve thought for a long time that I’d like to have at least a cursory knowledge of ActionScript (the scripting language that runs on Adobe’s Flash platform), and once Flex became more well-known I thought of it more often. Today Micah gave me a reason to actually get into it a little bit. My assignment was to investigate AIR, Adobe’s newest platform, which allows you to run Flex applications outside the context of the browser as regular desktop applications. The idea is sort of a kiosk-mode application for a client, and while I encountered (and partially) some technical problems with Flash’s security mechanisms, I also gained some reading knowledge of ActionScript and MXML, the markup language for Flex.

I haven’t done anything really interesting yet as far as layout goes, but it was super-easy to embed basic web browsing capability into the application:

height="100%" width="100%"
location="" />

I only did some very basic ActionScripting, but it shares some syntax with JavaScript: the var keyword for local variable declarations and the function keyword for, well, you know… On the other hand, ActionScript has classes, which is of course more like Java. The technical issues I ran across forced me to look into a good bit of event and listener code, which is good for me since that’s probably the aspect of JavaScript I understand the least. Luckily, I happen to know an ActionScript master from my Athens days, and he was able to set me straight on a minor limitation of the Flash platform.

There’s a little weirdness in the construction of an AIR application. A lot of the just-starting documentation assumes that you’re using FlexBuilder (Adobe’s expensive IDE), and I’m not. Also, you can do a lot of behavioral programming in Flex either with ActionScript or with MXML. I wasn’t sure how to get started with plain old ActionScript, so I have kind of a bloated MXML file at this point (all my ActionScript is embedded in mx:Script tags). I’m sure there’s a way to extract that to another file, but for now I’m just spiking to see if this is a technology that will work for our client.

The big question marks left have to do with packaging up the AIR runtime (and with it, I suppose, Flash itself, in case that’s not installed) so that the install of our application would include the installs of Flash and AIR. Once I finish tracking down the answers to Micah’s questions on AIR, I’m going to be joining him and Doug on their project. I’m very much looking forward to having more opportunities to see them in action coding, and also to be working in a new domain. Also, their project has one component written in Objective-C, so it will be cool to at least get a bit of reading knowledge in that language.

Permalink Leave a Comment

Back and ready for action: reading and writing

May 4, 2009 at 9:40 pm (Limelight, Reading, Week 7) (, , , , , , , )

Well, I’ve played my last trumpet gig on the books for the time being. Took a trip down to South Carolina over the weekend to play a wedding ceremony and visit my mom. It was a good trip, and I actually got a decent amount of work done, believe it or not. The Limelight GUI that talks to my Java Tic-Tac-Toe code is finally in a completed state! I showed it to Micah this morning, and he didn’t have much to say at first besides that it worked pretty smoothly (he also noticed that I’d put in artificial sleeps to make the Computer vs. Computer game look more interesting). We spent a bit of time looking at some problems I was having with a refactoring in a Props file, but didn’t make much headway.

Most of the other work I did over the long weekend was reading – I’m really enjoying Michael Feathers’ Working Effectively with Legacy Code. I’ve noticed that most TDD resources I’ve read so far have dealt with simple, granular situations, where the design is perfect. But when I go to write tests for my code, I find that things are much more complicated. This tells me that at least one of two things are happening:

  1. Most textbook examples are simpler than real life situations
  2. My design isn’t clean enough

My estimation is that both are the case, but at any rate, I’m getting more and more motivated to write tests, even when it seems like it might be difficult. Particularly, the ideas of “sensing” and “separating” are helping me to crystallize what exactly I’m trying to accomplish when I write tests. The idea is that if I have an implementation method that needs to set a variable, I need to write a test that somehow senses the change in that variable based on the use of that method. It’s a simple idea, but there are a lot of ways that legacy code can make this difficult.

My next assignment was to pretend I was a writer (gasp!) and write a review of Limelight, as though it was for a magazine or something. I found myself drifting into tutorial mode for a paragraph or two, but eventually made my way toward an opinion on the framework. Basically, I think it’s great. There are a few strange behaviors here and there, and some features I’d like to see added, but it’s pretty cool to have a desktop application framework where you only need to write Ruby. Now, I must be completely forthcoming and admit that I’ve never tried any other Ruby GUI frameworks like Shoes, RubyCocoa, or wxRuby. In taking a cursory glance at Shoes (by everyone’s favorite Ruby mad scientist, _why), it looks interesting and feature-packed, but I’d like to see bigger examples, with the same separation of concerns that Limelight boasts. I’d also be surprised if interfacing with Java code was easy, or even possible, since Shoes doesn’t use the JVM.

Whew, I think I’ve written about all the prose I can write in a day; think I’ll spend the rest of the evening working some more SICP exercises. I watched another lecture over the weekend and finally started to look at the book and its exercises. It’s definitely forcing me to think in a very different way than I’m used to – I think this is exactly what Dave Thomas and Andy Hunt had in mind in The Pragmatic Programmer with their suggestion to learn a new language every year. At this point, I’m trying to learn several this half of the year, but since I’d at least written some cursory Java and Javascript code, I think I’m OK for now. I do worry sometimes about stretching myself too thin and becoming a jack of all trades, master of none, but as long as I can keep improving on all the fronts I’m aware of, I think I’m in good shape.

Permalink 1 Comment