Not long ago, I had an interesting lunchtime discussion with Job Vranish. I don’t recall exactly how we got on the topic, but we were discussing how mesmerizing siphons are. As the discussion progressed to imagining a fluid-based computer (that’s another story…), I remembered something I had seen as a child at the Indianapolis Children’s museum: an immense clock that kept time with the flow of water through glass tubes.

Later I did some research into what I discovered is one of the largest water clocks ever made by the French physicist-turned-artist, Bernard Gitton.

Gitton’s water clock begins, as many clocks do, with a pendulum. This pendulum is attached to a small scoop into which a constant stream of water flows. As the pendulum swings, the scoops spills its contents into another vessel at regular intervals.

These “dollops” of water must then be transformed into the displayed minute and hour values along the sides of the clock.

First, the dollops drain from the collection vessel down a piece of glass tubing where they settle into the “trap” of an S-shaped siphon. The siphon is calibrated such that multiple dollops collect before the siphon triggers, suctioning the entirety of the contents down into the next component. These siphons are triggered when the fluid reaches the height of the top of the S-shaped curve and begins to be pulled downward by gravity. Once this process begins, the fluid continues to drain from the siphon until it is empty.

In the case of Gitton’s water clock, the fluid drains into a series of additional siphons, calibrated to hold increasing volumes of water before triggering. These siphons act as frequency dividers for the initial signal provided by the pendulum. (i.e. If a dollop comes every two seconds, and the first siphon can hold three dollops, then the first siphon will drain only every 6 seconds, the second siphon in the series may hold several of these larger dollops, dividing the frequency still more, and so forth.)

The last siphon in the series has a very interesting property – the low pressure created by draining of the vessel is “captured” by a sort of “vacuum locking” device that keeps the “vacuum” from “traveling” back up the input channel. Instead, the lower pressure is carried by another piece of tubing over to a vessel with a siphon on the brink of draining. (Just how this balance is calibrated is not clear to me.) When the “vacuum locked” siphon triggers and transfers this lower pressure to the other vessel, it triggers that siphon and drains the fluid into the minutes counter.

This minutes counter is column of stacked globes that contain the colored fluid. The height of the fluid in the column fills a number of the globes corresponding to the minutes past the hour. Alongside the column of minute-globes is another S-shaped siphon that triggers just before the hour, draining the entire column and triggering another vessel to drain into the hours column. This process takes several minutes, during which the observer has the distinct impression that time itself is being lost down the drain. The Greek idiom used to refer to water clocks is “Clepsydra”, which translates more literally to “water thief”. Gitton calls these clocks (of which there are several around the world), Time-Flow Clocks or “Horloges à voir le temps couler” (roughly translated: clocks for viewing the passing of time).

If you’re as fascinated by this device as I am, you can read more at this page, put together by David M. MacMillan, where you can find a much more detailed technical explanation along with a number of helpful diagrams. I also recommend watching the fantastic nine minute documentary, Bernard Gitton – Physics and Art, done by Michael Magee. Another explanation of the water clock, produced by The Children’s Museum of Indianapolis, can be viewed on YouTube. There are a few other videos on YouTube of these water clocks in operation, but most of them are not very clear. You can get a better sense of what is happening by watching this intricately animated illustration created by Roland Barth. Additionally, Gitton’s studio has a small webpage with contact information at www.bernard-gitton.com. (You may need to scroll sideways to reach the content in the frames on the Gitton site.)

What beautiful artifacts inspire you? If you have children, do you try to expose them to things that inspire? What feats of engineering are still impressed upon your memory from childhood?

I wanted to test the performance of the system to see how well it handled hundreds of items so I created a couple of hundred tasks, all of which happened to be ‘liaison’ type.

There was no problem with speed in getting them loaded up and displaying, and scrolling was fine.

Chrome, however, did have a problem with the page–it thought the page was in French and offered to translate it. I let it and all the occurrences of ‘liaison’ were replaced with ‘link’. Even though liaison is now a commonly-used English word (with Old French roots,) Chrome thought that with so many of them used it must be a French page. After all, who else but the French would have so many liaisons?

When I have a spare few minutes I might run some tests to find what the threshold is for the number of liaisons that tips Chrome into thinking that the page is French rather than English…

It turned out to be a simple fix–add a meta tag of <meta name="google" value="notranslate"/> to the page.

I’m filing this in my Amusing Bugs list–and also my “What test case would find that defect?” list. I did not expect to find a translation bug whilst running a performance test.

I recently did a rm -rf * on the wrong directory.

That’s how all good stories start, right?

You always hear about rm -rf * horror stories. You know what I’m talking about. Everyone laughs and jokes about such things. It’s very amusing, unless you have just mistakenly done it to data rather important to you. But you have backups, right?

There are countless utilities and scripts out there to “make rm safe”. A quick Google search turned up several — mostly written in Perl. Unfortunately, I’m not very fluent in Perl. While the safe removal tools written in Perl were functional, they did not meet my more specific desires, and I did not feel comfortable modifying them to make them do so.

So, I wrote my own little script in Bash. Basically, I wanted my script to detect (and stop) any attempt to delete important directories directly (e.g. rm -rf /boot), as well as through globbing (e.g. rm -rf *). This is an important distinction as doing rm -rf / is just as bad as doing rm -rf * in the root directory. (Not all of the safe removal tools prevent the latter).

Basically, my script checks if the arguments to rm are absolute paths to important directories, or if globbed arguments match a certain number of keywords for important directories. Additionally, it throws in a short delay before even running. In my experience, I’ve hit executed rm -rf * only to immediately realize my error and hit ^C (Ctrl + c). But, of course, this is never faster enough. The short pause should give me a fighting chance at catching the mistake. (Of course, this may be a slight hindrance if you are doing something which uses rm in an automated fashion, like ./configure && make && make install. If that’s the case, recommend you comment out the sleep command.)

#!/bin/bash
sleep 2
args=( $@ )
preserve_paths=( / /bin /boot /dev /etc /home /initrd /lib /proc /root /sbin /sys /usr /usr/bin /usr/include /usr/lib /usr/local /usr/local/bin /usr/local/include /usr/local/sbin /usr/local/share /usr/sbin /usr/share /usr/src /var /opt )
preserve_keywords=( bin boot dev etc home initrd lib proc root sbin sys usr include local share src opt var )
for path in "${preserve_paths[@]}"
  do
    for arg in "${args[@]}"
    do
      if [[ $arg = $path ]];
      then
        echo "I refuse to delete: $path"
        echo "It seems too important. If you want to do it anyway, use /bin/rm"
        exit 100
      fi
    done
done
counter=0
matches=()
for keyword in "${preserve_keywords[@]}"
  do 
    for arg in "${args[@]}"
    do
      if [[ $arg = $keyword ]];
      then
        counter=$(($counter + 1))
        matches=( ${matches[@]} $keyword )
      fi
      if [[ $counter -gt 1 ]];
      then
        echo "I refuse to delete: ${matches[@]}"
        echo "They seem too important. If you want to do it anyway, use /bin/rm"
        exit 100
      fi
  done
done
/bin/rm "$@"

As you can see, it’s a simple script. I’m sure there are more efficient ways to accomplish the same thing — but I was able to throw this together quickly, and be confident it would stop me from repeating my error.

I’ve quickly installed this on my local computer and several other servers that I access regularly. To install it, I simply place it in /usr/local/bin, and make it executable:

sudo mv safe-rm.sh /usr/local/bin/rm
sudo chmod +x /usr/local/bin/rm

On Saturday, May 19, Lane Halley of LUXr will teach a 1-day workshop on User Experience for Lean Startups. The event will be held right here at AO’s offices. User Experience is one of the most challenging and least understood aspects of creating a product…and yet it will make or break your product. During this workshop, Lane will teach you Lean Startup methods that help you make the right product, and make your product right.

Whether you are a designer, a programmer, a product manager, or just somebody with a great idea, this workshop will introduce you to tools and techniques that help you deliver an experience that really shines. To see more of what happens at this workshop, take a look at the Lane’s Ignite talk.

Lane Halley, program director of LUXr, is a good friend of Atomic Object. She is a product designer infused with entrepreneurial energy. As an agile coach and design consultant, Lane helps cross-functional teams understand their project domain, develop empathy with users, and engage in creative collaboration. She is delighted to bring the LUXr program to Grand Rapids and looks forward to meeting you soon!

Plan now to attend. Register Here…and use the discount code “AOFriend” for 10% off. Space is limited!

