October 2009

Packing my bag for PASS Summit 2009

Flying out on Monday, and I’m so excited.  Here’s the stuff I’m throwing in my bag (as if any of you care).

  1. My Archos 5 IMT – 6+ hours and an extended battery.  Gotta load it up with all of the TV shows I’ve missed over the last few months on my SageTV rig.  Since I can’t find my boosteroo audio amp, I’ll need to go see if I can get a good set of headphones for the plane.
  2. Pad and pens.
  3. My laptop computer, complete with the Nokia softphone software.  I’ll still have to touch base with the office occasionally, and this way I can have portable VOIP.
  4. I’m writing a review for The Art of Unit Testing for the AtlantaMDF Reviews site.  Need to pack the book for the plane.
  5. Airborne Vitamin C.  I know it’s not likely to prevent germs, but boosting my vitamin C intake before I travel is almost a superstitious rite for me.
  6. My #sqlbingo cards and tag.
  7. My PASS Summit itinerary;  I was going to load it into Outlook, but I remember that the last time I did that, everything got screwed up because of the time change. 
  8. My phone, and an extra battery (for all of the twittering I plan on doing).
  9. Business cards.

And I still gotta pack clothing and essentials.  I’m hoping I can do it all with the carryon+laptop limitation, particularly since I have a layover on my way back.

SQLBingo: a few more things to consider…

SQLBingo is still on at Pass Summit 2009; we’re less than a week away, and this should be a lot of fun.  To sum up, a bunch of us SQL Tweeters are going to be wandering around Summit; if you want to play Bingo, you have to match the real person with their avatar on the card, meet the person, and get their codeword.  Should be a lot of fun, but I have a few more things to add.

If you haven’t read the following posts, you may want to start with them first:

SQL PASS Twitter Bingo: The rules so far…

A basic summary of the rules for squares (with some general advice for players).  I’d like to add some things to the “how to play” list, but we’ll get to that in a minute.

#SQLBingo: Meet nice people and learn their safewords.

Brent (as usual) writes a very succinct post on how to play if you’re not a square.  What’s important about Brent’s list is that he lays out some guidelines for things to do BEFORE you go to Summit.

Wanna play?  It takes some prep work…

It should be noted that this is a low-budget game at best; I think one of squares called it “guerrilla networking”, which I think is an awesome term for it.  What it means is that we’re trying to keep the rules and the play very simple, but unfortunately, that also means that the players have to provide some of their own resources for playing.

If you are playing, follow the steps at Brent’s blog:

  1. Print your cards ahead of time from http://sqlserverpedia.com/bingo. (Be sure to refresh in between)
  2. Find the tweeps.
  3. Turn in a card per day when you’ve filled out a row on Tuesday, 2 rows on Wednesday, and blackout on Thursday.

You may also want to set up a Twitter account between now and then.  If you’d like, you can check out sqlbingo’s profile; this is a dummy account set up by Aaron Nelson and myself to follow all of the squares.  The whole point of this account is to simply give you a quick list of all of the Twitter accounts that are on the cards.  You may also want to set up a search for the term #sqlbingo; remember, the squares will be broadcasting their location periodically throughout the day, and using this term will help find them.

Already a square? It takes some prep work…

Same rules for players applies to the squares; however, we’ve decided that squares are not eligible for prizes.  Sorry.  However, if you’d like to make it easy for your adoring fans to find you, you may want to print out a simple badge with your avatar and username on it.  Just a 2×4 scrap of paper, and tape it to your standard Summit badge.  If you forget, c’est la vie!  It’ll just be tougher for people to find you.

Looking forward to meeting all of you face to face!

Stu

Good Habits To Adopt: Enforcing the natural primary key

I’ve been reading Aaron Bertrand’s great series of blog posts on bad habits to kick, and have been thinking to myself: what are some good habits that SQL Server developers should implement?    I spend most of my day griping about bad design from vendors, yet I hardly ever take the time to document what should be done instead.  This post is my first attempt to do so, and it’s based on the following assumptions:

  • Good habits are going to be a lot more controversial than bad habits, and
  • SQL Server doesn’t enforce many of these good habits for you.

The first point refers to the fact that some of the choices that I make are not necessarily the best way to do things, and they may not satisfy the need of every application.  I’m a firm believer that there is an exception to every rule, but my goal is to at least define what the rules are (and again, these rules are my own creation and someone may have better rules).  The second point refers to the fact that SQL Server enforces the rules of SQL, but leaves some of that enforcement open to interpretation.  For example, the relational model defined by SQL assumes that tables are related, but SQL Server doesn’t require that you define a FOREIGN KEY (or even a PRIMARY KEY).

So here’s my first good habit:

When defining a surrogate primary key for a table, you should enforce the natural primary key with the use of a UNIQUE constraint.

To really understand this, you have to start with defining what a surrogate primary key is versus a natural primary key.  You can search for a variety of definitions, but I’ll use the following:

  • Primary Key: a non-nullable attribute (or combination of attributes) that can be used to uniquely identify a specific instance of an entity.  When used within SQL, a primary key can be mapped to a column (or columns) in a table, and the value of the key uniquely identifies a row.
  • Natural Primary Key: a primary key that is not auto-generated by the database or application.  The key is comprised of attributes that are associated with an entity, and the value of those attributes is defined by some authority beyond the scope of the database or application.  For example, a Social Security number is a “arbitrarily” assigned number that belongs to a specific citizen of the United States; most databases that use the Social Security number do not create the number, but rather use it as a reference to a particular US citizen.
  • Surrogate Primary Key: a primary key that is auto-generated by the database or application to specifically identify the row in the table representing the collection of entities.  Surrogate keys have no meaning outside of the database and have no relationship to the other attributes in the table.  An ID of 1 simply identifies a row in a table; a row representing a person, a squid, or an automobile may all have an id of 1, depending on what table the surrogate key the data lives in.

Sidebar: as I was writing this, Pinal Dave post the following to his blog: http://blog.sqlauthority.com/2009/10/22/sql-server-difference-between-candidate-keys-and-primary-key-2/ 

Most novices recognize that every table needs a primary key, and surrogate keys offer some benefits that natural keys do not, including:

  • Immutability: the ability of a key to stay constant over time.  A natural primary key (such as a person’s name) may change, but a surrogate key does not.
  • Simplicity of relational JOINS: surrogate keys can remain as a singular column for each table they represent.  For example, a complete invoice may need to be represented by a ClientID, an InvoiceID, and the LineID’s for the lines on that invoice.  Joining on the natural keys may require the Client Name and Address, the Invoice Number, and the Line Number. 

However, surrogate keys have one major weakness; they do NOT enforce the unique validity of each row.  If you use an IDENTITY function in SQL Server to auto-generate your surrogate PRIMARY KEY, and you insert Stuart Ainsworth into your table of Employees, and you accidentally run your INSERT script again, you’ve just double-inserted Stuart Ainsworth.  While there are certainly multiple people with my name, I’m the only one at my company.  However, my application never noticed it.

Using a UNIQUE CONSTRAINT on the columns holding the natural key information avoids this problem; you get the benefits of a surrogate key AND the unique validation of a natural primary key.   The hard part is, of course, identifying the appropriate natural primary key to enforce.  However, this exercise should NOT be overlooked when designing a database.

SQL PASS Twitter Bingo: The rules so far…

Sorry for the late posting on this, but it’s been a heckuva day 🙂  Anyway, we (Brent Ozar, Blythe Morrow, several others and I) have had several logistical discussion about how Twitter Bingo will be played at PASS Summit 2009, and I thought I would post what we’ve discussed so far.

The goals!

The goal of the game is to increase networking opportunities between the SQL Twitter community and face-to-face PASS Attendees.  Our hope is to a) strengthen existing relationships between SQL tweople, and b) encourage new people to start using Twitter and contribute to the social interactions beyond Summit. 

What is NOT the goal!

To win fabulous prizes.  Quest and SQLServerPedia are putting together some encouragement for new people to play, but the focus isn’t on “winning”; it’s on community interaction.

“Squares” and players…

Squares will be the volunteers who agreed to have their Twitter avatars placed on the cards.   Squares may certainly play the game by printing out cards and pursuing other squares, but at this time, squares are discouraged from entering the prize drawing (Sorry about that; the prizes are fabulous, but not that fabulous).  Again, we want to encourage new people to join the community; if you’re a square, you’re already there (ooh, that was a horrible rhyme.)

How will players mark off squares on their cards?

Each square has a code word; when asked for that code word, they should provide it to the player, who can write it on their card.  I realized that code words will probably be shared among players, but again, the goal is to encourage community interaction even at the risk of minor “cheating”.   We may come up with a more secure scheme next time, but this time, it just seems easier for Quest/SQLServerPedia employees to validate code words.

Arlene Gray (@whimsql) suggested that she write her code word on the back of her business card; I think that’s a great idea.

How will players know where to find me?

Twitter is an option 🙂  If you can, tweet your location throughout the day using the hashtag #sqlbingo.

Brent also suggested that if you’re a speaker, you may want to ask squares in the room to stand up before you begin your session, so players can identify them.  We’re also planning on asking squares to print out a small badge to tape to their regular conference badge showing their avatar and username.

Where do players get their cards?

We’re going to ask players to print out their own cards and bring them with them; we’ll also have some cards available at the Quest/SQLServerPedia booth.  Blythe Morrow also suggested that we use the PASS help desk booth as well.

How do players play?

We’re planning on adding this to the card:

Here’s how the contest works: print out 3 Bingo cards.  Try to meet as many people as possible that are on your card each day.  Each person has their own code word, and you have to write down their code word in their space on the Bingo card.  When you get a straight line (5 people in any direction) on Tuesday, you can drop off your card in the SQLServerPedia booth in the exhibit hall.  Each day, we’ll draw 2 winners and email them with their prize package – things like signed books, gift cards, and more.  On Wednesday, it gets tougher – you have to have two straight lines filled out.  On Thursday, you have to have a blackout – all spaces covered!  Only one entry per person per day.

Who’s a square?

Below is the list of squares:

Square SquareUserName
Andy Leonard AndyLeonard
Aaron Bertrand AaronBertrand
Aaron Nelson SQLvariant
Adam Machanic AdamMachanic
Allen Kinsel sqlinsaneo
Andy Warren sqlAndy
Arlene Gray whimsql
Bill Fellows billinkc
Bill Graziano billgraziano
Blythe Morrow blythemorrow
Brent Ozar brento
Brian Kelley kbriankelley
Colin Stasiuk BenchmarkIT
Denny Cherry mrdenny
Eric Humphrey lotsahelp
Geoff Hiten SQLCraftsman
Grant Fritchey GFritchey
Jeff Rush JeffRush
Jeremiah Peschka peschkaj
Joe Webb JoeWebb
Ken Simmons kensimmons
Kendal Van Dyke SQLDBA
Lee Anne Pedersen leeannepedersen
Lori Edwards loriedwards
Mike Walsh Mike_Walsh
Mike Wells SarasotaSQL
Pat Wright SQLAsylum
Peter Schott paschott
Peter Shire Peter_Shire
Ross Mistry RossMistry
Rushabh Mehta rushabhmehta
Steve Jones way0utwest
Stuart Ainsworth stuarta
Tim Benninghoff bugboi
Tim Ford sqlagentman
Tim Mitchell Tim_Mitchell
TJay Belt tjaybelt
Todd McDermid Todd_McDermid
Tom LaRock SQLRockstar
Trevor Barkhouse SQLServerSleuth
Wendy Pastrick wendy_dance
Wesley Brown WesBrownSQL
William McKnight williammcknight

 

That’s all for now; I’m sure more will come up as I think about it 🙂

All aTwitter about PASS Nominations

Lots of interesting conversations about the PASS nominations happening on Twitter today; if you are not up to speed, you’ve got a lot of reading to do.  I’ll try to sum up as best I can:

  • Some people applied to be nominated for board positions; a nominating committed approved 4 applications for 3 open positions.
  • 3 of the 4 positions are well-established members of the SQL community; one is a bit more controversial.
  • All 4 candidates have been invited to express their opinions on various forums, and all have been “interviewed” by Brent Ozar on his blog.  Links are below.

If you haven’t read these interviews, you need to.  For the most part, they’re pretty insightful, and they suggest what direction each of the candidates is moving in when it comes to PASS.  Matt’s candidacy raises some interesting questions about the nomination process, and the role of the Board in determining the direction of PASS.  It also raises some definitional questions about what PASS is, and what it should be.  I applaud him for his comments on Brent’s blog, because it takes a lot of guts to stand up under fire (even though I disagree with some of his positions). 

EDIT: I should have also stated that I applaud ALL of the candidates for their willingness to engage the members of PASS, including the first step of applying for the job. 

Before I go too much further, let me say that this post is intended to be an indictment of myself; I did not apply to be on the Board, nor did I even express much interest in the nomination process before today. I also didn’t even blink before I voted; I picked the three candidates that I felt comfortable with, and was going about my business until the conversations began on Twitter today.  I will not be so lax in the future.

What bothers me most about Matt’s candidacy is not his position, nor his background, nor the responses he gave to the questions asked of him; it’s the fact that he’s the only candidate that the community seems to have engaged in this fashion.  Granted, many of the questions asked were for him to clarify how his professional expertise would make him a good fit for the Board, and those are legitimate questions.  There were also other questions that were asked to help clarify his vision of direction for PASS which would have been suitable for the other candidates as well.  All of that’s fair game, but why didn’t we challenge the other candidates as well?

When I asked the question on Twitter, the general response I got was that “we know the other candidates; we don’t know Matt”.  That may be true, but even though we know someone, that should give us the opportunity to engage them on a deeper level than the “dark horse” candidate.  Instead, we as a community let 3 out of 4 candidates express themselves with little or no interaction from us, and instead focused on 1 controversial candidate.  I am not suggesting that Matt should not have been questioned; I am suggesting that we should have taken more advantage of the opportunity to get to know the other candidates better.

EDIT: As pointed out in the comments below, Matt was not the only candidate to engage with questioners; I didn’t mean to overlook the efforts of the candidates to make themselves approachable, but I did want to point out that many of us didn’t take them up on that offer.

Again, I’m pointing the finger at myself as much as anyone else.  I should have applied for the position; at the very least, I should have asked more questions before casting my vote.

Maker’s Schedule, Manager’s Schedule, User’s Schedule

During the recent SQLSaturday #25 in Gainesville GA, we had an open session at the end of the day which we treated like a “Meet the Experts”.  During the discussion, Cliff Jacobson referred to an article detailing the difference between the Maker’s Schedule and the Manager’s Schedule. 

Here’s the link for your reference: http://www.paulgraham.com/makersschedule.html

It’s a quick read, but I’ll sum it up for you

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour… But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started…

I would argue that (at least in our shop) there’s a third schedule: the User’s Schedule.  Some managers ARE users, so their time alternates between the Manager’s Schedule and the User’s Schedule, but for the sake of this discussion, we’ll keep this separate.

What is the User’s Schedule?  Basically, users only know of one time: Now().  Now is when they have to get their work done, and Now() is when the software breaks.  When their work gets interrupted, they have to resolve the problem before they can move on.

Why is this important?  Because when Users need a resolution, they don’t want to hear it’ll take a week to implement; they want it fixed Now().  When they request a feature, they want to know it’s being worked on Now().   Obviously, this is unrealistic for Makers; good code takes time to write, time to test, and time to document.  When a Maker skips one of those steps, it’s usually because they’re attempting to work on the User’s Schedule.

Now() is not necessarily a bad time; Users are not attempting to screw the Maker out of task completion.  The User really believes that Now() is when the Maker wants to know about the issue, so that the Maker can fix the problem before it gets too severe.  Notifying the Maker about the issue as soon as it happens is the User’s method of helping.

So how do we reconcile these three schedules?  Programmers need to meet with managers (they determine priority) and users (they determine requirements); in fact, the Agile Manifesto states that

Business people and developers must work together daily throughout the project.

How do you keep the conversation focused on the scheduled deliverable and not the bug of the moment?  You have to keep moving forward, but you also have to be willing to acknowledge the Manager’s need for status reports and the User’s need to report issues and request features.  I am no expert in this, but these are the principles I am starting to implement in my own schedule.

  1. I’m working with Management to find appropriate times to schedule status reports.  I’m trying to fit them in either right before lunch (either the meeting ends on time, or I may get a free meal out of it), or in the last hour before the end of the day (sometimes meetings go long, which is unfortunate).    This takes care of the Management/Maker disconnect.
  2. To avoid addressing issues Now(), I have started closing my email, forwarding my phone, and setting my IM status to Do Not Disturb (note: for a feature in Office Communicator, I wish I had a way to set different statuses for different contacts; DND doesn’t raise an alert, but I wish I could let my boss through) for 45 minutes out of every hour.  The last 15 minutes, I stop coding, and check email, etc.  This keeps my finger on rising issues, but is less interruptive than  constant contact.  Of course, I work remotely most days, so I don’t have to deal with Spring-Loaded-Butt Syndrome (and I’m not talking about hinges).
  3. When I do contact users to deal with the bug-of-the-moment, I try to reassure them that the a) bug is being recorded, and b) will be prioritized.  We use Team Foundation Server, which is OK for a bug tracking system.  The biggest problem that I see in my current environment is that Users don’t often follow up with Managers to make sure that the issues are prioritized.
  4. When discussing features for rollout, and the User attempts to bring up the bug-of-the-moment, I ask them to hold off on that discussion until the end of our stated objectives, and I encourage them to write it out.  By writing out the issue, they begin specifying the core elements of a bug report/requirements document. 

