DaedTech

Stories about Software

Jun
1

By

Armchair Tour Guides and Presenters

Category: The Life of a Programmer Tags: | 3 Comments

The blog has been quiet for the last 10 days or so and that’s because, as I mentioned previously, I was heading off on vacation. We had a good time; a few days in Seattle, a brief stop in Vancouver, and then a cruise along the Inner Passage of Alaska, where we stopped in a variety of cities and towns. It was a lot of fun. I got to fly over glaciers and an ice field in a small sea plane, go on a whale watching boat ride, see glaciers calve up close, and get a good look at a lot of indigenous wildlife (yes, including grizzly bears).

A lot of this was accomplished via paid tours and group outings, and, apart from enjoying myself, I had the opportunity to bemusedly observe a phenomenon that I came to think of as “armchair tour guiding.” Let me explain with examples. On my sea plane adventure, we boarded a bus to head to the docking area where the planes were tied up, and our chaperon was a girl who introduced herself as a 2-week-since high school graduate and part time employee of the sea plane company. Not wasting any time, a blowhard on the tour started grilling her about the planes — their make and model, their type of engine, and various other things that skittered out of my consciousness since I’m neither a pilot nor do I play one after reading a bit of wikipedia. The girl looked a little flummoxed, and asked the bus driver, and between them they were able to answer at least some of the guy’s questions. “As you can see, I do my research,” the man said, not bothering to hide his smugness at all. I had the distinct impression that not having all of his questions answered was the exact desired outcome. He won a contest in which only he had competed and no doubt became an even greater legend in his own mind.

On another tour on the trip (they did an excellent job, by the way, if you’re ever in a position to check them out), we took a boat out into the bay near Juneau to watch humpback whales and whatever other aquatic life we might happen to see. Our guide was very knowledgeable, and we learned a lot about the humpbacks, other marine life, and the area in general from her. That is, we learned a lot when a handful of armchair tour guides on the trip could restrain themselves from vying for center of attention. There were several, but the ringleader felt the need, at times, to interrupt the tour guide to explain that she took a whale watching tour once in Monterey Bay and learned something different. I was pretty excited to hear from vacation-lady, since clearly, my girlfriend and I had shelled out $400 for the day to hear what some woman remembered of some California vacation she took once. That was superior in every way to hearing the expert we were there to hear. /sarcasm

Why do I harp on this on a technical blog? Well, because in a strange way it reminded me of being at technical user groups or conferences. In those venues, I’ve frequently sat in a room and listened to an audience member or two completely derail the presentation with questions about minutiae or grandstanding games of “stump the presenter.” I’ve sighed and rolled my eyes through long-winded ‘questions’ whose only purpose was clearly to brag: “So, how do you think this ‘Introduction to Java’ presentation can help someone who has written 16 compilers — someone like, oh, let’s say, me?” I tweeted about this once and vulgarly called it “Q&A-hole” but I think I like the ring of “Armchair Tour Guides” (or perhaps “Armchair Presenters” or “Armchair Experts”) better.

ArmchairPresenter

Don’t be that guy. Don’t be an armchair anything. It’s tempting for all of us, including me. Gameshows and games about trivia wouldn’t exist if possession of knowledge weren’t a fierce source of human pride, and it’s perfectly natural to want to showcase what you’re proud of, but this isn’t the venue. Even if you aren’t deterred by how rude it is to hijack a session, then be deterred by how unimpressed those around you actually are that you googled airplanes before a plane tour or that you once went on a tour somewhere like this tour or that you’ve played with the technology about which someone is presenting. Seriously — no one cares. Ask yourself who those in attendance have paid or come to see, and if the answer isn’t “you” then you’re going to have a really, really hard time stealing the show. People don’t walk out of those types of presentations thinking, “wow, I’m glad that one guy showed up and hijacked the presentation and man am I impressed with how much he knows!” They walk out thinking, “if that idiot is in another talk I plan to attend, I’m leaving.”

By all means, engage and ask questions of presenters, but, as an exercise, ask yourself whether others would find the answers to those questions interesting or helpful. If the answer is “probably not,” then wait until the presentation is over and engage the presenter one on one (or email him or her later or something). And, if you’re going to interrupt to share your own experiences, a better rule of thumb is, “don’t because no one cares.” Now, is this universally true? No. I’m sure there are examples you can think of where some witty audience member interjected a quip or corrected a presenter and it was actually valuable and helpful, but that is oh-so-rarely the case, compared to the number of times people do it, assuming it will be the case. I’m not offering hard and fast rules of existence, but rather guidelines for behavior that will make you far less likely to inspire annoyance and loathing in your fellow humans. It’s amazing how far common courtesy goes, sometimes.

May
23

By

Information Exchange Realpolitik: Pushers and Pullers

Category: The Life of a Programmer Tags: |

This is going to be another one of those posts where, in an attempt to explain myself, I may wind up putting my own bizarre pathologies on display for the world to see, but c’est la vie. I think that I can start most easily by saying that it drives me insane when people interrupt me to finish my sentences, though I’ve mostly mastered the art of completely suppressing any reaction for the sake of politeness. This is unfortunate and somewhat unfair of me since I tend to be methodical and precise with my words when speaking, often favoring a few beats of silence over verbal pauses or simply using a word that isn’t exactly the one I want. (As an aside, this does tend to come in handy because I write almost exactly the way I talk and vice versa, making scripted speeches sound relatively natural). In other words, I sort of invite people to finish my thoughts and then get annoyed when they do. People who finish the sentences of others I’ll call “information pushers” or just “pushers.”

I wanted to expand on my recent post about the great TDD debate to go into more detail about the real, underlying reason that people shouting their opinions at one another bothers we and one that goes well beyond simple matters of social decorum. It isn’t that I’m a shrinking violet, wishing that everyone would just stop with all of the shouting and be friends. It’s that I have an aversion to people spewing unsolicited opinions — I have an aversion to being around people who are serial pushers. It isn’t that I dislike the people, per se, it’s just that they’re hard for me to take in anything other than small doses. This is probably because I’m generally not a pusher and I’m only slightly a “puller.”

That last statement probably seems odd because any lover of symmetry would assume that, since I’m not a pusher, I must be a (as yet undefined) “puller.” But these things aren’t mutually exclusive. One can be neither or one can be both. I’ll define a “puller” as someone who tends to solicit information and opinions. You’ve probably worked with intense pullers in the past — people who can’t seem to go 10 minutes without asking you for help with something. Some people are pushers and pullers (I think that a lot of extroverts are both), blasting out opinions whether or not others are interested, but also genuinely curious about the opinions of others. A lot of gossipy people are both pushers and pullers.

Others are neither. Reclusive people, for instance, don’t care about your opinion and aren’t interested in telling you about theirs. This comes closer to describing me. I rarely offer opinions or advice unless people specifically ask me for them. That probably seems strange coming from a blogger who has been pumping out opinions for years, but if you think about it, by reading the blog, you’re sort of asking for my opinion. It isn’t as though I’m sending you an email telling you what I think about Java’s new implementation of generics or dropping by your cubicle with a cup of coffee and a “Hey… whaaaaat’s happening. Good.”

I have plenty to say if you ask, but I usually leave you be if you don’t. On the other side of the coin, I am a puller, but intermittently. I have a strong preference for trying to figure things out and master them on my own, and I tend to solicit help on problems only when I feel I’m in a blind alley. I’m more of a puller when it comes to passive assimilation of information — I read a lot of blogs, books, etc. But when I’m trying to solve a problem, I really only want help when I ask for it.

And therein lies the crux of the matter from my perspective. What happens when a reluctant/infrequent puller is working on a project with a huge pusher? Well, from the perspective of a slight-to-non-puller, what happens is that awfulness ensues. Someone I work with has a great expression that she uses that is appropos to this situation: “I asked you what time it was and you’re telling me how to build a clock.” This is a situation where a slight-to-non-puller is blocked, in need of some information from a pusher, and winces at the prospect.

Non Puller: Hey, can you give me the login credentials so that I can hit the web service from my code? I’m trying to —

Pusher: Oh, well, what are you trying to do? You probably don’t need a web service at all and could just get by with the old protocol we were using before. Let me take a look at your code. Yep, I don’t think you need any of what you were doing, and while we’re at it, I’ll just take the liberty of explaining to you that Java is a managed language, which means…

Non Puller (Mutters): Kill me, please.

Pusher: What was that? Anyway, like I was saying, programming can be summarized thusly…

Is this familiar to anyone out there? You need to ask Bill for just one tiny piece of information, and you know that as soon as you do, he’ll dash off to the nearest phone booth, don his Captain Obvious outfit, and return with a torrent of unsolicited information. So what do you do? You avoid Bill because he’s insufferable. Perhaps you make subtly snarky comments about him at lunch with the group. But what you probably don’t do is lose it and tell Bill that every word out of his mouth takes a fraction of a point off of your IQ. Even if you did, he’d probably interrupt you half way through your rant, impervious to your ire, to explain that IQ stands for Intelligence Quotient.

CaptainObvious

Don’t be Bill. Don’t be a pusher. It’s tempting at times for anyone. I mean, humans like expressing opinions. I’m no different, but I’m either wired or else I’ve conditioned myself to tend to do it only when solicited. When I feel like offering unsolicited opinions, I come here and vent them, but, as I’ve explained before, they’re not really being forced on anyone.

It’s not so much that I’m saying, “be like me because I’m awesome,” but what I am saying is that being a non-pusher has definitely helped me extensively in my career. I listen to people’s problems rather than interrupting them with solutions they’re not seeking. I let people finish their thoughts. I listen. And I offer opinions… when asked (for the most part, anyway — probably everyone is at least slightly a pusher, at times).

And, honestly, it’s opened doors for me. People tend to find me trustworthy and pleasant. Often times, near-strangers start telling me about rather personal problems. I tend to do fairly well in job interviews. A lot of it’s politeness and common courtesy, in my mind, but it all stems from avoiding tendencies to be a pusher.

So, here’s my take away from the situation. From an office realpolitik perspective, you should avoid being an extreme puller, since that’s annoying and it makes you seem incompetent. You have to be able to solve some problems on your own, but slight to modest pulling is the way of the world, since we don’t know everything. Ask judiciously and, when you do, demonstrate a good faith effort at solving the problem on your own.

But when it comes to pushing, I have no “go the middle route and avoid either extreme” advice. I can unequivocally say that I think pushing is a bad use of political capital in that it’s either all bad, or it’s a slight short term benefit for a long term detriment (i.e. you gain short term status as an aggressive expert, but eventually are thought of as a blowhard like Master Beginner). Spewing forth unsolicited opinions is like the influenza virus — the less you have of it, the better. Period.

So save that energy and do something useful with it. Heck, channel it into a blog. Or focus on being really good at what you do, which will have the nice effect of people actually soliciting your opinions, at which time you’re free to hold court. Respect is earned through actions and proof — not attrition.

May
20

By

How to Use a Code Review to Execute Someone’s Soul

Category: The Life of a Programmer Tags: | 31 Comments

I was having an interesting email discussion with someone not too long ago, and he made an offhand comment about code reviews that I noticed, identified with, and thought was probably a common experience. In essence, he said that he was yet to see them done well and be anything other than depressing experiences. For me, that’s been the case with most, but not all, code review environments. But before throwing the baby out with the bathwater, I’m hoping to write a how to guide for creating dirty bathwater in the hopes that you’ll read it and then not create dirty bathwater. By which, I mean, not give bad code reviews.

I have an odd personality characteristic that compels me to watch or listen to things over and over again if I find them compelling. That is, you might say, “hey, this song’s pretty cool,” and play it for me. If I really take to it, I pity you, because there’s a chance that I’ll play it over and over for like 45 minutes or so. I always feel sort of like a neurotic weirdo, so I try to play it cool and not do it in front of others too much, but, whatever. I’m getting less and less inclined to conceal my weirdness as I get older. I mention this as a segue to explaining the post title.

