- Welfare Makes America More Entrepreneurial (The Atlantic) — In a 2014 paper, Olds examined the link between entrepreneurship and food stamps, and found that the expansion of the program in some states in the early 2000s increased the chance that newly eligible households would own an incorporated business by 16%. (Incorporated firms are a better proxy for job-creating startups than unincorporated ones.)
- Security of Infrastructure Secrets — everything has a key that’s just one compromise or accidental drop away.
- Festo’s Fantastical Insectoid Robots Include Bionic Ants and Butterflies (IEEE) — Each butterfly has a 50-centimeter wingspan and weighs just 32 grams, but carries along two servo motors to independently actuate the wings, an IMU, accelerometer, gyro, and compass, along with two tiny 90-mAh lithium-polymer batteries. With a wing beat frequency of between one and two flaps per second, top speed is 2.5 m/s, with a flight time of three to four minutes before needing a 15-minute charge. The wings themselves use impossibly thin carbon rods for structure, and are covered with an even thinner elastic capacitor film.
- Arduino Celebration and Hexbugs hacking with Bob Martin (SparkFun) — The Hunter demo is a combination of object detection and object avoidance. It uses an IR sensor array to determine objects around it. Objects that appear and then disappear quickly, say in a second or two are targets which it will walk towards; however, a target that stays constant will be avoided. I’m still trying to find the perfect balance between making a decision between fleeing prey and a wall using only simple proximity samples from an IR detector array.
Five things we learned from the O’Reilly Software Architecture Conference 2015.
Last week, I had the opportunity to see the first Software Architecture Conference spring to life after a winter of preparation. Software architects, with or without the official title, swarmed the halls learning from speakers and attendees alike. I count myself among the people who were learning. Many notions about this profession and skill set have become clearer to me and I’m already planning to keep the content coming. I’m also in the early stages of developing out the next Software Architecture Conference (spring 2016).
Within this piece you’ll find my takeaways and lessons learned from the event. I expect these initial impressions to both shape our upcoming exploration of software architecture and be shaped by continued shifts within software architecture.
The O'Reilly Radar Podcast: Neal Ford on the changing role of software architects and the rise of microservices.
In this episode of the Radar Podcast, O’Reilly’s Mac Slocum sits down with Neal Ford, a software architect and meme wrangler at ThoughtWorks, to talk about the changing role of software architects. They met up at our recent Software Architecture Conference in Boston — if you missed the event, you can sign up to be notified when the Complete Video Compilation of all sessions and talks is available.
Slocum started the conversation with the basics: what, exactly, does a software architect do. Ford noted that there’s not a straightforward answer, but that the role really is a “pastiche” of development, soft skills and negotiation, and solving business domain problems. He acknowledged that the role historically has been negatively perceived as a non-coding, post-useful, ivory tower deep thinker, but noted that has been changing over the past five to 10 years as the role has evolved into real-world problem solving, as opposed to operating in abstractions:
“One of the problems in software, I think, is that you build everything on towers of abstractions, and so it’s very easy to get to the point where all you’re doing is playing with abstractions, and you don’t reify that back to the real world, and I think that’s the danger of this kind of ivory-tower architect. When you start looking at things like continuous delivery and continuous deployment, you have to take those operational concerns into account, and I think that is making the role of architect a lot more relevant now, because they are becoming much more involved in the entire software development ecosystem, not just the front edge of it.”
The O'Reilly Data Show Podcast: Erich Nachbar on testing and deploying open source, distributed computing components.
When I first hear of a new open source project that might help me solve a problem, the first thing I do is ask around to see if any of my friends have tested it. Sometimes, however, the early descriptions sound so promising that I just jump right in and try it myself — and in a few cases, I transition immediately (this was certainly the case for Spark).
I recently had a conversation with Erich Nachbar, founder and CTO of Virtual Power Systems, and one of the earliest adopters of Spark. In the early days of Spark, Nachbar was CTO of Quantifind, a startup often cited by the creators of Spark as one of the first “production deployments.” On the latest episode of the O’Reilly Data Show Podcast, we talk about the ease with which Nachbar integrates new open source components into existing infrastructure, his contributions to Mesos, and his new “software-defined power distribution” startup.
Ecosystem of open source big data technologies
When evaluating a new software component, nothing beats testing it against workloads that mimic your own. Nachbar has had the luxury of working in organizations where introducing new components isn’t subject to multiple levels of decision-making. But, as he notes, everything starts with testing things for yourself:
“I have sort of my mini test suite…If it’s a data store, I would just essentially hook it up to something that’s readily available, some feed like a Twitter fire hose, and then just let it be bombarded with data, and by now, it’s my simple benchmark to know what is acceptable and what isn’t for the machine…I think if more people, instead of reading papers and paying people to tell them how good or bad things are, would actually set aside a day and try it, I think they would learn a lot more about the system than just reading about it and theorizing about the system. Read more…
Andrew Hinton on making context understandable, smart devices, and programming literacy.
I sat down with Andrew Hinton, an information architect at The Understanding Group and author of the recently released O’Reilly book Understanding Context. Our conversation included a discussion of information architecture’s role in the context of the IoT, the complexities of context, and the well-debated “everyone should learn to code” argument.
Context, information architecture, and experience design
Information architecture (IA) has always been a critical part of creating great products and services, and many would argue that, until now, it hasn’t been given the attention or respect it deserves. The need for thoughtful IA is increasing as we enter the multimodal world of IoT. Whether you call yourself an Information Architect or Designer, you need to care about context. Hinton offers up this hidden motivation for writing Understanding Context:
“I’ll confess, the book is a bit of a Trojan horse to kind of get people to think about information architecture differently than maybe the way they assume they should think about it.”
I followed up with Hinton via email for a bit more on how we need to view IA:
“People tend to assume IA is mainly about arranging objects, the way we arrange cans in a cupboard or books in a library. That’s part of it, but the Internet has made it so that we co-exist in places made of semantic and digital information. So when we create or change the labels, relationships, and rules of those places, we change their environment. Not just on screens, but now outside of screens as well. And, to me, the central challenge of that work is making context understandable.”
Understanding is what designers should be striving for as the backdrop for products.
Editor’s note: this post originally published on Medium; this lightly edited version is republished here with permission.
About 10 years ago, I worked on a project for a new system for people with diabetes. We talked with many people who had diabetes or who helped educate diabetics. I even wore an insulin pump around for several days. In short, we were building up subject matter knowledge and empathy for the people we were designing for. During this user research phase, many of us (myself included) started to have actual nightmares that we had diabetes. I remember once looking at my toes, wondering if the tingling I was feeling was the onset of diabetes. (It wasn’t — probably just my foot was asleep.) We’d empathized to the point where we really identified with diabetics and their problems, which are considerable. We had so much empathy for them, in fact, that for several weeks, we couldn’t solve the problem. It seemed intractable, given what we knew about the condition and the state of technology at the time.
It wasn’t until we were able to step away from the diabetics’ perspective and become less empathetic that we were able to come up with a product concept. We needed distance — a psychic removal — in order to really assess the problem and take action to change it. In other words, we had to act like designers, which meant we had to be more objective, to sit outside and to the left of the problem space. As this experience taught me, too much empathy can be as crippling as too little.