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(&, &, ) { ... }

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(&, &, ) { ... }

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(&) { ... }

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(, ) { ... }
function hook_invoke_all() { ... }

Then our code to implement the hook looks like this:

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

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: 

Laser Cutter Kerf Gauge

While I was in Michigan over the past week, I got to play with i3 Detroit's new laser cutter (affectionately known as "Bumblebee"). When my friend Roger showed me how to use it, he mentioned that the laser cuts away part of the material, so the finished part will be slightly smaller than it is in the file. This lost material is called the "kerf" of the laser. To complicate matters, the size of the kerf depends on the material being used, and the power settings of the laser. So I thought there would be no better way to acquaint myself with Bumblebee than to measure its kerf.

The most obvious way to measure the kerf is to cut a slot and measure it with a thickness gauge, but we didn't have one. I found a few tutorials online for other ways to measure the kerf. This post on the adafruit blog shows how to measure the kerf by averaging over 10 cuts for greater precision, but still requires a thickness gauge. This instructable shows how to create a 1 inch square test piece that measures the kerf of a single cut with a thickness gauge or caliper. Then I came across another method that let's you measure the kerf without any gauges! I decided to find a way to get the best of both worlds: measuring the kerf over an average of several cuts, without needing a thickness gauge or caliper.

The result was this Kerf Taper Gauge. You simply cut the pattern with your desired material and settings, and drop the gauge through the hole in the tab. When the tapered gauge fits snugly, the taper of the gauge exactly compensates for the kerf, and you can read it off the label on the gauge. The measurement is averaged over 4 cuts: each side of the gauge and each side of the hole.

Next step: find a good way to correct for the kerf...

(Photo credit: Eric Merrill)

Tags: 

On Hackerspaces and Inclusion

TL;DR: Inclusion and diversity need to become core hackerspace values. When our spaces lack diversity, we should accept responsibility and take action, not make excuses. A little effort can go a long way.

Everyone running a hackerspace should be thinking about inclusion. There are a few interrelated issues that I keep seeing come up in the hacker/maker/DIY community, and I feel obligated to help give them some of the attention they deserve. Some spaces are doing a really great job at fostering inclusion and diversity, but these values are not yet widely accepted as part of hackerspace culture, and they need to be.

We should care about diversity. All too often, when I talk to members of the hackerspace community about diversity, I'm asked why it matters, or even told outright that encouraging diversity isn't worth the effort. In defense of my fellow hackers, they are also usually quite open to reconsidering their position when presented with good reasons. The reasons fall into two categories: practical, and idealogical.

The practical importance of diversity is simple. Hackerspaces are made of people, and the more awesome people you include, the more awesome your space will be. Diversity doesn't mean, as some might think, lowering the bar for members. It means not pushing away potentially valuable members for silly reasons. It means including everyone who has something to contribute, especially if it's different from what current members are contributing. It means opening up spaces to new socioeconomic groups who will tell you how to make your space relevant to a wider audience, and as a result more stable and sustainable.

But for me, the idealogical importance of diversity is even stronger. The hackerspace movement is about removing artificial technological barriers and using self-education and peer-education to reclaim the ability to make our world. If we leave people out for no reason other than their gender, skin-color, income, etc. then we are the ones placing artificial barriers and hoarding knowledge for our personal and selfish gain. Then we are hypocrites, and doomed to sabotage our ideals.

We have to accept responsibility and promote diversity and inclusion. Another common belief in the hackerspace community is that if we aren't actively discriminating against or excluding people, then there's no problem. But building an inclusive community takes more than that. Demographics are naturally self-reinforcing. Word-of-mouth travels through our social networks, made of people who are likely to share our demographics. When we teach workshops or hold events that are relevant to us, they are most likely to be relevant to an audience who shares our demographic. And there's nothing wrong with that, as long as we acknowledge and correct for it. When you're new to a group it's easy to feel like an outsider, especially if you perceive yourself as somehow different from the group's majority demographic. On top of that, members sometimes unknowingly say or do things that push people away because, through no fault of their own, they've never had to consider different perspectives.

A common response to the gender imbalance in hackerspaces is "Women aren't interested in what we do here." But on closer inspection this is just the "No True Scotsman" fallacy. In effect, it says "We [men] are True Hackers. If you are interested in something we are not interested in, you are not a true hacker and don't belong." To illustrate this point, ask yourself whether a clothes modding workshop or a Starcraft LAN party is more in line with the mission of a typical hackerspace. Then ask yourself which is likely to be better received.

The bottom line of resistance to making a hackerspace more inclusive is often "We don't want to change anything, we like things the way they are." That's a perfectly natural human response, but if it dominates your thinking, you don't have a hackerspace, you have a country club with Arduinos.

What we can do. Luckily, being inclusive is actually not that hard! At i3 Detroit, where I was a co-founder and board member for several years, inclusion was always one of my priorities, and I got a good sense of what works and what doesn't.

Just being actively welcoming to newcomers goes a long way. It doesn't need to be anything complicated, just saying hi, introducing yourself, and asking if they have any questions or if they'd like a tour. Sometimes that's a distraction to members who are in the middle of a project, but specifying best times for newcomers to visit, and a standard onboarding process can make it a lot easier. This is one reason I've never liked the idea of new members requiring a sponsor. Instead I like the idea of accepting anyone who shows interest and offering them a mentor to help integrate them into the group.

It's also crucial to create a safe and welcoming environment. That means having a sensible code of conduct and/or harassment policy. The policy should make it clear that if you're uncomfortable it's ok to voice your concern, and that someone trustworthy will listen, without judgment, and work to restore a safe environment.

Another key is being open-minded about what activities fit into your hackerspace's mission. If you give people the benefit of the doubt, you allow your space to grow beyond what you can currently imagine, and encourage people to push limits and take ownership in the space.

Finally, having a way to include students and other low-income members is important. A guest policy is one way to do that. Tiered memberships are another. A lot of spaces have "starving hacker" rates. At i3, we have two membership levels that are effectively the same, but a good number of people choose to step up to the higher level when they're able. Offering "scholarships" or no-fee memberships for those in financial need can also help. Even if they don't have a lot of money to spend on materials, those members may have awesome skills to share, and may be valuable contributors to group projects. And of course, members often grow through their involvement in hackerspaces. At i3, we had a "founding guest" who helped build the space even though he couldn't afford membership. Four years later, he's now a director and dues-paying member.

The hardest part of inclusivity is realizing that we can't see what's missing, that we have to actively seek it out. The rest is not that hard at all. Once we do that, our spaces benefit from a broader and more diverse membership, and more ties to the community. Some spaces are great at inclusivity, but as a community we still have a ways to go.

If you're part of a hackerspace, is this something your space talks about? What types of things do you do to foster inclusion and diversity? What works? What doesn't?

Mind Flame: Maker Faire Detroit 2012

For Maker Faire Detroit this year, I collaborated with Matt Oehrlein to build MindFlame, a mind-controlled flame effect game.

MindFlame uses commercial EEG headsets from NeuroSky to read the brain waves of two contestants. The signal is sent to an arduino, which can determine (more or less) how hard the contestants are focusing. When a contestant focuses hard enough, the arduino activates a solenoid, releasing a burst of propane past a glowfly ignitor, causing a giant burst of flame. The goal was to be the first person to get to four bursts of flame.

This project was tons of fun, and collaborating with Matt was great because we had twice as much time and resources to throw at the project, and I think the end result was much more impressive than we could have done individually. Plus, controlling fire with your mind is just awesome. Josh “Bacon” McAninch (from the Gon KiRin project) helped us with the flame effects, and Maddy "Brodi3" Winans helped us design and decorate the apparatus.

(Photo by Doyle S. Huge)

Pages