Archive

Archive for the ‘discourse’ Category

Book Review of Arquillian Testing Guide by John D. Ament

June 2nd, 2013 No comments

Here is a review of Arquillian Testing Guide by John D. Ament published by Packt Publishing. Before I give my opinion of his book, let me first make a disclaimer. I am also a Packt Pub author. I am the author of the up and coming Java EE 7 Developer Handbook (September 2013).

Mr Ament expects you the developer to be familiar with Java EE 5 or 6, an enterprise developer in Java. I guess you should have about one or two year experience and therefore you should know how to write Java unit tests with JUnit (or TestNG), the book leans on JUnit.  In the first, chapter, The Alien Have Landed; the author covers the basics of Arquillian Framework and it is helpful for engineers to have Apache Maven knowledge. Ament explains very well how to create a Maven project with Arquillian, and you find here hints and tips to avoid dependency download meltdown. The book’s first example is about building a Java project with an embedded container (so-called container-less build). Ament is clear about to set up a test project for re-use, creating different archive, JAR, WAR and EAR; and defining Maven profiles. It is an impressive start because when I writing my own Java EE 7 book, I wish that I had this information about an easy-to-read structure about integrating Arquillian.

The second chapter, Evolution of Testing digs deep in the history of Java enterprise testing and why we engineers must perform this duty in professional work place. Ament quickly guides the reader through jumps in technology from XDoclet to Mockito to HP QuickTest Professional. He also covers the Selenium and SoapUI toolkits briefly; and to a certain degree this text can treated as a handy reference to the background in testing. He covers the reasons where and how Arquillian can help to alleviate, extend these products and solve the nagging issues with these products in testing.

The real cherry berries for the contemporary Java EE engineer starts with chapter three, Container Testing; and this where the software developer does learn how to build integration tests with Arquillian Framework. The reader learns about different deployments and archives. Ament covers the Arquillian protocols in full detail. He obviously has tested Arquillian in many application servers in different configurations from JBoss AS 7 (rebranded recently to JBoss WildFly), GlassFish, Weld, OpenEJB, Jetty, TomEE and Tomcat. He has advice for Spring Framework developer too who want to use Arquillian in their applications. Ament particular does a fine job describing the merits of embedded versus managed and remote testing with Arquillian, because not all of the application servers, EJB container or servlet container are capable of support all of the Arquillian protocols and deployment capabilities. One of the great examples is the CDIDelegateTest that really helps the reader get the picture straightaway with no fuss.

Chapter four is called: Why Did the Test Fail? This chapter pays for the book itself. There is nothing worse than having a unit test or integration test fail, with or without Arquillian framework; and it is worst if you were not responsible for writing code in the first place. Ament has a lot of advice and descriptions on what could be cause for a failing Arquillian test. The text is particular relevant when you and your team are running Arquillian in continuous integration environment where the deployment is to a managed or remote server with other dependencies such a database. To finish, the chapter Ament provides a set of Dos and Don’ts sub sections.

The fifth chapter of book: Enriching the Enterprise Test Case, is about Arquillian and Context Dependency Injection, which I am a great fan of. Ament has nice examples and there is a fine explanation of CDI and JAX-RS testing for the request scope application. He covers also popular external CDI extensions and how to test features that use them very well. He even has a section on writing CDI extensions and testing there functionality with Arquillian, which is truly great stuff and a fantastic reference for advanced Java EE software developers. In this fifth chapter, also illustrates Arquillian Persistence extension with clear code and examples. This is hard-hat stuff that I figured out for myself whilst writing my own Java EE 7 book with Gradle and Arquillian test examples, and it is nice to see that Ament supplements and enhances my knowledge of the framework. If you want to find out how to test stateless EJB then you will find it here (and also in my Java EE 7 book).

There are ten chapters in this book and unfortunately I ran out time to review the rest of the book. The remaining content covers Arquillian extensions, including in-depth coverage of the Persistence and Transaction extensions, and running the framework with Spock with Groovy; Functional Application testing with Selenium and the Warp drive extension; web services testing; Arquillian and OSGI; and finally a full chapter dedicated to the underlying and central core framework ShrinkWrap, which allows developer to create a virtual Java archives.

Ament has written great book that concentrates on JBoss Arquillian Framework purely and simply. The book was written in the Java EE 6 timeframe just before next platform edition release, however the content is highly relevant still to all Java EE 7 developers. Ament has delivered a definitive guide to the Arquillian Framework. I wish that I had this book on my desk and Kindle application much earlier in my selfish task of writing about the sumptuous changes in new Java EE 7; and most of all I learnt how Arquillian can do a lot more than I what I thought it could.

Peter A. Pilgrim

     Author of Java EE 7 Developer Handbook

Sunday, 2ndJune 2013

PS: An earlier text of this review has also been uploaded to Amazon.co.uk.

+PP+

Keeping It Rather Fake on the Job Interview Front

May 29th, 2013 1 comment

#DontFallForThisOne

This arrived is my Gmail inbox this afternoon. I had heard that some people were getting these mails; but I didn’t believe them until now.

charles <charlesbrown486@yahoo.co.uk>

14:36 (22 minutes ago)

to me

Hi

As a result your application, I would like to invite you to attend an interview. 
You will have an interview with the department manager, Edie Wilson. 
The interview will last about 30 min.

Please bring three reference (If available), as well as a copy of your ID, 
e.g. Passport, Driving License to the interview.

Please contact me on 07064848730, in order to arrange an interview. 
We look forward to seeing you

Best regards
Charles Brown

You’re having a laugh. Seriously, I am laughing. This is obviously a job interview scam, although you might not think so if you are very new to IT industry. In this country (United Kingdom and Ireland), you don’t need to provide any references up front for work before a face-to-face interview in this country and anyone that asks you to do so is taking you for a ride. References and sometimes disclosure checking, though, are usually required when you have been made a fully legal job offer from a reputable entity company. Don’t give skimmers, clippers, in-between cheap labour force so-called here-today gone-tomorrow consultancies or confidence tricksters any glimmer of a chance and naturally any money.

BaLeeTeD

+PP+

Categories: discourse, information, Interview, it Tags:

Found a Foreword and Releasing that Java EE 7 Cat

May 23rd, 2013 No comments

It’s time to release that Java EE 7 cat out of the bag.  I’m very excited about delivering this first technical book. I have the pleasure of announcing that the great Markus Eisele has agreed to write the foreword to my forthcoming book: Java EE 7 Developer Handbook from Packt Pub.

Markus Eisele is an Oracle ACE  Director, a champion of Java Enterprise Edition, knowledgeable in messaging systems and is a German author of note. He lives and works in Germany; and Markus is famous for sending scores of valuable tweets on Java EE and related technology as the user @myfear. I am very pleased to have Markus be an early access reviewer for book and he recently accept my invitation.

Now that cat has been released; and it is finally free. I can let you also know a few more things. I am using my time on the contractor bench of truth to dig deep and finish writing the remaining content of the book. The aim of this book project is to have it fully ready for September 2013; published, printed and shipped for  JavaOne.

