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.

Advertisements

Permalink Leave a Comment

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

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

Getting more comfortable with Limelight

April 29, 2009 at 6:45 pm (Graphic Design, Limelight, Ruby, Week 6) (, , , )

OK, Limelight is starting to get fun. I’m finding my bearings in the framework, and I’m learning how to test different types of tasks. It’s really easy to do functional and view testing by adding a macro-style uses_scene :board call in RSpec (it’s built into Limelight as part of its spec_helper.rb). This gives you access to props on the scene that you specify. I’m also seeing some really awesome features of IntelliJ, which I’m learning to use better and am even starting to prefer over TextMate for the refactoring tools: Rename and Extract Method are two of my best friends at this point. Watching over Micah’s shoulder yesterday as he tracked down some Limelight source code, I learned the beautiful Command-Shift-N command to find files by name and autocomplete (like TextMate’s Command-T, which I’d missed very much).

The fact that all of Limelight’s code is in Ruby means there are lots of opportunities to cut down on repetition, which is especially welcome when it comes to Styles and Props (Limelight’s analog of the stylesheets and HTML elements we’d see in Rails). There are some tricks you have to be aware of to share data across files. There’s nothing like Rails’ passing of instance variables from controller to view, as far as I know. But luckily there’s an object called the production that everybody has access to, and we can add attributes to that object to hold data that needs to be available across files (in my case, references to the object that communicates with my Java code and some styling concepts).

And speaking of styling, I’m now armed with a handful of design-oriented links from my designer friends. Most are website gallery sites, but there’s a blog or two in there as well. Now, I’m not under any false impression that I’m suddenly going to be a designer by looking at some websites, but I’m sure I’ll improve. I have two Scenes (like views) in my application, and I’m relatively happy with the styling I did today on the first scene (the game type choices, like “Computer (X) vs. Human (O)”), but the second scene (with the board) definitely needs some work. I got a nice, simple color scheme from kuler.adobe.com, and I even did a little fade animation (you can easily change the transparency of props) as the scene begins.

Permalink Leave a Comment

Exploring Limelight

April 28, 2009 at 9:44 pm (Limelight, Ruby, Week 6) (, , , , , )

I spent the day continuing and accelerating my learning in the Limelight GUI framework. I’m sure I’ve mentioned before, but everything you write is Ruby code (there’s Java behind the scenes, so you run your applications with the JRuby interpreter and gems. Limelight is still very young (pre-1.0), and as with any framework, it takes time and advice to learn how the framework wants you to code. I ran across a couple of things that I felt would be more intuitive with a slightly different API (mostly styling-related), and Micah agreed and had me report them on the project’s Lighthouse page. There’s not a ton of tutorial documentation on Limelight so far, but here are the most important ones I know about already:

  • Installing Limelight
  • Calculator in 10 Minutes Screencast – Micah walks you through building a lightweight calculator application
  • Tutorial #1 – there’s a slight tweak you need to do to get it working this way, at least on the latest Limelight version
  • A Cook’s Tour of Limelight – great deeper-level overview of the parts of Limelight (Production, Props, Scenes, Players, Stages)
  • Style Attributes – similar to CSS style attributes, but with some awesome additions like built-in gradients and rounded corners (there are plans for drop shadows as well)

I’m sure as time goes by, there will be a lot more available, especially as JRuby gains in popularity. Keep your ears open!

I got the Tic-Tac-Toe game working with human players, which was a big step. There are still some kinks to be worked out with the “Play Again” process (I think my Java code is left waiting for input), but I’m excited to have it working, and to have spent the day getting better and more confident with BDD. Once I’ve patched those up, the real work will start on this assignment: styling it up, adding some effects, and in general just making it really presentable, with relation to the UI and design. I know my designer pals would be scared to hear about me designing anything, but I’d like to add some more design skill to the old bag of tricks, so I may be hitting them up for links to design blogs and other learning resources.

Permalink Leave a Comment

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)
Java::trptcolin.main.TicTacToe.newGame(@view)
end
end


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

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