What’s far more interesting than what your friends are doing? What your code is doing, of course. That’s why we’re enjoying Gitspective, developer Zach Moazeni’s Facebook-style timeline for your GitHub events.
Moazeni’s code uses the GitHub API to pull in pushes, forks, gists, branches, tags, follows and comments, displaying them in a vertical timeline reminiscent of Facebook. If you’d like to try it out, just head over to Gitspective’s GitHub page and plug in your GitHub user name.
The Gitspective code is still a work in progress and Moazeni has already listed a few wish-list items over on the Hacker News thread. If you’d like to contribute, grab the code on GitHub.
In case you missed it, yesterday Facebook acquired Instagram, a photo-sharing service with some 30 million users and hundreds of millions of images on its servers.
The reported sale price of one billion dollars no doubt has many developers dreaming of riches, but how do you build a service and scale it to the size and success of Instagram? At least part of the answer lies in choosing your tools wisely.
Fortunately for outside developers, Instagram’s devs have been documenting the tools they used all along. The company’s engineering blogoutlined its development stack last year and has further detailed how it uses several of the tools it’s chosen.
Instagram uses an interesting mashup of tried-and-true technologies alongside more cutting-edge tools, mixing SQL databases with NoSQL tools like Redis, and chosing to host its traditional Ubuntu servers in Amazon’s cloud.
In a blog post last year Instagram outlined its core principles when it comes to chosing tools, writing, “keep it very simple, don’t reinvent the wheel [and] go with proven and solid technologies when you can.”
In other words, go with the boring stuff that just works.
For Instagram that means a Django-based stack that runs on Ubuntu 11.04 servers and uses PostgreSQL for storage. There are several additional layers for load balancing, push notifications, queues and other tasks, but overwhelmingly Instagram’s stack consists of stolid, proven tools.
All in all it’s a very impressive setup that has, thus far, helped Instagram avoid the down time that has plague many similar services hit with the same kind of exponential growth. (Twitter, I’m looking at you.) For more details on how Instagram looks behind the scenes and which tools the company uses, be sure to check out the blog post as well as the archives.
Mozilla is hard at work on a Camera API that will give web developers a way to access your phone’s camera. The Camera API will make it possible to build websites that can take pictures with your device’s camera and then upload them to that webpage. Throw in some CSS-based filters — perhaps a bit of JavaScript to add other image effects — and you’ve got Instagram, no native app necessary.
The Camera API is part of Mozilla’s larger WebAPI project, which is developing a set of APIs that will allow web apps to better compete with platform-native applications. To do that the WebAPI project will give developers access to your device’s hardware capabilities, like the camera, the calendar and even the vibration mechanism.
The WebAPI effort is a long way from complete, but the Camera API will work today on most Android devices. Mozilla’s Robert Nyman has a new post over at the Mozilla Hacks blog that walks through the basics of using the nascent Camera API, including a working demo you can test on your Android device using either Firefox or Chrome.
Bear in mind that, cool as the Camera API is, it’s not yet an official web standard. As with the rest of Mozilla’s WebAPI project, the Camera API is still very much in the development stage.
On the other hand, for those that want to experiment, the Camera API is much further along than some of the other WebAPIs. Adding to the appeal is the fact that the Camera API is being developed in conjunction with the W3C’s WebRTC spec, an effort to standardize a set of real-time audio and video streaming protocols. That means that an official standardized version of the Camera API will likely emerge sooner rather than later.
As it stands the Camera API is already supported in Firefox and Google Chrome on Android devices. Some of the other elements used in Nyman’s demo, like the JavaScript function createObjectURL are also supported in Internet Explorer 10. So far Apple’s Mobile Safari doesn’t support the Camera API or any of the JavaScript used to create the demo app.
Adobe has released Flash Player 11.2 and has decided it’s high time the once-ubiquitous browser plug-in started earning the company a bit of money.
Starting Aug. 1, 2012, Adobe will begin taking a 9 percent cut of game developers’ net revenue over $50,000.
For most Flash developers that means the new revenue sharing plan will not have any effect, but for the very successful companies building Flash-based games using the new domain memory in combination with the Stage 3D hardware acceleration, the change may affect the bottom line.
Users of Flash Player 11 don’t need to pay anything.
There are two exceptions to Adobe’s new revenue-sharing model. The first way to avoid it is to crank out your app now, before that Aug. 1 deadline arrives. The second option is to switch over the developing for AIR, in which case there is no revenue sharing. That means that the new rules don’t apply to any AIR apps compiled to standalone apps for iOS or Android.
So what are you getting for your 9 percent fee? Access to what Adobe is calling Flash’s “premium” features category. The premium features all revolve around the hardware-accelerated Stage 3D graphics in Flash Player 11. The Stage 3D rendering in Flash 11 consists of a low level API that offers hardware-accelerated 2-D and 3-D graphics. Adobe claims that Stage 3D can deliver “console-quality games” in the browser.
Adobe says the new premium-tier features and the accompanying fees are aimed at “game developers interested in creating the most advanced, graphically sophisticated, next-generation games for the web.”
Of course developers may also note that Adobe’s announcement comes on the heels of an impressive HTML5 gaming demo from Mozilla, which might offer some game developers another possible way to avoid Adobe’s revenue sharing plan.
A webpage doesn’t have to look the same in every browser. In fact, a webpage shouldn’t look the same in every browser, according to former Yahoo developer and JavaScript guru, Nicolas Zakas.
Zakas, who spent five years as the front-end tech lead for the Yahoo homepage, recently spoke at the March BayJax Meetup group about what he calls Progressive Enhancement 2.0 — offering users the best possible experience given the capabilities of their device.
Not the same experience, mind you, but the best possible experience. That means progressively enhancing sites according to the device’s (browser’s) capabilities.
Progressive enhancement is perhaps best summed up by the famous Mitch Hedburg quip, “an escalator can never break, it can only become stairs.” In other words, if you’re building websites well they never break, even if you look at them in Lynx. The site may not look the same in Lynx as it does in, say Chrome, it may not function as smoothly, but the core content is still there and can still serve as a stairway that gets people where they want to go even when the enhanced ease of the escalator is absent.
More practically, progressive enhancement means starting with the least capable devices — an older phone, Lynx running on Windows 95 — and then adding more sophisticated features based on screen size, bandwidth and so on.
Zakas also takes on the common assumption that a web “page” is analogous to the printed page. In fact Zakas argues the web is more like television, which has a similar separation of content and device. In that analogy old browsers are like black and white TVs. No one expects a black and white TV to play HD content, but everyone would be disappointed if you served black and white content to an HD TV. Hence the need for progressive enhancement.
If you’re well versed in the history of the web the beginning of the video may be a bit slow, but stick with it. Also be sure to watch the questions at the end where Zakas addresses how to progressively enhance more application-like web pages.