Voice of the DBA

Category: Editorial

  • Presentations that are Easy on the Eyes

    Recently I was at a conference and was struggling to see some Visual Studio code on the large screen. As I age, I find myself trying to sit in the front of most talks if I need to see the screen. In this talk, the speaker was using the default dark theme in VS, and it was hard to read the C# code. It often doesn’t matter if I can’t read code, after all, I’m not coding during the talk, but I do like to try and follow along as the person is talking.

    I’ve had the same issues with presentation templates. Some companies seem determined to stand out with a colored template for their event, and as they try to differentiate themselves, some will invariably use darker colors for a background. I’ve run into more than a few of these where they look fantastic on a monitor but are barely readable on a projector.

    A few days later I ran across a post from Aaron Bertrand on using dark settings for SSMS. At first I thought that was a bad idea, and I debated this with a few people. I even asked a quick Twitter poll, with most people responding they preferred a light template, but only a few people responded. I decided to seek a little wider audience and see what others think.

    What colors are easier for you to see when someone presents? Do you prefer lighter backgrounds or darker ones? I know we all want higher contrast between the foreground and background, but as we add in code coloring and other elements, what do you prefer when you’re watching something on a screen larger than a monitor?

    I do need to experiment a bit, and as Aaron suggested, blog about my settings. Mostly so that I have a copy of them that I can easily find on new VMs and machines. I don’t think dark backgrounds are better on projectors, but I haven’t really experimented. Let me know what you think, and perhaps I’ll have a whole new look for you later in the year as I present in the fall.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.1MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Consider the Downside

    Technologists are often seen as cynical and disappointed by how poorly much code is written or maybe because an application architecture isn’t well designed. I hear no shortage of complaints over other people’s code, one of the reasons I think we have so many new projects started on Github (or other pubilc repos). Everyone thinks they can build better software than others.

    However, we are often quite optimistic when we write our own code. We throw together quick apps or scripts that solve a problem, expecting the best conditions. In general, we don’t think widely about the possible issues with our code. We build and test for the happy path.

    I thought about this as I saw this post on twitter. It shows a number of Trello boards that contain passwords. To be fair, as I researched this, most of these items are private boards, though seeing names and passwords in a Google search is worrisome. I suspect most of these boards are places where less than trustworthy individuals are storing data, but I did see no shortage of public Trello boards for various software development teams. No passwords were shown, but plenty of notes, and I didn’t spend a lot of time digging through the various cards, something I suspect a hacker would do.

    I think many cloud services are very useful and they help us work in new ways. The thing we should all keep in mind is that the search engines are always probing data, even if hackers aren’t. Perhaps there isn’t a concerted effort by anyone to look for our particular set of data, but you never know. Someone may stumble upon our data and if it’s publicly visible, that’s an issue. Even server names, IPs, and more can provide information that we’d rather not disclose.

    If for no other reason, consider that employment has changed in the world. More and more of us change jobs often. Today’s co-worker might be tomorrow’s disgruntled ex-employee that discloses information to anyone, or worse, to specific hackers that might make use of it. I’m not sure how much data from our companies is valuable in a general sense to a large group of hackers, but I know there are plenty of technical vandals that would use the information to cause disruption, because they can.

    Whenever you look to setup some new process, especially with secure data, please don’t treat this lightly. Expect that someone will find a way to cause issues. And if you use any service that is connected to the public Internet, I’d be extremely careful of the data that you store there. You might be surprised how much of it is visible in search engines.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.5MB) podcast or subscribe to the feed at iTunes and Libsyn

  • DNA for Data Storage

    In all my years of working with data, there’s one think I’ve learned: it always grow. Over the years, I’ve gone from having to store data in these sizes:

    • A few KB on cassette tapes as a middle school kid
    • Using 360k floppies to 720k for programming, then 1.44MB to 100MB ZIP drives to 600MB CDs to 4GB DVDs
    • 10MB HDDs that grew quickly to be GBs and currently are TB sized in my desktop
    • A flip phone that could handle dozens of contacts with a SIM card to MBs of data in a T-Mobile G1 to a 64GB phone today

    In that time, I’ve often filled up many of those devices and needed more space. I am looking forward to seeing capacities grow again. My 64GB phone is full of pictures and video, and I need to manage the space periodically. The same thing for the 500GB in my laptop and the 2TB on my desktop. I need to add storage, and archive off some older information, but I certainly don’t want to lose any data, especially my pictures. Those might be the most valuable bits I have.

    I am alternately disappointed and amazed by storage technology advances. Capacities have grown tremendously, but speed and latency have had fits and starts. SSDs were a great improvement, and I do look forward to the newer 3D flash for laptops and high performance servers. I am glad there are these large capacity HDDs, but maybe there’s a better way to store lots of data for the long term.

    I ran cross this piece the shows the University of Washington and Microsoft working together to store data in synthetic DNA. They managed to store 200MB, which breaks the old record of 22MB. If they can improve the technology and make a commercial version, the theoretical storage could hold 1EB in a cubic inch. Even if we got 10% of this, 100TB in a little cube would be amazing. You can read more about the project at Microsoft Research.

    I have no idea what the write and read latencies are, but this could provide a nice backup for lots of data that we want to keep around, especially for images, video, perhaps even old auditing or other data that needs cheap, reliable storage that lasts years. I know I’d like to have this capability as my collection of data continues to grow, sometimes at amazing rates. I just hope this is cheap enough for general use, since as a data guy, I’d likely want 3 copies of everything. You know, just in case.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.5MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Do I Need to Learn Linux and R and Python?

    The big changes coming in SQL Server 2017 are the Linux version and the addition of Python as a language used to analyze data. In SQL Server 2016, we had the R language added, and quite a few people have been on crash courses learning R, or worrying about the fact they don’t understand how to write an R script. Now many of these same DBAs and data professionals worry that they also need to find time to pick up some Python and Linux.

    I really like Python. I spent some time with the language and still dabble here and there. It’s a clean, easy to write and read language. My son took an intro CS course this spring in college and we shared some programming thoughts and ideas in Python. If you’re interested, I’d recommend the Dive Into Python book, as well as the meeting series from SDTIG. If you want to learn R, I’ve been dabbling at TryR from CodeSchool. There are also resources from Grant Fritchey and Buck Woody. For Linux, there are tons of resources out on the Internet. I don’t have a recommendation, but feel free to leave one in the discussion.

    If you are a data professional that works with data scientists or others that might want to incorporate some machine learning or complex analysis inside SQL Server, do you need to learn R and Python? Is that the feeling that you have? Are these languages require to ensure that you can perform your job?

    I’d argue that for many of us, we don’t need to understand the language or be able to write R or Python scripts that are being run in SQL Server, or even in a tool like Power BI, to support our users. We should understand how to execute these scripts, and maybe how to correct simple typos. A working knowledge of HTML has come in handy many times for me when helping users display their data and a quick change was needed. However, I wasn’t the person you’d call to design a complex CSS and interactive HTML pages. I can just fix a few simple mistakes.

    You might feel differently, but I don’t think most SQL Server professionals, developer or DBA, really need to learn R or Python. Feel free to do so if you like, and I’d put in a recommendation for Python, which I really like, but I don’t expect that either one will be a significant part of your job in the future. Learn Linux if you want to experiment with another OS, but for the most part, SQL Server on Linux is just SQL Server. Learn some rudimentary Linux skills, but spend most of your time making sure you understand the SQL platform and you’ll be fine.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.7MB) podcast or subscribe to the feed at iTunes and Libsyn.