Categories on Binary Redneck

Stabproof Coffee

Mon, 14 Dec 2020 11:50:46 -0500

Shared by popular request. Enjoy!

Stabproof Coffee Recipe

A hot, low-carb mocha (chocolate & coffee) flavored protein shake named for an office joke from years ago.

I use Isopure Dutch Chocolate Low Carb protein powder: https://amzn.to/2VrTmWr

Half-and-half, whole milk, or almond milk can be substituted for the heavy cream in this recipe in descending order of calories and feeling of fullness. Experiment!

Ingredients:

Heavy Cream 4 tablespoons (¹⁄₄ cup, or about 45-58g depending on hydration)
Protein Powder (see above) 1 scoop (33g)
Coffee Black American Coffee: about 10 fl. oz. or Espresso: 1 shot, plus enough hot water to make up the rest of your mug or bottle’s volume
Whipped Cream To taste, if you’re feeling fancy today.

N.B. It’s important that the protein powder and coffee don’t spend time together before the cream base soaks in, or else you’ll get disgusting cooked-acidified-whey-powder-lumps. So, here are different directions for mug prep vs. in a shaker bottle.

Directions - Mug:

Start coffee/water heating.
Put cream in bottom of mug, followed by protein powder. Stir until thoroughly blended (there shouldn’t be any dry lumps of protein powder left).
Add your shot of espresso or first couple ounces of drip coffee and blend thoroughly until no or very few, small lumps remain. Don’t forget to scrape the sides of the mug as you go.
Add remainder of drip coffee or hot water (if you started with espresso), stir to incorporate.
Top with whipped cream, if desired.

Approx 259 kcal, 3g carbs (2g net carbs), 17g fat, 25g protein in default recipe with heavy cream and no whipped cream topping.

Directions - Shaker Bottle

Start coffee/water heating.
Place protein powder in bottom of shaker bottle, and layer heavy cream on top.
Add either your drip coffee, or a shot of espresso plus hot water, on top of the existing ingredients.
Close bottle tightly and shake vigorously: the faster you blend the ingredients after beginning to add coffee, the fewer lumps you will have.
Top with whipped cream, if desired.

Approx 259 kcal, 3g carbs (2g net carbs), 17g fat, 25g protein in default recipe with heavy cream and no whipped cream topping.

These keep me very full, but I also realize that I eat less than most people. You can double the protein and cream pretty easily if you prefer. Or, ask me about the giant iced chocolate shakes I did when I was weightlifting. :)

About BinaryRedneck.net

Sat, 26 Oct 2019 00:39:00 -0400

Welcome to yet another mildly neglected blog by a hacker. I’m your host, Susan E. Sons, sometimes called HedgeMage.

This is my personal blog…the content can be random and sporadic, just as my interests are. If you’re looking for something more professional, head over to https://security.engineering

I can be contacted at hedgemage -at- binaryredneck -dot-net-.

Testing Hugo

Fri, 25 Oct 2019 18:16:10 -0400

Tonight, I began playing with Hugo, a static site generator in Go. I’ve been a big fan of static site generators for some time, due to the incredible freedom of just not maintaining a CMS before, especially for simple content. I’ve long needed to move from Ghost, which is great for its target audience, but too WYSIWYG and clicky for my engineer brain.

So far, so good. Hugo is much faster to compile and has a much bigger and more varied theme ecosystem than Nikola, the static site generator I’d worked with previously. I’m still putting my new deployment workflow through its paces with the intention of getting myself set up to post not just from a real computer but from my tablet as well.

Wish me luck!

DNS, Blocklists, and Fault Tolerance

Fri, 15 Dec 2017 22:39:00 +0000

My workplace hosts weekly “brown bag” discussions, wherin much of the team and various guests bring our lunches to our larger conference room, or an HTML5 videoconference bridge, and discuss some information security topic over a meal. It’s an informal affair; my stuffed animals may even appear on camera in my stead if I’m under the weather as I was today.

This week’s topic was the Quad9 filtered DNS service. The slides I used to kick off the discussion are publicly available, with some edits/additions in orange following the discussion. They give a brief introduction to why we have DNS, Quad9’s promise, and some dangers that some of my colleagues and I identified should Quad9 become the ubiquitous DNS service. However, I wanted to capture more of the discussion than slides easily lend themselves to, so below are some of my notes.

Notes

Lots of questions around centralizing DNS to one provider.
- It took 8.8.8.8 some time to sort out resilience, and they have all of Google’s resources behind them.
- The DynDNS DDoS was a huge disruption to the internet at large, and they are fairly robust. However, this was in part because so many authoritative nameservers as well as a popular resolving name service were centralized in one place.
- Why aren’t the same concerns raised about 8.8.8.8? Answer: because 8.8.8.8 can be used with other providers as failover sources for DNS. In order to receive any protection from Quad9, one must only use Quad9’s DNS and no failover provider.
Main reaction to Quad9’s failure modes were “well, it’s better than nothing”.
Sustainability is a big concern: encouraging these sorts of system-level changes for naive end-users is dangerous if the service may evaporate.
I was surprised that the differences in Quad9 response speed for already-cached entries vs. not-cached entries didn’t bother more people.
- I see this as an effective hellban on niche websites.
- Others felt that only power users visit anything other than very mainstream websites anyway, and we understand DNS or don’t expect reasonable performance from new startups and small operations.
The transparency issues didn’t seem important to most of the group. I did feel better once I was told that there was, in fact, a search mechanism to find out if one had been banned (but not why) and request removal. I missed it the first time due to an overzealous blocking mechanism in my browser that thought it was malicious, ironically. I, personally, would want to know a lot more about how Quad9 determined a site to be a malware source, malware command and control, or other bad actor, before recommending it. They have promised no content-based censorship, however, there are many grey areas here (such as sites doing legitimate malware research or discussing the topic of malware, IRC networks which inevitably see botnet activity from time to time) which they may not have considered.
One person did point out that it’s an open question as to where Quad9’s operators would have learned how to responsibly operate a blocklist. The three rules I laid out in my slides are widely accepted and easy to learn, but I can’t say they are published anywhere in a traditional sense. Blocklist operation, because of the risks involved, has always been a niche activity and a bit of black magic as viewed from the outside. You’d have to engage with a blocklist operator’s group, NANOG, or have experience consuming DNSBLs in some context to know what to do. I don’t think this is too much to ask, but others felt it sounded too much like “join our secret cabal or else!” and I get how it can seem that way from the outside.
I learned that some end-user security suites typically run by Windows users already attempt egress filtering to cut down on malware issues.

My thoughts afterward

I wish I’d done a better job explaining the failover issue. I’d made a point of explaining how and why failover is not possible with Quad9, but perhaps people aren’t aware that normal operation is that DNS fails over if your server doesn’t give you a useful response: that is, when the first one doesn’t work, it tries another, then another. We seemed to go in circles where people kept asking me why I thought Quad9 was categorically more likely to have outages than any other DNS provider, when that wasn’t my issue at all. My issue was that with any other DNS provider, an outage is handled by a failover service. With Quad9, an outage is an outage.
I’m still concerned about the lack of transparency on Quad9’s part, but I feel that I’ve been too harsh on them in this regard. They’ve made some effort to give people hope that de-listing can work, and it’s possible that no one ever introduced them to DNSBL best practices.
The discussion we had ended up being pretty slanted, because it was inspired by an email thread about a post (brown bags are often us going off on tangents after things like that) in which someone suggested that we advise people and organizations very broadly to use Quad9 as their DNS resolver. Many of the centralization issues are mitigated if it becomes just one-of-many providers, and especially if organizations with central IT managing their DNS use an unfiltered provider combined with egress filtering instead.
The question came up as people were leaving that if we’ve been having an argument about whether it’s a good idea for everyone to move to Quad9, would a saner question be (paraphrasing) “if we presume that DNS is a good place to filter some malicious activity, what solutions are best for what use cases?”
- This is a much better question!
- I feel like we could put together some sort of checklist for this:
  - If you are a nontechnical user who tends to stick to the mainstream internet and you aren’t in an organization with centralized IT management, and you can tolerate rare multi-hour internet outages, Quad9 would be a good match for you.
  - If you are inside an organization with centralized IT management, they should be doing egress filtering on your behalf.
  - If you are on your own, but non-technical, and just can’t tolerate potential outages or not being able to get to sites that were erroneously or overzealously blocked, then depending on your tolerance for failure modes vs. setting up your own router, you might choose between a newer SOHO router with egress filtering that’s managed for you and an antivirus suite that includes client-side egress filtering. The latter may be preferable if you are on a laptop and use a lot of public networks.
  - If you fall into the maybe up to 1% of people who are journalists or journalist cohorts, who are technical researchers (especially in areas around information security), have extremely high uptime needs, or have especially censorship-sensitive usage patterns… then you may just have to pick up some technical expertise, because there isn’t a set-it-and-forget-it option at that point.
  - The above is just me riffing off the top of my head, though…there are very likely bits that I haven’t thought of in these few minutes.
  - I’d also like to ask how heavily we should rely on DNS blocklisting as malware protection. It is a very circumventable defense, so while it can be one line of defense, I’m wary of getting too excited about it. I wonder if the success and usefulness of DNSBLs for e.g. spam mitigation have led to overconfidence in how well they can work for something as general as disrupting malware across the board.

I love our brown bags because it’s a casual chance to toss ideas around and hash them out. Malware is an interesting subject in general because it so often targets our end users, whom we should be here to protect, but who end up in a position of being blamed for something that is way out of scope for their level of knowledge and responsibility. That’s something I’m glad to say we did not have in this conversation at all.

Gifts of All Kinds

Sat, 30 Sep 2017 13:00:00 +0000

One of my mentees recently left me with a very special gift: a copy of Donald Knuth’s The Art of Computer Programming, Vols 1-4a.

Besides being a staple of the computer science community, these books have a special meaning for me personally. They remind me of another, even more priceless, gift: the support of adults in my young life, especially my parents, even when they didn’t understand me. I grew up in the last place one might expect a software engineer or information security professional to come from: the remains of an old farming community on Chicago’s south side, surrounded by some rougher neighborhoods. I was just a little farm girl who liked to read a lot.

I liked to read so much, in fact, that I’d read literally our entire library by the time I was 11 or so, even the things I had no interest in. Our reference librarian diligently helped to get me more books, especially tech books, through Cook County’s Inter-Library Loan (ILL) system. This was a harder task than you might imagine, despite the fact that the ILL was an agreement designed exactly for this purpose: so that patrons of any library in our county could borrow books from the collection of any other.

Sometimes ILL requests went smoothly, and sometimes they did not. Our tiny library was shared by Ford Heights, a multigenerational welfare community with gang problems and appalling literacy numbers, Glenwood, and Lynwood, a small farming town then not yet hit by urban sprawl, where many adults in my father’s generation left school early to work. Requests for technical books from us were often met with surprise and even refusal. One librarian asked ours, “can anyone there even read?”.

I don’t think our librarian understood why a 12-year-old girl wanted to read a three-volume¹ treatise on algorithms. I’m not sure if anyone in town besides myself really knew what an algorithm was or why there were so many of them. However, our wonderful reference librarian was incredibly indignant that anyone, anywhere would deny a child a book that the child was not just volunteering, but excited to read. After months of persistance, some library in the city coughed up a copy, with one horrible restriction: I couldn’t take it home. The books must be kept in my library during the loan period and only read there.

I can’t say that computers were my mother’s bag, either. All she knew was that there had been a long argument over whether or not these expensive computer books would be loaned to our library for me or not. Mom is an elementary school teacher, and if there’s one thing she believes in, it’s reading. Luckily, when the books arrived, we were on summer break. Every day for three weeks, she helped me pack a lunch and dropped me off at the library to study those books, then picked me up again. She let me chatter about them, even though I don’t think she entirely followed. I drank in as much as a 7th grader possibly could in three weeks (which was far from the entire contents), and back they went. No extension permitted.

I learned quite a bit that summer about searching and sorting. I started thinking about data in terms of the operations I would want to perform on it later. However, that wasn’t the important part in the long run. The biggest pay-off was that I learned, again, that my goals and choices mattered. I understood, then, that not all families treated their children this way. However, I also understood how common it was for parents to be so far lost into mental illness, substance addiction, and other dysfunctions that they couldn’t be bothered to feed their kids. I chalked the two up to the same kinds of lives.

It was only after I reached adulthood that I realized there are plenty of families in the apparently functional band, where feeding the kids happens, and school happens, adults have jobs and nobody’s being abused, yet children are only supported so long as their aspirations are things that their parents can identify with. This seems to be more common, on the whole, than either extreme.

I could lecture for a page or two on the psychological underpinnings of this: on tribalism, on parents’ fearing for their kids’ futures, on parenthood and identity, but that doesn’t matter so much to me, even though it’s all quite true. Humans are special animals: we don’t have to operate on instinct and emotion alone. We can use reason to make ourselves better.

Most people getting ready to have kids seem to fantasize about how their son or daughter might follow in their footsteps, or achieve things the parent dreamed of but never grasped. I’ve certainly learned important things from my parents, and they wanted the best for me. Thankfully, they didn’t spend a lot of time defining what “the best” was. They let me figure it out. When I wanted to be an astronaut, my dad stayed up to watch all the news reports about the international space station with me, and got out his aged drafting tools and some big paper to help me design my own for a contest I never won. When I wanted to be a writer, my mom dutifully read and copy-edited piles of fiction that never saw the light of day.

It may sound like a waste to some parents: I’ve found that a lot of people either expect youth to be frittered away and people to “find themselves” and their purpose magically in their 20s, having no real experience of work. Others expect young people to have laser-beam focus nearly from birth.

Today, I do cybersecurity focused on cutting-edge R&D. Trying to think my way around space station design as a child probably had something to do with how well I tackle the concerns of giant telescopes and oceanic drones today. All those years of “pointless” fiction writing likely lead to the work as a ghostwriter that partially paid my way through high school, and the technical writing success I’ve enjoyed in adulthood.

When I had my own child, I waited excitedly to find out what person he would be. I didn’t plan for a mini-me, or even demand that he be someone I easily understand. My parents taught me that.

Kids decide who to be…if you fight them on it, you just cause damage. If you support them, and give them the guidance to do whatever it is with a decent work ethic, skill, and ethics…you’ve given them an incredible gift.

Some of the saddest adults I know were kids from good families who did what was expected of them, and never considered that they had the option to do the things they were passionate about that didn’t fit those expectations.

The cool thing is that you don’t even have to be a parent to be a supportive presence in a kid’s life. I posted this thinking of my mom, but that librarian whose name I can’t quite remember fought some battles for me, too.

Volume 4a wasn’t published until I was much older. ^[return]

Just a thought...

Sat, 12 Aug 2017 01:27:12 +0000

Someone on IRC tonight told me that he thought he was incapable of self-improvement.

I pointed out that humans are born small and squishy, happily pooping on ourselves, unable to use words or spoons…

If you are reading this, you have already improved yourself.

So get over it, and decide what’s next.

My New "Toy"

Mon, 07 Aug 2017 22:56:51 +0000

I’m a fan of going analog whenever I can manage. Fountain pens and paper are a great way to focus, and to stay organized without waiting on apps or relying on batteries. I’ve used and iterated on my trusty Bullet Journal for some time now. However, as I’ve gotten busier I’ve started missing the pre-printed calendars from when I used to use more structured planners. Not willing to give up the freedom of big note taking spreads and rapid logging, I set out to find a hybrid solution.

Now I can have my cake and eat it, too with a leather cover that holds both my Leuchtturm1917 harcover A5 Bullet Journal and a softcover A5 notebook of my choice. Right now there’s a navy blue Moleskine notebook in there, but I plan to replace it with a softcover calendar.

Where did I find such a thing, you might ask? I couldn’t. I perused Amazon and Etsy, checked some local shops, and to no avail. So, not to be deterred (and with my saddle stitching skills firmly rusted to uselessness), I looked for someone who would take a custom order. D&M Leather Studio, selling through Amazon, had something close to what I wanted in their store. I found their customer service rep very helpful as we talked about my desired modifications, namely:

sizing the inside pocket to accommodate a second notebook
changing the snap closure to a leather tie (this is quieter, so I won’t feel like I’m bothering people when I open and close my notebook in a meeting, library, or coffee shop)
Making the pen loop larger, to accommodate my penchant for chunky fountain pens (TWSBI Eco pictured)

I was like a kid at Christmas waiting for the final product to arrive from China, but it came today¹! The quality is excellent. Were I to do it again, the only changes I would make would be to ask that the outside corners be rounded (I may do that myself as an aftermarket mod) and to widen the leather strap closure just a bit.

The wait was two days longer than planned due to a mistake by DHL, the shipping company. D&M did a great job of resolving this. ^[return]

How To Have a Meeting

Mon, 07 Aug 2017 21:07:27 +0000

I hate meetings. I hate anything that asks me to step away from my work for overhead tasks. However, meetings are useful and necessary if you want a group of people to act in a coordinated fashion. I’ve been working recently with a group that includes several people new to the professional world, some of whom are struggling with how to have a meeting like a professional. It occurred to me that while there’s been a lot of writing on meetings, I didn’t have a succinct checklist to point folks to… until now.

Qualities Of a Good Meeting

You know you’ve had a good meeting if it:

Makes efficient use of all participants’ time.
Communicates information clearly, in a way that invites clarification and corrects miscommunication before they can become a problem.
Acts as a “forcing factor”, an event that spurs people to action before they have to report on their inaction.
Results in clear, actionable decisions.

Meetings that waste people’s time or don’t accomplish anything don’t deserve those people’s time or attention.

How To Have a Good Meeting

Respect Everyone’s Time.

