crazybob.org

The truth about Android & iOS UI performance

2011-12-10T12:45:00.001-08:00

Some fallacies related to Android vs. iOS UI performance made the rounds recently, inflicting undue damage to Android's reputation. It all started with a misinformed Google+ update written by former Android testing intern Andrew Munn.

Time reporter Matt Peckham echoed Andrew's misconceptions the following day, further spreading the FUD about Android. Toward the end of his article, Matt noted:

I’m not an Android or iOS software engineer, so all I can say in response to any of this is that, assuming Munn’s correctly articulated the way rendering takes places on Android and iOS devices, it makes sense (but then so does the idea that Lee Harvey Oswald had help, at least to some people).

Peckham makes no mention of trying to corroborate Munn's claims with a more experienced, knowledgeable engineer, like Romain or Dianne from the Android team, nor does he reference the corrections made by iOS experts in the comments on Munn's post. A more qualified engineer would support their theories with evidence like code, specifications, and performance test results, not Reddit and Hacker News comments as Munn did.

I don't claim to have all the answers, but I can tell you that implementing fluid interfaces on both iOS and Android is time consuming and difficult. The challenges are an order of magnitude more complex than Munn suggests. I haven't had an opportunity to try Ice Cream Sandwich yet, so I can't tell you firsthand how it compares to the iPhone. However, Jason Kincaid, quoted by Munn, described ICS as quite smooth and noted that both Android and iOS stutter occasionally.

Now that Android has pervasive hardware acceleration, Android has no fundamental technical disadvantage compared to iOS with regard to to implementing fluid UIs. Given comparable hardware, any UI that runs smoothly on iOS should be able to run just as smoothly on Android. That said, hardware acceleration isn't a magic switch that you can just turn on. Android developers need to modify their applications to take full advantage, just like iOS developers have to design their own applications with hardware acceleration in mind. This will take time.

To Munn's point, "UI thread" and "main thread" mean the same thing. Most user interface frameworks, including those employed by iOS and Android, have a notion of receiving input events and manipulating the user interface from a single thread. Users of those frameworks often use the terms "UI thread" and "main thread" interchangeably. Why impose this restriction? If you limit access to UI elements to a single thread, you simplify API usage and improve performance because you don't have to deal with locks and concurrency. Contrary to Munn's claims, Android does actually assign a higher scheduling priority to the UI thread than it does to background threads. I assume iOS does likewise.

Android and iOS are more alike than different in this respect. Either platform will hang and stop responding to user input if you monopolize the main thread with blocking operations (like file I/O) or slow drawing logic. This likely explains why Jason experiences jitters when visiting global search on iOS. On both platforms, programmers should perform all blocking operations on background threads and should never block the main thread.

As for the differences, iOS's Core Animation framework tweens animations in a background thread while Android does the same in the main thread. On iOS animations continue running, even when the application accidentally blocks the main thread. In addition, when scrolling, iOS's main thread goes into a "tracking" mode where it filters out certain types of events that might result in redrawing or other performance degradations. This has no affect on background operations. Nothing technically prevents Android from supporting these features, but their absence doesn't preclude smooth UIs on Android either. Hardware acceleration is far more important.

Does this mean we're going to start seeing iOS-quality user interfaces across the board on Android in the near future? No way. The reasons have little to nothing to do with bytecode or garbage collectors and everything to do with the community and tools. First, iOS app developers have far more experience taking advantage of hardware acceleration. They're experts in going out of the way to avoid software rendering. Hardware rendering requires a different mindset, and Android programmers will need time to catch up.

Second, Android programmers need to support both software and hardware rendering for awhile. This requires more code. Some Android devices support only software rendering while others, like the Xoom, actually require hardware rendering to achieve any semblance of smooth animation. Developing and maintaining smooth Android apps will require significantly more developer resources than accomplishing the same on iOS, at least until we can retire support for pre-Honeycomb devices. Programmers with limited resource will no doubt have to elide animations and settle for lowest common denominator solutions for awhile.

Third, from what I've seen, iOS developers have far better tools at their disposal. iOS developers can tweak and reload their applications in seconds, faster than you can reload a Ruby on Rails web page, while Android developers are lucky to do the same in tens of seconds. Being able to quickly iterate and tweak a UI is essential to achieving pixel-perfect, high frame rate animations. If Android programmers need to wait up to a minute after each tweak, they'll be at a significant disadvantage compared to their iOS counterparts. iOS provides amazing tools that overlay their UIs and help pinpoint and eliminate software rendering. In contrast, the UI performance and bugs in Android's emulator are so bad that developers resort to running on real devices only, even during development.

Android's training and legacy support issues will resolve themselves eventually. If I ran the Android team, I'd triple down on tool support. Android's emulator sounds great in theory, but it fails spectacularly in practice. Professional Android programmers simply can't and don't use it. Frankly, the emulation model is a lost cause. Android should replace it with an iOS-like simulator, one with tightly integrated profiling tools, capable of building and displaying apps in seconds. Ideally, the development build process would further cut down the turnaround time by eliding resource compilation, dex conversion, etc.

In the meantime, Android developers can achieve buttery user interfaces on Honeycomb and ICS devices, just like their iOS equivalents, by eliminating blocking operations from the main thread, minimizing time spent drawing in software, and allocating objects judiciously. Android programmers just have to work a little longer and harder to get there. Given our fierce dedication to a flawless user experience, my team plans to invest the necessary resources and accomplish just that. If you think you're up to the challenge, please apply.

For additional reading, Dianne has done a wonderful job explaining why the Android team made the choices they did and how those choices enabled some unique advantages over iOS.

Coding Challenge: The Luhny Bin

2011-11-15T18:12:00.000-08:00

Note: This is cross posted from Square's engineering blog. Please submit comments over there.

“To err is human; to forgive, divine.” -Alexander Pope

Mistakes happen. At Square, we accept that human error is inevitable. We anticipate potential slip-ups and implement safety measures to mitigate—and oftentimes completely eliminate—any repercussions.

For example, Square’s Luhn filter monitors logs and masks anything that looks like a credit card number. If a number like “4111 1111 1111 1111” were accidentally logged as part of an error message, our filter would replace it with “XXXX XXXX XXXX XXXX” and page an on call engineer.

The Luhn filter looks for sequences of digits that pass the Luhn check, a simple checksum algorithm invented by Hans Peter Luhn in 1954. All valid credit card numbers pass the Luhn check, thereby enabling computer programs, like our log filter, to distinguish credit card numbers from random digit sequences.

The Luhn check works like this:

Starting from the rightmost digit and working left, double every second digit.
If a product has two digits, treat the digits independently.
Sum each individual digit, including the non-doubled digits.
Divide the result by 10.
If the remainder is 0, the number passed the Luhn check.

For example, “5678” passes the Luhn check:

Double every other digit: 10, 6, 14, 8
Sum the individual digits: (1 + 0) + 6 + (1 + 4) + 8 = 20
Divide the result by 10: 20 mod 10 = 0 Pass

“6789” does not:

Double every other digit: 12, 7, 16, 9
Sum the individual digits: (1 + 2) + 7 + (1 + 6) + 9 = 26
Divide the result by 10: 26 mod 10 != 0 Fail

Now for the challenge…

Write a command line program that reads ASCII text from standard input, masks sequences of digits that look like credit card numbers, and writes the filtered text to standard output. For the purposes of this challenge, a credit card number:

Consists of digits, spaces (' ') and hyphens ('-').
Has between 14 and 16 digits, inclusive.
Passes the Luhn check.

If a sequence of digits looks like a credit card number, replace each digit with an 'X'. Any characters, including digits, may flank a credit card number. Beware. Potential credit card numbers can overlap. A valid 16-digit number can even contain a valid 14 or 15-digit number. Your program must mask every digit.

I already wrote a test suite, so you can jump straight to the fun part: writing the algorithm. To participate:

Fork the Luhny Bin GitHub repo.
Modify mask.sh to call your program.
Test your program by executing run.sh.
Once run.sh passes, post a link to your solution in the comments below.

Windows users should use Cygwin to run the tests. Please make it easy for others to check out and run your solution.

The first time you execute run.sh, you’ll see a test failure:

$ ./run.sh 
Running tests against mask.sh...

.X

Test #2 of 20 failed:
  Description:     valid 14-digit #
  Input:           56613959932537\n
  Expected result: XXXXXXXXXXXXXX\n
  Actual result:   56613959932537\n

Modify mask.sh and make the tests pass. Line feeds delineate the test cases. If you pass a number on the command line, run.sh will repeat the test suite the specified number of times; this is useful for performance comparisons. The tests aren’t set in stone—if you have an idea for improving the test suite, please submit a pull request.

This isn’t a contest, but an innovative solution could score you interviews at Square. I’m primarily interested to see how different programming languages stack up with regard to readability and performance.

Once we have enough interesting submissions, I’ll summarize the results in a followup blog post and open source our own Java-based implementation. In the mean time, if you enjoy working with talented people on challenging problems like this, email your résumé to luhnybin@squareup.com.

Good luck!

Java SE 7 & 8

2010-11-16T22:56:00.000-08:00

Sometimes doing the right thing can be extremely difficult. In spite of and because of my commitment to Java, I had to decline an invitation to join the Java SE 7 and 8 expert groups. Talk about a tough decision!

Why did I decline? I'll contribute to open source projects and open standards, standards I can independently implement and license as open source. Java SE, with its anti-competitive licensing restrictions, is not an open standard. It doesn't belong in the thus far open JCP, and I can't support such a charade. I stand by Apache, and I hope Eclipse comes around.

