I learned a great term this morning via this talk: The "Geocities of Things". Frankly, half of the little Arduino projects I do are probably Geocities-of-Things level; certainly not professional, but then again, that's kind of the point.
SkyNet
Dweet.io
BERG Cloud
Node-RED
This is a step past the others. SkyNet, Dweet.io and BERG Cloud are all transports with varying degrees of sophistication. Node-RED is an IBM Research project that lives on top of MQTT. It's not interested in transport as much as analysis. It's a tool to create a processing node.
http://iot-bay.org/
The latest list of interesting things to print:
I always forget how to make some of this work.
tlmgr conf texmf TEXMFHOME "~/Library/texmf:~/texmf"mktexlsr c:\texlive\texmf-local\fonts
texhash
updmap
Instructable by donedirtcheap. This is absolutely brilliant and I can't wait until my son is old enough to appreciate it. Or eat solid food.
(Manual) Calibration points for my Prusa I3:
G1 F3000
G1 X0 Y30
G1 X0 Y200
G1 X150 Y200
G1 X150 Y30More objects to make:
- The XCLIP, a Raspberry Pi (and PCB) mounting solution
- 22mm broom handle holder
- The ultimate PEG board accessory creator v1.1
Some notes on auto bed levelling:
- Automatic bed leveling and z offset howto (Level 2/3)
- Specifically calls out sanguinololu controller and marlin firmware.
- Z-probe holder for Makerfarm i3 with auto bed-level
- Might require some modification to suit.
Today's moments of jazz zen:
Here are a few useful fan/shroud projects from thingiverse:
Luke recommended Working Effectively with Legacy Code. A couple of slide decks from CalPoly and Object Mentor cover some of the high points.
Essentially, Feathers defines legacy software as software without sufficient test coverage. Which is a sufficient insight in and of itself.
I love the idea of tests as a software vice. When machining metal, a vice holds the work steady. You don't use a vice to modify anything. It doesn't perform any operation aside from keeping your work oriented and positioned so you can do something to it. Tests are there to keep your software from squirming.
Anxiety occurs when people try to do today’s jobs with yesterday’s tools.
-- Marshall McLuhan
(Via Paper Bits and Stowe Boyd)
Some guidelines from The Checklist Manifesto.
You must define a clear pause point at which the checklist is supposed to be used (unless the moment is obvious, like when a warning light goes on or an engine fails).
You must decide whether you want a DO-CONFIRM checklist or a READ-DO checklist. With a DO-CONFIRM checklist, he said, team members perform their jobs from memory and experience, often separately. But then they stop. They pause to run the checklist and confirm that everything that was supposed to be done was done. With a READ-DO checklist, on the other hand, people carry out the tasks as they check them off.
The checklist cannot be lengthy. A rule of thumb some use is to keep it to between five and nine items, which is the limit of working memory.
But after about sixty to ninety seconds at a given pause point, the checklist often becomes a distraction from other things. People start "shortcutting." Steps get missed. So you want to keep the list short by focusing on what he called "the killer items"--the steps that are most dangerous to skip and sometimes overlooked nonetheless.
All of these points could just as easily apply to something as non life-critical as software development. Developers are more apt to skip any oversight unless it is absolutely minimal drag, and are just as easily prone to solitary labour vs team coordination.