Book review:  '12 Essentials Skills for Software Architects', Dave Hendricksen.

The question regarding what an architect's skill set should be is usually met with answers such as: excellent knowledge of software methodologies, non-functional requirements and all around superb technical ability. In '12 Essential skills for software Architects', Dave Hendricksen challenges this view by considering what other skills are required besides technical excellence.

In summary these skills are with dealing with people and business acumen.

Some examples of the people skills:

1. If someone makes a mistake, look for the reasons why they made certain decisions, rather than dismissing them for the mistake. The idea here is that a lesson can be learnt and the same mistake should not be made again.
2. A range of communication tips from being a better listener to dealing with conflict in a professional manner.
3. Leadership tips including being prepared to eat your own "dog food", being transparent in all your work and to combine passion with a persistence so that when challenges manifest you are prepared to endure and show fortitude.
4. Understanding different psychological traits. For example, Hendricksen presents an interesting psychological spectrum where "options people" are on side and "procedures people" are on the other. Options people tend to spend too long thinking instead of doing and procedures people tend to only want to do something the way they know how to do it and by a way that they have used before.

Now, a lot of all this may come across as common sense. But, in the cut and thrust of a challenging technical environment it can easily be forgotten and usually is. This is a recurring theme of the book, a reminder of the things we can easily forget but really should not.

Regarding the business skills, Hendricksen advises that the architect should not just know the problem domain but should understand how business people think and the language they use. He suggests attending trade fairs, increasing your customer interaction and to even consider taking a reputable business course. The reasons for all of this is because it is much easier to make better decisions with people the more you understand other stakeholders' perspectives. Making better decisions means people have more trust in your abilities.

The architect's role is clearly a very multi-faceted one which requires very quick context switching between the various demands. However, I think the advise in this book is applicable to anyone working in a technical organization. Not only because the lines between senior engineers and architects are becoming more of a blur but because the book is a reminder of the challenges every technical organisation faces besides solving difficult technical problems.

It is a super book and one that I will reading (and consulting) again.

CSS Sprites

The problem

You have a menu bar with the standars buttons, including the proverbial "previous / back" and "next / forward" buttons which look like...

You have been asked to improve the usability of them. In addition, your application is not coming up well in performance analysis tools. One reason for this is that many pages are downloading numerous components resulting in too many HTTP requests. It's time to consider mechanisms to reduce the number of HTTP request required to display your pages.

The solution

Well consider the usability first. The images for the buttons don't look that bad. It's obvious what they mean and what they will do, so there's not much point adding tooltips. But we could make things look sleeker with some "hovering".  What's hovering?  Hovering is a technique which dynamically changes a component when a mouse "hovers" over it. Technically, tooltips are a form of hovering but there are other types: components can change colour or light up. Let's apply some hovering magic to our prev / next buttons.  Hover your mouse over the buttons below, do it a few times and watch them glow.

So how did we do all that? Well, the first thing we do is make alternative images of our original images. This can be done using any decent editing tool: gimp, paint shop pro, take your pick - for this example, I just used Picaso. The second thing to do is to amalgamate the four separate images using a tool such as CSS Sprite generator into one single image.

Why one single image? Well that's for the performance part. HTTP requests can be expensive. We don't want to have to 4 separate HTTP requests for 4 images. So instead, we have one image which contains everything we need. This downloads all four components in one go. We then use some CSS tricks to:

1. Pull the 2 images out of the one big sprite
2. Switch the images to their hover versions when the mouse hovers over them

So how do we all that... time to look at some CSS.

#navlist{position:relative;}
#navlist li{margin:0;padding:0;list-style:none;position:absolute;top:0;}
#navlist li, #navlist a{height:60px;display:block;}

#prev{left:0px;width:60px;}
#prev{background:url('https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQTHOhAUUfvhMQd9wO68I_rFvM6N_u2oyx29R4IOGlHGdVa9rijixF2OgVDIHGZIMLucPUuXsyl0q4Whc0MpeKWCTuDsTdAnaoXlBYB6KsWRo09LNU022GecQvRQipB3TWOBq3qQVjeYTS/s200/sprite.png') 0 0;}
#prev a:hover{background: url('https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQTHOhAUUfvhMQd9wO68I_rFvM6N_u2oyx29R4IOGlHGdVa9rijixF2OgVDIHGZIMLucPUuXsyl0q4Whc0MpeKWCTuDsTdAnaoXlBYB6KsWRo09LNU022GecQvRQipB3TWOBq3qQVjeYTS/s200/sprite.png') -60px -60px;}

