Free Struts 2 Training (Outline)

Every company now has a web site. Struts is the most widely used Java framework for building these websites. Struts 2 is a radical overhaul, making it easier to use, yet more powerful at the same time.

In January, I will start delivering a course on Struts 2 for IACT – the Irish Academy of Computer Training.

Struts 2 Logo

This course is an overview to programming for the Web using Struts 2 and Java (free course outline here), including an introduction to the language for people already programming in other languages like Visual Basic. It covers what is different about developing web applications, the problems the Struts 2 framework solves, and how to develop applications within it using the Eclipse IDE. Optional components include JUnit, Ant, Log4J and building Web-Database applications.

If you’re a Struts 1 Developer looking for more than the free outline then I do plan to blog about upgrading your skills over the coming weeks. If that isn’t quick enough, you can always hire me for a 1-2-1 mentoring session 🙂

Update: The Course notes are now also available on the wiki / knowledgebase.

Agile Architecture – a new blueprint every day

The best thing about doing presentations is the questions you get asked at the end. Apart from the stomach churning moment of ‘will I be able to answer this one?’ they give you a new angle on things that you may have always assumed, but force you to think of in a different way.

Take one of the questions after yesterday’s Enterprise java presentation at DCU. One of the topics mentioned in the final ‘putting it all together’ was the Agile and RUP (or other upfront design) methodologies. The question , coming from an attendee that was keen on using Agile , was ‘How do you do Architecture in an Agile project?’
DCU Logo

On the face of it this seems a contradiction. Agile in it’s most extreme form is ‘make up just enough design as you go along’, with automated tests to make sure changing things later is a relatively low cost and pain free process. In real life most projects are a balance between Agile and need some element of a more formal process (often trying to answer the question ‘how mucn is this going to cost?)’

So , how do you merge Agile with an upfront design process? It’s easier than you think.

Most systems built the ‘traditional way’ do not get all their design done in one go. They might start out with the best of intentions for phase 1 with a clean sheet but over the months / years people come and go, business requirements change and different phases try to deliver different things. Over time the original clean design twists and turns and you work hard to try and make it work out ok. Some of features you thought were key may end up getting thrown out as too complicated.
Now Agile architecture is a similar situation. Each weekly / monthly iteration is like phases on the larger project , with twists and turns that may be unexpected. The difference now is that you have a safety net comprised of your (J)Unit tests, to allow you to make radical changes if your blueprint ends up in a cul-de sac.

Yes, it is ok to have an idea the bigger picture and where you like to go with the design. Yes, a good architect will find reasons in the current release to build towards that design. And yes, a good architect may admit that some of the design features he / she thought were required weren’t actually needed. The difference between Agile and Upfront architecture is in when you find your ‘Don’t really need it’ point. With Agile , you find it just before you build it. With upfront design / architecture you find it when it’s already too late.

Enterprise Java Presentation at DCU

On Wednesday, I’m presenting on the topic of Enterprise Java at DCU (Dublin City University) , in conjunction with Trigraph.

Trigraph Logo


I’ll blog later about bits and pieces of the slides (for commercial reasons I can’t publish the full set here), but the overview is below.

Description: Success or failure in your business depends on dealing with information faster and better than your competitors. This briefing shows you how Enterprise Java tools can do this and how to apply them to your organisation. Crucially, the briefing shows you when not to use Enterprise Java and details the alternative approaches.The briefing will give delegates an overview of the Java Web development environment, how to architect and distribute multi-tier applications and how to link these components with existing sources of information using Enterprise Application Integration (EAI). Most business have substantial investments in existing and legacy IT systems and the briefing will show how to integrate these with techniques such as JMS Messaging/ MQ Series, SOAP / XML or using the Java Connector Architecture (JCA).

As well as examining the main Java Application Server vendors (including Sun , IBM , Oracle , BEA and JBoss) the briefing will detail the technology stack that they offer. This stack includes Web presentation frameworks and SOA – Service Orientated Architecture at the Front end. In the middle (Business) layer this covers the capture of Business knowledge using Business Rule Engines and workflow (BPEL). At the back (Service) layer, this includes database integration using JDBC, and the Enterprise Service Bus (ESB).

What Problem are we trying to solve?Where Java Fits in Enterprise Computing.
Enterprise Application Integration (EAI).
A Componentised & Connected Enterprise.
Enterprise Java Architecture Overview.
Enterprise Java Platform Roles.
Benefits to the Enterprise.
Alternatives (.Net , PHP , Oracle , Lightweight Java Frameworks , scripting)
Scripting Languages and Enterprise Java (Ruby, Python, Groovy)
Vendors (IBM, Oracle, Sun , Bea , JBoss and SAP)
Vendor Specific Solutions (e.g. Oracle Fusion / ADF , IBM MQ )
Market Trends – Resource availability (can we get the people to do this?)

Foundation Technologies & Techniques.

Enterprise Web 2.0 and Service Orientated Aritecture (SOA).
Integrating with other Systems ( Legacy Systems, Oracle etc)
Enterprise Java Beans 3
Middleware (MOM, Rule Engines, Workflow)
Java on the (Enterprise) Desktop
Web Services / Enterprise Service Bus
Best practices (Code standards, Build standards, Version Control / Iterative Development / Junit)
UI Layer: HTML, Servlets, JSP, XML/XSLT.
XML’s Role in the Enterprise.
Application Tier: EJB, JNDI, JDBC, JDO.
Integration Technologies.
Java Connector Architecture- JCA
RMI, CORBA/IIOP, SOAP.
Security – Application and Server Level
Java Access & Authorization Service (JAAS).
Object-Orientation & UML.
Design Patterns.
Frameworks (Struts , JSF, ADF, DWR, Spring, Hibernate)
.Net interoperability

