Based on some pretty awesome feedback that I've received from people who apparently find Time Tracker v1.0 very useful, I'm adding a few new features and improvements to the user interface.

Time Management experts will tell you an individual only has 24 hours in a single day; proper time management isn't finding time in your day, but rather discovering and dealing with inefficiencies in your day. The best way to discover those inefficiencies - at least as recommended to me as part of the AMA Time Management Strategies seminar which I recently attended - is to document how you spend your day.

With that, I introduce Time Tracker, an Open Source Efficiency Tracking Utility for the Lotus Notes Client.

The idea is simple. At the start of your day - upon completion of your first task - create an entry highlighting what you did and whether you feel it was an efficient or inefficient use of your time. Based on several requests, you can also select the priority, apply categories, or even align your time against a project.

For Lotus Notes Client v8.0 and above, you can use the Time Tracker Widget to make this process even easier!

I've been playing with this idea for a while now, and was just recently given an opportunity via a customer project to do it! The plan is to have an ongoing series here that details a project build, from the initial architecture phase to deployment. And as an added bonus, I plan on providing the build project application a download on this site at the end of the build/post-deployment.

So for our first Public Build project - which is due December 31st (it's an End of Year thing) - is a relatively simple Events Calendar. The Events Calendar (or EC) will allow a group of event coordinators to post and maintain event entries while allowing authenticated users to sign-up for attendance to an event. The client usage scenarios will be for both the Lotus Notes client and the Web Browser client, so we'll need to make this solution both functional AND portable.

Starting Monday, you'll see a flood of posts discussing a (hopefully) complete list of requirements as well as a pseudo-scope of work. From there, we'll start a deep-dive into the development process with screencasts and blog entries outlining exactly what I'm doing. Outside of a minor break for the holidays (or at least until the family is nestled, all tucked in their beds) I expect to get quite chattery in this space for the next two weeks.

The EC Public Build will hopefully be a first in an ongoing series of projects that hit that sweet spot of 1) being useful to more people in their base build than just the intended customer and 2) being at least somewhat interesting to you, Constant Reader!

I am constantly telling people (and constantly being reminded through the day-to-day) that I "married up" when I was lucky enough to marry my wife. Shirley is one of those amazing people that not only puts up with me (which makes her a saint), but that enables me to be a better person just being around her.

I've gotta tell ya... I find that I've "married up" with my circle of friends. I've not only got a more firm footing on Match Maker as a result of several IM conversations and a phone call with Tim today, but there's something coming down the pipe that will knock the fillings out of your teeth - an all-star team (and me - ftw?!) working on the next "sliced bread" solution.

But back to Match Maker. I'm slightly modifying the data architecture of Match Maker - pushing for a more globally useful approach instead of a source database/document approach - which should allow some amazing functionality. Simply put... (get ready for some pseudocode-babble):

1. You define an Application Profile - which is a simple NotesDocument that lists the Server, NotesDatabase, and it's "status".
2. You then define a Relationship Profile - which consists of the following NotesItems:
   

   hash	Simple "user-defined" formula - ie., field1 + "_" + field2 + "_" + field3
   app_source	Selected "source" Application Profile.
   app_source_criteria	Evaluated simple "user-defined" formula used to limit the Source Application's NotesDocumentCollection.
   app_target	Multi-value selected "target" Application Profiles
   aoo_target_criteria	Evaluated simple "user-defined" formula used to limit the Target Application's NotesDocumentCollection(s).

3. Now, Match Maker will run on all "active" Relationship Profiles:
   
   1. Evaluate and get a handle on the Source NotesDocumentCollection via the Source Criteria.
   2. Get a handle on the first Source NotesDocument.
   3. Evaluate the hash formula against the Source NotesDocument.
   4. Check for an existing Relationship Document for the evaluated hash. If none exist, create one and set it's DocumentUNID to @Password(evaluated hash)
   5. Evaluate and get a handle on the Target NotesDocumentCollection via the Target Criteria.
   6. Loop through the Target NotesDocumentCollection, updating the Relationship Document match NotesItem with the following: AppProfileKey^targetDocUNID
   7. If you've gotten this far - save the Relationship Document and move on to the next Source NotesDocument in the Source NotesDocumentCollection.

So, let's say I want to find matching documents to each email in my Inbox, across my CRM Contacts Database, Helpdesk Database, and Projects Database solutions. Instead of (heaven forbid it!) modifying those target NotesDatabases or running time-consuming searches in real-time against 3 different databases, all I'll need to do is set a Relationship Profile with a hash of from + "_CHP". To grab the NotesDocumentCollections of matching documents, I just simply do a MatchMakerDB.getDocumentByUNID and feed it the evaluated hash (from + "_CHP").

Simple and immediate. It's almost finished - still playing around with a few things - but it'll be a pretty sweet (and hopefully useful) multi-database meta index utility for those of you who find yourself needing such a thing!

A better description, and a MUCH smoother process overall, v0.2 of xCopy comes with the following enhancements from the original:

• xcopy via Java Agents and Script Libraries
• Transaction Log documents via Java Agents and Script Libraries.
• Can now handle multi-thread large file xcopies.

And that's about it! Not a major release from a feature perspective, but certainly a major overhaul as I've ported the actual functional Agents from LotusScript to Java... with Tim's help of course!

New/first-time xCopy downloaders just download, sign, and go! v0.1 users: download, sign, change to a Design Template, change the extension from .NSF to .NTF, and run Replace Design!

If you have a need to either manually or automatically copy defined files to a defined target location, this is the app for you! If not, download it if for nothing other than a very simple example of Java Agents and Script Libraries. Feedback and feature requests appreciated.