Ted Neward

First there was iPod. Then iPhone. Then iPad. And with each new release, the mobile device market grew hotter and hotter. Now, as Google’s entry into this race, the Android system, begins to hit its stride as a competitor platform to the iOS, as a Java developer you’re intrigued—it’s Java (well, assuming you ask anybody except Oracle), and it’s a mobile device, and it’s open source, and…. What’s not to love?

In this all-day workshop, we’re going to turn you into a journeyman Android developer. This is a Java-based platform, so we’ll have a leg up on those other “Java-free” environments where you’ll have to spend half the day just learning how to count from 1 to 10 and print it to the console all over again. We’ll start by looking at the Android toolchain and how it integrates with your existing toolchain (Eclipse or otherwise). We’ll get your hands dirty writing some code to the Android emulator, then (for those of you who have Android devices handy) push it to a device. We’ll write some unit-tests for testing an Android application. We’ll look at how to store data to the device, both in a SQLite database as well as to a straight file. We’ll look at how to make Internet calls to remote services, and when all is said and done, we’ll have an application that Really Works ™. Bring a laptop, your Java skills, an Android device if you’ve got one, and buckle in, because it’s going to be a straight-from-the-firehose kind of workshop.

Fred Brooks said, “How do we get great designers? Great designers design, of course.” So how do we get great architects? Great architects architect. But architecting a software system is a rare opportunity for the non-architect.

The kata is an ancient tradition, born of the martial arts, designed to give the student the opportunity to practice more than basics in a semi-realistic way. The coding kata, created by Dave Thomas, is an opportunity for the developer to try a language or tool to solve a problem slightly more complex than “Hello world”. The architectural kata, like the coding kata, is an opportunity for the student-architect to practice architecting a software system.

In this session, attendees will be split into small groups and given a “real world” business problem (the kata). Attendees will be expected to formulate an architectural vision for the project, asking questions (of the instructor) as necessary to better understand the requirements, then defend questions (posed by both the instructor and their fellow attendees) about their choice in technology and approach, and then evaluate others' efforts in a similar fashion. No equipment is necessary to participate–the great architect has no need of tools, just their mind and the customers' participation and feedback.

