I was glad to see the announcement that two pump-and-dump penny stock scammers were arrested recently. 

Texas Attorney General Greg Abbott’s Special Investigations Unit charged two Texas residents with devising an illegal high-tech scheme to defraud investors out of more than $4.6 million. Both suspects, who were indicted July 3 by a Harris County grand jury, are the subjects of an ongoing investigation by several states and the Securities and Exchange Commission (SEC). In addition to the state’s charges, the suspects face securities fraud charges, which were filed today by the SEC.

Darrel Uselton, 40, of Katy, and his uncle, Jack Uselton, 69, of Houston, face organized criminal activity and money laundering charges. According to state and federal investigators, the Useltons reaped millions in illegal profits by promoting shares from at least 13 penny stock companies. The suspects then secretly sold those stocks into an artificially active market they created with manipulative trading schemes, spam e-mail campaigns, direct mailers, and Internet-based promotional activities.

I don’t know if these two were involved in any of the scams that affected me, but as the recipient of the blowback from bot-net blasted spam emails, I think it’s about time that some of these bastards were taken down.  It’s just unfortunate that we can’t bring back the stocks and the pillory.

While I’m on the topic of brain-dead ISP’s, it appears that AOL’s cancellation tactics have finally gotten it into hot water.  They are now agreeing to mend their ways:

Under the agreement, which was filed by Texas and 48 other states, AOL must provide its customers a simple online cancellation method (http://cancel.aol.com). The attorneys general took legal action after AOL customers complained about difficulty and confusion when they attempted to cancel their AOL paid services. In the future, AOL must record and verify telephone calls between AOL customer service representatives and customers calling to cancel their accounts. AOL must also resolve outstanding customer complaints and provide refunds to consumers who complained since Jan. 2005 of unauthorized service charges or improper billing.

I suppose it remains to be seen if this actually pans out.  But then AOL is getting out of the ISP business anyway, so perhaps they anticipate lots of cancellations and would have done this anyway.

Despite removing all catch-alls, thereby killing the Joe Jobbers in their tracks, I still seem to be banned from sending email to certain people.  Most notably people with AOL email addresses.

I had someone contact me yesterday via my Contact Form to ask some questions about the Marlin Camp Carbine, but my reply got bounced.  AOL informed me that it was not accepting email from my address.

Now this is stupid on the part of AOL, since I never sent spam to their users.  But they still put my domain into their blacklist of spammers, apparently because of the previous Joe Job crap. 

Anyhow… if you try to contact me and you’re using AOL (or Earthlink) and you don’t hear back from me, you might want to investigate getting a less brain-dead email provider.

The laptop battery fire and explosion recall has expanded again, this time with Lenovo recalling 208,000 9-cell lithium-ion batteries that shipped with certain of the 60 and 61 series laptops.  It turns out that my new Thinkpad, a T60p, has one of these explosive devices attached to it.

I submitted a request through their online form for a new battery, but I find it a bit irritating that the confirmation page says that it will take “4 to 6 weeks” to receive a replacement.  In the meantime, for safety, I’m supposed to remove the battery and only use it with the AC adapter.  Hmm… that kind of defeats the purpose of having a notebook computer, doesn’t it?

It occurs to me that there needs to be some kind of handy short catch-phrase for all the recent notebook battery problems. Glocks have _kB!_ (for kaBOOM!), which is immediately recognizable.

How about noteBOOM!, to be referred to as nB!.  Hmm…  that seems to be a little too derivative.  Any ideas?

I hated to cave in and do away with my catch-all address, but I finally had to do it.  I saw a definite pattern where I’d get four or five apparently hand-crafted emails, followed within a few hours by a tidal wave of bounces.  It appears to me that the spammer were probing my domain to make sure the catch-all was still in place so that their bounces wouldn’t be rejected.  Then, upon confirming the catch-all, they’d engage the bots for a major spam run, with me catching all their crap.  If I’d taken the catch-all off of the domain, their initial probes would have been summarily rejected by the SMTP server. 

Because I’ve been using the domain for the past seven years for making up email addresses at will, I had lots of possibly valid addresses that I had to deal with.  I wrote a short Perl script that groveled through all my old Inboxes (back to 2000) to extract all addresses with an aubreyturner.com address in the “To:” and/or “for” headers (in some cases, especially with lists, my address wouldn’t have been in the “To:” field), discarding duplicates.  When I was done there were 1732 unique email addresses.  I spent a couple of mind-numbing hours going through that list deleting garbage entries from spammer Joe Job backscatter.  That left me with 604 addresses that I had to enter into the Dreamhost email control panel.  Fortunately, they have a “bulk edit” feature for each domain.  But it almost caused the panel to cough up a furball when I uploaded the list.

Now I’ve gone back and deleted another 30 or so that looked legit, but which I’d forgotten had been compromised by spammers.

If anyone out there has tried to email me and the message bounced, it’s probably because I missed an address in the alias file.  I’ve verified that the Contact Form target address works, so you can get in touch that way.

Anyone for killing spammers and using their guts to hang them from light poles?  Or am I the only one so annoyed?

Dreamhost has taken a lot of hits recently due to instability and downtime.  I think some of the complaints were overblown.  After all, if you’re betting your business on a website, a $9.99/month shared hosting plan isn’t very smart.

However, Dreamhost has slipped in several areas since I first joined them in 2000.  Given my recent experiences with them and their support staff, here are a few recommendations I have on ways Dreamhost could improve.

1.  Bring back targeted email/panel announcements.

This was one of the better things they used to do.  Whenever a server you were using was going to have any work done they’d send you an announcement telling you what servers were affected, what was being done, when the server would be down, and for how long.  They’ve since moved all of their announcements to their status page, which is a crappy way of doing things.

I don’t expect Dreamhost never to have any downtime, especially at the rates we’re paying.  But they could certainly do a better job of communicating with users.  As an example, they moved my server in early December and the only way I found out about it was after the fact when I saw their status entry.  I should not have to keep track of their blog to determine when one of my systems is being affected.  I should get a directly targeted email.  It cuts down on the clutter I have to manage.  Yes, I know they have RSS feeds, but that still means I have to poll the stupid thing to get information and that I have to wade through all the announcements that are meaningless to me to determine if something is relevant.

This would have also helped me with the ImageMagick issue that I discovered after the upgrade (i.e. I would have known the exact date of the change).

2.  Inform users when their particular systems are down or are rebooted

This is somewhat related to the first item, but that was proactive, while this is reactive.

It’s understood that sometimes things break and a system goes down or has to be rebooted (even if all of your stuff is still working).  As soon as any trouble ticket for a particular system is seen and the problem is verified (not fixed, just verified), then all users of that system should be notified that a problem has been identified and is being worked.  When the problem is fixed, another announcement should be made.  Being properly informed would likely prevent additional trouble tickets from other users of the system if they know the problem is being worked.

I think this would go a long way towards getting ahead of the customer satisfaction issues.  Something like 90% of the griping (my unscientific impression of it, anyway) in the comments is from people who are complaining that their sites are down, yet they aren’t affected by the system that was mentioned on the status page.  But since they don’t trust the ticket system and don’t have any positive information about the problem they flood the comments with complaints about their own sites.  If the system was known to work properly and people knew they’d be notified, there’d be a lot less griping. 

3.  Allow users to update their own trouble tickets

If there’s a way to do this, I haven’t found it.  But in several instances now I’ve need to update the ticket with new information (i.e. in one case I found the problem myself and just needed them to do something; in another the problem went away “on its own”).  My only recourse was to either open a new ticket and reference the first or wait for the tech to reply. 

The last case, where the problem went away on its own, appeared to me to have been a problem with the database server.  And from what I could see, someone rebooted it.  Everything was working fine within 30 minutes of me opening the ticket.  First, if I’d been properly informed (per my suggestions #1 and #2 above), I’d have understood what was going on (and obviously someone was working on it, since the DB system was rebooted), and would not have opened a ticket.  Or, if I hadn’t seen the announcement in time, I could have closed the ticket myself, thereby saving everyone time.  Instead I had to wait 14 hours for a Dreamhost tech to get around to telling me that the site was working fine now.  Duh! 

4.  Provide a site monitoring service

When I first started with them they used to have a system status page where you could see the uptime information for your Apache, MySQL, and SMTP/POP3 services.  Of course, checking uptime in Apache isn’t necessarily an accurate reflection of a site’s availability, since there are other factors, such as application load, network and database availability, etc that can allow Apache to stay up even if the site doesn’t “work.”  Since the status page didn’t give accurate uptime impressions, they decommissioned it.

It’d be nice if they had a site/application monitoring service that allowed you to specify your own webpage and the frequency of monitoring.  That way it could monitor a real example of your application (i.e. the page you specify would access the database and run the application code) and not just the HTTPD status.  The service would then notify you if the site didn’t respond or gave an error. 

Since this involves additional resources to handle, I could see this being a fee-based add-on.  Perhaps it could even include a feature to open a problem ticket automatically if certain events are triggered (this would likely require an extra fee, as well as some work on your part to identify the various failure modes). 

Anyhow, this is just a “nice to have” thing, not necessarily something that’d be required.

At the root of all of these is a simple idea:  Keep your customers informed.  If people have relevant, timely, and accurate information about their systems, there should be a lot less griping (or at least less confusion).

Last summer I implemented watermarking for all hotlinked images.  But while checking referrer logs today I came across some images that weren’t getting watermarked.  This puzzled me at first, as all the logs clearly showed that the file was being properly redirected and they were picking up the watermarked version.  Examining the cache showed that everything since late December wasn’t getting the watermark added (the cache image was the same as the original).

Looking at the watermarking script and the fact that it used the composite command from ImageMagick reminded me that Dreamhost had just upgraded ImageMagick.  They’d long been running on a very downlevel version and upgraded at the end of December to v6.2.4 (which is still a bit odd, given that the current release is 6.3.1).  Thinking that perhaps something in the command line had changed from v5 to v6, I tried manually running the command.  Even with debugging and verbose options on, it showed no errors and the invocation matched the example in the documentation.  It just wasn’t adding the image overlay.

So I took a further look at the documentation and they had an example of using commands to dynamically generate the text (with associated background changes to help differentiate it).  I created a small script that used parameters for the filename and replaced the composite command in the watermarking script with my script.

#!/bin/bash
convert -size 250×35 xc:none -gravity center \
    -stroke black -strokewidth 2 -annotate 0 ‘Hotlinked from aubreyturner.org!’ \
    -channel RGBA -blur 0x3 \
    -stroke none -fill white   -annotate 0 ‘Hotlinked from aubreyturner.org!’ \
    +size $1 +swap \
    -gravity south -geometry +0-2 -composite $2

I still don’t know what broke in composite with the upgrade, but at least this works and looks better than my original.

Hotlinkers will get the image with the text added at the bottom in the center, like this:

I just upgraded to Expression Engine 1.5.2.  Yes, I know I’m 20 days behind the curve.   

The upgrade seemed smooth on the server end, so let me know if you experience any unusual symptoms (from your browser; I don’t want to know about that itchy pentagram shaped rash ). 

While I was playing with the gun show page I also ran into something that annoyed me enough to finally fix it.  Each page on the gun show site had a little navigation header (sort of like tabs) at the top that displayed the current page in bold and had links to the other pages:

Adding new pages is kind of annoying since you have to go into each of the previously existing pages and add the new links.  Further, in adding the new pages I decided to make them “sub pages”, which further complicated matters:

One of the great features of EE is the ability to create templates that you embed in other templates.  So I thought that if I could figure out how to differentiate the different pages I could possibly create a template that determined which item to highlight automatically.  That would solve the problem once and for all, and adding a new page would be as simple as adding the link to the one template.

It turns out that EE has some handy features to let you do this.  If you’ve noticed the URL’s on this site, they’re usually of the form “/basedir/index.php?/group/template”.  The group segment of the URL specifies the “template group,” which is a set of templates that logically go together.  They can be used for a variety of purposes, but I typically use them to organize different weblog (i.e. this page is in the “orglog” group and the gun shows are in the “shows” group).  But EE will let you pull content from multiple weblogs into a single template, which (while powerful), kind of confuses things.

Anyhow, EE lets you access the segments of the URL after “index.php?” using segment variables in your templates.  For example, if the URL is “../index.php?/shows/history” you can reference “segment_1” and get “shows” or “segment_2” to get “history.”  Since I used a unique template name for each “type” of page (main, calendar, details, map, etc), I can examine the second segment to determine which page is being used.  The only exception is the index template, which is implied when no other information is given or if the second segment is unrecognized (which is how EE handles individual pages, by the way; if the last segment isn’t a recognized template it’ll invoke the index template with special parameters which cause the main weblog entries loop to return only the one entry specified in the URL; you can see this by clicking the “Permalink” link below this entry).

So, using the above, you can use EE’s conditionals to check for the template name and decide which is highlighted:

In the short term it would have probably been faster (but a little tedious) just to hard-code the header in each page, but what many people don’t realize is that programmers are lazy.  We’ll spend inordinate amounts of time (just an hour or so in this case, though), figuring out how to automate something that only takes a few seconds if it’s annoying or tedious.

Six months to a year ago I got an interesting email from someone asking about historical gun show listings.  This fellow needed to figure out the date of a show back in 2002 or 2003 (I think it was), and that was back when I was still maintaining the list using a static HTML page.  This had something to do with an IRS audit, although I didn’t get the details.  I sent him the files I could find in the archives and hopefully he survived his meeting with the IRS.

Anyhow, one of the things that I’d been trying to decide how to handle was the issue of old show listings.  Sometimes it’s good to be able to look back to find the exact date of a show, such as when you’re trying to remember exactly when you bought something.  The problem was that while it’s technically possible to incorporate the old listings into the main page, it would be horribly cluttered (they go back to May, 2004 in the database).  My current solution to keeping the main page uncluttered was to set the post expiration date to one month after the show.  That way they’d stay around for a month and then disappear from the listing.  They would still be Open in EE, just “expired,” so every so often I’d go in and do a mass Close on them (it makes finding and working with current listings easier, since I can search for just Open items).

I copied the main Index page template to a new one called “history” and modified the selection criteria and tweaked the display a little (I decided to use nested unordered lists instead of a table) and fairly quickly came up with a history page.

I have become more and more impressed with the capabilities of the EE weblog module over time.  All it took was tweaking the “entries” loop a little and adding the list tags on the date_heading and date_footer to get everything properly enclosed:

In the above, “exp:weblog:entries” causes a loop over all entries in the blog called “dfwgun” that are closed (or expired) and ordered by date (oldest first).  Everything between it and the closing tag gets repeated once for each entry, except for the “date_heading” and “date_footer” tags, which get inserted in the loop anytime a new month boundary is crossed.  All of that stuff generates the following:

While I was in there I also did something similar to display the list of promoters from the database.

Update: changed code to image from blockquote (less messy).