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.

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.

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.

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!

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.

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.

TheServerSide just posted a video interview they recorded in May shortly after the Guice 1.0 release. Since then, I've had ample time to chew over what I like so much about Guice and hone my thoughts on dependency injection in general.

Being a fan of plain old Java, before I wrote Guice, existing dependency injection frameworks were non-starters for me. I'd sooner write factories by hand than keep XML in sync with my classes or embed method names in strings. I mean, if you don't have type safety, all of that extra typing really is for naught, and you might as well switch to Ruby. Furthermore, a programmer shouldn't have to fire up a debugger or even think too hard in order to figure out what her code is doing. I felt the same way about mocking frameworks until EasyMock pioneered their extraordinarily typesafe approach.

Before Guice, I had to make the same up-front decision over and over: do I call a constructor directly, or do I write a factory and call it instead? If you start out calling a constructor and later decide that you need a factory, you have to go back and change all the callers. On the other hand, factories come at a cost: they clutter your API and result in a bunch of boilerplate code which you have to both write and maintain. In practice, if the only reason you need a factory is to enable testing, most programmers will forgo the factory, testing be damned.

Guice provides the best of both worlds and finally enables agile programming in Java. Injecting an object requires roughly the same amount of effort as calling a constructor. If you decide later on that you need more abstraction, write a factory and change your code in one place; there's no need to change all the callers. If you're providing code to someone else, give them a bunch of interfaces and a Guice module. They can test their code, you can change how you create objects to your heart's content without impacting your users, and your API will be smaller to boot. As you can probably tell from Guice, I love small, interface-heavy APIs.

Referring to this ActiveRecord example:

class Person 

Gavin says:



At this point, most developers are thinking um, ok, so how the hell am I supposed to know what attributes a Company has by looking at my code? And how can my IDE auto-complete them? Of course, the Rails folks have a quick answer to this question Oh, just fire up your database client and look in the database!. Then, assuming that you know ActiveRecord's automagic capitalization and pluralization rules perfectly, you will be able to guess the names of the attributes of your own Company class, and type them in manually.



Somehow, excitement about the Ruby language has warped their perceptions to such an extent that these people actually believe that this is a good thing!



Couldn't have said it better myself.