Reid Burke

  • Best Trumps Easy

    I work at Yahoo!, building open source software. I build Yeti, but I work alongside the team building YUI. The engineers who built this team, and continue to work on this team, are the reason I have chosen to stay at Yahoo! building Yeti: they choose what’s best over what’s easiest.

    You work with people too. You know your people are not perfect, but they’re going somewhere great, which is why you’ve decided to join them.

    I’m going to tell you that building software is very hard, but the most challenging part of my job isn’t building code. It’s building people.

    Your people are not a test framework or a programming language: they are human beings. Like your favorite code, they don’t always meet your expectations. They will let you down.

    People tell stories. What you do next will define the stories they tell.

    You probably rely on these people, so when they fail you, it’s going to affect you. A lot. You probably don’t deserve to be subjected to their actions.

    It’s easy to react.

    I’m telling you, the best people never settle on what’s easy.

    The best people never coddle or spin. They’re honest and speak their mind, but only after giving it 5 minutes. They think instead of react.

    The best people deliver criticism inwardly, one-on-one, to the person who needs it. The attitude is service and respect.

    The best people will embrace the opportunity to be a mentor instead of the opportunity to stand up for what they deserve.

    Next time your people don’t meet your expectations, I encourage you to see an opportunity to invest in people. It will be hard. It may take up a lot of your time and nobody but them will appreciate your investment. Yet serving others this way will reward you.

    You never know when you’ll need it yourself.

    It’ll also reward them. Honest feedback delivered this way is very desirable and mutually beneficial.

    If you want this kind of culture in your team or community, I’d encourage you to be the first one to start. Give more than they deserve, seek to understand what they care about, and after careful consideration, deliver your feedback to them personally.

    It’ll be the start of a conversation you won’t regret.

  • Yeti & YUI

    If you’re a YUI core developer, you should be using Yeti. Here’s how to get started.

    Yeti runs JavaScript tests in any browser. With Yeti, you capture browsers once, then submit tests to those captured browsers during the day. Yeti takes care of running all of your tests in every browser you throw at it.

    Yeti works best with modern browsers.

    Make sure you have a recent Node.js then grab the latest Yeti:

    npm install -g http://latest.yeti.cx

    Daily setup

    Open a new Terminal tab, cd to your YUI source, then start the Yeti server.

    cd path/to/yui3
yeti -s
Yeti Hub started. LAN: http://10.1.1.10:9000
                  Local: http://localhost:9000

    Now you’re set. Navigate your local browsers to the local link and your browsers elsewhere on your LAN to the LAN link.

    It’s important that you run this from the yui3 directory and not inside the src or build directories. That’s because Yeti’s server will only serve files in the current directory, so if you started it inside src your tests wouldn’t be able to load ../build files like the YUI seed.

    Optional: Tunnel out

    Using Localtunnel, you can easily share a Yeti Hub with browsers outside your firewall.

    gem install localtunnel
localtunnel 9000

    Use the URL you get from localtunnel to connect more browsers.

    Run your tests

    This could not be easier.

    cd path/to/yui3/src/your-component
yeti tests/unit/*.html

    You’ll get test feedback right away. Feel free to abort with Ctrl-C and your browsers will reset for the next run automatically.

    Easy coverage

    Would you like to see code coverage, too?

    yeti --query 'filter=coverage' tests/unit/*.html

    Now you have line coverage in your output.

    Use someone else’s Hub on your network

    If someone else already has browsers setup on a Hub, you can easily use their Hub by giving Yeti the Hub’s URL. Here’s an example.

    yeti --hub http://10.1.1.10:9000 tests/unit/*.html

    If you started a Hub, share the LAN link with others on your network and have them use the --hub option with that URL.

    This magic happens using HTTP upgrades, so simple proxies like Localtunnel or some Node.js cloud hosting providers won’t work for Hub sharing because they don’t handle these kinds of connections. Look for services that support WebSockets.

    Run everything

    Every automated test in the project can be submitted. This will take a while.

    cd path/to/yui3
yeti src/**/tests/unit/*.html

    More coming soon

    I’m making this easier every day. If you’re annoyed by something, mention @reid on Twitter or discuss Yeti on the YUI Library forums. You can also file a bug against Yeti.

    Yeti does not behave very well on older browsers. I am currently working on an all-new frontend that will be much more robust with error handling and reconnection. To keep up with what’s new, subscribe to the official Yeti blog where I highlight features and fixes for every Yeti release.

  • Ryan Grove: Why I believe in YUI

    Ryan Grove has posted a follow-up on his YUI from the outside post from last week.

    My blog post on Friday stemmed from my frustration at how it feels to be an outsider wanting to contribute to YUI— frustration that I probably wouldn’t feel so acutely if I hadn’t had the experience of contributing to YUI from the inside. I wanted to be frank, but I also wanted my criticism to be constructive, which is why I suggested solutions instead of just complaining.

    It wasn’t my intent to be discouraging, and I think I probably should have waited a while and written that post from a place of less frustration. I stand by what I wrote, but I regret that it was couched in negative emotions. I owe the YUI team an apology for that.

    Ryan also notes how we’re already addressing his concerns. I’m looking forward to continuing this in the weeks ahead.

  • 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.

  • iPhone UI Anti-Examples

    Check out the screenshots of TripLog/1040, The Athlete’s Calculator, and Handy Randy, new iPhone applications from PalmOS developer Stevens Creek Software. Via Gruber, who points out that this really isn’t a joke.