Tag: open source

Tech: Three reasons healthcare.gov failed all of us

By Ashish Datta | Leave a Comment on Tech: Three reasons healthcare.gov failed all of us

Since going live early this month, Healthcare.gov has been universally panned for being unstable, unusable, and close to an outright disaster. As the publicity of the problems have intensified, it’s become clear that the project has was mismanaged and probably sloppily developed. The team certainly faced daunting challenges like going from 0 to full capacity overnight but with a reported budget of over $50 million dollars and three years to execute it’s hard to have too much sympathy. Anyway, without knowing the project guidelines, business constraints, and other considerations it would be irresponsible to armchair quarterback and predict technical decisions that would have performed any better. However, on the non-technical side there are some strategic and architectural decisions that are disappointing.

The Team

Like any large project, the success of the project is ultimately driven by the strength of the team behind it. The experience, structure, and mindset of the team building the project will be the key drivers for what tradeoffs are made, how things are architected, and of course how development is executed. Unfortunately for us, according to the Washington Post, CGI Federal the company that built healthcare.gov is both a relative newcomer to US government IT consulting and also has a spotty track record of building large, commercial web applications.

I’ll be the first to admit that I have no background in government procurement, but it strikes me as odd that the Obama administration didn’t handpick the team that was going to build the software for their watershed legislation. Most notably, since the sweeping democratic win in 2008 has largely been attributed to the Obama campaign’s exceptional technology resources. Brad Feld actually suggested bringing in Harper Reed who served as the CTO of the campaign to fix the problems, but why wasn’t he leading the project from the outset?

Transparency (or lack thereof)

For an administration that campaigned on transparency (lets ignore NSA/drones), the lack of transparency surrounding healthcare.gov has been severely dissapointing. The lack of information has left media outlets reporting outlandish claims like that the site is 500 million lines of code or that Verizon has been brought in to help triage the situation. Apart from technical details, the White House has also remained completely silent on visitor and enrollment statistics even though they clearly have them since the site is running a slew of analytics and monitoring services. Leaving the public in the dark has driven rampant speculation and left everyone wondering “What if they aren’t releasing data because its THAT bad”.

Another area where healthcare.gov has been dissapointingly secretive is the actual source code of the project. Although some people, including Fred Wilson, are recommending open sourcing the code as a potential triage measure the code really should of been available from the outset. Even if the proprietary licensed technology had remained private, tax payer dollars financed the site and open sourcing it from the outset would have added some much needed oversight and accountability. Looking at the site, its using several open source libraries anyway including Twitter Bootstrap, jQuery, BackboneJS, and apparently violating the OSS license for jQuery.Datatables.

No Plan B

One of the accepted truths in software engineering is that shit is going to break and that bugs will crop up in even the most heavily tested applications. Mix in things like legacy integrations and 3rd party APIs and issues almost become a guarantee. Despite this, looking at the rollout of healthcare.gov it’s clear that the team had no contingency plans for how to handle various error scenerios. As pieces of the application started to fail, they didn’t have any way to mitigate poor user experiences, losing data, or simply showing “fail whale” style error messages. And although bad at launch, the situation still seems just as bad 3 weeks later – with their band aid to simply boot users once they’ve reached their concurrent session limit.

Building a high traffic web app that interfaces with legacy systems, is highly available, and is also easy to use is undoubtedly still difficult but the failures of healthcare.gov haven’t just been technological but procedural and organizational as well. Hopefully someone has the experience and political clout to right the ship before the website’s troubled launch defines the healthcare law it was built to implement.

PHP: Installing HipHop PHP on Ubuntu

By Ashish Datta | 10 Comments on PHP: Installing HipHop PHP on Ubuntu

A couple of weeks ago, a blog post came across /r/php titled Wow HHVM is fast…too bad it doesn’t run my code. The post is pretty interesting, it takes a look at what the test pass % is for a variety of PHP frameworks and applications. This post was actually the first time I’d heard an update about HipHop in awhile so I was naturally curious to see how the project had evolved in the last year or so.

Turns out, the project has undergone a major overhaul and is well on its way to achieving production feature parity against the Zend PHP implementation. Anyway, I decided to give installing HipHop a shot and unfortunately their installation guide seems to be a bit out of date so here’s how you do it.

