Volcano Mombachu (In the last picture) Is apparently quite active and always smoking and spitting.

Posted via email from riaancornelius’s posterous

If you keep that in mind, it is quite simple to come up with regular expressions to search for commented out code.

For single line comments:
(?s://[^/]+;)

and for multiple line comments:
(?s:/\*[^/]+;)

These regular expressions won’t necessarily find every line of commented out code, but they should find every block.

I’m working on a project where no logging was done, but a lot of information is printed out to System.out and System.err (Most exceptions print out their stack traces as well).

While this is not ideal, it is much better than nothing, and this is why: You can redirect the standard output streams to any java.io.OutputStream.

I found the following code in “Covert Java – Techniques For Decompiling, Patching, And Reverse Engineering” by Alex Kalinovsky. I would suggest that anybody serious about Java read this book.

import java.io.IOException;
import java.io.PrintStream;
import java.util.logging.Logger;

public class LogOutputStream extends java.io.OutputStream {

    static Logger logger = Logger.getLogger(LogOutputStream.class.getName());
    private char lineSeparatorEnd = '\n';
    private String lineSeparator = System.getProperty("line.separator");
    private StringBuffer buffer = new StringBuffer();

    public void write(int b) throws IOException {
        char ch = (char) b;
        this.buffer.append(ch);
        if (ch == this.lineSeparatorEnd) {
            // Check on a char by char basis for speed
            String s = buffer.toString();
            if (s.indexOf(lineSeparator) != -1) {
                // The whole separator string is written
                logger.info(s.substring(0, s.length() - lineSeparator.length()));
                buffer.setLength(0);
            }
        }
    }

    public static void main(String[] args) {
        System.out.println("Installing the interceptor...");
        PrintStream out = new PrintStream(new LogOutputStream(), true);
        System.setOut(out);
        System.out.println("Hello, world");
        System.out.println("Done");
    }
}

The code is fairly standard. You extend OutputStream and implement the write(int) method. You define a static Logger to log the messages and then you can see that the System.out messages are logged as INFO-level messages by the Logger (Line 20).

The rest of the code in the write method is all just to detect line separators. Essentially it is somewhat more complicated than it could be for performance reasons.

Because the line separator is different on Unix and Windows system, the only way to get cross-platform code is to use the “line.separator” System property. But this property is a string, and substring searches are slower than character comparisons (Especially since you are already looping through characters in any case).

So, the lineSeparatorEnd char is used to detect probable line-separators and then a substring search is used (with the actual line-separator) to confirm it and to print out the contents of the buffer.

The main method shows how you would redirect the System.out stream (Line 29). In my project, I also do a different OutputStream for System.err that logs errors.

You can see in this example, I use the built in Logger, but this is much more useful if you use Log4j and configure a file appender to log everything to file.

While this is not ideal, if you have to support existing code where debugging information or exception stack traces are printed out to the console, this is a good way to get some logging into your application without much effort.

This is the view from my patio today. The house hidden behind the trees behind the horses is pretty much our only neighbour that we can see. The other 3 sides has fields and trees to look at. The second is the view of my patio. Butterflies, dragonflies and frogs love the ground cover with all it’s little yellow flowers.

Posted via email from riaancornelius’s posterous

It can be difficult to know when you should rewrite and when you should just leave it alone.

There are some very clearcut cases at the extremes. If it works and you don’t need to change anything, leave it alone, even if the code is terrible. On the other hand, if you are going to be making a lot of changes, it is likely to be faster to throw out the code that you will be rewriting in increments in any case.

Which brings us to the in-between cases. Basically, my measure for whether to throw out the code is to plan properly and try to decide upfront how much of the code I’m likely to rewrite in the process of making the changes. If I’m likely to end up rewriting a big percentage of the code, it is usually faster (and leads to better design), to just start with a blank screen.

In aproject I was recently involved with, a Java Enterprise system was outsourced to a developer. It turns out that he was completely incompetent. I only got involved 3 months into the project at which stage we replaced this developer and outsourced the development to a small company.

I argued that we should scrap the code and start over, but I was overruled (Because we had invested too much in the code already) and we continued with that code. The project should have taken 3 months to complete. It is now just over a year later and we are finally looking like we have solved the final performance issues. I was only involved in a desktop application that exchanges data with the online application, but I did get to see the early code for the web application, and it was not pretty.

Obviously, scrapping bad code costs money (The initial cost of development, plus the cost of redeveloping), but if the design is bad enough, not scrapping the code can cost a lot more.

On that note, I’ve just scrapped 50 000 lines of terrible code for some functionality that we want to change and extend, and the new design is so much more maintainable and flexible. If you can, throwingout really bad code can help a lot, but as with all things too much of a good thing can be really bad.

Good code doesn't just happen – You have to make it happen. 

I'm forced to think about this, because I'm way behind deadline on some development because of the bad code in the rest of the system. This is after I tossed out about 50 000 lines of the worst code. I'm still figuring some parts out, so this will be a series of posts on the relevant subjects as they come up. 

I will also write a series on how to write good code at the same time as the ultimate goal is to replace the bad code with good code and make sure that this doesn't happen again. 

The system I'm working on is a Java application with over 600 000 lines of code and practically no unit tests, so the focus will be on how to make changes that will keep increasing the quality of the code base without making radical changes.  While a lot of the code is not great, the system is stable and does work with very few known bugs. The main problem is just adding new features.

To start with, We'll look at what makes bad code and how it happens in this article. Then in future posts, I'll write about:

• When to throw away code.
• Refactoring existing code.
• Writing unit tests and doing test driven development.
• Using design patterns.

I'll link these once I write them and also add any other topics I think of in here.

What is bad code?

There are a lot of different measures for what makes good and bad code. For me, bad code is code that is unreadable, unmaintainable and untestable. 

To make code that is maintainable and testable, your code should be well encapsulated and loosely coupled. 

Encapsulation means that all the related code for a feature is together (For example, in the same package). Encapsulation is mostly important because it makes your code easier to understand.

Coupling is when code depends on other code. Loose coupling means that related code only depends on the obvious code in the same class or same package. Esentially, if you can compile a single class without compiling anything else, it is loosely coupled. If you need to compile another class, which compiles another class, which has to compile another class, that code is set to be tightly coupled. Tight coupling is bad because it means that a change to a class might affect a completely different class somewhere else in a seemingly unrelated part of the system. This makes it difficult to make any changes in the system. 

Tight coupling also makes it difficult to write unit tests, since each method might depend on methods in a completely different part of the system.

Even if the code works fine, as programmers, we spend a lot more time reading code than writing code. As such, it makes sense that difficult to read code is bad. The biggest mistake is to over complicate things. Don't use more dificult code because it might perform better. Rather use simple code and if there are performance problems, just tune the worst bottlenecks and make sure that you put comments explaining why the more complicated code was used.

On the topic of comments, make sure that comments tell you why something was done, not what was done. The code should tell you what was done.

So how does bad code happen?

The worst time, where code usually goes bad, is after the initial version of your software has been released and you start getting requests for new features. Ad to that tight deadlines because of bug fixing that you didn't anticipate, and most programmers will cut where they can.

There really are only 4 factors that you can realistically change when you are under pressure:

• Move the deadline.
• Cut features.
• Add Resources.
• Compromise on quality.

Usually, management will not cut features or move the deadline, since they have already started marketing. Adding resources are unlikely to happen in any case, but even if it does, by the time people realise that they are in trouble, it is too late to add more people to a project.

This leaves the only option: Compromise on quality.

Most programmers hate doing this, and doesn't necessarily realise immediately that they are doing it, but that's what happens. 

“Yes, I know this design isn't great, but we have to ship, so I'll just make it work and we can clean it up later.” Sounds familiar? How many times do you go back and clean it up? 

That's called technical debt. And like any other debt, there's interest on it. The longer you leave it, the more it will cost to fix, until eventually you get to a point where everything is too broken to fix and the only solution is to rewrite from scratch. Of course, doing that just starts the process again and you eventually end up in the same position.

Esentially, the only way to keep code from going bad is to put in a conscious effort to leave the code in a better condition than you found it every time you work on it. Even if you only put some meaningful comments, rename a few variables to make more sense or just write a couple of unit tests.

Always look at the code after you worked on it and ask if you made it better or worse.

At the moment, I’m developing the processes for our team (I use team rather loosely since I’m the only member at the moment – I do at least 3 or 4 peoples work though, so  guess it still counts). We used to be a team of 4 people, and for a while, 3 of us stuck with the company while the 4th seat got taken by a new developer every 6 months or so. To make a long story short, everybody else left and I got to do all the work myself. Because we were in the middle of a project when the last guy left last year, we decided to finish that before employing more people.

Now we are finally at the point of employing new people and I find myself thinking about our processes and methodologies. We’ve always followed more agile processes, so we’re already well on our way there. Our main problem is that we don’t do enough planning upfront, so we tend to have lots of changing requirements towards the end of the project which leads to less than optimal code.

Any software development plan should minimally include the following items to some degree:

• Analysis – Basically gathering and refining requirements.
• Planning – Figure out what resources you will need and how much time it will take to build.
• Design – How are you going to put it together?
• Coding – Build it.
• Testing – Make sure it works.
• Deployment – It’s a bit pointless if you can’t get it to the end user.
• Documentation – Both for end users and the developers and technical support staff that need to maintain it.
• Review – Ensure that it stays maintainable and high quality.

Any successful development will do all of those. Not necessarily in that order (or even in separate steps), but it will always happen.

From our perspective, I’m thinking that we want to do most of the analysis, planning and design before we start (At the very least the broad concepts if not all the details).

For the actual development, we want to do the development in iterations (probably 3 week iterations with 1 or 2 shorter iterations at the start). Requirement changes should ideally be discussed at the start of iterations, and once development starts for an  iteration, requirements should be frozen (Unless something directly impacts what is being developed in the iteration). So, between iterations we will do more analysis, planning and design if refinements are required.

We want to do test driven development when we build it, so unit tests will be written as we build the system. This should lead to better designs and better maintainability. Unit tests are also to a large degree the best programmer documentation that you can do as it states very explicitly what the code is expected to do.

During the process, there will be short (less than 15 minutes) stand up meetings at the beginning of every day. The only things we want to know during these meetings are:

• What did you do yesterday
• What will you do today
• Do you have any problems you need help with

By doing this, we can make sure that we immediately know when there are issues and if the schedule is slipping.

We will also do code reviews of any new code regularly (probably every 2-3 days) based on how much new code was checked in.

Any technical documentation should be created as the code is written, and user documentation will be done at the end of the development when functional testing is happening.

This only leaves deployment which is something we already do fairly well, but it is a manual process. We need to plan how we will automate this process to get to the goal of one button deployment.

To that end, I’ve been working on getting all our project dependencies into a local repository and I’ve been setting up a Hudson build server to do daily automated builds.

We’ll see how this plan evolves, but this is basically the process I’ve decided to adopt (in very broad terms).

I see it time and time again. In small development houses, the general approach is to have an idea, rush headlong into development, rush to get something done, and then step back to see what they end up with. During this process, they realize that they missed some killer feature, so the put it in. But while they’re working on this feature they figure out that they missed another feature, so they start working on that at the same time. Because of this the software is never done, and no thorough testing can happen.

Eventually, 2 years down the line, they realize that instead of their 1 week email notifier project, they now have a full fledged email client and Microsoft is their competition. They also realize that because they didn’t do any planning, the architecture is so shaky that they’ll need another six months to fix it before they can release.

At this point, it is time for the “Software development plan template”. They know they have to plan, but have no idea how to do it, so just ask Google for a template. This unfortunately does not work. Most templates you find will apply to a company bigger than yours.

So what do you do?

The problem is that the plan needs to be adapted to your needs and for your resources. These are the main points you need to consider:

• What’s the scope of the project? How much time and resources can you afford to allocate for this?
• You need to plan and document the requirements. Decide upfront what features need to be in this release of the software and stick to it.
• Design the software based on the requirements. You need to document this in a design spec. See Joel’s functional spec information for a brilliant resource and example.
• Now you need to spec the development and decide on estimates.
• Review the estimates and see if you can finish the software on deadline. If not, you need to take out features, add more developers, or move the deadline.
• Do the development. Note that this is only one step in the process. If you’ve done the preceding steps properly, this will be as painless as is possible.
• Develop a test plan and do the testing. Unit tests should be written as you are developing the system.
• Once you are happy with the software, develop training materials for the end user.
• Develop any necessary user documentation. Help manual, installation guide, etc.
• Beta test. Identify beta testers and deploy to them. Get feedback and decide what actions are necessary. If the software needs to change, go through the above steps again.
• Plan maintenance and set up any necessary structures.
• Deploy the product.
• Review the product as well as the process. Document any lessons learned and adjust your software development plan as necessary so that you will do it even better the next time.

As you can see, there are a lot to consider. Most small businesses focus on the development, but never consider the supporting functions. Even if they do get it right and develop a useful product, without planning for deployment or maintenance, they can become a victim of their own success.

You can get a Microsoft Project software development plan template at this site if you want a starting point for creating your own template.

This guy was pretty much in my yard (You can see he is right up against the fence in the last 2 photos).

As far as I can tell it is the imaginatively named Green Iguana and grows up to 1.5m long. This one was probably about 70-80cm long.

A while back one was in my back yard where we have fencing to keep the dogs in. It got stuck in the fence trying to get away from the puppies (Who obviously wanted to play with it). Luckily it got away while we locked the dogs in the house.

I wasn’t looking forward to trying to get it out of the fence. I got the distinct feeling that it wouldn’t care for the help…

Posted via web from riaancornelius’s posterous

Facebook

First, Facebook really can’t be lumped into the same category as most other social media (from a marketing perspective) – It was designed to help you stay in touch with FRIENDS… The whole design makes it virtually impossible to use facebook profiles for marketing. Facebook pages is a different story, and facebook PPC ads are unbeatable for markets that are tightly linked to a certain demographic (Where else can you target your ads at women between the ages of 20 and 30 that will be getting married fairly soon?)

Twitter

One potential problem with Twitter (And in fact any social media) is that there is a very thin line between Twitter working for you and Twitter turning into the beast that eats all your time and turns you into a useless procrastinating mass. However, given the right tools and a definite goal, the returns could be fabulous.

Always have a goal

The main goals in my mind is this:

• Networking – Especially with people that would never talk to you if you approached them using any other media.
• Staying up to date with the latest news/gossip in your market
• Building a relationship with your market

I have found that Twitter will give you direct access to people who would never even have given your email a second glance (If they even read their own mail). This doesn’t only go for business, but also fun – Who here can have a chat with Neil Gaiman about any of his books? (Please tell me you know who he is..)

The general belief is that social services probably converts worse than PPC/Google traffic… In my experience this isn’t necessarily true. If you don’t have any kind of reputation and relationship with your market yet, then yes, it’s very true, but once you build that reputation, nothing will convert as well. The thing is that you have to keep it social,  you can’t jump in and start pitching. If you do, people will ignore you. Build a relationship first, and then start feeding in disguised promotions – Free content on your blog that requires email opt in for example.

Seth Godin mentioned that if you can create a tribe of  fans that really respect and like you, you have a sustainable business. Social media allows you to do this, but at a much lower startup cost and in a much smaller space of time than you could previously. Obviously this won’t work for every market… If your market doesn’t use twitter, there’s no point, but you have to go where your market is.

Do you know if your market is on twitter?