Introducing YUI Benchmark

YUI Benchmark is a new toolkit for JavaScript performance testing. Despite “YUI” being in the name, it can be used for any type of JavaScript application, including vanilla JS, YUI, Dojo, jQuery, Node.js, and anything else you can think of. The project was something I was working on at Yahoo to help with YUI’s CI performance testing needs, and since its quiet open-sourcing a few weeks ago, I’ve had some time to clean it up, fix bugs, and introduce some new functionality.

Before we get into what it is, let’s first look at why it is useful.

Prelude

I believe the current state of JavaScript performance testing is a little inadequate. While there are certainly some developers who use tools like JSLitmus, Benchmark.js, or manual profiling to gather performance metrics, most don’t actively test performance of their code. Instead, most developers write performant code to the best of their ability and call it a day. I don’t think this is due to lack of interest in the idea. Rather, I just think it is due to a lack of flexible and easy-to-use tools. For instance, JSPerf.com is awesome at what it does, but due to it being web-only, its usefulness is a bit limited. What about developers who want the ease of JSPerf, but want something command-line driven? Perhaps in a CI environment? Benchmark.js is handy, but it requires lots of boiler-plate for browser-testing as well as a custom test runner for integration into CI. Shouldn’t this be easier?

We went through this before. If you look back 5+ years, few JavaScript developers were unit testing their JavaScript code. Even some of the popular JS libraries weren’t shipping fully tested code. We first started with JsUnit, then came YUI Test, QUnit, Jasmine, Mocha, Vows, and a variety of others. As the number of available tools grew, so did our acceptance of the idea that our code needed to be rock-solid stable. Now, often times the only way to deploy code is through continuous integration systems (such as Jenkins, Travis CI) that run your code through a gauntlet of unit tests. Heck, a few weeks ago I was talking to a fellow developer and he said “Know when code can be considered ‘legacy’? When it isn’t unit tested.”

Our priorities, expectations, and workflows have changed since 2008. So with JavaScript unit testing now a mostly solved problem, I think we can now turn our attention to the problem of performance testing. If this field is of interest to you, here’s a tool that can probably help you out.

What is YUI Benchmark?

Think of YUI Benchmark as the glue that combines Node.js, Benchmark.js, Phantom.js, Yeti, and was designed around the workflow of YUI developers and CI testing environments. To dive in a bit more, it is a Node.js application that utilizes Benchmark.js to measure performance of a given function in various environments, including Node.js and web browsers.

Here’s a quick demo executing this simple test.

// vanilla.js - A test suite to compare array creation
var suite = new PerfSuite({
    name: 'Simple test',
    tests: [
        {
            name: 'new Array()',
            fn: function () {
                var arr = new Array();
            }
        },
        {
            name: '[]',
            fn: function () {
                var arr = [];
            }
        }
    ]
});

YUI Benchmark demo

The idea is that you provide simple performance tests (examples), which contain only the code you want to test performance for, and you get to forget all the boiler-plate code. YUI Benchmark will read your test file, then compile it to either a .html file (for browser testing) or a .js file (for Node.js testing), execute it in the environment(s) of your choice, then dump the human readable results to the command-line or a raw JSON file. Flexible, and simple.

Bonus features include the ability to test in multiple browsers at the same time (thanks Yeti!), as well as multi-version testing for development on the YUI project. In addition to built-in support for YUI, it also offers the ability to test jQuery and Dojo as well. Here’s an example of that.

So that’s the quick intro. I could go into more details here, but it would be duplicating much of the details and demos that can be currently found in the README. So go check that out for more information on the project and details on how to get started. (Hint: npm install -g yui-benchmark)

Roadmap?

