I’m now hosting my blog here: http://www.matthew-steele.com/

Update your RSS Feeds: http://www.matthew-steele.com/feed/atom.xml

Video:

Diving into the Device API from Matt Steele on Vimeo.

Slides

I found this fascinating, and had to try them out. Here’s what I’ve learned.

Note: for most of these demos, you’ll want to try them out in specific browsers (either Android Firefox or iOS Safari); as of today, browser support is limited. The most up-to-date information on browser implementation is on this page.

All demo code is available on GitHub.

Battery Status

View Demo (works in Android Firefox)

The Battery Status API is straightforward – it adds a new object window.navigator.battery that you can inspect and discover how much juice is left in the device for you to suck out (this is exposed by battery.dischargingTime and is measured in seconds).

battery.charging returns a boolean. You can inspect the charged level using battery.level, but the most interesting parts are the events, which let you capture when a device starts charging, or reaches a threshold over 60%, etc.

The demo captures the chargingchange event and changes some background colors. but you could do lots of things with this data. For example, it might be prudent to turn off 3D CSS transformations at a certain battery threshold, as they’re quite power-hungry. By treating power as a feature test, you can take progressive enhancement to a new level.

Availability

Firefox currently supports this API on desktop and mobile Android. WebKit appears to have implemented it briefly last year, but it’s currently disabled and work to re-enable it appears to have stalled. Similarly, Chromium has a patch built but it doesn’t seem to have ever landed.

Ambient Light Sensor

View Demo (works in Android Firefox)

Most phones have an ambient light sensor – it’s mostly used to dim the screen in low-light environments. The Ambient Light Sensor API works with any sensors that can read light levels, including an embedded camera. There’s lots of environment-specific modifications to a site you could perform with this.

Availability

Firefox on Android has it, and it’s implemented on the desktop in OS X. There’s a patch for Windows 7 that appears to have stalled. I don’t see any evidence that other browsers are planning to implement it.

Device Orientation

A native app that recently captured my attention was the well-advertised Pizza Compass for iOS. It does exactly what you’d expect. I wanted to try a version in pure HTML5. Right now it only points you to a pizza place in my city, but it meets my use case, so why abstract?

View Demo (works in Mobile Safari/iOS Chrome)

There’s a number of device location/orientation sensors in modern cell phones, and it’s not always clear which HTML5 feature to use:

• Accelerometer/Device Tilt: DeviceOrientation
• Latitude/Longitude: Geolocation
• Compass: DeviceOrientation (using the alpha property)

There’s been plenty of apps that use Latitude/Longitude; many use it to assist in a “Store Locator” feature. Google’s also done a few interesting experiments with DeviceOrientation, but I haven’t seen many instances of its use in the wild.

Here Be Dragons

The basic functionality works on current iOS browsers. However, I ran into a number of quirks on other platforms that also support the DeviceOrientation API; which means you can’t build interoperable apps with it.

• Firefox increases the alpha property as the device rotates clockwise. All other tested devices decrease the property when rotating clockwise.
• The alpha property’s initial value is all over the place. Some browsers (iOS Mobile Safari) set it at 0 based on the initial orientation of the device. Other browsers set 0 to a particular orientation, but it’s inconsistent (Android Browser is 0 at west, Firefox is 0 at north, Chrome is ambiguous).
• The event provides an absolute property, assuming the alpha value is calibrated to formal Euler Angles (Firefox and Chrome for Android implement this). There doesn’t seem to be consistency even with this.

Availability

Most mobile browsers support these APIs, with the caveats stated above.

Conclusion

These features are really slick, but they’re hampered by the same issues that hinder the web platform generally: platform fragmentation and buggy implementations. But take the long view, and soon enough you’ll be able to build real-world sites that capture environment input in lots of cool ways.

We’ve gone from writing toy programs in JavaScript to full-blown applications, but our testing skills haven’t caught up. Weirdly, lots of us are coming to JavaScript from other languages that value and encourage testing. What happened?

Turns out, unit testing JavaScript is different than other languages, and doing it well means you have to rethink how you write JS code.

Slides

Slides + Audio

I was coming down from an NES Zelda bender, and I think it shows.

Slides

Slides + Audio:

Video:

Today I’m releasing the code I used to obtain this data: a script called Town Tester.

View town-tester on Github

It’s a Ruby script that queries the Github API to do the following tasks:

• Find users with their Location set to the value you provide
• Clones all “popular” repos (not a dotfiles project, at least 1 watcher, not a fork)
• Checks for the existence of tests (based on a filename that includes “test” or “spec”)
• Creates a .csv with data on each repo, and prints statistics broken down by language

I’m excited for the possibilities of this project:

• Want to showcase how awesome your local community is? Steal developers away from San Francisco by proving your city can test better than their piddling 56% rate.
• Put an end to the Great Semicolon Debates. Whichever developer has more JavaScript repositories with tests wins all syntax arguments by default!
• Gamification is all the rage. Why not track your city’s testing ratio over time, and give XP to developers that increase the ratio the most? Each month, the winner could get free drinks at your local Beer && Code.
• Just in time for the Global Day of Coderetreat, you could lure Corey Haines to your hometown by being the best tested city in the world. I’m pretty sure he doesn’t really want to go to Sydney or Honolulu anyway.

I know I’m just scratching the surface of this venture.

Also, please don’t game the system by adding a “test.txt” file to the root of each of your repositories.

