Don’t use anything fancy like Microsoft Project. The trouble with Microsoft Project is that it assumes that you want to spend a lot of time worrying about dependencies….I’ve found that with software, the dependencies are so obvious that it’s just not worth the effort to formally keep track of them.

– Joel Spolsky, Painless Software Schedules

That article has many other great insights, including:

If you are sloppy, and pick big “chunky” tasks (”implement grammar correction”), then you haven’t really thought about what you are going to do. And when you haven’t thought about what you’re going to do, you just can’t know how long it will take.

…and

Many rookie software managers think that they can “motivate” their programmers to work faster by giving them nice, “tight” (unrealistically short) schedules. I think this kind of motivation is brain-dead. When I’m behind schedule, I feel doomed and depressed and unmotivated. When I’m working ahead of schedule, I’m cheerful and productive. The schedule is not the place to play psychological games.

As the article is over ten years old, Joel has end-of-lifed it, and replaced it with this one from 2007. I still like the original!

I was playing with an elderly blogging platform called Blosxom. It’s really simple to use, although that, combined with its age, means it’s not up to the current status quo. Regardless, I found it fun to play with. Plus, it’s written in Perl, and everything else is PHP these days, so it was a nice novelty.

Now, one of the things it expects (as does the rest of the internet, apparently), is that the CGI file may be treated as an application, folder, or directory on the web. Like this:

http://example.com/blosxom.cgi/2010/06/28#Post

Now, the script itself is the cgi file, a file called blosxom.cgi in the root of my server. As you can see, it looks like a directory in that location, and according to the Internet, that feature should work, passing any “trailing pathname information” (as Apache calls it) to the script via the PATH_INFO environment variable.

Apache didn’t think so.

Now, attempts to google for “apache trailing slashes” or “apache cgi trailing slashes” or anything like that ended up fruitless. It shames me to say I spent over an hour investigating things like ExecCGI, mod-rewrite stuff, and all manner of other things to try to find out why that feature wasn’t working for me.

Eventually, I did what I probably should’ve done an hour before, and looked at the server error logs. Yes, they existed and were visible. I didn’t think that particular host would let me see them — it’s a free host — but I was wrong, and they surprised me yet again.

So, here’s the key: the host had switched off the AcceptPathInfo directive. Ordinarily, that’s left to the handler concerned (CGI, PHP etc.) to decide, which explains the ubiquity of the “on” setting, and the lack of anyone complaining when it’s switched off in various places I looked.

So there you have it, folks. If your CGI scripts don’t work when you have trailing slashes or trailing path info after the script’s name, don’t get lost in RewriteRules – have a look for AcceptPathInfo.

Not only that, but the rest of the audio on the phone stops too, until a reboot of the phone.

Here’s how I fixed it:

• Make a call.
• Note the codec it uses (shown under the call box). It will be something like “PCMA (64kbit)” or “PCMU (64kbit)” or something else technical looking^[1].
• Assuming the call fails (which is, after all, why you’re here!) go into the settings, choose “Audio Codecs”, and disable the codec you just noted. In my case, I set “PCMU (64kbit)” to “Never”
• This is the annoying bit. You’ll probably have to reboot the phone if SIPDroid won’t let you make another call.
• Once you’re back in, make another call, and note the codec. If you’re lucky, you’ll have a successful call, and no lockup. Success!
• …on the other hand, if you’re like me, you’ll have to repeat this process until it works. For me, I hit GSM before it worked.

Of course, there are other known issues at the moment, including one-way audio, issues with registering with the VOIP server, and so on. I didn’t have these issues, so if you are, you’ll have to look elsewhere I’m afraid!

^[1] …where “technical looking” means stuff like G722 HD Voice (64kbit), silk24, silk16, silk8, speex, GSM, BV16, or other supported audio codecs.

(Writing this here because I haven’t seen anything similar after much googling. Hopefully it’ll help someone!)

Other programmers are happy to question the spec, to discover business functionality that may not have been known, and to engage more in design.

Sometimes, and ideally, these functions are separated; you have a programmer who solves problems made clear in the spec, and you have a software project manager/domain expert who designs the solution to be implemented by a programmer.

Having said that, it’s not unusual to find the two functions in a single person, particularly a developer with more experience within the problem domain (in fact, it’s hard to find a project manager who’s experienced enough to design a good solution, who isn’t an experienced programmer).