I'm not a lawyer, but I can't help but wonder whether Oracle even has a right to apply additional licensing restrictions to the intellectual property in Java SE. Oracle didn't create Java SE on their own. Look at the list of JSRs pulled into Java SE 7 and SE 8 (see the Contributions sections). Look at the experts on those JSRs. Most of them aren't from Oracle. For example, JSR 310: Date and Time API comes from our own Stephen Colebourne.

The JSPA section 4.D protects experts in these situations, enabling them to withdraw their IP contributions if a spec lead, Oracle in the case of Java SE, changes the licensing terms:

Withdrawal of Contributions due to Change in Announced License Terms. If the Spec Lead for an Expert Group in which You are participating makes significant changes to the terms and conditions of any license granted pursuant to Sections 5.B or 5.F below after those terms and conditions are first disclosed pursuant to the Process, then You may, upon giving notice to the Specification Lead and the PMO, withdraw any copyright or patent licenses concerning Your Contributions granted pursuant to Section 4.A.I or 4.A.II above (but not patent licenses granted by You pursuant to Section 6 below).

It's not clear to me exactly how section 4.D applies to umbrella JSRs like Java SE, but I'd say that changes preventing independent open source implementations qualify as a "significant."

GOTJCPECV (Get Out The JCP EC Vote)

2010-11-01T11:52:00.000-07:00

Today is the last day to vote in the JCP EC election. If you're a JCP member, you received voting instructions in an email from pmo@jcp.org with the subject line JCP Elections 2010 end November 1! This email contains the link and your password.

Note: The password is different from your jcp.org password.

If you voted already, thank you. Please help me spread the word through blogs, tweets, Facebook, etc.

Square Snare

2010-10-21T07:09:00.000-07:00

My dad makes and sells keychains for Square readers. He attaches a keyring to a 3.5mm jack. Make your own or order one pre-made for $5:

Long Live Java

2010-10-20T11:54:00.000-07:00

The JCP EC elections opened today, and I'm running.

After Doug Lea's resignation and subsequent replacement with Hologic, Inc., maintaining individual representation is more important than ever to Java's future. Individuals stand to account for only 13% of the SE/EE EC. Please vote for me and hold the ground for non-corporate interests.

Voting

If you're a JCP member, you received voting instructions in an email from pmo@jcp.org with the subject line "JCP Elections 2010: vote today." The email contains a link and a password. If you have any problems, email admin@jcp.org or call 1-866-543-8750 (US or Canada) or 1-202-207-0529 (International).

Why vote for me?

You're no doubt aware that a bargaining impasse between Apache and Sun/Oracle has virtually halted progress within the JCP over the past five years. Openness of Java SE is critical in the fight against its real competition: .NET, V8, Erlang, Flash, et al. I'll do everything I can to ensure an open future for Java, but we can't let one JSR grind the JCP to a halt. Life must go on.

Just last year, in the midst of this kerfuffle, I led the fastest-executing, most open JSR in the history of the JCP:

If you blinked, you might have missed it. JSR 330, Dependency Injection for Java, completed the shortest development cycle of any Java Specification Request on record within the Java Community Process (JCP) program, a feat that looked only theoretically imaginable on paper until Bob Lee proved it could be done. As co-Spec Lead of JSR 330, Bob wasn't focusing specifically on agility when he pushed the envelope. "While I'm glad JSR 330 executed quickly, I'm even prouder of our specification's quality. I think we raised the bar," he says.
How is it possible to achieve both speed and superiority? Doesn't something have to give? In fact, Bob gave a lot to make this happen, and other Spec Leads can learn a lot by retracing his steps. He attributes the short execution time and enhanced quality to a number of factors, including a crack team of Experts, an aggressive schedule that hacked the normal process, transparency, limited scope, and a willingness to collaborate, compromise, question assumptions, and think outside the box.

If you elect me...

I'll continue this record of innovation and pave the way for more JSRs like 330. I'll introduce an abbreviated process for Open JSRs. JSRs that meet our criteria for openness will be able to follow an easier, faster, simpler specification process. This process will motivate more open JSRs. It will free spec leads up to focus more on the technology and less on the process. It will attract more experts to the JCP and ensure a bright future for Java.

Thank you,
Bob Lee

Android: Trusting SSL certificates

2010-02-05T09:17:00.000-08:00

We use a self-signed SSL certificate for the test version of our backend web service. Since our certificate isn't signed by a CA that Android trusts by default, we need to add our server's public certificate to our Android app's trusted store.

These same instructions apply to trusting a custom CA, except you'd get the public certificate directly from the CA instead of from a server.

Required tools:

OpenSSL's command line client
Java SE 6 (for keytool)
Bouncy Castle's provider jar

1. Grab the public certificate from the server you want to trust. Replace ${MY_SERVER} with your server's address.

