Reid Burke

Web Development

  • Write Code That Works

    Dav Glass and I visited the Yammer office in San Francisco this week to discuss build & test tools we use at YUI.

    We showed off Shifter for building YUI, Grover for testing headlessly, Yeti for testing in browsers, and Istanbul for statement-level code coverage. We use Travis for running most of this stuff in public CI. We now require 70% statement coverage before a new YUI module is allowed to land in the core and nobody can commit when the Travis or internal CI build is broken, unless the commit fixes the build.

    This is all very impressive. But @mde was quick to notice that we didn’t drop everything to get to this point—before diving in, you first need to prioritize what you work on. I couldn’t agree more.

    When you’re starting from scratch, you start to love the metrics. Green dots for passing builds. Green coverage reports when you hit 80% of your statements. The increasing number of passing tests. I’m all for having good code coverage, but before you go crazy, you should be careful that you don’t start writing tests for the wrong part of your code.

    Your code is not uniform

    Your code has various levels of quality starting at the first commit you make. You will write some code that’ll last for weeks or months, and some code that’ll need a rewrite next week. You need to embrace this kind of change and understand where it happens in your project.

    Node.js solves this problem quite well with the notion of a Stability Index.

    Throughout the documentation, you will see indications of a section’s stability. The Node.js API is still somewhat changing, and as it matures, certain parts are more reliable than others. Some are so proven, and so relied upon, that they are unlikely to ever change at all. Others are brand new and experimental, or known to be hazardous and in the process of being redesigned. The Stability Index ranges from Deprecated (0) and Experimental (1) for unstable code to Locked (5) for code that only changes for the most serious bugs.

    It’s a good idea for any post-1.0 project to assign a Stability Index to the APIs in your own code. Not only is it a clear message to those using your APIs, but it’s also a clear message for your team. It tells you where you should—and shouldn’t—write tests.

    More stable, more tests

    If you write tests like they cost nothing, you’re going to find yourself writing tests instead of writing code that works.

    Kent Beck’s wisdom says it best:

    I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. This answer is good and I’ll take it a step further: You should prioritize writing tests for parts of your code with a higher Stability Index. Especially if you’re just starting on a new project.

    If you’re writing tests for code that’s rapidly changing, you’re going to spend more of your time writing tests instead of shipping features. For code that’s brand new, I typically only test-first a small amount of code and wait a while before hitting that green bar on a code coverage report.

    Don’t get sucked into the allure of metrics too early. Remember what your job is: writing code that works. Code coverage and good testing tools are very important, but not if they get in the way of building what you’re supposed to build.

  • When PHP Actually Is Your First Programming Language

    I have read a few articles about how PHP is a perfectly good first language and how it should never be a first. These articles are interesting because my first programming language was PHP† and I have been using it extensively since 2004.

    One thing is true: it’s really easy to get started with PHP. My first real job was creating a system to log phone call metadata from a PBX. I was able to get a working version up quickly because 90% of it was in PHP. There’s a function for nearly everything, and if there isn’t, you’ll find sample code online quickly. I had the project done in a month with very little prior experience. However, because it was so easy, it was horrible. Procedural, PHP inline with HTML, calls directly to mysql library functions, really bad logic.

    When I was brought on to develop on their flagship web application, my coding practices improved from exposure to a better codebase. The biggest improvement was when I started working with PHP code developed by a new coworker that I would later learn was heavily influenced by Java. I went from looking at objects as namespaces to a representation of something. I learned to separate logic from presentation. I started to think about code more logically. I was baffled at problems caused by PHP’s lax nature (such as when (0 == 'hey') is true). However, I had knowledgeable coworkers to explain these problems when the language wouldn’t.

    The best thing about PHP is that it takes away the need to manage “stuff” and let’s you get started right away. For me, I was able to more quickly grasp object oriented programming because PHP was more forgiving. This later helped me embrace objects in JavaScript, understand polymorphism, and become a better web developer.

    That’s also why it’s so awful. If it weren’t for my exposure to good PHP code influenced by proper programming practices, I would have remained a contributor to the vast amount of bad PHP code out there. The unfortunate problem is that most new developers who use PHP stay in that place, because their stuff works. For most jobs, that will suffice. It’s only when they move to other languages that the frustration begins.

    Making PHP my first language made it harder to grasp pointers, strong types, and memory management in other languages. It initially made it more difficult to use OOP properly. However, if I didn’t make PHP my first language, I may have been so intimidated by the “stuff” that I may have given up.

    Whatever you choose to learn as your first language, the key is to learn from great code. You will make mistakes and your language, framework, or mentor should be there to guide you. If you don’t, you’re only going to become frustrated and confused later.

    Update: There’s a good discussion about this article on Hacker News.

    † My first languages were actually Applesoft BASIC followed by VB6, but nothing serious came out of my experimentations with them except for a brief stint working on ignitionServer.

  • YUI: ScrollTabView Makes Tabbed Views Even Better

    I’ve recently been tinkering with the excellent Yahoo! UI Library. My first contribution to the community is ScrollTabView, an extension of TabView that uses a scrolling animation to switch between tabs. (Just check out the examples.)

    My inspiration was Panic’s Coda site as well as a few others. Now it’s easy to create a similar effect on your site using YUI.

    Check out my new YUI addons page to grab the code and view more examples!

    Update: I’ve been featured on the official YUI Blog!

    Update 2 (May 27): I’ve been featured on Ajaxian!

  • MySpace Hacking: Hiding Code From IE

    Note This no longer works. I use their Profile 2.0 now anyway.

    Today I noticed that my MySpace profile looked awful in Internet Explorer. I recently changed some stuff in my profile but didn’t touch my custom CSS. However, after looking through the code, I discovered the problem: MySpace is now scrubbing out “<!” from my profile.

    This is bad, because I make use of Internet Explorer’s conditional comments to hide some CSS from the browser. Basically, I was using this:

    <![if !IE]>
    <style>
    .yourStylesHere { font-weight: bold; }
    </style>
    <![endif]>

    Now, the “<!” bit is replaced with “..“, making the conditional statement worthless and exposing IE to what it shouldn’t be seeing.

    After some research, I found that the IE-only tag <comment> works just as well as the conditional comment I used before. By simply replacing the conditional tags with the <comment> tag, everything worked great in Internet Explorer (even IE 7).

    Now I have:

    <comment>
    <style>
    .yourStylesHere { font-weight: bold; }
    </style>
    </comment>

    This works great. I hope this helps someone!

  • MySpace Profile Facelift

    MySpace RedesignAbout a month ago, I followed the excellent guide to style a MySpace profile over at Mike Industries. He detailed many details about the challenges he faced in his blog that I shared when doing my own (still awful) modifications when I first signed up for a MySpace. I never thought I would be able to have my profile look as appealing as his styled goodness, however, he was nice enough to include some sample CSS for all to enjoy. Finally, I can seperate myself from the thousands of awful profiles that litter MySpace. Yay for Mike!

    I took his code and with some changes and my own graphics I finally have a MySpace profile worth looking at (see screenshot at right). I’m very happy with it: it’s about as good as it could look without overlaying the whole page or commenting out chunks of HTML. Check it out, and have a look at Mike’s guide to make your own.