So right now I’m sitting in a booth on the Yahoo! campus, the same booth where I set a goal 20 months ago that one day I’d work for Yahoo! and….

[Wavy distorted omg we're going into a flashback. Begin narration]

My first experience on the Yahoo campus was for Y! HackDay 2008. I remember coming to the campus, being totally lost, and overwhelmed, almost like your first day of High School or College. I wasn’t an employee or anything. I was just a dumb programmer who wanted a taste of what Silicon Valley was really like. Seriously, I come from the startup world in Kansas City, I was in absolute awe of the place. This is where the Internet happens. Holy shit.

I came to HackDay armed with an idea for a hack to build, but was totally unable to focus, so I just sat around, tweeting, talking, and having fun. The music, the hacks, the food, the beer. I was totally awestruck when I talked to someone who worked at Yahoo!, especially the ones working on products I had used. I knew at that moment this was a place I’d always strive to work at. I knew I just *had* to work here, and be the person on the other end of that conversation.

Through the course of that weekend, I met a recruiter who for one reason or another took interest in my skills and said he’d follow up with me. I didn’t expect he would and he was just being nice. A couple weeks later I got a call from him stating he was interested in setting up an interview. I was shocked. “Ok, yeah, umm.. sure, anytime” I was so nervous before that first call. I reviewed just about every book I owned on programming, and I own a lot. I got the call and was speaking with an engineering manager who started asking me all sorts of questions about web development. In retrospect, I totally bombed it, and knew it. Rejected.

Down, but not out, I was focused, I knew it was attainable, but I just needed more time. So, over the next year I did just about everything I could to get my skills up to the level they needed to be for another crack at an interview, always keeping that original interview experience in mind. I had a blueprint. A plan.

A year later I got an email… “I’m back at Yahoo! Want another interview?” It was the original recruiter. “Yeah, absolutely.” The only goal I had this time was getting further than the first. I wouldn’t be totally bummed out if I didn’t get the job, but I at least wanted an on-site interview, just as validation I was making progress. Off I went, studying my ass off for about a week straight, so focused on the lone objective of nailing that phone-screen. The phone rang, and we started chatting. These questions were totally different from the first time. But that’s ok, I knew them. Apparently I did well, and I got an on-site.

The on-site (at the Santa Monica office) went well, and I got an offer. It was a big step leaving Kansas City, but one that I’d always regret if I stayed. So off I went, off to sunny SoCal. I started at the Santa Monica office working with the Entertainment team in November. Due to some mix-ups, I never did make it up here to Sunnyvale for training & orientation. Beyond that, there was never much need for me to be up here in person as we have tele-conferencing equipment galore, and these virtual meetings are in our DNA because we have offices around the country, and around the world.

So 5 months go by and I finally get up here for my first time. I’m actually glad I didn’t get up here before. I get to experience my first day at Yahoo, twice. I knew it was going to be weird, a good weird, and I knew that first time I came here was going to start flashing back. So here I am, sitting in the same booth, sipping my (free) mocha cappucino, admiring the courtyard, the weather, and the conversations going on around me. This is awesome. I have somewhere to be right now. But, nope…

If you haven’t set goals for yourself, do it. Set big ones. Set life-changing ones. When you achieve those, set higher ones, and just keep rolling. If you don’t have goals, find them. I stumbled across this one because I saw a tweet about HackDay, thought it sounded fun, and stepped on a plane to fly out here almost 2 years ago. Random. Lucky… Bold.

It’s feelings like this that you wish you could just bottle up and relive whenever you want.

So, I guess that’s the reason I’m writing this. A 30 minute slice of awesomeness, carved into this blog.

Twitter engineer Alex Payne sent out a prophetic tweet last month. In this message to the Twittersphere, he basically says that Twitter.com is going to be so badass and feature-rich that you’ll soon rethink your need for 3rd party Twitter clients. This caused an uproar in the developer community as many (over-reacting) people took his comments to mean Twitter was going to try & kill off the alternative clients. @Al3x and the rest of Twitter HQ went into damage control mode to explain that Twitter wasn’t attacking alternative clients and that they were still supportive of the developer community. Hugs all around, right? No. I think most people saw the writing on the wall at that point.

I know I have. So, after 2 years of developing my own Twitter clients, I’ve decided that I’m finally throwing in the towel.  Twitter has built a great web app, so there’s little need for me to continue. There’s part of me that is sad, but mostly I’m really happy for Twitter.  Also, I’m relieved as I can now focus on something else.

A little background… It wasn’t up until recently that Twitter’s own web client (Twitter.com) lacked most of the features that I wanted, so I was forced to build them on my own. I began building Tweenky almost 2 years ago and the goal was simple… create a Twitter web client that had the following features:
A) A friendly Ajax interface
B) Integrated searching
C) Groups
D) Saved searches
E) Fixed the @reply problem where replies were not visible to your replies feed unless it started with “@username”
F) Had other basic shortcut features (like retweet links)

