A few years ago I found an article pointing out how spammers had figured out how to abuse some code I wrote back in 2001 or so. I’d put it on the list to fix and even started a blog post so that I could take my lumps publicly.

Now I’ve rediscovered that draft post…and that I never fixed the bad code it had fingered. Worse, I’m no longer in a position to change the code.

Along similar lines, I’ve been told that a database driven DHCP config file generator that I wrote back in the late 1990s is still in use, and still suffers bugs due to my failure to sanitize MAC addresses that, being entered by humans, sometimes have errors.

I’ve written bad code since then and will write more bad code still, but as my participation in open source projects has increased, I’ve enjoyed the benefit of community examples and criticism. My work now is better for it.

There it is in the PHP manual for return():

Note: since return() is a language construct and not a function, the parentheses surrounding its arguments are not required. It is common to leave them out, and you actually should do so as PHP has less work to do in this case.

I knew the parentheses were optional, but I’ve been merrily using them all along. And I probably would have continued doing so until I saw the second note attached to the docs:

Note: You should never use parentheses around your return variable when returning by reference, as this will not work. You can only return variables by reference, not the result of a statement. If you use return ($a); then you’re not returning a variable, but the result of the expression ($a) (which is, of course, the value of $a).

I’ve got a PHP script that sometimes just dies with no errors to the browser and no messages in the error log. I’ve seen this in the past with scripts that consumed too much memory (yeah, it should have issued an error, but it didn’t, and increasing the memory limit fixed it), but now the memory limit is set pretty high and I’m not sure I want to increase it further. I certainly don’t want to increase it without seeing where it’s going wrong, anyway.

To do that, IBM developerWorks says the memory_get_usage() and memory_get_peak_usage() functions are for me. And they offer some other interesting tips as well.

David Cloutman pointed to Craiglist’s job ads as an indicator of programming language popularity. Here’s the hit counts for “web design jobs” and “internet engineering jobs” in the Bay Area:

Cloutman has a few ideas for what the numbers mean, but I’m just entertained by the data. (Note: he corrected his original numbers.)

Poul-Henning Kamp, the guy behind the Varnish reverse proxy, talks about 1975 programming:

It used to be that you had the primary store, and it was anything from acoustic delaylines filled with mercury via small magnetic dougnuts via transistor flip-flops to dynamic RAM.

And then there were the secondary store, paper tape, magnetic tape, disk drives the size of houses, then the size of washing machines and these days so small that girls get disappointed if think they got hold of something else than the MP3 player you had in your pocket.

And people program this way.

They have variables in “memory” and move data to and from “disk”. [...]

Well, today computers really only have one kind of storage, and it is usually some sort of disk, the operating system and the virtual memory management hardware has converted the RAM to a cache for the disk storage.[...]

Virtual memory was meant to make it easier to program when data was larger than the physical memory, but people have still not caught on.

Colin over at Command-Tab alerted me to some great cheat sheets, including this one for JavaScript at ILoveJackDaniels.com.

tags: cheat sheet, cheat sheets, javascript, programming, web, web development