Currently, the chapters sort of look like this:

  • Chapter 1 Introduction
  • Chapter 2 CDI
  • Chapter 3 EJB
  • Chapter 4 Essential JPA
  • Chapter 5 Intermediate JPA
  • Chapter 6 Java Servlets 3.1
  • Chapter 7 WebSocket 1.0
  • Chapter 8 JAX-RS 2.0
  • Chapter 9 JMS 2
  • Chapter 10 Bean Validation 1.1
  • and more

The content is subject to change, of course, and all of the usual caveat emptors and legal clauses apply. Sadly, I decided to drop the JSF content out of the book, because we are rather too close for comfort to page limits for hardware printers.

+PP+

PS: I have a couple of other secret helpers out there and they know who they are. Thanks to you also.

Friday JPR 2013

March 4th, 2013 Comments off

The last day of the Round-Up, which was a bit sad. The day began with a bang with a nice session hosted by Julie Pitt titled “Scaling Scala”. Daniel also co-hosted this session with suggestion on topic to cover the popular Scala libraries: Play and Akka. This content has a lot of good ideas about how to get Scala adopted into an organisation, where it is a new language. The general advice was to start slowly and surely; don’t bite off the functional programming parts until you and your team understands the concepts fully and can write refactorable and maintainable clean code. There was a reminder of the temptation to write a single val assignments, which while are impressive to the smart developer, could leave the co-worker puzzled. Far better it would be for new Scala teams to write smaller chunks of Scala code (with caveat of writing a unit test with ScalaTest or Spec) and then combine those fragments in to a larger whole.

JPR 13

Day 4 Sessions of JPR 2013

The second session was a follow session to the first in many ways. Dick hosted a session; it was called “Types: How Much Can Compiler Do?”. Given static compiled language like Scala enforce type safety, Dick wanted to find out from other people how to ensure code will execute correctly by push the burden of type verification with semantics on to the compiler. Dick is obviously influenced by functional programming languages such Haskell. This may be considered advanced developers and programmer only, when you listen it in the podcast.

The final session of the Java Posse Round-Up 2013 was the “Open Source Business Model” which proposed and hosted by Hans Dockter. Bruce Eckels, Fred Simon and, of course, Hans were the main contributers to this discussion. If you are interested in running a professional open source business in near future, I believe this will be worth you while, as they discuss the various business models on service, product and consultancy oriented operations.

This wrapped up the conference. In the afternoon, there were a bunch of us, who went up to the mountain for a downhill ski or ride on a snowboard. It was great being with Jeremy Cerise, DJ Hagberg, Chris Phelps and Chris Marks. In particular, Chris Mark and I tore the mountain up!

JPR 13

A sunset view of the Crested Butte mountain outside of the Yurt

JPR 13

Inside the Yurt

The last event of the conference, proper, was the Yurt dinner, which James Ward organised very successfully. It was very well attended. The Yurt is a Mongolian hunt in the country side a couple of kilometres from the Crested Butte town. In order to get to the hunt, because it is inaccessible by road, the group hike with showshoes from the Gronk area of town to the Yurt location. The three course dinner was cooked by a quality chef. It is not free, we all had to pay about 75 USD, but it was delicious and well worth it. The biggest bonus was not the dinner or wine, it was the remoteness, and the absence of town lights. When I say we could see the stars, I mean, in truth, we could see stars aplenty. The milky way was fascinating, it was a bit hard to star up in the nightsky, but eventually I saw a faint band of dense stars arching overhead.

JPR 13

Inside the Yurt #2

JPR 13

Inside the Yurt #3

Time to wrap and go home. The end of the Java Posse Round-Up 2013. It has been a fun experience, I am glad I had the chance to travel to this open space conference, despite the initial airplane and weather problems. You do meet some of the best quality minds and humans on this planet. I have come away refreshed and I know exactly what I am going to focus on for the rest of the year.


+PP+

Tuesday JPR 2013

March 2nd, 2013 Comments off

Tuesday, 26th February, 2013, the day one of the Round-Up. The shenanigans of United were left behind. Today was a fresh start, a time that duly manipulated into a recharge. I was exhausted, the others had gone ahead to Rumours for initial Round-Up coffee, then they walked a short distance to the Parish Hall.

JPR 13

The Parish Hall

Whilst I was tucking in a scrambled egg breakfast, Bruce and the JavaPosse organised conference badges, explained what an Open Space was to new beginners, and everyone did a meet and greet again. By the time I arrived with my coffee, the room was a hive of activity, as participants took up post-notes and pinned proposed session titles to the wall. Open Space is a contributory activity; there is no achievement if you refuse to get involved. I proposed a Gradle session for Wednesday, which tied up with some else, who wanted a session of Build Pipelines; so those topics could be grouped together as a session.

Jpr 13

An example of the self-organisation of an open-space conference like the JavaPosse Round-Up. The participants come up with session ideas for the morning and also afternoon activities.
The church group were having meeting at 9:00, hence the hall was unavailable on this morning.

Because of the introductions and self-organisation of the participants, the first session took place at 10:00am and the second session followed at 11:30am. The sessions lasted one hour at the maximum and there is break between them. The first session of the round-up that I choose was Reactive Programming, which I think was proposed by James Ward. It was good discussion of asynchronous and non-blocking input and output operations of applications. We talked a lot about Scala in this session and some frameworks like Play, and comparisons to NodeJS. Many people expressed their view on this style of programming. The second session was hosted by Barry Hawkins and it was about Domain Driven Design and whether this subject has been usurped, diluted and vandalised by over zealous practitioners, and perhaps misunderstood by the developer community in the same way that Agile with a big-A is accepted by good practice, but poorly implemented by many organisations. I must admit prior to this one, I had no experience of Domain-Driven Design. I took part in it as this subject always appears at technical and agile conferences. I came away with tentative, yes, that maybe I should invest some time in the future to learn about Ubiquitous Language and Bounded Contexts. I believe I was put off from the subject, because of the perceived notion that DDD is strongly associated with Model Driven Architecture and meta language programming, which I absolutely have no such interest. Although, I have an interest in Domain Specific Languages, of course, such as ScalaFX, I have not yet come across a project where I need to be build a DSL to model a software design for client. I believe this podcast will be well worth a listen. After the morning session, I went back to the house and collected my snowboard.

There was no chance of slacking off today.

Untitled

Picture of me with a helmet camera, GoPro Hero 3 Silver

 

+PP+

Categories: Conference, discourse, javaposse, Sustainable Tags:

Initial Days of the JavaPosse Round-Up 2013

February 26th, 2013 Comments off

On Saturday, 23rd February 2013, South London, early in the morning, having packed my snowboard and a small Samsonite grey suite case overnight, I got up, trying my best not to disturb my partner. I was on my way to London Heathrow. The morning Sun sternly pushed its sunlight through seeming impenetrable clouds in to average Londoner grey day. A couple of snow flakes magically decided to reveal themselves every cubic metre on the fresh wintry quest for vanity. The United Airlines plane took off time to Newark at 10:15. I could sit and back and relax, so they say.

I have to immediately say that Argo, the movie that Ben Affleck won the Oscar Director for, is great, even though you know the result. I was rooted for the government workers to get out. It told the story from both sides, especially the Iranians were frustrated with their lot, their Shah of Iran, who escaped with billions of gold. In my opinion, Ben Affleck is the next Clint Eastween, if this is the standard of his first directed movie. That was the highpoint of transatlantic voyeur; and a large hint of the frustration to come to me.

