rosshuggett.com

Simplicity is the ultimate sophistication

2011-12-28T17:50:00.000Z

I can't take credit for the title of this post. It's one of Steve Jobs maxims and was used in Apple's first brochure. I also like "less is more" and after reading his autobiography, I liked the fact that he pushed to remove and simplify at every step of product development.

We are constantly told to simplify a product or service but never really told why or how. I particularly liked Jony Ive's philosophy. He said that we like simple products or services because we feel like we can dominate them.

This is a great way to look at it because if we feel like we can dominate them, we are more likely to feel like we are in control and consequently, use them more.

He also said that simplicity isn't just a visual style. It's not just minimalism or the absence of clutter. It involves digging through the depth of complexity. To be really simple, you have to go really deep. You have to understand everything about it and it's essence in order to get rid of the parts which are not essential.

When you look at some of the user experiences in software and the web today, you can immediately tell where the the product or service owner has gone deep and where they haven't.

Can you think of any examples where you can tell? Let me know.

If in doubt, under promise and over deliver

2011-07-17T13:19:00.000+01:00

A company I used to work for had 5 fundamental rules which it asked all it's team members to follow, of which number 3 was "Always deliver what we promise. If in doubt, under promise and over deliver".

I always have this rule in the back of my mind during sprint planning as there is always some degree of doubt when you first estimate a task. Therefore, the estimate is usually slightly higher than the amount of time I think it will take me to do the task.

If I come in early, I've exceeded expectations and if I found it was taken me longer than I thought, I come in on time and have matched expectations.

If I didn't follow that rule at all, I would have been late leading to client frustration and loss of trust in the future so I think it's a nice rule to follow sometimes.

What do you think?

Thoughts On Native v Cloud Apps a.k.a. UX v Sharing

2011-07-12T21:36:00.000+01:00

With all the recent news of the wonders of the cloud with Apple releasing iCloud and Google releasing Chromebooks, I thought I would write a post on my own thoughts on the subject. Feel free to post you own thoughts on this subject by commenting below.

The title of this post could be misleading because it suggests that these are competing technologies, and to some extent, they are. However, they also complement each other in many ways, and when choosing your own strategy, you need to think carefully about what is important to you.

I strongly believe in user experience (UX), it's what I first started off doing in my career and have still have a keen interest in. It's one of the hardest things to get right, but when you do, it's great, and users love it.

In my view, you cannot beat the UX of native apps as they work using the API's directly offered to them from the hardware you used to download them from be it a mobile phone, tablet or laptop. They are quick, don't need the internet to run and we have all enjoyed using them for many years before the internet was just a twinkle in Sir Tim Berners-Lee eye.

After being very creative on these native apps, the next thing you want to do is share what you've done with others and have their creativity contribute to the success of the work. This is where the cloud comes in and things get complicated. Let me explain.

The cloud let's you share your work easily because it's just a bunch of computers connected to each other and its those connections which makes it possible but by it's very nature, the cloud is a layer of abstraction from the device meaning that the native API's no longer become available and you loose that native UX. You also get ads as the providers have to make their money somehow.

I've found a mixture of native and cloud apps works best for me depending on what I'm doing at the time. What works for you?

Red Bee Media: A Retrospective

2011-05-06T08:57:00.002+01:00

Today is my last day at Red Bee Media so I thought I would write a retrospective of my time here.

The strongest aspect of Red Bee has been the diversity of it's talent. We've had guys working here from places I can only dream of visiting from Réunion to Xinjiang. I hope that, maybe one day, I will visit these places as I regard many people not only as colleagues, but as friends.

While everyone came from different places, we were united in many ways like work ethic, technologies and our ability to deliver projects.

This was reflected by everything we achieved in those years. When I look at the position we are in now and what we have delivered in that time given the people we had, it was been nothing short of remarkable and I think I leave the guys in an excellent position to continue that success.

I have always felt that the team was at it's best when individuals and interactions were favoured over anything else and this reflected in the speed at which we delivered projects. Let's hope this continues in the years to come.

I can honestly say that the learning experiences I have gained here, working with what I considered to be the brightest minds in the industry, has been phenomenal. In particular, many aspects of agile development including test driven development which, if you are a regular reader of this blog, you will notice that I strongly believe in.