Quickstart

To keep things simple, I used a 64-bit Ubuntu 13.04 AMI (https://console.aws.amazon.com/ec2/home?region=us-east-1#launchAmi=ami-e1357b88) on a small EC2. One thing to note is that HipHop will only work on 64-bit machines right now.

Once you have the EC2 running, Facebook’s instructions on GitHub are mostly accurate except that you’ll need to manually install libunwind.

After that, you can test it out by running:

Awesome, you have HipHop running. Now just how fast is it?

Well you’ll have to check back for part 2…

PHP: Is PHP losing popularity?

By Ashish Datta | 3 Comments on PHP: Is PHP losing popularity?

I was on Quora earlier this week and ran across a question asking Why is PHP losing popularity? along with the elaboration being:

I’ve been keeping my eye on job boards and tech media, and it seems that the new trend is up with Node.js and down with PHP, Ruby staying about the same.
I know every tool has its purpose, but most web applications could be built in any language and framework and fare all the same. PHP is surely scalable, fast enough, safe enough, and heavily supported. Facebook has been happy enough to keep it around, and they have a lot to own up to.

The top two answers basically declare that PHP is on its way out because developers have more options (Ruby, Python NodeJS, etc.) and because the PHP ecosystem is “standing still”. It’s pretty clear that both of these answers are incomplete, if not outright wrong but then where does the truth lie?

Since this isn’t high school there isn’t a universal metric for how to evaluate the popularity of a given programming language. People tend to use things like search trends, job salaries, or the number of questions tagged on StackOverflow. These KPIs are fine for vanity comparisons but they don’t really reveal anything about the velocity, evolution, or enthusiasm for a language or framework. Since we’re concerned specifically with PHP, it’s easier to pick out specific examples that demonstrate its continuing popularity.

Drupal and WordPress

Although treated with disdain by developers, both applications power hundreds of millions of websites. According to Wikipedia, “WordPress is used by more than 18.9% of the top 10 million websites as of August 2013.” and Drupal “is used as a back-end system for at least 2.1% of all websites worldwide”. Which, to put in perspective, are both absolutely staggering numbers. On top of that, Automatic and Acquia, the companies commercially backing WordPress and Drupal, have been raising money and growing at a phenomenal pace.

So what does that mean for PHP? Velocity. With two well funded commercial companies actively developing, selling, and supporting PHP software there will be an increasing number of PHP sites coming online every day.

Symfony, Doctrine, and Zend

In the last few years, all 3 projects have completely overhauled their architectures and rewritten their code bases to incorporate from their respective “version 1s”. A total rewrite is a heroic feat for any project, let alone a popular open source project with thousands of users. All three rewrites have had a positive effect on the PHP community as a whole, including powering new frameworks (Symfony2, Laravel, etc.), enabling consolidation (Drupal 8 powered by Symfony Components), and of course pushing developers to evaluate PHP for new projects.

For PHP, this certainly signals a continuing evolution and a willingness of the community to learn, adapt, and evolve as the web changes.

The Language / PHP Internals

Unfortunately, this is one facet that strongly negatively affects the perception of the PHP ecosystem. Looking at PHP the language, plenty has been written bemoaning the inconsistencies, “wtfs”, and generally bizarre paradigms that the language constructs introduce. Although things have certainly gotten better, a lot of the same issues people were complaining about in PHP4 still exist today with no roadmap for them to be resolved.

Related to the language, is the PHP internals mailing list where core devs discuss language changes and generally how PHP will evolve. Most recently, core dev Anthony Ferrara outlined the major problems with the internals mailing list and generally why he feels the project is in trouble.

The issues with the PHP the language and its apparent lack of real evolution clearly affect the enthusiasm for the ecosystem. Outsiders look in and ask why we’re dealing with a “shitty” language while insiders are stuck defending PHP by pointing to features it got in 5.4 while meekly dodging the fact that there’s still no real unicode support.

So is PHP becoming less popular? Almost certainly not. In the last few years, dozens of interesting new tools and frameworks have been built and at least two VC funded companies have built successful business on software powered by PHP. Unfortunately, the perception of PHP the language as a ghetto is still persistent and the internals team seems to have no plans to change it.

Fun: Three programming languages I want to experiment with

By Ashish Datta | Leave a Comment on Fun: Three programming languages I want to experiment with

I spend my days almost entirely developing in PHP and Javascript with the occasional trip to Bash. For the most part, the style of the code ends up looking mostly the same, object oriented PHP and a mix of OO and functional Javascript. Because of this, I’ve been researching a couple of new languages I’d be interested in testing out. Anyway, here is my list – I’d love any feedback or suggestions!

Scala

From Wikipedia:

Scala is an object-functional programming and scripting language for general software applications, statically typed, designed to concisely express solutions in an elegant, type-safe and lightweight (low ceremonial) manner. Scala includes full support for functional programming (including currying, pattern matching, algebraic data types, lazy evaluation, tail recursion, immutability, etc.). It cleans up what are often considered to have been poor design decisions in Java (e.g. type erasure, checked exceptions, the non-unified type system) and adds a number of other features designed to allow cleaner, more concise and more expressive code to be written.

So what makes Scala interesting? Personally, a couple of things stand out. First, the type system looks powerful while also being unobtrusive enough to not offend my dynamic sensibilities. I’ll butcher any explanation of how it works but this presenation does a much better job. Another interesting Scala feature is its rich support for functional programming techniques. I’m excited to try out things like currying and pattern mathing. The last Scala feature that is particularly appealing is that it can be run through the interpreter or compiled to a JAR. Because of this, it would facilitate writing simple “one off” scripts and running them through the interpreter.

Go

Go has been making the rounds on the blogosphere lately so naturally its piqued my interest. From Wikipedia:

Go aims to provide the efficiency of a statically typed compiled language with the ease of programming of a dynamic language. Other goals include:

  • Safety: Type-safe and memory-safe.
  • Intuitive concurrency by providing “goroutines” and channels to communicate between them.
  • Efficient garbage collection “with low enough overhead and no significant latency”.
  • High-speed compilation.

At face value, Go looks familiar and comfortable primarily because of its C inspired syntax and imperative style. The big ticket Go features that look the most interesting are concurrency support and its package and dependency management system. I haven’t written much (or any?) concurrent code and exploring Go’s “goroutines” seems like a great place to start. The official docs provide a great overview of the concurrency features Go exposes. Managing dependencies is painful and nothing is worse than getting stuck in dependency hell. Go has a unique approach to solving these issues, favoring convention over configuration. This post has a great rundown of why Go’s solution looks like a win.

Lua

From Wikipedia:

Lua , from Portuguese: lua meaning moon; explicitly not “LUA”) is a lightweight multi-paradigm programming language designed as a scripting language with “extensible semantics” as a primary goal. Lua is cross-platform since it is written in ISO C.[1] Lua has a relatively simple C API, thus “Lua is especially useful for providing end users with an easy way to program the behavior of a software product without getting too far into its innards.”

