Cloud Memories Open IDEO Refugee Education Challenge Project

Remembering the positive aspects of home helps to comfort students as well as maintain their sense of their culture and self.

Cloud Memories is a web-based system that allows a counselor or teacher to easily create a shared memory book for students with snapshots of their home country, familiar audio, for example classic children's stories read by a native-language speaker, market sounds, songs. The memory book will also contain short-length videos and written narratives, like folk tales, in the students native language.

Read More

Distributing iOS Applications for Private Testing, The Magic of Ad Hoc

The design, build and testing process for an iOS application should be extensive and iterative.  Combining excellent human-interface design with well-functioning code are the visible hallmarks of the best iOS store applications. 
A large part of the behind-the-scenes magic for top iOS applications is the manner in which they are tested long before being submitted to iTunes for final approval.
Ad hoc distribution makes private testing readily available to stakeholders on their personal iOS devices.

Read More

Mobile Advertising Responsiveness High for Women

A very recent report released from mobile ad network AppCircle (operated by mobile analytics power-house Flurry) uncovered very useful information about the demographic segmentation of mobile ad campaigns. The report uses a sample of 60,000 "active, daily users on iOS." A recently as just a year ago analysts reporting on new app penetration and mobile web ads would have named men ages 18-24 the group most likely to be the most responsive and in turn earning the highest eCPM. The AppCircle report proves that this is no longer the case. Women using smartphones have clearly broken out of the pack and are now lengths ahead in terms of responsiveness and value of audience for mobile ad spends.

This trend is supported by well-established browsing habits of women in online formats. Informational searching, community engagement and elevated click with intent to purchase are all proven habits of browsing females ages 18-35 with above median household incomes. The apparent increase in mobile ad responsiveness may in fact not be a change in behavior for women users but actually an increase in mobile analytics capabilities as well as more ads featuring products and services that appeal to women. To date the mobile ad space has been dominated by ads that are targeting the 18-24 y.o. male demographic.

As agencies quickly pivot ad spends to take advantage of the responsiveness of women in the mobile medium one would expect to see a surge in display buys within mobile apps and web for brands that rely on groups of women with high conversion rates in traditional mediums. According to the report "25-34 year old females fetch the highest eCPMs at around $13, driven by high click-through and conversion rates. In fact, females are the more desirable target audience across most age breaks, tied with men in the 18 – 24 year old age range, and exceeding them at 25 and older."

Overcoming the Android OS Pattern Lock, a Practical Approach

The Android pattern lock feature found sudden fame when it recently became the focus of  a federal search warrant petition. FBI investigators referred to the pattern-locking mechanism  when they asked that the court require Google to provide either access to the suspect's account that the fail-over unlock code was maintained by or to "turn over a Samsung default code" or instructions to pass the pattern lock and gain access to the device.

The Android pattern lock is an incredibly user-friendly, and safe, method of locking an Android device's screen. During set-up of the pattern lock users connect a series of dots in the pattern of their choice and set the lock.  Other options for locking include the conventional entry of a pass code consisting of letters, numbers and special characters.

Several mobile phone forensics groups commented publicly that the Android pattern lock was a force to be reckoned with from a technical perspective.  Most experts cited the lock-out effect, meaning that the phone will stop allow attempts to enter the correct pattern after repeated failed attempts.  Once this stage is reached the remedy for the average user is to use their Google email account to reset the lock. The lock out effect also means that a brute force attack on the lock pattern will only repeat in a fast shut-out of future attempts to guess the pattern.

Overcoming the Android pattern lock does not have to mean a brute force attack or a resulting lock out. The most important part of the Android pattern lock workaround is the understanding that the pattern lock does not encrypt the device data, it simply protects access to the data. This places the emphasis on gaining access to the underlying system and file data and not cracking the lock. By using a forensics tool to root the device and engage the USB debugging mode, the reviewer is able to create a replica of the full file system, application data, logs, cached information, databases, and past geo-data.

Replacing the current pattern lock with a new, known pattern lock entirely is also easily achieved when the device is rooted. The critical dependencies for the pattern lock are the pc.key and gesture.key files in the data/system/ folders. Replacing the pattern sequence in that file with a new pattern sequence will allow for entry post reboot. Replacing the pattern sequence becomes easier if the reviewer copies a the sequence from a test device's pc.key or gesture.key file. It is important to note that injecting new files into an evidence phone file system is not best-practice but practical knowledge of what these files look like and where they are located can be helpful during an actual forensic device review.

For many types of reviews, the above workaround will provide the level of information necessary. However, rooting a device with any tool has inherit risks and some evidence-gathering procedures require that the system files, including rooting of the device, remain unchanged during the collection of evidence as was the case with the recent FBI search warrant. Barring these issues, the workaround presented here cuts to the chase and gains access to the information behind a pattern lock quickly and in most cases without complication.

Finally, a great tool for reviews and performing discovery is the Oxygen Forensics Suite. And remember, if your agency or prosecution team has a policy against the rooting of a device, ie. changing the phone settings in any way, be sure to turn off the auto-rooting function of your tools or use the tools manually instead of running the wizards.

An Easy, Homegrown, GitHub Issue Management System for Your Developer Outreach Efforts

Do you need to know what issues devs are having with your API or platform in near to real or real time?

Does your team have a platform, API, BaaS or other solution that calls for community developer involvement and developer outreach/evangelism through GitHub? 

Do you need to be responsive to developers that file issues about your product in your Github repo?

If you answered "Yes" to any of the above then this GitHub Issue response system tutorial is for you!