Be on time to the meeting: everyone waiting for you is wasting their time.
Be prepared when the meeting begins. You should never discover a teleconferencing problem, rifle around to find note-taking tools, or take your first look at the agenda after the meeting begins.
End the meeting on time. Failing to do so can wreak havoc on others’ schedules, causing them to miss other commitments.
Don’t have more meeting than you need. Scheduling meetings for one hour blocks seems to be the default, but that is usually a bad choice. Consider:
- If the meeting is well-run and of a small scope, it can probably be done in 25 minutes.
- A one-hour meeting can, at worst, usually be trimmed to 50 or 55 minutes in order to allow all participants time to get to their next meeting.
- Don’t encourage people to “fill the whole time slot” in order to appear busy. If the meeting ends 4 minutes or even 45 minutes early, thank everyone for their efficiency and release them to get back to their “real” work.
Make the schedule clear. Use calendaring software, if possible, or failing that an easily referenced meeting list to make sure that everyone knows upcoming meeting dates and times, and receives notices of cancellations or changes.

Make it easy for all to prepare for the meeting.

Both the notes from the previous meeting and the written agenda for the coming meeting should be made available at least one business day in advance of the coming meeting.
The written agenda should be organized by topic, not by the person reporting, though the person reporting on each subject, or leading discussion on it, should be noted.
The written agenda should include (by reference or attachment) any related materials for discussions to be held.

Two models for effective meeting notes:

Option A: Have a designated person present to take notes, who is not part of the proceeding, and who will distribute notes to all attendees after.
Option B: Use a collaborative editor, such as Google Docs, to take notes as a group in a location that all can reference.

Have a written agenda beforehand, and stick to it.

You may want to open up the floor for about a minute at the start of a meeting to allow additions for something last-minute, but once the agenda is set, anything not listed will be deferred for discussion at a later time.
Forcing adherence to an agenda is the best way to get the meeting to end on time.
One person should chair (run) the meeting. It is up to this person to keep discussion moving, prevent tangents, and keep to the agenda.
The chair (with help from all participants) should ensure that any decisions to be made in the meeting actually happen.
The person(s) taking notes should ensure that all action items are included, and that action items from the current meeting make it to the next as “old business” so that they can be reported on (if needed) or confirmed done.

Do your part as a participant.

Before the meeting: Add any items you wish to discuss to the agenda. Review the agenda and any attached materials.
The day of the meeting: Show up on time, with working equipment (note-taking gear, your teleconference set-up, etc.), and prepared to discuss the items on the agenda. Be prepared to take notes for yourself or as part of a group note-taking document. Pay attention so others don’t have to wait on you.
After the meeting: Review the meeting notes and make sure that you have added any action items that resulted from the meeting to your to-do list, then do them.

Why I Care

I’ve been told that I’m very un-hacker-ish about meetings. By my observation, the usual hacker behavior is to whine about meetings, show up late and/or unprepared, and waste lots of other people’s time with interruptions, distractions, and meandering monologues or debates that cause the meeting to run longer than scheduled. I’ve even seen one such person play video games in the middle of a meeting. So, I’ll take that particular charge as a compliment.

I don’t grok why so many hackers not only behave like this, but aren’t embarrassed by their total lack of professionalism.

Meetings are going to happen. Doing them properly means that we get less bikeshedding and more action, and that everyone gets to spend less time on meetings. My record for one-hour meetings is getting everyone out of the door in 21 minutes (per meeting average for a three-month span in which I tracked it).

A Hacker's Guide Getting Ahead

Mon, 07 Aug 2017 00:00:00 +0000

This page serves as a living index of things a hacker could use to raise their effectiveness in the general sense. These are the bits of professional development that are often glossed over or skipped in the learning paths of technical people. I often refer my mentees to these resources, and have most of the books in my personal library available for loan to friends, colleagues, and Newguardians.

Time Management and General Organization

Resources in this section are focused on at least one of the three pillars of general productivity: finding more time in which to do work, fitting more work into the same amount of time, or doing more impactful work.

Getting Things Done, a book by David Allen, is the place to start for managing your most precious resource: time. It’s not just some rigid tracking system: Allen describes the principles of time management, such as how much you gain by not wasting your mental RAM remembering things, instead entrusting all those “things to remember” to a system (paper, electronic, whatever) that will remember them for you.
Bullet Journal is an organization system by Ryder Carroll that he gives away for free on the web site. Instead of requiring special equipment or software, Bullet Journaling can be done in any notebook you like. It’s meant to be simple, fast, and unobtrusive while getting things out of your mental RAM into proper storage so you can focus on your real work rather than remembering.
The Sketchnote Handbook is for people who don’t take notes because they are “too visual” or because filling a blank page with words isn’t intuitive or effective for them. It’s a visual person’s take on note taking.
The Seven Habits of Highly Effective People by Stephen Covey is a classic early read on how to be more effective, balancing very accessible advice on moving from task-only thinking to top-down and bottom-up thinking with useful time management tips.
org-mode is a powerful organizational tool as an Emacs major mode. It can do outlining, agendas, and more. Org-mode files are stored as simply marked up plain text, so they can be read anywhere even when org-mode is not available, and can be outputted in a stunning array of formats from ePub to PDF to HTML to LaTeX and more. This has a high-ish learning curve, but will appeal to Emacs diehards.

Communication, Networking, and Relationship Building

These resources each touch on some areas of teaching, giving talks, writing documentation, or day-to-day communication with peers, superiors, and subordinates.

How To Make Friends and Influence People by Dale Carnegie is a book on everyday social engineering. In a very digestible form, one chapter for one habit, it coaches you through the behaviors that can make you the sort of person all the best people want to work with while getting what you want to get done done.
Confessions Of a Public Speaker by Scott Berkun is a short, light read full of actionable advice on becoming better at giving talks and presentations. If you are new to public speaking, start here.
If you ever have the opportunity to take Edward Tufte’s course on Presenting Data and Information do so. It’s a bit chatty, but it’s only one day and you will think about how you publish and present differently. Without the class, you can still find Tufte’s books useful. He gives out Visual Explanations, Beautiful Evidence, Envisioning Information, and The Visual Display of Quantitative Information to those attending the course.

Management

If you are or plan to be in charge of others, these resources are worth checking out.

The Effective Manager by Mark Horstman is the book behind the management practice at my day job, and I’ve begun using it elsewhere because these methods are so effective. Instead of a lot of vague, nebulous advice like “encourage teamwork”, it’s focused on three practices that can form the basis of effective communication between managers and their direct reports: regular one-on-ones, frequent high-quality feedback, and coaching.

Mark and his team also produce two podcasts: the Career Tools podcast for individual contributors trying to build or boost their careers, and the Manager Tools podcast for those running projects and managing people. The web site offers a number of other useful tools for sale, such as an interview planning tool, a resume improvement series, and so on.

Executive Stuff

“Executive education” sounds too fluffy and business-y for most engineers, because they think of “executive” in terms of “being a CEO” when, in fact, it’s much broader than that: “executive” things are concerned with executing something generally: carrying out a plan, driving work forward. It matters for everyone from mid-level and senior individual contributors to leaders of teams to leaders of organizations.

Strengths Based Leadership isn’t just for people in management roles: it’s a book for people who are ready to take a step back and ask “what are my strengths, in a general sense, and how do I leverage them?”. This is especially important for tech folks, because we too easily focus on accumulating technical competencies, which eventually expire, while neglecting the meta-skills that amplify everything we do. I’d recommend this book over Strengths Finder 2.0, even for people who don’t think of themselves as leaders, because the Strengths Based Leadership book is more action-oriented. Buy a new copy so you are sure to have an unused code for their online assessment.

Think of it like building a party for DoTA2 or D&D… you need complementary skill sets in order to be effective, and you play to your strengths so that you can snowball by building on places where you are strong. Too often tech people forget these lessons and try to work on teams of people who are like themselves (imagine a D&D party of only fighters when evil magic is encountered), or focus on “fixing” weaknesses while neglecting the chance to snowball (imagine someone trying to play DoTA’s Puck as a tank).

Bloomington Bees

Sat, 01 Jul 2017 21:22:42 +0000

My 14yo son, Lucas¹, is working on his first startup. Bloomington Bees is a Bloomington, Indiana based apiary, or bee farm, producing honey, beeswax, honeycomb, and other interesting things. The Bloomington Bees blog, linked above, launched last week and received a bit of polish today making it ready to promote. Lucas talks about beekeeping and what it is like to start a business while still in school.

My original post about Lucas’s beekeeping endeavor can be found here: So it bee-gins.

Usually referred to here as “LittleFish” ^[return]

So it bee-gins.

Sun, 11 Jun 2017 17:20:00 +0000

When most people talk about startups, they conjure up visions of inexperienced hipsters fighting for VC¹ money with a “build it now, exit soon, profit will magically happen sometime” attitude. There’s a lot more going on in the world–a lot more going on just in the US–but it gets little attention because it’s not trendy and “high tech”.

My 14yo is starting up this year.

It all started last winter, when Lucas saw a movie set in Sherlock Holmes’ later life. Holmes pulled himself out of retirement to solve one last case. In doing so, our favorite detective entrusted his home apiary² to a young neighbor boy to ensure it would be looked after in his absence.

Lucas, who used to be afraid of bees, became fascinated with the idea of raising them and collecting honey. A few people thought I was crazy, but hey his mom is the sort who deals with her acrophobia by going mountain climbing, so why not? I reminded Lucas that a friend of ours had started an apiary about a year before, and Lucas was soon off to the races, trying to find out what he needed to do to start an apiary of his own.

I learned more about bees than I ever wanted to know.

For months, the subject of most conversation in my house has been bees, honey, beeswax, hives, and the things one can do with them. Honeybees originating in Italy are higher producers than those originating in Russia, which are hardier. You can tell which cell will hatch a queen by its color. Bees only buzz when they are angry or can’t find their queen.

Lucas steeped himself in bee-related Youtube videos, as well as a book and articles sent to him by our beekeeping friend.

It turns out that bees are expensive.

To start his apiary, Lucas was going to need a hive stand, hive components, protective gear, a smoker, be feeding supplies, and, of course, bees. Although he had more than $200 saved up, this wasn’t going to be enough to launch an apiary. Like any kid, he wanted to spend my money, but I wasn’t going to just throw a few hundred dollars at something that might evaporate when my teen’s attention span ran out.

To show that he was serious, I required Lucas to make a business plan and pitch it to me, as any founder would do to their potential backers. Here’s what the title slide of his pitch deck looked like:

It took him about two months to finish the business plan and pitch deck, having never done this sort of thing before. Lucas ended up researching a lot of things he hadn’t thought about: Where would he sell his product, and for how much money? How would he package it? What was his marketing strategy? What risks would he have to mitigate along the way, and how would he do so?

Lucas realized that he would have to start two hives, to hedge against winter die-off. Losing some bees in the Indiana winter is normal: if you only have one queen, though, you lose your entire hive if you lose her. With two hives, each with their own queen, chances are at least one queen will survive the winter. In future years, Lucas will have expanded to enough hives that winter die-off won’t be so scary.

Lucas also learned that, to help his hives fill out by winter, he would have to feed his bees. Bees are amazing foragers, traveling up to 2 miles from the hive in search of nectar, but starting a hive from nothing takes an incredible amount of resources. By providing the bees with a steady supply of sugar syrup, Lucas could ensure that strong hives were built by the time the weather turns cold.

Lucas found out what prices honey was going for locally (bulk and retail), and learned that a local farmer’s market offers free tables and promotion for sellers under 16 who manage their own booths (i.e. parents aren’t running the show). He priced packaging, signs, and business cards for his beekeeping operation as well.

Lucas quickly learned that a wise entrepreneur doesn’t operate in a vacuum: his business plan included myself as his business advisor, and our beekeeping friend as a subject-matter expert. It’s great when your investors make good advisors, because they have a vested interest in your success! Being mom, I was Lucas’s investor. However, he did a great job of getting others excited about his endeavor. Soon, our beekeeper friend had offered him some free start-up bees, and Grandma had decided to purchase materials and make a nice bee-themed tablecloth and other display items for Lucas’s farmers’ market booth.

Beekeeping and bookkeeping

Lucas’s plan was definitely for the long term, and he backed it up by saving his money for the start-up costs in the months leading up to this spring. When friends or relatives asked him what he wanted for holiday or birthday gifts, he always responded, “money for my bee business, please”.

In the first year, it was questionable whether Lucas would be able to harvest any honey, wax, or comb. That would depend on how fast the bees built up their hives. He didn’t want to set them back, harming long-term gains, just to get an early honey harvest. He planned conservatively, ensuring that he could cover his expenses by the end of year two, even if a third of his bees died off in winter.

Preparing the hives

Lucas’s first purchase, on a trip to Kelley Bee Supply down in Kentucky, were frames for his hives. A frame hangs in a hive box and gives bees a place to build their honeycomb. Lucas chose “foundationless frames” which, weirdly enough, aren’t mainstream these days. Most beekeepers seem to favor frames with foundation: a plastic base that is shaped like the backplane of sorts built between layers of honeycomb. It’s believed that foundation helps the bees speed up hive building. However, there are down sides: the most robust bee home is one that bees have built to their own specs. Forgoing foundation means that you get stronger honeycomb at a slower pace that allows the colony to grow up before it starts building out too far.

That’s a frame. You’ll see that the top bar hangs over the sides, to allow the frame to rest on a ledge inside the top of a hive box.

This photo is taken at an angle that shows how a triangular ridge hangs down from the inside of the frame’s top side. This gives the bees something to attach their honeycomb to.

The frames, of course, need a hive to hang inside. A modern beehive consists of a top cover, a bottom cover, and some number of “hive boxes” in between, filled with frames. These come in different sizes: for Lucas’s hives, we chose 8-frame mediums, because it’s the smallest practical size and would be easy for him to move around himself even when loaded down with honey, comb, and bees. To save money, Lucas purchased the boxes unassembled, and spent a Sunday afternoon putting them together:

The outsides were painted to help the boxes last a bit longer outside in the elements, but it’s important not to paint the insides, as that would make an unhealthy environment for the bees.

Disaster Strikes

Over the winter, a number of our friend’s bees froze to death due to water intrusion into hives. It’s one thing for hives to get a little wet, or a lot cold, but water freezing in the hive can and will kill bees. Lucas lost his source of donor bees!

Bastin’s Bees, an apiary outside of Indianapolis, came to the rescue. Ron Bastin took a late bee order and helped make the project affordable for Lucas and his financial backer. Our bees came this week!

June is a bit late for starting brand-new hives, so there likely won’t be a honey harvest this year. However, the bees should still have time to build up their homes before winter. Our beekeeper friend treated Lucas to some very nice feeders to help deliver lots of sugar syrup, encouraging fast colony-building.

Because one challenge wasn’t enough: the day before we were to pick up Lucas’s bees, he had an accident while doing crafts and needed stitches for a cut on his hand. Two hours in the local urgent care later, he was exhausted but back home. We’d missed our window for building the hive stand that day, and I was behind on work. I downed some coffee and caught up so Saturday would remain free.

More helping hands

We picked up the bees Saturday morning from Bastin’s, along with two deep hive boxes, because that was the size of frame the bees came on. There would be no time to paint the deep boxes or the new feeders before bees moved in. Two NUCs, corrugated plastic containers for bee transport with a few frames in them, rested under a shade tree while we hastily built the hive stand. Another friend and long-term houseguest was a tremendous help with the building.

Because the back of our property is sloped, we had to dig quite a bit to make sure the hive stand would come out level.

Lucas’s beekeeping mentor soon arrived to help him move his bees into their new homes. The expert installed bees from the first NUC into the first hive, then Lucas installed the bees from the second NUC into the second hive.

The bees are in…

Now we give them a couple of weeks to settle into their new home. The bees seem to like the hive on the right better than the hive on the left for some reason. If the populations are very uneven by two weeks from now, Lucas will have to swap out full frames from the high-population hive for some empty or less-full frames from the low-population hives to even them out and ensure that both hives are healthy.

He’ll add boxes to the stack as the bee population grows, making each hive taller over time. Eventually, he should be able to phase out those deep boxes in favor of easier-to-handle mediums. Meanwhile, the bees get a steady diet of sugar syrup from the feeder boxes just under the hive covers to help supply their new hives. Lucas’s first business is what all the buzz is about!³

Venture Capitalist: wealthy folks who’ve set aside money for investment in (usually very young and/or high risk) business ventures ^[return]
Apiary: the correct term for a “bee farm” ^[return]
No, the a-pollen string of puns will never end. Just give up now. ^[return]

Getting Mentorship Right in Open Source

Mon, 05 Jun 2017 00:58:00 +0000

Thanks to pdurbin and moongazer in #openhatch for the original discussion, and pdurbin again for some good edits to this post.

I was party to a great discussion on IRC today about the disconnects in expectations that can make creating great mentor/mentee relationships difficult. This post is an attempt to capture some of my own thoughts and correct some misconceptions.

A Mentor’s Perspective

I’ll begin by explaining what mentoring looks like from the mentor’s perspective. This is something most prospective mentees don’t usually think much about, because they haven’t yet gotten to this stage. Understanding your mentor’s needs and concerns can make the process of getting good mentorship make more sense.

A good mentor is busy. The people who make the best mentors are people who aren’t just competent at what they do, but the combination between a top performer, a good communicator, and the type of personality who is themselves always learning. This is a recipe for being busy, all the time.

Good mentorship is labor intensive. Mentoring costs a mentor time and energy. Because good mentors are busy people, these resources are already at a premium. Too often, mentees don’t understand that mentorship is, on the part of a mentor, an investment of a precious resource.

The time and energy a mentor spends on a mentee is taken from his or her own work. Because good mentors are so busy, and mentoring so labor intensive, it naturally follows that resources for mentoring come from the reserve the mentor has for his or her own projects, goals, and responsibilities.

Mentoring others is essential for ambitious people. If we don’t mentor, we don’t have a reliable source of successors. Thus, we either have to drop responsibilities on the floor, allowing things we cared enough to build, fix, or nurture to die, or stay in the same roles forever instead of evolving and growing ourselves. Mentoring solves this by creating a pool of people we can trust to hand our work off to when we move on, or when projects and organizations grow in scope.

Mentoring is how many pay it forward. OSS isn’t new any more. Many contributors have built fulfilling hobbies and even careers from the foundation of our open source learning experiences. Some repay that benefit to the community by providing learning opportunities for those who come after.

A Method to Mentoring

Good mentor-mentee relationships do “just happen”…once in a while. However, the need for good mentoring in many fields is greater than what will crop up due to chance. There is a method to making these relationships happen.

Step 0: Common Ground

The first step in getting yourself a good mentor is to meet enough senior people in your field to “click” with someone. This means attending conferences, corresponding with authors, joining IRC and similar venues, and really participating were you can be seen.

I met some of my early mentors by stumbling on to IRC and USENET, participating in discussions, and asking for help from people involved with the projects I was contributing to.

Peter Thiel picked up his aide-de-camp Blake Masters after Masters attended one of Thiel’s lectures at Stanford in 2012. Masters took detailed notes from the class, and circulated them far beyond campus. Ultimately, Masters and Thiel worked together to turn the material into a book.¹

Often, formal mentoring programs do a worse job of this kind of matchmaking than informal professional networking, because they presuppose an investment by mentors without any pressure on mentees to give back. Additionally, they’ll usually make a bad match rather than fail to match someone.

Step 1: The beginning is up to the mentee.

This is an especially important point to drive home today. One of the core expectations in Open Source communities is that new people will periodically show up and start doing things. Unfortunately, many of the young people looking for Open Source mentorship have grown up in a world without pick-up games of this or that, dominated instead by organized activities with registrations and applications before anything happens. Often, new contributors don’t contribute because they can’t figure out where the gatekeeper is they should get permission or assignments from, when we don’t believe in gatekeepers at all!

I cannot emphasize enough that beginning a mentoring relationship is in the hands of the mentee, not the mentor. It is up to the mentee to:

Find a mentor you “click” with, who makes you think “I love how this person thinks about $subject.”
Court their mentorship by doing work they will care about, and take a “work first” attitude toward being a mentee.
Reach out to your prospective mentor. Understand that a mentoring relationship is built in stages; don’t try to make it happen all at once.

Step 2: Work first.

Beginning the relationship with work on the part of the mentee demonstrates to the mentor that this mentee is a good investment, rather than yet another beggar trying to get something for nothing.

Remember: you are asking a mentor to take time away from their own work and give it to you. A wise mentor won’t do this for everyone who asks–they’d fall down from exhaustion–instead, a wise mentor will invest in those who show good follow-through, and will give back to the mentor’s activities. This lets the mentor know that the resources they are investing will actually result in learning, and also serves to offset the cost of being a mentor.

Concrete examples of this include:

Taking great notes from a talk or presentation the prospective mentor gives and adding value to it by putting the content into a more easily shared form, translating it, or doing a case study about how you put it into action yourself.
Fixing a few bugs or updating documentation for a project the prospective mentor maintains.
Hanging out on IRC, Mailing Lists, etc. for the prospective mentor’s projects, and contributing to discussion, answering questions.
Helping triage issues in the queue for the prospective mentor’s project.
Find something the prospective mentor has written about, try to apply it, and write up a blog post or article on your experience, perhaps reaching out to the prospective mentor to let them know you did it, or for a quick review near the end of the process.

Step 3: Growing the relationship.

One you gain a mentor’s attention, expect that work on both of your parts will be needed to make a mentorship relationship work.

Regular communication is essential. Whether you correspond by email, have regular phone calls, or catch up via IRC in the course of working on a project together, mentor and mentee should always know when and how the next regular communication is coming.

Having a shared project is the most effective basis for long-term mentoring relationships. When a mentee devotes time and effort to work that matters to the mentor, this provides both needed labor for the mentor, and a problem set for the mentee with which the mentor is intimately familiar.

It’s important for the mentee to understand that having a mentor is not having an instructor. In an instructor-student relationship, the instructor’s primary work is the progress of the student, in fact they are paid specifically for this process. An instructor is in command of the student, to some degree, and is charged both with teaching and with evaluating.

A mentor, by contrast, is a colleague of more experience than the mentee. A mentor can offer guidance and help with problem-solving, but they are usually compensated by the mentee’s contributions of time and skill, and are not charged with grading the student. The only measures that matter to a mentor is whether they feel the relationship is worthwhile, and perhaps when the time comes, what they are comfortable delegating to the mentee.

Below, I lay out a description of the evolution of a mentoring relationship, but please don’t take these stages as rules. This is merely a model that I find fairly reliable to play out. There are others just as good, and I deviate from this often, playing mostly by ear.

Matchmaking… The first thing is to form a relationship, get to know one another. This can happen in person, or through correspondence, whatever. Establishing mutual interests and a personality fit is usually pretty natural for both parties.
Coaching… Some arms-length coaching tends to be the beginning of a mentoring relationship. This is one of the lowest-overhead forms of mentoring. By “coaching”, I mean a form of mentoring where the mentor offers the mentee suggestions on reading or practice, and the mentee will follow up with questions or concerns, or requests for advice, to talk through with the mentor. A wise mentee will take special care not just to pick up chances at skill-building, but to get hold of the culture and history of the discipline. This is especially important in open source communities, as we draw from so many cultures and backgrounds that our shared history and culture, communicated through time in science fiction, technical writing, April Fool’s jokes, and more give us needed common ground.
Close-in Mentoring… This is the point where the mentee has taken up a role in one or more projects of the mentor, accepting delegation of tasks and working some coaching into the fringes. The mentee, at this stage, is expected to have the maturity to undertake some self-development and exploration, mostly leaning on the mentor for new challenges and for feedback when they find themselves stuck. A close working relationship means that much of the mentoring just flows from project-based interactions.
Succession Planning… A mature mentee will eventually be included in the mentor’s succession planning. Building leadership–technical or social–in those below them is every mentor’s job. We shouldn’t allow ourselves to become a bus factor² of one for any project, and additionally some of our projects or organizations will grow to a complexity where more than one-person leadership is needed.

Attracting the Right Mentee

A word now for prospective mentors, on finding the right mentee or mentees.

I personally believe in having more than one mentee whenever possible. This helps one to avoid the failure mode where one becomes over-invested in another person’s path, prone to providing unreasonable levels of direction or even pressure. It feels like your one mentee weighs more heavily on your own reputation and abilities, where that same person making mistakes or going a different way than you’d hoped is far less stressful for the mentor if they are one of a few mentees.

Having an incoming pipeline of possible mentees involves getting out there in the world. Sending your writing, code, or other works out into the world often isn’t enough of an invitation. Give talks, go to conferences, seek out events where you’ll be exposed to people who aren’t as far along as you are. Or, if you struggle with those sorts of social things, try to talk a colleague in your or an adjacent specialty who thrives in these environments into keeping eyes open for you and doing a bit of matchmaking on your behalf.

Find opportunities to coach multiple people in a broad way. For example, if you do a regular monthly chat or meetup, you can start to get to know regulars who share your interests and give a bit of advice here and there. Based on how those interactions go, you can decide where to invest more time and effort.

Conclusion

While the value of good mentorship for the mentee is often extolled, too seldom is it mentioned that creating and maintaining a mentoring relationship requires more of the mentee than showing up and asking a mentor to take them on. It is a good thing that the best mentors ration their time: because the world cannot afford to lose its most skilled people to mentoring duties entirely. We need them working at the things that make their mentorship valuable.

Being a good mentee means taking some initiative to find a mentor who is a good fit for you³, and to provide value to the mentor first, as a way to establish the relationship. Then, maintain the relationship by working on yourself, and by contributing to the mentor’s work to offset the cost of mentoring a bit.

Zero to One: Notes on Startups, or How To Build the Future by Peter Thiel and Blake Masters. ^[return]
“Bus factor” rather uncharitably describes social failure points within a project or organization by counting the number of people who would have to be hit by buses and killed before the project or organization would be in peril of total failure. ^[return]
It’s worth mentioning also that many people start looking for a mentor before they know entirely what their own interests are. This is okay: do work while you’re figuring things out. If you don’t find the work challenging enough, or rewarding enough, and you can’t shake it out with help from your mentor, you may need a different mentor or a different line of inquiry. ^[return]

Meritocracy in Open Source

Thu, 11 May 2017 22:26:00 +0000

I sat it on a great talk at OSCON today by VM Brasseur about succession planning in Open Source projects and communities. There was a point where she called out the weaknesses in claims of meritocracy in open source projects: At first, I expected the worst: another tirade about putting the goal of selecting contributors who look different from one another ahead of selecting for competence, differences in thinking, or complementary skill sets. What I actually got was something very different: a real assessment of where attempts at meritocracy usually fall apart.

Specifically:

The “I know it when I see it” failure mode: no one defines what merits a project or role needs, leaving new contributors flailing to figure out how to fit in, and established contributors blind to how to select and encourage others to eventually succeed their roles. (Fun fact: this blindness usually leads to a high attrition rate among new contributors and selection that corresponds more to individual biases than what the project needs.)
The “the role is the person” failure mode…succession planning is put off again and again until it never happens, because project leadership never look at what the key roles are that they need to fill, being stuck in the “so-and-so does this” mode of thinking.
The “I’m waiting for someone competent to show up” failure mode. I’ve renamed this from the presentation, to reflect a bias I see in senior contributors time and again. Rather than building competence in new contributors, some senior contributors wait for it to magically appear. This doesn’t actually happen.

There were others, but the list went by quickly. I was very happy to see that my projects–those I run, at least–have carefully dodged these failure modes, at least for the projects in which I was in a leadership position. I’ve always pushed hard on mentoring, on defining roles, and on defining what meritocracy means in the context of my projects and for those who want mentorship from me.

However, while I’ve passed this on time and time again, I’m not sure I’ve written it down somewhere linkable and searchable. So, here it is:

Show up, be polite, do work.

It’s a pretty simple, yet it’s surprisingly often the last thing on new contributors minds when they show up to an open source project I run. There’s often a fear among new contributors that they don’t have enough technical skill and experience (if you’re a good worker, we’ll help you build it), or that they don’t understand the problem well enough (we’ll point you at things to work on). Worse, some come in with the idea that the project should invest in them on the promise of maybe doing work later.

Let’s talk a bit about how and why this works in practice in my projects.

The importance of showing up.

Most open source projects suck at recruiting and mentoring. These are learned skills, which too few OSS leaders get any training in. Even projects that have skill in recruiting and mentoring have limited resources. It is crucial that these projects spend their resources wisely. One of the most important things you can do to demonstrate your worth in the context of my projects is to be reliable in showing up. This means:

Make the time you spend on the project predictable: your colleagues should know when to expect to see you again, and if you get too busy for something, you should communicate to the team instead of going silent.
Make sure to cleanly hand off any responsibilities you can’t carry out on your own, so that they don’t get dropped.
Make good use of the project’s communication channels, so that others know what you are working on and you know what’s happening on the project.
If you take on a critical role, such as lead developer, a component owner, information security officer, or such you should make it easy for project members to contact you in an emergency, even if you are offline.

Showing up means that the project knows it will get back its investment in mentoring you, it means that you won’t randomly become a blocker on progress being made, and and it means that you are generally respectful of others’ time and the need to be reliable to advance from drive-by contributor to more senior roles.

On being polite…

Projects are made up of people. A toxic social environment can and will kill a project’s ability to forward technical goals. Unfortunately, some projects’ response to the real threat of toxic social environments is to create a more toxic environment, by defining correct behavior as behavior that doesn’t bother anyone (i.e. “the most aggrieved person wins”). This simply predisposes insecure people to take offense more often, because it’s an easy power grab that needn’t be backed up with facts, offensiveness being a subjective matter.

Taking offense will get you nothing on my projects. As a matter of fact, part of our social code is to be generous in the inputs we accept, and careful in the outputs we produce. Mistakes and miscommunication happen; and this precept helps to minimize them.

Another piece of our definition of politeness is to assume right intent until absolutely proven otherwise. Mistakes come in many forms, but assuming ill intent can quickly escalate a mistake to a disruptive community schism. In any case, most people mean well most of the time. Acting on this assumption tends to bring out the best in people.

We limit our areas of concern to behavior within the confines of the project. We accept contributors from many cultures and walks of life. To truly do this, they must be free to have whatever personal life they want, while responsible enough to behave with a certain level of pro-hackerism in project venues and when speaking for the project elsewhere.

The above guidelines are mostly concerned with preventing the wrong kinds of conflict, and avoiding escalation of conflict, within the project. We also have expectations for managing constructive conflict, and for a few other matters of concern.

Responsibility is considered greater with more-senior contributors. As individuals rise to more senior roles, they get coaching on social and leadership skills.

We do our best to avoid, when possible, and otherwise clearly disclose potential conflicts of interest or appearances thereof.

When arguments arise, as is inevitable, it is expected that all parties confine the discussion to the technical merits of an issue, leaving aside any commentary about the parties as individuals, especially avoiding any ad hominems or characterizations of others’ motives. It is also expected that, once the issue is closed (if necessary by a decree of the appropriate project lead), the issue is dropped from debate. Questions about the origin of the decision are then referred back to issue queue or mailing list logs rather than a re-hashing of the debate. To enable this, we try to summarize various sides of an issue when the final decision is made including, if possible, a statement of the conditions under which this may be revisited.

When it comes to social or process issues, there is a general preference for enabling efficient and effective technical work over other concerns. This is especially important where opportunities for fault tolerance exist. That is, we expect humans to make mistakes with some frequency and thus design our processes to offer some safety net for that.

We endeavor to make role definitions and succession planning explicit rather than implicit wherever possible. Oftentimes, power games within a project arise because there isn’t a clear definition of boundaries of authority.

We accept that usually, a sub-optimal decision executed now, and executed consistently, is better than a taxing, long-running process or a breakdown in the conceptual integrity of a code base or document. That is, don’t let the perfect, or a search for consensus, get in the way of work being done. In the end, a project or component “owner” is justified in making an arbitrary decision as well as they can when a debate is dragging on to the point of repetition.

We expect all project members to generally treat one another as colleagues (and, occasionally, friendly competitors) rather than as combatants. This includes an expectation that feedback will be given soon and often, rather than expecting others to intuit boundaries and social standards that should have been communicated.

It’s all about the work.

Each of my projects is arranged around a mission. Furtherance of that mission is our primary objective. This is very important, because “does this further the mission?” is a great check when making decisions. It takes a lot of ego out of things, and also gives us a way to bring people together: it’s about the mission, not about individuals identities, beliefs, demographics, or personal lives.

Doing the work well means maintaining the the product (usually, but not always, code and documentation) quality standards of the project, following our process, and being honest with project colleagues about the project (including saying “I don’t know” rather than trying to cover with a guess and possibly leading others astray). It means finding a niche and fitting in to it. It means taking direction or giving direction well, when appropriate.

Generally, I’ve found that once the project mission is clear, and security/coding/documentation standards are made explicit, the rest straightforward enough to give junior and mid-level contributors the guidance they need to function within the project. Being a senior contributor or lead is, by nature, different: these people need the maturity to set the standards, and to ask the tough questions. Balancing that takes experience, ethics, and skill, none of which will come from a set of project guidelines and thus are out of scope here.

Is it really this simple?

It’s certainly straightforward to run and participate in a project with this standard, but it is by no means simple. It’s actually a lot more work than the “Code of Conduct” guided projects are, but in my opinion the effort is worth it.

Communication is a responsibility.

In projects run according to my meritocratic rule set, we accept that people won’t know what is expected of them unless it is communicated. This is part of assuming good intent until proven otherwise. By nature, it confers a responsibility upon senior contributors and long-time community members: the responsibility to constantly and consistently communicate expectations to others. There’s no “you should have found, read, and interpreted my document as well as the mental states of other contributors” out here.

If you have a boundary, it is your responsibility to communicate it.

If you see a problem, especially involving a more-junior contributor, it is your responsibility to see that the problem is communicated to those involved, clearly, promptly, and without escalating the situation.

If you find that something is unclear, it is your responsibility to ask, though we understand that very inexperienced contributors may have trouble realizing what is unclear and asking, and do our best to provide active guidance before a serious problem happens.

Leadership training is part of moving up.

Everyone moving into a senior position for the first time, and many people whose leadership or management experience is in organizations markedly different from these communities, needs coaching or mentorship in leadership skills. It’s not fair to expect someone to deal with their first cult-of-personality situation, their first underperforming subordinate, their first big decision as a component owner, and so on without the support of more experienced colleagues. Leadership isn’t about being the smartest or the most technical: it’s about keeping the team moving forward toward a goal, and conducting oneself ethically.

Everyone has something to prove.

When some people talk about being treated with respect, they mean “treat me like a person”. When others use the word respect, they mean “treat me like you are my subordinate”. We expect everyone on my projects to be treated like a person, with reasonable courtesy. Beyond that, respect must be earned.

Too often, in today’s society, people expect to be accorded some amount of deference merely for showing up, or for having some credential or membership in some pointless demographic. Introducing people accustomed to such a culture to the idea that they must earn the respect of others in order to be treated as a valued colleague, let alone as an authority, can be jarring for them. However, requiring people to prove themselves by showing up, being polite, and doing work is a positive for an open source project.

On my projects, we encourage people to see the chance to prove themselves in every interaction. Be the bigger person in a conflict. Quietly plug away at a problem no one else is attending to. Spend your time and effort to get better at something that can help the team. Help those less experienced than yourself.

This means both that people have to work to become part of our core team, but also that membership in the team means something. It’s worth being proud of, and each of us can trust other members of the team to show up, be polite, and do work.

Embracing similarities among differences

This is a truly hard thing for most humans. There’s a tendency to surround oneself only with like-minded individuals. It feels safe and productive, and doesn’t tend toward high levels of disagreement. It’s also beneath the dignity of a great mind.

Like groups tend to fall to the narcissism of small differences, constantly narrowing the in-group by carving out outgroups in what could have been a community. Unlike groups can have a special synergy: when group members have very different perspectives as a result of very different backgrounds, personal beliefs, and methods of operation, they tend to compensate naturally for one another’s weaknesses and blind spots.

This works well if the group has a shared mission to rally around, rather than a demand to be all-inclusive (because an all-inclusive group can’t do anything, as there’s no one thing that every human wants to do and can do). It’s important that the mission is doing something (as progress toward a goal can be observed) rather than being something (as that descends into identity warfare).

A diverse group with a common mission can set aside their differences in the name of the mission, and be a better group for it. However, it takes a culture where appeals to identity are immediately shut down and not rewarded.

Leadership doesn’t get the luxury…

of taking things personally
of not having patience
of letting people who don’t acculturate stick around and poison project culture
of refraining from comment for the sake of “avoiding conflict”
of giving feedback only for the negative events
of not investing time and energy in non-technical leadership skills
of benefiting from the skills of inadequately socially functional people without doing the work to insulate others from their negative impacts
of being indispensable
of avoiding criticism

In short, you don’t get to run a community on autopilot, and you don’t get to put appearances ahead of accomplishment. You must make and take responsibility for tough and sometimes unpopular decisions. You must give feedback early and often. You must work on your own leadership skills and those of your team. You must put the long-term health of the community ahead of your own personal comfort. You must be willing to be controversial at times.

It’s hard work.

But what about biases?

All humans are biased. No one can make perfect assessments of others: if anyone could, then hiring would be easy, at least at the companies who can afford the best hiring managers. Trying to eliminate human bias through policy won’t work, it just introduces new, harder to combat biases to the environment.

A clear process with a goal of meritocracy can be iterated upon. Abandoning meritocracy as a concept means deciding that the OSS project’s mission is not really its core mission: it is dishonest at its core.

But what about difficult, high-performing, contributors?

An experienced, competent leader can weigh someone’s contributions against the contributions lost due to that person’s behavior if they are watching closely enough. Meritocracy doesn’t mean “high producers get to do whatever they want”. The health of the whole project over the long term should be taken into account.

However, going back to the assumption of good intent until proven otherwise: problem contributors are, in most cases, bearing some social dysfunction or inexperience rather than actually malicious. Certainly, malicious actors should be ejected from a project. Merely dysfunctional ones, if sufficiently high-producing to merit the effort, should be treated with more creativity.

Often, providing some education and support to, or buffering around, the “problem” contributor can make them a functional part of the team who isn’t hampering others’ performance. Try a few different things. Look upon the problem as a social disability, and create a plan to either resolve or mitigate it.

Most importantly, stop trying workarounds when the overhead of doing so exceeds the contributor’s value to the project. Yes, this means that not everyone gets the same treatment. That is life: it’s a project manager’s job to see to the health of the project, not to make life fair. What is the project’s mission? What is helping or hindering that mission?

Blog Migration

Sun, 22 Jan 2017 19:27:46 +0000

So, I’ve finally done what a certain loved one calls “taking an engineer pill”¹ and moved another bit of my digital world to a managed service, reducing maintenance overhead so that I can focus on other things.

This blog is now hosted courtesy of https://ghost.org, who have kindly offered me a complimentary hacker account to support my work in open source. They’ve taken over running my blog on the new Ghost blogging platform so that I can focus on content and, of course, my infosec work.

I’m still migrating content and chasing down several remaining theme bugs, but thought I’d go ahead and set this live so that I could begin to put more writing out into the world. You’ll see new and old content continue to appear here in a trickle over the course of the next few months.

Feedback is always welcome.

To “take an engineer pill” is to do one of the hardest things an engineer could do: to let go of control of something under one’s purview and hand it over to someone else, who may or may not do it exactly as the engineer him/herself would have. It is so called due to the implication that some engineers may have to be sedated to actually manage such a feat. ^[return]

Hacker's Notebook

Sat, 07 Jan 2017 02:46:26 +0000

This page stands to aggregate resources that may be useful to folks interested in starting out as hackers. It’s made up of a few mini-essays and many links and references to longer-form resources. Don’t try to go through it linearly; skim for topics that interest you and cherry pick what you find useful right now. The rest will still be here if and when you need it.

Feedback most welcome via the usual channels.

Hacker Ethos

There’s plenty of writing out there about what it means to be a hacker. You should be familiar with the definition of “hacker” from the Jargon File. There’s a lot in the Jargon File that I consider outdated, but it’s a seminal part of our cultural history. Having at least a passing familiarity is worth your time.

You’ll find, as you read different accounts, that there’s disagreement on what makes a hacker. This is the nature of the one thing we do generally agree on: a hacker must be a creature of independent thought and action. It clearly follows that we view what we do differently.

I plan a future blog post to cover some of my thoughts on the matter. For now, I intend to give you just a few tips to help you begin grokking how the community works.

The Basics

Hacker identity is rooted in independence, personal responsibility, and competence. Getting respect in our community requires that you value these qualities, and demonstrate that you are doing your best to live up to them (no one ever does completely, but that’s just being human).

We honestly don’t expect newbies to show up with a ton of competence. Everyone started out knowing very little. The problem newbies are the ones lacking independence and personal responsibility.

We cannot read your mind and tell you what you will be good at; it’s your job to find things and try them. You will fail at some things, succeed at others but be too bored to become great, and have various other not-the-right-fits before you find your niche. This is generally considered to be a necessary part of your professional evolution. The process both ensures that you end up working on things you actually care about and have talent for, and ensures that you gain at least a cursory familiarity with a hand full of areas outside your core expertise.

We do not have time to hold your hand. You should be respectful of our time by using documentation, learning how to be easy to support and mentor, asking questions appropriately on IRC and mailing lists, and so on.

Part of personal responsibility is not walking around with a sense of entitlement. I use that word in the American sense, where “entitlement” has come to mean “the belief one is owed things neither earned or paid for”. Many people show up and say “teach me”.

Story Time…

I had some amazing teachers and mentors when I was younger. A few years ago, when I was really feeling a lot of weight on my shoulders due to just how few people in my generation had picked up some of the subspecialties I work in, I talked to a couple of my mentors about it. I felt responsible for so much, and I felt alone. My mentors were supportive, but at this point they were aging: a couple had died, more were slowing down or preparing to retire. I’d just realized that it would fall to me to fill the gap, and I needed to train my own help if I were going to have any.

“Why didn’t you teach anybody else?” I asked, feeling slightly childish.

They said that they had been waiting for more competent students to come along.

I couldn’t believe it. I wasn’t competent when I started. I was 12 years old, and I didn’t know that there was more than one programming language in the world or what an issue queue was. They taught me anyway. I demanded to know why I was different.

The answers were all along the lines of “you were just so cute and helpful that we couldn’t bear to turn you away”.

I spent a couple of years–yes years–just facepalming at the idea of “cute and helpful” as selection criteria for future internet maintainers. Then, one day, I suddenly grokked…

“Cute” in this context meant that I was polite, didn’t complain when corrected or didn’t know things, and I tended to make the channel more pleasant to be in. My enthusiasm was catching. “Helpful” was about how I showed up. It never occurred to me to go to strangers and ask them to teach me things for free. That wasn’t part of my culture. I showed up and started doing scutwork… fixing small bugs, triaging issues, giving support in IRC and on mailing lists, and fixing documentation. I learned things by quickly becoming part of the “inner circle” of many projects. I was liked for my good attitude and hard work, and why wouldn’t even the most highly sought-after developer take a half-hour to help explain something to a kid who was doing hours of free work on his or her project? It turns out that “cute and helpful”, or rather, “pleasant, courteous, and ready to work” isn’t such a bad metric after all.

I cannot emphasize enough that this is the key to getting the best quality of hacker education, without going to or paying for school. Do high-quality, free work for smart people, and do it with an amazing attitude.

I’ll cover this strategy in more detail later, under “How To Learn”.

Kinds of Hackers

Many people equate “hacking” with “pentesting”, or breaking into things. That’s a lot like equating “engineering” with “failure testing components”: you’ve named one task amid a huge and varied discipline, ignoring the rest. While some of what you will find in this document applies to software and hardware hacking in general, the focus is on learning to defend networks and secure infrastructure software.

Building Out Your Kit

No matter what kind of hacking you intend to focus on, you’ll need good tools. For the software and information security hacker, this will mean a workstation and some sort of lab setup at a minimum.

A hacker’s primary workstation

First of all, yes, you must run Linux or BSD. Get over it now. This is probably different than what you are accustomed to, and yes a few hackers get by on using Mac OS or Windows as a primary workstation. The people who do so are expert enough to work around the shortcomings of those systems. If you, as a newbie, work from those systems, about every third thing you do will require extra time and debugging. You will be asking your mentors to put in extra work to make up for the inadequacies of your tools, and wait for you to take longer to learn, because you are not using the most efficient possible tools.

When you ask people to do work for your benefit, such as teaching you valuable and highly marketable skills that they take personal risk in teaching you, you disrespect them by making it harder and slower merely for your comfort.

How To Learn

Building Your Reputation

Pitfalls & Safeguards

Intro to IRC

Mon, 02 Jan 2017 18:33:31 -0400

N.B., this guide is specifically for new and future hackers interested in finding community via IRC. Not all advice applies if you are only interested in non-hacker communities such as Nerdfitness or gamer stuff.

What is IRC?

IRC, or Internet Relay Chat, has been the place to get hacking of the network and software engineering kinds done since the 1980s, with information security soon on its heels. It remains so, because:

IRC makes it equally easy to chat with someone down the hall and someone miles away.
IRC chatter can easily be logged and searched to find that thing you forgot.
IRC clients come in many shapes and sizes, so it’s generally easy to find one that fits your workflow well, and is accessible to you regardless of operating system or disability.¹
IRC lets live conversations happen as easily as it lets messages sit around for later, so it bends to your schedule instead of the other way around.

Choosing a client

HexChat is a popular GUI client available for Windows², Mac OSX, Linux and UNIX. It is easy to use, and has most of the popular networks preconfigured. On Linux or UNIX you should get it from your package manager if possible. Mac OSX and Windows users should download from http://hexchat.github.io/downloads.html.

weechat and irssi are popular text-mode clients available for Linux, Mac, and UNIX. Both require considerably more configuration than Hexchat or Xchat to get started, and have more of a learning curve in general. However, the payoff is a very clean text-mode chat experience that is extremely configurable and handles complex filters, dozens of channels across multiple networks, and custom behaviors very very well. If you have a preference to avoid ncurses, irssi may suit you better, but in all other cases I’d recommend trying weechat first, as it is more actively developed and slightly easier to ramp up on than irssi.

There are at least a hundred other clients out there – clients that live inside Emacs, clients that run on your phone, clients that integrate with your email client, XMPP (Jabber) client, and more – just look around.

IRC basics

Networks

There are two IRC networks that you probably care about if you are just starting out: OFTC and freenode. Both of these networks are preconfigured in Hexchat, so you need merely select them and give yourself a nickname. If you’re trying to configure something else, see the networks’ respective home pages for connection details.

Freenode is the network where the bulk of open source projects host their development, support, and social channels.

OFTC is a spinoff of freenode, with a small but significant number of open source channels, plus a number of privacy and security channels.

Each of the clients I mentioned is capable of simultaneously connecting to both (or more!) networks so that you may enjoy channels on each.

Nicknames

You’ll find me on both freenode and OFTC as “HedgeMage” when on my personal machines or “HedgeWork” from a work machine. The separation is arbitrary, it’s just a result of how I manage my bouncer accounts.

You should find a unique, unregistered nickname and register it so others can get to know you. While some people use their initials or some form of their legal name as an IRC nick, this is by no means required. Nicknames that are easy to remember are preferred, and this often leads to seemingly outlandish ones. Being HedgeMage certainly doesn’t keep me from being taken seriously. Similarly, bonsaikitten, Isky, micrypt, and CaptainPlatypus are all quite serious individuals whom you should probably get to know at some point.

In order to “own” a nickname on an IRC network, you must register with nickserv. This has the advantage both of reserving that nickname for your use only, and of giving channel owners the ability to give you invitations to invite-only channels, chanop (channel operator) privileges, or other special permissions if they so choose.

Registration is simple. Do /query nickserv info foo, where “foo” is a nickname that interests you, until you find something that you like which has not been registered by someone else. Then do /nick foo to change your nickname to “foo”. /query nickserv help register will provide you with registration instructions.

Authentication in IRC is often referred to as “identifying to nickserv”, because it’s an apt description of the usual command (where “MYPASSWORD” is the password set during registration):

/msg nickserv identify MYPASSWORD

If you get sick of typing that every time you connect, before joining any private channels, you can tell your client to identify for you on connection. The mechanism varies, but if you can’t find specifics in your client’s documentation, feel free to ask for help via your client’s IRC channel.

Channels

There are channels out there for nearly every interest. Since most of my readers are focused on open source software development or information security, I’ll suggest a few in this arena:

On OFTC:

#grokmenot is a beginner-friendly channel for current and future infosec professionals.

On Freenode:

#icei belongs to my nonprofit org, the Internet Civil Engineering Institute. Stop by, and help us save the internet.
#friendly-coders is a good place to ask questions about programming in any language.
Most programming languages have their own channels on freenode: e.g. #python
#startups is for founders and employees of early-stage startups, and others interested in what is happening in startup-land.
The best places to start are usually support and development channels for software you use and are interested in.

Other Networks:

Mozilla has their own network, plus there are some older networks like DALnet and EFnet out there. Feel free to explore, but before you do, read on to understand IRC culture a bit so that you make friends instead of enemies.

Like any other community, IRC networks have their own social standards. For the most part, you’ll pick these up as you go, but there are a few points worthy of special attention:

On freenode, it is considered stalkerish to pm (private message) someone without their express permission. Other networks don’t care that much, but when in doubt ask before pm’ing.

It is 100% normal and expected IRC behavior to “idle” in channels, or leave a client connected to a channel in which one is not active. This lets users peek in between other tasks and become active if something interests them, see what they missed while gone, or just plain not create a bunch of join/part messages by entering/leaving frequently. It’s often useful to idle in a channel for a while when one first joins to get an idea of how people there interact. Every channel has a social code of their own.

Almost every IRC client will “hilight” lines that contain the user’s IRC nick. This is a useful way to help others follow a conversation when other conversations are happening in the same channel. So, if I’m supposed to notice something in a busy channel, you probably want to preface it with HedgeWork:. It’s not very nice to gratuitously hilight someone who is obviously idle or away, as that would leave them with a huge backlog of notifications to return to.

Almost every IRC client offers tab-completion of nicknames. This is really useful when trying to hilight someone or send a pm.

Before trying to get help in a support channel, please read How To Ask Questions the Smart Way and The Anatomy and Habits Of the Common Support Leech. Everyone reading this is likely smart enough that if we need support, it’s going to be from someone bright and skilled enough that they are likely to also be curmudgeonly about IRC behavior.

Know where you are before you talk about working in or being interested in security. IRC has good neighborhoods and bad. On EFnet, for example, or in #defocus on freenode, stating that you’re in the security field has about a 1-in–5 chance of making some teenage twit with a botnet very interested in you.

Commands

IRC has a lot of commands. Standard commands, commands specific to the IRCd or services daemons running, commands specific to the client used or commands custom-configured by the user. Here are a few very basic, very universal ones that you may find useful.

/join and /part

This is how you join and leave channels. /join #foo will let you join the foo channel, and /part while focused on that channel will cause you to leave.

/topic

You should always issue the /topic command upon entering a channel you haven’t been to before to find out what it’s about or if there are any channel rules they want newbies to be aware of. Many clients also display the channel topic somewhere above where the channel’s traffic is displayed.

/query and /msg

The /query and /msg commands allow you to send a private³ message, or pm, to another user. In some clients, these behave identically. In other clients, /query will start the private conversation in a separate window or buffer but /msg will not.

Example:

/query HedgeWork Hey, are you going to be posting your Penguicon slides any

time soon?

/me

The /me command is used to sort of narrate yourself, for example, if I type /me fires her Nerf gun in Craig’s direction., others will see:

* HedgeMage fires her Nerf gun in Craig's direction.

/away

The /away command is used to set a status message so people know you are not paying attention to IRC. The syntax is /away At lunch, back around 1pm.. To unset your away, just use /away with no message or arguments.

N.B. to weechat users: weechat defaults to only applying away commands to the network currently focused. To set or unset your status on all currently connected networks in weechat, use /aaway instead.

Some clients will set you away automatically after you have been idle for some time, and remove it when you next type something in the client. This can be very helpful.

Some clients will announce to every channel you are in and every person you’ve recently pm’ed that you are going away, and when you return. This is obnoxious, and should be turned off.

/names

The /names command will display a list of the nicks currently joined to the current channel. This is superfluous in Hexchat, Xchat, and weechat – all of which present a nicklist next to the traffic for each buffer – but irssi users may find themselves using /names more often.

/whois

/whois allows you to get some basic information about a user. The exact information presented varies from server to server, but their nick, hostmask, real name (if set), and idle time are typically included. The syntax is /whois HedgeWork to get info on the user HedgeWork.

nickserv and chanserv

Nickserv and chanserv exist to register and manage nicknames (nickserv) and channels (chanserv). Both are well-documented on the server (and their usage can differ from network to network depending on which server daemons are being used). You can /msg or /query either to get a list of commands and additional documentation, e.g. /query nickserv help or /query chanserv help.

Things to avoid

The following are either insecure, obnoxious, or outmoded, and should not generally be used:

Anything containing “DCC” or “CTCP” other than the CTCP “version” and “ping” commands (and those only if you really must).

/notice

Any command that sends coloration to the channel (though many clients and channels now strip colors, blinking, and other weird text effects).

Pasting more than 2–3 lines at a time to a channel. Instead, use a pastebin and give the channel a link to your paste.

Advanced (Optional)

SSL

Many IRC servers are capable of SSL-encrypting client<->server connections and/or accepting client auth via SSL certificate. The specfics vary per network, but if you are interested you can look up connection info on the network’s web page. I’m currently less than impressed with this capability as almost every client available uses GnuTLS to handle SSL. Hopefully, that will be phased out soon.

Screen and tmux vs. bouncers

Often, it is useful to maintain a connection to IRC even when your computer isn’t on or isn’t connected. This can allow you to read backscroll of conversations you missed, get messages from folks, or just reboot without annoying anybody with needless join and part notices.

Some people accomplish that ongoing connection by running a command-line IRC client on a server or other high-uptime machine inside a screen or tmux session that they attach to from their workstation or laptop. Others, like me, prefer to run an IRC bouncer.

A bouncer is a daemon that runs on a server, but connects to your various IRC networks like a client. Then, you connect your local client to the bouncer as if it were the IRC server. The bouncer is always connected, so nobody sees your client disconnects, and traffic you missed is sent to your client when you reconnect to the bouncer.

Pros:

You don’t have to miss what happens when you log off.
You won’t annoy anyone if your connection is flaky.
A bouncer can be configured to remember the channels you join or leave, so that you don’t have to manually maintain your autojoin list.
The IRC networks you connect to will see your bouncer instead of your local machine.

Cons:

It’s another thing to maintain.
The IRC networks you connect to will see your bouncer instead of your local machine.

If you feel like trying a bouncer, I highly recommend ZNC.

This is my biggest beef with “modern” alternatives such as Slack: they fall down on both support across operating systems and support for the blind, and break hackers’ workflows by requiring separate tabs, identities, or clients for each project one interacts with. ^[return]
Some people will hear you are on Windows and recommend a client called mIRC. DO NOT use mIRC. In addition to the fact that it has security issues and violates the IRC spec in ways that create extra work for network staff, mIRC is a favorite of script kiddies, and that’s really not the message you want to send about yourself. ^[return]
For some value of “private”. Pm’s are not broadcast to the channel like regular messages, but they aren’t encrypted, either. Some clients are capable of using OTR or GPG to perform end-to-end encryption for private messages, but the implementations are hellishly buggy. ^[return]

Heavy Training

Sun, 27 Feb 2011 21:51:00 +0000

This isn’t just a post about training hard in martial arts – though it is about that – it’s about training hard when one is very overweight. In the past year, I’ve lost clothing sizes even faster than I’ve gained belt ranks, and thinking back on the process, much of it was non-obvious. So, tonight I’d like to collect some of my thoughts where they can be seen by other overweight martial artists and their teachers and ukes.

If you can stand and walk, you can start training in martial arts.

I spoke to my sensei last summer about two martial arts sessions I’d been asked to lead at a local nerdcon. I was having a major case of imposter syndrome, being only an orange belt¹ at the time and overweight to boot. Sensei chuckled and said he couldn’t think of anyone better for the job. “As a general rule, the people who most need to study martial arts never will. Nobody in a room full of computer geeks and gamers is going to listen to a word I say, but you speak their language. They might listen to you.” Sensei was right on both counts.

The face of martial arts to outsiders is usually buff 20-something military men or deceptively agile short old guys. This has absolutely no relationship to reality, where I’ve trained with military guys, but also trained with a soccer mom, a painter, an accountant, an IT guy, a couple of high school students, a few elementary school kids, a law student, a lawyer, and so on. My sensei has a day job selling snack food, and the most intense guy in our dojo is a ponytailed cook whom Sensei has nicknamed “the hippie”. I’m an overweight single mom who writes code for a living. If I can do this, nearly anybody can. If you need help growing your dojo, it’s the oddballs you want to tap for PR duty – the best way to demonstrate that anyone can do this is to show people that others who don’t fit the stereotype already have.

Uniforms can be troublesome.

Gis only come in ten sizes, from 000 (tiny child size) to 7 (proportioned for an exceedingly tall, beefy guy). None of these are at all round. For the moderately overweight, choosing a larger size then hemming the legs and sleeves can work out fine. However, when I started studying at my current dojo, a size 7 gi top did not close properly on me. It’s incredibly embarassing to have to explain to Sensei that there’s no uniform you fit in. Dojos can solve this problem by making uniforms optional for their lowest rank, giving very overweight students the chance to learn to move and get into that first gi.

As if gis weren’t enough trouble, most stores don’t carry any activewear for women over a size 14 or 16. I’ve had very good luck with Old Navy’s Plus Size Activewear over the past couple of years. They don’t stock it in Old Navy stores, but their sizing is pretty consistent so ordering online isn’t a nightmare. To me, it’s worth the money to feel a little less self-conscious (and not chafe) when I train.

Excercises work differently when you are heavy.

So, you are out of shape. You don’t have the muscle you need yet, and you can’t do the exercises others in your dojo are doing, so progress seems out of reach. It’s not! The worst consequence of most heavy folks thinking they can’t do martial arts is that very few dojos have experience in scaling work-outs for heavier students. Case in point:

Not long ago, a gym junkie friend of mine decided he was going to help me improve my workout regimen. He came to my house and was shocked to find that I couldn’t do pushups. He was sure I just wasn’t trying. So, I had my 9-year-old son sit on his back and watched him fail to do push-ups. It’s amazing how fast the fit forget exactly how much more resistance every exercise we do has, just because we ourselves are heavy.

Thanks to a guy I met online who does understand how carrying extra weight changes the game, I eventually progressed from “can’t do any pushup” to being able to keep up with our class as long as I cheated by using my knees, and pulling off real push-ups a few at a time. I ended up telling that push-up story to my favorite uke – a thin brown belt – who gave me the most stunned look. He, too, had never considered that my push-up was like his push-up with weights added. He was very complimentary about my having pulled it off. :)

How did I do it? My online friend had me start doing push-ups at the bottom of a flight of stairs. At first I could only do them with my hands five stairs up. However, I did a set every time I went up or down the stairs, and each time I got comfortable doing sets of 8 I moved down a stair. By the time I hit the second stair from the bottom, I could manage cheater push-ups on the ground. I’m working on improving my regular push-ups now.

While most exercises work backwards – becoming easier as we lose weight and gain muscle, like push-ups – there is one amazing exercise that scales perfectly all by itself: swimming. Fat makes one more bouyant, while muscle is denser than water, weighing us down and making us work harder. Meanwhile, if your swimming feels a bit too easy, just up the pace until it’s right – the harder you push against the water, the faster you move. I’ve lost a great deal of weight and built a good deal of muscle on a routine of “swim as hard as I can until my lungs threaten to explode, swim slowly until I can breathe comfortably, repeat until I run out of pool time or start contemplating death, whichever comes first”².

Find someone who knows how to scale exercises to help you figure out what will get you from where you are to where you need to be. This is a rarer skill than it seems – most trainers, martial arts students, etc. have always been fit and don’t really grok how a fat body works – if someone tells you it can’t be done, or that anything more strenuous than walking will kill you, move on: they just don’t have this apparently rare skill set.

Be willing to push yourself. Your body will usually tell you what it can/can’t take. Never worry about how long you are working out – anything you can do for hours straight without falling over from muscle failure isn’t working you hard enough anyway – instead, judge by how your body feels. Muscle pain can be good; joint pain is bad.

Protect your joints.

Carrying a substantial amount of extra weight is very hard on one’s joints, especially knees, hips, and ankles. Don’t try to increase your weight loss with high-impact activities like running. Instead choose things like swimming that don’t put added stress on your joints.

Expect your balance to come and go.

Every martial artist must learn balance. Martial arts requires movements our bodies aren’t used to, and it can take a while for us to get a feel for how to get through these sometimes counter-intuitive motions without falling over, not to mention develop the muscle needed to actually do so.

Being an overweight martial artist adds a new wrinkle: as you lose weight, your center of balance will change! In the last year, I’ve gone through several cycles of improving my balance only to have it fall apart again. Make sure you are training something that challenges your balance at least every third day, whether your dojo has a class that day or not. This will minimize the time it takes you to adapt to your body’s changes because you will be training on much more incremental changes than if you only tackled balance every week or so. Having patient ukes and teachers really helps with this one. I remember spending an entire class period once drilling one particular kick to be able to do it without falling over…and that was before I drilled to get it on target! Then a few weeks later I had a wonderful spurt of weight loss and started falling over again.

Nothing beats a decent point of reference.

Like any student, an overweight student won’t always see how much he or she is improving. This is especially true for the ones who, like me, tend to spend most of their training time with people several ranks more skilled, and several hundred percent fitter than themselves. It’s easy to use others (who are also steadily improving) as a reference point instead of using ourselves, and feel like we aren’t making any gains.

One morning, it was just me and the brown belt leading class. Warm-ups began with jumping jacks as they always did when this person led, and soon I was hating life and silently lamenting how out-of-shape I still was, finally giving in and pausing to stretch my whining calves for a beat or three before continuing. The brown belt ended the jumping jacks and complimented me: when we’d begun training together, I couldn’t make it through the usual thirty seconds of jumping jacks without taking two breaks, however that day I’d gone almost two full minutes before stopping! He’d kept it going just to see how far I’d come, and make me see it. He also had the courtesy not to do this around other people, as he knows how self-conscious I can be about my fitness level.

A note to senseis and ukes

Overweight people are usually the hardest to sell on martial arts study, despite often being the people who most need it. As previously mentioned, the image most people have of martial arts study and martial artists isn’t very welcoming to those who aren’t already fit. You can help change that image by encouraging the oddballs in your dojo to be your front-line PR. Also, when you talk about the benefits of martial arts to someone overweight, focus on self-defense, comraderie, discipline, confidence, strength, etc. first – otherwise the overweight would-be student may file you away with every other weight-loss scheme he/she has heard of – and leave weight loss out of the equation until asked, or as a side note rather than a central bullet point.

There’s something worse than being clueless about working with an overweight student: being over-eager. Nobody wants to feel like “the fat kid” or a pet project. Be ready with good information when asked (especially useful is some knowledge about scaling exercises down when needed), but don’t push. Martial arts has a way of inspiring those who study to want to be better, and the things that make us fitter happen pretty naturally in the course of being a martial artist.

Apart from these few gotchas, being a fat martial arts student isn’t terribly different than being an average or thin one.

This is a comparatively low rank in Shorei-Goju Ryu Karate. Imagine a scale of -10 (white belt) to 10 (head of style), but with no zero in the middle. Orange belt is a -7 on this scale. ^[return]
Insert appropriate disclaimers about this not being a good idea if you have certain medical conditions that could make that contemplation of death suddenly more urgent. ^[return]

The Drupal Support Gap

Fri, 21 Jan 2011 06:11:00 +0000

The Problem

We lack a clear and inviting path from discovering Drupal and learning how to use it to becoming an active and productive contributor. As a result, our most active developers are plagued by the support demands of intermediate users who have outgrown the Drupal.org forums and don’t know where to go. This effect is compounded both by our failure to attract and assimilate new highly qualified support-givers, and the myriad bad behaviors that newbies are learning in “newbie ghettos” such as the forums – behaviors that make it difficult-to-impossible to adequately support them and bring them into the wider Drupal community.

The Solution

Phase out the Drupal.org forums in favor of a more straightforward Q&A format resource.
Treat posts that resource as not just the answering of this question here and now, but building a useful searchable reference into the future. Be brutal in eliminating off-topic chatter and duplication (but as kind as possible in explaining why a question was closed) ala StackExchange.
Provide easy gateways from that resource to more active participation in the Drupal community: IRC, issue queues, doc team, translation teams, GDO, etc.
Improve the consistency of IRC and Q&A moderation by setting up a venue for moderator docs and discussion.

Rationale

Why is this important?

Most users’ first community interaction will be in the form of seeking support. That support-seeking experience will form the basis for how they interact with the Drupal community in the future.

If we can sufficiently improve our primary support venue, we can expect:

Fewer people trying to get support in inappropriate ways, such as by clogging the issue queues or demanding the personal attention of our most active devs every time they have a problem.
More new Drupal consumers to eventually evolve into active Drupal contributors.
Fewer behavior problems in IRC and the issue queues.
Users utilizing a search engine to solve their Drupal problems to get more useful results more often.
The Drupal learning curve to seem a little less onerous to new Drupallers.
Giving support on Drupal.org to suck a lot less for the support-givers.

What is wrong with what we have now?

The most active, experienced Drupallers are not active in the Drupal.org forums due to:

Poor signal:noise ratio
Too much overhead (read: time suck) in following discussion on the webforums
A format that does not lend itself to passive participation (i.e. following well enough, with a minimum expenditure of energy, that one would know if a question one actually wants to answer has come up)
The support mailing list suffers from the above, plus:
- Poor searchability
- Publication of participants’ email addresses
Intermediate and advanced questions in the venues above get too few helpful responses. There is no clear path to the “next level” of community participation and support. Thus, the post-newbie spillover tends to land in the issue queues, developers’ inboxes, and other places where it interferes with active development.
Though the forums especially, and to a lesser degree the support mailing list, are sometimes praised for their low barrier of entry due to the lack of behavior corrections present on IRC and the issue queues, this comes at an enormous cost. These newbies visit our supposedly newbie-friendly support venues, learn behaviors (reinforced in the forums) that are exactly what keep the experienced folks out, then are shocked to be treated with less than total acceptance in more active venues. After all, they learned the behaviors we taught them. Why shouldn’t they fit in? They’re doing it “right”.
Of course, some newbies never make it that far. Many get caught in the forum cul-de-sac and never find their way to the vibrant, geeky community that really powers Drupal.

What could we be doing better?

A new support venue should:

Make it easy for participants to understand the venue’s expectations, and how to best get support.
Encourage behaviors and approaches (RTFM, search, ask smart questions) that will serve one well throughout one’s entire Drupal career, not just among other newbies.
Be thoroughly indexed and easy to search. Ideally, this should be part of the main drupal.org search so that the support-seeker has as few places to search as possible.
Reduce duplication as much as possible so that answers are clearer and easier to find, and volunteers aren’t needlessly burnt out by having to explain how to log in to a Drupal site in maintenance mode 4,000 times.
Have extremely low participation overhead (that is, how much time you have to invest clicking around in order to ask/answer questions).
Have an extremely good signal:noise ratio.
Provide easy, obvious bridges to other parts of the Drupal community.
Be a great example of the culture surrounding Drupal, rather than an isolated ghetto not particularly representative of or connected with our community.
Address support questions across a broad range of skill levels and subspecialties within the Drupal ecosystem.
Successfully help people with their problems and questions regarding using, theming, and developing for Drupal.

Conclusions

In order to successfully address questions in all areas and at all skill levels, the support venue must be attractive to Drupallers with all levels of experience.
In order to be of the greatest utility to both individual Drupallers and the Drupal community as a whole, a community support venue should go beyond just answering the question at hand: it should act as a reference for future support-seekers to find, and nudge people toward the behaviors and attitudes that will make their Drupal experience successful in the long run.
The Q&A format would be a huge improvement over current venues for Drupal support, specificially because it:
- Has a good track record. Drupal questions are frequently asked and answered on StackOverflow, and there are nearly 200 people committed on a proposal to add a drupal sub-site to Stack Exchange. (No, this site isn’t going to be created, for reasons beyond the scope of this post.)
- Has low participation overhead, while still being very searchable.
- Helps teach newcomers the mindset that this venue is a place to get things done, rather than a place to visit (as forums tend to lead them to believe).
- Puts moderators in the position of being able to close questions for not being real questions, for being duplicates, etc. without the lashback of confused forum users (who generally have expectations based on experience with discussion forums, not support venues).
- Is an easier format from which to bridge users to proper IRC and especially issue queue behavior: the Q&A format is, in a way, an issue queue designed solely around support issues rather than coding, docs, etc.
NO support venue will serve the purposes described above without consistent, appropriate moderation. Consistency would be greatly increased if moderation procedures were documented, and if moderators had a place to privately sanity-check borderline situations before acting. Additionally, moderation standards should be set with the focus on encouraging the right attitudes and behaviors all the time, rather than letting things go until these poor attitudes become expectations and these poor behaviors become habits.

Prerequisites

Tue, 04 Jan 2011 17:53:00 +0000

I was recently asked what one needs to know before becoming a Drupal developer. It’s a tricky question, both because Drupal draws strength from the diversity of our community, and because it’s hard to pinpoint the precise point where one becomes a dev. Below is my attempt at an answer; feel free to suggest additions or changes:

The Basics

Have Patience

Rome wasn’t built in a day, nor will your Drupal-fu be. Prepare for trial and error; it’s part of life in the open source world.

Speak Fluent English

