Security Seminar in Dublin on 7th September 2006

Brian Honan of BH Consulting passed on news of a Security Seminar in the Burlington Hotel Dublin on the 7th September 2006. If you’re interested in attending , contact Brian directly. The seminar is part of Global Security Week, (http://www.globalsecurityweek.com). The seminar is free and open to all who wish to attend.

BH Consulting Logo

This year, the theme for Global Security Week is IDENTITY THEFT and as part of this years event a free seminar on Combating Identity Theft will be held on Thursday the 7ths of September at 2:00 p.m. in the Burlington hotel. The purpose of the seminar is to make individuals and companies aware of the threats posed by Identity Theft and how to protect yourself and your company from becoming a victim of this fast growing crime. The US Treasury Department in a recent report says that cyber crime has now outgrown illegal drug sales in annual proceeds, netting an estimated $105 billion in 2004. A recent report published in the Unitised Kingdom shows that companies in the UK have lost over STG£50 million as a result of company identity theft in 2005 alone.

Highlighting the dangers posed by Identity Theft and how individuals and companies can best prevent becoming victims of this crime will be speakers from the following organisations:

  • The Garda Bureau of Fraud Investigation
  • ENISA (the European Network and Information Security Agency)
  • The Companies Registration Office

The agenda for the day is ;

14:00 – 14:15 Introduction
14:15 – 15:15 Identity Theft in the Real World – Garda Bureau of Fraud Investigation Protecting your online identity – Garda Computer Crime Unit
15:15 – 15:30 Coffee
15:30 – 16:00 Identity theft – ENISA (the European Network and Information Security Agency)
16:00 – 16:30 Protecting your Company’s identity including demonstration of CORE – Companies Registration Office
16:30 – 16:50 Panel Discussion – How Best to Combat Identity Theft – Panel will include speakers from the day
16:50 – 17:00 Close
The seminar will be hosted in the Burlington Hotel on Thursday the 7th of September from 2:00 p.m. Registration is open to anyone concerned with Identity Theft and places can be booked by simply replying to this email or contacting us on 01 4404065

ABOUT GLOBAL SECURITY WEEK

Global Security Week is a global security awareness initiative in the week leading up to September 11th every year. The idea is simply to coordinate and encourage a wide variety of security-related awareness activities worldwide in that week, taking advantage of the obvious focus on security by the world’s media.

The theme for this year’s Global Security Week is identity theft. During the week, September 4th to 10th 2006, a number of events, workshops and awareness raising activities will take place worldwide to educate, inform and better prepare people to tackle the growing problem of identity theft.

Global Security Week is a public awareness initiative, not a commercial or political venture. We are not trying to obtain funding, de-rail other security awareness activities, nor focus on any particular aspect of security (such as terrorism, information security or physical security). Global Security Week is deliberately designed to be a broadly-scoped event but with a long-term aim to become the main focus for security awareness activities in years to come.

Against a backdrop of global terrorism and organised crime, security in general (and information security in particular) has become a vitally-important sociological and business issue. Commercial and governmental organisations are investing heavily in technical security controls but the security problems caused by people remain largely unaddressed.

Whilst responsible businesses and individuals employ a wide range of security measures, the global Internet community suffers as a result of those irresponsible businesses and home users who remain largely unaware of security. Hackers and spammers frequently take control of insecure Internet-connected systems, for example, to use as platforms for their attacks. Raising the general level of security awareness is the only feasible means of addressing this issue.

For more information about Global Security Week please visit www.globalsecurityweek.com

UCD Module on Autonomic Systems

Want to know what we’ve been up to in the module on Adaptive Software? Simon Dobson’s Home Page (the course head) is as good a place to start as any.

When you understand Adaptive Middleware , replication , self -management , context collection and self-directed systems management , please let me know. It seems a long time since we covered these topics back last November and I’m currently ploughing through them preparing for the exam at the end of next month.

Apparantly Fuzzy logic isn’t just something that happens down the pub after a few pints, it’s alive and well in the chip that controls your washing machine. The theory of fuzzy logic does not cover what happens where all the odd socks disappear too.

It's been very quiet over here (aka what has Paul been up to) – Enterprise Web 2.0

It’s all been very quiet over here , too quiet. And not just because of the hosting issues (the people at Netbunch, you know that I’m talking about you)

It’s been very quiet , because I’ve been very busy. On top of all this , we’re coming to the end of the year for the (part time) Masters at UCD in Dublin, so we’ve also got exams coming up. Thankfully it’s the last year, the downside being I have a dissertation to write.

Being a blogger , I’m not happy putting together a weighty tome that will sit gathering dust on a shelf. Instead , I want something that will solve some business problems , and that I can use as interesting content. So after much thought , the proposed title of my dissertation will be …… cue drum roll ….. ta-da!

Enterprise Web 2.0

Now, if you’ve talked to me , you know I spend a lot of my working day as an Enterprise Java Consultant , working for various banks. The idea is to take some of the Web 2.0 ideas (and you don’t need me to repeat them) and apply them to the sort of problems large companies have. Or , if you want the catchy subtitle , ” it’s all about sucking the knowledge out of people’s brains and putting it onto (ugly) websites”.

So an obvious topic to cover is the use of Ajax , which while big on the web at the moment , is going to be huge once companies realise what it can bring to their internal applications. The rest of the topics cover knowledge management (what is web 2.0 if it’s not about sharing knowledge), but also some tools and techniques that will all Enterprise Java (with all it’s robustness and scalability) compete with the nimbleness and tricks of Ruby.

Business Problem 1: How to present this information to people in a easy to deploy, but powerful way.
Solution: Update to Sun Java article – this one on how to do Web 2.0 / Ajax ‘right’ in Enterprise Java (i.e. not worrying about legacy code)

Business Problem 2: Where you have documentation, but don’t know how to find it.
Solution: Write up of the Red-Piranha Adaptive Search engine that ‘learns’ what the team wants , and finds more of it.

Business Problem 3: Where you have information in Excel sheets, but can’t do much with it.
Solution: Update to previous O’Reilly Articles on JBoss Rules – this one on JBoss’ ability to ‘run’ Excel Spreadsheets.

Business Problem 4: Where you have information that people ‘know’ , but that a machine finds it hard to ‘learn’
Solution: Simple Neural Networks using Joone, applied to a ‘real life’ business problem.

Business Problem 5: Where several people have to work together on a set of information , following a strict set of steps.
Solution: JBoss workflow, with a simple online example

Caspar Weinberger and how to do presentations.

The Irish Times carried a report on the Death of Caspar Weinberger in it’s weekend edition. Mr Weinbeger was a contoversial but highly intelligent figure in Ronald Reagan’s Presidency (he was the US Secretary of Defense). A lot of things have already been said about him, but one almost trivial incident stood out from his obituary.

During the 1980’s , Mr Weinberger wanted to increase the Defence budget. Given that Mr Regan had a very ‘pictorial’ view on life, Caspar’s entire presentation consisted of three cartoon figures.

  • A Solider figure , made to look as wimpish as possible (short of wearing lavendar), to represent the Democrats Defence Policies.
  • A Nerdy Solider figure , wearing glasses and with a briefcase, to repsent the ‘balanced’ approach his opponents in cabinent wanted.
  • A Rambo like figure, armed to the teeth , representing the Billions he thought the US should be spending on Defence.

Mr Weingbeger got his Billions. You may or may not agree with his objectives, but as presentation skills go, he can still teach us a lesson. Forget the details – you can talk about those later. Cartoon like images are what stick in people’s minds.

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

Day 4 – Summary of the Agile Course so far (Part 1)

Below are my notes from the Agile course so far – covering introduction to Agile projects , why it makes business sense, the use of FIT and other acceptance testing tools what Agile means for customers , managers and teams.

These notes are a good complement to the Agile presentation I gave.

Introduction to Agile

  • Requirements
    Change on project – it’s going to happen , clients (paying for the code) have the right to change their mind , accept it and get on with it.

  • Agile Family Includes

    • XP (Extreme Programming)

    • Scrum

    • Adaptive Software
      Development

    • Lean Software
      development

    • Feature Driven
      Development

    • Crystal

    • DSDM

  • Values
    wrap Principles wrap Practices

  • Values
    (from the Agile manifesto)

    • Individuals and interactions over processes and tools.

    • Working software over comprehensive documentation.

    • Customer collaboration over contract negotiation.

    • Responding to change over following a plan.

  • Principles
    (Customer Focused)

  • Deliver early, deliver often.

  • Deliver valuable software.

  • Welcome change.

  • One
    Big team (business people and developers)

  • Principles (for Management)

    • motivated individuals give better results

    • face 2 face is the best way to communicate (although accept need to
      communicate across location and across time as good 2nd
      best).

    • Remember : working software that meets business needs is the primary measure
      of progress

    • Promote sustainable development (or you’re just going into Technical Debt)

  • Principles(for Teams)

    • use technical excellence and good design to promote agility but

    • simplicity is essential

    • the best architectures, requirements, and designs emerge from
      self-organizing teams (rather than imposed from above)

    • do continual improvements to the process

  • Practices

    • Continual Improvement

    • Technical Excellence

    • ProjectManagement

    • Business Practices

    • Community and Collaboration

  • Why Agile

    • Waterfall projects : we’re most likely to find bugs in testing phase at the
      end , when (a) we’re most likely to be under time pressure and (b)
      when they’re most expensive to fix.

    • Waterfall projects: Hard to know how far through we are , as each step is
      different from the last (design has gone well , but will coding do
      better or worse?)

    • Agile:Testing is continuous, so likely to get early feedback and
      resolution of bugs. Testing = Unit Tests and Acceptance Tests.

    • Agile: Progress is steady and measurable , as we carry out all
      tasks as part of a regular cycle.

    • Productity = doing less but producing more value. e.g. Customer can prioritize
      highest value tasks and we deliver these first.

    • Standish group stats showing small projects are more successful.

    • Deploy early and often gets usable software into the hands of users sooner
      where it can start to payback it'[s investment earlier.

    • Success factors for Agile projects:

  • Enthusiastic development team/ Committed customer / Knowledgeable on-site QA
    resource / Didn’t cherry pick practices / Open workspace / Regular
    retrospectives.

  • Still hard work to do:

    • Good people give good software

    • Can be faked , so people really need to buy in

    • Practices are learnable / a lot are common sense

    • Recognize reality

Informative
Workspace

  • Person walking into ‘normal’ coding office has no idea of what is going on, nor what status it is at. Most of the stuff is in people’s heads.

  • Informative workspace seeks to communicate this information (via simple methods)in the office e.g. Notice boards, coder of the week hat , printed graphs of velocity , iterations etc.

  • Kent
    Beck :
    "An interested observer should be able to walk into the team space and get a general idea of how the project is going in 15 seconds. "

  • Similarto Kanban idea – while going for Just in Time / continual improvement , visual representations are displayed to demonstrate
    progress.

  • Information Radiators : anything that gives out info (example given of monitor running , showing latest build progress).- jokey examples of Lava
    Lamps / notes in toilet

  • Toyota (Toyota production system – recognise their edge is in how they build their cars, and not just the cars that they build).

    • Human face to automation.

    • Board giving current
      production status

    • Audible Cues

    • Ability for anybody to stop the line.

Testing and Design by Contract

  • Started by Bertrand Meyer in the Eifel Language

  • Frameworks available to add these (fully) to the Java Language – over and above the functionality available in Java 1.4 (the assert keyword)

  • Already have a contract that is enforced by the compiler in Java (e.g. Method signatures , return types)

  • Adds to this , to be a finer grained level .e.g method should return not only an Integer , but an Integer of value 0 to 100

  • Like every contract both sides (Caller and Callee) have responsibilities

  • Pre Conditions : Condition that must be true when the method is called.

  • PostConditions: Condition that the method guarantees when it returns

  • Class Invariants state what will be true at a class level (once all pre-conditions at method level / constructor level satisified)

  • Both pre and post provide additional specifiication (.ie. It is clearer to people using the code what is required / what it does). As such
    provides clearer design and additional documentation.

  • Can make code more succient by replacing ‘boilerplate’ code with standard check (e.g. Precondition param must not be null).

  • Java
    Example :

    • Pre
      Condition /**
      @require !empty() */ – as
      javadoc on method (multiple checks allowed) –

    • Post
      Condition : /** @ensure !full()*/

    • Class Level invarient: /** @invariant 0 <= count()*/

  • Exceptions

    • Pre Condition violation should give RuntimeException – provide method to test before call (e.g. IsEmpty() before doing remove)

    • Post conditions: supplier should be every effort to fulfill these : so if it can’t , it is normally due to an Exception (callee should be prepared for this failure)

  • Junit

    • Codein Junit verifies the contact of the class (and provides documented example of code use)

    • assert methods = post condition testing

    • test invarient by checks at class and not just method level (e.g. Check overall status of class, not just return value of method under
      test)

    • Pre conditions by be tested by violating these in setup (code before call to method/ class under test) and ensuring exception is thrown.

  • Think about Test as a contract.

Acceptance Testing

  • Acceptance Tests – defined (or agreed by customer) , states thatfunctionality is complete

  • Differ from unit tests in that they are system wide rather than at class/unit level.

    • Sometimes people used high level / coarse level Junit tests.

  • Unlike unit tests don’t need to be a 100% all the time (but once passed , should alway pass)

  • Automation is nice (for developer and customer)

    • Own note: Not everything in acceptance testing is automatable. e.g. UI testing.In this case automating the acceptance testing of the calculations (the 80%) means that the UI testing is a lot easier.

  • Sample Frameworks for Automated acceptance testing

    • FIT – see notes below

    • Exactor – see notes below

    • Fitnesse – FIT but wiki based (easier to do multiple tests , easier to communicate these to a team.

    • WinFIT runner

  • Inputto all these tools is close to a spec (close in that typicaluser , after one walkthrough should be able to understand what the documents mean).

  • Tests can be written before application is build (again, the notion of the tests forming a spec). A lot of the commerical tools ,
    especialy those that record against a ‘live’application, do not allow this.

Automated Acceptance Testing with FIT

  • Allows Customer s to review (if not write) the acceptance tests.

  • Previously would have done these tests manually , or via large Junit tests (i.e. Use Junit not as Unit testing , but a way of describing the entire app from the user point of view).

  • Data (unlike in Exactor) is specified as a HTML table. All non-tables are ignored (so safe to created tests documents using MS Word).

  • Fixture (connects this HTML Data) to run test against ‘production’ code.Fixtures are written by programmers (as part of proving code meets
    the spec). Three types of fixtures.

    • Column

      • One class for each table

      • Fit works through on a line by line basis – good for repeating the same action over and over again.

      • 1st Line of Table : Class Name to be tested

      • 2nd Line of Table : class variable or methodName() to be set / called

      • 3rd
        Xth lines of table: values to set or expected values to be returned

      • Good for testing Domain (Business) Logic parts of an application

    • Action

      • mulitiple class for
        each table

      • start – the class to be tested

      • enter – value to be passed into method (no return value)

      • press – call method (no input or output)

      • check – check value on method (no input)

      • Good for stimulating interaction with the user interface (or more accurately either the controller that sits just behind the user interface).

    • Row

      • Like Column , but interprets all at once (rather than one at a time)

      • extend RowFixture ,
        provide query[] and getTargetClass() methods – allows Fit to see what data structure

      • good for testing coding in the service / persistence / db layer of code.

Automated
Acceptance Testing with Exactor

  • Exactor (http://exactor.sourceforge.net)

  • Allows Customer s to review (if not write) the acceptance tests.

  • Previously would have done these tests manually , or via large Junit tests (i.e. Use Junit not as Unit testing , but a way of describing the entire app from the userpoint of view).

  • Comprises (like fit) of

    • Script – a text file thatyou could show the customer.

    • Commands : what the script calls , extends Exactor classes. These commands then call the code beingtested.

    • Command extends Junit assert –
      so usual capabilities available.

    • Command provides access to test wide map to allow storing / exchange of values.

    • Allows composites to reuse scripts.

    • Scripts allow placeholder parameters