LAMP vs J2EE

The LAMP Stack is fairly easy to understand:

  • L is for Linux which is an Operating System a server is run on.
  • A is for Apache which is a Server that accepts and processes HTTP requests.
  • M is for MySQL which is a database used to store any data the web server will be CRUD-ing.
  • P is for PHP which is a scripting language used to produce web pages dynamically.

Anyone who has used the LAMP stack knows how easy it is to work with. For example, to change some part of the website you can open a text editor, change a PHP file and then save the file on the server. The next time a HTTP request is processed by the Apache server the new PHP change will be picked up.

In the J2EE world, things are a little different. A server stack using J2EE otherwise known as Java Enterprise Edition can also use Linux and MySQL. The major difference in the setup when compared to the LAMP stack is that Apache is replaced by a J2EE Implementation of the Servlet Specification commonly known as a “Web Container“. A Web Container then handles HTTP requests and routes them to an appropriate Servlet. A Servlet is a Java program that adheres to the Java Servlet interface and provides custom behaviour that allows dynamic content to be produced by the web server (as opposed to static content). Essentially the Java Servlet provides the same functionality as PHP would in the LAMP stack.

 

My First Refactor – Part 2

Continuing from my previous post, I’ve created a characterisation test for my Stock Analysis application. I captured the HTML output it produced and wrote a simple test which ensured that it always produced the same output. I used PHPUnit as the testing framework and used composer.js for dependency management.

Creating the Characterisation Test

Part of my initial code produced a raw HTML <table>  with the  results of the investment strategy. You can see what this looks like from this screenshot:

Dollar Cost Averager Screenshot
Dollar Cost Averager Screenshot

I restructured the code from being all in one index.php file to being in two files engine.php and index.php. In doing so I broke up the code into two partitions:

Application Partitioning
Application Partitioning

I moved all the logic which interacted with the database and which produced the <table> into the engine.php and kept the <form> and application title elements in the index.php. 

This is good design because now the Application partition can focus on processing the data and the Main partition can focus on displaying the data to the user and interacting with the user.  At a high level at least this application structure now follows the Single Responsibility Principle. Meaning that each part of the application should do one and only one thing. So now, my index.php looks like this:

I hope you’ll agree that this looks much simpler than before and easier to read. This restructuring also enables me to capture the output of the new calculateReturnOnInvestment()  method. This method returns the full HTML table element. So I can run it from the php interactive console and then copy and paste the output into a new file called golden_output.php. This file contains a method called getGoldenOutput() which returns a string with the “golden” HTML which I will use for comparison.

Finally I write the test. The test itself is a comparison of the golden output and what the calculateReturnOnInvestment() method currently produces. You can see the test here:


I run my test using PHPUnit’s CLI interface:

Running this test now  instantly informs me if I change the current behaviour of the code. So I can focus entirely on performing the refactor without worrying that I’ve broken anything.

Refactoring the Application Partition

So far, to get my application under test I’ve just copied the hard to read blob of code into a single function. I need to break this function up so that the code is more understandable and easy to change. I turned to Martin Fowler’s book ” Refactoring – Improving the Design of Existing Code” to learn about the different mechanisms for refactoring.

Martin Fowler - Refactoring Improving the Design of Existing Code
Refactoring Improving the Design of Existing Code

 

Mr. Fowler provides a catalogue of refactoring techniques which I’ve tried to employ during my refactoring efforts. In this section, I highlight examples of how I used these techniques. To start, lets have a look at the calculateReturnOnInvestment() function:

The first thing you might notice about this code is that it’s hard to follow. So how to improve this code? As I mentioned in a previous blog post, Robert C. Martin suggests that “classes hide in long functions”. You can see that the function has lots of temporary variables and various blocks of logic all using those variables. This sounds like those blocks could be methods for the class and the temporary variables could be members. So in this case changing this function into a class sounds like an ideal first step.

Refactoring Technique: Extract Class

To do this, I create a new class called ReturnOnInvestmentTablePrinter and move the logic into it. While it might seem that I’m just bloating the system with more code,  creating this class now enables me to employ more refactoring techniques. I’m now able to split out this method into different code blocks.

Using this technique, I split up the code into header, rows and footer generation methods. Now the generateReturnOnInvestmentTable() method is bit easier to read:

 

The getTableRowsHTML() method is still pretty long and complicated. There are lots of different code blocks and temporary variables within it. It looks like I should perform another Extract Class. This would separate the table printing code from the strategy simulation code. I create a new class called DollarCostAverageStrategy with a getInvestmentResults() method and move the code from getTableRowsHTML() into it.

DollarCostAverageStrategy::getInvestmentResults() will return an array with the the $monthly_data which the table printer class can print neatly into a <table> element. Now the getTableRowsHTML() method looks like this:

Refactoring Technique: Remove Temps

