Tom’s Graphic Design Journal

So work has this help desk / ticket system. Very basic, but taking this conversation a step further...It could be any ticket system script you have on your server. I won't go into trac though -- but I know how it could be integrated just the same. I'm going to stick to PHP for now because this is the implementation used in my situation.

The help desk form has some specific fields related to the web site and then stores the ticket into our database and then e-mails it off to people on the development team. Basecamp doesn't have a ticketing system (STUPID - this is merely one reason why trac is infinitely better than basecamp) so our requests and e-mails are all separate from Basecamp. The project manager has to transcribe all the e-mails and store them in Basecamp for record keeping. Note now a time stamp discrepancy aside from it being very very time consuming.

So what to do? Well, there's a 3rd party site that has a ticketing system for Basecamp at http://bctix.com. It's ok and completely non-invasive...but it's also limited and non-intuitive. Plus not integrated with your personal site or Basecamp in terms of filling out a ticket support form.

No one besides the signals there are going to make a perfect integration into their system. They need to do that. Although we can copy their css/html and layouts to make our system "look" like it's part of Basecamp...minus the URL. In my case we have our own ticket system that looks like some tools on the client's site and not like Basecamp at all. No big deal. However...it is familiar looking to the client and the form is completely customized for the client's needs.

Now what the bctix site does is puts in the title of each message, numbers that essentially equate to different things like categories and status. Ugly and more important very easy to screw up. The other downside is that you have to use the bctix site's forms.

My super slick solution (which was hours of pain) is to add on to our already existing form ... note for others out there, this means add on to your already existing ticket system ... and make it send off to Basecamp via the API at the same time it saved the ticket to the db and alerted the staff by e-mail. Cool. Easy. So then what? You have to go into basecamp to update the ticket or reply to it? No no no, here's the cool part (where the headache came into play)...

Along with e-mailing the proper people, there was another e-mail address tacked on to the CC which contained helpdesk-{basecamp ticket number}@domain.com. This wildcard e-mail address was then handled by a script on the server (Qmail was being used). This now leaves an address to reply to that is our "basecamp bridge" and what happens now is the server reads any e-mails coming back at it and takes the number past the hyphen ... which came from the response we got from the basecamp API when the initial ticket was made ... and adds a comment instead of a message using the Basecamp API. Now we have all replies from our e-mail programs automatically saved as comments (replies) in Basecamp under the appropriate message! It's by id number too so we can change the title of the message to file it or do whatever we want. We won't get messed up. 

Cool. So if you haven't figured out where I got a headache...it was in the server setup to receive e-mails to a wildcard address and process the mail through a PHP script. The other part that was difficult was all the regex matching to removed nested quotes from e-mails, privacy policy statements our company had at the bottom of our e-mails by default, etc. So in the end, it was just our replies that made it to the comments and not the same ticket repeated over and over. Very clean. 

So how'd we get the server to handle the e-mail? I partially followed this tutorial on evolt. I also looked up the Qmail manual/documentation which came in handy. Also note we are using Media Temple's DV server...So you need root access sadly. Unless -- your host is super cool and in your control panel you can forward e-mails to a PHP script...and also setup the catch-allo or wildcard aliases. I think that's possible somewhere under some shared host...it sounds possible at least, though rare...but think about people who can e-mail in their blog posts, right??

So in the .qmail file I basically made the setting to run a PHP script that analyzed the headers. At first I thought I'd be REAL sneaky and read the message-ID and references headers to see the e-mail thread and keep using that to distinguish between comments or replies. I also set a uid in the initial e-mail that was sent off from the help desk (which is still sent off). That didn't work out so well because different e-mail programs destroy headers. Almost all (if not all) e-mail programs remove any custom headers you set. So that's actually good -- note the uid I set now acts as the distinction between a brand new e-mail or a reply...because obviously replies will never have that uid, right?

So that's it. Our script basically reads the e-mail address in the header and grabs the id and uses that to call the Basecamp API to leave a comment on the message id. Voila. A very slick and transparent integration. I'll try to clean up my experiment and post something later.

