I let the cat out of the bag on twitter today and sent someone a link to Twitterpate.  Twitterpate is my threaded-twitter experiment.  I started it a couple of weeks ago in my spare time.  If you follow the twitter eco-system at all then you're more then aware of the ever-increasing number of twitter-clients that have hit the scene.  Each of these clients offers a unique set of features catered to a specific tweet-need, whether it be for a mobile device, trends, hash tags or what have you. A couple of clients have recently tried tackling the threading issue, but none of them, in my opinion, have done the task justice.

Here's the issue I wanted to solve...  If you "tweet" you may be replying to someone else's tweet.  When this happens you sometimes lose track of what's happening in a chain of replies.  This is because twitter is pretty linear.  New tweets appear at the top of a timeline with little connection to previous tweets that they may be replying to.  If multiple conversations are occurring simultaneously then things can get messy and you run the risk of losing track of where the conversation is going or what you're replying to.  I've run into this issue many times.

Twitter tried to reconcile these problems with the introduction of a reply-to field on a tweet, and then with the addition of a link to a tweet's originating message if available.  This is fine, but it winds up being a lot of extra work to follow a conversation and it prevent you from getting a full view of a conversation.  This is where Twitterpate comes in.  Twitterpate is a web based twitter client designed to parallel your twitter home page, but with the power of threading.  It also features some other handy tools, including auto-updating, grouping by day and some preliminary filtering capabilities.

Right now this is a spare-time project, but I hope to expand what I've started and continue to add features to it.  I'm also fairly confident there will be bugs to work out a long the way as well.  Twitterpate uses OAuth, so if you're curious and want to take a look, but don't want to share your twitter credentials don't sweat it.  All authentication happens on twitter, so you don't have to worry about any of your "stuff" ever falling into the wrong hands.

I'm really curious to get feedback and if you find any bugs, please let me know.

As a disclaimer...  the name "Twitterpate" is intended to be a play on the the phrase "twitterpated" from the Disney movie, "Bambi".  If you don't get it, rent the movie!

I've been getting into Twitter as of late, and I admit that I'm enjoying the micro-blogging world intermixed with a little bit of social networking.  I've been entirely disenchanted lately with Facebook, especially since their recent interface overhaul.  It seems overloaded, and they've pushed the micro-blogging feed too far.  The Facebook feed has reached a point where it's no longer useful because there is too much there.

So I've migrated to a smaller community over at Twitter, and I've been enjoying it - for the most part.  One of the things I started to miss from Facebook were the mini-feeds that would spin off of a posting, creating a conversation.  Now Twitter lets you converse with @tweets, but more then once I've thought someone was replying to tweet X when they were really replying to tweet Y.  If you use the web interface you can now reference back the old tweet, but there's an extra step involved there and it's only one tweet at a time.

What I've wanted for a little while now is threading for tweeted-conversations.  I want to take it a step further though, I want threading and then I want my client to be intelligent enough to move a thread up to the top of my tweet list when there's a new tweet in the conversation.  Then just for extra measure I want to be able to clearly see where tweeting on Day 1 is from tweeting on Day 2.

To my surprise there is very little activity on the world wide web for threading twitter.  I imagine that there are a number of reasons for this, the API rate limits being a huge one.  All this aside though, I began to think about how I would deal with threading twitter.  This snow-balled into an experimental project I am working on.

The idea for the project is simple, it's not to reinvent twitter nor is it to develop yet another air application for your computer.  It's simply to augment the existing web interface for twitter's user home page with a threaded version.  Along the way I may toss in some other nifty tricks, but the principal problem I'm trying to solve is threading.

So stay tuned and keep your eyes open, it's on the horizon... and if you happen to be following me on Twitter pay attention to the source of my tweets, you may even see this mysterious project appear occassionally.

I've gotten a couple of e-mails asking if jGrowl was compatible with the newly released jQuery 1.3. To the best of my knowledge jGrowl is fully compatible and there are no know regressions. I would recommend using the latest 1.3.2 release of jQuery though, albeit there are no known issues the items fixed since the initial 1.3 release are worth having and could possibly effect overall behavior.

