Day 3 was a busy day with a beer bash and BattleBots at the end of it.
Fun and Profit with the Google Checkout API in Java Technology::
This talk was a few guys from Google and one outsider talking about how Google Checkout works, what they are trying to accomplish, and how we as developers can integrate commerce sites with Google Checkout. Specifically they covered:
1. Checkout Service
2. Checkout API
3. Sample Java Code
4. Posting a Cart
5. Processing Notifications.
6. Adding shipping information for product tracking.
For the Google APIs they pointed us to the 32 APIs found here. They also talked through why they came out with Google Checkout and showed us stats about online sales, how they are projected to grow, and where they thought Google Checkout could add value. I can definitely agree with their conclusions based on the data showed. They then went through the benefits to Buyers and Merchants and showed detailed diagrams around the buying and shipping notifications processes and how some of the processes are synchronous and asynchronous. As it turns out there are two integration options with Google Checkout. You can simply add a button to your page that will take the Buyer to the Google Checkout so they can finish the transaction. This is known as level 1. Level 2 integration involves using the Google Checkout XML API which made it look like the Buyer can finish their transaction from within your site. As a Buyer I would prefer to stay at the same site to finish my transaction whether I'm using Google Checkout, Paypal, or a cc. Then they walked us through implementing the ubiquitous Java Pet Store using the Google Checkout API in Java. They also talked about some of the mistakes they have made along the way. Toward the end a guy from outside of Google talked about using a test product called Mendoza to test the whole transaction process. It is a simple jar file that sits as a proxy between the client system and the Google Checkout Sandbox.. It verifies the syntax going back and forth through it as well as uses Selenium to place orders. I use Selenium on my current project and highly recommend it. He then went on to talk about future improvements such as:
1. Improved UI
2. Unit Testing Tools
3. Test Suites out of the box.
Deploying and Scaling Massive Digital Archive Repositories::
This talk was given by a Sun guy and it basically covered the problem of how do you store massive amounts of data (Petabytes) in an economical way but still allow users to access the data within a decent amount of time. Some examples he used of web sites that add this amount of data were Youtube and Flickr. He said that data is basically made up of fixed data (data that never gets modified) and other data that does get modified. For fixed data think music, videos, pictures, programs that you run on your computer etc... For data that gets modified think word documents, web pages, code that you write, etc... He said that roughly 80 % of the data out there is fixed and will not be modified later and that it will, grow year after year, at an alarming rate. Then we walked through the different stages of building a massive storage system. It was kind of like playing sim city in that you start with something small and simple and as you evolve it becomes more and more complex until you finally throw in the towel. Some of the different technologies in the this space that he talked about include:
He then went on to talk about new models of storing massive amounts of data. He covered the idea of storage objects. Each object has:
1. Data
2. Searchable Metadata
3. Code that can be executed against the data.
He said that if you are going to build your own massive storage system you should build it from an existing framework and focus your efforts on your workflow. Then he went on the pitch a case study using Fedora and the Sun StorageTek 5800. I got to check out this machine at the Sun booth and it was pretty sweet.
Testing Concurrent Software::
The testing concurrent software talked about the difficulties involved in and the ways that developers should approach testing their multithreaded applications. It was no big surprise when the speakers said that the testing is difficult but not impossible. They said that concurrent software testing is like sequential software testing except there are more failure modes. Some of the failure modes included deadlock, livelock, and missed signals. Some bugs require the stars to align the right way and are very difficult to reproduce. I know this well from experience :-). There is nothing quite as fun as running a test, seeing a problem, spending the time documenting the problem and looking at the log files and then trying to reproduce it before going to the developer and then not being able to reproduce it. They said that for concurrent software you need more intensive tests that run for longer and look for rare probabalistic failures. They also recommended separating your concurrent logic from all your other logic as much as possible. They also made the assertion, which I agree with, that testing will never find all the bugs. Instead it increased the confidence you have that your application will work. There are several areas of testing. They include:
1. Manual Code Review (expensive because it requires subject experts to be effective).
2. Static Analysis
3. Unit Test
4. Unit Test under constant stress
5. Performance Testing
6. Stress Testing
Other testing items they covered included TestNG (concurrent support), the Marmoset Project. findbugs, testing for race conditions, testing for bounded buffers, Con Test, JMX API, and documenting what you need the product to do, and system integration testing. You can also find a list of all his publications here.
RubyTooling: State of the Art::
This talk focused on different IDEs, editors, and debuggers for Ruby. Overall I didn't find it that interesting because it focused on the lack of good, robust tools for Ruby development. Some links they mentioned were rubyforge.org and datanoise.com.
Write a 3-D Game in the Java Programming Language in Less Than 50 Minutes::
This was a pretty fun talk that focused writing a simple 3-D Game in java in less than an hour. In reality, you could "write the code" for the game in less than an hour, but it would take you way more than an hour to get all the tools in place for you to get your game going. It was fun and entertaining though and the Demo game was Duke (the java mascot) running around shooting coffee beans. :-)
After all the sessions were over they had an after dark bash complete with BattleBots, a midget band playing Kiss songs (I'm not kidding), and lots of food, drinking, and games. Overall it was pretty entertaining and the BattleBots fights were pretty cool. Some of them were even driven by Sun executives.
Posted by troutm8 at May 14, 2007 11:05 AM