Kecko.comhttp://kecko.com/feeds/atom/2011-04-05T13:41:44+00:00Say *what* again, I dare ya, I double-dare ya!Zinnia, My Django Blog2011-04-05T13:41:44+00:00scoopseven/author/scoopseven/http://kecko.com/zinnia-my-django-blog/<p>UPDATE: 4/7/11 !!! IMPORTANT !!! Read the comments between Julien and I below before installing or deciding to install Zinnia.  It's far easier than I lay out in this post.  I'm leaving here for reference of what not to do :) --Mark</p><p>After writing so much lately about Django and Python I felt silly doing so on a hosted WordPress blog.  So for no good reason, I started investigating Django blogging engines. I decided to go with Zinnia.  It's an app, which means I can include it in other projects I have already started or going.  The documentation is fairly complete (or seemed to be) and it's still supported / in development. The main missing ingredient is multi-blog support, which is possibly in the works.</p><p>If you've decided on using a Django blog and Zinnia is your choice, I'll let you in on a couple secrets that may save you some time during installation and conversion from WordPress, if that's where you're coming from.  </p><p>There are <a href="http://django-blog-zinnia.com/documentation/install/#getting-the-code">three ways to install Zinnia</a>, all which will load all of the dependencies for you.  When I did this on my Apple Macbook (for development/testing purposes) I ran the pip install, copied the Zinnia project code from /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django_blog_zinnia-0.8-py2.6.egg/zinnia (where it installed), placed that code in my project and p<a href="http://django-blog-zinnia.com/documentation/install/#applications">ut the proper lines in my settings.py</a> file. All of that was pretty seamless. When I updated templates (to change the look) I saw the changes immediately on my local python runserver. </p><p>I repeated this process on my production Arch Linux machine, the application acted differently.  When I updated my live server with the updated templates, I didn't see any of the design changes.  Restarted apache, still nothing. So I ran the zinnia pip install again, restarted apache and whaddyaknow, there were my changes.  On the production machine, it seems like Django/Python ignores the "zinnia" installed app in settings.py and runs the code/templates from the site-packages/django_blog_zinnia-0.8-py2.6.egg/zinnia folder. Since I didn't want to have code in there and have my project live in two places, I deleted the site-packages/django_blog_zinnia-0.8-py2.6.egg/zinnia folder and make a symbolic link to the zinnia folder in my project. </p><code><p>ln -s /path/to/your/project /usr/lib/python2.6/site-packages/django_blog_zinnia-0.8-py2.6.egg/zinnia</p></code><p>Now my project lives in one place and Zinnia works as it should. Yay!</p><p>Another thing that impressed me about Zinnia is that it includes <a href="http://django-blog-zinnia.com/documentation/wordpress_2_zinnia/">tools for converting to and from WordPress</a>. When I exported my WordPress xml file, ran the script and started getting errors:</p><code><p>xml.parsers.expat.ExpatError: unbound prefix</p></code><p>I was starting to think I'd made the wrong decision going with Zinnia. This time though, the problem was on Python/WordPress. WordPress exports with this xmlns information in the rss tag:</p><code><p><rss version="2.0"<br />xmlns:excerpt="http://wordpress.org/export/1.0/excerpt/"<br />xmlns:content="http://purl.org/rss/1.0/modules/content/"<br />xmlns:wfw="http://wellformedweb.org/CommentAPI/"<br />xmlns:dc="http://purl.org/dc/elements/1.1/"<br />xmlns:wp="http://wordpress.org/export/1.0/">  </p></code><p>If you add this line:</p><code><p>xmlns:atom="http://www.w3.org/2005/Atom"</p></code><p>The error magically goes away.  I found that <a href="http://stackoverflow.com/questions/3249799/python-feedparser-not-using-atom-wordpress-namespace">solution on StackOverflow</a>.  It wasn't a horrible process once I found the couple of gotcha's, so don't be afraid to ditch WordPress!</p>WD Scorpion Blue vs Seagate Momentus / 13" Macbook Pro2011-03-28T01:03:06+00:00scoopseven/author/scoopseven/http://kecko.com/wd-scorpion-blue-vs-seagate-momentus-13-macbook-pro/I was recently forced to take my 13" Macbook Pro (2009/Unibody) apart to replace the LCD display. I figured, since I've got it apart, I might as well upgrade the stock 250 GB 5400 rpm stock hard drive with a 500 GB 7200 rpm drive. Bigger + faster = better, right? I got the Seagate Momentus 500 GB 7200 rpm hard disk from <a href="PowerbookMedic.com">PowerbookMedic.com</a>, who had a great price on the LCD. Turns out they marked up the hard disk up about $30 from what it was at Amazon or NewEgg.
After installing the drive and getting it up and running using Carbon Copy Cloner (awesome) I immediately noticed a loud humming noise and vibration that I had never felt. After about a week (I'm plugged in most of the time) I also started to notice decreased battery life. So I decided to read up on my purchase. I found several reviews touting the 500 GB Scorpion Blue as the de-facto replacement drive for Macbooks. At $90 (about the same I paid for the Seagate), I decided I'd pony up and get the larger <a href="http://www.amazon.com/Western-Digital-Scorpio-Notebook-WD7500BPVT/dp/B003D18DM0">750 GB Scorpion Blue from Amazon</a>.
Same install process using Carbon Copy Cloner (did I mention this program rocks?) with very different results. No humming, no vibrations, 250 GB more space! There's absolutely no noticeable speed/access time difference the 5400 rpm and 7200 rpm drives. The WD Scorpion Blue is superior in every way (as far as I'm concerned). My battery life also went back to +2.5 hours on a full charge, something it had not done with the Seagate installed.
With the new LCD and 750 Gigs of space I've got a happy Macbook again. Yay!