Feature entry

Photo by Michael Biven
First thanks to everyone who helped pull this off: Mom, Dad, Carrie, Lane, Kegan, Biddy, Tom, Charm City Cakes, the staff at Tsunami’s Baltimore and everyone who showed up. Without these people the event wouldn’t have happened, the cake would not have been made and I would have probably had a heart [...]

Millennium Falcon Cake: The KY to Maryland run in Less Than Nine Hours

Announcing BarCamp Louisville

I’m happy to announce that BarCamp will arriving in Louisville this year during the IdeaFestival (September 25-27). The venue and the exact dates are still being worked out, but we already have a couple of sponsors lined up. This will be a great free event that should help act as a catalyst for the local tech and creative community by bringing them together and mixing them up with those in town for IF. So if you’re in the Louisville area or planning on attending IF why not go over and register yourself and maybe even propose a session or two?

A couple of other things for those in the Louisville area is a possible new Coworking space and a geek dinner on 6/30. There is a new effort to get a Coworking space started in Louisville that you should check out. And don’t miss out on Monday nights Louisville Geek Dinner at Bluegrass Brewery Company for a chance to casually chat up with your local peers.

More Optimization for your site

Sill looking for a way to improve your site’s performance after trying other methods? Well Tenni Theurer, a Product Optimization Manager at Yahoo has five great articles that covers reducing the number of HTTP requests, explains web browser caching, the effect of HTTP cookies (co-written by Patty Chi), parallel downloads (co-written by Steve Souders) and details on caching for the iPhone and iPod Touch.

If you find yourself out growing your current setup and need to look for something a bit more robust take a read over Demystifying Clouds by John Willis. He gives an excellent description on what cloud computing is and a run down on the services currently available.

Please oh please…

Watching the example of the newspaper at the beginning of the presentation below, “Foldable Interactive Displays” by Johnny Chung Lee. I really want a small, flexible laptop that uses a display like shown with the keyboard / multitouch interface from the iPhone. Small and have enough to handle a web browsing, email client, a feed reader, word processor and wireless. Perfect for writing out ideas, surfing while in bed, on the couch and would make for a more durable notebook.

via Ask E.T.: Residing in spaceland: Johnny Chung Lee’s imaginative work

Migrating WordPress to a different domain or server

Two common questions I see both at work and from friends is how best to migrate a WordPress site from one server to another or how to go about changing the Domain Name. There are four different scenarios that will affect the changes you would be making:

Changing the Domain Name only or in combination with one of the scenarios below
Moving from one self-installed server to another self-installed server
Moving from a self-installed server to WordPress.com
Moving from WordPress.com to a self-installed server

Below are the steps that I suggest including backups, starting DNS changes, configuring the new server, database import and changes, verifying the new server, final DNS changes, 301 redirects and final verification. I will point out which applies to each of the different scenarios and also briefly go over a few tools that can help at the end of the guide. Remember though I don’t expect anything bad to happen this guide is completely use at your own risk and I do not take responsibility for anything resulting from following them.

Backup:

(applies to all four scenarios)

The very first thing to do is make a complete backup of the existing site for a few different reasons. First if you really do care about the work and effort you are putting into your site take the extra time to backup it up on some sort of regular schedule. Next is that we are about to make changes to the site and you will want a recent (as in the day your making the changes) backup to fall back on just in case something goes awry. And if you are moving from a self-installed copy of WordPress to another you will already have a copy of the plugins, themes and uploads to copy over to the new server. You do already have a current copy of WordPress and any plugins you have installed right?

So now on to backing up your site. I would suggest that you follow Lorelle’s guide to create a backup for WordPress and keep in mind the XML export would be needed if you are migrating from or to WordPress.com.

First set of DNS changes:

(applies to all four scenarios)

Try to make the following changes in DNS at least 24 hours before you plan to switch to the new domain name or server. Drop the Time To Live (TTL) for the A record that the blog uses down to something like 300 (make note of it’s original setting since you will need to change it back later). The TTL is in seconds so the 300 is equal to 5 minutes. During the migration to the new server you will be getting a new IP address, this way the TTL is dropped and since you made the change at least 24 hours before your migration you should only be looking at a 5 minute hiccup during the switch to the new server.

Configuring the new server:

(applies to all four scenarios)

Next on the new server go ahead and complete the basic install of WordPress. If you are moving to WordPress.com configure the new site, keep it set to private, but do not enable the domain alias at this point (under Options > Domains). For self-installed copies of WordPress depending on what type of access you have with the server you may need to edit your hosts file on your local computer to complete the install since you do not have DNS pointing to the new IP address, specifically when you run the file wp-admin/install.php.

Importing the data:

(applies to all four scenarios)

Now that we have the basic WordPress site completed it is time to import the data (posts, comments, pages) into the new server. Remember if you will be changing the Domain Name as well you will need to make the necessary changes in two tables in the database which I will go over at the end of this step.

If you are moving from one self-installed copy of WordPress to another use the backup of the database to create a new database on the new server. You will need to recreate the database user and edit the file wp-config.php to reflect any changes in the database name, user and password.

If you are moving to or from WordPress.com you will only be able to import the data to the new server from the XML export you created earlier. From the dashboard at the new WordPress.com site go to Manage > Import and then select WordPress. You will then be prompted to browse to the location of the XML from the previous export. Also when importing the file you will be asked if you want to change the author for the posts and drafts you are importing.

If you have changed the domain name used for the site and used the database backup to import your data you will need to make changes to two different tables. We need to change the Blog Address (URL), WordPress Address (URL) and the GUID for the posts. The Blog Address is listed as siteurl in the field option_name and the WordPress Address is home in the same field. You can use either phpMyAdmin or mysql if you have shell access, but the examples I give will be using phpMyAdmin.

The first two fields are located in the tables wp_options. After logging into phpMyAdmin click on the name of the database in the left hand side (you will need to select it form the drop down box if you have multiple databases) and then click on the SQL tab at the top of the page. In the “Run SQL query/queries” text box enter the following and press “Go” to change the Blog Address (URL):

UPDATE wp_options SET option_value =
replace(option_value, 'http://old.domain.com', 'http://new.domain.com')
WHERE option_name = 'home';

And to change the WordPress Address (URL):

(remember if you have your WordPress files in its own separate directory this URL will be different than the Blog Address)

UPDATE wp_options SET option_value =
replace(option_value, 'http://old.domain.com', 'http://new.domain.com')
WHERE option_name = 'siteurl';

To update the GUID with the new domain name enter:

UPDATE wp_posts SET guid = replace(guid, 'http://old.domain.com','http://new.domain.com');

And for any links to other pages or posts internally in your site with absolute URLs:

UPDATE wp_posts SET post_content =
replace(post_content, 'http://old.domain.com', 'http://new.domain.com');

Now that we have the data over get your theme and any plugins that you will be using configured on the new site.

Checking our work up to this point:

(applies to all four scenarios)

At this point you should have the new site up and running on the new server, but before we make it live by updating DNS with the new IP address or enabling the domain alias in WordPress.com you should take a moment to verify (thanks to the edit to the hosts file) that everything looks and behaves correctly. Consider viewing the site both while you are logged in as an admin and while logged out. You won’t be able to view a WordPress.com site while logged out unless you create a new user account and grant it permissions to access the site under Options > Privacy.

Final changes to DNS:

(applies to all scenarios)

After you are satisfied with the new install make the final change to DNS by either changing the A record or enabling the domain alias in WordPress.com. The changes for the A record includes updating it with the new IP address and changing the TTL back to it’s original setting.

301 redirects:

(applies to scenarios where the domain name changes)

So you just changed the domain name for the site and you might be asking yourself what about any links to the old domain name that are still getting spit out by search engines. You can take care of this with a simple .htaccess file in the root of your old domain names web server. Simply create or edit the file to include the following:

RedirectMatch permanent (.*) http://new-doamin.com$1

This will send any links to the old domain to their corresponding page at the new domain name as long as you do not make changes in the permalink structure. The longer you can leave this the better, but you should start seeing search engines updating with the new link, because we used a permanent redirect.

Final checks:

(applies to all scenarios)

It would be easy to think you’re done and stop right here, but I would suggest a couple more checks. Though you might have to wait a few hours or a day depending on how you made your DNS changes, take advantage of Google’s Webmaster tools, the Feed Validator, or Yahoo! Site Explorer to verify your sites robots.txt, sitemap, and any errors that they encounter with your site or feed. Also keep an eye on your bandwidth after the change just in case you have misconfigured something that is causing any problems with the site making calls to itself (ie using the RSS widget to load its own RSS feed) or anything else that we might not think of at the moment.

Closing and additional tools to help:

If you are planning on moving your site I hope you’ve found this guide useful, good luck and enjoy.

A few additional tips to help you check things as you go or troubleshoot (hopefully not) any problems.

Flush your local DNS cache:

In addition to making the changes in your local compuaters hosts file you may need to clear out your local DNS cache.

Mac OS 10.4 and older:

lookupd -flushcache

Mac OS 10.5:

dscacheutil -flushcache

Windows XP and newer (might work on Windows 2000):

ipconfig /flushdns

Query DNS servers with dig:

Being able to query the DNS server you are using or others is another handy skill to have when your mucking around in your sites DNS. On a Mac running OS X or Linux you can query your’s and other DNS server to see what they have listed for your domain using dig.

check your current DNS server for the A record

dig domain.com

check your current DNS server for the MX record

dig domain.com mx

check your current DNS server for the A record on a subdomain

dig sub.domain.com

check a different DNS server for the A record

dig @DNS.server.com domain.com

check a different DNS server for the MX record

dig @DNS.server.com domain.com mx

check a different DNS server for the A record on a subdomain

dig @DNS.server.com sub.domain.com

Tumbleblogs and reblogging

There has been an interesting conversation bouncing between a few tumbleblogs over at Tumblr on reblogging and how tumbleblogs compliment blogs that got me thinking on how Tumblr’s reblog button can be improved and to improve comments for blogs.

If you’re not familiar with the term a tumbleblog is a short version of a what we now know as a blog combining different media types (audio, video, pictures, links, quotes, conversations (ITC / Tweets), and code snippets). Think of the Moleskin galleries you might have seen on Flickr with everything from notes, sketches and poems as an analog version of a tumbleblog. It is not so much as moving blogging in a new direction, but really just going back to what it used to be before permalinks, Google and Digg.

One thing Tumblr does very well is allowing people to use their “reblog” button to quickly add content from other sites hosted on Tumblr and still give attribution to the original author. The drawback is that both the original content and the persons site needs to be hosted on Tumblr. I think we would be better off if popular CMS’s like WordPress, Drupal and others started adding the authors name, blog’s title, and the post’s title in one of the available microformats (not sure which if any would be the best to use, still reading through them). Not only would a bookmarklet or other tool be possible to work just like the “reblog” button for any site supporting this, but other services like Ma.gnolia and Del.icio.us would have an easier time pulling in some basic information for a site or post.

While some probably would not view them as a true tumbleblog both Planet and Feedjack have and can be used to create your own. Remember with exception to adding options to change your theme, create posts and additional features like the “reblog” button most tumbleblogs will just pull in a set feeds that you give it. And that last part is pretty much all what Planet and Feedjack does. Some of the earlier examples of Planet that I came across were usually for a Linux group pulling in their members blog feeds (maybe even for a specific linux feed) and conversations from a IRC bot they would have running in their channel. Very stream of conscious and I can remember seeing many a conversation playing out in it. If you were to see the members individual site these little messages wouldn’t make since at all unless you viewed after they had been pooled together using the Planet.

Taking that idea of how those conversations worked across multiple sites I’m playing with the idea of moving the comments on a blog over to a service like Twitter or Pownce. This would get (hopefully) more people involved or at least following the conversation. The only downside would be starting to see more spam ending up in either service.

Installing Ruby on Rails on Mac OS 10.5 or patching Dan Benjamin’s guide

Update: Dan has posted his updated guide for installing Ruby on Rails on Leopard.

I don’t think there are too many people who hasn’t come across either of Dan Benjamin’s guides when looking to install Ruby on Rails on a Mac. They are simple, to the point and you could basically copy and paste to get Ruby, Rails, MySQL and depending on which guide either Mongrel or LightTPD installed, but since the release of Leopard the instructions if unaltered would fail when installing Readline, Ruby and Subversion. Dan has mentioned that he will be providing an update to the guide for Leopard users, but with a new baby and job it might (and justifiably so) be a bit before he has the chance to finish them. What I’m going to cover are the additional steps I added to Dan’s guide to get everything up and running for me. First thing to do is read his guide making sure to note the following sections: What’s needed (except we are using OS 10.5 and Xcode 3.0), bash, Quick Warning, sudo and paths. To get the parts of Dan’s guide that would fail to work we will be applying some patches to Readline, Ruby and Subversion. If you are uncomfortable with this then I would suggest that you wait for his updated guide. And if you haven’t already tried installing the unaltered version on Leopard, consider running through each step to see the error before and after the patches. And remember just as he points out himself these instructions are completely use at your own risk and I do not take responsibility for anything resulting from following them.

Before you begin

Make sure to follow the steps from his guide to install Xcode, update your path and create the directory at /usr/local/src if you have not already done so.

Ruby

If you have tried his guide while using Leopard you probably got stuck at the first step when trying to compile readline. You will need to apply a patch from the developers, because the unpatched version of readline checks for the version of the operating system but does not include darwin9 (Leopard) in it’s list. We will be applying a patch to the file support/shobj-conf located in the readline-5.2 directory in /usr/local/src/ and then we can compile it without getting an error. You should also notice that we are installing the latest stable version.

curl -O ftp://ftp.gnu.org/gnu/readline/readline-5.2.tar.gz
tar xzvf readline-5.2.tar.gz
cd readline-5.2
curl -O http://ftp.gnu.org/gnu/readline/readline-5.2-patches/readline52-012
patch -p0 < readline52-012
./configure --prefix=/usr/local
make
sudo make install
cd ..

And now on to installing Ruby. While looking into why Ruby would segfault during the install I came across Laurent Sansonetti’s explanation and the set of patches that are applied to Ruby by Apple for the version that Mac OS ships with.

curl -O ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6-p111.tar.gz
tar xzvf ruby-1.8.6-p111.tar.gz
cd ruby-1.8.6-p111
curl http://chopine.be/lrz/ruby-osx-patches/dot-darwin.diff | patch -p0
curl http://chopine.be/lrz/ruby-osx-patches/etc-irbrc.diff | patch -p0
curl http://chopine.be/lrz/ruby-osx-patches/ignore-gsetcontext.diff | patch -p0
curl http://chopine.be/lrz/ruby-osx-patches/md5_sha1_commoncrypto.diff | patch -p0
curl http://chopine.be/lrz/ruby-osx-patches/use-dyld.diff | patch -p0
curl http://chopine.be/lrz/ruby-osx-patches/use-setreugid.diff | patch -p0
curl http://chopine.be/lrz/ruby-osx-patches/words-bigendian-from-arch.diff | patch -p0
./configure --prefix=/usr/local --enable-pthread --with-readline-dir=/usr/local --enable-shared
make
sudo make install
sudo make install-doc
cd ..


RubyGems

Only change here is using the current version.

curl -O http://files.rubyforge.mmmultiworks.com/rubygems/rubygems-1.0.1.tgz
tar xzvf rubygems-1.0.1.tgz
cd rubygems-1.0.1
sudo /usr/local/bin/ruby setup.rb
cd ..

Ruby on Rails

sudo gem install rails --include-dependencies

Remember one change in Rails 2.0.2 is that SQLite3 is now the default database. When you followed Dan’s instructions and changed the path you lost the SQLite3 bindings for Rails that Leopard ships with so we need to add them back.

gem install sqlite3-ruby

Mongrel

Just like RubyGems no changes here except it will be grabbing the latest version.

sudo gem install mongrel --include-dependencies

Subversion

This would be the next step that you should see an error while following the unaltered guide. I came across a patch from Brian D. Wells that allowed for me to complete the install.

curl -O http://subversion.tigris.org/downloads/subversion-1.4.6.tar.gz
curl -O http://subversion.tigris.org/downloads/subversion-deps-1.4.6.tar.gz
tar xzvf subversion-1.4.6.tar.gz
tar xzvf subversion-deps-1.4.6.tar.gz
cd subversion-1.4.6
curl -O http://homepage.mac.com/brianwells/.Public/apr_darwin_smb_patch
patch -d apr -p0 <apr_darwin_smb_patch
./configure --prefix=/usr/local --with-openssl --with-ssl --with-zlib
Edit the file /usr/local/src/subversion-1.4.6/apr/include/apr.h
Changing the line #define APR_HAS_SENDFILE 1 to #define APR_HAS_SENDFILE 0
make
sudo make install
cd ..

Capistrano

sudo gem install capistrano --include-dependencies
sudo gem install termios --include-dependencies

MySQL

And finally we’re ready to follow Dan’s instructions to install MySQL.

Alternatives