My first thank you has to go to Stacey Anklam who gave me the job. I never thought it would turn out the way it has. For their leadership, Shams Uddin and Ross Weaver who have given me advice and support during my time here, and for their technical leadership, Dilshat Hewzulla and Bertrand Payet who's knowledge never fails to impress.

They were the reason why my time here flew by.

I hope that I get the opportunity to work with the guys again sometime soon but in the meantime, I will miss them all.

Don't spend too long on tests

2011-03-22T15:06:00.000Z

If you are a regular reader of this blog, you will know that I strongly believe in test driven development (TDD). However, I wanted to share my experience of learning TDD with you so that if you are learning it for the first time, you don't fall into the same traps I did.

When you are writing your tests first, and find that it is taking some time, stop and ask yourself, why is it taking so long? The tests, like the development, should be simple and quick to do. Don't forget you still have to do the actual development and the project manager will be asking you to demonstrate what you've done before you know it.

So, if they are taking some time, it usually means that you have began to do the following:

Started to test features that you shouldn't be testing. Remember that you should only be testing what you've developed, not what somebody else has. Check your test boundaries, make sure you haven't gone outside them. If your test is something like 'Test call a web service should return back a response', make sure that your not testing 'Test call a web service should return back a response and make another web service call'. Ask yourself, what are my inputs and outputs? In the example before, the input would be the call to the web service, the output, the response. You can then write your assertions on the outputs.
Asserting things that you should be asserting. If you are spending some time on writing some complex assertions, make sure that they are relevant to your test. Go back to your pass and fail criteria and make sure that they are covered. If they are, finish your assertions.
Write a test which has too much set up. If you find that you've just spent the last hour just writing the set up data, ask yourself, is this test worth it? This problem is usually a design problem where there is too much tight coupling with means you have to endlessly inject dependency data to get the test running. Take another look at your design and make sure that the components are loosely coupled and can be tested in isolation. TDD forces you to make good design decisions, whether you like it or not! It makes you think about things that you wouldn't normally think about.

That's all I can think of right now but I'm sure there are more. If I think of any, I'll update this post.

I'm interested to know what your learning experiences have been around TDD. Why not add them as a comment below.

I feel the need, the need for speed!

2011-03-03T14:29:00.002Z

If you don't recognise the title of this post, you probably haven't watched Top Gun. If you haven't, watch it. It's a great movie. There was a great quote in that movie:
I feel the need, the need for speed.
It's a saying that Maverick and Goose have between each other and the context is when they are flying their Grumman F-14 Tomcat. This saying is as relavent to software engineering as it is flying a F-14 believe it or not.

The reason why I say this is because when you are designing and developing software, there is a need for speed, or put another way, don't be slow.

So when you are thinking about a design problem or using a framework or tool during implementation, ask yourself the question, will this slow me down?

If your answer is yes, then rethink the problem, or ask yourself should you even being using that framework or tool in the first place? If it's slowing you down from delivering a goal, then don't use it. It's a simple as that.

Too many times I've seen a solution to what appears to be a simple problem, and it's taken a month to develop where is should have taken a week. When you start to look into the reasons for that, you start to see complexity which shouldn't be there. Usually, what has happened, is that complexity has been introduced which has nothing to do with the problem inhand like some future requirement which will never materialise.

For me, agile software development and processess is my F-14. If there's anything slowing down my F-14, I need to quickly address it otherwise a MiG-28 will shoot me down and I'll stop delivering.

Writing Your Tests First Using Cordys 'ExecuteProcess'

2011-03-01T14:04:00.004Z

This post is mainly for Cordys users who want to test their business processes's first and in isolation.

Before writing your business processes, you can use soapUI and the ExecuteProcess WSDL to generate bindings and create a test suite. Next, create a new test case and a new test step which is a soap test request. Select ExecuteProcess as the operation and generate the soap message. It should look something like this:


   
   
      
         [YOUR_FLOW_NAME]
         definition
         
            <[YOUR_FLOW_NAME] xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">[YOUR_INPUT_MESSAGE]</[YOUR_FLOW_NAME]>

You can see from this example that inside the message element, you can drop your input message for your business process. When you submit the request to the endpoint, Cordys will find the business process and invoke it with your message. Sadly, the response you get back isn't the output of the process so you can't do some nice assertions, but it's goes someway to test automation.

