Buddy Michini on commercial drones

The O’Reilly Solid Podcast: Drone safety, trust, and real-time data analysis.


Subscribe to the O’Reilly Solid Podcast for insight and analysis about the Internet of Things and the worlds of hardware, software, and manufacturing.

In our new episode of the Solid Podcast, we talk with Buddy Michini, CTO of Airware, which makes a platform for commercial drones. We cover some potentially game-changing research in localization and mapping, and onboard computational abilities that might eventually make it possible for drones to improve their flight intelligence by analyzing their imagery in real time.

Among the general public, the best-understood use case for drones is package delivery, which obscures many other promising applications (and perhaps threatens to become the Internet-connected refrigerator of autonomous aircraft). There’s also widespread (and understandable) fear of drones. “We need to make drones do things to improve our lives and our world,” Buddy says. “That will get people to accept drones into their lives a little bit more.” Read more…

Four short links: 6 October 2015

Four short links: 6 October 2015

System Intuition, Magic is Power, Predicting Behaviour, Payment Required

  1. Flux: New Approach to System Intuition (LinkedIn) — In general, we assume that if anything is best represented numerically, then we don’t need to visualize it. If the best representation is a numerical one, then a visualization could only obscure a quantifiable piece of information that can be measured, compared, and acted upon. Anything that we can wrap in alerts or some threshold boundary should kick off some automated process. No point in ruining a perfectly good system by introducing a human into the mix. Instead of numerical information, we want a tool that surfaces relevant information to a human, for situations that would be too onerous to create a heuristic. These situations require an intuition that we can’t codify.
  2. Jumping to the End: Practical Design Fiction (Vimeo) — “Magic is a power relationship” — Matt Jones on the flipside of hiding complex behaviours from users and making stuff “work like magic.” (via Richard Pope)
  3. Predicting Daily Activities from Egocentric Images Using Deep Learning — aka “people wear cameras and we can figure out what they’re going to do next.”
  4. 402: Payment Required (David Humphrey) — The ad blocking discussion highlights our total lack of imagination, where a browser’s role is reduced to “render” or “don’t render.” There are a whole world of options in between that we should be exploring.

Transforming the experience of sound and music

The O'Reilly Radar Podcast: Poppy Crum on sensory perception, algorithm design, and fundamental changes in music.

Subscribe to the O’Reilly Radar Podcast to track the technologies and people that will shape our world in the years to come.


In this week’s Radar Podcast, author and entrepreneur Alistair Croll, who also co-chairs our Strata + Hadoop World conference, talks music science with Poppy Crum, senior principal scientist at Dolby Laboratories and a consulting professor at Stanford.

Their wide-ranging discussion covers fundamental changes in the music industry, sensory perception and algorithm design, and what the future of music might look like.

Here are a few snippets from their conversation:

As we see transformations to the next stage of how we consume content, things that are becoming very prevalent are more and more metadata. More and more information about the sounds, information about personalization. You aren’t given the answer; you’re given information and opportunities to have a closer tie to the artist’s intent because more information about the artist’s intent can be captured so that when you actually experience the sound or the music, that information is there to dictate how it deals with your personal environment.

Today, Dolby Atmos and other technologies have transformed [how we experience sound in the cinema] quite substantially, where if I’m a mixer, I can take a sound and can mix now, say, instead of seven channels, I can mix 128 sounds, and each one of those sounds has a data stream associated with it. That data stream carries information. It’s not going to a particular set of speakers; it has x, y, z coordinates, it has information about the diffusivity of that sound. Read more…


Contrasting architecture patterns with design patterns

How both kinds of patterns can add clarity and understanding to your project.

Developers are accustomed to design patterns, as popularized in the book Design Patterns by Gamma, et al. Each pattern describes a common problem posed in object-oriented software development along with a solution, visualized via class diagrams. In the Software Architecture Fundamentals workshop, Mark Richards & I discuss a variety of architecture patterns, such as Layered, Micro-Kernel, SOA, etc. However, architecture patterns differ from design patterns in several important ways.

Components rather than classes

Architectural elements tend towards collections of classes or modules, generally represented as boxes. Diagrams about architecture represent the loftiest level looking down, whereas class diagrams are at the most atomic level. The purpose of architecture patterns is to understand how the major parts of the system fit together, how messages and data flow through the system, and other structural concerns.

Architecture diagrams tend to be less rigidly defined than class diagrams. For example, many times the purpose of the diagram is to show one aspect of the system, and simple iconography works best. For example, one aspect of the Layered architecture pattern is whether the layers are closed (only accessible from the superior layer) or open (allowed to bypass the layer if no value added), as shown in Figure 1.

Figure 1: Layered architecture with mixed closed and open layers

Figure 1: Layered architecture with mixed closed and open layers

This feature of the architecture isn’t the most important part, but is important to call out because if affects the efficacy of this pattern. For example, if developers violate this principle (e.g., performing queries from the presentation layer directly to the data layer), it compromises the separation of concerns and layer isolation that are the prime benefits of this pattern. Often an architectural pattern consists of several diagrams, each showing an important dimension.

Read more…


Jim Stogdill on cloud-based typewriters and smart watches

The O’Reilly Solid Podcast: Distractions, wearables, and reference peanut butter.


Subscribe to the O’Reilly Solid Podcast for insight and analysis about the Internet of Things and the worlds of hardware, software, and manufacturing.

In this episode of the Solid Podcast, David Cranor and I talk with Jim Stogdill, one of the key figures behind the launch of our Solid conference, about some of the cool pieces of hardware that we’ve come across recently.

Stogdill starts off with the Hemingwrite, an ultra-simplified Internet-connected typewriter for writers who need to isolate themselves from distraction. It duplicates, at significant expense and austerity, a small part of any modern computer’s functionality. The Hemingwrite’s existence — along with that of its oversubscribed Kickstarter campaign — demonstrates the new economics of hardware: development costs have fallen enough that clever entrepreneurs can isolate and solve niche consumer problems like needing a browserless computer because you sometimes don’t want to be distracted by your browsered computer. Also, I’d like one. Read more…


On leadership

Dinner conversation turns into a career retrospective. Food for thought for leaders and leaders-to-be.

Toss Bhudvanbhen co-authored this post.


Over a recent dinner, my conversation with Toss Bhudvanbhen meandered into discussion of how much our jobs had changed since we entered the workforce. We started during the Dot-Com era. Technology was a relatively young field then (frankly, it still is) so there wasn’t a well-trodden career path. We just went with the flow.

Over time our titles changed from “software developer,” to “senior developer,” to “application architect,” and so on, until one day we realized that we were writing less code but sending more e-mails. Attending fewer code reviews but more meetings. Less worried about how to implement a solution, but more concerned with defining the problem and why it needed to be solved. We had somehow taken on leadership roles.

We’ve stuck with it. Toss now works as a principal consultant at Pariveda Solutions and my consulting work focuses on strategic matters around data and technology.

The thing is, we were never formally trained as management. We just learned along the way. What helped was that we’d worked with some amazing leaders, people who set great examples for us and recognized our ability to understand the bigger picture.

Read more…