Slicing & dicing, and Chicago Code Camp!

May 31, 2009 at 1:55 pm (Ruby, Scheme, Watching, Week 10) (, , , , , , , )

Friday I spent the morning with Eric Meyer working on the same Rails app Jim and I had been working on last week. We got two bugs knocked out pretty quickly, and we also did some planning for a database refactoring (not as big of a deal as it sounds like, as the system isn’t in production yet). Eric’s laptop was having some boot problems, so we used mine; hopefully his Time Machine backup worked over the weekend – there aren’t many things more frustrating than not being able to boot. In the afternoon I chopped up a new website that should launch on Monday, showing Paul some tricks with the Slice tool in Photoshop along the way. I feel like I’m pretty efficient slicing up a PSD into XHTML/CSS – hopefully before too long I’ll feel that way in the code world!

Saturday was Chicago Code Camp, and it was awesome. The first session I went to was “Trends in Continuous Integration and Software Delivery” with Sean Blanton of OpenMake software. He went through the major features of a continuous integration system, and while we’ve got one in place for a couple of websites I work on (cc.rb), there was a lot of information there. I never realized how many different systems were out there. I was impressed with the fact that Sean wasn’t just pimping his products (Mojo and Meister) – it really seemed like a pretty fair assessment of the different systems. There were a couple of slides on Git, actually, which talked about how powerful it was, but that it might be hard for novices to get into. I thought that was odd at first, but as people asked questions I realized that Subversion and other systems have lots of GUI implementations that integrate tightly with OS’es, and Git doesn’t have so many yet. Maybe that’s a good project for someone…

Then I made the tough choice to miss Eric Smith and Eric Meyer’s talk on “TDD for the IPhone,” in order to attend Dean Wampler’s talk on “Better Ruby through Functional Programming.” Sorry, guys! I figured that since I’m working on a presentation involving functional programming, and I mostly use Ruby during work hours, I’d learn a lot there. And I did! I have a much better grasp of what functional programming is now, and how to apply that to Ruby (it can be done without too much hassle, actually). There was one particularly interesting point where Dean posited that we’d see programming (and concurrent programming in particular) become more functional on a small scale, but still object-oriented on a macro level.

Micah’s talk on Limelight (“Develop your Graphical User Interfaces (GUIs) faster than ever, with a thorough suite of unit tests to boot.”) was great, but it was tough because the 8th Lighters were the only Rubyists in the audience (I think), and there were only a few Agile/TDD practitioners. But there was a powerful point about what to do when something is hard to test: rewrite it so that it’s easy to test. And that’s just what Micah did with Limelight – which is indeed easy to test, once you know what you’re doing.

Next, I went to Dean’s other talk, “The Seductions of Scala,” and missed Jim’s “TDD and JavaScript” talk. Sorry, Jim! I had seen a version of Jim’s talk on Friday during the Lunch & Learn, and it was awesome. I’d of course heard about Scala because of the big Rails/Scala/Twitter debacle awhile back, so I was interested in what a language looks like that’s built with concurrency in mind. The language runs on the JVM, so like JRuby, it’s easy to interface with existing Java code. There is some strange-looking syntax to get used to, but it seems interesting, and it sounds like it’s gaining traction on production systems. I had thought the next language I took a look at would be Clojure, since it’s a Lisp dialect with concurrency in mind, and I’ve been studying Scheme, but now I’m thinking I may look into Scala. Or maybe learn JavaScript right. We’ll see. Incidentally, Dean’s new book, Programming Scala is available online in draft form as a preview – it looks great!

Micah’s last talk on “Ruby Kata and Sparring” was great. I’d seen forms of it before: the Langston’s Ant Kata and RubyConf 2008. There’s some kind of magical stuff in this version of the kata (instance_eval), but it’s extremely elegant once you understand the algorithm. I really like the notion of practice as important in software development; Paul was talking about this earlier in the day as well. I’m going to try to do the same kata 3 times a week for a few weeks and see if I see any benefits. I know from trumpet playing that even playing ridiculously easy exercises on a regular basis, with strict attention to form, can yield great benefits.

Permalink 2 Comments

Photoshop, Radiant, and threads

May 28, 2009 at 6:59 pm (Graphic Design, Week 10) (, , , )

I polished off the old Photoshop skills today to put together a design for an upcoming event web site. Things came back to me relatively quickly, but it’s still an amazing program that I’ll probably never master. The CS 3 version of Photoshop, incidentally, gives you the ability to select multiple layers in the Layers palette. I’m pretty pleased with the way the design is coming together so far; it’s almost done; I’m just waiting on a logo to finalize the look for the header. I ended up using a lot of shapes and the Direct Selection tool to modify them when the shapes needed to change. It seems like the Agile way to design: change becomes very easy, compared to just painting and filling selections.

Caleb and I are going to be working on the site together, and we’re pretty sure we’re going to use Radiant for the site. Radiant is a CMS (content management system), using Rails. It’s installed as a gem, which makes things very easy and makes our work mostly configuration rather than re-inventing the wheel by coding up an admin section. We don’t need anything too complicated, just some image uploads and static information. We took some time this morning checking out Radiant’s extension system to make sure it’s going to be customizable enough, and I was really pleased to see how easy it was. I’m looking at Keith Bingman’s paperclipped extension, which is based on Thoughtbot’s excellent Rails plugin: Paperclip.

I’m also working through Uncle Bob’s The Craftsman articles (click “Craftsmen” on the link to get to the articles), which I’d started a month or two ago, but fizzled out on. Justin Martin’s apprenticeship blog reminded me to get going on them again, and I’m thinking a lot more about concurrency. Threads have seemed fairly magical when I’ve used them (and seen Micah use them) so far, so I definitely need to do more reading and practice with them.

Permalink Leave a Comment

REST, refactoring, and the best cheap sandwiches

May 27, 2009 at 7:19 pm (Ruby, Week 10) (, , , , , )

Today Jim and I finished up the second iteration of our client project on Rails (I had been under the impression that we were on iteration 1 until this morning’s stand-up). I coded a story on my own early in the day, along with some styling and validation work, and we paired to finish off another story (and do some refactoring) later in the day. It was a little hectic, and we ended up not quite finishing all of the stories for the iteration, but the good news is that we have well-tested, relatively clean code that will be easy to modify and refactor as changes become necessary.

I was excited to see that in Rails 2.3.2, overriding a RESTful route doesn’t seem to force you to manually override routes on a per-action basis when you want to add non-RESTful actions (through the use of the member and collection parameters to the routes file). Our growing understanding of the project is guiding us towards refactoring those actions to their own controllers (making them CRUD/RESTful along the way). We haven’t done that refactoring yet, but in the meantime, it’s nice that Rails is now doing what I had expected it to do in 2.2. I’m not sure where that change came along, but I like it!

There were a few times pairing with Jim where I would lose focus and find myself needing to take several steps back to remember what exactly we were wanting to test, but things are feeling pretty natural with BDD/RSpec on Rails. I ran into more issues with objects like template on my own when working on helper and view tests, but I’m getting more of an understanding – the more times I have to figure these things out, the quicker I’ll get at it.

We’re using Pivotal Tracker for this project, which is a pretty cool app for agile project management. Note cards are great, but an app like Pivotal Tracker essentially gives everyone their own copy of the cards online, which seems like a must for teams with remote members, and it’s very well-done.

Also, in a poll taken over lunch today, 100% of respondents* agree that Jimmy John’s is better than Subway.

* Sample set for this poll were selected from actual respondents by using only the very common last names Jones and Smith. This is a surefire statistical method that could never fail 😉

Permalink Leave a Comment

RSpec getting easier on new project

May 26, 2009 at 9:44 pm (Ruby, Week 10) (, , , )

I hopped on a new project today with Jim and Paul (both Erics are also on the project, but weren’t in the office today). It’s a Rails application, and I was making some changes and bug fixes. I ended up having lots of questions for both of the guys as I got acquainted with the application; some of those are going to go away as I learn the codebase. The end of the first iteration is tomorrow, so I’m trying to work quickly to patch up these bugs, but at the same time I’m keeping a high standard of quality. It was a little stressful, but that’s probably mostly because I had a little too much caffeine – nobody’s putting pressure on me to hurry up yet!

It was great taking responsibility for a small piece Rails code (test-driving it, of course) and improving it. As I’ve said before, I generally feel very comfortable working with Rails and HTML/CSS, so I appreciate the chance to give back to the team, even though the other guys are probably still faster on the Rails test-writing.

RSpec isn’t feeling foreign at all anymore. At this point, I think I have a decent intuition for when to mock, when to stub, and the general syntax, but my vocabulary needs much improvement. I spent some time with the RSpec documentation looking for matchers, but I didn’t always know where to look to find what I wanted (especially in view and controller tests). So I’m planning to bone up a bit on objects like response and template (looks like the RSpec wiki on GitHub is a great source of information).

Tonight Software Craftsmanship group meeting was awesome. Doug kicked things off by talking about a bit of the history behind the software craftsmanship manifesto, and his thoughts on gaining consensus and what makes someone an authority. The main takeaway, for me (in addition to the contextual history of the manifesto), was that apprenticeship is the path to finding your personal authority. When you’re an apprentice to someone, you’re making that person an authority in your field of apprenticeship.

Then Jake Scruggs and Jim talked about their experiences during the software craftsmanship swap (which they’ve also both blogged about). It was mostly a question-and-answer session, but both of the guys were really interesting and engaging speakers. I’m excited about the next swap; it seems to me that it’s energized both teams into improvement.

Permalink Leave a Comment

Fitnesse (the extra “e” is for “excellent”)

May 21, 2009 at 8:49 pm (Javascript, Ruby, Week 9) (, , , , )