When I was younger, I watched the Al Pacino movie, “Scent of a Woman,” and I came to be very fond of the Al Pacino character, Frank. He said a lot of very memorable things in that movie, in kind of a gruff, misanthropic, wolfish, but nice-guy-when-you-get-to-know him way. I won’t go through all the quotes here, but I probably could. The reason I could is that I watch things enough times to commit huge swaths of them to memory, and this was the case with this movie. Indeed, this is the reason for the neurotic replay — I don’t just want to experience things; I want to command them and be able to recall and recite them at will later. Anyway, near the end of the movie, Frank gives this extended, loud, angry soliloquy defending his reluctant protege, who is on the precipice of expulsion from school. During the course of this, when talking about the effect that expelling him would have, he says, “you think you’re merely sending this splendid foot-soldier back home to Oregon with his tail between his legs, but I say you are executing his soul!”

What he’s referring to is that the boarding school is on the verge of expelling the protege for taking what he feels to be a principled stand and refusing to “rat out” a classmate in exchange for favorable treatment. The Frank Slade character is saying, in essence, “by punishing this kid for ethical behavior, you’re jading him and altering the course of his life and interactions with others.” And I think that this sentiment has a parallel in our world of programming: I have seen code reviews, things that should be a collaborative, learning experience, subvert group dynamics and result in negativity and hostility being paid forward. So, if you’re interested in a guide on how to do just that and how to turn optimistic, bright eyed developers into angry, cynical people, look no further, because I’m going to tell you.

Nitpick and bikeshed

I think most of us would agree that there’s nothing like spending an hour or two arguing about whether to use implicit typing or not or whether it’s better to trap a null parameter and throw ArgumentNullException or to just let the NullReferenceException happen organically. So, why not make all of your code reviews like that? You can forget about big picture concerns or pragmatic but philosophical discussions such as code readability and ease of maintenance and opt instead to have heated arguments about the little things. Anyone who had previously viewed code reviews as opportunities for learning and collaboration will quickly come to realize that they’re the place for heated disagreements about subjective opinions on details.

Be condescending and derisive

Pointing out a possible logic error is something that would go on in a healthy code review, but why stop there? If pointing out the error drives the point home, adding an “I can’t believe anyone could miss that” will really light a fire under them not to do it again. Since your code reviews are one-way activities, there’s no chance of someone on the other side of the table noticing your mistakes later, so you might as well let ‘er rip with the insults and really dig into their self confidence. They’ll learn to look forward to the day when they can follow in your footsteps and humiliate junior developers from right where you’re sitting.

ExpertBeginner

Make them interminable

If a little code review is good, a 10 hour marathon has to be great. Make sure you go over every line of code, every config file change, every markup tag, and every automated refactoring. Bonus points if you get things wrong in the history and review things that other developers checked in, taking the one in the review to task for code that he didn’t even write. Punish developers for getting their work finished by making them justify every character they’ve added to the code base as if it were a PhD Thesis defense.

Make the code reviews gate-keeper reviews that have to be “passed”

While you’re on the professor-student theme, you might as well go ahead and implement a policy that code has to “pass review.” That way, it’s not a team of professionals reviewing one another’s work and offering critiques, suggestions and insights, but rather a terrified junior developer trying to figure out if she’s good enough to check in code this release. Why not make every sprint/iteration/release just like taking the SATs and waiting for college admissions decisions for all involved? There’s nothing like wondering existentially if you’re good enough at life to have a future to keep the creative juices flowing freely.

Pass your opinions off as facts

Is it your opinion that static methods are better than instance methods? No, of course not. It’s just a fact. At least, that’s how you should approach code reviews. Think of all of your personal tastes in design patterns, coding approaches, style, etc, and then remove qualifying phrases like “I think that,” “I prefer,” or “In my opinion.” So, “I like pre-pending field names with underscores” becomes “you should pre-pend your field names with underscores” and “I find out parameters confusing” becomes “out parameters are bad.” And whatever you do, never back anything up with evidence or citations. When you tell someone that their methods are too long and they ask “what makes them too long,” don’t cite any studies about the correlation between method length and increased defect counts, just see the point about condescension and derision and say something like, “the fact that I’m the senior programmer here and yours are a lot longer than mine.”