I attempted to code and write content a little. I had bean researching how GlassFish Embedded application server v4.0 and WebSockets 356 played together, and following the expert group mailing list. Danny Coward now wanted to renamed the current annotations in the specification JSR 356. WebSockets endpoint were not been injected by the CDI Container present GlassFish, and this was a frustration on the plane. Luckily before I took flight I changed the gradle settings to include providedCompile 'org.glassfish.main.extras:glassfish-embedded-all:4.0-b77'. This brilliant idea that I had was fantastic, running “gradle idea” sort of worked, but I realised that I missed one other dependency providedCompile 'javax:javaee-api:7.0-b77'". There was no available Internet on the transatlantic plane. It was time to put the machine away.

Untitled

View into Montrose

Eventually, I landed at Denver International Airport after 18 hours, where they do have free-WIFI, only to be shocked at the news: The 19:30 flight from DEN to GUC (Gunnison) was canceled. I got on the internet with phone, something about Dianne Marsh and the Weather and delayed and cancelled flights. United Airlines service customer desk at gate B33 did confirm cancelation of the flight, I was stuck in Denver for the overnight. The clerk handed me a pink slip for the airport hotel. My annoyance really almost saw the milk almost boiling over on the stove: no, I just caught it in time, flicked the switch, the British Gas was extinguished and gladly no lactose was burned: this time. The smell, anyway, would have been so awful. The sense of decorum, in myself, returned, sort of. United had given be a confirmation of Monday 25th February at lunchtime as my next guaranteed flight out to Crested Butte. Two nights in a Denver hotel: you got to be bloody joking! Decorum was gone by the time, my neurons interpreted, filtered and assessed this aural data.

Matt Zimmer, the organiser of the house in Crested Butte that I am staying in, and a friend had also suffered the cancelation of the last United flight to Gunnison many hours earlier. Without Internet access, I was none the wiser. Matt decided to get his luggage and travel by road the next day with D.J Hagberg. I elected to re-route my flight to Montrose, 60km further out from Crested Butte and thanks to advice from Dianne Marsh, I was flying out the next morning on Sunday at 08:10AM. I overnighted at the DoubleTree hotel, about 25 minutes by free shuttle from Denver airport. I was exhausted and my head was minced like Baked Beans.

Untitled

 

I am standing outside the vacation rental house, 329 Maroon. This photo was taken by Matt Zimmer who organised the rental this year. I thought that let somebody else be responsible for a chance, having being the “housemeister” for 2009, 2010 and 2011.

 

Eventually, I arrived at Montrose, the next day, having survived the ordeal of wearing the same clothes for a second day. Bum hole! United had not sent my snowboard and trolley case onwards with me. I reported my missing luggage and got on the Alpine Express, so much for the best laid plan. The original intention of arriving on Saturday night, was that I would have a full Sunday to go up to the mountains and enjoy some powder and board to my heart’s content before the Round-Up on Monday. Chagrin, I love the French. They had a wonderful footballer, didn’t they, Zinedine Zidane.

I desperately wanted to be Zidane, World Cup winner 1998, on the Sunday, so skilful on the football, able to hide his true emotions and then engineer a flash of instant magic that regularly produced the killer pass to the Brazilian legendary striker, World Cup Winner 2002, Ronaldo, when they both played regularly and so sumptuously together at Real Madrid. Alas, my modus operandi were not that good, when speaking to customer representatives on Skype. I was first to arrive at the vacation rental house on Sunday, managed to get an Internet connection, got on the blower to United to see about my snowboard. The web site, United Baggage Resolution Centre, yes it is all true, Dear Lord, is a load of bollocks. Sorry! Excuse my French. The status was always Tracing Your Baggage, Please Check Back Later; and I did every four hours. I went around Crested Butte, got a bite, a Hawaiian style Teriyaki Chicken, to eat at the Last Steep, which is quite decent. I supposedly reasoned that it was good to have finally made it back here again in Crested Butte for my fourth Round-Up event. I, then, withdrew a bundle of US Dollars for spending money. It could have been a blast. It wasn’t to be. I was safe. Instead, I did some coding more on Java Web Sockets, I found out about the techniques for responsive CSS web design and yes that Gradle Dependency was the cause of the CDI injection failure. I solved it. Tyrus 1.0-build11 is the version of the reference implementation inside GlassFish 4.0 server build 77. Great though that was, a change of fresh warm clothes would have been the clincher.

Matt Zimmer arrived in the evening at the vacation rental house in Maroon. Immediately, we went off to Bruce Eckel’s house later in the evening, as D.J. Hagberg also made it to Crested Butte from Denver through the mountain passes. Being a local Coloradian, D.J said that the four hour trip on a regular day took them seven hours, the weather was turbulent high up on 11,000 feet or so. Experience obviously counts: he is a very safe driver. You’d trust him with your life.

Untitled

Crested Butte, Main street, on Sunday afternoon

The mini-progressive dinner at Bruce’s place where everyone contributed a little bit of this, a little bit that, steak; pork chops; a six pack beer, which I did along with my brother-in-spirt-man, Chris Phleps ; a couple of bottle of wine went along way to taking my mind off the baggage ordeal. It was good to meet and greet and see the Round-Up folks from 2011, when I was last here in Crested Butte. Fred Simon, Diane Marsh, Chris Marks and several other regulars were here ahead of time. Also Hans Dockter of Gradleware and Gradle was present at Bruce.

Monday morning started in a despondent fashion with a fifth call over Skype to the UBRC , the status of the website was the same Still Tracing. I learnt by now to try a different tact on this; my partner often suggested this alternative manoeuvre when communicating with customer representatives anywhere in the world, she says: Tell them, only, what you want. I asked for my snowboard and my case to be put on the next available plane to Montrose and I also asked them for the exact location of where the luggage currently was located as the website was useless at revealing this data. I should say, that all calls, go out to India. I am not surprised by outsourcing suffice to say you can figure out yourself the rest of my reaction to this situation. The fifth customer rep said they do all they could, they will send a message to emergency expedite the bags.

Untitled

Matt Zimmer (L) and James Ward (R) discussing Scala Play Framework during the Free Day on Monday. The workshop took place at the “Posse’s old” rental house.

So my Monday, started at Posse house with Matt Zimmer learning a Scala Play framework with James Ward leading us through an introduction and blocking and non-blocking actions. I thought James did a good job. Monday is a free day for the Round-Up; we could learn Big Data if we wanted to, instead we study a topic that interests us collectively. For me and a few others, an introduction to Play Framework was a good topic. We learnt about a tool call Apache Bench and found that on Mac Book Pro at least, Mac OS X, Play does scale nicely to 1000′s of web request on the same machine. James attempted to reconfigure the Execution Context, of the Play’s underlying fork join framework, which is derived from Professor Doug Lea’s incantations or close enough, as all road lead to his Rome, his knowledge of Java Threads and Concurrency is primus uno. We concluded there must be an issue with the number of collected input and output resources at an operating system level. Matt was a little unimpressed with this as he decidedly had commercial Scala and Play project on the line. Marek Radonsky thought the issue could be a configuration failure with the Netty server library, which Play Framework relies on for asynchronous input and output. Still, Play, for me represents a little bit of dichotomy in comparison with the Java EE world.

