For some reason, I find myself sitting in Edmonton International terminal, contemplating my response to self-criticism, as I wait for my flight to Seattle. Maybe it’s that holiday time of year where I begin to reflect on the year that was, but I’m reliving a few moments within the last year where I became critical of myself, and thinking about how I handled my own feedback. I guess you could say that I’m being critical of the way that I criticize myself.

After a terrible performance in Bozeman Montana I was convinced that I’d lost whatever ultimate Frisbee skill and talent that I once had. After receiving negative feedback on my attempts to generate demo videos for our product, I was convinced that I had no place in producing marketing material.

In both situations, I think that by admitting fault, I did the first thing correct. I passed a self reality check. Instead of ignoring the facts, I accepted that my performance wasn’t at the level that I expected of myself. It seems like this is the righteous decision to criticize ourselves for our shortcomings. After accepting such criticism I think there’s 2 ways where I go wrong handling this information.

1. I use the criticism as a dodge.
I think that a lot of time, self-criticism serves as a way of me avoiding doing something much harder. It seems odd, but I think it’s true that often it’s easier to call yourself fat rather than diet and exercise, easier to call yourself a poor programmer and logician, than to take the effort to get better.

2. I focus on the criticism instead of what I can do about it.
“I’m fat, and unattractive. I’m never going to meet anyone and have a family.” Why instead don’t we say “I’m fat, and unattractive. I think whenever I’m bored or anxious, I fall into the habit of eating pretzels. Maybe I can grab a water instead”
I read something from Eric Maisel a while ago about this. He suggests that whenever dealing with criticism, either self or external, is to state the facts, and then say “and ….” I spent a week generating a demo video, and it didn’t meet the standard of what our team expected and ….. while I realize that I failed this time, it was my first time doing such a thing, I learned that I need to focus on the higher level goal of the demo video rather than subtle details such as smooth transitions and voice overs. I realize that I need to produce a script that makes sense as the first step to generating a video. I realize that I need to let the script drive the actions instead of the actions drive the script.

The alternative to self criticism isn’t denial or wandering around in ignorance. Never would you say “I don’t make mistakes. I think for myself, the most effective alternative is stating the facts, feeling the bit of pain, then moving on to what I can do about it, and what I learned from the mistake.

BTW … I’m actually not fat and lazy ….. but I am a poor programmer … which is why I focus on breaking the software with internal tools ☺

Once the ActionMailer base class was all patched up, I was able to add both the envelope sender and the message sender headers to outgoing messages. For test purposes I used the following simple test method:

def test(mail_to, mail_from)
subject “My simple rails mail”
recipients mail_to
from mail_from
sent_on Time.now
sender ” Accounts <accounts@mydomain.com>” #envelope and message header for SPF check
end

In addition, engine yard added an spf record to allow our messages to pass spf authentication checks:

“v=spf1 include72emailsrvr.com include72_spf.ey01.engineyard.com ~all”

Unfortunately, the messages I was sending myself as tests, once delivered, did not include the message sender header. Checking the production log confirmed that messages leaving our application included the message header.

After some troubleshooting, I discovered that the exim servers were stripping off the message sender header, as the message was being sent out This was because exim doesn’t allow non-local users to set the header (at least this seems to be a hard rule according to the documentation I’ve read). So as a workaround, we’re using another smtp provider that allows us to authenticate in, and then send mail. This is working great.

Ie. In the ActionMailer configuration:

ActionMailer::Base.smtp_settings = {
:domain => “yourdomain.com”,
:perform_deliveries => true,
:address => ‘smtp.yoursmtpserver.com’,
:port => 587,
:authentication => :login,
:user_name => “mailuser@yoursmtpserver.com” ,
:password => yourpassword
}

After going through the process of generating a microsoft authenticode signing certificate (spc) using Thawte, I was already to incorporate code signing into our build process. One problem. Where is my .pvk file?

The private key is generated during the certificate request process. Thawte never actually has access to your private key (this is obviously a good thing and by design). Unfortunately I originally went through the reqest process from my Vista dev. machine. Due to restricted security permissions,

Vista not only saves the private key into the registry (I knew this before hand and was ok with it), but it also meens that the private key can not be exported from this machine.

Thawte has a known issue article about this, but I’d failed to read it before hand.

The work around … re-issuing the certificate, but this time, placing the re-issue request from our build machine where the pvk is easily exportable.

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.

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.

Perception and happiness is governed 10% by facts and 90% selection and presentation of these facts.

