Weblog Without Honor or Humanity

Muppets go to Hollywood. Actually, PostgreSQL, which has just became version 7.3 goes Win32. The idea of doing native Win32 port of PostgreSQL has been discussed many times in the past and rejected. Sometime in 2002 the attitude has changed, mostly because of multiple independent efforts of doing Win32 port. The core team decided that this indicates real demand for such thing and decided that the best approach is to integrate Win32 into the mainline code. Now the question is not “if” but “when” and “how”.

If it breaks. jwz:

If it breaks, feel free to keep both pieces.

Mac upgrade. I’ve upgraded my (hardly used) Powerbook G4 to Mac OS X 10.2. 150 improvements, none that matter much to me. My life is exactly as it was before - what a disappointement. On a related note: here’s a confession of a Mac reverse-switcher.

Free Pepper.
Pepper is a text editor that I used shortly. It was a commercial product and its author recently decided to stop developement. I thought it was a nifty app (text editors are aplenty but this one had personality). Apperently more people think that it was nifty and want to free the source. They need $11 k to buy out the sources from the author, so far there is $360 in dontations. Recently a trick like that was pulled off for Blender (and it was around $100 k), will those quys succeed as well?

A bigger agent.
From Those Lips, Those Eyes :

There’s one thing you learn in this business, and you learn it over and
over: There’ll always be a bigger agent, there’ll
always be a better job and there’ll always be a prettier girl.

Good programming practices.
OSA Foundation is a project to follow. They have a high-quality people on the board, as evidenced by
this post on good programming practices:

Off the top of my head, here’s a quick partial list of things that I think are important:

• Continuous releases and daily builds
• Rather than put a bug in the bug database, first try to fix it. Don’t
  code first and ask QA to find bugs.

• The engineer who wrote the code is mostly responsible for QA.
• No code is finished until the unit test is finished.
• Good design results from getting something going quickly, followed by
  lots of quick iteration.

• The best architectures evolve for a long time.
• Code reviews are a regular part of development.
• Difficult parts of code are best done by a team of two people working
  closely together.

• If you see a new bug while doing something else, drop everything and
  jump on the chance to fix it. It just make your life easier down the road.

• It is possible to eliminate all bugs from many subsystems and you should
  use techniques that make it possible, like monte carlo simulations and
  exhaustive checking code whenever possible.

• Complexity is your enemy — the sooner you learn the smell of too much
  complexity, the better.

• Simplicity is your friend. Don’t fall for a really cool fancy algorithm
  unless you know you need it.

• Buzzword technologies often become religious. The only thing you should
  be religious about is happy customers and they don’t care about buzzwords.

• Don’t build elaborate systems unless you know you need them.
• Research existing open source project to make sure the code you need
  isn’t already available.

• Never write a slow program.
• By the time your project is finished your competitor’s project will be
  way better than you think.

• Price is only one feature of software. It’s often not the most important.
  From the user’s perspective, simple things should be simple and complex
  things should be possible.

• Automate releases.
• Use source level debuggers.
• Use IDEs
• Don’t write makefiles unless you have too.
• Measure then optimize.
• Always spend at least 10% of your time learning new things.
• Use multiple languages, programming environments, operating systems and
  programming methodologies until you are comfortable with them and learn
  to appreciate the benefits of different approaches.

• Use the best tools, even if they are expensive.
• Optimize variable names for maximum clarity, not minimum typing.
• It’s OK to make mistakes. The only thing that isn’t OK is to not learn
  from them.

• Don’t leave code commented out unless it’s clearly explained.
• Approach each piece of code you write like it’s final finished code.
  Don’t leave loose ends to clean up later because you’ll never have time
  to clean them up.

• Never code an algorithm that you know won’t work in the final product
  either because it won’t scale, run fast enough, or will have a rare
  failure case.

• All successful products have a life longer than you can conceive. Files
  and processors will grow by factors of 10,000 — make sure your design
  can accommodate change.

• Don’t code the first algorithm that comes to mind. Try to examine all
  possible approaches and choose the best. Get someone to review your
  approach before coding.

• Don’t put band aids on bad code, rewrite it. At first is seems hard, but
  after you’ve done it awhile you’ll find successive rewrites go much
  faster than you thought.

• When you work on someone else’s code, don’t leave it in worse shape than
  it came to you. Ask the original author to review your change.

• No bug is impossible to fix.
• Get to be good friends with a programmer, designer, or writer who’s
  better than you.

Tablet PC. Dan Bricklin tells us his impressions after using Tablet PC. He likes it. I think I like it too - they look cool. I want one but I’m not going to be getting it anytime soon. Tablet PCs are expensive and I’m way over my gadget-oriented budget.

LL1 Videos. Accidently, a day after I watched LL2 webcast on-line, I got in my mail a CD with videos from LL1 (which you can order from Dr. Dobb’s). Talks from LL1 actually interest me more. LL1 had talks about Arc, Rebol, Parrot, Goo. Good stuff.

LL2 webcast. I love internet. What else would enable me to watch Lightweight Languages Workshop 2002 (LL2). I liked the talk about Erlan (I don’t care much about Erlang but the presenter was entertaining), talk about disruptive programming language technologies and a talk about new language called Needle. Being there would be much more fun but being able to watch it is second best option.

Spam for spam.
I just got a spam advertising spamming services. You too can buy 1 million addresses for just $25. Interesting question: will my address will be in that database? I assume that yes, if the spammers use the database they sell. Which leads me to another question: I wonder how often spammers get their own spam?