Visual Studio Code is an excellent editor, with a ton of room for customization. As a recent convert from Emacs, I appreciate the ability to customize my editor through the form of extensions. Creating an extension is quite simple, if none that fit your needs are available in the marketplace. Read more on Building Your Own VS Code Extension for a Mac Touch Bar…
Recently, I needed to add an entry to the local domain name server on my home network. For many years, I have used Emacs to edit files on the terminal both locally and on remote systems. However, over the past year or so, I’ve become familiar with Visual Studio Code, and I very much enjoy its editing experience. I searched through the available extensions and found one called Remote VSCode.
Like many other developers at Atomic, my Git workflow relies heavily on the command line. I recently started using Visual Studio Code since my editor of choice, Spacemacs, did not have great React and TypeScript support.
Since I started using VS Code’s Git interface, I have seen an improvement in my productivity. Here are some benefits to using a GUI in your Git workflow. Read more on Integrating a Visual Git Interface into Your Workflow…
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…