If your flow is just orchestrating other services, you could call that service to assert that whatever it is that your flow is doing, that it did it properly.

When you come to write you business processes, now that you have your test cases, it should be breeze!

For me, ExecuteProcess is the ESB part of Cordys. It can be used for many other use cases, not just for testing. It offers a layer of abstraction between the caller and the underlying business processes. Do you agree? Let me know by commenting.

What they don't teach you about properties files in school

2011-02-20T09:10:00.001Z

Properties files. There seems to be very little written about these files. When you are taught programming at school, you are told that they are a way to configure your application.

When I was told this, it didn't mean too much to me and I didn't explore it anymore. When I started to use spring, and learnt about inversion of control and dependancy injection, it started to mean more but I was still developing code which was tightly coupled with the environment I was deploying it to.

For example, I would create artifacts called mock-service-1.0-development.zip and mock-service-1.0-test.zip. The only difference would be an ip address or a url. This approach is okay if there are only a few environments, but as soon as you add more environments, your service can get complicated and difficult to maintain.

When I started developing in Mule, I started to use properties much more for environmental configuration and found the advantages that it brought.

I created a single artifact called mock-service-1.0.zip and a properties file for my local environment. It looked something like this:

mule.host=localhost
mule.service.port=8081

I then gave these to the environment manager and explained what each of the properties meant. I told him that he could generate a properties file for any new environment, or if there was a change to the existing environment, he could just change an existing file and I didn't have to get involved.

We started off in a development environment with a SNAPSHOT version which gave us the ability to flesh out any integration issues or identify any properties that he wanted that I didn't include. Once we got it working in development, I would then release it and he would deploy to any another environment he liked in exactly the same way. This made deployments seamless.

I hope this example goes someway in explaining a good use case for properties files. I intend use them as much as I can in the future for deployments.

The Time Tunnel and How To Avoid It

2011-02-14T13:22:00.001Z

Too often I've found myself in the following situation:

I have a task, so I've followed my admin reference and have a card, a Jira issue and it's on the whiteboard. I've timeboxed it to say, three hours and I've begun work.

So I'm working away on the task and before I know it, I've burnt two hours and I've got a hour left to complete it. In the last two hours, something strange has happened. The task has got more complicated and is probably going to take longer than the three hours I originally time boxed it at. The problem is, I haven't seen it yet.

So I carry on into the third hour, thinking I'm going to be done at the end of the hour and when I reach it, I realise that maybe it's not going to be done in three hours, but I'm thinking that it's only going to take another thirty minutes.

Thirty minutes pass, and I'm still not done. An hour passes and, guess what, I'm still not done. I'm stuck in what I call, the time tunnel.

This is where your mind is so focused on the problem, that there is very little cognitive capacity left for time planning.

So when you begin a task and you enter the time tunnel, you see the end after three hours and you head towards it. After two and a half hours, you think it's thirty minutes away, but in fact, it's another hour away, so you keep going and before you know it, you've spent five hours on the task and your still not done.

This is a bad situation to be in because there was probably an expectation that you would be done by now and you've failed to deliver the task.

When you're in the time tunnel, the walls don't appear to have an emergency exit. The best advice I can give is that whatever state the task is in halfway through, try to stop and take a step back and look at what you've done. If you think that it's going to take longer, then add more time to the task.

What I've leant is that guys like to be told as early as possible if the task is going to take longer than first estimated, as it gives them more time to plan if it is part of a wider task.

I hope this helps people who have been in this situation before. I know I have and I'm hoping to refer back to this article to remind myself what to do.

Thanks for reading.

rosshuggett.com now on Facebook

2011-02-13T16:42:00.004Z

I'm pleased to announce that rosshuggett.com is now on facebook. So you can enjoy your favourite posts right from your favourite social networking website. Enjoy!

Using SCP with the Maven Deploy Plugin

2011-02-13T09:19:00.003Z

If your using the Maven Deploy Plugin and you want to use SCP to deploy your artifact to a maven repository, here's an example you can try:

mvn deploy:deploy-file -Durl=scp://[hostname]/[maven_repository_url] -DrepositoryId=[repository_id] -Dfile=[your_jar].jar -DgroupId=[group_id] -DartifactId=[artifact_id] -Dversion=[version] -DgeneratePom=true -Dpackaging=jar

