Pasta and leeks

Sending email with Perl in 2010

Example of how you should send email in 2010 with Perl.

#!/usr/bin/perl -w
use strict;

use Email::Sender::Simple qw(sendmail);
use Email::Simple;
use Email::Simple::Creator;

my $email = Email::Simple->create(
    header => [
        To      => '"Peter Foo" <foo@example.com>',
        From    => '"Peter Bar" <bar@example.org>',
        Subject => "What's up",
    ],
    body => "Hey, how are you doing?",
);

sendmail($email);

You can see that this is simple enough. First you create an Email::Simple object. This object will format the message that wil be sent.

After that sendmail will send this message using it's default transport.

The nice thing about using these modules is that you can, while testing, replace the default transport with testing modules.

use Test::More;
BEGIN { $ENV{EMAIL_SENDER_TRANSPORT} = 'Test' }
use YourModule;

YourModule->run;
my @deliveries = Email::Sender::Simple->default_transport->deliveries;
is(@deliveries, 1);

This way you can check how many emails were send using in the code your testing. By picking apart @deliviries you can check out the text of the emails that were send. See Email::Sender::Transport::Test for more information about this.

Help prove help you

I use prove from Test::Harness to test the code of my Perl projects. The program prove runs tests files and summarizes the output. If tests fail then it shows the error in its output.

The problem is, my defaults aren't the same as the defaults that prove uses. I keep my main application files in app/lib and a few vendor libraries in vendor. The problem with this is that I have type out the options of prove every time I wanted to test. For the longest time I used a Makefile to solve this problem.

Then I found out about .proverc. If you put this file in your current directory of in your home directory, then prove will use each line as an extra command-line option.

The .proverc in the root dir of my project looks like this:

-Iapp/lib
-Ivendor
-r

It includes two extra directories in the Perl include path; app/lib and vendor. It also find all test files recursively in the t directory, which is also not a default setting of prove.

Buzz paper cuts

In the same way that Ubuntu has a list of problems that are trivially fixable Paper cuts, you could also do that for other programs. Google Buzz is a service that I use at the moment. I like this program, because it seems to take public standards into account and it will allow decentralized communication between people. So today I will spend some time to write down the few problems that I found that will be trivially fixable.

Ubuntu's definition is this:

a paper cut is a trivially fixable usability bug that the average user would encounter in default installation of Ubuntu or Kubuntu Desktop Edition*.

Paper cuts

1. Muting a Buzz is very slow. This seems to be a problem with the fade. The thing is, it is nice that the Buzz fades away, but I don't need to see it. It should be fast. It also moves the viewpoint to the top. Please don't move my screen.

2. Clicking a Buzz that isn't selected will move the screen to the start of the Buzz. If you scroll up from the next Buzz to a comment above in the previous Buzz, and then click on the comments, it will move the viewpoint to the start of the Buzz.

3. The @-prefix for responding to people is ugly, when used with the domain name. There are better ways to do this. A few suggestions: '->', 'r:', '#', '>', '>>'. And I say screw backward compatibility and expectations.

So if you like the things I said here, please find a way to share it with some people. There seem to be quite a few places where that's possible today.

Using user-generated HTML on webpages

Jeff on Coding Horror writes:

Among programmers of any experience, it is generally regarded as A Bad Idea (tm) to attempt to parse HTML with regular expressions.

You should read the rest of the article. I'm mostly of the same opinion about this as Jeff. Additionally I think that parsing HTML is a bad idea in the first place.

One of the examples Jeff gives for parsing HTML is sanitizing user input. The user input will be used on the website as comments for example. I think allowing people to write HTML and putting it on a webpage is the wrong way to go.

If you want to include user input in a web page there are only two ways to do it:

1. Encode all special HTML characters. You can start with <, >, &, " and '. If you encode these then people can send all the HTML they want, but it's encoded and will not affect your web page. For Perl I recommend the HTML::Entities module.

2. The other way to allow HTML is, on a page, where it is their own. If they want to break their own web page, they should be allowed to do that. This doesn't mean profiles on websites, but actual websites that are completly their own.. So you say it is HTML and then use the input verbatim.

If you want to include some kind of formatting for the input, you can use a markup language. Use a markup language that allows to specify as much formatting as you like, this could be a HTML-like language, that only transforms the tags that you want. Therest of the text should be HTML encoded.

I would have lost interest somewhere between...

Adam Turoff wrote:

I could have written my taxicab number search in C or Java, but I would have lost interest somewhere between #include <stdio.h> or public static void main(String args[]) and firing up the compiler.

It's a shame this happens so often. It should be easier to just write the part your idea is about and then insert it into some thing, that will make the rest work.

Before being able to try and research your ideas, you need to have the basic code working. When people ask: why would you write your own X software? Where X is one of the pieces of software you have written, that looks like something that already exists. This would be the answer.

If there is a program or system that works for 95 percent or even 90, that would take a lot of time write. Then there is almost no incentive to create (or test) a similar tool. An example of this would be Google. Or a computer game that uses a 3D engine.

These all take many years to create, and there is not much to gain from the work that is done to get to the same level. To innovate you need to have a basis; but you will be bankrupt before you even get near.

The problem with Wave (and other things)

A few days ago I started using Wave for some real projects. I found out that Wave is not really hard to use. The problem is that the network effect is kicking in, but in the opposite way.

Wave is a communication tool. You can use it to send messages and collaborate on projects with other people. And I think the problem here, is that the other people are missing.

I remember the first few years that I had internet. Not many friends were using email. I had email, but I had no one to send emails to. The same is happening with Wave now to. What use is it to send an email to someone, if you can't be sure that that person will read it.

I have a simple solution to this problem: install a Wave notifier. At the moment I use a notifier that works as extension in Chrome. It's non intrusive and shows a little number when I have new unread Waves. No interruption and I can take a look at the Wave that people sent me.

Wave me at peter.stuifzand@googlewave.com.

Simple tool for finding an external ip address

I just released a small program that gets the ip address or your computer. The nice thing is, this service is REST-based.

You can find it at Stuifzand Software Tools.