Today was my introduction to Fitnesse. I’d heard Micah and Doug talking about it, and of course I’ve read about the acceptance testing framework before, but I hadn’t every really looked into the code or used it outside of a few minutes during my interview here. As a high-level testing tool, it reminds me a lot of Cucumber. Both frameworks have a good argument for being the most customer-friendly. Cucumber is written in plain English sentences, whereas Fitnesse has a more complicated syntax to learn. On the other hand, Fitnesse is hosted in a wiki, so the acceptance test author doesn’t need to worry about using Subversion, Git, or any other source control management system. What we call “steps” in Cucumber are “fixtures” in Fitnesse, which may seem a bit strange to people coming from Rails, where fixtures are sample data (also for use in tests). I’ll have to get in deeper to see more changes.

I need to go through Brett Schuchert’s Fitnesse Tutorials to learn which commands are built into RubySlim (the language that runs the backend of our tests) and which were created especially for this project. I was able to get a couple of tests written towards the end of the day (with lots of help from test that were already written, and confirmation from Micah), but I’d have a hard time writing my own from scratch.

Micah and I wrote some AJAX code with JQuery that that ends up doing something similar to what we’d use RJS for in Rails (we’re using Sinatra). It definitely took a little longer than RJS would have, but on the other hand, we were forced to think about exactly how we were interacting between the browser and server. I’d done just a small bit of this before, working on a typing trainer web app for programmers, but this time I felt much more comfortable (my informal functional programming study helped, I think).

I drove Caleb to the train station after work, and we talked about his Tic-Tac-Toe implementation (he’s working on minimax right now). He’s doing his in Java as well, and it sounds like things are going great. My impression is that he’s done a better job of test-driving his work than me, though I’m getting closer to making it a habit. It’s inspiring to be surrounded by a bunch of motivated people who are all working to get better!

Permalink 1 Comment

$0 in Ruby is worth more than you’d think!

May 20, 2009 at 10:51 pm (Ruby, Week 9) (, , , , )

I feel pretty good about my work today; we did a lot of refactoring and cleaning, and I was able to do a couple larger things on my own, which was good for my confidence. I got a better understanding of how the application works in edge cases, and we got some code under test (and made even more code more testable). We also cleaned up a lot of noise in the tests and process runs, moving it to log files rather than STDOUT. I was able to use a lot of code that Micah had just written, so that made my job significantly easier. Micah taught me a neat trick for differentiating between command-line file runs and simple requires in Ruby: $0, which is the name of the file run from the command line. Here’s what I’m talking about:

### file1.rb
if $0 == __FILE__
  puts "running file_1.rb from the command line"
end
### file2.rb
require "file1"

So, if I type this at the command line:
$ ruby file1.rb
I’ll see the output from the puts statement above, but not if I run
$ ruby file2.rb

Now, it might not look like much in the simple example above, but imagine if you have a script you want to run at the command line, but you also want to require it in other files in order to test the methods in the file. So you can eliminate the need to actually run the script during the test, simply by wrapping the actual run line in an if statement like the above. Pretty cool idea.

I was also able to give Jim a couple of tips on using Vlad the Deployer, the deployment love-child of Capistrano and the Rails Machine gem. Great stuff, but it could stand to have more examples in the documentation, so the second time around is much easier.

Permalink 8 Comments

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
"?#{Time.now.to_i}"
end

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

Programming parallels with trumpet playing

May 18, 2009 at 7:41 pm (Ruby, Week 9) (, , , , )

Throughout the day, Micah and I did some ping-pong TDD development in Ruby, getting a good bit of the way through the feature we’re working on. There are still some things to do on this, and I’m going to need to get quicker at changing contexts within the application. It’s not trivial – most Rails apps I’ve worked on have been basically CRUD applications, so this is definitely the most complex (and interesting) project I’ve worked on. The code is very clean, but there were some requirements that increased the complexity a good bit (involving AJAX where we might ordinarily use a simpler 2-way communication method). I’m sure things will get easier as I get more exposure to the project.

With a big project like this, I’m seeing a convincing parallel between my programming life and my trumpet-playing life. As a working trumpet player, I often needed to perform music that seemed too hard for me. In high-pressure situations like these, I just had find a way to make it happen. I would practice and do my best, and in the end I often just had to accept the fact that I couldn’t play it as well as I imagined it could be played by my favorite trumpeters. I feel kind of like that on this project – Micah is of course very comfortable on the project, partly because he’s been on it longer, but mostly because he’s a great programmer. The big plus here is that because we’re pairing most of the time, I don’t have to settle for a subpar performance. The aspects where my junior-ness really shows are the length of time it takes me to figure out how to write the next test or to make it pass, and the number of times I have to ask Micah for explanations and/or confirmation. The end result is still good code, Micah’s making sure of that; it’s just slower going for now.

Just like with trumpet playing, I know things are going to get easier as I get better. How do I make that happen? I’ve improved a lot since I arrived in Libertyville, so my plan is partly to continue on the path I’m on: listening, watching, practicing, and performing (just as I’d do with trumpet). As a trumpet player, there are 2 basic ways I get to the point where I can play a piece beautifully: practicing fundamental skills, and practicing parts of the difficult piece at a slower tempo or lower register. I have the luxury right now of being a little slow, but it needs to be faster. I’m not panicking or pushing myself to go faster than I’m able to do well, but I’m going to start digging into the parts of this project that are difficult for me, in order to get more comfortable, so that I can get faster at thinking through things.

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

Next page »