Archive for the ‘programming’ Category

Download Trek.apk

More fun with Google’s Android App Inventor. This one is a Star Trek Communicator. Use the “open communicator” move to “flip” open the cover, then speak your command. The lights do things, too, so press them to find out.

There’s only a couple of commands active in this. I’m demoing it at the Intuit Tech Forum and will add a new command there, plus I’ll probably play with it more and add commands. Fun!

If you haven’t already done so, you’ll need to install the free Google Text to Speech service. Click here to install it.

Download Trek.apk

Click here to download the TextyDriver application

If you haven’t already done so, you’ll need to install the free Google Text to Speech service. Click here to install it.

It’s inevitable. You’re driving down the road, and you get a text message. What to do, what to do. You can read it – that takes your eyes off the road briefly. But… what if you need to respond? Can you pick up groceries? Make a quick call? Stop and pick up the kids from the mall?

You can text back a response. Dangerous. Trying to type while driving is a pain. Maybe your text message app accepts voice and transcribes it? That’s a little better, but you still have to click on the text field, then find the tiny microphone icon, speak your message, then read it to see if it was correctly transcribed, then press the send button.

Of course, you’re about out of luck if there was a transcription error. You have to try and delete the message and start over.

You could call. But that means more button pressing, locating the contact, getting to the right phone number, pressing the call button.

Enter Texty Driver. Massachusetts, like many states, has outlawed texting while driving – and for good reason! As I wrote above, it’s distracting. So the Texty Driver app is voice command driven. You can setup 3 frequent texters and with one button press, activate the texting sequence.

First, it states the name of the contact you are about to text and tells you to speak your message. When you are finished, just stop talking. The Android operating system on equipped phones, such as my Motorola Droid, will connect to servers and transcribe the message. It’s very accurate and works well even in road-noise environments.

Second, your transcribed message is read back to you. That lets you confirm the accuracy of transcription without looking away from the road. You can respond with “Yes”, “No” or “Cancel”. Yes sends the message, with a voice confirmation. No starts the transcription over, letting you speak your message again. Cancel stops the process.

If the app is kept running, there is an option that lets it speak received messages back to you. If one of the selected contacts responds, the app will convert the message to voice and speak it. However, App Inventor doesn’t currently allow applications to run as background processes, so it won’t speak if something else is running, or if the phone is locked.

Click here to download the TextyDriver application

A co-worker of mine told me of an ongoing contest at my office: a contest centered on me. The winner would be the person who could get me to say “Hello” to one of them. Someone would see me go for some coffee or popcorn, and they’d queue up to go into the break room and try to talk to me.

It wasn’t that I was intentionally unfriendly… I was just… focused. This was back when I was coding every minute of every day, cranking out applications at a rapid rate. My fellow programmers joked that I must type with my feet, too, since I was so fast. That speed was, in part, enabled by my ability to focus. Even necessary activities like restroom breaks or a snack were unwanted intrusions, an opportunity for my attention to drift away from the next line of code, the next bug to resolve.

My concentration was such that I would acknowledge other people, but often only in my mind. I said “Hello”, it was just so low-pitched, and sometimes no-pitched, that it was simply not there. So the only winners in that contest were the ones who happened to catch me at a transition, like finishing a bug sheet or a major part of code.

When I joined the Intuit Innovation Lab in 2002, some of that… lack of social grace… was necessarily overridden by the nature of my new work: I had to visit customers and talk to them. Or at least listen closely and ask the right follow up questions. I talked more to my co-workers, with my co-workers, and I learned how to connect with customers.

But all that change was just an unthoughtful response, not a deliberate difference compared to my “contest” days. It certainly wasn’t enough. I still had a lot of friction with my co-workers, viewed as “smart, fast, creative, and hard to work with”. It came to head when I locked horns with a co-worker, pushing things “my way” and not allowing a different opinion into the room. I didn’t like working that way, and neither did people like working with me when I was that way.

Fortunately, my boss at the time, Tara, suggested and supported me with a plan to change. She hired an executive coach for me. With his insights and help, I transformed how I interact with people – everyone, from my family, to my co-workers, to customers and just to everyone I meet.

I first took a personality test called an Enneagram. There are many such tests out there, and the Enneagram is probably one of the best. It has 3 person types, and 3 sub-types. The three types are Body, Mind and Feeling. I’m a Body type, with a sub-type of 1 – the Reformer. I want to solve problems, to make everything better. At my worst, I’m a perfectionist, plowing ahead with my own solution and pushing everyone else to the side.

The key to my transformation was to take the worst stereotype of a Reformer and apply that to myself. In every situation, I would laugh at that stereotype picture and refuse to fit into it, even as I knew that my normal mode would fit into it! I became a listener, a peacemaker, able to get things done as a team, as part of a team. I could let other ideas join my own without feeling like the solution would be “worse off”.

I can feel the difference, and it usually astonishes me. I’m happier, friendlier. I can connect with almost anyone. I get onto a plane where a flight attendant is greeting people. She didn’t look particularly happy, saying “Hi, welcome aboard.” I said, “Hi, thanks! How are you?” It was amazing – her face brightened, she talked some more, told me thanks for asking. I could hear her behind me greeting others with a smile! That’s why I’m astonished – I really had no idea before that I could personally, individually, brighten someone’s day just by, well, caring about them, to be honest. It’s more than just a “friendly” hello, rather I actually mean it when I ask, “How are you?” I talk to people about their day, their work, their feelings.

Those of you who know how I was “before” will, I believe, be pleasantly surprised at how I interact with you and those people around you. It’s a world full of people out there, and they’ve had all kinds of days: good and bad and indifferent. Open up ye engineers and explore the people around you. We’ll all be happier for it!

Software is… hard. There are so many things to think about, even when creating an offering as simple as an automated email message. Click on the image on the left and you’ll see what I mean. Notice the link in the bottom status bar and the highlighted link in the text. It’s for Hertz.com, but the actual link reference is for Hertz.com. – an added “.” period. Note that it is also an SSL secure website, which means that the security certificate needs to exactly match the URL if you don’t want the browser to pop up a scary “security exception” notice. Someone at Hertz.com didn’t get it right. More likely several someones.

Creating good software takes an attention to detail that the “engineering” discipline attempts to enforce. But unlike many traditional engineering tasks, there are many different ways of accomplishing the same task, and they can all be valid at one point or another. The number of systems, concepts, languages, end customer environments… it’s staggering how much a programming “maven” needs to keep in his or her head.

Processes and project roles are a big help. A project manager to plan and maintain the big picture, designers who sweat the details, developers who are experienced and focused, quality assurance folks who nitpick every little comma and period. Every one of those roles has a responsibility to catch that “Hertz.com.” error.

  • Did the project manager ensure that the wording in the email is correct?
  • Did the designer check the text, the fonts, the highlighting colors?
  • Did the developer know how to construct a link in both HTML and Text formats?
  • Did the QA folks actually click the link – and clicked it using a “clean” environment?

I remember a tester who worked on my EasyACCT stuff back at Tax and Accounting Software Corporation (TAASC) in Tulsa – Brian Anderson. He was a superb tester, and later became a developer as well. He owns Hostek.com, where this website (and my others) are hosted.

He would sometimes come up with the craziest sequences to duplicate an error – press Ctrl-Shift and then down arrow five times, type “Q-2” and press Enter, and you see this error message. Maddening. But if Brian tested it, then I was confident that my application was thoroughly tested and working as good as mortal man could make it.

A great tester is worth his or her weight in gold, as is a nit-picky designer, a thorough and knowledgeable project manager, and a careful and experienced developer. Don’t skimp on your people, and always have at least one truly experienced person in your project team. Programming is an art, not a science. You put chlorine onto gold, you’ll get dissolved gold and a very unhappy investor. There aren’t variations when those two elements are mixed. You design an application, and there are dozens if not hundreds of ways that things could be mixed to create the working application. Experience is absolutely necessary if you want Quality.

I’ve been using the App Inventor for Android for a while now. I managed to get in on the private beta, partially on my credentials as an MIT Scratch educator. I’ve taught 3 Scratch classes to kids from elementary to high school. I also follow the App Inventor Google group and came across a few people needing a URL Encoder.

I’d already written a simple URL encoder while testing out a mapping application. It uses the Google Maps staticmap API function to retrieve a map with markers. The markers are created by passing in an address, and although many browsers will accept spaces in URLs, the Image component in App Inventor won’t: you must encode a space either with a plus + character or with the hexadecimal encoding %20.

The newline character “\n” is also encoded, but the routine to test for it is separate from the others as App Inventor doesn’t find the correct location of various characters when you include it.

Here are the blocks for the character codes and their translations, plus some misc variables used in the encode routine. The “chars” block contains $&+,/:;=?@ “<>#%{}|\^~[]’ and the codes block contains 24262B2C2F3A3B3D3F4020223C3E23257B7D7C5C5E7E5B5D60.

Now the URLEncode routine itself is fairly simple. It loops through each character in the provided text and searches for it in the chars and ctrl strings. If it finds it, it calculates the offset position for the code and adds that to the URL. If it doesn’t find it, then it just adds the character from the provided text. The offset position for each character is ((pos-1)*2)+1.