In WordPress 1.5, permalinks must end in a slash, otherwise the nextpage tag will not work.
In the Options/Permalinks screen of WordPress’s admin interface, I had my permalink format set to Continue reading “WordPress permalinks should be slashed” →
You can install several different versions of Microsoft Internet Explorer concurrently on Windows. Finally I could see how awful my site looked in IE5 — and the truth wasn’t pretty.
You can download standalone versions of Internet Explorer 3, 4, 5, 5.5 and 6 from the browser archive at evolt.org. Continue reading “Multiple Internet Explorer versions in Windows” →
In the year 2014, The New York Times has gone offline. The Fourth Estate’s fortunes have waned.
What happened to the news?
And what is EPIC?
EPIC 2014, a time-shifted transmission from the future, has the answers.
Functions that take collection parameters should take the generic parameter. E.g. don’t do this:
public void process(ArrayList list);
do this instead: Continue reading “Use generic collection interfaces as parameters” →
Here is a simple documentation strategy that emphasises minimal yet useful documentation for small to medium sized software projects. The goal is to ensure that writing the documentation is not too arduous, and that the documents are useful both during the project and after it is finished.
Traditionally, software development organisations deliver several documents, including Requirements, Functional Design and Technical Design. In this approach, each document is heavily dependent on the previous one. This means the documentation is often inconsistent. For example, if the FD needs to be revised, the TD may need updating too.
Part of this comes from the idea of forcing the customer to make all judgement calls. This can be slow. It’s better in many cases for the development team to make the call themselves, based on their understanding of customer requirements, and communicate this to the customer. The customer can then intervene if they really need to — and they won’t need to if the developers understand the actual requirements (as opposed to the documented requirements).
Continue reading “Simple documentation for software projects” →
When a TestCase runs, it should either succeed or fail: there should be no side effects. For example, Testcases should not write to the console or to a log file, or save anything to a database. There are two reasons for this. Continue reading “No side effects in test code” →
Structure your JUnit test suites to simplify unit testing — you can easily run all your tests with one command.
In every package directory, create a test suite called AllTests, containing all TestCases in that directory. For example: com.zikzak.widget.util.AllTests (This can be generated automatically by the Eclipse IDE.) Continue reading “Write useful JUnit test suites” →
This may seem obvious, but many JUnit tests are written that don’t really test anything useful.
Don’t write tests cases for code that’s too simple to fail on its own: that would be a waste of time. You’re supposed to write tests that test your application code, not the test framework or the compiler.
Import statements provide good documentation, but not if they contain wildcards. For example:
import com.zikzak.db.*;
import com.zikzak.util.*;
...code...
WidgetId = new WidgetId();
There’s no way to find out what package the WidgetId class belongs to without searching through the source tree. Continue reading “Don’t import wildcards from non-standard Java packages” →
Every development project should have an architect. This person determines the way the software is put together, and specifies policies and standards for design and coding. For example: