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.

2010: Who bought Heroku? Really?

When Salesforce.com purchased Heroku, I was initially surprised. I didn’t see it coming, but it made perfect sense after the fact. Heroku is very much an analog to Salesforce for developers, and Heroku brought something to Salesforce that Force.com couldn’t achieve: developer authenticity and community.

Heroku, like Salesforce, is the opposite of shrink-wrapped software. There’s no investment in on-premise infrastructure, and once you move to Heroku — or any other capable platform-as-a-service (PaaS), like Joyent — you question why you would ever bother doing without such a service.  As a developer, once you’ve made the transition to never again having to worry about running “yum update” on a CentOS machine or worry about kernel patches in a production deployment, it is difficult to go back to a world where you have to worry about system administration.

Yes, there are arguments to be made for procuring your own servers and taking on the responsibility for system administration: backups, worrying about disks, and the 100 other things that come along with owning infrastructure. But those arguments really only start to make sense once you achieve the scale of a large multi-national corporation (or after a freak derecho in Reston, Va).

Jokes about derecho-prone data centers aside, this market is growing up, and with it we’re seeing an unbeatable trend of obsoleting yesterday’s system administrator.  With capable options like Joyent and Heroku, there’s very little reason (other than accounting) for any SMB to own hardware infrastructure. It’s a large capital expense when compared to the relatively small operational expense you’ll throw down to run a scalable architecture on a Heroku or a Joyent.

Replace several full-time operations employees with software-as-a-service; shift the cost to developers who create real value; insist on a proper service-level agreement (SLA); and if you’re really serious about risk mitigation, use several platforms at once.  Heroku is exactly the same play Salesforce made for customer relationship management (CRM) over the last decade, except this time they are selling PostgreSQL and a platform to run applications.

Heroku is closer to what Salesforce was aiming for with Force.com.  Here are two things to note about this Heroku acquisition almost two years after the fact:

1. Force.com was focused on developers — a certain kind of developer in the “enterprise.” While it was clear that Salesforce had designs on using Force.com to expand the market, the existing marketing and product management function at Salesforce ended up creating something that was way too connected to the existing Salesforce brand, along with its anti-developer message.
2. Salesforce.com’s developer-focused acquisitions are isolated from the Salesforce.com brand (on purpose?) — When Benioff discussed Heroku at Dreamforce, he made it clear that Heroku would remain “separate.”  While it is tough to know how “separate” Heroku remains, the brand has changed very little, and I think this is the important thing to note two years after the fact. Salesforce understands that they need to attract independent developers and they understand that the Salesforce brand is something of a “scarecrow” for this audience. They invested an entire decade in telling businesses that software isn’t necessary, and senior management is too smart to confuse developers with that message.

Investments point toward greater developer outreach: Sauce Labs

This brings me to Sauce Labs — a company that recently raised $3 million from “Triage Ventures as well as [a] new investor Salesforce.com,” according to Jolie O’Dell at VentureBeat.

Sauce Labs provides a hosted web testing platform.  I’ve used it for some one-off testing jobs, and it is impressive.  You can spin up a testing machine in about two minutes from an array of operating systems, mobile devices, and browsers, and then run a test script either in Selenium or WebDriver. The platform can be used for acceptance testing, and Jason Huggins and John Dunham’s emphasis of late has been mobile testing.  Huggins supported the testing grid at Google, and he started Selenium while at ThoughtWorks in 2004. By every measure, Sauce Labs is a developer’s company as much as Heroku.

Sauce Labs, like Heroku before it, also satisfies the Salesforce.com analogy perfectly. Say I have a company that develops a web site. Well, if I’m deploying this application to a platform like Joyent or Heroku continuously, I also need to be able to support some sort of continuous automated testing system. If I need to test on an array of browsers and devices, would I procure the necessary hardware infrastructure to set up my own testing infrastructure, or … you can see where I’m going.

