DaedTech

Stories about Software

Nov
24

By

RESTful Home Automation

Category: Home Automation Tags: , , | 2 Comments

Here are the general steps to get a REST service going on your Raspberry Pi, using Python. One thing that I’ve learned from blogging over the last several years is that extremely detailed, granular how-tos tend to be the most yawned-at posts. So this is just a quick overview of how you can accomplish the goal without going into a lot of detail. If you want that detail, you can drill into the links I’m providing or else feel free to ask questions in comments or via email/twitter.

  1. Go out and buy these things: USB transceiver, plugin transceiver, lamp module (optional)
  2. On your Pi, install apache with sudo apt-get install apache2.  This is the web server.
  3. Also on your Pi, install web2py with sudo apt-get install python-webpy.  This is the module that makes setting up a REST service a snap.
  4. Install some driver dependencies (I will probably later roll these into what I’m doing) with “sudo apt-get install libusb-1.0 python-usb”.  Here are more detailed instructions from the page of the home automation python driver that I’m using.
  5. Follow the instructions on that page for disabling interfering kernel drivers.
  6. Give your user space account permissions to hit the USB device from the referenced instruction page, but note a typo where he says “sudo nano /etc/udevrules.d/cm19a.rules” and you really want
    “sudo nano /etc/udev/rules.d/cm19a.rules”.
  7. Now go get my stuff from github and run a web server using python rest.py <port>

That’s all there is to it.  Right now, at the time of writing, you would go to http://<your pi’s ip>:<port>/office/on to basically turn everything from A on.  A and office are both hard-coded, but that’s going to change in the next few days as I grow this service to support adding rooms and lights via PUT, and storing them as JSON documents on the server.  You’ll be able to add a light with PUT, supplying the room, light, and X10 code, and then you’ll subsequently be able to toggle it with http://pi:port/room/light/{on/off}

You can also just install Andrew’s driver and use it as-is.  It even has a web mode that supports query parameters.  The reason I didn’t do things that way is because (1) I wanted a REST service and (2) I wanted to be able to customize everything as I went while learning a new language.

Nov
21

By

The Hidden Cost of Micromanagement

Category: The Life of a Programmer | 2 Comments

I think everyone has encountered the micromanaging type at some point or another in their career. Most obviously or memorably, this might have been a boss who took the attitude, “no decision too small!” But it might also have been a coworker’s boss or just someone else at the company you had the misfortune to share an office with. If you’ve managed to avoid this your whole career, count yourself fortunate, but understand that there is a type of person out there that feels as though he is the only one capable of making decisions and then acts accordingly.

The up-front cost of this behavior is fairly obvious. It clearly doesn’t scale well, so micromanagers wind up being huge bottlenecks to productivity with all decisions essentially on hold until that person gets to them. Micromanaging also the effect of creating learned helplessness in those around them, rendering everyone else less productive. People learn that there’s no point in trying to have autonomy, so they check out and stop paying attention. Some will even engage in passive aggressive behaviors that harm the organization, such as malicious compliance. “You want me to ship this code as-is, huh? Okie-dokie.” (“Heh, heh, well, it crashes, but hey, you’re the boss!”)

Being subjected to a micromanager is hard to take and often stressful, so turnover is typically high in such scenarios. And that’s where a hidden cost comes in. People working under the purview of a micromanager don’t suddenly and automatically switch gears when their situation improves — they often bring their previous behaviors along for the ride. If you’ve ever seen the movie The Shawshank Redemption, recall the scene with Red in the grocery store when he gets paroled to work after 40 years in prison:

Red: Restroom break?
Boss: You don´t need to ask me every time you need to go take a piss. Just go.
Red (thinking to himself): Forty years I´ve been asking permission to piss. I can´t squeeze a drop without say-so.

Red’s boss and the grocery store are experiencing what I’m describing as the hidden cost of micromanagement. He has an employee so used to having his day micromanaged that the employee is maddeningly, annoyingly dependent. In your own travels, it’s easy to tell the signs of a previous victim of micromanagement: endless updates about details and inconsequential minutiae, constantly asking permission to do anything, non-stop preemptive apologies and general insecurity about work quality. That all might seem harmless, if a little sad, but the problem is that this lack of autonomy and willingness to take charge of situations has a real productivity hit for both parties. The new manager/lead should be focusing on bigger picture issues, such as removing impediments from the path of her team — she shouldn’t have to worry about whether one of her team members’ Outlook inbox is 80% full. That’s a meaningless detail that nobody should report to anyone, and yet tons and tons of micromanagement victims do.

It goes without saying that you should avoid micromanagement. It’s a terrible interaction and leadership strategy on its face that is largely the purview of people with psychological problems. But look for past victims of micromanagement and given them a hand or a leg up. Encourage them. Work with them. And most of all, let them know that they’re capable of making good decisions and worthy of being trusted to do so. Your organization will be much better off for it.

Nov
20

By

Lessons in Good Naming through Absurdity

Category: Language Agnostic Tags: , | 8 Comments

There’s something I’ve found myself stressing a lot lately to people on my team. It’s a thing that probably seems to most like nitpicking, but I think is one of the most, if not the most, under-stressed aspects of programming. I’m talking about picking good names for things.

I’ve seen that people often give methods, variables and classes abbreviated names. This has roots in times where saving characters actually mattered. Methods in C had names like strcat (concatenate a string), and that seems to have carried forward to modern languages with modern resource situations. The reader of the method is left to try to piece together what the abbreviation means, like the recipient of a text message from someone who thinks that teenager text-speak is cute.

There are other naming issues that occur as well. Ambiguity is a common one, where methods have names like “OnClick” or even “DoStuff.” You’ll also have methods that are occasionally misleading — a method called “ReadRecords” that reads in some records and then actually updates them as well. Giving this a simple name like “ReadAndUpdateRecords” would take care of this, but people don’t do it. There are other examples as well.

All of this probably seems like nitpicking, as I said a moment ago, but I contend that it isn’t. Code is read way, way more often than it is written/modified, and it’s usually read by people who don’t really understand what was going through the coder’s mind at the time of writing. (This can even include the original coder, revisiting his own code weeks or months later.) Anything that furthers understanding becomes important for saving minutes or even hours spent trying to understand. Methods with names that accurately advertise what they do save the maintenance programmer from needing to examine the implementation to see how it works. When there is a standard like this through the entirety of the code base, the amount of time saved by not having to study implementations is huge.

Toward the end of achieving this goal, one idea I had was a “naming” audit. This activity would consist of the team assembling for an hour or so, perhaps over pizza one lunch or evening, and going through the code base looking at all of the names of methods, variables, and classes. Any names that weren’t accurate or sufficiently descriptive would be changed by the group to something that was clear to all. I think the ROI on this approach would be surprisingly high.

But if you can’t do that, maybe a more distributed approach would work — one that combines the best elements of shaming and good-natured ribbing, like having the person who breaks the build buy lunch. So maybe any time you encounter a poorly named method in the code, you rename it to something ridiculous to underscore the naming problem that preceded it. You bring this to the method author’s attention and demand a better name. Imagine seeing your methods renamed to things like:

  • ShockAndAwe()
  • Blammo(int x)
  • Beat(int deadHorse)
  • Onoes(string z)
  • UseTheForceLuke()

I’m not entirely sure if I’m serious about this or not, but it would make for an interesting experiment. Absurd names kind of underscores the “dude, what is this supposed to mean” point that I’m making, and it’s a strategy other than endless nagging, which isn’t really my style. I’m not sure if I’ll try this out, but please feel free to do so yourself and, if you do, let me know how it goes.

Nov
14

By

The Joy of Adding Code to Github

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

These days, a good portion of my time is spent on overhead tasks: management tasks, strategy meetings, this sort of thing. In my role, I also am responsible for the broad architectural decisions. But what I don’t get to do nearly as often between 9 and 5 these days is write code. All of the code that I write is prototype code. I’m sure that I’m not unique in experiencing drift away from the keyboard at times in my career — some of you do too as well. As you move into senior or lead type roles and spend time doing things like code reviews, mentoring, etc, it happens. And if you really love programming — making a thing — you’ll feel a loss come with this.

Of course, feeling this loss doesn’t have to be the result of having more overhead or leadership responsibilities. It can happen if you find yourself working on a project with lots of nasty legacy code, where changes are agonizingly slow and error prone. It can happen in a shop with such intense and byzantine waterfall processes that most of your time is spent writing weird documents and ‘planning’ for coding. It can happen in an environment dominated by loudmouths and Expert Beginners where you’re forced by peer pressure or explicit order to do stupid things. It can happen when you’ve simply lost belief in the project on which you’re working or the organization for which you’re working. And it almost certainly will happen to you at some point in your career.