echo | openssl s_client -connect ${MY_SERVER}:443 2>&1 | \
 sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > mycert.pem

For example, here's the PEM-encoded public certificate from google.com:

2. Android has built-in support for the Bouncy Castle keystore format (BKS). Put Bouncy Castle's jar in your classpath, and create a keystore containing only your trusted key.

export CLASSPATH=bcprov-jdk16-145.jar
CERTSTORE=res/raw/mystore.bks
if [ -a $CERTSTORE ]; then
    rm $CERTSTORE || exit 1
fi
keytool \
      -import \
      -v \
      -trustcacerts \
      -alias 0 \
      -file <(openssl x509 -in mycert.pem) \
      -keystore $CERTSTORE \
      -storetype BKS \
      -provider org.bouncycastle.jce.provider.BouncyCastleProvider \
      -providerpath /usr/share/java/bcprov.jar \
      -storepass ez24get

3. Create a custom Apache HttpClient that uses your custom store for HTTPS connections.

import android.content.Context;
import org.apache.http.conn.ClientConnectionManager;
import org.apache.http.conn.scheme.PlainSocketFactory;
import org.apache.http.conn.scheme.Scheme;
import org.apache.http.conn.scheme.SchemeRegistry;
import org.apache.http.conn.ssl.SSLSocketFactory;
import org.apache.http.impl.client.DefaultHttpClient;
import org.apache.http.impl.conn.SingleClientConnManager;

import java.io.InputStream;
import java.security.KeyStore;

public class MyHttpClient extends DefaultHttpClient {

  final Context context;

  public MyHttpClient(Context context) {
    this.context = context;
  }

  @Override protected ClientConnectionManager createClientConnectionManager() {
    SchemeRegistry registry = new SchemeRegistry();
    registry.register(
        new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));
    registry.register(new Scheme("https", newSslSocketFactory(), 443));
    return new SingleClientConnManager(getParams(), registry);
  }

  private SSLSocketFactory newSslSocketFactory() {
    try {
      KeyStore trusted = KeyStore.getInstance("BKS");
      InputStream in = context.getResources().openRawResource(R.raw.mystore);
      try {
        trusted.load(in, "ez24get".toCharArray());
      } finally {
        in.close();
      }
      return new SSLSocketFactory(trusted);
    } catch (Exception e) {
      throw new AssertionError(e);
    }
  }
}

That's it! If you think this kind of stuff is fun, Square is hiring.

Tomorrow is the big day.

2009-08-14T14:36:00.000-07:00

Friends,

Tomorrow morning, I'll swim 1.5 miles from Alcatraz to SF to benefit the American Liver Foundation. I set my fund raising goal at $10k, and I'm already 30% of the way there. If you've already donated, thank you! If not, please sponsor me.

Thanks,
Bob

It's in the JCP's hands now.

2009-05-20T17:13:00.000-07:00

This morning, Google and SpringSource submitted an updated version of the aforementioned @Inject proposal to the JCP. In response to popular demand, we expanded the proposal's scope to include a low-level build-time and run-time configuration API. You might think of the new API as a type-safe analogue to JNDI and @Resource. Having a central integration point for DI configuration means you can use multiple configuration approaches in a single application without suffering from the-chicken-or-the-egg problem; anyone who has tried to use more than one DI framework in the same application knows that deciding which framework to initialize first can be problematic to say the least.

Our goals are to enable portable applications and to spark further innovation in the DI configuration space. By making it easier to use multiple configuration approaches with the same tools and in the same application, we lower the barriers to entry and adoption for new approaches.

We've added the following paragraphs to the JSR proposal's introduction:

A programmer configures a dependency injector so it knows what to inject. Different configuration approaches make sense in different contexts. One approach is to search the classpath for dependency implementations, avoiding the need for the programmer to write explicit code. This approach could be useful in quick-and-dirty prototypes. A programmer working on a large, long-lived application might prefer a more explicit, compartmentalized approach. For example, the programmer could write XML that tells the injector to inject an EJB client proxy named "NetworkTimeSource" when a class needs a TimeSource:
  <binding type="TimeSource" ejb="NetworkTimeSource"/>
It often makes sense to use more than one configuration mechanism in the the same application. For example, a quick and dirty prototype might grow into a real application, and the programmer could incrementally migrate to a more maintainable configuration. As another example, a program might configure some resources explicitly, while others are configured automatically based on an external XML file or database.
This JSR will standardize a low-level kernel API that can be used directly by a user or as an integration point for higher level configuration approaches. This approach enables portable Java applications without quashing innovation in dependency injector configuration.

We've rewritten the scope:

This JSR will standardize:
A set of annotations for use on injectable classes
A typesafe, user-friendly injector configuration API that provides an integration point for higher level dependency injection configuration approaches

And we've adjusted the time line and other parameters accordingly. Check out the full proposal.