Lots! Aside from my full-time job, I just wanted to plug a shameless link. Cloud-9ine uses my media blog for a face so I can keep notes about my discoveries with Amazon's web services EC2 and S3. Course it's my blog so whatevs At any rate...and more importantly, I wanted to let anyone looking at my blog (and anyone interested) know that I'm working on making my media blog / cms infinitely scalable.

It has some refinements that need to be made. Some bits that could work a little faster and basically more dynamic...for example, adding one or adding ten images at once...Things like that. This is pushing the development really into the next phase of beta which is just polishing things off. I already have working demos, but I want to polish what I have before adding more features. I also want to of course figure out how it'll all work in terms of being deployed.

So how will that deployment work? Well, I still want to offer some sort of version to the world because I've been a leech long enough and I want to give back to the community. We all really need better blogging software anyway. WordPress (used right here folks) and Blogger, etc. are great...but...It's 2008. We have all this new wonderful technology that simply didn't exist when all these blogs and CMS' were built. No fault of anyone...and certainly WordPress is quite good. I won't go into my theories, there's enough of that here and where I think the future is going to take us with web development.

Back to the point. One of the things I envision happening in the whole web industry is a very acute change in how our web sites are hosted. Of course Amazon EC2. That's not the only provider either, there's others like Joyent and many "regular" web hosts that have been offering VPS solutions for a long while. That unique thing about EC2 (and Joyent to some extent, but that's Solaris and I believe more geared for Ruby - bleh) is that you can set the instances up in such a way that you can simply turn on and off more as you need. This is way cool and here's why:

Minervablog will be more of what they are coining the phrase "appliance." Where you will simply be able to turn on as many instances as you need to cover the traffic...But probably automatic. Meaning you will run one instance and as the traffic increases more will automatically turn on. As the traffic spike subsides, the instances will turn off. There will be backups, etc. Also, some nice little features.

Nice features? If instances automatically turning on isn't enough...another feature slated is the ability to "phone in" more support. Meaning, Minervablog will e-mail out to your phone an SMS (e-mail to sms via phone carrier) and alert you to errors. It will also give you the ability to e-mail back (if you can from your phone, cool, else, where ever) to make certain changes. Changes like starting up or turning off an instance, and more...Oh yes, there's more. This is just a taste.

I've been working with sites, and quite specifically, some fairly unstable sites. It's extremely handy to have e-mail alerts. However when you get one, you really can't do anything about it if you're out on the road or somewhere away from a computer. Well you still can't fix major issues, but with some of the features I have figured out, you'll at least be able to "reset", or add/remove power to, your site.

Note: I do quite a bit of research and let me tell you what I'm working on (whether you see it or not) is very big and doesn't exist elsewhere. I know it doesn't because the technology is all too new. Similar solutions (that are probably just as good and some better) do exist, but the cost and availability is the catch. Thanks to new technology, that's changing. Make no mistake...If it's a site that needs a CMS/blog and has a ton of traffic - this IS the solution it needs. Didn't I say it was 2008?

Of course it may be 2009 by the time this all comes together...But I hope not! I hope someone out there is interested, I just may work faster and stay up later each night.

So first off I finally found, cleaned up, and posted the source code to the little demo/tutorial on CakePHP and AMFPHP I posted a while ago here. I didn't write the most comprehensive tutorial, I highlighted on some key points. However, getting CakePHP to work with Flex is quite easy.

Also note that since this tutorial which used CakePHP 1.1 and AMF0 (I believe you can still switch that out for AMF3) there has been some new things going on. First off, there's AMFEXT which is much much faster than AMFPHP because it's a server extension. It also makes things easier for you as far as programming is concerned. There's a CakeAMF project that implements AMFEXT in CakePHP. I have yet to try this, but am very eager. The only downside I should note is that you have to install the server extension, so that pretty much cuts most shared hosting sites out.

Then there's SWX, which is a native data format for Flash. So that of course has been implemented in CakePHP as CakeSWXPHP which can be read about on the CakePHP Bakery. I personally didn't have much success with that at a first quick try, but it's also apparently very easy to use and setup. It also appears to be less code work involved than AMFPHP. I am unsure about the speed though. Here's a little tutorial about using flash remoting with SWX and CakePHP to make a Flash blog written by wouter.

So there's a few options for flash remoting and CakePHP. Now, I'm going to say the same thing I always tell people. Be CAREFUL how, when, and where you use Flash. You probably should not make a blog done completely in Flash if you write a lot and want it to be picked up by search engines. First off, it takes longer to load...but that aside, you're really missing out on what blogs are so great for - getting traffic. Search engines love text and hence crawl and list blogs a lot. So if they can't see the text in your Flash blog...you're in trouble.

I'm of course working on a media blog that will utilize both HTML/CSS and Flash to get the job done. Making it not only load more efficient, but also reach that maybe 10% market that doesn't have Flash and also be better optimized for search engines. More on that later, or go back and read some of my blog posts. I'm kinda at a point where I need to clean up some things to move forward with it - but the major functionality is done with that. You can also see Minerva blog in action...and kinda unrelated to this post - it doesn't use flash remoting, it uses RSS feeds...because I felt they were more universal and can be used for not just the galleries but also syndication. Aside from, perhaps, the most important reason: there's no writing back to the database using Flash with my blog. See how planning goes a long way?

So oddly RSS in CakePHP 1.2 came up a lot one night recently in the Cake IRC channel. There's a really good article on the Bakery about it, but that's for CakePHP 1.1. In 1.2 it's MUCH easier to do, there's less code. So here's a short how-to, though I'm sure it's published elsewhere, the more places one can find from Google the better.

First in your /app/config/routes.php file you need to setup the routing to handle the rss extension. So just add this line:

Router::parseExtensions('rss');

Then you'll need to make some changes and add a method in your controller.

// make sure you have text and time helper, the rest are whatever else you need
var $helpers = array('Html', 'Form', 'Javascript', 'Text', 'Time');
// example method i have here, but your find methods and model will be different of course
function latest() {
       // shows latest posts
       // So the first thing here checks to see if a .rss has been requested...
       // if so get what we need for the feed
      $isFeed = ife($this->RequestHandler->prefers('rss') == 'rss', true, false);
      if ($isFeed) {
            $this->pageTitle = 'Latest Posts Feed';
            $this->set('channel', array('description' => 'Latest posts'));
        }
       $limit = 10;
       $this->set('posts', $this->Post->findAll(null, null, 'date desc', $limit, null, -1));
    }

Then we'll go over to our view template.

// this file is located under /views/posts/rss/latest.ctp
items($posts, 'transformRSS');

function transformRSS($data) {
        return array(
                'title' => $data['Post']['title'],
                'link'  => 'view/'.$data['Post']['lid'],
                'guid' => 'view/'.$data['Post']['lid'],
                'description'  => $data['Post']['body'],
                'author' => $data['Post']['author'],
                'pubDate' => $data['Post']['date']
        );
}
?>

Just take note that your model and fields will differ from what I've output in the feed. "lid" is something I created for the link id...which is part of a friendly url system I have setup for example. Everything should explain itself here, but the most important note is the location of the template file. It should not only be the name of the method (like usual) but should be located under the /rss/ directory under the model's view directory where the other templates are.

That's pretty much all there is to it. RSS is quite simple to setup compared to what you neede to do with CakePHP 1.1. The main difference is a lot of the setup and creation of the xml document is built into 1.2 for you.

You can see this specific example in action on my media blog latest post feed.

I always write about CakePHP and love it. I give it mad respect because the guys behind that project not only deserve it, but without it I'd be stuck in the dark ages. Perhaps I'd move to Zend or Symfony, but I'm glad there's CakePHP. However, there's a bunch of other web frameworks that aren't well known (not that any of them really are in the big picture), they include CSS, Actionscript, JavaScript/AJAX, and more...but I'm just going to talk about the two most important of the current tools in my shed.

CakePHP

CakePHP is (obviously) a PHP framework that was inspired by Ruby on Rails...but thank god it's not using Ruby. Despite the fact that Ruby is now available on more and more web hosts...I just believe PHP to be a more popular and better choice. Not to get involved in a whole which language is better situation, but for WEB APPLICATION development, I prefer PHP over .NET, ASP, Jav