Server teams are made up of the people who write and maintain the code that makes servers go, as well as those who keep that code working. Twitter, Facebook, Instagram, Amazon, Google, and every other service in the world have one or more people in this role. When things go right, nobody notices, and they get no praise. When things go wrong, their phones ring at 3 in the morning, they're up fixing a new issue, and they're answering calls from every cog in the corporate ladder who's screaming about how much money they're losing. It's a thankless job.
Diablo 3's launch has had a number of issues around load. When you have millions of people swarming on a server, ruthlessly trying to log in every few seconds, it causes a huge amount of load. At this scale, things you expect to go right suddenly break in strange and unfamiliar ways. No amount of load testing could adequately prepare the server team behind Diablo 3 for firepower of this magnitude. The way you fix these kind of issues is to look at what's slow, fix it to make it less slow, and hope it works. Do this until load stops being a problem. Oh, and you have to do it quickly, because every second that goes by people are getting more and more upset. And you can't break anything else while you do it.
The people who work on the servers for services of any decent scale cope with new problems every day around keeping the thing alive and healthy. The Diablo server team has been moving quickly, solving issues of massive scale in a short time, and getting the service running again. Players notice and yell the service when it stops working, but the response to it and the maintenance of it has been quick and effective.
Next time you're using an Internet service, or playing a multiplayer game, think about the people who keep it running. If you know any of these people, tell them thanks. They're the unsung heroes of the Internet.
Adobe is finally putting an end to Flash Player. They've announced they're stopping development of the mobile Flash Player, which is where the future of tech innovation is heading, and the writing is on the wall for desktop Flash Player as well. This is a good thing for a myriad of reasons, both technical and political.
However, it is important to remember that Flash drove much of the innovation on the web as we know it today. When Flash was conceived over a decade ago, the web was a glimmer of what it is today. Creating something visually impressive and interactive was almost impossible. Flash brought the ability to do animation, sound, video, 3D graphics, and local storage in the browser when nothing else could.
Flash Player itself seemed like a means to an end. Macromedia, and then Adobe who acquired them, sells the tool that you use to build Flash content. Thus, Adobe's incentive was not to build a great Flash Player, but a pervasive one that would sell its tools. Its technical stagnation provided a market opportunity for browser developers to fill in the gaps that Flash provided. As a result it has a huge market dominance in tools for building rich apps for the web, tools HTML5 lacks.
HTML5 offers developers the ability to build high-performance, low-power apps and experiences. Browser innovation has never been faster; Apple, Google, Microsoft, and Mozilla are all competing to bring the best new features to their browsers in compatible ways. But they're just now filling in many features Flash Player has had for years. Adobe can harness this to help build a better web, and few others can. Hopefully they seize this moment.
iCloud looks like it will be an incredible technology for moving app data between devices. This is inherently a good thing, and it will open avenues for many new types of apps. But, there is a fundamental problem. Right now, the only way to access it is through Objective-C APIs embedded into iOS and Mac OS X. Under the hood, they are obviously talking to the network and doing the business of syncing data, but that networking layer is not exposed or documented, and would have to be reverse-engineered in order to understand and use. So the only way for developers to move their data through this system is through a pre-compiled bundle that gets referenced within an application.
This has a few interesting practical repercussions. If you build an application targeting iCloud, you can only ever put it on two platforms - Mac and iOS. You will never be able to port it to Android, WebOS, Windows Phone, or the web (mobile or desktop). If you sync data through iCloud, And, you will never be able to have a server component that can do things with your data all the time.
Here's some examples of what I'm talking about. In my To Do list app, Todolicious, one thing I would love to be able to do is to push badges to your iPhone and Mac showing the number of To Dos you have left. When you tap a To Do to mark it as done, suddenly all your devices would show the correct number on the icon. With the sync server I was building, this was fairly trivial; wait for the user's list to change, and send a signal to push the count everywhere. But if I back Todolicious with iCloud, I have no way of speaking between my server and iCloud (and I'd still need a server of some kind to send the notifications, after all).
Similarly, if I were to build a web app version of Todolicious (which I was planning on), I could not get access to that data within iCloud at all. I'd have to have either to sync to both iCloud and a custom solution (unwieldy, poor UX and network traffic, and otherwise gross), or not load existing data at all (completely negating the benefit of having such a web app).
So there is a serious ecosystem lock-in problem for apps that wish to target iCloud. All of these problems go away when iCloud is made available as a server-to-server API. A big benefit in the promise of cloud computing includes service interoperability, but right now iCloud is merely a data silo. I have filed this as a bug, rdar://9598555, for a server-to-server API (through which you could build code that speaks to iCloud on your server or on other platforms). I dearly hope Apple addresses it.
Such a server-to-server API would drastically decrease the friction of setting up cloud services to complement an iCloud-backed app, and would lead to better apps and more pleased users.
Twitter recently introduced a feature on its website called "Who To Follow". This feature presents you with a list of people you aren't following already, but who are active in your social graph. However, I happen to be very proactive in finding new people to follow through a variety of means, and have no need for Twitter to point it out to me. I thought it was a bit obnoxious to see, especially considering both of my first recommendations were people I had blocked.
This Safari extension removes that box from the Twitter homepage, whether you have it turned on for you or not. It's a simple CSS stylesheet that sets display:none on that box. You'll never have to see it again.
You can download it here. I'm still a bit new at Safari extensions, but it should auto-update in the future if I ever release an update.
Update 9/18/2010: Follow Freely 1.1 has been released, with support for the new Twitter web client. It also fixes the issue where Safari would constantly say there was an update available.
We've all got our thoughts on what the Jesus Tablet will be, so here are my guesses. I fully expect to be completely wrong on all of this, as many of these answers are completely blind shots and that Apple will blow my expectations out of the water.
- 8"-10" touch screen, running at 1280x720
- Very thin; less than 1/2" thick (the iPhone 3GS is 0.48" thick)
- About 1lb heavy, light enough to hold in one hand
- 8 hours of battery life
- 32 or 64 GB SSD
- 3G over GSM, and Apple's US 3G partner will continue to be AT&T
- There will be some way to pair your Tablet cell connection with your iPhone's cell connection; either with an official announcement of AT&T tethering, or by adding your Tablet to the 3G account
- Front-mounted camera
- Some kind of collapsible stand in the frame, so the device can sit on a table
- Multi-touch on the display, exactly like the iPhone
- Multi-touch on the back of the device, similar to the surface of the Magic Mouse
- Photos and video via front-mounted camera
- Audio via front-mounted microphone and speakers, wired headphones, or Bluetooth
- Dock connector
- Expanded voice recognition
- Software keyboard, no Bluetooth keyboards available
- It will run the iPhone OS 4.0; or rather, the iPhone OS will become a "Mobile OS X", consisting of the heavyweight Tablet and the smaller iPhone.
- It will allow multiple apps to run at the same time, with some UI for viewing multiple apps alongside each other. This may not be possible on the iPhone.
- It meant to replace a full PC for most common day-to-day needs
- iPhone applications will not run "automatically", but will need to be resubmitted through the App Store approval process. Most applications will run without much modifications. Icons will need to be higher resolution.
- A system-wide Dock for documents, applications, and small widgets will be onscreen at all times
- The home screen will be significantly revamped, and renamed to the Dashboard. App icons, web clippings, and widgets will be freely arrangeable.
- Handwriting recognition will be available for text input, with an optional stylus, or with a gesture such as two closed fingers drawing as if you had a pen.
- Some gestures will be used on the back of the device, such as scrolling and zooming.
- Standard kind of iPod and Internet communications apps the iPhone OS comes with. iTunes video, iTunes LP content, Maps, and Safari web content will look phenomenal.
- Sketchbook, an unlimited workspace to sketch and write notes, with collaboration features.
- iWork, a full port of the iWork application suite, tied to the Internet (and expansion of the iWork.com web application), with collaboration features.
- iChat, a port of the Mac app, with a heavy emphasis on video conferencing
- The SDK will be available immediately, with a simulator.
- There will be an emphasis on application interoperability.
- Applications will be able to register plugins with view controllers and UTIs. When an application wants to expose an object (say, an image) to other apps, it will look for app plugins which respond to the "public.image" UTI, load one which matches the UTI, and present the view without leaving the application.
- Applications will be able to expose services, similar to how they work on Mac OS X. Services will be integrated into the voice control system.
- 32 GB model will be available for $899
- 64 GB model will be available for $999
- Available in US in March, major countries by summer
- There will not be a WiFi-only model at launch.
- Updated MacBook Pros and MacBook Airs, with the mobile Core i5 "Arrandale" processors from Intel.
- There will be no mention of Verizon
- There will be no updates to the iPod or the Apple TV
- There will be no announcements of the iPhone 4G
URL Shrink is a new OS X tool with a very simple purpose - converting URLs to shorter permalinks on various web services. As the internet has matured, and services like IM, IRC, and Twitter have forced us to write shorter messages, it was clear that a system was needed that was as ubiquitous as Quicksilver.
For now, the main service of URL Shrink is just converting a URL that is on the clipboard, although this will be expanding over time (including things like a system text service, a command line client, a Quicksilver plugin, etc.). To do this, there is a keyboard shortcut (option-shift-space) which will convert the URL in the background to a tiny URL using one of the services provided. If you've selected one as your favorite, it'll choose that one. For example, I'm personally partial to is.gd, so all the URLs that are processed by URL Shrink on my machine go through is.gd.
At a low level, URL Shrink is a system where multiple shrinking engines can be added. It was designed to be extremely easy for developers to write just a little bit of code to integrate with other web services, including private URL services. For information on that, see the project page below.
URL Shrink is licensed under the BSD license. I encourage its adoption within other applications; I'll be adding .framework and .a targets for building this into Mac and iPhone apps respectively. Indeed, the project was born out of the URL shrinking capacity of another app I'm working on.