John Crepezzi and I launched GetSparks.org (the CodeIgniter package manager and repository) a little under a year ago, and the response we received from the community was overwhelmingly positive.

The best part of GetSparks isn’t the site itself. It’s a moderately simple app that provides a vehicle for quickly dropping other developers’ code in your codebase.

Many of the packages on GetSparks are very well maintained. I am continually impressed by the amount of effort spark developers pour into their submissions when I peruse the site and try new packages out. One example would be WanWizard‘s DataMapper-ORM: Look at how well thought out it is, and how detailed the docs are.

Another would be codeigniter-payments. I rolled in to the second day of CICon 2011 NYC to find @calvinfroedge talking about a new payment spark he had made — one of the most in-depth, flexible payment libs I’ve ever seen.

GetSparks has almost clocked 50,000 package downloads at this point, but there are handful of sparks that have really stood out in terms of popularity. They are the year’s top 10:

And of course, there are people whose contributions have made GetSparks.org the success it is. A special thanks goes out to:

• Beau Frusetta — First team member (retired), and the guy who made GetSparks look halfway decent
• Mike Pauley — Team member
• Sean Downey — Team member
• Joe Auty — Team member
• Jake Ingman — Who made us a sweet logo
• Joel Cox — For some fine features and great sparks
• Balsamiq — Who donated a copy of their mockup software
• Spicer Matthews of CloudManic, who contributed the “forking” feature (which I have big plans for)

Happy New Year everyone. Keep up the awesome work, and keep knocking out those timeshanks when developing a new app with new sparks (things like payments, emailing, auth, assets, etc).

Something that has always come naturally to me (I’m not saying it’s something I’m great at) is promotion of my projects. When I wrote chip a couple months ago, I wanted to spread the word and evangelize it. I presented it at Hack and Tell in NYC, made a screencast, and pretty much inundated my co-workers at Yahoo! with tips and tricks on how to use it. I submitted it to Linux Journal, and now I’ll apply to couple sys-admin confs to present the next version.

Y! folks: `yinst install chip`

I did all that because I was excited about it and I wanted everyone who had ever had the same problems that chip solves to use it. Isn’t that why a lot of us make our projects open source — because other people might find it useful?

I think there are a few different reasons developers might open-source their projects, but I think it ultimately whittles down to this: You’ve solved some problem or made something easier, and you never want to see anyone without a solution (your solution in-particular) again.

But a lot of developers stop short of promotion. They hack something together that they know other people would find useful, release a few versions, and leave the project in the wilderness of github for someone else to stumble upon. That might — but probably never will — actually happen.

In a lot of ways you can find the exact same thing among startups. A couple developers get together with a great idea and a whole lot of initial excitement. They feverishly build whatever the hell it it is and put out an initial version. Then when they realize the software does not in-fact sell itself, the project begins its slow decline into obscurity and float away in the river of bad excuses.

Has this ever happened to you? Did you hack something that’s awesome and should be used by everyone, but no one has ever heard of it? Did you try and start a company, build an entire product, and start to lose interest in it when the time for marketing and promotion came around?

Following through on projects is one of the hardest things to do, but you owe it to yourself. I’m guilty of stumbling on this too. But remember: You didn’t spent 4 months of your life on 3 hours of sleep so you could look back and say “Yea, I should have followed through on that, but I …”

The point: If you can’t close on a project, you can’t close shit. You are shit. Hit the bricks pal, and beat it.

If you get the reference, it’s from a great movie named Glengarry Glenn Ross. A good friend of mine turned me on to it. The relevance? It’s time to sell. To investors, to customers, to anyone who will listen. Get off your ass and go do it.

The success of you and your app depends on your ability to work hard and follow through. Gary Vaynerchuck refers to it as “The Hustle.” It’s how great products, projects, and brands are built.

So yea. Let me end on a quote. This is difficult, because I hate inspirational quotes — but Method Man and Biggie tell it like it is: “Everything ya get you gotta work hard for it.“

Note: CodeIgniter Reactor 2.0.2 has a bug in it’s core Loader class that breaks package config file loading (and sparks, sadly). It’s recommended that you use 2.0.1 OR the latest at https://bitbucket.org/ellislab/codeigniter-reactor OR make the following change in your 2.0.2 installation: https://bitbucket.org/ellislab/codeigniter-reactor/changeset/c461483c8ca0 . The last option is the best.