YUI Benchmark is still a young project and has only been used in YUI’s CI system as well as a few select developers. While the feedback so far has been great, there’s probably still some rough edges to iron out. So aside from improving stability and usability, I’d love to eventually add some features to the project so it can realize it’s full potential. Here’s a few ideas…

  • Generalize multi-version testing for all projects, not just YUI. Multi-version support is valuable in performance testing because duplicating testing conditions for comparative analysis when results are gathered sometimes months apart, is not ideal. It’s often times far easier to execute tests against select versions of your code in the same test run and compare your results.

  • Machine state intelligence. I believe this is the most exciting aspect of an application like this. With the possibility of YUI Benchmark code executing in the client and server while your performance tests are executing, insight can be gathered about the state of your machine and factored into test results. Did your CPU max during testing? Are you swapping memory? Are your objects leaking? Any of these problems could be detected to inform the user that the results are less than ideal.

  • Phantom.js cluster support. Currently tests are run serially, one after another, after another, after another. If your project is like YUI, you can have dozens of tests suites containing hundreds of test cases, and at approx 6 seconds per test, this pretty quickly fails to scale. One solution could be to farm out the test files to phantom.js clusters on low-powered VMs so the tests could be run synchronously. Important to note that while performance testing on low-powered VMs seems counter-intuitive, it’s important to realize that this type of testing is comparative, not discrete. The key metric you are looking for is not how many operations per second your code ran, instead, it is how much faster it ran than your other result. Also, I’d target “low-powered VMs” because that is commonly what you get in CI environments.

  • Introduce threshold support to trigger regression/failure in CI. Currently multi-version results require manual analysis to determine if your code is regressing. It isn’t possible to always trigger a failure if your test is running slower due to the fact that swings of +/- 5% are not uncommon. My suspicion is this will require the introduction of a threshold to accommodate highly variable tests. In the future, more intelligence can be used to compare against historical deltas and automate the process of determining the regression threshold value.

  • More intelligent analysis of gathered statistics. Any performance testing toolkit should provide accurate and detailed statistics so the developer can make the most informed decision for appropriate fixes. Currently, YUI Benchmark simply relays the statistics Benchmark.js calculates, but greater analysis can be done with multiple --iterations to expunge outliers and re-execute the suite.

  • And more!

Thanks for reading this, and I look forward to your feedback and contributions!

On Leaving Yahoo

A week ago I walked out of Building E for the last time. There are a lot of emotions as I reflect back on everything that has happened over the last 4 years since I joined, the jubilant successes, the lesson-learning failures, and everything in between. I have to think that in the end, it will likely go down as one of the more fun and rewarding periods of my life.

Some highlights…

  • Attending, speaking, and mentoring hackers at 27 conferences. The YDN crew is world-class, and despite all the free food and nice benefits, working with them is one of the best perks of being an engineer at Yahoo. At least I think so. Special thanks to Anil, Havi, and Stacy for all their support at Hackdays, and helping organize SoCal meetups.
  • I feel fortunate to have been around for the beginning stages of what everyone hopes will be Yahoo’s “big turnaround”. We probably won’t know for another 2 or 3 years if it will ultimately succeed, but the changes made in the first 18 months have been exciting to witness. While I don’t envision myself taking over a struggling Fortune 500 company anytime soon, learning some lessons for what it takes to turn that ship around been invaluable. Communicate, set goals, accomplish, repeat. Simple, right? We’ll find out.
  • I also feel fortunate to have had the unique opportunity to work on a project that reaches, what… 1/7th of the Earth’s population in a given month? Kinda mindblowing when you think about it. And to top it off, you get to do it while working with a really talented and passionate group of people.
  • It was especially great being able to see the insides of how to effectively manage a large open-source project. Since YUI is on a never-ending quest to open up as much as possible, looking back on where it was in 2009 compared to now is pretty remarkable. Some of that praise should of course be given to Github, for producing such an amazing product for open-source organizations and letting developers focus on developing. The entire culture around open-source has evolved greatly in the last few years, and I think YUI has responded remarkably well.
  • Hacks! Especially ones with YQL. Between things like the YQL Executor, Secure OAuth in JavaScript, hacking YUI inside of YQL, SoCal Hackdays, Hacker Movie Nights, late-night scripting competitions with Dan Beam, and my projects from internal Hackdays, Yahoo absolutely cultivates the hacker mentality. I couldn’t tell you if Paul Graham was right about Yahoo’s dead hacker culture in 1998, but it certainly doesn’t apply in 2013. Let a thousand hacks bloom! (as one of my hack-discuss memos once said)
  • The Purple Kitten Tracker. One of these days, purple kittens will make an appearance in URLs, and it will be glorious.
  • Y! Sports Karaoke. I’ll just leave this here.
  • But most of all, the biggest highlight was simply setting a career goal, accomplishing it, then again.

