New issue: bioreactors and food production, modeling a worm's brain on a computer and letting it drive a robot, and more.
The fifth issue of BioCoder is here! We’ve made it into our second year: this revolution is in full swing.
Rather than talk about how great this issue is (though it is great), I’d like to ask a couple of questions. Post your answers in the comments; we won’t necessarily reply, but we will will read them and take them into account.
- We are always interested in new content, and we’ll take a look at almost anything you send to BioCoder@oreilly.com. In particular, we’d like to get more content from the many biohacker labs, incubators, etc. We know there’s a lot of amazing experimentation out there. But we don’t know what it is; we only see the proverbial tip of the iceberg. What’s the best way to find out what’s going on?
- While we’ve started BioCoder as a quarterly newsletter, that’s a format that already feels a bit stodgy. Would you be better served if BioCoder went web-native? Rather than publishing eight or 10 articles every three months, we’d publish three or four articles a month online. Would that be more useful? Or do you like things the way they are?
And yes, we do have a great issue, with articles about a low-cost MiniPCR, bioreactors and food production, and what happens when you model a worm’s brain on a computer and let it drive a robot. Plus, an interview with Kyle Taylor of the glowing plant project, the next installment in a series on lab safety, and much more. Read more…
Before you ask HR to find a developer skilled in a particular tool or language, think about who you really want in that seat.
I had a conversation recently with Martin Thompson (@mjpt777), a London-based developer who specializes in performance and low-latency systems. I learned about Martin through Kevlin Henney’s Tweets about his recent talk at Goto Aarhus.
We talked about a disturbing trend in software development: Resume Driven Development, or RDD. Resume Driven Development happens when your group needs to hire a developer. It’s very hard to tell a non-technical HR person that you need someone who can make good decisions about software architecture, someone who knows the difference between clean code and messy code, and someone who’s able to look at a code base and see what’s unnecessary and what can be simplified. We frequently can’t do that ourselves. So management says, “oh, we just added Redis to the application, so we’ll need a Redis developer.” That’s great — it’s easy to throw out resumes that don’t say Redis; it’s easy to look for certifications; and sooner or later, you have a Redis developer at a desk. Maybe even a good one.
And what does your Redis developer do? He does Redis, of course. So, you’re bound to have an application with a lot of Redis in it. Whenever he sees a problem that can be solved with Redis, that’s what he’ll do. It’s what you hired him for. You’re happy; he’s happy. Except your application is now being optimized to fit the resumes of the people you hired, not the requirements of your users. Read more…
Network neutrality is about treating all kinds of traffic equally — throttling competition equates to extortion.
I’d like to make a few very brief points about net neutrality. For most readers of Radar, there’s probably nothing new here, but they address confusions that I’ve seen.
- Network neutrality isn’t about the bandwidth that Internet service providers deliver to your home. ISPs can charge more for more bandwidth, same as always.
- Nor is network neutrality about the bandwidth that Internet service providers deliver to information providers. Again, ISPs can charge more for more bandwidth, same as always. You’d better believe that Google pays a lot more for Internet service than your local online store.
- Nor is network neutrality about ISPs dealing with congestion. Network providers have always dealt with congestion — in the worst case, by dropping traffic. Remember the “fast busy” signal on the phone? That’s the network dealing with congestion.
- Network neutrality is entirely about treating all kinds of traffic equally. Video is the same as voice, the same as Facebook, the same as Amazon. Your ISP cannot penalize video traffic (or some other kind of traffic) because they’d like to get into that business or because they’re already in that business. In other words: when you buy Internet connectivity, you can use it for whatever you want. Your provider can’t tell you what kind of business to be in.
The 13 principles in the U.S. CIO's Digital Services Playbook are applicable for everyone.
Whenever I hear someone say that “government should be run like a business,” my first reaction is “do you know how badly most businesses are run?” Seriously. I do not want my government to run like a business — whether it’s like the local restaurants that pop up and die like wildflowers, or megacorporations that sell broken products, whether financial, automotive, or otherwise.
If you read some elements of the press, it’s easy to think that healthcare.gov is the first time that a website failed. And it’s easy to forget that a large non-government website was failing, in surprisingly similar ways, at roughly the same time. I’m talking about the Common App site, the site high school seniors use to apply to most colleges in the US. There were problems with pasting in essays, problems with accepting payments, problems with the app mysteriously hanging for hours, and more.
Synthetic biology surely can get weirder — but this is a great start.
If you’ve ever tried any of the various vegan cheese substitutes, they are (to put it kindly) awful. The missing ingredient in these products is the milk proteins, or caseins. And of course you can’t use real milk proteins in a vegan product.
But proteins are just organic compounds that are produced, in abundance, by any living cell. And synthetic biology is about engineering cell DNA to produce whatever proteins we want. That’s the central idea behind the Real Vegan Cheese project: can we design yeast to produce the caseins we need for cheese, without involving any animals? There’s no reason we can’t. Once we have the milk proteins, we can use traditional processes to make the cheese. No cows (or sheep, or goats) involved, just genetically modified yeast. And you never eat the yeast; they stay behind at the brewery.
Joe Schloendorn is creating and distributing plasmids that can freely be reproduced — a huge breakthrough for DIY bio.
At O’Reilly, we’ve long been supporters of the open source movement — perhaps not with the religious fervor of some, but with a deep appreciation for how open source has transformed the computing industry over the last three decades.
We also have a deep appreciation for the dangers that closed source, restrictive licenses, patent trolling, and other technocratic evils pose to areas that are just opening up — biology, in particular. So it is with great interest that I read Open Source Biotech Consumables in the latest issue of BioCoder.
I’m not going to rehash the article; you should read it yourself. The basic argument is that some proteins used in research cost thousands of dollars per milligram. They’re easily reproducible (we’re talking DNA, after all), but frequently tied up with restrictive licenses. In addition, many of the vendors will only sell to research institutions and large corporations, not home labs or small community labs. So, Joe Schloendorn is creating and distributing plasmids that can freely be reproduced. That in itself is a huge breakthrough.
Inside this issue: implanting evolution, open source biotech consumables, power supplies for systems biology, and more.
We’ve made it to our fourth issue of BioCoder! I’m excited about this issue — it’s the best collection of articles we’ve published so far.
Some of the highlights are:
- Implanting Evolution:
- We spend a lot of time thinking about how to modify other creatures, from microbes on up. What about ourselves? Surgeons already implant pacemakers and insulin pumps into humans. What about other applications? What are the possibilities if you implant NFC and RFID chips?
- Open Source Biotech Consumables:
- One of the biggest problems for grassroots biotech research is the price of ingredients. Some proteins cost thousands of dollars per milligram, hardly affordable by a community lab or a small startup. We can solve that problem with “open source” DNA. This is an exciting development — and a challenge to what we mean by “open source” (I promise to write about that in another post).
If all companies are software companies, then all companies must learn to manage their online operations.
Two years ago, I wrote What is DevOps. Although that article was good for its time, our understanding of organizational behavior, and its relationship to the operation of complex systems, has grown.
A few themes have become apparent in the two years since that last article. They were latent in that article, I think, but now we’re in a position to call them out explicitly. It’s always easy to think of DevOps (or of any software industry paradigm) in terms of the tools you use; in particular, it’s very easy to think that if you use Chef or Puppet for automated configuration, Jenkins for continuous integration, and some cloud provider for on-demand server power, that you’re doing DevOps. But DevOps isn’t about tools; it’s about culture, and it extends far beyond the cubicles of developers and operators. As Jeff Sussna says in Empathy: The Essence of DevOps:
…it’s not about making developers and sysadmins report to the same VP. It’s not about automating all your configuration procedures. It’s not about tipping up a Jenkins server, or running your applications in the cloud, or releasing your code on Github. It’s not even about letting your developers deploy their code to a PaaS. The true essence of DevOps is empathy.
Think your IT staff can protect you better than major cloud providers? Think again.
I just ran across Katie Fehrenbacher’s article in GigaOm that made a point I’ve been arguing (perhaps not strongly enough) for years. When you start talking to people about “the cloud,” you frequently run into a knee-jerk reaction: “Of course, the cloud isn’t secure.”
I have no idea what IT professionals who say stuff like this mean. Are they thinking about the stuff they post on Facebook? Or are they thinking about the data they’ve stored on Amazon? For me, the bottom line is: would I rather trust Amazon’s security staff, or would I rather trust some guy with some security cert that I’ve never heard of, but whom the HR department says is “qualified”? Read more…
All systems are distributed systems, and we’re starting to see how they fit into Velocity's themes.
From the beginning, the Velocity Conference has focused on web performance and operations — specifically, web operations. This focus has been fairly narrow: browser performance dominated the discussion of “web performance,” and interactions between developers and IT staff dominated operations.
That’s not to say that Velocity hasn’t looked at the rest of the application stack; there’s been an occasional glance in the direction of the database and an even more occasional glance at the middleware. But the database and middleware have, at least historically, played a bit part. And while the focus of Velocity has been front-end tuning, speakers like Baron Schwartz haven’t let us ignore the database entirely. Read more…