The updates keep rolling out... I've done some more UI enhancements, including a toolbar at the bottom which will show you pericopes as you hover over days. I've also added the Gradual, Verse and Tract to Sundays - I have not yet had time to put these together for festivals where they are available. Each proper can also be collapsed by clicking on it's respective title and they can be universally collapsed and expanded with a +/- sign in the upper right corner of the day's header. I've straightened out some display issues with commemorations and other labels as well. I also have exciting news... Today I received from a friend who has been helping me with data entry about 85% of the daily lectionary from LSB (basically the non-festal portion), and will begin working to integrate this into sanctus.org soon. Keep an eye out, that and the new iCal export are just around the corner.

I've upload some updates to sanctus.org tonight, they include fixes to the existing iPhone optimized version (for those curious, just go to the normal site in your iPhone/iPod Touch), fixes to the Sundays after Christmas and New Years, fixes to some backend logic that no one cares about, the addition of text-links to Libronix (little icons at the end of Scripture readings) and the ability to go directly to a date by doing... http://sanctus.org/lectionary.html#YYYY-mm-dd where YYYY-mm-dd is the year - two digit month - two digit date, ie. 2009-01-05.

For those that have been asking, an iCal file is on the way. The file generated from the old sanctus.org site ended on 12/31/08 so if nothing else I need it. I'm verifying dates and things of that sort and then need to figure out a place to post it. There's also the possibility of a Libronix Lectionary file coming as well. If you're in need of these resources and would like to see it and others please consider a donation to help support the Lutheran Lectionary Project. All donations go to defer the cost of hosting and bandwidth.

Pax Christi

I've just release jGrowl 1.2.0beta3 over at the jQuery plugin page. This release includes some minor changes based on user feedback to the way that a notification is closed. Currently the triggers occur by the little "x" close button or by way of time elapsed or by way of the "close all" button. While it's possible to introduce your own trigger for closing a notification (for example, click anywhere on the node), it's not as easy to implement. Subsequently, the closing off a notification has been moved such that at any time you can call, jQuery("div.jGrowl").trigger("jGrowl.close); and the close operation will be initiated.

You can download this release here.

Dates and timestamps and things of this sort have often been the bane of my existence when working with javascript. For whatever reason javascript never came out-of-the-box with handy dandy date utilities to make working with those types of variables painless. I'm slightly spoiled, because in PHP you can do just about anything with strtotime() and the formatting options of date(). PHP 5 tossed in the DateTime object and then things became really fun. Likewise, when I work in the world of Java there is SimpleDateFormat and the far superior Joda. Most of the time I just let these things do the grunt work when it comes to dates and I let Javascript feed off of their superiority.

Today I stumbled into Datejs, which is a Javascript library that takes from the best elements of the Java and PHP world, mixes them together and tacks on some excellent jQuery-style chaining to make what is by far the best date solution for Javascript I have seen to date. There are formatting features for outputting dates, conversion features for reading in dates, modification and comparison methods and best of all a series of chainable function to build dates, ie. Date.today().next().thursday();. How cool is that?!? I'm bundled this into just about everything I do, if I include jQuery or some other primary library into a project I expect to be tucking this in with it. Too often am I stuck with a date conundrum, so it's better to have this utility around.

Bottom line, if you're doing javascript work of any kind and haven't already found this gem - go download it now().

Unlike some other languages, PHP does not continue to run in the background even when "stuff" stops happening. Compare PHP to Java for example and you'll see what I mean. This can pose problems for large requests, where perhaps the browser gets locked up longer than most users are willing to sit by and endure. This can cause problems. One of the issues I've also run into deals with updating static content. Sometimes content changes, and in order to detect static content changes you have often have to do some work which calls into question the benefit of static content, or resort to caching which brings its own set of problems. Other times you just need to do something at a given interval or period, say for example checking to see if an RSS feed has changed. You may want to do this every 30 minutes. Your options are to check the time when a user access a page and decide if you should do some background work or resort to a cronjob and let it take care of this business. Most of the time one of these two options will work just fine.

