Category: Editorial

  • Here’s a Reason to Document

    A search engine for code

    This editorial was originally published on Feb 17, 2006. Steve is traveling in the UK this week and we are re-printing some old pieces.

    A new search engine, Krugle, set to launch next month, is supposed to focus on code. Mostly open source code, but also places like SQLServerCentral.com, which has scripts and other types of code available. Wired has a good article on the idea behind this search.

    It’s an interesting idea, though given the types of comments and the wide range of ways that things are described, I wonder if it will work. I know that we get lots of posts in the forums that I easily find answers for using Google when other don’t. I suspect that I am just searching on better terms than others. Course that doesn’t always work for my own questions, so perhaps it’s a second set of eyes that really help.

    However this also depends on the actual coders spending some time to properly describe their system. That’s always a difficult task. But even assuming that they will describe their code well, how will you know if it will “plug in” easily to your system? I’ve seen lots of code that wouldn’t easily integrate with something I was writing.

    And if I checked out 3 or 4 of these incompatible, or not easily integrated systems, from a search engine, I’d be tempted to just write my own. Actually I think lots of developers write their own code, or build on a base and then do everything themselves because it takes so long to integrate disparate code at times.

    Still it’s a great idea and I hope it works.

    Update Jul 13, 2011: Has anyone used, or is using, Krugle?

  • Bad Eyes

    This editorial was originally published on Jan 9, 2006. Steve is traveling to the UK this week and we are reprinting a few older editorials.

    It seems that most DBAs that I know are a little bit older and more experienced. It’s fairly rare that I see someone really young, right out of college, early 20s, etc., as a DBA. So when I saw this question on Slashdot about computers and vision, it caught my eye. I’m one of those “visually challenged” individuals that asked the question. And I’ve been working with computers pretty much since 1991 as a career. In middle school I slowly found out that my vision was failing. That was when my career as a baseball catcher ended. With glasses on, I couldn’t pull off the mask without pulling the glasses with them and ensuring that I’d catch the ball with my cheek instead of my glove 🙂

    I’m not a 15 hour a day computer user, but I am a 7-8 or more user. Fortunately it’s not all at one stretch. Usually it’s early am, then a break, then most of the day until the kids come home, and then late at night. At least the last few years it’s been like that. Before that I was mostly a 7-8 hour stretch person and a little at night.

    Through all that, including 5-6 years of working as a bartender in a late night, smoky atmosphere, I’ve had pretty much the same prescription for about 15 years. I switched to contacts in high school, but since college I’ve pretty much been the same, blind 20-400 in both eyes. I’m getting an eye exam today, so we’ll see if it holds for another year.

    I think the person asking the question has other problems, 15 hours a day in front of the computer being the least of them, but it still is worth asking the question. Is a monitor bad for your eyes? Is it any different than staring at anything in a repetitive work environment.

    One of the things suggested is a light source behind the monitor. That’s an interesting one. Especially for the guys that like to work in the dark. I’ve had a number of co-workers that insisted on working in the dark. Personally I’m an outside, ambient light guy. I like to sit on my shaded porch and work with the laptop in nice weather.

    So do any of you have issues working in front of your monitor? Any suggestions to take better care of your eyes? I’m sure everyone in the community would be interested in this.

    Steve Jones

  • Lesson #6: What CIOs Really Care About

    What Do CIOs Care About?

    I saw a blog by Dave Rosenberg and it was interesting in a few ways. First of all, Dave works for OSDL, which promotes the use of open source software.

    There were a number of basic things that you could probably guess like costs are important, blogs aren’t, and more. But there were two things that I really thought made sense to a SQL Server guy.

    The first was that security was mentioned as a big item, but more importantly, one of the examples was “don’t build SQL Server apps using sa.” I’ve preached against this many times, but still developers want to do it. And I don’t understand why it’s so hard to just create a login and get away from the all access development. Especially given the security issues across all platforms in recent years.

    The second one was something that I think more CIOs should stand behind and not just “talk” about. Hiring and maintaining staff was listed with this comment: “This is my number one issue.”

    And it should be. Retaining staff is a big deal, especially as more and more systems are integrated or even running side by side in new and innovative, and most often, complex ways. Having some knowledge of the journey that got you to a place is important and it’s hard to rebuild that in new people. Making good hiring decisions and then making an effort on a regular basis to be sure those people stay is important in all businesses, large and small.

    Not that you won’t have to turn over staff at times or cut your losses. After all, not every person fits in every job and circumstances certainly change.

    It should just be the exception rather than a regular practice.

    (update, Info World has removed the original blog)

  • Self-aware Instances

    I like the idea of limited self-awareness in our systems.

    I’ve been seeing lots of monitoring solutions written up lately. I saw this blog from Phil Darmanin on SQLServerCentral and we have had numerous articles written over the years on building monitoring solutions. The build vs. buy debate is one that companies regularly have, and if time is an issue, my company, Red Gate, sells a great solution in SQL Monitor that’s worth checking out.

    However most of the solutions I see use a similar architecture. They have a central monitoring server that reaches out to all other servers and gathers information from them, which is rolled up into a database for reporting. That’s fine, but in many cases there isn’t a ton of testing or error handling built into home grown solutions, and when they fail, you lose data for the day. You also either go into fire-fighting mode to get things working, or you just drop data for a few days.

    However I’ve had a different approach in the past. I’ve typically had a set of monitoring scripts that I’ve deployed to each instance, having them run on a schedule that gathers all the data on settings, changes, backups, jobs, etc. for that instance. I then have a central server that just reads that data from each instance, so if I have an issue with my rollup process, I still have the data on each instance. For this Friday, I wanted to ask this question of you:

    Do you like the idea of architecting processes to be more self aware and distributed, or do you prefer some central process that reaches out to control everything?

    It’s an interesting debate, and one that reminds me of an MIT competition years ago. Early in the 90s, there was a competition where different professors were trying to build robots to navigate a space. One team used a central CPU with complex instructions that controlled the legs and eyes and made decisions. The other used smaller, less powerful controllers in each leg and eye and had them “learn” to work together. Both worked well in different ways, but the latter approach always struck me as a more interesting one.

    For your SQL Server, or application code, which approach to you prefer and why? Let us know this Friday.

    Steve Jones


    The Voice of the DBA Podcasts