Cover things for which checks could be easily automated

Why spend the day on productive tasks when you could sit in a cramped meeting room and pore exhaustively through the code looking to see if anyone committed the grave sin of using camelCase instead of PascalCase on a method. While you’re at it, count the lines in each method to see if they’re too long. Maybe even compute the cyclomatic complexity by hand and then have arguments over whether this method’s is 4 or 5, if you count the default of the case statement. Sure, there are tools that can do any of those things in seconds, but then you lose out on the human touch whereby junior developers are publicly rebuked for their mistakes instead of learning about them quietly and quickly from an automated tool.

Focus only on the negative

It’s amazing how just a little bit of positive feedback can brighten the whole experience, and there should be plenty from which to choose, since examining others’ code always presents an opportunity to see new ways of doing things. So, because of that, you have to be careful to keep it all negative, all the time. Use a whiteboard or a spreadsheet to list people’s mistakes, and the more, the better. Everyone should walk out of code reviews pretty convinced that they chose the wrong line of work and that they can’t hack it. Lights at the end of the tunnel are for cowards.

The Takeaway

I’m hoping it’s pretty obvious that this has been a tongue-in-cheek post, but there’s a serious takeaway here. It’s easy to allow code reviews to become negative, depressing and even political affairs. I’ve heard an awful lot of developers talking about hating them, and I think it’s for a lot of the reasons mentioned here — they’re needlessly adversarial and draconian, and people learn to dread them. I also think that there’s kind of a human nature tendency to “pick on the new kid” and make these things tiered affairs where the council of elders passes judgment and doles out tribal knowledge.

To keep code reviews healthy and beneficial, I believe that a concerted effort is required. I might make a post on this as a separate subject in the future, but some general ideas all revolve around staying positive and respectful. If you see things that could be errors, you don’t need to tell people they’re wrong, usually a “what do you think would happen if I passed null into this method” would suffice because the person will probably say, “oh, I didn’t think of that — I’ll fix it when we’re done here.” Allowing them to solve the problem and propose the improvement is empowering and so, so much better than giving them orders to fix their deficient code.

Look at code reviews not as exams or activities to prove the worth of the code, as-written, but as opportunities for groups of people to work toward better solutions. Instill a collective sense of code ownership instead of different people slamming their visions together and watching sparks fly. Reduce the friction in code reviews by complementing the activity with pair or mob programming. That way, more people are defending the work together than the group picking on a single person, and you also get the benefit of not spending days or weeks building up a defensive attachment to your code.

I have seen studies suggesting that the most effective way to reduce defect counts is not to try really hard or run static analysis tools or even (hold your noses, TDD fans) unit tests. The best way, bang-for-buck, to reduce defect count is through pair inspection. It’s far too valuable a tool simply to toss. We just have to be decent about it and treat one another like human beings.

By the way, if you liked this post and you're new here, check out this page as a good place to start for more content that you might enjoy.

May
16

By

TDD Chess Game Part 6: Starting with More Pieces

Category: You Asked For It Tags: , , , , | 7 Comments

I recorded this clip at a home, where I have a pretty old dual core processor that’s really starting to show its age when I have the video capture software running alongside VS2013 with all of my plugins. So, if you see the recording looking a little choppy in places, it’s because I edited out some places where I finished writing a test and was just drumming my fingers waiting for the test to go green or something. No need to show you completely dead time. Note to self — probably time for a new machine here soon.

Here’s what I accomplish in this clip:

  • Pretty up Rook.GetMovesFrom() a bit with Linq via refactoring.
  • Added Bishop class.
  • Implemented Bishop.GetMovesFrom()

