I'm a just a dude like any other programmer

After listening to Should Google+ require you to use your real name? one fine sunny bike ride, I was left wondered if maybe my justification for anonymity might be more common than the authors might think. My wondering stopped there, until this evening when I giggled at my one of GitHub messages. 

There are many nefarious reasons to use a handle. Some people hide behind anonymity to post nasty comments on YouTube, troll in general, say abusive things or start mass riots in countries where freedom of speech isn't common.  But not all reasons for anonymity are nefarious, some are just about having a level playing field. As "cesine" I've quietly listened on user groups while others suggest new barbie wall papers, and flirty penguins to bring in some of the female persuasion over to Linux, etc. I once made an eye fluttering Tux and put it on my website, wondering if they might catch on that there was something different about the operator of that server.  

Anonymity for me meant having people treat me like any other programmer/geek. My real name isn't at all gender neutral like Tony, Alex or Jesse. But my handle, "cesine" which has been my web identity since 1996 is everything neutral. And apparently, it's working. I think this speaks for itself.

Now that I'm officially "out of the closet" in the blogosphere, its only a question of 10 minutes research to find I'm not your typical dude, but still that's 10 minutes most people won't take. As long as I don't have to use my real name, that's a 10 minute cushion of unbiased respect.

Precision vs. Recall defined for linguists

Precision and recall are some interesting examples of terminology from computer science which will help linguists know how to divide tasks best done by a linguist, from those best done by a script or some sort of automation; in other words, when it needs to be perfect, and when good enough, is good enough.

Recall means getting back all the examples in your data which display that factor. You can get high recall by writing a script which returns a lot of results. There is always a second step, to go through the examples yourself as a human to filter out the extraneous examples. Getting high recall is generally a good first step when you start your research (think: google web search, you really want to know all the authors that have written on your topic...)

Precision means getting data that you can run stats on and get statistical significance. High precision means all the results are what you were looking for. Getting high precision is important to make any claims or generalizations, its generally the last step (and highly valued) in your research.

How do you get high recall or high precision?

You get high precision by rules or having a human check your data (or multiple humans if its hard to detect or the classification is tricky). You get high recall by making a simple script or using statistics and setting your statistics threshold to be more permissive.

How do know which one you need depending on the context?

When you are working on theory ideally you want high recall and high precision (its basicaly the equivalent of necesary and sufficient conditions to define a set). Having high recall but low precision is okay, as long as your goal is to share your research and data and get feedback on the categorization of your data.

Watchmes for AuBlog

I made some quick-n-dirty Watchmes

How to use AuBlog for blogging via typing

How to user AuBlog for blogging via dictations

The machine transcriptions are hilarious, and not very useful. AuBlog uses an Open Source machine transcription software (Sphinx). It needs to be trained to your "iLanguage" (vocabulary) to return quality results...

Feature Algebra in a Nutshell

Feature Algebra is an "algebraic form of representation that allows the use of variables and indices for the purposes of identity checking" (Reiss 2002).

Posted using my Android

App Stats 20 days - Conclusion: Calling for Malay localizers :)

Let's take a look at my Android Market stats during open beta testing for Iteration I Aug 9-29 : User Interface

I have a total of 15 active users according to the Android Market, most of the users have either Android 2.2 (Froyo) or 2.3.3 (Gingerbread).

Android versions:

1.	2.2	2,084	78.17%
2.	2.3.3	381	14.29%
3.	3.1	67	2.51%
4.	2.2.1	50	1.88%
5.	3.0.1	43	1.61%
6.	2.2.2	20	0.75%
7.	2.3.4	13	0.49%
8.	3.2	7	0.26%
9.	(not set)	1	0.04%

Total active installs : 15

Naturally I have had installs in Canada and the US, but 50% of my user base is in Indonesia and Malaysia  (probably my friends from Grad school) although I'm not sure how they found out about it, since I only told a couple of people that I knew that had Androids. There were also some users from Israel,  Austria, Sweden, India, Lebanon and the UK. How they found AuBlog and why they downloaded it I can't guess :)

1	Malaysia	26.7% (4)
2	Indonesia	26.7% (4)
3	United States	13.3% (2)
4	Canada	13.3% (2)
5	United Kingdom	6.7% (1)
6	Austria	6.7% (1)
7	India	6.7% (1)

The most important thing for me was to find out what kinds of devices I should target. I have tested my app with an HTC Desire (2.2),  Viewsonic Gtab (2.3.3) and a Motorola Xoom (3.1) all of which have different user experience with my app.

1	Samsung Galaxy Mini
2	Samsung Galaxy Tab 10.1
3	Samsung Galaxy S2
4	HTC Thunderbolt
5	HTC Wildfire S
6	LG Optimus One
7	Samsung Galaxy Fit
8	HTC Desire
9	Samsung Galaxy S
10	HTC Sensation 4G

Device Testing

The HTC Desire : my everyday device.

Audio
Bluetooth works seamlessly with Aublog. This is fortunate, as this is the device I go biking with. The audio is also a much better quality using the bluetooth although it is still only 8000 hz sample rate, yielding only 4000hz sample rate which is not usable for phonetic analysis. What a 4000 hz sample rate means is that high frequency noise like the white noise in the bursts and frication of stops, fricatives and affricates is not captured.

Visual
On the visual side of things, the Javascript in the Drafts Tree consistently renders the tree and the JavaScript in the Edit Entry page also consistently saves state when I rotate the device. On the other hand, the buttons in the WebView are quite ugly, by default.


The ViewSonic GTab

Audio
It doesn't work with Bluetooth, despite having bluetooth, and successfully pairing with my bluetooth headset. It is perhaps due to a lack of a telephony system. In order to play and record audio through bluetooth, the app must actually route the audio through the telephony system in earlier versions of Android. So the fact that Bluetooth works on the HTC Desire, maybe due to the fact that it is 2.2, or that it is a phone. The Bluetooth API underwent a lot of improvements in 3.0 and beyond so hopefully it will work more consistently on the other devices. On the other hand, Android 2.3 and above allows for wide band recordings of 16,000 hz sample rate which yields a much better quality and is useable for phonetic analysis as the range needed for human speech sounds is below 8000 hz.

Visual
On the visual side of things the large screen size is fun for using the Drafts Tree! While testing I realized I started using the titles in the nodes unconsciously to document the branching test scenarios for each feature and sequence of  user actions in AuBlog. It serves as a pretty quick tree generator, especially for nodes with small labels. I was planning on repackaging it into a tree drawing app for linguists, or tree thinkers.  The WebView buttons are also quite visually pleasing, by default.

A question for the tablet users: can you record and hear audio with your paired bluetooth headset when you enable it in AuBlog?

The Motorola Xoom

Audio
The bluetooth and the audio on the Xoom has the same story as the GTab, no bluetooth but surprisingly good quality with the built in mic.

