Sinan at InstallAware has just posted an interesting read:
Viresh: Did He Make or Break InstallAware?
While some of it is questionable, if you have an interest in the behind the scenes opinions of this industry it's really worth reading the entire article. He goes into such topics as the war between Rob and InstallAware, the copying of the ZeroG website (along with an attack on Stefan Krueger ), what he really thinks about WiX and his own product WiXAware and behind the scenes poaching of InstallShield employees and alleged poor quality code they delivered to him
Interestingly he also claims that only he and Rob Mensching have innovated in the last year and leaves me out of his rant.
He also mentions not liking a strategy of having a very thin IDE on top of WiX. Funny, this is exactly where I'm trying to go with IsWiX. I think with the right investment and development staff I could make a really good go at it but I'm not crazy enough to try. This market is too saturated and mature in my opinion.
Historical archive 2003-2016
Thursday, February 17, 2011
Austin Networking
Sometimes I think it would be nice to have some sort of get together in the Austin area. I'm not sure what that would look like so I'm open to suggestions. I don't have corporate sponsors so there wouldn't be super cool swag although a few pizzas and/or Rudy's BBQ could probably happen.
So leave a comment or send me an email if you are interested. I'd be up for everything from a simple happy hour / social get together to a more traditional special interest group meeting. And of course if you ever just want to bend my ear privately for whatever reason I'm usually available for lunch.
Either way I'm very interested in getting to know more people in the Austin area.
So leave a comment or send me an email if you are interested. I'd be up for everything from a simple happy hour / social get together to a more traditional special interest group meeting. And of course if you ever just want to bend my ear privately for whatever reason I'm usually available for lunch.
Either way I'm very interested in getting to know more people in the Austin area.
Monday, February 14, 2011
Software Entropy
Recently, someone suggested to me ( putting it mildly ) that our build automation should ignore failed unit tests in order to get further down the process. I instinctively bristled at this notion. Later I decided to google the subject to see if anyone else in the world was actually entertaining such non-sense. There was an answer on StackOverflow that referenced a story from the Pragmatic Programmer called Software Entropy. It's an interesting story about the effects of Broken Windows on a building and what it means for software rot. (See Active Rot )
There's a few expressions I like to use: (Fair warning, these are cynical and/or sarcastic)
Every one of those things is a broken window and frankly, I don't allow broken windows. Unfortunately, that doesn't always make me a very popular person because developers are often quite self-convinced that their solution is acceptable.
So back to my initial comment about unit tests failing builds. For installs this is Windows Installer validation and I suggest custom ICE's to enforce quality standards. I suggest writing tests that enforce your coding standards. Don't allow selfReg? Write an ICE that checks the SelfReg table. Don't allow InstallUtil CA's? Write an ICE that scans for those. Allow only sanctioned DTF custom actions? Write a unit test that reads in a white list file and make sure only those custom actions exist.
Enforcing standards through automation is the best way to fight entropy that I know.
There's a few expressions I like to use: (Fair warning, these are cynical and/or sarcastic)
- Entropy is a bitch
- Once is an exception, twice is a pattern
- Death but a thousand cuts
- What's the problem with a little poo in the installer.
- Garbage In, Garbage Out
- Fix the installer and not the application. That's a great idea.
Every one of those things is a broken window and frankly, I don't allow broken windows. Unfortunately, that doesn't always make me a very popular person because developers are often quite self-convinced that their solution is acceptable.
So back to my initial comment about unit tests failing builds. For installs this is Windows Installer validation and I suggest custom ICE's to enforce quality standards. I suggest writing tests that enforce your coding standards. Don't allow selfReg? Write an ICE that checks the SelfReg table. Don't allow InstallUtil CA's? Write an ICE that scans for those. Allow only sanctioned DTF custom actions? Write a unit test that reads in a white list file and make sure only those custom actions exist.
Enforcing standards through automation is the best way to fight entropy that I know.
Saturday, February 12, 2011
the Build Maestro
In my last blog post I encouraged Nick Skitch to start blogging and today I noticed he now has the blog:
the Build Maestro
I'm not sure if my public dare worked or not ( it could be pure coincidence ) but let's welcome Nick none the less. Also, I've put him on my Daily Rounds.
Speaking of my "Daily Rounds", they are just that. There is absolutely nothing political or ideological about it. If there is a blog that contains subjects that are interesting to me, it will make my list. This is true regardless of whether or not I typically agree with the source.
Finally, there are no favorites when it comes to who gets listed first. It's really simple to stay on the top of my reading list: Post Often.
the Build Maestro
I'm not sure if my public dare worked or not ( it could be pure coincidence ) but let's welcome Nick none the less. Also, I've put him on my Daily Rounds.
Speaking of my "Daily Rounds", they are just that. There is absolutely nothing political or ideological about it. If there is a blog that contains subjects that are interesting to me, it will make my list. This is true regardless of whether or not I typically agree with the source.
Finally, there are no favorites when it comes to who gets listed first. It's really simple to stay on the top of my reading list: Post Often.
Friday, February 11, 2011
Motivational Feedback
Recently I've received some comments and emails ( reposted with permission ) from readers that I wanted to share.
The first comment is from Jerra who I first met on InstallShield Community. He had started a thread trying to come up with, well - interesting, ways via custom actions to get InstallShield 2010 LE to create services. This thread was actually in the inspiration for the article Augmenting InstallShield using Windows Installer XML - Windows Services in which Jerra left the following comment:
The next feedback came in an unsolicited email from Nick titled Shout out to Deployment Engineering Blog:
I hope Nick does in fact blogging. The setup world always has room for one more leader.
Update: Nick is now blogging.
The first comment is from Jerra who I first met on InstallShield Community. He had started a thread trying to come up with, well - interesting, ways via custom actions to get InstallShield 2010 LE to create services. This thread was actually in the inspiration for the article Augmenting InstallShield using Windows Installer XML - Windows Services in which Jerra left the following comment:
Absolutely fantastic! I just got the installation to work on my development machine (XP, VS2010 Professional, Wix 3.5, InstallShield 2011 Express). ... This is just great! I have read the articles you linked and checked a few more and have still more to read later. A new world is opening itself..I can't tell you how much it warms my heart to help someone come to this place. If Jerra could just get 5 people there and they get 5 people there, well just maybe the setup world would be a much better place.
OK so I understand now that using custom actions (CA) makes you go outside the "safe"/controlled environment of MSI and any changes to the system will not be included in the automatic
transactional/rollback sequences otherwise generated by the installer (if I got it right)? Apparently there are cases where CA's are legit but its best to really look for ways to do things inside within the installer.
The next feedback came in an unsolicited email from Nick titled Shout out to Deployment Engineering Blog:
You don't exactly know me, but I sure as heck know you. I've been following your blog and read everything back to the beginning. I just want to personally thank you for everything you do for the field. From your informational and entertaining blog posts to your nearly countless replies in the Installshield forum. It seems like every problem I search on, Chris Painter has a solution or can point you in the right direction.
I appreciate your innovative stance on embarrassing DTF in its infancy. You supported this technology rather than the inferior attempt at managed custom actions implemented by Installshield... at a time when senior engineers were 'pooing' on managed code for installers. Very brave and your reputation goes to show.
You are the rock star of this niche field ;)Aw shucks, thanks Nick. I was a little embarrassed re posting this but I think that I've taken so much grief over the years from people who try to discredit me in order to silence the dissent that it's important to take a moment and know that my reputation in fact remains intact.
I'm basically just writing you to express my gratitude and encouragement for you to continue what you're doing. It's a minefield out there. Man, is it crazy. I have so many stories that I think I'm going to start blogging about.
I hope Nick does in fact blogging. The setup world always has room for one more leader.
Update: Nick is now blogging.
Thursday, February 10, 2011
Opinion: InstallShield and Agile??
I few months back InstallShield posted the following:
I had a reaction the moment I read this but I wanted to pause a bit before I shared my thoughts. First a little background on my world view. From 1996 to 2005, I experienced that most developers don't want to touch installs with a 10' pole. Back in 2005-2006, I participated in an attempt to make developers responsible for setup development. It ended very, very, very poorly. It was so bad that I quit the company and moved on. For the next couple of years I would read blog posts from the likes of various MSFT employees talking about Agile in context of Setup Democratization and I would just bristle at the thought as I remember just how bad it had ended.
After a couple of years I returned to that company in 2008 and after 6 months or so I started down the path of attempting democratization again. This time around we had better tools, better strategies and slightly better attitudes from developers. You can read more about this attempt here. Things went well, very well.
Ok, back to InstallShield's assertion from above. First, I question how common it is for installation development to be a team sport. I'm guessing they have market research that I don't because in my experience very few people do this. Second, I really disagree that specialists aren't needed. Deployment engineering and MSI / InstallShield are domains that can really bite you if you don't have extensive training and experience. A specialist is required on small projects to ensure quality and on very large projects an architect with deployment experience is desirable. Someone has to be responsible for defining and enforcing the strategy while delegating the work.
Now InstallShield no doubt sees the Agile buzzword has an opportunity to, well, sell more licenses.
There are several problems with this in my opinion. First is the cost of InstallShield. $2000 a seat is one thing when you are talking about a specialized tool for a handful of developers but when you start scaling that out to include all kinds of things such as stand alone build licenses, floating licenses, collaboration and so on it's no unusual for a mid sized team to get quotes of nearly $100,000. That's crazy.
Second is DRM. It's crazy to drop that kind of money and then be treated like a criminal. Maybe I'm a little extra jaded on this one because our development networks aren't connected to the internet and activation is a really big pain for us.
Third is InstallShield's DTD XML project format does not support branching and merging in a meaningful way. When I designed IsWiX a lot of attention was paid to creating XML could easily be developed on multiple branches and then merged back together without conflict. We use multi site base Clear Case and this is a very big deal to us. A little while back I looked at the version tree of a .wxs file and I was part horrified as to just how many branches there were and part elated in the knowledge that through all this it had magically worked without any developers ever reporting any issues.
Finally InstallShield has too much of a learning curve. An ideal tool provides an easy button abstraction while allowing for under the cover tweaking off all the buttons and switches. With IsWiX and WiX I get this. With InstallShield and InstallShield Collaboration I don't.
Now this isn't to say that InstallShield doesn't have a part to play. Frankly, I couldn't easily do what I do today without at least a few licenses of InstallShield. Perhaps in very large shops like Microsoft you can justify creating extensive external UI's, bootstrappers and chainers such as seen in Microsoft Office and Visual Studio but that just isn't an option for many companies. Conversly, I couldn't easily do massively scaled Agile development without WiX and IsWiX either.
Collaborate during installation development – Installation development today is becoming more of a team sport where all developers can participate. There isn’t as much of a need for specialist in Agile development. You may have people that are more experienced in certain areas than others, of course, but in Agile everybody rolls up their sleeves and implements features. It also means all developers often participate in developing parts of the installer.
I had a reaction the moment I read this but I wanted to pause a bit before I shared my thoughts. First a little background on my world view. From 1996 to 2005, I experienced that most developers don't want to touch installs with a 10' pole. Back in 2005-2006, I participated in an attempt to make developers responsible for setup development. It ended very, very, very poorly. It was so bad that I quit the company and moved on. For the next couple of years I would read blog posts from the likes of various MSFT employees talking about Agile in context of Setup Democratization and I would just bristle at the thought as I remember just how bad it had ended.
After a couple of years I returned to that company in 2008 and after 6 months or so I started down the path of attempting democratization again. This time around we had better tools, better strategies and slightly better attitudes from developers. You can read more about this attempt here. Things went well, very well.
Ok, back to InstallShield's assertion from above. First, I question how common it is for installation development to be a team sport. I'm guessing they have market research that I don't because in my experience very few people do this. Second, I really disagree that specialists aren't needed. Deployment engineering and MSI / InstallShield are domains that can really bite you if you don't have extensive training and experience. A specialist is required on small projects to ensure quality and on very large projects an architect with deployment experience is desirable. Someone has to be responsible for defining and enforcing the strategy while delegating the work.
Now InstallShield no doubt sees the Agile buzzword has an opportunity to, well, sell more licenses.
There are several problems with this in my opinion. First is the cost of InstallShield. $2000 a seat is one thing when you are talking about a specialized tool for a handful of developers but when you start scaling that out to include all kinds of things such as stand alone build licenses, floating licenses, collaboration and so on it's no unusual for a mid sized team to get quotes of nearly $100,000. That's crazy.
Second is DRM. It's crazy to drop that kind of money and then be treated like a criminal. Maybe I'm a little extra jaded on this one because our development networks aren't connected to the internet and activation is a really big pain for us.
Third is InstallShield's DTD XML project format does not support branching and merging in a meaningful way. When I designed IsWiX a lot of attention was paid to creating XML could easily be developed on multiple branches and then merged back together without conflict. We use multi site base Clear Case and this is a very big deal to us. A little while back I looked at the version tree of a .wxs file and I was part horrified as to just how many branches there were and part elated in the knowledge that through all this it had magically worked without any developers ever reporting any issues.
Finally InstallShield has too much of a learning curve. An ideal tool provides an easy button abstraction while allowing for under the cover tweaking off all the buttons and switches. With IsWiX and WiX I get this. With InstallShield and InstallShield Collaboration I don't.
Now this isn't to say that InstallShield doesn't have a part to play. Frankly, I couldn't easily do what I do today without at least a few licenses of InstallShield. Perhaps in very large shops like Microsoft you can justify creating extensive external UI's, bootstrappers and chainers such as seen in Microsoft Office and Visual Studio but that just isn't an option for many companies. Conversly, I couldn't easily do massively scaled Agile development without WiX and IsWiX either.
Dealing with Slow Starting Windows Services
Every once in a while a question pops up about Windows Installer trying to start a service and if fails but that if the user starts it manually it works. The solution usually turns out to be related to solving some race condition either in terms of dependency or timing. I won't attempt to enumerate all of these today but I did want to draw attention to something I recently observed.
The Windows (NT) Service Control Manager ( SCM ) waits up to 30 seconds by default for a service to report that a pending operation is successful. There is a registry value called ServicesPipeTimeout that can be used to change this behavior to a longer time. In doing so though one must keep the following in mind:
So in conclusion, a setting exists but it won't help with the installer much unless all you need to do is set the service to automatic and ask for a reboot.
For C#/.NET junkies using the ServiceBase class, I'll offer an additional observation that thread.Sleep() calls in the OnStart() method exceeding the ServicesPipeTimeout threshold didn't seem to cause any problems. However placing the delay in the constructor or instance members in the class did cause a problem.
The Windows (NT) Service Control Manager ( SCM ) waits up to 30 seconds by default for a service to report that a pending operation is successful. There is a registry value called ServicesPipeTimeout that can be used to change this behavior to a longer time. In doing so though one must keep the following in mind:
- As with many things ServiceControlManager related, the ServicesPipeTimeout setting requires a reboot to become effective. It’ll offer no help if you are trying to start a service during the install.
- Even if it was effective right away, I’ve observed that when the MSI SDK says “max 30 seconds” it means 30 seconds max. Changing the ServicesPipeTimeout setting has no effect on the behavior of the StartServices standard action. ( A bug in my opinion. MSI should track with SCM in my opinion. )
So in conclusion, a setting exists but it won't help with the installer much unless all you need to do is set the service to automatic and ask for a reboot.
For C#/.NET junkies using the ServiceBase class, I'll offer an additional observation that thread.Sleep() calls in the OnStart() method exceeding the ServicesPipeTimeout threshold didn't seem to cause any problems. However placing the delay in the constructor or instance members in the class did cause a problem.
Subscribe to:
Posts (Atom)