When it was ready in the summer of ’08, I released it to the wild with the help of TechCrunch and other tech blogs, who all praised its set of features. I’m not going to claim I was the only one working on such features. Most of them were just obvious extensions to how people really wanted to use the Twitter service. They would have been implemented by Twitter themselves had the service been stable enough to add feature development resources. It’s funny to think that between 2006 and 2009 Twitter.com remained largely unchanged. Why? Because they were generating too many failwhales and fixing those was the #1 priority.

By 2009, the engineering team had rebuilt Twitter into a stable platform and they were finally able to let the front-end developers loose and start working on features. First came some ajaxy goodness, then integrated searching the replies/mentions fix. Later in the year they added Lists and the Retweet feature. At that point, I noticed Tweenky started to become less & less useful. Others did too and the userbase started to decrease.

Enter 2010… The front-end team is beginning to crank out features & tweaks at a fast pace. So far this year we’ve seen hovercards, location dectection, and integrated maps. It’s finally at the point where the speed of innovative features is out-pacing what the developer community will be able to keep up with. There are still some major clients, such as Tweetie (on the desktop) that haven’t even integrated Lists yet. I’m not going to attempt to work on the hovercards or integrated maps, not because I can’t do them, but because what’s the point? I’ve actually begun using the Twitter.com web client more than my own client because it simply lacks essential features. Sure I can add them, but once I’ve completed that, the larger-than-1-person-front-end team at Twitter will have rolled out a couple more slick features, and I will always be playing catch-up.

So here’s the point of this post… I’m done. From here on out I suspect the majority of my Twitter time will be spent on the Twitter.com web client. Don’t take this the wrong way, I’m actually really happy for Twitter and the awesome front-end/UX team they’ve assembled (which includes a number of ex-Yahoo’s =D ). They’ve implemented most of the “must-have” features that 3rd party developers have been working on for years. This is a good thing because those features are now available to the majority of the Twitter userbase instead of a small portion. I suspect over the course of 2010 and beyond, the pace that we see new features will continue to increase, and with every new release, more & more 3rd party developers will cease working on their own clients. This will be a bitter pill for some in the developer community to swallow but the side-effect is they’ll be spending less time on simple, basic features that Twitter.com should have, and instead hopefully on innovative non-client apps or things completly unrelated to Twitter.

I’m happy with this direction. The main reason I’ve developed Twitter clients is to geek around and gain experience in areas I feel my knowledge is lacking. I’ve never approached my client development as “OMG, I have to get as many people as possible to use this thing so I can make money and/or sell it!” I’ve never attempted to monetize my work. I’ve just approached it as there’s a certain user experience I want to have with Twitter, and if anyone else wants to join the fun, cool. No? That’s cool too. Work hard and good things will come.  Having converted the original Tweenky client from mostly PHP to all JavaScript, I’ve been able to gain valuable experience with jQuery, YUI3, & JS in general. To me, that is satisfying enough. All the JS, REST API, and scaling knowledge I gained through this process is one of the reasons I now have a job at Yahoo.

So what’s next? I dunno. If I’m spending X less hours per week trying to replace Twitter.com, I can now spend X hours working on something else. I’ll most certainly work on some non-client Twitter apps, but I’m hoping to spend the majority of my time on non-related Twitter projects. Maybe some much needed Node.js hacking? Maybe some WebOS apps? Hmmm… Stay tuned.

P.S. Tweenky has always been an open-source project. You can find the source code on GitHub. You can also find Tweenky’s cousin “Tweetanium” (a YUI3 rewrite) on GitHub as well.

The more I play around with Node.js, the more I love server-side JavaScript. Once you get over the weirdness of writing JavaScript outside of the browser, it feels very natural. And the bonus is that it is blazing fast.

Also, as I’ve been playing around with YQL (Yahoo Query Language) more lately, I realized I wanted to be able to access YQL data from within my Node app. So, I created a node-yql module.

Now you can do something like…

YQL.get("SELECT * FROM weather.forecast WHERE location=90066", function(response) {
 
	var location  = response.query.results.channel.location,
	    condition = response.query.results.channel.item.condition;
 
	sys.puts("The current temperature in " + location.city + " is " + condition.temp + " degrees");
});
// Output: The current temperature in Los Angeles is 57 degrees

The real power of jsFiddle is that you have the option to include any of the most popular JS libraries, including; Mootools, jQuery, Prototype, YUI2.8, YUI3, Glow, Vanilla, Dojo, Processing.js, & ExtJS. This feature gives anyone the ability to try out any of these libraries without going through the task of downloading, extracting, and coded up some examples. With a few mouse-clicks you can view example snippets from any of the major JS libraries, and start editing them to see how they work.