Once you have the main board, most of the other peripherals are cheap and readily available. It uses 5v micro-USB for power (from a spare cell phone charger), and SD cards for storage. They gave it both HDMI and RCA video output, so it could use the old TV in the attic as a display. It has a USB port for keyboards, mice, network adapters, and the like. (The “B” Pi, $10 more than the standard “A”, includes a second USB port and built-in ethernet.)

While it’s easy to gush about the technical stats, and it certainly has a lot of power for the price, that’s not why the Raspberry Pi excites me. There are many cool projects that never happened because the hardware to prototype them was too expensive to bother. $25 is reasonable for a spontaneous experiment, though, and that’s where much innovation happens.

An RP and a USB wireless adapter could easily run a jukebox or a monitoring device like a Twine; an RP and a spare monitor could be an information radiator for live web traffic or continuous integration, or a home arcade.

Like the Arduino, its GPIO pins can connect it to all kinds of electronic sensors, but it’s also powerful enough to host several web services that display their input. It could be the foundation for many home automation devices, and accessible over the internet. Also, it can be programmed in scripting languages like Python (after which it is named), Ruby, or Lua, making it very accessible for exploratory hacking.

The RPF is still catching up to heavy demand, but I’m eager to see what other projects come from such a versatile prototyping platform.

Carl has written about the good, the bad and the ugly of transparency, but he has always stood by his conviction that a culture of openness is essential to sustainable business success.

I believe in transparency as a philosophical basis from which to run a company. The resulting trust, loyalty, buy-in and contributions of your employees more than make up for the downsides. But there are indeed some downsides.

I regularly read Mark Henson’s newsletter. Some of his articles resonate more than others, but I’ve come to appreciate the clarity and truth shared in all of his writing, regardless of topic. Mark’s recent post lays out a perhaps counter-intuitive, yet spot-on perspective on the challenges of leadership and growth. He argues for transparency:

Leadership IS clueless

You see, we mistakenly think leadership means having all the answers. In fact, leadership actually means having NONE of the answers. It doesn’t mean they can’t figure out the answers, but leadership, by definition, involves actually leading people somewhere they’ve never been before.

People don’t need to be led somewhere they’ve already been. They need leaders to take them somewhere new — to battle a new enemy, to accomplish a new goal, to explore new territory. And there is typically no map for new territory. And if there is a map, it’s out of date the moment it is printed.

Being clueless is not a bad thing. Trying new approaches is not a bad thing. Exploring new territory is not a bad thing. Unless you don’t have the support of the people who work for you. Then it’s a horrible, horrible thing for everybody.

Read the whole post: Yes, Your Company’s Leadership Is Clueless.

So, just as we all want awareness, support and encouragement from our leaders, they need the same from us in equal share. Successful leaders are confident enough to chart the unknowns of new territory and humble enough to admit they may be clueless at times.

A company culture that fosters openness and transparency will grow leaders and teams with all the confidence they need to succeed together.

Bias isn’t always negative, but the focus of the research presented in this paper is bias of the decidedly unfair variety:

… we use the term bias to refer to computer systems that systematically and unfairly discriminate against certain individuals or groups of individuals in favor of others. A system discriminates unfairly if it denies an opportunity or a good or if it assigns an undesirable outcome to an individual or group of individuals on grounds that are unreasonable or inappropriate.

They outline three classifications for unfair bias in computer systems: Preexisting Bias, Technical Bias, and Emergent Bias.

Types of bias

Preexisting Bias

Bias that gets built into a software system because the organization determining the requirements for the software is biased. The software reflects their own bias.

Technical Bias

Technical bias emerges as a consequence of technical constraints or decisions. Limited space on a display, input devices, and specific algorithms can bias a system in one way or another.

Emergent Bias

Use of a software system changes over time. Through the addition of new users, new types or sources of data, or a myriad of other possibilities, bias can emerge in ways that would have been difficult, if not impossible, to predict when the system was built.

Bias spotting

Since reading their work I’ve been much more aware of bias in computer systems, and pretty much everywhere else. In this case, being aware of the problem is the first step to preventing bias in the systems you build.

The following two are non-software examples I spotted in the physical world. I’m not sure physical-world biases always fit in the classification system outlined in the paper, but they’re interesting to consider.

Apple’s release of WWDC tickets for 2012

