Update Misses: no cameras, no GPS, no stylus, no SD
If there is going to be an Apple Tablet there are a few features that I would like to see. These aren’t really predictions but more my limited view of how you might use such a device:
Hardware
Front and rear video camera for killer video conferencing and augmented reality applications
The standard WiFi, GPS, accelerometer and compass package with optional 3G/wimax connectivity
Support for all the typical touch gestures along with a stylus for writing
A low-power mode that is still suitable for reading documents
A dock suitable for both home plugged in use and on an airplane so you can watch video on it easily
At least 1080p resolution — any more than this is overkill
Some thought to how you would carry it around without destroying it
Smaller and lighter than a Macbook Air with a longer battery life — 8 hours?
Single USB port, Display Port and SD card slot
At least 64GB of local storage
Might as well be a conference room quality speakerphone as well
Software
Support for applications from the iPhone App Store along with new tablet applications
Strong integration with MobileMe for Back to my Mac, syncing and file sharing
Tablet versions of Mail.app, iWork, iLife and Dashboard
Air gestures that use the camera and voice commands for additional remote control
Broadcast whatever is on the tablet to another Mac or an AppleTV easily
Run up to 3 applications at the same time
A device with a bunch of features like that might be nice to have around the house, in meetings and on the road. Could even get some programming done as long as I have a home machine I can connect to as well.
Update 2: JRockit Real Time 3.1.2 using -XgcPrio:deterministic performed even better than this configuration in testing though it is not yet an approved VM at Yahoo! we will continue to test with it.
Update: One issue we still have is that after many hours of deployment with this configuration the heap fragments and we start to get concurrent mode failures. We only saw this though during periods of peak activity.
We were struggling with some long pause times due to GC for YQL that we couldn’t stomach for our internal property SLAs. The secret turned out to be a collection of parameters for the Java 6 garbage collector:
I have so far been blown away by the results of this combination of parameters. Not only does it work very efficiently under moderate load, under crushing load it rises the occasion and aggressively keeps down the heap in such a way as to never cause the:
Concurrent Mode Failure
The concurrent collector uses one or more garbage collector threads that run simultaneously with the
application threads with the goal of completing the collection of the tenured and permanent generations
before either becomes full. As described above, in normal operation, the concurrent collector does most
of its tracing and sweeping work with the application threads still running, so only brief pauses are seen
by the application threads. However, if the concurrent collector is unable to finish reclaiming the
unreachable objects before the tenured generation fills up, or if an allocation cannot be satisfied with
the available free space blocks in the tenured generation, then the application is paused and the
collection is completed with all the application threads stopped. The inability to complete a collection
concurrently is referred to as concurrent mode failure and indicates the need to adjust the concurrent
collector parameters.
If you have any other GC secrets for the JVM, leave them here. Just as a heads up I compared it with all the other GC’s available for Java 6 including the experimental G1 and none of them were as effective.
I’m basing this blog entry on this reference page. There are only a few different things that you need to do so I will spell those out cleanly relative to what was previously needed:
Grab the dependencies except for JIBX, it is no longer needed for the build.
With all the talk of geolocation in the browser, I decided this afternoon to go ahead and make it really easy for anyone to automatically update their location in FireEagle by going to a single url from any browser. Depending on the capabilities of your browser it will use various technologies to determine your current location:
One of the really cool features of MobileMe and the new iPhone 3.0 OS is the ability for it to reach out and locate your iPhone at any time if you have that feature enabled. Right now Apple only makes this available on their MobileMe website however and does not offer a programmatic way to get a hold of the information.
Since the iPhone doesn’t have background processes to update your location for third party applications I thought that it would be great to have the ability to do this anyway by leveraging their website. The first thing you need to do whenever you are going to scrape a sophisticated service like MobileMe is to collect all the relevant packets going over the wire. Since this service is entirely behind HTTPS the easiest way to do this is within the browser client itself. To that end I found what I believe to be the best Firefox plugin for the job, Tamper Data. Continue Reading »
As you know the original 4hoursearch was built using Yahoo! BOSS, YUI and Python running on Google App Engine. Although Google App Engine is a very productive environment I was unhappy with it for a few reasons. It doesn’t feel snappy enough, presumably because of the security enforcement aspects of the system, your code has to be written in Python which is not my favorite environment, and the last is that I was showcasing a great Yahoo! API by leveraging Google infrastructure. The last point is the least valid as Yahoo! doesn’t offer a truly equivalent environment but I think it will be more compelling as a showcase built entirely on Yahoo! technology. I could have moved it over to this new implementation when YQL launched but I also wanted to wait for BOSS to offer more features so I could significantly enrich the search experience at the same time. Continue Reading »
The Yahoo! Query Language aspires to be the last web service API that the normal developer will ever have to learn. By default we implement 50+ tables that grab data both from Yahoo! web services, some 3rd party web services and then the web at large using our dynamic tables that allow you specify a data type and a url. However, those dynamic APIs limit the YQL user to a very flexible but ultimately hard to work with API without the benefit of the structure found in the other tables that we offer.
Today YQL introduced a new feature that allows 3rd parties to define new tables and then share those table definitions with whomever they like for them to use. For example, let’s say you are the New York Times or you are a developer that likes the New York Times APIs and would like to make them more accessible to someone using YQL. Yesterday, they released the article search API, so I will use that one among others as an example, to get an api-key to execute these examples go to their developer site. This is a pretty sophisticated API that allows you to search using a variety of parameters. If you were to use YQL without modification, you would simply use the dynamic JSON endpoint to parse out the results from their service. The big issue with this though is that you would be unable to easily construct the URLs required and would have to write that code that collected all the parameters and created the URL. If you had a YQL table, those parameters would be defined and how they are expressed in the URL codified and you would be able to individually address the keys. Continue Reading »
One of the great things about the JAX-RS specification is that it is very extensible and adding new providers for different mime-types is very easy. One of the interesting binary protocols out there is Google Protocol Buffers. They are designed for high-performance systems and drastically reduce the amount of over-the-wire data and also the amount of CPU spent serializing and deserializing that data. There are other similar frameworks out there including Fast Infoset and Thrift. Extending JAX-RS to support those protocols is nearly identical so all of the ideas I’ll talk about are generally valid for those frameworks as well. The one limitation that we will table for now is that JAX-RS only works over HTTP and will not work for raw socket protocols and the high-performance aspect of protobufs is somewhat reduced by our dependency on the HTTP envelope. My assumption is that you have done your homework and know that message passing is your overriding bottleneck. Continue Reading »
You’ve probably read about things like Xoopit and Xobni for analyzing both online mail and your outlook mail. As it turns out, Apple has done something great in this regard that I think has been mostly overlooked. Mail.app stores all of the meta-data for you email in a file called ~/Library/Mail/Envelope Index. You might wonder what the format of this file is… well it is a SQLite3 database. The contents are pretty easy to see, go to the terminal and type:
macpro:~ sam$ sqlite3 ~/Library/Mail/Envelope\ Index
SQLite version 3.6.3
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>
Building applications for deployment to the web has evolved over the last several years to be focused on dynamic behavior, separation of model/view/controller, and simplified but scalable configuration and deployment. From a performance, tools and library perspective I’m still highly biased to development in Java over more up-and-coming languages. However, much has been learned in the Java community from the better frameworks like Rails and those lessons should not be ignored.
I’ve been looking for a while though to find that perfect combination of frameworks and libraries that would give me the expressive power that I want for building web applications. There have been many contenders from JRuby on Rails, to Grails, to Seam and even just writing everything myself. Ultimately, I believe in the DRY principle (like Rails), though I don’t think many frameworks go far enough when dealing with the database. When you are building a web application it is rare that you are going to change what database you are using. In fact, the majority of your scaling architecture is likely highly dependent on how you store your data. This is why I prefer an application framework that allows me to start with the database and construct my application’s data object model from it. Continue Reading »
