Thursday, 22 March 2012

Fastest Way to Delete a Directory In Windows

I had a load of large directories (several GBs) which I needed to delete so that I could meet the minimum free space requirement for Windows to run the defragmentation tool.  Unfortunately, Windows Explorer is unusably slow for this as it first scans the whole directory so that it can show the estimate and then copies everything into the recycle bin or not if the directory is too big.

Below is some batch script to delete a directory very fast.  The code is on stack overflow here where the commenter Hugo bench marked it at 3 times faster than rmdir which itself is a hell of a lot faster than deletion via Windows Explorer.

bestrmdir.bat

rem to use, drop in your c:/windows/system32 directory for this to be usable anywhere
rem in then command line type 'bestrmdir MyDirectory' to delete MyDirectory
del /f/s/q %1 > nul 
rmdir /s/q %1

Wednesday, 29 February 2012

Typed Integers

I really like the idea of typed integers. For example, if you a number representing the number of cats and a number representing a number of dogs it is possible to add these together.  In a typed integer world it would not be possible and throw an error upon compilation.  I think this would be a big improvement for API safety and also a method of documentation.  There is nothing worse than a method with a structure like #foo(int, int) which is difficult to understand without reading or documentation every time.

In general use this would be suicide in a managed language where the overhead of an object for every int could mean a huge jump in memory usage and GC wouldn't be worth the improvements.  The actual implementation in Java would also be extremely ugly, for example:

class EventID {
  private final int id;
  public EventID(int anID) {
    id = anID;
  }
}

The class doesn't even contain basic methods like a way to get the ID, compare or hash it which with an int you get for free and it is still a fair wedge of code.  Lombok's @Data annotation can really improve classes like this and make the language feel more declarative.

I have found the best language to implement this is c++, the following is my proof of concept implementation:

template
class TypedInt
{
public:
  const int value;

  TypedInt(int v) : value(v) {};

  TypedInt operator + (TypedInt num)
  {
    TypedInt result(value + num.value);

    return result;
  }

  TypedInt  operator = (const int other)
  {
    TypedInt result(other);

    return result;
  }
};

This allows the following usage:

struct eventid {};

typedef TypedInt EventId;
  
EventId i = 2, j = 3;

EventId result = i + j;

Overall this feels natural to use.  If I was actually using class then the other operators such as == could be implemented without problems. 

One of the benefits of c++ is that an object wrapping an int does not take more memory than an int would, during compilation this abstraction is apparently stripped away.

Sunday, 26 February 2012

Compatible Images

A couple of weeks ago I was tasked with improving the performance on a legacy java swing application that was really crawling.  It would repaint the whole screen on any event, which it could receive a lot of, and painting the whole screen was really slow.  By using compatible images instead of the default kind of image read by ImageIO, the painting code was sped up by a factor of 70 and the event frequency was a non-issue.  The whole change was about 10 lines of code, much less than that to make the software use the graphics clip.

If you are having an issue with graphics performance make sure you try compatible images before trying anything else since it is so easy to introduce.

Before deploying to site I was worried that the speed up I was seeing was in some way down to my dev machine working well with compatible images so I wrote the tool below to test if the improvement was the same which it was.  Some notes:
  1. The tool requires an image.  When I attempted to create an in-memory image there was no difference in run times.
  2. Results are printed on the command line so remember to use java.exe and not javaw.exe
  3. I went to some effort so that this program was a single class to make it easy for the support guys to run.  I don't usually like to implement Runnable on a class that isn't just a Runnable.

How Much Architecture is Enough?

In the past I have often wondered if I have provided enough architecture for the software team to work to.  Conversely I always like to leave enough room to maneuver for the guys to do design for their own parts of the software, I would really hate it if I was working on a project where everything was defined and all I needed to do was "code in the blanks".

The idealist in me wants to provide just enough architecture to start work at all, and emergency design will do the rest.  I have found this is not how great software is made.  When everyone is left somewhat to their own devices, the code starts to lose coherence.  Everyone will code their own mini framework that will not interact well with other stories or allow extension for all requirements.  This is natural as everyone might not be aware of all requirements for the project.

The answer to this is pretty simple in practice, whenever two or more stories meet the following criteria you need some architecture:

1. Other code interacts with the product of a story.  
For example some kind of remote or local service or data.  In my current work we do a lot of inter-process communication.  This is really a technical detail, web services or in-process framework meets the same criteria.  Whatever it is, it needs some documented architecture.  The documentation part here is important, it should be simple to find look-up the exposed interfaces with arguments including valid values, errors etc.  This rule tends to reduce errors and confusion (more errors) occurring from not knowing about or not understanding .

2. Two or more stories are similar

For example, two kinds of message or input that could be handled in the same way or are similar enough to be categorised together.  Polymorphism and/or inversion of control can be used to have a central mechanism handle these in a reusable way.  This rule tends to reduce the overall amount of code and improve code quality. 

These two scenarios are sum up pretty much of every time where I had wished I had provided some architecture before work commenced

Monday, 12 December 2011

Some of My Coding Habits

This is a brief description of my coding habits including indentation, new lines and other things that I don't usually see although I think it makes code clearer.