Wearing the same clothes for the third day did its best to sally my enthusiasm for the Round-Up. I was beginning to lose the will to live by the afternoon, I refused an offer to go snow shoeing around the town of Crested Butte. I hope I didn’t come off with being like a damp squib to the other Round-Up people. The prospect of extensive physical sweat in the only clothes I had on my back knocked the desire out of me, clearly. By this time, Andrew Harmel-Law arrived and I followed him on tour of the vacation rentals, the Posse House, then Bruce Eckel’s house.

I decided by late afternoon to get back into writing that WebSocket Java EE 7 example for my forthcoming book, incidentally called Chapter 7 WebSockets, at the time of writing. Chris Phelps was there at Bruce Eckel’s house and he showed off his cool JavaScript example: AngularJS and Backbone. He said, “It’s was step up from JQuery”. I was impressed so much by AngularJS and Twitter Backbone, I need to add a client example of this into my up and coming book only to show the state-of-the-art. Barry Hawkins, the long time Agile consultant who transferred to California and a gaming company, Riot Games, was also at Bruce’s house, he was learning Kernighan and Ritchie’s C Programming Language. We had a light smirk on this topic. The irony of all. For many of us C was a one of the first professional computing programming language when we read at University or began our careers. No offence to Barry was intended. Learning is a lifetime of progress, so respect is due, to all those who continue with improvement. A few others, Andrew and somebody else, decided to delve into the Groovy programming language. I think shared knowledge learning with somebody else to trade idea is great way to jump into a new technical area, especially when you know that the people that you conserving with, have quality, it was like the meeting of the England Football team international training at Bisham Abbey. Andrew will probably be amused or get slightly annoyed with that national football team comparison, because he, just like my partner, is Scottish, but you know what I mean about quality developer, designer and experienced people, many of them great Americans. The point you know when you are standing with peers of high quality; you have met these sort of professionals, then you know what the quality and the standard is for evermore.

A bunch of us headed to Secret Stash, my mood was somber, I did my best to put on a Lady Gaga appearance emotionally, but my version of Poker Face didn’t hold up so well and my tell came to life and revealed itself when the restaurant and the cooks were 15-20 minute late with my pizza whilst everyone else at the table was tucking into pork infested pizzas. I was hungry, frustrated with United Airlines, and everything else. Eventually the BBQ Chicken arrived; it was just okay. I cracked a few jokes, and war stories here and there. I fist pumped with Chris Phleps about respectively terribles ordeals in the IT industry. We both needed to get the funk out of our collective systems. We both moved on to something better, it was good to give each other that support.

Untitled

Monday night dinner at the Last Steep restaurant. From left to right: Guy, Dimitry, Chris Marks, Chris Phelp, Andrew Harmel-Law, Todd Costella, and Me.

My fight with United continued for seven time after 8pm on Monday. Finally, a breakthrough, my baggage had been located in Denver and they were sending it through to Gunnison, unfortunately the Indian UBRC representative could not tell me either when exactly and how it get to Crested Butte. I went for a short nap, read a few emails and tweets from London UK. Not much going on, Ben Affleck was now a super star actor and director and so was the actors Anne Hathaway with Daniel Day-Lewis making Oscar history. Some cheer at the achievements of others. I ruminated a little about the remaining schedule for my book. Life could be worse. I was fortunate to make it Crested Butte at all.

I dragged my flesh and bones over to the Ted talks taking at the local Matinée theathre in Crested Butte. I was half interested in the Ted talks by 10pm; too much was going in the grey cells. I was, indeed, not looking forward to a fourth day of wearing the same clothes, then, a Dame in shining armour reared her head. I got a message via Matt Zimmer after the Ted talks: Tracy Quinn the wife of Java Posse member, Carl Quinn, Netflix, said she had got my snowboard at Gunnison Airport. The Java Posse team was also a day late getting to Crested Butte, they finally flew in on the evening flight.

Thanks to them, now I have my snowboard and trolley bag for this next morning. I am eternally grateful for their support and bringing my stuff over as well as other people who also had delay baggage to Crested Butte. We can go as we mean to. I have to rush off now to the Tuesday round-up the first proper morning of the Round-Up, wish me luck.

+PP+

“Why You No Train?”

February 1st, 2013 Comments off

It is a simple question. So why don’t you get more training? Do you feel that you operate already effectively? Is there no more stuff to learn? Do you think that you are already “good”? Sometimes,  just when we are walking about and we feel everything is going smoothly, then the bottom drops out of the bucket, our world suddenly of positivity, in the situation, our lives, family and friends, takes a nose dive to the other side. When our world changes to tragedy, conflict and controversy those times,we all experienced, can be really depressing and shockingly awful. These are the times when we start to kick ourselves, probably. We reproach ourselves with, “I should’ve done this. I could’ve done that.” Well the question at the beginning still stand, why do you not care about any changing the train, saving for a rainy day, and could of all of this tragedy be avoided. They say, prevention is better than the cure. We could all have done with some forewarning, some training. If you are expecting a company to train you in all things; then that is great, especially if you are a star performer on the ye olde balance scorecard, getting 100% in the 360 review, and if your boss is terrific, he and she will send to you training. If the company has the money to invest in you, when you are brilliant and company thinks so as well then they will continue to invest in you. For the rest of us mortal souls, though, we are not perfect creatures and probably never going to be fortunate for the big golden handshake of continuous personal development and abundant budgets. Some companies do care about their employers and give them a fair crack of training budget. Sadly, the training budgets for the common worker, developer and designer team are reducing month by month, and it is one of the first thing that are cut in a downturn. So if you are waiting for a company to send you on splendid trip to conference to JavaOne 2013, with all expenses, flights, hotels and tickets, paid; good luck with that. In the next section, I thought about some insights in to the gaining personal training, divided in two sections. The company does not want give you the training you really want, what can you do as alternative.

  1. Spent your own personal money and funds; if you believe in it and then you will do it
  2. Negotiate with the training company, they might be able  to cut you a special deal on a early bird that far enough in the future.
  3. Find a user group who are doing a coding group or the practising the skills you desire
  4. Find another organisation to work for, watch the job adverts for up and coming talent and especially firms with attractive starting gifts like those willing to throw in a Retina edition mac book pro; trade that in for the training instead as a condition of joining
  5. Find another job that pays more money and then personally fund the training you need
  6. Trade skills with a pal. Suppose you have reasonable advanced knowledge in No SQL databases, like Mongo DB, and want to learn better JavaScript then try good old-horse trading with a colleague might just be way to get training on your side as well as theirs
  7. Don’t accept the classic answer from the boss, “How does X help the business?”. If the training is relevant to you achieving a goal of being a much better software engineer and designer, then, of course it is relevant. These types of answers are just excuses to keep you, bedded down; to just give in and accept the status quo, which, of course, is utter nonsense. Perhaps, the time has finally come to find better job.
  8. As a last option and certainly one that I personally can testify for is, you could become a contractor instead of an employee. As contractor you find, organise and pay for your own training, because it is up to the contractor to stay up to data and learn new skills. Training counts as unpaid leave or can taken between subsequent contracts. Contractors may have certain tax advantages for training and materials, and of course, more money means you can attend more training and conferences.

