magpiebrain

Sam Newman's site, a Consultant at ThoughtWorks

Archive for ‘June, 2006’

I’ve been struggling with configuring a password protected Resin-deployed JMX application on windows recently. This is being blogged in the hope that Google will pick this up and make the process much simpler for someone later on.

These instructions assume you are using Resin, but should work for any container.

h3. Enabling Password Protection

Starting Resin secured using a password is pretty simple. Firstly, start Resin with the following properties:

com.sun.management.jmxremote.port=
com.sun.management.jmxremote.authenticate=true
com.sun.management.jmxremote.ssl=false
com.sun.management.jmxremote.password.file=
com.sun.management.jmxremote.access.file=

Next, you’ll need to create @jmx.access@ file, like so:

joeblogs readwrite

And a @jmx.passwd@:

joeblogs password1

p. jmx.passwd needs to be secured such that only the user running the Resin process can access the file. On Linux or Unix, this is simply a case of running @chmod 400 jmx.passwd@. However on Windows this is more involved – the “five step process(How to a Secure Password File on Microsoft Windows Systems)”:http://java.sun.com/j2se/1.5.0/docs/guide/management/security-windows.html required to secure the file is rather baroque, and worst of all makes running JMX applications secured in this manner rather hard for development teams, as this has to be done each time the file is checked out. I suspect a “Calcs”:http://www.ss64.com/nt/cacls.html or “SetAcl”:http://setacl.sourceforge.net/ script could be folded into the build, but it really shouldn’t be that hard. I suspect Sun want us all to use SSL instead.

h3. Programatically working with password protected JMX

This “sample from sun”:http://java.sun.com/j2se/1.5.0/docs/guide/jmx/examples/Security/simple/client/Client.java shows how to work with your newly password-protected JMX app:

public class Client {

  public static void main(String[] args) {
  try {
      HashMap env = new HashMap();

      String[] credentials = new String[] { "username" , "password" };
      env.put("jmx.remote.credentials", credentials);
      JMXServiceURL url = new JMXServiceURL(
         "service:jmx:rmi:///jndi/rmi://localhost:9999/server");
      JMXConnector jmxc = JMXConnectorFactory.connect(url, env);
      MBeanServerConnection mbsc = jmxc.getMBeanServerConnection();
      String domains[] = mbsc.getDomains();
      for (int i = 0; i < domains.length; i++) {
         System.out.println("Domain[" + i + "] = " + domains[i]);
      }

      ObjectName mbeanName =
          new ObjectName("MBeans:type=SimpleStandard");
      mbsc.createMBean("SimpleStandard", mbeanName, null, null);
      // Perform MBean operations
      [...]

      mbsc.unregisterMBean(mbeanName);
      jmxc.close();
    }  catch (Exception e) {
      e.printStackTrace();
    }
  }
}
Advertisements

In my post, “The Five Variables of Project Management”:http://www.magpiebrain.com/blog/2006/06/25/the-five-variables-of-project-management/, both “Marty”:http://www.magpiebrain.com/blog/2006/06/25/the-five-variables-of-project-management/#comment-1790 and “Richard”:http://www.magpiebrain.com/blog/2006/06/25/the-five-variables-of-project-management/#comment-1800 used the term ‘quality’ rather than my prefered term ‘process’. I didn’t do a good job of justifying the term process in the post, so felt a follow-up was in order.

I felt that an example would help explain my thinking. To use a not-that-theoretical situation, let us imagine a project, where the average piece of functionality takes one day to implement, and 1/2 a day to create a user-interface test. Let us also say that on average, each piece of functionality introduces 1/8 a day worth of bug. The QAs believe that too much time is being spent on automated testing, as they end up checking everyhting maually anyway to pick up problems with the automated tests. The team decides to try not creating automated acceptance tests which drive the UI, and instead create functional tests which drive the domain model rinstead, which is quicker. As a result development is faster, and the increased speed of delivery outweighs the increased bugs picked up during manual testing.

What we’ve done is is change the _process_ to increase delivery speed. What we haven’t necessarily done is decrease the final quality of the product.

Let’s pick another example. We spend a month or so gathering requirements. Then we spend a month or two developing requirements, only to find the customer has changed their mind – business priorities have changed. We then have to spend time undoing what we’ve done. We decide to change our _process_ by spending only a week gathering requirements followed by two weeks of development. This means we reduce the chance of being affected by our customers changing their mind, and if they do we only have a a couple of weeks work that could be affected, rather than a couple of months. The net result is that we deliver faster – we’ve changed our process to increase delivery speed, but we haven’t changed the quality of the final product.

Changing process _can_ affect quality, but changing process is about more that _just_ changing quality.

p(update). Update: Picked up on a thread on “TheServerSide”:http://www.theserverside.com/news/thread.tss?thread_id=41092, so there may be some more discussion over there.

In my experience (and more so that of my more experienced colleagues) there are five variables over which you can exert control to decide when – and with what functionality – you can deliver your software.

h3. Scope

In simple terms, if you deliver less functionality, it will take you less time. The problem is that often the decision as to what _not_ to deliver happens during the development process itself. This means that prioritisation of functionality from the outset is important. if half way through you need to cut scope, but the only stuff you have left is the stuff your users simply *must* have, and you spent the last three months delivering things they’d only _like_ to have, your options are limited. Priorities can change, but core functionality tends not too – concentrate on delivering that and you’ll make it easier for yourself in the long run.

h3. Time

Typically the thing over which technical people have the least control (anecdotally it seems as though the go-live date for software is defined more by sales and marketing than by need), but you can decide to deliver later to get what you want.

h3. People

Adding more people to a project _can_ make it faster – to a point. However in software adding people very rarely tends to result in a linear increase in productivity. Hiring the right people can be more efficient, but is far from easy.

Some organisations take the ‘lots of dumb people being told what to do by one or two smart people’ route, others the ‘a few smart people all knowing what to do’. I’m sure most of us (myself included) believe we hope for the later. I’ve certainly seen examples in the consultancy world where an organisation with a lower charge rate but lots of people ends up costing much more deliver than a small number of people with higher charge rates.

h3. Process

Reworking one’s process in order to be more efficient is an obvious thing to do, but hard to achieve. Depending on the flexibility of your organisation changing your process might not be easy, even if you know what it is to change. Changes mid-project – for example in order to deliver faster – tend to be limited, small changes. Retrospecitves can be a good tool for identifying what the team thinks is required, but don’t discount seeking outside help – someone from another team might have a different take on things.

A far more common type of process change occurs when people make what is often claimed to be short-term sacrifices in terms of software quality to deliver on time. Changes could involve writing less developer tests, spending less time performing manual tests, stop pairing, or spend less time ensuring consistent technical vision. When these changes really are short-term, and time is set aside afterwards to repair the damage done, this may be a viable technique. However those organisations which tend to drop quality in order to deliver faster tend to use this technique more than any other, and frequently never spend time playing catch up – leading to a team spending most of their time running from one disaster to another.

h3. Risk

Risk Management is something I’m personally becoming aware of. Making sure you have situations in which potential risks can be raised is important (a daily stand-up might be one). Periodically risks should be assessed, in terms of how likely they are to occur, and also in terms of how much damage they can create.

Some risks can be mitigated, some eliminated entirely, and others cannot be addressed by you. In any case once prioritised in terms of likelihood and potential damage, they can be mitigated or communicated to your business sponsor accordingly.

I’ve just got back, and here are some useful lessons.

Lions, Forbidden City

h3. Getting a Visa is easy if someone does all the work for you

I think it also helps that we have a office there too. I did very little other than give someone my passport, fill in an A4 form, and get some passport-compatible photographs. Only the latter was painful.

h3. Getting flights is easy if someone does all the work for you

Although checking in at Heathrow terminal 4 is another matter. I understand why BA recommend getting there three hours in advance – it took me over an hour to get into departures! The “Heathrow Express”:http://www.heathrowexpress.com/ is excellent though.

h3. Currency

Is called the Yuan, but normally simply refered to as RMB (China Yuan Renminbi). Taking large quantities in or out (5000 RMB is the limit, which is about $600) is a no-no.

h3. Power Adaptors

Australian one’s should work – but even if you don’t have them, most power sockets seem to take American adaptors too.

h3. Overnight flights are a good idea

My outbound ten hour flight departed on Wednesday afternoon, and I arrived Thursday, thereby minimising Jet Lag. The flight on the way back was OK, but I got my ass handed to me by Jet Lag – NASA reckon it can take up to one day per time zone to get over it, and I crossed about 15!

h3. I either need a new camera or more skill

As “these photographs”:http://www.flickr.com/photos/samnewman/sets/72157594158965922/ will show.

h3. Our chinese colleagues are very young

They’re also very smart and incredibly well organised. They arranged an agile conference for 500 people, and I struggle to manage an away day for 50.

h3. Five days isn’t enough

Which really goes without saying – I’m looking forward to going back. Hopefully next time I’ll be able to visit our Xi’an office and spend some more time getting to know everybody.