It took a month longer than expected, but we’ve finally released the Beta version of GetSparks.org, the repository and package manager system for CodeIgniter.

Here’s the very minimum of what you need to know:

1. A spark.info file is now required in every spark
2. You should upgrade your spark system as soon as possible (just follow the usual installation instructions)
3. If you submitted a spark prior to the beta, we’ve normalized all version numbers to x.x.x. So curl 1.0 becomes curl 1.0.0. Check the site.

The alpha was all about weeding out fundamental issues in the initial repo and system. The big problems we had were:

• Some spark developers wanted the ability to specify dependencies
• There was no difference between a repository tag and the spark version — They had to be in sync
• Users wanted RSS feeds for latest spark overall, and latest versions of individual sparks
• There was no way to rate a spark
• There was no way to tell if your spark was going to be accepted by the spark processor prior to submission

We knocked those out and a little more with the beta. Going forward:

All sparks must have a spark.info file at the root. Details are here.

• You can now specify spark dependencies in spark.info
• The spark manager will now install a spark and all of its dependencies
• The spark manager can now self-update
• All spark versions must be in x.x.x format. Sparks released prior to the beta had their version numbers change in the system (tags remained the same though)
• Versions and tags are now decoupled. The version is pulled from spark.info
• Sparks are now ratable via a simple “Love”, “Like”, or “Hate” rating
• A Spark-SDK is available to spark developers in order to validate their sparks prior to submission

It is necessary that you upgrade your spark manager with the release. The current version is 0.0.4. You can upgrade by removing the ‘tools’ folder from your webroot and following the same installation instructions at: http://getsparks.org/install

Send any issues to ohcrap@getsparks.org!

Now that the structural changes have been made, we can focus on tightening up the spark system’s feature set. This is what you see in the coming weeks:

• The ability to install sparks in configurations where the application folder is not in your webroot (possible now, but not automated)
• The ability for sparks to act more like modules — ie, sparks will be able to override core libraries and more

Also, we plan to:

• Put a news section on the site (long overdue)
• Configure our notification system better so its emails don’t land in your spam folder

And don’t forget the ultimate goal: Integration in CodeIgniter Reactor.

Check out the beta and ping the team with any problems! ohcrap@getsparks.org

If you’ve ever had the need to investigate production issues in a load-balanced setup, you’d know why having a tool to pull down all of your remote log files into a single filtered stream can be handy. I think splunk is great at this, but in many cases, overkill.

I wrote chip to accommodate this demanding use case:

I have n production servers. From my local machine, I want to view the web application logs across those servers on a single terminal, while highlighting error lines in red. Additionally, I want those errors emailed to me.

That’s what chip does. It’s a powerful log file monitor (like swatch) and multiplexer. That is, it combines local or remote logs into one stream that you can see. Watch the screencast:

A full description of what chip can do is at the github project page, but the gist is:

chip starts up and tries to open log file(s), either local or remote. If one isn’t specified, it reads from standard input. It goes through each line looking for patterns that you have specified as arguments. When it finds a match, chip does whatever you told it to do with that match.

I use chip daily to watch production logs. When I’m investigating issues, I set up an additional pattern and handler to send certain log lines to my inbox. Just think: An instant monitor set up to watch all of your production logs while you do more important things. Useful for just tailing logs, splitting them, colorizing them, monitoring them, or any combination of the above. You can also use it as a more flexible alternative to `tee` when piping in input.

Anyway, now I can get back to working on the GetSparks.org project

chip is still technically a beta, but has been stable throughout my use of it. Check out chip at https://github.com/katzgrau/chip.

On Twitter, I’m @_kennyk_.

Note: I wrote this over a month ago, but decided not to publish it until now.

I was talking with the Co-founder of a pretty cool start-up in DUMBO the other day about why the non-PHP development world generally has such disdain for PHP and the community surrounding it. He brought up an interesting point that stuck with me, largely because I hadn’t heard it before.

If you’re unaware of the usual beef most developers have with PHP, it tends to revolve around:

