Google Analytics

Friday, September 11, 2015

I'm going back to my GhostDoc post because I'm trying to set it up once again for myself after setting up a new dev. environment. I'm super-annoyed to see how horribly Blogger handled the XML Doc markup and annoyed at myself for not noticing it before.

I'd have to go back into the HTML view (and sift through how horribly Blogger creates its own markup) to add it all in correctly. I may just rewrite the article and make it available to download somewhere if people want. Or maybe I'll really try and go through and fix the markup.

Anyway, if you tried to use the post as reference before, I apologize and hope that maybe you found some things useful, even if the format of the XML sucked.

Thursday, August 27, 2015

Some Assembly Required

I thought I would post this answer out there to hopefully save some people the hassle I just had in trying to troubleshoot a "Could not load file or assembly" error, for in my particular case I have not seen the same solution posted out there yet.

My case is this - I was getting an error trying to open a locally installed web service. The "warning" (though it really should show as an error, imho) showing up in my event log was this:

Could not load file or assembly 'System.Data.SQLite' or one of its dependencies. An attempt was made to load a program with an incorrect format.

The "incorrect format" part usually has to do with having an x86 version of the DLL in question rather than an x64 version, and SQLite is one of those where it has a different library for each platform. I had installed the x64 version of the service, so I checked that it was also installing the x64 version of the SQLite DLL, which it was. I was perplexed. Everything I was Googling made me think that somehow it was loading up the 32-bit version somehow. Finally I had my aha moment.

A couple days back, while trying to build and run this same service, the configuration was such that only the 32-bit version of the service would build. So, at the time, I changed the Application Pool that it ran under to allow 32-bit applications. That changes the Application Pool to use WoW64, the Windows 32-bit emulator. So, the Application Pool thought it needed the x86 SQLite DLL. Once I changed the Application Pool to not allow 32-bit applications everything ran smoothly once again.

Thursday, June 11, 2015

Rambling About Scrum, pt 1

I started this post a while back, meaning a couple weeks ago. I started it for the reasons I start any blog post, because I had both a flicker of inspiration and a few minutes to begin writing something. I realized after a while that I was sort of rambling, another good attribute of my blog posts. So instead of going on rambling I thought maybe I should begin breaking this into little doses, so that it is apparent that I'm just rambling. And now I'm rambling, so without further ado, part one on my thoughts bout applying Ssrum outside of the domain of software development:

So I'm already about halfway through my friend Jared's book dealing with sports psychology. I had said to him that I was looking to mine it for ideas for helping me as a ScrumMaster considering that a ScrumMaster is a sort of coach. We certainly coach teams, especially new team members in the Scrum process. We deal with monitoring the team performance and trying to find ways to improve. ScrumMasters help motivate and focus the development team. Finally, we shield them from negative outside influences that would detract from the team performance. So, there are ways where being a ScrumMaster is very much like being the coach of an athletic team, though I said previously that it may be a little more like coaching a golf team than a football team. (Of course, as I'll point out, a Scrum team is like a rugby team in more ways than one.)

Well, Jared turned the question back on me, saying he'd like to learn more about Scrum to see how it might apply to what he does in regards to sports psychology. I thought about that. How would I describe Scrum to someone completely outside the domain of where we use it? That idea certainly isn't foreign to anyone who has practiced Scrum for any length time: You need to get business managers and executives to buy into Scrum or Agile practices at least, you need to sometimes guide product owners in why it works, and there are sometimes when you need to explain it to the customer directly. Still, while they are all stakeholders in the process, besides the product owner they really only need as much understanding as needed to let the dev. team do its thing. Customers, upper management, they aren't really "practicing Scrum" (unless you are lucky). So where does one start to get relatively good understanding from someone outside the domain of software programming?

First off, I'll say as an aside, that if you are a business person interested in how Scrum can affect business practices, you are really better off looking into Lean practices. The Lean software development practice was adopted from the Lean manufacturing process which was built from the Toyota Production System. Frankly, I don't know Lean near as well as I know Scrum. Maybe someday I'll learn enough to feel comfortable writing a blog post about it.

While Jared writes from the point-of-view of practicing, playing, and coaching football, I work in the domain of voting machines and elections software. So that's where some of my examples will come from.

Any discussion of Scrum needs to start with a discussion of Agile methodologies. "Agile" has become such a buzzword in software development, and it's one that like many buzzwords, few people really understand before they bandy it about. Software development is a very, very recent and evolving practice. If you think about it, man has been building houses since he first moved out of the caves. The art of architecture is at least older than the Great Pyramids. The art of creating software is not so old, so new rules and practices are always being tried. Well, some years back, a bunch of programmers got together and (I like to think) had a bunch of pitchers of beer trying to solve all the problems inherent in this nascent practice and came up with a manifesto, the Agile Manifesto for Software Development:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. 
Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas 
© 2001, the above authorsThis declaration may be freely copied in any form, but only in its entirety through this notice.

To me an Agile software development methodology is one that values those things on the left sides of the statement over those on the right. That leaves a lot of room for interpretation on just how to accomplish that, but it also means that just saying that your team embraces responding to change doesn't make it an Agile team. There are three other lines in that manifesto. Certainly those values aren't only valuable to software development, and could easily be applied to other types of business. So I want to highlight in this discussion those areas where Agile practices and Scrum in particular could be generalized.

Thursday, May 28, 2015

A Great Day to Run it Again!

Just had to buy an old friend and classmate's book after finally checking it out. It's been on my list of things to do. It's a sports psychology book by Dr. Jared Wood. (Doctor! Lord Jesus, help us all, Jared Wood is a doctor!) I bought it hoping that it may give me a few ideas in my own job. A ScrumMaster is a coach of sorts for a software development team. It's pretty unlike coaching a football team, maybe the furthest thing from while still being able to refer to oneself as a coach. Maybe more like coaching a golf team. But just in Jared's blog I saw enough similarity to think his book may help.

The stories Jared tells about high school football bring back a ton of memories. I have recurring dreams about high school football. It was one thing I just wasn't very good at, and I desperately wanted to be. To tell the truth, at the time, I desperately wanted to be good at everything. My friends, though, the kids I grew up with, my pals, were good at football. Jared, Ryan, Chad, Ryan (a different Ryan), Eric, Terry, Bill, did I mention Ryan? They did other things in the offseason - maybe basketball, maybe baseball, but football was all-important at Frankenmuth High. That's a slight exaggeration; it wasn't all-important... but really pretty damn important.

And truthfully, it wasn't so much the sport itself that was so important. For me, it was being with my friends that was important. Yes, Mom, if my friends jumped off a bridge I would probably do it too. I wanted to be just like them, which meant playing football. Genetics conspired against me mostly. I think I was still 5'4" at the end of my sophomore year, adding a whole 3 inches over the next year, and I was still the smallest guy on the varsity team. Also, truth is, as competitive a person as I am, I'm not so much competitive with other people; I was competitive with myself. I was okay with losing as long as I "did my best" as my mother would say. I wanted to set PR's with running. I was never going to be the biggest, fastest, or best athletically, but as long as I was better each day, I was... okay with it. Jared, on the other hand, hated to lose. When I hear about those great athletes like Michael Jordan and Tiger Woods who don't so much like winning as they just hate to lose, I think of Jared. I don't think he took pleasure in winning so much as it was a relief.

I guess I've come to experience that same feeling over time. There are times in some competition where you simply know you are better than your opponent. You know that the only way to lose is by beating yourself. That's when winning comes as a relief. Nowadays, I mostly only ever get to feel this directly while beating some poor souls at a trivia game. Still there is the indirect experience of rooting for the Broncos and the wash of relief as we pound the Raiders into oblivion again. (I'm sorry that my Lions fan friends cannot enjoy this. Every win is a God-damned celebration for you.) 

In his last post, Jared tells this story of Coach Munger, our high school football coach, yelling "Run it again!" at practice.... Over and over he'd yell it. Mind you, Coach Munger would yell this in a game. If we ran "sweep-right" and someone missed their block he'd go halfway out on the field and scream, "Run it again!" for us to hear, the opposing team to hear, the fans and all the rest of the world to hear. And we would, and we'd run it better. 

So at one practice we're running this play where the wing in the formation, normally lined up outside the tight end, is lined up off the line between the the tight end and tackle. His job is to come through the line and wipe out the inside linebacker with a block while the ball gets handed to the fullback, Jared in this case, on a dive following right behind the wing. I played back-up safety so I was the safety on the scout team. On this particular play when the inside linebacker gets wiped out, I'm supposed to fill in behind and tackle the ball carrier. Well Jared may have had seventy pounds on me at that time (not to mention Jared was also probably the only person on the team faster than I was), so the first time we run it, he just steamrolls me. 

For some reason, Jared turning me to pudding on the practice field isn't good enough for Coach. "Run it again!" he yells. Same play, linebacker wiped out, I fill in, and Jared goes over me like a Mack truck. From my vantage point on my back on the practice field  staring up into a slate gray, autumn Midwestern sky I can't tell what nit Coach has to pick with his first team offense, but I hear him yell, "Again!" So I haul my body up off the ground, cursing a bit under my breath and get ready for superstar fullback to come through again. This time, as he blows me up I grab some jersey or pad and hang on for dear life, eventually dragging him down twenty yards past the line. Coach is already yelling, "Run. IT. Again," as we are picking ourselves up. "Sorry, man," Jared mutters to me. Right then, I wanted to just say to him, "Fuck you. I don't want you to feel sorry for me. I want to knock you 'ass-over-tea kettle'," (as the coaches would say). I don't know what I actually said, but I know we ran it a couple more times because I remember being pretty steamed that he apologized to me. I'd love to say being angry made a difference; I'm pretty sure I thought it did at the time and that I was better at least at absorbing the impact. 

Then like every other person who has played the game, you realize that you won't ever play it again. I'd love to go back. Even to be as small as I was then, I'd love to have one more season or one more game. One more practice with those guys or even one more play, as a backup safety waiting for the fullback, Doctor Wood, to come barreling through that line, because this time it would be different.

(You can get Jared's book for yourself at his site. I'm only through the first couple chapters, but I know I will have much more to say about this as it pertains to Scrum and coaching.)

Wednesday, January 21, 2015

Moby-Dick, or The Book

I finished reading Moby Dick last night. I don't know how long the voyage of the Pequod was, but I'm certain it was nowhere near as long as it took me to read the book. I added it to my Goodreads account five years ago. I'm not sure if I added it because I had started reading it, or because I wanted to. Regardless, it's been a long, long time since I started that book.

Recently I became more and more adamant on completing my quest. I was three-quarters through that book and the eponymous whale hadn't even made an appearance yet! I was beginning to become more and more suspicious that the whale NEVER shows up, and that only two people ever had gotten to the end of the book where Melville writes, "Shhh! Let's have a big laugh at everyone and never let them know that Moby Dick doesn't actually appear in the book."

I think I wavered between Ahab's determination to finally confront the Leviathan and Starbuck's insistence that they just pack up and go home. On and on I read. 92% done my Kindle said. 93%... 94%, and this exhaustion came over me. A very real exhaustion. My eyes were burning, and I couldn't make any sense of what Melville was writing anymore. The words, difficult enough to understand when I was lucid, were becoming a mangled pudding in my head. I slumped off to bed, and my headrush literally brought me to my knees before I could make it there.

I had a short nap but was then awakened by Buck, our little pip of a dog. Maybe he was nervous because Jen had left and he felt alone, but maybe he was telling me I had to finish before all momentum was lost. I picked that Kindle up again, raised sail once again if you will, and plowed on just as the Pequod plows forth to its fate.

I won't tell you how it ends. Maybe the whale makes an appearance. Maybe he is never seen. Is the whale the devil? Is Ahab? Maybe Melville himself is. Was it worth it? "Hours of entertainment," I told Jen. "For free."

Monday, January 19, 2015

Creating a Local Windows Group on Install

One of the recent Installer/Wix issues that needed to be addressed in our product was to automatically create a Windows group on install. Our installer creates and starts a number of Windows services that are run as a particular user with the appropriate permissions. Currently, whomever is installing the product must create the local group, create the user account to run the services and add the user to the local group before running our installer. In order to count down on the tasks the user must do manually, we added a story to both create the local group and user on install, and I first took to doing a spike solution to create the group.

Doing a spike allowed me to isolate the action needed to just creating the group. Our installer is currently made up of several Wix libraries, approximately a dozen Wix source files, and a number of custom actions. I wasn't confident about finding just the right place to add the group before I even understood how to do it. Also, the spike allowed me to quickly run the install and uninstall without going through all the other actions our current installer does.

My hope was that I could do it fairly simply with Wix or with the Wix Utilities extension. The utilities extension does provide a group element; however, "This element is not capable of creating new groups but can be used to add new or existing users to an existing group." Luckily a Google search indicated that someone had already done the work to create the necessary custom actions to do this. Msiext (http://dblock.github.io/msiext/) contains a UserPrivileges extension along with a number of other Wix extensions which I wish I had known about before. The download includes runnable demos, but there isn't much in the way of documentation. Ergo, I'm writing this blog post rather than simply pointing you to some documentation there.

So I got the latest msiext download. I created a console app as my spike and added a Wix Setup project to the solution. To the setup project I added a reference to the WixUserPrivilegesExtension DLL in the msiext package. This gives access to the LocalGroup element:

<UserPrivileges:LocalGroup Id="DemoLocalGroup1" Name="DemoLocalGroup1"
Description="Demo local group 1 for a spike." CheckIfExists="yes"
CreateOnInstall="yes" DeleteOnUnInstall="yes">
</UserPrivileges:LocalGroup>

The explanation is pretty straight-forward. the Id is the unique element id, Name is the name of the group and description is what appears in the description when you Manage Groups in Windows. CheckIfExists will prevent it from re-creating the group if the group already exists. CreateOnInstall creates the group on install and DeleteOnUnInstall will delete the group on uninstall. These can be changed if, for example your application creates the groups itself and all you want to do is delete it on uninstall, or if you want to leave the group unchanged even if the user chooses to uninstall. Like I said, pretty straight-forward.

My entire Product.wxs looks like so:


xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
     xmlns:UserPrivileges="http://schemas.appsecinc.com/wix/UserPrivilegesExtension">
    <Product Id="*" Name="SetupProject1" Language="1033" Version="1.0.0.0" Manufacturer="PlutoTech" UpgradeCode="5eec8bc9-ee30-451b-b3c2-fd4ce78bf277">
        <Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
        <MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
        <MediaTemplate />
        <Feature Id="ProductFeature" Title="SetupProject1" Level="1">
            <ComponentGroupRef Id="ProductComponents" />
        </Feature>
    </Product>

    <Fragment>
        <Directory Id="TARGETDIR" Name="SourceDir">
            <Directory Id="ProgramFilesFolder">
                <Directory Id="INSTALLFOLDER" Name="SetupProject1" />
            </Directory>
        </Directory>
    </Fragment>
 
    <Fragment>
        <ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
            <Component Id="LocalUserGroupDemo1" Guid="YOUR-GUID-HERE">
                <UserPrivileges:LocalGroup Id="DemoLocalGroup1" Name="DemoLocalGroup1"
                    Description="Demo local group 1 for a spike." CheckIfExists="yes"
                    CreateOnInstall="yes" DeleteOnUnInstall="yes">
                </UserPrivileges:LocalGroup>
                <File Id="File.MyService" KeyPath="yes" Source="$(var.AddLocalGroupSpike.TargetPath)" />
            </Component>
        </ComponentGroup>
    </Fragment>
</Wix>

Note that the INSTALLFOLDER cannot be the keypath for the component. In this case it is actually the executable, Id="File.MyService. In our actual installer, the component that creates the necessary groups is separate from any other files, but the component group it belongs to is associated with the TARGETDIR directory.

Thursday, January 15, 2015

Keystone XL

I'm hoping I can weigh in on the Keystone pipeline before Obama vetoes the bi-partisan bill authorizing its construction. This is one of those political issues that I think highlight how dysfunctional our federal government has become. The stance of Congress, mostly on the right side of the aisle with a couple handsful of supporters on the left, is that the Keystone XL pipeline, an offshoot, a shortcut, if you will, of the rest of Keystone that has already been built would make it easier to get oil down from Alberta, Canada, to the refineries on the U.S. gulf coast. The majority of Democrats, following the lead of the White House, believe that more time is necessary to study the environmental and economic effects of the pipeline before authorizing its construction. Note, no one is saying it should NEVER be built, only that we need to take more time to examine the impact of building it.

First, let's get one thing right out of the way: the Republican argument that it will create 42,000 jobs. That's the figure thrown out there all the time by those on the right. It isn't a made-up one, but the report they are citing says that money spent on the the pipeline would help sustain 42,000 jobs. In the short-term it would create about 4000 construction jobs. Other jobs would be created both directly and indirectly by the construction, but not 42,000. Some of those jobs involved actually already exist, are filled, and are being paid today. So, while I'm sure that while locally it will help economies where it is being built, the construction isn't really going to have a big impact on the national job market. That was just a nice story for Republicans to throw out there when unemployment was so high.

I certainly wouldn't dispute that there are environmental issues at play with the construction of Keystone XL. However, assessments of its impact have been going on for five years now. The government itself published its "Final Supplemental Environmental Impact Statement" this time last year. Note the terms Final and Supplemental. It's supplemental because the government wasn't happy with the assessment created by a third-party that they allowed the owner of the pipeline to commission, which said that no significant environmental impact would occur. Guess what the government's independent assessment stated. That's right, that the pipeline and construction of the pipeline would have no significant environmental impact. Well, there was money well-spent. And how can the president insist that more study is needed when they've been holding on to the "Final" impact assessment for a year now?

In fact, Obama himself fast-tracked the construction of phase 3 of the pipeline in 2012. (The XL extension is phase 4). He made a big proclamation to the people of Oklahoma how he was going to cut through the bureaucratic red tape to get that phase built. We already have hundreds of thousands of miles of pipeline criss-crossing the U.S. It isn't the pipeline nor its construction that is really at issue in regards to the environment. It is oil sands.

Oil sand, as the name suggests, is oily (really bituminous) sand. Like its stony shale cousin, only recently has the technology made it profitable to try and extract oil from. The extraction of it is more akin to strip-mining with pits and tailings, than it is to an oil well. Also, it burns with higher carbon emissions than lighter crude oil, but much less than those given off by burning coal. Environmentalists real concern is that the pipeline will give easier access to Alberta's oil sands reserves and expand its extraction.

Two things about this: 1) Canada has been expanding the oil sands extraction regardless of access to the pipeline. That has been driven by the high price of oil and better and better technology. With the oil price plummeting, extraction may not increase, but you can bet, at some point, that oil is going to come out of that ground. 2) Currently those gulf coast refineries already refine oil from oil sands, only that oil comes from Venezuela. Venezuela is one of the largest exporters of crude oil in the world. Their government is also a repressive, socialist one that has consistently labeled capitalism and the U.S. specifically as its great enemy. The U.S. imports about 300 million barrels of crude oil annually from Venezuela. Even with today's price, that's $15 billion U.S. dollars flowing to Venezuela annually. Why would we want that money going to Venezuela instead of Canada?

Finally, as I said before, that oil is going to come out of the ground in Alberta one way or another. They are still expanding their operations up there. How does that oil get to the refinery now?, you might ask. Because it IS still going to refineries. The answer is by trucks and trains. Go ahead and Google "train derailments". Go ahead and Google "Lac-Mégantic". Tell me that moving that oil by train is somehow safer than by pipeline. I don't even need to start on truck accidents. We had one here just north of Brighton, carrying diesel rather than crude, that closed the interstate yesterday. What emits more carbon into the air, pumping oil through a pipe or moving it by truck or train?

This is federal government bullshit on both sides. Okay there's some job impact but not significant enough to say that the pipeline is definitely in the national interest. There is some environmental impact but not enough to say it isn't in the national interest. This issue is simply a political card that the two sides are wielding against each other. I, like most other Americans according to polls, believe the pipeline should be built. Yes, we have low gas prices now, but the market will adjust. When prices go back up, we'll be bemoaning the fact that Alberta is sitting on a ton of crude they can't move fast enough. However, whether it makes sense or not, let's stop with the bullshit coming out of Washington.

Sunday, January 4, 2015

RIP Stuart Scott

Honestly, I never thought I'd shed a tear over the passing of Stuart Scott. I'll admit that I wasn't the biggest fan of him as a Sportscaster. Initially I thought that Boo-yah and all the other catch-phrases were sort of gimicky. I just wanted the sports scores. I didn't need SportsCenter to be entertaining. As a young white kid used to the vanilla delivery of the sports report each night and then each morning with the advent of ESPN, I found Scott's delivery to be uppity. There, I said it. Yes, UPPITY. Subtle racism that I didn't recognize at the time, but it amounted to this black man coming into a white man's world and overturning the apple cart. Thank God he did. Sportscasting has never been, and will never be, the same again.

There is one fewer innovator in the world this morning. Scott brought real soul, soul in the most African-American, hip-hop, barbershop, gospel choir sense of the word, to the mayonnaise on white bread world of Bristol, Connecticut's ESPN, and he did it unabashedly and without compromise. (Can I get an Amen?) He changed how every sportscaster would deliver the news, black or white. I'm paraphrasing, but one of the more insightful comments I read about Scott this morning was from one of his white colleagues (it escapes me just which one) saying that Scott came in and was just himself, a rather brash black man, and that gave everyone else the permission to just be themselves as well.

More recently, while I appreciated what he had contributed to his profession, I felt that he had grown a bit long in the tooth for his "cool as the other side of the pillow" persona. I remember though after his eye injury, someone taking a shot at him on social media about it and thinking, Really? Here's this big brash persona who puts himself in the public eye (still completely unabashed), is very good at what he does, and yet has plenty to criticize, and you want to take a shot at his appearance? And it was with great sorrow that I heard of his cancer diagnosis. Having lost loved ones to cancer, it isn't something I would wish on anyone.

I started following Stuart Scott on Twitter. It was then that I really began to admire him. Here was a man who was facing a devastating illness with such a quiet dignity. On Twitter he told of the doctor visits, the treatments, but never with any complaint. His concern was more for the young cancer patients he saw. He was always optimistic, always a warrior attitude toward the fight ahead. And still his timeline was mostly about sports and his children. On air, other than his increasingly thinner appearance, you'd never know anything about his fight with cancer. I was impressed to see him on air so soon after what I'm sure was some exhausting round of radiation. A professional. Cal Ripken and Lou Gehrig rolled up into one.

Today's news is further proof that cancer is a bitch. It doesn't care how optimistic you are, or how much of a fighter. I mean, those traits are certainly healthier for you in a fight with cancer than resignation. I just mean, that I've seen the most optimistic, courageous people lose to cancer. It's more proof that the fight cannot be left to those who have the disease or their immediate circles. The fight against cancer belongs to all of us. This world was a better one with Stuart Scott in it.