Functionally, Lua is a fully featured scripting language written in C which makes it a perfect candidate for embedding places where users need to be able to “script” the behavior of a program. Looking at Wikipedia, Lua has made its way into dozens of projects – including Nginx and Apache. From a language perspective, Lua looks “clean” and somewhat similar to Javascript but the most interesting feature is the possibility of embedding it into a host application. PHP also has out of the box functionality to support embedding Lua.

Anyway, that’s my list – I’d love to hear about any other languages worth checking out.

Bootstrap: Customize the typeahead() render method

By Ashish Datta | 5 Comments on Bootstrap: Customize the typeahead() render method

Earlier in the week, I was looking to customize how the Bootstrap typeahead() plugin was rendering the autocomplete options. Surprisingly, looking at the options listed on the plugin there is no way to specify a custom renderer function. Poking around a bit, I ran across this pull request on GitHub it looks like changes to the typehead() plugin have been tabled since it’s going to be replaced in Bootstrap 3.0 anyway.

I didn’t really want to customize our version of Bootstrap for a single page so I went on the hunt looking for a way to customize the renderer without modifying the plugin. Looking at how the typeahead() plugin is instantiated I noticed that a reference to the “Typeahead()” object with the render() method is actually stored using data() for the element it’s activated on. Because of that, it’s actually relatively straightforward to just overwrite the render() method on the specific element that you’ve activated typeahead() on.

The code I ended up with basically looks like:

Anyway, just a fun tidbit. Questions or comments welcome as always.