I was reminded of this by my godmother Millie in a late night phone call while feeling overworked and alone. Millie, always good for a picker upper, reminded me that you …. and only you … are in control of your happiness. While this is tough to believe for anyone who has been dealt life’s equivalent of a 2-7 off-suit ; I believe this to be true within reason.

Along this line of thought I’ve realized that life, happiness, and perception really is all about the projection of facts.

On one hand I could have written a Christmas card spinning a glamorous tale about my year in 2007 – how I bought a nice home and flipped a profit in under 6 months, was a founder in starting up a software company which achieved funding, moved into a hip and funky apartment in one of Seattle’s trendiest neighborhoods, traveled to Texas for consulting opportunities.

While on the other, I could focus on how I sold too late in the Edmonton housing market, how I miss family friends and loved ones in Edmonton and Canada, and how the kitchen sink in my apartment in Seattle continually gives me electrical shocks, how the bathtub continually backs up leaving me standing in a pool of my own filth when finishing a shower, and how the neighbors … F#$((# you Jennifer!!! …. Are incredibly loud.

Focusing on the positive, while at the same time neither remaining ignorant or improving on weakness … make it my resolution.

It’s been a bit of a battle getting fitnesse reports included in CruiseControl reports.

Here’s the outline of what I had to do:
1. Launch the fitnesse tests using the task in the cruise control project
2. Launch a batch file that translates the resultant fitnesse raw html file to a cruisecontrol readable xml file
3. Merge the xml file to the cruisecontrol log

Things that caused me some pain …
– For some reason the java class for creating the .xml file had to be launched using a batch file. I couldn’t get the class to load using task directly in the cruise control project
– I had to place the after the merge task within the publishers tag. When it was before, the resuts were not being merged in.

Still to do: The results are only appearing on the dashboard for the build. For some reason they are not being added to the email notification

Here’s my ccnet.config file added tasks

TestRunner.exe
C:\fitesse\dotnet
-results c:\fitnesse\results\FitNesse-Results.html localhost 81 SystTestScrub
60

FitnesseReport.bat
c:\fitnesse
60

c:\fitnesse\results\FitNesse-Results.xml

FitnesseReport.bat looks like the following:
cd c:\fitnesse
java -cp fitnesse.jar fitnesse.runner.FormattingOption C:\fitnesse\results\Fitnesse-Results.html xml c:\fitnesse\results\Fitnesse-Results.xml localhost 81 SystTestScrub

5. Black Friday

4. Watching someone getting their shoes shined

3. The I5 Freeway

2. The word “Galoshes”

1. Wasteful, noisy, fossil fuel consuming leaf blowers

1

Staring outside the bustling Seattle espresso shop watching the Loius Vuitton designer bags, the color co-ordinated scarves, the lights, the buskers playing christmas carols, I’m watching a 15 year old remove the seat of his bicycle, the front tire, and proceed to lock the bike to a no longer lonely light post.

It’s funny how now after so many years of being away I look back upon growing up in simple small town Gull Lake Saskatchewan with such fondness.

I can’t help but think of carelessly tossing my bmx bicycle to the curbside outside of freds trophies; unlocked and unattended for hours; as I went inside to spend my weekly allowance on Bubble Bobble, or whatever the trendy game of the day was.

After I’m done sipping on this Grande decaf Americano, I’ll wander on past Sonic Boom, the Peoples Pub, Mattador restaurant, and proceed to unlock the 3 locks that guard my bachelors apartment. Is it just me, or was it a daily occurrence to head off to Gull Lake High School along with my sister and mom, leaving the house completely unlocked for the whole day?

There are a couple compelling reasons to capture the self registration of COM components inside Windows installer tables instead of allowing windows installer to register the component through registration calls.

– It allows the installer to be more consistant and truly contain a pre-and post install snapshot of the system
– Allows the install / uninstall to be transactional
– And most importantly; allows the installer to install components per/user, so that non-admins can register components.

The most difficult part of this effort is to capture these registry settings so they can be added to the installer tables. WIX (the tool we are using with attassa/collabomatic) comes with a tool called Tallow. This receives .reg files as well as dll’s and derives the registration settings for the files in the form of wix fragment. This works great for dll’s but unfortunately it doesn’t work so hot for .exe COM servers.

For this, I use the following process (using regcap.exe from a dos prompt).

DOS: Regcap.exe /o component.reg component.exe

DOS: tallow.exe –reg component.reg > component.wxs

This produces the components fragment file that just requires a few touches before it’s merged into our main installer using light.