reesesWeb

58% (Dixie). Barely into the Dixie category.

Er, what?

Extremism is a crucible for annealing morality.

This has been getting overexposed everywhere, but it's great. It has the same rambling unfocusedness of dada. I would buy someone this book on Ruby just to see how they'd handle it.

...home reefer enthusiasts are so attuned to the life cycles of their captives...

reeses == m0r0n

So, let's say you address part of your problem with a shitty residential t1 loop by implementing traffic shaping on your router. You take some measurements with dslreports, and you cap your bandwidth at, say 240kbps. Yes, that bad. It enables Vonage to work slightly, and that's what you're after.

Fast forward two weeks. You (or, more importantly, your wife) gets fed up with the shitty network and inept administration, and you order cable modem.

Cable is installed. You rewire the network, and check your speed.

WTF??? 240kbps down? This is supposed to be three mbit!

If you find yourself in this situation, kindly remember to turn off shaping, or at least tweak the thresholds.

Shibnibble.

If your browser supports alternate stylesheets (Firefox does, via the little palette icon in the lower left), put on your sunglasses and check out my homage to my first window manager.

Do you remember a time when you looked at something that ugly for 18+ hours/day?

Now I know why they had to invent pr0n, so people could stand looking at their screens.

Cleaning things up and replacing my four-hundred-year-old nested table mess with CSS. It looks fine in Safari 1.2 and looks OK in Firefox 0.8, although the line spacing is a little fux0r3d. Use the atom feed instead, if you don't like how it renders in your browser.

I can't do anything about the actual content with CSS, so you're skr00d there.

Tore through a few books recently:

The Great American Novel, by Philip Roth

I picked this up after Goose reminded me that Roth wrote like a mofo. I had read Portnoy's Complaint back when Hector was a pup, and figured that I missed most of what was interesting.

Let me lay it out now: Roth writes better than you, or anyone you know, or anyone you have ever read, ever has or ever will.

I hate baseball, and this book is nowhere near Roth's best, but there are stretches of this book that I wanted to lube up and get busy with. I wasn't so happy with the last half of the book, but the first half, especially the first fifty pages or so, is pure sexbutter. I started it on the way to the airport on Monday morning, and probably scared everyone in the Metro and the terminal with my stifled chortles and cannibalistic grin.

From http://java.sun.com/developer/technicalArticles/Interviews/livschitz_qa.html, via Lambda the Ultimate (addendum: also on lispmeister):

Q. Jaron Lanier has argued that we cannot write big programs with a lot of code without creating many bugs, which he concludes is a sign that something is fundamentally wrong.

A. I agree with Jaron's thesis completely. The correlation of the size of the software with its quality is overwhelming and very suggestive. I think his observations raise numerous questions: Why are big programs so buggy? And not just buggy, but buggy to a point beyond salvation.

I think it is rather obvious why large software projects are inherently buggy. I can think of two reasons off the top of my head, one much, much more important. I agree for the most part with the article, in that understanding of components is essential, but I veer a little away from the problems and solutions enumerated as they feel autocratic, to be expected from a major vendor such as Sun. "Use our standard components, and this cool language we've developed to use them, and your problems will melt away!" Anyway, let me prate...

Software construction is a largely cerebral activity, and as such, requires the notion of a unit of conceptual work. Let's take an overly simplistic perspective on this, and say that individual velocity is constant. A given project will require the execution of a fixed number of these units. They can be executed in parallel to some extent, distributed across a team, but one person can only execute one unit at a time.

No matter what, the more of these units comprising a project, the larger the number of defects. It's like juggling an increasing quantity of balls, chainsaws, and flaming torches. Eventually, you'll have too many, and someone's losing a hand. It doesn't matter if someone juggles better than most, because the scale is so large -- good juggling might involve a dozen balls, and as far as I know, no one has solo juggled even more than fifteen. Now imagine juggling challenges routinely involving thousands of balls. The more lines of code, the more bugs, under our current paradigms of software development.

The solution that is most popular right now (other than overburdening specification, which I assert barely helps) is to reduce the number of units of work in any iteration (either by reducing scope or efficient design) and executing with small teams, distributing the work unit across 3-6 developers.

However, there is a limiting factor on the quality of code produced by groups of developers. Communication between all cognitive nodes is inherently lossy, and this is the source of all problems in software development in the large.

The least lossy communication is between two units of thought (separated temporally) in the same mind. If I think of something, I can build upon the thought with a decent recall fascia. This can be reduced proportional to recency, as quality of recall decays with time.

Lossier than this is communication between individuals of common background and shared experience. Pair partners are a good example of this. It's still lossy because of the burden of expression, but increased familiarity will increase contextual rapport, and reduce misunderstandings. Your pair partner knows when you're being sarcastic and not literal, and this maps to an understanding of intent when exerting conceptual effort.

Even lossier than this is communication between remote/estranged/unfamiliar individuals. Imprecision of verbal communication introduces errors in expression, and creates inaccurate constructs in the mind of the remote individual.

Lossiest is the communication between groups. This communication is often written, in the form of functional specs, api documentation, comments in code, etc. It's always poorly maintained, poorly edited, and written in a peculiar pseudo-academic style that is dry and pedantic, and from which all vitality has been extracted. As such, the eyes glaze over and the mind shuts off and merely stores motes of knowledge.

This poor communication is the result of all major defects not arising from individual programmer ineptitude, and, in fact, helps contribute to my second reason, harmonic propagation of complementary errors. I.e., aggregations of small bugs lead to big bugs.

Software is usually developed in a bottom-up fashion. One person builds a component. Another person consumes that component in another component. Another person adds a message-passing layer to that component, so that it can communicate with other components in the system over a common bus. All of these components, modules, and functions depend on an understanding of both the immediately-relevent components, modules, and functions, and an implicit understanding of the components, modules, and functions each of those depends on.

Lossy communication diminishes the accuracy of the impression of these dependencies. This loose cognitive binding between components results in code that is not adequately defensive, does not handle errors or boundary conditions appropriately, and creates defects within the system.

How would I solve this problem?

A couple ideas, all abundantly obvious if you've tortured yourself by reading to this point, all related to reducing aggregate loss in communication.

On one hand, increase expressivity of explicit communication. Teach verbal skills to programmers to raise the quality of communication. This is incremental, and no massive gains will be made.

Increase expressivity of implicit communication within code. Design by contract, checked exceptions, etc. Also incremental, but look at the lack of low-level bugs within java code. NPE's are well-represented, but there are very few pointer arithmetic bugs, a large number of the bugs are of a higher conceptual level. Bad business rules, faulty data, etc.

Alternatively, avoid the problem altogether by reducing the communication requirements within the system. This will shift the balance toward the higher-quality end of the communication spectrum. A larger quantity of the work will be done by individuals, and be more conceptually consistent. This can be done with the use of 4+ gen languages, although, again, those create a massive orb of lossiest communication, and a great deal of faith is necessary when developing in these environments. Is the environment sound, is the interpreter/compiler consistent, etc.?

I am an amateur linguist, so I tend to err in believing that the problem can be solved environmentally. I always tend to believe that the right language (whatever the representation, written, geometric, visual, acoustic, etc.) will lead to a massive increase in code quality. This language can and should be part of a holistic environment, either an IDE or image such as Smalltalk or Lisp use, and honestly, the use of better IDEs has been observed to increase code quality for reasons cited above. Intellisense in Visual Studio, and its like in other environments such as VisualAge, IDEA, etc., have enabled me to write code very quickly with a lower defect rate than previously possible, moreso than can be attributed solely to experience. I include refactoring support, etc., in this.

Obviously, automated analysis tools are massively useful. Checkstyle, lint, PMD, etc., will also greatly reduce the errors resulting from programmer ineptitude, by which I mean errors that always happen (fat-fingering constants, not knowing how methods on immutable objects work, etc.) but can be caught in a straightforward way with modern tools.

I was sitting there with my headphones on and that "I'm listening to my iPod" expression on my face, i.e., blank stare forward. I had the reading light out, and apparently, the earphones weren't visible.

"Sir, is your reading light inopportune?" saith the flight attendant.

It took me asking her to repeat herself three times to realise she had no idea what "inopportune" meant, and that she probably meant something along the lines of "inoperative".

Don't believe everything you read on Orkut.

Here it is, via lispmeister. A suitable replacement for changedetect, which, we all know, sucks the goat arse. Web Secretary is a vast improvement on my elisp hack.

From the project page:

Web Secretary is a web page monitoring software. However, it goes beyond the normal functionalities offered by such software. Not only does it detect changes based on content analysis (instead of date/time stamp or simple textual comparison), it will email the changed page to you with the new contents highlighted!

One q: is it "highlighted" or "highlit"? Suffer me the sloth preventing me from looking it up myself. I like "highlit", because I'm that type of person.

We moved into a new place yesterday, finishing up a lot of the unpacking today. We moved because Kat wanted a larger place, as the difficulty of storing things in the last place was getting to her. When things get to her, she gets to me.

This place is just slightly bigger, about one room, one bathroom, and 350 square feet. It's smaller than our place in SF, but it feels capacious after our tiny hovel in DC.

Obviously, with the increase in size, there's an increase in price. One of the absurdities of the District of Columbia is that I can move three miles and save $2k/month in "state" income tax. So, whilst I hate moving, (Hate) moving out of DC is like Kat getting a job. A badly-paying job, but a job nonetheless.

There are two bloody awesome things about this place. One, is that we have literally 200 restaurants within about six blocks. The second is that this county is as non-smoking as California. It's bloody glorious. We sat at the bar and ate foie gras tonight, and were actually able to taste it.

reeses == moron

So, I'm happily sitting here at 5:20pm, and I looked at my ticket to see what the boarding time was.

The boarding time was an hour ago, because I bought the ticket for a 4:45 departure instead of 6:30. 6:30 was the time for every flight I've taken in the past three months, so why would it be anything else?

Because, two weeks ago, I thought it would have been a good idea to go home a little early.

Fux0r. I had the brief concern that I'd be stuck in Minneapolis longer than I wanted, and I was willing to pay whatever it cost to get out. Luckily, elite status is good for one thing, and that's bailing your stupid ass out of predicaments such as this.

Jesus.

Best fuckin' video ever.

Fathom is one of the few software companies in the world created specifically and exclusively for developing enterprise solutions on component based�platforms (J2EE and .NET), emphasizing specifically the use of SOAP, XML and Web Services.

Has someone redefined "few" since I last checked a dictionary? Has it joined "bad", "wicked", "stupid", and "nasty" in the ironic argot of our time, and taken on a new meaning, completely opposite from the literal definition?

Just checking.

Yet more evidence that one of the defining characteristics of Sofitel is "crappy wifi". Do not stay there, unless a bidet is worth giving up high speed access. Yes, it's a tough call.

Note to self: read this later.