Forem: John Oerter

2021 Development Environment Review

John Oerter — Sun, 27 Feb 2022 17:49:35 +0000

Introduction

I recently had this idea to write about my current dev environment every year. I thought it would be fun to keep track of how the tools I'm using every day change and evolve over time. And since it's still February 2022, I figure it's not too late for a 2021 recap post.

My Tech Stack

This year, I transitioned to full-stack JavaScript / TypeScript development. I spend the majority of my time in Node.js and React projects deployed on serverless AWS. Prior to 2021, I spent more time in the C# / Microsoft ecosystem. C# is an amazing language and Visual Studio is a powerful IDE, but I am very happy with my new JavaScript based tech stack.

Desktop - macOS and elementary OS

I currently split time between Linux and macOS. I've been a Linux user for years and have primarily used Ubuntu and other Ubuntu-based distros. I switched to elementary OS earlier this year and have really enjoyed it. Even though I have used Linux for a long time, I don't really enjoy fighting with updates or spending lots of time configuring my desktop environment. Elementary gives me the best out of the box experience I've found on Linux so far. All that being said, my Linux laptop is getting old, and I'm planning on buying a MacBook to replace it. I've been eyeing the M1 for awhile, and I think it's the best choice for me right now. If System 76 ever releases a laptop made in house like the Thelio or Launch Keyboard, I will definitely check it out.

Editor - NeoVim

My VIM setup with Neovim has never been better. I've gone back and forth on using VsCode, Emacs, and JetBrains IDEs instead of VIM in the past, but I keep coming back. Almost every editor these days has VIM emulation, but at the end of the day only VIM is VIM. What I mean by that is even the best VIM emulator running in another editor falls short of the real thing in some way. I made a real effort to switch to Emacs at the end of 2021 by following System Crafters Emacs from Scratch series. The videos were really excellent and I learned a lot, but in the end, I couldn't quite get over the performance issues with Emacs and switched back to Neovim. I fully expect to maybe flop back and forth on this position in the future, so I'm very curious to see where I'm at a year from now.

Luckily, there is a lot of development going on in the Neovim ecosystem and many great plugins are taking advantage of the new Lua integration. I can now easily have an LSP configuration that gives great autocomplete similar to VsCode. Here are a few of my favorite plugins:

Here's a screenshot of my current Neovim session:

I'm using the Dracula colorscheme everywhere I can.

Terminal - Alacritty, tmux, and zsh

Alacritty has been my terminal emulator of choice this year. It's easy to configure using yml files so I can share my configuration between machines. Tmux is a vital piece of my workflow for organizing my sessions and windows.

Zsh along with Oh My Zsh has been my shell for years now. I make heavy use of the cdc and zsh-autosuggestions for moving between repos.

Link to my dotfiles repo on GitHub

Message in a Bottle - A Simple Clojure App

John Oerter — Thu, 10 Dec 2020 03:16:14 +0000

The Social Network for Deserted Islanders

I've been spending time learning Clojure lately, and I wanted to build a super simple web application to put my learning to use. Message in a Bottle is a fake social network for people stranded on deserted islands. It allows them to read and send messages to other stranded people. Messages are at the mercy of the wind and waves so you'll never know who will get your message or what you will receive. But that's part of the fun!

People stranded on deserted islands aren't lucky enough to have access to the social networks you and I use and enjoy every day. How can they waste hours of their day scrolling through timelines or experience extreme jealousy at that new rainwater collector their friend built? Message in a Bottle is the answer.

In this post, I'll dive into how I built the app and what I learned. If you'd like to check out the app, visit https://message-in-a-bottle-1.herokuapp.com/. My apologies if the performance is slow or the app takes a minute to respond. I'm using the Free level of Heroku which sleeps after 30 minutes of inactivity. Feel free to read and write a few messages! I need to find a way to increase the daily active users of Message in a Bottle before the IPO... 😆

You can find the source code here.

Overview

In order to keep Message in a Bottle simple, I decided to use an MVC-style approach with no client-side code. That way, I could just focus on a simple request-response cycle with a simple form and data store for persisting the messages. Since the messages aren't relational in any way, I decided to persist them using Redis. I've used Redis in the past with JavaScript and C# and generally find it to be a joy to use.

Here's a quick list of the main tools I used:

Leiningen - Leiningen is the main build and dependency manager in Clojure. Think of it as a bit like NPM if you're coming from JavaScript land.
Ring - HTTP web stack
Compojure - Routing library for Ring.
Hiccup - Write HTML in Clojure!
Environ - For managing environment variables.
Carmine - Clojure Redis client
Redis - Message persisitance
Docker and Docker Compose - Local development
Heroku - Deployment and hosting

Routing and Handling Requests

I used the Compojure Leiningen template to scaffold the app with lein new compojure. That template starts you off with a handler.clj file that contains a sample route and app setup with the default settings. Here's how my routes ended up at the end:

(defroutes app-routes
  (GET "/" [] (handlers/home))
  (GET "/read-message" [] (handlers/read-message))
  (GET "/send-message" [] (handlers/send-message))
  (POST "/send-message" [message] (handlers/sent-message message))
  (route/resources "/")
  (route/not-found "Not Found"))

Each HTTP method function from Compojure takes a string for the route url along with a function to run for the response. I chose to set up these functions in a handlers.clj file. I'm not sure if that's idiomatic Clojure or not since they are essentially controllers, but that's how I did it. I would love to hear any stylistic improvements or suggestions anyone has here.

Take a closer look at the (POST "/send-message" [message] (handlers/sent-message message)) form. The [message] argument is the value of the message textbox POSTed to the server from the web browser. It is passed on as an argument to the handlers/sent-message function.

This is one of the reasons I really enjoy writing Clojure. This code is highly readable and low-ceremony. If I compare this to C# and ASP.NET Core, which is where I spend most of my time writing web applications, I notice the lack of syntax, keywords (public, class, namespace, etc.), and type declarations. We can debate the merits of statically vs. dynamically typed languages, but there's no denying that Clojure is a simple and beautiful language to read.

Writing HTML with Hiccup

Using Hiccup to write HTML in Clojure is a joy as well. The idea is to use vectors for elements, and maps for attributes. Here's an example of the form to send a message:

(defn send-message
  [validation-message]
  (layouts/default "Send Message"
    [:p "Write your message below. Unfortunately, the paper can only hold 250 characters."]
    (if (nil? validation-message) [:span] [:p validation-message])
    (hf/form-to [:post "/send-message"]
                [:textarea {:name "message" :autofocus "true" :rows "10"}]
                [:input {:type "submit" :value "Send"}]
                (rf/anti-forgery-field))))

In this function, I'm using a layouts/default function I created as well. This function adds in some default HTML I wanted to have on every page like CSS, a page title, and simple app header.

The hf/form-to is a hiccup defined function that creates a form with an action on submission. Inside the form, I've added a simple textarea element along with a submit button.

Storing Messages with Redis and Carmine

Let's get to the good stuff!

My basic idea for storing and reading the messages using Redis was to store each message using a random UUID as the key. Then, I could use Redis' RANDOMKEY command to easily get a random message every time a user wants to read a new message.

Carmine, the Clojure Redis client I used, gives an example of a wcar* macro to use when issuing commands to Redis. I'm still learning about Clojure macros, but this one seems pretty simple. Here's the definition:

(defmacro wcar* [& body] `(car/wcar server1-conn ~@body))

This saves me from having to reference the server1-conn definition every time I use a command. Therefore, saving a message is as easy as calling SET with a UUID:

(defn save-message [message]
  (wcar*
   (car/set (uuid) message)))

Where uuid is a function that returns the unique string.

Then, to read out a message I just need to get a random key from Redis:

(defn random-key []
  (wcar*
   (car/randomkey)))

And use that random key with the GET command:

(defn get-message []
  (wcar*
   (car/get (random-key)))

Easy peasy!

Wrap Up

I learned quite a bit with this project. It was a challenge to get started, but I'm glad I picked something simple enough to finish quickly. Next, I'm going to focus on some front-end ClojureScript development by working through the https://eugenkiss.github.io/7guis/ project.

Vim and Vim Emulators

John Oerter — Thu, 19 Nov 2020 03:13:00 +0000

Introduction

I recently scored a license to the Rider IDE from JetBrains through work. I've been a Resharper user for years, but this is the first time I've used a full JetBrains IDE. I have to say that I'm really enjoying it. This is also my first experience with JetBrains' Vim emulator, IdeaVim.

I've been a Vim user since being required to use it in my intro to programming course in college. Like many Vim users, I've gone back and forth between using and believing in a pure Vim setup, and using the Vim emulators that are available for pretty much every IDE and editor.

Today, I believe I have settled on using Vim emulators. Here's why:

IDE-like Vim Configuration Is Hard

I've spent a good chunk of time fine-tuning my .vimrc, but there have always been a few features that seem just out of my reach to get working perfectly. Auto-completion is a perfect example. I've tried coc.nvim and others, but I still can't seem to achieve the level of auto completion that comes out of the box in VSCode, Visual Studio, or the JetBrains products.

This isn't because these Vim plugins are buggy or low quality, it's just that the amount of work it takes to install the plugins, learn how to use them effectively, and maintain them across updates is really hard to stomach when I can download any of the IDEs I mentioned earlier and get this functionality working almost perfectly without any extra work.

It's the struggle between taking the time build a setup that is made specifically for my needs and tastes versus accepting an environment that may not check all the boxes, but allows me to be productive from day one.

Vim Emulators Are Good and Getting Better

The three main Vim emulators I've used are VsVim for Visual Studio, VSCodeVim, and IdeaVim. I've had generally good experiences with all of them, and they can all effectively emulate the main features of Vim that I find useful. As long as I can use the standard motions and keybindings and create some simple imap and nmap rules, I'm happy. If the emulator supports macros and relative line numbers that's even better.

One of the most important features to me is the ability to switch from INSERT mode to NORMAL mode easily by typing "jk". I made the switch to this a long time ago to save myself the time of reaching for the ESCAPE key or using the CTRL-[ shortcut. I would suspect this is a difficult effect to achieve in an editor that doesn't support modal editing natively, but all the emulators above are able to mimic this flawlessly.

Conclusion

I still see myself dropping into Vim if I need to quickly edit a file, but I believe the days of making constant tweaks to my .vimrc are over. Vim (including emulators) continues to be highly relevant to today's developers, and offers a substantial productivity boost to those that take the time to learn to use it effectively. If you're interested in taking the plunge to learn Vim, I would recommend checking out Learn Vimscript the Hard Way and Vimcasts. However, I think the best way is the old fashioned one of starting up Vim Tutor and practicing regularly with code katas until the keybindings become second nature.

10 Tips for Awesome Angular Apps

John Oerter — Sun, 08 Nov 2020 23:32:56 +0000

This article started out as an explanation of my approach to handling state management in Angular apps. Instead, it's turned into a list of lessons I've learned while using Angular for around 3 years. I hope you find a point or two useful or at least find one of the articles I've linked to informative and a good jumping off point for your own exploration and learning. Enjoy!

When it comes to state management in Angular apps, there are plenty libraries to choose from. A few examples are NGRX,
Akita, and NGXS.
You can even use libraries more popular in the React ecosystem like Redux and Mobx. In my experience, these libraries add boilerplate and knowledge overhead and you're usually better off using vanilla Angular with @Input and @Output properties and services. You Might Not Need Redux is a great article about this topic from the React perspective, but I think the same principles apply to Angular.
"Prop drilling" is the problem where you need to pass @Input or @Output properties through multiple layers in the component tree. I recommend utilizing a service to manage state when passing data through 3 or more layers of components. You can even use hierarchical dependency injection to make services visible only to a certain component tree instead of global to the entire application.
Favor composition over inheritance. Since Angular components use TypeScript classes, it can be tempting to reach for inheritance to share common functionality. In my experience, this leads to a rigid architecture that is difficult to debug and follow. Compose components, refactor shared functionality into services, or use shared directives instead.
Dynamic component loading is possible in Angular, but almost never useful at the application level. I can see its uses in libraries, but for applications, I've never seen a problem solved with dynamic components that couldn't have been solved more easily with a simple *ngFor or *ngIf directive.
Use the OnPush Change Detection Strategy. This results in increased performance, but that's not the main reason I recommend it. OnPush gives you more control over when change detection runs and forces good practices when it comes to immutability and changing @Input properties. Netanel Basal has a fantastic article about OnPush here.
Use the async pipe. Subscribing to streams in components can cause memory leaks if not unsubscribed during the OnDestroy lifecycle method. Instead, let the async pipe handle this for you. It runs change detection when using OnPush Change Detection too!
For DTOs and communicating with your backend, favor interfaces over classes. The simple reason is that TypeScript interfaces only exist at compile time and are not present at runtime. Classes, on the other hand, are bundled with the application and can cause unnecessary weight if you're only using them as a data structure.
Strive for immutability in your applications. You may find success using a library like Immutable.js to force immutability, but I've found that using OnPush change detection and having a good code review process can be just as good without the 3rd party library overhead. This can really be as simple as using spread syntax and reassigning to array and object fields in components.
Use Spectator for your unit tests. This library is awesome. When I first started using Angular, I found the TestBed and built in testing tools so cumbersome I favored writing class based tests for every component. With Spectator, tests are a breeze to setup and it helps you write better tests. It does this by emulating the same selectors used by the Testing Library family.
Don't test implementation details of your components. Another way of saying this is that you shouldn't have a test file for every single one of your components, directives, or services. Instead, test the behavior of your application like a user would at a higher level in the component tree. In the OOP world, Uncle Bob calls this Test Contra-variance. By following this, you will end up with tests that may exercise the functionality of multiple components at once. This leads to tests that are far more valuable and less prone to breaking due to minor refactors in component structure.

Thanks for reading! Let me know if you've found this article helpful or disagree with any of these points.

Originally posted at https://redgreenrefactor.dev/posts/ten-tips-for-awesome-angular-apps

Gear for a quick and effective standing desk

John Oerter — Tue, 17 Mar 2020 15:39:41 +0000

Today, I'd like to spread the word about two products that have significantly improved my work from home situation during this COVID-19 outbreak. If you're like me and don't have a furnished home office already, I hope you check these out and find them useful. The two products are the Roost Stand and the GhostStand desk.

Roost Stand

I am seriously impressed with this stand. When I was in the market for a laptop stand, I was looking for 3 things:

Wide compatibility with different laptop sizes and models
Portability
Overall quality

For me, the Roost Stand hits all three marks. It's light yet sturdy. I can easily carry it with me to coffee shops, and my laptop feels extremely secure when it's resting on the stand.

If you don't already have a laptop stand to put your laptop at an ergonomic height, I highly recommend the Roost Stand.

Ghost Desk

You might be wondering why I'm recommending what essentially looks like a cardboard box. While it might seem silly, this desk does a pretty good job of making a workable standing desk if you don't have an alternative. You could cobble together some surfaces from around your house and accomplish the same thing, but it's harder than you'd think to get the right stair step height for keyboard and mouse placement lower than the monitor placement. For me, I've also found the portability aspect of this product to be a huge advantage over alternatives. It's also surprisingly sturdy for cardboard. I've been resting my laptop with the Rooststand on top and don't have any worries about the whole stand collapsing.

That's it! I hope you find these products helpful. I'd love to hear and see other improved work from home desk areas in the comments.

Integration Test Entropy

John Oerter — Wed, 19 Feb 2020 04:23:40 +0000

What is Entropy?

According to the Oxford Dictionary, entropy can be defined as:

gradual decline into disorder

When I think about integration or end-to-end tests I've encountered in my
career, entropy definitely comes to mind. I have written and encountered
integration tests that were written when the project was under active
development, but became more and more brittle and lost value as time went on. As a result, developers begin skipping them in CI builds and soon neglect them altogether. In this article, I want to talk about the two main reasons I believe this entropy occurs and what can be done to make sure integration tests thrive and provide value throughout the lifespan of a project.

Note: Integration tests could have many different meanings to different
developers. For the purposes of this article I'm referring specifically to end to end tests that either test a UI (Selenium, Cypress, etc.) or test the data returned by a REST API.

Data Reliance

The most common reason for brittle integration tests I've seen is a reliance on data. I do believe that end-to-end tests should manipulate data all the way to the data store in order to assure stakeholders that the application is working properly. However, these tests shouldn't assume that the data will always and forever be in the correct state for an accurate run of the test. Data change is inevitable and no one wants to waste hours trying to diagnose a failing test because of a change in data.

There are several ways to mitigate this risk. The easiest would be to write setup and tear down code for integration tests that ensure that data is in the right state before and after the run. Of course, if integration tests can be written in a way that they are not reliant on any specific data this is even better. A more complicated solution could be to utilize a Docker container that contains known data specifically for integration tests.

Business Requirements

In my opinion, every integration test should be tied to a business requirement and this link should be immediately obvious to anyone who encounters the test. Unfortunately, this doesn't always happen. Tests that make an HTTP request to an API endpoint and assert against data or tests that look for a specific element to appear on a UI don't necessarily meet this need. When the test inevitably breaks for a developer unfamiliar with the original requirements, the test should make its value clear. Otherwise, it's all to easy to decide the test isn't valuable anymore and delete it.

My favorite method for linking tests to actual business requirements is to use Behavior Driven Development. You may be familiar with this concept as BDD, Cucumber, or Gherkin, but the idea is the same. If integration tests can be written in a behavior oriented fashion that business owners can easily understand and verify, the result is a huge win for the project.

Originally posted on redgreenrefactor.dev

Learning to Love Testing Library

John Oerter — Wed, 12 Feb 2020 04:00:49 +0000

When I first started using Angular, I found the built in testing tools awkward to use and slow to run. In order to write unit tests and get into a TDD flow, I turned to isolated class tests. I really enjoyed this technique
because it let me write tests for Angular components in the same fashion that I would write tests for C# classes. I even made a simple function to create typed stubs of dependencies to inject into tested classes.

This method worked, but I've now learned that there's a better way. I've been playing with angular-testing-library and react-testing-library recently, and they've completely changed the way I think about UI tests. If you're not familiar, these libraries are a part of a family of libraries built for writing maintainable tests in several different JavaScript libraries. This can be explained by one of the guiding principles
of Testing Library:

The more your tests resemble the way your software is used, the more confidence they can give you.

This means that all the implementations of Testing Library only expose ways to assert against the DOM. In angular-testing-library for example, there is no way to assert against properties or methods on the component itself. You must query the DOM in the way a user would interact with your application.

My first reaction to this philosophy was a negative one. I thought that this was too limiting, and would make writing unit tests very difficult.
But I was very wrong! I've been using Testing Library more and more and I've found that the guiding principle is 100% correct. But it also has me
wondering, are tests writtien with Testing Library Unit tests or Integration tests?

At first, I thought of them as integration tests because of two reasons:

Tests written with Testing Library interact with apps in the way a user would - through the DOM. This style is often associated with other end-to-end test frameworks like Cypress or Selenium.
I find myself testing features of an app that may involve a parent and many child components instead of writing 1 to 1 tests for each component.

The more I think about it, however, I'm not sure this distinction really matters and I'm comfortable with either classification.

Going back to #1 above, the DOM really is the public API of my UI components just like the public properties and methods are the public API of classes and interfaces in C#. Therefore, it makes sense to test UI components only through the DOM and not through the "implementation details" of their component properties, even if these properties are accessible "in code".

For #2, this is a pattern that I'm adopting more and more for C# as well. Unit tests don't have to be - and probably shouldn't be - written
1 to 1 for classes. Instead, I've begun writing tests for a top level class that may depend on other helper classes whose functionality is tested through the public API of the top level class. This leads to far less mocking and more maintainable tests.

This is how Testing Library has changed the way I think about testing for the better. If you haven't tried it out yet, you should check it out in
your framework of choice! There are flavors for React, Angular, Svelte, and more.

Originally posted on redgreenrefactor.dev

Bowling Game Kata in JavaScript

John Oerter — Tue, 24 Dec 2019 14:27:23 +0000

I created a video showing the Bowling Game Kata in JavaScript. This is a kata originally created by Uncle Bob Martin. I wanted to show the kata in JavaScript. This is a great kata to do when learning TDD, a new language, or practicing using your editor more efficiently. Thanks for watching!

Do you use Bootstrap?

John Oerter — Thu, 12 Dec 2019 19:06:38 +0000

Not long ago, it felt like every site and app in the world was built on top of Bootstrap. Now, it feels like there are a lot of other great options and even though Bootstrap is still very popular, I feel like new projects aren't using it as much. I'm curious if you're still using the framework - especially in a newer project and your reasons for or against Bootstrap usage.

Correctness vs. Behavior

John Oerter — Wed, 11 Dec 2019 16:38:20 +0000

I recently read this excellent blog post by Bob Martin about an interesting
debate he had on Twitter with Mark Seeman. The debate centered around
testing in static vs. dynamically typed languages. Uncle Bob made the assertion
that using a statically typed language does not reduce the number of tests
one needs to write because one must still execute the tests to prove that
the system has the correct behavior. Mark Seeman made the point via one of
his past blog posts that languages like Haskell that don't have nulls eliminate a
whole class of tests one would need to write in a dynamically typed language or one that allows nulls.

In his article, Martin runs through the same problem that Seeman solves in his blog using
Clojure, a LISP-style dynamic functional language.

Near the end of the article, Uncle Bob makes the following statement:

This is the crux of the argument between Mark and I. I claim that the number
of tests required are only those tests that are necessary to describe the correct
behavior of the system. If the behavior of each element of the system is correct,
then no element of the system will pass invalid arguments to any other.
Invalid states will be unrepresented.

I was so happy when I read this because it made an idea clear in my head that
I've been feeling for years, but didn't have the words to express. I now call it
Correctness vs. Behavior. I've felt that some developers approach tests in a
similar fashion as Mark Seeman, and feel they need to prove the "correctness" of
their systems by testing that it correctly handles every possible input.
This is why they often prefer statically typed languages. To varying degrees,
these languages are able to guarantee some kind of safety and eliminate
the need for some kinds of tests.

I agree more with Bob Martin's line of thinking. If the whole system is well tested,
why should I feel the need to write tests for states that are never going to happen?
I prefer to focus on the behavior of the area of code I'm testing.
In this way, the difference between statically and dynamically typed languages doesn't matter much
at all to me.

I wonder if this different way of thinking is something that turns developers off from TDD.
I wonder if developers that feel they need to cover every invalid argument or state in
their system don't see the benefits of driving the correct behavior of a system with tests.
This mentality could be why many developers prefer to write their production code first and
then use tests to prove correctness.

This article is not meant to spark debate about which way of thinking is better or more effective.
I have simply found joy in being able to finally express this dichotomy and expand on it here.

Introduction to Code Katas

John Oerter — Wed, 11 Dec 2019 16:37:18 +0000

What Are Code Katas?

In the software development world, code katas are commonly used by developers
to hone their skill. They are meant to create a safe environment to experiment
and learn new techniques. The word "kata" is borrowed from the world of martial
arts.

In that world, katas are a series of choreographed movements meant to
be memorized and practiced over and over again until they are perfect. Similarly,
code katas are meant to be practiced regularly, making small improvements each
time. Code katas are usually performed using Test Driven Development.

When a martial arts practitioner masters the movements of a kata, the idea
is that he or she will be able to perform the same movements perfectly
in the real world without hesitation. The same idea holds for code katas.
The TDD flow of a kata along with its refactorings are memorized so that a
developer can perform similar refactorings and patterns in production code.

The point of a code kata is not to figure out a solution to a problem as quickly as
possible. Rather, the point is to intentionally practice the fundamentals of
writing code with TDD and using your chosen editor efficiently. Each time
a code kata is performed, small improvements should be made. These
improvements and gained efficiencies will be transferred into production code.

How Do You Do a Code Kata?

Getting started is easy!

First, choose a problem or create your own.
There are numerous katas out there that other developers have created. Some
of the most popular are the Bowling Game,
String Calculator,
Prime Factors,
and Roman Numerals.
Next, choose a language. Depending on your goals, you can choose a
familiar language or learn something entirely new. When doing a new kata
for the first time, I would recommend using a familiar language. You can
try new languages later after you're understanding of the kata is solid.
Start coding! Remember to follow the TDD cycle:
- Write a failing test
- Write just enough code to make the test pass
- Refactor
- Repeat

Remember, this is a safe environment where you're free to make mistakes.
If you can't figure out a kata, don't feel bad about looking up solutions.
The point is to learn the movements of TDD or to practice the keyboard
shortcuts of your editor.

What Are the Benefits of Practicing Code Katas?

The three main benefits of practicing code katas are:

1. Practicing the TDD flow.

I hear that many developers want to learn TDD, but learning TDD on the job is
not always a good option. We need a safe environment to fail and learn without the
pressure of deadlines or preventing bugs. Code katas can offer that environment to
any developer that cares to improve or learn their TDD skills. Regular code kata
practice should make doing TDD in the workplace almost second nature.

2. Increased Editor Efficiency

Have you always wanted to learn Vim, but never felt you had the time? What about
all those ReSharper shortcuts? When you practice a code kata, you can take the time
to learn the most efficient key strokes and really get to know your editor. This can
really pay off when writing production code. It's a great way to increase your
confidence as a developer. Whatever editor you use, you owe it to yourself
to be as proficient as possible with your tool set.

3. Learn a new language or language features

After you understand a kata well and have practiced it a couple of times, feel free
to experiment. What would the code look like in a completely different language from
the one you use everyday? Are there some brand new features in your favorite
language you have yet to try out? Code katas are a perfect way to both learn
new languages and gain a deeper understanding of familiar languages.

Closing Thoughts

In life, fundamentals often separate the successful from the unsuccessful. What do
many coaches say after a tough loss? "We have get back to the fundamentals".

As developers, how do we practice the fundamentals of developing software?
I think this is something that our industry often forgets. We are so eager to dive in
and start slinging code that we rarely take the time to slow down and deliberately
practice to improve our skills. I believe doing regular code katas is a fantastic way
to practice the fundamentals developing software and will make a noticeable difference
in your productivity.

Originally posted on RedGreenRefactor

A Short Introduction to TDD

John Oerter — Wed, 11 Dec 2019 16:33:30 +0000

What is TDD?

Whether you're new to software development or have been around for awhile,
you may have heard of TDD, but have never really gotten a full explanation
of the process and benefits of adoption. The purpose of this post is to give
you a quick introduction to TDD and hopefully pique your interest if you don't
already have TDD in your arsenal of tools.

So what is TDD? To put it simply,

TDD (Test Driven Development) is a methodology of developing software
that relies on very short feedback loops using unit tests.

To practice TDD, start with a failing unit test.
Then write only enough code to make that test pass. Finally, refactor the
production and unit test code you've written. Repeat.
This cycle is often called Red Green Refactor and is the inspiration for the name of this blog.

Uncle Bob Martin summarized this
process into what he calls the "Three Rules of TDD",
which are:

You are not allowed to write any production code unless it is to make a failing unit test pass.
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Why Should I Learn TDD?

Learning and practicing TDD has numerous benefits while developing software.
I'll expand on the most important ones to me here.

The Code is Always Running

When you're in a TDD flow, the time between unit tests runs is usually no more than a few minutes.
This means that at any given point, the whole program worked at most a few minutes ago.
If you somehow make a change that breaks some part of the code, it's much easier to undo
that change and get back to a working system. This makes it much harder to have an
hours long coding session of many changes that leaves a whole program in disrepair.
And if you're being proactive during the Refactor phase of a TDD cycle,
your code is always in a clean state which makes the possibility
of creating bugs smaller.

Saving Debugging Time

Another benefit of tighter feedback loops from unit tests is a drastically smaller
need to use the debugger. You may still need to use the debugger if a test unexpectedly fails,
but the issue should be much more apparent when there is only a small unit of code to debug.

Easier Refactoring

After following TDD for a bit in a large system, you may have hundreds of unit tests.
These tests are your best defense against breaking the system.
If you find that the architecture is flawed in some way,
you can always rely on these tests during refactoring.
You could fearlessly delete all of your production code and start completely
from scratch while being guided buy a suite of comprehensive tests.

Unit Tests as Documentation

Having a large suite of passing unit tests can act as living and
breathing documentation of your system. This is like a detailed specification
that is forced to stay up to date with the production code. When other developers read your code,
they can use these tests to understand the requirements of the system and the constraints.

Gets Requirements Out of Your Head

Last, but certainly not least, is my personal favorite.
If someone asked me why I use TDD and why I am more effective as a
developer when following a TDD flow, this is the first reason I would give.
As developers, we are usually juggling so many thoughts and concerns while creating software.
Requirements, edge cases, and possible performance issues are just a few examples.
By practicing TDD, I can get those out of my head piece by piece and
build upon them bit by bit. I can solve the simplest problems first and then
move on to the more complex. TDD allows me to get out of my own way when
writing code and solve problems faster.

Wrap Up

I hope you enjoyed this article. If you've never heard of TDD,
I hope I've inspired you to check it out. If you've tried it
and decided it's not for you, then I hope I've inspired you to give it another shot.

Originally published on RedGreenRefactor