1. Ugly syntax
2. Lack of some necessary features that other languages have (prior to 5.3, namespacing, closures)
3. Inconsistent function naming, usage, and other quirks
4. Mix of procedural and OO-ness
5. The fact that 80-90% of PHP projects are probably gigantic piles of shit

But his problem with PHP was a little different. He didn’t say the actual language was poor — he said it was the general culture surrounding the language, which is usually iconified by a language’s founder, that seems to encourage bad practices. That is, PHP code bases tend to be hacky and unmaintainable.

The concept that the community surrounding a language or framework embodies an author’s philosophy seems to be true. He brought up Ruby and Matz. Matz wanted a language that was easy to read and write, and enhanced programmer productivity. Don’t Ruby developers seem to harp on rapid application development and the elegance of their language?

Then DHH and the Rails came up. Then Guido and Python. So I thought: What about Rasmus?

Rasmus Lerdorf is an interesting figure. He created the original version of PHP, continues to contribute, is widely considered a demigod in the community and the authority on almost anything PHP. He steals masses of attendees at conferences, gets hired by big internet places, and garners the respect of everyone despite one glaring property: Rasmus represents what most non-PHP developers hate about PHP.

Rasmus generally promotes abstention from using frameworks, and the use of PHP as more of a templating language. To him, this translates to raw speed and scalability (load-wise). To everyone else, this translates to piles of procedural spaghetti code, and unmaintainable projects. For roughly 10 years following the birth of PHP in 1995, this was how PHP projects were written.

But another issue cropped up:  In it’s pizza-faced adolescent years (pre-5.0), PHP gained a serious following among novices. The language has a fantastically low barrier to entry, so anyone could get started in 2 minutes by downloading some self-extracting *AMP stack for Windows. Additionally, the acceptance of the MVC paradigm hadn’t really occurred yet in web development. What do you get when you mix n00bs and a lack of best practices? Unmaintainable garbage. And that’s what proliferated.

Don’t get me wrong — there were some great PHP developers around, even back then. But like I said, unrefined n00b-sauce was all around. When cowboy PHP developers with no standards got together to build a project, it came out looking like PHPbb, PHPNuke, or some other gnarled mash of .php3 files. But can you singularly blame PHP developers? No! The other web language giants, ASP and Perl, were also gross as hell and promoting the same spaghetti-code practices.

So why does PHP get a bad rap? Because of its legacy. And most old-time PHP devs who have fled to Python, Ruby, and Java haven’t really looked back to see what kind of development has happened in the language since the introduction of MVC on the web. Additionally, there were super-outspoken critics like “Ruby guy” Zed Shaw complaining of developers with “PHP-Infected Brains”, and the distribution of stuff like this on RubyInside.

PHP was a ghetto.

But the development of frameworks like Zend and CodeIgniter have greatly pushed the language development into the right direction. In fact, it’s been pushed in the opposite direction of where Rasmus would probably like to see it. Check out the Zend or CodeIgniter frameworks and tell me it’s not some of the best documented, most well-written code you’ve seen.

When most developers learned Ruby, they were learning Rails and MVC  at the same time. PHP was in use for a full 10 years before that. So there really wasn’t a period of time when heinous Ruby was being written by novices. There was an established standard in place for Rails, and the barrier to entry was a much higher, typically keeping less experienced developers out.

The fact is, a PHP applications can be as well-written as an application in any other language, and probably have the additional advantage of speed. The widespread use of MVC-style development in the PHP world is a relatively recent phenomena though, and admittedly, we can probably thank Rails for it.

So what does PHP have going for it now?

1. Standards (not universal, but generally a flavor of MVC for most projects, and little procedural crap)
2. A very low barrier to entry
3. Speed & Scalability (maybe the best among script-based languages)
4. A great unit testing framework
5. Arguably the best documentation for any language

Additionally, it’s behind some of the internet’s most influential websites and tools, like Facebook, Digg, Wikipedia, WordPress, Drupal, etc. I’d bet that having a solid understanding of it opens more doors for a developer than any other.

If you don’t agree with the above, comment on this post, or email me — I’d like to hear why you don’t think so.

I’m no PHP fanboy — in fact, I’m very language-agnostic. I write PHP more often because, you guessed it, people pay me to. So it all comes down to this:

If you are capable of making wise software design decisions, PHP is a great choice to build your web application with.

By the way, if I just convinced you to build your next webapp in PHP, check out CodeIgniter. It’s the lightweight, no magic, ultra fast framework for PHP. When it comes to CodeIgniter, I am a fanboy.

4/4 Edit: I’ll be presenting a tool I wrote in Perl called ‘divvy‘ tonight at Hack and Tell in NYC. Here’s a video of a previous event (about 10 minutes in) where a developer plugs in his laptop to reveal Windows XP on his desktop (strike 1.5) and then admits to being a “PHP Coder” (strike 4). Is it me, or can you feel the judgment in the air? Maybe it’s me.

On Twitter, I’m @_kennyk_.

If you aren’t already familiar, a package manager and repository for CodeIgniter libraries was released last week at GetSparks.org. In the few days between then and now, some very interesting and useful packages have been submitted. There’s one for combining, minifying and caching assets, one for database scaffolding, viewing logs, geocoding, template-ing, etc.

Here’s a short screencast that shows how GetSparks.org has already started using some of these sparks in its own development.

If you’re interested in the project, follow it at twitter.com/getsparks. If you’re a developer and you’re interested in following or helping out with development, head to the github repository over at http://github.com/katzgrau/getsparks.org.

As always, if you’d like to join the project, find me at: katzgrau@gmail.com.

If you’re familiar with package management, you’re aware of how awesome it can be. Yum, Apt, MacPorts, homebrew are examples of package managers on the Operating System level. Need to install some common software package like mysql? On OSX, it isn’t any harder than:

$ brew install mysql

For software development, you have Python’s eggs and Rails’ gems, which each work a bit differently, but generally achieve a solution to a big problem: Using, installing, and contributing other developers’ libraries should be easy.

So if you’re a CodeIgniter developer, picture this common scenario: You need a library to interact with Amazon’s new Simple Email Service, but you know someone out there must have already written one. You end up on some guy’s blog, and it looks like he has a working library. You copy/paste, download, whatever.

Maybe the lib was written to work with CodeIgniter, or maybe it’s just a general PHP lib. Maybe it works, maybe it doesn’t. Maybe it has solid documentation, maybe it doesn’t. If it’s not to your liking, back to Google you go, and search for something else. This is all time-consuming.

As of today, this problem is solved for CodeIgniter. It’s called CodeIgniter Sparks, and you can read all about it at http://getsparks.org.

CodeIgniter “Sparks” is still in an alpha state at the time of this writing, but it’s planned to be a full package manager for CodeIgniter applications. You can install it by using a one-liner.

Thanks to some early contributions, you can now get some Amazon SES functionality by:

$ php tools/spark install amazon-ses

And boom-shakalaka! It’s installed in your application. A special thanks to Joël Cox for that one.

Phil Sturgeon and Dan Horrigan each came through with their respective ‘template‘ and ‘tag‘ packages.

It’s still very early in the project’s lifetime, but I don’t think its too early to say that this could be very beneficial to the frameworks as a whole. As I put in the “GetSparks.org Manifesto”:

1. There are plenty of feature requests for CodeIgniter, especially when it comes to libraries. 99% of the suggested libraries don’t belong built-in to the framework. We hope that Sparks helps keep CodeIgniter one of the lightest, fastest frameworks for PHP.
2. Some fantastic and useful libraries have been written for CodeIgniter, but they remain scattered around the internet on blogs, wikis, forums, and github. Using these in your projects is a chore of copy and paste.
3. When you’re thinking of using someone else’s code, there isn’t much of a way to gauge whether it’s ready for the big-time. Is it fault tolerant? Unit tested? Relatively recent?
4. Most importantly: CodeIgniter developers don’t have an easy way to share their code and contribute extensions to CodeIgniter functionality.

It all comes down to making code easier to use and share among CodeIgniter developers.

If you’re interested in helping out on the project, reach out to team@getsparks.org. Right now, the team consists of me, John, Beau, and Mike. If you just want to follow along, check out http://github.com/katzgrau/getsparks.org. I’ve already received a ton of feedback, and it’s all appreciated.

PS: John and I put together a podcast explaining why we thought all this was needed by CI a couple weeks ago. Check it out!

