TSSJS2011: How to Reap the Benefits of Agile-Based TDD

I attended a breakout session on jQuery right after lunch, but I didn’t have my laptop up and, honestly, it was a pretty high-level presentation of jQuery in any case.   The technology certainly looks promising and I’ll have to find a way to play with it one of these days.   Then again, I’m still trying to play with Scala and Mule, technologies I heard and read about after last year’s TSSJS.   Aaaah…. where does the time go?

Agile based TDD sounds like a good session.   As much as I keep wanting to move to TDD, I have a really difficult time doing so.   Hopefully the more exposed I am to it, the easier it’ll become to actually use the methodology.

What is TDD?
Test-Driven Development is a software development process.

The TDD Process:
1.  Write a failing test for the target behavior
2.  Implement the behavior as simple as possible to get the test to pass
3.  Refactor the implementation

TDD is a Design Activity

TDD treats Tests as VIP Artifacts:  You need to treat your tests as first-class citizens

TDD is an “Agile” Practice:
1.  Working software is the primary measure of progress
2.  Continuous Attention to technical excellence and good design enhances agility
3.  Welcome changing requirements, even late in development

Types of Tests:
1.  Unit Testing: Verification of Design
2.  Acceptance Testing:  Verification of Features

What is a Unit Test?
Exercises a small testable piece of software
Tests a specific object behavior in isolation
Assumes that external dependencies work according to their contracts
Defines the assumptions that can be made of the target unitHow is unit test independent of its dependencies?  Mock Objects

Tools and Frameworks

JUnit
Openpojo:  a framework for validating that POJOs are adhering to a standard contract
Mockito:  Mocking Framework – Declare dependencies with @org.mockito.Mock

The Benefits of TDD

Test-Driven Development improves Design

SOLID Design
* Single responsibility principle: Can do one thing really well, loosely coupled
* Open/close Principle: Encapsulation – What, not how?
* Liskov substitution principle: Contract  first Design.  Avoid inheritance unless “is a” …
* Interface Segregation Principle: Interface clients should only depend on methods they need
* Dependency Inversion Principle: Depend on Abstractions instead of mocking

TDD Follows Law of Demeter

TDD avoids Static Helper Classes:  Procedural programming, not OO programming.

TDD Measures Progress, provides Documentation, and provides code coverage

How to Make it Work

* Flip Your Perspective – become a user, not a developer
* Always See Your Test Fail – make sure your tests have clear messages
* Listen to Your Tests – Urge to share test fixture state, setup, … => need to refactor
* Use an Interface Driven Approach
* Learn it well – TDD by Kent Beck

KATA

TDD Kata – Exercise in coding, refactoring and test-first, that you should apply daily for at least 15 minutes.  -Roy Osherove

http://www.osherove.com/tdd-kata-1/

TSSJS2011: Do You Really Know Class Loaders?

I’m back at The Server Side Java Symposium this year and this is the first breakout session I’m attending.   I think I’ve got good knowledge of ClassLoaders and Java Reflection API, but we’ll see if Jevgeni Kabanov, the speaker, can enlighten me with some new nuggets of knowledge.   He’s Founder & CTO of ZeroTurnaround, a company I know next to nothing about, although I have heard of JRebel, one of their products.   Anyway, enough background info… Let’s jump into the meat of the presentation.

Basics

public class A {
    public void do() {
        B b = new B();
        b.do():
    }
}
Instantiating Object B causes the following:  A.class.getClassLoader().loadClass("B");

Problems & Solutions

1. Class Not Found
You build some code and get a NoClassDefFound exception when deploying and trying to run the servlet.   How do we find out what the problem is?

Some solutions:
* IDE Class Lookup
* find *.jar -exec jar -tf ‘{}’ \; | grep MyClass
* URLClassLoader.getURLs()

2. Wrong Class Found
What if you get a NoSuchMethodError?  What’s happening there?  Well, the Class is found, but there’s something wrong with the class.