This tutorial will take you through the steps to set-up a multi-layered way to manage incoming Issues via GitHub.  Multi-layed GitHub-driven Issue alerting accelerates the break/fix process and eliminates bottlenecks by getting information into multiple points in the Agile cycle. The system outlined here makes your Agile team as responsive as possible to every incoming GitHub Issue for a given repository.

This system puts developer feedback instantly to work for your team by getting critical feedback into your Agile workflow in all the right places: during planning via a Pivotal Tracker new Story and text message, during testing via a new Zendesk Ticket and post-release via a Ducksboard heads up display.

This type of multi-layed response let's developers know that you are listening actively and it gets valuable developer feedback into the hands of multiple members of your team quickly so that it can be acted upon quickly and iteratively, the way Agile was designed to.

This tutorial uses the following: a GitHub repository, Zapier, Ducksboard, Zendesk and Pivotal Tracker.

You can choose to use the whole system or just the parts you love, it's up to you. GitHub and Zapier are the only items that are definitely required for this tut and for the most part they are both free.

Follow the steps and at the end of the tutorial you will have a system that takes an incoming Issue from a GitHub repo and then:

  • files a new Support ticket to your Zendesk account
  • sends a text message to a set of phone numbers like your PM or developer evangelist
  • files a new Bug in your Pivotal Tracker to be triaged (if you use Agile)
  • makes a post to a Ducksboard heads up display wallboard

Step 1

Turn on Issue Tracking for the GitHub repo that your open-source code or SDK reference material resides in. Turn on Issue Tracking by going to your repo and then go to Settings -> Features -> check the box to allow Issues.

After enabling the Issues feature the Issues option will appear for all users as a top level tab next to Pull Requests and Wiki.

Step 2

Let's get the part working that opens your Zendesk ticket, files a Pivotal Tracker Bug and sends a text message (aka SMS) to some mobile numbers.

Set-up an account (it's free) at Zapier.

Have your GitHub, Pivotal Tracker and Zendesk account pages open and handy so that you can grab authentication details.

Set-up an account with the SMS folks at, make a new campaign while you are there, name it anything you'll remember, pick a keyword it can be anything, check off the "MO" box under the Keyword field. Keep the user/pass handy.

Now for the fun part!

Create a new 'Zap' on Zapier by finding GitHub in the services marketplace and dragging the GitHub icon into the box on the left. Click the New Issue trigger from the GitHub trigger choices.

Find the Zendesk icon and drag that into the box on the right, select Create Ticket as the action.


Click Create This Zap. The page will set-up forms to collect your auth details for the GitHub side and then the Zendesk side.

In Section 2 drag in the fields from the left that you'd like to populate the new Ticket with.

Scroll all the way to the bottom (don't worry about Filters or Tests right now) and click Enable.

You'll land on your dashboard page and see the new Zap live under the Live Zaps table.

Click Create New Zap and run through the same process again but this time use GitHub New Issue on the left and drag Pivotal Tracker over onto the right. Choose New Story for the Pivotal Tracker action.

Enter the auth info for your Pivotal Tracker account. Scroll down drag in the fields from the left that you'd like to populate the new story with and Enable the Zap.

Now the last Zap!

Click Create a New Zap. Drag GitHub to the left as with the previous two, drag Mobyt SMS onto the right. Choose New SMS as the action.

Drag the Mobyt SMS icon into the right side of the Zap and select New SMS as the Action.

Add your authentication info for Mobyt.

Decide what fields you need the people getting the text message really need to see. I normally use the Title and Body.

From the dropdown on the Mobyt side, select the keyword that you set up earlier, it should be the only one there at this point.

In the Recipient field enter the mobile phone number that should get a text message when a new Issue is filed.

Just enter one to get this going, you can add more later once you know it's working the way you want it to.

Select the Campaign and Keyword that you set up when you opened the Mobyt account. It will be the only option in the list.

Head over to GitHub and file a new Issue in your repo.

Open up your Dashboard on Zapier. All of your services should be Live, not Paused.

Click the gear to open up the menu for each service.

Click Run for each service.

Click the Run icon to run your new Zap and test it.

After running each service you should see a new Ticket filed over in Zendesk, a new Story filed in Pivotal Tracker and a new text message arrive on your mobile phone.

This next step will allow you and your team to see all of your GitHub Issues in real-time on your heads up display. 

Ducksboard is a versatile real-time dashboard visualization web page that can be displayed on a monitor, a TV or you can link to your Ducksboard page from your Intranet, site or Wiki.

Here is an example of a sample Ducksboard that is displaying recent issues from GitHub, a list of a repo's followers and some info from Pivotal tracker.

This example is a Ducksboard that shows GitHub Issues, Followers and Pivotal Tracker actions for a given repository.

To use GitHub with a Ducksboard just head to Ducksboard and create an account, there are plenty of free and trial options.

Click the + sign on your first board and scroll around to find the GitHub widget.

Pick the GitHub Issues group then select GitHub Issues, One Column/Two Rows.

After authenticating click Choose Content from the tabs on the left.

Add your GitHub username and the name of the repo where you turned on Issue Tracking.

Save the preferences for that widget and presto, your Ducksboard will begin loading the issues from the repo.

You can add other widgets to the Ducksboard and then share the link with folks on the team who need it or add it to a wall board on a TV etc.


We just created a new Ticket in Zendesk, a new Story in Pivotal Tracker, a text message and a heads up display all from a single new Issue filed on GitHub!