Apple opened their ticket purchasing for WWDC at a time when people on the West Coast were less likely to be awake and able to purchase tickets. They sold out very quickly, leaving many West Coast residents crying foul because of the unfair bias against them.

Getting teeth cleaned at the dentist

I noticed that the rooms used for dental cleanings are set up for right-handed people. The room can’t be easily rearranged and I imagine a left-handed dental hygienist would be at a notable disadvantage.

What examples of bias have you noticed recently, in software or elsewhere?

CPU utilization is simply the ratio of time a processor spends doing real work over a given period of time. The time of measurement can be arbitrary. Ideally, it’s better to align your measurement time with the shortest deadline time in your project; it depends on the goals of the CPU utilization measurement. If you have to service a communication bus 10ms after receiving an input, and it takes 9ms to perform the necessary processing, then you may want to measure utilization over 10ms so that you can capture this 90% worst case, critical path. For the purpose of simplicity and illustration I will measure over 1s.

The first thing we are going to need is a reliable timing source. I recommend setting up a timer interrupt. I could explain how to, but luckily someone else already has here. In my example I chose to use timer 2 since timer 1 is used by the servo library and I might actually use that in the future.

The next step in setting up your project is defining what 0% utilization is. The most basic way of doing this is by incrementing a counter in your idle task (in this case loop()) and seeing how many idle counts occur during a measurement period. If no work is being done (besides the timer interrupt) then this represents the maximum number of idle counts and 0% utilization. One might argue that the act of calculating idle counts is work and that 0% utilization is not achievable with the instrumentation code in place. That’s true, but I think such concerns are negligible when the CPU utilization measurement period is sufficiently large.

Anyway, it’s important to note, here, that once you determine the maximum idle counts, no code can be added to the idle task. This would change the maximum idle counts. In general, I think the idle task should do essentially nothing. Where then can you get useful work done?

My example provides a very simple, round robin, periodic task scheduler. Here you can perform calculations as fast or as slow as required. It’s also noteworthy that I used the ISR only to notify tasks that they are ready to run. It’s good practice to keep ISR’s as fast as possible and to keep application code out in order to prevent problems with shared data.

To test my example I simply add a delay(50) to my 100ms task. This will run 10 times in one second. 10*50ms=500ms I should calculate 50% utilization and if I run the example I see that it does.

Feel free to use my template as you wish. I recommend moving any activity out of loop() and putting it into one of the task functions.

(There’s a strange history of opinions revolving around DI in Ruby, and they’re worth discussing… sometime soon.)

I’ve been having a hard time finding a good DI tool for Ruby. I’m ready to move forward from DIY and enjoy some of the great conveniences that tools like Guice provide, such as automatic instantiation of object trees based on constructor and type info. So I wrote Conject, and though it’s still young, it’s working and showing promise.

• gem install conject

ObjectContext

Conject’s power hinges on the usage of ObjectContexts: essentially, a home for objects keyed by name, which are accessed via #put, #get and convenient hash-like indexing via #[]. An ObjectContext may have another ObjectContext as a parent; a parent context will be consulted as a fall back if a requested object is not available in the child.

