Challenges in testing Dancer 2.0 apps
I’ve been dabbling in Dancer, and I managed to put together a moderately complex re-hosting of a web application with Dancer 1.0, including a preliminary package of unit tests via Test::More.
Spoiler alert: I don’t yet have a solution, but I thought maybe this blog post would organize my thoughts to where someone else might peek in and spot my problem.
A bit of introduction follows for those who may not have been down this path before.
Testing a web application can take one of two general approaches:
- Test the underlying code by calling it directly, one program to another, with no web server involved. This is pretty straightforward, although you may have to rig up some replacements for the environment (such as if your code expects CGI parameters, or reacts to things in the web server environment such as cookies, remote IP address, etc.). In any case, you have to recognize that you are now testing the code logic, not the actual interaction of your code as a subsystem in the web server.
- Test the web application in its “native environment”, by issuing requests to its associated web server and examining the responses (as web pages, JSON, what-have-you). This is much preferred, as it …
dancer perl testing
Proxmox and the fun maze of IPv6 connectivity
While working on the Proxmox machine setup and specifically on the IPv6 connectivity I found a problem where after a reboot I always kept getting the *** net.ipv6.conf.all.forwarding*** and all related variable set to 0, thus giving lots of IPv6 network connectivity issues on the guests.
While brainstorming with a colleague on this, we discovered in the boot logs these few messages which are quite indicative of something horrible happening at boot:
# less /var/log/boot.0
[..]
Mon Jul 8 18:38:59 2013: Setting kernel variables ...sysctl: cannot stat /proc/sys/net/ipv6/conf/all/forwarding: No such file or directory
Mon Jul 8 18:38:59 2013: sysctl: cannot stat /proc/sys/net/ipv6/conf/default/forwarding: No such file or directory
Mon Jul 8 18:38:59 2013: sysctl: cannot stat /proc/sys/net/ipv6/conf/default/autoconf: No such file or directory
Mon Jul 8 18:38:59 2013: sysctl: cannot stat /proc/sys/net/ipv6/conf/default/accept_dad: No such file or directory
Mon Jul 8 18:38:59 2013: sysctl: cannot stat /proc/sys/net/ipv6/conf/default/accept_ra: No such file or directory
Mon Jul 8 18:38:59 2013: sysctl: cannot stat /proc/sys/net/ipv6/conf/default/accept_ra_defrtr: No such file or …
debian ipv6 sysadmin
Use Rubygems.org To Find GitHub Source For Gems
If you want to look at source for a gem on GitHub, make sure to go to Rubygems.org first and find the gem’s GitHub project through rubygems’ page for that particular gem. The reason for this is that there are lot of forks on GitHub and you may end up finding the source to a fork that is dead. Rubygems.org is guaranteed to have the right path to the gem you are installing via “gem install mynewgem”.
Most of the profile pages for a gem on Rubygems.org have a link for the “home page” and “source code” of a gem and these usually link to the GitHub page of the gem’s source. This trick isn’t a 100% as not every gem’s source is located on GitHub but it works about 90% of the time. In the case where you can’t find a gem’s source through Rubygems.org, try “gem unpack
ruby
Automating checking for new versions of PostgreSQL
It is important to run the latest revision of the major branch of Postgres you are using. While the pgsql-announce mailing list is often touted as a canonical way to become aware of new releases, a better method is to use the check_postgres program, which will let you know if the version you are running needs to be upgraded or not. An example usage:
$ check_postgres.pl --action=new_version_pg --dbhost=iroh
POSTGRES_NEW_VERSION_PG CRITICAL: Please upgrade to version 9.2.4 of Postgres. You are running 9.2.2
Postgres version numbers come in three sections. The first two indicate the “major version” of Postgres that you are running. The third number indicates the revision. You always want to be using the highest revision available for your version. In the example above, Postgres version 9.2 is being used, and it should be upgraded from revision 2 to revision 4. A change in the revision number is known as a minor release; these are only done for important reasons, such as security or important bug fixes. Read the versioning policy page for more information.
When a new version of PostgreSQL is made, there are two general ways of communicating this fact: the …
monitoring nagios postgres sysadmin
CouchDB pagination with couchdb-python
I’ve been working with couchdb-python v0.8 to meet some of a project’s CouchDB needs and ran into an unfortunate shortcoming.
Retrieving database rows is as easy as:
for row in db.view(mapping_function):
print row.key
However, all the rows will be loaded into memory. Now, for small databases this is not a problem but lucky me is dealing with a 2.5 million+ document database. Long story short: kaboom!
There is an excellent blog post by Marcus Brinkmann that details the memory issue and also provides a pagination solution. However, couchdb-python v0.9 (released 2013-04-25) does provide its own solution: the iterview method. If you’ve been able to manage small databases with v0.8 but are anticipating larger and larger databases, be sure to upgrade!
couchdb python
WAVE: Evaluating Web Accessibility
It’s been far too long since I wrote a blog article! I’ve been a bit preoccupied:

My [cute] preoccupation.
I thought I’d start with a short blog article to get back into it. Recently, the H2O project has been keeping me busy. One interesting resource I’ve been using for the project is WAVE. WAVE is a free web accessibility evaluation tool, which in our case helps us evaluate the H2O web application for it’s use in an academic setting for those users with disabilities. The tool helps to evaluate accessibility against Section 508, WCAG, and more.
To use the tool, you simply visit https://wave.webaim.org/ and type in the URL that you want evaluated:

WAVE homepage
The results show warnings and alerts, as well as feedback regarding other structural markup overlayed on the page. The results are meant to serve as a resource to make decisions regarding accessibility. Some web application developers may be more inclined to follow the guidelines than others.

Example WAVE output, analysis of End Point’s home page.
accessibility user-interface
Rails transposing day and month after upgrading Ruby 1.8.7
If you’re wondering why your month and day are being transposed when saved in your database, you’re likely:
- Using a text field input for dates (likely with some JavaScript date picker)
- Using American style date formatting (mm/dd/YYYY)
- Upgrading from Ruby 1.8.7
If you meet these criteria you’ll find that American style dates get parsed incorrectly in Ruby 1.9+ because of Ruby 1.9.x’s new date parsing strategy. Unbelievably, this change effectively does away with American style date parsing in Ruby 1.9.x and Rails has happily followed suit!
american_date to the rescue!
After trying and failing to restore American style date parsing using timeliness, delocalize, and i18n_alchemy, I found american_date. If you look at the implementation, it is straight forward and restores backwards compatibility by simply adding a line to your Gemfile. Enjoy the return to sanity!
With Ruby 1.8.7 going EOL this month, and Rails 2.3.x and older losing support for even sevre security issues, it’s time to bust out your upgrade-foo for those old Rails apps. Of course, this is a tried and true topic, with many resources, most notibly Railscast #225. Good luck with your upgrades!
rails
Custom 500 error page while using nginx proxying
I was working with our customer Paper Source to setup a 500 error page that looked like the rest of the site when I ran into something interesting. I went through the nginx configuration and added this line to allow for a custom 500 error page just like I had done for the custom 404 error page.
error_page 500 = /cgi-bin/paper/500.html;
What I noticed when I forced the site to create an Internal Server Error was that I was still getting the ugly normal Apache version of the 500 error page. It seemed like nginx was ignoring the error_page directive. I did some searching and found out that you have to use the proxy_intercept_errors directive.
proxy_intercept_errors on;
This directive allows nginx to recognize the 500 error code being returned from Apache and run its own directives to display the right page.
nginx sysadmin