Visual
The Xoom was an interesting visual surprise for AuBlog. First of all, after testing heavily on the HTC, and once and a while on the GTab I didn't expect the Xoom to present such an unusable user experience. There are no hardware buttons on the Xoom, the buttons are created by the software. Moreover, there is no Menu button by default. Instead, menu items are rendered in "the Action Bar" if the app targets SDK 11, using the same underlying code. However, despite targeting SDK 11, and using best practices for menu coding, the menu didn't show up on the Xoom (probably because there are just words as menu items, not icons). To have the menu show up I changed the target to SDK 10, and now the software menu appears. The next problem with the XOOM has to do with the Drafts Tree. The drafts tree is generated when the user clicks on Drafts. The Activity calls the WebView with the static HTML page, and the HTML page loads the JSON (the tree).  By initializing the tree only after the page has loaded, and the JSON has finished exporting, the tree loads properly on the HTC Desire, and also on the GTab, but not on the Xoom. At first I thought it might be due to having 2 cores (one core might be still writing the JSON to file, while the other is loading the JSON into the WebView, but the GTab also has two cores. It may also have to do with having a new WebView version. A question for the testers with Android 3.0 and up, does the Drafts tree load?

In future iterations (once I'm out of the prototyping stage and the architecture has stabilized) I was also planning on localizing AuBlog for another language to put all the mechanisms in place, my candidate languages were French (since I live in Montreal) and Inuktitut (since my informants might tell their friends about it), but it seems like Malay could be fun too since its 50% of my current users :) That is not for a few more iterations, I will wait until the architecture has stabilized further.

Architecture Growth
Itteration I Graphical User Interface : v1.0 - 4 Months
Standard Activities + WebViews for graphically interesting User Interface + Settings for persistant variables and user preferences

Most of the development time so far has been devoted to reconciling the interest of a visually pleasing user interface with maintaing state and not loosing user's entries while they type and rotate the screen. It seems like it should not be such a complex operation, but rotating the screen "destroys" and recreates the activity. Since the user is typing in a webview the Javascript interface has to save the state down to the activity in order to use the built-in state saving mechanisms. Nothing is more frustrating than loosing what you have just entered because you shifted in your chair and the screen rotated. On the other hand rotating the screen is crucial for a good user experience: some times you want to read the entry in wide screen, and then rotate to edit in portrait with the keyboard on the bottom of the screen. The user interface uses a couple of open source JavaScript libraries to make the drafts tree interactive (JIT) and the blog editing WYSIWYG (MarkItUp).

Iteration II Background Services: v1.1 - 20 days
Standard Activities  + WebViews for graphically interesting User Interface + + Settings for persistant variables and user preferences + Recording and transcription server interfacing refactored into Services + Broadcasts between modules

Audio Management Services and the transcription server architecture (Node.js and PocketSphinx) was surprisingly straightforward to set up, and also the most important core of AuBlog's mission. In this iteration AuBlog supports 3 audio configurations: Bluetooth for wire-free dictation, earphones+mic for private dictation, and built-in mic and speakers for default dictation. AuBlog also supports a variety of internet connection preferences, from transcription only over Wifi, to transfers over 3G for x file sizes. In my experience dictations are between 2-4 minutes long, and result in really small files (10-15KB) so its worthwhile to send them for transcription over a 3G connection while I'm biking. I made it so that its completely configurable and users can decide what they want to automatically transcribe. I generally only send the lowest daughter on a branch for transcription since the others are drafts, I prefer to re-listen to them and reformulate them until I'm satisfied.


Iteration III Voice User Interface & Widget : v1.2 - (3 Months)
A homescreen widget for "eyes-free" bike blogging. This will encourage refactoring the code into a central "brain" which issues intents to the other components.  This will also be an interesting challenge to make it as "eyes-free" as possible and set up/adopt architecture to use Google Voice to recognize app commands
"New Entry"
"Play/Read Mother Node"
"Play/Read/Record Sister Node"
"Delete Entry"
"New Daughter"
"Stop recording"
etc

After spending so much precious dev time making sure the graphical user interface's javascript libraries is functional on an Android device, I remembered that I never really wanted a visual user interface; I wanted an "eyes-free" (meaning language only) interface. So, at this point the GUI is functional, and it will stay as it is unless there are some bugs which affect its functionality. I would love to auto-resize the nodes to fit the text but that would require a lot more dev time. I'm excited to start Iteration III, the part of the app that really interests me and is the part I can contribute to most: the VUI (voice user interface). I expect this will take me more time than Iteration II, which only took 20 days. It all depends on the existing open source modules I find and how well they integrate with Android. 

My first published app!

I published my first app yesterday on the market, it's called AuBlog.

Code https://github.com/cesine/Aublog

It's designed to let me blog while biking. I figured some others might be interested too so I put it on the market. I didn't advertise anywhere, I'll post about the organic statistics as they come in.
Posted using my Android

Le P'Tit Train du Nord Bike Trip

Day 1 - 109km @ 19.06km/h

Created by My Tracks on Android.

Total Distance: 109.23 km
Total Time: 9:53:21
Moving Time: 5:43:53
Average Speed: 11.05 km/h
Average Moving Speed: 19.06 km/h
Max Speed: 39.00 km/h
Min Elevation: 61 m
Max Elevation: 423 m (1388 ft)
Elevation Gain: 1825 m (5986 ft)
Max Grade: 24 %
Min Grade: -26 %
Recorded: Fri Jul 29 08:10:01 EDT 2011
Activity type: cycling

Day 2 - Part 1 : 62km @ 19.23km/h

Created by My Tracks on Android.

Total Distance: 61.74 km
Total Time: 5:08:52
Moving Time: 3:12:41
Average Speed: 11.99 km/h
Average Moving Speed: 19.23 km/h
Max Speed: 31.00 km/h
Min Elevation: 172 m
Max Elevation: 325 m
Elevation Gain: 788 m
Max Grade: 17 %
Min Grade: -18 %
Recorded: Sat Jul 30 07:36:59 EDT 2011

Day 2 - Part 2 : 27km @ 22.59km/hr

Created by My Tracks on Android.

Total Distance: 27.15 km
Total Time: 2:16:41
Moving Time: 1:12:07
Average Speed: 11.92 km/h
Average Moving Speed: 22.59 km/h
Max Speed: 35.00 km/h
Min Elevation: 177 m
Max Elevation: 300 m
Elevation Gain: 275 m
Max Grade: 10 %
Min Grade: -12 %
Recorded: Sat Jul 30 13:23:55 EDT 2011
Activity type: cycling