- A General Technique for Automating NES Games — software that learns how to play NES games and plays them automatically, using an aesthetically pleasing technique. With video, research paper, and code.
- rietveld — open source tool like Mondrian, Google’s code review tool. Developed by Guido van Rossum, who developed Mondrian. Still being actively developed. (via Nelson Minar)
- KPI Dashboard for Early-Stage SaaS Startups — as Google Docs sheet. Nice.
- Life Without Sleep — interesting critique of Provigil as performance-enhancing drug for information workers. It is very difficult to design a stimulant that offers focus without tunnelling – that is, without losing the ability to relate well to one’s wider environment and therefore make socially nuanced decisions. Irritability and impatience grate on team dynamics and social skills, but such nuances are usually missed in drug studies, where they are usually treated as unreliable self-reported data. These problems were largely ignored in the early enthusiasm for drug-based ways to reduce sleep. […] Volunteers on the stimulant modafinil omitted these feedback requests, instead providing brusque, non-question instructions, such as: ‘Exit West at the roundabout, then turn left at the park.’ Their dialogues were shorter and they produced less accurate maps than control volunteers. What is more, modafinil causes an overestimation of one’s own performance: those individuals on modafinil not only performed worse, but were less likely to notice that they did. (via Dave Pell)
How a small and passionate team used modern techniques to shift a business on a short timeline.
Over the past year, I assisted in creating an application that helped shift a major part of IBM to a software-as-a-service (SaaS) model. I did this with the help of a small but excellent development team that was inspired by the culture and practices of web startups. To be clear, it wasn’t easy – changing how we worked led to frequent friction and conflict – but in the end it worked, and we made a difference.
In mid-2013, the IBM Service Management business and engineering leaders decided to make a big bet on moving our software to the cloud. Traditionally we have sold “on premises” software products. These are software products that a customer buys, downloads, and installs on their own equipment, in their own data centers and facilities. Although we love the on-premises business, we realized that cloud delivery of software is also a great option, and as our customers evolved to a hybrid on-premises / cloud future, we needed to be there to help them.
Scale and complexity call for leaving it to specialists
As applications move from onpremise to SaaS, the scale of deployments increases by orders of magnitude (to “webscale”). At the same time, application development and operation become tightly integrated and continuous deployment brings the frequency of updates down from months to days or even hours.
The larger scale makes the health of SaaS applications mission-critical and even existential to its providers, while the frequent updates increase the risk of failures. Therefore, monitoring and root cause analysis also become mission critical functions, and more instrumentation is needed to ensure the application’s quality of service. At the company I co-founded, we see customers using extensive and often tailored instrumentation that generates massive amounts of data (think hundreds of thousands of data streams and billions of data points per day).
Automating NES Games, Code Review Tool, SaaS KPIs, and No Free Lunch
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…
The closed core model requires businesses to determine where their unique value lies and to be generous in offering the public extra code that supports their infrastructure but does not drive revenue. This model may prove more robust and lasting than open core, which attracts companies occupying minor positions in their industries.
Python Unicode, Cognitive Enhancement, Journal Balk, Engineering SaaS
- Unicode in Python, Completely Demystified — a good introduction to Unicode in Python, which helped me with some code. (via Hacker News)
- A Ban on Brain-Boosting Drugs (Chronicle of Higher Education) — Simply calling the use of study drugs “unfair” tells us nothing about why colleges should ban them. If such drugs really do improve academic performance among healthy students (and the evidence is scant), shouldn’t colleges put them in the drinking water instead? After all, it would be unfair to permit wealthy students to use them if less privileged students can’t afford them. As we start to hack our bodies and minds, we’ll face more questions about legitimacy and ethics of those actions. Not, of course, about using coffee and Coca-Cola, ubiquitous performance-enhancing stimulants that are mysteriously absent from bans and prohibitions.
- Copywrongs — Matt Blaze spits the dummy on IEEE and ACM copyright policies. In particular, the IEEE is explicitly preventing authors from distributing copies of the final paper. We write scientific papers first and last because we want them read. When papers were disseminated solely in print form it might have been reasonable to expect authors to donate the copyright in exchange for production and distribution. Today, of course, this model seems, at best, quaintly out of touch with the needs of researchers and academics who no longer desire or tolerate the delay and expense of seeking out printed copies of far-flung documents. We expect to find on it on the open web, and not hidden behind a paywall, either.
- On the Engineering of SaaS — An upgrade process, for example, is an entirely different beast. Making it robust and repeatable is far less important than making it quick and reversible. This is because the upgrade only every happens once: on your install. Also, it only ever has to work right in one, exact variant of the environment: yours. And while typical customers of software can schedule an outage to perform an upgrade, scheduling downtime in SaaS is nearly impossible. So, you must be able to deploy new releases quickly, if not entirely seamlessly — and in the event of failure, rollback just as rapidly.
Cloud Checklist, Feedback Loops, Coverage Testing, and Un-national Services
- Multi-tenant SaaS Checklist — if you’re used to building single-site web apps, this is a simple overview of the differences when building multi-tenanted web apps. Nominally about Java, ending with a plug for its author’s product, but ignore all that and it’s still useful. (via Abhishek Tiwari on Twitter)
- Angel Investing: My First Three Years (Paul Buchheit) — interesting to see how it stacks up for him. What caught my eye was The more great YC companies there are, the more reasons there are for other smart founders to join YC–the clever feedback loop in YC, where graduates help the newbies, builds its quality and increases its first-mover advantage year after year. (via Hacker News)
- Coverstory — reports on coverage of unit tests in Xcode. (via Noah Gift on Delicious)
- A Musing About 2011 and an Un-National Generation (JP Rangaswami) — The emerging generations want to use services independent of location of “origin” and location of “delivery”. Attempts to create artificial scarcity (by holding on to dinosaur constructs like physical-location-driven identity) are being responded to by a whole slew of spoofing and anonymisation tools; as the law becomes more of an ass in this context, you can be sure that the tools will get better. Living in a country other than America brings this home.
Part 5 of the series, "What are the chances for a free software cloud?"
The merger of free software with cloud and web services is a win-win. The transition will take a buy-in from cloud and SaaS providers, a change in the software development process, a stronger link between computational and data clouds, and new conventions to be learned by clients of the services. (Part 5 of a 5-part series.)
Part 4 of the series, "What are the chances for a free software cloud?"
Let’s put together a pitch for cloud and web service providers. We have two hurdles to leap: one persuading them how they’ll benefit by releasing the source code to their software, and one addressing their fear of releasing the source code.