Over the weekend I put a full day into creating and completing a WordPress plugin that probably doesn’t appeal to anybody except for developers: A tool to list your github and bitbucket projects right inside a post or on your side bar.

You can see it in action on my projects page.

Basically, I was tired of updating my long-obsolete project list. These days, everything I do is kept on a publicly-hosted repository anyway, so why not pull my project info from those places so it updates automatically?

The plugin is simple to use. Just insert something like:

{{github:katzgrau}}

In your post or page where you want the list. Here’s a real-life example of the output:

• KLogger — 87 following

  A Simple Logging Class For PHP

• ajax-proxy — 5 following

  An easy-to-use PHP ajax proxy class and script for facilitating cross-domain ajax calls which supports cookies and has minimal dependencies (doesn't need curl)

• WP-Easy-Cache — 1 following

  A PHP class for easily caching data programmatically in WordPress. Oriented for develeopers pulling Twitter feeds, etc. A nice alternative to the weak built-in cache functions.

• ci-robot-helper — 5 following

  A spark that can be used to generate questions and answers to avoid robot form submissions

• wordpress-github — 21 following

  List your github and bitbucket projects on your WordPress blog really, really easily. Why? Because you're a baller.

• getsparks.org — 74 following

  getsparks.org - The CodeIgniter Package Managment Repository

• spark-sdk — 5 following

  A CodeIgniter Spark to assist in developing and validating new sparks.

• chip — 57 following

  A log file multiplexer and monitor. Tail multiple remote or local log files, set actions, and more. A friend to every developer and system admin. Alpha.

• boomcalc — 1 following

  A jQuery plugin that renders a usable calculator in a DOM element.

• notes — 1 following

  An open-source multi-user website building application

• access — 6 following

  A CodeIgniter Spark for easily protecting all or part of your site with HTTP Auth prompts

• codeigniter-amazon-ses — 2 following

  A CodeIgniter library to interact with Amazon Web Services (AWS) Simple Email Service (SES)

I use BitBucket for CodeIgniter-related projects, and GitHub for pretty much everything else. So on my project page, I actually do:

{{github:katzgrau,bitbucket:katzgrau,sortby:watchers,sortdir:desc}}

Which pulls projects from both github and bitbucket, combines them, sorts them, and displays a list. A widget which comes with the plugin will do the same thing if you just want to list projects in your sidebar.

Anyway, check it out. You can find it in the WP admin plugin panel by searching for ‘GitHub’. Then just look for the ‘GitHub and BitBucket Project Lister‘. You can find the github repo (where it’s developed) here: https://github.com/katzgrau/wordpress-github

In my initial post after joining the CodeIgniter Reactor team (over Thanksgiving weekend ’10), I went as far as to saying that you could hold me responsible for the quality of the CodeIgniter documentation. Here’s a universal truth: Documentation > magic.

CodeIgniter 2.0 was released last week, with an announcement on the EllisLab news feed. The “Reactor” project is now considered to be “CodeIgniter”. All official forum references, downloads, and docs referring to CodeIgniter are referring to the project sitting here at BitBucket.

You can check out the lengthy change-log here: http://codeigniter.com/user_guide/changelog.html

Version 2.0 was released while some big features were still in development (but not 100% ready for the limelight). My favorite upcoming feature (by no coincidence) is something I’m currently putting together: A user-contributed note system for the user guide.

Everyone who keeps a place in their heart for PHP (as hard as it may be at times) knows how helpful php.net is. It’s a single place for clear PHP documentation, code examples, and user-contributed notes.

Some would argue that the most helpful parts of the PHP docs are the notes that PHP developers contributed themselves. A long-time request for CodeIgniter has been to add something similar the user guide.

Since late December, I’ve worked been working on (and have pretty much completed) a full-featured versioned user-contributed notes system for the docs. You can the see the progress in the BitBucket ‘user-notes’ branch:  https://bitbucket.org/ellislab/codeigniter-reactor/src/a6f52cbc8229

The actual application used to host the notes is being developed at: https://bitbucket.org/katzgrau/ci-userguide-notes

And of course, some screenshots of notes in action:

Adding a note looks like a clone of the contribution page at PHP.net:

You can check out a live instance of a user guide with the new system here (link not guaranteed to work into the future!): http://ci-notes-exp.katzgrau.com/user_guide/libraries/benchmark.html

Like I mentioned, the notes are versioned. That means notes can be promoted from older versions to newer versions, and they can be pruned from newer versions as they become obsolete, without affecting the old. Best of all, the user_guide will still come distributed in HTML format with the framework. The notes are pulled in and loaded via some simple Javascript.

I’ve always thought the CodeIgniter docs were the best among any framework that I’ve come across. I think this’ll take them even further.

Look for them at the end of Q1 2011.

There are a lot of people out there who call themselves “LAMP” developers — short for Linux, Apache, MySQL, PHP. That’s the standard configuration for production PHP applications. Recently, I ended up having to build a CodeIgniter application on Windows, IIS, Mysql+MS-SQL, and PHP. Sound like there are bound to be issues? You bet, and it especially hurts because now I’m a real-live WIMP developer.

And what made it even more interesting was that due to constraints, I had to develop the application in Ubuntu and deploy to Windows for production.

Please keep in mind that I didn’t opt for this setup by choice. The servers to be used were already in place, and well, it just had to be this way. I’d imagine this unholy mix can be found on server farms somewhere around the seventh or eighth circle of hell.

Anyway, the point of this post is to document a few “gotchas” that came up along the way. At this point I should say that application is now happily humming along in production. I knew from the start that mixing all of the above would be a headache, but luckily, things worked out without sapping too much time. I should also say this before I start: Thanks to some great work done by others over the past 2 years, this setup was actually possible.

Gotcha #1: PHP and MSSQL on Ubuntu

Thank god this was so easy. In order to use the standard database functions like mssql_connect, mssql_query, etc, all I needed to do within my existing LAMP installation was run:

$ sudo apt-get install php5-sybase

And sh-bang, I could connect to SQL Server without an issue. From CodeIgniter, I set the database to use mssql as my driver, and I was home free.

Gotcha #2: PHP and MSSQL on Windows

For years, forums and IRC rooms were filled with hopeless requests to get these two to mix. In 2008, Microsoft wrote a driver to help PHP developers seamlessly connect to SQL Server. For Win-PHP installations, just install this gem: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=80e44913-24b4-4113-8807-caae6cf2ca05 . Also, read up on the docs.

That driver uses a different API then the regular PHP mssql_* functions. In fact, it uses sqlsrv_* functions instead. So CodeIgniter can’t work with it out of the box. Luckily I found an excellent 2 and 1/2 year-old post by a guy who wrote the CodeIgniter driver to work with the Microsoft drivers. Just download the code, and drop it into system/database/drivers. Read up here: http://www.kaweb.co.uk/blog/mssql-server-2005-and-codeigniter/

One thing you will have to do to make it work with the latest version of CodeIgniter is create a dummy function in sqlsrv_driver.php. Just drop ‘function db_set_charset() { }’ somewhere in the class declaration.

As a side note, that driver would make a great addition to CodeIgniter Reactor.

Gotcha #3: mssql vs. sqlsrv

Notice that I had to use different drivers for connecting to SQL Server between Ubuntu and Windows. This is why it’s handy to use some sort of database abstraction class like the one that comes with CodeIgniter. All I had to do to switch between drivers when I deployed to the new environment was edit the configuration.

Also, query result fields that are fetched using PHP’s mssql driver come back as strings. The Windows sqlsrv driver gets fancy and hands back field values as objects. Your code won’t have to change for the most part, but beware that MSSQL ‘datetime’ fields come back as native PHP DateTime objects using sqlsrv_*, not strings. In the code, I ended up doing something like: if($date instanceof DateTime) return $date->format(…); else return $date;

Edit: Commenter Brian Swan and Twitter user Juozas Kaziukėnas have pointed out that the sqlsrv_ PHP driver will take a boolean ‘ReturnDatesAsStrings’ option in sqlsrv_connect() that specifies whether datetime fields come back as strings or objects. More info is here: http://msdn.microsoft.com/en-us/library/ee376928%28v=sql.90%29.aspx. Thanks guys!

Gotcha #4: File Permissions and Logging

As the author of WPSearch, a Wordress search plugin which does heavy work with the filesystem, I can say that the number one cause of broken installations is that the permissions are too strict. On Windows, files can appear to be 777 when viewing them via FTP, but on the Windows end, they are set as ‘Read Only’, or ‘Archive’. This throws a serious wrench into things.

When I first deployed to the production server, all I would get for responses was a blank page. Worst of all, the log wasn’t writing anything. After a trace through the CodeIgniter bootstrap, I found that the application died when the logging class was loaded. If your application’s logging threshold is set to write anything, and the logging fails, the application might just crap-out. This is different behavior than I’ve seen on linux, where you just won’t see logs appear in the logging directory, but the overall application still works fine.

Just turn off logging to make sure that empty responses aren’t the result of file permission errors.

Gotcha #5: No .htaccess Fo’ You!

I hadn’t known that I needed to drop the final application into an IIS instance from the start. I learned about that 1 day prior to the launch. Before that, I though I’d be rollin’ on Windows/Apache. Wrong!

IIS doesn’t use silly .htaccess files, which I had only used for standard URL rewriting/prettified URLs. I was forced to decide between converting the .htaccess to an IIS web.config file, or just ditch the prettified URLs. Since it was a small application, I went with the latter. Here’s a nice StackOverflow thread discussing a translation though: http://stackoverflow.com/questions/702526/translating-an-apache-htaccess-file-to-an-iis-web-config

Edit: Juozas had some comments here too: “@_kennyk_  about .htaccess vs web.config – you can actually import .htaccess in IIS URL Rewrite section.”

Gotcha #6: 2 Databases, 1 Application

This is more of a CodeIgniter issue. For this application I had to lookup data in a MySQL database, then use some of that information to pull rows from a MSSQL database. The hurdle revolves around having two concurrent database connections open in CodeIgniter.

You can’t really load the database in traditional CodeIgniter style, like $this->load->database(), or by autoloading it. Something like this doesn’t work:

$this->load->database('mysql-group-name');
# Do Stuff with mysql
$this->load->database('mssql-group-name');
# Do Stuff with mssql

Instead, you have to ask CodeIgniter to hand you back the actual database object with each connection. It’s a good idea to encapsulate each within the models where you’re using them. Do something like this:

class SomeMySQLModel extends Model {
  # the mysql db instance
  private $_db = NULL;

  function SomeMySQLModel() {
    $this->_db = $this->load->database('mysql-group', TRUE);
  }
}

class SomeMSSQLModel extends Model {
   # the mssql db instance
   private $_db = NULL;

   function SomeMSSQLModel() {
     $this->_db = $this->load->database('mssql-group', TRUE);
   }
 }

Gotcha #7: Mysterious lag time

IIS can exhibit some odd behavior regarding response times. When I was initially testing the application on my SliceHost dev server, I was getting pretty speedy responses in about ~100ms (keep in mind that I was connecting to both MSSQL and MySQL across the internet, not locally).

But when I moved to production, requests were taking 6 seconds each. Confused, I thought there must be some sort of bottleneck in the application. I used CodeIgniter’s profiling and benchmarking classes to investigate. I benchmarked the MySQL and MSSQL connections, queries, and overall application execution time.

The app was reporting that it was finishing responses within 100ms. So where was this strange delay coming from?

I then thought there might be some sort of redirect loop going on. From the shell, I ran:

$ time curl -v [address]

And something else became apparent. The full content of the page would come back, but there was a 6 second lag before the connection would finally close. After a little research on the Google, it turns out I’m not the only one who’s observed this with PHP and IIS: http://www.google.com/search?q=iis+php+response+lag

I would like to say I figured out why IIS was being so lame, but the in-house net-admin suggested moving the application to another production server on hand, where the issue mysteriously dissappeared. At that point, everyone was happy, so I didn’t look into it any further. I did read about some resolutions regarding DNS settings, and skipping name resolutions in the db configurations. That might have been it, but I’ll never know.

Recap:

Don’t willingly try this. That being said, everything worked out much better than it could have, and there were relatively easy solutions to the bumps along the way. If you have to put together a project like this, I highly suggest using some sort of database abstraction (or a framework like CodeIgniter), and planning out how you’ll work out URLs, permissions, and differing environments. Thinking these things over will save you a lot of time, and hopefully leave the stakeholders a whole lot happier.