#next{left:61px;width:60px;}
#next{background:url('https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQTHOhAUUfvhMQd9wO68I_rFvM6N_u2oyx29R4IOGlHGdVa9rijixF2OgVDIHGZIMLucPUuXsyl0q4Whc0MpeKWCTuDsTdAnaoXlBYB6KsWRo09LNU022GecQvRQipB3TWOBq3qQVjeYTS/s200/sprite.png') 0 -60px;}
#next a:hover{background: url('https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQTHOhAUUfvhMQd9wO68I_rFvM6N_u2oyx29R4IOGlHGdVa9rijixF2OgVDIHGZIMLucPUuXsyl0q4Whc0MpeKWCTuDsTdAnaoXlBYB6KsWRo09LNU022GecQvRQipB3TWOBq3qQVjeYTS/s200/sprite.png') +60px 0px;}

The second half of the cake is the HTML, note the id's

Explanation

1. The CSS shows a styled navigation list. A list with id="navlist" will reap the styled benefits.
2. An element with id="prev" will disect up the collection of images aka the "sprite sheet" and take out the part of the image it wants i.e. the left arrow
3. An element with id="next" take out the right arrow
4. "prev" and "next" have hover images which are also taken from the sprite sheet and will be displayed when the mouse hovers over them.

So there we go. Better usability and better performace.  A good day's work. So any other questions? Well an obvious one would be why not just use an image map? It will also reduce HTTP requests. That's true. But, it's not as flexible as using CSS sprites. When image maps are used, the images have to be continguous. Using the CSS sprites technique, you can split them up whatever way you want. A whole bunch of images can be put onto the one sprite and then can be used together, seperate and in whatever order you want.  In fact this is how most companies used CSS sprites. They create a sprite sheet which contains various images for all parts of the web application.  Inline images are another approach. This approach will download the image in the same HTTP request as the page and thus also reduce HTTP requests but it willalso increase the size of the HTML page.  Browser support for CSS sprites approach is also better.

So, is anyone else using CSS sprites - hell yeah! Recognise anything here...

References

1. Really interesting page about the evolution of google super sprite
2. W3C page on CSS sprites
3. Sprite generator

The CompTIA Network+ exam