Ok let suppose you are the boss, you are the line manager and you have a good team.

  1. Fight for your team and their training; fight for your team’s budget and don’t let the senior management take it away
  2. Give up your personal training for the entire year and suggest that they allocate the extra budget to training for your team members
  3. Perhaps, it is time to evaluate the relationship with the preferred supplier of training, if your company operates like this. Have your firm been getting decent value from the PSL (preferred supplier list)? No, then try an independent trainer, a famous speaker or find a lone runner, who is much smaller than the big training business, but can deliver bespoke training to you company. Procrastinating on a bad PSL is a waste of everyone’s and your business’s time.
  4. Find alternatives to training like brown bag lunches, collaborate with other businesses
  5. Get on the old blower (the telephone) to the training company and use your managerial skills to negotiate rate especially for early birds far into the future
  6. Take the sword for the team when your boss says the training budget has to be cut. Say that you will resign if the team’s training budget is cut. They will probably think hard and fast, the cost of recruiting another person just like you, training somebody else up in your role equates to training for about 4 or 6 developers.
  7. Don’t be idiot and attempt to coach or mentor in the training yourself, especially if you have no idea what you are talking about. Don’t go cheap, go for the quality training for team member.
  8. Use so-called creative accounting and budget, stick too fingers to human resources dictum, find an independent trainer not for you, but your team. Use the magic entry in the budget cover the training. Insist to HR afterwards that you wanted your team to be best, be productive and get the job done with higher quality. If HR still don’t like it, then perhaps it is time to be a manager in another firm, because your firm would have shown their idea of value of people in the organisation. (If you are going to leave, think about taking your best pal with you.)

Without commitment to training and learning new skills there can be no continuous improvement, which is one of the prime directives for Agile and Lean engineering. I hope that I have given you some great ideas. Everybody needs training and self-improvement; don’t let the government or business tell you otherwise. +PP+

Categories: Agile, Communication, discourse, Economy, exchange Tags:

Some Advice for New University Graduates; Dreams of Developing Software

December 26th, 2012 1 comment

I have taken a step back in an attempt to put the year 2012 in focus. As always, it started with great hopes and there were highs and it seemed for a moment, that working life was back on track, but lurking in the background was an impending disaster. The problems were not fixed, I can see them now, but that is for another blog post.

In this post, I went with another angle of working life, I pondered for a moment, what on earth would I tell myself as the twenty something university graduate? What advice would I give to another university graduate now?

Tools, Frameworks and Languages

The tools for writing applications are definitely here. At the end of 2012 there are an abundance compared to slow pre-Internet age of 1992. You have lots of opportunities in programming languages such as Java. It runs on a virtual machine and you can forget about dreams of C++ being a guru engineer and purely object oriented development. The landscape is changing. I would say learn something about functional programming languages. You have to learn version control systems such Subversion, Mercurial and Github. Take advantage of the new technologies for learning, videos and on line courses, broadband Internet, and ways to amplify your knowledge. Remember: technology is not the answer, a panacea on its own, it only exists to serve to every human being, to provide efficiency, improvement and greater achievements in progress. Out there is such a breadth of knowledge waiting and so little time to learn it all. Choose your technology and learning wisely.

I would warn myself about the dangers of social networking, and suggest you would do the very same. Privacy is dear. Code and ideas are dear. Keep some part of life in the off-line mode for your own security, if nothing else. Other people have been known to take ideas with out credit and attributions. That drunken binge or that slur against some person could in the future become a living nightmare. Only ever put on the Internet, the stuff you are truly happy to let be public knowledge; find the balance between share-nothing and share-almost-anything for yourself. Be wary of code that you do put out there in the Internet.  In my opinion in the future it could be held or used against. If you are showcasing ‘wares make sure it is the best work that you can do, don’t be shoddy or lazy about programming. Being part of open source framework as a committer is a good thing, it will open doors, and you get to meet electronically people on the other side of the planet. You might even be lucky enough to meet the other committers at conference or visit on holiday; maybe they may come to you. Life is better with the people you know; who know you and therefore have a bond with.

Because they are too many tools, frameworks and programming languages out there, I would advise myself to choose the special interest wisely with a view of what is going to benefit my career in the long term. Nobody can be master of all trades in IT. Now, our profession is too long in the tooth for that. If you want to be good developer, be that, a database girl be that, a security dude, then be that. Practise, rehearse and train in order to “get good”, only then will you become great at whatever it is you choose to do. Choose something you enjoy not the thing that your mother and father tells you that you must do. Listen to your beating heart first, before listening to the opinion of other people. Develop that gut, that the gut-feeling, the little voice in your head, the spirt that comes sometimes you feel exciting or when there is a sudden whisper of foreboding, an ill-wind, whatever, because it is true. It is the one statement of a fact that is not a YAGNI, you are going to need it, your inner voice.

You must live and work with other people. If the code is an experiment and is just for fun, then advertise as that with a definite label. Code is also nothing with people. Unfortunately code is the easy part, it is the dealing with the people, the communication, the handling of information between groups of folk, the social aspects, which are the hard parts.

Elitism

Surprise, surprise: be warned that Elitism is still in effect. Nothing has changed since the early 1990’s in what is legalised prejudice of university graduates. Employers are allowed to specify on job advertisements that they are only interested in certain set of candidates from so-called red brick universities [2] even though this smacks in the face of diversity and fair entrance. There are employers wanting the so-called best software developers out of university or higher education college, if you have less than second-class first level degree (2-1) your application might tossed directly straight in the bin [1]. In my day applications were sent by post, now it is quite easy to discard a very crafted Word or PDF document in to the digital waste receptacle in the sky. Yet, it is common knowledge, or it should be, in the IT profession that a certain Mr Bill Gates, of Microsoft, did not even graduate with a degree.

My advice is to the same now as it was then, Keeping On Moving [10], there are always alternatives to elitist organisations, which may well go out of business sooner rather than later. I learnt very quickly there is always one choice, colloquially, known as The Law of Two Feet [9]. All you have to do build on the network that you started whilst in university. The teacher or lecturer you did the best project for, the mate that you had the best times with at the pub, even the gym is a place to find and discuss opportunity. If you have impressed a friend or colleague and if they are really your friend, know you personally, then you are more likely to get opportunities of work that are more suited to your skills.

Job Shock

During the early 1990’s the world was recovering from previous financial crisis, albeit it was a smaller compared to the massive crunching meltdown that we have had running now for five years, since 2007. For the record, I am also grating my teeth too, in frustration with you too.  I feel. I am a human being too. The shocking stories of the job search of recent university graduate have left me cold.

There was a time before the monetary union of Europe and the Euro, when each country in the European union had it’s own currency like the Deutschemark, the Franc, the Peseta and Lira; and therefore their own national bank of control, of monetary policy, then there was the possibility and the economic reality of at least Germany still being the powerhouse of Europe and the World when Britain was in the doldrums. Indeed, Germany was able to survive the recession of the early 1990’s, I know because I was living there for a time.

Since the turn of the century, the sudden explosion of the Internet, the reliance on better communication links, the rise of common markets, radical improvements of technology, better efficiencies in trading have meant we have a global economy.  The door has closed forever on hoping over the English Channel to find lucrative work, even if the language barriers were not there at all. A recession in Germany most certainly means a downturn in Britain and Ireland.