I also think I can see where Salesforce is going. They didn’t acquire Sauce Labs, but this investment is another data point and another view into what Salesforce.com is paying attention to. I think it has taken them 4-5 years, but they are continuing a push toward developers. Heroku stood out from the list of Salesforce acquisitions: It wasn’t CRM, sales, or marketing focused; it was a pure technology play. Salesforce’s recent investments, from Sauce Labs to Appirio to Urban Airship, suggest that Salesforce is become more relevant to the individual developer who is uninterested in Salesforce’s other product offerings.

Some random concluding conjecture

Although I think it would be too expensive, I wonder what would happen if Salesforce acquired GitHub. GitHub just received an unreal investment ($100M), so I just don’t see it happening. But if you were to combine GitHub, Heroku, and Sauce Labs into a single company, you’d have a one-stop shop for the majority of development and production infrastructure that people are paying attention to.  Add an Atlassian to the mix, and it would be tough to avoid that company.

This is nothing more than conjecture, but I do get the sense that there has been an interesting shift happening at Salesforce ever since 2008. I think the next few years are going to see even more activity.

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:

We converted an html-coded draft of a book that included 53,426 words, 11 JPG images and 1 JavaScript program into a 5.27 megabit bitstream. We then encoded these bits onto 54,898 159nt oligonucleotides (oligos) each encoding a 96-bit data block (96nt), a 19-bit address specifying the location of the data block in the bit stream (19nt), and flanking 22nt common sequences for amplification and sequencing. The oligo library was synthesized by ink-jet printed, high-fidelity DNA microchips. To read the encoded book, we amplified the library by limited-cycle PCR and then sequenced on a single lane of an Illumina HiSeq.

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.

While this technology may only be practical for long-term storage and high-latency archival purposes, you can already see that this paper makes a strong case for the viability of this approach. Of all biological storage media, this work has demonstrated the longest bit stream and is built atop a set of technologies (DNA sequencing) that have been focused on repeatability and error correction for decades.

In addition to these advantages, DNA storage has other advantages over tape or hard drive — it has a steady-state storage cost of zero, a lifetime that far exceeds that of magnetic storage, and very small space requirements.

If you have a huge amount of data that needs to be archived, the advantages of DNA as a storage medium (once the technology matures) could quickly translate to significant cost savings. Think about the energy requirements of a data center that needs to store and archive an exabyte of data. Compare that to the cost of maintaining a sequencing lab and a few Petri dishes.

For most of us, this reality is still science fiction, but Church’s work makes it less so every day. Google is uniquely positioned to realize this technology. It has already been established that Google’s founders pay close attention to genomics. They invested an unspecified amount in Church’s Personal Genome Project (PGP) in 2008, and they have invested a company much closer to home: 23andme. Google also has a large research arm focused on energy savings and efficiency with scientists like Urs Hozle looking for new ways to get more out of the energy that Google spends to run data centers.

If this technology points the way to the future of very high latency, archival storage, I predict that Google will lead the way in implementation. It is the perfect convergence of massive data and genomics, and just the kind of dent that company is trying to make in the universe.

I asked Chas to enumerate some of the topics that would make a difference to developers: something that would attract attention to Clojure as a language, so we wouldn’t spend time talking about yet another syntax. One of the first things he immediately mentioned was REPL. Writing code in Clojure is often about making changes and immediately seeing your results. Clojure has emphasized this shell-like approach to development and created an environment that allows for immediate evaluation of code and incorporating changes into a running process.

Clojure differs from other languages in that this interactive shell isn’t an afterthought. Ruby’s IRB or Java’s beanshell are similar attempts at interactivity, but they are not primary features of each language. With Clojure, REPL is built in, and you can connect to any running Clojure process and modify and execute code. In this interview we discuss some of the possibilities that this introduces for Clojure developers.

The full interview is embedded below and available here. For the entire interview transcript, click here.

Highlights from interview:

On what is unique about REPL

“…what’s really unique about Clojure is that most people’s workflow when developing and using Clojure is tightly tied to the REPL, using the dynamic interactive development capabilities that the REPL provides to really boost your productivity and give you a very immediate sense of control over both the Clojure runtime, the application, programming or service that you’re building.” [Discussed 00:52]

How does REPL affect your development?

“Generally what you do in Clojure is you start up a JVM instance that is running the Clojure runtime and starts a REPL that you connect to … then you stay connected to that running Clojure runtime for hours, days. I’ve had Clojure environments running for weeks in an interactive development setting, where you gradually massage the code that’s running within that runtime that corresponds to files you have on disc.

“You can choose what code to load into that environment at any time, massage the data that’s being processed by your application. It’s a great feedback mechanism and gives you an immediate, fine‑grain sense of control over what you’re doing [Discussed 01:18]

On using REPL to deploy production patches

“It’s true, you can start up a REPL running on Heroku right now, connect to it and modify your application. Everything will work as you would expect if you happen to be running the application using Foreman locally.

“You don’t want to be, in general, modifying your production environments from an interactive standpoint. You want to have a repeatable process … Depending on the circumstances, it can be reasonable in a ‘fire drill’ situation to push a critical, time‑sensitive patch out to production … 99% of the time you probably shouldn’t reach for it, but it’s very good to know that it’s there.” [Discussed 05:44]

On using REPL for direct access to production statistics

“JMX is great in terms of providing a structured interface for doing monitoring. But you need to plan ahead of time for the things you’re going to monitor for and make sure you have the right extensions to monitor the things that you care about.

“Having a REPL available to connect to in every environment — whether it’s development, user acceptance, functional testing or production — means that when you need to, you can get in there and write a one‑off function. Pull some data from this database, see what’s going on with this function, capture some data that you wouldn’t normally be capturing, stuff that may be far too large to log or to practically get access through JMX. It’s a great tool.” [Discussed 05:44]

OSCON 2012 — Join the world’s open source pioneers, builders, and innovators July 16-20 in Portland, Oregon. Learn about open development, challenge your assumptions, and fire up your brain.

Save 20% on registration with the code RADAR

Related:

• Clojure Programming (book)
• Clojure: Lisp meets Java, with a side of Erlang
• Clojure is a language for data

The full interview is embedded below and available here. For the entire interview transcript, click here.

Highlights from interview:

On the evolution of the sysadmin

“What has happened is that the old school operator, where you had a three-ring binder and you followed procedures over and over again, frankly, that job sucked. What has happened over a period of time is that sysadmin skill set has been expanding to include more and more basic infrastructure software development. What has been most interesting in that transition, has been essentially, I think of it as an expansion in the job roles going from basic systems administration to really what we call infrastructure engineering. The road ahead for everybody, who builds and maintains infrastructure or applications in software, looks like building a very powerful software platform.” [Discussed 01:47]

How much awareness is there of technologies like Chef, Puppet, and CFEngine?

“When I look at this and I think, ‘Where are we?’ we are probably at less than 1% of the total addressable market. We have got a long way to go. It’s a big space. It is in giant flux. We are moving from software developers, sysadmins and their management up to the CIO and CEO. That’s going to be a decade-long revolution, just like it has been with open source.” [Discussed 04:40]

What’s the most surprising use of Chef so far?

“Large-scale stuff … for instance, the work that Cycle Computing is doing taking the Amazon spot market for large instances. They are combining that with a tool they wrote called Grill, which is based on Chef.

“They are running these 50,000-core protein folding jobs to find cures for cancer. They are building a supercomputing cluster in a couple of minutes, where the consumer of that is the scientist. It’s not like they’ve got some big engineering team. It’s almost like a single click or a few clicks and these very, very large, typically previously prohibitively expensive workloads. They are using Chef for that.

“It’s unbelievable. 50,000 cores in a couple of minutes for under $5,000 an hour, where previously that would have been a massive, multimillion-dollar, multi-year supercomputing project. That stuff is available on demand.” [Discussed 06:53]