What will the new API look like? That's for the expert group to decide, and they'll do so in an open and inclusive manner. In addition to Guice and Spring, this proposal already has support from the PicoContainer, Plexus and Tapestry IoC teams, not to mention prominent users like Tim Peierls and James Strachan, and well known API designers like Doug Lea and Josh Bloch. We'll have no shortage of expertise when it comes time to assemble the group.

Guice 2 already provides a great foundation for extensions and tools. The Guice team is excited to start with a clean slate and apply the lessons we've learned over the past few years. This time around, we'll be able to work with the platform instead of around it. As a member of the JSR-294 expert group, I'm eager to align our dependency injection efforts with the module support coming in Java 7. JSR-294 modules will enable sharing types, and this proposed JSR will build on that foundation and enable sharing instances.

Guice²

2009-05-19T19:21:00.000-07:00

After two years in the making, it's official. We've released Guice 2! Here's Jesse's announcement from the Google Code Blog:

Two years ago, Bob Lee and Kevin Bourrillion open sourced Google Guice 1.0, a lightweight Java dependency injection framework. Guice takes the pain out of writing and maintaining Java applications big and small. Guice has gained a great deal of traction both inside and outside of Google. Almost every Java-based application at Google is also a Guice-based application; the list includes AdWords, Google Docs, Gmail, and even YouTube. Open source users run Guice in everything from file-sharing software to ATMs. They've even written two books about this Jolt-award-winning framework.

Today, we're releasing Guice 2. The minimally-sized API extensions introduced by Guice 2 will have a majorly positive impact on the size and maintainability of your code. We closely scrutinized each addition, carefully balancing maintainability and flexibility. Here are a few of my favorite new features:
Provider methods eliminate the boilerplate of manually-constructed dependencies.
Module overrides allow you to tweak a production module for a unit test or QA deployment.
Private modules enable compartmentalized configuration, simplifying module reuse.
Guice works with Java SE, Java EE, Google App Engine, Android, and even Google Web Toolkit (via GIN).

References
Guice 2.0 Release Notes
Downloads
User's Guide
Javadoc

By Jesse Wilson, Google Developer Team

In addition to the user-facing features mentioned by Jesse, Guice 2 provides an extensive service provider API that enables first class extensions like James Strachan's GuiceyFruit and makes writing tools like Guice Grapher a snap.

Thanks, Jesse, for all of your hard work on this release. Special thanks goes to our users for being patient and building a vibrant community around Guice.

If you're interested in learning more, don't miss Jesse and Dhanji's Guice 2 talks at Google I/O and JavaOne.

Announcing @javax.inject.Inject

2009-05-05T10:34:00.000-07:00

I'm proud to announce a new dependency injection specification backed by both Google Guice and Spring. You can catch the official announcement over on the Google Code Blog:

Five years ago, Spring 1.0 brought Java dependency injection into the mainstream. Three years later, Google Guice 1.0 introduced annotation-based dependency injection and made Java programming a little easier. Since then, developers have had to choose between a) writing external configuration or b) importing vendor-specific annotations.
Today, we hope to give developers the best of both worlds. Google Guice and SpringSource have partnered to standardize a proven, non-controversial set of annotations that make injectable classes portable across frameworks. At the moment, the set of specified annotations consists of:
@Inject - Identifies injectable constructors, methods, and fields
@Qualifier - Identifies qualifier annotations
@Scope - Identifies scope annotations
@Named - String-based qualifier
@Singleton - Identifies a type that the injector only instantiates once
One additional interface is specified for use in conjunction with these annotations:
Provider - Provides instances of a type T. For any type T that can be injected, you can also inject Provider.
You can check out an early draft of the specification. We deliberately left external dependency configuration out, so as not to quash ongoing innovation. We haven't formally submitted this standard to the JCP yet, but we plan to do so shortly. Standards wonks can read a draft of our JSR proposal.
The expert group will be inclusive and will work in the open. For example, our mailing list is publicly readable, and we host the specification at Google Code. Several industry players have already expressed interest in supporting this effort. Contact us if you'd like to help out.

This specification will address the last shortcoming of annotation-based dependency injection. You no longer have to import vendor-specific annotations.

Our hope is that this specification will not only improve interoperability between existing dependency injection frameworks and unify the Java community, but it will also lower the barrier to entry for new injector implementations and foster even more innovation in this space.

I'd like to thank Paul Hammant, Doug Lea, Tim Peierls, James Strachan, Hani Suleiman, and Jason van Zyl for their early reviews and official support. Special thanks goes to our partner in this endeavor SpringSource, especially Rod Johnson, and my fellow Googlers and Guicers Josh Bloch, Jesse Wilson, Kevin Bourrillion, and Dhanji Prasanna.

How to create simple Amazon affiliate links

2008-10-13T11:03:00.000-07:00

