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.

Advertisements

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

Let the names begin!

April 27, 2009 at 5:59 pm (Ruby, Week 6) (, , , , , , )

I decided it’d be better if I gave more semantically meaningful titles, so that people have more of an idea of what they’re getting into when they happily decide to read about what I did at work. Today, clearly, is an exception (at least as it relates to my learning), but let’s look past that and on to a future where I’m not speaking in numbers anymore.

Eric and I worked most of the day on behind-the-scenes work for our Rails app: mostly automating the deployment with Vlad the Deployer and writing automated browser-based tests utilizing Watir. Both technologies are pretty cool. I’ve lived with Capistrano for some time, though I mostly used the outstanding Rails Machine gem as a starting point. Well, it turns out Vlad owes a lot to Capistrano and Rails Machine as well, so it wasn’t all that different. There were a few gotchas I ran across, namely some weirdness with set deploy_via, :remote_cache, but for the most part we were just re-learning how to set a deploy recipe up from scratch. Not too difficult once we found the list of Vlad variables, and it’s great to have things automated now instead of having to SSH in manually and make the changes we need.

While we’ve done our unit testing with RSpec and used Cucumber for most of our integration tests, we found that there were certain things we needed Watir for: SSL and Javascript testing, in particular. I’m pretty certain there’s a way to hook Cucumber up to Watir, but we ended up just wrapping these new Watir integration tests with RSpec, which works just fine for our current purposes. There were a few problems that required us to SSH into our staging server (which we’re running these Watir tests against), but once we figured out the syntax for multiple SSH commands on one line, we were home free (we have SSH keys set up to manage the login process, which I highly recommend for anyone managing servers):

ssh colin@jones.com 'cd /path/to/application/current/; rake do_task'

The single quotes are the key! Once again, thank you Google.

I also did a story by myself where our error page has a form to submit your email address if you have a problem and would like to hear back from the support team. Hopefully that story won’t see a lot of use, but I’m proud of it. The code is clean and will be easy to maintain, and there are good tests for it. I hope I’ll be able to say the same about my Limelight app once it’s done.

Permalink 2 Comments