Brian Mark - Guitaraholic

Today, we had an XML process change so invalid XML was being returned (or changed invalid XML, because it's always invalid, but we had a fix for the prior version). Instead of just affecting us while the bad data was being returned, it actually lasted a little while longer. Why? Because we use memcached to store the result, lessening the load on our inventory management system. While it isn't normally an issue (most people don't deal with this oddball system), if we were storing those results longer than we had been, this could have been a huge issue. It was rendering product pages non-functional, which isn't a good thing. As a result of this, we're going to start doing more error checking and trapping. Oh what fun it is to deal with systems that don't care about being valid in the slightest and having Perl modules that require it.

I got the first step of the checkout process Ajaxified today on the live site. Because of all the issues I could cause by installing Norton, disabling JavaScript, etc. that I'm actually just giving "Helpful hints" if some input is wrong. For example, an invalid postal code or an invalid email address. Now I get to start checking for valid postal addresses and trying the same thing. A bit trickier, and a lot more possible instances. For example, is it valid, not valid, valid with multiple matches or invalid with multiple matches? Now, how do I convey all those messages? Should prove interesting.

For many developers, running a simple web server on a windows box would simplify things a lot. I've been asked many times how to do that best. Well, my answer has been the same for a while now: use Indigo . Indigo Perl installs Apache as a service with PHP and Perl support. You can install this right to your Windows workstation and be off and running in a few minutes. No more uploading a file and saying "Oops" when there's a typo. Install it and view your site on your own PC before you FTP the files up to your web server. I've installed this on a few Windows servers as well for some Intranet apps. It sure beats manually configuring things to run Perl, since that's the language I program almost everything in. Yep, I'm old school, but that's mostly linked to my past as a Unix sysadmin. Wow... that makes me really old school.

I'm starting to work on developing an AJAX-style checkout process and came across something pretty cool. It uses a combination of a server-side Perl script, a Perl module, some JavaScript and a simple HTML form. The first thing I had to do was install the Mail::CheckUser module. The installation on all 5 servers I tried it on didn't want to work via normal methods, and 'make test' always came back saying it had errors, but doing a 'make install' let it install and it works just fine, even with all of the errors reported by the test step. The next thing to do was create a real simple Perl script to check it out. I simply called it validate.pl (since it's part of a form validation routine) and loaded it to a web server with the correct permissions, then replicated it across the rest of our servers. The actual work is done by the following chunk of code. #!/usr/bin/perl print qq(Content-type: text/plain\n\n); use CGI qw (:standard); checkEmail(); exit; sub che...

One of the things that has always bugged me is the excessive bandwidth that PDF's use when presenting schematics. We also have a fair number of users that aren't computer literate enough to understand what Acrobat Reader is, although this seems to be less of an issue lately. Many of our vendors only supply PDF's, and with the 1000's and 1000's of schematics we have it's just not a good option to manually manipulate each one. Enter ImageMagick. ImageMagick ImageMagick is available for many languages, but I prefer using Perl to manipulate the images. Most of the concepts will be the same regardless of language, even if the syntax is changed. So, to begin, I'll include the module and assign the path I want to convert files from. I've also bolded any items you may want to change for your implementation in all of the code snippets below. #!/usr/bin/perl use Image::Magick; use IO::Dir; my $path = [path to images] ; tie %dir, IO::Dir, $path; At this point, we...

So I started on a site that is going to do some manipulation of MP3 files dynamically, taking a preview out of the song that should be sort of representative of the song. I toyed with a few different ways of pulling out the section I wanted, looking for large dynamic changes, widest frequency range, flattest frequency pattern, breaks in the song, etc. I also tried a few different methods of making the snip. Here's what I found. 1) Regardless how cool it is to be able to detect changes in dynamics, frequency ranges, patterns, breaks, or anything else it just doesn't mean that the section will be representative. 2) MP3 players are fairly bullet proof and don't mind some abuse. There isn't any need to split properly across frames within the file - MP3 players (all that I've tested in Win and Linux) all handle improperly split files just fine. 3) Bitrates don't translate perfectly. Just because you know how many bits per second a file is doesn't mean you can cli...

I enjoy image manipulation. If I can do it via code, even better. For example, the following image will get text added to it because I'm hotlinking (using it from the ToolBarn.com web server from a different site). We're doing that mostly for the benefit of eBay users that decide to use our images. It's resulted in some visits and sales for us, and fewer sales for the eBay users. Of course, nothing is as cool as dynamically created images. When I decide to put a thumbnail of my blog on this page, I created a tool that does that. www.toolbarn.com/web-tools/ has a webpage thumbnail generator now. I've been playing with it for a while, trying to make it display as many pages as possible correctly, and it seems to be working fairly well now. I got a pop-up blocker working, it renders flash properly, and does a few other "Goodies" like timestamping the image and giving a guess as to the PR of the page in the image. Again, simple stuff, but cool none the less. I in...