Chefcon is next week, May 15-18, in San Francisco. The Velocity Conference is next month, June 25-27, in Santa Clara, Calif.

Velocity 2012: Web Operations & Performance — The smartest minds in web operations and performance are coming together for the Velocity Conference, being held June 25-27 in Santa Clara, Calif.

Save 20% on registration with the code RADAR20

Among the other highlights from our interview:

• O’Grady on the challenge of big data: “Kevin Weil (@kevinweil) from Twitter put it pretty well, saying that it’s hard to ask the right question. One of the implications of that statement is that even if we had perfect access to perfect data, it’s very difficult to determine what you would want to ask, how you would want to ask it. More importantly, once you get that answer, what are the questions that derive from that?”
• O’Grady on the scarcity of data scientists: “The difficulty for basically every business on the planet is that there just aren’t many of these people. This is, at present anyhow, a relatively rare skill set and therefore one that the market tends to place a pretty hefty premium on.”
• O’Grady on the reasons for using NoSQL: “If you are going down the NoSQL route for the sake of going down the NoSQL route, that’s the wrong way to do things. You’re likely to end up with a solution that may not even improve things. It may actively harm your production process moving forward because you didn’t implement it for the right reasons in the first place.”

The full interview is embedded below and available Here. For the entire interview transcript, click here.

Fluent Conference: JavaScript & Beyond — Explore the changing worlds of JavaScript & HTML5 at the O’Reilly Fluent Conference (May 29 – 31 in San Francisco, Calif.).

Save 20% on registration with the code RADAR20

Related:

• Building data science teams
• The NoSQL movement
• Data science democratized

He also was wondering if he could talk about something entirely different: “a Selenium-powered, ‘Angry Birds’-playing mobile-phone-testing robot.” While I had initially been worried I’d have to sit for several hours of interviews about Component Dependency Ennui 4.2, here was an interesting guy that wanted to not only demonstrate his “Angry Birds”-playing robot but also relate it to his testing-focused startup Sauce Labs. I welcomed the opportunity, and here’s the result:

From what I could gather, Huggins’ bot is driving two stepper motors that control a retractable “dowel” finger covered in some sort of skin-like material that can fool the capacitive touch sensor of a mobile device. He sends keystroke commands through this Arduino-based controller, which then sends signals to two stepper motors. The frame of the device is made of what looks like balsa wood. He’s calling it a “BitBeamBot.” You can find out all about it here and you can see it in action in the following video:

Relating BitBeamBot to Sauce Labs and Selenium

In the course of the interview it became clear that BitBeamBot was the product of an off-time project. Here’s how Huggins explained it: Imagine a wall of these retractable dowels, each representing a single pixel. if you could create a system to control these dowels, then you could draw pictures with a controller.

While working on this project, Huggins attended a Maker Faire and found some suitable technology. His creation of a single-arm controller then led to his big “eureka” moment: This same technology could create a robot that can play “Angry Birds,” and if a contraption can play “Angry Birds,” it’s a simple leap to create a system that can test any mobile application in the real world.

Huggins went through a similar discovery process with Selenium. Selenium is a contraption that supports and contains a browser. You feed a series of instructions and criteria to a browser and then you measure the output.

With BitBeamBot, Huggins has taken the central software idea that he developed at Thoughtworks and applied it to the physical world. He envisions a service from Sauce Labs, the company he co-founded, where customers would pay to have mobile applications tested in farms of these mobile testing robots.

Sauce Labs

Sauce Labs is focused on the idea that testing infrastructure is often more expensive to set up and maintain than most companies realize. The burden of maintaining an infrastructure of browsers and machines can often exceed the effort required to support a production network.

With Sauce Labs you can move your testing infrastructure to the cloud. The company offers a service that executes testing scripts on cloud-based hardware. For a few dollars you can run a suite of unit tests against an application without having to worry about physical hardware and ongoing maintenance. Sauce Labs is trying to do for testing what Amazon EC2 and other services have done for hosting.

Toward the end of the interview (contained in the first video, above) we also discussed some interesting recent developments at Sauce Labs, including a new system that uses SSH port forwarding to allow Sauce Labs’ testing infrastructure to test internal applications behind a corporate firewall.

Strata 2012 — The 2012 Strata Conference, being held Feb. 28-March 1 in Santa Clara, Calif., will offer three full days of hands-on data training and information-rich sessions. Strata brings together the people, tools, and technologies you need to make data work.

Save 20% on registration with the code RADAR20

Related:

• Bob Lee on Java references and the state of Java

Lee is one of the reasons the Android platform just works. He was responsible for Android’s core APIs and libraries. His contribution to Google is also greater than just working on one of the most popular mobile platforms in the world. Along with Dhanji Prasanna, Jesse Wilson, and Kevin Bourrillion, Lee was the creator of a dependency framework named Guice. Now Guice isn’t nearly as popular as Spring, but it runs many of Google’s critical applications and it has been incorporated into a few high profile projects, such as Maven. Bottom line: If you use Google’s products and you happen to have an Android phone, Lee’s handiwork is all over the place.

At JavaOne, Lee and I discussed Java references and he fielded a few free-form questions about the Java community. The following video contains the full interview.

In the associated audio interview 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”.

McWhirter will expand on many of these ideas during his session at next week’s OSCON Java conference in Portland, Ore.

An Interview with Bob McWhirter on Torquebox, Java, and Ruby

(For the textually inclined, a full transcript from the McWhirter interview is posted below).

Bob McWhirter: I am Bob, Bob McWhirter. I have a couple of titles, I guess, but currently I am the JBoss Fellow with Red Hat, which means I get to go do research and development and figure out what the next cool things we’re going do are.

Previous to that, of course, I was the founder of The Codehaus, and
I’ve been involved in open source for probably 10 years now, if not
longer.

Tim O’Brien: What is your session going to be on?

BM: The session that I’m giving these days is typically talking about
the power of Java, but with the beauty of Ruby, that you don’t have to
start over from scratch just because you change languages. You can
take all the great stuff you know, whether it’s third-party libraries
you’re using or if it’s your own legacy components and be able to use
them and take baby steps into the world of Ruby and to taking
advantage of the beautiful expressiveness of Ruby.

TO: Java programmers learning Ruby. Is that a wave that’s already
passed or do you think that’s a wave that’s just starting to crest?

BM: I think we kind of go in a couple of cycles here, honestly. There
was a big surge in Ruby a couple years ago where a lot of Java people
just got pissed off and annoyed with Java enough to jump over to the
world of Ruby. That was kind of a rebellion, if you will, kind of a
heartbreak where they gave up on Java and moving over to Ruby.

I think now, though, we’re seeing a more rational kind of move of
people who want to just add Ruby to their toolbox. Not necessarily
trying to rebel against Java and get away from Java, but just trying
to get away from quite so much Java.

One of the things I’m seeing more of is where people are taking their
legacy components, but let’s say, rewriting a front end in Ruby. Their
view layer or whatnot, or maybe building small little departmental
type of applications with Ruby just to get their toes wet. And really
evaluating it in earnest, as opposed to as a rebellion or as a
fed-up-ness with Java or whatnot.

We support CDI in TorqueBox, so you can inject your Java bit over into
your Rails application and use them. You can get started really
quickly and really easily with your existing stuff and just “let’s
throw up a new web page that’s written in a Rails app or a Sinatra app”.

I think we’re just at the beginning. I think as JRuby gets better and
as things like TorqueBox continue to improve – and particularly if we
ever get, let’s say, a supported offering behind it where you can go
choke Red Hat’s neck if something breaks – then I think that will give
more enterprises the comfort level they need to move over to Ruby or
to start experimenting more with Ruby.

I don’t think it’s passed us by. I don’t think we’ve missed this boat
and we’re going to lose it to Scala, however it’s pronounced, or
anything. I think the market will continue to grow for Java people who
are moving over to Ruby.

OSCON Java 2011, being held July 25-27 in Portland, Ore., is focused on open source technologies that make up the Java ecosystem. (This event is co-located with OSCON.)

Save 20% on registration with the code OS11RAD

Torquebox: What problem does it solve?

TO: You were working on Ruby and Java stuff for a while, a couple
years now, three or four years?

BM: Yeah, a little over two now, about two and a half.

TO: Why did you start paying attention to this?

BM: It’s a little on the winding road. I joined JBoss four years ago,
I guess, and I joined as a manager and I learned pretty quickly that
I’m not a very good manager. So I took a sabbatical from the job for
about three months. With a friend of mine, who I now work with, we
started trying to do a startup and we, like any other startup, we did
it with Ruby on Rails.

I really liked that environment and I had used Ruby on Rails before,
of course, building the Codehaus. I really liked it, but my sabbatical
was up, the startup failed, and I had to go back to this Java
Corporation. I’m thinking, “Well, what can I do to take my love of
Ruby on Rails and still get a paycheck from the Java Corporation?”

Thankfully, JRuby exists, and start gluing it onto JBoss AS. Being a
fellow thankfully meant that I didn’t have to produce revenue pretty
quickly or anything. So I could take the time to look at how do we
take JBoss AS5, at that point in time, and glue JRuby to it and make a
good experience for Rubyists. And also give Java people an
alternative, if you will, a way to start playing with Ruby without
having to change their entire platform.

My first goal was really just to get Rails running on top of JBoss
using JRuby. Then from there it’s like, “Well, we got that done. Let’s
add to it. Let’s do more. Let’s make it enterprise-y.”

TO: Coincidentally, JRuby was a product of Codehaus. It still is.

BM: Yeah, it’s had a weird history. Charlie Nutter kind of drives it
now with Thomas Enebo. But they weren’t the founders. I’m not sure who
actually started the project. At some point it was over at Kenai for a
while, Sun community. Then part of it was at Codehaus. Then I don’t
know what Kenai is up to or Java.net.

It’s unfortunately one of those projects that’s scattered around. But
the fact that it’s having some touches with Codehaus, I think, does
make it easier for me to work with those guys and get to know them and
have a little mutual respect because TorqueBox ultimately benefits
them and JRuby certainly benefits TorqueBox. So it’s a very symbiotic
relationship I have with those guys.

TO: What was the main technical problem that you were trying to solve?

BM: It’s really kind of two-fold. The first problem doesn’t involve
JRuby Rack. It actually involves Warbler, or previous to that it was
GoldSpike, I believe it was called. Which is where you can take your
Rack application or your Rails application, bundle the JRuby Rack and
stuff it inside a WAR file. Then you go deploy this WAR like you would
any other WAR file. Your app server doesn’t know anything other than
WAR file.

The problem I have with that is that I’m having to stuff everything
inside a WAR file, basically a packaging step. One of the beauties
about Rails work is that you can edit your files there, live, on
disk. You have your whole source tree laid out and your app is running
from that source tree on disk. There is no compilation. There is no
packaging. I edit a model. I edit a view. I edit a controller. Those
changes are picked up live. If I have to stuff everything inside a WAR
file I’ve broken that quick development cycle. I now have to edit
code, package, deploy, and then test.

With regular Rails development I just edit and I go to my browser and
hit refresh and I see my changes immediately. That was what I didn’t
like about Warbler as far as a way to deploy Rails applications on
Java app servers. Certainly made it possible, but it didn’t make it
fun and easy and it lost a lot of the cool stuff you get from
developing in Rails in the first place.

Now, that’s not such a big deal if you’re developing just vanilla
Rails apps that run the same way under MRI, traditional Dbase Ruby or
run under JRuby inside a WAR. You can develop under one platform,
package it and deploy under another. But there you’re only dealing
with the web part of the problem.

