Tag: syndicated

  • Annual Email Pruning

    Like most of us, I get a lot of email. I get subscribed to various services from different ads, events, etc. throughout the year. That’s fine. I understand how marketing works, and the reason that I get some free services, or some lower cost events is because of the marketing that comes through email newsletters or other information. The reason SQLServerCentral was able to grow and survive was because of marketing, and our email newsletter, which I’m thankful so many of you subscribe to on a daily basis.

    I like to think that the SQLServerCentral newsletters are interesting and worth your time to glance at. I don’t expect most of you to read them every day, but I do think that it must be interesting more often than not for your to keep subscribing. I know the Database Weekly ones are, and I hear from more than a few of you if we ever end up forgetting to send one out.

    Over the last few weeks, I’ve undertaken an annual tradition of weeding out some of the email advertisements I get. As new mail arrives in my inbox. I make a quick evaluation of whether or not I’ve been reading the other mail from this particular sender and if it’s valuable. If not, I’m unsubscribing.

    I do this periodically on Twitter as well, cleaning out my timeline if I find someone posting in there things that aren’t interesting enough for me to continue following them.

    Time is one of my most valuable resources. I’m willing to give vendors and people a chance to prove that they add something to my workday, but if they don’t, then I let them go.

    BTW: If there are things you’d like to see improved at SQLServerCentral or Database Weekly, let our webmaster know or post a note in the forums.

  • The First Event of 2013 – SQL Saturday #183 – Albuquerque

    I’ll be delivering the Modern Resume presentation at SQL Saturday #183 in Albuquerque, NM on February 9, 2013. I got my acceptance today and replied that I’ll be there.

    This is the first SQL Saturday in New Mexico, which is a little exciting. I’ve been there a few times since my brother used to live there and thought it was a neat city. I’m looking forward to going back and wandering around for an afternoon before the event.

    If you’re anywhere nearby, register and come to the event. It should be a lot of fun.

  • You Need to Manage Passwords

    I saw a note this week from CNet about a system built to crack passwords (also on ArsTechnica). It reminded me of the story of the guy that cracked Googles DKIM key at 512bits. Not insignificant, until you get to the point of renting that power from AWS for tens of dollars.

    Here’s a great comic on the subject of passwords: Password Strength. It’s got some good advice, but there’s more to it than just having a good strong password. You need to manage your passwords, as in you need to have lots of them.

    Doubt that? Here’s a good piece from Troy Hunt.

    You need a password manager. Whether you use 1Password, KeePass, or PasswordSafe (my choice), choose one and set the defaults to something long. I’ve been using 12characers, but I’ve moved to 16 for my passwords. All of these work cross platform, and you can sync your files between devices.

    One more thing: you need to rotate passwords. Not just on your password manager, but on your various sites. If someone gets a copy of your password manager file, then it’s just a matter of time before they can crack it. Within months, they could have all the passwords in your file if they were determined.

    Lots of passwords I’m not overly worried about, but some I am. Banks, mail, a few of my profiles, these are important to me, and so I rotate the password periodically on them, using new passwords from my manager.

    Security is hard, and passwords aren’t going away anytime soon. Tell your friends, family, and make sure they all consider using some type of password manager and improving their security.

  • T-SQL Tuesday #37 – A Month of Joins

    tsqltuesdayIt’s time once again for T-SQL Tuesday, and this month is hosted by SQLity.net, Sebastian Meine.

    If you want to know more or participate, read the invitation and write your own blog post.

    The topic this month is joins, in honor of Sebastian’s a-join-a-day series. He’s writing about various aspects of joins, and invites us all to do the same thing on this Tuesday.

    Writing Better Joins

    I’m not a T-SQL expert. I can write code, and understand many type of queries, but I’m not one to dazzle others with their code, like Jeff Moden can. Instead, I want to talk about how I’ve learned to ensure that my code makes sense, is understandable, and most importantly, easy to find the mistakes inside.

    I mainly do this by paying attention to the formatting of the code. I would say that once I started to get away from writing code like this, I found bugs easier, and understood the code better:

    WITH [EMP_cte]([BusinessEntityID], [OrganizationNode], [FirstName], [LastName], [RecursionLevel]) -- CTE name and columns
    AS (
    SELECT e.[BusinessEntityID], e.[OrganizationNode], p.[FirstName], p.[LastName], 0 -- Get the initial list of Employees for Manager n
    FROM [HumanResources].[Employee] e INNER JOIN [Person].[Person] p ON p.[BusinessEntityID] = e.[BusinessEntityID]
    WHERE e.[BusinessEntityID] = @BusinessEntityID
    UNION ALL SELECT e.[BusinessEntityID], e.[OrganizationNode], p.[FirstName], p.[LastName], [RecursionLevel] + 1 -- Join recursive member to anchor
    FROM [HumanResources].[Employee] e INNER JOIN [EMP_cte] ON e.[OrganizationNode].GetAncestor(1) = [EMP_cte].[OrganizationNode]
    INNER JOIN [Person].[Person] p ON p.[BusinessEntityID] = e.[BusinessEntityID]
    )
    SELECT [EMP_cte].[RecursionLevel], [EMP_cte].[OrganizationNode].ToString() as [OrganizationNode], p.[FirstName] AS 'ManagerFirstName', p.[LastName] AS 'ManagerLastName',
    [EMP_cte].[BusinessEntityID], [EMP_cte].[FirstName], [EMP_cte].[LastName] -- Outer select from the CTE
    FROM [EMP_cte] INNER JOIN [HumanResources].[Employee] e ON [EMP_cte].[OrganizationNode].GetAncestor(1) = e.[OrganizationNode]
    INNER JOIN [Person].[Person] p ON p.[BusinessEntityID] = e.[BusinessEntityID]
    ORDER BY [RecursionLevel], [EMP_cte].[OrganizationNode].ToString()
    OPTION (MAXRECURSION 25) 

    I often find code in forums, or sent to me and I need to reformat it so that it looks better. I prefer something like this:

    WITH    [EMP_cte] ( [BusinessEntityID], [OrganizationNode], [FirstName], [LastName], [RecursionLevel] )
              -- CTE name and columns
              AS (
                   SELECT
                    e.[BusinessEntityID]
                   ,e.[OrganizationNode]
                   ,p.[FirstName]
                   ,p.[LastName]
                   ,0 -- Get the initial list of Employees for Manager n
                   FROM
                    [HumanResources].[Employee] e
                    INNER JOIN [Person].[Person] p
                        ON p.[BusinessEntityID] = e.[BusinessEntityID]
                   WHERE
                    e.[BusinessEntityID] = @BusinessEntityID
                   UNION ALL
                   SELECT
                    e.[BusinessEntityID]
                   ,e.[OrganizationNode]
                   ,p.[FirstName]
                   ,p.[LastName]
                   ,[RecursionLevel] + 1 -- Join recursive member to anchor
                   FROM
                    [HumanResources].[Employee] e
                    INNER JOIN [EMP_cte]
                        ON e.[OrganizationNode].GetAncestor(1) = [EMP_cte].[OrganizationNode]
                    INNER JOIN [Person].[Person] p
                        ON p.[BusinessEntityID] = e.[BusinessEntityID]
                 )
        SELECT
            [EMP_cte].[RecursionLevel]
        ,   [EMP_cte].[OrganizationNode].ToString() AS [OrganizationNode]
        ,   p.[FirstName] AS 'ManagerFirstName'
        ,   p.[LastName] AS 'ManagerLastName'
        ,   [EMP_cte].[BusinessEntityID]
        ,   [EMP_cte].[FirstName]
        ,   [EMP_cte].[LastName] -- Outer select from the CTE
        FROM
            [EMP_cte]
            INNER JOIN [HumanResources].[Employee] e
                ON [EMP_cte].[OrganizationNode].GetAncestor(1) = e.[OrganizationNode]
            INNER JOIN [Person].[Person] p
                ON p.[BusinessEntityID] = e.[BusinessEntityID]
        ORDER BY
            [RecursionLevel]
        ,   [EMP_cte].[OrganizationNode].ToString()
    OPTION
            ( MAXRECURSION 25 ) 

    That actually came from reformatting the code using SQL Prompt, a product from my employer, Red Gate Software. I’m lucky in that SQL Prompt formats things as I’d prefer them, indenting and getting the JOIN and ON clauses onto separate lines.

    Having code with structure, where you can clearly see the tables being joined, the clauses in use, and not miss any of the columns being selected at a glance is important. When you’re under stress and trying to debug or develop something, it’s easy to miss something that’s happening in the code if it’s not formatted correctly.

    Whether you like commas before or after columns, or you want things indented so that the names of objects line up doesn’t really matter. What’s important is that you and your team agree on a set of formatting, or have tools that reformat things for each developer in a consistent way. You’ll spend less time trying to understand the code and more time building or fixing it, if it has a consistent layout.