Design or Develop

A while ago I was explaining the architecture of a solution I have developed when he made a remark about how my solution was based on the integration of off the shelf Solutions (OTS) rather than a custom development and he added how a custom development would have been more impressive and efficient not to mention superior in every way. Being a solution architect that’s a question I have to answer at the beginning of almost every project I am responsible for and the answer is almost always customize and integrate, in this post I’m going to explain the logic behind such as decision.

  1. Someone has done it better: you might have access to the best developers but unless you are developing something within the core technology of your company you don’t have the accumulated experience someone else has especially if that solution is within their core technology area. When you limit yourself to in house developed solution you also limit yourself to the skills you’ve got within the confines of your company.
  2. Is it really custom development: unless you are writing machine language or using your own compiler you are actually customising the only difference is the building block size. Developers use libraries and packages that someone with more experience has built and most use it as a black box without fully understanding it’s inner workings and they really shouldn’t.
  3. Cost: in theory you can build everything if you have no cost and time constraints however unless it’s a toy or personal project cost and time constraints are of key importance. The more customization requires the more costly in terms of time and money a project becomes. Licenses cost money but almost always they are cheaper than the investment needed to build the same functions in house. There is also a hidden costs associated with the involved risks and the bugs that we’ll be discovered during QA and initial customer experience.
  4. Accumulated experience: vendors building OTS solution amount the combined experience of their customers which means they’ve covered more use cases and edge cases than the your in house development team ever will this experience is merged into the patches and product updates.
  5. Compliance: it’s a lot easier to comply with certification criteria when using larger building blocks (OTS) as the certification bodies are familiar with the OTS solutions and the vendors are usually precertified. Trying to certify an in houe developed solution can be both expensive and time consuming.
  6. Integration best practices: this point is a bit tricky to explain when in house solution is used the developers use integration short cuts to save time that are often far from the industry best practices, using OTS solutions enforces a certain level of best practices conformity this is valuable as a at a later stage components can be swapped out at a minimum impact.
  7. Operability & Extensibility: Even if you have the ultimate bespoke solutions built specifically for you, finding people to operate it or build on top if it in the future might prove to be problematic especially if the original team who built it moved on.

So these are the reasons why you should almost always go for customization of OTS rather than in house solutions and using larger building blocks with micro services, how about the situations where you should in fact build your own solution and going for the smallest building block possible (language default libraries)? Thats my next post.

Automating the Nespresso Coffee Machine part 1

I like drinking coffee first thing in the morning, however preparing coffee in the early morning is not something I’m a big fan of, so I decided to use my particle photon to automate the coffee making process. Thus turning my normal Nespresso machine to an IoT enabled machine.

The steps for this build are quite simple, it requires the following components :

  • Particle Photon
  • Servo
  • Power Bank
  • Paper Clip
  • Rubber Band
  • Velcro Tape

To build it connect the Servo to the photon, noting that the data pin must be connected to one of the PWM enabled pins, in my build I used Pin D0.

Use the paper clip to twist and attach on the servo keeping it in place using the rubber band, this serves as the push rod that’ll press on the coffee maker’s button.


Attach the servo to the Nespresso machine using velcro and tape, you’ll need to adjust the servo angles on the code to work with your machine and how the servo is attached to its body.

Connect it to IFTTT service and enjoy your coffee, Personally I then created a DO button on my phone to press the first thing in the morning.

Continue reading

Downloading Torrents Remotely

I’ve set up a home server and wanting a simple straight forward way to download torrents remotely I relied on an old hack I’ve heard about but never attempted. You can configure transmission the torrents client to pick up torrents files from a certain directory, sharing this directory on google drive means that you can drop torrent files for transmission to download for you at home.

Screen Shot 2016-03-15 at 4.21.56 PM.png

The problem is you can’t really monitor the progress of the torrents and some of these torrent files may not even start. So I decided to write a small shell script that monitors two events and updates me through push bullet, the first event being the torrent download start (creation of a *.part file) the second event is the completion of the download (new file in the downloads directory).

The script works as follows:

Screen Shot 2016-03-15 at 4.15.30 PM.png


for i in $(find $partsLocation -name "*.part" -maxdepth 1|sed -e "s/ /_/g");
echo "Handling File"
echo $i;
echo "----------------------"