For university graduates, this means that getting a job search is much harder than 15 and 20 years ago. The competition is fierce; the depression is deep. Some graduates wondered why they have invested their formative years in to getting a university paper only to find themselves flipping hamburgers at McDonald or desperately applying to become a retail shop assistant at the local Debenhams or Next fashion store [3][4].

The Job-Shock of 2012 is clearly worse than 1992.

Eric, Newcastle

I have just passed my 1 year anniversary from my master’s degree. There’s nothing to celebrate because it’s also the same time I started looking for jobs and 1 year on, I have had no success. I have been to nearly a dozen interviews to progress on my career to be an engineer and have had no success.

Laura, London

I completely understand what you guys mean. It is so hard to keep motivated when you keep getting told, “Sorry, you haven’t got enough experience” and then you say “but that’s why I want a job!!”

With the two years from finishing my degree to starting my graduate job I gained experience and continued to apply. Getting experience isn’t easy though because quite often you need some experience to get experience. My advice is to plan what skills you want to show experience in then make a plan from their, starting with smaller experience and aiming for the bigger stuff when you have something in hand.

We are losing young and gifted people across a wide-cross section of disciplines [5]. Some are giving up on their dreams of having a career. Sadly, some people who thought about a career in information technology, software development, programming or designing applications, may already be saying to themselves: too long and hard to achieve the result I dreamed of; do not think to apply because it never happens to people just like me.

Continuous Reinvention

I am here to tell you that if you want to get a programming job in information technology then it is possible. Don’t give on IT just yet. The roles are there, if you keep looking for them. It is quite similar to dating. Two people will never meet each other, if they stop searching of the other lover. If either one of them gives up then the cause of true love is lost. But then, how do I find a job? A better question is, how do I find a job that I really will enjoy? The best and ideal way to do this is, I think, is to find that company and group of employers that is enthusiastic, altruistic and cultured. In other words, the company must have a distinct lack of dysfunction, but you as a graduate candidate have already found that to be true, yours suspicions, which you most likely experienced on the job hunt are quite correct, I am afraid.  You absolutely correct to note that every company that advertises, “We hire only the best candidates”, is logically not “the best”.  Learn to read those job specifications and as some would say read between the lines. Ask some searching questions: what happened to last year’s recruitment? As an addendum to the infamous and standard question: How did this job become vacant?

Start networking when your career is in infancy. Keep your ear to the ground and listening and learn the behaviours of others. It is sad, but true, in the IT career too, you have to watch your back as well. Resist the temptation to be closed and unapproachable, instead be that person, open to change, a mind like parachute. Remember who put the faith in you and got you to this great position that you are in now. You have a university degree or better, not many people in the world get that, and those who try to put you down, are jealous, because when they had their chance in life, they bloody blew it. Just because they took a mis-step then that does not mean you are going to. If you really want to be black and proud and be bad meaning good, then for heaven’s sake, buy the CD or download the MP3 of Public Enemy: Fight The Power, Rebel without a Pause and Bring The Noise [8]. Rock on out in your bedroom when you feel the world is against you. For all other people find some inspiration and music to gets you going, motivates and inspires positivity in yourself, whatever it is, whether music, theatre, classics, walking the dog, or a landscape that you remember as a child, then keep on at it and make it your central core, your sword and shield in the battle, the battle of survival.

When you leave university and get on the job market for the first time, it is a great time to learn and identify the different types of institutions. For instance, you may have thought that big company ACME was the best for you to a get a job in, perhaps you were tempted by the glossy brochure, or the suited and booted personel at the job fair, maybe they had the best gizmos in the handout bag at a conference; and then you later find out that the much smaller FROZFIZZ is better. You will be probably be surprised at youreself suddenly turning to the FROZFIZZ, and finding this smaller enterprise attractive. Maybe it was because they have a better training scheme, perhaps they send there employees to get  proper IT certifications, and perhaps they offer a real chance to use the next interesting new technology or framework there. More often or not, the FROZFIZZ employees seem really happy ,warm and generous. It is not fake, because you can confirm from a friend who recently got a job there. That is good-cultured. You know it when you find it. Some people spent their life trying to find the good culture. Okay, FROZFIZZ has a much lower starting salary than ACME and they cannot afford to pay an contributory pension plan or some other additional benefits compared to ACME. This is the time after university to learn how to measure up and down different employers when, most likely, you have not yet got the husband or the wife or long term spouse to bloody annoy you and you can concentrate on what is best for you and your career. Twenty years down the line, you will not regret choosing happiness in organisations like FROZFIZZ rather the gravy train of ACME. In fact, it is better to have worked at series of FROZFIZZ like companies than stick to the pressure and unloved atmosphere of ACME for ten years, even if you start climbing the promotional ladder in to senior management. The one thing that I want to hit you home with, that is almost universal truth, “The People are the Company”.

In software industry, which is a global economy, being comfortable where you work and when you work is the most important reason for having a career. Yes it can be learning Java or Scala or Groovy some other programming language, but if the company is dysfunctional then the world can feel like a horrid place. In this day and age, we are rapidly seeing the decline of a job-for-life. If you cannot change the organisation, then change the organisation.

Some people, do leave the country just to find that the one opportunity to start an IT career. If you want my advice, and you are seriously considering it, then do it. If nothing else, you will learn a new language, if English is not the native language of country that you will work in, and you will have a different culture and outlook of life to tune it in. It will demonstrate to the world, on your curriculum vitate that you are one of the few who is remarkable, courageous and brave. Although leaving the country is tough and deliberate decision for many people, you can always come back after a few years. Even fewer souls, permanently leave Great Britain for the USA or beyond and never return, their lives changed because they made the decision. It is all about finding alternatives.

Remember you always a choice. Just ask Carol Vorderman [7]. Stay the course, and achieve your dreams of becoming a professional software developer; I guarantee you will not regret it.

[1] http://www.standard.co.uk/news/work/sign-of-the-times-graduates-take-to-streets-in-search-of-job-8226282.html

[2] http://en.wikipedia.org/wiki/Red_brick_university

[3] http://www.independent.co.uk/news/education/education-news/redbrick-universities-are-more-elitist-than-oxbridge-634051.html

[4] http://www.guardian.co.uk/money/2012/jul/04/graduate-recruiters-look-for-21-degree?intcmp=239

[5] http://www.guardian.co.uk/education/2012/jul/31/lower-second-degree-employment-prospects

[6] http://en.wikipedia.org/wiki/Organizational_culture

[7] http://www.guardian.co.uk/theguardian/shortcuts/2012/jul/04/dont-judge-job-applicant-by-degree

[8] http://en.wikipedia.org/wiki/Fight_the_Power

[9] http://en.wikipedia.org/wiki/Open-space_technology

[10] http://en.wikipedia.org/wiki/Keep_On_Movin’_(Soul_II_Soul_song)

+PP+

Your Next PR Disaster is Inevitable When You Provide No Feedback

December 25th, 2012 Comments off

This is a warning to the reader; your might feel at the end of this entry that it is all Dickens’s Christmas Carol and “Bah! Humbug!”. You would be rightfully semi-accurate in your analysis, of course.

Quite simply, I hate when I go to an interview that is either face-to-face with a potential employer, or a client, and then I have to fight tooth and nail to get those statements of fact that many ordinary souls could consider to feedback from the interviewers or clients. I am amazed, more often than not, in today’s climate when I get unexpected feedback; most of the time I have specifically ask for it.