As if that wasn’t enough, jsFiddle also includes social features that give you the ability to write a snippet, save it, and share the URL. As I was hanging out in various JavaScript IRC chatrooms tonight, I continually found myself using jsFiddle to code up snippets to answer questions. In the past, everyone would always just use Pastebin.com, but that lacks any interactive features. Now you can use jsFiddle as a replacement to Pastebin for any JS, HTML, or CSS snippets and the user will have the ability to actually edit, execute, and view the output.

As icing on the cake, you can take your snippets, copy the embed code, and paste them anywhere. Here’s a snippet that I was able to code up in about 15 minutes (writing this blog post took longer than that!) to demonstrate the power of YUI3, YQL, and the Twitter API. In this iframe, you’ll find all the JS, CSS, and HTML you need to create a simple little Twitter widget.

In all, this is an amazing product that I’ll likely find myself using on a daily basis.

I just finished watching Part 1 of Douglas Crockford’s ongoing lecture series on JavaScript, and it’s fascinating stuff. A must watch for any programmer. Even if you don’t code in JS, it’s worth watching simply because this first part is all about the history of programming. (video of talk is below)

As web developers, we spend anywhere from a little bit of our time to the majority of it coding in JavaScript, but few know the history behind the language. I’m not talking about just reading the Wikipedia article and knowing that it was created by Brenden Eich at Netscape in ’95, I’m talking about the history of where the ideas behind the language came from and everything that influenced it. Like most every language, JavaScript’s syntax and style didn’t appear out of nowhere, it was influenced by a number of different languages, and those influencers were in turn also influenced by a slew of languages.

It’s easy for those of us that started programming with C (or anything after) to just look at it as the “Alpha” language and ignore everything that happened before it, but that’s missing a lot of really important history, that we, as professionals, should know. It’s like a politician in the United States just ignoring everything that happened before 1776. Learn from the mistakes of the past and spot the trends going forward and pave the best path. Crockford shows us snippets of languages that were created in the 60′s and 70′, dissects them, and explains why certain people thought they were good ideas at the time. It’s amazing to think that there was a time before modules or functions, or before we had figured out the best way to format a for loop. The history of programming languages is littered with a ton of bad ideas, but occasional brilliant ideas. Those brilliant ideas are what get refined, and lay the foundation in the next generation of languages.

Finally, one concept he goes back to over and over that I found really interesting is that programmers are a very stubborn breed. We all know this. There’s little point to all our flame wars on which language or framework is better, and most of it comes from either insecurity or ignorance. He says it takes a long time for us to evolve, and he’s right. It’s not because new ideas aren’t coming along all the time, but it’s because the adoption of new ideas only take place at each generation shift, when the “old” thinkers get replaced those with few preconceived notions. The world didn’t wake up one day and realize that GOTO statements were bad, it’s that those who supported GOTO and argued for it for a decade finally retired. Out with the old, in with the new. That’s evolution.

Anyways, I could go on and on about all the “Ah hah!” moments in this talk, but you really need to watch it for yourself. I’ll probably chime in again after part 2, which I’m probably going to watch right now. I’m excited. It’s like a sequel. “Ooo! What happens now?!”

Also, here’s the “Mother of all Demos” video he mentions about halfway through.

It’s now been about 6 weeks since Apple bought Lala and I’ve spent some time reflecting on the acquisition. When I first heard the news, it sounded like a good fit. After-all, Lala is essentially a web-based version iTunes and has some great technology powering it. It makes sense that Apple would want to buy the next best thing and get some great engineers in the process. However, I didn’t think at the time that Apple’s strategy would become so clear, so soon. Apple’s acquisitions usually take years to come to fruition. Not this time though. TechCrunch recently reported that Apple is planning on transforming iTunes into a cloud-based iTunes.com service, and Lala’s technology is the quickest way to do that. (“Apple’s Secret Cloud Strategy And Why Lala Is Critical“).

Seeing the immediate impact Lala’s technology can have, I began to think about who else was in the bidding war for Lala? Most reports say there were multiple companies interested, so you have to assume the a few of the typical parties were involved; Google, Amazon, Microsoft, Yahoo, AOL, Facebook, & MySpace. Only a couple of those companies stand out as a great fit, Amazon & MySpace. Right now MySpace has too many problems to deal with, so that leaves just one likely suitor… Amazon.

Amazon’s entry into the digital music download space has been game-changing. Prior to Amazon.com/mp3, music lovers had no where to go to purchase non-DRM’d MP3s. We were stuck in the world of buying CDs to rip, buying DRM’d tracks from iTunes, or of course… pirating music. When Amazon came into the market in 2008, their impact was immediately felt as prices began to drop and DRM began to die. This opened the floodgates to other services who also began selling non-DRM’d MP3s, and music streaming became a sustainable business model. Without Amazon’s entry, I suspect little would have changed over the past 2 years. Having competition for Apple is vitally important to the evolution of the media industry. Apple is an amazingly innovative company, but like most companies, they grow content & less innovative without anyone breathing down their back.

