Jim Hoskins

I have been using autotest (actually autospec and autofeature) for my development cycle for some time now, and I always felt like it was missing something. Then, one night while playing Team Fortress 2, I realized the the announcer’s taunts and encouragement really motivated me to continue and do better.

I thought this would be awesome for Test Driven Development. So I found some TF2 Sound files, and hacked up my .autotest file.Now when I go from red to green or green to red, I get a message from the TF2 announcer alerting me to my status.

I thought that sounds might be a bit annoying while developing, but this configuration only plays a sound when you go from green to red or vice versa, so it doesn’t play sounds constantly and it is actually very motivating.

I thought I would share my autotest setup for anyone else who would like a little more excitement in their TDD cycle.

.autotest Gist

This file has sounds off by default. To enable sounds, set the environment variable AUTOTEST_SOUNDS=true

It expects to have a directory ~/.autotest_media with the images (for growl notifications) and folders with sound files named success and failure with sound files to use for each state.

You can download my autotest media directory here

This media directory contains

• Pass and Fail Images (for growl)
• Failure Sounds
  • “Do not fail me again”
  • “Do not fail me this time”
  • “You failed! Prepare for sudden death”
  • “You failed! Stalemate!”
  • “Failure!”
  • “You FAILED”
  • “You must not fail me again”
  • “You must not fail me this time”
• Success sounds
  • “Success!”
  • “Time has been added”
  • “Congratulations, we have been awarded additional time”
  • “Success, we have been awarded additional time”
  • “Additional time has been awarded”
  • “We have succeeded”

  Whenever a sound is triggered, it will play a random file out of the success or failure folders, so you can add, remove, or replace any sound files you wish.

  Happy testing!

  This autotest file and images are from the excellent Peepcode: RSpec Basics

From JakeAndAmir.com


oh… and the embed code has been totally Validified

I wanted to post a quick guide to the special ruby syntax for literals that utilize the % (percent) symbol. Most beginners guides to ruby leave out an explanation of these forms of literals, but many ruby coders use them. When someone encounters them for the first time it is almost impossible to figure out what they mean. (Try searching Google for “%w”)

Ruby has special syntax for making strings, arrays and system commands easier to write. They allow you to use different characters as delimiters so you can minimize escaping in your literals.

The syntax

The syntax for the % literals is a percent symbol (%) a letter which defines what kind of literal it is (Q, q, w, x, r) a delimiter,  the content, and the closing delimiter.

The delimiter can be any character, and is defined as whatever is immediately after the letter in the syntax. For example %Q!content! , the delimiter is the ! and it surrounds the content. There are special cases when the delimiter is { or (, the closing delimiter will be } or ) respectively.

%Q and %q (Percent Q): Strings

%Q!Some String of “Characters”! <==> ” Some String of \”Characters\” “

%Q is the equivalent to a double-quoted ruby string. #{expression} evaluation works just like in double-quoted strings, even if you use %Q{} as your delimiter!

You can also leave off the Q and it will have the same functionality. I recommend leaving the Q in to be more clear.

%q!Some String of “Characters”! <==> ‘Some String of Characters’

The %q is just like %Q, but acts the same as a single-quoted string. Whatever is inside the delimiters is returned as a string.

You can remember %Q is for strings because it acts like Quotes.

More info here: http://docs.huihoo.com/ruby/ruby-man-1.4/syntax.html#string

%W (Percent W): Arrays

%W(North South East West) <==> ["North", "South", "East", "West"]

%W (and %w) allow you to create an Array of strings without using quotes and commas.

The delimiter rules are the same as strings, but typically parentheses are used. The content inside the delimiters are split by white-space, and put into an array. This is great if you have a hard coded list of single word strings.

When using %W (capital W), it is evaluated as a double-quoted string. This allows you to use #{} to interpolate values. %w (lower-case w) will evaluate as a single quoted string.

You can remember %W is by thinking of it as a White-space divided Array.

More info here : http://docs.huihoo.com/ruby/ruby-man-1.4/syntax.html#array

%x (Percent x): System Execution

%x{ ls /usr/local } <==> `ls /usr/local`

%x allows you to call system commands, equivilent to wrapping the command in `s (grave accents). The benefit of the $x{} syntax is you don’t have to escape your accents in commands that use them.

You can remember to use X because it eXecutes a command.

More info here: http://docs.huihoo.com/ruby/ruby-man-1.4/syntax.html#command

%r (Percent r): Regular Expressions

%r{/usr/bin/} <==> /\/usr\/bin\//

%r is really handy for regular expressions that contain /s (forward slashes) which are the default delimiter for regular expressions and have to be escaped.

Remember to use %r with regular expressions.

More info here: http://docs.huihoo.com/ruby/ruby-man-1.4/syntax.html#regexp

I hope this information is helpful. Please leave a comment if this helped or if I left something out.

Are your web pages valid XHTML? Hopefully. But if you use any flash on your page, chances are, your page is not valid at all. Why is Flash crashing your validation parade? It’s the embed code that was generated. Most of the time people put Flash into a page, they use embed code created by either their content provider or their authoring application. These codes are almost invariably invalid XHTML.

Here comes Validifier to save the day! Validifier makes your Flash embed code Valid XHTML! There are a lot of different reasons embed code fails validation, Validifier takes care of all of them. Just paste your current code into the box, click Validify! and use the code provided. It’s Valid, Compatible, and Free!

This is the first product released by Done21, check out Almost Done: The Done21 Blog for more information on upcoming tools and product releases!

Many applications require the use of password based authentication. In many web applications, this is done using cookies/sessions, and the login mechanism is an HTML form that is submitted to the application. If you are trying to build a RESTful web service, or any service where this client may be automated, It becomes useful to utilize HTTP authentication.

It may not be immediately obvious from the CherryPy documentation, but CherryPy includes all the tools needed to implement HTTP authentication, both Digest and Basic. You can see what the CherryPy website has documented about authentication at the CherryPy Builtin Tools Page. The best documentation for this is available in the book: CherryPy Essentials: Rapid Python Web Application Development

Basic vs Digest

HTTP supports two types of authentication, basic and digest. To a user accessing a protected page through a web browser, both types look the same. The browser will prompt the user for a username and password. The difference is how the client (browser) sends the password to the server.

With basic authentication, the client sends the password in clear-text, so any malicious attacker who can see the request can see the password. With digest authentication, the client does not send the password, but rather a digest based on the password and other factors. The server will also compute the digest using the known correct password. If the digest sent by the client matches the one calculated by the server, authentication succeeds.

The catch with digest authentication is the users’ passwords must be stored stored in clear-text on the server** in order to calculate the digest. On the flipside, basic authentication must send the password in clear-text through the network. If you are going to use basic authentication, it is recommended you use SSL to prevent the password from being sniffed.

** This is not entirely true, The digest algorithm allows you to store a partially digested password on the server side, however CherryPy has no easy way to specify this.

Digest Authentication

The following code creates a simple application with a public page and a secure page using digest authentication. The server configuration defines that the /secure url is to be protected with digest authentication (via the tools.digest_auth Tool available in CherryPy)

Read the rest of this entry »

When using Digest Authentication with Cherrypy, if a client tries to authenticate a session from a page with a POST body, the credentials will be rejected even if they are correct. This is due to how Cherrypy’s digest_auth tool handles the initial request and request body.

The Problem

In Cherrypy 3, when utlizing Digest Authentication (via tools.digest_auth), if the first request to a protected area comes from a POST request (with HTTP body), the client will not be able to authenticate properly.

Example: Posting from an HTML form to a protected action, the client will be prompted for credentials. After supplying a good username and password, Cherrypy will reject and the request and ask for credentials again.

The Cause

First a primer on Digest Authentication:

The Process

1. The client requests a protected url URL (eg: /secret)
2. The server tries to authenticate the request from the HTTP headers for the URL. There are not credentials, so this fails. The server replies with an HTTP Status code of 401: Not Authorized
3. The client recieves this requests and gets a username and password (from an operator or database or other source)
4. The client requests the URL again, but adds the credentials to the “Authorization” HTTP Header.
5. The server tries again to authenticate. If the credentials are good, the resource at /secret is served. If authentication fails, The server responds with 401 …
6. rinse and repeat..

Read the rest of this entry »