ElfGA - Alien Technology Blog

Speak. Slower… and pause… often…

When I was young, I was absolutely terrified of getting up in front of the class to present something. Physically shaking, a weak shaky voice, staring down, rapidly reading off the 3×5 index cards, you name it. Even doing the class reading where each kid reads a chapter out loud had me panicked and in a rapid fire shaky panic.

Things started turning around for me in my second round of college. Part of the mandatory class listing was a communications class that was all about standing up and presenting. The first and last presentations were video taped and we were given VHS copies.

Old guitar as speaking prop
Our first assignment was a two minute speech on an object that was important to us and why. I brought a guitar, one of my few non-computer related hobbies. The tape showed a terrified kid (even though I was a couple years older than all the other students), using the guitar body to hide behind. My voice shook, I trembled. It was sad and painful to watch.

A couple months later, the final speech was ten minutes long. I was still obviously uncomfortable, my voice still trembled. There was still panic and fear. But I was able to stand up without a prop to hide behind. I had learned that everyone is afraid, but I hadn’t quite integrated the lesson yet. There was still more to be done.

A couple years later, I volunteered at my local Linux users club (smluc) for a presentation. I’d done a handful of presentations for different classes, but this was different. This was a group of people who voluntarily came out to honestly learn something for the pure learning, not for a credit, not as an assignment. I’d done up some trivial slides using javascript to make a slideshow that would work on the library computers ancient Internet Explorer (tricky, given I was only using Linux at home and mostly FreeBSD at work).

People of all ages were listening to what I said, they were interested! The audience was actually engaged! But I still spoke too quickly. I kept talking, even when there was nothing to say just yet. I got the verbal diarrhea. There were “um” and “uh” fillers, racing to the next slide. I had an audience that was engaged, but I was still racing and panicking.

Fast forward many years, I’ve been a “unix guru” at a small computer shop, a “senior technical analyst/sr unix admin” doing infrastructure tool development at a fortune 100, a computer scientist for the US Army Research Laboratory… And I got to sit in on a life changing event. A presenter that did it brilliantly, and then I went out to lunch with him. He was a real human, friendly, and he did this riveting presentation, unlike any I’d been before.

I learned two huge things that day.

Don’t read your slides. Never read your slides, the crap you present on the screen is just there to support what you say. If the slides are what you say, just email it and never do the presentation. The wall of text slide is soooo very wrong. But we knew that.

The other was to speak slower.

Sometimes. Very. Slowly.

Jack Donaghy
Once I learned that, I can’t stop seeing it. People who have something important to say speak slowly and pause often. People who you want to listen to speak slowly and pause often. Presidential State of the Union Addresses are all slow speaking and pauses. The television show ’30 rock’ has “Jack Donaghy” as a high powered businessman, played by Alec Baldwin. He speaks slowly with conviction and determination. He pauses frequently. He only seems to speak quickly when he’s out of control.

If you want people to hear and understand your message, you need to speak slow enough for them to process what you have said.

You need to pause.

You need to allow them a chance to process what you have said.

I think one of the better presentations I’ve given was on the internal operations of the Meta-ball primitive in the BRL-CAD software package. The slides were bare, stripped down to the minimal. Each slide was either a single picture of a single line of text (rarely more than 4 words). I believe the only outlier was a grid of performance numbers. I was careful to speak slow and accept silent moments. Several of the audience found me after the presentation and complimented me on it. I was even accused of being good at public speaking, a far cry from the trembling guy trying to hide behind a guitar, rushing through a set of bullet points on index cards.

I don’t think speaking slower is just for public presentation. I think any time you communicate, slow down. Speak with determination and thought.

Give people a chance to hear and understand you.



Comments Off

Lottery Calculator app sales funnel analytics for June, 2013

The number of impressions, hits and sales for the Lottery Calculator dropped after the big Powerball jackpot in April, but the conversion rates seem to be remaining stable.

As with last month, I’m posting the numbers as conversion rates for the year to date.



Conversion Rates


Conversion Rates

Tagged , , , , , | Comments Off

PostGreSQL time format for sitemaps

After converting the database for Adage from a memory resident format backed by cl-store to the postmodern PostGreSQL interface, Google reported that my generated sitemaps were flawed.

PostGreSQL date in Sitemap - Error according to Google

The original bit of SQL I used to fill the last modified field looked something like this
cast(timestamp as text)

Unfortunately, that format did not satisfy the google sitemap parser, so I had to use a format string in the casting SQL statement. This is what I ended up using
to_char(timestamp at time zone 'gmt', 'YYYY-MM-DD\"T\"HH24:MM:SSZ')

Tagged , , , , , , | Comments Off

Lottery Calculator app sales funnel analytics for May, 2013

May saw a bump in the number of people interested in lottery related searches. The spike was highest on May 17th, so it is probable reasonable to assume that the large Powerball jackpot ramping up to $590,000,000 before the big winning ticket was sold.

As with last month, I’m posting the numbers as conversion rates for the year to date.



Conversion Rates


Conversion Rates

Wrap up

The conversion rates stayed fairly stable from April. It’s definitely neat to see that they stayed regular through spike of traffic in the middle of the month.

Tagged , , , , , | Comments Off

Lottery Calculator funnel analytics for April, 2013

The Lottery Calculator App is definitely not one of the huge iStore success stories, but it is turning out to be a very good educational test bed. Things are probably great if you can get featured by Apple. Unfortunately, very few apps can be featured, so a different approach to marketing is required.

Funnel for Analytics

The web page I set up for Lottery Calculator is very basic, not much more than the app store entry. One key difference is that I can get a little information on how many visitors there are and do some analysis on the funnel. The metrics currently gathered are hits, outclicks, and how many of those hits are from the target platform (iPhone or iPad). Additionally, I gather information from the Google Webmaster tool about how often the page shows up in search as well as the number of actual purchases. Assuming the purchases are overwhelmingly from people who found it from the web page and that most users find it via Google, I’ve set up the basic funnel. Search->Hit->Outclick->buy.



Conversion Rates

A little basic math provides the conversion rates


Conversion Rates

February is skewed due to a brief ad campaign that brought in 15 hits. I modified the web page a bit based on SEO advice from around the web in March which I think is responsible for two bumps, the first almost immediately, then a significant jump in impressions in mid April.

Wrap up

One thing that jumps out at me is how very little data is needed to give somewhat consistent results. I expected the graph to jump all over the place, but the curves quickly flattened out. If I’d have known, I would have began collecting and analyzing much sooner instead of assuming I had too little data to be useful.

Tagged , , , , , | Comments Off

VSIP Application

I Quit!

VSIP application submitted!

Last week, I applied for Voluntary Seperation Insentive Pay (VSIP) at my day job. With the sequestration and looming furlough, they offered a stack o’ cash as a carrot to trim the work force. The program is a severance pay for people who voluntarily leave, with a handful of rules attached. If I were to rejoin the DoD or take on a “Personal Services” contract in the next 5 years, they would want me to pay the VSIP back.

What I’ve been up to

I’ve been reading the startup websites for years. I’ve spent some free time learning the technologies like Ruby on Rails, jQuery, NoSQL (Cassandra, MongoDB, CouchDB, etc), OpenID, CSS, etc. There are even a handful of web experiments (Adage, Belter, funnyname, Kore0, notify, password generator, performance monitor) and an iPhone/iPad app for computing the cash payout if you win a lottery (Lottery Calculator). Quite a bit of effort in learning the basics of SEO and the basics of marketing, as well.

I’ve actally been planning on leaving ARL for a while, so this seems like a kick in the ass with some extra cash to extend my runway. The VSIP isn’t guaranteed, and I’ll probably still be at my day job until September, but one of those big steps has been made!


Over the next six months, I’m planning on continuing to save like mad and work on learning the marketing and business side to being an entrepreneur. The financial prospects of the Lottery Calculator iPhone app are fairly grim, but it is useful as an educational tool. A little interface clean-up and the VCS Notification Service will be ready for “launch” and I hope to learn a lot more, and maybe even get lucky with a revenue stream. We’ll see where life takes me on this next adventure :)

Comments Off

The Great Google Reader Exodus

RSS Reader
Image credit: juliengron

Google announced sunset of their
RSS Reader and the geekier side of the internet seems to have exploded.

Many articles and comments talk about the various alternatives and how the lack of an 800 pound gorilla in the room will foster innovation in the RSS reader market. People will try and comment new approaches and ideas in how to consume their RSS feeds and small businesses will try new approaches to capitalize on the large displaced user base. On February 18th of 2013, I looked around for alternatives and found all of them wanting in some form or another, so I stuck with Google Reader at that time. This time, I’m being forced to find a replacement, so I guess I looked a little harder. The one that seems to match my use the most is TheOldReader, a simple Ruby on Rails SaaS that makes heavy use of AJAX (and had significant growing pains the last couple of days). It’s very close to Google Reader, so it might be worth a try.

Several other comments on various boards, forums, and other sites indicate that a lot of people are going to write their own. Honestly, I had the same idea at first, then decided to use a preexisting one and make suggestions to the developers to help shape it to my needs, then I decided it’d be better to just write my own, then I decided to let someone else, … Fighting the “Not Invented Here” syndrome. In the end, there are a lot of RSS readers now, a lot more on the way, and I think my time can be better spent elsewhere. Good luck to those who give it a shot!

The other major category of activity over the sunset of Google Reader is a lot of people claiming that Google has made a huge mistake and will be sorry. That seems like a petty and naïve stance to take. Of the geek friends I’ve talked to, only one other actually uses an RSS reader. The non-geek friends have heard something about google something going away, but have no clue what it is. While the minority is vocal and occasionally makes a good point, it’s very much a minority and I think well outside of domain Google seems to be focusing on lately. Googles reason for existence is to make money and they’ve probably done analysis of direct revenue, indirect revenue and cost before making this decision. Larger companies often even accept a little loss on a pet project just to keep the developers happy.

It’ll be interesting to see what the RSS world looks like when the dust settles.

Tagged , , , , , , | Comments Off

Long Tail Optimization, the numbers of a happy accident

I’ve been thinking a lot about SEO, long tail optimization, and various other methods for driving traffic lately. I have also been watching the analytics religiously and trying to guess at what matters. A certain blog post (the one about using jquery’s asynchronous request stuff, or AJAX, to update a bootstrap progress bar) seems to be well placed out on that long tail and drives a notable portion of that traffic.

Long Tail graph

This certain post only gets around 100 impressions a month from google, but has a CTR of about 20%. I have other pages that generate several times as many impressions, but never rack up the click count to even register. There definitely seems to be something about using long tail optimization to target the niche, as the other pages that get traffic mostly sit at 0 hits. Here is the google analytics graph of the jquery/bootstrap progress bar page

Google Analytics

While the traffic is hardly impressive, it is enough to start providing numbers to optimize. This is exciting as I have a brain chock full of lean startup concepts and am eager to start applying them in a practical fashion. The trick will be look for that magic balance where there is enough traffic to be worth it, but small enough interest that it’s not a saturated market. Neat stuff! :)

In the future, I think would like to start doing market research before blogging. Obviously, I like writing about some fairly esoteric topics, like how to generate Mac application bundles using SBCL or Setting up the UncommonWeb application server, but those pages get very little attention. The entry on the jQuery/bootstrap kinda felt like pandering when I wrote it, but drives more traffic than all the others combined. I think I’ve been focusing too far down the long tail!

Tagged , | Comments Off

LottoCalc for iOS (iPhone/iPod/iPad)

In early May of 2012, I jotted down a set of ideas for the next code to write. I had decided that it would either be a web app (UnCommonWeb based) or a mobile app. With the mobile apps, android let you get an app running on a device for free, but iOS seemed far more monetizable. While I was toying with ideas that only a geek could love, Erin had a clever idea; an app to estimate the ‘cash in hand’ if you win the lottery.

The huge lottery jackpot values advertised are cooked in an interesting way. Estimates are made of ticket sales and some ‘magic math’ is done on that number to come up with an investment value. The advertised jackpot is the sum of the payouts if the original lump were invested and a fixed amount cashed out monthly over the term listed in the small print, something like 30 years.

Wait, what?

That $100,000,000 jackpot on the billboard is NOT the winning amount! It’s an approximation of the value of the actual value if invested into a fund and tapped as an income value. If you wanted to cash out in one lump some and manage your own investments, the amount is significantly less.

Once you decide to take the cash out value, there are additional taxes that further reduce the take-home value. We focused on the US, looking at the Mega-Millions and Powerball lotteries in particular. The tax turned out to be chock full of special cases. There’s a federal hit right off the top. Some states don’t tax lottery winnings, others do. Some cities apply their own taxes. If you happen to win the lottery and live in Yonkers, there are 4 different taxes applied! If you buy the ticket in a state you’re not a resident of, the tax situation is further complicated.

So in late April of 2012, we set to work. We reverse engineered the ‘magic scalars’ and built the tax tables. We wrote a library in C to estimate the actual cash payout based on jackpot, location, residency, etc. We wrapped it in a simple iOS frontend and submitted it to the app store in late June. After about a week and a half, it quickly went from ‘waiting for review’ to ‘in review’ and ‘approved’. Success!

Tagged , , , , | Comments Off

Passing apache connection and config information to the application server

One of the challenges I’ve had in working with UnCommon Web (UCW) as an application server behind an Apache front-end is handling connection information. Modproxy creates a new connection to the app server itself, losing some of the incoming information. One way to pass that “extra” info to the app server is using an apache configuration line like this:

RequestHeader add "X-Name" "value"

This appends the new key/value pair to the HTTP headers. In my case, I wanted to tell if the connection was using SSL or not. In VirtualHost directive for the SSL listener, I added a line saying that the protocol is ‘https’.

    SSLEngine on
    RequestHeader add "X-Protocol" "https"

In the non-ssl version, I put in a line saying the protocol was http.

    RequestHeader add "X-Protocol" "http"

With the apache configuration done, apache can be restarted. Catching the value is as simple as querying the http headers in the application. Once possible way to do that in UCW is something like this

(defun protocol (req)
 (let ((prot (assoc "X-Protocol"
                    (headers (it.bese.ucw.core::headers req))
                    :test #'string=)))
  (when prot (cdr prot))))
Tagged , , , , , , , , , | Comments Off