In case you didn't know, Amazon will pay you to recommend their products. If you're going to link to a product anyway, why not take credit? Amazon provides all sorts of fancy tools and flashy widgets to help you advertise their products, but creating a basic URL through their web interface isn't straightforward.

In hope of simplifying the process, I followed some 3rd party instructions I found for hacking together your own referral URLs, but they didn't work. I asked Amazon instead, and here are the official instructions:

If you would like to link directly to an item's detail page using a simple text link, use the following format to construct your links:
http://www.amazon.com/dp/ASIN/?tag=your_Associates_ID
To make this link functional, replace "ASIN" with the 10-digit ISBN or ASIN of the product, and replace "your_Associates_ID" with your Associates ID or tracking ID. However, you would not be able to link to a search results page on Amazon.com.
If you would like to link to the Amazon.com homepage, you can use the following format:
http://www.amazon.com/?tag=your_Associates_ID
To make this link functional, replace "your_Associates_ID" with your Associates ID or tracking ID.
An item's ISBN/ASIN is listed on the item's detail page. For example, follow the link below, and then scroll down to the section labeled Product Details to find the ISBN (0439434866) for "Harry Potter Paperback Boxed Set."
http://www.amazon.com/exec/obidos/tg/detail/-/0439434866/

I don't make much money from referrals, but I do enjoy taking my payments in the form of Amazon gift certificates and buying myself a little something from my wish list every now and then.

Taken with my 'gPhone'

2008-09-22T17:37:00.000-07:00

I've been playing around with the 3 megapixel camera on my Android-based G1. Like any phone camera, you need a little diligence, a lot of light, and a steady hand.

For the best results, tap and release the shutter button, and then hold the phone still until it takes the picture a second or so later. It's not necessary to hold down the button until the picture takes. Holding down the button will contract the muscles in your hand and make it more difficult to keep the phone steady.

Click here for more photos.

Greeting Grammar

2008-07-12T10:28:00.000-07:00

I've noticed that most people start off emails with "Hi Bob,". I suspect they're treating "hi" as a less endearing replacement for "dear" in "Dear Bob,". Technically, "dear" is an adjective describing "Bob" while "hi" stands on its own and is not part of the direct address. I prefer the more correct salutation: "Hi, Bob."

Who is the most grammatically correct social network? Facebook, Plaxo Pulse, and Flickr get this wrong, by my standards, in their automated emails. Twitter gets it right.

Expert Guice

2008-06-26T10:42:00.000-07:00

Stephan just posted video of a talk I gave at Javapolis back in December: Expert Guice: 50 some odd ways to Guice up your Java

Update: Stephan fixed the audio levels so you should be able to hear me now. :-)

Guice @ Google I/O

2008-05-28T07:23:00.000-07:00

Jesse and I are presenting Guice 101 at Google I/O, 11:15 this morning:

Guice (pronounced 'juice') is a Jolt award-winnning, lightweight dependency injection framework for Java 5 and above. Put simply, Guice alleviates the need for factories and the use of new in your Java code. Think of Guice's @Inject as the new new. You will still need to write factories in some cases, but your code will not depend directly on them. Your code will be easier to change, unit test and reuse in other contexts.

Teyana Taylor - "Google Me"

2008-05-04T12:07:00.000-07:00

Going to JavaOne? Sign up for Twitter.

2008-05-01T17:42:00.000-07:00

If you already twitter, feel free to skip to the next section. If you've never heard of Twitter, read on and keep your finger on the pulse of JavaOne.

With Twitter, you can broadcast short status updates to your followers and receive updates from people who you follow. It's like having one big instant messaging conversation with all of your friends.

You can access Twitter via SMS. During JavaOne, you can easily keep tabs on your fellow attendees as well as let them know what you're up to, all from just about any cell phone (standard text messaging rates apply).

For example, if you follow me, and I text "free beer at Guice BoF!" to Twitter, Twitter will forward the message on to your phone.

Note: In addition to following someone, you must also enable "device updates" for that person in order to receive their updates via text and instant message.

If you don't have unlimited text messaging, you can always access Twitter via the web or one of the zillion 3rd party Twitter applications.

#javaone

The Twitter world utilizes an ad hoc tagging system called hashtags. It's simple. Tag your JavaOne-related messages by appending "#javaone" to them, and I'll be able to see your update even if I'm not following you yet.

Simply text "track javaone" to Twitter in order to receive any message containing the word javaone from anyone on Twitter, or search for "#javaone" on Summize, a real time Twitter search engine.

Follow Me

I plan to twitter throughout JavaOne. In addition to following me, also check out these Java twitterers:

JavaOne - The conference itself
Dan Diephouse - Mule
Ted Leung - Jython
Sam Pullara - Yahoo, ex BEA, Gauntlet founder
Dick Wall - The Java Posse
Robert Cooper - Author of GWT in Practice
Roberto Chinnici - Java EE 6 spec. lead
Dave Johnson - Blogging Roller
Dion Almaer - Google code evangelist and founder of Ajaxian.com
Geert Bevin - RIFE, Terracotta
Mary Smaragdis - Sun marketing director
Gregor Hohpe - Google, enterprise messaging patterns
Van Riper - Silicon Valley JUG
Bob McWhirter - JBoss
Patrick Chanezon - Google API evangelist
Mike Cannon-Brookes - Atlassian founder
Charles Miller - Confluence lead
Cameron Purdy - Tangosol founder
Rob Misek - Coherence sales dude
Mike Loukides - Java editor for O'Reilly
Alexandru Popescu - InfoQ co-founder
Kjetil Paulsen - JavaZone
Stuart Halloway - Relevance, Inc.
Mark Reinhold - Chief Engineer, Java SE
James Strachan - Groovy, ActiveMQ, Latrz, etc.
Kevin Bourrillion - Guice, Google Collections
Neal Gafter - javac, closures
Dhanji Prasanna - Warp, author of Manning's Dependency Injection
Jesse Wilson - Glazed Lists, Guice
Alex Miller - Terracotta
Eugene Kuleshov - ASM, Terracotta
Emmanuel Bernard - Hibernate
Jason Carreira - WebWork
Guillaume Laforge - Groovy, Grails
Sun Developer Network @ JavaOne
Frank Wierzbicki - Jython
Charles Nutter - JRuby
Michael Galpin - eBay
Jesse Kuhnert - Tapestry
Jevgeni Kabanov - JavaRebel
Sam Charrington - Appistry

If you'll be twittering from JavaOne and I didn't mention you above, link to your profile from the comments so others can find you.

Finally, please spread the word about this post and twittering at JavaOne in general. The more people who Twitter from JavaOne, the more fun we'll have!

The Twubble with Twitter

2008-04-17T14:40:00.000-07:00

Dion Almaer interviewed me about Twubble for the Google Developer Podcast:

If you use Twitter, Twubble can look at your existing friends' friends and recommend new people for you to follow. It's a stupid simple idea, but I think the execution and fun factor have won people over.

I wrote Twubble in a couple nights of hacking in bed after the kid went to sleep. I used the latest Google Web Toolkit milestone which supports Java 5 (flawlessly from my experience). I was writing Javascript code (server and client side) for years before I ever got into Java, but I have to say, you'd be crazy to write AJAX apps any other way than GWT nowadays.

Statically Typed Foreword

2008-03-11T13:03:00.000-07:00

Robbie asked me to write a foreword for his upcoming Guice book. Having never written a foreword before, I Googled, "how to write a foreword," which brought me to two helpful posts from Muse Ink: Foreword Thinking and Foreword March.

Here's what I came up with:

I created Guice in the midst of one of the biggest projects of my career. When you have hundreds of engineers touching millions of lines of code, you come to appreciate the benefits of static type checking. Static types aren't just about compiler errors. In fact, I rarely see Java compiler errors nowadays. Thanks to all that great, formalized Java type information, my IDE helps me write correct code in the first place.

Writing your application in a nearly 100 percent type safe manner, like Guice enables and Robbie advocates in this book, opens the door to a new level of maintainability. You can effortlessly navigate unfamiliar code, jumping from interfaces to their implementation and from methods to their callers. As you master your Java tools, you realize that deceptively simple atomic refactorings combine to form molecular tools, which you can reliably apply to companywide swaths of code, accomplishing refactorings you'd never even consider trying by hand. In the long run, it's much cheaper to ward off bit rot through heavy reuse and constant refactoring than by nuking the world with a rewrite every couple years.

Having experienced Guice's benefits on a number of projects, we at Google knew we couldn't keep it to ourselves and decided to make it open source. Readying Guice for the outside world felt like it took an order of magnitude more work than writing that first internal version, but community contributors like Robbie who fuel the forums, help polish rough edges, and generate excellent documentation like this book pay back that effort tenfold. You'll find that Robbie's brevity and conversational tone suit Guice well. I like my books like I like my APIs: with high power-to-weight ratios.

I focused on static typing because I've gotten a lot of questions about it lately. There's a lot of misinformation out there. For example, some people incorrectly conflate static typing with compiler errors, and, based on that false foundation, they claim that unit testing is an adequate substitute for static typing.

Static typing and unit tests are orthogonal. Static typing doesn't replace unit tests. Unit tests don't replace static typing. In fact, static typing can make maintaining unit tests much easier, especially when paired with the right mocking framework. I certainly believe that scripting languages have their place; beware anyone who tells you that static typing doesn't.

Thanks for the Jolt!

2008-03-10T11:23:00.000-07:00

Guice took home the Jolt, a.k.a. the geek Oscar, at an award ceremony hosted by Bob Cringely during SDWest:

The Jolt Awards recognize those products, books, and websites that have "jolted" the industry in the past year. Winners are selected by a panel of judges consisting of industry insiders, columnists, and technology leaders.

I started reading Dr. Dobb's Journal back when I was 12. I regularly bought it off the newsstand at Oxford books in Atlanta and was lucky to understand one article in the entire magazine. I learned much of what I know by reading instead of going to college, so DDJ has been an invaluable resource for me. I remember greatly admiring the Jolt winners each year. I hardly imagined myself among them, especially so soon.

The judges picked three productivity winners and one overall Jolt winner from a pool of six finalists in each category. Guice had some stiff competition; other finalists in the Libraries, Frameworks and Components category included the Eclipse Modeling Project, JasperReports, Qt Jambi, the Spring Framework, and the Zend Framework. Congratulations to the productivity winners: Eclipse, Zend and JasperReports.

Kevin and I had the pleasure of accepting the award on stage, but the truth is, Guice 1.0 is heavily indebted to a lot of people. I can't name you all, but I would like to thank:

My wife Krista and daughter Dagny for their support
The Jolt judges for recognizing our hard work
Kevin Thompson, our manager at the time who gave me the latitude to work on Guice full time
My mentors Josh Bloch and Neal Gafter
Cedric and Hani for their treatment of Guice in Next Generation Testing
The early adopters and contributers who helped steer Guice to 1.0, in random order: Jesse Wilson, Zorzella, Laura Werner, Peter Epstein, Don Brown (Struts 2), Cliff Biffle, Arthur Gleckler
Brian Slesinsky, for his apt analogies, Eric Burke, for his cartoons, and all the other bloggers who helped popularize Guice
Robbie for writing a Guice book
Dhanji for writing a Guice book, and integrating Guice with Hibernate and JPA in Warp Persist
My parents for instilling a strong sense of type safety at an early age (Thanks for the reminder, kebernet.)

And finally, I'd like to thank Google for its unparalleled commitment to open source. If you haven't tried Guice yet, now is the time.

The trouble with Twitter is...

2008-01-30T07:28:00.001-08:00

When it's down, the first thing you want to do is Twitter about it being down. I originally wanted to tell Duncan Davidson how much I love his site design. I'm sure it's been that way for awhile, but I normally only see his RSS feed.

I'm also thinking about picking up the second edition of the Dragon Book. I want to learn more about language design and compilers. I know the Dragon Book has it's shortcomings, but I love that the new edition covers JIT compiling and garbage collection, and I'm really just looking for a foundation, not a definitive reference. I can catch up on the latest and greatest via the ACM.

I guess it would have been hard to fit that into 140 characters anyway.

Update: After reading the Amazon customer reviews, I bought Programming Language Pragmatics instead.

In the hot seat

2008-01-22T18:23:00.000-08:00

I sat down for an interview with Carl Quinn during Javapolis, and the video is now up on parleys.com. You can also find an audio-only podcast version on the Java Posse's web site. In it, we talk frankly about:

The history of and philosophy behind Guice, what problems it solves, how we implemented it, the secret sauce in Guice's stellar performance, and how Guice compares to other approaches.
How we in the Java community need to take a step back and rethink API and framework design after Java 5 and 6. Reflection heavy and convention based Java 1.4 designs won't fly for much longer. Readability doesn't necesarily mean fewer characters. Java 5 made static type safety a reality and introduced explicit meta data. Java 6 lowered the barriers to compile time code generation, but good documentation of these new features is still much needed.
The future of Guice and dependency injection in general. I'd like to see dependency injection on mobile devices and deeply integrated into Java SE. One day, many of the problems we're solving in a separate framework will be addressed seamlessly by the core platform, and we'll be free of integration headaches and able to focus on higher level abstractions all around.
Google Collections, an excellent open source project led by Guice co-lead Kevin Bourrillion. Check it out if you haven't already. Kevin and the rest of the team try to hold the Google Collections to the same standards as the core Java SE Collections, and it shows.
Weak vs. soft references, which you should use, and specifically when not to use soft references.

Thanks again goes to Carl and Stephan and the rest of the BeJUG team. Javapolis was one of the most fun, inspiring, community-oriented conferences I've been to in a long time. Getting back and forth between your hotel and the conference was a little tricky at times, but the venue itself absolutely rocked.

Guice @ Javapolis

2007-12-07T10:42:00.000-08:00

I'm speaking about Guice first thing on Wednesday and JSR 299 Web Beans on Thursday. How should I approach my Guice talk? We already have a pretty good video introduction up on the web. Is it safe to assume enough people understand the basics and dive right into the future of dependency injection? What would you like to hear about?

I dream of electric sheep.

2007-11-11T11:39:00.000-08:00

In roughly 24 hours, we'll release the Android SDK, and I'll finally be able to talk about what I work on. My phone will be one (big) step closer to freedom. Wish us luck!

Update: It's alive!