My current goal is to split up the big getInvestmentResults()  method into smaller, more easily understood methods. However there are lots of temporary variables which are needed by all the different code blocks in this method. This is preventing me from breaking this long hard-to-understand method up. To get around this I need to remove these temporary variables. I have a number of options – I can promote a variables to be a member of the class so that it will be accessible from all methods. Alternatively I can replace a temporary variable with a query method and finally I can inline a temporary variable where it is used into the code.

I usually take one temporary variable at a time and perform the appropriate technique. Once complete, the code now looks like this:

Notice how the readability of the code has improved, especially in the: getInvestmentResults(), processStockPriceData() and calculateInvestmentResults() methods.

Dependency Injection

You may have noticed that I now pass the stock price data array into the Strategy and pass the Strategy object into the Table Printer. PHP isn’t a strongly typed language so it might not be fully clear that I’m trying to ensure that the Table Printer doesn’t rely on the Dollar Cost Averaging Strategy, instead it relies on an object which can getInvestmentResults(). The table printer shouldn’t know how the investment results are generated – it just knows that it will be passed an object from which it can getInvestmentResults().

There is still some coupling between the table printer and the strategy – the printer still knows about the table headers and about all the type of results available in the $monthly_data array. This can be improved later but at least we’re moving towards a loosely coupled design.

Changing the Behaviour

Up until now all I’ve cared about is improving the design. The Characterisation Test helped me do this. Now that I want to change the implementation to do something different. I can’t use a catch-all test anymore because this will break as soon as I change how anything behaves.

To do this, I need to write some more finely grained tests so I can ensure that my existing behaviour will continue to work while I add more functionality.

 

 

 

My First Refactor

Over the last Christmas I was thinking about investing so I developed a small tool which I was using to analyse stock market data. I was interested in checking what the rate of return on various stocks actually was if you use the Dollar Cost Averaging method of investment.

Google Finance - Download to Spreadsheet
Google Finance – Download to Spreadsheet

I retrieved the data from Google Finance – you can download daily stock prices for any stock you’d like.  I then imported that data into a MySQL database so I could write simple queries for the data from php. Finally I wrote a single little php script that took the value in Euros which you wanted to invest per month and calculated how much your money would grow (or decline) in value over the time you chose.

For the moment, both the stock you invest in and historic period over which you invest in are hard-coded in the php code. These could be both made into fields for the users of the tool to change later.

However, as I made progress the PHP was growing larger and longer without much redesign. So I thought it was perfect piece of code to practise refactoring on! The code as it is today is pasted below. As you can see there is no clear structure to the code, just variables, constants and a loop that echos out the response. There are no tests so I have to re-load the page and examine it manually every time  I make a change to make sure I haven’t broken it.

Clearly I need to clean this code up! The first step will be to write a test around it – I’m going to try writing a characterisation test for this. Then I can begin refactoring. Once I’m happy with the refactor I can go back and refactor my tests so they aren’t so fragile and tied to the response output.

Clean Code

Why is Clean Code important?

Code which is not well written is hard to read and understand. It’s a mess. Working with a mess is hard and prevents programmers from making changes easily. If not tidied up it will eventually deteriorate into unsupportable goop and you can’t sell goop. This is why Clean Code is important.

Clean Code by Robert C. Martin

Robert C. Martin tries to answer some questions with his book Clean Code. Why do software projects become harder and harder to change and modify? Why does our productivity drop as the project goes from release to release? Robert explains that it happens because programmers write bad code. There is no one else to blame but the ourselves. If we write a mess we can’t continue to go fast like we were able to at the start. By reading his book, I hope to learn how to write clean code which in turn should allow me to be more professional when I write code.

What is Clean Code?

Michael Feathers

“Clean code is code that looks like it was written by somebody who cares.”

– Michael Feathers

Ward Cunningham

“You know you are reading clean code when each routine that you read is pretty much what you expected.”
– Ward Cunningham

Some Practical Refactoring Tips

“Classes hide in long functions.”

Robert means that when you look at a long function which uses lots of variables in various different (functional) ways then you’re probably looking at a piece of code which should be a class. The suggested approach is to take that code and move it into its own class before further refactorings. The original function still exists but instead it just creates an instance of the new class and calls “invoke()”. The new invoke() method simply contains the moved code block. This is part of the refactoring technique – the invoke() method can be renamed later once the purpose of the class is well-defined to something which will be clear to any reader of the code. So after this step, you have a block of code in the invoke() method of a new class. The next step in the refactor is to move the variables used in this function out and make them class members. This can be done one variable at a time. At the same time, the large invoke() method can be broken up into methods which do one thing (next bullet point). I think this sounds like a great tip. I’ve often wondered where to begin when refactoring code. At work I have a class which is several thousand lines long and has lots of really long methods. It’s calling been calling out to be refactored for some time! I intend to use this practical piece of advice on that class.

“Lots and lots of little well-named functions will save the team lots of time in the long run.”

Well-named functions act as littles sign-posts within your code and make your code much more navigable to other developers. Its rare that you work on a project on your own – and even if you do those well-named functions will guide your future self through the code when you come back to it and you inevitably will.

