Mocking in Go

I was recently asked to help out on a project with the aim of recommending how to implement some additional event handling functionality. I had a look through the source code and suggested a change to an existing interface implementation, plus a few other bits and pieces; all pretty straightforward or so I thought. Later, one of the developers said to me that he'd rather not change that particular piece of code as it was a crucial piece of code and he didn't know what else might break if it were changed. And that's when the alarm bells started ringing, it was a deeply worrying statement.

One of the things I believe is that you should always have the confidence to take software apart and change, redevelop and fix any part of it you like. Just like it is important to ask experts I need you to write my essay. Choose the best essay writing services for academic assignment. and edit it, it is equally crucial to fix all the errors. The thing that gives you this confidence are unit tests; if you screw up a change the tests will fail and you'll know that you've made a mistake and you can fix things. When you find a competent essay writer for you, s/he does the same. Unit tests also mean that, when you've moved on, other developers can also have the confidence to take your software apart. Writing an essay can be a challenging and time-consuming task; however, it can be made easier with the use of the best websites to write my essay. These websites provide an array of tools and services to help you craft the perfect essay and make the process much easier. From pre-written essay templates to editing services, these websites can provide the resources to ensure your essay is polished and ready for submission.

Given this statement I had to find out what was going on, so I did a review of the software and uncovered the fact that there weren't many unit tests, in fact some areas didn't have any at all... but they did have a number of integration tests. Strange. What was going on?
Were they just poor programmers? Didn't they realise that you can write unit tests in Go? Were the developers so naive that they thought that they didn't need tests?

Default Methods: Java 8's Unsung Heros

A few weeks ago I wrote a blog saying that developers learn new languages because they're cool and they help with coding homework like professional experts thanks to their variety. I still stand by this assertion because the thing about Java 8 is it's really cool. Whilst the undoubted star of the show is the addition of Lambdas and the promotion of functions to first class variables, my current favourite is default methods. This is because they're such a neat way of adding new functionality to existing interfaces without breaking old code.

The implementation is simple: take an interface, add a concrete method and attach the keyword default as a modifier. The result is that suddenly all existing implementations of your interface can use this code. In this first, simple example, I’ve added default method that returns the version number of an interface¹.

public interface Version {

  /**
   * Normal method - any old interface method:
   *
   * @return Return the implementing class's version
   */
  public String version();

  /**
   * Default method example.
   *
   * @return Return the version of this interface
   */
  default String interfaceVersion() {
    return "1.0";
  }

}

You can then call this method on any implementing class.

The Simple Story Paradox

I’ve recently been following the #isTDDDead debate between Kent Beck (@kentbeck), David Heinemeier Hansson (@dhh), and Martin Fowler (@martinfowler) with some interest. I think that it’s particularly beneficial that ideas, which are often taken for granted, can be challenged in a constructive manner. That way you can figure out if they stand up to scrutiny or fall down flat on their faces.

The discussion began with @dhh making the following points on TDD and test technique, which I hope I’ve got right. Firstly, the strict definition of TDD includes the following:

1. TTD is used to drive unit tests
2. You can’t have collaborators
3. You can’t touch the database
4. You can’t touch the File system
5. Fast Unit Tests, complete in the blink of an eye.

He went on to say that you therefore drive your system’s architecture from the use of mocks and in that way the architecture suffers damage from the drive to isolate and mock everything, whilst the mandatory enforcement of the 'red, green, refactor’ cycle is too prescriptive. He also stated that a lot of people mistake that you can’t have confidence in your code and you can’t deliver incremental functionality with tests unless you go through this mandated, well paved road of TDD.

Is it Imperative that you learn Functional Programming with Java 8?

I've recently been taking look at Java 8 and have got hold of "Java 8 In Action" published by Manning. The first thing that struck me is how one of Java 8's unique sales propositions is functional programming; functions are now first class variables, you can pass them around your code as you would an int or a String. This is a big change.

It seems that functional languages have become more popular in recent years and there are no end of them to choose from. Modern function programming language examples include Clojure, JavaScript, Scala, and even Erlang, invented in the late 1980s, has made a come back.

So, why is there this change in direction? You could probably come up with several reasons, but we’ll begin with the premise that industry best practise changes over time and even the most popular languages will one day fall out of favour. I imagine that if you're young enough there will be a day when you'll look back and say "remember when we used to use Java”? Before looking at why there is this change, let’s reflect on how we got here by stepping back to the 1980s...

Tracking Exceptions - Part 6 - Building an Executable Jar