Is this perfect? No, but it’s a start.  I’d be interested in hearing what your ideas are on the subject, and what steps you have taken to coordinate Maker’s time, Manager’s time, and User’s time.

PASS Summit 2009 – Twitter Bingo Players

Last call!  If you’re planning on being at PASS Summit 2009, and you have an active Twitter account, and you’d like to be sought after by millions of screaming fans (OK, that last part’s an exaggeration, but there will be people looking for you), please let me know by Friday, 10/16/2009.  So far, the following tweeple have signed up to be squares on the card (please check your handle for accuracy; I’m a lousy typist):

@stuarta
@BrentO
@WesBrownSQL
@RossMistry
@lotsahelp
@mrdenny
@AndyLeonard
@peschkaj
@sqlinsaneo
@Bugboi
@billinkc
@williammcknight
@leeannepedersen
@paschott
@SarasotaSQL
@SQLDBA
@AdamMachanic
@SQLvariant
@whimsql
@kbriankelley
@SQLRockstar
@kensimmons
@way0utwest
@BenchmarkIT
@sqlagentman
@tjaybelt
@GFritchey

UPDATE (I either missed these, or they saw this post and wanted to play):

@SQLAsylum
@SQLServerSleuth
@loriedwards
@SQLCraftsman
@Todd_McDermid
@wendy_dance
@Peter_Shire
@blythemorrow  (who should definitely be the center square!)
@sqlAndy (who MAY actually post something<G>)
@rushabhmehta
@JoeWebb
@billgraziano

UPDATE II (last call<G>):

@AaronBertrand

 

Although we have more than enough players to fill up a card, we could use a few more so that we’d have a truly random configuration.  We’re still working on some of the logistical details, like how you’ll be recognized as a payer when you don’t look like your avatar, but this is coming together.

UPDATE (AGAIN): Rough draft of card is up: http://sqlserverpedia.com/bingo/

YAY! Somebody likes me…

I just got the email today; Red Gate friended me.  Or, rather, I am now a Friend of Red Gate.  What does this mean?  I try to think of it kind of like a NASCAR patch; I now have a perpetual sponsor for all of my various presentations in the SQL community.   I don’t know what else to say other than “THANK YOU!”

Seriously, I love Red Gate’s products, and have been a big fan of theirs for a long time.  Their SQL Compare product just works, and it works well (unlike the sometimes-challenging implementation in Visual Studio’s Database Developer).   I bought SQL Prompt with my own money because I saw it as a major time saver.

I’m very jazzed about this.

SQL Saturday 25; reflections

Another SQLSaturday down!  This was my second one to organize in a year, and it was much different than the first event we held in April.  I learned a lot this time about managing the event, so it’s time for another wrap-up post 🙂  (YAY! You know you’re excited!).

Before I go to far, I need to express a huge THANK YOU to the faculty and students at Gainesville State College and the Institute for Environmental and Spatial Analysis, particularly Allison Ainsworth (and yes, we’re related).  I’ll explain more about their role in a bit, but they really made the event flow flawlessly and their presence helped make this event a huge success in a number of ways.  I’d also like to thank my daughter Isabel, who (like a typical twelve-year-old) alternated between being bored and excited about being there.  She was constantly in motion throughout the event, and she made me very proud.

I also want to thank our sponsors: Interworks and RedGate, as well as our hosting user group AtlantaMDF.  Without their involvement, there would be no SQL Saturday, and I hope that we can continue this tradition in our area for a long, long time.

Basic stats

  • 103 registered; 75 attendees
  • 12 faculty and student workers
  • 3 tracks; 14 speakers

What worked well…

  • Faculty & Student Volunteers rocked.  Having someone running the show who did not have a vested interested in seeing the speakers was a great asset; if you can partner with a local school and work out a deal to have student workers, DO IT!.  The team at GSC worked very hard, and while they managed to sneak in a few sessions, they didn’t expect to see all of them.  This was very different from the Alpharetta event earlier in the year where I felt guilty because several volunteers were unable to attend sessions.
  • Attendee Volunteers were awesome.  I had several attendees who were very willing to proctor the sessions they were in (thus relieving the student workers of that responsibility).  They handled speaker time, took care of announcements, and made sure that the sessions flowed smoothly from one to the next.
  • Lunch!  Lunch was a bit of an accident, really; we had made arrangements with Sonny’s Bar-B-Q to provide the meal, but had neglected to follow up until right before the event.  We were expecting box lunches, but because of the timing, they provided us with a buffet.  This happy accident was actually OK, as our costs were lower, and the amount of food provided was enough to ensure that everyone was well-fed.  In general, everybody ate well (breakfast, lunch, and a snack).
  • Speakers!  Just thumbing through the evaluation forms, I saw a lot of positive comments.  I also heard a lot from the attendees about how well the speakers did in general.  We had several first-time speakers at this event, and I think they handled themselves very well.
  • Facility.  I had several attendees compliment me on the choice of the facility; even though GSC is a bit of a drive from downtown Atlanta, several people seemed to indicate that the spaciousness of the floor plan was worth the drive.