Enterprise Java Application Architectures.

Overview of Enterprise Application Servers.
Commercial Application Servers.
Distributed Application Models with Enterprise Java.
Enterprise Java Application Server Basics.
How to Choose a Enterprise Java Application Server.
Enterprise Java Application Architecture.
Building a Enterprise Java Application.
Deploying the Application.

Enterprise Java & Your Business.

Planning for Migration.
First Steps.
The Implementation Plan.
Organisational Challenges.
What’s next for Enterprise Java?

Close.

Day 5 of the Exoftware Agile Course at UCD Dublin

If you’re very observant , you might notice that this post is about a week late. Still , here are my notes on the slides / nodes from the final day of the Agile course.

Previous Posts from the training course are:

Exoftware Logo

Junit Introduction

  • Junit
    Framework for writing automated unit tests (don’t need to use Junit
    to write the tests , but it helps)

  • All Junit
    tests extend TestCase

  • Individual
    test methods (pre Junit 4.0) : public void testSomething() method
    signature

  • Use
    assertEquals assertTrue assertFalse assertNull assertNotNull
    assertSame and fail methods for testing.

  • SetUp() and
    tearDown() methods called before and after each test method.

  • TestSuites
    (groups of TestCases) replaced by Ant and (Eclipse) IDE
    functionality

  • Run tests via
    built in Text / Swing test running , or more likely use IDE / Ant
    integration.

  • Organise via
    same or paralell folders

  • TestMyClass
    or MyClassTest

Mock and Stubs

  • Problem: some
    classes (Collaborating Objects) can be tightly bound to system
    resources (e.g. File or Database) or to a hard to test API. Another
    example is the observer pattern. How do we unit test these?

  • Solution: use
    fake object , pass it to class under test , allows testing of the
    class at a unit level.

  • Stub : fake
    object that uses hard-coded data , often following an API. Many
    ready made stubs available (e.g. For the JDBC libraries).

    • Replace
      expensive to create objects

    • Have to
      create all objects that production code interacts with.

    • Start in
      middle and develop outwards

    • One failure
      can ripple out / appear elsewhere.

  • Crash Test
    Dummy: type of stub that deliberately fails in order to test
    exception handling – simulate database crash or I/O full.

  • Self Shunt is
    where the unit test itself implements the interface (doesn’t work
    for classes) and gets callbacks from the class under test.

  • Mock Objects
    like stubs, except that they are intelligent enought to self-verify.

    • Mock
      Secondary objects (normally ones that we build) instead of API (as
      Stub does)

    • Outside in
      development style

    • What if mock
      implementation is incorrect?

  • Interaction vs. State: In
    state-based testing you check the tests by examining the state after
    the stimulus. In interaction based testing you check the right
    interactions were triggered by the stimulus – Martijn
    Fowler,
    http://martinfowler.com/articles/mocksArentStubs.html

  • Mock objects
    tend to test more the interaction between objects rather than a unit
    test of the object itself.

  • Stub rather
    than mock external API’s

Smells and refactoring.

  • Code smells
    are bad or suspect design decisions in code.

  • Not always
    bad , but should be looked at (often will involve a trade off)

  • Smells are
    often hard to understand , hard to change code.

    • Samples :
      duplication / long methods / poor naming / tightly coupled classes
      / switch statements /

  • Refactoring :
    Small , controlled changes to codebase , so that it continues to
    compile / tests run to improve the design. The behaviour remains
    exactly the same.

  • Seperate
    refactoring and adding additional functionality.

  • Easier with
    automated tools and Unit tests to confirm that nothing has broken.

  • Refactoring
    != Rewrite. Codebase is evolved , not thrown away.

User Stories

  • In some ways
    , equivalent to Use Case from Predictive methods (but with subtle
    differences).

  • Represent
    chunk of functionality that makes sense to the customer.

  • Can be
    represented as card / conversation / paper based documents (more
    predictive approach).

  • In Agile (as
    opposed to predictive) , shift the focus from writing to talking
    i.e. Get a true understanding of what the customer wants , even if
    they haven’t expressed it very well.

  • Lessen the
    importance of requirements

  • Support
    iterative development and participatory design.

  • Even a simple
    requirement has many possible permutations (that lessen the odds of
    getting it right.

  • Not just a
    generic user – but more user roles – groups of users that do
    different things with the system , depending on their experience ,
    task at hand etc

  • User Stories
    should be Invest:

    • Independent

    • Negotiable

    • Valuable

    • Estimatable

    • Small

    • Testable

  • Templace
    (FlashCard , as used by Xplanner)

  • Be careful of
    size

    • too big and
      cannot be used for estimated (break these down into smaller
      stories). Easy for Compound , but for complex stories might need to
      do some research and then break out.

    • Too small ,
      and it is not worth the admin of estimating each. Bundle them up
      into higher level task like UI improvements or bug fixes.

  • User Story
    should give us the acceptance tests

Next version of NoUnit (a JUnit Extension)

NoUnit is an open-source code coverage tool that shows you the effectiveness of your JUnit tests.

After a suitable pause , I’m now thinking of starting work on the next version of NoUnit. Some of the features I’m thinking of including are:

  • Eclipse Plugin , so that you can run NoUnit code coverage reports as easily as you do JUnit tests in Eclipse.
  • Support for JUnit 4 and Java 1.5 Annotations
  • Support for EJB 2.0, EJB 3.0 and Spring – currently NoUnit only shows direct calls between Java classes.
  • Various outstanding bugs and change requests from users.

Is there anything else you think should be included? Leave your comments here.