As painless as Amazon has tried to make the downloading process when you purchase tracks from their MP3 store, it is still not as smooth and elegant as iTunes. To add insult to injury, once the download is complete, Amazon’s user experience is then transfered over to iTunes (for most users) where the user must import the purchased files to begin listening. Amazon clearly needs to do something about this. Transferring a customer into your rival’s product at the end of the transaction process is a giant flaw in product design. They need to provide their customers a way to stay in an Amazon environment throughout the Purchase->Download->Listen->Manage cycle. This is where their acquisition of Lala would have been perfect.

Had Amazon bought Lala, they would have obtained the engineering team that is hands-down the best at building a web-based media manager. After integrating Amazon MP3 with Lala, they could then integrate the Amazon Video & Kindle management interfaces into the Lala-based manager. Beyond music, video, and books, Amazon could then begin to expand into other areas, perhaps buy a company like Roku and make their streaming video experience end-to-end Amazon as well. We could have had a real competitor to iTunes. Sadly though, Amazon dropped the ball with Lala, especially since the acquisition only cost Apple $17 million. That’s nothing for a company that just spent over a billion dollars to purchase Zappos.

We’re clearly approaching a time where our music devices are going to have constant wireless broadband connections. You won’t have to worry about locally storing music, it can all be hosted in the cloud and streamed to you on demand. This isn’t a brand new concept, but the timing is right for it to finally become mainstream. If Apple is successful in transforming iTunes into iTunes.com, unchallenged, they will likely be able to declare “game over” with music delivery in the US.

Hopefully Amazon sees the writing on the wall and steps up their game to provide a challenge. Is Spotify our only hope?

Up until now the Twitter developer ecosystem has been very closed. Sure the Twitter APIs are as open as possible, but all the clients out there are largely closed platforms. There are a few exceptions, including Spaz and Tweenky (my client) which are open-source. It is great to have a starting point (aside from raw libraries) that gives developers a place to start with when building a Twitter application. With Seesmic Desktop invading Windows with a programmable version that you can write plugins for, this is a huge step that hopefully will push other developers/companies towards the same model.

When I launched Tweenky about 18 months ago, I hadn’t event thought about making it programmable, but pretty quickly afterwards I realized the potential it could have if it were programmable, and so I began a rewrite, and coded it in 99% JavaScript with two plugins out of the box, Twitter and Identi.ca. I had plans for other plugins (Facebook), but the problem with developing a platform, and not just an application, is that it takes a loooot of time. For one guy working in his spare time, it just wasn’t going to be possible to abstract out a platform and develop a community around it. So, I started with another rewrite and only focused support for Twitter. I still think it was the right move given the limited amount of time I can spend developing it.

What I’m really waiting for is an easy way for Twitter developers to monetize their applications. We’ve all seen what the Apple has accomplished with the App Store and the ecosystem they created overnight. While most iPhone developers have made very little, others have won the lottery and struck it rich. While Twitter (the company) has been very supportive of the developer community, they should really look at giving it a push and figuring out a way to monetarily reward Twitter developers. Nothing gets developers going like a big, fat, diamond crusted carrot dangling in front of their noses. Afterall, Twitter wouldn’t be Twitter if it weren’t for the developers. The various clients are what made the service usable for the hard-core Twitter users that create most of the valuable content.

P.S. You can still view the programmable version at beta.tweenky.com.

Coming into this job as the lead developer for MyCatholicVoice.com, I had zero experience running a project the size of where we have taken this. I had never built a web server this size from scratch (software-wise). But along the way, I’ve had to tackle hundreds, or heck… likely thousands of problems along the way, and I’ve learned something at every step. It’s been such an incredible learning experience as I’ve gained a bit of knowledge about so many different areas. These new skills include everything from cloud computing, systems architecture, to Linux administration, all the way to the front-end with JavaScript libraries. Then of course, that middle layer of PHP where my skills and knowledge have improved an unmeasurable amount.

When I started my career after graduation 5 years ago, I had a gameplan, a very iterative gameplan:

• Step 1: Get a job, anything.
• Step 2: Find a web development job, maybe it would be something that I wasn’t thrilled about or didn’t pay well, but it was at least enough to get me in the door as a programmer.
• Step 3: Find a job that paid a decent amount, but didn’t have to be a project I was passionate about.
• Step 4: Now that everything else is taken care of, find a project I was passionate about.

Beyond those 4 steps, I wasn’t sure exactly what came next. Perhaps it was starting my own company? Maybe moving out to the west coast? Maybe it wasn’t even in web development? In fact, mid-step 3, I considered changing careers because my job was just so unfulfilling. I enjoy cooking, so maybe Culinary school? Then I remembered I don’t like anything outside 10 foods, so nevermind that. I loved doing 3D animations in high school, but never pursued it because I can’t draw. So… I stuck it out and realized it was just my job, not my career choice, that was unsatisfying. Boom. Reenergized.