What needs improvement…

  • Sponsor recruitment.  We only had a couple of sponsors, and I wished I had managed to contact more.  Part of the difficulty was in approaching sponsors so soon after the Alpharetta event.  However, I did have a few attendees remark that they missed having the opportunity to meet with the sponsors.
  • Prizes-for-evals.  In each session, we had attendees complete an evaluation form for a ticket; this way the form could be confidential, and they would have a chance to win a prize at the end of the day.  According to Allison, this was tough to manage (making sure that tickets and forms were collected at the end of each session).   I also think it biased the evals; since people HAD to complete one to get a ticket, many of them simply circled all #1’s or #4’s.
  • Session oppositions.  I had a couple of situations where I wished I could have touted the GIS sessions more than I did; at the end of the day, for example, most of the SQL Server folks went to the open spaces sessions rather than the GIS session describing the program at GSC.  People have free choice, but I wish I could have found a way to encourage them to learn more about the hosting organization.
  • Student presenters.  We had originally intended that there be a SQL Saturday #24 on Friday, featuring Student presenters.  It didn’t happen, so we need to figure out a way to open doors to students at GSC (and other schools).  We did have two presenters on Saturday, but I wish we had more.

What I would change next time…

  • Speaker polos; student worker T-shirts.  We had speaker –t-shirts made up for the event, and we also shared them with most student volunteers.  I had a couple of speakers remark that they missed the polos (but they understood it was a budgeting issue).   It was nice, however, to see a sea of green t-shirts manning the registration desk, and helping attendees find their way.
  • More vegetarian options.   No one went hungry; however, we had ordered vegetarian meals from a local Chinese restaurant for the attendees who had registered as vegetarians.  We had a few people who thought they had registered as a vegetarian, but it didn’t list that way on the extract from the site (my guess is they never actually clicked the button).  IF we do a buffet next year, we may do it as a Chinese buffet with additional vegetables.
  • Bill the event as a North Atlanta or Lake Lanier event.  The space is great, and we’d love to make it a bigger event next year; however, we have to convince the Atlanta development community that it’s worth the drive, AND we have to figure out a way to get more sponsors involved.   IF we could get a well-known keynote (or special topic) speaker to appear, that could boost our attendance rate, and boost the sponsorship.
  • Give away prizes during the last few minutes of a session.  Let’s do away with the prize-for-eval; still hand out eval forms, and tickets, but let the proctor in each session do the prize pull at the end of the session REGARDLESS of whether or not they have a completed form.  Hang on to all of the tickets for extra prizes at the end of the day.

Additional writeups:

A couple of blogs have already made it around the net; here’s a couple of different perspectives on the day.

http://dyfhid.blogspot.com/2009/10/sql-saturday-25-and-epiphany.html

http://ammonsonline.com/jeffablog/post/SQL-Saturday-25-Fun.aspx

http://arcanecode.com/2009/10/10/sql-saturday-25-gainesville-ga-october-10-2009/

Wrapping up for SQLSaturday 25

Whew.  Just finished my presentation for SQLSaturday #25 (The Social DBA), and am now going through my short list of stuff left to do.  This has been an interesting experience because of the help from the college; having volunteers take care of things like food and beverages has been both helpful (and a little stressful; I don’t hand off tasks well).

Anyway, here’s my short list, in case you want to know what’s involved with a SQL Saturday:

  1. Pick up inserts for Name Badges and a roll of double-sided tickets
  2. Take the table from upstairs to GSC
  3. Design & Print badges for Speakers and volunteers
  4. Design & Print tickets for big prize drawings
  5. Print final registration list (with no-pays marked).
  6. Print Veggie Lunch list
  7. Print out Inserts for books 
  8. Print out evaluation forms.

BTW, we’re up to 105 registrants, as of today, even after having speakers and attendees drop out throughout the day.   24 hours to go. Woo-hoo!