Some call it “burnout,” some call it “boredom” and some call it “losing your way.” It has a lot of names. All of them mean that you’re losing connection with the thing you’ve liked: programming, or making a thing out of nothing. And you need that. It’s your livelihood and, perhaps more importantly, your happiness. But, you can get it back, though, and it isn’t that hard.

Lightbulb

Recently, I decided to order a few more home automation pieces (blog to follow at some point) and reboot the design of my home automation server to make use of a Raspberry Pi and a REST service in Python. I don’t know the first thing about Python, but after the parts arrived, and I spent a few hours reading, poking around, failing, and configuring, I was using Fiddler to turn all the lights off downstairs (code on github now — work in progress).

There is nothing quite like the feeling of creating that new repository. It’s daunting; I’m about to start learning a new programming language and my efforts in it will most certainly be daily-WTF-worthy until I learn enough to be passingly idiomatic in that language. It’s frustrating; it took me 15 minutes to figure out how to reference another code file. It’s tiring; between a day job taking 50+ hours per week and the work I do with my blog and Pluralsight, I’m usually coding at midnight on school nights. But forget all that because it’s exhilarating ; there’s nothing like that feeling of embarking on a journey to build a new thing. The code is clean because you haven’t had a chance to hose it up yet. There is no one else to tell you how, what, or when because it’s entirely your vision. The pressure is off because there are no users, customers, or deadlines yet. It’s just you, building something, limited only by your own imagination.

And what a powerful feeling. If you’ve got a case of the professional blues, go out and grab this feeling. Go dream up some new project to start and chase after it. Recapture the enjoyment and the excitement of the desire to invent and create that probably got you into this stuff in the first place.

Nov
12

By

Asking Questions That Change The World (Or At Least Your Group)

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

I recently asked a semi-rhetorical question on Twitter about health insurance in the USA. Specifically, it seems deeply weird to me that health insurance is tied in with employment. I mean, your employer doesn’t subsidize your homeowner’s, auto, or renter’s insurance, so why health insurance? Someone answered that this was an end-run around salary caps and restrictions that just kind of stuck around. This rang a bell, and I looked it up. Here’s an explanation that details how caps on wages during WWII were circumvented by offering this perk and making it tax deductible, and so a long, nonsensical tradition was born, established, and worked into our culture to a degree where everyone thinks, “that’s just the way things work.”

Many people respond to hearing questions of “why do we do this, anyway,” with something like, “hey, yeah, that’s a good question!” Once it’s pointed out to them, they recognize that perhaps an entrenched practice is worth questioning. Others balk at the notion and prefer doing things that are traditional, well, just because we’ve always done it that way. There seems to be something about human nature that finds ritual deeply comforting even when the original reasoning behind it has long expired. White dresses on wedding days, “God bless you” after sneezes, using signatures to indicate official permission, and many more are things that we simply do because it’s what we know, and if someone asked you “why,” you’d probably say, “huh, I don’t know.”

In this manner, software engineering resembles life. Within a group, things that originally had some purpose, reasonable or misguided, eventually become part of some unquestioned routine. I’ve seen shops where everyone was forced to use the same diff tool, where try-catch blocks were required in every single method, where every class had to implement IDisposable, and more, for reasons no one could remember. Obviously, this isn’t good. In life, tradition probably has an anthropologically stabilizing role about which I won’t speculate here, but in a software group, there’s really no upside.

Accordingly, I don’t want to team up with people that blindly follow cargo cult processes. It’s bad for the team. But who do I want on a team? It isn’t just people that are willing to forgo routines and rituals when they’re called into question and evaluated. I want people that think to do the questioning in the first place.

Don’t get me wrong. I’m not looking for iconoclasts that question everything whether or not there’s reason to question it or that rail against everything that others want to do. I’m looking for people that take no assumptions on faith and are constantly using data and objective metrics to reevaluate the validity of everything that they’re doing, even when those things are regarded as “no-brainers.” I want people that get creative when solving problems, expanding their thinking beyond obvious approaches and into the realm of saying “what if we could do it without doing this thing that we ‘have’ to do?”

It’s this kind of thinking that gave rise to NoSQL; what if a relational database weren’t required for every application? It’s this kind of thinking that turned the internet from a way to view documents into an application medium; what if there were applications that didn’t require CDs and installers? It’s this kind of thinking that changes the world, in software and in life. I want people on my team that wonder why their employer pays for their insurance, anyway.

« Older Posts
Newer Posts »