While prepping this talk, I discovered that only 43% of GitHub repositories from Omaha developers have any tests at all. How many were built with TDD is certainly an even smaller fraction.

Slides with Audio

Video + Slides

Slides

JavaScript demo app | Jasmine test suite

The code for the app and the slides are also available on Github.

This weekend I took part in Hack Omaha – the city’s first hackathon with a focus on making apps from public data. We built an app that gameified health inspection data. It was awesome. Nate’s already written up an hour by hour recap of our team’s experience, but I thought I’d share specifics of what I learned.

• Pitch an idea, even if it’s not a winner. Nick Wertzburger started the pitch session off with a joke app (I think) that he tweeted earlier. It was one of only a handful of pitches, and his team ran with it and melded it into an awesome heatmap page; my favorite project of the weekend.
• Sinatra rocks. My day job consists of writing Web Services, with a capital W and S. The process is often heavyweight, cumbersome, and requires numerous approval and manual configuration steps. It was beyond refreshing to just write a get /matchup method, paste in some JSON, and have a working service. Prototyping service design before you’ve even gotten a dataset gives you lots of flexibility to change your design on the fly.

Initial mockups for the app

• Heroku is great, except when it isn’t. We ran the app’s service layer on a shared (read: free) Heroku instance and a shared Postgres database. This was my first experience hosting apps on Heroku, so I relied on Steve’s expertise. Pushing changes was simple as pie, but we ran into numerous issues getting Rake migrations to function correctly. We ended up creating databases on my machine, and using Heroku’s backup/restore feature to load up production. It’s not pretty but it got the job done.
• Designers are worth their weight in gold. With all due respect to Nate’s work, we could have used someone to help with the usability, icon design and overall polish of our app. Most projects were in the same boat. But they were in extremely limited supply here.
• ORM flexibility is helpful. Since you have no idea what tech stack you’ll be working with, you don’t want to require teammates to have a particular database already installed. For example, Steve didn’t have Postgres installed on his MacBook, but we just configured a SQLite instance on his box, set up his ActiveRecord configuration to connect to it and he was off and running.

The team on Friday evening

• Don’t let your VCS hold you back. We decided to use GitHub to host the source, but only half the team had any git experience. Rather than try to learn a crash-course on git, they used a shared Dropbox folder as the repository location.
• Colocation isn’t necessary. We spent most of Saturday working from our individual houses, and we stood up a Google+ Hangout to help. The video chat and screensharing worked really smoothly. We probably had an advantage over the folks who worked at the hackathon venue, as wi-fi was spotty the whole weekend.
• We could have been more ambitious with our tech stack. We were familiar with almost every piece of what we built. Then I look at Omaha Bounty Hunter, which was developed against a five-day old JavaScript framework, and I feel a little sad that we didn’t try something farther out there. At the very least, we could have tried a document database like Mongo, given that nothing we were doing was relational.
• Keep projects small and focused. We were essentially finished with our app by 6pm on Saturday. After that, we spent the rest of the time play testing, tweaking the design, and adding features like analytics, win/loss counting, etc. But having a small, achievable project meant we weren’t scrambling to get basic functionality working at the last minute.

The demo session

• I don’t know Ruby very well. I kept running into syntax issues, like trying to return early out of a block (which isn’t allowed). I also spent a ton of time learning the methods on Enumerable, and figuring out how attributes in ActiveRecord models function. You only have to look at the number of Hash.new and Array.new in the codebase to see that we’re still noobs at this.
• Untested code becomes legacy code, fast. We cranked out the services with nary a unit test in sight. If it didn’t cause a syntax error, we shipped it. By the end, all code was making into Sinatra routes, which meant we had to reload our web app each time we wanted to change a group_by, or see if our ActiveRecord query was right. This slowed us down noticeably, even by day 3 of the project.
• Not all prepwork is fruitful. I tried to learn two new technologies before the hackathon: Neo4J and PostGIS. I thought each might be helpful, and I spent weeks trying to learn just enough to fake knowing it for a weekend. But I ended up using neither. Rather, a 2-hour session with Twitter Bootstrap proved far more useful than anything else I knew.

Much thanks to Steve, Nate and Mike for putting up with me this weekend. And many, many thanks to Matt for setting up the event. I’m ready to do it again.

It also was something I’d wanted to do because last year, my company brought in Robert C. Martin for a two-day course on TDD for me and a dozen other employees. And it was amazing. My colleague Shawn compared it to “getting private guitar lessons from Jimi Hendrix”.

To my delight, this came up as an anecdote in Chapter 6 of his book, “Practice”:

Since then many programmers have adopted a martial arts metaphor for their practice sessions. The name Coding Dojo seems to have stuck. Sometimes a group of programmers will meet and practice together just like martial artists do. At other times, programmers will practice solo, again as martial artists do.

About a year ago I was teaching a group of developers in Omaha. At lunch they invited me to join their Coding Dojo. I watched as twenty developers opened their laptops and, keystroke by keystroke, followed along with the leader who was doing The Bowling Game Kata.

Reading this on the plane, I couldn’t help but smile. Uncle Bob has had a tremendous affect on my development style and coding habits, so I’m glad to hear that I had an influence on him, however small that might be.

Postscript: At the start of the session, we each introduced ourselves and explained what we wanted to get out of the course. Jessica‘s conversation went like this:

Jessica: My name’s Jessica Codr [pronounced “coder”]

Uncle Bob: [pause] That’s the best last name I’ve ever heard. I need to put your name in my next book!

I think this counts.