Well, tomorrow is the transition between from Step 4 to Step 5. This year I realized the next step for me was going to be moving to LA, SF, or Seattle. I needed to get to a tech hub where there were thousands of jobs, with companies large & small. But, there was also something from this last step that I was missing, that “passionate about the project” part. While I’m incredibly proud of the platform we’ve built at MyCatholicVoice, I’ve never been able to have much of a connection with our users. Why? I’m a non-Catholic working on a Catholic project. While I think the purpose of the project is a noble one and I agree with bringing “web 2.0″ to the Catholic church, it ultimately doesn’t effect me faith-wise. That’s a little bit of a bummer sometimes. I want to be a user of the product, as well as a developer.

Well, enter Yahoo. Talking about being a user of a product… Y! is one of the oldest services I still use from my first days on the internet in the mid-90s. Check out my last post for all the reasons I’m thrilled to have this opportunity.

So, what’s after what’s next? Hmmm….

When I attended Yahoo’s HackDay ’08 at their Sunnyvale headquarters, I was so impressed with the people, the event, the technology, and the culture at Yahoo, that I made working for Yahoo one of my career goals. Well, it came a little sooner than I expected, and I’m thrilled to say that starting Nov 23rd, 2009, I can scratch “A career with Yahoo” off my bucket list.

Why Yahoo?

There are a number of reasons why Yahoo is so appealing to me at this point in my career.

The Scale: As a developer, there is a lot of satisfaction in knowing that millions of people are happily using your products. With billions of pageviews per day across the Yahoo network of sites, there are only a handful of companies that can offer similar challenges as Yahoo (Google, Facebook, Microsoft, and maybe a few others). At Yahoo, I expect to learn what it takes to code and assemble massively scalable web applications. Not many developers get a chance to work on products this large, and it is certainly an opportunity I find invaluable.

The Collective: Yahoo employs roughly 15,000 people, and thousands of those are software engineers working on some of the largest products used on the web. I’m confident that whatever problems I may run into on a daily basis, there is someone at Yahoo that has the knowledge to help me out. I can name dozens of current and former Yahoo employees that have inspired me in one way or another during my career, and I’m sure I’ll meet dozens more.

The Products: Yahoo certainly has its fair-share of best of breed products on the internet. The jewels are of course the Yahoo portal, Yahoo Mail, and Flickr. Beyond that, there are some other very successful products throughout the years, including; Yahoo Games, GeoCities, Messenger, Music, Movies, News, and Sports. All of which I’ve used extensively at one point or another. My first Yahoo account I created when I was 15, and I am now 28. There’s certainly a sense of pride and satisfaction knowing that I’ve been a happy customer of my future employer for 13 years.

The Culture: Yahoo puts an enormous amount of resources into their Developer Network and open-source technologies. As an advocate of open-source software, it’s a thrill to know I’m working for a company that values it as much as I do. It’s a shame that some of the neatest tools Yahoo has to offer are still unknown or unused by many developers (YQL, Pipes, & YUI), and I will certainly do my best to evangelize the incredible tools Yahoo has offered to the community.

The Location: Having lived in/near Kansas City my whole life, I love it here, but between October and March sometimes you wish you could take a vacation to Hell just so you can warm up a little bit. I’ve been to Southern California probably a dozen times throughout my life, and it doesn’t take more than a few minutes of the ocean breeze, the palm trees, and the sunshine before you don’t want to ever leave.

Since I signed the paperwork and this whole thing became a reality, it has certainly taken a while to sink in. I still don’t think it has fully sunk in, and even after my going away party this weekend, boarding that flight to LA on the 22nd, it still may even take sitting down at my desk before I finally realize what just happened. So needless to say, I’m thrilled with the opportunity Yahoo has presented, and during my time there I will do my best to ensure it is as rewarding for them as it is for me.

Finally, I wanted to thank Fred & Mary Kay Fosnacht for sharing their dream with me over the last 3 years. Working for Catholic Content has been an amazing experience and certainly has been life-changing. I can safely say that my career wouldn’t have been the same without their confidence and encouragement and I will always be grateful for the opportunities they’ve given me.

Onward and upward.

function genRandomString($length = 10) {
    $characters = ‘0123456789abcdefghijklmnopqrstuvwxyz’;
    $string = ”;
    for ($p = 0; $p < $length; $p++) {
        $string .= $characters[mt_rand(0, strlen($characters))];
    }
 
    return $string;
}

While that’s great and all, don’t you just feel like there’s some better, simpler way to generate a random string? Preferably something done all in one line, so you don’t even need a function inside your code?

There is a way. Actually, there are lots of ways. There are numerous functions in PHP that can be used to generate a string of random characters, and the one I typically use here is something you’ve probably used quite a bit… md5().

If you aren’t familiar with it, MD5 is a commonly used hashing technique that can be used to generate a unique 32-character “fingerprint” of a string. While it has been shown to have some security holes and not be collision proof, that isn’t really a concern the majority of the time you need to generate a random string. So, we’ll go ahead and use it here.