#apply check here if file exists
countOfParts=$(cat parts.log|grep $i|wc -l)
echo $countOfParts
if [ $countOfParts -gt 0 ]
echo "already listed"
echo "new file, adding to parts.log"
echo $i >> parts.log
curl -u $pushBulletAPI: -d type=note -d title="Tor Started" -d body="Download started for file $i"

#scan for complete files

for i in $(find $completeLocation ! -name '*.part' ! -name '*.log' ! -name "*.sh*" ! -name "." -maxdepth 1|sed -e "s/ /_/g");
echo "Handling File"
echo $i;
echo "----------------------"
#apply check here if file exists
countOfComplete=$(cat complete.log|grep $i|wc -l)
echo $countOfComplete
if [ $countOfComplete -gt 0 ]
echo "already listed"
echo "new file, adding to complete.log"
echo $i >> complete.log

curl -u $pushBulletAPI: -d type=note -d title="Tor Completed" -d body="Download Completed for file $i"

Deploying A Mobile APP in an Enterprise Environment

The use of mobile application on consumer grade devices is increasing in popularity as more and more companies are using customised apps on mobile devices for field purposes instead of using a purpose built device. Example of such an implementation can range from Biometrics Scanning, Merchandise Delivery or even Taxi Dispatching.


Certain risks are associated with this approach since unlike web applications each user is responsible for managing and updating his version, just like the pre web-apps days back when people used desktop applications, These risks include:

  1. Using an obsolete version of the app that is no longer compatible with the backend.
  2. Using a version of the app that include a critical security issue.
  3. Incorrect business process due to the use of an older version of the app.
  4. Using a none official version of the app using the same backend, thus bypassing any front end validations.

There are certain guidelines that can be followed to control the inherent risk, I’m going to list some of them here as a guideline

I. Upgrade Enforcement 

For critical upgrades that renders the previous versions obsolete, for instance changing the business process or introducing a critical security enhancement. The best practice is to break the backends backward compatibility.

Breaking the backend backward compatibility can be done by adding an app version check with every request, including the app version in every request is easy and has a negligible cost on both data and processing yet is very useful when needed. The server response should include an error code that would trigger a “You Must Upgrade Now” message.

II. Upgrade Notification

For less critical updates push notifications can be used to suggest an upgrade to the customer, a more aggressive approach  (for android) would be to handle the push to fire the play store on the application’s URI. The frequency of these notifications can reflect how important this update is.

III. Application Verification

To restrict against none official apps the api should include a verification token, there are many ways to implement this, one of the easiest way would be encrypting one of the fields (timestamp for instance) and sending both the encrypted as well as the none encrypted versions. The backend would then verify the version of the app by comparing the decrypted field against the plain text one, if they do not match the response should indicate that.

There are many ways to implement this, the encrypted field approach happens to be the easiest way to do it.

IV. Root Check/Emulator Check

Rooted phones can offer a malicious user the means to manipulate the backend calls, while keeping the verification field. A root check can be conducted on the device every time an activity is started. Emulators are easy to uncover as well.

V. Malicious Usage checks

Just in case all of your checks fail, backend should conduct even a rudimentary malicious behaviour check, blocking devices that exhibit none expected behaviour.

VI. Connectivity Issues

Even with the advances in cellular service coverage 3G/4G service remains spotty especially in rural areas. There are few ways to mitigate this depending on the nature of the requirements. If no online/sync operations are required you can implement a simple request cashing service, in which server side requests are cashed to be retried when connectivity is available.

VII. Usage Patterns Analytics (for android)

Creating usage heat maps is important when it comes to determining how the people are actually using the applications and whether certain features should be augmented or removed due to lack of usage. Luckily google analytics can be integrated to track usage or activity launches, it can even be used to track individual controls actions.


I hope this post was helpful I’m planning to write another post soon on how to conduct unit, QA and scale tests on enterprise apps.

Particle Photon Powered Physical Notifications Device

Having just received my photon maker kit I wanted to build a simple project to show case the photon’s capabilities and so I decided to build a photon powered RGB lantern which I’d light up using IFTTT recipes.


The Internet Powered Lamp Lighting Up