Standard project management technique would suggest you start with the scoping, and the environment (the “why” and the “what”), and only when you get to identifying the work, to get down to the “how”.

Frequently, the guys involved in organising the scope are not the guys doing the actual nitty-gritty work, so by the time they’re involved, the “why” and “what” should ideally have been specced out.

With software development, particularly with iterative methods, the “what” is usually figured out as part of each iteration, which lets the “why” leak in, and should ideally involve lots of two-way communication between the developers and the client.

This isn’t always how it works though. As I said above, it’s an ideal world that can separate the functions, and often a programmer with enough experience to connect business analysis with programming will already be filling that role in any given project.

You may try this:

…only you find, to your amazement, that SQL Server has put the same number into each row.

Hmm.

In SQL Server, when rand() is called multiple times in the same query (e.g. for multiple rows in an update statement), it usually returns the same number.

Two problems:

* Firstly, the rand() function returns a number between 0 and 1.
* Secondly, when rand() is called multiple times in the same query (e.g. for multiple rows in an update statement), it usually returns the same number (which I suspect your algorithm above is trying to solve, by splitting it into multiple calls)

My favourite way around this problem is to use a function that’s guaranteed to return a unique value each time, like NEWID(), convert it to binary, and use it as the seed.

This works because NEWID() is guaranteed to return a new GUID (a globally unique 16-byte number) each time it’s invoked. We must convert this to binary before using it, as RAND() won’t accept GUIDs as its seed.

So, although RAND() ordinarily gives the same random value for each row in an update, we get over the problem with RAND by giving it a different seed for each row using a function that gives a different result for each row.

Only you’ve got hundreds of employees, each one with their own email address, and your MySQL database is in dire need of updating to reflect this.

To get around this, you’ll need to replace the relevant part of each email string within an update statement, grabbing the hostname substring (after the ‘@’) with a REPLACE, and replacing it.

Note: REPLACE() is case-sensitive, so if needs be, you can use LOWER(email) inside the REPLACE function if you need to catch all case possibilities, as below:

This will also convert all your email addresses to lowercase, so be aware of that.

Accessibility is a hot topic on the web, and there are many emerging standards to help move in an accessible direction. We have CSS media types, alternative web pages with simpler navigation and high-contrast styling, alt and title tags, and the general move away from mixing style with substance.

Along with all of this, we have the relatively old standard of using the accesskey attribute on invokeable elements such as hyperlinks and form inputs. This allows us to attach a keyboard shortcut to elements in our webpage.

Unfortunately, this isn’t a widely used, or easily implemented standard. Although the accesskey attribute is widely supported, only one commonly-used browser (Opera) at the time of writing provides an easy way for users to see what accesskeys are enabled on a given site, and there is no widely-accepted standard for choosing which accesskeys perform which function.

However, with a little jiggery-pokery we can implement a simple way to show accesskeys on demand:

The code for the above is pretty simple. First, the button:

<input type="button" value="Show access keys" 
       onclick="showKeys()" style="float: right;" />

The hyperlink itself (abbreviated):

<a href="http://jeremysmyth.com/...." 
       title="Link to this post" 
       accesskey="9">This link</a> 
will bring you...

Finally, the javascript:

function showKeys() {
        if (document.styleSheets) {
                var sheet = document.styleSheets[0];
                var len = sheet.cssRules.length;
                // reformatted to fit
                sheet.insertRule("[accesskey]:after {" +
                        "font-weight: 700; " +
                        "border-bottom: 1px blue dotted; " +
                        "content: '[' attr(accesskey) ']';}" , len);
        } 
}

Clicking on the button calls the “showKeys()” function in the Javascript script block, which adds a style to the current stylesheet. The style automatically styles elements with the “accesskey” attribute, adding the value of that attribute after the element itself.

Put simply, it adds a styled [9] after the hyperlink, because (1) it has the “accesskey” attribute, and secondly, the “9″ is the value of that attribute, as calculated by the attr() function.

Note: The above Javascript won’t currently work in Internet Explorer; for that, you’d need Microsoft’s addRule function rather than the standards-compliant insertRule I’ve used.

We have thousands of open idea requests (the codebase is nearing 20 years old), and close only a sizeable fraction of those opened regularly.

