Idea: Road Trip games

I had an idea. It was brewing during a day trip with the family in the countryside. I remember that when I was on a day trip with my siblings and parents, we play two games, one was car cricket and the other was a car spotting.

The car cricket game is a bit complicated. It was based upon a numbers that appear on the car number plate. As in a cricket game, the last digit in the number plate is the runs, and it is only used from a specific car or a bus. When the last digit is a 0, a wicket is produced. When 12 wickets is encountered, the next person takes its turn at batting. When everyone had its turn, the scores are added up and who ever has the largest runs is the winner.

The car spotting game is a lot simpler than car cricket game. Before the journey starts, a brand of car is selected. It could be a BMW, Porsche or VolksWagen. When someone spots the car, its brand name shouted out. A point is given to him. At the end of the trip, the person with the highest score is the winner.

It is possible to encapsulate these two games into a mobile app?

  

Gmail Logging

A story posted on hacker news about Google logging every single email you ever wrote is an interesting discussion piece. Of course,  that is assuming that someone of the communication chain is using Google's services.

At each point, an opportunity of storing the data is presented. Let's look at the chain. But let me premise that I am not network engineer, so they will be gaps in my analysis.

1. Joe sent the email on his computer to his brother Peter. A copy is saved on his email client. Typically in his sent folder.
2. The mail server received his email to dispatch to the recipient. The mail server could save a copy of the email.
3. The receiving mail server accepts the email and stores it until Peter is ready to take it. The mail server here stores it.
4. Peter connect to the mail server and download the email.  It is stored in the Peter's inbox.

Just with my simple communication chain, each link provides an opportunity to stored the email.

Once you throw in a smartphone, cloud email clients that are accessible on multiple computer,  the opportunity increases quite quickly.

dupfinder

My family and I own about seven devices that takes photos. Most of these devices are phones. Funny enough, we only have one camera. With some many photos floating about, managing them is a headache.

The first step in managing these many photos is to weed out the duplicates. One sure way of generating duplicates on our computer is not to take care when transferring them from the phone to the computer. The following is the typical situation.

• plug the phone to the computer.
• transfer the pictures to the computer.
• I don't delete the photos from my phone as I want to see them as I carry my phone about.
• A few days later, I would repeat the download cycle again, except that I would copy all the photos to different directory. I can't remember where I put the photos a few days ago and I am too scared that I might delete photos.

To overcome this problem, I need a python script.

The algorithm is simple. In 3 simple steps,

1. For each file generate a md5 digest of it.
2. group all the files that have the md5 digest together.
3. copy a file from each group to a new directory

The underlying assumption is that collisions are not possible, but as we all know (http://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities) md5 are not collision free.

The script seems to be relatively fast. It through its way through 2500 photos in about 10mins. This is on an Mac Mini with an 2.7Ghz i7 processor. 

The first version is not fancy and not loaded up with options. There are a number of options i would like to add, including a paranoid and a statistical mode

If you are interested, the source code is available at my Github (https://github.com/tyc/dupfinder) 

idea for side project #1

Problem

Not knowing how often the lights are being turned on when it is not being used.

Solution

To solve this problem, data must be collected to understand usage pattern of the environment. From this problem, when the light switch is turned on and off, the system will take a note of the date and time of each event. Ideally, each light source would have an accompanying sensor.

Over a course of about two months, enough data would be collected to the system to start doing some preventive measurement.

However, the first measurements it would provide is how much energy is being used by the lights. This should correlate to your power bill.

Secondly, due to the pattern that it has analysed, if anything falls outside the usage pattern, a notification could be sent out. Potentially, saving money.

The sensor could be coupled to a PIR. The analysis could draw patterns on the presence of movements and the active status of the light.

In a typical family house with children, lights will be left on when they exited the room. This system will help reduce the amount of the light is switched on and no one is  in the room

Keep your App signing keys safe.

Today I tried to publish version 3 of Dream Noise but struck against a problem that I was not aware previously.

During the preparation of the apk for uploading to Google Play, I forgot the password for the signing. "OK, no big deal. I will just delete the old keystore and create a new one," I thought. Well, that went well until I upload the apk onto Google Play. As the version 3 of the Dream Noise was signed with a different key, Google detected that the difference and reject the submission.

I can see that this is the correct thing for Google to do. The signing of apk ensures that it can only be updated by the same people.

So the lesson learn for me is to keep a note of the password that I have used to create the keystore.

To recovery of this problem is to unpublish Dream Noise from Google Play, wait for it to be removed. Upload a new application on to it. That is the plan. Let see if it will work out like that.


This is a link on StackOverflow that addresses this problem. Take heed.

http://stackoverflow.com/questions/4843212/the-apk-must-be-signed-with-the-same-certificates-as-the-previous-version

Dream Noise is on Google Play

Dream Noise is now published on Google Play. Initially, I wanted to do the right testing phase and run the Alpha / Beta test programs through the Google eco system. After speaking to a couple of friends, it turns out that the simplicity of the app allows it to be published straight away.

If you are interested to find out what it is, just to the Google Play link, (https://play.google.com/store/apps/details?id=com.dreamnoise.application) to download and play.

I have also posted the link to Facebook, Google Plus and Twitter. I am now actually sure how to track where the most clicks are coming from. The Google Developer console does have a statistical information, but it is only for downloads. Visits does not count to the Google Play item does get counted.

So far, it has gone through one iteration. It was mostly to change the background colour from a white colour to something darker. The reasoning is when the user is trying to fall asleep, it would be rather silly to have it a bright light emitting from the phone. So I changed it to a dark blue colour.

zipalign

Before an application is uploaded into Google, it must be aligned to the 32bit boundary. The alignment will be checked by the Google during the upload process. If it fails, a pop up message will say that the .apk is not aligned and reject the upload.

The zipalign tool is located to /tools. You can call it directly or add it to your PATH environment variable.

To execute it, use the following

zipalign -v 4 < outfile.apk>

The outfile is now ready for upload into Google.