Timothy M. O'Brien
Salesforce's recent investments suggest it's building a developer-centric suite of tools for the cloud.
Have you ever seen Salesforce’s “no software” graphic? It’s the word “software” surrounded by a circle with a red line through it. Here’s a picture of the related (and dancing) “no software” mascot.
Now, if you consider yourself a developer, this is a bit threatening, no? Imagine sitting at a Salesforce event in 2008 in Chicago while Salesforce.com’s CEO, Marc Benioff, swiftly works an entire room of business users into an anti-software frenzy. I was there to learn about Force.com, and I’ll summarize the message I understood four years ago as “Not only can companies benefit from Salesforce.com, they also don’t have to hire developers.”
The message resonated with the audience. Salesforce had been using this approach for a decade: Don’t buy software you have to support, maintain, and hire developers to customize. Use our software-as-a-service (SaaS) instead. The reality behind Salesforce’s trajectory at the time was that it too needed to provide a platform for custom development.
Salesforce’s dilemma: They needed developers
This “no software” message was enough for the vast majority of the small-to-medium-sized business (SMB) market, but to engage with companies at the largest scale, you need APIs and you need to be able to work with developers. At the time, in 2008, Salesforce was making moves toward the developer community. First there was Apex, then there was Force.com.
In 2008, I evaluated Force.com, and while capable, it didn’t strike me as something that would appeal to most developers outside of existing Salesforce customers. Salesforce was aiming at the corporate developers building software atop competing stacks like Oracle. While there were several attempts to sell it as such, it wasn’t a stand-alone product or framework. In my opinion, no developer would assess Force.com and opt to use it as the next development platform.
This 2008 TechCrunch article announcing the arrival of Salesforce’s Developer-as-a-Service (DaaS) platform serves as a reminder of what Salesforce had in mind. They were still moving forward with an anti-software message for the business while continuing to make moves into the developer space. Salesforce built a capable platform. Looking back at Force.com, it felt more like an even more constrained version of Google App Engine. In other words, capable and scalable, but at the time a bit constraining for the general developer population. Don’t get me wrong: Force.com wasn’t a business failure by any measure; they have an impressive client list even today, but what they didn’t achieve was traction and awareness among the developer community. Read more…
DNA storage could change the way we store and archive information.
It wasn’t enough for Dr. George Church to help Gilbert “discover” DNA sequencing 30 years ago, create the foundations for genomics, create the Personal Genome Project, drive down the cost of sequencing, and start humanity down the road of synthetic biology. No, that wasn’t enough.
He and his team decided to publish an easily understood scientific paper (““Next-generation Information Storage in DNA“) that promises to change the way we store and archive information. While this technology may take years to perfect, it provides a roadmap toward an energy efficient, archival storage medium with a host of built-in advantages.
The paper demonstrates the feasibility of using DNA as a storage medium with a theoretical capacity of 455 exabytes per gram. (An exabyte is 1 million terabytes.) Now before you throw away your massive RAID 5 cluster and purchase a series of sequencing machines, know that DNA storage appears to be very high latency. Also know that Church, Yuan Gao, and Sriram Kosuri are not yet writing 455 exabytes of data, they’ve started with a more modest goal of writing Church’s recent book on genomics to a 5.29 MB “bitstream,” here’s an excerpt from the paper:
If you know anything about filesystems, this is an amazing paragraph. They’ve essentially defined a new standard for filesystem inodes on DNA. Each 96-bit block has a 19-bit descriptor. They then read this DNA bitstream by using something called Polymerase Chain Reaction (PCR). This is important because it means that reading this information involves generating millions of copies of the data in a format that has been proven to be durable. This biological “backup system” has replication capabilities “built-in.” Not just that, but this replication process has had billions of years of reliability data available.
Chas Emerick on how Clojure can make a difference to developers.
REPL is built into Clojure, and you can connect to any running Clojure process and modify and execute code. In this interview, "Clojure Programming" co-author Chas Emerick discusses the possibilities this introduces for Clojure developers.
Shifts for sysadmins and a surprising use for Chef.
OpsCode chief community officer Jesse Robbins discusses cloud infrastructure automation and the most surprising use of Chef he's seen so far.
How a game-playing robot could help shape the future of mobile testing.
If you try to talk to Jason Huggins about Selenium, he'll probably do to you what he did to us. He'll bring his Arduino-based Angry Birds-playing testing robot to your interview and then he'll relate his invention to the larger problems of mobile application testing and cloud-based testing infrastructure.
Square CTO Bob Lee digs into Java's current position.
In this short interview from JavaOne, Square CTO Bob Lee discusses Java references and weighs in on the state of Java and the industry.
Bob McWhirter on Ruby, Java and TorqueBox.
Bob McWhirter, JBoss Fellow, Codehaus Despot, and creator of TorqueBox, discusses the boundary between Java and Ruby and his efforts to make Torquebox "a real first-class Ruby platform that works the way Rubyists expect".