Perl Testing - stopping the firehose
By Greg Sabino Mullane
September 13, 2010
I maintain a large number of Perl modules and scripts, and one thing they all have in common is a test suite, which is basically a collection of scripts inside a “t” subdirectory used to thoroughly test the behavior of the program. When using Perl, this means you are using the awesome Test::More module, which uses the Test Anything Protocol (TAP). While I love Test::More, I often find myself needing to stop the testing entirely after a certain number of failures (usually one). This is the solution I came up with.
Normally tests are run as a group, by invoking all files named t/*.t; each file has numerous tests inside of it, and these individual tests issue a pass or a fail. At the end of each file, a summary is output stating how many tests passed and how many failed. So why is stopping after a failed test even needed? The reasons below mostly relate to the tests I write for the Bucardo program, which has a fairly large and complex test suite. Some of the reasons I like having fine-grained control of when to stop are:
-
Scrolling back through screens and screens of failing tests to find the point where the test began to fail is not just annoying, but a very unproductive use of my …
perl postgres testing
Reducing bloat without locking
By Josh Tolley
September 9, 2010
It’s not altogether uncommon to find a database where someone has turned off vacuuming, for a table or for the entire database. I assume people do this thinking that vacuuming is taking too much processor time or disk IO or something, and needs to be turned off. While this fixes the problem very temporarily, in the long run it causes tables to grow enormous and performance to take a dive. There are two ways to fix the problem: moving rows around to consolidate them, or rewriting the table completely. Prior to PostgreSQL 9.0, VACUUM FULL did the former; in 9.0 and above, it does the latter. CLUSTER is another suitable alternative, which also does the latter. Unfortunately all these methods require heavy table locking.
Recently I’ve been experimenting with an alternative method—sort of a VACUUM FULL Lite. Vanilla VACUUM can reduce table size when the pages at the end of a table are completely empty. The trick is to empty those pages of live data. You do that by paying close attention to the table’s ctid column:
5432 josh@josh# \d foo
Table "public.foo"
Column | Type | Modifiers
--------+---------+-----------
a | integer | not null
b | integer | …postgres
CSS Sprites and a “Live” Demo
By Steph Skardal
September 6, 2010
I’ve recently recommended CSS sprites to several clients, but the majority don’t understand what CSS sprites are or what their impact is. In this article I’ll present some examples of using CSS sprites and their impact.
First, an intro: CSS sprites is a technique that uses a combination of CSS rules and a single background image that is an aggregate of many smaller images to display the image elements on a webpage. The CSS rules set the boundaries and offset that define the part of the image to show. I like to refer to the technique as analogous to the “Ouija board”; the CSS acts as the little [rectangular] magnifying glass to show only a portion of the image.
It’s important to choose which images should be in a sprite based on how much each image is repeated throughout a site’s design and how often it might be replaced. For example, design border images and icons will likely be included in a sprite since they may be repeated throughout a site’s appearance, but a photo on the homepage that’s replaced daily is not a good candidate to be included in a sprite. I also typically exclude a site’s logo from a sprite since it may be used by externally linking sites. End Point uses CSS …
ecommerce optimization
Guidelines for Interchange site migrations
By Ron Phipps
September 3, 2010
I’m involved at End Point often with Interchange site migrations. These migrations can be due to a new client coming to us and needing hosting or migrating from one server to another within our own infrastructure.
There are many different ways to do a migration, in the end though we need to hit on certain points to make sure that the migration goes smoothly. Below you will find steps which you can adapt for your specific migration.
During the start of the migration it might be a good time to introduce git for source control. You can do this by creating the repository and cloning it to /home/account/live, setting up .gitignore files for logs, counter files, gdbm files. Then commit the changes back to the repo and you’ve now introduced source control without much effort, improving the ability to make changes to the site in the future. This is also helpful to document the changes you make to the code base along the way during the migration in case you need to merge changes from the current production site before completing the migration.
-
Export all of the gdbm databases to their text file equivalents on the production server
-
Take a backup from production of the database, catalog, …
ecommerce environment git interchange perl
Long Lasting SSH Multiplexing Made Simplish
By Brian J. Miller
September 1, 2010
My Digression
To start off digressing just a little, I am primarily a developer, lately on longer projects of relatively significant size which means that I stay logged in to the same system for weeks (so long as my X session, local connection, and remote server allow it). I’m also a big believer in lots of screen real estate and using it all when you have it, so I have two monitors running high resolutions (1920x1200), and I use anywhere from 4-6 virtual pages/desktops/screens/(insert term of preference here). On 2-3 of those spaces I generally keep 8 “little black screens” (as my wife likes to call them) or terminals open in 2 rows of 4 windows. In each of those terminals I stay logged in to the same system as long as those aforementioned outside sources will allow me. A little absurd I know…
If you are still with me you may be thinking “why don’t you just use screen?”, I do, in each of those terminals for the inevitable times when network hiccups occur, etc. Next you’ll ask, “why don’t you just use separate tabs/windows/partitions/(whatever they are called) within screen?”, I do, generally I have 2-3 (or more) in each screen instance …
ssh
An Odd Reason Why I Like Google Wave
By Jon Jensen
August 30, 2010
Others have noted reasons why Google might have decided Wave is a failure, but for me the most significant reason is that when it was announced at Google I/O 2009, it needed to be open to all interested parties. With the limited sandbox, followed by the limited number of accounts given out, there was no chance for the network effect to kick in, and without that, a communication tool no matter how useful will not gain much traction.
I still use Google Wave, along with several of my co-workers. Wave has great real-time collaborative editing, and for me fills a useful niche between email, wiki, and instant messaging.
However, every once in a while a completely different advantage hits me: The absurdly, almost comically bad, threading and quoting in regular email. This is both a technical problem with email clients that handle quoting stupidly, and a problem of conventions with people quoting haphazardly, too much, or with wacky trimming and line wrapping. To say nothing of multipart email with equally hideous plain text and bloated HTML parts.
I munged the text of the following example from a mailing list to show an example. It’s not the most egregious mess of quoting, and had …
community
Learning Spree: 10 Intro Tips
By James Bennett
August 26, 2010
In climbing the learning curve with Spree development here are some observations I’ve made along the way:
-
Hooks make view changes easier — I was surprised at how fast I could implement certain kinds of changes because Spree’s hook system allowed me to inject code without requiring overriding a template or making a more complicated change. Check out Steph’s blog entries on hooks here and here, and the Spree documentation on hooks and themes.
-
Core extensions aren’t always updated — One of the biggest surprises I found while working with Spree is that some Spree core extensions aren’t maintained with each release. My application used the Beanstream payment gateway. Beanstream authorizations (without capture) and voids didn’t work out of the box with Spree 0.11.0.
-
Calculators can be hard to understand — I wrote a custom shipping calculator and used calculators with coupons for the project and found that the data model for calculators was a bit difficult to understand initially. It took a bit of time for me to be comfortable using calculators in Spree. Check out the Spree documentation on calculators for more details.
-
Plugins make the data model simpler after learning what they …
ecommerce rails spree
Hopefully Useful Techniques for Git Rebase
By Ethan Rowe
August 20, 2010
I recently had to spend a few hours merging Git branches to get a development branch in line with the master branch. While it would have been a lot better to do this more frequently along the way (which I’ll do going forward), I suspect that plenty of people find themselves in this position occasionally.
The work done in the development branch represents significant new design/functionality that refactors a variety of older components. My preference was to use a rebase rather than a merge, to keep the commit history clean and linear and, more critically, because the work we’re doing really can be thought of as being “applied to” the master branch.
No doubt there are a variety of strategies to apply here. This worked for me and perhaps it’ll help someone else.
Some Key Concerns for a Big Rebase
Beyond the obvious concern of having sufficient knowledge of the application itself, so that you can make intelligent choices with respect to the code, there are a number of key operational concerns specific to rebase itself. This list is not exhaustive, but it is not an unreasonable set of key considerations to keep in mind.
Rebase is destructive
Remember what you’re doing! While a merge …
git testing