Author: David Quail

Sending emails on behalf of users

Our application, much like many others, uses email as a means of communication between users. We recently made a design goal to send these emails from the users themselves as opposed to from our application. The decision itself seems to have been easier than the spam filters, spf records, domainkeys, and ActionMailer patch implementation details that ensued.

I’ll publish a list of articles that articulate the necessary technical steps to not only send email out on behalf of users (this is the easy part), but to get beyond spam filters, but for now I’m concentrating on motivations for sending out said emails as users.

The scenario that I’m considering is one familiar with users and developers of social networking sites. User John Doe invites Jane to use “My Application.” At this point, Jane will either receive an email from Accounts@MyApplication.com or else an email from John@hisdomain.com. I think it’s fairly obvious that a barrier of trust exists when users receive an invitation from some arbitrary domain owner …. such as “My Application,”regardless of how convincing the message is. Therefore I’m convinced that for virality, it’s ideal to invite users by using their email addresses, ie. John@hisdomain.com.

Before I begin to expand on implementation details in getting beyond spam filters, I must admit that at certain points, I began to question the nature of what we were doing. Part of me at times felt as though spam, and spoofing in particular, was exactly what we were trying to accomplish. I

In the end however, I am comforted and assured that what we are doing does not infringe on any privacy issues. Ultimately, users are intending on inviting others to collaborate with them. They intend to send a message to their friends or colleagues that they’d like to work with them; we enable these messages to be delivered in a natural way using the email addresses the users are working with.

What not to do when creating a software demo

I recently went through the pains of making a demo for an upcoming product. Perhaps the most obvious thing that I learned from this trial was that there is a reason people do this sort of thing professionally!

Needless to say, I took my lumps and in the end generated something that closely resembled a big steaming pile of poo for a demo. Fortunately, there will be a second crack … and we received some awesome feedback from Steven Blank, author of The Four Steps to Epiphany, a classic on bringing a product to market. Some lessons learned when making a demo:

4. Slow down
People watching the demo haven’t lived, breathed, and dreamed Attassa for the last year and a half. Chances are, it’ll take them a bit more time for things to sink in and make sense.

Screens need to be displayed for more than a fraction of a second, actions need to be explicitly pointed out, introduced, and explained.

3. Keep a running dashboard of benefits
One of the best suggestions that Steven had was to create a running list of benefits. As these benefits were being demonstrated, check them off of a list; making them painfully obvious. Clear Context does a nice job of the running dashboard of values.

2 . Create a demo scenario, not just a list of features to demonstrate
The most compelling demos are those that are able to show a real life usage that resonates with viewers. Without getting overly specific in any scenario, you can usually come up with one that is generic enough to convey value, while specific enough that the practicality of the software is beleviable.

1. The point of the demo is demonstrate value
It took me about 2 minutes to lose track of this and my engineering side to pop out as I proudly sliced together clips, transitioned audio, and in general, used every feature of the screen capturing software.

Why Edmonton is Deadmonton for Technology Startups


I love Edmonton. It’s a beautiful, friendly, family oriented city that I owe a lot to. I landed my first job here, gained countless amazing friends, and will always think positively about the city. But at the risk of sounding like a pre-madona, it’s a terrible place to be if you’re starting up a technology company.

I’ve bounced between Seattle and Edmonton the last 3 years in an attempt to balance a career, a software startup company, and a relationship; probably compromising all 3 fronts instead of fully investing. My assertion has always been that being in Seattle or San Francisco as a founder of a software startup is extremely advantageous

I’ll spare you the chest pounding rhetoric, and just give you the personal first hand challenges founding a company while spending time in Edmonton.

1. It’s expensive
Sure, web 2.0 startup costs are much cheaper than traditional models, but we experienced the expenses of Edmonton’s remoteness on a recent business trip. Since I was in Seattle at the time, I flew Seattle to San Francisco for $200 return. My co-founder flew Edmonton to San Francisco for $650 return. It also took him 6 more hours to get there.

2. Bootstrapping possibilities
When considering venture capital investment, our team considered continued funding through independent contract work. Finding contract work in Edmonton is tough. Government contracts do exist, but to be frank, it’s not always the most invigorating work. The following is a screenshot of the “Ruby” jobs listed in Seattle Area

… and Edmonton Area.

nuff said …

3. Finding Capital
We got lucky and raised money on a cold call early on in our efforts, so this claimed advantage is based more on assumptions than first hand experience. In our early planning, we always assumed we would have to hit the east coast, Seattle, or the Valley for Angel investment or Venture Capital; perhaps I’m wrong on my assumption.

My assumption is that Edmonton is filthy rich, but the money is tied up in Oil. Edmonton’s rich are Oil millionaires. They know the industry, understand it, believe in it, and trust their investments in it. I don’t blame them. Talking, and getting helpful investment from an ex Amazon, Web-Ex, Microsoft, Google, or Oracle millionare is much easier than a Talisman, or Husky Oil. Furthermore, investment is more than just $$, and the sweat equity gained from someone who understands the business is extremely valuable.

4. Talking to startup and technology peers Talking to peers in any professional domain is energizing. Physicians, lawyers, educators, laborers, are all motivated, educated, and energized talking shop with peers. Forget networking, schmoozing, or any other cliché, there hasn’t been a Seattle Tech Startup, Seattle lunch 2.0, or startup weekend that I’ve not been incredibly motivated by. Seattle offers events sponsored by Npost, Northwest Entreupreneurs, Startpad, Seattle Tech Startups, Biznik, Seattle Lunch 2.0, and many more. No such technology evens exist in Edmonton, and I can’t help but feel incredibly isolated in Edmonton.

5. Finding evangelists We’re very close to releasing Beta product. In addition to trying to find early adopters of our software via blogs, online marketing, etc, you can bet we’re going to go the grass roots route and talk to as many of our contacts as possible in an attempt to find a beach head customer. It’s a tough thing finding evangelists of new technology when they’re all bogged down with IT policy, software restrictions, as most corporate and governmental organizations are in Edmonton.

7. Finding co-workers Not sure what comes first the jobs or those qualified to perform them, but they go hand in hand. See above screenshots of Ruby jobs in Edmonton.

8. Standard of living Start hurling tomatoes Albertans …. But the *standard of living* offered by the immediate access to the Puget sound, lake Washington, Cascade Mountains, the metropolitan perks, is a convenience for someone with a demanding work schedule. Not having to drive more than 30 miles for these benefits provides a lot of the balance we all need in our lives. While Edmonton is beautiful, it’s also extremely isolated and unbelievably cold.

I’ll admit that my ability to hack away on a laptop, whether I’m in Gull Lake Saskatchewan, Seattle, San Francisco, Edmonton, or Timbuktoo, is about the same. If only starting up a tech company was as easy as typing away on a laptop.

Adding UI to Add Remove Programs Uninstall

As part of our uninstall flow, we want to give the user the option to manually save any of their user generated data before our uninstaller deletes it. Giving all users on the computer, not just the uninstalling user, this option, is a completely separate bag of worms that I’ll address in a later post.

Unfortunately, Windows launches uninstall in minimum UI mode when run from Add/Remove program files. This meens that as fancy and elegant as my underlying UI is on uninstall …. You’re not gonna see it when launched from Add remove programs. After going down a few false positive routes

– Changing the uninstallstring in the registry from /X to /I (windows ignores this)

The Rube solution was to

  • Hide the repair option from ARP

  • Enable the change option from ARP.
  • Modify my installer UI so that control elements displayed would be dependent on whether installing, repairing, or uninstalling

Installed

Wix bootstrapper setup.exe

As part of an effort to address several edgy installer and deployment requirements, I finally decided to wrap our installer .msi in a setup.exe. Previous deployments required our users to download a setup.exe which would download, and launch a second .msi. Being constrained by the wix toolset, and not having the luxury of install shield or another setup application made this a non-trivial task.

Our bootstrapper requirements were fairly straight forward and consistent with any other …

– Extract the internal msi

– Launch the external msi with maximum allowed privileges. If running as admin, install per / machine, else install per/user. This allows us to get around some of the Vista UAC nonsense in determining whether the installer is running as admin or not.

– Launch upgrade path REINSTALLMODE=vomus if the application was previously installed and running setup.exe.

There’s several bootstrapper stubs out there and available on the internet, some even containing code, but none of them seemed to do the job. Our Rube Goldberg solution ….

Use the wix 3.0 setupbld.exe tool along with the wix default default setup.exe stub.

Setupbld.exe is a nice tool that is part of wix 3.0 that beautifully wraps an msi with any setup.exe stub. The setup.exe stub that is bundled with wix 3.0 fulfills the above installer requirements that we have, so there was no need to even write our own stub. The only problem a person may have with this approach is not functional, but rather cosmetic. The generated setup.exe bootstrapper contains the resource information from the stub. Ie. You’re stuck with the generic icon as well as version information contained in the stub. One work around for this (that’s tough to automate in a build system) is to manually crack open the stub.exe in visual studio (simply file open) and change the resource information to that which you prefer.

So … our process ….

1. Autobuild generates the binaries

2. Autobuild builds the installer msi wrapping these binaries

3. Autobuild wraps the msi into a setup.exe

a. setupbld -out Setup.exe –mpsu setup.msi -setup setup.exe -title “Product Setup”

If we had wanted to inject our own branding into the build, we could update the setup.exe bundled with wix 3.0 with our own branding / version information.

Microsoft Xobni aquisition offer

While the value proposition offered between our product Attassa and that of Xobni is not identical, there is enough similarities between the 2 technologies and value, that they’ve always been on our radar. So watching their progress all the way from Y-Combinator to Bill Gates Demo, it always seemed clear to me that a Microsoft acquisition was a likely exit. So it wasn’t too much of a surprise when I read today that Microsoft is mulling over an offer.

I’m rather intrigued by the $20 million dollar speculated offer.

On one hand, Xobni has been overwhelmingly successful at proving that they can generate buzz. Watching Bill Gates Demo, was proof enough to me that they’ve nailed out their vision with great success. Considering this and the 4M first round of funding, I’m inclined to think that taking a $20M exit would be leaving a serious chunk of change on the table.

