mult.ifario.us

I would prefer to blow my 15 minutes all at once on something major, but here's a snap that the barrista at the local Tully's snapped of Pat Helland and me on our way back from some pho:

I recently came across a post to a mailing list that asked how to truncate a Java double to two decimal place. The usual answers, either using a formatter and parser or multiplying by 100 and using floor() and then dividing by 100, will work, but there's an even simpler one:

double x = 12345.6789d;
double y = x - (x % 0.01);

As expected, y is 12345.67.

It seems like the typo instance that supports mult.ifario.us goes down at random times, since I stop by every so often and find the blog down. If I were really a good guy, I'd look at it to figure out why, but the logs don't have any useful information. It's easier to just assign a lightweight nanny to look after it; my choice is python (three guesses as to why not ruby, but read the script first):

#!/usr/local/bin/python
import os
import time

def kill_and_restart(procs):
  print time.asctime(time.localtime()) + " - Killing processes..."
  for proc in procs:
    os.kill(int(proc.split(None)[0]),9)
  if len(procs) != 0:
    time.sleep(10)
  print time.asctime(time.localtime()) + " - Restarting server..."
  os.spawnve(os.P_NOWAIT,"/usr/local/sbin/lighttpd", ["lighttpd","-f",
              "/home/pbrown/web/lighttpd/config/lighttpd.conf"],
             {"PATH" : "/sbin:/bin:/usr/sbin:/usr/bin:" +
               "/usr/local/sbin:/usr/local/bin"})
  return
  
procs = []
for line in os.popen("ps xw").read().splitlines():
  if line.find("lighttpd") != -1 or line.find("ruby") != -1:
    procs.append(line)
status = "".join([x.split(None)[2] for x in procs])
if len(procs) != 3 or "Z" in status or "T" in status:
  kill_and_restart(procs)

The bit with the dictionary in the spawnve is needed because cron is pretty dumb about the environment that it provides to the processes it starts, and ruby isn't on the path. To make sure that we're not being bad citizens:

pbrown@chilco$ time ~/bin/nanny.py
real    0m0.104s
user    0m0.015s
sys     0m0.015s

And then it goes in the crontab:

MAILTO=paulrbrown<at>gmail⋅com
@reboot /usr/local/sbin/lighttpd -f /home/pbrown/web/lighttpd/config/lighttpd.conf
*/10 * * * * /home/pbrown/bin/nanny.py 2>&1 >> /home/pbrown/logs/nanny.out

This ensures that I'll get an email if a kick is needed, and only running every ten minutes should ensure that the script never overlaps with itself except under truly extraordinary circumstances. This approach won't detect situations like internal deadlock or unresponsiveness, but neither would a nagging nannny. That has to be approached other ways.

Joel's crotchety pointer commentary and the ongoing programming language derby are food for thought, albeit that my first thought is about Spaceballs — "I see your Schwartz is as big as mine."

I have nothing against pointers, used recreationally or even by trained professionals, and I had a good time teaching data structures and algorithms in C during one of my semesters at UIC. (I probably had a good time because my idea of fun includes anything that combines colored chalk and running around in front of a captive audience for an hour.) It is my considered opinion that working with pointers is not particularly challenging other than that it can be tedious, and in the sense that working with pointers is good for punishing carelessness or sloppiness, I can see value in it as a teaching tool. As Bill de Hóra points out, concurrent programming in Java, especially pre-JSR166, provides a similar proving ground. I'm open to arguments as to why pointers help people build better software or help groups of people collaborate on large pieces of software, but I'm not going to hold my breath.

On the subject of different languages, Paul Graham has the following restatement of the Sapir-Whorf hypothesis (linguistic determinism) in the preface to his ANSI Common Lisp book:

Programming languages teach you not to want what they cannot provide. You have to think in a language to write programs in it, and it's hard to want something that you can't describe.

To strengthen the analogy with Sapir-Whorf, this statement is false, as it would preclude the creation of any programming language ever, but it poses an interesting question about how important language features are to programming. For contrast, here's a quote from Knuth's classic article on literate programming:

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

For me, this would be the yardstick by which to measure language features against the task at hand.

I originally ran into the de-motivational posters from Despair, Inc. back in the late 1990's, and while the posters could be considered trite (although less so than the motivational posters they mock), Despair, Inc. is now producing video podcasts and have published a 400+ page book with more bite.

The podcasts feel like a Christopher Guest mockumentary about a motivational speaker, and like the vignettes in Spinal Tap that evoke different bands, the sad kernel of truth in each of podcasts is that I've observed executives who emulate E. L. Kersten without realizing it...

Guy Kawasaki posted eleven lies that entrepreneurs tell venture capitalists, although "Eleven Lies that Entrepreneurs Tell Themselves" would work fine as an alternate title. Been there, told those.

Although FiveSight never raised venture capital, we tried a couple of times, and various people had varying small degrees of success convincing me to tell different shades of those 11 lies. A few thoughts about the various lies, by category:

• Analyst predictions and other forecasts. You should assume that the VC is at least as savvy as you are, so if it doesn't fool you, it won't fool them. On the flipside, if it does fool them, then they're uncharacteristically thick for a VC and you don't want them or their money anywhere near your baby.
• Uniqueness. Clever ideas often require educating the customer about the value, and that's a losing proposition. You shouldn't have to convince your customers that they want to be your customers...
• Beating the Big Boys. Small companies can innovate faster than large companies, but large companies can buy a little innovation and reach a market faster than a small company can ever burn money. If Larry, Bill, Steve, or any other billionaire wants your niche, he can out-sell and out-market you without breaking a sweat. On the other hand, if you can help that billionaire beat up on his buddies by getting him to market quicker or better, that's more interesting, but you need to pitch the billionaire and not a VC.
• Patents. No amount of funding will enable you to win a money fight with a juggernaut like IBM, Google, Amazon, or Microsoft. (One possible exception would be having a big university to back you.) The patent may have value to a juggernaut in an acquisition scenario, but that means it's a secondary consideration for investors.

What's the alternative to the eleven slide deck presenting your version of the eleven lies? Planning and running your business so that you don't have to lie at all. Of course, that may also keep you out of VC's offices. By the time that I had settled on FiveSight's path forward (and likely exit through acquisition), it was also clear that it wasn't a VC investment.

Our house in Seattle is about twice the size of our condo in Chicago, and we're starting to get the open spaces filled with furniture. One of the first pieces on its way is a nice armchair with more or less the same classic lines as my old, red thinking chair. I bought the red chair in the summer of 1989 or 1990, already in sub-par condition, at a garage sale for $3 and carried it home. The red chair is where I did almost all of my thinking and writing, and it followed me from Reed to Berkeley to Chicago, where it was donated to chairity (sic.) in 2003. I can only hope that it didn't fall into the wrong hands...

I've been wondering about the ambient context for my most productive thinking sessions, both foreground (thinking about things on purpose) and background (getting ideas spontaneously). For foreground thinking, I like an armchair, clean sheets of white paper, a decent black pen (i.e., not a ball point), and either colored pencils or crayons. A good-sized blackboard (not a whiteboard!!) with colored chalk and room to pace around will also work, and for some purposes, so will a text editor or word processor if I pretend that the formatting capabilities aren't there. I also prefer private, open space. (As for sharing an office, you might as well get the Handicapper General to fit me for headphones that play a loud noise at random but frequent intervals...) For background thinking, I like a walk or run, a shower, a drive, doing yard work, or something else to keep my lizard brain busy and focus my attention.