via Timoni.
Manufacturing guy-at-large.
Rubyday photos
From yesterday.
The Rashomon Effect
from Wikipedia:
The Rashomon effect is a term that has been used by a number of different scholars, journalists and film critics to refer to contradictory interpretations of the same events by different persons, a problem that arises in the process of uncovering truth.
The idea of contradicting interpretations has been around for a long time and has implications to ethics in journalism. It is studied in the context of understanding the nature of truth(s) and truth-telling in journalism...
It is named for Akira Kurosawa's film Rashomon, in which a crime witnessed by four individuals is described in four mutually contradictory ways...
In The Simpsons episode Thirty Minutes Over Tokyo, Marge comments that Homer liked Rashomon, but Homer replies that he remembers it differently.
I can only hope that the Rashomon effect colors my idea of the fallibility of my own perception in a profound way.
Hackweek Days 3-4
For reasons I'll get into below, I've got a bit less to show for the past few days.
The major theme of the past eight months of my life has been to form a new path towards long term stability, satisfaction and happiness. Some of that has been personal: I've spent a lot of time with friends; I've done my share of dating; I've been about as physically active as ever. But a major component has been my career.
I'm skeptical about anyone who claims a high degree of authority over their own emotional state. I tend to think that statements of ultimate preference (e.g. "I could never be happy in finance" or "I'm not satisfied unless I'm building something") tend to fall to post hoc ergo propter hoc fallacies. I want to be happy, and I refuse to let my career get in the way of my happiness.
That said, I have a particular set of goals vis a vis my career, and high on the list is to be appreciated for my ability to break down complex problems on a range of subjects. And it so happens that the types of problems I'm interested in solving are largely strategic rather than technical, and it so happens that I see the most interesting strategic problem solving happening in the tech world.
I have spent most of my adult life learning skills, but software development is not one of them. I'm probably more comfortable at a command line than the average person, and I can talk generally about a tech stack, but I am not a programmer. Except in certain contexts that fact doesn't bother me. I'm not an engineer either; nor am I a certified welder or a particularly well practiced machinist or carpenter. But I've got all of those skills nonetheless, and I've put enough time in on those types of projects to communicate well with people whose careers are dedicated to those crafts.
I don't want to be a developer any more than I want to be a bike mechanic. Skills are like tools - I like having them, but I'm wary of committing to any particular one, lest I view the entire world through a single lens. Some problems require a hammer; some require knowing the first damn thing about how serial port emulators work. I want to be a general purpose problem solver; I want to bring a wide variety of skills and experience to the table. I want my range of conceptual frameworks to be broad. I want to be intellectually agile.
Also - and I don't mean this to be trite - I like computers.
So Zach and I spent most of yesterday doing an overview of the tech stack required for a basic web app. We've got a couple of ideas that would fall across hardware and software, and it would seem that an RoR backend would fit our needs nicely. We'll still probably be programming our hardware in C, and will have a bit of HTML/CSS on top, but the meat of it - and, really, the fun stuff - would be Rails.
So today, we got about a third of the way through the Codecademy Ruby class. The Codecademy site is pretty slick. It's weird doing programming classes in this context, though. I took a few CS classes in college, but that was before laptops were ubiquitous, and I never really got comfortable with the format. Doing Codecademy is a lot cleaner - I like having the instruction and the execution all in one interface - but there's something about it I haven't gotten totally used to yet. I suspect that'll go away, but it was there a little bit today.
I'm excited to bang this class out over the next few days. I'd also like to be making concrete progress on a project, though, and it's hard to know how the two mesh. Not wanting to be a developer puts me in a weird position in the tech world. I'm a bit of a spectacle - a guy who swatted nails for a few years and can talk with some conviction about the benefits of climb milling. For the most part, that's fine with me, but the romanticism that the tech world has for physical objects - and old ones in particular - strikes me as a bit condescending and disrespectful. And all things being equal, I'd rather not be the one being condescended to.
But, whatever. Sorting hashes is fun, and I relish the opportunity to flaunt my command of logical structures. I'm enjoying learning a new skill, and if history is any guide, I'm sure I'll find a way to put it to use.
John Burroughs
A man can fail many times, but he isn't a failure until he begins to blame somebody else.
Scoop
via fffound.
Puff
via fffound.
xkcd on Internet Privacy
Perfect.
Josh Levin on Mediocracy
I think the larger issue that this points out is that everyone wants every team to have a great stadium, a beautiful downtown ballpark...I was incredibly sad when RFK stadium stopped hosting the Nationals here in DC. It is fine for not every team to have this impeccable ballpark...There should be some acceptance in American society for not everything being above average. There needs to be a below-average stadium, for us to maybe appreciate what we have in this world...A bad stadium with a good team: there's something to rally around there.
Josh Levin on the always excellent Hang Up and Listen podcast.
Hackweek Day 2
Unsurprisingly, it's trickier to troubleshoot a handmade PCB than it is to make a PCB by hand. We (and by "we" I mean Zach, with my mostly moral support) spent a bunch of the day ringing out one weird bridge to ground. It's frustrating work, and we ended up only isolating it partially before putting our mind to more tangible problems (we'll return to it tomorrow or Thursday).
Meanwhile, I spent a lot of the morning setting up a new domain to use for hosting projects. I also explored a few more APIs, and then spent the middle of the day refreshing my shell scripting chops. I took a UNIX class in college but couldn't invoke sed to save my life, and I suspect that our next step in getting some simple data transfer going will involve a serial port monitor, cURL and the Google Docs API. Suffice it to say that I've got a bit of re-learning to do before I can start learning again.
In the afternoon, we pulled out my XBees and did a refresher on their configuration. The new version of XCTU is available for Mac (thank god), but the interface is foreign to me and I had to familiarize myself before I could give Zach anything resembling a primer. By the time the evening rolled around, though, we had them up and running again, and Zach had played around with a high-temp temperature sensor enough to get it reading data to an arduino.
Tomorrow we'll probably throw a few of these things together - XBee, the temperature sensor, and a AC rated relay - and get a feedback loop going that will boil water and then shut the hot plate (the same one we did our reflowing on) off. I would like to then use cURL to schedule the whole thing by making a PULL request from Google Calendar, but we'll see how the afternoon goes.
Hackweek on! Spencer out!
That Transitional Time
From the past month-ish of my life. Click 'em to "embiggen," or whatever.
Hackweek Day 1
Zach and I started the week with The Public Radio.
When last we visited it, we had assembled - destructively - our first PCB. Today we started fresh, beginning with solder paste application.
We spent a little while trying to find a reflow curve for our solder paste, but gave up after Sparkfun (of course) fell flat on a datasheet (Note to self: get proper solder paste, and get it in a fucking syringe. Enough with the toothpicks.) So we found one for some Kester paste and shot for that. With my non-contact thermometer and our crappy hot plate, reflowing went damn well.
Then, we basically looked at it real close. I've got a line loupe, and recently threw down for an eyeglass style magnifier. Add a multimeter and we were able to figure out where all of our bridges were pretty easily.
On to fixing. We had a bit of trouble getting our wick + torch to agree with each other, but eventually got all (but possibly one - but it's going *down*) bridge fixed.
The net effect: The Public Radio is basically ready to have its bootloader installed. With any luck, we should get it programmed, tested, and bumping HOT97 tomorrow.
Meanwhile...
Lunch.
I spent a good part of my afternoon working to get data passed to a Google Spreadsheet. It turns out that the quickest way to do so is to create a form, which by default dumps text inputs to the next row of a spreadsheet. The standard format puts a timestamp on the first column and then text strings in each subsequent column. I wanted to start by passing data from a command line, mostly because I was pretty sure that implementing cURL was going to be straightforward. There's plenty of info about cURL and the Google Data Services API, but once you get to the complicated stuff, everyone's building PHP scripts - something that was a little much for me to take on for the afternoon. So I reached out on twitter, and within a half hour a friend from college got back to me with the syntax I was looking for.
The next step here (if you believe my pseudo-engineer ass) will be to built a PHP web app that can pass data to the same spreadsheet. Some of this will transfer right from what I did today, but the complexity level - and the potential things I can do with it - will increase pretty quickly. A PHP script will allow me to get and push data, and will also handle some computation as well. From there, I hope to add an additional layer - a basic embedded system that can post data from a wireless connection (likely XBee and/or GSM) directly to a Google Spreadsheet. I'm planning on getting the web app mostly built tomorrow (it'll be extremely simple, but will be the basis for a lot more) and hope to be getting data from a wireless device later this week.
The net effect: A good amount of progress today, capped off with a (somewhat...) interesting meetup in the evening. Plus, Zach got a little real about his twitter account.
Shit's real.
Grey pinstriped suits
I went to the headmaster of this school and I said, "I got an 800 in my math and I love art. Obviously I should go into architecture, because it's where the two meet." And this headmaster was very smart, and he said something to me that was extraordinary. He said "You know, I like grey suits and I like pinstriped suits. But I hate grey pinstripe suits."
And...I went to architecture school, and in fact I did *two* degrees in architecture before I realized that it was the grey pinstriped suit, and that *really* the mix of the [math and art] was computers. "
Nicholas Negroponte on the Seminars About Long-Term Thinking podcast.
If you need me, I'll be: This Week
This week is hackweek for me and Zach.
We've been working, slowly, on a handful of projects (products?). Some require skills we don't have; some require time we haven't had the guts and/or availability to put in.
I'm not bothered by the things not being done. I'm bothered by the skills unlearned, the effort not put in, the mental and emotional shit that I've put in my own way (nb. I'm not talking here about actual shit that actually happens - I accept that God laughs, etc. - I'm talking about self imposed shit, which I suspect is the lion's share of what most of us deal with most of the time). These are the problems that keep anyone - everyone - from taking care of the crap that matters most to them.
But fuck that, right?
In the interest of keeping ourselves on track, here's a brief overview of the week's agenda. Some of it's pretty hazy, but that's what you get.
- The Public Radio. We've got a couple PCBs and need to populate, reflow, program and test them.
- GSM data. Getting activities on an Arduino to a Google Doc, web app or Twitter feed.
- Temperature sensing. I got a high temperature waterproof thermometer a while back, but never got around to figure out the communication protocol. The plan is to be able to accurately test for temperature in a pot of boiling water, and relay that (via xBee/GSM/possibly Bluetooth & a PC) to a Google Doc, web app or Twitter feed.
- Barometric pressure sensing. Ditto for "Temperature sensing."
- Bluetooth. Getting data from a Bluetooth enabled sensor node to/from a PC.
- iOS dev. I just want to make a static app to start. Then build something that'll post data to a Google Doc/web app/Twitter feed.
- Google Docs API. See above. My impression is that it's easiest to send http requests to a Google Doc Form, which then dumps the data entered into a spreadsheet; we'll see.
- Twitter API. See above. Useful to trigger IFTTT actions... and just as a general exercise.
- Simple web app. I'd like to be able to trigger physical/electromechanical actions from a web interface, and then return the results to the same interface/a Google Doc/Twitter feed. For instance, I want to ask my web app what the temperature is at my xBee, and then have that temperature returned to my output streams. My plan for now is to do this in Ruby; we'll see.
That's the meat of it. In addition, I've got a couple of additional pet projects that'll need some attention:
- Get Zach to be posting shit actively.
- Some interesting bike-related design.
- Some interesting coffee-related design.
- Some freelance design.
- The Hardwired meetup on Monday.
- Bike rides MWF mornings.
- (Possibly, depending on my condition) running w/ dog TTh.
- Write up & publish a post re: Geoff Pullum & George Orwell.
- Post a big batch of photos.
I'm expecting it to be a good week.
From my own archives: On Content
What follows here is excerpted from a personal email I wrote earlier this year. It remains representative of how I feel about my own content creation - reckless enthusiasm and all :)
It appears slightly edited, for formatting and privacy.
- - -
The way I see it, there are really two types of content: curatorial and original.
There are a *lot* of curatorial blogs. The best, e.g. Kottke, are *excellent.* The worst are just commonplacing, which is actually pretty cool. I suppose you could argue that curation in a digital age should occur in Evernote or a similar document storing platform, but at that point, who cares. It's fun to have an aesthetic perspective, and if all you do is reblog photos, what's wrong with that?
Original content is, to me, closer to the heart. I like this quote, from a recent post by Keenan Cummings:
But regardless of wherever that team and those designers might fall on the criticism-worthy spectrum, I’ve learned to not question the intentions and sincerity of anyone. It hurts my work. It makes me cynical, competitive, fickle, distracted. My heart is in the work that I do, and I do better to assume it’s the same for others.
But that's just from my perspective as a viewer - and I certainly don't mean to imply that you're any of those things.
As a creator it is - at least for me, in the point in my career - even more important that I defend shitty content. Shitty content is "a way to make your soul grow." And if you want to work in the idea economy - or, I mean *fuck,* any economy where you need half a brain to succeed - the best way to show employers/clients that you're worth their time is to: 1) be able to show them *something,* and 2) have been creating that something for long enough that you've gotten halfway decent at it.
viz., my blog. My blog is silly - the things I write are *way* too long, and I'm too focused on creating a long argument that's based partly on something personal. I love writing this shit, but I'm still way green at it. And if I want to work at a place like [REDACTED] - and don't I? - then I *need* to be doing it all. the. time. Or else someone else who is will get the job from under me.
With regard to the light drowning out the stars: I think it's not nearly as bad as that, you just need to believe in it. Spielberg:
You shouldn’t dream your film, you should make it! If no one hires you, use the camera on your phone and post everything on YouTube. A young person has more opportunities to direct now than in my day. I’d have liked to begin making movies today.
But then again, consider who's talking. *Everything* is important to me right now, and remarkably little of it is getting looked at by anyone - let alone anyone of note. But I'm okay with that. Anonymity is good for me right now; it gives me the opportunity to make mistakes. Just give us all a year or two - once we've had a little more practice, we'll be showing *everyone.*
Valve on Management (or lack thereof)
While people occasionally choose to push themselves to work some extra hours at times when something big is going out the door, for the most part working overtime for extended periods indicates a fundamental failure in planning or communication.
From the Valve employee handbook. Lots of good stuff there, this is just an excerpt.
The 3D Printer version of an iPhone
The funny thing about Jobs' 2007 iPhone keynote is that they hype-iest thing he said turned out to be absolutely true. The iPhone isn't a phone at all: it's a totally revolutionary general purpose device.
Indeed, Jobs undersells the product. He says it's three things - an iPod, a phone, and an internet communications device. In fact, the iPhone is far more than that. It's the most general purpose user interface that we had ever seen, and one that enabled whole new categories of interaction - ones that go well beyond "internet communications."
3D printers are a wholly different animal, and they attack the problems of their industry from the opposite angle as the iPhone did.
To me, a MakerBot is to manufacturing as Tinder is to mobile computing. The iPhone is the layer that we use to access Tinder - and hundreds of thousands of other apps. It's a platform that enables digital interaction. MakerBot is just a node in a manufacturing paradigm.
The MakerBot Replicator is a tool that can be used for a very specific purpose - laying down beads of PLA and ABS to form a physical object. All the layers above it - the CAD software used to design a part, the web interface used to share and transmit those design files, the slicer used to translate a solid file into GCode, the embedded circuits and software that the Replicator uses to interpret and execute GCode - those will be what's driving changes of massive proportion to the way we think about product development, fabrication and distribution.
I believe that the rise of 3D printing will - and has already begun to - necessitate much needed advances in general manufacturing. But it's what 3D printers are driving us towards that's the real cool shit. The printers themselves are just nodes.
Chris Anderson on Digital Manufacturing
So, the "Seminars on Long-Term Thinking" podcast is awesome.
Today I became engaged in a conversation about the future of manufacturing. It was in the context of my parts organizer spiel, which I tend to think (self importantly) is the basis of one aspect of a revolution of how we manage data on physical objects. My interlocutor - with a totally healthy degree of skepticism - questioned the breadth of what I was suggesting (which, dear reader, you're just going to have to imagine for now - I don't have the energy to describe it in full here). He pointed to the required complexity of a unifying theory for parts management, and asked to the basic premise that a single standard for parts data was necessary or useful. It was a totally fair line of reasoning, and one which I defended myself against in a marginal way at best.
It was a pure coincidence, then, that I returned home and listened to an excellent talk given by Chris Anderson about digital manufacturing. I'll skip right to the chase here: Anderson begins by describing the NUMMI factory, which was jointly run by GM and Toyota from 1984-2010, when it closed due to market pressure and disputes between its owners. What follows below are Anderson's words (emphasis is mine; photos are from google images):
That was ten, twelve years ago. And then Tesla bought that factory...for a song, and put in place another factory. This is what the Tesla factory looks like:
What you're seeing there looks superficially the same. You're once again seeing machines making cars. But the difference is that the NUMMI machines were custom - each machine did one job. And they were extremely hard to program, and very inflexible, and once you got the whole factory up and running, you didn't want to change it - you just churned it out, one after another. And every machine was different. The welding machines were different from the painting machines which were different from the stamping machines which were different from the sewing machines and the testing machines and the wheel-applying machines, etc.
What you're seeing [at the Tesla factory] is that all of the machines are the same. These are Kuka robotic arms, from Germany...but the point is that they are general purpose robots. Every car can be different. And today, the American car [factories], they could be making washing machines on the same line. These robot arms have these racks of different tool heads, and they can change their functions simply by going and grabbing a different tool, so they can be a welding robot or a bolting robot or a door-closing robot or a wheel-applying robot. And there is hardly a person to be seen on the floor.
What looks like a subtle difference - single purpose, specialized robots vs. general purpose robots - is actually transformative, because fundamentally what this allows is flexibility. And flexibility, I'm going to argue, is the key winning factor of the 21st century. Because flexibility allows you to move faster, it allows you to operate in smaller batches, and it allows you to personalize. Every Tesla can be different...So this is what digital manufacturing looks like on the industrial scale, and that's why this era of automation is different from the other ones.
Anderson goes on to discuss - with infectious enthusiasm - the Maker Movement, distributed fabrication, and his expectations for how manufacturing, creativity, and product development will change in the 21st century. I highly recommend his full talk.
The net effect, though, is this: We need - and I plan on spending as much of my career as possible addressing - more general purpose solutions to the problems associated with hardware development and manufacturing.
My focus on general purpose technologies is a large contributing factor to my wariness about the hype surrounding 3D printing. 3D printing is not a general purpose technology. And every bit of energy spent working on producing a better 3D printer just distracts from the tools that I believe will truly revolutionize hardware development and distribution. We need broader, more powerful tools - tools which interface with all manner of manufacturing processes, and which designers and consumers alike can plug directly into.
The pieces are all here. 3D CAD has trickled down to all manner of consumers. Prototyping tools abound as well - and here I mean not some crappy FDM machine, but services like Rapid Machining and Shapeways. Distribution platforms are there as well, from Shapeways to Kickstarter to Etsy.
What's needed now is to unite these all with a single layer. When all of these platforms speak the same language - and when Makers, designers, and consumers learn to do the same - then the third industrial revolution will begin to take shape.
Saving this for later
I've got some thoughts about this tweet, by Tindie's Emile Petrone. I'll come back to it later.
3D Printers are the new cell phone. They aren't really getting better just cheaper. Time for the 3D Printer equivalent of an iPhone
— Emile Petrone (@emilepetrone) September 21, 2013
In related news, I'm looking forward to visiting the Maker's Faire tomorrow - and not for the dime-a-dozen FDM printers :)
The effect of total bullshit
This week I somehow came across the Seminars About Long Term Thinking podcast, and listened to an episode with the psychologist Daniel Kahneman. At one point in the discussion, he mentioned a study by Paul Rozin that investigated the effect that placing a label saying "cyanide" on a bottle had on participants' willingness to drink the contents inside.
The results of the study, copied here from the Journal of Personality and Social Psychology under the title "Operation of the Laws of Sympathetic Magic in Disgust and Other Domains" (emphasis is mine):
Cyanide label-1. In this procedure, we ascertain whether the label "sodium cyanide" imparts its quality to the substance it labels...Subjects returned to their seat at the table and were presented with two brown glass 500ml "chemical" bottles, each about one-quarter filled with a white powder, which was, in fact, sucrose. One had a typed label on it that said "Sucrose (Table sugar)," the other had a typed label that said "Sodium Cyanide" with a red printed "Poison" sticker below it. The experimenter said:
"Here we have two bottles with powder in them. The powder in both bottles is sucrose, that is, table sugar. These are brand new bottles that we just bought. They never had anything in them but sugar. This bottle (on the subjects' left) has a sucrose label that we put on it. It's a brand new label, that was never on any other bottle. This other bottle (on the subjects' right) has a brand new sodium cyanide label on it. This label was never on any other bottle and was never even near cyanide. Remember, sugar is in both bottles."
The experimenter set out two different colored plastic cubs, one in front of each bottle, and poured water from a glass pitcher into both, until they were about half full. Now, using separate, new plastic spoons for each bottle, the experimenter put a half spoonful of powder from the "sugar" bottle into one cup, and stirred it. The spoon was discarded, and the same was done with the sugar in the cyanide bottle, with a new spoon. The subject then rated, on the 200mm line, how much he would like to drink from each of the cups, and stated a preference between the two. The subject was then asked to take a sip of the sugar water from the preferred cup, and subsequently to account for his or her choice.
Cyanide label-2. We thought avoidance of the cyanide-labeled bottle might be motivated by doubts about the real contents of the bottle (though it seems absurd that the experimenter woudl try to poison the subject by offering a poison-labeled bottle). For this reason, in the second sequence, the subject himself labels the bottles. Initially, we performed this second test only for subjects who indicated a substantial preference for the sugar-labeled bottle's contents. The last 20 subjects, however, were run on this procedure independent of their results on the first sequence. The total N for the second procedure was 38; that is, 12 subjects were eliminated on the basis of their performance on the first cyanide test.
Previously used bottles and glasses were taken away, and two similar, empty bottles were brought out. The covers were removed, and sugar from a 5-lb box of locally sold "Domino" sugar (sucrose) was poured into each bottle (to a level of about one-third full). The subject was then given two peel off labels on a piece of paper. On read "Sucrose (table sugar)," the other read "Sodium Cyanide." (Through an error, this cyanide label did not have a red "Poison" sticker affixed to it.) The subject was asked to put one label on each bottle, in any way he wanted. Then, the procedure used for Cyanide Label 1 was repeated (mixing sugar water, rating of both solutions, indicating a preference, and sipping the preferred solution).
...
The sugar labeled as "Sucrose" was preferred to the sugar labeled as "Sodium Cyanide" by 41 of 50 subjects (p < .001). The mean difference between the cyanide- and sugar-label ratings was -30.58 (p < .001). When asked to explain their choice, the most common responses were reference to the label, and no response. Only 1 subject suggested the possibility that there might be cyanide in the cyanide-labeled bottle. The second cyanide manipulation, in which the subject put the labels on herself, showed a much smaller but still significant effect, with a net difference of 16.5 points between cyanide and sugar.
Wild.
This reminds me of the anchoring effect, described famously by Tversky and Kahneman in 1974 (nb. I was aware of this study previously - it comes up a lot in the literature on negotiation - but certainly couldn't have told you who the authors were. Before setting out to write this post, Kahneman's name would have meant nothing to me.). From their paper, "Judgment under Uncertainty: Heuristics and Biases" (emphasis is mine):
Insufficient adjustment. In a demonstration of the anchoring effect, subjects were asked to estimate various quantities, stated in percentages (for example, the percentage of African countries in the United Nations). For each quantity, a number between 0 and 100 was determined by spinning a wheel of fortune in the subjects' presence. The subjects were instructed to indicate first whether that number was higher or lower than the value of the quantity, and then to estimate the value of the quantity by moving upward or downward from the given number. Different groups were given different numbers for each quantity, and these arbitrary numbers had a marked effect on estimates. For example, the median estimates of the percentage of African countries in the United Nations were 25 and 45 for groups that received I0 and 65, respectively, as starting points. Payoffs for accuracy did not reduce the anchoring effect.
Studies like these are totally fascinating to me, and have the effect of reinforcing the skepticism that I am inclined to approach all statements which lack some method of independent verification. I also try to remain aware of the danger of taking self-reported data at face value: In my experience, people (including myself) are notoriously bad at knowing what's going on in their own heads.
For the intrepid among you, there's a bunch of great throwaways on anchoring on its wikipedia page. An excerpt:
Even when the anchor value is obviously random or extreme, it can still contaminate estimates. One experiment asked subjects to estimate the year of Albert Einstein's first visit to the United States. Anchors of 1215 and 1992 contaminated the answers just as much as more sensible anchor years. Other experiments asked subjects if the average temperature in San Francisco is more or less than 558 degrees, or whether there had been more or fewer than 100,025 top ten albums by The Beatles. These deliberately absurd anchors still affected estimates of the true numbers.
Insane. It's worth stating explicitly that, when entering into negotiation, one should be acutely aware - and wary - of anchoring strategies.