Craig's development blog

The development world according to Craig. A bit of this and that from all over.

Wednesday, November 17, 2004

15 Commandments to Curb Bad Programmer Habits

I hijacked this from here and modified it.



  1. Thou shalt not break the unit tests or system functionality (by checking in half done crap code to source control).

  2. Thou shalt really understand the requirements driving your work (not make them up or not bother to read them and/or not ask questions when necessary).

  3. Thou shalt deliver what the customer needs (not that which is easy to implement).

  4. Thou shalt estimate work effort accurately (and deliver within agreed estimates).

  5. Thou shalt understand the implications of thy work with respect to others on the team.

  6. Thou shalt not just comment out code because it causes the test to fail (without understanding why it was there in the first place).

  7. Thou shalt understand the implications of thy work with respect to other areas of the system as a whole.

  8. Thou shalt follow the business priorities (not just do what you think is interesting).

  9. Thou shalt deliver stuff that actually works - including the user interface that can't be unit tested (i.e. actually try it out rather than hoping for the best - test the UI - don't just leave it for the external tester to find as that is "their job").

  10. Thou shalt not regard communicating with other members of the team as an unnecessary and tiresome overhead that can be ignored.

  11. Thou shalt not deviate from the "agreed" development approach without a good reason that has been thought about.

  12. Thou shalt understand that the external image of the development team is important - even though it does not contribute to your daily work.

  13. Thou shalt not call the customer a wanker even when it is true. <ok, can't have this on the wall>.

  14. Thou shalt understand that sometimes thou must do things because they are important to other people's jobs (thou art not the only person in the universe).

  15. Thou shalt understand that getting the software out there, so others can see something has actually been done, is important (we're not just doing this as an intellectual exercise).

Tuesday, November 16, 2004

Found a bug in Delphi 7

I got irritated with Delphi 7's SOAP implementation today. I was wondering why their XML code didn't produce the correct xs:datetime values with a local-bias for South Africa. So I filed bug# 9547 on Borland's Quality Central site.


The function DateTimeToXMLTime and XMLTimeToDateTime in XSBuiltIns.pas don't apply a local-bias for time-zones without transition times for daylight savings. e.g. South Africa uses GMT+2 (Harare, Pretoria) but we don't use daylight savings and therefore have no transition dates. The GetTimeZoneInformation API function is documented in the Platform SDK.

Thursday, November 11, 2004

Building Security Awareness in .NET Assemblies

I happened to actually look at a CodeProject e-mail today and found some articles by Chua Wen Ching on security in .NET assemblies. He has published 3 parts so far:



Part 1 - Learn to break a .NET Assembly


Part 2 - Learn to protect your .NET assemblies from being tampered


Part 3 - Learn to break Strong Name .NET Assemblies


I am eagerly awaiting part 4 to see what solutions he has. Obviously one that comes to mind is obfustication, but that isn't real security, its just a hurdle.

Wednesday, November 10, 2004

Nothin' but ASP.NET: Use Cache, Save Cash

Nothin' but ASP.NET: Use Cache, Save Cash

Learn how to use database cache invalidation in ASP.NET 1.1 with a similar technique as the one used by ASP.NET 2.0.

.NET disassembly tools

There comes a time in every developer's life when you just want to know how someone else did it. Yes I'm talking about disassembly of binary code, or in this case .NET assemblies.


Most .NET developers will know about a tool like Lutz Roeder's .NET Reflector which can do amazing things. Using the CodeDom it is able to reverse engineer methods to IL, C#, VB and Delphi on my machine. Yes I have Delphi 8.0 for .NET installed. But a tool like this is limited until it meets a really cool plugin like Denis Bauer's Reflector.FileDisassembler. It is able to dump an entire assembly into a file per class. It works like a charm from my initial experiments - I haven't tried to comple my Delphi.NET code as yet.