Wednesday, January 18, 2012

SOPA, PROTECT-IP, and Legislative Position Statements

At the end of December 2011, I wrote to my federal representatives regarding my opposition to SOPA (US House) and PROTECT-IP (US Senate) legislation that portends to reduce piracy and theft of intellectual property.


Today, many websites are protesting these bills. Wikipedia and others have decided to shut down for the day (or part of the day).  Google and others have decided to alter their homepages.

I encourage you to view the legislation via the links above for a Wikipedia summary, then follow the 'External Links' to the text of the bill and develop your own opinions.  If you wish to oppose it, Google has a petition online that you can sign.  In either case, you should also write your representatives directly.  Hopefully, you will get a useful response.

Senator Toomey (R-PA) only responded to me with a confirmation that the legislation does, in fact, exist.  I did make specific references to provisions in the bill, so it is obvious that I already knew this. A follow-up did not result in an actual reply regarding the Senator's thoughts on this bill.  Senator Casey (D-PA) and Representative Altmire (D-PA) both failed to respond to my email.  I only give minor props to Toomey for responding at all, however, all three of my representatives get failing grades for their lack of adequate response.  

Even if my representative has opposing viewpoints or is projecting a vote contrary to my opinion, I believe it is their responsibility to have and disseminate intelligent position statements on each piece of legislation pending in their chamber and inside any committee that they are a member of.  An intelligent position statement is one that is published within 48 hours of the bill successfully leaving the committee and would include all of the following elements:
  • A link to the full text of the bill, including chronological history of successful amendments with time stamps.
  • If the vote were held today, based on version at timestamp ???, I would vote (yea/nay/uncommitted)
  • In the words of the representative, a summary of the intention of the bill.
  • List of elements that the representative supports and believes critical to the success of the bill.
  • List of elements that the representative opposes.
  • List of elements that require additional flushing out or personal research.  This list would be required if 'uncommitted'.
  • List of bills pending in committee or in the queue for a floor vote that portend to address the same concerns.
  • List of existing legislation on this topic and established case law that covers (or fails to cover) the subject matter of the new bill.
  • Media reports, studies, corporate statements, lobbyist groups, etc. that advocate for the need of the new law.
Update 1/18/2012: Sen Toomey released a statement that he does not support SOPA or PROTECTIP "in their current forms", yet he fails to make any statement as to what specific portions of it he takes issue with.  This statement is clouded in doublespeak.  Please keep the pressure up to get him to explain his position.

Tuesday, March 15, 2011

Wix, Votive, and Semicolons...

If you are using the Wix in Visual Studio (known as 'Votive') and need to set one or more preprocessor variables, it is rather simple. If you right-click on the Wix project, select 'Properties', then the 'Build' tab, you simply populate the 'Define preprocessor variables:' text box like so:

Name1=Value1;Name2=Value2
If you are using MSBuild, or editing the .wixproj file itself, this translates to the contents of the 'DefineConstants' element, which is where Votive stores what you put in that text box.

Things, however, are not really clear (or documented) if you need to set Name1 in the example above equal to a semicolon delimited list - for example "one;two;three" - so lets try it this way:
Name1=one;two;three;Name2=Value2
Candle.exe is passed (which is obviously incorrect based on our intentions):
-dName1=one -dtwo -dthree -dName2=Value2
The solution is NOT to put quotes around the list (my first guess), but to replace the semicolons that break up the list (and only the ones in the list) with '%3b', like so:
Name1=one%3btwo%3bthree;Name2=Value2

Candle.exe is now correctly passed:
-dName1=one;two;three -dName2=Value2
I do not know if this is way you would handle this situation in anything newer than Wix 3.0 - I haven't updated to 3.5 yet.

Friday, March 04, 2011

Electric Power Generation Choice in Pennsylvania

This post is centered around the deregulation of electricity generation in Pennsylvania, why you get to shop for an electricity generator (the history lesson), the factors to consider (the practical lesson), and ultimately how to save real money (the lesson in pragmatism).  I'm sure that the general advice applies to other states that have started 'deregulation' of the electricity market.

Let me provide some quick background on the process by which electricity gets to your home.  There is, of course, a power plant that makes electricity - this is called a 'generator'. There are several 'generators' that are connected with each other at multiple points - this is known as the power 'grid'.  The purpose of the grid is to assure service in the event that one or more of these 'generators' is turned off or disconnected that power can still be supplied from other generators.  It made sense for generators on many levels to interconnect with other generators owned by different companies into the same grid.  Meters indicating how much power each generator supplied into the grid allowed for proper bookkeeping.  Then you have the 'transmission and distribution' part - which is the lines connecting the generators to the grid, and the grid to your home and meter how much power is consumed.  This is a very simple model of something much more complex.

The way electric power was implemented, one company was responsible for dealing with all parts of the process - even if the company that billed you had no actual generation capabilities.  You were charged one rate based on how much power you consumed.  These companies are a 'natural monopoly' - mostly because it doesn't make sense, economically, to run multiple power lines from several companies in parallel. Because of this competition does not exist.  This is a similar situation to gas and water companies today.  Over a decade ago cable and telephone companies were in the same boat, but technology advanced to the point that both wiring systems can carry signals that allow for a limited amount of competition.

In 1997, a PA state law "Electricity Generation Choice and Competition Act" was passed (Regulations covering this law at 52 Pa. Code § 54 - pdf).  The links provided are to the text of the current law and rules and regulations pertaining to it, as amended.  The intent of the law was to deregulate the electricity generation market.  Since any generator in close physical proximity to a consumer can apply power to the grid, and the amount each one applies can be controlled, why should the consumer be stuck with buying power from one specific generator?  The direct impact of the law to the consumer consists of a few major points: (1) The costs of generating power were separated from the costs of delivering the power from the grid and itemized on your bill.  (2) All of these rates were temporarily capped and tightly controlled, until (3) These caps expired on Dec. 31, 2010. The very first part of the law, Declaration of policy, describing its complete intent, is a good read that is easy to understand.

The law attempted to take into account consumer protections and industry protections during the transition period to an unregulated market. If we look at the old regulated market, the supplier either engaged in long term contracts with a generator or generated the power themselves.  Unless you (the consumer) were willing to build your own power grid, you were at the mercy of their business decisions. These decisions were based on the monopolistic system of the time, industrial/residential growth projections, understated nuclear power costs and growth, and should be viewed in that light. Some were good, some not so good.  The not-so-good decisions resulted in what was called 'stranded costs' in that if the market was opened up and the utilities were forced to sell power for their cost of generation no one would buy power at that price.  After the law took effect, the generators were able to recoup these 'stranded costs' but under a capped price system - essentially meant to prepare the generators to compete in a free market. A whole book could be written explaining the theory of how this works. In the end, it sort of worked out - the 2008 national cost of electricity was 9.83 cents per kWh and PA was 9.60 so the 'capped' numbers were not far off in the end.

What the law didn't take into consideration is that deregulation does not and can not do anything for supply capacity and demand in this particular market. There has been very little supply capacity added to the market since the death of domestic nuclear power.  This law did nothing to make it easier to add generating capacity. Government projections show little growth in capacity. Power generated by your former monopolistic provider can now be sold to other distributors both in and out of state at competitive rates further reducing local supply by filling demand elsewhere.

Electricity, like oil, is a 'source unknown' commodity.  An electron is an electron regardless if it came from solar, wind, oil, coal, gas, or some guy on a treadmill.  The true difficulty in the marketplace now is figuring out who owes whom what... The whole concept of the electric grid is that it gets fed (hopefully) at the same rate it is drained - figuring out who owes who for the times you over or underfed the grid sounds like an added task  (and challenge) for your local utility.

By making your selection of generator, you are telling your utility to buy the same number of kWh that you use from the generator you selected at the price you are contracted for.  There are several selection criteria that you may want to consider aside from the current price: (1) Environmental reasons such as how that generator produces power, (2) Rate terms - how long you wish to 'lock in' a specific rate, (3) Usage patterns - can you or are you willing to juggle your energy use to minimize peak load or consumption based on time of day.  Make sure the 'price to compare' you are quoted from various suppliers includes all fees and taxes. The Gross Receipts tax is complex to calculate yourself if not included, and a really stupid tax for more than just that reason.

Environmental concerns is a tough one to compare.  If this is a concern for you I'd suggest rating each generator on a four star system based on their byproducts of generation (coal, gas, oil, nuclear, or renewable) and your personal belief system. I'd personally favor nuclear and renewable equally - but to each his or her own. This information is difficult to obtain from most providers.  Be aware that at times your generator may need to buy extra power on the spot market - exactly how much and from whom and how are all something to concern yourself with.  They could 'trade' power (best) by taking some extra now and paying it back when production peaks - wind and solar is very inconsistent.  They could buy on the spot market for demand peaks (medium). They could be oversubscribed (bad) where they are never producing as much as their customers are buying so a portion of the 'clean' energy you are purchasing is really quite dirty but you are paying much more for it - if those profits are 100% dedicated to expanding their production capabilities and are NOT considered profit then that may be OK.  Environmentally sensitive folks are likely better off conserving and selecting the cheapest provider while investing the difference in for-profit companies researching commercially viable clean energy production.  Funneling money into the current non-viable technologies only slows the progress in developing truly groundbreaking and cost-effective solutions that will truly benefit us all. If you really do the math on what goes into manufacturing (inputs and byproducts) and transporting solar, wind, and battery systems required to support them and amortize that environmental cost over its lifespan they are not as attractive as many believe them to be compared with other options - especially modern nuclear technologies with near-zero waste.

Some suppliers have a contract term where the rate is held constant for a period of 1, 2, or 3 years. These providers may or may not have incentives for signing (gift card, airline miles, etc.) and termination fees if you quit early.  Be sure to add in the costs and benefits from those deals as well in your calculations.  Should you do a 3 year lock in?  The government is predicting generation prices drop from current levels and bottom out in 2012 then begins to rise again, yet historical price data shows steady climb in the 'real' column so you can bet either way here.

There are other ways that you can change your usage behaviors to save more money. Can you go to load based pricing to save money (running dryer, dishwasher, A/C, and stove/oven at separate times to minimize the simultaneous current draw)?  Is there a time based rate plan where you concentrate your power use to off-peak times and pay less for it?

All that stuff mentioned above is rather difficult for the average person to understand and digest.  What happens if you DON'T choose a specific generator? If you don't you will be the sucker that will end up subsidizing the prices that allows your default generator to sell power cheaper to other utilities.  The 'default' generator is assigned based on contract with your utility - when your contract expires with your current generator, they close or get shut down, or you go into financial default you get that one.  There is no incentive for them to charge the lowest rates, since a good number of people won't choose and they are allowed to recoup fees and costs associated with being a default generator.  Based on a brief survey of default vs. cheapest alternative the 'idiot tax' on people that don't pick a provider is 5-10%.  Oh, and the default generator is not allowed to provide a usage based discount but other generators can so not picking can cost you even more than that.

There is a case where you may not want to switch... at least today... so just skip the next three paragraphs. If you have an all-electric home and are under 'Residential Heating' billing codes (stated on your bill as 'RH' - 'Rate RH' and 'Penn Power RH') you are probably charged different rates at different times in the year. This rate system was developed years ago to encourage all-electric homes.  Electric only homes are interesting, because their usage is much greater in the winter than summer - the exact opposite demand cycle of a gas heated home. Electricity generators need to have the capacity to handle peak loads or you have brownouts/blackouts and since the all-electric home is in the minority that occurs in the summer.  In this peak usage time, smaller power plants get taken online or offline based on demand (which correlates with temperature) - these are generally the most inefficient and costliest ones to run like coal, oil, and gas fired plants.  When they are turned off or down you save a bundle as you are burning less fuel. When you have a nuclear plant, it does not saves much money when production is less than the maximum capacity.  With the advent of cheap excess power in the winter, you now want to encourage usage spikes in the winter to get the best rate of return on your nuclear power plant investment.  Enter the all-electric home, which is only cost effective comparable to gas (in our climate) if the cost of electric power is cheaper in the winter.  Deals made with developers to offer a special rate plan where this dream can be fulfilled.  This was a mutual win for homeowners and power generation plants.  People built their homes, chose their appliances, and chose their heating system based on these rate promises.  The history lesson is now over - lets look at what this means.

As of Feb 28, 2011, Penn Power's Residential Heating rates for June-Sept were 6.44 cents/kWh and for Oct-May were 4.50 cents/kWh straight up.  This means no kWh minimums before the discount was applied - just a seasonally adjusted generation rate. According to a phone call I had with Penn Power on 3/4/2011 there is no plans to change their existing program, although no new subscribers can be added to it.  Also of this date there is no competitor for this pricing plan.  If you fall into this boat, as I do, you shouldn't do anything.

PECO Energy has a slightly different program which is being phased out (more discussion on that topic here).  I'd call your provider to get the details and figure out your own cost structure.  Through 3/31/2011 their prices were 9.74 cents/kWh for the first 600 kWh then 5.35 cents/kWh for any usage above that with no mention of summer prices.  Pennsylvania's consumer advocate, Irwin A. "Sonny" Popowski, states: "The commission regulations essentially require the elimination of the special winter heating rates, though we have tried to do this over a multi-year period." I fail to find supporting evidence of this statement in the Rules and Regulations. Since the context of the quote is PECO specific, and their RH rates are discounted only after a kWh minimum is reached, the reference may be to that specific implementation of the winter heating rates by a default provider.  Personally, I call bullshit on this rate change being from the legislation or Rules and Regulations since PECO's price to compare for non RH codes varies in June 2011 (9.99 cents/kWh for the first 500 and 11.20 thereafter). I'd call your legislator and 'Sonny' and get the specific portions of the law/regs I linked to above that he is using to support his assertion. It's PECO's game, anyhow, and yeah - you folks in Philly are probably screwed regardless of what the law says.

After looking at the options across the Commonwealth, I conclude that you could probably save more money by conserving than switching.  Remember that if you save 10% by switching that is only saving the generation charge - not 10% of your total bill.  To learn how to conserve, you need to know your baseline usages, and understand where the power is being consumed then reduce it. This site explains what a kWh is and how to save energy. There are also some simple techniques to check basic insulation effectiveness - like seeing if the snow melts off your roof faster than all your neighbors (that would be bad). Other such tips can be found in the two books I recommend at the end of this post.  If you have electric heat the book on insulation is excellent and a must read.

Good luck in selecting a provider - you will need it.  I found that trying to figure out all the nuances of selecting a provider is way too specific to your particular needs and usage patterns to offer any sort of general advice.

More Information:
PA Office of Consumer Advocate Shopping Guide
PA Public Utility Commission 'PAPowerSwitch' Site

Recommended conservation books:

Thursday, August 27, 2009

Wix way should you go?

Now that I know Rob still reads my mostly stagnant blog, I guess it is the appropriate time to write a long-overdue post.

When I started working with Windows Installer technology, back when it was first introduced with Office 2000, I played around with customizing the package for the IT department to push out a customized version. The tools were quite primitive, the technology was new and largely unknown, and the concept of having blogs, yet alone Microsoft folks blogging, seemed completely foreign. Support was pretty much nonexistent, and much of the documentation was unintelligible. Fast-forward 10 years, and what a difference that makes! Today there are several free and low-cost repackaging tools for transitioning non-Windows Installer based setups to the MSI format, authoring tools, and lots of community support.

Most setup authoring tools have significant issues. Non-MSI or script based installations have issues because they encourage hacks - I can't tell you how many installations I encountered that install services by writing keys to the CurrentControlSet hive and forcing you to reboot merely so the Service Control Manager can pick up that addition. Furthermore, if you are targeting any sort of enterprise where more than one of your setups will be installed IT departments want MSI deployments for very good reasons. GUI based Windows Installer tools fail to do a good job of grouping related things into the same component, and dynamically adding a directory of files at build time breaks patching semantics horribly. Another big disadvantage to these tools lie in the setup author because he or she does not need to understand the underlying technology and can get away with "programming by coincidence" (as described in The Pragmatic Programmer).

I remember several paradigm shifts throughout my experiences with setup technology - nested MSIs, merge module distribution, and chaining installations. During this time the stock price of Rolaids likely skyrocketed. The biggest challenge was attempting to get developers to take a more proactive approach to deployment considerations as they were writing their code. One approach that I took was the use of merge modules - developers of feature-units would package their build output in an MSM that was consumed when building the final product. Using Visual Studio 2005+ with their deployment projects was not only difficult, but downright impossible because of how limited, shortsighted, and buggy deployment projects are. Adding custom actions to these modules involved a complex and convoluted post-build scripting process that nobody understood, but it DID move teams towards the direction of thinking of deployment while coding.

These days, the tag-team of MSBuild plus Wix 3.0 is THE enabler to accomplishing those goals and largely eliminating the disadvantages of the GUI-based tools. Since there is close to a one-to-one correlation of XML elements to the Windows Installer tables, it is quite simple to follow if you understand the underlying Windows Installer engine. To use WiX to author a complete installation, you MUST have an understanding of the Windows Installer engine. To make a few tweaks or additions once the basic skeleton of the installer is laid out, just about any developer can do it provided access to the WiX documentation. I have team members that are NOT setup developers add services, event log sources, and more with no official training.

Some of the more compelling points in favor of WiX is how you can use it to easily and properly make multiple product editions which share components, separate units of related components into their own WXS file(s) for easier understanding and maintenance, and integrate it easily as a first-class citizen into an MSBuild project. No other product is available to my knowledge that accomplishes those goals. Best of all - WiX is free, fast, and easily installable onto any developer machine.

If you are looking to switch authoring tools, take WiX for a test run by using the dark.exe decompiler to convert your existing MSIs and play around with it a bit. Subscribe to the WiX mailing list and ask a few questions. You just might like it.

Congratulations to Rob and the entire team and individuals who have contributed to it, as well as the community of developers who support it via the mailing list on a daily basis. If you are ever in Pittsburgh, let me know. I'll buy you a beer.

Tuesday, August 04, 2009

Visual Studio 2008 GenerateBootstrapper task and UAC

I am extremely disappointed in the Visual Studio 2008 bootstrapper to say the least. While the concept of a bootstrapper is great, it is obvious that the designers did not look at real-world deployment scenarios.

Let me give one example scenario: Installing prerequisite packages and interacting with Vista's User Access Control (UAC). Most of the time, the author of the bootstrapper (by the way that packages are authored and selected) is pretty confident as to how things are required (and I use the word required here very specifically) to be installed: per-user or per-machine. In some cases, such as the .NET framework and many third party redistributables, this is a per-machine only situation. Perhaps some components could be installed per-user, but generally if one part is installed per-user, then all parts capable of being installed per-user should be.

The above understanding should certainly be incorporated as part of a bootstrapper from the start. If some components require a per-machine installation, UAC should be prompted for once, start the elevated process, and this elevated process could be 'commanded' by the non-elevated bootstrapper main process. If per-user components exist, the option to install all of them could be given to the user, and appropriate ALLUSERS=x or command line arguments could be passed to the chained installations capable of doing per-user installations, and the elevated or non-elevated boostrapper process is used based on the requirements of the package and user selection.

Instead, the VS 2008 bootstrapper prompts for elevation of each chained installation, even though the entire POINT of a bootstrapper is a single entry point and interaction for the user to get a piece of software installed onto a users machine. We as developers consider setups a massively coordinated symphony of prerequisites and third party components. The user considers software they purchase or wish to install as a single piece and a single process, and it should seem this way to them.

For setups that are rather long and/or chained-installation heavy, prompting after each chained installation is aggravating to the user and is completely unnecessary from their perspective. This design flaw requires the user to babysit the entire process. We as developers hope that the user chooses to elevate each one - if not the entire setup fails with a rather hopeless error message requiring a support call.

Corporate users are the only ones who generally care about per-user installations, and generally can follow a dependency chain of installations to push apps to the users. Most of them will NOT use our generated bootstrapper, anyway.

The point of this post is to tell you how to work around the 'elevate for each' behavior of the generated setup.exe by hacking the setup bootstrapper used by the MSBuild GenerateBootstrapper task so that it prompts for elevation once at startup and installs everything elevated. This is not ideal because sometimes it is not necessary to elevate, but it certainly makes the end-user result better for the 'happy path' for 99% of all users.

Normal caveats apply - if you break something, its not my fault. Keep a backup of all modified files. The solution presented here will change the behavior for ALL GenerateBootstrapper build tasks unless as part of your msbuild script you replace the appropriate file with the version that gives you the appropriate results.

The Windows SDK actually contains this bootstrapper, and it can be located here on a default installation on a 'normal' PC: C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Engine\setup.bin. Copy this somewhere and rename it to setup.exe. In Visual Studio 2008, do a File->Open->File and find your setup.exe. This will open up a resource viewer/editor. The RT_MANIFEST 'folder' is what you want to expand. Right-click on "1" and export it, saving it as a text file. Open the text file and find the requestedExecutionLevel node - change the level attribute's value to 'requireAdministrator'. Use CTRL-A and CTRL-C to copy the contents of this file to the clipboard. Back at the resource editor, double-click the '1' entry to get it in the hex editor. Select all but the first three bytes and paste your clipboard contents in there. Save and exit. Now rename the setup.exe back to setup.bin and replace the original file, saving a backup, of course. The next time your build happens, the setup.exe will now use the new manifest, giving you one prompt and doing EVERYTHING elevated.

I won't get into the other issues with this bootstrapper - no autogeneration of MSI logs, no timestamps in its own log, immediate run and exit that hinders seld-extracting archive packages for single-file download, no MSI caching for patch scenarios like the Office team uses, spanning over multiple CDs/DVDs etc. I will wait for Wix 3.5's Burn to hopefully resolve these issues and the ones not mentioned. Rob Mensching, are you listening? I'll even volunteer to help write it.