The interesting part is: when an object is not available in an ObjectContext (nor any of its ancestors), a new instance of the requested object will be created, cached and returned. Any dependencies the object declares will be fulfilled at creation time (before #initialize is called) by recursively searching for the required objects within the ObjectContext itself, or in ancestor contexts as needed.

Declare dependencies with .construct_with

Classes may declare their need for collaborators by enumerating them by name, using .construct_with.

class Car
  construct_with :chassis, :engine, :highway
end

car = Conject.default_object_context[:car]

In this example, the default object context will create a new instance of Car, store it with the key :car. A :chassis and :engine will also be created and stored as needed. (Note: objects are cached by default within an ObjectContext; they are “singletons” within their context and repeated reference to a named object via #get, #[], or from .construct_with will return the same instance.)

.construct_with does three things of importance:

• It formally declares that any instance of the decorated class must be built with a certain set of named objects
• It provides a pre-constructor that will accept the required components (in the form of a HashMap)
• It defines private reader methods for each component. In the above example, #chassis and #engine now exist as private methods within the Car class.

If you’re referring to classes who are namespaced beneath a module, eg, Graphics::ChartComponent, your dependency declaration should assume the name for such an object would be "graphics/chart_component", and the internal reader method would be #chart_component. (.construct_with will treat strings and symbols equally.) The next release of Conject should support classes that are themselves in a module refering to companion classes within that same module without having to include the object name prefix and slash characters.

Configuring objects

For many cases, using .construct_with (and retrieving top-level objects from the ObjectContext) will be all you need to do to get your objects talking.

For others, you may occasionally need to do special configuration. The options for configuration are still under development, but so far you can:

# Disable caching for specific objects:
my_context.configure_object engine: {cache: false}

# Custom object construction via proc or lambda:
my_context.configure_object chassis: {construct: lambda do "The Chassis" end}

Subcontexts

Some designs call for the creation of microcosms of objects, which desire to refer to instances by name, and have those references be shared amongst multiple collaborators in the same context, even though many copies of this microcosm may coexist in the system. An example of this would be a Model-View-Presenter triad for an on-screen widget:

class ChartPresenter
  construct_with :chart_model, :chart_view
end

main_context.in_subcontext do |sub|
  sub[:chart_model]
end 

Subcontexts have implicit access to ancestral objects. If an object constructued within a subcontext refers to an object that already exists in an ancestor, the existing object will be provided. For example, if you’re building Cars in a subcontext, you could provide a Highway in the supercontext that all Cars would share a reference to.

Using your context directly

When an object needs explicit access to its owning ObjectContext, it can be constructed with this_object_context. One obvious use for this is writing code that needs to generate subcontexts in reaction to some command or event.

class Galaxy
  construct_with :this_object_context
  def spawn_new_solar_system
    this_object_context.in_subcontext do |subcontext|
      subcontext[:sun].genesis
    end
  end
end

Notable TODOs

• Implied modules for classes namespaced beneath the same module
• Explicit Rails support
• Auto-requiring…?
• Make it convenient for objects within a Module namespace to refer to each other without specifying the module name each and every time.

Studying potential users of the app we’re creating is an important part of the project. The research being done is a clear example of IDEO’s “start with people”, design thinking process, as described by Tom Kelley at a recent Design West Michigan meeting. At our project kickoff, I had one of those delightful moments of finding my intuition entirely at odds with what was being presented, when our IDEO colleagues described how they selected research subjects.

If you drew a distribution of people’s behavior (or expertise or passion or knowledge in the domain you’re studying), you might find it looks like the curve below. It doesn’t matter whether this distribution is actually Gaussian or not—I doubt anyone actually knows, and it probably varies by domain. The point I’m describing doesn’t depend on the specific distribution.

The question is, where should the people you select for research lie on this distribution?

The answer which seems obvious to me is you would want typical users, or the ones that clump up around the middle of the distribution. After all, for a broad, consumer-facing app these people represent most of your potential users. You may never have budget to build features for the “outliers”. Your business success depends on delighting the majority of people. So of course, to understand the problem and design the best app, you should concentrate your research on the middle of the distribution. Makes sense to me.

What the IDEO researcher surprised me with is the sketch below showing how they look instead to the extremes of the user population:

The point our colleague made is that since research is all about learning, a very fast and efficient way to learn is by studying the extremes. The issues that are relevant to all users are most clearly visible in the extremes of the population. In the great middle the “signals” you’re looking for will be a lot less obvious and buried in more “noise”. By closely observing the extremes of the community you learn more quickly what’s relevant to everybody, and hence to the application you’re building. Counter-intuitive, but it made a lot of sense once I heard it.

Here’s how this approach might work for Kidtelligent, a web app we built last year. The users of Kidtelligent are parents of 7-10 year olds. The app helps parents, mostly mothers, understand their kid’s personalities and gives practical advice on how to help them succeed in relationships, school, sports, etc. If the dimension of consideration for researching moms was “familiarity with behavior profiles and web tools”, then going to the extremes would mean finding moms who had never heard about such profiles and seldom used computers, on one end of the spectrum, and moms who were clinical psychologists and expert computer users, on the other.

What would we learn from each group? I wish I could say. We didn’t use this technique on that project. Maybe, from the naive group, we would have learned more quickly the issues moms worry most about for their kids, independent of the behavior assessment. Maybe, from the expert group, we’d learn the most valuable measures to provide in the report (which did they put the most emphasis on, given their expertise?) In any case, by studying the extremes, we might have learned more quickly. The important issues might have been surfaced more distinctly compared to observing average moms who were typical computer users somewhat familiar with behavior profiles.