I came across an article in Nature today that discusses Stephen Hawking’s theory of how the universe began. Basically, he assumes that every possible history of the universe was present in the first few instances after the Big Bang. Within that period the histories that lead to our present universe began to dominate, while the other possibilities whithered away. Cool concept!
Customers of Sympatico’s high-speed Internet service receive instructions on how to set up their email; however, these settings are aimed at people using Outlook, Netscape, or Eudora. What I needed were instructions on how to configure my local SMTP server, Postfix, with Sympatico. Of course, that information is not available. This document details how I figured out the settings required to make smtphm.sympatico.ca happy.
You need a version of Postfix built with TLS and SASL support enabled. If your distribution doesn’t come with it pre-built follow the instructions at:
On my Debian unstable system I simply did:
apt-get install postfix libsasl2-modulesI’m assuming that your Postfix configuration directory it /etc/postfix. Adjust appropriately to accommodate your system.
To use SASL we need a password file containing our user name and password for the server we are connecting to. Per Sympatico’s instructions the server is smtphm.sympatico.ca.
cd /etc/postfix
mkdir sasl && cd sasl
echo "[smtphm.sympatico.ca] USERNAME@symaptico.ca:PASSWORD" > passwd
postmap hash:passwdThe above creates the password file and the hash-based database file that Postfix uses. Of course replace USERNAME with your [% symaptico %] user name, and PASSWORD with your password (the email password, not the b1 password to access the Internet.)
Make sure in your main.cf you have configured your relayhost as: relayhost = [smtphm.sympatico.ca]
Finally, add the following lines to your main.cf file:
# Enable TLS/SASL for the smtphm.sympatico.ca server
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes
tls_random_source = dev:/dev/urandom
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/passwd
smtp_sasl_security_options = Restart Postfix and send a test message. If all went well you should see the successful sending of the message in the Postfix log file.
Good luck!
While reading various blogs online I came across a post mentioning a great Firefox add-on called FireBug. According to the author’s write-up:
FireBug is a new tool that aids with debugging Javascript, DHTML, and Ajax. It is like a combination of the Javascript Console, DOM Inspector, and a command line Javascript interpreter.
I would highly recommend this add-on for anyone doing “Web 2.0” development.
Every working programmer or software developer ought to have a large personal library of books they consider essential–these books are mine. My list started off being very language heavy (mostly Perl), but as I’ve gotten older (and gained more experience) I’ve gravitated towards broader topics in software development.
I try to read a variety of books. In the past the local library was down the street from where I lived, but now I prefer reading ebooks (either purchased or borrowed.)
There is a large gap where no books were recorded while the site was offline: a regret as I know I read during those periods.
(If you’re a programmer or developer, check out my collection of programming books.)
For the past week I’ve been employed as a Perl web application developer at chaffee::interactive. It’s been an interesting week. I’m now starting to get the hang of the development environment. A lot of the code is older, so I’ve been spending most of my time updating the code.
It’s a great job, and I love the fact that I telecommute to work. It’s especially nice when I wake up in the morning and see a foot of snow.
I’ve done a lot of CGI application programming. Over the years I’ve developed a CGI::Application base class that I derive my applications from. I’ve called my Perl module WormBytes::CGI::Application since it derives from CGI::Application. It brings in all the modules I normally use in my CGI programming.
In addition to the required modules, I’ve extended the class to handle session management. There is also rudimentary support for user management in the base code. Nothing fancy, but enough to do simple log-in style applications. It can be easily extended in sub-classes if needed.
The session management code uses a UUID numbering system. The idea is that each session ID needs a unique ID, but the IDs do not need to be random. Uniqueness is more important. To ensure that sessions can not be hi-jacked, an additional HMAC cookie is included with the session ID cookie. This HMAC includes a random number stored in the session on the server plus a hash of information from the client. The client information is not required, but it does help if the information is present. Because of the random key that’s used in the hash it is impossible to guess what the HMAC will be. It is checked at the beginning of each request and modified at the end of each request. Therefore, the HMAC is constantly changing and is constantly validated. In this, the base class, an invalid session causes the system to log the user out.
There are also certain helper functions like tt_pre_process() that adds certain objects and variables to all templates. cgi_untaint() creates a CGI::Untaint object for later use. Finally, redirect_url() simply redirects the client to a new location.
I find this module to be a great base for all my CGI applications.
I had an interview for a Perl programming position the other day, but I got stuck on their request for sample code showing my Perl programming skills. I have done Perl programming for eight years, but their requirements for sample work did not seem to match anything I had done. I finally found something I could show, but I wasn’t entirely pleased with it. Therefore, I posted a meditation to Perl Monks asking how they would Show Sample Source Code without Modules
Maybe my fellow monks can offer some suggestions for next time. (All though, I would really like to get the job I interviewed for.)
Emacs is my editor of choice, and like most people who use Emacs I have customized it to suite my personal taste. I have included copies of my customizations so that others may build on what I’ve created, or simply have a more pleasant working environment.
This is my main .emacs file. It contains the bulk of the customizations, but it does include a few other features and functions that other people may find useful. Some of the code is written by me, and other parts I’ve found on the net.
To help me manage my time and my projects I have turned to the plannel-el (PlannerMode) major mode. Since I have worked as a independent IT consultant, I often need to track the number of hours I work on projects for various clients. I have customized and extended planner-el to allow me to clock in and out of a task. Upon clock-out the system will automatically prompt me for a description of what I did during the clocked-in time, and then write a note on the task page for the project detailing the amount of time I spent, and allowing me to classify the work performed. I then have a separate Perl script that takes the raw task pages and produces an invoice. I think it’s a very slick setup.
I have done a lot of firmware programming on various Microchip PIC micro-controllers, and I found that the default asm-mode.el script did not handle the idiosyncrasies of the PIC assembly language very well. Therefore, I created pic-asm-mode.el as an extension to asm-mode.el. It syntax highlights PIC assembly mnemonics and handles formatting correctly.
Damian Conway gave a tutorial in 2004 titled “Best Practices Perl” that describes a series of best practices concerning programming Perl applications. (Mike Kruckenberg wrote up a review of the presentation.) I agree with most of his points, but I do have a bit of a problem with the section of POD documenting. Damian mentions that: “put POD after END since the parser doesn’t have to parse the POD.”
I can agree with Damian’s point about not needing to parse the lines, but normally you would have comments there anyway. I believe it’s better to have the documentation in POD format rather than as comments. There is no appreciable difference in parsing speed between parsing POD and parsing comments.
Damian’s point that POD documentation at the end does not need to follow the layout of the code does have merit, but I believe it is outweighed by the need to keep code and documentation in sync. With the documentation as close as possible to the actual code it is easier to keep them aligned.
Finally, if performance is most important then all POD and all comments should be stripped from the files before placing in production. This would eliminate all parsing time. I would argue that this may be a good trade-off in specific instances, but not in general.
All told, I would recommend any Perl programmer picking up a copy of Damian’s book Perl Best Practices and incorporate those ideas they feel comfortable with. Highly recommended.