“Functions should only do one thing”

However how do you know when a function does one thing? He explains that you should “extract until you drop”. This means that if you can extract functionality from a function you should. Otherwise that function is by definition doing more than one thing.

Show me an example!

I’ve watched him refactor long functions in a number of screencasts from his cleancoders.com series of videos. He rewrites code which has lots of indentation into short functions with well written names. He uses the IntelliJ IDE’s refactoring features heavily in his screencasts. These are built specifically to automate moving blocks of code around in useful ways, such as extracting a block of code from one function into a new function, or even a new class entirely if needed. I’m interested to find out if IntelliJ can be used in that way for C++, perhaps the Visual Studio plugin I use at work Visual Assist can be used in this way. However the key is knowing the techniques of refactoring.

He declares that the functions should be limited to 4 and at most 5 lines long. This he says helps to increase the readability of the code because you can’t fit heavily indented code into 4 lines of code!

At the end of the screencasts the code reads a lot better, by this I mean that there is minimal indenting, usually there is no need for curly braces around the contents of an if-block or a for loop. Switch statements are removed and replaced with polymorphic classes using the Template pattern.

Before refactoring code, Robert always has a set of automated regression tests. Its well known why he does this – to ensure the refactor he is about to perform doesn’t break the functionality of the existing code! I found one example particularity interesting. He was refactoring a single function which calculated  prime numbers and outputted these numbers in a neatly formatted output. There were no existing unit tests for this code. So his approach was to run the function and capture a “golden” output for a set of inputs. He then wrote a test which called the function and checked that it produced this golden output. Another name for this test is a “Characterisation Test“. If it did then the test passed. It’s a novel approach to developing a suite of tests on-the-fly for a given piece of code you wish to refactor.

However these auto generated tests are rigid and fragile. Sure they tests the code, and will catch when you break something – but the tests were tied to how the data was outputted and formatted. In other words, if you wanted to change the formatting of the output your tests would break. In my view that means that once Robert was happy with the refactor of the Prime Number generator code he should go back and refactor his tests to make them clean also!

Startups – from an Investor’s Point of View

The lads and I went to the third floor of McSwiggans pub to the second Startup Galway event which consisted of the founder of boards.ie John Breslin interviewing Dermot Berkery in a fireside chat style of interview. Dermot is a partner at Delta investments which focuses on startups with potential for lots of growth and thus a big return-on-investment. Dermot was quite candid in his answers. Some of the interesting points raised were:

  • About 300-400 startups come looking for seed money but only about 10-12 get picked.
  • Usual seed money requested is about €500k – which apparently isn’t very much if you have to keep a team of people going, go through legal contracts / patenting and developing a product
  • The average startup founder they invest in is about 35-40
  • The usual initial pitch is a slide deck of about 15 slides instead of a business plan.
  • He made out that the share the investors would look for would be between 10-25% depending on the business if they’re interested.
  • If they are really interested, it can take about 4-5 weeks for them to do a full background check on the founders and then another 4-5 weeks to get through the legal arrangements. This all has to happen before the money is transferred.
  • Usually the relationship between the investors and founders is just regular update meetings (weekly / monthly) depending on the strength of the business and the founders. As the business progresses more investment may be sought at which point the investors may help look for more investment and help sell the business.
  • Unsurprisingly, Ireland is a more difficult place to grow a business to significant proportions when compared with the US. So usually, the founders in Ireland need to work a lot harder to expand their businesses because they have to expand to new countries which adds overheads and complexities.
  • If the founder is currently working and is seeking investment so they can leave their current employment and dedicate their full time to this venture – the salary would usually be less than the average working salary because they are getting usually a 75% or greater stake in a company in exchange for investment. There needs to be an incentive to work at growing the company.
  • Another interesting point brought up by a member of the audience who was from Enterprise Ireland was that both Galway and Dublin have startup hubs or incubators. Galway has New Frontiers.

I was sitting next to a guy, who’s I’ll call Bill. For the last 4 years Bill has been developing a product. He has 4/5 partners so far, a prototype and is in the finally stages of developing the product before selling it. However, he has put €80k of his own money into it and hasn’t sold one product yet. It really seems to me that he’s setting himself up for serious failure if this business doesn’t work out.

Leafy Justice – GameCraft II

I attended Game Craft II this weekend. GameCraft is a 12-hour game-building competition and it was mighty craic! This time it was hosted by Engine Yard who have a kick-ass office in Dublin. We coded from 9 to 9, then the judges came around to try our games while we sipped on a few cold ones from the office beer-fridge.

I’ve uploaded a copy of the game we completed in the 12-hours. Its written in HTML5 using a neat game engine called melon.js. Click the screen-grab to play!

Leafy Justice - Title Screen

 

Game credits:

Artist Kevin O’Flaherty
Sound Designer Rory Brady
Developers Matthew O’Flynn (me)
Conor Fennell
Brendan Sheehy
Paul O’Flaherty
Simon Wielens