A big thanks to Dan for creating each of these guides and keeping them updated over the years. I hope you find these additions useful and remember usually there are a few different alternatives to doing something.

Optimizing performance for WordPress

Taking responsibility of your WordPress site by keeping it up to date to the latest version and managing it’s load on the server hosting it is just as important as the content you’re writing for it. Security updates, performance improvements and other bug fixes will help keep your site running smoothly, but there are a few other steps you can take to improve it’s performance.

Keeping WordPress in check:

First thing is to make sure your install is current. It’s amazing the number of sites that you can come across that are still running older versions even with great tools like the Wordpress Automatic Upgrade plugin written by Keith Dsouza of Techie Buzz which is a very simple way to update your site. It will backup your sites files and database, download the latest version of WordPress, place the site in maintenance mode (a simple splash screen), de-activate all plugins, updates WordPress and then reactivates the plugins after you have clicked the upgrade link. This step is probably one of the most missed tasks in maintaining your WordPress site and remember we’re not just talking about performance improvements here, but also keeping it update to any available security patches and preventing exploits like adding spam or reading copies of your saved drafts.

Caching in WordPress:

After making sure you have the latest version installed using caching is one of the simplest ways to improve your sites load times and also help reduce its load on the server. Donncha O Caoimh’s WordPress Super Cache plugin is an improved version of the WP-Cache 2 plugin by Ricardo Galli Granda. One improvement is that unlike the WP-Cache 2 plugin Super Cache will actually create a static HTML page instead of still having some PHP calls when served from the cache. It will serve simple HTML without having to use any PHP as long as the user visiting the site is not logged in or has not posted a comment. If they have commented or are logged in and tries to load a cached page the normal WP-Cache function will serve the page, but one of the best features of this plugin is the “LockDown” button. This will prevent the cache files from being deleted when a new comment is made. So if you think a post of yours is going to get hit by Digg or Slashdot you can have the server ready for the traffic or simply enable this after noticing any high traffic.

Comment and Pingback Spam:

Besides being just plain annoying comment and pingback spam can actually increase the load generated by your site. First make sure you are using the Akistmet plugin that comes with WordPress, then take a look at the using the comment blacklist feature under Options > Discussion. This will help reduce the number of spam that finds its way into your comments and pingbacks, but we also want to prevent blatant spam from posting at all to keep your queue of stuff marked as such as low as possible. To do that you can add some additional lines to your sites .htaccess file that I found at Perishable Press. By adding the rule found at the previous link you can keep any spammer from directly calling the file wp-comments-post.php to post a comment. If you do find that you have a large number of items marked as spam (hundreds or more of pages when you got to Comments > Akismet Spam) keep in mind that Akismet will automatically delete messages marked as spam greater than 15 days old. Depending on how your sever is performing it’s possible you might see the site slow down while its deleting all of those items marked as spam (a little later I’ll show you a tool that will help see what is going on in the background).

Offload as much as possible:

Any images, videos, audio, CSS and JavaScript files that you are serving from your server increase the number of requests that the web browser makes each time it loads your site. The good thing is that there are some very simple alternatives to place these files on a different server that is configured especially to serve static files. Instead of just using the obvious services from Flickr and YouTube for images and videos you can also use services like Amazon’s S3 to serve the CSS and any JavaScript files that your site is using. Also take a look at any additional JavaScript that you are adding for statistics, ads, calendars or basically any other information your are adding to it that is not a post or page. Consider using a web statistics product that is hosted on a different server (Google Analytics) instead of one that is served from your site like Mint for example. Other web stats tools like AWStats and Webalizer don’t actually place any scripts on the site, but instead use the web servers access logs to generate the statistics, either of these tools would allow you to remove a call to any type of a webstats tool, but remember these are generally created from a scheduled job that is run and would not provide you with any type of real time reporting.

Pruning the Plugins:

If there are any plugins that you are not using you should deactivate and remove them from the wp-contents/plugins directory. After that take a close look at each plugin and try to determine the value your site gets out of it and what actually goes on in the background when the it is used. In the next section I’ll briefly go over a few tools that you can use, but remember to check both the WordPress Codex, forums and the plugins site as some of the question you’re about to ask may already been answered. If the plugin actually interacts with the database look at the number of queries that it is sending to it and try to determine if it using any type of caching or can be rewritten without using the database. If you are lucky enough to find a way to improve it’s performance make sure to submit a patch to the plugins author to allow others to benefit from your hard work.

How to see what is going on:

Here are a few tools you can use to see what is going on in the background on the web server your site is hosted on.

Firebug

A Firefox add-on giving you tools to edit, troubleshoot and view CSS, HTML and JavaScript in real time for a web page. Allowing you to see the load times and sizes of individual files (images, CSS and JavaScript) it can help pin down what is slowing down a site. And if you add the YSlow add-on from the Yahoo Developer Network it will integrate with Firebug to give you some feedback on your sites performance and some suggestions on how to improve things.

LiveHTTPHeaders

Another FireFox add-on LiveHTTPHeaders will display the http headers showing you any redirects, sessions, cookies, compression or caching that may be happening when viewing your site.

Mytop

To see what queries are running in your database you could use mytop which is similar to the Top command, but looks at MySQL instead. This tool would require that you have shell access and the ability to install it if it is not already there, but it’s a great way to see real time what your sites is asking the database for and to do.

Access / Error logs

Looking at your web servers access and error logs can give you a great deal of information. Being able to see any web server or PHP errors, where all of that traffic is coming from if the site starts to crawl to a halt from high traffic, if it is getting crawled or scraped by a bot, and can show suspicious activity. If you see a problem or suspect something unusual is happening these logs should be one of the first places you look.

Phpinfo

And don’t forget to take a look at how PHP is setup by using phpinfo. Create a file called phpinfo.php and enter only the following in it:

<?php

phpinfo();

?>

Save that and place it in your sites directory on the web server and you will be able to view the options, extensions, and a slew of additional information on PHP and the web server when you load the file in your web browser.

OK, that was a basic overview of some steps I take to optimize a WordPress site (or any site for that matter), but don’t forget another way to keep things humming along would be to consider actually hosting it on WordPress.com. Hopefully these steps will point you in the right direction to improving your site performance.

What ever happened to the MacDevCenter?

O’Reilly’s MacDevCenter used to have much more in-depth articles on Apache, Cocoa development, Database and Systems administration, but now it is all about conferences and Aperture. Seems like they have forgotten the “Dev” in the sites name and are getting it mixed up with their other Mac site over at Digital Media.

That stream of great articles that were written after I got my first Mac (TiBook with 10.1) has died off. And that includes the practice of updating older articles after an update or new release of the OS. The newsletter hasn’t been updated since August of 2005 and even the list of contents in the sidebar has been absent for sometime (below is a copy of what used to be in the sidebar with links to each category, grabbed from The Internet Archive).

Derrick Story please bring back the MacDevCenter to it’s former self.

Content:
• All Articles
• Apache and Web Serving
• AppleScript
• Cocoa Programming
• Database and Sys Admin
• Designing for Aqua
• Developing for Mac OS X
• Digital Photography
• Email and Related
• Inside Mac Radio
• Java on Mac OS X
• Mac Weblogs
• Mac OS X Conference
• Mac OS X Innovators
• Music and iTunes
• Networking and Wireless
• Product Reviews
• QuickTime and iMovie
• Terminal App and Unix
• Switch to OS X

Cyndicate, AKA PulpFiction 2.0

Cynical Peak Software released Cyndicate yesterday bringing it out of it’s beta release that started in early April. If you liked PulpFiction from Freshly Squeezed Software (FSS) you should enjoy using Cyndicate. In fact Brad Miller and Erik Barzeski from FSS are the two behind Cynical Peak. With Brad doing all of the dev work and Erik running support and as much of everything else he can.

During the beta it was great to see both Brad and Erik listening and reacting to the feed back offered and have a pretty quick turn around on bugs that were submitted. Throw in a discussion on how some of the other beta testers actually use feed readers / aggregators and the couple of ideas that came out of that; the interest shown for these ideas by the developers is very encouraging for the future of Cyndicate.

  • Ratings - using Bayesian methods to teach Cyndicate to automatically rate content
  • Labels - for subscriptions and / or articles
  • Folders / Smart Folders - easily organize all of your feeds and articles
  • Filters (including Growl support) - move stuff, label stuff, flag stuff, delete stuff or alert you to stuff
  • Themes - create your own custom themes usign HTML and CSS
  • Share This - post an article to Ma.gnolia, Del.icio.us, Digg or any of the other 14 services listed

cyndicate.jpg