Here are some lessons to take away:

  • You can write a test that’s green from the get-go if you want another data point prior to a refactoring.  Strict TDD says you need a failing test before you modify production code, but you can write green tests to your heart’s content.
  • Sometimes inheriting from a base class or implementing an interface is the quickest way to get from non-compiling because of an undefined method to having that method defined.
  • Just stubbing out a test method doesn’t constitute a failing test.  As long as everything is green, refactoring is fine.
  • I personally find that there are occasions when extracting a method or defining a common method is actually the simplest way to get something to pass.  So, even though that seems really like a refactoring, it can be your simplest path to get a red test green because it saves re-coding the same thing repetitively.
  • It’s perfectly fine to leave a working, but ugly, method and come back the next day/session to refactor.  Often times a much more elegant implementation will hit you in the shower or on the drive to your office, and you’ll make short of cleaning up the method when you have this fresh perspective.

And, the video:

May
13

By

Introduction to Home Automation Course Now Live

Category: Announcements, Home Automation Tags: |

I have received a comment or two here and there over the last year, asking whatever happened to the home automation posts I used to do. These were admittedly sporadic, largely because I work all day, then I moonlight at night with freelance gigs and Pluralsight, and then I blog regularly, and only then do I split my time between many hobbies. Only one of those hobbies is home automation. But, enough excuses, I decided a few months back. I’d merge two of these interests and optimize my life.

The result has been a few fun months in the making. I have created a Pluralsight course, now live, that is a detailed introduction to home automation that’s far more comprehensive than anything I’d have been able to convey on the blog easily. I think that this course probably makes up for a whole lot of posts that I otherwise may or may not have done. If you have a Pluralsight subscription and are interested, please go check it out and give it a good review if you like it. If you do not have a subscription, but are interested, email me at erik at daedtech and I’ll send you a free 7 day trial so that you can watch it and any other courses that interest you.

For this course, I used X10 and a Raspberry Pi. Some might ask why I’d do this when things like Google’s Nest are all the rage. The reason I chose this for a “fundamentals” course was for the same reason that programmers might start out with C if they’re serious about programming — it’s the original tech, and it’s an excellent platform from which to grow and really understand the various principles involved. Depending on how this course is received, I may opt to do others where I get even more advanced with X10, where I bring in other, similar technologies, or where I start expanding out to use more polished, turn-key products as part of a broader solution. We shall see.

If you’re not sure whether home automation will interest you or what, exactly, home automation is, this course will cover you. It goes into the back-story and it assumes you know absolutely nothing about the topic. Within a few hours of course time (and probably a week of real time since you’ll need to order some equipment), you can go from knowing nothing about home automation to making REST calls that turn on a light in your house, using your favorite HTTP client. And the cost of all of the infrastructure that you’ll need for this will have an upper bound of $100. But heck, watch if you’re just curious — you can always decide whether to order the stuff and follow along later.

I’ll leave you with the introductory section of my script to give you a feeling for the course.

What is Home Automation?

Let’s talk a bit about what home automation actually is.  You’re an intelligent person, and I have little doubt that the words “home” and “automation” used in succession probably conjure up an image in your mind, even if you aren’t already familiar with the term.  And whatever it is you’re imagining is quite likely accurate to some degree and at least a subset of what home automation is.

We all do a lot of manual things around the house.  When the sun goes down, we walk over to a wall switch and turn on a light.  If we suddenly feel cold, we go downstairs and adjust the thermostat.  If it hasn’t rained in a week and the garden plants are wilted and unhappy, we go out to water them.  If it’s too dark and depressing during the day, we open the blinds.  We dust, we vacuum, we scrub, and we clean.

Home automation is the process whereby we stop doing all of that manually.  We automate tasks around the house to varying degrees, either through mechanisms like remote control or through a centralized computer programmed with triggers and actions or even machine learning algorithms.  When the sun goes down, the house senses growing darkness and turns on the lights.  If we suddenly feel cold, we say into our phones “turn the heat up 2 degrees” and go back to whatever we were doing.  If it hasn’t rained in a week, the sprinkler system is smart enough to know the garden plants need water.  We needn’t bother opening the blinds because the house knows we prefer them open on sunny days and does this automatically.  We don’t dust, vacuum, scrub or clean because we have devices that do these things for us.

Rosie