In my long career of some twenty years or so, I have attended many competency based styles of interviews, and I have learnt in all that time, you cannot effectively improve your skills without a third-party honest ethical reference telling you exactly what you were strong on and what specifically you were weak on.

When I use skills here, I am deliberately being very wide in the definition of term; it can be communication skills, behavourial skills, technical skills or even sitting-still-in-chair-with-your-hands-motionless whilst you talking skills. I will also include puzzle solving, listening to the interviewer, technical analysis and getting off my bum to do a bit of white-boarding, and rapport building, submitting a sample test programming project and panel interviews as part of this scheme.

There is a nothing worse than when you have done all that you can do to perform by giving your valuable time and effort to a round of interviews, and then hearing the cacophony sound of silence; and seeing nothing wafting in the email inbox for a few days. If you have ever attended an interview and waited more 24-48 hours for an answer, and seen and heard nothing, then you probably know placing your on heart that this is an instant fail. If you have ever attended an  interview and got the answer of “no” and the client and the recruiter had no feedback in their response then that I too would classify the end as a similar fail. If you have ever received an “no” and then asked for feedback, and then also received a blank response, then, in fact, that is plainly rude. If you have never received any feedback from the interviews whatsoever then that series of flawed communication from a so-called officer of a reputable business, from beginning to end, actually, is very revealing about the target organisation; and says that perhaps enduring the entire process was a close miss, from your point of view.

Sometimes, after receiving a “no” from an interview, then I have, to be absolutely fair, received some great feedback and pointers on things that I missed and definitely things I could improve on. I have gone over those weaknesses, then revised, educated myself and rehearsed. I improved myself. Sometimes the mostly painful feedback is the stuff you don’t want listen to. I certainly had to train to listen and not just hear.  When I have won a contract and got the job I have learned what the interviewer and recruiter also thought about my appearance, skills, white-boarding and communications; basically the whole lot. So this gripe is not for those who are good at giving prompt, fair and concise feedback whether it is in a good or bad light. They do not have to worry.

In the earlier part of my career, long before the Facebook and Twitter, it was customary to receive the rejection letters through the post. Nowadays, it is the rejection email. For university graduate developers, in these Twenty Tens, it is now even worse, if they they do not receive a response then they may as well consider themselves rejected. Is this the state of business communication in the early twentieth first century? Really. And we thought that we were a classless society; elitism had been knocked cleanly on the head. Surprise. It never actually vanished into the thin air. When we have laden the front-door to new software engineers in our industry with a flaming glass ceiling of unemotional dependency injection. This action is a contempt for an industry and the people working inside it. This, very sadly, is a disgrace.

Dependency injection may work for building the infrastructure of application software and abstracting two components from explicit referring to each other, but does it work not at all for human beings, especially the newest talent? Feelings are hurt; belief and hope with ambitions are trampled; dreams are thrown asunder. No wonder it has hard to attract new people; whether they are youngest and brightest undergraduates, or they are mature folk and utterly serious about retraining in to computer science, if this final result of lack of feedback is a spit on the face, which they have, ultimately, to look forward to.

It is just not enough to say “no”. It does not help the recruitment consultant and the prospective candidate. How can the recruiter help to get better people for the organisation? How can the candidate ever know what went wrong? We are reaping bad karma and more misery on those people who are trying to keep fighting the good fight.

The stock answer from the client that is unforgivable and long-term patched in the synaptic memory is “Sorry. I am so busy that I really cannot afford to do it. You want me to give feedback on all of the candidates who interview here. I got more important things to do in the meantime. Unfortunately, I don’t have time for that.” If you read that and do happen to agree with that sentiment, then shame on you. Here it is the crux; effective candidates require feedback. Senior developers and technical leads always want to improve. The most talented inexperienced engineer who only has a couple of A-level’s wants to improve. If you do not care to give feedback, I guarantee you this fact; they will remember you and your company. Candidates who interview with or without a recruitment agent deserve feedback. You, as a technical leader, have a duty to provide it. It is your job description, so just do it.

It will be a terrible day when one of those candidates that you interviewed and failed to provide feedback for remembers you and your company when they do just give up; and instead grow to become to the next successful generation of rock star developers: a public relations disaster of your own making.

+PP+

PS: Managers and technical leaders need to be give regular feedback direct to their team members. If they do not then they are not being effective in any organisation. If they want all people to perform then they need to coach and mentor others too in order to become better.

Categories: Business, career, discourse, diversity, it, leadership Tags:

Agile Software Developer Terminology for New Programmers

December 21st, 2012 2 comments

This is a post for new developers, young, inexperienced or old and retraining into information technology.

Recently, I had a discussion with many engineers at one of those many London user group nights about how there is so much new stuff that we have to explain to people new to programming. One person had to coach a graduate developer on writing unit tests. Another person had to explain the reasons why dependency injection is better than dependency lookup.  I can recall similarly stuff, being able to gently and concise explain why we should have unit tests in the code, and why we need them.

Here is my current matrix of terms:

Term Description
YAGNI You Are Not Going To Need It – The issue hare is that far more code is written than necessary to solve or deliver application functionality. 

Classic symptom: Added unused finder methods to session beans in Java EE

DRY Don’t Repeat Yourself – writing code that has lot of duplication across methods, classes, packages and package object. 

Classic symptoms: Copy & Paste coding in unit tests and repeated metadata in entity and the front end

KISS Keep It Simple Silly [or Stupid] – a mantra to describe writing only code to solve the function problem instead of writing a less complicated codeAlso see Occam’s Razor.

 

Classic symptom: Too many abstract layers in a software application

WET Write Every Time – the antithesis to DRY, where code is deliberately written that repeats lots and lots of time in different classes, packages, and functions. 

Symptoms: Deciding to do things your way and instead of collaborating with the other developers and finding some common ground.Classic antidote: DRY, Unit Tests and Code Refactoring.

WETTT Write Everything Ten Thousand Times – the hyperbole colloquial version of WET
R3 Rules of Three – This is not the proprietary operating system of the same name, or the classic 1980′s arcade game, or either the description of a maxed out pimp-my-ride Volkswagen Golf; but the idea that when ever you have three duplicated parts of code in a method, function or classes then it is time to refactor the duplication in to single method. See Rule of Three computer programming. 

Related to DRY and WET

 

Class Symptom: Ignoring the code repeats because of time pressures, or the Scrum master says no, don’t do it in this sprint.

DBC Design By Contract – the idea of building a service from a contract first. In Java you write the interface as simply as possible and then secondly worry about the implementation class.

 

Interfaces are easier to refactor around and because you can plug different implementations into the interface you get higher cohesion and lower coupling.

 

Classic Example: JDBC specification since version 1.0. There are tons of implementations for different relational databases including MySQL, Postgres, H2, Derby etc.  Every Java programmer knows how to code against JDBC because that they don’t have to fight with an different implementation, which vary, because the DBC implied it will do the right thing most of the time.

 

Also related to standardisation of application programming interfaces.

BDUF or BUDF Big Up-Front Design – a problem with many large corporate institutions that sometimes require a 100 – 1000 page document full of business requirement before any software construction gets the green lightSome poor architect or business analyst will have spent weeks investigating and chatting to the business about the requirement, only for the development team to say the document is practically worthless.

 

