For the last few months, I’ve been using Visual Studio Code on a Node.js project. It’s a pretty great editor, and its support for TypeScript is fantastic. As part of my normal workflow, I try to follow TDD practices as much as possible. For efficiency’s sake, I like to execute the tests in the test file I’m currently editing, right from the editor (I’ve written about setting up Vim to run the current test file in an external terminal in the past). Read more on Running the Current Test File in VS Code…
Over the past couple of months, I have expressed much interest in learning Clojure. The problem was that no matter how motivated I felt on any given day, I didn’t seem to put in the time and effort required to actually learn it.
I’ve been using Visual Studio as my primary code editor since 2008, and I put together a list of the top commands I use in VS 2015. I use most of these daily, but the less common ones are nice to fall back on in specific situations. I included the default keyboard bindings from the General profile where appropriate. Read more on 42 Visual Studio Shortcuts & Commands…
After working on .NET applications for the past six years, I recently spent a few months using Ember.js and AngularJS. Both originally supported organizing files in a project by type: separate top-level directories for models, controllers, views, etc. But this has changed over the past few years to prefer organizing by feature area—Ember with pods Angular with modules.
I was introduced to Caliburn.Micro less than a year ago, and it has since become my preferred MVVM framework for XAML development. It supports several conventions that reduce boilerplate code. It’s an opinionated framework that encourages a ViewModel-First approach during development.
Unfortunately, design-time support out of the box is limited to ViewModels with a public parameterless constructor1. This works for a while, but it becomes tedious to duplicate and maintain code that only exists for design-time support. I now use a
DesignTimeViewModelLocator class for binding sample data in the designer.
Read more on Using a Design-Time ViewModelLocator With Caliburn.Micro…
As software consultants, we work in many environments. Most of the time we are working in our own environment on a brand new project, but sometimes we work with a team of client developers on existing software. In the later case, we have to be mindful of their coding standards. One practice that drives me nuts is code organized into #regions.
What’s Wrong with Regions?
Microsoft introduced #regions to help organize big files into understandable chunks. In my opinion, if your code can be broken up into regions, then it can be refactored into smaller files. I try to write my classes with single responsibility in mind, where a class has a single responsibility. Therefore regions are not required to organize the code into responsibilities.
Regions are also used to separate private, public, and protected variables, properties, and functions. This is where I see them used most often. If your class is small enough, there is no need to organize them into regions. Read more on I Hate #regions…
I’ve been working in Visual Studio a lot lately, and I’ve found a few handy plugins that are very helpful for effective test writing. A good way to show these off is to follow my process for creating a new class and test via Test Driven Development. My goal here is to improve speed by removing the need for using the mouse (not to mention reduce the risk of repetitive strain injuries).
Here’s the short version:
|Navigate to a file in the test project||NavigateToTest||Ctrl+G|
|Jump to Solution Explorer||Resharper||Atl+Shift+L|
|Create new test file||Visual Studio||Ctrl+Shift+A|
|Move class under test to matching folder in core project||Resharper||Ctrl+R, Ctrl+O|
|Vertical split between test and class||VsVim||:vsp|
|Move files between split tabs||Visual Studio||Ctrl+W, Ctrl+H/L|
|Jump between files while editing||TabGroupJumper||Ctrl+W, H/L|
|Run the test||Resharper||Ctrl+U, Ctrl+R|
Now let’s take a look at the details. Read more on TDD a New Class in NUnit & Visual Studio without Ever Using the Mouse…
Brooke Hamilton has developed some of his own extensions to Presenter First and a cool-looking visual modeling tool to match.
Presenter First is a technique for organizing source code and development activities to produce fully tested applications from customer stories using Test-Driven Development. We at Atomic have not put it to use yet (none of us is using Visual Studio 2008) but it sure looks snazzy.