At the time I wrote it, I probably thought my code was beautiful. An elegant masterpiece. It should have been printed, framed, and hung on a wall of The Programming Hall of Fame. As clever as I thought I may have been a few years ago, I rarely am able to read my old code without some serious time wasted debugging.
This problem plagued me regularly. I tried different techniques to try and make my code easier to understand.
Bert has some good thoughts here, and I’ll add two small bits. First, there’s a saying that it takes more mental effort to debug code than it takes to write it, so if you’re writing code at the edge of your understanding, effective debugging becomes difficult to impossible. Second, unless you see a business rule frequently enough to internalize it, your greatest familiarity with the “whys” of the system is right when you are developing. There is huge value in taking the time to document the rules in an accessible manner; even if you wrote the code, you probably won’t remember that weird edge case at 4 AM six months from now, when you need to remember it the most.
Which brings us to the matter of getting stuff done. Imagine if everything you do has to be approved by a stakeholder and a manager, every line of code you write is peer-reviewed, then tested in a dev test environment, then in an acceptance test environment (which should both contain reasonably fresh, yet scrambled copies of the production data), then approved for deployment by the stakeholder (who ideally should also take time to verify the results), and finally deployed to production by two other people, under a four-eyes principle where no single person can perform any change in production alone. Sprinkle this with a bunch of project meetings, all while leaving a long and winding trail of tickets and documentation.
This is how most development cycles look. Except, you know, the test environments are rarely fresh, the tests aren’t really that thorough, and the peer-review could probably be called a peer-glance at best.
A lot of this depends upon the industry and the likelihood that an outage will cause direct physical harm to people. I’m personally ambivalent about where the right risk acceptance point is, but Daniel makes a good argument on the “accept more risk” side.
The message is loud and clear that ODBC is the supported and preferred path for native applications going forward. The Data Access Technologies Road Map provides an overview and history of Microsoft data access technologies, which I recommend you peruse to ensure you are not inadvertently using deprecated or unsupported technologies for new development and, for existing applications, consider moving from legacy data access technologies to current ones when practical.
The current Microsoft ODBC Driver for SQL Server as of this writing is ODBC Driver 13 for SQL Server. Note that that both the 13.0 and 13.1 versions of this driver have the same “ODBC Driver 13 for SQL Server” display name listed under installed programs and ODBC Data Source Administrator. If installed, the driver will be listed under installed programs along with the corresponding driver version (when viewed detail mode). The 13.1 version adds support for the Always Encrypted feature. These ODBC Drivers are available from the link I mentioned earlier.
They will pry OLE DB from my cold, dead hands. For my money, it’s still the best SQL Server data access technology for Integration Services, beating out ODBC both in terms of ease of use and performance.
Extended properties are a great way to internally document the data warehouse. The key advantage here is that the values of these extended properties can be retrieved with a T-SQL query. This allows us to access this information with a view as needed. My favorite method of using this is to create an SSRS report that end users can run to look up the attributes and comments I store in the extended property. Data warehouse tools take some of the pain out of the process. Unfortunately, not all tools support use of extended properties. Make sure your tool does or consider changing tools. Be sure to document the names and use cases for each property you create. Consistency is the key to the value here.
I’ve never been a big fan of extended properties, mostly because I typically don’t work with tools which expose that information easily. Regardless, there are other important forms of documentation, so read on.
With CREATE permissions this isn’t the case; there is a piece of the above template that isn’t needed, and it’s quite easy to see why when I sat down and thought about it.
Specifically, it’s this bit:<On What>
I’m granting CREATE permissions; since I haven’t created anything, I can’t grant the permission on anything.
I like this post for the direct reason (granting certain permissions doesn’t require specifying an object), but for the implicit point as well: we build up internal systems of rules and processes as we act on things. This inductive reasoning tends to work well for us in most scenarios, but at some point, our systems break down and we find out either that we need to incorporate edge cases into our system, or that we were actually focusing on an edge case the entire time.
The API has to do two things: perform an OAUTH authentication, and respond to API queries. Slack uses OAUTH to authenticate that a user really does want to add the app to the Slack team. In essence, this happens in three steps. Slack sends a web request to your API, the API server then requests an OAUTH token from the Slack service (using a secret key), and finally returns this token on the original Slack connection.
As for serving up the T-SQL reference documentation, it’s just a matter of opening static text files in the web server directory and passing them with some encoding to the client. That’s it.
All of these exchanges are JSON encoded, which is trivial to work with in node.js.
If you’re spending all day in Slack, this seems like a pretty good thing to do.
I honestly believe that company benefits tell you more about a company than any formal interview will. The benefits that a company offers to an employee are a sign of how you’ll be treated if you work there. There is definitely a correlation between great benefits and happy employees.
Companies who respect their employees will express that respect through their benefits. (The inverse is also true–companies often have poor benefits because they do not respect their employees.)
Employment is a package deal, so if you’re not paying attention to benefits, you’re missing part of your bottom line.
Recently I have been working with some new features of SQL Server 2016 and have had questions which blogs, TechNet and Stack Overflowprovided no answers on the internet. Fortunately, I have found people to help me resolve the answers. If you go searching for the same errors I had, you will find answers now, as I have posted them. If you have had a problem unique to the latest release of SQL Server, I hope you will take the time to post the question and the answer if you have it. I’m going to try to be better at answering forum questions, especially now I have learned a few interesting factoids. I am looking forward to the fact that next time when I go looking for an answer, thanks to all of us who have done the same, we can all help each other out. The next person who finds themselves in the same jam will thank you for talking them out of the tree.
And if you don’t already do so, blog. And if I don’t know about your blog, tell me about it.
This month, I have several improvements in the SQL Server 2014 and 2016 sets, along with additional comments and documentation in the SQL Server 2012, 2014 and 2016 sets. One new feature is a series of six dashes after each query to make them easier to parse by people who use PowerShell to run the queries and collect the results. I have gotten quite a bit of interest about making a special version of these queries for SQL Database in Microsoft Azure. So, I will be doing that pretty soon.
If you don’t already use Glenn’s queries, I highly recommend them as a starting point in tracking down issues.
Faced with this very issue, I decided to setup a local SQL Server Full-Text Search.
Some of the cool things Full-Text Search will give you, over and above, a standard search include the following:
- One or more specific words or phrases (simple term)
- A word or a phrase where the words begin with specified text (prefix term)
- Inflectional forms of a specific word (generation term)
- A word or phrase close to another word or phrase (proximity term)
- Synonymous forms of a specific word (thesaurus)
- Words or phrases using weighted values (weighted term)In order to get stared with the setup, it’s important to know that the Full-Text Search architecture relies on filters for searching various file types. This is important for this example because the PDF filter is not installed by default. So, for starters, we need to go download and install the PDF ifilter(PDFFilter64Setup.msi).
Up until I read this blog post, I had no idea that full-text search could index PDFs, so that’s very interesting.