You need to run this in the same directory as your jar file. Hope you find this useful. Let me know if you have any questions.

Software Engineering - An admin reference

2011-01-09T14:38:00.008Z

Here is another one of those posts which I intend to use as a reference when I start a software engineering task or project (however small) and thought it would be useful for the community.

They aren't involved with the actual design or implementation of the software itself (generally), but are important in the success of the project:

1. Jira - I have found that using Jira has brought many benefits during the software development process. It is an excellent tool for collaboration as it follows closely with agile software development methodologies like the creation of user stories. I have found that it's a better form of conversational communication than email as it allows conversations to be grouped by user story making them easier to refer back to and search. Email conversations can be difficult to follow and tend to get sorted in personal folders and forgotten in time. Another benefit is that it also forces accountability as issues are allocated driving clear ownership.

2. Index cards on a white board - This is the creation of a simplified snapshot of what is going on in jira. Index cards are used to write the detail of the user stories that have been created in Jira. They are then stuck on a whiteboard. The whiteboard is broken down into 3 sections, assigned, in progress and done. The cards are then moved into the different sections as the task progresses. The information on the cards includes the Jira issue number (both epic and story), the environment the task is dependant on, the title of the task, who is responsible for the task and the hours remaining to completion. These cards can then be used in the daily stand up or scrum to determine how much time is left on the story and if the sprint goals are to be realised.

3. Test first - I consider creating your tests first to be one of the most important things to do before any code implementation. It forces you into making good design decisions and makes you think about problems up front before it's too late. It's a good idea to split out the tests into separate user stories to ensure there is time for this to be done.

