- Project Journal: Objects (Ian Bicking) — a view askew at the Web, inspired by Alan Kay’s History of Smalltalk.
- Speech Recognition for Arduino (Kickstarter) — for all your creepy toy hacking needs!
- Conductor (github) — a framework for testing distributed systems.
- Dataflow Syntax for Functional Programming? — two great tastes that will make your head hurt together!
"testing" entries
Four short links: 17 July 2015
Smalltalky Web, Arduino Speech, Testing Distributed Systems, and Dataflow for FP
Static analysis with C#
Complement a good testing program and identify hard-to-find bugs with static analysis.
Static analysis is, quite simply, any analysis you perform on software without actually running it. (Analyzing software as it runs is dynamic analysis.) There are many reasons to do static analysis, but almost all of them boil down to the desire to improve software quality. As a designer of developer tools, improving software quality by any means is keenly important to me.
Let’s consider compiler warnings. They are produced without executing the code, so the compiler is doing static analysis. Their aim is to inform the developer that the code, though legal, is probably wrong. Suppose you were a compiler developer and you wanted to add a new warning; what characteristics must that warning have?
- There must be some statically identifiable pattern to the suspicious code.
- The pattern must be common and plausibly written by a developer; developing a warning for a too-rare pattern or completely unrealistic code is effort that could be better spent on other features.
- The warning must have a low “false positive” rate; a warning must actually identify defective code more than, say, 99% of the time. False positives encourage developers to eliminate the warning by turning the warning off, or worse, by incorrectly changing the code. There must be a way to eliminate the warning without introducing a bug into the code.
- The pattern must be identified extremely Slowing the build process by anything more than a few percent is unacceptable.
I always recommend that everyone use the strictest warning settings on their compiler, to pay attention to warnings, and to (carefully) fix them all. Even fix the false positives; if the code was weird enough to fool the compiler then it’s weird enough to fool a human, and you don’t want to have “expected” warnings distracting you from actual warnings.
Read more…
Applied DevOps and the potential of Docker
The cultural impact within a software engineering organization can be dramatic.
Editor’s note: this post is from Karl Matthias and Sean P. Kane, authors of “Docker Up & Running,” a guide to quickly learn how to use Docker to create packaged images for easy management, testing, and deployment of software.
At the Python Developers Conference in Santa Clara, California, on March 15th, 2013, with no pre-announcement and little fanfare, Solomon Hykes, the founder and CEO of dotCloud, gave a 5-minute lightning talk where he first introduced the world to a brand new tool for Linux called Docker. It was a response to the hardships of shipping software at scale in a fast-paced world, and takes an approach that makes it easy to map organizational processes to the principles of DevOps.
The capabilities of the typical software engineering company have often not kept pace with the quickly evolving expectations of the average technology user. Users today expect fast, reliable systems with continuous improvements, ease of use, and broad integrations. Many in the industry see the principles of DevOps as a giant leap toward building organizations that meet the challenges of delivering high quality software in today’s market. Docker is aimed at these challenges.
Four short links: 3 February 2015
Product Trends, Writing Code, Simple Testing, and Quantum Gotchas
- Frog Design Predictions (Wired) — designers pick product trends, arrayed from probable to speculative.
- Making Wrong Code Look Wrong (Joel Spolsky) — This makes mistakes even more visible. Your eyes will learn to “see” smelly code, and this will help you find obscure security bugs just through the normal process of writing code and reading code.
- Simple Testing Can Prevent Most Critical Failures — We found the majority of catastrophic failures could easily have been prevented by performing simple testing on error handling code – the last line of defense – even without an understanding of the software design. We extracted three simple rules from the bugs that have lead to some of the catastrophic failures, and developed a static [Java] checker, Aspirator, capable of locating these bugs. One of the tests is a FIXME or TODO in an exception handler.
- Quantum Machine Learning Algorithms: Read the Fine Print (Scott Aaronson) — In the years since HHL, quantum algorithms achieving “exponential speedups over classical algorithms” have been proposed for other major application areas […]. With each of them, one faces the problem of how to load a large amount of classical data into a quantum computer (or else compute the data “on-the-fly”), in a way that is efficient enough to preserve the quantum speedup.
Avoid disruption through exploration
Support experimentation and continuously evaluate to stay ahead.
Businesses have always come and gone, but these days it seems that companies can fall from market dominance to bankruptcy in the blink of an eye. Kodak, Blockbuster and HMV are just a few recent victims of the rapid market disruption that defines the current era.
Where did these once iconic companies go wrong? To my mind, they forgot to keep challenging their assumptions about what business they were actually in.
Businesses have two options when they plan for the road ahead: they can put all their eggs into one basket, and risk losing everything if that basket has a hole in the bottom, or they can make a number of small bets, accepting that some will fail while others succeed.
Taking the latter approach, and making many small bets on innovation, transforms the boardroom into a roulette table. Unlike a punter in a casino, however, businesses cannot afford to stop making bets.
Business models are transient and prone to disruption by changes in markets and the external competitive environment, advances in design and technology, and wider social and economic change. Organizations that misjudge their purpose, or cannot sense and then adapt to these changes, will perish.
The sad truth is that too many established organizations focus most of their time and resources on executing and optimizing their existing business models in order to maximize profits. They forget to experiment and explore new ideas for customer needs of tomorrow.
Four short links: 22 January 2015
MSVR, The Facebook, Social Robots, and Testing Microservices
- Microsoft HoloLens Goggles (Wired) — a media release about the next thing from the person behind Kinect. I’m still trying to figure out (as are investors, I’m sure) where in the hype curve this Googles/AR/etc. amalgam lives. Is it only a tech proof-of-concept? Is it a games device like Kinect? Is it good and cheap enough for industrial apps? Or is this the long-awaited climb out of irrelevance for Virtual Reality?
- The Facebook (YouTube) — brilliant fake 1995 ad for The Facebook. Excuse me, I’m off to cleanse.
- Natural Language in Social Robotics (Robohub) — Natural language interfaces are turning into a de-facto interface convention. Just like the GUI overlapped and largely replaced the command line, NLP is now being used by robots, the Internet of things, wearables, and especially conversational systems like Apple’s Siri, Google’s Now, Microsoft’s Cortana, Nuance’s Nina, Amazon’s Echo and others. These interfaces are designed to simplify, speed up, and improve task completion. Natural language interaction with robots, if anything, is an interface. It’s a form of UX that requires design.
- Microservices and Testing (Martin Fowler) — testing across component boundaries, in the face of failing data stores and HTTP timeouts. The first discussion of testing in a web-scale world that I’ve seen from The Mainstream.
Four short links: 20 October 2014
Leaky Search, Conditional Javascript, Software Proofs, and Fake Identity
- Fix Mac OS X — each time you start typing in Spotlight (to open an application or search for a file on your computer), your local search terms and location are sent to Apple and third parties (including Microsoft) under default settings on Yosemite (10.10). See also Net Monitor, an open source toolkit for finding phone-home behaviour.
- A/B Testing at Netflix (ACM) — Using a combination of static analysis to build a dependency tree, which is then consumed at request time to resolve conditional dependencies, we’re able to build customized payloads for the millions of unique experiences across Netflix.com.
- Leslie Lamport Interview Summary — One idea about formal specifications that Lamport tries to dispel is that they require mathematical capabilities that are not available to programmers: “The mathematics that you need in order to write specifications is a lot simpler than any programming language […] Anyone who can write C code, should have no trouble understanding simple math, because C code is a hell of a lot more complicated than” first-order logic, sets, and functions. When I was at uni, profs worked on distributed data, distributed computation, and formal correctness. We have the first two, but so much flawed software that I can only dream of the third arriving.
- Fake Identity — generate fake identity data when testing systems.
Four short links: 18 September 2014
Writing Testable Code, Magical UIs, High-Performance ssh, and BASIC Lessons
- Guide to Writing Testable Code (PDF) — Google’s testable code suggestions, though C++-centric.
- Enchanted Objects (YouTube) — David Rose at Google talking about the UX of magical UIs. (via Mary Treseler)
- hpn-ssh — High Performance SSH/SCP.
- Lost Lessons from an 8-bit BASIC — The little language that fueled the home computer revolution has been long buried beneath an avalanche of derision, or at least disregarded as a relic from primitive times. That’s too bad, because while the language itself has serious shortcomings, the overall 8-bit BASIC experience has high points that are worth remembering.
Four short links: 22 August 2014
Crowd Problems, Robot Butler, Opportunistic Encryption, and A/B Framework
- Blame the Crowd, Not the Camera (Nina Simon) — Cameras weaponize an already unwieldy mob of people.
- The Botlr — the Cupertino Starwood hotel has a robot butler (botlr) doing room service.
- tcpcrypt — opportunistic encryption of all network traffic.
- Sixpack — language-agnostic A/B testing framework.
Reddish-Greenish-Refactor
Variations in Test-Driven Development
“Red-Green-Refactor” is a familiar slogan from test-driven development (TDD), describing a popular approach to writing software. It’s been both popular and controversial since the 2000’s (see the recent heated discussions between David Hansson, Bob Martin, and others). I find that it’s useful but limiting. Here I’ll describe some interesting exceptions to the rule, which have expanded the way I think about tests.
The standard three-step cycle goes like this. After choosing a small improvement, which can be either a feature or a bug fix, you add a failing test which shows that the improvement is missing (“Red”); add production code to make the test pass (“Green”); and clean up the production code while making sure the tests still pass (“Refactor”). It’s a tight loop with minimal changes at each step, so you’re never far from code that runs and has good test coverage.
By the way, to simplify things, I’ll just say “tests” and be vague about whether they’re technically “unit tests”, “specs,” “integration tests,” or “functional tests”; the main thing is that they’re written in code and they run automatically.
Red-Green-Refactor is a very satisfying rhythm when it works. Starting from the test keeps the focus on adding value, and writing a test forces you to clarify where you want to go. Many people say it promotes clean design: it’s just easier to write tests when you have well-separated modules with reasonable interfaces between them. My personal favorite part, though, is not the Red but the Refactor: the support from tests allows you to clean things up with confidence, and worry less about regressions.
Now for the exceptions. Read more…