On the other hand, what Xobni has yet to prove out is a business model. Furthermore, they’ve yet to prove that their product provides real time or cost benefit to the end user … beyond an Outlook bell or whistle. If they’re concerned about either … a $20 might be humored.

I’d be shocked if they took anything close.

David – Attassa (That’s “Attassa” spelled backwards, and then spelled backwards again)

The face behind a name … and a title.


My girlfriend dislikes being called doctor.

A quick survey of the large stack of mail that typically resides on her coffee table reveals that none is addressed to “Dr.”, and if asked, she would show you that the cards in her wallet would indicate no such intitials. Furthermore, when asked by a stranger what she does, she responds by saying “I work at the hospital.” Her next response is typically, “Actually I’m a physician.” Of course, this response is required to correct a typical “oh, you’re a nurse” declaration by the stranger. I admire this modesty in her; perhaps even more than I admire the determination, intellect, talent, sacrifice, and grueling hard work that has entitled her to these initials. I reflect upon my own level of humbleness and the real face behind the “founder of a startup company” title I often mention.

After listening to a “White coat, Black art” podcast on CBC radio one exploring how MDs haul out their credentials to get perks; I reflected upon my own behavior. It seems as though in our software industry, to many, “founder in a startup company”, is viewed as a glamorous position. This was certainly reflected at Seattle Startup Weekend at Adobe. In contrast to obscuring these credentials, I take every opportunity to make them known. From my blog, business cards, collabomatic t-shirts, to conversations with my hairdresser, I far from hide my occupation.

Perhaps I just realize that the life as a founder of a startup is fundamentally fleeting …. subject to a ticking clock and the maturity of the company. Unlike a lifetime with a “Dr.” title, I am simply making the most of the small window of time. Furthermore, core to the success of your company is exposure of both the company and its founders, so on occasion self promotion is required.

Without a doubt, the effort and sacrifices in founding a startup are something to very much be proud of. However, I think there’s a line between enjoying the moment, being proud, gaining exposure …. and … bragging. I’ve probably stepped over this line on occasion.

Computer Science Is Dead

I just finished reading Short history of Progress. A great read, and falls nicely into this pseudo hippie/midlife crisis I find myself in.

My extremely limited literary genius tells me that one of the core themes of the book is that throughout the history of man, science has advanced, in occasions too fast for the good of society. Ronald Wright does a nice job of showing this through examples of “progress traps” ie. Babylon fell as a result of their very own success through sophisticated wet agriculture practices leading to increased food yeilds, cities and wealth, but also, eventually salination and death of the soil.

I’ll take a gigantic leap and compare the death of a culture … with advances in programming tools leading to the death of computer scientists, as I recently heard a peer boast.

Ok, that’s a bit extreme … a lot extreme actually … and even more naive. While the likes of auto-generated code, garbage collectors, intellisense, .net and rails frameworks have in many ways, allowed pragmatic and scientific skills to be optional when writing code; much like any other science, advances in the tools allows the scientist to focus on other areas of their domain.

Stating that computer science was dead because of an advanced compiler would be like claiming mechanical engineering was toast because of the invention of the wheel. To me, computer science ultimately comes down to mathematical logic, category theory, domain theory, and algebra. Having an IDE doesn’t help me out in any of these areas.

Why I’ll no show for Seattle Startup Weekend on Sunday


The only person in complete control of what they get out of an event like Seattle Startup weekend is … themselves. For this reason it’s largely my own failure for not getting more from the weekend.

In addition, Andrew Hyde has done a good job coordinating such a phenomenal weekend full of energy, creativity, and excitement. I really do think he’s onto something with Startup weekend, and the likes of Nathan Kaiser from NPost ,and the Jott http://www.jott.com/ crew did Seattle proud.

However, I am simply not embracing the experience and won’t be heading back Sunday for the final day to see the product called SkillBit launch. Despite plenty of talented and technical people, lots of product brainstorming, marketing, bizdev discussion and a general *I’ll do anything* attitude shown by many, this in so many ways feels more like the large company atmosphere, than that of a startup.

Dev waiting for requirements, designers waiting for a product name and url, business developers drafting page long business plans, project managers scurrying around asking what they can do to help, and an odd vibe of bitterness when egos and consensus collide.

I suppose when combining 130 some odd people, this process and division of labor is both inevitable and needed. However, to me, the most appealing part of being a founder in a startup has been the lack of role definition and the abundance of overall responsibility of all the founders performing tasks spanning from bizdev to sales, to product development.

Or maybe the real reason is simpler. I’m lucky enough to have the opportunity to invest my energy and time working on my own startup that I’m passionate about, and will see the rewards of instead.

If I were to do it again, I’d take the advice of Andrew and treat it more as a community building exercise. I’d pick a role to latch onto Friday night and learn as much as possible from one of the experts in the subject area much more experienced than I … perhaps SEO …. Perhaps learning Django …. But as it was, I couldn’t tear myself away from thoughts of our own product .. and a Ruby interpreter.