To conclude…

It was a pleasure to work with so many smart and passionate people, which was the entire reason why I joined Yahoo. If you are the smartest person in the room and not the CEO, go find a smarter room. If you are working for a company that doesn’t believe in you, it’s time for a change. Ultimately, your career is about you, and the best way to succeed is to have the support of a company that can help you reach your goals. Yahoo gave me an immense amount of support over the years, and I’ll always be grateful. So thanks to my managers Michael, Dan, Thomas, and Jenny.

What’s Next?

Believe it or not, in my four years at Yahoo I only took one vacation. So, I’m going to spend a few months off, Hawaii next week, travel more after that, hack on new projects, contribute to open-source, and eventually find my next adventure! If you are interested in speaking to me about opportunities, you can connect with me on LinkedIn, and find any other relevant links at derek.io.

Well Yahoo… So long, and thanks for all the fish!

Creating an API Service with YQL

I spent a few days last week in New York City at Yahoo’s Open Hack All-stars event. At this hack day, I was mentoring a team of 3 students from the University of Texas who set out to create a hack that allows you to control a media experience on your TV by using your iPad.

For this hack, they needed to talk to search APIs from 4 different services (Youtube, Justin.tv, Flickr, Netflix), parse the results, and display a thumbnail for each item with a link to play/view it. Traditionally, this would be a rather bulky iPad application where you’d have to include all the code and logic to communicate with the various JSON, XML, & ATOM service APIs, parse the results, combine them, and finally render the content. Likely, the HTTP calls would be synchronous, which would certainly present some issues as you get to 5+ APIs and you have to wait for one response to return before making the next.

Alternatively, you could create an API service that will do all of this for you. When that option was presented, I immediately realized YQL would be perfect for this task. Why?

  • It can communicate with any HTTP-based APIs, asyncronously, so your response time is always as fast as the slowest API you have to talk to
  • Use custom JavaScript to parse the results and form the return set
  • Reduces the number of requests your client makes to a single HTTP request

So, I strapped on the headphones and began coding. A few hours later, here’s the result. It’s YQL datatable that heavily uses the <execute> feature, which allows you to run arbitrary JavaScript. Within <execute>, you get a simple library that allows you to do things like parse JSON, make HTTP calls, and create XML structures with E4X. The datatable code is pretty straight-forward really. Here’s the service to talk to, the URLs to send the search query to, and the callback to parse each result set. Now go!

The beauty of this YQL datatable is that you have now created a fully-functional high-performance API server without the need for a server of your own to run it on.

Here’s a JSFiddle of the script in action. Click the play button to see the combined search results.

You can also toy around with the query in the YQL console here.

If you are interested in learning more fun stuff you can do with YQL, here’s another post, How-to: Secure OAuth in JavaScript

Learning JavaScript

So you want to learn JavaScript huh? I can’t blame you, it’s a pretty rad programming language. Well lucky for you, it’s a really easy language to pick up and learn. You can get started with the language without spending a penny on a compiler, an IDE, or any instructional material. Heck, you already have a computer capable of running JavaScript. I know that because every modern web browser has one, and that’s how you are viewing this blog post.

I’m approaching this post as an introduction to JavaScript for someone who is already a programmer (novice or advanced, doesn’t matter). An introduction to programming would be an entirely different post.

Without further adieu…

Tip #1: Start by Reading the Wikipedia Entry

Yeah, we’re really swinging for the fences now, this is a tough one. You’ll find that entry here. Read it, thoroughly. It’s really helpful to get some background information on the language, the history, and various implementations of it. It’s helpful to understand that JavaScript is a standardized language, with many “engines” available to execute your code. There’s no single company behind the language. Also, forget that JavaScript has anything to do with Java. It doesn’t. It was just a horrible name for a language that wasn’t supposed to be very useful. Well, it turns out it was, and we all accept that it’s a horrible name and have moved on. C’est la vie.

Tip #2: Learn it Outside of a Browser!!!

