Archive for October, 2010
It’s been about a month since I’ve completed the book on “Getting Things Done” by David Allen and integrated lists into my organizational process.
It’s a quick read (200 pages) and if you don’t want to buy it I found my copy readily available at my local library.
In this whole process of re-organization I have to say the greatest difficulties have been:
- Finding time to go over the lists (have now blocked out time for myself)
- Being sure to add items when they cross my mind
- Figuring out exactly what categories are effective for me
For those of you that aren’t familiar with the “Getting Things Done” (or GTD) process here is a quick summary.
The first phase is to gather. This could be a simple as everything from your Inbox to brainstorming all of your tasks and writing them on slips of paper.
Once you gather all of your to-do’s then you process. Each item gets placed into a category of your choosing. If you run across any items that take 5 minutes or less you go ahead and do them on the spot (phone call, quick e-mail, chat with a co-worker, etc).
Once you process you have lists of everything that was weighing on your mind in nice neat lists. From there it’s up to you to review and prioritize.
It is suggested that you run through this entire process once a week to ensure you are staying current and have confidence in your lists.
I personally am a big advocate of trying to do everything electronic. I find if I try to maintain a list on paper I inevitably tend to lose it or forget it.
So what could I use that would be fully electronic, easy to use, and be readily available wherever I go?
Seeing as how I carry a Blackberry for work, an Android phone at home, and split my time between 4 different computers I chose Evernote (http://evernote.com). Evernote has allowed me to set up my categories, access my lists from any device, and allows me to easily add an e-mail, picture, or a documents on the fly.
If you haven’t checked out Evernote it’s definitely worth a look.
The GTD process is still very new to me and the jury still seems to be out on how much more effective I am in work and home life (mainly because I have not fully formed the habit of add/checking my lists).
I think right now it’s subtle, but in time I hope to be one of those people that others say “when does he sleep?”
Share and Enjoy
A UDF is a User Defined Function in SQL Server. You can develop the function using T-SQL or your favorite .NET language (C#, VB, etc).
For Part One I’m going to talk about Scalar UDFs. Scalar UDFs are functions that return a single value only. There are a couple limitations to what UDFs can and can’t do. They cannot modify data in tables and dynamic SQL is also not an option.
Besides the function limitations they also have special syntax requirements:
1. They must have a BEGIN and END clause
2. They must be qualified by schema name.
3. You cannot omit parameters even if optional. Those must contain the DEFAULT keyword
So your first question might be “do I use T-SQL or the CLR”? The answer is typically T-SQL is faster for routine set-based computations. However, if you’re dealing with very complex computations the CLR is a better bet.
Let’s write a very simple T-SQL Scalar UDF function:
-- turn off count
SET NOCOUNT ON;
-- check if function already exists and drop if so
IF OBJECT_ID('dbo.myUDF', 'FN') IS NOT NULL
DROP FUNCTION dbo.myUDF;
-- declare function specifying an integer as the input and varchar(20) as output
CREATE FUNCTION dbo.myUDF
(@CustomerID AS INT) RETURNS VARCHAR(20)
DECLARE @myResult AS VARCHAR(20);
-- function query
select @myResult = case @CustomerID
when 1 then 'International Business Machines'
when 2 then 'Microsoft'
when 3 then 'Ebay'
This generates something like the following:
Pretty basic right? So why should you care? Well, Scalar UDFs are easy to write, and easy to maintain. I find them particularly useful for lookups and reporting when you need the same data over and over again.
There are some drawbacks however. (Life couldn’t be that simple could it).
Scalar UDFs when called are run on all the rows of the table and not just on the resultset. This can have a negative impact on performance just like cursors. If you’re dealing with a massive table Scalar UDFs might not be your cup of tea.
So what do you do if you want a neatly packaged function but don’t want the performance impact on a large table?
The answer could be table-valued UDFs as I will show in Part Two [coming soon].
Share and Enjoy