Antidote: Get the technical lead and some key developers talking with the business and the analysts and the customer. Ideation sessions everybody!Symptom: Waterfall methodology and aspects of the investment banking IT culture

 

Antidote: Unknown, lots of people how tried to bring “Agile” with both a big A and small A to many of these institutions with some success and failure

Pink Book Describes the book with a Pink Cover called Extreme Programming Installed by Ron Jeffries, Ann Andersen, and Chet Hendrickson. I do not recommend this for new starters unless for reference, since the Pink Book is now rather old, 2000, there are other more recent Agile development books and courses that help new Java developers.
YOLO You Only Load It Once [If Ever] – this is related to fact that you want to have a single source of truth in an application system. This is problem of mis-architecture, where someone has not thought the functional requirement through enough.

 

Classic Example: Shopping Cart Service EJB – you only ever want one implementation of the pay-point in an application, albeit you will have many pay-point providers (credit and debit card third parties and PayPal)

 

The If-Ever part is YOLO and YAGNI added together. You are not sure of the another part of the system loads the data, so you decide to keep the component. (You probably want to put a logging client on the YOLOIF thing so that you can effectively decide to chuck the component if nobody has used the function in 12 or 18 months time.)

 

Digression: If you have find data that is constantly being uploaded to serve a web request then perhaps it really needs caching and not YOLO.

Spike A quick exploration of coding in Sprint in SCRUM methodology, which is also time-boxed inside a single sprint, usually. In a Spike you are probably are looking an new API, like a cloud service or user interface API like JavaFX or similar and basically you explore if the function can implemented relatively well in the new API.In short, you are trying to build some confidence in a new area before committing yourself and other resources to it. Spikes are usually contained and protected from the flow of the critical path and restricted to a time length. See SMART goals. Once your team has gained confidence and knowledge in the new “thing” then reasonable estimates can be made.

 

Classic Examples: Adopting a build system – moving from Apache Ant to Maven; moving from Subversion to Git; Adopting a new open source library

TDD Test Driven Development – often conflicted as not being fully explained as a change of discipline and mind.”You are only ever doing one of these four things: writing unit tests, writing production code, refactoring unit tests, and refactoring production code; and never doing more than one at these previous at the same time.”
TFD Test First Development – builds on the ideas of TDD and then extends the discipline to writing unit test code before any production code.”Once you have a brand new unit test written completely, then you make sure that new unit test(s) actually fail in order to switch over to writing production code ensures the the new test passes.  After you have done that, you refactor the tests. Run all tests for all the green bars. Refactor the production code and runs the tests for all the green bar.Repeat: Go back to the start; write a new unit to that will check validate operation of the next function for the application. Repeat with the same formula as above.”

 

Velocity This is often misunderstood as a very basic measurement on the Return-on-Investment for SCRUM/XP software development and it has nothing at all to do with financial services, budgets and/or reporting. The creators of SCRUM/XP now disuade velocity as a ROI indicator at all.

 

Velocity is the number of story points completed per team per iteration. To the SCRUM/XP  experienced: Velocity is equal to the aggregated units of work completed over aggregated time intervals, which implies you measure each progress of tasks in two or more sprints.

Story Point For each user story in the sprint or task, predict  how hard it is to implement by using unit of reference. 

Story points are usually written in Fibonacci numbers: 0, 1, 1, 3, 5, 8, 13, 21, 34, 55, 89, 144Every agile team in the world has a definition of a user story unit point.Teams decide on the backlog items in order to come up with predictions and these joint predictions every member of team go to decide what should applied to the next sprint.

DTSTTCPW Do The Simplest Thing That Could Possibly Work – Related to Spike and KISS in many ways. If you are pressed for time and some trading systems developers in investment bank are then this is your working life. 

DTSTTCPW certainly invites team collaboration and effective sound-boarding from other developers and members of the team, otherwise you are asking for trouble.

VoC Voice of the Customer – This is a term from SCRUM methodology, but I am about 20% unsure about this one; I believe 80% of the time to mean a proxy, a placeholder, for the real customer, the person who understands the business requirement and will of the customer. Because the true user is unavailable for some reason due to authority, culture or organisation, or even geo-location. 

Some people have amusing called this abbreviation, the Voice of Reason, especially when they do not enjoy working with the customer directly.

Unit Test In Java programming, a Unit Test is a Java JUnit framework test class or TestNG framework test class that specifically verified and validates a single function of work in an application 

A unit test requires a target, which can be a Java Class, a Service Bean, Managed Bean or something implements the said functionality.

 

Unit test are often seen as low-level fast and efficient tests.

Functional Test A functional test is a larger test, which can also be a unit test, designed to test packages of classes or sub part of the overall application infrastructure. Functional test validates if the application meets one of the customer’s external requirements on performance, results and efficiency.

 

Symptom: a functional test is not necessarily a unit test, and not all functional tests are acceptance tests.

Acceptance Test An acceptance test is the same as a functional test in name only. Acceptance tests are those where the customer wants to see the validation pass in order they sign of the implementation. 

Symptom: If the customer is disastisfied with the application at demonstration time, then at least the one of the acceptance test is broken. Add one in the next sprint.

SOLID A set of five principles:Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation and Dependency Inversion.
Single Responsibility Principle An object class, a service bean, web service, a function or procedure should have only one single responsibilitySymptom: It is hard to write unit test for complex object, because it doing WETTT
Open Closed Principle Open for extension and closed for modificationIt means you can subclass the object, but the object is encapsulated by not allowing an outside object to gainfully change the internals. 

Symptom: leakage in object implementation, hard code dependency, and not working with Java interfaces (or interface like constructs i.e. Scala traits and mix-ins)

Liskov Substitution Principle Idea of swap-ability and is expressed as a Design By Contract (DBC).I can swap in another object X which is an implementation of T if that objects is a type of T and the overall application works.This is the basis of mocking objects, mocking implementation frameworks; testing in general; proxy remote objects, persistence capable objects; application server and lifecycle monitoring situations; plug-and-play and restartable applications. I could go on, but I won’t.
Interface Segregation Principle A service interface that does only single specific functional thing is better than a service interface that does several different things. 

Symptom: Failure to adhere to the KISS principle. In days gone, the non standard C++ String libraries where everybody threw in the kitchen sink of methods for any operation that one would want to write that manipulated a C/C++ String (char*)

Dependency Inversion Principle Idea of not hard-wiring a direct relationship to a dependent into object.In Java EE world, you would use a dependency injection container such as CDI to inject different managed beans into a service bean. 

Dependency inversion also should mean in my humble opinion given up on managing the life-cycle of service components and beans. The lifecycle is managed by the application container, the cloud provider or whatever it is you are using.

 

In another school of thought: every application is managed these days, whether it is the operating system, a virtual machine or web container or mobile platform (iOS and Android). This is the way forward.

Design Patterns A classic book on Design Patterns by Erich Gamma et Al. 

Ask your local technical leader to lend you his or her copy of the book; and if they don’t have a copy then that really sucks. Tell them to give you a personal training budget and buy the book yourself!

Glad to be of service to all my readers.

Merry Xmas and Happy New Year 2013!

+PP+

PS: I, once, had a notebook and file with a lot more of these terms with or without explanations. If I find anymore abbreviations and terms that I will add to this blog entry.