Mooring Hitch on a Slipknot

Here's a fun knot I worked out. It's essentially two slipknots securing each other. It forms a secure, single loop, and can be quickly released by pulling on the working end. I'd be interested to know if anyone has seen it used or know if it has another name. Warning: I'm not endorsing this knot as being useful for any particular purpose, use at your own risk.

Tying Instructions

  1. This is a knot, get some rope.
  2. Tie a slipknot.
  3. Form a single turn by passing the working end behind itself.
  4. Pass the turn over the slipknot forming a large loop.
  5. Pull a bight of the working end through the loop of the slipknot, creating the loop of a second slipknot.
  6. Tighten the large loop to secure the knot. To prevent accidental release, pass the working end through the loop of the second slipknot.
  7. To release, pull the working end back through the second slipknot and tug perpendicular to the standing part.
Update: Thanks to the friendly folks on the International Guild of Knot Tyers Forum, I've been able to identify this as a variant of the . The bight in the standing end is replaced by the loop of a slipknot, which fixes the position of the knot on the standing end, allowing it to function as a loop as well as a hitch.

xsection.js | 30 Years in Data

The Earth has, just today, completed revolving around the sun three times for each finger on a typical human hand since the day I was born. To commemorate the occasion, I made an interactive visualization of my life. I've open-sourced the code as xsection.js and you can create your own custom version by modifying the data.js file.

Return to Moderate Drinking is Still a Lie

Every few years, someone discovers that problem drinkers can return to moderate drinking—and they're always wrong. So when I saw an op-ed in the New York Times entitled "Cold Turkey Isn't the Only Route," I was disappointed, but not surprised. The op-ed, written by Gabrielle Glaser in support of her new book, has a simple message: for those who struggle to control their drinking, moderation is an alternative to abstinence. This claim is not new, and it's been disproven time and time again, often at the cost of human lives.

The first excitement over moderate drinking came after a 1962 case study by D.L. Davies. Of 93 patients treated for alcohol addiction, Davies found 7 who self-reported (with corroboration from family) drinking at most 3 pints (4 12 oz. drinks) of beer per day for at least 7 years after their treatment[1]. Although this sparked the first wave of claims that alcoholics could achieve moderate drinking, Davies' actual conclusion was that "the generally accepted view that no alcohol addict can ever again drink normally should be modified, although all patients should be advised to aim at total abstinence." Unfortunately, even that modest claim turned out to be based on bad data. A 1994 followup concluded that (surprise!) his patients had understated the severity of their drinking[2].

In the 1970s Mark and Linda Sobell picked up the torch. They devised an experimental technique to train alcoholics to drink moderately and tested it on 20 patients, concluding "some 'alcoholics' can acquire and maintain controlled drinking behavior over at least a 1-yr follow-up interval[3]." Based on those 20 patients, they wrote a book to teach their method to the general public[4]. In 1982, a team of scientists from UCLA did an independent review and follow-up with the Sobells' patients, finding very different outcomes:

Only one, who apparently had not experienced physical withdrawal symptoms, maintained a pattern of controlled drinking; eight continued to drink excessively—regularly or intermittently—despite repeated damaging consequences; six abandoned their efforts to engage in controlled drinking and became abstinent; four died from alcohol-related causes; and one, certified about a year after discharge from the research project as gravely disabled because of drinking, was missing[5].

In 1984, a Federal panel investigated the Sobell's for fraud. The panel found ambiguous language, errors, incorrect statements, and that the Sobells had "overstated their success," but attributed these discrepancies to carelessness rather than deliberate fraud[6].

The 1970s also saw an oft-cited study from the RAND Corporation, reporting that moderate drinking didn't predict relapse in patients previously treated for alcohol problems[7]. But that study only followed patients for six months. A four-year follow-up by the same researchers found that many of the original study's "moderate drinkers" had relapsed[8][9].

In Wednesday's op-ed, Glaser mentions a program called Moderation Management (MM) and reports meeting many women who have used it to change their drinking habits, but she doesn't go into MM's history. In 1994, on the heels of the Sobells' study and the first RAND report, a woman named Audrey Kishline came across the research on moderate drinking. She believed she was a problem-drinker, but not a chronic drinker, and embraced moderate drinking as her goal. Then, under the guidance of the Sobells, and contemporary moderate-drinking proponents Jeffrey Schaler, Stanton Peele, and Herbert Fingarette, she founded Moderation Management. She wrote a book, analogous to AA's "big book," to help other problem-drinkers like herself find an alternative to abstinence[10]. MM continued to grow and gain members over the next 6 years.

Then, on March 25, 2000, Kishline crashed her truck into oncoming traffic on Interstate-90, killing a 38-year-old man and his 12-year-old daughter. At the time, Kishline had been on a two-day vodka bender. She later admitted to NBC that while running Moderation Management, she'd been breaking her own rules, drinking at least 3 or 4 drinks a day, every single day, and sometimes binging on 7 or 8[10]. In her interview, she said she still believes problem-drinkers can achieve moderation as long as they're not truly alcoholic, but when asked where that line is, she replied "Nobody knows."

Kishline's experiment failed, and the small-scale, short-term, self-reporting studies claiming to show a return to moderate drinking have all fallen apart under scrutiny. The longest, largest study of the behavior of problem-drinkers has been by Harvard's George Vaillant, who studied over 600 subjects from the 1930s to present day. His conclusion: "Training alcohol-dependent individuals to achieve stable return to controlled drinking is a mirage.[9]"

In Glaser's defense, she does qualify her claims, saying "This approach isn’t for severely dependent drinkers, for whom abstinence might be best." But (almost) no one suggests abstinence unless a drinker is already having problems. If you want to drink less, try drinking less. If that works, you don't need a book, if it doesn't, there's probably no book that can help you. Glaser's book follows the path laid out by the Sobells, Kishline, Schaler, Fingarette, and Peele: helping no one, and exploiting the hopes and denial of the chronically mentally ill.

If you'd like a credible source of information on alcoholism, I highly recommend Alcoholism: The Facts by Ann M. Manzardo et al. and The Natural History of Alcoholism Revisited by George E. Vaillant. For a more personal account, Drinking: A Love Story by the late Caroline Knapp is honest and brilliant. Let's finally put the myth of return to moderate drinking to rest.

[1] D.L. Davies. "Normal Drinking in Recovered Alcohol Addicts." Quarterly Journal of Studies on Alcohol 23 (1962): 94-104.

[2] G. Edwards. "D.L. Davies and 'Normal drinking in recovered alcohol addicts': the genesis of a paper" Drug and Alcohol Dependence 35.3 (1994): 249-259.

[3] M. Sobell, and L. Sobell. "Alcoholics Treated by Individualized Behavior Therapy: One Year Treatment Outcome." Behavior Research and Therapy 11 (1973):599-618.

[4] M. Sobel, and L. Sobell. Behavioral Treatment of Alcohol Problems: individualized therapy and controlled drinking. Springer, 1978.

[5] M.L. Pendery, I.M. Maltzman, and L.J. West. "Controlled Drinking by Alcoholics? New Findings and a Reevaluation of a Major Affirmative Study" Science 217(1982):169-175.

[6] P.M. Boffey. "Panel Finds No Fraud by Alcohol Researchers." New York Times. September 11, 1984.

[7] D.J. Armor, H.B. Braiker, and J.M. Polich. Alcoholism and treatment. Rand, 1976.

[8] J.M. Polich, D.J. Armor, and H.B. Braiker. The Course of Alcoholism: Four Years After Treatment. Rand, 1980.

[9] G.E. Vaillant. The Natural History of Alcoholism Revisited. Harvard University Press, 1995.

[10] A. Kishline. Moderate Drinking: The Moderation Management Guide for People Who Want to Reduce Their Drinking. Crown Publishing Group, 1994.

[11] D. Murphy. "Road to Recovery." Dateline. NBC. Sept. 1, 2006.

Laminar Flow Fountain - Maker Faire 2013

This year at Maker Faire Detroit, I helped Matt Oehrlein and the team from i3 Detroit with their laminar flow fountain. The fountain is composed of three laminar jets. Each jet shoots into a barrel containing the next jet, creating a ring. The individual jets are controlled by an Arduino which wirelessly communicates with a Makey-Makey connected to three brass candle holders. Touching two of the candle holders causes a jet to connect the corresponding two barrels.

Since the project was built in Detroit, and I'm living in Boston these days, I wasn't able to help with the fountain construction. Instead I helped create a "screensaver" demo to show the fountain off when there isn't any activity on the controller. I didn't have access to the electronics when I started because 1. they were in Detroit and 2. they weren't finished yet, so instead I wrote a simulator for the fountain in Processing and worked on it in Boston.

Since the team from i3 was using an Arduino to control the fountain, and the Arduino language is a subset of Processing, I was able to copy my demo code straight from the simulator and into the controller code. You can see the result in the video above, showing the demo running on the fountain with the simulator in the upper right corner.

I wish I could take credit for the fountain itself, because it turned out amazingly well (despite a lot of wind throughout the Faire). The demo was still a lot of fun to work on, and this project now has me thinking about more ways the Arduino/Processing combo can be used for remote collaborations.

Drupal Hooks Should Use PubSub

Drupal is an incredibly flexible piece of software, but that flexibility often comes at the price of slow performance. After several years working on Seltzer CRM, which I modeled after Drupal 6, I've realized that there is a simple way to get the same flexibility without as much of a hit to performance.

Drupal achieves its flexibility through modules and hooks. A Drupal module is simply a self-contained chunk of code that can be installed and enabled to provide a set of features, like a shopping cart, or comment moderation. A hook is a function in one module that changes the behavior of another module, like taking a form produced by one module, and altering its contents. Drupal's takes an implicit approach. If I have a module foo and I want it to alter forms produced by other modules, I implement the hook_form_alter() hook like so:

function foo_form_alter(&$form, &$form_state, $form_id) { ... }

Whenever the form system creates a new form, it checks each module to see if hook_form_alter() is implemented, and if it is, passes the form data through that function. All my module needs to do is define the function. So what's the problem?

The performance problem is in plain sight. Every time a hook is called, every module needs to be checked for the existence of that function. The number of checks increases linearly with the number of modules, and in practice, most of those checks are unnecessary because any given hook will only be implemented by a small fraction of available modules. We can improve performance by switching to an explicit approach.

For our first try, let's invent a function called form_alter_register() that allows our module to explicitly register a callback:

form_alter_register('foo_form_alter');
function foo_form_alter(&$form, &$form_state, $form_id) { ... }

Now, the form system can check each callback in the list rather than checking each module, which could speed things up quite a bit!

However, we're not quite at the same level of flexibility yet. Let's imagine that there's another module called "widget" and if its installed we want to be able to alter widgets as well. We do the following, right?

widget_alter_register('foo_form_alter');
function foo_widget_alter(&$widget) { ... }

It works fine if the widget module is enabled, but what if the widget module is optional? Then widget_alter_register('foo_form_alter') won't be defined, and our code will crash! We could check whether the function exists before calling it, but that could get tedious. Better yet, we can use the same trick again, resulting in something like a publication-subscription approach.

Specifically, we define two core functions, one that allows modules to register the hooks they implement, and one that calls all hooks of a given name:

function hook_register($module_name, $hook_name) { ... }
function hook_invoke_all($hook_name) { ... }

Then our code to implement the hook looks like this:

hook_register('foo', 'widget_alter');
function foo_widget_alter(&$widget) { ... }

Now we have improved performance and the same level of flexibility. Some might argue that even calling hook_register() before each hook definition is tedious, and it may be. On the other hand, code is read more than it is written (as the adage goes) and this pattern explicitly identifies a hook as such, making it more readable, while Drupal's current pattern does not. So for improved performance and readability, the next time I'm writing a modular framework, I'm likely to use this pattern instead.

PS: Does anyone know if there is a proper design pattern name for either of these approaches?

Sustainable Hackerspaces FTW

Last Friday, the CEO of i3 Detroit announced his resignation, and Bucketworks in Milwaukee announced that they were raising money to help make rent (they did). Both announcements generated a lot of valuable discussion about the sustainability of hackerspaces, but there are a few important points that I believe are often overlooked when talking about sustainability.

Growth hurts sustainability. Expanding membership numbers or square footage sounds like a good thing for a hackerspace, but it also carries downsides, especially when that growth happens quickly. More members and more space means more to manage, which means a higher burden on the leaders of a space. A quick influx of new members can weaken the community because those new members take time to learn the group’s social norms (e.g. how to “be excellent,” as so many spaces encourage). It also takes time for new members to learn how to contribute back to the space, so even if they want to, they won’t at first.

At i3 Detroit, they’ve implemented a mentor system where all new members are assigned a mentor (similar to the time-tested big brother/sister system used in fraternities and sororities). Mentors are a single point of contact to help new members get acquainted with the space, its rules, and its values. It’s a new program, but it seems like a great way to tackle the instability that comes with growth, and I have high hopes for it. Have any other spaces tried this technique, or others, to combat the instability associated with rapid growth?

Fundraising is good, saving is better. Many spaces run very close to the break-even point, so when the natural oscillation of membership goes down, or they have to make an unexpected repair, they need to have a “rent party” to quickly come up with money to make ends meet. The alternative is to regularly contribute to an emergency fund. One benefit of such a fund is that even if you still need to have a fundraiser, it buys you time. That extra time opens up new possibilities, like getting more quotes on a repair, or even finding a new space. Plus, extra time makes it a lot easier to continue keeping the space running smoothly for members while dealing with financial issues, without burning out.

But spaces can save for more than just emergencies! Even nonprofit spaces can have investment savings and use interest and dividends to offset operating costs. It takes a long time to build these kinds of savings up, but once you have them, it’s that much easier to weather hard financial times, fund special programs, offer reduced dues for those in need, and so on. Many universities, for instance, use these kinds of funds, called endowments. Similarly, hackerspaces should be considering saving to buy their own buildings. I’m not aware of any that have done this, but owning rather than renting would lower monthly expenses for most spaces (even if they have to get a mortgage) and would prevent the common problem of landlords raising rent after a group has invested in repairs and improvements to their space.

Finally, hackerspaces are businesses. This is a controversial statement, but I believe that if the leaders of a hackerspace aren’t treating it like a business (keeping accurate books, financial planning, catching problems before they snowball, etc.) then they are doing a disservice to the members and setting themselves up to burn out. That said a hackerspace should not feel like a business to the members. Hackerspaces work best when members can come in and just hack, teach, and learn with a minimum of obstacles. In good hackerspaces, the administrators consistently remove those obstacles, and in great hackerspaces they do it before the members even notice them.

There is a lot of good common wisdom floating around on design patterns for hackerspaces and common traps to avoid. Now that so many hackerspaces are up and running, I’m hoping to see more attention turn to how to ways to keep them running, not just for 5 or 10 years, but for future generations.

Communication for Geeks

Here's an outline from my Penguicon 2013 panel "Communication for Geeks."

Sleep Hacks - Penguicon 2013

Here's an outline from my Penguicon 2013 panel "Sleep Hacking."

Seltzer CRM - Penguicon 2013

Here's an outline from my Penguicon 2013 panel "Seltzer CRM."

Voip, SMS, and MMS - Penguicon 2013

Here's an outline from my Penguicon 2013 panel "Voip, SMS, and MMS."

Tags: 

Pages