I’m going to assume you have some experience with another programming language. Odds are likely it is PHP, Ruby, or Python. Those are all scripting languages, which means it isn’t compiled prior to runtime, instead it is read by an interpreter and executed on the fly. Well, JavaScript works the same way, there’s no compilation step you have to do prior to running a program. So, download Node.js and start writing some basic scripts. At this moment, Node.js only runs on OSX and Linux, so if you are running Windows, then ok… You can either visit jsbin.com or use the JavaScript console that comes built in to Chrome. Windows support for Node.js is coming soon though (late-summer 2011).

The reason I say learn it outside of a web browser is because you should approach JavaScript just like you would any other programming language. Only focus on its standard library to start. If you start toying with it in a web browser, you all of a sudden have access to the DOM and the BOM APIs, and then you’ll be distracted by learning HTML, CSS, which will likely be frustrating and lead you to a library like jQuery or YUI. Just don’t do it. Once you get comfortable with the syntax, scoping, and prototypal nature of the language, then proceed to use it inside of a web application.

Tip #3: Read Some Books

I highly recommend Eloquent JavaScript to start, because it’s a great book, and it’s free! After that, check out a few other of my favorites; The Good Parts, High Performance JavaScript, and Pro JavaScript Techniques. You can buy them all used off of Amazon for under $15 each.

Tip #4: Watch some videos

The YUI Theater is an excellent resource for anything front-end related. Some of it is focused on YUI, but there are quite a few videos that are just about JavaScript in general. The Crockford on JavaScript lecture series is amazing. Must watch!

Another video I came across recently was Alex Russell’s talk at Google.io 2011, “Learning to Love JavaScript“. It is probably the best introduction presentation to the language I’ve seen.

Tip #5: Get Involved in the Community

JavaScript meetup groups are popping up in every major city around the world, and there are many major JS-related conferences/events every year. Go to Meetup.com and search for “JavaScript” in your area. Attend a meetup, meet some fellow nerds, and ask them about their learning experiences with JavaScript. Don’t see one in your area? Create one! I did, twice.

If you really get into it, attend JSConf.us or JSConf.eu. They are the best JS-related conferences out there.

If you are anti-social and don’t want to get out and meet people, don’t worry, there’s a large community on-line as well. You can find us in #javascript on Freenode IRC. I usually hang out there (user: dgathright), as well as #yui, #jquery, #node.js, #html5, and many others. If you see me on there, ping me and let me know you saw this post and I’ll give you an internet high-five. Also, join the JSMentors mailing list. Its whole purpose is to help newbies like you learn the language we love.

Tip #6: Ignore W3Schools!

There is a plethora of ancient JavaScript tip sites that haven’t been updated in 10+ years. They often contain horrible, and sometimes incorrect, examples of JavaScript code. Instead, visit the Mozilla Developer Network’s JavaScript documentation. W3Schools is so bad, it even spurred W3Fools.com.

Tip #7: Be Curious

There are more discussions about JavaScript and code posted per day than time you have to actually read it. That means there is an unlimited supply of information out there about the language, seek it out.

Well, those are the tips that immediately come to mind. There’s quite a few more ideas, blog posts, tools, resources, services, etc… that I’d love to recommend, but you have more than enough to get started. Now go get coding!

The Best Career Advice You’ll Ever Get

The Huffington Post just posted an interview with Marissa Mayer (“Google Exec Marissa Mayer Explains Why There Aren’t More Girl Geeks”) in which she explained why she chose Google over 13 other companies she had job offers from out of college.

“Work with the smartest people you can find, do something you’re not ready to do, find an environment in which you’re very comfortable so you can find your voice, and work for someone who believes in you — because when they believe in you, they’ll invest in you.”

I couldn’t agree more. For some people, that’s Google or Facebook. For others, that is a startup. For me, that encompasses every reason why I’m at Yahoo.

Splitt

Growing up in Kansas City, I spent quite a few summer afternoons at Royals games. My grandparents had season tickets, front row, just next to the home dugout. Amazing seats. It pretty much felt like you were on the field. As much as I love some of my other teams, there’s a certain connection you have with your baseball team. I suspect that is largely due to the fact that they play just about every night, 162 games per season. If you are a fan, you are in it for the long-haul. It takes commitment.

