Like nails on a chalkboard

You know the feeling... someone says something in a meeting that just grates on you. You know it's not true and now you have a choice. Do you nuke them, politely point out where they've erred, or do you simply forget it and go on with life? I had the opportunity to review a slew of Project Management books recently and Applied Software Project Management by Andrew Stellman, Jennifer Greene was one of them.

Their phrase "All developers are created equal" grated on me in this way and initially I went with the third route, but when they recently wrote an article for OnLamp titled What Corporate Projects Should Learn from Open Source and then it made Slashdot, I had to respond.

Indexing Experiment - Expressing Queries

In last week's post, I started this indexing experiment by creating a simple index based on the words found at specified URLs. Today, I want to look at querying such an index. Using last week's example, my goal is to find all indexed documents containing the words

  • Python and PHP
  • Python or PHP
  • Python not PHP

And so forth. Let's take a look.

The Right Idea?

If I believe everything I read: ideas are cheap; it's all about execution. Developers are sitting on dozens of great ideas for products or services, if they only had enough time and funding. It wouldn’t matter which idea they chose, as long as the execution was right.

Although there's plenty of truth in the "execution is everything" school of thought, it’s important not to completely devalue the idea, a good idea will imply and steer you towards the right execution.

Stupidly Easy App Walkthough

One day, the phone rings.
Joe: Hey!! can you make a website for my Candy Wrapper Club?
You: "Candy Wrapper Club?!?"
Joe: "Yes! We collect Candy Wrappers! We just need a little bit about the group, how to contact us and a membership list. It will probably only take you a week. My cousin has a webserver with PHP and MySQL. How about it?
You: <sigh> Sureeeeeeee, I've been wanting to try this MVC thing with PHP.
This is a long one, so grab a cup of coffee!

[Anon] Management and Refactoring

Well, we have our second victim for the Anonymous Blog. As noted before, this is not a single person's space, it is available to anyone who requests it. Therefore, I and no one else around here can claim accuracy or accept blame for anything said here. Please add your thoughts or if you'd like to post yourself, please let me know. - Editor, KC

I am part of a team working on a fairly big, complex piece of software. Over the last six years many, many different programmers have worked on it. The code shows it, too. There are various serious issues with the program: The performance could be much, much better and a lot of code could be simplified greatly. My colleagues and I have identified several areas that would lend themselves to meaningful refactoring work, some of them involving quite significant internal changes. Here's the problem though: All our development (be it new features or fixing of existing bugs) are very much schedule driven. This is a huge problem for us.

Indexing Experiment

Not that the discussion of web crawling is over - far from it - but I thought it would be nice to start tinkering with indexing a little bit. This post will bring a very simple example of creating such an index then. The example is intentionally simple to show how easy it is to get started on writing an indexing scheme in Python.

Learning Design Patterns – Facade Pattern

This week I'll be simplifying my life with the Facade Pattern in my series on design patterns plucked from this book and from examples on the Internet.

What is it?
The Facade Pattern simplifies a complex interface so that it's client can rely on simple methods in the facade that handle multi-step calls to subclasses. The client might call facade.PowerUp, then the facade would turn on all of the subcomponents in the correct order and adjust their initial properties.

Micro ISV Blogging: Summary

Over the last few weeks I posted a series on Micro ISV blogging, here is a brief summary of the five articles so far.

Don't Worry, it's Just Computer-Generated...

This has been happening a lot lately, but the canonical example ocurred today with my <sarcasm>wonderful</sarcasm> DSL provider, SBC. Some scary and/or irritating bit of correspondence arrives in the post, declaiming that I'm about to lose my health insurance, or my house, or my savings, or my left leg. Today, with SBC, it was along the lines of "your contract expires at the end of this month; if you renew for another year, we'll only jack up your rates 20%. If you fail to renew, we'll jack them up 150%."

How nice of them. You'd think that maybe, just maybe, they'd think to reward loyal customers by, oh, say... lowering their rates? Or at the very least, not sticking them with an increase?

Interactive Programming with the REPL

In this week’s post I’ll discuss the joys of interactive programming. For those who write only in compiled (or byte code compiled) languages this may be a foreign concept. There seems to be some level of this feature in most scripted languages. In Lisp interactive programming is supported by a feature known as the REPL, or read-eval-print-loop. It is also known as the top-level listener or simply the top level. Ruby has something similar called the IRB, or interactive ruby shell. In Python it’s just the interactive shell.