4. Demo - I have been lucky enough in my career to work with some of the brightest minds in software and I've found that the single most effective way to harness this powerful resource is a demo. Getting guys in a room with a whiteboard and showing what you've done by way of an activity diagram (depending what you've done) or a live demo is a great way of getting immediate feedback on your approach. It makes you think about things that never even crossed your mind and you will find that you barely have time to write everything down. I highly recommend it.

5. Wiki - I've found that certain types of information are useful to have as a webpage and wiki's invite all users to edit and create new pages within the wiki web site. It is an excellent collaborative tool with useful information like release notes and best practices to name but a few.

6. Document repository - When dealing with external organisations I have found that Basecamp is an excellent document repository tool. I haven't used it too much but it has fast become the point of contact when you want the most up to date document on an interface which has been agreed with an external organisation.

I can see this list changing considerably over the days and months to come but that's all I can think of right now. If you know of any more that you use, let me know.

Update: 10th January 2011 - I've thought of another one already:

7. Properties file - Use properties files where possible to store configurable values. I've found that they are particularly useful when decoupling your software from a deployment environment.

Update: 21st January 2011 - Here's another one:

8. Peer Review - I really like doing peer reviews but I don't want it to slow down development. I think that the best approach is to have a driver and observer, as in pair programming. The driver writes the code, and the observer checks it out, writes in-line comments and commits them. The driver updates, reads them and actions if necessary. I think this is quick and increases quality.

Refactoring: Why go back to a product or service you've just delivered?

2010-12-13T21:52:00.001Z

This is the second post of a two part post on question answering. The theme for this post is refactoring and the question is:

Why go back to a product or service you've just delivered?
This then leads onto other questions like:

Why should I pay for you to go back to a product or service I've just paid for?
In answer to the first question, one of the main reasons is technical debt. As part of any agile software development with short iterations the goal at the end of the cycle (typically two weeks) is to have a workable piece of software which can be run in a production environment.

The developer may have a to work very quickly in order to achieve that goal and subsequently there maybe be areas in the design or implementation where he or she would like to go back to in order to make it easier to work on in the future.

This maybe in the form of comments like this:

/**
 * This class does something. 
 *
 * TODO Remove some parameter from the something method.
 */

or a simple note on a UML diagram.

It could be that unit tests levels might have fallen or there maybe not much in the way of documentation for the support team.

During the next sprint, the developer must be given some time to go back to address these areas otherwise you may see longer sprint cycles (from two to three weeks) and goals rolling forward from one sprint to the next, pushing delivery further and further back.

My Google Alphabet

2010-12-10T18:39:00.002Z

These are the words Google thinks I want to type when I type each letter of the alphabet into it's search engine:

a is for argos.
b is for bbc.
c is for currys.
d is for debenhams.
e is for ebay.
f is for facebook.
g is for google maps.
h is for hotmail.
i is for itv.
j is for john lewis.
k is for klm.
l is for lotto.
m is for msn.
o is for o2.
p is for play.
q is for quidco.
r is for rightmove.
s is for sky.
t is for tesco.
u is for utube.
v is for virgin.
w is for wikipedia.
x is for x factor.
y is for youtube.
z is for zara.

It's got it right in some cases, but in others, it's way off!

Pair programming: Isn't it just two people doing the same task?

2010-10-26T08:51:00.004+01:00

This is the first post of a two-part post on two separate subjects but a similar theme. The theme is question answering and the first subject is pair programming and the question is:

Isn't it just two people doing the same task?
This then leads onto other questions like:

Why should I pay two guys to do the same task when I could be paying for just one?and:
Can you do the task in half the time?
all of which are valid questions which need answering so lets take the first one: Isn't it just two people doing the same task? Yes, is the short answer but if you have two people working on the same task you get shorter programs, better design and fewer bugs, than one programmer working alone.

Traditionally, these benefits were gained by having a code review after the task has been completed. However in my experience this slows down the development process because it takes time for the reviewer to go through the code, identify any issues and feedback to the developer. The developer then has to make the change, retest and deploy the new version. Pair programming could have caught the issue at a much earlier stage preventing this cycle.

If the issue is one of design e.g. a badly designed interface, then the problem can be much harder to change once the implementation is complete.

In answer to the second question: Why should I pay two guys to do the same task when I could be paying for just one? Studies have found reduction in defect rates of 15% to 50% depending upon programmer experience and task complexity. So that means you will pay less for testing and debugging later on in the development process.

In answer to the final question: Can you do the task in half the time? Yes, pairs usually complete work faster than one programmer assigned to the same task. However the total programmer cost can increase so the manager needs to balance faster completion of the task with reduced debugging and testing against the higher cost of coding. Analysis of the task and collaboration with the pair is also required to decide if pair programming is appropriate because some studies have shown that where the pair have a good understanding of the task, pairing can result in a drop in productivity.

If you did have any of these questions, I hope this post has helped to answer some of them. If you have anymore questions, please post them as a comment and I'll try to answer them.

tweet-a-trade has a new logo!

2010-08-27T09:57:00.000+01:00

tweet-a-trade has a new logo:

Many thanks to Amanda Layton for the design. This is an important step for the tweet-a-trade brand because it shows the partnership with Twitter and also distinguishes itself as a standalone brand.

Footy! is Live!

2010-08-20T13:22:00.002+01:00

Footy! is Live! Congratulations to Amanda Layton, David Nicholson, Frank Sagnier and all the guys in Sweden for their pioneering work in social gaming. The fusion of technology and art in this game will surely make it a bit hit! Well done again guys.

tweet-a-trade

2010-08-10T08:00:00.001+01:00

I've created a new service called tweet-a-trade. I'm hoping that it's going to help local people find local tradespeople. The next time you need a local tradesperson, give it go. You might find that it's easier than you think.

Using Netcat for testing web service calls

2010-06-16T20:12:00.001+01:00

I recently found myself in the situation where I was using Mule to invoke a web service but it was failing with an exception.

I'm not going to talk about Mule or the exception as it's not the subject of the post but what I am going to talk about is how I solved the problem with the help of Bertrand Payet and Dilshat Hewzulla.

Instead of Googling the exception, I wanted to see how Mule was creating the SOAP message because I had a feeling that it was the message itself that was causing the problem. So what I did was use Netcat as a listener for the SOAP message.

I did this by running Netcat and got it to listen on a port:

macbook:~ rosshuggett$ nc -l 8787

In this example, the port I've specified is 8787 but you can choose any port you like. I then defined the Axis outbound endpoint address in Mule to point to the listening Netcat:

Now when Mule creates the SOAP message, Netcat will consume the message and show it to you on the command line:

POST /[you're endpoint] HTTP/1.1
Content-Type: text/xml
X-MULE_ENDPOINT: http://localhost:8787/[you're endpoint]
SOAPAction: http://localhost:8787/[you're endpoint]
[you're parameter]:[you're value]
style: wrapped
use: literal
Authorization: Basic aXR2dXNlcjppdHZ1c2Vy
User-Agent: Jakarta Commons-HttpClient/3.1
Host: localhost:8787
Content-Length: 972



 
  
   d85554ff-7936-11df-9ca2-eb06d9f0a905
   -1
   -1
  
 
 
  [you're soapenv:body]

I then used this to check the SOAP message and found it was incorrect causing the exception.

I've used Mule as an example of a client calling a web service, but you can of course use you're own client like SoapUI to generate the web service call and it will work in the same way.

Update [22nd March 2011] : Here's a nice Windows port.

Solution to 'svn: authorization failed: Could not authenticate to server: rejected Basic challenge' error

2010-06-01T14:33:00.004+01:00

Here's another post of something that I wanted to make a note of and decided it would be useful for the community. I kept on getting an error when when trying to do a Maven release. I was using the command:

mvn release:prepare

and getting the following:

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: Commit failed (details follow):
svn: OPTIONS of '[subversion-url]': authorization failed: Could not authenticate to server: rejected Basic challenge (http://[subversion-host])

I'm not sure where my authentication details were getting lost, but as a workaround, I added the authentication on the command line:

mvn release:prepare -Dusername=[username] -Dpassword=[password]

It took me a while to figure out this one out as there didn't appear to be a straight forward solution on the internet so hopefully if anyone comes across this problem, it will help them out. It only seems to effect mac users.

Let me know if you have any problems.

Finding classes in jar files

2010-05-26T17:13:00.010+01:00

I've used the following command quite a bit to see if a class file exists as a dependancy in a jar file:

find . -name *jar -exec grep [name of you're class file] {} \;

So an example might look like:

find . -name *jar -exec grep AbstractTransformerTestCase {} \;

If there is a match, you should see something like this:

Binary file ./lib/mule/mule-core-2.2.1-tests.jar matches

You can then verify it:

jar tvf lib/mule/mule-core-2.2.1-tests.jar | grep AbstractTransformerTestCase

and you should see:

4270 Tue Mar 24 15:14:12 GMT 2009 org/mule/transformer/AbstractTransformerTestCase.class

I wanted to make a note of it so that I didn't forget it so I decided to put it on here. Now everyone can enjoy it too! Hope you find it useful. Thanks to Bertrand Payet for his help.

Let me know if you have any questions.

The balance between scalable code and keeping it simple

2010-05-09T11:55:00.004+01:00

It's been a couple of months since my last entry in this blog so I thought I would spend some time to think about an idea which has been on the back burner for while.

I originally thought about this problem back in January but have only just got round to writing about it. The problem is about making software scalable and future proof enough to handle changing conversational stories but also not over complicating the code in order to facilite this mandate.

I've seen architects and developers pour over UML diagrams trying to think how they can design their software so that it can handle a future requirement that they know nothing about. In my experience, some users don't know what they want now, let alone in the future.

The problem with this approach is that you can end up with code that is wrote to try to satisfy a future requirement but has made it too complicated in the process. So when a real requirement comes along, it can be different to what was originally predicted and can take longer to implement. This could happen for a number of different reasons, there could be a different developer who is trying to understand some complicated code or the developer might have to go back and do some refactoring in order to implement the new change.

A typical example of this might be where a hash table has been used to abstract the real type in an interface. So if you had an interface which looked like this:

public interface Communication() {
  public HashTable getTypes();
}

you can add Communication types easily without having to change the interface, it does make it more difficult for the developer to read and understand as you don't know what the types are unless you go deeper into the code. It might have been better just to make the interface look like this:

public interface Communication() {
  public Letter getLetter();
  public Email getEmail();
}

This way, you avoid the complexity of having to retrieve the hashtable, iterating round it to find the type you want and then retrieving the data. The operation alone can be heavy, especially if you're hashtable is big.

Another example could be a class which might share some similarities with another future class you don't know about yet. You can create an abstract class and give it an abstract name and create a light weight class which implements it.

The future class never materialises or another class comes along which turns out doesn't quite fit with you're abstract class, so you can't extend it and you end up with complicated code again.

Whilst these examples are quite simple, when you are faced with more complicated problems it's important to try to strike a balance between making you're code open to future requirements but also keeping it simple enough so that it can be understood.

Edit: 11th January 2011 - What I'm talking about here or course it type safety. The hash table is an example of weak typing.

SSH tunnels - what they do and how to create one

2010-03-20T12:27:00.009Z

Creating SSH tunnels seems to be an area where some developers struggle with so I thought I would write a post on what they do and how to create one.

If you work in an environment where there are lots of firewalls slowing down the speed in which you can deliver, creating an SSH tunnel can be the solution as long as you know a machine which you have SSH access to which has access to the machine and port you want to connect to. The best way to explain this is through a worked example.

So, say you have the machines x, y and z:

x has an ip address of 192.168.1.100
y has an ip address of 192.168.1.101 and the authentication details ross:pwross
z has an ip address of 192.168.1.102

You are on x and you want to connect to z via port 8080 but it's blocked by a firewall. x has SSH access to y but not z. y only has access to z via port 8080. You can test this by ssh'ing to y and running:

telnet z 8080

If you get back an error message like this:

Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host

you don't have connectivity. If you get anything else, you have connectivity.

If you are running a POSIX based operation system like Mac OS X or Linux, you can just use the command line to setup your tunnel:

ssh -f -N -g -4 -L 8081:[z]:8080 [username]:[password]@[y]

So, using the ip address's and authentication details specified above, it would look like this:

ssh -f -N -g -4 -L 8081:192.168.1.102:8080 ross:rosspw@192.168.1.101

Now all you need to do is check that you have connectivity to z from x, so you can run telnet again specifying the port:

telnet 127.0.0.1 8081

Noticed here that I've specified localhost (127.0.0.1). If you want to make this a more recognisable hostname, you'll have to put an entry in your hosts file like so:

# 192.168.1.102 z
127.0.0.1 z

Notice that I've commented out z's real ip address. Now I can run:

telnet z 8081

If you are running Microsoft Windows, you can use PuTTY to setup your tunnel.

First, type y into the hostname box (I've put the ip address in for y):

Navigate down the 'Tunnels' Category in the left hand side box. It's under 'Connection' and 'SSH'. In the destination box, type z:8080. You can see I've put the IP address in again. In the Source port box, type 8081:

Now click 'Add', and you'll see it in the forwarded ports list:

Click 'Open' and it will start up a session where you'll need to authenticate with y's details again. Once the session is established, repeat the hostname entry part above, and you'll have connectivity.

Let me know if you have questions.

Mobile UI design and patience

2010-03-13T11:25:00.005Z

This is a bit off topic for me as I haven't done UI design for a while but I've been looking at how people use mobile UI's and wanted to get some recent observations down.

When I used to do UI design, we used to think a lot about users who sit down in front of a computer with a screen, keyboard and mouse and look at how they use websites.

At first, we had a lot of time to play with, as the expectations were less a few years ago. Users had time, concentration spans lasted longer as users had the patience to wait for pages to load and find their way through complicated UI's to what they wanted to do.

As time went on, expectations on the speed of a service increased and they had less patience for a slow service and a complicated interface.

What I notice now, in the mobile space, is that users aren't sitting down and they don't have a mouse and keyboard. This may sound obvious, but it's relevant. They have a screen and a finger and task to do and that's it.

The amount of time, concentration span and patience they now have to perform a task has been drastically reduced to a few seconds. If you're UI is complicated or you're service slow, it simply won't get used.

A good example of this is a service I've been trying our recently, foursquare. On my mobile (which happens to be an iPhone, but's it's available for Android and Blackberry), the app loads in about second, and you are immediately presented with a big 'Check-in' button:

This is good because most of the time, this is all I want to do and I want to do it very very quickly. The reason is that if I'm at a new place, I probably want to do something else other than check in, for example, if I checked in at the gym, I want to work out.

In this scenario, I don't want to see who's here or do anything else. I might later want to look at my history and use this data to see if I've been going to gym enough times to warrant carrying on with my gym membership, but for now, I just want to check in.

Other times, if I'm out at a social event, I might want to spend more time to look which of my friends are here and meet up with them.

I hope you enjoyed reading this. What do you think about mobile UI development?

Simplest way to update Twitter?

2010-02-22T12:25:00.003Z

Is this the simplest way to update Twitter?

curl -u [username]:[password] -d status="[status]" http://twitter.com/statuses/update.xml