Category: Uncategorized

  • Plagiarism Again

    Update: The problem posts have been removed from the SQLTechConsulting site.

    I ran across a note from Brent Ozar (blog | Twitter) on Plagiarism, Inspiration, and John Dunleavy yesterday, having missed what looks like an interesting Twitter discussion since I’m halfway around the world from where I usually am. However in reading this post, and the Twitter notes, I am actually shocked at someone defending an undefendable position.
    It’s like having a child put their fingers in their ears, while closing their eyes and singing “la-la-la-la” in response to a parent.
    John, dude, you’re wrong. You’re not syndicating, you’re not “helping others to learn”, you’re plagiarizing content from other sites. From other writers, and passing it along as your own content. Providing a link is not enough to give credit to someone else.
    You can read Brent’s post to get some of the story, and I have had emails in the past with John, requesting that my content be removed from his site. Just so that it’s clear how I feel, a few examplse below of what I think is wrong.
    Here’s a post from SQL Tech Consulting:
    sqltech1
    This post is “by John” (emphasis mine) and links to a note at MSSQLTips. That’s fine, and that’s a good example of writing your own  content and linking to others, though I think there ought to be some mention here of MSSQLTips.
    Here’s another one:
    sqltech2
    This is also “by John”, but the content isn’t by John. This is actually content taken directly from the MS link for the download page. This is re-publication and reproduction of content, implying that it’s by John at SQL Tech Consulting.
    It’s not.
    This by someone at Microsoft, and this is a copyright violation. All the text of this post is not John’s work.
    I link to articles from SQLServerCentral on other sites. I credit those sites, as shown below, only reproducing a small abstract with credit.
    ssc_copy_1
    SQL-Server-Performance links to my content in their newsletter, and next to every title it clearly says “SQLServerCentral”, so you are aware of who the publisher is. There is no mistake. What’s more, sql-server-performance doesn’t co-mingle my content with theirs, as shown below. Unlike SSWUG, who some people believe is mis-leading readers, they only show their published articles.
    ssp-1
    SQL Tech Consulting is violating copyright in re-producing content, and the lack of a citation is  plagiarism. It’s ethically wrong, and there is no defense. Not giving credit to the authors, or the publishers, is in-defensible. There’s no excuse. It’s not syndication, and as noted by many people, it’s not with permission. Even if it is, you must give credit, and note, “reprinted with permission.”
    I’m not sure if SQL Tech Consulting doesn’t understand these concepts and wants to imply to current and potential customers that they have more knowledge than they have or if they just want to attract more business and think this will raise their search engine rating.
    In either case, this type of behavior means it isn’t a company I’d hire.

  • Be Responsible in your blogging and posting

    I have been awarded the MVP award from Microsoft a few years in a row and it’s an honor, but it’s also a responsibility. One of the benefits from the award is that I get information about what is coming up in products, often under an NDA (non-disclosure agreement). That means that I can’t release this information publically, and every quarter it seems that one or more MVPs lose their award for disclosing information they shouldn’t.

    The same thing ought to apply to the posts you make, blogs you write, etc., when it might apply to your company. I wrote an editorial at SQLServerCentral on this recently, and it is something that you ought to keep in mind for not only posts, but also discussions you have with friends.

    Be responsible in your career, and don’t disclose information that you shouldn’t.

    (cross posted to The Modern Resume)

  • Losing Two Days

    I’m off tomorrow to the UK for a week of work at the Red Gate offices, and then a couple days of vacation. My oldest is graduating from high school this year, and as a present, we’re taking him and the rest of the family to the UK for a week. My family actually leaves Mon and will arrive Tues, and they are there for a week, coming back the following Tuesday.

    It’s not a trip I’m looking forward to. Going to Red Gate is fine, but the 10+ hour flights and being out of my routine for a week bugs me. I don’t like traveling this much. I prefer the short, two day SQL Saturday trips.

    With cutbacks on all airlines, it becomes harder to travel these days. Even going to the East Coast from Denver requires 2-3 days for work. I used to be able to catch an early flight from Denver to somewhere like NY in time for a lunch meeting on the East Coast, working half a day, and coming home late at night. These days it seems like you always have to leave the night before, and possibly stay another night if you want to work until 5pm.

    The UK is worse. I leave Sat morning, arriving early Sun morning. I would leave Sunday, but I have had issues with delays, and I have work to do Monday. Plus I hate being exhausted that first day at work more than I hate traveling. That’s a day of travel plus a slightly lost day of my weekend on Sun. I’ll probably work on Sun to get things done and get a little ahead.

    Coming back we leave on Tuesday morning, arriving late afternoon in Denver that day. However another day lost to travel, and even though it isn’t a vacation day, it’s a lost day of work. In the world I live in, which is a grinding daily list of things to keep the site running, it puts me behind. Even with someone helping out, I usually take a few days to get caught back up.

    I’m dreading this next long week, and will likely be a little out of touch on the site. Hopefully everything still runs smoothly.

  • Be Wary

    We make mistakes when we publish things. It happens, and I am as guilty as some people of mistakenly putting something down on paper that isn’t correct.

    Or worse in SQL Server, put something down that applies to one version, and it gets superseded. I don’t usually go back and rewrite things later. I don’t realize I’ve left something out there, or that I’ve forgotten the version. When someone reads it, they might assume it’s correct with my name on it.

    However I would like to think that while we have lots of controversial things published, we don’t often put something out there that’s flatly incorrect. I saw this blog post on performance optimization recently and I’ve grabbed a couple images in case it disappears.

    badblog_1

    badblog_2

    The advice given here, while sometimes correct, isn’t necessarily what I’d actually give to developers, or what I think others would give to developers. Some of it appears to be more relevant to SQL 7/2000 and not necessarily something I’d apply to current versions.

    Some things are wrong, like “However, if you create a table variable, it only resides in the memory”. This is a common misconception that quite a few people have about SQL Server table variables.

    There’s also the “Each time you get a row from the cursor it requires in a network roundtrip, where the normal query makes only one roundtrip. “ That’s not necessarily true. It depends on how you have coded around the cursor. My guess is that this person is either using ODBC cursors, or has seen developers SELECT data from each loop through the cursor. However it seems to display a mis-understanding of how a cursor works.

    I point out a couple of items since I think there is some bad advice here, and some very vague advice, that SQL Server people might not want to follow.

    To me this is actually good and bad. Perhaps someone out there looking to hire SQL Programmers of Chicago will find my, and other, commentary on this post and decide not to hire them. Or perhaps SQL Programmers will read the interesting Twitter thread on their post (from 3/17/10, about 3:00MST) and decide they should beef up their skills.

    Be wary of advice you find on the Internet, whether mine or others. Double check, and above all, test, test, test.