Jeremy Anderson and I just spent several hours trying to integrate Backbone with a set of XML RESTful services. Backbone comes with built in support for JSON services, but none for XML.
We started by trying to follow this article about using Jath . It seemed promising, but had some holes. Most notable, we were hesitant to make modifications to the core backbone.js. Doing this would have prevented us from easily upgrading to new versions, etc.
The other (slightly) complicating factor was that we were using CoffeeScript and all the code was in JavaScript.
The current release version of Backbone (0.5.3) does not allow for easily adding the options we needed to the ajax request inside sync(). While perusing the Backbone source, we discovered the the current master version on GitHub had some enhancements that made our lives easier. Downloading the master version, we were now able to pass the new parameters in the options hash.
# Keep track of the original sync method so we can# delegate to it at the end of our new sync.originalSync = Backbone.sync
# Our new overriding sync with dataType and ContentType# that override the default JSON configurations.Backbone.sync = (method, model, options) ->
options = _.extend(options, dataType: 'xml' contentType: 'application/xml' processData: false )
originalSync.apply(Backbone, [ method, model, options ])
Be sure not to override the incoming options with a new hash. You must simply append (extend) to the incoming options.
The last step is to get the incoming XML converted to JSON so the rest of Backbone can understand it. Below is an example using Jath as described in the above link.
class OE.Offer extends Backbone.Model
class OE.Offers extends Backbone.Collection model: OE.Offer url: 'http://localhost:7000/offer/opportunities/merchant/123'
parse: (response) -> template = ["//offer", { id: 'id', name: 'name', code: 'code' }] Jath.parse(template, response)My first barefoot run was at the Recreation Center in Saline, Michigan (just south of Ann Arbor) back in January 2010. Since then, I’ve run there many times as well as run a 5K and a 10K. For most of the summer I ran outside, but as it began cooling off, I went back to the Rec Center treadmills.
Today was the first negative reaction I’ve had to my barefoot running.
As I approached the treadmill in my flip-flops, a few people glanced my way as they usually do when seeing something unusual. One woman in particular gave me a bit of a surprised look. She had a baseball cap on, so I’ll call her Cappy. I kicked off my flip-flops and hopped up on the treadmill next to Cappy. No sooner had I started the machine than she hopped off, leaving all her stuff behind and disappeared around the corner.
A few minutes later, she returned and began running again. A couple minutes after that, a Rec Center staff member came over:
Staff: “Do you have anything else to put on your feet”?
Me: “No.” (I wasn’t going to run in flip-flops).
At this point, Cappy took out her headphones to (presumably) listen in.
Staff: “Our rules say you have to wear shoes”.
Me: “I’ve been running here for almost a year without shoes.”
Staff: “It’s for health reasons.”
Me: “My feet are cleaner than most people’s shoes.”
Me: “I don’t think there are any Michigan Health Regulations against being barefoot.” (not sure if this is true, but I think I heard it somewhere).
Staff: “Ok, go ahead and keep running. I’ll go talk to someone.”
Me: (thinking) Damn, now I have to keep running. 
I finished my run and after I got off and wiped down the machine (which most people wearing shoes don’t do. ewwww!), the staff member approached and showed me the rule book. I said that I’m pretty sure they’re not allowed to have that rule since it’s a publicly funded center (again, not sure). She offered to have the Director call me about it, which I agreed to. She also conceded that it was not a health problem, just a rule.
I also suggested that if they wanted to keep that rule, perhaps they should add the following rule as well: If you workout with shoes on, you may not put your sweaty feet on the locker room floor without appropriate footwear. She appreciated the logic, and was very polite through the whole encounter. Kudos!
Sooo…. I have a couple questions:
- Is the “must wear shoes” rule legal, particularly since this is a publicly funded center?
- Is there anything in the Michigan Health Code
It would be great to have answers before I talk to the director.
Thanks!
Yesterday, I picked up the “box set” of Kent Beck‘s Test Driven Development screencast series. For $25, you get about 1.5 hours of “over the shoulder” perspective from one of the masters. I figured that even if it was horrible (unlikely), it was an opportunity I couldn’t pass up.
Here then, are some observations I had after watching the first screencast:
I was immediately surprised to see Kent’s Eclipse setup. He uses a non-monospaced font in the java editor, which I had not seen before. It seems a little easier on the eyes than the monospaced”Menlo” that I use in my editor. After watching, I played around with some new fonts, but couldn’t find one that looked good. I should probably find out which one he uses.
Kent also keeps his JUnit view minimized, and simply monitors it’s progress by the red/green color of the icon. I’m used to keeping the view open so I can see the errors that show up. Maybe that’s a smell that I’m having too much red during my TDD.
I was interested to see that Kent described TDD as having the following 3 steps:
- Developers write automated tests as they go
- Tests are written in advance of the code
- Design a little at a time
I’ve always described the TDD steps as Red/Green/Refactor and I found his description to be a little harder to think of as “steps of the process”. During the screencast, he also didn’t emphasize things like “now let’s write a failing test”, “let’s get it to pass”, etc. It was much more casual. Perhaps this style makes it more accessible to newcomers.
The first test that Kent wrote was actually what I consider an “Integration Test”, as it hit a network resource. It sounds like he’s going to address this in “part 2″, and I suppose it wouldn’t make much sense to immediately introduce mocks when trying to explain the basics.
Kent appears to use something like the “TDD like you meant it” approach, which I’ve also begun to favor recently.
Overall, it was really nice seeing how fluid and natural his style of development was and I’m looking forward to picking up some more tips from the next episode (in a few minutes).
On the XP list over the past few days, a cute little poem has emerged, first written by Tim Ottinger and enhanced by Tom Rossen:
Software that’s coded by monkeys
Is redundant and smells rather funky.
It’s cluttered, and fragile,
Nowhere near agile,
But it’s dope to a waterfall junkie.
I like it.
Fitting these pairing sessions into my schedule has been a bit trickier than I expected. A lot of recent difficulty has occurred due to people’s summer vacation schedules. Now that school is about to begin, I hope the frequency improves.
After some timetable negotiation, I was excited for the opportunity to spend a day at Healthmedia (a company providing Healthcare-related services) in Ann Arbor, by invitation of Helene Gidley, Matt Long, and Brad Neighbors.
Upon arriving, I sat with Matt for a bit and he gave me an overview of the application his team was currently working on, showed me their story tracking system, and generally oriented me.
Shortly thereafter, many people arrived in the team area and conducted their standup, after which most of those people left. I found this a bit odd, but it’s hard to make any sort of judgements with such a small dataset.
My first pairing session was with with Shilpa Nalgonda. We worked on some java code dealing with surveys and worked through discussing and then writing an outer level Acceptance-style test to drive our inner loop of TDD. We discussed test method naming and mocks. The team was using EasyMock, which I’ve never used due to my dislike of the record/replay syntax. I prefer using Mockito, as I think it a more natural DSL.
I also got into a discussion with Lyudmilla Mishra and a couple other folks regarding their move over to start using a dependency manager (Ivy) for their builds. It was interesting to hear about some of the issues they had to consider from a healthcare/HIPPA perspective. I shared my experiences with Ivy and Maven (Maven, FTW!).
Brad, Helene & I went across the street to Grizzly Peak for some lunch, which was great as usual.
After lunch, it was more pairing with Shilpa, joined by Brad for a bit of tripling as well. Brad shared some of his experience using the Builder pattern for creating test objects. I had combined Fluent API and Builder in my mind, but Brad reminded me that they were actually different things for different purposes.
During this pairing we experienced the pain of the current dependency management setup firsthand, having to wait 5 minutes between changing a domain class and being able to use the changes in the service layer. Hopefully, this will get solved with the Ivy implementation.
We finished off the day with some informal retrospecting between myself, Brad, Lyuda, and Matt. I provided them with my observations of the day and a few suggestions (visible task boards, introduce WIP limit, develop end-to-end rather than in architectural layers). All in all, a great bunch of people who I’m sure I’ll be seeing around the Ann Arbor Area.
Yesterday, as part of the 2010 Michigan Pairing Tour, I had the opportunity to spend a day at the new offices of BillHighway in Troy, MI. They have a very nice setup including an area with leather couches, a large screen TV and XBox + Wii consoles.
BillHighway “bills” themselves as a “Quickbooks for Communities”. One of my longtime friends works there, and I’ve had the privilege of getting to know their CIO over their past few years of impressive growth.
BillHighway is primarily a VB.NET shop. I’ve never spent more than 5 minutes looking at .NET code, and the last time I used VB was about 12 years ago. It promised to be an eye-opening experience.
In the morning I paired with André LaMonde, a VB.NET hacker. We were working on standardizing some of the UI components to be in line with a new Look & Feel for their site. I was briefly thrown for a loop by the unfamiliarity of Visual Studio and strange syntax, but quickly recovered and was able to follow what was going on without too much trouble.
Unit testing is not regularly practiced by the team, so we had some good discussions about some of the challenges that dealing with legacy code bases brings about, and some strategies for integrating tests going forward. We struggled with NUnit for about 15 minutes, then bailed out and were able to get some tests up and running with the framework built into VS 2008.
In the afternoon, I paired with Meghan Letscher. She was very quick and was whizzing around Visual Studio like a pro. We worked on a similar task as in the morning, and delved into a bit of JavaScript & CSS to round things out. After struggling with some DLL permission problems and having fun with caspol.exe for a while, we were able to get some tests running and even managed to do a bit of TDD.
Overall, I had a great time, and picked up some 3l1t3 .NET skillz. I’m looking forward to the next stop!
Last Friday was the first stop on the 2010 Michigan Pairing Tour.
I sat down with Ilya Sterin at a Caribou Coffee in Grosse Pointe, Michigan and we started off by discussing a few of the projects he was currently working on.
We decided to write some tests around code that he had written to post Facebook status updates. This led use Mocks for the Facebook API, and refactor some of the code to be more testable.
During this refactoring, Ilya brought up the question of whether we should favor writing testable code at the possible expense of simplicity. I think that writing testable code generally results in simpler code (not gold plating, etc, etc), but I replied that it’s only important to write testable code if you care if it works.
After lunch at a nearby Sushi bar we tackled a different project that had a lot of concurrency going on. Ilya has a lot of experience with java threading and he has an excellent handle on how it all hangs together. I learned quite a bit from him in this segment, include exposure to the Guice DI framework.
We were able to bring a couple consumer/producer classes under test. This again required some refactoring–mostly along SRP lines–and resulted in a simpler and cleaner design.
Overall, it was a great experience, and exactly what I hoped to get out of the pairing tour. I’m looking forward to my February date which is tentatively scheduled for next 2/12/2010. I’ll post more details when it’s confirmed.
On Friday, 1/29, I’ll be making my first stop of the 2010 Michigan Pairing Tour in Grosse Pointe, Michigan. The plan is to pair with Ilya Sterin on what he describes as writing tests for:
a highly concurrent producer/consumer implementation for data messaging through numerous sources
Aaahh, legacy code testing and refactoring. One of my favorite pastimes I love it!
The Tour Calendar is now available for anyone interested.
The February and March dates are *almost* confirmed, so i’ll be announcing those shortly.
Inspired by Corey Haines‘ Journeyman Tours, I’m kicking off the 2010 Michigan Pairing Tour.
To start with, I’ll be spending 1 day per month pairing with individuals anywhere within about a 2 hour driving distance from Ann Arbor. (Yes, I realize this puts the top of Ohio in play as well. If you’re nice, maybe I’ll cross the border for you )
I’ll pair in any language, on any project. We can write code, write stories, write acceptance tests, you name it.
Goals
What am I trying to accomplish?
- Enhance my own skills from hands on experience with other practitioners.
- (Hopefully) enhance my partner’s skills.
- Meet more like-minded folks throughout Michigan.
- Inspire others who don’t have the availability for a full Corey-style tour to go out and grow themselves and the community.
Logistics
If you’d like to be on my tour, please contact me via email or twitter. If you need to get permission from your boss, I’m happy to talk to him/her or sign any corporate NDA’s that are required.
My current plan is to do this on Fridays, but I’m pretty flexible, so let me know what works for you.
I’ll put up a Google Calendar shortly with all the booked dates. (Update: Google Calendar is posted)
Thanks for your interest, and I hope to see you on my journey!
I upgraded my 17″ MB Pro last night to Snow Leopard. The installation went smoothly, and took about 45 minutes. the Mac rebooted a couple times on it’s own and then I was done.
This morning, as I started using the new OS, I experienced the following issues:
- Dev tools not installed – easily solved by installing the XCode package off the DVD
- QuickSilver not working — solved by upgrading to SL version, and removing
- ~/Library/Application Support/Quicksilver and
- ~/Library/Preferences/com.blacktree.Quicksilver.plist
- MacRuby seems to be broken — seems like 0.5 is needed.
- Quicken 2007 needs Rosetta — quite a nice implementation, as SL automatically downloaded Rosetta and installed it.
- Electric Sheep 2.7b16 does not work — waiting for devs to update
- iStat not working — waiting for devs to update
- Xmarks not working — waiting for devs to update
- Growl has strange behavior — upgrade to v1.2b fixes it http://code.google.com/p/growl/downloads/list — final release should be available soon.
- Nambu not working — switching (permanently?) to Tweetie or TweetDeck
- Weird font problem in Firefox — some sites indicate a problem with 3rd party font managers, but i have none. No solution yet.
Nothing critical (for me), but hopefully these will get worked out soon.
UPDATE (2010/01/20) – All issues have been resolved!