While Drupal itself has been translated for use in many languages, the lingua franca for development is English. English is spoken in the issue queues, on the [contributor IRC channel)(irc://irc.freenode.net/drupal-contribute), and at DrupalCons. If you don’t speak, read, and write English fluently, you will miss out on most of what is going on, and you will never reach a high level of Drupal developer-fu.

Use Drupal

You might think this goes without saying, but we do get wanna-be devs who don’t really grok what Drupal is or how to install it. It’s not necessary to be an expert Drupal admin before your first issue queue visit, but you should have installed drupal at least once and be be using it regularly.

Understand Your Computer

We’re accustomed to walking new contributors through using git, rolling patches, etc. We’d rather not have to teach you how to use:

Your OS (desktop and server)
A web browser
email
IRC
A syntax-highlighting editor with *nix-style line-endings
SCP / FTP
SSH
Your web server
- basic set-up
- configure domains
- view logs
Your database server
- basic set-up
- create databases
- create users
- dump and restore databases
- empty a database
- manage permissions
A search engine
A syntax-highlighting pastebin
An issue queue
api.drupal.org

Understand Markup

A basic understanding of HTML and CSS is needed, nothing extreme.

Understand Programming

It’s not necessary to come in knowing PHP, but if you don’t, you should have enough programming knowledge to pick up a new language quickly. Some of our devs also know Javascript (especially jquery), some don’t; its usefulness depends on what kind of Drupal work you like to do.

Finally, and most importantly,

Know How To Be Worth Helping

Ask each question in the right venue.
Pay it forward by supporting others, doing issue queue triage, testing patches, contributing code, and documenting things.
Be patient.
Observe good IRC/forum/ML/issue queue courtesy.
Have thick skin; take criticism well.
Ask Smart Questions
Don’t be a Support Leech.
Be willing to try things out.
Embrace Best Idea First

Bonus Round

You don’t really need to know this stuff when you first show up, but any of it that you do know will be helpful in some way:

HTML5
CSS3
Important Drupal concepts:
- node
- field
- taxonomy
- content type
- view
- panel
- user
- role
- permission
- module
- theme
Common Drupal modules:
- Views
- Panels
- CCK
- Sitedoc
- Pathauto
- Admin Menu
- imagecache and image
- wysiwyg
- Contemplate (and why it should never, ever be used for anything)
- Drush
git
how to roll or apply a patch
general troubleshooting skills
Drupal coding standards
Hacker culture

Resources

Drupal.org docs api.drupal.org Drupal.org Forums Drupal IRC Channels groups.drupal.org Drupal Planet Drupal.org Mailing Lists The Cathedral and the Bazaar The Jargon File Using Drupal Pro Drupal Development New Drupal Developer Toolkits W3C

Learn this--hacker culture is not optional

Sat, 11 Sep 2010 05:05:00 +0000

In the past couple of weeks, I’ve become increasingly aware of how much conflict younger open source projects I’m involved in have compared to more mature projects and projects run by folks with an extreme number of years in open source.

Then I had to explain to my housemate who Donald Knuth is… …and tell a fellow Drupalista what the Jargon File is… …and define “grok” for a colleague from the XMPP community… …and stifle a laugh while my 7-year-old tried to describe the wumpus to someone who should know better… …after which I read Eric Raymond’s recent post on the social utility of hacker humor.

Then I grokked.

In the projects that have been around for a dozen or more years, or those run by hackers who have been, there is a common culture and identity shared by all: we’re hackers. Whatever else we are – country bumpkins, urbanites, gay, straight, bi, male, female, transgender, a particular religion or nationality, old or young, single or married, parent or not, rich or poor – we are hackers, and all we need to know to work together is that we share that cultural bond of hackerdom.

In the younger open source projects, people are expected to recognize that we all come from different cultures. Not only are we to recognize it, but we are supposed to keep track of these cultural differences and be sensitive to them, which of course means being constantly aware of them. It’s all about differences, and “what do people think because I’m a $whatever?”

Meanwhile, I’ve worked with old-school hackers who were evangelical Christians – the kind that are as certain of the corruptive nature and future damnation of pagans as they are of the sun rising – and never had an issue. To those of us immersed in hacker culture, a hacker is a hacker; hackerdom provides enough common ground for us to work together and enjoy it. Without that, people end up bailing out of development discussion because of cultural claptrap.

Successful open source draws on talented people regardless of their religions, sexual identities and preferences, nationalities, disabilities, ages, and other differences. A couple of decades have shown that an extremely successful way to do that is to have – regardless of whatever else we are part of – a common hacker culture.

So for the sake of harmony and productivity, PLEASE:

Grok some Heinlein.
Hunt a Wumpus or two.
Remember to bring your towel.
If you have trouble remembering your towel, consider investing in sapient pearwood luggage.
Read The Art of Computer Programming (yes, the entire series).
Read RFC 1149
Play Adventure and/or Nethack.
Try to “man woman”
Keep in mind that Tux is not randy (that would be impolitic!) he’s full of fish.
And see what Alice and Bob are up to now. …because failure to look up any of the above via the Jargon File or a search engine kills kittens.

Also, to those of you already indoctrinated in the ways of the hacker, help the newbies around you get some culture. Trust me, it makes us all less isolated from one another, less at odds with one another, and more able to focus on the code.

I usually don't write about feminism, but...

Wed, 08 Sep 2010 13:10:00 +0000

I rarely write about feminism. When I have, it has to point out the foolishness of pushing non-tech women into technology in the name of gender equality, and trying to obscure the ability gap by pressuring competent women to spend too much of their time with the incompetent ones.

This time I’m writing about a brilliant article I came across on twitter (thanks @crell).

The tech industry isn’t closed to women, or girls for that matter. I was welcomed from the first day I wandered into the open source world, a self-conscious twelve-year-old farm girl with no feel for tech culture. The problem is that most 12yo girls don’t feel like spending their nights in front of a computer screen and line after line of code.

Jolie’s article talks about what should be obvious, but no one talks about – you can’t raise a little girl with nail polish and baby dolls then expect her to magically become obsessed with tech at university. I’m sure my chemical sensitivities (which caused extreme illness when I was exposed to clothing stores, new clothes, make-up, etc) had something to do with my becoming a geek.

Will all girls raised in a more varied existence go into STEM fields? Of course not. But those with the talent will discover it early enough to have it inform their goals and personalities.

Please read the article I linked above – it’s really worth the read. I’m going to stop in the office of my son’s elementary school this afternoon and offer to resurrect the junior high school computer club I used to run in an elementary version, so that more kids (boys and girls alike) can get into tech. :)

On Speculative Web Development Work

Wed, 07 Jul 2010 19:36:00 +0000

Many web developers, especially Drupal developers (who are in particularly high demand these days), won’t touch speculative work, period. With so many options available to us, we can choose work that will pay now over work that might pay some day. Still, not everyone who has an idea has the front money to build it. I have had some luck with speculative web development work over the years, and I thought I’d talk about why I do it and how I choose which projects are worth speculating on.

Not long after I diverted from my former career path to pursue life as a Drupal consultant, I received the following advice from a trusted friend: “Every good independent web developer has a project or two that is their own, besides what they do for their clients.” It’s turned out that he is right. Good speculative work gives me a chance to build a product I’m really happy with, free of portfolio-harming client compromises and NDAs. It also provides me with important experience following a project through its entire life cycle, so that I can jump into my consulting projects and easily answer “where do we go from here?” no matter what state the site is in. Finally, good speculative work gives me something potentially profitable to do when my consulting business slows down. Instead of having tons of work or no work, I have tons of paying work and a little speculative work to fill in the gaps, which is better than no work!

Despite the potential benefits of developing a few well-chosen speculative projects here and there, there will always be far more demand for speculative development than there are developers available to fill it. I, like every other developer who considers speculative work, must somehow separate the wheat from the chaff. There isn’t a formula for a successful project (if there were, we’d all use it and be rich) but here are some key points to consider before taking (or offering) a speculative web development project:

A typical speculative offer from an inexperienced businessperson looks something like this: Alice brings Bob idea and, if he’s very lucky, some management or sales skill (none of which matters until there is a product to sell or someone to manage). Bob does all of the development and theming work, provides server resources and possibly graphics. Alice offers Dave 2%-10% interest in the venture. Any developer would have to be insane to accept such a proposal. A typical web start-up with no physical product and a moderate amount of custom development needed will cost $15-$30k in funds, labor, or some combination thereof to get off the ground. Many need more than that. Alice’s offer has Bob putting in 100% of that investment (mostly in the form of his labor) for only 2-10% of the profits should the business take off. Meanwhile, Alice risks nothing (having an idea didn’t cost her anything) and walks away having either broken even ( 0 investment, nothing to lose) or with 90+% of the profits!

There are some developers who will work with someone coming in with just an idea. I won’t, even if I truly believe he/she has the next billion-dollar idea. I don’t want to work with someone who has nothing to lose. Having nothing to lose changes the way one approaches a business venture. As the old saying goes, we should all have a little skin in the game. That said, most people with an idea don’t want to give 50+% of the venture to their web developer, and few web developers can invest thousands of dollars in development time and other resources in a project from which they will at worst take a total loss, and at best receive only a tiny share of any profits that might come along some day.

What I have found works for me is to take a smaller share of a venture in exchange for a discount on any work performed on the project. This lowers my risk (I can still pay my bills while we get the site running), gets the other participant to invest something (the development money), makes start-up far more affordable for the “idea person”, and has slightly better odds than a lottery ticket of getting me a pleasant bit of extra money down the road.

Is this person/group someone I want to work with?

You’ll note that I haven’t even gotten to evaluating the idea yet. This is on purpose. The idea matters, but it’s only one part of the risk/reward equation. I take on very little speculative work – on average less than one project per year. I’m not going to do work with no guarantee on what the return might be and deal with a giant pain in the rear doing it. I only take spec. work from people I’ve worked with before. I don’t want to partner with someone and then find out he/she is a total crackpot, and I’m stuck with him/her! Whomever I am working with must above all be someone I know I enjoy working with. Who a developer will enjoy working with varies, but some things are (mostly) universally true: we want to work with people who value our work and expertise, and whose skills and expertise compliment our own. We don’t want to have to argue with you for hours to talk you out of a flash splash screen or auto-playing audio on the web site. Remember, one of the primary benefits to speculative work (from a developer’s perspective) is the chance to build a great product – the best product we possibly can. In theory, this is exactly why the “idea person” brings in a skilled developer to begin with.

Is the “big idea” here viable?

There’s no formula here (or if there is, I don’t know it) – for me, evaluating the “big idea” is tag-team between intellect and instinct. This is not to say that I have amazing business instincts – if I did, I would have a much more expensive car and a much bigger yard – but that I can usually tell if something’s really hinky. The intellect part of the equation means asking questions like “who is the target audience?” “what is the product?” “how is this different/better than the competition?” “how does this generate income?” “what kind of overhead is involved?” “is there anything out there on which we can gauge the potential success of this project?” and “how will our target audience find out we exist?”. Then I think of some other questions and ask them. Again, I must emphasize that I am not a business genius. I do, however, have years of experience watching web sites succeed and fail. If something is way outside my area of expertise, I probably know someone with the knowledge I need to guess if an idea will be worth my time. 90% of the time, when someone offers me speculative work, they either want to identically clone some existing, successful site, or they have a vague idea of making a web site about $something, but have not given any thought to how it will actually generate revenue.

Can my potential partner and I come together on a strategy?

A good idea, without execution, is just a daydream. I don’t do handshake deals on speculative projects – it’s too easy to get cheated (or just recall the deal differently) two years down the road when real money starts coming in. Stratagem #1 is making sure that who is putting in what, who is doing what, and who is getting what out, are all down on paper. We also need things like a working budget, a strategy for promoting the site, etc. Hash out the basics early on, when the cost for walking away is minimal to none. Make sure everyone has realistic expectations.

What happens if it all goes south?

If I can’t handle a project failing, I shouldn’t be speculating on it. Of the four speculative projects I’ve taken on in the last few years, one was a total loss, one made me slightly more than I’d have made billing normally for the time spent on it, and two have futures yet to be seen. The one that was a total loss financially, ironically, is the one from which I’ve taken the biggest gain. I was very new to the business world, essentially fresh off the farm where I grew up, and what limited experience I had was working for the military and a military contractor – which are a world all their own. Working on a venture capitalist (word I didn’t know before this project) funded project with a business-savvy partner was very educational!

Protection vs. Preparation

Fri, 25 Jun 2010 20:49:00 +0000

A 7yo boy was kidnapped from someplace in Oregon. It’s received the kind of coverage parents can only get when their missing child is cute enough to imply profitability to network news directors. During a one-year period studied by the DOJ (stat via missingkids.org), an average of 2,185 children were reported missing each day. Paring the news coverage down to the occassional poster child makes the subject more manageable, but it also gives the illusion that kidnapping is a rare occurrence.

Commentary I heard today from parents I know – really good parents – was all along the lines of “I just want to hug my kids and never let them go” and “it makes me scared to let my children go anywhere”. It’s an understandable impulse – as the parent of a kidnapped (and safely recovered) child, I certainly experienced the instinct to keep my child close at hand. Years later, I have an amazing and increasingly independent seven-year-old.

He’s got a year of formal martial arts training, and a lifetime of instruction on basic tactics. At seven years old, and as he grows up, Little Fish deserves both a little freedom, and the skills to deal with the unexpected. Even if he never needs to defend himself, he’s still learning discipline, gaining confidence, making friends, building character, and so much more.

No matter how we feel about it, we can’t keep our kids on a short leash forever – or at least we shouldn’t. Kids need independence in order to grow into confident, capable adults. Our job as parents isn’t just to protect our children: we must also teach our children to protect themselves. I cannot say enough about the benefits of martial arts, or of training with your child as I do with Little Fish, but if you can’t be convinced visit the dojo twice a week, you can at least teach your child some basic tactics for staying safe:

If you are being chased, do not hide. Remember, if no one can see you, no one can see if a BG (Bad Guy) steals you or hurts you, either. Instead, find a crowded place and ask someone there to call the police.
Trust your instincts. If someone, even someone you love and trust, says or does something that gives you a bad feeling in the pit of your stomach, talk to a grown-up you trust as soon as you can. Parents, your child MUST learn from experience that you will believe them when they tell you something is wrong, or they simply won’t tell you. This means that if they got in trouble for “no reason” or a kid at school pushed them, or whatever, no matter how small you MUST NOT blow them off. Look into it. Assume your child is telling you the truth until you have proof to the contrary. Most kidnappings and child molestations aren’t by strangers, they are by someone the child knows and trusts, someone the parents may trust.
Keep a safe distance from strangers, even friendly ones. It’s okay to hug or lean on or stand close to your friends, but if you do not know someone well, never let them inside your personal space. It is impossible to tell nice strangers from BGs – even grown-ups can’t do it – so you should always be at least one big grown-up step away from any stranger. This gives you time to run if they try to grab you or strike you, and they can’t do it without attracting attention.
Practice a commanding voice. If you say “no” or “stop” to someone, especially a grown-up someone, you must be able to show with your sound and your body language that you mean it. If you look at your toes and squeek out a soft “no”, a BG knows they can pressure or scare you into doing what they want. If you stand tall, look someone in the eye, and use a commanding voice, they know you are not an easy victim. When we practice this at the dojo, the difference between how fast we stop for an unsure voice and how we stop for a commanding voice and body language is incredible – even coming from a very slight, barely three-foot-high white belt.
Practice for emergency situations. Nothing is as scary once you are ready for it. Practice what to do in case of a fire, a severe storm, an injury, in case a stranger asks you to leave with him/her, or anything else you can think of. If an emergency happens, and you already know what to do, it’s that much easier to do it.

The Anatomy and Habits Of the Common Support Leech

Wed, 23 Jun 2010 23:50:00 +0000

Support leeches are a fact of life in the open source world. Some people don’t understand how to be worth supporting. Others are just so obsessed with their own short-term wants that they are willing to destroy the community they are trying to get support from in the process. Below are my observations, gleaned from years of actual support leech encounters.

Anatomy

There are two subspecies of support leech, however hybrids are not uncommon:

The clueless support leech is uninitiated in the ways of open source support, and possibly in IRC, mailing list, or forum courtesy in general. With proper education, some clueless support leeches can be persuaded to morph into community members – a completely different, non-parasitic, species.
The entitled support leech is hyper-focused on its own needs, and does not care to make the support process go smoothly for support-givers or others in need of support. This subspecies is the more persistent parasite (when compared with the clueless subspecies), as even when educated on “helping us help you” or even general courtesy, it will barrel forward, certain that only its own needs could possibly matter.

Habits

The examples below center around support leech behavior in IRC support channels, however the support leech’s habits are consistent across support venues, including mailing lists, web forums, IRC, MUC, and user group interactions. Unless noted, habits below are common among both subspecies of support leech, as well as most hybrids. The easiest way to tell the difference between clueless and entitled support leeches is to note their general level of politeness, and how they respond to correction.

Support leeches often require a show of support or expertise before asking a specific technical question. “Can anyone help me?”, “Is anyone there?”, “Does anyone use…?”, or “Who here knows a lot about…?” are common forms for this demand, but there are others. The clueless support leech often does this because it thinks such behavior is polite, or because it feels some trepidation about asking its “real” question. The entitled support leech, in contrast, is motivated by the feeling that its time is so incredibly valuable that asking a detailed question without a promise of help is beneath it. Community members, the support leeches’ non-parasitic counterparts, enter the IRC channel and immediately ask a detailed and complete technical question, so that they may be helped in the most efficient fashion possible.

A typical IRC channel has 2-4 community members trying to support 5-15 users at once, probably while trying to get their own issues handled. If for each of those 5-15 users we have to go through a round of greeting them, a round of telling them it’s okay to ask a question, and a round of explaining that we don’t know whether we can help until we know what we’re being asked to help with, we’re wasting five or more minutes per person, that could be dedicated to support – 4 volunteers trying to help 15 people over the course of an hour have 240 minutes to go around. That’s 16 minutes per person if we get straight to the support issue, and 11 minutes per person if we don’t.

Support leeches ask questions as vaguely as possible, so that support-givers must interrogate them in the process of troubleshooting an issue. The clueless support leech has no idea what information is relevant, and so may go the extra mile by including lots of irrelevant information (like what they were eating at the time), while not giving enough information about the problem to solve it.