Royals fans are a great bunch. I’ll always view Kansas City as a baseball town, no matter how good the Chiefs are any given season. That’s especially remarkable considering the fact that we’ve only had a single winning season since we won the World Series. FYI, that championship happened 25 years ago, if you didn’t know. Us Royals fans know. It’s always in the back of our minds as we hover around the .500 mark anytime after April. “This is the year, we’re gonna do it!” is what we think. Most fans say that about winning the division. Not us. We just want 82 wins in one year, a winning season. Just once, and then we’ll build from there. Baby steps. Progress.

Over the stretch of a 162 game season, most baseball fans will watch or listen to dozens and dozens of games. There’s a connection you feel with the guys in the booth, a one-way bond that is developed over hundreds of hours of listening to their narrative. I can literally hear the Royals announcers in my head as I write this and make their voices say anything I want. I know them that well. Their catch phrases. Their quirks. Their jokes. I feel like I’ve known them my whole life, yet never met them once. I’m not even sure I’d recognize them if seen in person, but I could recognize their voice from across a crowded room.

Tuesday night, one of our announcers lost a battle with cancer. When the news came out last week that Paul “Splitt” Splitorff was ill, the rumors swirled that he had less than a week to live. It was a shock. We all suspected he wasn’t in great health, but no one thought it was something this bad. Less than a month ago he was calling a game. Two weeks ago he was doing the Royals postgame show. People don’t just… go like that. Do they?

Unfortunately, yes.

As I watched the Royals vs Baltimore game the day of his passing, the Royals TV broadcast observed an inning of silence for a man who gave 2/3s of his life to the organization. He was one of the first players drafted by the new expansion Royals in 1968, and pitched wearing royal blue all 16 years until his retirement. After his retirement, he began an even longer 24-year career as a broadcaster with the team.

He wasn’t the greatest pitcher the team ever had, but he still holds the record for most won games. He wasn’t the greatest announcer the game has seen, but he was ours. He was mine. He was a constant. Every night you know you can turn on the ball game and listen to the same guys call a game.

Broadcasters are special. So much has changed in your life, but they’re still doing the exact same thing they were decades before. The day you graduated high school, they were calling a Royals game. The day you got married, they were calling a game. The day you had your first child, they called a game. The day your kids graduated high school, those same guys are calling yet another game from the exact same booth for the exact same team.

Inevitably though, change must occur, and the next generation is given their chance. Sad that this time it happened sooner than it should have.

We’ll miss you Splitt.

Planting Seeds

6 years and 6 months ago I was a recent college grad, unemployed, and recently fired from my computer sales job. I was horrible at sales. Not because I’m not social and can’t communicate, but because I always viewed myself as being on the side of the customer, not the employer. “No, you don’t need that, it’s twice as expensive as this model, and you won’t use most of the features. Here, this one is a better fit for you. Actually, you probably don’t even need this at all.

Needless to say, sales managers don’t really like that attitude.

So as a 24 year old (f)unemployed person, how do you spend your time? Trying to sell a professional sports team, of course.

Alright, that statement deserves a little explanation. If you know me, you know I’m a huge soccer fan. I’d been attending Kansas City Wizards games since Major League Soccer’s inception (1996) and was very involved in the KC team’s supporters group. Well, a few days after I was given a pink slip, on Dec 9th, 2004 the Wizards ownership group announced they had pretty much given up hope on the team and were putting it up for sale. That was pretty devastating for us fans. We knew there was little chance someone was going to come in and buy an MLS team in Kansas City. If they did, they were buying it to move to another city. There wasn’t much hope in keeping our team, but we weren’t going to lose it without a fight.

Being without a job, I had more than enough time to take the initiative and get the ball rolling. I registered our name (Heart of America Soccer Foundation), wrote forum posts, sent out emails, made phone calls, hosted a wiki for us to organize, etc… It was a busy time for a lot of us. Within a few weeks, we were having meetings, internally, with politicians, and with potential ownership groups. Our goal was to make the city and fanbase as attractive as possible to anyone interested in making a significant investment in the team. We of course weren’t the ones selling the team, but we could make a pretty convincing argument that Kansas City was the right home for whoever was buying it. It was a collective voice that needed to be heard.

While we organized & communicated mostly online, early-on we were without a website, so that needed to change. WordPress of today would have been perfect for the task, but this was 2004, so it was pretty unknown at the time and certainly wasn’t as robust as it is now. I had built a few web sites before, dabbled in PHP, HTML, and CSS, but had never built anything too special and certainly nothing professional appearing. However, that didn’t discourage me, and I was excited for the challenge of learning how to build the site from scratch. Luckily, we had a talented designer in the group, so all I had to do was the coding. Off I went.

Because of how much fun I was having building the HASF website, I started to have the confidence that maybe I could turn my long-time programming hobby into a career. Within a few weeks, I had my first interview for a web developer position at a local startup. During that interview, I was asked all the typical questions, some technical, and some non-technical. I was doing ok. Well, maybe. My lack of professional experience was pretty evident, cause I had none. Towards the end I was asked, “Do you have a website you’ve built that you could show us?

Luckily…

Sure, I just built one a few weeks ago“, and we pulled up hoasoccer.org on the projector.

I was pretty proud of it, and they could tell as I enthusiastically talked about all the things I wanted to eventually do with it.

Later that night, I got a phone call, and a job offer. Accepted!

As I ventured into a new career, my involvement with HASF had to take a backseat. Oh, I was still involved, but I just didn’t have enough time to spend the majority of each day as the COO of a grassroots organization. At that point, more qualified individuals took leadership roles and did an amazing job. It was a long process, but on August 31st, 2006, the team was finally sold to a local ownership group for $20 million. Mission accomplished!

Well, mission accomplished as far as HASF was concerned. There was still a massive uphill battle for the new owners to get a stadium built for the team, ensuring its long-term home is Kansas City. Luckily for them, some of those heavily involved with HASF joined the new ownership group filling a variety of roles. It’s a very talented, passionate group of individuals. While I worked on building my career, they continued on the journey to build a world-class soccer stadium right in the heartland, in Kansas City. I was rooting for them every step of the way.

At the same time, in 2007 I was working as a developer at an advertising agency, and not having very much fun there. Jeff, a friend from HASF, emailed me one day about a meeting with a family friend of his who was working on a startup. We heard the pitch, and the challenge was exciting. I was in the process of buying my first home, so leaving a steady job and going month-to-month contract at a web startup was a pretty dumb idea. My mom disliked it, can’t blame her. But, I took it, and had an extremely satisfying 2.5 years there. It even directly led to the next chapter in my career.

Fast forward to today, a journey that started on Dec 9th, 2004 is going to conclude on June 9th, 2011 with that first game at LIVESTRONG Sporting Park, home of Sporting Kansas City (formerly Kansas City Wizards). That’s 2,374 days of hard work one group of people have done to accomplish something uniquely special. I now live in Los Angeles, but am making the trip back for the first game in the new stadium this week. For myself, it’s going to be pretty amazing walking into that stadium for the first time. There’s a personal connection. But I can’t even imagine what it will be like for those people who have been involved with every step of the process.

It boggles my mind to think what I’d be doing if I didn’t wake up one day and decide I wanted to help save a sports team. If I don’t co-found a non-profit organization that had nothing to do with technology, I likely don’t get that first programming job at a startup. If I don’t work at that startup where I learned what it takes to build the engineering side of a company, I don’t get the experience to actually lead the next startup. Well, that next one is what directly led to where I am today and the new position I’ll be starting in a few weeks.

The takeaway from this story is that you need to be driven by your passions. This stadium’s story very likely could have happened without my involvement early on. But the fun part is, it did happen with my involvment. When you are motivated by things that you love, you’ll make awesome things happen. Continually plant seeds for for the future, because eventually some of those seeds will turn into trees.

You never know, someday one of those trees might look like this…



Photo credits:
Facade: Ramsey Mohsen – Flickr
Grass: Flickr

Joining YUI

It seems like just yesterday I accepted a position with Yahoo and began a new adventure. These last 18 months have been an incredibly exciting time in my life, and am very thankful to have been given the opportunity. I can confidently say that Yahoo is -the- best place to work as a front-end engineer.

Well, the next chapter is about to begin.

Tweet: Exciting day. Accepted a position with the YUI team at Yahoo. Yes, that means I'll be moving to NoCal. Watch out San Fran! I'm comin for ya.

(Note: I’ve since learned it is actually “NorCal”, not “NoCal”. Me = California noob.)

What is YUI?