If you’ve read the previous five blogs in this series, you’ll know that I’ve been building a Spring application that runs periodically to check a whole bunch of error logs for exceptions and then email you the results.

Having written the code and the tests, and being fairly certain it’ll work the next and final step is to package the whole thing up and deploy it to a production machine. The actual deployment and packaging methods will depend upon your own organisation's processes and procedures. In this example, however, I’m going to choose the simplest way possible to create and deploy an executable JAR file. The first step was completed several weeks ago, and that’s defining our output as a JAR file in the Maven POM file, which, as you’ll probably already know, is done using the packaging element:

Tracking Exceptions - Part 5 - Scheduling With Spring

It seems that I'm finally getting close to the end of this series of blogs on Error Tracking using Spring and for those who haven’t read any blogs in the series I’m writing a simple, but almost industrial strength, Spring application that scans for exceptions in log files and then generates a report. From the first blog in the series, these were my initial requirements:

1. Search a given directory and its sub-directories (possibly) looking for files of a particular type.
2. If a file is found then check its date: does it need to be searched for errors?
3. If the file is young enough to be checked then validate it, looking for exceptions.
4. If it contains exceptions, are they the ones we’re looking for or have they been excluded?
5. If it contains the kind of exceptions we’re after, then add the details to a report.
6. When all the files have been checked, format the report ready for publishing.
7. Publish the report using email or some other technique.
8. The whole thing will run at a given time every day

This blog takes a look at meeting requirement number 8: "The whole thing will run at a given time every day" and this means implementing some kind of scheduling.

Tracking Exceptions - Part 4 - Spring's Mail Sender

If you've read any of the previous blogs in this series, you may remember that I'm developing a small but almost industrial strength application that searches log files for exceptions. You may also remember that I now have a class that can contain a whole bunch of results that will need sending to any one whose interested. This will be done by implementing my simple Publisher interface shown below.

public interface Publisher {

  public <T> boolean publish(T report);
}

If you remember, the requirement was:

7 . Publish the report using email or some other technique.

In this blog I’m dealing with the concrete part of the requirement: sending a report by email.

Error Tracking Reports - Part 3 - Strategy and Package Private

This is the third blog in a series that's loosely looking at tracking application errors. In this series I’m writing a lightweight, but industrial strength, application that periodically scans application log files, looking for errors and, if any are found, generates and publishes a report.

If you’ve read the first blog in the series you may remember that I initially said that I needed a Report class and that “if you look at the code, you won’t find a class named Report, it was renamed Results and refactored to create a Formatter interface, the TextFormatter and HtmlFormatter classes together with the Publisher interface and EmailPublisher class”. This blog covers the design process, highlighting the reasoning behind the refactoring and how I arrived at the final implementation.

If you read on, you may think that the design logic given below is somewhat contrived. That’s because it is. The actual process of getting from the Report class to the Results class, the Formatter and Publisher interfaces together with their implementations probably only took a few seconds to dream up; however, writing it all down took some time. The design story goes like this...

Tracking Exceptions With Spring - Part 2 - Delegate Pattern

In my last blog, I started to talk about the need to figure out whether or not your application is misbehaving in it's production environment. I said that one method of monitoring your application is by checking its log files for exceptions and taking appropriate action if one is found. Obviously, log files can take up hundreds of megabytes of disk space and it's impractical and really boring to monitor them by hand.

I also said that there were several ways of automatically monitoring log files and proposed a Spring based utility that combs log files daily and sends you an email if / when it finds any exceptions.

I only got as far as describing the first class: the FileLocator, which will search a directory and it's sub-directories for log files. When it finds one, it passes it to the FileValidator.

Tracking Application Exceptions With Spring

A few weeks ago a colleague asked me to spend a week doing a support role as he needed cover whilst he took a well earned holiday and he couldn't find anyone else. As I'd just completed a particularly complex coding project and was feeling a little burnt out, I said 'yes'; after all the change would do me good.

Part of the job consisted of monitoring a collection of fairly critical backed processes, to see how well they were performing and whether or not they were going wrong.

We developers spend a lot of time and energy adding logging to our application in order to prove that it's working okay and to figure out what went wrong when an exception occurs. These log files are often used to tell us how well, or badly, our application is performing on a daily basis.

I'm ignoring other techniques such as adding probes to your application by whatever method you choose, such as HTTP or JMX. These provide immediate information on your application rather than the second level monitoring under discussion here.

There are at least three ways of monitoring log files: