Skip to content

Active PFC-Enabled PSUs Are Not Compatable With Most Low-End UPS

It turns out that most PC power supply units with active power factor correction (PFC) do not work well with lower-cost uninterrupted power supplies (UPS), e.g. battery back-ups. This I learned the hard way, as my Antec EarthWatts EA 500 PSU, which I adore, will go dead the second the battery on my APC Back-UPS BX1300LCD kicks in.

That’s because APC’s Back-UPS units output power, when on battery, as a modified sine wave, rather than a true sine wave.

In short, if you send a high-end PSU the current created by a lower-end UPS, the PSU’s built-in power factor correction hates it, and cuts power to the PC immediately. As in, the exact thing you bought the UPS to prevent in the first place is exactly what happens.

While I understand the value in having a high-performing PSU — less heat, more power, protection for internal components — a straight-up power off of the PC is never a good thing. So your choices are either to forgo a UPS, purchase a really expensive UPS, or purchase a low-cost PSU.

Continue reading ‘Active PFC-Enabled PSUs Are Not Compatable With Most Low-End UPS’ »

The Future Of Web Programming: From Artisan To Assembly Line

Sent to me via e-mail from Billy, a frequent commenter on this blog (that is, for as infrequently as the blog gets comments, Billy is often one of those commenting):

I was wondering if I could get a small interview, just one question, for a term paper. I have 15 bibliography cards to do and I need sources and I was going through websites, found three good ones about career prospects in the programming/web development and design fields and that was it. I was thinking about people I could ask questions to and thought about you. I basically needed to know what you think the career opportunities in the programming and web development fields are and what you think they’ll be years on down the road. If you’re too busy I understand. Thank you for your time.

Billy:

I’m no industry analyst; my prognostications are usually limited to American football, and more often than not turn out wrong. (Quoth I, just before kickoff of Super Bowl 44: “The Saints are a great story, but this is gonna be a rout. Indy’s gonna annihilate them.”)

But I do have opinions about what programming and the Web will be like in 20 years, formed as a result of listening to others’ opinions, the history of the neolithic, agricultural and industrial revolutions, and my own experience of seeing how the Web has changed over the roughly 15 years I’ve been working in programming it.

The Web and computer programs we have today are, in a lot of ways, very much like the horse plow, rail fence and punch-card looms of antiquity. Today’s Web technologies and desktop programs are not primitive, but they’re largely second and third drafts of technologies that are changing fast.

The first Arab to tend a garden didn’t envision ConAgra; Adam Smith would probably have laughed at the notion of a Chinese economic juggernaut as he wrote The Wealth of Nations. The same will hold true of Al Gore and Tim Berners-Lee: What they thought they were making, at the time they were making it, is markedly different from what we have today, and will result in something far different, further down the road.

Continue reading ‘The Future Of Web Programming: From Artisan To Assembly Line’ »

Some Quick Housekeeping

Today, I cleared out all blog entries here that aren’t related to programming; that included about 60 posts on eBay vendors I’ve used in the past, as well as probably another 30 posts about music, football and the like.

I want this blog to focus on programming, business practices and other profession-based posts. Besides, that stuff wasn’t very popular and seldom added to the sum of human knowledge. Sometimes, they were negative and critical; I really am trying to be better than that.

So, from here on out, positive posts about programming. On the rare occasion when I feel the need to write about something else, I’ll use Blogger.

Dynamically Adding JavaScript To Your ASP.NET Master Page From A Child Page

A common challenge when working with ASP.NET master pages is how to dynamically add JavaScript that is relevant to a specific child page.

In other words, maybe your site has 10 child pages that share one master page / template. One of them is, let’s say, a contact us / directions page, and on that page, you want to display a map from one of the many mapping APIs out on the Web; for simplicity’s sake, let’s use the Google Maps API.

Proper implementation of the Google Maps API requires you to call, in the head section of your page’s HTML, the API library. So, you’re left with four options:

  1. Import the library in the master page’s code for all child pages, and thus incur that overhead for every page using that master page / template;
  2. Create a second version of the master page, containing the code, and apply that master to the child page that needs it;
  3. Don’t use a master page for the page that needs the API; have that erstwhile “child” page contain all the HTML it needs; or
  4. Figure out a way to add the needed code to the head of the master page for the child that needs it.

Option 1 seems reasonable, but it’s messy; although simply bringing in the Google Maps API for every page isn’t resource-intensive in this strong-computer, fast-bandwidth world, it’s sloppy at best and a potential security risk at worst (although the Google Maps API is pretty much safe to import, even if you’re not going to use it).

Option 2 leaves you with what is fundamentally two versions of the same thing, which is pretty much the dictionary definition of “inelegant.” Option 3 isn’t any better.

Option 4 is the best approach, and thankfully, there are a couple of ways to do it in ASP.NET. I’m going to describe the way to do it by dynamically adding HTML elements to the master page’s head, but first, a quick digression on using a PlaceHolder control.

Continue reading ‘Dynamically Adding JavaScript To Your ASP.NET Master Page From A Child Page’ »

Blog Changes: New Themes, New Syntax Plugin, Several Plugins Deactivated

Since I’m reviving the blog, I decided to give it a good going-over, in terms of theme, plugins and other aesthetics / tools I’m using.

The most notable change: I’ve switched from Fluid Blue to F2, both by SriniG. I really like the straightforward, clean appearance of Srini’s templates; when it comes to Web design, I am decidedly minimalist.

I’m inclined to agree with Chris Brogan and Julien Smith, authors of Trust Agents, when they strongly suggest having a personalized blog template. Experience certainly tells me that packaging and logo is vital to building any brand.

Truth be told, I can’t make anything anywhere near as nice as F2, and I’m too cheap to hire someone who could. Maybe, someday, I’ll trade a Web designer, programming for design. If you’re interested, let me know. Anyway, I like the new look, which I’ve hacked a bit, mostly by keeping all the fonts sans-serif.

I’ve also turned off several plugins. As previously noted, WP-PostRatings was not very popular. AskApache Google 404 did not deliver the SEO optimization I expected, and is a bit too ugly out of the box for my taste; I didn’t want to invest the time it would take to make it look pretty.

Global Translator is really just some buttons to use various online translation services. It does provide a local caching mechanism, which is why I installed it in the first place: I wanted to have the search engines index my posts in multiple languages.

But I couldn’t get the cache to work properly, which caused all kinds of 404 errors (which, again, AskApache Google 404 didn’t really help to fix). To top it off, the translation services were translating my code blocks, rendering them useless. Again, I could hack these problems myself, but since visitors can use the same services Global Translator uses, I decided to simply scrap it.

Continue reading ‘Blog Changes: New Themes, New Syntax Plugin, Several Plugins Deactivated’ »

Hacking WP-PluginsUsed To Remove Plugin Version Numbers

One of the greatest contributors to the WordPress plugins repository is Lester “GaMerZ” Chan.

It’s testament to the value of his contributions that his work has not only been duplicated, borrowed and built upon by hundreds of other plugin developers — just search “gamerz” in the WordPress plugins repository to see how many times his name is cited — but many of his ideas and hacks have made their way into the core functionality of WordPress.

I use two of Gamerz’s plugins: WP-PostViews and WP-PluginsUsed. (Until recently, I also used WP-PostRatings, but that was not a popular feature, so I turned it off.) I like them both, but I had concerns about the security of using WP-PluginsUsed.

My concern was not WP-PluginsUsed itself, but the fact that it reported the version numbers of other plugins. Just telling the world that I am using a plugin is bad enough; reporting the specific version number, making it even easier on crackers, seems pointless.

But I believe in giving credit where credit is due, even at the risk of someone trying to exploit this site. I can always deactivate any plugin that has a major security hole. Besides, what plugins one is using generally isn’t difficult to figure out; there tends to be a handful available for any given task, and the ones that work well are often few and far between. You can pretty much just look at a WordPress blog and get a good feel for what plugins it is running.

That said, to keep my peace of mind, I simply commented out the part of WP-PluginsUsed that reveals version numbers.

You can do that either in the plugin editor that’s built into WordPress, or your favorite text editor. Look for the get_plugingsused_data() function, around Line 46:

46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
### Function: WordPress Get Plugin Data
function get_pluginsused_data($plugin_file) {
	$plugin_data = implode('', file($plugin_file));
	preg_match("|Plugin Name:(.*)|i", $plugin_data, $plugin_name);
	preg_match("|Plugin URI:(.*)|i", $plugin_data, $plugin_uri);
	preg_match("|Description:(.*)|i", $plugin_data, $description);
	preg_match("|Author:(.*)|i", $plugin_data, $author_name);
	preg_match("|Author URI:(.*)|i", $plugin_data, $author_uri);
	if (preg_match("|Version:(.*)|i", $plugin_data, $version)) {
		$version = trim($version[1]);
	} else {
		$version = '';
	}
	$plugin_name = trim($plugin_name[1]);
	$plugin_uri = trim($plugin_uri[1]);
	$description = wptexturize(trim($description[1]));
	$author = trim($author_name[1]);
	$author_uri = trim($author_uri[1]);
	return array('Plugin_Name' => $plugin_name, 'Plugin_URI' => $plugin_uri, 'Description' => $description, 'Author' => $author, 'Author_URI' => $author_uri, 'Version' => $version);
}

We’re going to edit the last line of that function, the one that says “return array( … ).” Here’s the replacement line:

64
	return array('Plugin_Name' => $plugin_name, 'Plugin_URI' => $plugin_uri, 'Description' => $description, 'Author' => $author, 'Author_URI' => $author_uri, 'Version' => ''); //$version);

What this does is replace the version number for each plugin with an empty string; it has the same practical effect, through the rest of the plugin’s code, as never having reported the version of the plug-in.

Note that I also could have commented out lines 54, 55, 56 and 58, and left Line 64 intact. That, too, would have set the value of the version for each plugin to an empty string. I opted for the solution above because it is most elegant.

I distribute all code under the GNU GPL.