Bitcoin and the Android flaw

The Problem

Basically the Java random generator on earlier versions of Android didn’t really generate a random number.  This causes a problem for Bitcoin apps that generate addresses on the device itself because private keys can be compromised.  Once a hacker has a hold of someone’s private key, they can easily determine the address.  With that information all they have to do is send the Bitcoins to another address.  That’s it.

What should users do?

Upgrade to the latest version of Android ASAP.  Just to be safe, you may want to consider transferring all your Bitcoins to another address that is not generated on an Android device.  Online and offline wallets exist to facilitate this.  Some examples include, Armoury, Blockchain, etc.

What should developers do?

I’ve never been a fan of placing business logic within a mobile application.  Instead, I would create a server side application (possibly in the cloud), to generate the address and send it back to the mobile application.

What is the impact?

The impact seems to be minimal.  It appears that some Bitcoins were stolen but not a whole lot.

Final Thoughts

My hope is that people are not discouraged by Bitcoins because of this unfortunate incident.  Keep in mind, this was a flaw in the Android OS (that affects other types of applications), not the Bitcoin movement.

Advertisements

Breaking the Build

So your CI server is in place.  Developers are checking in their code on a daily basis.  And then an email notification goes out to everybody, FAILED BUILD.

What do I do?

Fix the build right away.  Unless of course there is a production issue.  The sooner you fix the build the less time it will take.

What don’t I do?

Don’t comment out the test.  For Java developers that means you should refrain from adding the @Ignore annotation to the test and checking it in.  The test failed for a reason. Either the test itself needs to be updated or there is a real problem with the application code.  In either case, it should addressed right away.

How do I prevent this from happening?

Use information radiators.  Have a whiteboard set up with everybody’s name.  When somebody breaks the build, add a tick next to their name.  At the end of the week, whoever has the most ticks is responsible for bringing in donuts the following week.  In the event of a tie, the more senior developer is responsible (just because they should know better).  You can use your own variation of this but you get the idea.  This is a great way of encouraging people to run their tests before they check-in code.  Also, penalizing people in a fun way has two main benefits.  First it gets the point across, and second it’s done in a non-confrontational way.

Perform root cause analysis.  Keep asking why until you figure out what the real problem is.

Why did the tests fail?  Because I didn’t run them locally.

Why didn’t you run them locally?  Because the tests take too long to run.

Why do the tests take too long to run?  Because the system tests perform end to end testing.

Ah ha!!!

Maybe we should have a lightweight build that only runs unit tests and a separate heavyweight build that runs all tests on a nightly basis.

Final Thoughts

You should only put in measures to track broken builds if it becomes a common theme. Remember, you want to make this a rare occurrence.  Once you get to that point you no longer need to track it.  So don’t encourage it.

Mobile – Getting started with the right tools

Note:  This article does not relate to Windows Mobile apps.

The Basics:

If you’re developing for iOS you’ve probably already downloaded Xcode and you’ve familiarized yourself with Objective C.

If you’re developing for Android you’ll need to learn Java.  But when it comes to IDEs, your choice comes down to Eclipse or Android Studio.  Android Studio was developed by JetBrains and since I’m an IntelliJ fan I decided to go with this one.

The Tools:

Choosing the right tools is critical to any project.  Some people are so anxious to start coding that they don’t even bother to implement proper CI/Revision Control or they claim that they’ll add it later on when they have time.  Trying to implement this later on is much more difficult.  Most people just end up abandoning the idea once frustration sets in.  Setting up the right tools at the beginning will make your life a whole lot easier.

  • Source Code Repository

My advice is to go with Git.  If you already have an internal Git repository you’re off to a good start.  If not, no need to worry.  There are plenty of free online tools.  If you have an open source project, just create a repository on GitHub.  However, if you’re looking for an online private repository you can use Bitbucket, which is also free but you can pay extra for additional services.

  • Continuous Integration

When it comes to mobile, CI is a bit of a different beast.  For example, to run CI against an iOS application requires that you have dedicated Apple hardware to run the build.  Thankfully, there is an alternative.  Online services exist that provide CI for mobile applications.  cisimple is one such tool that is easy to get up and running quite quickly.  Basically, you can connect to your Git repository via HTTPS or SSH and run a build.  The free version gives you just that.  For an extra fee you include services that will run your unit tests and provide an online simulator to run/test your application.

Final Thoughts:

The race to get your app to the App Store or Google Play and eventually in the hands of potential users can definitely work as a competitive advantage.  However, you don’t want to release an application that has not been properly tested.  Users are not that forgiving when it comes to bug infested applications.  They’ll just move on to the next best thing.  You’re much better off taking the time to put these tools in place and release a product that is high in quality even if it doesn’t have all the functionality.

Update:

CISimple has ceased operations.  However there are other such tools available:

Travis

CircleCi

bulldozer

hostedci

appurify