I recently wanted to brush up on my networking knowledge so decided to have a go at the CompTIA Network+ certification.  The CompTIA Network+ exam is technology agnostic (it doesn't get hung up on CISCO details) and reasonably straighforward.  You don't need any sys admin experience (or any prior certifications) just a bit of technical know how, some study and you'll be fine.

In my own case, my background is software engineering and technical architecture.   I have never worked as a sys admin and never will - I am pretty sure a good sys admin would  find this certification too easy.  So, if you are in a similar boat you may be asking what is the benefit of putting the time into attempting this certification?

Some reasons...

Reason 1: Protocols

In every architecture (especially a J2EE / JEE one) you don't just have a range of software protocols (e.g. RMI, JDBC) you usually have an array of classical network protocols:  TCP, DHCP, DNS, HTTP,  HTTPS etc. And depending on what your architecture is trying to do you'll more than likely have a few more.  For example, if you're sending / receiving emails you'll be talking mail server, SMTP, POP3 and IMAP; if you have some Voice over IP, you'll be talking SIP and RTP.  Having a good understanding of every protocol that does something in your architecture is as important as understanding every component in your architecture.  It's all part of the same jigsaw.

Reason 2: IP
 
In your deployment, as you start to scale and start adding more servers to your architecture understanding things like IP addressing mechanisms, subnetting, private IPs, static IPs,  APIPA, Autonomous systems, WINS, Default gateways, broadcast addresses, NAT, DHCP scopes,  etc. becomes important.   Even if you are not scaling, you may want to do something like put your REST services under their own domain name in the same way Dropbox (http://api.dropbox.com) and Twitter (http://api.twitter.com/) do.  Understanding how to do this and how to get the benefits from it require some networking knowledge.  For example, you may decide to use different TTL values for your REST domain name than for the rest of your architecture.

Reason 3: Security

The Network + certification contains plenty of interesting stuff from a security perspective:

• The difference between stateless and stateful firewalls. Stateful Firewalls remember your session and can have more sophisticated rules based on its knowledge of previous requests from the same session.
• The various wireless encryption standards (WEP is awful, WPA2 is good).
• The various attacks that can happen to your network, DoS, Smurf etc.
• RADIUS, TACACS+ and Kerberos protocols
• Understanding that FTP, Telnet, RSH, RCP, SNMP v1/2 are unsecure
• Understanding that SSH, SNMPv3, SFTP, SCP are secure.
• Intrustion protection scanners and Intrustion detection scanners - what they do and when to use them.
• Port scanners - useful for seeing which ports are open. Try angry ip scanner
• Packet sniffers - useful for lots of things. Have a go with wireshark
• IPSec - the only IP encryption protocol to work at layer 3. It encrypts both header and payload.

Reason 4: Performance

From a performance perspective:

• Wireless network speeds - 802.11n is way faster (up tp 400 Mbps) than 802.11g (54 Mbps) which many networks are still on.
• Optic fibre options and types- single mode supports much longer distances than multimode. 
• Bandwidth for various ethernet cables types. For example 1000BaseT has a speed of 1 GB/s and must use Cat 5e / 6 cable. It has a distance of only 100M. 
• Methods to guarentee or increase bandwith for users and applications - Traffic shaping and QoS

Reason 5: Network commands

Some network commands are well known and obvious to all of us. For example: PING.  But, do you know how do to set buffer size for your ping request? (It's PING -l). Or that PING will give you idea of network hops from the TTL value returned?  Or what protocol is required for ping to work? (It's ICMP). Is this any relevance?  Well it may not be. But, it might help you.  For example, by default you can't PING an Amazon EC2 instance because - by default -  Amazon disable ICMP for its EC instances.  Now that might be useless information, or it might save you a painful 2 hours some day!

The Network+ certification  also contains some good stuff on commands that aren't so obvious.  This includes DIG and MTR . The former is useful for diagnosing DNS problems and gives a little bit more than NSLOOKUP; the latter (MTR) is a sort of combination of TRACEROUTE and PING.

Exam preparation

To study for this exam, I read the CompTIA Network+ book by Mike Meyers and went through all the Network+ training videos from Professor Messer - these are free and really good.  The exam contains 100 multiple choice questions that have to be answered in 90 minutes.  In comparison to any Java certification, that's a lot more questions.  Most of the questions are reasonably straight forward however, the pass mark is 80% which is a lot higher than most other industry standard certifications - so it's not that easy a certification.  Regarding cost, well at exchange rates of the time I did the exam (Feb 2012), the damage to the credit card was €263.00.  I sat the exam at the New Horizons exam centre on Strand Street Great, Dublin 1.  Good set up there.

Summary

So in summary, the Network+ exam will not turn you into a Sys admin genius. Some of the questions are easy, some are just a matter of brushing up on what you probably already knew and other parts you'll learn something new.  As with every certification, there are the proverbial bits of irrelevant stuff - things you have to learn for the exam and probably never need again.  This can be a pain.  However, there are also many good things that can be learnt.  I have tried to outline some of them here.  Please feel free to add a comment below or contact me if you have any questions

Code reviews in the 21st Century

Find that Bug!

There's an old adage that goes something like: 'Do not talk about religion or politics'.  Why?  Because these subjects are full of strong opinions but are thin on objective answers.   One person's certainty is another person's skepticism; someone else's common sense just appears as an a prior bias to those who see matters differently.  Sadly,  conversing these controversial subjects can generate more heat than light.   All too often people can get so wound up that they forget that the outcome of their "discussion" has no bearing on their life expectancy, their salary, their chances to win x- factor, getting that dream date, winning the lottery, finding a cure for climate change or whatever it is they regard as important! 

Similarly, in the world of software engineering code reviews can end up in pointless engagements of conflict.  Developers can bicker over silly little things, offend each other and occasionally catch a bug that probably would have being caught in QA anyway - that conflict free zone around the corner!

Now don't get me wrong, there are perfectly valid reasons why you may think code reviews are a good idea for your project:

1. Catching bugs sooner means less cost to your project. You don't have to release a fix patch because it's has been caught in development phase - yippee!
2. Code becomes more maintable.  That crazy 200 line method that Jonny was writing with a hangover has being caughted before it has the chance to make itself at home deep in your code base.
3. Knowledge is spread across your team. There are no longer large blocks of code that only one person knows about.  And we all know, when that one person talks about taking a two month holiday everyone panics!
4. Developers make more of an effort. If a developer knows someone else is going to pass judgement on his work, he's more likely to put that line of javadoc to clarify when an exception will be thrown.

However, it would be naive to think that code reviews don't cause problems.  In fact, they cause so many problems many 21st century projects don't do them.  I think they have a place but there needs to be some thought regarding how and when they are done so that they are beneficial as opposed to a nuisance.   Here are some guidlines...

• 1. Never forget TDD 

Ensure you have tested your code before you asked someone else to look at it.  Catch your own bugs and deal with them before someone else does.

• 2. Automate as much you can 

There are several very good tools for Java such as PMD, Checkstyle, Findbugs etc  What is the point  getting a human to spend time reviewing code when these tools can very quickly identify many things the human would waste time moaning about?  I am going to say that again.   What is the point  getting a human to spend time reviewing code when these tools can very quickly identify many things the human would waste time moaning about? 

When using these tools, it's important to use a common set of rules for them. This ensures your code is at some sort of agreed standard and much of what used to happend in an old fashioned 20th century code review, won't need to happen.  Ideally, these tools should be run on every check in of code by a hook from your version control system.  If code is really bad - it will be prevented from being checked in.  Billy the developer is prevented from checking in the rubbish he wrote (when he had killer migraine) that he is too embarrassed to look at.  You are actually doing him favours, not just your team. 

• 3. Respect Design 

In some of the earlier Java projects I worked on, the reviews happened way too late.  You were reviewing code when the actual design was flawed.  A design pattern was misunderstood, some nasty dependencies were introduced or a developer just went way off on a tangent.  The review would bring up these points.  The proverbial retort was: 'This is a code review not a design a review!' .  A mess inevitably ensued.  To stop these problems we changed things so that anyone asked to review code would also be involved - in some way - in either the design or the design review.  In fact, we got much more bang from the buck from design reviews than code reviews.  Designs were of a much higher quality and those late nasty surprises stopped.

• 4. Agree a style guide (and a dictionary) 

Even with the automated tooling (such as Checkstyle, Findbugs etc), to avoid unnecessary conflict on style, your project should have a style guide. Stick to the industry standard java conventions - where possible.  Try to have a 'dictionary' for all the concepts your project introduces. This means, when code refers to them it's easier to check that the usage and context is correct.

• 5. Get the right tooling

If all your developers are using Eclipse (and happy using it) something like Jupiter makes sense.  You can navigate your way through code, debug code and essentially leverage everything the Eclipse IDE does to make your life looking at code easier when reviewing code.  However, if everyone is not on the same IDE (or the IDE is not making your life easier) consider something like Review Board. 

• 6. Remember every Project is different.

You may have done something in a previous project that worked.  But remember, every project is different.  The other project had a certain architecture (may have been highly concurrent, highly distributed), had a certain culture (everyone may have enjoyed using eclipse) and used certain tools (maven or ant).  Does the new one tick the same boxes?  Remember, different things work for different projects.

• 7. Remember give and take

When reviewing be positive, be meticulous but do not be pedantic.  Will tiny trivial things that get on your nerves make a project fail or cost your company money?  Probably not.  Put things in perspective.  Remember to be open to other ideas and to change your own mind rather than getting hung up changing someone else's.

• 8. Be buddies 

In my experience, what I call 'buddy reviews' (others call 'over the shoulder')  have worked really well.  A buddy review consists of meeting up with another team member informally every day or two and having a quick glance (5 - 10 mins)  at each other's code at your desk or their's.  This approach means:

1. Problems are caught very early
2. You are always up to speed as to what is going on
3. Reviews are always very short because you are only looking at new code since the last catch up
4. Because the setting is informal - there is no nervous tension. They're fun!
5. You can exchange ideas - regularly. 

When Tech Leading, buddy reviewing your team members is a great way of seeing if anyone on the team is running into trouble early rather than late.  You can help people and get an idea of everyone's progress all at the same time.  And because of the regular nature of buddy reviews, they become habitual and actually get done.  Something we can't say for many other 21st century code reviews!

In summary, if your project is going to engage in code reviews, they should be fast, effective and not waste people's time.  As argued in this post, it is really important to think about how they are organised to ensure that does not happen.

'Til the next time - take care of yourselves.