Archive for September 2009
Looks like I may be able to soon replace Adobe Fireworks as my image editing tool of choice for the web. Ajaxian recently featured a new tool called Opacity, and if you follow through to their website, you’ll find a great video tutorial that shows how you can create great looking icons and simple images.
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.
Today Wordpress.com announced RSS Cloud support for all their hosted blogs. Not to be left out of the party, I also installed the RSS Cloud plugin on this blog.
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!
As JavaScript becomes a more integral part to the core functionality of websites, ensuring that a user has a fresh copy of the latest code is as important as ever. Normally a browser will cache certain filetypes (CSS, JS, JPG, etc…) for an indefinite period of time. If the code within one of these cached files is updated, sometimes a browser will not know to reload that file. So, if those changes are important for the functionality of your website, your users may run into issues and not be able to use your site properly. Worse, they likely won’t have any idea what the issue is and will eventually give up and go elsewhere. But have no fear, there’s a solution to this problem… versioning your static files.
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.
I just came across one of the coolest music videos I’ve ever seen, and the beauty of it? It was made by a fan, just for the fun of it. Incredible.
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
