The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,975 other subscribers

Archive for February 13th, 2020

Use the Visual Studio Code mssql extension for SQL Server | Microsoft Docs

Posted by jpluimers on 2020/02/13

Since I really want to switch most of my SSMS usage to a tool being less resource intensive, as a truckload of my work is just running scripts, not browsing through data: [WayBackUse the Visual Studio Code mssql extension for SQL Server | Microsoft Docs

This tutorial shows how to use the mssql extension for VS Code. This extension allows you to edit and run Transact-SQL scripts in VS Code.

This will also make it a lot easier to run my code from a Mac.


Posted in .NET, Database Development, Development, Software Development, SQL Server, Visual Studio and tools, vscode Visual Studio Code | Leave a Comment »

When a team uses IntegrationTest – always ask what they mean with the term

Posted by jpluimers on 2020/02/13

Since Integration Tests have been around since the 1980s (yes, that long!), better ask what they mean in your teams.

If they are broad, you might want to re-consider and switch to narrowly scoped ones (but mind your pace).

A while ago, I landed another team, they were doing various kinds of test, but  nobody had a good definition of which was what, so I dug up the below article.

Integration tests see if independently developed units of software work correctly when connected. Traditionally broad they are now better narrowly scoped.

Source: [WayBack] IntegrationTest


Posted in Agile, Development, Software Development, Unit Testing | Leave a Comment »

Reminder to self: be aware of implicit setup/tear down code in methods

Posted by jpluimers on 2020/02/13

If a part of a method requires implicit setup/tear-down code (for instance when using managed types like arrays, strings, etc), especially in rarely taken execution paths, then consider putting that code in a separate method.

I bumped into this recently, and found out it does not just hold for Delphi, it can happen in other languages too.

A Delphi example I found back is this one: [WayBackDelphi Corner Weblog: Speed problems caused by code that never ran.

The problem with Delphi is that the language does not have local scope (variables are at the start of the method) which means the penalty is for the full method.

I bumped into this in C# where a piece of legacy code had the variables declared away from the block where they finally were used.

This historically grew, because originally they were used in more placed of the code.

The refactoring limiting the scope just never put the declaration close to the usage hence violating the proximity principle.

Via: [WayBack] Ouch! Code that doesn’t get executed can still cause other code in the same procedure to become much slower. Of course, in retrospect, once you know the… – Thomas Mueller (dummzeuch) – Google+


Posted in .NET, Delphi, Development, Software Development | Leave a Comment »

%d bloggers like this: