At work, I constantly have to browse around my computer as an administrative user. Whether it’s cleaning up profiles, troubleshooting a software issue, or just wanting to get Firefox installed - I’m rarely on my normal account.

This wasn’t really a problem with Internet Explorer 6. Right-click, Run As, then switch to the Explorer Bar. But, Internet Explorer 7 has made leaps and bounds in trying to secure itself - and separating itself from the rest of the operating system is one of those solutions. You can run IE7 as an admin all day long but you’re not going to browse around the system as an admin.

I finally came across a miracle worker of a command - that will launch a separate instance of Windows Explorer as an admin:
runas /user:DOMAIN\username "explorer /seperate,C:\"

I’ve tried to make this a shortcut but it pukes out saying “explorer can not find the path seperate,” - for now, it will remain a sticky-note on my monitor.

I used to be that guy that would come running into the office a minute or two before my shift started. Still tired, my hair a mess, and rubbing the sleep out of my eyes; I was pretty much worthless for the first hour of work.

About 4 months ago I started forcing myself to wake up earlier - giving myself enough relax time before heading off to work, rather than running out the door as soon as I get my clothes on. It started slow, of course. I’d wake up 15 minutes earlier than I used to; after a week of that, I’d wake up 30 minutes earlier, then an hour. I’m now at an hour and a half before I have to start my commute and I feel as if it is the perfect period of time.

Here are just a few reasons you should consider waking up 30 minutes earlier.

1. Eat Breakfast
2. Get to Work on Time
3. Watch the Sunrise
4. Get a Cup of Coffee
5. Read the News
6. Shower in the Morning
7. Say Meaningful Goodbyes
8. Plan Your Day
9. Pack a Lunch
10. Call Family

As most of you know I’ve been unavailable for the past month as I attended the Basic Combat Convoy Course (BC3) at Camp Bullis, TX. As my reenlistment nears (April 09) I have been debating the fact as to whether I would reenlist or not. Approaching my 6 year mark, a reenlistment of 4 years is more than just a small commitment - if you hit 10 (the half way point to retirement) you may as well do all 20!

Well, BC3 (and this deployment in general) made that decision very simple for me: I’m getting out. It’s not because I didn’t like the course; I actually thought it was great: very educational, relatively fun, and without a doubt a new experience (think computer nerd driving a tractor-trailer and you know what I just went through for a month).

A quick look at the bank account leads to an obviously apparent conclusion: I don’t make enough to support my lifestyle. Sure, we’ve went over our heads on a few things (our car, minor credit card debt), but we skim by each month. To be honest, I think I’m worth more than that.

My knowledge, skillset, and dedication to my work is worth more than $21K per year. Sure, we have great benefits (namely, free medical) but everytime I crunch the numbers we always come out in a better position, even when I take worst case scenarios into account.

But, it’s not all about the money. To be honest, very little of it is. It’s primarily about happiness and joy. Sure, I love the Air Force and I love my job within the Air Force; but, would I not love doing the exact same thing on the outside (minus having to leave my family every year)?

Personally, I value my daughter’s 2nd birthday (which I’ll be missing), holidays, and the security in knowing that I won’t get blown up on my way to work more than I value the free medical.

So, what does this mean to you - my trusty minions loyal readers? Well, I need to boost my resume and you reap the benefits. While completing my tour here in Kuwait (through November) I will be spending my spare time working on a few open source projects (PHP web applications using CodeIgniter, of course).

Here are a few of my ideas:

• Redesign of my blog, focusing on my portfolio and open source projects
• Possible: Switch to EE, we’ll see when it lands on it’s CI base
• A 37signals’ In/Out clone
• A personal management application
• A bug tracker (which will be used for my open source apps)
• A client/invoicing/project/time tracker (which I will start using with my clients)
• Completion of 3 contracts
• Begin work (and maybe complete) 3 personal projects

If you have any suggestions for applications you would like to see feel free to leave me a comment. If you know of any full-time jobs opening with companies in the San Antonion/Austin area (or that I can work remotely from those locations) that may be interested in my skillset, I would love to hear from you! Like I said, I am committed to the Air Force until April 09 (give or take 2-3 months if I can get certain paperwork approved).

After the release of ErkanaMigrate a few people have requested I attach a license to it - something I’m not really used to doing honestly. For the most part, you can do whatever you want with anything you find on this blog; as long as you don’t claim you did it yourself. Sure, if you modify it - claim your work, but claim my hard work as well.

I’ve finally broken down and selected a license for ErkanaMigrate and ErkanaAuth (and you have permission to assume this entire blog and its contents falls under the same license unless otherwise stated) - the Creative Commons Attribution-Share Alike 3.0 United States License.

Not your typical selection for software, right? I chose this license for two reasons:

• It states my intentions in plain English. Feel free to use, modify, destroy, eat, mulch, color upon, whatever. Use it commercially if you want. Just don’t go running about the community saying, “Look what I built!” when you didn’t. Give credit where it is due.
• It’s in plain English. The legalize most of these licenses carry around is retarded. If your license is several hundred lines longer than your code - you’ve probably selected the wrong license.

So, why did I not pick some of the more popular licenses out there?

GNU-GPL requires you to place a copyright notice and it locks you into GNU-GPL (as opposed to any comparable license). I’m lazy and I think you should be able to select any comparable license for your derivative works, so GNU-GPL is out the window.

Same thing goes from GNU-LGPL.

The BSD license is actually a great choice, but it doesn’t have the bandwagon CC does. I love bandwagons.

Elliot Haughin, one of my CodeIgniter All-Star brethren, has posted an excellent article entitled Optimizing and Scaling your CodeIgniter Application. In this article, Elliot takes you from a baseline CodeIgniter installation, through memcache, opcode caching, and finally output caching. From 45 requests per second to more than 389, this is a must-read article for any serious CodeIgniter developer.

On a side note, I’m going to try and highlight more and more community articles and forum posts in the future. There is a lot of CodeIgniter gold out there that people miss.

Nathan Smith has written a quick review of CodeIgniter for Rapid PHP Application Development by David Upton.

The review is, for the most part, lackluster and doesn’t provide much information beyond what you would find at Amazon.com or by reading the back of the book. Nathan mentions that the book would appeal to “Experienced PHP gurus who are looking for a way to enhance their workflow,” which I simply don’t agree with. Sure, the book would help them if they didn’t read the user guide but after reviewing the user guide, this book is a waste of money for any experienced PHP developer.

I do feel as if Nathan hit the nail on the head when he mentions this book is suitable for “front-end developers who are familiar with PHP templates, and want to take their skills to the next level by applying MVC best practices.” David Upton does a great job of explaining the CodeIgniter framework in plain language that anyone can understand and this book would benefit any front-end developer by helping them understand exactly what their backend developers are working with.

Nathan did include some link gold at the bottom of the posts, two of the links I had never seen before: Aten Design Group discusses redesigning their website with CodeIgniter and a Zend Podcast with a CodeIgniter Overview (actually, I believe I have seen the latter but never listened to it).

Other notable links were to Derek Allard and Yannick Lyn Fatt.

Ever since I moved over to Slicehost I have been trying to expand my horizons as much as possible. I’ve been playing with Python and Ruby much more than in the past, primarily because I have an Ubuntu VPS all to myself. I can destroy and wreak havoc and I don’t really have to worry about losing anything (this blog may be down for a few hours, but no biggy).

One of the areas in which I have been experimenting is web server. For the most part, Apache is king, and it is a very powerful piece of software - no doubt. But, is it really your best option? It’s extremely bloated - on my 256MB VPS I was consistently maxing out my RAM, hosting nothing more than 3 blogs. Now, I’m sure there are some configuration options I could change to bring the memory usage down (releasing HTTP connections more often, decreasing the number of work handlers, etc) but it seemed like a great opportunity to see what’s out there.