From our perspective, the idea requests are welcome, but not all of them are actionable; some are brilliant, and are implemented immediately because they work well with our vision; some are entirely incompatible and are closed/denied.

The majority fit in between; they’re ideas that would work with a bit of tweaking, or a bit of thought, but aren’t necessarily on the primary development roadmap, so don’t get our attention immediately. Nor do they warrant closing, because they are relevant, merely not timely or important.

Because our developers have their own ideas, their own neverending todo lists, we treat the open idea pile more as inspiration than as a roadmap. There’s very much a feeling of “we’ll get to it when we’ve run out of other things to do”, but this never happens in practice.

I know it’s a cop-out not to choose one or the other, but I think it’s a normal thing to have to choose between two equally bad things in a public forum like this: either responding to most feature requests with a “denied”, and so risk upsetting the folk who love the community enough to contribute with their own ideas; or leave some of them dangling because they’re not immediately and obviously wrong, but to do something worthwhile with them takes more time and effort than the idea deserves right now.

It’s pretty well known that most browsers will display a tooltip of sorts when you hover over an image. The alt attribute of the img tag gives rise to that, in pretty much all places.

Lesser known is the title attribute, which is supposed to give the tooltip; the alt attribute might do that as a side-effect if title isn’t there, but it’s just that: a side-effect. The alt attribute is really there to give browsers that aren’t displaying images (or screenreaders that can’t see them anyway) some idea of what the image is.

This separation of concerns is somewhat of a problem when it comes to image maps: in image maps, the alt text for the area elements is there for similar reasons, to show what options are there when the image isn’t there. The title attribute is there for the tooltip, as ever.

However, if both alt and title are there, Internet Explorer shows the alt text as a tooltip, where Firefox will show the title text. Although they serve very different functions, a conscientious web developer is forced to keep them identical, or risk causing problems for the non-standards-compliant behaviour of Internet Explorer.

Of course, title will still work in other places, for example on images or even links:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
   "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

What’s the relationship between that and the actual code in the web page?

Well, a DOCTYPE tag declares what document type this webpage is, by formally specifying a Document Type Descriptor (that’s what the “dtd” in the filename and in the declaration means). This is the formal specification, written in its own computer language, used to define legal dialects of languages descended from SGML. Most predominantly, this includes languages like HTML 4.01 and XHTML. Hence this walkthrough.

In our specific case, it references a specification for XHTML, which is a modular XML-expressed version of HTML. Let’s look inside.

Firstly, if we look in the declaration, we see the link ““http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd” which, if you download it, shows the DTD itself. For XHTML, this is a relatively short document; the specification largely consists of modules, referenced from this document. Let’s have a look.

Within the DTD, you’ll see this section (around line 121):

<!-- Text Module (Required)  ..................................... -->
<!ENTITY % xhtml-text.module "INCLUDE" >
<![%xhtml-text.module;[
<!ENTITY % xhtml-text.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Text 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-text-1.mod" >
%xhtml-text.mod;]]>

This defines a module to be included, which itself is a technically part of the DTD as it is INCLUDEd.

If you navigate to the included module, “http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-text-1.mod”, you’ll see a further set of INCLUDEd items, for example:

<!ENTITY % xhtml-inlstruct.module "INCLUDE" >
<![%xhtml-inlstruct.module;[
<!ENTITY % xhtml-inlstruct.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Inline Structural 1.0//EN"
            "xhtml-inlstruct-1.mod" >
%xhtml-inlstruct.mod;]]>

This entry includes the inline structural elements br and span, and further down the document we have more included modules containing inline phrasal elements (em, strong etc.), block structural (p and div), and block phrasal (h1, h2 etc.).

Try them:

• xhtml-inlstruct-1.mod
• xhtml-inlphras-1.mod
• xhtml-blkstruct-1.mod
• xhtml-blkphras-1.mod

In each, you’ll see the definitions for tags such as p, div, code, strong, em and so on.

For comparison, have a look at the HTML 4.01 DTD, which you’ll be able to follow using the DOCTYPE:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">

…and linked to from here: http://www.w3.org/TR/html4/strict.dtd. As you’ll see, it’s not quite modular, but still contains code defining the elements (and their contents, attributes and so on) that are legal within the dialect concerned.