Posted using ShareThis

I gave the following presentation at work and would like to share it here:

• introduction-to-scrum.ppt

RESOURCES:

• http://en.wikipedia.org/wiki/Scrum_(development)
• 5 minutes intro: http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf
• glossary: http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms
• very useful from MountainGoatSoftware: IntroducingAnAgileProcess.pdf
• 5-writing-contracts-for-agile-development

WEBSITES:

• http://www.mountaingoatsoftware.com/
• http://controlchaos.com/resources/
• http://www.scrumalliance.org/
• with cartoons: http://www.implementingscrum.com/

Introduction and History

Goals of AOP

Aspect Oriented Programming (AOP) is a programming paradigm that aims to promote desirable software characteristics that have been difficult to implement in the current OOP (Object Oriented Programming) technologies. Desirable software characteristics include the DRY principle (Don’t Repeat Yourself), 1:1 modularity, information hiding, and separation of cross-cutting concerns. Examples of cross-cutting concerns are logging, security, transactions, remoting, caching, lazy instantiation, and even business logic.

Design (anti-)patterns

In the absence of multiple inheritance in the current programming languages such as Java and C# (1), design patterns have been developed to help with modularity. However, design patterns (i.e. such as decorator, proxy, command, inheritance, and callbacks)tend to be work-arounds that are usually weakly-typed, invasive, and cumbersome - requiring programmers to follow a template, thus leading to code copying and making it more difficult to refactor. True separation of concerns enables each concern to be developed and tested individually, leading to easier refactoring, and thus improving agility (adaptation to change).

Paradigm Shifts

While programming languages come along more often (2), programming paradigms shift roughly once a decade: assembly/C in the 1970’s, SmallTalk in the early 1980’s, C++ in the mid-80’s, Java in the 1990’s. AOP adoption is increasing due to improvements in tools which provide clarity in where aspects are applied.

AOP Basics

join point - a point in the runtime execution of a program.
pointcut - a set of join points matched together by a pointcut expression.
advice - a method to execute for each matched join point in the pointcut. Types of advice are: before, after (normal exit, exception thrown, both), and around.
aspect - a unit of modularity (like a class) that specifies pointcuts and advices to implement a cross-cutting concern.

Spring AOP vs. AspectJ

Both Spring AOP and AspectJ are now backed by SpringSource and are increasingly tightly integrated: using the same pointcut language and annotations from AspectJ, while Spring provides dependency injection to complement aspects. The differences between them provide the choices that can be made when programming AOP in Java. These differences are language, join point model, weaving possiblities.

Language

While Spring AOP specify aspects as normal Java classes and configured using XML or annotation, AspectJ requires the use of the AspectJ language. There are advantages and disadvantages for both. Because aspects as Java classes can be easily understood by Java developers, Spring AOP is easier to adopt, but it has its limitations (see below). Furthermore, pointcut expressions, as well as annotations, are the same as AspectJ. On the other hand, while AspectJ requires knowledge of a new language, the language is most natural for coding aspects, allowing better static analysis with the provided tools and optimal runtime performance.

Join Point Model

A join point model is a set of join point types which specify when an advice can run. AspectJ has a rich join point model: including:
- call
- execution
- get
- set
- exception handlers
- initialization
- static initialization
- advice execution
On the other hand, Spring AOP supports only method execution from the above join point types. (Note that initially Spring AOP is sufficient and easier to adopt especially if already using Spring).

Weaving

An aspect has to be “weaved” into the classes in order for the aspects to be executed during runtime. Spring AOP uses proxy-based (runtime) weaving, while AspectJ provides the choice for compile time, post-compile time, and load time weaving.

Proxy-based weaving (runtime)

Proxy-based weaving means that a proxy is dynamically created for each object that need to be advised. This type of weaving is used by Spring AOP. With proxy-based weaving, there is the runtime flexibility to add, remove, and reorder advices, as well as allowing individual objects of the same type to be advised differently. However, with this flexibility comes the inherent problems of proxies such as identity management (which object is ‘this’?). In addition, as mentioned above, Spring AOP is restricted to method execution pointcuts.

Compile-time weaving (iajc)

Compile-time weaving means that all sources including aspects are compiled with iajc - incremental AspectJ compiler. This links the classes and aspects together to produce fully-weaved .class files. However, there might be reasons why another compiler cannot be used.

Binary weaving (post-compile, byte code instrumentation)

Binary weaving means that aspects are linked with pre-built .class files instead of building the whole application from source. The .class files are “instrumented” like they are for coverage measurement with tools like Cobertura and EMMA. There is full Ant (http://dev.eclipse.org/viewcvs/indextech.cgi/aspectj-home/doc/ant-tasks.html) and Maven (http://mojo.codehaus.org/aspectj-maven-plugin/) support for both compile-time and binary weaving.

Load-time weaving

Load-time weaving means that weaving is deferred until the last possible moment: when a class is loaded by the VM. From what I understand, this is the least straight-forward approach, since it is application server specific. With Java5+, a Java agent, referencing a weaver, is used to run the application. For application servers, enabling load-time weaver depended on the configuration of the classloader as provided by each application server.

Summary

In this post, I wrote an introduction to AOP, presenting goals of AOP, a bit of history, and AOP basic concepts, and finally, exploring the difference between Spring AOP and AspectJ in terms of language, join point model, and weaving. The next post will be about basic pointcut expressions.

Resources:
http://en.wikipedia.org/wiki/Aspect-oriented_programming
http://static.springframework.org/spring/docs/2.5.x/reference/aop.html
http://www.eclipse.org/aspectj/

Footnotes:
1 Why no multiple inheritance in Java?
http://www.javaworld.com/javaqa/2002-07/02-qa-0719-multinheritance.html
http://en.wikipedia.org/wiki/Diamond_problem

2 History of Programming Languages
http://merd.sourceforge.net/pixel/language-study/diagram.html
Main programming languages: http://people.mandriva.com/~prigaux/language-study/diagram-light.png
Full 150+ languages: http://people.mandriva.com/~prigaux/language-study/diagram.png

Summary

Applications running on a server require the following phases for coverage: instrumentation, running, data collection, and report generation.

Note: In Maven, I’ve put all EMMA related cofiguration in an ‘emma’ profile and all Cobertura-related configuration in an ‘cobertura’ profile, each activated by the coverage property (-Dcoverage=emma or -Dcoverage=cobertura) so only one can be run at a time.

Instrumentation

There are not much difference between EMMA and Cobertura in the instrumentation phase. Both Maven plugins are similar to use and configure, although Cobertura seems to be more clear in specifying paths.

Field Reflection

Note that because classes are that are instrumented have added fields to hold coverage data, it is not possible to reflect through all fields of an instrumented class because EMMA/Cobertura fields are not accessible at runtime. Therefore, it is better to reflect using names of fields that you know are there instead of through all fields. If code change is not possible, exclude the classes to be reflected from the instrumentation.

Our project is a multi-module Maven project. To instrument all modules, only the master pom must be altered.

EMMA

<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>emma-maven-plugin</artifactId>
<inherited>true</inherited>
<executions>
<execution>
<id>instr-emma</id>
<phase>process-classes</phase>
<configuration>
<filters>
<filter>+com.mycompany.*</filter>
<filter>-com.mycompany.*.SomeClass</filter>
<filter>-com.mycompany.*.*Test</filter>
</filters>
</configuration>
<goals>
<goal>instrument</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

To access the emma-maven-plugin, the CodeHaus snapshot repository must be added to your pom:

<pluginRepositories>
<pluginRepository>
<id>snapshot.codehaus.org</id>
<name>CodeHaus Plugin Snapshots</name>
<url>http://snapshots.repository.codehaus.org</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>

Cobertura

Cobertura is very similar:

<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<inherited>true</inherited>
<executions>
<execution>
<id>instr-cobertura</id>
<phase>process-classes</phase>
<configuration>
<instrumentation>
<includes>
<include>com/mycompany/**/*.class</include>
</includes>
<excludes>
<exclude>com/mycompany/**/SomeClass.class</exclude>
<exclude>com/mycompany/**/*Test.class</exclude>
</excludes>
</instrumentation>
</configuration>
<goals>
<goal>instrument</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

Running

Running is the same with or without coverage.
Unit tests are run with the surefire plugin in Maven. While integration tests that require applications to be running on a server must be packaged and deployed before they are run from the client side.

EMMA

Because an application running with EMMA connects to the socket ‘47653′ by default, a running application server and the test client will conflict for the socket. Therefore, if the test client is running on the same machine as the application server, configure the the socket for the test client by setting the system property -Demma.rt.control.port=12345 for the test client.

System Properties

Although the surefire plugin is supposed to allow passing in system properties (see http://maven.apache.org/plugins/maven-surefire-plugin/examples/system-properties.html), it did not work when I tried it. Therefore, I moved back to Ant to run the tests.

Data Collection

EMMA

The main reason I chose EMMA is because of the ability to dump and reset coverage data without shutting down the application server. EMMA (from version 2.1.5320) provides a tool (ctl) for getting a dump from a server and resetting the data. The ctl tool is accessible from the command line or from Ant. This is useful for running several types of tests where you want to collect coverage data for each separately. Here I use Ant so that it can be platform independent (instead of a .bat or .sh file).

After declaring the emma task (see Appendix), the following is the Ant target to be run from the POM’s of the test projects:

<target name=”emma-server-dump”>
<delete file=”${project.name}/coverage-${server}.ec” failonerror=”false”/>
<emma>
<ctl connect=”${server}:47653″>
<command name=”coverage.get” args=”${project.name}/coverage-${server}.ec” />
<command>coverage.reset</command>
</ctl>
</emma>
</target>

The properties are as follows:

Cobertura

Although Cobertura provides an API (See http://cobertura.sourceforge.net/faq.html) for dumping coverage data from an application running on a server, it must be coded, deployed, and exposed to be triggered yourself. Furthermore, there is no API to reset the data. Therefore, to achieve the same functionality as EMMA, the server must be restarted between different test runs.

Report Generation

For both EMMA and Cobertura, it is not possible to specify more than one source directory in the report configuration in Maven. Therefore, generating the report in Maven is only useful for single module Maven projects or for running unit tests where only one source directory is to be considered for the report. Because of this limitation, I reverted to Ant to generate the coverage report for both EMMA and Cobertura.

EMMA

The following is a portion of the Ant build file after the emma task has been defined (see Appendix).

<target name=”emma-report”>
<delete failonerror=”false” dir=”${report.dir}” />
<mkdir dir=”${report.dir}” />
<emma>
<report>
<sourcepath>
<dirset dir=”${top.dir}”>
<include name=”**/src” />
<include name=”**/ejbModule” />
<include name=”**/Javasource” />
</dirset>
</sourcepath>
<fileset dir=”${top.dir}”>
<include name=”${project.dirs}/target/coverage.em” />
<include name=”${project.name}/coverage*.ec” />
<exclude name=”*Test*/target/coverage.em” />
</fileset>
<html outfile=”${report.dir}/index.html” />
</report>
</emma>
</target>

The properties are as follows:

Cobertura

Because it is not possible to specify more than one source directory in a wildcard, configuring cobertura for reporting is much more annoying. Furthermore, meta-data files and coverage data files (.ser) must be first merged because only one such file can be given for the report.

<target name=”merge”>
<cobertura-merge datafile=”${report.dir}/${test.name}.ser”>
<fileset dir=”${top.dir}”>
<include name=”${project1}/target/cobertura/cobertura.ser” />
<exclude name=”${project2}/target/cobertura/cobertura.ser” />
</fileset>
</cobertura-merge>
</target>
<target name=”cobertura-report” depends=”merge”>
<cobertura-report format=”html” destdir=”${report.dir}” datafile=”${report.dir}/${test.name}.ser”>
<fileset dir=”${src.dir.1}”><include name=”**/*.java” /></fileset>
<fileset dir=”${src.dir.2}”><include name=”**/*.java” /></fileset>
<fileset dir=”${src.dir.3}”><include name=”**/*.java” /></fileset>
…
</cobertura-report>
</target>

The “cobertura-report” target depends on the “merge” target.
The properties are as follows:

Appendix: Declaring EMMA / Cobertura in Ant

EMMA

<property name=”emma.home” value=”/usr/local/emma”/>
<path id=”emma.lib”>
<pathelement location=”${emma.home}/emma.jar” />
<pathelement location=”${emma.home}/emma_ant.jar” />
</path>
<taskdef resource=”emma_ant.properties” classpathref=”emma.lib”/>

Cobertura

<property name=”cobertura.dir” value=”/usr/local/cobertura” />
<path id=”cobertura.classpath”>
<fileset dir=”${cobertura.dir}”>
<include name=”cobertura.jar” />
<include name=”lib/**/*.jar” />
</fileset>
</path>
<taskdef classpathref=”cobertura.classpath” resource=”tasks.properties” />

spring application,ejb Job Trends

spring application jobs - ejb jobs

The new buzz from SpringSource is all about the Spring Application Platform (S2AP) with built-in OSGi support. Basically, SpringSource is getting into the application server space, but as they have always done, they provide a different way of doing things from the traditional J2EE. S2AP is basically an application server but with OSGi enabled - I’m still not sure why they don’t call it an application server.

According to the OSGi Alliance, OSGi is the dynamic module system for Java. It “modularizes” applications into bundles which can be “dynamically” swapped in and out of the runtime environment. I see it as like Maven - but for runtime. The idea is to be able to manage versioning of internal and external bundles (jars) during runtime. By pulling external jars out (from a war or ear file) into a repository, OSGi would massively reduce the size of a deliverable. In the future, I would like to see it with built-in search and automatic download from an online repository. OSGi is in fact a very service-oriented technology. It consists of bundles which contains “services” that you can “publish” to a “registry”. An OSGi-enabled bundle is basically a jar with special information in the manifest that tells what services the bundle exports and what other bundles (and their versions) are dependencies. A bundle would follow a certain lifecyle: where you can install, start, stop, uninstall, and update a bundle in runtime.

In an OSGi environment, a bundle must publish its services and find and bind to other bundles. The plumbing code for doing this is provided by Spring Dynamic Modules. Spring-DM combines Spring and OSGi. It provides a dynamic service model that makes it easier to write Spring applications for deployment in an OSGi environment.

Although all of the leading application servers seem to be moving towards OSGi, Spring seems to be the only one that makes it available to developers instead of only for the operations side. I’m not sure why this is. Maybe someone can let me know.

In conclusion, Spring Application Platform and Spring Dynamic Modules together provide Spring developers the ability to managing versioning in runtime using OSGi. The main idea is to promote faster development by removing the need to redeploy on the application server.

Selenium comes in several version: IDE, core, remote-control, grid.

First, Selenium IDE is used to create tests and run them during test development. It comes as a Firefox plugin, which means that installation happens in one click. One of the biggest advantages of Selenium is that the tests are stored in HTML, which is easy to understand and easy to manage even without a lot of technical knowledge, making it perfect for functional testers. In addition to creating tests by recording user interactions, tests can also be manually built up from a large list of commands, implemented in Javascript. Some of these commands use XPath or DOM for specifying elements within a web page.

If the HTML/Javascript solution is not enough to expression your test scenarios, tests can be written in Java, C#, Perl, PHP, Python, or Ruby. Selenium IDE even converts an HTML script to any of the above languages for you as a starting point. But once code that cannot be converted back to HTML are introduced in the test, the test can no longer be run within the IDE, but must be compiled (if necessary) and run with Selenium RC (see below).

Second, Selenium RC (remote-control) is used for running the tests from the command line and remote from the application server, making it easy to integrate into a nightly build. Since Selenium is Java-based, it can be run in any OS that supports Java. Selenium RC encapsulates Selenium Core, which was the initial product that requires tests to be deployed together with a web app. This means that Selenium core is probably no longer used by itself.

Lastly, Selenium Grid encapsulates several Selenium RC servers and allows the tests to be run in parallel on multiple machines. This is useful to start the tests on several different OS at the same time, driven from one process.

Selenium seems to be perfect for functional testing. It is easy to adopt, but is flexible enough for more complicated test scenarios which can be written in a variety of languages.

Selenium references:

• Selenium IDE documentation
• Selenium command reference
• Selenium forum

TITLE
Duchess, Ladies in Java
link: www.jduchess.org

ABSTRACT
Female programmers are rare. Female Java programmers are even more rare. As female Java programmers ourselves, our interest in this issue led us to start Duchess, an organization to support and promote women in the Java industry and hopefully to encourage more to join. Our approach to the shortage of women Java programmers includes making the problem and
arguments for involving women in IT visible. Why is it good to have more women in the industry?

Why are there so few women in IT and why there should be more
Communications and Language Skills
First, there is the image of IT as only for men because men are better at it. However, according to an article “Why More Women Should Consider a Career in Computer Programming”, V. Berba Velasco Jr. (the author) argues that women can contribute a lot to the field because of their intrinsic language and communications skills. People with better language skill produce better code because the code would be more readable. This would in turn lead to lower development and maintenance costs. As Martin Fowler
once said, “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” A team must understand each other to produce the software together. Furthermore, better language
skills lead to better documentation, which helps the intended audience use the software.

Diversity = Productivity
A diverse workforce is more productive. Therefore, there should be more women in the IT industry. In a recent article on the NYTimes, Scott E. Page, a professor of complex systems, political science and economics, said that homogeneous organizations get stuck more often, while “diverse groups of people bring to organizations more and different ways of seeing
a problem and, thus, faster/better ways of solving it.” In his study, he used mathematical models and case studies to support the claim that diversity = productivity. Men and women complement each other. In a BBC article reporting on Helen Fisher’s speech at DAVOS, she said that “Having only men or women on your team would be like hopping on one foot instead of walking.”

Economy
A second reason for so few women in IT is related to economy. In some countries, the IT industry suffers from the same issues that lead to the general lack of women in the workforce. In these countries, the lack of affordable childcare and flexible hours in the workplace means that women often stop working completely. The price of childcare outweighs the salary of the woman in the family, so that it is often financially unwise for a woman to return to work after having children. In this case, the women staying home is the optimal economic configuration for the family. But for the economy as a whole, a shortage of labor often impedes economic growth. In these countries, governments and businesses can encourage women to return to the workplace by providing affordable childcare and promoting flexible hours.

Stereotypes
We realize that some of the things we said about women above are considered stereotypes and of course, not everyone fits in to a stereotype, but the fact is that men and women ARE different. The important thing is to be aware of the stereotypes, so you can see how a person - male or female - fit in.

About Duchess?
Duchess is an organization of women Java programmers. It provides a platform for women to organize themselves online and offline for real life networking. Our short term goals include arranging technical sessions, study groups, social outings, and discounts for external events and courses. Our long term goals include establishing local branches all over the world and reachout programs in schools and universities.

If you are a female Java programmer, why should you join Duchess?
Network. Extending your network is always good for your career.
Learn. There is a chance to learn from workshops and courses accessed through Duchess.
Share. Share your experiences will deepen your knowledge and support other women in IT.

References:
http://www.scienceblog.com/cms/does-diversity-increase-productivity-15193.html
http://www.nytimes.com/2008/01/08/science/08conv.html?_r=1&ref=science&oref=slogin
http://www.streetdirectory.com/travel_guide/10105/women/why_more_women_should_consider_a_career_in_computer_programming.html
http://www.informit.com/articles/article.aspx?p=360842&seqNum=4
http://www.unescap.org/esid/GAD/Events/EGMICT2001/apctt.ppt
http://www.unu.edu/unupress/unupbooks/uu37we/uu37we0k.htm
http://news.bbc.co.uk/2/hi/business/7209353.stm

In a service oriented architecture, the services are loosely coupled to each other with the promise of reusability and improved performance in a distributed environment. However, while services are usually stateless, a business process (use case) often span more than one service, which communicate via a centralized component: a database or a messaging provider. In a tier-based architecture, problems with scalability may negate any improvements made by the distribution of services. Gigaspaces provides a solution in the form of XAP (eXtreme Application Platform), an application server built to enable linear scalability. Linear scalability means a one-to-one ratio between machines added to the deployment and the performance gained, making scaling predictable in costs and effort.

GigaSpaces argues that tier-based architecture is the nemesis to linear scalability. In fact, the architecture itself is the bottleneck, not unoptimized component. This is because in a tier-based architecture, as scability patches are introduced, the communication between the tiers become more complicated and expensive. The complex interaction between tiers and between physical machines in the deployment cause problems with latency and data consistency. Possible problems with tier-based architecture are bottlenecked access to the database, bottlenecked access to a centralized messaging provider, messaging overhead, network latency, inefficient clustering, and unreliable failover recovery. GigaSpaces addresses each of those problems by providing a platform that enables space-based architecture.

The whitepaper, “Scaling Spring Applications in 4 Easy Steps”, introduces a four-step approach to achieve the implementation of a space-based architecture.

1) Virtualizing Data
In the first step, virtualizing the database using the IMDG (In-Memory Data Grid) reduces I/O latency to the database. The IMDG (In-Memory Data Grid) provides consistency, availability, and reliability of application state and can be made as reliable as needed - from keeping in memory for fast access, to asynchonous batch writing to database, to direct write/read. It is not only more efficient, but more reliable than a database, by providing failover recovery and memory usage monitor to prevent memory crashes, which helps in tracing memory problems. Although virtualizing the database reduces I/O latency, the need for each tier to access a centralized messaging provider and the need for two-phased commit of distributed transactions when using a centralized transaction manager are still bottlenecks in the system.

2) Virtualizing Messaging
In the second step, virtualized messaging is achieved by creating a data bus to consolidate messaging and data in the same place. The data bus is implemented in the IMDG as a JMS façade acting as the messaging provider. This requires minimal changes to applications using the JMS API. Data affinity, or colocating related data, removes the need for a distributed transaction manager.

3) Virtualizing Application
The third step towards a space-based architecture is to create self-sufficient processing units by packaging the business logic together with the data and messaging middleware. In practice, this means putting all the services required for an entire business process in one processing unit. Because each processing unit is self-sufficient, requiring no external component access, packaging business logic, messaging, and data together enables linear scaling and minimal latency. XAP takes care of content-based routing and automatic detection of service availability to enable dynamic scaling. Within a processing unit, the business logic is hooked into the messaging and data middleware with the “polling container”, which allows the business logic to be notified of changes with the messaging/data space.

4) Virtualizing Deployment
The fourth and final step is virtualizing deployment using the OpenSpaces Deployment Framework, which provides the administrator an overview of the entire deployment scope. The OpenSpaces Deployment Framework uses a SLA(Service Level Agreement)-driven container to dynamically scale up (or down) application resources bundled in processing units and to adhere to the service-level agreements by automatically detecting and recovering from failures.

The above four steps effectively transitions an existing application to a space-based architecture. The beauty of it is that using GigaSpaces’ XAP is completely transparent to all concerned - to the designer, developer, administrator, and client. An application deployed in XAP acts as one single server.

References:

See http://jduchess.org/.

Female Java programmers are welcome to join. As soon as moment there is a critical mass in your area, it’ll be possible to organize local events and activities.

Also, come to our launch party if you’re near Amsterdam.