Solution:
* Get ClassLoader().getResource(Util2.class.replace(‘.’,’/’) + “.class” to find out where the ClassLoader is getting the class.  Then you can use javap -private Util2 to inspect the contents of the file.

3. More than One Class Found
That error will typically occur if 2 different ClassLoaders are used and find different classes for the same name.   They are not the same.

Helpful:  -verbose:class, as well as ClassLoader.getResource() to identify the different classes.

Leaking ClassLoaders

If a Class has a reference to its ClassLoader, that object has a reference to all of its classes.    To leak a ClassLoader, it’s enough to leak just one object loaded by that ClassLoader.

Hierarchy is not enough?

* Isolation: Difference versions of the same library
* Performance: Class lookup is very slow
* Restricted: Why can’t siblings see each other’s classes?
* OSGI, JBoss, NetBeans and others implement a different system

Follow the speaker on Twitter: @ekabanov

TSSJS2010: JVM Languages for mission-critical applications

The slides for this presentation can be found here

JSR-223: Scripting & what it means to you.

You want to use scripting languages to implement code faster through continous prototyping.

Scripting is built right into Java 6.   Spring has limited support, though.  But it is available on Mule ESB, ServiceMix, and other Spring containers.

Take a look at the javax.script package

Reasons for Scripting

  • Prototyping
  • Better tools for problem domain

Jawk – Processing a lot of text
Jython – System Management tools
XSLT – XML Manipulation

If the only reason you’re using scripting language is for dynamic code deployment, though, you should instead look at OSGi.

There’s also a tool called JRebel that’s worth taking a look at.

The Java Language is Awesome as long as you don’t break its abstractions!

Mule is great for pulling services together across multiple protocols.

TSSJS2010: The Cloud Computing Continuum

Bob McWhirter by far gave the best keynote session I’ve seen yet.   His delivery is humorous, he’s got great stage presence, and the slides were very creative.  Furthermore, he was best able to give me an understanding on what the hell the cloud is anyway.

The cloud is the next logical step in application delivery.

First, we jammed some servers in some closets.
Then we did some colo.
After that, we leased some managed servers.

With the cloud, we lease what appears to be servers.

The Cloud Computing Stack

Software as a Service (SaaS) – Abstracts software
Platform as a Service (PaaS) – Abstracts Services
Infrastructure as a Service (IaaS) – Abstracts Hardware

Tenets of the Cloud

  1. Illusion of Infinite Resources
  2. On Demand Acquisition and Provisioning
  3. Someone Else’s Responsibility

Virtualization makes it affordable to make mistakes.  Repeatedly.

The network isn’t all that slow, compared to spinning disks.

Messaging (REST-MQ)
Scheduling
Security & Identity (OASIS)
Computation (Query and otherwise)
Transaction (REST-TX)
BPM
Telephony

It’s a stack of services, instead of a stack of software.

More info at http://cloudpress.org

TSSJS2010: Mission Critical Enterprise/Cloud Application Case Study

Not a good start.   The speaker, Eugene Ciurana, is nowhere to be found.   Apparently he’s on his way.  Hopefully his mission critical apps are more responsive than he is.  😉   He finally arrives out of breath as he was apparently working out at the gym.   After he catches his breath, we begin.

The presentation is about how to design, implement and roll-out cloud/enterprise hybrid applications.   There are a lot of different cloud architectures:  PaaS, SaaS, and IaaS (infrastructure as a service).   Technologies include: ESB, clods, mini-clouds, Java, App Engine, Chef!/Puppet, etc.    Cloud technologies lower your cost:

* Which applications are best suited for cloud deployment?
* Identify the advantages of PaaS or SaaS resources?
* What are the caveats of cross-platform and cross-language integration?
* High-performance alternatives to XML serialization for data exchange?  (i.e., JSON)

What is the Cloud Anyway?
* Platform as a Service (Amazon, Google, Rackspace, etc.)
* Software as a Service (Salesforce.com, Amazon)
* Infrastructure as a Service (IBM, HP)
* Pure-infrastructure (Data centers)

Cloud Services Features
* Quick deployment of prepackaged components
* Uses commodity, virtualized hardware and network resources
* “Pay as you consume”
* Horizontal scalability is achieved by adding or removing resources as needed
* May host full applications or only services
* They could replace the data centre
* Basic administration moves to the application owner
* For the bean counters… it’s an operational expense!
* Assuming sensible SLAs, the ROI is better than for co-located or company-owned data centres (but won’t achieve 4 9s)

Uptime != Availability.   Many factors affect availability: network, storage, process

Hybrid Cloud Architecture

* Many mission-critical systems will live behind the corporate firewall
* The cloud is used for high-load applications and services
* The cloud applications work independentlyof the data center applications, and vice-versa.

Case Study: Video game company with  hybrid cloud application

Objectives
* Stable architecture
* Low cost
* Build scalability whenever possible
* Optimal data transfer rate for all properties

Initially, there were some 8 machines that were running everything: QA, PROD, debugging, etc.   The performance was atrocious!

Phase 1: Scalability

* Introduces a CDN for asset delivery (media, images)
– Amazon S3 for asset delivery
– Reduces load on company servers and bandwidth costs
* Introduces database replication for production environments
* Establishes a continuous integration environment
– Improved build/release process
* Fail-over with traditional database replication techniques

Phase 2: Cloud Deployment
* Web applications move to a uniform technology (.Net)
* The database and stored procedures normalized and optimized
* Applications use common resources via Mule ESB and services
– No more direct calls from apps to database
– Business logic is implemented as stateless POJOs
* Software stacks was best of breed
* Web and other RPC services must coexist
– Different partners use different protocols
* Bandwidth can be expen$ive!
* Data exchange protocols
– clients: custom, XML, JSON
– images: HTTPD, S3
– Cloud-to-HQ: custom, XML/SOAP, protocol buffers
– HQ data center: XML/SOAP, protocol buffers
* Replication strategy: data centre
– The cloud isn’t trustworthy yet
* Deployment involves using an Amazon Machine Image (AMI)
* AMIs need a post-configuration step in a load-balanced environment
* Elastic Load Balancer and Elastic IP limitations

And so it ends.   This session clearly pitched to C-levels (in particular CIOs.)  There was very little meat and substance for Java geeks to get their hands on.   It’s a shame.   Clearly Eugene has a lot of knowledge, but this was just way too high in the clouds (pun intended)

TSSJS2010: Cloud Computing with Scala & GridGain

I’m here at the beautiful Caesar’s Palace waiting to hear more about Scala.   James Gosling’s keynote speech this morning was a bit of a letdown.   I was hoping to hear a visionary speech from the father of Java, perhaps not with Obama’s oratory skills, but nevertheless captivating.   What I got instead was a 60 minute informercial on Sun’s current product offerings.   Yes, Java EE 6 and GlassFish 3.0 are totally slick, and I do like the concept of using annotations for event handling.   That said, I was hoping he would talk more about the future of Java, especially with all the Oracle merger and everything.   Anyway, no-go.   So now I’m here waiting to hear what the hell is Scala and how I can use it.   From what I’ve read, they’re using it at Twitter, so it’s gotta be somewhat scalable, right?  😉

The presentation is broken down with 20% talking and 80% live coding.   Nikita Ivanov, the presenter, has a very good stage presence and I enjoy his direct approach.

We start with the talking part by defining a few terms for us neophytes (including myself!)  What is Grid/Cloud Computing?   A Grid is defined as two or more computers working in parallel.   Grid Computing is comprised of Computer Grids + Data Grids.    The Cloud, meanwhile, is comprised of Data Center Virtualization.  Clouds are the new way to deploy and run grid applications.

Why Grid/Cloud Computing?

It solves problems often unsolvable otherwise.   Google has ~1,000,000 nodes in its grid.   Put another way, it’s about money.   Amazon says that 100 ms latency cost 1% of sales.  Google says that 500 ms latency drops traffic 20%.   In the financial sector, one millisecond costs $4M in currency markets.

GridGain at a Glance

The project was started in 2005 as Java-based Cloud Development Platform:
* Compute Grid (aka, MapReduce)
* Data Grid (aka. Distributed Cache)
* Auto-scaling on the cloud

Scala at a Glance

* Started in 2004 by Matin Odersky at EPFL  (author of ‘javac’ and Java Generics)
* Scala is Post-Functional Language (combines functional and OO approach)
* Fully inter-compatible with Java (runs on JVM, Call Java and called from Java methods)
* Statically typed (Unique and powerful type inference)

Apparently, there’s more use of Scala in Europe than there is here in the US.   A large national French bank already has a dozen Scala projects rolling out.   In the audience here today, only one hand was raised when asked who was using Scala today?

Why Scala?
* Performance largely equal to Java
* Statically typed
* Inter-compatible with Java
* Scalable language

Scalar – Scala-based cloud computing DSL + GridGain 3.0
* Uses Scala
– Functional-impertive
– Runs on JVM
– Reuses 100% Java libraries
* Running on top of GridGain 3.0 runtime

DSL – Domain Specific Language
* Provide simple cloud computing model
* Draws on functional features of Scala
* Dramatically simplifies cloud computing applications

The demo is to build a Scala grid application in 10 minutes!

import org.gridgain.grid.gridify.Gridify
import org.gridgain.grid.GridFactory

object ScalaDemo {
    def main args: Array string {
        GridFactory start

        try {
            say "hello Scala Las Vegas"
        }
        finally
            GridFactory stop true
        }
    }

    @Gridify
    def say msg: String   { println msg }
}

This code automatically deployed the object to the Grid and executed it on one of the nodes!   That’s mindblowing and so cool!   Clearly there’s tons of complexity behind the scenes.   The class definition must be serialized, the grid must be located, some scheduler must identify the node on which the object is to run.   I’m totally blown away by how painless it is to deploy on a grid!

Ivanov proceeded to write a task in about 10 lines of code that split the string into words and dispatched the job of printing those words onto the various nodes.

The same demo was then given using Scalars, which is a GridGain construct.    That got a little more cryptic, in my humble opinion.   Still, it did require less lines of codes to get the job done.   The tradeoff, though, seems to be readability.  You’re slowly creeping into the world of Python, which I’ve never enjoyed because only the original developer can ever make bug fixes.

Still, Scala clearly is pretty slick and it looks like the integration with GridGain in order to parallelize tasks is very easy.   I’ll definitely need to investigate how I can leverage this for risk analysis.