Considering it's Doppelgänger week on Facebook, I thought I'd mention that I have my very own Doppelgänger at work and his name is, well, Chris!
See, I share an office with another Chris. Yes, the jokes abound. Let's see, there's Chris 1 and Chris 1, Chris P and Chris T and Chris Squared.
It's actually kind of wierd because we implement practically all the same interfaces. People will come into our office and just say "Chris?" and then settle for whoever happens to answer first. Sometimes we just sit there silently the other Chris will be explicitly requested.
Sure, there are differences between us. He's been with the same company for 8 years while in the last 8 years I've been with, well, 8 companies! We take turns being the installer team lead. He usually has the helm when I leave to work elsewhere gladly giving it back to me when I return. What a friend... I think. :-)
Did I mention that he really gets it when it comes to setup and that he's joined the DeploymentEngineering.com blog team?
While he hasn't actually posted yet, I do know that he has an interesting story to write regarding his trip out to PDC last fall and a deployment focus group he attended.
Maybe if everyone says hello he'll actually get around to hitting the submit button.
Thursday, January 28, 2010
Monday, January 25, 2010
Still Hiring in Austin, TX
As I posted last summer, I'm still looking for experienced software engineers in the area of Install, Build and/or Internal Tools development.
Desired skills include InstallShield, MSI, WiX, BuildForge, ClearCase, TFS, C# .NET 3.5 ( Winforms, WPF, ASP.NET and Linq 2 XML).
There are several available roles with different emphasis on the above skills. In general, the engineer will be part of a Build/Install/Internal Tools team that currently consists of 11 members with additional on the way to meet our ever growing needs.
Please contact me at chrpai@deploymentengineering.com if you are interested.
Please note, due to customer requirements, all applicants must be a US citizen. Ability to obtain and maintain a US Security Clearance is required; an active clearance is highly desirable.
Desired skills include InstallShield, MSI, WiX, BuildForge, ClearCase, TFS, C# .NET 3.5 ( Winforms, WPF, ASP.NET and Linq 2 XML).
There are several available roles with different emphasis on the above skills. In general, the engineer will be part of a Build/Install/Internal Tools team that currently consists of 11 members with additional on the way to meet our ever growing needs.
Please contact me at chrpai@deploymentengineering.com if you are interested.
Please note, due to customer requirements, all applicants must be a US citizen. Ability to obtain and maintain a US Security Clearance is required; an active clearance is highly desirable.
Monday, January 4, 2010
Shared Resources Are Imaginary and Feature Gap Is Real
I was reading a blog post from Heath Stewart:
While it's an interesting read, albeit covering 10 year old concepts, I have a problem with the last little bit about "custom resources". Well, two problems:
1) Windows Installer doesn't expose the concept of "custom resources". This is entirely made up. Don't believe me? Then tell me how to mark a custom resource as the key-file for self repair checks? How do you involve the custom resource for costing purposes? Sure, you can write data driven custom actions that associate themselves conditionally to a component, but your out of process custom action will never really implement resources.
2) Why doesn't MSI already handle all these examples that are presented as "custom resources". Seriously, what (enterprise) application these days doesn't store data in XML or relational databases and/or present application layers as web apps or web ui? Wasn't Windows Installer intended to solve enterprise TCO issues?
Sorry, but the feature gap here is just mind boggling if you ask me.
Components are the basic unit of installation in a Windows Installer product. They are installed by one or more features, and can contain any number of resources including files, assemblies, registry values, and are recommended for custom resources as well. Examples of custom resources are web sites, virtual directories, SQL tables, and stored procedures.
While it's an interesting read, albeit covering 10 year old concepts, I have a problem with the last little bit about "custom resources". Well, two problems:
1) Windows Installer doesn't expose the concept of "custom resources". This is entirely made up. Don't believe me? Then tell me how to mark a custom resource as the key-file for self repair checks? How do you involve the custom resource for costing purposes? Sure, you can write data driven custom actions that associate themselves conditionally to a component, but your out of process custom action will never really implement resources.
2) Why doesn't MSI already handle all these examples that are presented as "custom resources". Seriously, what (enterprise) application these days doesn't store data in XML or relational databases and/or present application layers as web apps or web ui? Wasn't Windows Installer intended to solve enterprise TCO issues?
Sorry, but the feature gap here is just mind boggling if you ask me.
Subscribe to:
Posts (Atom)