webschuur.com

This is an updated version of my earlier post. Since msmtp is no longer needed, things are a lot simpler, hence the new article.

Problem: on development (and test) you don’t want to send out mail. But you /do/ want to test it. You certainly don’t want to be in my shoes when a client called me, telling she recieved dozens of confused and angry mails from users on her site, after I fired up cron on my local development machine. And sent out approximately 3000 notification mails to users, with stuff like “new post for you: “W000t, fieldz0rz developmentz in CCK is workinggggg!” (I am making this up now. Allthough…. ;) ) Problem: when debugging mail, you want to inspect the headers and often (in case of multipart or HTML mail) the source too. Most emailclients are crap for that (and right so: who other then the odd mail/webdeveloper needs to inspect the source of a mail. ever?)

Solution: the brilliant Ruby application named mailcatcher. This is a simple SMTP server and sendmail replacement that shows the mails sent to it in a handy webapplication. The webapplication features debug-tools such as headers, and source displaying.

UPDATE Please see the version of this article, the latest malcatcher has its own sendmail replacement, making installation for PHP a lot simpler.

Problem: on development (and test) you don’t want to send out mail. But you /do/ want to test it. You certainly don’t want to be in my shoes when a client called me, telling she recieved dozens of confused and angry mails from users on her site, after I fired up cron on my local development machine. And sent out approximately 3000 notification mails to users, with stuff like “new post for you: “W000t, fieldz0rz developmentz in CCK is workinggggg!”. Not cool.

Problem: when debugging mail, you want to inspect the headers and the source (in case of multipart or HTML mail). Most emailclients are crap for that (and right so: who other then the odd mail/webdeveloper needs to inspect the source of a mail. ever?)

Solution: the brilliant Ruby application named mailcatcher. This is a simple SMTP server, which shows the mails sent to it, in a handy webapplication. The webapplication features debug-tools such as headers, and source displaying.

The, by far, simplest solution to add some form of authentication in Rails is basic authentication. It has a lot of downsides, but the simplicity is such a benefit that it may just outweight.

Downsides are, amongst others:

• No users, no user-manangement.
• Your username and password are hardcoded in the application.
• No fancy or good looking login screens: just the basic HTTP login provided by your browser.
• No logout, other then closing the browser.

Here is a simple implementation for a simple app I needed.

A good practice. A notorious problem when working with Drupal. An impossibility when moulding Joomla! 1.x into your customers wishes: how to override defaults without forking off (within a tight planning and budget).

Every single CMS, Framework or development toolkit, in some way, allows you to start off, with what the makers think you need. And then allows you to change that into your own wishes. I have written before on this subject, and drew a CMS landscape. That landscape draws one thing: the flexibility. How far a tools can be stretched, so to say.

‘Drupal considered dangerous’ has been echoing trough the RSS feeds for the last days. More often then not, the word Ruby has been mentioned. To kill some FUD before it is even spread, I wrote a short intro on what Ruby and Ruby on Rails are, and how they stand newt to Drupal.

But there is more. Sure, Drupal can be considered dangerous, so should Perl, and Java be, and the same can be said about Wordpress, phpBB etceteras.

To state the obvious: For every problem there is a perfect solution. And not the other way around: For every perfect solution there is a problem. What I am saying is: Don’t consider Drupal the perfect solution for each problem. Don’t think That Ruby on Rails equals forty two.

To illustrate that, I put several solutions for your website in a diagram. This diagram is valid for most, but certainly not all website-development-projects; complete websites, not small improvements to existing sites. On the y-axis we see the amount of effort (development Time, development budget) needed to get a website up. On the x-axis we see the amount of flexibility we want to have. Every “solution” has an area in which it can be deployed, this is marked by an ellipse around the logo of the solution.

In many database driven applications (web-apps) you need some sort of user-system. A system to manage log-in facilities and rights management etceteras. A general “mistake” I see all over the place is that a user equals a person, in these systems. I decided to make a decent normalised concept for this and document it for once :).

The idea is that there are two separate entities: a user and a person. You may, or may not couple them, either now, or later. The benefit is that, using this concept, you have a choice: