The enterprise IT phenomenon known as systems of engagement can empower developers in varied sectors.
Working on software development tools at IBM, I typically work with enterprise customers. These are large teams building large, complex software systems with a lot of legacy. I was excited when I had a chance to get involved with IBM’s platform-as-a-service (PaaS) initiative, which is now available as BlueMix.
The “systems of engagement” concept behind BlueMix sounded promising, but also triggered my buzzword-skepticism reflex. Ultimately, though, I’ve become convinced there is something happening here, and it extends beyond my traditional enterprise stomping grounds. It’s a projection of a trend that is occurring among makers, enterprise software development shops, and, most surprisingly, in complex systems.
The IT phenomenon “systems of engagement” is actually much bigger than that — it’s a feature of a new era of apps and composable services in software and systems, and it could even be the beginning of a fun phase of software development. Read more…
How do we manage systems that are too large to understand, too complex to control, and that fail in unpredictable ways?
“What is surprising is not that there are so many accidents. It is that there are so few. The thing that amazes you is not that your system goes down sometimes, it’s that it is up at all.”—Richard Cook
In September 2007, Jean Bookout, 76, was driving her Toyota Camry down an unfamiliar road in Oklahoma, with her friend Barbara Schwarz seated next to her on the passenger side. Suddenly, the Camry began to accelerate on its own. Bookout tried hitting the brakes, applying the emergency brake, but the car continued to accelerate. The car eventually collided with an embankment, injuring Bookout and killing Schwarz. In a subsequent legal case, lawyers for Toyota pointed to the most common of culprits in these types of accidents: human error. “Sometimes people make mistakes while driving their cars,” one of the lawyers claimed. Bookout was older, the road was unfamiliar, these tragic things happen. Read more…
Physical and biological design are about to get much more digital, says Autodesk’s CTO.
One of the core ideas behind our Solid Conference is that software can replace physical complexity, and that it’s getting easier for it to do so because the relationship between the physical and virtual worlds is becoming more fluid. Input tools like 3D scanners and computer vision software, and output tools like CNC machines and 3D printers are essentially translators between digital and physical. They make it possible to extract information from physical objects, compute on it, transform it, combine it with other data, and then “rematerialize” it.
I recently spoke with Autodesk CTO Jeff Kowalski about this convergence between physical and digital, and its impact on design. In his view, computers are about to go from mere drafting tables to full partners in the design process. They’ll automate the tedious cycle of trial and error, and leave designers to guide aesthetics and experience. “Decades ago, someone came up with the term ‘computer-aided design,’ but what we’ve had up to now is really computer-aided documentation,” he says. “Design has been accomplished solely in the head of the designer, and then the computer is used to document the outcome.” Read more…
Design in the hardware era, how big companies and small companies should interact, and the importance of data privacy
On stage, along with myself, are three Solid people: Rachel Kalmar, data scientist at Misfit Wearables and member of our program committee; Mike Kuniavsky, principal scientist at PARC and speaker on Functional Forms at Solid; and Dan Saffer, creative director at Smart Design, who will speak about microinteractions (and has written an O’Reilly book about microinteractions as well). Read more…
Self-driving cars will make decisions — and act — faster than humans facing the same dangerous situations.
Frankly, I’m already tired of the discussion. It’s not as if humans don’t already get into situations like this, and make (or not make) decisions. At least, I have. Read more…
When ActiveRecord just isn’t enough
In Just Enough Arel, we explored a bit into how the Arel library transforms our Ruby code into SQL to be executed by the database. To do so, we discovered that Arel abstracts database tables and the fields therein as objects, which in turn receive messages not normally available in ActiveRecord queries. Wrapping up the article, we also looked at arguments for using Arel over falling back to SQL.
As alluded at the end of the previous article, Arel can do much more than merely provide a handful of comparison operators. In this post, we’ll look at how we can call native database functions, construct unions and intersects, and we’ll wrap things up by explicitly building joins with Arel.