That’s the second half of what I was trying to attack, was that our
apps are so much more than web and Rails is only just web, Rack is
only just web. But what we do for daemons, what do we do for handling
message queues, that kind of stuff.

That’s where I find a lot of the fun development going on in
TorqueBox. We get to take these functional solutions that the Java
world has and map them down to the Ruby APIs or create Ruby APIs for
them and make it a joy to work with like message driven Beans, if you
will, from Ruby where you never have to think about message driven.

Once you do that then you can’t do this kind of stuff under MRI,
traditional Ruby, so you can’t just develop an app under MRI and
bundle up in a WAR and send it over to your app server. So that’s
where we decided to try to make TorqueBox a real first-class Ruby
platform that works the way Rubyists expect. No more packaging in to
WAR files or anything with Warbler.

Then also give them more than just the web components. That’s where we
start bringing the message listeners, start bringing scheduled jobs
and daemons and things to the app server.

In this interview I ask Andrew to briefly introduce Tor and talk about some interesting useage statistics that show adoption of this anti-surveillance technology from within Iran. He answers a question about whether Tor is “unstoppable” and comments on the legality of running a Tor node. For the full interview, listen here.

The Tor Project

First, what is Tor? From The Tor Project:

Tor is free software and an open network that helps you defend against a form of network surveillance that threatens personal freedom and privacy, confidential business activities and relationships, and state security known as traffic analysis.
Tor protects you by bouncing your communications around a distributed network of relays run by volunteers all around the world: it prevents somebody watching your Internet connection from learning what sites you visit, and it prevents the sites you visit from learning your physical location. Tor works with many of your existing applications, including web browsers, instant messaging clients, remote login, and other applications based on the TCP protocol.

When you run a Tor node, you are adding another node to a grid of computers that are used to establish random encrypted paths between each node to satisfy any given request. Law enforcement, military agencies, intelligence networks, journalists, and dissidents frequently use Tor to bypass restrictions and avoid surveillance. Andrew Lewman, Tor’s Executive Director, wanted to be very clear that the Tor Project itself does not take positions on conflicts, and does not involve itself in resisting oppressive regimes. In response to a question about traffic from Iran, Andrew Lewman produced the following data:

New client connections from within Iran have increased nearly 10x over
the past 5 days. Overall, Tor client usage seems to have increased 3x
over the past 5 days. There are a lot of rough numbers in these
statements, and they are very conservative. However, the source data
we’re reviewing continues to show these results.

For more information, see Andrew’s blog post from last night: “Measuring Tor and Iran”. Here’s a graph from Andrew Lewman of Tor client count over the past few days, it appears that Tor is becoming an increasingly popular way for people in Iran to use the network to avoid surveillance.

But is it legal? The Legality of Running a Proxy Server

Peter Eckersley, Staff Technologist at the EFF, took some time to answer some very simple questions about EULAs, Tor, and the legality of running a proxy server.

Q: Various broadband providers state in EULAs that a customer must
secure the equipment used to provide access to the Internet. What is
the position of the EFF with regard to the legality of these EULAs?
Are people breaking the law by providing an open access router?

Peter Eckersley: It’s impossible to comment on broadband EULAs in general; each of them has
different specific language and ISPs deploy them in different ways. We aren’t
aware of any case in which a broadband subscriber was sued for running an open
wireless router, a proxy, or similar technology for sharing their connection
with others.

Q: The last update to the Tor FAQ from the EFF on the Tor site was
from 2005. Have there been any developments with the EFF in relation
to Tor? Since 2005 is there more clarity as to the legality of
running an Exit Node in a Tor network?

Peter Eckersley: The EFF Tor FAQ still reflects our opinions about the legality of Tor. It hasn’t changed since 2005 because there haven’t been any published cases or
other events that have changed our views.

Q: What advice would the EFF have for anyone new to setting up a proxy
server this week (as many have done to support protestors in Iran)?
Is it legal? What issues do people need to be aware of?

Peter Eckersley: EFF’s advice at this point is that people should consider setting up Tor bridge nodes or Tor routers instead of proxy servers. Several thousand new proxy servers have appeared in the past week, but we fear than unencrypted proxies
leave Iranians vulnerable to surveillance and continued censorship by the
Iranian government. SSL ecrypted proxies are better in this respect, but they
are harder to set up than Tor routers, and there are some reports that the
Iranian government has succeeded in blocking access to at least some encrypted
proxies.

Fixed Typo @ 3:23 PM Central Saturday: One of my questions for the EFF had a rather important typo – I had typed Iraq instead of Iran. Fixed.

In this 10 minute interview with Sarah Milstein, co-author the Twitter Book, she discusses how Twitter is being used by Iranian protesters and how Twitter has accidentally created a system not easily overwhelmed or controlled by authorities. She also talks about the continued evolution of Twitter over the past few months. I ask her to contrast the reaction to Twitter during the Swine Flu with the reaction to Twitter during the recent events in Iran, and it is clear from her answers that as Twitter becomes more familiar to the general public the significance and meaning of the platform are constantly evolving. Milstein comments on whether Twitter is becoming more “serious”, and responds to the continued stream of stories by journalists who feel the need to pass judgment on this still-emerging communications platform. Milstein also discusses this week’s 140 characters conference in New York.

On the Iranian protests, Milstein is very deliberate to say that the powerful aspect of Twitter during the Iranian protests is that Iranians within the country were able to use it to communicate with one another and with those outside of the country. Toward the end of the interview, I ask Milstein to comment on inadvertent transparency in the context of a previous post by Brady Forest. The Iranian protests story this week was as much about facilitating communications as it was about making sure that protesters were not communicating unintended information to the Iranian government.

Another Twitter Backlash

In the continued reaction to the Iranian protests, we’re seeing a new surge of Twitter backlash. The last backlash occurred during the Swine Flu, a few days after the initial surge of Twitter activity, journalists felt obliged to point out Twitter’s uselessness in the face of the flu crisis. It appears that the same cycle is playing itself out this time. The difference this week is that Twitter is much more familiar to The Fourth Estate than it was just a few weeks ago. More journalists are approaching Twitter for what it is, a tool, like email, which allows individuals communicate with one another and less like a popularity contest. As I wrote previously, the often negative reaction of journalists to Twitter has more to do with unfamiliarity with the medium. If you follow the wrong people, Twitter is noise, if you stick with it, you refine your following list and it starts to make much more sense.

Persistent Twitter skeptics such as Morozov at Foreign Policy still regards Twitter as irrelevant to the current Iranian crisis noting that the Iranian regime has more important things to worry about than Twitter protests. Iran’s biggest weakness at this point is the unstoppable force of social media networks and instantaneous communications medium. These protests would not have reached a critical mass without collaborative, electronic, social media. By singling out Twitter, journalists oversimplify the picture making it easier to discount the power of this emerging medium by using a system with a silly name. These protests are facilitated by an entire technology stack which includes Twitter, cell phones with cameras, Facebook, SMS, YouTube, Google, Papillion’s anonymizing PHP Twitter gateway. Iranian colleagues have told me directly that Web 2.0 technologies are allowing them to communicate with other Iranians in way that were impossible a few years ago.

There are still many who think Twitter is a silly joke – a toy. Maybe it is the name that confuses them. The real power of Twitter isn’t the obvious communication it facilitates, it is in the technical success that they have achieved, the ability to support millions of simultaneous and instantaneous many-to-many messages was neither trivial nor obvious just two years ago. It is tempting to equate Twitter with Google, and although I consider them to be functioning on different scales (Twitter is tiny to Google’s massive influence and weight), I do think that both systems present a mirage of simplicity that masks a larger technical revolution within the data center. They’ve made a Herculean task seem so trivial and so easy, it is easy to write them off.