Variable declaration and assignment on separate lines
Example:

JLabel nameLabel;

nameLabel = new JLabel("Name:");
nameLabel.setBackground(Color.RED);

Although I didn't take up SmallTalk seriously I did come away with, among other things a new coding habit.  SmallTalk variables are always declared in pipes i.e. | myVar | before use.  In Java I use this, especially when the object needs one or more method calls after it is created.  It is almost like a paragraph header and allows the code on the left hand side to match up which I find quite easy to read.

Static imports

No need for an example here, I just really like static imports... in moderation.  They are particularly effective for enums where the enum name might be repeated over and over again.  It is also quite safe to use enums in this way because type safety will not allow you to do anything silly such as EnumA.RED == EnumB.RED without giving a compilation error.

Static imports are quite bad for importing primitive constants, it is much easier to make a mistake without the context of the class name from where it came.  For example, two different integers might mean very different things.  A number of cats and a number of dogs which should not be added together. 

It is quite rare for me to write static methods so this isn't usually an issue.

Returning new
Example:

public String findDayName(int dayIndex)
{
  assert dayIndex >= 1 && dayIndex <= 7;

  switch(dayIndex)
  {
    case 1: 
      return "monday";
    case 2: 
      return "tuesday";
    default: 
      return null;
  }

  // and when using an if statement
  if(dayIndex == 1)
    return "monday";
  else if(dayIndex == 2)
    return "tuesday";
  else
    return null;
}

When using a reasonable size switch or if statement I typically bring this out into a separate method with no variables other than the data needed to perform the switch.  Even this is not necessary if the data is a class field. There is no variable that gets assigned to so no need to worry about a name, or maintain the name and the method name make sense together.  If statements also do not have brackets to cut down on needless lines and white space which in this case would just make the code more bulky and difficult to read.

The if statement is reminiscent of Erlang guarded methods.

Saturday, 15 October 2011

Resolving Bugs

There are at least three roles in a bug report.  The first two are the bug reporter or owner of the bug who is equivalent to the Customer or Product Owner and the Software Engineer responsible for the bug.  An Architect, Technical Lead or Project Manager may exist who has more direct access to the customer, this is called QA in Bugzilla.  In certain cases the Engineer may need to escalate issues if they cannot resolve it themselves.  This can happen all the time, the Customer might raise a bug stating that functionality is missing when it is not in the requirements.  If this is not dealt with in a way that includes all stake holders, it could cause issues immediately or later on in the project at demo time.


Below is a table of resolutions and the circumstances in which they can be applied and by who.  The only possible option for the software engineer is to fix the bug or agree another resolution with the customer, or team lead.  This means that the bug will always be fixed or dealt with in a final way where the specification will be updated to reflect the new behaviour (or new understanding of behaviour) or at least a resolution agreed which should be traceable in the bug comments.  If the bug is not fixed and not agreed then it is bound to come back in the future starting with the line “I reported this months ago and it is still NOT FIXED”!

Fixed
Only the Software Engineer can set.
Invalid
Only the Customer can set.
Won’t Fix
Architect, Technical Lead or Project Manager can set based on agreement with customer.  Should be extremely rare.
Later
Never set
Remind
Never set
Duplicate
Software Engineer can set in the interest of efficiency.  Be careful that this is truly a duplicate and the customer is in fact not describing some other behaviour.
Works For Me
Never.  Negotiate with the Customer for them to set the bug to Invalid instead.

Sunday, 25 September 2011

Detangling Dependencies Between Guice Injected Services

It is very easy to allow services to depend on each other, even when they are in different modules.  In fact Guice explicitly supports this behaviour with the AbstractModule#requiredBindings method.  I think this is very bad and in my experience has led to some complex interactions and strict requirements on order of creation.  Even worse, in some cases you may require a cyclic relationship to fulfill what you want to do which means you can't fully initialise the services via constructors.

Instead of a clever technical solution, I believe it is the software design that is incorrect.  The issue can be resolved using SOLID principles to identify and rectify the issue.

The services require the dependencies because they are trying to do too much, this is violating the Single Responsibility Principle (SRP).  I often think of SRP as a DON'T whereas the Interface Segregation Principle (ISP) is a DO: to fix an SRP issue apply ISP and move that behaviour out into new classes.

This still hasn't fixed the issue yet because those dependencies still have to be wired up in the modules, except you don't.  The new classes with dependencies can be instantiated via Guice when required with injected dependencies, the code to wire them up in the modules can be removed altogether.

In this way, layers of objects are being created.  The bottom layer of services are injected into the next layer of composite services which are then injected into the application.  This is the Open Closed Principle (OCP) where classes should be open for extension but closed for modification.  In other words, prefer to building on top of existing classes instead of modifying them.

I do suggest that all layers can talk to each other unless the software is huge enough to justify such abstraction.  Also, be sceptical of composite services which simply provide a layer over another service and perhaps wrap exceptions or even provide a something useful.  In this case a new API has been created to replace a more universal one.  Ask if the new API is actually better than what it is truly wrapping and it is worth the new layer being imposed.