Asking complete and useful questions is something of an art form, one that is learned with experience (by those not so entitled as to refuse to learn). However, the more complete the question, the better and more forthcoming a helpful answer will be. It is important to include at least what operating system the problem system is running, what version of the software in question is being run, versions of dependencies (if applicable), recent changes to the system (this stopped working since I…), and the precise symptoms being experienced (“it broke” or it won’t work” are not precise.

Support leeches generally will not consult existing documentation before asking for help. Clueless support leeches often lack an understanding of how to find relevant documentation. Entitled support leeches generally feel that they will dispose of their issue faster with a human support-giver walking them through it, and simply don’t care that this takes time away from helping other support-seekers. When confronted with the admonishment to RTFM¹, support leeches often fail to follow the advice.

Community members create documentation so that information will be easy to find and use, and to prevent duplication of effort. Community members who encounter an issue with a particular technology will check the documentation for that technology to see if an answer can be found there, and then do a web search on relevant keywords, before asking a live support-giver for help. Exceptional community members document things they have learned, so that future support-seekers can find the information and be helped.

Support leeches will often ask the same question nearly simultaneously in multiple channels, and/or repeat it unneccessarily. This is most typical of entitled support leeches who feel that their question is so important that their desire for attention far outweighs the inconvenience to support-givers who monitor multiple channels. Clueless support leeches display a variation of this habit in which they ask a question in one channel, give up an getting help there after just a few minutes, and then ask in another channel.

Community members will ask a question in the correct venue the first time, and then idle there for at least an hour in case someone becomes active who does know the answer. A community member will repeat a question only if about an hour has passed, or if they see a known topic expert suddenly wake up. If their question goes un-answered for a long time, community members understand that no one is active in the channel with the time/skills to answer, and will ask in another venue (mailing list, forum, etc.) or at a time when support-givers from a different time zone may be active.

Support leeches often go so far as to argue with support-givers.

The incongruity of asking someone for their expertise, and then argue with the proffered advice, baffles me to this day. However it is a common MO² among support leeches. Asking a probing question when advice doesn’t seem quite right, or simply not taking the advice are acceptable, but one should not be pugnacious with someone offering their time and expertise to others for free.

Support leeches are known for PM³ing support-givers without permission. This is an attention grab made at the expense of others seeking support, and is even detrimental to the needs of the support leech itself – but support leeches persist in doing it anyway.

Support should almost always take place in the public support channel. This way support-givers can juggle multiple support requests effectively, and recipients of support can benefit from the input of multiple support-givers. Additionally, PMing anyone without his/her permission on IRC is a lot like following a stranger to his/her car – no matter how “innocent” your intentions, you will still give off a creepy stalker vibe. Always ask permission before PMing someone you don’t know well, and only move a support discussion to PM if it either includes privileged information (such as login credentials) or has veered far off-topic from the channel in which it began.

Support leeches exhibit an inability or unwillingness use the /topic command in IRC to read a channel’s topic. This leads to them frequently breaking channel rules and/or asking questions in a totally inappropriate channel, where their question is naught but off-topic noise.
Finally, the most virulent form of support leech, the entitled support leech, as well as most clueless/entitled hybrids, are demanding and rude to channel denizens whenever possible. They fail to internalize the fact that they are asking for free use of others’ time and expertise, and that volunteers have no reason to spend their time on those who treat them discourteously. Free support venues exist because someone finds it rewarding to help others – the less rewarding the experience, the less support will be provided, either due to community members refusing to subject themselves to entitled support leeches, or to volunteer burn-out.

I sincerely hope that this information will help others in preventing and dealing with support leech infestations before they overwhelm their support venues. When time permits, I intend to follow up with a post on support leech encounters.

Refer To the Friendly Manual ^[return]
Modus Operandi or “mode of operation” ^[return]
Private Message ^[return]

Taxes are less about money than you think

Tue, 15 Jun 2010 08:05:00 +0000

Reuters reported yesterday that a bill about to be considered would raise taxes on investment fund managers, by treating some of their investment income like “regular” income. Will this raise a lot more money in the grand scheme of things? No. Why do it? Politics. It’s a way to look “tough on” Wall Street.

This week the unpopular people are the investment fund managers, so we are going to tax them extra, and not let them eat lunch at the cool kids’ table.

One of the reasons our tax system is so insanely complex is that it’s not designed to be about raising needed money, it’s not particularly “designed” at all in the sense that there’s some overreaching vision that has created a coherent system.

The tax system is our legislature’s favorite plaything. They take away money from whomever isn’t cool this week, and give it to whomever is. Meanwhile, in their great concern that we all be a little cooler, they tax ugly shoes (or whatever else they deem uncool) a little extra and provide tax credits for funky wallpaper (or whatever they think is cool). Since, like ditzy teenage mallrats, congress can’t be bothered to think for a minute about the fact that trends change constantly, and it really isn’t their business to try to rid the world of ugly shoes (or – gasp – that they may have horrific taste to begin with), the tax code is a pile of unrelated and sometimes contradictory snippets of fleeting fashion sure to rival any sixteen-year-old girl’s clothes closet.

Did you know that federal income taxes haven’t always existed in America? It was not until the Revenue Act of 1861 was signed into law by Abraham Lincoln, to raise money for the Civil War, that we had an income tax. We did fine without one for nearly 100 years.

You may be wondering why “capital gains” are treated differently than other types of income when it comes to paying taxes. We hear a lot about “capital gains” from the talking heads on TV, who seem to agree that there is some vague evilness about “capital gains”, but never talk about what it is or how it got that way.

Article I, Section 2, paragraph 3 of our constitution says, in part, ”…direct Taxes shall be apportioned among the several States…according to their respective Numbers…” “Direct taxes”, in a constitutional sense, are basically taxes on things you already own. So, if the federal government wants to tax things people already own, it must be done by taxing each state according to its population. The idea is that once you have worked hard and finally bought your family a home, the federal government can’t say “give us this much money every year or we’ll take away your home”. (States and localities have no problem doing this to you, of course.)

Now, what happens if something you own causes you to have more assets (stuff, money, anything worth anything)? This can be an “on paper” sort of income, such as if your house becomes more valuable over time or some knicknack you bought becomes a valuable collector’s item – you don’t actually have more money, because you aren’t selling your home or your knicknack, but in a legal sense it is income – or actual money coming into your hands, such as if you rent out a house you own, or if a farmer pays you to cultivate some of your property. If the federal government taxes that, is it taxing something you already own (a direct tax), or is it taxing new stuff you are getting (an indirect tax)?

In 1895, in a case called Pollock v. Farmers’ Loan & Trust Co., the Supreme Court said that income from things you already own (such as when those things become more valuable, or someone rents them) is a direct tax. That special income – income from things you already own – is today most often referred to as “capital gains”. Congress, because it doesn’t like being told it can’t tax things, soon passed the Sixteenth Amendment, which changed the constitution to allow Congress to tax individuals for all kinds of income, including what we now call “capital gains”.

There’s a political theory that says “we don’t like people who don’t work for their money, so we need to tax capital gains more”. It sounds good on TV! Unfortunately, it really hurts people. If you own a house, raise your children there, and want to keep raising your children there, but your neighborhood suddenly becomes more desirable, you may find that the house you bought for $120,000 ten years ago is now worth $200,000. That is an $80,000 capital gain! Do you want to pay taxes on $80,000? Is it fair to lose your home over it? Is it fair to go to jail over it? Remember, it’s “income” you “didn’t work for”.

Now, here’s the kicker: even if we did pretend that capital gains are all evil, and should be taxed like crazy, WHY should they be taxed differently for people with one job description than for people with another? That’s like saying “there was a plane accident this week, so we’re down on pilots, everyone who is a pilot will now pay extra income tax”. This week people are freaking out about Wall Street, and we understand what those people do less than we understand what pilots do, so it’s easier to make the argument while sounding good on TV.

At least the tax preparers, accountants, financial advisors, tax consultants, IRS auditors, and government beurocrats are all making lots of money trying to sort through all these exceptions and special cases.

Also posted to Political Illiteracy.

The Warrior Obsession

Sun, 13 Jun 2010 16:00:00 +0000

According to the latest ad for Kings Island amusement park, riding their roller coaster makes you a “ride warrior”. I guess we can add it to the list with “road warrior” and “war on poverty”. It’s standard identity advertising – that is, making people want something because they want to think of themselves as the kind of person who wants that thing. It’s ridiculous, and it sells. There’s a reason that the “warrior” image can sell Americans on just about anything these days, and it’s a symptom of a real problem with some pretty terrifying results.

There’s big business in selling tactical gear to people who don’t know how to use it, and convincing America that a thousand other mundane consumptions (roller coaster rides, taxes, etc) are empowering, but there’s nothing you can buy or ride, and nothing that the government can take from someone else to give to you that will make you a warrior. Unfortunately, consumption is how mainstream America approaches life.

The warrior ethos outright rejects passivity and non-responsibility.

The warrior knows that with a trigger pull, a well-aimed slice, or a powerful strike, he or she can end someone’s life. The resulting corpse will be equally dead regardless of whether the warrior meant well or not, so the warrior had better do more than mean well – he/she had better be right. In that moment, there is no one else. Inaction and action are equally weighty decisions – either can save a life, or end one.

The warriors I know do not live passively. They don’t whine about how “somebody” should fix education, or unemployment, or the crime rate. They mentor, teach and run for school board, they start businesses or share their skills with others, and they protect themselves and others. Mainstream America, by contrast, feels powerless and cynical – that’s how government has ended up in the role of national nanny – making decisions about food, education, housing, religion, showers, and more that used to be made independently by citizens across the country.

In Ethics From the Barrel Of a Gun: What Bearing Weapons Teaches Us About the Good Life, (worth reading in its entirety) Eric Raymond writes:

“The Founders had been successful armed revolutionaries. Every one of them had had repeated confrontation with life-or-death choices, in grave knowledge of the consequences of failure. They desired that the people of their infant nation should always cultivate that kind of ethical maturity, the keen sense of individual moral responsibility that they had personally learned from using lethal force in defense of their liberty.”

That “keen sense of individual moral responsibility” is lacking in our culture, and whether mainstream America realizes it or not, thirst for it is growing. We see it in the national obsession with action movies and video games, and the fact that people will actually travel to Ohio and buy $50 theme park tickets just to get a little closer to that cheezy “ride warrior” image and a little adrenaline. Consuming is the only “action” or “power” we “normal” citizens are supposed to want.

“To believe one is incompetent to bear arms is, therefore, to live in corroding and almost always needless fear of the self — in fact, to affirm oneself a moral coward. A state further from the dignity of a free man would be rather hard to imagine. It is as a way of exorcising this demon, of reclaiming for ourselves the dignity and courage and ethical self-confidence of free (wo)men that the bearing of personal arms, is, ultimately, most important.

This is the final ethical lesson of bearing arms: that right choices are possible, and the ordinary judgement of ordinary (wo)men is sufficient to make them.”

A mile wide and a half-inch deep

Tue, 01 Jun 2010 07:47:00 +0000

Martial arts has always been an important part of my life…in theory. In fact, the only thing more challenging that martial arts study, is trying to maintain some sort of coherent study while moving 11 times in 10 years (assuming you count temporary moves). Apart from some periods of exceptionally poor health, I’ve always studied something, but the something has changed many times based on local availability. Due to the irregularity of my study, and probably at least somewhat owing to my irrational hang-ups about sparring, my martial arts background is about a mile wide and a half-inch deep.

Sure, there are many arts on my “tried that” list, but the longest-studied received only a few months of my effort and attention. Some, I only have a few hours of exposure to as part of a larger retreat or event. I really like my new dojo here in Indianapolis, and hope to stay for the long haul. I want the experience and growth that comes with going beyond beginner levels. I want to challenge myself with something other than my ability to adapt to new learning environments, and getting over my fear of sparring for the 15th time.

This morning, after too little sleep, I found myself thinking about the silver lining to all of this: in trying so many things, I’ve gotten a good idea of what works best for me. I’ve spent time training in dojos large and small, US Army gyms, rural community centers, and my own front yard among other places, with teachers of many stripes. Lessons learned include:

Nothing feels as good as cool grass or as bad as ice-cold concrete for a long training session.
There are many martial arts worth studying; an exceptional teacher is a much rarer find.
It’s not how fancy the dojo is, it’s how clean the bathrooms are.
One should always take study seriously, and never take oneself seriously.
Everybody sucks. One is no longer a newbie when one can articulate exactly how much and in what ways one sucks.
There’s no such thing as too fat or too old to start. If you can move, there is a martial art worth studying.
Do fewer things, and do them better.
Every goal, every step on the journey, is essential. Earning that black belt is a worthwhile endeavor, but so is fitting into a gi for the first time since who-knows-when – the former won’t likely happen wihout the latter. People who wait to be accomplished before “getting serious” or training hard will not likely accomplish much.

I’ve read a couple of blog posts lately on how to choose the “right” style or dojo for you. Having done this way too many times, I feel the urge to put my two cents in:

If you associate the instructor’s pitch with either a cult, or an infomercial, RUN AWAY.
The popular advice to ask a potential teacher about his/her background and/or the style’s lineage is, to me, pretty silly from a beginner’s perspective. If you are well-versed enough to evaluate the answer, you don’t need to be told how to find a good martial arts program.
Talk to the teacher, about anything. If he or she gives the impression that he/she is listening to you, and giving straightforward answers to your questions, rather than trying to impress you, it’s an important and neccessary good sign.
Try it. Lots of newbies feel like they have to commit to a style or dojo, and must be uber-informed when they do. Heck, I still feel like this in a way when I move, even though I know it’s irrational. My biggest fear, because my son and I now train together, is that one of us will love our new dojo and the other will hate it, making the decision whether to stay or move on very unpleasant. I think I exchanged a dozen emails with our current Sensei prior to moving here1 and actually visiting the dojo. In the end, a dojo will feel like a good fit, or not, and a good teacher will not be offended by your trying their class and deciding it’s not a match for you.

Now for one last thought before I haul my sleep-deprived body off to bed: I know several martial artists who are far more experienced than I that will not touch or try anything other than their one particular focus of study. I think people who do that are missing out. I’m not suggesting that anyone adopt my scattershot path to personal growth through martial arts, but I think we all benefit from trying something different every now and again. An afternoon visit to a school of a different martial art2, a weekend retreat in a completely different area of study, or a casual “show and tell” between friends pursuing different disciplines can be refreshing, and may even help us look at our chosen art with new eyes.

Inside the Drupal toolbox.

Wed, 21 Apr 2010 05:00:00 +0000

Today’s BoF for new Drupal contributors went better than I could have hoped. I’ve seen three of the participants in the issue queue already! One thing that came up at the BoF session was taht new contributors aren’t always sure how to set up their dev environment and choose tools that will make playing in the issue queue easier

chx* nano, komodo, bzr, kubuntu
chx* lots and lots of good music is very important to get you in the groove (see my blog post on flow)
wonder95* MAc Book Pro, AMP setup using MacPorts, Komodo IDE with xdebug and FF Xdebug Helper extensions, prefer Git
jcfiala* komodo, mercurial. Either wamp or virtualbox to work in ubuntu.
sepeck* notepad++
joshuarogers* Geany
scyrma* debian, vim (and cgvg package), xdebug .. local lamp stack.
merlinofchaos* all my servers are CentOS 5 servers running apache/php etc. I use EditPlus as my editor and samba so that I can use my windows tools on the files. Most other stuff I do via putty to ssh to the linux server.
webchick* I use vim for most hacking, then Komodo when I need to deal with, like, Form API or node access. CVS for Drupal.org, Subversion for personal projects (probably eventually Git), Mac OSX, Skitch for visual patch reviews
mikey_p* XDEBUG
dmitrig01* oh yeah I use skitch a lot
webchick* XDEBUG!
ksenzee* Ubuntu, NetBeans, xdebug
cwgordon7* I run windows xp with wampserver set up. I have xdebug there which helps. I sometimes use eclipse, but mostly I use notepad++ for more lightweight code editing

I run a LAMP stack on my local machine, do my revision control with git, edit in nano or gedit, and do my diffing, patching, etc on the command line. I use irssi to keep up on Drupal IRC. If I’m looking at a very large or complex diff that’s hard to follow in the terminal (command line interface), I throw it in meld.

I have a couple of little configuration items that help my work go a little smoother. For example, I use my /etc/hosts file to direct traffic for example.com to my localhost (and configure example.com in apache). It makes my dev environment look a little friendlier, and when taking screenshots or doing a demo on my laptop, I’m already showing a nice standards-compliant example.com.

The big thing is to do what works best for you. Try any or all of the combinations above, or make some of your own.

For anyone who ever doubted that martial arts study teaches kids hard work and discipline.

Tue, 16 Mar 2010 01:27:00 +0000

Today’s mail brought a very nice card from my son’s and my old Sensei and his wife asking how we’ve been since we moved, and whether we’d found a new place to study karate. I wrote a short letter in return, letting them know that our new city is treating us well, that we found a great new dojo (which I’ll post more about later), and mentioning my son’s new found diligence in practicing each day.

My son drew a picture for Sensei’s wife (a great lady who also helps with karate classes). I asked whether he’d drawn one for Sensei, too. He said “No, Senseis don’t want pictures. Sensei will like this,” handing me a second piece of paper. It read:

Dear Sensei,
I do my job at karate every day.

and was signed at the bottom.

One item removed from my wish list

Tue, 18 Aug 2009 01:34:00 +0000

Bye, bye, Amazon Kindle. I’ve been lusting after the Kindle DX for months now. I’d planned a purchase this fall as a birthday gift to myself, but no more. Amazon, a company whom I had generally trusted, has really disappointed me with this one

Publishers publish Kindle books.
Kindle users buy Kindle books.
Publishers feel flip-floppy and decide to stop selling certain ebooks.
Amazon reverses the sale of those ebooks, refunding the purchase price and deleting them from users’ Kindles and account archives without any warning or explanation.

Now, are you ready for a killer dose of irony? The books were George Orwell’s 1984 and Animal Farm.

One could keep whispernet turned off at all times and download content via internet to the computer for transfer via USB – this is something I planned to do anyway due to the general wisdom of maintaining fair use backups of all my digital content. However, I have already overlooked a great deal of DRM nonsense from Amazon, in the hope that it would soon go the way of the dodo like DRM on iTunes did once the sheeple finally figured out why it was bad. Worst of all is that Amazon (according to a phone call I had with one of their reps when Kindle 2 first came out) does not allow Indie authors the option of selling their titles via Kindle Store without DRM.

Amazon, I understand that the big publishing houses don’t have their acts together, but this has gotten out of hand. Big media has cried apocalypse every time content delivery has taken another step. They fought public libraries, radio, cassette tapes, photocopiers, VCRs, CDs and DVDs, digital music, DVRs, online media streaming, and now ebooks. They will adjust, the market will grow, and the world will continue spinning. Learn to stand up for your customers, or lose my business and the business of anyone whom I can persuade.

Another sign that the media just don't get it...

Fri, 19 Sep 2008 14:20:00 +0000

The Washington Post reported today that Cisco has purchased Jabber, the open instant messaging protocol used by Google, LiveJournal, MySpace, and many others. Unfortunately, the Washington Post isn’t smart enough to discern between the purchase of Jabber.com, a Jabber service company, and Jabber a.k.a. XMPP, the protocol.

One company bought another company – it happens every day, and usually isn’t the end of the world. Unfortunately, the story the Post told, that the protocol had been bought, would have spelled disaster for Jabber users and server operators worldwide. Jabber’s greatest strength is that it is open to the community – losing that would mean losing the ability for anyone to make an interoperable server or server software.

I don’t think anyone from the open source world who read this article believed it. I don’t think anyone from the Washington Post intended deception. I think that the author, editor, fact-checker, etc. involved with the publication of this piece are woefully, inexcusably out of touch with a common, everyday technology, not to mention the issues of intellectual property that mark the difference between buying a company that uses a protocol, and buying the protocol.

If anyone out there wonders why open source software and open technologies in general are having such a hard time breaking through to the average joe in America, this is why. The mainstream media can’t be bothered to learn this stuff, so Joe Average is saddled with their careless misrepresentations, rather than getting real facts. When, oh when, will it end?

I have minions!

Mon, 17 Dec 2007 20:57:00 +0000

I am almost sorry to see winter break drawing near. For the past two weeks, I’ve had the privilege of introducing an amazing group of kids to open source software. Inspired by GHOP, Google’s pilot Highly Open Participation contest, I’ve put together an extracurricular computer club for interested students at nearby Sandridge Elementary. We meet twice per week after school for an hour and a half. I came into this with the slim hope that the school’s new administration would let me shepard a couple of students through GHOP. Mr. Hollingsworth’s (Sandridge’s principal) and Dr. Sawyer’s (Sandridge’s superintendent) enthusiasm took me by surprise, and became a catalyst for the growth of a program that I hope will someday serve as a model for other schools.

Of the club’s eight active participants (not counting occassional attendees), seven are trying their hands at GHOP projects, alongside high school students from around the world. Most have chosen to work on projects for Drupal, which makes for good crossover activities with our two under-13s who have taken charge of creating the club’s web site.

So far, the biggest challenge for me is leading a group like this in an essentially unwired community. Students generally only have computer access at school. and few parents have regular access to email. Simple things like password resets can take days, and my students are at a disadvantage for things like GHOP. I must give them all credit, though – despite never before being exposed to basics like FTP, they are all jumping in the deep end and making amazing progress.

I have been lucky enough to round up some great speakers and corporate donations. We are still looking for a speaker in a graphic design field (preferably someone familiar with GIMP, Inkscape, Blender, or other open source tools), and donations of hardware (especially laptops, thin clients, servers, USB keys, blank CDs, and a tablet). If you can help with any of this, please drop me a line.

The open source world is as much a true meritocracy as I think I’ll ever see. No one cares who you are, where you are from, or what you have – they just want to see your code. Anyone can do anything.

OSCMS Summit and Drupalcon -- Day 2

Tue, 27 Mar 2007 04:00:00 +0000

I started the morning with a round of Drupal lightning talks – eleven topics in sixty minutes. dww even convinced me that if I ever actually have free time, I should pitch in a bit on project module.

Dries’ “State of Drupal” talk was excellent, though the audience as a whole didn’t seem to react well to the bit about eliminating the webmaster, developer, designer, etc. The whispers and whines in the crowd implied that some people found those statements threatening. I’m mentioning this because I didn’t feel that way, and I’d like my fellow geeks to know why: web technology is an ever-evolving industry. I’ve been doing system administration since the early 1990’s, working with open source software since 1995, and playing with web technologies on and off since the 1990’s as well. NOTHING is like it used to be, and I’m still here. So are a lot of other people. There was a time when the end-all and be-all of being a webmaster was smashing text and some basic HTML into static pages, then updating them by hand any time anyone wanted to make a change. Then came scripting and databases – suddenly you could code your way out of the repetition, and even make some editing and interaction (such as web forums) available to users. The hard-core coders moved on to writing scripts, the less nuts-and-bolts folks formed new niches as site moderators and documenters, and users could now contribute directly to content. Those less interested in adapting moved on.

This is what Dries was talking about when me mentioned “eliminating the webmaster”. On many sites, users began to take a leading role in entering content. Now we’ve moved from every site being scripted in isolation, to CMSes where a community of developers and themers can provide the tools for even non-coders to create web sites with all sorts of features. The internet is still evolving, and will be for the foreseeable future. I’m not afraid of the market for my talents drying up tomorrow, nor should anyone else be, as long as they are willing to learn and step into the next niche. In the mean time, keep innovating! If you doubt how much work there still is to be done, take a look at the Drupal issue queue and forums sometime.

Next came a talk on the Date API and Calendar modules. Karen’s presentation was absolutely wonderful, and I learned more than one useful tidbit about managing time, scheduling, and iCal feeds in Drupal. Steven Witten’s talk on jQuery convinced me both that JavaScript is every bit as hideously disgusting as I thought it was, and that jQuery makes it tolerable to add some JS tricks to things I’m working on (for those users who even enable JS) without feeling dirtied by the evils of JS code. Last, but certainly not least, I sat in the audience of the Live from OSCMS Summit Drupal podcast/netcast. There’s no need for a long description here, you can listen for yourself.

After the close of the summit, some of the Lullabot crew, a few other Drupal geeks, and I went out for Thai food. Still fewer of us ended up in add1sun’s hotel room, where much Drupal hacking goodness and a fair bit of socializing took place. We were joined by Leslie from Google and a couple of Joomla folks. I finally headed back to my hotel around 3am, my head buzzing with thoughts of projects to come, some curiosity about the aggregator module and what might be involved in cleaning it up, along with a healthy dose of laptop-related determination. I was still buzzing on the plane ride home. Those of you who have had the good fortune to fly off to a brain-bendingly interesting conference and there meet at least a dozen people you’ve worked with for ages but never met face to face, only to become even more excited about the project that brought you together know exactly how I feel. The rest of you couldn’t possibly imagine, so I hope you get to try it some time.

OSCMS Summit and Drupalcon -- Day 1

Mon, 26 Mar 2007 08:00:00 +0000

I started OSCMS by making hasty child care arrangements from my cell phone in the airport Wednesday night, due to my mom’s flight being canceled in the eleventh hour. Everything worked out, though I also spent a large part of Thursday on the phone, ducking in and out of sessions to coordinate the situation at home. My poor mother finally made it to my place late Thursday night. I’m still glad I went, though I feel pretty bad that my mom went through all of those delays and cancellations.

Rasmus Lerdorf’s talk alone made the trip worth it. He’s an even better public speaker than I’d heard, and I learned some new things about PHP, including the existence of some tools I can’t believe I didn’t know about. The OpenID talk was well done, but really didn’t tell me anything new. I changed my mind about “Theming Drupal” and instead went to chx’s talk on the new menu system. I am glad that I did. Not only did I learn quite a bit, but I ran in to webchick, the first of my fellow Drupalers besides chx to whom I could match nick, real name, and face. She is even more awesome in person than online. Her astute questions and comments added a lot to every presentation or discussion I saw her in. I certainly picked up a lot more than I would have had she not been there. Yahoo’s hospitality was top notch. They provided parking, meeting space, food, swag – all the essental materials. I even managed to get some extra swag for mom as a thank-you for all she went through to babysit for me. Earl (merlinofchaos) gave an outstanding talk about node_access. It was my favorite among today’s talks. After node_access, I attended the Drupal Search talk, but gave up on the internationalization talk part way through because I have a horrible time following people with strong accents when I don’t have enough visual cues to make up the bits I missed. I plan to catch up on the internationalization info online once the conference is over. I nabbed a great pick-up discussion in the common area after leaving, so the time block definitely wasn’t a loss.

The summit wrapped up for the day around 5:15, but I stuck around for a quick Drupal Dojo meetup. Following that, I joined sepeck, webchick, add1son, jjeff, eaton, Dries, dopry, chx, KarenS, merlinofchaos, and many others for dinner, drinks, and witty banter. Much fun was had by all, and if my head wasn’t already completely awash with new ideas after my day at the summit, it was when dinner ended. My only regret is not having a functional laptop to take notes, scratch out ideas, etc. on. (Not to mention the coding withdrawal I’ve had lately for the same reason.) I can’t wait for tomorrow.

DrupalCon & Open Source CMS Summit at Yahoo!

Sun, 11 Feb 2007 07:19:00 +0000

Update: I found a roommie, yay! I can’t wait to see you all at the summit.

I’m trying to figure out how I can attend DrupalCon 2007 at the Open Source CMS Summit sponsored by Yahoo! The summit and related events are free, so it’s mostly a matter of child care (got it covered) and affording transportation and the hotel stay. If any non-smokers in Washington would like to carpool to Sunnyvale, or any nonsmoking webmonkeys would like to split a hotel room with an easygoing lady geek, please let me know. I’m a night owl, I don’t hog the bathroom, and I’m happy sharing accommodations with geeks of any gender. Please note that I am deathly allergic to cigarette smoke, so not smoking in the car/room isn’t good enough – you really have to be a nonsmoker.

DIY Planner

Tue, 17 Oct 2006 18:51:00 +0000

I’ve finally given up on keeping my calendar, etc. on the laptop. It just doesn’t work for me. I’ve gone back to the system that got me through my youth juggling homework, work, extracurricular activities, volunteer commitments, family events, and some minor political activism – an 8” by 5.5” paper planner.

I caught a sale at Office Max, and picked up a leather planner binder with some undated starter pages and a year’s worth of dated refill pages, for about $15 more than I’d have expected to pay for just just the year of dated pages. Not bad, since the binder could have retailed for more than I paid for the entire shopping trip. That, of course, is one of my biggest reasons for trying to leave my paper day planner habits behind: they get expensive. I was lucky to have found a good bargain.

I’m very particular about my planner, and as luck would have it, the pages I like the best are among the most expensive on the planet: Day-Timer. The possibility of making my own pages has lingered for some time on a shelf somewhere in the back of my mind. However, the time required to come up with a layout I am happy with would likely be considerable, so the idea has remained shelved, until now… Enter DIY Planner, a great (Drupal-powered!) site offering organizational tips, and free templates for creating everything from the ubiquitous 8”x5.5” ring-bound planner to the super-light “Hipster PDA”, an organizational system designed to be printed on index cards and bound with a binder clip for maximum portability. With a computer, printer, and some basic office supplies (plus a binder, if you like that sort of thing), it is quite easy to create a fairly customized planner system for a fraction of the price of commercial ones, thanks to the DIY Planner templates.

I’m well stocked with Day-Timer dated pages through the end of 2007, however I plan to give DIY addon pages a try right away.

Yes, I've lost my mind

Thu, 28 Sep 2006 04:14:00 +0000

I’ve been thinking about it in an offhand, “Oh, I’d never have time” sort of way for a couple of years. This year, thanks to my good friend Steve, I’m doing it.

NaNoWriMo: National Novel Writing Month For 30 days, I’m taking a break from my various volunteer opportunities, from playing online chess while my son naps, and from spending all of my time trying to be productive. I’m going to write a novel, and, for once in my life, not care if it’s perfect. I’m excited, and apprehensive. I suppose now that I’ve emailed my mom to tell her about NaNoWriMo and encourage her to mention the NaNoWriMo Young Writers Program to teachers at her school, promised Steve I’d be his partner in crime, and blogged about it, I have to do it. That is the scary part. That’s also why I’m blogging about it – so I have to do it. 30 days… 50,000 words… caffeine and chocolate without measure… no excuses. NaNoWriMo.

RIP Rob Levin

Sat, 16 Sep 2006 11:48:00 +0000

Today, Rob Levin, aka lilo, CEO of PDPC and head of the Freenode IRC network, died of wounds sustained in a car-vs-bicycle accident a few days ago. He leaves behind his wife, Deborah, his son, Benjamin, and a legacy of cooperation, leadership, and tolerance. Rob will be missed by friends, family, and the FOSS community as a whole. You are not, and will not be, forgotten.

How NOT to Hire Me

Tue, 01 Aug 2006 04:17:00 +0000

Recently, I’ve recieved a number of job offers from people who make even this died-in-the-wool techie feel like business and marketing experts rolled into one. I’m all for finding work. As a matter of fact, I’m on the market right now. However, anyone who manages any of the following acts of cluelessness had better be starting their own job search ASAP. I present, for the sake of learning from one’s (or better yet, others’) mistakes, “How NOT to hire me”…

Misrepresent that you are prepared to pay me for my work. Posting on a forum entitled “Paid [web technology] Services” leads readers to believe that you are offering money in exchange for a service. If this is not the case, post elsewhere. If you are looking for someone to front the effort to launch your latest brainchild, in the hope of some compensation when it takes off, say so up front. Do not use the phrase “full time employee” unless you intend to pay me for approximately forty hours of work per week on an ongoing bases.

Try to present spamming 50,000 high school teachers as a marketing strategy. Yes, it happened. Today, I spoke to someone who wanted me to develop for his education-related portal project. When asked about his stated plan to leverage “access to a large educator community from other involvements”, he said that he had “acquired” a list of 50,000 high school teachers’ email addresses. I confronted him directly about his intentions, and he told me that he just hands over the list to a “marketing agency”, and doesn’t really know what they do with it.

Have no idea about the laws that effect your business. The person with the education portal had seemed very proud of his idea to create a portal that was a thriving community of teachers and students using social networking tools. When asked how he forsaw DOPA effecting his business model, he was at a loss for words. After I’d explained to him just what DOPA was, he still couldn’t grasp how a ban on social networking sites at schools would effect an education-oriented social network targeted at teachers and students.

Lack a basic understanding of your own business model. A woman came to me recently with an idea for yet another new e-businessed based on an advertising model. She didn’t know the difference between getting “clicks” and “conversions.” (A “click” means someone clicked on an ad, a “conversion” means someone clicked on an ad and purchased something, gave information, or otherwise did whatever the advertiser was hoping for.) She also didn’t understand why search-engine ranking was important.

Lack a business model. When I asked one potential employer “How do we make money off of this?”, he couldn’t answer me.

Cold-call me without knowing anything about me. I am not a C# developer, nor do I live in Colorado or have any idea why you think I’ll be “just perfect, ma’am” for the job you have there.

Return my call about your business venture from a bar or club at 9pm on a Saturday evening. The sounds of inebriated people whooping it up in the background does not make you sound professional; neither does interrupting my putting my son to sleep for something that doesn’t involve smoking servers and/or lots of blood.

Call me about your business venture while I am out with my family, decline my offer to return your call at a more convenient time, then order me to tell “that kid” to be quiet. I am a human being with a life. I am not your personal drone. If this is how you woo me into your employ, I’d hate to see how you might act if I actually worked for you!

Women???

Fri, 30 Jun 2006 05:52:00 +0000

It seems that having some sort of special program to “reach out” to women is the trendy thing in FOSS right now. Debian Women has been around for ages, but now we have Ubuntu Women, the Gnome summer camp for women, and Gentoo is talking about starting Gentoo Women. I suppose I should be impressed that in each case they say “women” and not “girls”. I’m tempted to check out some of the above groups just to see what’s going on. I’ve pointedly avoided them thus far because I totally and utterly fail to see how they can be a good thing for FOSS, or a good thing for the kinds of people whose involvement most benefits FOSS.

In addition to being a FOSS geek, I have at least a passing interest and some experience in a number of other predominantly male activities, including politics, defense, motocross, home improvement, and automobile repair. At one time or another, I’ve been invited to a “girl group” or “women’s group” for each of the above activities, with the following results:

In an attempt to interest women who don’t consider themselves particuarly savvy in a certain area, the well-meaning group de-emphasizes technical aspects of the activity. Most involved women never learn to hold their own and instead just kind of wander along the margins, or leave the activity altogether.
The very existence of a “safe” venue for women implies that other venues are not safe, and increases the social divide between men and women. Frankly, if you are afraid to talk to half of the population of this world, you need a therapist.
They encourage men to bring their girlfriends/wives/mothers/sisters/whatever along in the hopes that the woman in question will learn to love the activity and share it with the man who brought her, then dump the women in a group together so that they can further re-enforce the behaviors and perceptions that keep them from interacting comfortably with groups of men or groups of mixed gender.
Capable, interested women are encouraged to have some sense of loyalty to or responsibility for the “girl group” and end up expending most of their energy there instead of in the mainstream groups surrounding the activity. This makes it more likely for men to percieve women as less capable, because they are getting less contact from capable women, and when there is contact, the capable women find it harder to keep up with equally capable men because they are isolated from the main group.

I do feel that a lot of women are missing out on some very cool things, from computers to motocross to defense. To change this, I suggest the following:

Accept that if you drag any human to something they have absolutely no interest in, that person’s strongest first impression of the activity will probably be negative.
Give up on the girl groups. Encourage women, young and old, to be part of an interest group, not a special group for their gender.
When in a situation where being pegged as “the girl” will make it harder for you to earn respect, try the following: if on an online or similar forum, try to use a gender-neutral nickname, if on the motocross track don’t take off your helmet until after the first race you do well in. At this point, you have the same respect you’d have been given if you were male (because most people assumed you were), and the discovery that you are a woman will increase the mens’ perception of women being capable, and women who are the timid type will go “wow” and just might be inspired to follow your example.
If you really want to be a “women in X” evangelist, find a potentially capable woman and mentor her. Avoid bringing in women who will never cut it just to even out the gender ratio. Such women increase the perception, among women and men alike, that women are less capable than men.

In the end, I’m not a “women in” anything evangelist. I’m a woman with some traditionally male interests, and I rarely have a hard time becoming “one of the guys”. I see very few men involved in my stereotypically feminine interests, such as quilting and rug weaving, and no one seems to think they are criminally underrepresented and missing out due to unfair gender stereotypes. I wish that people in general would quit being so hung-up on sex roles (enforcing them or acting contrary to them) and just live.

Edubuntu Membership

Wed, 07 Jun 2006 23:00:00 +0000

At today’s Edubuntu Community Council meeting, pygi (Mario Danic) and I were officially made Edubuntu members, each by a unanimous vote.

At the meeting, JaneW and others encouraged me to become more involved in the development side of the Edubuntu project. I am eager to do so, as that has been my aim from the beginning. I joined the Edubuntu Cookbook team as a way to test the waters before jumping into development. My past experiences with debian-edu had left me skeptical, and I didn’t want to again risk becoming invested in a project that was foundering under the weight of surrounding social politics.

The Edubuntu community is both lively and laid back in a way that even I find truly refreshing. I quickly became more deeply involved, particularly with Cookbook. While I do look forward to taking on a more technical role in the future, I’ve made a commitment to Cookbook that I must first see through. Cookbook is a wonderful and much needed addition to the Edubuntu documentation. The project has, unfortunately, suffered due to a high rate of volunteer churn over the past few release cycles. I’ve found myself in a leading role for the project, and I hope to live up to the trust placed in me by Mario and the others to get this done. Edgy Eft is due to release this October, and I intend to make sure that the first print-worthy edition of Cookbook is ready to release with it.