• Akismet
  Probably the best method in existence for filtering out spam comments. I wouldn’t dare run a blog without it unless I wanted to spend hours a day deleting spam (except in certain situations: see #2).
• Disqus
  Replaces the built-in WP comment system with an externally hosted solution. Does a good job of filtering spam, and add a lot of functionality to comments that the stock WP install doesn’t possess.
• Feedsmith
  Redirects all your RSS feeds links to your Feedburner feeds. Really good if you want to keep track of how many subscribers you have, and use the other added functionality offered by Feedburner.
• No Self Pings
  Stops new posts from pinging other posts on your site. Pretty self-explanatory.
• Wordpress Database Backup
  Makes it really easy to backup your WP content. You can choose to store the backup on your server, have it mailed to you, or download it directly. It can also schedule automated backups that will be mailed to you.
• WP-Syntax
  Enables some pretty slick code highlighting for your blog posts. Check out this post for an example.
• WPtouch
  A nice little plugin that modifies the layout of your site when being viewed on an iPhone/iPod Touch.

There you have it, the 7 plugins that help me manage this site more effectively.

A really great short film by Garrett Murray and Shawn Morrison. Head over to Vimeo to watch it in HD.

The new Heroku is instant Ruby deployment with a pure Git workflow. In my estimation, there is no faster or easier way to get a Ruby web app online. We’re finally making good on our tagline: “Never think about servers or hosting again.”

Having never used Heroku, his post gave me enough incentive to try it out. I can now say that Adam speaks the truth about how easy it is to deploy onto Heroku. If you have a pre-existing Ruby app that’s already under version control in a Git repository, in the most basic case it takes literally three commands to deploy the app and have it up and running. Check out the quick start guide for details. If you are new to Ruby web app deployment, or looking for an easier solution for small apps, definitely take a look at Heroku.

*Note: I said Ruby, and not Rails, because Heroku can handle many other Ruby frameworks as well, such as Merb and Sinatra.

• Gustavo Duarte
• good coders code, great reuse
• CompSci.ca
• Hacker News

While Hacker News isn’t strictly a blog, it has an unusually high density of useful technology related information compared to Digg, Reddit, etc.

Fabric is similar to Capistrano, but I find it to be a little more lightweight and much easier to get up and running quickly. I tried to install it on my Macbook Pro using the Python ‘easy_install’ tool, but I think there was some type of dependancy problem, so I ended up installing it through MacPorts. Once it’s installed, all you need to do is create a file called ‘fabfile’ in the root of your project directory, and add the necessary tasks. In Fabric, each task is just a plain old Python function. Let’s say you build your application into a ‘dist’ directory. Here’s an example of a simple fabfile that will archive the dist directory, copy it to the production server, and extract it.

1
2
3
4
5
6
7
8
9

def production():
  config.fab_hosts = ['myserver.com']
 
def deploy():
  'Deploys the project to the remote hosts'
  require('fab_hosts', provided_by = [production])
  local("tar cvf project.tar dist')
  put("/remote/path/to/project.tar", "project.tar")
  run("tar xvf project.tar")

As you can probably guess, local() will run a command on your local machine, put() will copy a file over to your remote machine, and run() will run a command on your remote machine. There is also a sudo() function, which will run a command under sudo privileges on your remote machine. The production() function just tells Fabric which servers to run the deploy commands on. The config.fab_hosts variable is an array, so feel free to add as many hosts as you like. If you wish to setup multiple environments, then just add a different function for each (i.e. test(), staging(), production() ), and then add the extra environments to the ‘provided_by’ variable on line 6. Finally, deploy your project with the following command:

$ fab deploy

So as you can see, it’s very easy to get started with Fabric. I haven’t had a ton of experience with Capistrano, but I can tell you that it took me quite a bit longer to get a handle on Capistrano than it did with Fabric, but YMMV. I just think it’s a cool little tool that would be really useful for a wide variety of deployment situations.

by Oren Lavie ]]> http://jamiemurai.com/2009/02/her-morning-elegance/feed/ http://jamiemurai.com/2009/02/her-morning-elegance/ http://feedproxy.google.com/~r/jamiemurai/~3/F89DkRzddxo/ http://jamiemurai.com/2009/02/protect-wordpress-admin-with-ssl/#comments Thu, 05 Feb 2009 05:56:53 +0000 Jamie http://jamiemurai.com/?p=131 If you ever login to your Wordpress admin section while on a public network, you probably want to encrypt your login information with SSL so that unscrupulous people don’t start posting naked pictures of themselves on your blog. Ok, so that might be a stretch, but I still think it’s a good idea to protect your login information.

These instructions assume that you’re running Ubuntu 8.10 with Apache 2, and the latest version of Wordpress (2.7 at the time of this writing).  Let’s start off by creating our self-signed SSL certificate. Remember that when using a self-signed certificate, your browser will throw up a warning, but your traffic will still be encrypted and safe from prying eyes. To generate a self-signed certicate, run the following command, and when prompted, specify the full domain name that you want to protect (i.e. yoursite.com).

$ sudo make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /path/to/your/cert/mycert.pem

Set the /path/to/your/cert to wherever your want to store your self-signed certificate. Now we need to go ahead and activate the mod_ssl module and restart Apache.

$ sudo a2enmod ssl
$ sudo /etc/init.d/apache2 restart

Next up, we need to configure Apache to listen on port 443 (the standard SSL port) alongside the default port 80. We need to edit a couple files to do this. First, edit /etc/apache2/ports.conf to contain the following.

1
2
3
4
5

Listen 80
 
<IfModule mod_ssl.c>
    Listen 443
</IfModule>

Next, edit /etc/apache2/apache2.conf, and add the following if it doesn’t already exist.

1
2
3
4
5

NameVirtualHost *:80
 
<IfModule mod_ssl.c>
    NameVirtualHost *:443
</IfModule>

Lastly, we just need to enable SSL for the virtual host under which Wordpress is running. The easiest way to do it is to just copy the existing virtual host definition, change the port number, and add the lines to activate the SSL. This is done inside the virtual host definition file for your blog, most likely /etc/apache2/sites-available/yoursite.com or something similar.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<VirtualHost *:443>
  # Admin email, Server Name (domain name) and any aliases
  ServerAdmin admin@example.com
  ServerName  yoursite.com
  ServerAlias www.yoursite.com
 
  # Index file and Document Root (where the public files are located)
  DirectoryIndex index.php
  DocumentRoot /path/to/your/wordpress/install
 
  RewriteEngine On
  RewriteRule !^/wp-admin/(.*) - [C]
  RewriteRule !^/wp-login.php(.*) - [C]
  RewriteRule ^/(.*) http://yoursite.com/$1 [QSA,L]
 
  # Custom log file locations
  LogLevel warn
  ErrorLog  /path/to/your/logs/error.log
  CustomLog /path/to/your/logs/access.log combined
 
  SSLEngine on
  SSLCertificateFile /path/to/your/cert/mycert.pem
</VirtualHost>

Keep in mind that you still need the virtual host definition for the one running on port 80. This means that the 1 file should have definitions for 2 virtual hosts. Lines 11-14 just ensure that any https traffic directed at anything but the admin section is redirected to standard http. This isn’t necessarily required, I just personally prefer that only the admin section uses SSL.

All that’s left is to tell Wordpress that we want to use SSL for the admin section. This can be accomplished by adding a single line to your wp-config.php file. That is the same file where you defined your database connection info.

1

define('FORCE_SSL_ADMIN', true);

If you wish, instead, to only use SSL for the login, then you would replace the line above with the following.

1

define('FORCE_SSL_LOGIN', true);

Restart Apache one more time, and everything should be working properly. From now on, when you visit any admin page, you will automatically be redirected to the https version. This will ensure that no one is able to intercept your login information and fill your blog with pictures of lolcats.