Twitter Bootstrap is the bee's knees.  At Nyaruka we've used it for virtually every single project since it arrived on the scene.  And we aren't the only ones.  Sites across the web have picked it up as a great tool to get functional, good looking designs up quickly.

But there's one downside to the popularity of Bootstrap, it is all too easy to have your site look like every other Bootstrap site.  To my eyes, the biggest giveaway that someone is using Bootstrap is the black nav bar.  It seems like the majority of sites use the default black nav bar, and that screams lazy.

We almost always customize the top bar color for our sites, and though they are still obviously Bootstrap to a trained eye, they add a bit of personality.  Whether it's a little green for our work with TechnoServe on their Coffee Transparency site, or showing off our company colors for our Ministry of Health feedback site, a little goes a long way.

Of course there's a reason not that many people change it.  That black nav bar isn't so bad looking, and Bootstrap doesn't make it particularly easy to change.  It can be especially annoying if you are using menus, having to track down all the variables needed in that fancy CSS takes some patience.

Thankfully, the upcoming 2.0 version (due out January 31st) introduces a couple variables to make things easier, though you'll still have to do a bit of hackery to deal with drop down menus.

Bootstrap is built using Less, so the first step is to get set up with that environment, Twitter gives some nice tips on getting that up and running on different platforms in their documentation.

In 2.0, Twitter has defined two new variables in the patterns.css file, @navBarBgStart and @navBarBgEnd.  These, quite naturally, define what the top and bottom colors are for the nav bar gradient.  Though you can set these to whatever you'd like, if you want to keep things simple I recommend using dark colors, so that the default light text colors work without modifications.

Ok, so let's try this out with a nice royal purple:

@navBarBgStart: #3D368B;
@navBarBgEnd: #232051;

Once we recompile the CSS file using Less, we get something majestic indeed:

Well that was easy right?  Not so fast, it turns out if we want to have drop-down menus, there's more to it.  Let's check out what that drop down looks like:

Shoot, well that isn't right.  It turns out Bootstrap 2.0 doesn't make changing those colors any easier, so that's something we have to dig a bit deeper to change.

We'll need to change both the background color for the dropdown, and the gradient used to draw the selection highlight.

The first can be set by changing the background-color in the .dropdown-menu style, somewhere abouts line 180 in patterns.css.  By default this is set to #333.  I recommend setting this to a value somewhere between the two gradient values you set for your top bar:

.dropdown-menu {
     background-color: #2F2A6C; // defaults to #333

The second change we have to make is how the active item is highlighted.  This is another gradient, and is under the styling for li a, somewhere around line 192 in patterns.css:

li a {
      color: #999;
      text-shadow: 0 1px 0 rgba(0,0,0,.5);
      &:hover {
        #gradient > .vertical(@navBarBgEnd, #1B183E);
        color: @white;
      }
    }

One of the new exciting initiatives happening in Rwanda is Minister Mondays.  A few times a month, the Minister of Health, Dr Agnes Binagwaho goes on Twitter and answers questions from the general public.  She answers questions from a wide range of topics, this week's focusing on nutrition.  That kind of access to leadership and transparency is to be applauded and is something pretty unique, not just in Rwanda but in the world.

But one thing we thought could be better was that the primary form of interaction was via Twitter.  Though it is a great platform for reaching a digital audience, it does leave out quite a few participants in a country where the penetration of PCs (and Twitter) is still low. 

As we specialize in building SMS services, we decided to volunteer a bit of time to see if we could bridge that divide.  Last week we met with the Minister and discussed what could be done.  Happily we found that the Minister had the same goals as we did, trying to reach a wider audience, with a focus on transparency, on putting those questions and answers on the public record.

A few days later and we had put together Nyaruka Listen, a platform to make that kind of interaction as easy as possible.  Since we were on a tight schedule and wanted to make the service available across carriers, we decided to leverage our Android relayer to deliver messages to our service.  That let us quickly use a regular SIM card to relay messages from the MTN network and back.

The final service is simple.  Incoming messages to the Minister Monday phone number are ingested by Listen, the sender receiving an SMS confirming that it was well received.  Meanwhile, the Minister can see all incoming messages on a web dashboard and can instantly reply using a simple interface.  That reply is sent back to the original sender's phone and made public for the world to see.

It is a simple product, but one we think could have real potential for other organizations.  The penetration of mobile phones in Rwanda and other East African countries is high and only getting higher and SMS is a cheap and reliable technology that people use on a daily basis.

Using Listen, an organization can set up a hotline where their customers or beneficiaries can send in comments and concerns via SMS.  Each message is viewable by everyone in the organization and can be dealt with appropriately.  Forward looking organizations can even follow Dr Agnes's model and be transparent, publishing the responses for the public to see.

Of course this kind of system might seem like it would be expensive but it not need be.  We believe so strongly that this would be beneficial to other organizations that we're willing to provide Listen to any organization for a really compelling price.  You too could give your community a voice and the power of easily interacting with your organization via SMS.

If you are interested in exploring that further make sure to contact us to find out more.  But either way, we hope to see you interacting with the Minister during the next Minister Monday session in early January.

A few weeks ago, RURA, Rwanda's Utilities Regulatory Agency, announced the new procedures for acquiring short codes in the country.  Short codes are just that, short (four digit for our purposes) phone numbers which allow companies and organizations to build services which are more easily accessible to the general public.  Instead of having to dial a 10 digit number, a user can instead use a shorter four digit number.

Short codes also serve the purpose of allowing services to be deployed across carriers.  To build a reliable SMS service, such as the ones Nyaruka builds, you need to integrate with the carrier's SMSC.  Each carrier has it's own SMSC, and that's where SMS'es get routed on their network, or alternatively crosses to another network.  If you want to build an SMS service that works well on all networks, you need to integrate with each of these, and you need a shortcode to make it easy for the customer to access them all.

Old Procedures

In Rwanda thus far, acquiring short codes has been a pretty easy affair.  You just put in a request to RURA for a new shortcode, along with your intended use and a week or two later they reserve a new four digit number for you.  This worked but posed some problems, both for us as customers of RURA and for RURA themselves.  

For RURA, because short codes had no cost to them, there wasn't much incentive for companies to use them wisely, or even wait until they had a business plan to acquire them.  Worse yet, with no maintenance fee, short codes would often lay stagnant, unused, but still reserved and unavailable to use.  That's a real problem when there are only 10,000 short codes available.

For companies, RURA didn't have any procedures for us to pick our own short codes.  Instead, you would include seven or eight different short codes you'd be happy with in your request, but more often than not you were just assigned a random shortcode.  Not a great outcome if you are trying to build a consumer facing service.

New Procedures

The new procedures that RURA announced should go a long way towards solving both of these issues.  But before getting into that, I must first commend RURA for making both the presentation and the application form easily available on their site, this is great to see and shows a real willingness to operate openly.  Even more importantly, I was also really impressed with how they presented the new plan, inviting all the stakeholders to a meeting and allowing for lots of feedback and discussion.  Very well done.

The main change, as expected, are that short codes will no longer be free, but instead require a yearly maintenance fee.  This is a good change, as it now rightly discourages squatters from taking over short codes.  In addition, it now means that you will be able to request a specific short code and if free, receive it.

The new fee structure is 25,000 RWFs as an application fee, then either a $200 USD or $1,000 USD yearly maintenance fee for the short code, depending on what category it falls in.  $200 short codes are reserved for what RURA calls "Customer Information Services" and here I think they will run into trouble, as it is not immediately clear what falls under that category.

Although not in the slides, further discussion with RURA at the meeting leads us to believe that RURA is reserving the $200 fee for short codes which are less desirable and used for non-profit purposes.  But again, this is a hard thing to define, there is no bright line rule that works well, especially as more and more SMS services are trying to support their programs by deploying premium or normal rated SMS services.

Our Comments

Although we are fine with the plan as presented, I think a better option would have been to just define different classes of short codes based on their desirability, and charge differently based on those, regardless of purpose.  For example, RURA could have said any short code with only one digit, say: "1111" would be $2,000 a year, those with two pairs or consecutive digits, say: "1234" or "2020" would be $1,000 a year.  Those with two different digits, say "1112" would be $500, and all others would be $200.  

That kind of fee structure would allow small businesses to still acquire short codes at reasonable prices when first starting up, and later graduate to a nicer shortcode.  It also removes the very subjective measure of what is a "Customer Information Service" and instead makes the pricing completely transparent, which is always a good thing.

But even if it isn't quite perfect in our view, the new procedure is much better than before, and having a yearly maintenance fee should go a long way towards freeing up desirable short codes which aren't in active use.

Online Registration

One of the things that was both good and disheartening to hear was that RURA was also planning to launch an online registration system for short codes.  This is great news, as it is one thing that really doesn't work well currently.  In order to be able to pick a short code, you really want an up to date website which lists all the short codes already taken, letting you weigh the pros and cons of those still available.  So having an online database and registration form is a huge step towards making the process both streamlined and more useful for customers.

The disappointment comes in that Nyaruka built such a system specifically for RURA and presented it to them back in May of this year.  We had experienced a lot of the pains in the old paper procedure for short code registration, so we decided to build something better.  Emile spent about a month thinking through the problem and building the site, and we presented it to RURA, offering it for free save for any further customizations and a small hosting fee.

RURA seems to have decided to go their own way on this, as is certainly their right, but it is a bit disheartening to see.  We haven't seen the system that RURA itself will deploy, but I hope it does a better job than ours, and I hope it launches before the November 30th deadline for applications for existing shortcodes.  

Speaking of which, here's the demo video we put together for that system.  Built, designed, and coded in Rwanda by a Rwandan.  Even if it never gets used, I'm proud of the work Emile did in thinking through the problem and implementing it.

We recently decided to hire an intern at Nyaruka.  We thought it might be a nice way to give back to the community, to help a student along for a few months, give them a taste of working at a software company.  The internship periods were starting soon, so we quickly put together an application form and started advertising for applicants.

The response was excellent.  In less than a week, we got over 50 applicants from various universities.  Our application was mostly focused on coding questions, very simple things like writing a function to return whether a number is odd or even and simple string manipulations.  We are strong believers that coding ability comes first, far before degrees or certificates, so our focus was there.

The applications we got back were varied.  Some obviously cheated on their answers, clearly copy/pasting from somewhere on the internet despite our warnings not to use external references.  Others gave it their best shot, honestly trying but getting few answers correct.  But about eight applicants looked promising, and from those we picked the four which we thought did the best and asked them to come in for a follow up interview.

And here we learned just how badly the Rwandan universities are failing them.

Our interview question for the applicants was a simple one: given a string such as "AABAB", return the string with all consecutive duplicate letters removed, ergo: "ABAB".  This is the type of problem one might be given as a first assignment in Computer Science, something that uses only the most basic fundamentals and constructs.  But our applicants struggled with it, far more than is reasonable.

Now keep in mind that although this is an internship, all these students were three, four, or even five years into their Computer Science programs.  By now they should have a reasonable grasp of programming, debugging etc..  If asked they will tell you their curriculum includes the same titles that any Western CS program might have, Operating Systems, Algorithms etc.. but despite their impressive names, it is clear the universities aren't teaching their students much at all.

This angers me.

It makes me mad at the professors teaching courses they aren't qualified to teach and mad at the universities charging students in both time and money and yet not fulfilling their promise.

The problem stems to their methods in teaching Computer Science.  Universities here are still teaching their students using pen and paper, teaching from books instead of computer screens, teaching by lecturing instead of by doing.  That simply does not work for this field, you cannot learn how to program by reading a book.

Computer Science isn't unique in this respect, but sometimes this is hard for people who aren't coders to understand, so an analogy might help.

Imagine you take a course to learn how to swim.  Not just a short course, but a dedicated university program on swimming.  Over the course of years, you attend classes where you learn the names and characteristics of various bodies of water you can swim in.  You listen to lectures about buoyancy, take exams on rip tides, diagram the various swimming strokes.  Your professors, while unable to swim themselves, assure you that they have also completed this certification and have read many books on the subject.  So after years of study, years of applying yourself according to the plans of the university and hours upon hours in the classroom, you graduate with your certificate.

To celebrate, you go to the beach, where you quickly drown.  Because, in truth, despite your years of studying, you have no idea how to swim.  You've never been in the water.

This is the state of Computer Science in Rwanda (and really the region in general).  Despite impressive graduation numbers, despite the glowing press, despite the undisputed progress, there is a shocking failure to actually teach any of the required skills to be a programmer.

This must stop.  This must change if Rwanda is at all serious about trying to build an IT sector.

The universities must take a hard look at their professors and their curriculums and redesign them to be more effective.  There isn't a huge pool of qualified professors to draw upon, but that doesn't make it hopeless.  Both MIT and Stanford, provide many of their class materials online.  Not only the lecture notes and assignment, but videos of the lectures themselves.  Why not build courses around these?  I would guess that small groups of students assigned to work through these courses together would learn far more than they are now.

To give you an idea, this single MIT course: Introduction to Computer Science and Programming, would provide an understanding of CS fundamentals that far exceeds what is taught in the four year programs at the Rwandan universities.  A single course!  Why can't KIST professors help students through such a course, playing the video lectures, working through the assignments with the students?  Why isn't this a model that is adopted?

My advice to anybody in Rwanda who wants to learn Computer Science is this: Don't attend University.

Instead, invest the money in a laptop and a modem.  Download and start working your way through the MIT course, find friends to do it with, help each other along.  Do the assignments, write the code.  It will be hard at times, you will struggle, but it is the only way to learn.  When you do complete that course, which should take less than a year, you will have skills that far exceed any of your colleagues who attended University.  And with those skills you'll be able to find work doing real programming.  As a matter of fact, come to us and show us you did the work, and we'll help you along, certificate or not.

To the Rwandan Government, I plead with you to get serious and start talking to people already here on how you can do better.  Some programs already exist which are successfully training students, PIH's Medical Informatics Course being the prime example.  But their scale is far too small, their focus too specific.  Start finding ways of starting similar programs or scaling the successful ones up.   Look at things like Nairobi's iHub as inspiration on how to build the space and community which can help foster an IT community.  What if Kigali had an iHub where students could come and work through the MIT course together?  Imagine the possibilities if you encouraged a community of students and professionals alike to collaborate in learning?

None of this is expensive, none of this is hard, but the current institutions are failing their students, and in turn, their country in accomplishing Rwanda's goal of building an IT sector.  The first step is admitting that what is being done is not working, that the current graduates are not qualified, that the education system is failing them.

Once we can admit that, then we can all work together to do a better job.  

We're here because we believe in that dream and because we want to help, so are many others.  Let's work together to make it happen.

We're still playing with 2D barcodes and testing out how well they work with various Android devices.  One question that came up from our last test was how well they dealt with errors in the barcode, that is dirt, rips or parts missing entirely in the way.

The answer is pretty darn well.  Here's a barcode that still runs despite me scribbling all over it:

But there are vulnerabilities.  Specifically on QR codes, they are very sensitive to having one of the position detection patterns destroyed.  This QR code, while in much better shape than the one above, refused to read, just because the top left block was filled in.

Note of course that all these results are in the context of using the Barcode Scanner application on an Android phone.  There are almost certainly weaknesses in the scanning algorithm, but that's the state of the art for Java based QR Code reading, so it is what is relevant for us.

Also, we tried the same tests with DM codes with similar results.  Newer DM codes support the very same Reed Solomon error correction algorithm, and just like QR codes allow for up to 30% of the data being corrupted before failing entirely.  Again though, if you start messing with the position markers for DM codes, which are the left and right edges, you run into trouble more quickly.

We're a huge fan of the Huawie Ideos phones.  They are ridiculously cheap, $100 unlocked, and can be bought over the counter at Safaricom in Kenya or about $120 from NewEgg in the states.  That is a crazy pricepoint, totally blowing away any other Android phone and really making J2ME handsets mostly irrelevant as contenders for the kind of ICT4D projects Nyaruka undertakes.

Recently we've been working with a client and have been considering using these as a way of managing and tracking inventory.  After all, the cheapest barcode scanners are around the same price, and you don't get a built in touch screen, GSM connectivity, GPS and the ability to build the entire application on the device.  That makes the Ideos mighty tempting indeed.

One thing we were curious about though is just how well they would perform with high resolution 2D barcodes.  In our case, we'd like to have the option to encode quite a bit of data in the barcodes, so we were curious how the inexpensive Ideos optics would fare.

Methodology

We created and printed 2D bar codes encoding 23, 50, 100, 200, 500 and 1000 characters, then tested them at different sizes.  The codes were all generated at Invx.com, which seemed to do a decent job, even for our monster 1000 character barcode.

We printed each using a laser printer and scaled them from roughly 4"s to 2"s and finally 1" squared.  This was under normal lighting conditions using the most excellent "Barcode Scanner" app in the Android App store which uses the open source ZXing library.  We also tried things out with a Nexus S, and a Sidekick 4G.

Camera Specs

The big knock to the Ideos is that it is a fixed focus camera, despite being 3.15 megapixels.  What that means in this application is that you always need to hold the Ideos at a fixed distance from the code in order to get a sharp picture, which means that you start running into the limitations of the sensor resolution for the higher data QR codes.

The Sidekick4G and Nexus on the other hand, have autofocus cameras, which help greatly.  The Sidekick also has a 3 megapixel camera, but it is able to focus so fares much better.  The Nexus S has a 5 megapixel camera with auto-focus, so should be the best yet.

Scoring

For each phone and barcode, we ran a series of tests and ranked the performance as Fail, Poor, Good or Excellent.  Fail means that we either couldn't get the phone to read the barcode at all, or it was very, very difficult.  Ok means that it took a good bit of searching to read the barcode, but it did so consistently.  Good meant the barcode was easily read when well aligned and Excellent meant the barcode was instantly read even when misaligned or at an oblique angle.  Excellent readings have that magical quality to them where you just wave the phone in the general direction of the code and it picks it up.

Results

So what did we find?

Not surprisingly, auto focus made a huge difference.  Since the Ideos has a set focus point, you essentially always have to hold it roughly the same distance from the code.  That is reasonably easy to do and you get a feel for it, but it means that if the QR code is small, then the sensor won't be able to make out the details.  Here's a quick example that makes it clear:

That's the Ideos quite easily reading the 100 character 2" barcode and struggling on the 1" version.  You can see that the 2" code takes up a greater size so reads easily, but the smaller 1" code doesn't.  We can't move closer to the 1" code to make it fill the screen as then it becomes out of focus.

One interesting learning there is that you can work around that resolution if you have the freedom to make larger QR codes.  The 'optimum' size for a code for an Ideos is probably around 3"'s square, that would fill the frame at the exact distance where it is focused.  We didn't try this out, but I bet you could get a 200 character code reading excellently.

The benefit of the autofocus is obvious when you compare the Ideos results to the Sidekick, which has a similar resolution, though much better optics and autofocus.  The Sidekick has no problem reading even 500 character barcodes at 1".

For all practical purposes the Nexus doesn't do any better, which probably indicates that we are reaching the limits of the optics rather than the limits of the sensor sizes.

Practical Limits

So what are the practical limits?  On an Ideos, I would stick to ~100 characters or less on a 2" bar code, and ~50 characters or less on a 1" barcode.  At those sizes things work brilliantly, instant recognition at virtually any angle.

On an autofocusing device, you have a lot more flexibility.  Even at 1" you can easily decode codes with up to 500 characters.  For QR codes that seems to be the practical limit, though if you are willing to use a DataMatrix code you might be able to squeeze a bit more in.

QR Codes vs DataMatrix Codes

The two biggest 2D barcode standards for this kind of application are QR Codes and DataMatrix codes.  DataMatrix is actually the older standard, but due to leaving out support for Kanji characters, QR Codes were created in Japan and have been taking over.

There are some advantages and disadvantages to each.  QR Codes are more tolerant to being read at oblique or rotated angles.  The guide blocks in the corners seem to help tremendously here and I definitely noticed faster and more consistent reading for QR codes.

However, those blocks come at the cost of data density.  Here are the two 1000 character codes used in these tests, the QR code at left and the DM code at right.  You can see that the DM code requires less resolution to read, so by and large the DM codes tended to fail last, at least when good alignment was used.

Error Correction

One interesting feature of QR codes is that they are a bit more tolerant to errors.  You can cover up the bottom right corner of a QR code and it will usually still read, the DM codes are more sensitive here.  This might be an overstated benefit though, as I didn't have as much luck covering up the top right, left, or bottom left corners of QR codes, where the guide blocks are, so the practical cases where the error correction would come in seem minimal.

Error correction is something you can tune in QR codes, some generators lets you define more redundancy in the generated code.  However, this will presumably come with lower data density, so is probably very specific to your application.

Troublesome QR Code

Strangely, the lowest resolution QR code generated, of 23 characters, actually was troublesome to read in many cases.  Looking at it closely it looks like it contains one less control block than the 50 character code.  You can see that below, the 23 character on the left vs the 50 character on the right.  

This might just be a limitation or bug in the scanning software itself, but does point out that real world testing is still really important.  The DM code didn't display any such issues.

Full Results

Finally, here's the full results if you want to see the nitty gritty details:

But one thing that is the same, is the constant ask for access to
capital by various companies. A few presentations over the past few
days have had asks for six figures in funding, which gives me serious
pause. It seems like there is a belief that funding is the goal as
opposed to a necessary evil. The truth is just the opposite, as
software engineers, we have the unique advantage that we can build
systems to earn us money without doing physical work. Add to that
that all we really need is an internet connection, some ramen noodles
and an ample supply of coffee and the funding asks really make me
scratch my head.

One interesting exercise is to look at YCombinator as a comparison.
YCombinator is arguably the leading seed funder in the Silicon Valley
today. Companies compete in a similar way as we have here at Pivot25
to be one of the companies to be taken under their wing. And you know
how much they give? $20,000. And this is only the most promising,
most experienced, most qualified companies in the world. Their
graduates include the likes of DropBox and Loopt among countless other
visionaries.

So my advice to some of the less experienced teams. Forget about the
funding and go build your idea, after work if you need to, using a
loan from your friends and family if necessary. If you don't believe
in your idea enough to suffer through eating ramen, or to sell your
family on it, then maybe you don't believe in your idea as much as you
say you do.

My point is the only expensive thing about starting a software startup
is paying engineers, and if you are one, then you should be able to do
it without raising money, and you'll be all the better for it.

Quite a few people, myself included, believe that Android is going to become absolutely huge in Africa.  Here in Rwanda, smartphones are becoming more and more prevalent for the upper tier consumers.  Though the Blackberry is the only smart phone sold by local carriers, it is not uncommon to see unlocked iPhones as well, no less a status symbol here as the rest of the world.

Of course the beauty of Android is that at any moment one of the carriers here could start selling them, unlike the iPhone, Android is open for anybody to sell on any network.  As a matter of fact, I have it on good authority that the biggest carrier here, MTN, will start carrying some Android handsets soon.  And as the price continues to drop, I'm sure they will become just as popular here as they have become in the West.

That is if it wasn't for one giant gotcha: Android's terrible support for the Sim Toolkit.

Now if you live in the States, you might not even know what the STK is, so a bit of explaining is in order.  Put simply, the STK allows carriers to load a simple set of menus and 'applications' on your SIM card.  Again, on your fancy iPhone, you may question the need or purpose for such a thing, but that's because you are still years behind and using a credit card.  Here, where credit cards are virtually unknown, the present and future of payments is Mobile Money, which is almost always delivered via.. you guessed it, the STK.

See, the STK works on virtually any device, from a $5 Alcatel to a $200 Nokia, these phones all implement the GSM standard and therefore allow anybody, both rich and poor to access services like Mobile Money.

Except if you have an Android handset.

Earlier versions of Android, up to 1.6, actually included a rather rough, but functional Sim Toolkit application, but at some point it was dropped, and even Google's own latest and greatest ROM's for its Nexus One and Nexus S handsets lack it.  As a matter of fact, I don't know of any devices running Android 2.3 that include it.

Thankfully, CyanogenMod has been forward porting the Sim Toolkit for a while now, and sure enough, Cyanogen 7.0 still has it.  But it is a buggy and unpleasant experience.  I tried to activate MTN Mobile Money today using my Nexus One, and half way through the process just gave up and used my $5 backup phone instead.  I can access most menus using Cyanogen, but only by force quitting the Sim Toolkit after every request.

I'm not the only one commenting on this, the web is full of people screaming that their fancy new $500 smartphone is too snobby, too highfaluting, to play with the rest of the world.

So here's a clue Google:

If you want Android to be relevant anywhere apart from the West, then start thinking about how we live day to day.  Build a browser that does wire compression before sending it down (oh hai Opera!), give us finer control over when background data is used, give us USSD API support, and for god sake's, implement a 20 year old standard so we can use the services that make our lives more convenient than yours.

A few days ago, MobileActive posted the results to some interesting work they did in Egypt, trying to quantify SMS latencies and whether they might indicate that filtering is taking place.  Essentially they wrote an Android application that allowed them to easily measure the SMS latencies between networks.  That application sent a variety of messages, some with 'safe' content and others with 'political' content.  The idea being to help quickly identity if networks are filtering or blocking messages based on their content.

While I applaud the effort, and I think it is an interesting project, I feel like there are some flaws in the methodology, significant enough flaws that MobileActive should have resisted even hinting at any conclusions before fixing them.

We do a lot of work with SMS here in Rwanda, we live and breath the stuff really, so we are pretty familiar with just how mysterious latencies can be.  We've done work in Ethiopia with Android phones and seen instant deliveries right after massive delays, all with just boring old numerical messages.  And we've done a lot of work here in Rwanda talking straight to the carrier's SMSC and seen similar things.  To put it simply, even under the best circumstances, making rhyme or reason to delivery failures, much less latency is a really hard task.

And that puts an enormous burden of proof to any experiment which claims to try to corrolate messages latencies to message content, and here I feel MobileActive should have known better and resisted any, even tentative and disclaimed, reporting of possible filtering.

It is hard to know exactly what the data showed, since the data isn't publicly available, but we do know that the study involved roughly 270 messages across a variety of networks.  One of the hypothesis they give is that Etisalat may be filtering messages based on the content of the message.  From the graphs provided it seems we can guess this is based on roughly 70 results, which seems to fit in with their totals.  Here's their graph of those results:

Now it is certainly tempting to look at this and start making hypothesis that political messages are being filtered, but we have to keep in mind our previous caveats about the reliability of SMS deliveries.  Specifically, especially when measuring something as unpredictable as SMS, we need to start with a valid hypothesis and then work out an experiment that makes sense.  Again, we don't know enough about MobileActive's methodology here to draw any conclusions, but here's some things I'd do:

1) Network latency is often cyclical, the network sometimes just acts up for a bit.  So when testing various messages it is important to both randomize the order that the messages are sent, and do multiple passes of the test at various times of the day.  If we skimp on either of these we may just be seing the artifacts of a network under load.

2) Are delays consistent across the same message?  From what I can tell this is the biggest flaw in the tests as a whole.  If every time I send a message saying "revolt now" it takes 20 seconds to deliver, then perhaps we have a case.  But if it is inconsistent, then we really need to start looking at what else can explain that latency.

3) If the hypothesis is that filtering is taking place, what do we think is the mechanism?  Clearly, any filtering that is automated would be completely lost in the noise of normal SMS delivery times.  Even the most sophisticated algorithm would take mere milliseconds to evaluate whether 160 characters should pass or not, you wouldn't be able to detect it via measuring the latency.  If the hypothesis is that some kind of manual filtering is taking place, such that actual humans are looking at the messages, then we should design our experiment to capture that.  For example, perhaps we can try to overload these mechanical turks by sending a large number of political messages in a short time period.  If the delays increase even further, then that's probably an indication that there is some human intervention taking place.  I find it very, very, hard to believe that any carrier has such a system in place that would still result in sub-minute deliveries, but if that is indeed our hypothesis, we could create an experiment to test it.

Perhaps my biggest complaint here is the lack of openness.  In our fast paced age of Twitter and Facebook and flashy headlines, we need to resist the temptation for sensationalism and be rigorous in our methodologies, especially on topics this important.  Not publishing the raw data that these results were based on just isn't acceptable, and if the excuse is one of not enough time, then the original article should have waited until that part was ready.  And just as you should always be skeptical of any benchmark which you can't run yourself, you should also be skeptical of any test using software you can't examine.  Again, lack of time is not an excuse, if you don't have time to make the process transparent, then you should just delay publishing your results.

MobileActive and others all do important work, but we must remember to maintain our standards, our scientific training, whenever sharing important information such as this.  It is all too easy to be drawn to the headline, to be taken over by the excitement of your results, and most importantly, all too easy to see patterns where none really exist.  We have all fallen victim to this, but it is our job as a community to call each other on it, to remind each other to be rigorous in our conclusions, to be peer reviewed and to never forget about that little thing called statistical significance.

I hope MobileActive stays true to their word and releases their Android client.  No need to clean it up guys, we won't judge you!  Let's all work together to get to the bottom of this most intriguing mystery.  We have lots of experience building Android apps and would be happy to lend a hand, as well as give our results on the Rwandan carriers.

There are lots of different theories on the right way of branching on Github. One very neat one is flow, but perhaps you haven’t invested in using that for your particular project. In any case, there may just come a time when you decide after the fact that you should have created a remote branch.  Here’s how to do it easily in a few steps.

Step 1) Find the last commit you want included.

This one’s easy, just go to your project, check out your commits and decide where things started going awry. You want the hash for that commit (not tree not parent), as that’s where you are going to branch. It should look something like:

ff96b9182a2648bfb65f

Step 2) Create your new branch.

I assume you already have your repo checked out from Github, yes?  Ok, great, then just go create your new branch.

git branch production ff96b9182a2648bfb65f

Step 3) Add it to Github

Almost there.  Now we just need to push it to Github so others can use it.

% git push origin production

That’s it.  You can checkout, merge and do everything else as you would with any Git branch, and others can track your branch straight from Git.

Ahh, git so powerful, yet so obtuse.