I'm a firm believer that an out-of-the-box application should be as stupid-proof as possible, and that as the application packager I should assume the user knows nothing and do everything I can to make installation seamless. This is why I use a Phar to distribute app's and have them extract their own SQLite database, for example. With this line of thinking it's just not safe to assume the user has the slightest clue about cronjob's or how to set them up, let alone have access to them. So, what do you do?

Initially I assumed I would setup a single cronjob and call a single script which would dictate scheduling for programmatically designed "jobs". This would allow any one of my various modules to create a job on the fly programmatically and not have to concern itself with the particulars of how that job would be executed. Sounds fine, but still doesn't solve my dummy proof approach. Then I stumbled across this code snippet in the PHP manual while looking at ignore_user_abort()...

<?php
ignore_user_abort(); // run script in background
set_time_limit(0); // run script forever
$interval=60*15; // do every 15 minutes...
do{
   // add the script that has to be ran every 15 minutes here
   // ...
   sleep($interval); // wait 15 minutes
}while(true);
?>

Some purists won't like this code, but I think it's golden! I've been running some tests locally, and as best I can tell if you're smart about your "job" code you won't run into any issues. Part of the trick is remembering to make sure the scheduling script is running. I do this by updating a row in a database to indicate the last time the scheduler ran, and if that last scheduler execution exists outside of a given range (say twenty minutes with the above example), then I trigger the scheduler again. For this to work, though, keep in mind the scheduler needs to be triggered with an http request. You can do this either in the HTML-word using javascript or something similar, ie. an AJAX request to the scheduler. Or you can use PHP itself like this...

<?php 
$ctx = stream_context_create(array( 
    'http' => array( 
        'timeout' => 1 
        ) 
    ) 
); 
file_get_contents("http://www.mydomain.com/scheduler", 0, $ctx); 
?>

Notice this will timeout right away, the purpose is to initiate the scheduler and not to actually see what the scheduler is doing or wait for it. Another important thing to note is that you'll want to check to make sure the scheduler isn't already running when you go to start up the scheduler. I realize we just covered spawning the scheduler, but in the actual scheduler code you want to double check it's not running. It's entirely possible depending on your setup that a scheduler could get triggered when another scheduler is executing, and you want to be assure to avoid tying up your apache processes with unnecessary instances of the scheduler.

As a final precaution, realize that you need to be smart about your code in the scheduler. You need to aware of variable usage and what you're doing to the memory allotted to PHP. I suggest even going so far as to maybe evaluate memory usage in the scheduler itself, shutdown the scheduler when necessary and spawn a subsequent scheduler process. You also have to deal with error handling, both from PHP and from user-land. Cron takes output and e-mails it to you, that's an option, or an external log file is an option. Either way you want to be aware of errors and make sure the right people know about them.

Well, happy scheduling!

A new beta of jGrowl 1.2.0 has been uploaded on the jQuery plugin page. This latest beta fixes several syntax errors if you went to compress the library or obfuscate it, as well as fixes a major bug in the log callback. That error would have occurred in the event that a custom option object did not define a log callback. If you run into any issues or have any suggestion please feel free to send them to me. Otherwise, you can download this release here.

I've released two new versions of jGrowl this evening, the first is 1.1.2 and includes minor changes to 1.1.1. Nothing serious or exciting there. The other release is an initial beta of 1.2.0 which offers pooling capabilities. What I've noticed is that sometimes too many messages get sent to jGrowl at a given time and messages which are the bottom of a listing can expire before they ever come into view by the user. This really defeats the purpose and functionality, so I've been trying to figure out how to avoid this problem. Messages are pooled into a queue and will only be rendered in the event that the pool has now reached its pooling size. By default this functionality is turned off, however I've included an example file that enables this functionality and sets the pool size to 5 messages. For those who use jGrowl and have run into this issue I highly recommend trying out the 1.2 beta. I haven't decided if anything else is going into 1.2 yet, so you may be looking at a final release... who knows, only time will tell! :) Anyhow, feel free to provide me with feedback on this recent change. You can find these releases on the jQuery plugin page here.