36 Chambers – The Legendary Journeys: Execution to the max!

April 27, 2014

Upcoming Events

Filed under: Database Administration, Programming & Work, Wacky Theories — Kevin Feasel @ 6:00 pm

First, a plug.  The folks at Red Gate have re-published my Tribal SQL chapter as a standalone article.  If you like it, go out and get a copy of the book, as there are a number of excellent authors there.

  • On May 16-18, I will be attending CarolinaCon.  It’s hard to beat $20 for a weekend of security talks.
  • On May 21st, I am going to present to the TriNUG Data SIG on In-Memory OLTP in SQL Server 2014 (AKA, Hekaton).
  • On June 14th, I am going to attend SQL Saturday #299 in Columbus.  I’m not sure yet if I’ll have the opportunity to present there, however.

Over the next few weeks, I plan to start putting up some more technical posts as I look into Hekaton and a couple of other topics.  The big one that I have is an analogy:  F# is to development DBAs what Powershell is to production DBAs.  I want to introduce F# as a set-based functional language which plays very nicely with a SQL Server infrastructure and provides a shallower learning curve than C#.

Also, now that the weather is warming up, it’s time to start hitting the trails and visiting parks.  This means I should be able to start taking more photographs again.

February 8, 2014

Powershell Saturday

Filed under: Programming & Work — Kevin Feasel @ 8:00 am

I am at Powershell Saturday 007 in Charlotte today.  With luck, it will turn out to be as good as a quality SQL Saturday event.

September 11, 2013

The UpDesk: A Review

Filed under: Programming & Work — Kevin Feasel @ 9:39 pm

A couple of months ago, I bought an UpDesk for my home office.  Here’s a quick product review.

The particular model that I bought is 6′ long, and I use it for two separate computers.  One computer is my primary home computers, with 4 monitors in a grid.  The other is my primary work computer, with two monitors and a laptop.  The desk is wide enough for all of my monitors, so that’s a huge plus.

The biggest advantage to using an UpDesk is that you can easily move between different heights.  It’s a good idea not to stand all the time, just like it’s a good idea not to sit all the time; the best plan is moderation.  This is the best part about the UpDesk for me:  I have programmed two different heights, one which is just right for when I’m sitting and another for when I’m standing.  When I want to sit down, I push the right button (to tell the new height) and then hold the up or down arrow to adjust the desk itself.  Switching from ~28″ up to 42.8″ takes approximately 10-15 seconds, so it’s not instantaneous, but when you switch three or four times a day, it’s not really that big a burden.

There are a couple of disadvantages to using an UpDesk.  The biggest one for most people is probably the lack of storage:  unlike a standard sit-down desk, you don’t get any filing cabinet space.  In my case, I actually prefer this because it allows me to move between computers, sitting or standing at either my home or my work setup without bumping into anything or contorting my legs while sitting.  To compensate for this, I have filing cabinets and side desks around my UpDesk.  The other disadvantage is the price:  you can find a similar-style, non-hydraulic desk for about 10-15% of the cost ($100-150 instead of $1000), but then you don’t get the ability to move the desk up and down.

I’m very happy with this purchase and would definitely do it again.  It looks like UpDesk has come out with a new model which is even better than the one I purchased.  If you do end up purchasing an UpDesk, definitely get a good anti-fatigue floor mat.  I’ve noticed a huge difference when I use it while I’m standing versus standing barefoot on carpet.

July 10, 2013

Getting Out Of The Office

Filed under: Programming & Work — Kevin Feasel @ 6:00 pm

Working from home has huge benefits:  for example, I get to work barefoot, my office equipment doesn’t suck, and I don’t have a bevy of strange noises and smells to distract me.  On the other hand, it’s easy to become a shut-in, never leaving the house.  And when you’re working from home for an out-of-state company, you have to try harder in order to meet people.

As a result, I’m joining a few user groups.  I was active in the Columbus SQL PASS Chapter, so TriPASS is a logical destination.  I’m also joining the Triangle Area .NET User Group.  I haven’t joined any other groups yet, but I’m looking at a few outdoor activities groups, because there’s another thing that you start to miss out on as you realize air conditioning doesn’t exist outdoors…

March 28, 2013

Do You Need That Trigger?

Filed under: Database Administration, Programming & Work — Kevin Feasel @ 6:00 pm

Merrill Aldrich has a wonderful flow chart pertaining to database triggers.  The short answer is “No.”

At one place I have worked, the primary production database had over 200 triggers, mostly to handle auditing and logging.  Why couldn’t they do something like Service Broker or change tracking or some asynchronous mechanism to keep things up to date without triggers everywhere?  Good question…

March 18, 2013


Filed under: Programming & Work — Kevin Feasel @ 6:00 pm

This is a little old, but no more telecommuting at Yahoo.  Suzanne Lucas was not happy with this idea, nor is Tim Ford (who knows a thing or two about telecommuting).  She also has an interesting post on whether telecommuting hurts your career.

Telecommuting has grown on me over the past few years.  Even if it’s just occasionally—once or twice a week—it’s a great non-monetary benefit for employees you trust to get the job done.  And given that we have easy videoconferencing solutions available, there’s little reason for people in IT to have to come into the office each day unless they want to get out of the house.

February 15, 2013

Formal Formatting Standards Are Overrated

Filed under: Database Administration, Programming & Work — Kevin Feasel @ 6:00 pm

Grant Fritchey has a blog post about naming standards, including an excerable tblDdltbl.  The comments thread then becomes people defending their particular naming and formatting standards.

Let me explain my standard:  I try to be consistent, except when I’m not.  Anything more than that runs the risk of hitting rationalist stupidity, like tblDdltbl.

So what does this mean?  Well, I have a particular naming format for tables:  give the table a clear, unambiguous name that describes the entity this table implements.  Anything more than that is unnecessary cruft, and if I ever have to look at a chart to translate a table name, I know I’ve failed.  We get 128 characters for our names, so even very long names work, and auto-complete saves your precious fingertips so you can spend more time chatting on Facebook.

Okay, so what about stored procedures?  Well, name them in a way that makes sense.  I like Grant’s [Object][Action] combination, but be consistent…except when it makes sense not to be consistent.  Sometimes, [Object][Action][Predicate] is necessary, but that doesn’t mean you have to re-name all of those [Object][Action] procedures.  And if you want to use [Action][Object] instead, that’s fine:  just be consistent.

With database objects out of the way, what about formatting?  I could write an MLA-length document on precise formatting of SQL code, but what’s the benefit?  Is there any point in indenting here versus there, commas here versus there, or splitting out into lines here versus there?  Maybe.  But here’s the problem:  we don’t really have any solid metrics on this, so all of this comes down to stylistic preferences.  You may see your preferred formatting pattern as the pattrern, but that’s little more than an opinion based on the relatively small sample of formatting styles to which you have been exposed.  Furthermore, even if you write up a long style guide, chances are you’ll either hit the shoals of stupidity (tblDdltbl) or have gaping holes that you never thought about, thereby requiring actual independent thought and the risk of non-consistent code styles.

Let’s give an example of that now.  There are certain things which I believe make SQL code easier to read:  columns on separate lines, primary clauses (e.g., SELECT, FROM) outdented and the only thing on the line, subqueries following consistent indentation patterns, etc.  When I write a procedure or view, I tend to do that, except when I don’t:  for example, trivial NOT EXISTS subqueries might end up on one line rather than broken out.  But what constitutes a trivial NOT EXISTS clause?  Just a SELECT and FROM?  SELECT and FROM with one element in the WHERE clause?  Maybe an INNER JOIN somewhere?  Would splitting this out into several lines make that particular procedure significantly more difficult to read?  And if not, why should I put much mental effort into following The One True System?

I get the notion of trying to have a single coding style which everybody can follow to try to make it easier to read other developers’ code, but we live in the world of auto-formatting.  If you don’t like the format, it’s trivial to reformat code to your preference.  Or, better yet, get over it:  the interpreter doesn’t really care how you format your code, so if it makes sense to you, go for it.  Just don’t pretend that what makes sense to you is scientifically superior (unless you have the studies to back this up) or even makes sense to everybody else.

February 9, 2013

Windows 8 Office Hours

Filed under: Computinating, Programming & Work — Kevin Feasel @ 6:00 pm

Jeff Blankenburg is introducing office hours for assistance with your Windows 8-based apps.  That’s a great use of a Microsoft evangelist’s time, and if you’re developing on that platform and in the Columbus area, hit him up.

December 30, 2012

OAuth Providers

Filed under: (In)Security, Programming & Work — Kevin Feasel @ 6:00 pm

Ben Foster has a nice roundup of how to set up OAuth with some of the biggest providers (Google, Facebook, Twitter, LinkedIn, and Microsoft).

December 2, 2012

Sentence Of The Week

Filed under: Our Favorites, Programming & Work — Kevin Feasel @ 7:00 pm

I am reading a paper on HIPAA compliance in the cloud (hat tip to Jeremiah Peschka).  On the first page is this wonderful sentence:  “If you are considering storing protected health information (“PHI”) with a cloud provider, they should be knowledgeable about HIPAA (ideally, they should even spell the term correctly). “

I know far too many people in the health care industry who cannot spell HIPPA…err, I mean HIPAA…

Older Posts »

The Silver is the New Black Theme. Create a free website or blog at WordPress.com.


Get every new post delivered to your Inbox.

Join 94 other followers