echo MD5(); // PHP Warning:  md5() expects at least 1 parameter, 0 given

So, we need to pass in something, anything, but try to be unique. microtime() is a good choice.

echo MD5(microtime()); // 5959e4c551ee3a91d89449437b681ead

Great, now we have a random 32 character string. But what if you only want a slice of that, like 5 characters? substr() is your answer.

echo substr(MD5(microtime(), 0, 5); // 5959e

If you are concerned about security and making this string as random as possible, just shuffle it with str_shuffle().

echo substr(str_shuffle(MD5(microtime())), 0, 5); // 6c468

Now wasn’t that easy?

Via RWW: Google’s Eric Schmidt on What the Web Will Look Like in 5 Years

• Five years from now the internet will be dominated by Chinese-language content.
• Today’s teenagers are the model of how the web will work in five years – they jump from app to app to app seamlessly.
• Five years is a factor of ten in Moore’s Law, meaning that computers will be capable of far more by that time than they are today.
• Within five years there will be broadband well above 100MB in performance – and distribution distinctions between TV, radio and the web will go away.
• “We’re starting to make significant money off of Youtube”, content will move towards more video.
• “Real time information is just as valuable as all the other information, we want it included in our search results.”
• There are many companies beyond Twitter and Facebook doing real time.
• “We can index real-time info now – but how do we rank it?”
• It’s because of this fundamental shift towards user-generated information that people will listen more to other people than to traditional sources. Learning how to rank that “is the great challenge of the age.” Schmidt believes Google can solve that problem.

It’s hard to argue with any of those, really. The one I’m looking forward to most of all is the convergence of media platforms as the lines between TV, Radio, and Web become more and more blurry. As those lines become blurred, more innovation will occur between the gaps and the old-time revenue models based mostly on distribution begin to fall apart.

Here’s how you can do it.

// Define some vars
var foo = "hello";
var bar = "world";
var function_name = "say_" + foo + bar;
 
// Since its name is being dynamically generated, always ensure your function actually exists
if (typeof(window[function_name]) === "function")
{
	window[function_name](" World!");
}
else
{
	throw("Error.  Function " + function_name + " does not exist.");
}
 
function say_helloworld(the_word)
{
	alert("Hello " + the_word);
}
 
// Browser will alert "Hello World!"

When you think about it, it makes a lot of sense considering all global objects in JavaScript are actually properties of the “window” object. Take a look at this example to understand that concept a bit more.

var foo = "apple";
 
function foobar()
{
	var foo = "orange";
	alert(window["foo"]); // alerts "apple"
	alert(foo); // alerts "orange"
	alert(window["foobar"]); // alerts the foobar function
}
 
foobar();

Here’s another example of when using a string to call a function could come in handy. This time we’re calling the property of an object we’ve created.

function Person()
{
	this.message = "Hello World!";
	this.say_hello = function(to)
	{
		alert(this.message);
	}
}
 
var Derek = new Person();
function_name = "say_hello";
Derek[function_name]();

See how it looks pretty much the same as the method above using a global function?

Hope that shed some light on your problem.

But, the best feature in my eyes could be their JavaScript export option that can be dumped inside HTML5′s <canvas> tag to render & animate the image. I haven’t yet seen the source code this generates, but it seems logical that you could translate layer based vector art into JavaScript.

Another feature I also love is the integration with the various OSX FTP clients like CyberDuck and Transmit, as well as the dynamic web preview option.

With <canvas> being relatively new on the scene, a tool like this could really bridge the gap between designers & developers and accelerate the adoption of another open standard that can help push the “open web” forward.

You can read more about Opacity at WebMonkey’s review or check out Opacity’s product page

If you can’t wait to get your hands on Chrome for OSX, go download a Chromium nightly build, unzip, and copy to your Applications folder.

At first glance, it doesn’t appear much different from Safari, which isn’t too surprising since they’re both based off the the same layout engine (WebKit). The real differences are just going to come in the skin (which is pretty similar) and the JavaScript engine (Chromium = V8, Safari = Nitro, formerly “Squirrelfish”).

Rogers Cadenhead recently wrote a post “The Reason RSS Cloud Failed to Catch On“. In this he argues that RSS Cloud is not sustainable when it begins to scale to thousands of users needing to receive pings every time a post is made. While he has a point, I believe his argument is much more accurate when put into the context of 1999 as opposed to 2009, and it is even more irrelevant a few years from now. This points to one thing… RSS Cloud was ahead of its time.

Today, supporting RSS Cloud is cheap. Bandwidth is a fraction of a percent now compared to what is was 10 years ago along with cloud based virtual servers available for ~$10 / month. I’d suspect a properly tweaked VPS at the Rackspace Cloud or EC2 could handle millions of pings / day without issue. Unlike PubSubHubBub, the content of the post is not delivered with RSS Cloud, it is just a body-less ping, so bandwidth isn’t even an issue. A server supporting these types of capabilities back in 1999 would have cost thousands of dollars per month. Now? Just a few bucks. 5 years from now I suspect it will be free (example: Google App Engine is currently free and could be configured for this service).

Let’s go ahead and take into consideration the dream scenario with RSS Cloud, and that is that we have completely replaced Twitter. In this scenario Ashton Kutcher will have 5 million followers and will need to notify each of those followers when he tweets out 100 mundane posts / day. Let’s not kid ourselves and not think there is a middle man in there somewhere. These services are the “Cloud” portion of whole term. Just like Feedburner and Google Reader are proxies between publisher and reader now (by storing local caches of RSS feeds), there will be many services that would be happy to host the feeds, providing a web client to the reader and analytics to the publisher in turn receiving all the statistics they chew on. Proof? Twitter purchased Summize (search.twitter.com) and Google bought FeedBurner because they saw the value of this type of service. Afterall, the analytics portion of that is the whole business model that Twitter is rumored to be building.

But ok… let’s assume those “Cloud” services never pop up because, hell… I don’t see any reason why they wouldn’t, but let’s just imagine they don’t exist. Solution? TURN OFF THE NOTIFICATIONS! That’s the beauty of RSS Cloud feeds, it’s completely backwards compatible with non-Cloud enabled feeds. If the Cloud server fails to send out notifications, then their subscribers will simply revert back to the old method of routine polls looking for new content. But, failing to notify your subscribers of new content in a sea of real-time has drastic consequences. Even if you are the first to report information, you will always be “scooped” by others because the lag caused by your inability to notify your subscribers. That alone will be enough to even the playing field. As a compromise, you could get away with just notifying a few dozen RSS aggregators (Google, Yahoo, Feedburner) to take care of the majority of your subscribers, and those using readers you don’t notify will revert to polls.

So as you can see, RSS Cloud is currently gaining traction because it wasn’t until now that it was a viable service for the masses. Even now there is very little support within the client portion of RSS Cloud, but I suspect that will be a battleground many will fight for in the next couple years.

RSS Cloud is an ancient RSS element (in web 2.0 years) that has been given new life recently as the “realtime web” in exploding (thanks to Twitter and Facebook). Basically, it allows RSS readers the ability to be notified when a feed has been updated instead of waiting minutes, hours, or days before that client has a chance to check the feed. Now, an RSS Cloud supported reader that is subscribed to an RSS Cloud enabled feed can be notified within seconds that the feed has been updated. RSS now has a realtime element.

RSS Cloud support is still in it’s infancy with only 1 RSS reader supporting RSS Cloud notifications (River2), but within the coming year, it could become a game-changing technology that can give rise to self hosted Twitter-like publishing platforms. There’s a number of people (myself included) that are working on such platforms, and hopefully I’ll be able to make an announcement in the coming weeks. My feeling is, as great as WordPress is for blogging, it’s not the ideal platform for micro-blogging. What the community needs is a microblog version of WordPress that has a real-time element, and I think this RSS Cloud element fits the bill.

Related Articles

• WordPress: RSS in the Clouds
• TechCrunch: WordPress.com Enables RSSCloud In Post Feeds
• ReadWriteWeb: WordPress Just Made Millions of Blogs Real-Time With RSSCloud
• Scripting.com: Tease! Tease! Tease!

By “versioning” these files, I’m referring to changing their filenames from “my_styles.css” to “my_styles.version274.css” for example. The problem with that example is it relies on you renaming the file and updating your includes every time you make a change. That sounds like an nightmare, right? Luckily there’s a neat tactic you can you to make it appear to the browser to be a new file, but it will actually be the same file and will require no effort on your part. This variation of the versioning tactic is often referred to as “Auto-versioning”. Here’s an example…

First, we use the following rewrite rule in .htaccess:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-s # Make the file doesn't actually exist
RewriteRule ^(.*)\.[\d]+\.(css|js)$ $1.$2 [L] # Strip out the version number

Now, we write the following PHP fuction:

/**
 *  Given a file, i.e. /css/base.css, replaces it with a string containing the
 *  file's mtime, i.e. /css/base.1221534296.css.
 *  
 *  @param $file  The file to be loaded.  Must be an absolute path (i.e.
 *                starting with slash).
 */
function auto_version($file)
{
  if(strpos($file, '/') !== 0 || !file_exists($_SERVER['DOCUMENT_ROOT'] . $file))
    return $file;
 
  $mtime = filemtime($_SERVER['DOCUMENT_ROOT'] . $file);
  return preg_replace('{\\.([^./]+)$}', ".$mtime.\$1", $file);
}

Now, wherever you include your CSS, change it from this:

<link rel="stylesheet" href="/css/base.css" type="text/css" />

To this:

<link rel="stylesheet" href="<?=auto_version('/css/base.css')?>" type="text/css" />

And when rendered, will appear as:

<link rel="stylesheet" href="/css/base.1251992914.css" type="text/css" />

How does this work? Because that mod_rewrite rule above will strip out the timestamp, your server will deliver /css/base.css as the requested file. But to the user’s browser, it will appear as a different file whenever it is updated.

Neat!

Note: Some strategies to fix this caching issue is to append a version # onto the end of the css or JavaScript file with a querystring, such as:

<link rel="stylesheet" href="/css/base.css?version=1234" type="text/css" />

This method will actually prevent the file from being cached, period! This is bad. You want the benefits of caching. You don’t want to make your users pull down 100k of JavaScript & CSS files on every page load. More importantly, your servers could start to strain under the additional load.

Why is it not cached? See Section 13 from the HTTP Specification, in particular Section 13.9

13.9 Side Effects of GET and HEAD

Unless the origin server explicitly prohibits the caching of their responses, the application of GET and HEAD methods to any resources SHOULD NOT have side effects that would lead to erroneous behavior if these responses are taken from a cache. They MAY still have side effects, but a cache is not required to consider such side effects in its caching decisions. Caches are always expected to observe an origin server’s explicit restrictions on caching.

We note one exception to this rule: since some applications have traditionally used GETs and HEADs with query URLs (those containing a “?” in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URIs as fresh unless the server provides an explicit expiration time. This specifically means that responses from HTTP/1.0 servers for such URIs SHOULD NOT be taken from a cache. See section 9.1.1 for related information.

Link: Two Weeks – Grizzly Bear from Gabe Askew.

One of the first things I thought about while watching Gabe’s video was whether this would be yet another take-down viral video because of copyright infringement? But, a group like Grizzly Bear (or their record label) would be crazy to complain about the soundtrack because of the attention it generates for the song.

You could either be a band that removes the soundtrack from someone’s artistic work, infuriating them and accomplishing nothing. Or, you could capitalize off it, much like Chris Brown’s (or his record label’s) decision to not remove the soundtrack from the “JK Wedding Dance” video that ended up boosting him to #4 on the iTunes charts and possibly saved his career.

Another recent example is the use of Barcelona’s “Please Don’t Go” song in a tranquil aquarium video that has been 1.8 million views at the times of this posting. The band was so pleased that they posted a video response to introduce themselves to their new fans and credited the video towards increased albums sales and concert attendance. Instead of saving a career (as in Brown’s case), this very well could make a career for these guys, and all because they lucked out and had a passionate, artistic fan that wanted to showcase both their works, together.

Gabe’s video is yet another great example of how music artists (and any celebrities) for that matter can use their fans to crowdsource ideas and content. Instead of spending thousands or millions to produce a video, you can get really high quality content for next to nothing, all because your fans are passionate about your work and want to be more involved. So get them involved, they want to be, and they’ll reward you for the opportunity.

As a final example, here’s a video from Tilly & The Wall which was completely crowdsourced by their fans. All they did was ask users to send in clips of them singing their song “Rainbows in the Dark” and spliced them all together, making an awesome, fun, and cheap video. Imagine a progressive band like Nine Inch Nails or Radiohead saying they weren’t going going to make a video for their latest single and instead were holding a contest for a fan to make an “official video” for that song and awarding $20k? Contests like that can become a breeding crowd for viral videos, something all musicians are dying for nowdays.

Related reading:

• ‘Pirated’ Youtube Clip Boosts Band’s Album Sales
• Could Viral Wedding Dance Video Save Chris Brown’s Career?
• Interview with Gabe Askew

#1 Shakira – She Wolf (2009)

I can’t help but crack up everytime the chorus kicks in, it’s just horrible. And the “Ah-ooooo” 1:35 into the song? What hack producer though that was a good touch?

#2 Black Eyed Peas – I Gotta Feelin’ (2009)

This song is such a crock of shit. Not that I expected amazingly creative lyrics from the Black Eyed Peas, but c’mon, this song isn’t even trying. Here’s a great review from Cracked.com, Black Eyed Peas Have Officially Written The Worst Song Ever

#3 Rednex – Cotton Eye Joe (1995)

Whoever the hell though mixing techno and country would be a good idea needs to be shot. Oh, and don’t forget about the group’s chartbusting 2002 follow-up, Cotton Eye Joe 2002

#4 Toby Keith – The Angry American (2002)

On the topic of rednecks…

Outraged by the 9/11 terrorist attacks, Toby Keith enlisted in the Air Force — no, sorry, he wrote a fight anthem so vengeful, it makes “The Star-Spangled Banner” sound like “Give Peace a Chance.” Though right-wing radio hosts and politicians called him a hero, Keith (who hadn’t had a hit in years) moaned, “It sucks ass that I have to defend myself for being patriotic.” Wrong. You have to defend yourself for celebrating violence and bloodlust.

#5 – Billy Ray Cyrus – Achy Breaky Heart (1991)

As if line-dancing really needed a comeback. This is a song that gets stuck in your head, and won’t leave for at least a couple days. So go ahead, click the image, I dare you.