FEATURED STORY

Four short links: 27 April 2015

Four short links: 27 April 2015

Living Figures, Design vs Architecture, Faceted Browsing, and Byzantine Comedy

  1. ‘Living Figures’ Make Their Debut (Nature) — In July last year, neurobiologist Björn Brembs published a paper about how fruit flies walk. Nine months on, his paper looks different: another group has fed its data into the article, altering one of the figures. The update — to figure 4 — marks the debut of what the paper’s London-based publisher, Faculty of 1000 (F1000), is calling a living figure, a concept that it hopes will catch on in other articles. Brembs, at the University of Regensburg in Germany, says that three other groups have so far agreed to add their data, using software he wrote that automatically redraws the figure as new data come in.
  2. Strategies Against Architecture (Seb Chan and Aaron Straup Cope) — the story of the design of the Cooper Hewitt’s clever “pen,” which visitors to the design museum use to collect the info from their favourite exhibits. (Visit the Cooper Hewitt when you’re next in NYC; it’s magnificent.)
  3. Two Way Streetan independent explorer for The British Museum collection, letting you browse by year acquired, year created, type of object, etc. I note there are more things from a place called “Brak” than there are from USA. Facets are awesome. (via Courtney Johnston)
  4. The Saddest Moment (PDF) — “How can you make a reliable computer service?” the presenter will ask in an innocent voice before continuing, “It may be difficult if you can’t trust anything and the entire concept of happiness is a lie designed by unseen overlords of endless deceptive power.” The presenter never explicitly says that last part, but everybody understands what’s happening. Making distributed systems reliable is inherently impossible; we cling to Byzantine fault tolerance like Charlton Heston clings to his guns, hoping that a series of complex software protocols will somehow protect us from the oncoming storm of furious apes who have somehow learned how to wear pants and maliciously tamper with our network packets. Hilarious. (via Tracy Chou)
Comment

IBM is banking on design’s ROI

Phil Gilbert on IBM’s deep design roots, change management, and hiring for culture fit.

Ripples_of_Colour_Scott_Cresswell_Flickr

Companies of all sizes are recognizing that by taking a design-first approach to product development, they can improve profit. I recently sat down with Phil Gilbert, GM of design at IBM, to discuss how he is helping to lead the transformation to a design-first company within IBM. Adopting design as a key corporate asset may seem like a no-brainer, but for a company of more than 350,000 employees, it’s a massive undertaking. IBM hasn’t been quiet about its plans to hire 1,000 designers over the course of five years and embed design in product teams throughout the organization.

IBM’s long history of design

What I was surprised to find when reading about IBM’s latest design plans, is that the giant tech company has design roots dating back to the 1950s. Gilbert shares in more detail:

We started our first design program — and we were one of the first to really apply design holistically at scale — in 1956. In the 1950s and the 1960s and into the early 1970s, we had a constellation of designers around IBM that, quite frankly, has never been equaled.

Elliott Noyes was our first head of design. Thomas Watson Jr. hired him in 1956. He assembled people like Eero Saarinen, Charles and Ray Eames, and Paul Rand. He assembled this team of people, and, essentially, I think the reason it happened then is because humanity was addressing a fundamentally different relationship between ourselves and technology. There was a lot of turmoil and angst as a result. We used design at that time to communicate and engage in a conversation with humanity about that relationship and about our role with technology. We viewed it as a very holistic statement — we communicated it through our products, our communications, our buildings, and we did it through our exhibits at places like the World’s Fair.

Since then, I don’t think there has been as fundamental a change in the relationship between human beings and technology. The move from mainframe to mini-computer, the move from mini-computer to personal computer, the move to client-server computing — all of these things were actually fairly incremental. But I think in 2007, with the release of the iPhone and with the ubiquitous access via mobile devices, I actually think that we’re, again, in a time of real turmoil and change around this relationship of where does technology sit with human beings.

This is a real change, and I think that human-centered design and design thinking as a method to achieve human-centered design is why it’s become so important. Because our relationship with technology is, it may not be as frightening as it was in the 50s and 60s, but it certainly is fundamental. I don’t think we quite yet understand it. I think design is the primary lever that we have to understand that relationship and then to communicate that relationship.

Read more…

Comment

Coming full circle with Bigtable and HBase

The O'Reilly Data Show Podcast: Michael Stack on HBase past, present, and future.

stones_geralt_pixabay

Subscribe to the O’Reilly Data Show to explore the opportunities and techniques driving big data and data science.

At least once a year, I sit down with Michael Stack, engineer at Cloudera, to get an update on Apache HBase and the annual user conference, HBasecon. Stack has a great perspective, as he has been part of HBase since its inception. As former project leader, he remains a key contributor and evangelist, and one of the organizers of HBasecon.

In the beginning: Search and Bigtable

During the latest episode of the O’Reilly Data Show Podcast, I decided to broaden our conversation to include the beginnings of the very popular Apache HBase project. Stack reminded me that in the early days much of the big data community in the SF Bay Area was centered around search technologies, such as HBase. In particular, HBase was inspired by work out of Google (Bigtable), and the early engineers had ties to projects out of the Internet Archive:

At the time, I was working at the Internet Archive, and I was working on crawlers and search. The Bigtable paper looked really interesting to us because the archive, as you know, we used to host — or still do — the Wayback Machine. The Wayback Machine is a picture of the Web that goes back to 1998, and you could look at the Web at any particular time. What pages looked liked at a particular time. Bigtable was very interesting at the Internet Archive because it had this time dimension.

A group had started up to talk about the possibility of implementing a Bigtable clone. It was centered at a place called Powerset, a startup that was in San Francisco back then. That was about doing a search, so I went and talked to them. They said, ‘Come on over and we’ll make a space for doing a Bigtable clone.’ They had a very intricate search pipeline, and it was based on early Amazon AWS, and every time they started up their pipeline, they’d get a phone call from Amazon saying, ‘Please stop whatever it is you’re doing.’ … The first engineer would be a fellow called Jim Kellerman. The actual first 30 classes came from Mike Cafarella. He was instrumental in getting the first versions of Hadoop going. He was hanging around Apache Nutch at the time. … Doug [Cutting] used to work at the Internet archive, and the first actual versions of Hadoop were run on racks at the Internet archive. Doug was working on fulltext search. Then he moved on to go to Yahoo, to work on Hadoop full time.

Read more…

Comment

The challenge of connecting anything to the Internet

The O'Reilly Solid Podcast: Zach Supalla and Will Hart on building a supply chain, making radios work, and taking on big telecom.

Chain_of_Command_Pardesi_Flickr

Subscribe to the O’Reilly Solid podcast to stay on top of topics related to the Internet of Things, hardware, software, manufacturing, and the blurring of the physical and virtual worlds.

A few weeks ago, hours after launching a blow-out Kickstarter campaign, Zach Supalla and Will Hart of Spark Labs dropped by our podcasting studio to have a wide-ranging conversation about how they’d built a successful hardware startup, how they manage their overseas supply chain, and how they’re taking on established machine-to-machine and telecom companies by turning themselves into a mobile virtual network operator (MVNO).

Zach and Will are leading a workshop at our Solid Conference called “How to manage China” on how to build and maintain a supply chain.

Spark’s latest product, the Electron, is a tiny development kit that can connect just about any kind of device to Spark’s back-end platform over a 3G cellular signal for as little as $3 per month. Read more…

Comment

Chaos Monkey for systems of people: The ultimate performance hack

The O'Reilly Radar Podcast: Alois Reitbauer on performance hacking, DevOps applications, and fostering a culture of respect.

geralt_Pixabay

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 episode of the Radar Podcast, O’Reilly’s Courtney Nash chats with Alois Reitbauer, chief evangelist at Ruxit, about how DevOps is deeply woven into the Ruxit culture. Reitbauer also talks about how the term “performance hacking” came about at Ruxit, why Chaos Monkey should be applied to systems of people, and why trust across — and between — all departments in an organization is essential.

DevOps beyond DevOps

Performance hacking is a term that emerged at Ruxit about a year ago as the company prepared for the beta launch, Reitbauer said, when they realized as the company scaled up, they needed to bring everyone from all their teams together. “The idea of performance hacking, then,” he noted, “was really, how can we scale up this collaboration between the DevOps teams, the product development teams, and our go-to-market growth hacking teams while we grow as an organization.” The ultimate aim was to figure out how to continue to act like a three-person, one-room startup as the company scaled to a couple hundred people.

One of the approaches embraced at Ruxit is to apply some of the DevOps best practices to their growth hacking and product development strategies. As an example, Reitbauer offered up the idea of Chaos Monkey, as applied not to AWS instances, but to the organization as a whole. The way it works, he explained, is to send a member of a team — any team — away on short notice (or no notice) and see what breaks. Reitbauer said that they’d actually done this and outlined what they learned from the exercise:

We have done it, and it also came up as part of our regular organizational practices. Like, when we had our first very strong conference season — we sent people to different shows all over the place; we picked people from the team who had to go somewhere. And even if people knew they were going to be out of the office in a couple of weeks, they still started to behave as if they would be around all the time, that they wouldn’t be leaving the office. Then, suddenly they were on a plane. They had no time to do their everyday work, and suddenly they realized where they really needed help. So, you don’t even have to make it a total surprise. You just have to plan how to get people out of their regular working behavior to do something else. Then we were able to figure out, ‘We really need somebody else to be able to jump in here or to help somebody out over there.’ It might be a regular holiday or just not daily routine.

Read more…

Comment: 1

6 best practices for giving a product critique

Productive critique can strengthen relationships and collaboration, improve productivity, and lead to better designs.

Firewood_Stack_Support_Trusses_Dan_G_Flickr

Download a free copy of Designing for the Internet of Things, a curated collection of chapters from the O’Reilly Design library. This post is an excerpt from Discussing Design, by Adam Connor and Aaron Irizarry, one of the books included in the curated collection.

There are two sides, or roles, in any critique:

Recipient: The individual(s) receiving the critique (i.e. the creator or presenter of whatever is being analyzed) who will take the perspectives and information raised during the critique, process it, and act upon it in some way.

Giver: The individual(s) giving the critique, who are being asked to think critically about the creation and provide their thoughts and perspectives.

Within both of these roles, there is the discrete aspect of intention: why are we asking for/receiving/giving feedback. Intent is the initiator of the conversation and is often what separates successful critiques and feedback discussions from problematic ones.

For the best discussions, the intent of each participant, regardless of whether they are receiving or giving critique, needs to be appropriate. If we aren’t careful, critique with the wrong, or inappropriate, intent on either side can lead to problems not only in our designs, but also in our ability to work with our teammates. Read more…

Comment