YUI (mostly pronounced “Y U I”, sometimes “Yooey”) is an abbreviation for the Yahoo User Interface library. It’s a project that began in 2005, and was open-sourced in 2006. It is primarily a JavaScript library, but also contains some CSS components as well (see: Grids, Reset). It is used extensively across just about every webpage Yahoo has, and it is popular externally as well.

Continue reading

On: The Engineer

(Most of this post was written a few months ago and for whatever reason it has been sitting in “draft” status for a while. Figured it was time to finish it up and publish)

According to Wikipedia:

“Engineering is the discipline, art and profession of acquiring and applying scientific, mathematical, economic, social, and practical knowledge to design and build structures, machines, devices, systems, materials and processes that safely realize solutions to the needs of society.”

One morning I was watching Carol Bartz’s interview at the Web 2.0 Summit. John Battelle asked her the question about acquiring engineering talent in the software/web world. When he asked that question, I stopped what I was doing and focused on the conversation because it’s important to me that our CEO understands what motivates us. If she doesn’t “get” it, then the company has a serious problem. Here was her answer:

[Engineers] want a really interesting job to do, they want to have the tools to do it, they want to work on large data sets and large problems, and [Yahoo] has that.

Exactly what I wanted to here. And it’s not just lip-service, there is really awesome stuff we’re working on at the moment, things that haven’t been done elsewhere, so it is clear she does get it.

Then, a theme began to emerge for the day. A friend that works in developer relations at HP/Palm tweeted…

Continue reading

Google shutting down the Translate API

When I have conversations with people about what excites me in technology today, I usually start with the fact that the Web is breaking down barriers in a way we’ve never experienced before. It is simply amazing that anyone is free to publish anything they want whenever they want, and is it instantly available for global consumption.

Today, 2 billion people are on the internet. That means nearly a third of the world’s population has access to Wikipedia, Google, Yahoo, Twitter, Facebook, etc… The Web has finally given us the chance to globally communicate. The only thing restricting us at this point isn’t a technical barrier, but instead is a language barrier. Linguists estimate there are between 5,000-6,000 currently spoken languages on the planet. Yet, very few of us speak more than one or two of those. More than ever we need free & accessible ways to easily translate between languages, allowing us to communicate with a global audience.

Since 2008, we’ve have that. The Google Translate API. It’s an API (application programming interface) that allows you to programmatically send text to Google, and they will translate it for you, for free. It’s an amazingly useful service that I have in one of my Twitter clients to instantly translate any tweets I can’t read.

Sadly, yesterday they posted this message on the API’s page.

Important: The Google Translate API has been officially deprecated as of May 26, 2011. Due to the substantial economic burden caused by extensive abuse, the number of requests you may make per day will be limited and the API will be shut off completely on December 1, 2011. For website translations, we encourage you to use the Google Translate Element.

In other words… “This is why we don’t have nice things”

Very disappointing, especially for a company who set out to “Organize the World’s Information” a decade ago. One would assume the goal of organizing is to make it accessible. Guess not.

When Google implemented the Speech Input API in Chrome, my mind instantly blew up with ideas. I loved knowing that we were so close to having an application for your mobile device that allows you to say something, and it will instantly start translating it into text of any language.

Here’s an example of how easy it could be.

<html>
    <input type="text" speech id="foo">
    <textarea id="translation"></textarea>
    <script src="https://www.google.com/jsapi"></script>
    <script type="text/javascript">
        function translate() {
            google.load("language", "1");
            google.setOnLoadCallback(function() {
                var native_text     = document.getElementById('foo').value;
                var native_language = "en"; //english
                var target_language = "es"; //spanish
                google.language.translate(native_text, target_language, native_language, function(result) {
                    document.getElementById("translation").innerHTML = result.translation;
                });
            });
        }
        document.getElementById("foo").addListener("change", translate);
    </script>
</html>

You could solve a problem humans have had for thousands of years, in about 5 lines of JavaScript code.

Well, starting Dec 1st, 2011, you’ll have to use another service.

There’s no doubt in my mind we’ll get this type of capability in the near future, I’m just disappointed Google decided it didn’t want to be involved in solving these kinds of real, human problems.

Hopefully Google reconsiders this decision. To help, go post a comment on the Google Code blog.