The components :

  • Particle Photon
  • 3 x 8mm RGB LEDs (common anode)
  • 330ohm resistor
  • Prototyping board
  • Battery Pack
  • Ikea Paper Lantern


  • Connect the 3 RGB in parallel with the  the resistor connected to the common anode.
  • Red to A4
  • Green to A3
  • Red to A2
  • Common anode resistor to D0
  • Battery pack positive to photon Vin
  • Battery pack -Ve to photon GND


I didn’t want the lantern to light up all of a sudden instead I wanted it to gradually light up.

// -----------------------------------
// Controlling RGB LEDs over the Internet
// 23 October 2015
// -----------------------------------
int led_red = A5;
int led_blue = A4;
int led_green = A3;
int led_on = D0;

int led=D7;

int r_val=255;
int g_val=255;
int b_val=255;
int p_val=0;
int t_val=1;
bool is_on=false;
// Last time, we only needed to declare pins in the setup function.
// This time, we are also going to register our Spark function

void setup()
   // Pin configuration, 3 PINS, plus anode
   pinMode(led_on, OUTPUT);
   pinMode(led_red, OUTPUT);
   pinMode(led_blue, OUTPUT);
   pinMode(led_green, OUTPUT);

    //we declare a photon function to use through IFTTT
    //turn the LEDs off 


void loop()
   // Nothing to do here

/*This is the function IFTTT will be talking to, it accepts a string command

int ledToggle(String command) {
    /* Spark function to receive colour and duration RRRGGGBBBTTT example 000255255001 for RED turn on for 1 second, 
    values are reversed so 000 is the strongest illumination and 255 is off

    /*debug bit*/
    Serial.println("c : ");
    Serial.println("command recieved "+command);
    /*tokenize string and extract colors*/
    String red=command.substring(0,3);
    String green=command.substring(3,6);
    String blue=command.substring(6,9);
    String backoff_t=command.substring(9,12);
    /*debug bit*/

    /*cast string colors*/

/*cycle colours on*/
    /*keep lights on for the required duration*/
    //reset vars and turn off 

Function used to set lights
int set_lights()
    //colour cycle while lighting up
    //set colour
        // gradual power increase to common anode
        for(int i =0; i<=255; i++)

IFTTT integration:

Once the code was flashed on my photon, I was able to invoke the photon function over the internet, with the desired RGB colour value and duration sent as a parameter.

IFTTT Action

IFTTT Action, to light up purple for 20 seconds


**Update: I cleaned up the implementation by using a neopixel stick which greatly reduced the wiring and increased the functionality**

USSD API on Android

I’m currently trying to build a small widget that shows you several statistics about your cell phone usage, this would require using USSD codes and catching their responses. I scoured the internet for a solution however wasn’t able to reach one.

The only available solution which is mainly a hack relied on catching the logcat entry and displaying it, unfortunately this was fixed in subsequent versions of android and now USSD response doesn’t appear in the logcat.

There is even a Facebook page created just to request this feature from google…anyway if anybody manages to find a way to handle USSD responses please do share.



It is now possible to read the USSDs using the accessibility services, the downside is how indirect this method is and how the app should be manually enabled as an accessibility app in the device setting.

Sharing an Image from Bitmap in Android

I had a project that required downloading an image from the internet then calling the sharing intent to share that bitmap, I went through countless entries until I reached the conclusion that it is impossible to share an image directly from a bitmap object, the bitmap must be saved first and then you can share it and if you dont want to keep a copy on disk you have to explicitly delete it.

Here are how I ended up doing it.

1. Save BitMap

String file_path = Environment.getExternalStorageDirectory().getAbsolutePath() +
File dir = new File(file_path);
File file = new File(dir, name);
FileOutputStream fOut;
try {
fOut = new FileOutputStream(file);
abmp.compress(Bitmap.CompressFormat.PNG, 85, fOut);
} catch (Exception e) {

2. Share URI from file

Uri uri = Uri.fromFile(file);
Intent intent = new Intent();

intent.putExtra(android.content.Intent.EXTRA_SUBJECT, "");
intent.putExtra(android.content.Intent.EXTRA_TEXT, "");

intent.putExtra(Intent.EXTRA_STREAM, uri);
startActivity(Intent.createChooser(intent, "Share Cover Image"));


If you can come up with a hack to share directly from BitMap please do share, but I dont believe it is possible.