Software Basics Brushup Brownbag

I posted the slides from my latest presentation at work onto SlideShare.

Enjoy!

Senior Developer Interviews: Tales from the Trenches

From my experience as a Junior Software Engineer and Java Developer, since there is such high demand for software developers as soon as you qualify for a job in the field you have a pretty good chance of landing one in short order.  Trying to go for a Senior Developer job broke the mold in a number of ways.

First off, people rise up through the pay grades for the first two levels pretty rapidly, which means that you're competing with people with approximately your experience level.  However, people with TEN years experience can be applying for a Senior Developer job.  This of course means that the required 5+ years experience is going to put your résumé not looking too hot on paper.  However, you can tell yourself that you "punch above your weight" so you'll impress them on the purely technical side.  Easier said than done as they say.

In the first two tiers, you're treated as a technical specialist.  You just have to be an expert in JavaScript OR Java OR SQL, and you're not even really expected to know in detail how those fussy clusters of computers with their web containers work in detail, that's IT's job right?  Not at the Senior level though.  You're expected to be able to prance about the entire software stack with ease and grace.  Saying that the JavaScript prototype concept is kinda like Java inheritance and leaving at that isn't going to cut it.  Confusing your jQuery with your XPath is not going to cut it.  Not knowing how to make a Java Singleton a true Singleton when deployed to a clustered environment isn't going to cut it.  Not knowing the difference between an inner and outer SQL joins isn't going to cut it.  Not knowing the details of your web containers' class loader isn't going to cut it.  On top of all of this, you're expected to have excellent soft skills at this level as well.

Just getting over social anxiety by taking a metric ton of Prozac every day is just the preliminaries of the soft skills you're going to need.  In addition to being able to charm people ("Hay!  I thought engineers were allowed to be socially awkward!"  Nope) and having the standard "Excellent Written and Verbal Communication Skills" where you thought communication skills were being able to feign interest in Steve's ukulele collection and your bosses Whole Foods shopping, veiled "spirituality" references and superstitious neo-hippy quasi-Eastern bull****, but also be able to orate and deliver technical speeches / presentations and be able to handle yourself in the office-politics charged meetings that you'll be invited to more and more. All the while keeping your code throughput high and keeping your inboxes at 0 (you also should have read Getting Things Done by now, or the context switching will require a few buckets of daily anti-psychotics as well).  Did I mention a strong social media presence and a great Klout score too?

In summary to snag that $100k+ Senior Developer job you won't just need to hone your existing skill sets, but learn many additional ones as well.  You will need to possibly hold a regular Programmer position until you have 8-10 years experience.  You will need to know the entire software stack to the point of being a quasi-superhero of computation.  Lastly you will need truly overwhelming social skills, including conducting presentations, giving prepared speeches and attending and holding meetings.  All in all, I have about 7,000 pages of books queued up to read to bring myself up to these levels, because possibly the most valuable skill you can have is being able to rise to a challenge.

"An Upgrade Without Downtime"

Over at Udi Dhan is a summary post about Dennis van der Stelt's blog on how using a publish/subscribe model and large buffers allowed for power-cycling critical infrastructure without affecting the overall system performance.

It's the first time I've read something about software development and genuinely thought "epic".

Something Important Happened

I just caught on the eetimes that there is a new software engineering certification.  What makes this a big deal is that it's by the National Council of Examiners for Engineering and Surveying, something that has an actual track record.

The test info is also on their site, look for "Software" in the list.  As the recent spat on Yahoo's CEO demonstrated, there isn't currently an equivalent of the engineering certifications in software.  This may change that.

This may prove to be pivotal for the field of Software Engineering / Programming / Whatever we call it.

NOW I Get It: Aspect Oriented Programming

After going through the Aspect related chapter of Spring in Action the concept of Aspects finally "clicked" for me.  This is after reading the Wikipedia on it, the Spring documentation and various other articles as well.

To summarize:

• Some things (like logging) need to be executed everywhere, even in modules who's primary purpose isn't logging.  Aspects address this issue.
• An Aspect is just a bit of code (with Spring it can even be a POJO) that is configured (typically with an annotation or XML) to run before, after, or around a join point (for now, assume it's a fancy word for method).
• For the canonical example of logging, you can create an aspect to log something like "Calling method x with parameters x, y and z" before a method runs and "Returning from method x with return value y" afterwards.  
• This separates the logged class from the logging system entirely and results in a second class logging the first one.  
• If you want logging statements in the middle of a method, too bad, refactor to call a helper method (thus creating a new join point) and log there.

Hopefully presenting the gist of it with concrete examples will help everyone's understanding.

Gower's Law

Gower's Law: You can deliver a broken build in near-zero time.

(PS: thedailywtf article in the above link is gold)

This was inspired both by Peopleware (where they mention that when there is a tight schedule quality usually suffers) and my own experience in the work force.

Testing, Testing and Testing

You hear it in real estate: location, location, location.  You hear it (not as much) in software: test, test, test.  However, in software the tests are all different.

A recent project that I'm on involves a venerable app with as much technical debt as the US Government... and we need to add a feature.  Solution: tests, tests and tests.  More specifically if you don't know the different kinds of tests:

• Good old Unit Testing, easy to implement and understand, unless...
• You are getting used to mock objects (e.g. JMock or Mockito)
• You are testing database functionality and are new to DBUnit
• You are testing a web app or Servlet and are new to HttpUnit
• You're confusing unit testing (ONE module) with integration testing (multiple modules)
• Example: testing your Data Access Layer (DAL) with a dummy DB, like a local HSQL
• Integration Testing, usually implemented with a framework that ends in "Unit" so it's easily confused with unit testing.  Integration testing integrates two or more components, everything from two classes to the entire app with a dummy DB.  Due to this you can have multiple levels of integration tests, each testing more modules together.  Examples include:
• Testing a servlet in HttpUnit's ServletUnit instead of your actual web container
• Testing your DAL with an "actual" database (whatever actual means to your project)
• Testing a fully created Spring bean with the real beans injected instead of mocks
• System Testing, this is tests of the entire system
• QA usually conducts manual system tests
• There can be automated ones as well with things like Selenium
• As an example for a web app, using a supported browser to use the app in the final web container and using the real database.

There is of course, much more to software testing, but these three are usually a good start.  Heck, in many organizations / projects even using unit testing is new to people.  Like Regan said: trust, but verify.

PS: There's a good post at EvilTester with a more philosophical approach to testing.

DBUnit in Practice

For those of you unfamiliar with DBUnit, it works with JUnit to put a database into a known state between unit tests (e.g. you can wipe out the DB and start from a blank on each run if you want).

I've recently picked up how to use this technology in practice, and this article will help others ease the (somewhat steep) learning curve.

I found DBUnit to be a very collaborative technology, in the sense that it interacts with a lot of other technologies to do it's job.  First off, DBUnit does not PROVIDE the stub or mock database, you'll have to provide one yourself (Apache Derby and HyperSQL are swell for this).  Secondly you have to establish a connection to the DB yourself (using JDBC) and thirdly you'll need to create the tables for the DBUnit data yourself (e.g. via SQL CREATE TABLE statements).  Lastly you'll need to dependency inject (if you know Spring than this concept is nothing new) your JDBC connection object going to the test DB into whatever class you are going to test.  THEN you can run your DBUnit tests.

In conclusion, you need to use a lot of other technologies and paradigms in order to truly use DBUnit.  I hope that this overview and the links help.

A Technique on Comments: The Separation Banner

In a lot of commenting best practice articles much ballyhoo is made of commenting in the small (single lines or methods) or at the class level (headers, footers, etc), but it seems hard to find anything in between (e.g. what is a good way to separate major parts of a single class).  This article will explain a technique I've seen used, but haven't seen named before or expounded upon: The Separation Banner.

Quite simply, a separation banner is used when you need to demark major blocks of a class or other source-file (assuming you aren't using Java) to aid in visual navigation and in keeping the class in order.  The pattern I've seen the most is a line of slashes (i.e. enough to fill up to the 80 column), two slashes + text, and another line of slashes.  E.g.

  //////////////////////////////////////////////////////////////////////////////
  // IFoo Implementation
  //////////////////////////////////////////////////////////////////////////////

Other examples for the text inside can be things like "Accessors" "Static Methods" or "Inner Classes".

Humorous Image brought to you by
Digital Storytelling and The Simpsons

In general, I have found the separation banner to be quite useful, and created an Eclipse code completion entry for it so I can avoid adding all of those slashes every time.  As always, you can have too much of a good thing so having one banner for every five methods or more (roughly) has worked for me.

So, next time you frequently get lost in the inner muckings of a class, consider adding some additional structure with a separation banner.

Best of Perl - Plain English if Statements

I worked with Perl for a couple of years and I miss being able to write code that feels like plain English.  I've managed to capture a bit of this into plain old Java by using self-documenting booleans instead of actual statements in if statements, as in the following:

final boolean fooExists = foo == null;
if (fooExists) {
  // code here
}

Hater's Gonna Hate at Zoitz.com

This seems almost too simple to deserve the declaration, but you can also write more complex statements like "if (fileIsOpened)" or "if (stringHasContents)" (i.e. not null and not empty / blank).  In particular, it helps when re-factoring someone elses code to understand what an if block actually does or MEANS.

NOW I See: The Realized Benefits of Unit Testing

We all know the things that we are supposed to do, but don't as much as we should: eat fiber, cut down on sugar, don't be sedentary, exercise, eat fruit, unit test.  Blegh!

Not my exact point, but pictures about
unit testing are hard to find!
(Image from Reportnet)

For the last part at least, I came across some actual useful results.  Before, whenever I wanted to unit test a class, I didn't write a test for it before and usually had to ramp up on another technology to boot (JUnit3 vs JUnit4, HttpUnit, DBUnit, Mocking) or realize that I really wanted an integration test (jMeter, Selenium).

This time however, I spotted what looked like incorrect code and there was already a unit test for the class!  I was able to write a short test that verified the bug (i.e. wrote a failing test), fixed it and reran the test successfully!  All this in less time it would take to run mvn verify (including deployment to WebLogic)!

I'll be a bit less loathe to write tests in the future now, since I actually SAW that "it's better in the future" thing they say about testing.

Valhalla Koan: Logging Without Logging

OK, this isn't really a koan, because there is an answer.  The more mundane version of the question is, how do you make log statements to diagnose why your favorite logging framework isn't working.

Just as parents can learn from their children, those close to mastery can learn from the neophytes, System.out.println is usually acceptable (you're web-container may vary).

If you're using WebLogic 11g, their logging documentation can be just as confusing as a koan.  Fortunately, as a part-time hipster I'm really into their earlier work (i.e. their prior documentation actually makes sense).

So, to get to the point, if you want to use the WebLogic logging before you initialize your favorite like (like Log4j) you can:

1. Use the simpler WebLogic APIs for logging until your main logger is working.
2. You may have to have your WebLogic server use more logging statements (mine was set to only WARNs and above but all of my logging statements were INFO until I changed it).  You can do that by:
1. Logging into the WebLogic Console.
2. Going to Environment -> Servers.
3. Select the server you want.
4. Click on the Logging tab.
5. Expand the Advanced section.
6. Turning everything to DEBUG or TRACE. 
7. Save your changes.
8. Restart the server.
9. Finally, redeploy your application.
3. Then you can trigger the early logging statements and view them in the WebLogic Server Administration Console.

If you're familiar with Oracle and WebLogic products, you appreciate how this is as simple and straightforward as it gets.