There are various terms for the concept of home automation.  It’s been called “Domotics” when it involves some form of domestic robotics, or having a “Smart Home.”    Lately, the idea of an “Internet of Things” has had some overlap with the concept of home automation, though there is nothing that requires any of the automation be exposed to a broader network.  Here are some of the many concepts that fall under the broad heading of home automation:

  • Controlling the lighting inside and outside of the home
  • Temperature and HVAC, or heating, ventilation, and air condition, control
  • Media management, such as music and movie playing
  • Shading, which includes the drawing and opening of curtains, blinds, etc
  • Home security, including, but not limited to door locking, intrusion detection, and monitoring systems
  • Communications systems such as intercoms
  • Cleaning devices, of which the Roomba is probably the most iconic example
  • Appliance triggering and status monitoring

Needless to say, the subject covers a lot of ground, but it can be loosely summarized as the idea of automating previously manual household tasks.

A Quick History of Home Automation

If you are somewhat familiar with the concept of Home Automation, what probably comes to your mind is recent commercials such as one for an iPhone app that lets you turn your house’s lights off when you’re not at home or else perhaps Google’s recent foray into the market with the purchase of the Nest learning thermostat.  But it goes back a lot further than that.

The absolute precursor to any concept whatsoever of home automation was the introduction of electricity into the home, which happened on a widespread scale in the early 20th century.  In the same timeframe, RF remote control technology was first introduced by Tesla and would lay groundwork for later home automation in earnest.  The first half of the 20th century was accompanied by a couple of other important advances on the front of media: radio, and later television.  Still, by the 1950’s the most significant advances were largely in the imaginations of people who uses phrases like “home of tomorrow” to describe what they thought would be possible, though some remote operation of various devices was possible, and concepts like mechanical timers for lights and thermostats did exist.

In the 1970’s, a landmark first step toward the modern concept of home automation was taken with the introduction of the X10 protocol.  The concept was simple but groundbreaking and elegant – existing AC wiring in homes could be used to transmit signals between electronic devices.  In the late 1970’s, this idea had been realized with the introduction of a command module, an appliance module, and a lamp module that allowed lights and appliances to be controlled from a centralized point in the home.  It wasn’t long before these became available for retail sale.

Since that promising development, however, progress has not been nearly as rapid as a 70’s home automation enthusiast might have hoped.  Various niche commercial devices such as The Clapper have struck the public largely as curiosities rather than game-changing developments.  More elaborate home automation systems have remained largely the province of tech-savvy hobbyists and millionaires with consultants that setup boutique, custom arrangements.  Retail brands emerged, such as X10, which was named after the protocol, but also Z-Wave, Insteon, Zigbee, and others, but none of these has been able to last in retail stores, and the X10 corporation actually wound up going bankrupt in the early 2000’s.

In spite of its disappointing lack of movement over the last 30 years or so, the home automation market is showing some signs that it may truly be about to take off.  Of course, enthusiasts have been saying that for the last 30 years, and companies like IBM and Honeywell have tried without success to capitalize on this line of products, but these days, Google, Apple, Comcast, and ADT are all pushing products that are gaining more widespread adoption.

HomeAutomationHistory

I personally think that this is a very exciting time to get into home automation as a hobby.  As a society we’ve enjoyed such stunning technological advancement that phones we carry in our pockets have made maps, calculators and separate cameras virtually obsolete in one fell swoop, but we still turn our lights on and off in largely the same way that people in the late 1800s did.  I’d like to get a lot smarter about that and see it change, and I think that being a home automation enthusiast right now is probably comparable to being a personal computing enthusiast in the late 70’s and early 80’s.

So, Check it Out!

I’ll return to this subject matter here and there, the way I do with my other Pluralsight courses, so if you prefer the blog medium, you’ll still get to see some of the static content.  But what I won’t be doing is posting any of the video demos that are property of Pluralsight, so if you want the full experience, I definitely suggest checking out the course.  I take you through literally every nitty gritty detail of ordering parts, Linux command line setup, implementing REST with Python, and configuring Apache on the Raspberry Pi.  End product code is also up on github and downloadable through Pluralsight.

Enjoy!

« Older Posts
Newer Posts »