With the rise of the NoSQL movement, a whole new crop of different ways to store data suddenly became available to the Java developer. Unfortunately,what didn't come with them was an owner's manual. CouchDB, for example, was the first of the NoSQL databases to be named as such, and offers features not found in the traditional RDBMS: A distributed, robust, incremental replication document-oriented database server with bi-directional conflict detection and management, accessible via a RESTful JSON API, stored ad-hoc and schema-free with a flat address space, that is both query-able and index-able, featuring a table oriented reporting engine that uses JavaScript as a query language. (With a list of buzzwords like that, what's not to love?)

In this session, we'll look at CouchDB, how to set it up, store data to it, retrieve data from it, and in general figure out where it fits within your next project.

Once you've learned the core Collections clases, you're done, right? You know everything there is to know about Collections, and you can “check that off” your list of Java packages you have to learn and know, right?

In this presentation, we'll go over what's missing from the Java Collections library, what is provided via other sources (Google and Apache, among others), and what you can provide for yourself, including a brief foray into the world of functional programing, and how it can make your Java code more elegant.

Android is a new mobile development platform, based on the Java language and tool set, designed to allow developers to get up to speed writing mobile code on any of a number of handsets quickly. In this presentation, we'll go over the basic setup of the Android toolchain, how to deploy to a device, and basic constructs in the Android world.

Attendees should be intermediate to advanced Java developers, as no time will be spent on Java basics, just the Android parts. Attendees are encouraged to bring laptops to the session (and your Android-based device, if you have one) to fill out code as we go, but the limited time frame means a focus on fast delivery of content and example code; have your fingers warmed up (and the SDK downloaded!) before you get here. (Latest Android SDK will also be on a USB key for attendees' use, in case attendees haven't had a chance to download & install.)

Creating a good game begins with finding an idea and fleshing it out into something… fun. In this session, we'll explore the art and science of designing games, including a few exercises designed to spark attendees' creativity.

Yes, we're talking about games. And we're talking about getting you, the programmer who got into this industry originally because of games, back into the arena of game development, regardless of whether it's “just for fun” or as a career change.”

Games? What do games have to do with good business-oriented applications? Turns out, a lot of interesting little tidbits of user-interface, distribution, and emergence, found normally in the games we play, have direct implications on the way enterprise applications can (or should) be built.

Come to this session, find out some intriguing things about what’s going on in the game industry, but more importantly, how ideas from the gaming world can turn around and answer some thorny problems in the business world.

“The Google Guava project contains a host of new features/classes for use by the Java programmer. Intended as a drop-in supplement for the standard JDK APIs, Guava provides features like immutable and forwarding collections, some concurrency utilities, more support for primitives, and so on.

In this session, we'll go over the Guava library, looking at what it provides, when you might seek to use it, and what the overheads and consequences of using it would be.”

With the forthcoming release of Java7, a number of things come to fruition, both in the Java language and in the libraries, and it's important for Java developers to know what those features are, and how they change the game of writing Java code–or not.

In this presentation, we'll go over those changes, JSR by JSR, and discuss where and how they may affect your next project.

The Java Virtual Machine is home to several different languages beyond Java, many of which mix ideas (paradigms) together to create a flexible language. Languages which support these different paradigms can be awkward and hard to understand how to use at first.

But if we tear apart the paradigms, examine each one and its advantages and disadvantages, then we can go back to bringing them all back together to create some truly elegant and powerful software designs. It all begins with understanding what software design paradigms are.

“From Wikipedia: “A physics engine is computer software that provides an approximate simulation of certain simple physical systems, such as rigid body dynamics (including collision detection), soft body dynamics, and fluid dynamics, of use in the domains of computer graphics, video games and film.
Their main uses are in video games (typically as middleware), in which case the simulations are in real-time. The term is sometimes used more generally to describe any software system for simulating physical phenomena, such as high-performance scientific simulation.”

In this presentation, we'll look at some of the physics engines available, and how to use them from within Java for a variety of purposes (most of which will be game-oriented, but can easily be extrapolated into other, more business-focused, scenarios).

Building an application is not the straightforward exercise it used to be. Decisions regarding which architectural approaches to take (n-tier, client/server), which user interface approaches to take (Smart/rich client, thin client, Ajax), even how to communicate between processes (Web services, distributed objects, REST)… it's enough to drive the most dedicated designer nuts. This talk discusses the goals of an application architecture and why developers should concern themselves with architecture in the first place. Then, it dives into the meat of the various architectural considerations available; the pros and cons of JavaWebStart, ClickOnce, SWT, Swing, JavaFX, GWT, Ajax, RMI, JAX-WS, , JMS, MSMQ, transactional processing, and more.

After that, the basic architectural discussion from the first part is, with the aid of the audience in a more interactive workshop style, applied to a real-world problem, discussing the performance and scalability ramifications of the various communication options, user interface options, and more.

With the rise of multi-core processors, and their growing ubiquity (on client machines, to say nothing of the server machines on which Java applications most frequently execute), the need to “program concurrently” has risen from “nice-to-have” to “mandatory” requirement, and unfortunately the traditional threading-and-locking model is just too complicated for most Java developers–even the brightest of the lot–to keep track of with any degree of reliability. As a result, numerous new solutions are emerging, each of them with their own strengths and weaknesses, leaving the Java developer in a bit of a quandary as to which to examine.

In this presentation, we'll look at Akka, a framework/platform specifically aimed at building high-throughput, concurrency-friendly applications in either Java or Scala (or both), with a slew of additional add-on modules to handle issues like persistence, communication (pub-sub, REST, and more), and more. By the time we're done, you'll be able to start looking into using Akka on your own projects, and have a good feel for what your projects would look like when Akka-ized.

For so many Java developers, the java.util.* package consists of List, ArrayList, and maybe Map and HashMap. But the Collections classes are so much more powerful than many of us are led to believe, and all it requires is a small amount of digging and some simple exploration to begin to “get” the real power of the Collection classes.

In this presentation, Java developers will see the basic breakdown of the Collection API designs, the relationship of the interfaces to the implementations, how to create a new Collection implementation, and how the new Collections introduced as part of JSR-166 (the concurrency JSR) and Java6 make their programming lives easier.

Much noise has been made in recent years about functional languages, like Scala or Haskell, and their benefits relative to object-oriented languages, most notably Java. Unfortunately, as wonderful as many of those benefits are, the fact remains that most Java developers will either not want or not be able to adopt those languages for writing day-to-day code. Which leaves us with a basic question: if I can't use these functional languages to write production code, is there any advantage to learning about them?

  The short answer is yes, for the fundamental premise--"I can't use functional code on my Java project"--is flawed. Java developers can, in fact, make use of functional ideas, and what's better, they don't even have to reinvent them for Java--thanks to the FunctionalJava library, many of the core primitives--interfaces that serve as base types for creating function values, for example--already exist, ready to be used.

In this presentation, we'll go over some basic functional concepts, then start seeing how they apply in the FJ library, and show how to use FJ and functional ideas on common Java programming tasks. Let the excuse “I can only use Java” finally be consigned to the rubbish bin, once and for all.