The two leaders within the alternative web servers are Lighttpd and Nginx. Nginx was developed by a Russian programmer for his own site, primarily because he was tired of the large amount of resources Apache was draining. It is now used by more than 85% of the websites hosted out of Russia. No doubt, Nginx is a piece of software to keep your eyes on and it has a large number of fans here in the States. Unfortunately, not all of the documentation has been translated over from it’s Russian origins and I found it a bit difficult to find information on some of the more obscure functionality of the server.

Therefore, I opted to go with Lighttpd which also powers some of the hottest Web 2.0 properties like YouTube, Wikipedia, and Meebo. One of the first things I noticed about Lighttpd was how easy it was to configure. After just a few hours of first reading about Lighttpd I had it installed on my server and had a psuedo-Virtual Server system setup based on the Debian-based practices of storing websites within a user’s home directory and making them available/enabling them via a set of configuration files and symlinks within a root accessible directory. Of course, Lighttpd supports the standard Virtual Server configuration that Apache supports but it just doesn’t work for my needs.

One downfall of Lighttpd is that it does not support Apache .htaccess files - so in many cases, you are left to some self-education as to how to get your open source software to work properly. Thus, brings us to CodeIgniter - while Lee over at MadeByFresh is putting the final touches on my new design I wanted to get to work on rolling my own blog engine. As a CodeIgniter developer, using my blog to promote my services, I feel it’s important to “eat one’s own dog food.”

Remarkably, Lighttpd supported CodeIgniter right out of the box without any configuration changes. This is the same functionality you would receive with Apache if you just uploaded the framework to your public directory and started serving files. But, of course, I wanted to get rid of the dreaded index.php.

So, our URL requests will be similar to: domain.com/home or domain.com/users/edit, which are processed by CodeIgniter’s index.php because those directories and files really don’t exist (at least not via the path passed in the URL). Well, that sounds a lot like a 404 error to me, right? Trying to access a file that doesn’t exist…

lighttpd.conf

server.error-handler-404   = "/index.php"

Lighttpd allows you to define a custom 404 Error Handler and in this instance, we’re just going to pass them all to index.php. Don’t worry - Lighttpd doesn’t pass a 404 header so the browser still thinks we’re headed to a legitimate page.

So, what happens when we’re request CSS, images, Javascript, etc? What you’d expect! In those instances you are linking to real, legitimate files, via their actual path on the server (domain.com/assets/css/style.css for example). So, Lighttpd just serves up a static instance of that file (automatically compressing it, if you have that module enabled - so much goodness in Lighttpd).

Now that we’re throwing all of our potential 404 errors at index.php we need to tell CodeIgniter how to figure out the controller and method to load. If you’ve ever ran a CodeIgniter application off of Dreamhost you will be familiar with the following setting:

config/config.php

$config['uri_protocol']	= "REQUEST_URI";

This simply tells CodeIgniter to scope out the $_REQUEST variable and determine where we are supposed to be going. CodeIgniter will load your controller/method just like normal, everything will work in your application as you’d expect, and you’ll meet a hot blonde in Tahiti, elope to Vegas, and live happily ever after.

Of course, CodeIgniter is such a smart little bastard, if it comes across a controller/method combination that doesn’t exist it is going to load up our errors/error_404.php file. Let’s go check it out and make sure Google and everyone else understands that if we hit this page we are at a legitimate 404 error page and to throw a 404 header. Up until now, we are still a legitimate request for a file on the server (only the server itself knows how sneaky you’ve become, using the error-handler).

<?php header("HTTP/1.1 404 Not Found"); ?>

Holy roasted potatoes Batman! Yes, EllisLabs are a group of geniuses and they have thought well ahead of us in advance. 404 headers are being thrown to tell Google to GTFO.

Getting CodeIgniter up and running on Lighttpd is extremely simple (btw: you use the same process to run Wordpress, phpBB, and damn near any other software that uses an index.php entry-point for clean URLs). Plus, you are going to see your memory usage drop significantly on your server. I am currently running 10 Lighttpd work handlers in the same amount of memory as 1 of Apache’s.

Let’s face it - whether you are working with a team or working alone, version control for your database pretty much sucks. Your best bet is managing numerous SQL files dumped from phpMyAdmin; not the optimal solution at all. I think Ruby on Rails hits the nail right on the head with their migration system, which is why I would like to introduce ErkanaMigrate.

First of all, let me say this up-front: this is super-duper early Alpha. I banged this out in about 2 hours tonight simply as a proof of concept; and, although it works pretty well at the moment - there’s a chance it could completely ruin your current project. So please, only use this for personal projects currently in development. If you go dumping this into a live site, or a client site that needs to be done by this weekend, and it ruins everything - please call me so I can point and laugh.

With that out of the way - let’s get into the details, shall we?

ErkanaMigrate consists of a library that you will call from a Controller. In a real world situation I highly suggest you place this Controller behind some sort of authentication system, but for our examples - who cares?

<?php
 
class Migrate extends Controller {
 
  function __construct() {
    parent::Controller();
    $this->load->library('migration');
  }
 
  function up() {
    $this->migration->up();
    echo 'Migrated database up to next version.';
  }
 
  function down() {
    $this->migration->down();
    echo 'Migrated database down to previous version.';
  }
}
 
?>

There is nothing really new here - other than we are loading the ErkanaMigrate library. We’ve establish two methods each of which makes a unique call to an ErkanaMigrate method. Something I should definitely point out is the fact that the library at this time does not verify whether the migration actually took place, it assumes it always works. Thus, the lack of conditional statements within this Controller that would return meaningful responses - this will definitely be fixed in the future.

So, how does this all work?

When you first load the ErkanaMigrate library it’s going to verify a few different things:

• Is there a db_migrate table? If not, it will make one - the name of this table can be changed within the class variable section of the library.
• Is there a directory within the applications config folder named migrate. If not, it will attempt to make one - of course, you can change this.
• Is there a version definition within the db_migrate table? If not, it will make a version definition with a value of zero.

Once all of that has completed the library then determines which direction you are migrating - either up or down - and loads the corresponding file for that migration. Currently, the library is limited to single steps in either direction and once again - this will be altered in future releases.

Migration files are saved in the application’s ./config/migrate/ folder and have a file structure of XXX_unique_name.php. The digits at the beginning of the filename define the version number (higher version numbers being newer files, of course), while the rest of the filename is a unique identifier for your use (and just happens to be the class name of that migration). Here are a few examples of valid migration filenames:

• 1_create_users.php
• 12_create_blogs.php
• 867524_feature_creep_sucks.php

Now that we know what our migration files should be named - what do they look like?

./config/migrate/2_create_blogs.php

class Create_Blogs extends Migration {
 
    function up() {
        $fields = array(
            'id' => array(
                'type' => 'SMALLINT',
                'unsigned' => TRUE,
                'auto_increment' => TRUE,
            ),
            'title' => array(
                'type' => 'VARCHAR',
                'constraint' => '255',
            ),
        );
        $this->add_key('id', TRUE);
        $this->create_table('blogs', $fields);
    }
 
    function down() {
        $this->drop_table('blogs');
    }
 
}

The first thing to point out is the class name - it should always be named the same as your filename, minus the version_ prefix. You can stray from this if you’d like, but not if you want it to work. The migration files use CodeIgniter 1.6’s new DBForge class to do all of the heavy work. You simply create an up() method - defining the action to take when moving to this version; and a down() method - defining the action to take when degrading from this version (essentially the opposite of up).

If you look closely you will note that I haven’t included any DBForge functions within the class… I have created an extremely small number of “entry methods” into the DBForge library that I think will make the creation of migration files much easier. I will, of course, create more entry methods in newer releases but it’s getting late and these few are all I needed for proof of concept.

• create_table(string tablename, array fields): This method is nothing more than a combination of DBForge’s add_field and create_table methods. Be sure to add any keys before calling this method.
• add_key(string field, boolean primary key, default FALSE): This method adds no value at all, except for saving you some typing. It functions exactly the same as it’s DBForge equivalent.
• drop_table(string tablename): Once again - no added value.

So, my entry methods don’t provide a lot of functionality and I am missing a ton of features, why include them at all? Why not just use DBForge all the time? I didn’t feel like typing this out:

$this->CI->dbforge->create_table('users');

Yeah - I’m lazy. You are more than welcome to use these calls to the DBForge library within your migration files - you’re not breaking any MVC morals or going to hurt my feelings.

So, feel free to bash, comment, make suggestions, etc. I’ll be taking everyone’s comments into consideration and will be actively working on this library. As opposed to ErkanaAuth (which was developed for me and I decided to share), I fully intend to continue to develop ErkanaMigrate and make it an excellent tool that makes all of our lives much easier.

Download ErkanaMigrate

ErkanaMigrate is licensed under a
Creative Commons Attribution-Share Alike 3.0 United States License.

Yesterday I posted a call for help, looking for a team to assist me in developing a distributed messaging system powered by WordPress. With the release of the Prologue template it has been made apparent that WordPress can easily be turned into the cross-domain messaging system of the future - the clear second step for the blogosphere.

I received some great responses from the community but ultimately the decision was very easy:

• Elliot Haughlin. Elliot has developed some of the greatest tutorials to grace CodeIgniter and is viewed as one of the “all stars” within the community. When Elliot sent me his bio I knew I would have to look no further for my lead developer - it’s an honor to have him on the team.
• Dylan Wreggelsworth. Dylan is elite design as it’s best and he embodies the clean, “less is more” attitude I love so much. He also understands branding and designs absolutely wonderful logos you have no doubt seen before (including Azureus and TVersity).

As we progress through our development we’ll be doing a lot for the WordPress community. Our first goal, of course, is to complete our product and get services rolling out to those that can utilize them. This leads us to a catch-22 of sorts, as of now only those users using the Prologue theme recently released could make use of our services.

We intend to release numerous templates, similar in functionality to Prologue, with varying designs. This will allow many more communities, organizations, and companies to make use of WordPress as a messaging system and get on board with our distributed messaging system!

Earlier this week, Matt Mullenweg (of Wordpress fame) announced Prologue, a pretty nifty theme for Wordpress. The blogosphere has been considering whether this is the first step in dethroning Twitter, Pownce, or Jaiku.

While I am not inclined to agree with those predictions I do feel as if Prologue deserves a fair amount of attention. When you cut away all the hype, Prologue is really nothing more than a Wordpress theme. It’s a great solution for quick communication within a company or small group of users, but how do we move that out to the rest of the Internet? How do we take Prologue and turn it into a Distributed Messaging System, where the blogosphere as a whole can partake in discussions while still maintaining the uniqueness and cohesion amongst their small niche?

You Can Help
I believe I’ve come up with a pretty good idea to handle this problem and I am currently looking for 1 designer and 1 CodeIgniter programmer to help me in building a beta first release this weekend. This first release will be very small in scope, primarily focusing on the administrative side of the service (user registration/management, “static” page caching/serving) and RSS parsing.

After this first release we will continue to add new features to better support the Prologue-powered networks that join this service. These new features include cross-network messaging, cross-network user management, advertising services, and more.

This is a non-negotiable 40-30-30 partnership, with myself claiming the majority stake. I hit on a big idea every now and then (just google WoWCensus, which was sold 3 years ago, for a prime example). I honestly believe this idea could really take off and become something big and would love for members of the CodeIgniter community to become a part of that as well.

How to Apply
Send me an email (subject: Application: DMS) with a short bio, your availability this weekend, your availability during a normal week, and your involvement within the blogging community (not limited to Wordpress). URLs to your personal blog or blogs you have worked on in the post are highly favorable.

In addition, please include the following depending upon the position you are applying for:

• Designer. Please include URLs and/or attachments to examples of your design work (websites, logos, print work, etc.). All applicants must submit at least one URL to a fully-coded xHTML/CSS website.
• CodeIgniter Programmer.Please include the URL to your profile on the CodeIgniter Forums as well as links to any sites you have developed in the past (as well as a short description as to what you accomplished within that development period). Prior experience with open source software, Wordpess, Lighttpd, and RSS parsing a plus.