I am not a huge video fan, though watching a video online does have an undeniable coolness factor. I have done some client work involving videos for a site and during the process ran into a few things that might be useful to others trying to handle video. There are quite a few open source and inexpensive tools to help deal with video handling, and combined with some server settings and PHP code it is possible to build some pretty cool video features.

    I think the phrase "Web 2.0" is for the most part universally despised, and I wholeheartedly subscribe to this point of view. While it may be fluffy market speak it does carry a meaning to me, a vague and over hyped meaning, but a meaning none the less. When I work on client sites I will suggest using AJAX or a more interactive design if doing so is a good fit for the site and overall functionality. More often than not however clients will ask for dynamic parts of a site, even going so far as to say "I want this page to be more AJAX-y". Over the last few years I have been involved with and written quite a few different dynamic and interactive web site features. Thanks to great packages like Sajax, Prototype, and Script.aculo.us among others, adding varied levels of web 2.0 goodness while keeping an eye on overhead and bloat is not too difficult.

    Rarely do I post what I would call "opinion pieces" (that is not to say my average post is not littered with opinionated statements), though I occasionally read some while trolling through tech and PHP related news and blogs. While doing so recently I came across an article with a title similar to "40 things bad PHP programmers do".  As I scanned the list I thought the ideas where all valid, if not a bit over zealously stated in an effort to make the point. This and a recent job interview (in which I did not get the job) got me thinking again about something I have pondered for a long time: How does a programmer balance practical limitations with best practices that can be difficult and time consuming to adhere to?

    Email comes in all shapes and sizes, from complicated nested multi-part structures to simple text bodies. But even messages comprised of just plain text require special preparation to safely and properly display from within a webmail application. For security purposes any HTML within a text message needs to be converted to appropriate entities. Using the CSS "white-space: pre;" setting is effective as well, the CSS equivalent of <pre> tags, but this makes word wrapping the message in such a way as to ensure that the webmail interface remains consistent very tricky. Neither approach is ideal (entities vs pre-formatted), and both suffer from some similar display problems. For example a line containing 200 characters in a row with no spaces, such as a long URL will either spill out from it's containing div or expand the width of the page to force a horizontal scroll bar (yuck). To further complicate the situation we need to be able to create links to both urls and email addresses within the text as well as highlight reply quoted sections, not to mention take into account converting the original character set to UTF-8 for display in the page. For Hastymail 2 I have been working on a new system that preps the text body in such a way as to address all of these concerns and creates a situation in which the text is wrapped by the browser automatically for almost any practical resolution without spilling out of its container and without horizontal scroll bars, and without a user setting that defines the maximum line length, all the while maintaining the intended format of the original message as closely as possible within the constraints of the presentation medium.

    Having decided at the new year to revive the Hastymail project (a neglected PHP webmail client I wrote years ago), I set out to improve the project website in a few different ways. First I moved it from the sourceforge web hosting to a private host, changing the site name from hastymail.sourceforge.net to good old www.hastymail.org. Many thanks to ThinkHost for generously donating the hosting to our project, and to David Schaefer for safe guarding the hastymail.org domain name for years in the event that we would someday need it. Secondly while the code is still managed at sourceforge, and we will continue to support any use of the sourceforge trackers and feedback tools,  we now have some nice feedback and discussion facilities at our main site as well.

   Hastmail 2 has kicked off with a bang. And by bang I mean a bunch of late night coding. We have svn setup for the new code at sourceforge,  and porting useful Hastymail 1 code has begun. The framework we are building from provides many basic web application mechanics, so the porting effort is focused on the back end functionality, like talking to the IMAP and SMTP servers. So far almost 1/3 of the IMAP related code has been ported, reviewed, and improved. I'm excited! I have yet to determine a satisfying metaphor to describe what it's like coding to the IMAP rfc, but when I do it will be rife with ambiguity if nothing else. Having not dug into the bowels of that dastardly document in a few years I almost washed away that clinging chill it evokes that eats away at your belief that you can read and understand the English language. Here is quick list of tips for anybody diving into the verbal quagmire that is the IMAP protocol RFC:

  I have been meaning to update the site with some new fixes and features that have been running in my local copy for the past month and finally have taken the time to do so. So without my usual off topic long winded self absorbed introduction here is whats new.

    Maybe it's the new year getting to me. Holidays always seemed so contrived after reaching adulthood, as if rather than celebrate human achievement or spread good will the experience instead is commercial and fabricated, but as I start to slide into my late 30's I'm as sentimental as a child. Worse even I get choked up at times for literally no reason at all. Seems even a Mountain Dew commercial can bring a tear to my eye. Whatever the cause I have decided to dedicate some time to Hastymail development again.

    People often ask me, "Jason, oh great PHP master, how can I write secure PHP code?". To this I respond "Climb back down the mountain and return to your home my son, the answers will find you there ... as long as you click over to my blog and wait until I get this post done. Now GO!". Seriously though, about the only thing I am a master of is run on sentences, embellishing, and the sometimes spooky but usually droll ability to raise either of my eyebrows individually. I have however written quite a bit of PHP over the years and have some suggestions to help others avoid some of the mistakes I have made in the past. So without further ado, here is my somewhat short, seemingly solid, sometimes sordidly sarcastic, synopsis of secure scripting suggestions.

    As a child I was, for a time, fascinated with computers. I even briefly entertained the idea that I would write a game in BASIC. The hours it took me to draw a slightly skewed line across the 16 color monitor of my Atari 800XL dispelled that notion almost as quickly as my prepubescent brain had latched on to it. Fast forward to college and while not a CS major, pursuing a Mathematics degree involved some logic and programming courses. When I say "pursuing" I mean barely attending classes and eventually dropping out completely to instead hitchhike across the continental US with all my belongings on my back and only a vague idea of where I was going. The bits of pascal and logic I did study did not stick with me except as a faint memory. Fast forward 8 years to 1998 and I have a wonderful daughter, a quaint middle management job at a box factory, and a renewed interest in the surging home computer phenomenon going on at the time. So with a brand new Windows 98 machine and a copy of Deitel and Deitel's C++ programming purchased for 10 bucks at a garage sale I set out to learn to write software during lunch breaks and late evening hacking sessions.