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.
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.
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?’
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.
On Wednesday, I’m presenting on the topic of Enterprise Java at DCU (Dublin City University) , in conjunction with Trigraph.
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.
||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.
Java Connector Architecture- JCA
RMI, CORBA/IIOP, SOAP.
Security – Application and Server Level
Java Access & Authorization Service (JAAS).
Object-Orientation & UML.
Frameworks (Struts , JSF, ADF, DWR, Spring, Hibernate)
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.
The Implementation Plan.
What’s next for Enterprise Java?
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:
Framework for writing automated unit tests (don’t need to use Junit
to write the tests , but it helps)
tests extend TestCase
test methods (pre Junit 4.0) : public void testSomething() method
assertEquals assertTrue assertFalse assertNull assertNotNull
assertSame and fail methods for testing.
tearDown() methods called before and after each test method.
(groups of TestCases) replaced by Ant and (Eclipse) IDE
Run tests via
built in Text / Swing test running , or more likely use IDE / Ant
same or paralell folders
Mock and Stubs
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?
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).
expensive to create objects
create all objects that production code interacts with.
middle and develop outwards
can ripple out / appear elsewhere.
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.
like stubs, except that they are intelligent enought to self-verify.
Secondary objects (normally ones that we build) instead of API (as
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
tend to test more the interaction between objects rather than a unit
test of the object itself.
than mock external API’s
Smells and refactoring.
are bad or suspect design decisions in code.
bad , but should be looked at (often will involve a trade off)
often hard to understand , hard to change code.
Small , controlled changes to codebase , so that it continues to
compile / tests run to improve the design. The behaviour remains
exactly the same.
refactoring and adding additional functionality.
automated tools and Unit tests to confirm that nothing has broken.
!= Rewrite. Codebase is evolved , not thrown away.
In some ways
, equivalent to Use Case from Predictive methods (but with subtle
chunk of functionality that makes sense to the customer.
represented as card / conversation / paper based documents (more
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.
importance of requirements
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
should be Invest:
(FlashCard , as used by Xplanner)
Be careful of
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.
should give us the acceptance tests
Day 3 of the Agile course.
Today’s topic was mock and stub objects, refactoring and automated acceptance tests using Fit and Exactor. Worked through Video Store example (from refactoring) to remove code smells.
Will update this with feedback from the ‘How to talk to your boss about agile’ event, but in the meantime, here is all the slides and links to articles used in the Agile presentation.
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.