Skip to main content


Showing posts from 2015


This tweet by Kent Beck explains perfectly why I use TDD. what if the problem with TDD is that it is adapted to address a level of anxiety most people just don't experience? — Kent Beck (@KentBeck) November 19, 2015 When I was first introduced to TDD and Unit Testing, I was blown away by the fact that I had never thought of writing code to test my other code. I would write code and run the entire application to see if the changes I made worked correctly. I would test the happy path and then pass it on to QA for more verification. I knew that I didn't find all of the bugs in the code, but I also wasn't sure what more I could do to find them. I hated when I got bugs back from QA and worse when the customer found a bug. I have the anxiety Kent is talking about. It was pretty stressful to deal with this anxiety as I wrote code not knowing how I was going to mess up this time. I would fix something only to introduce a new issue or cause a previously fixed problem to re

How to deal with difficult code

I have recently been working on a piece of very complex and very poorly designed code. It has been very difficult staying focused on the task at hand because I just can't keep everything going in my mind. I lose track of what path I was working on or how I got to a specific spot in the logic tree. What can I do in this situation? Unfortunately, I can't completely rewrite the entire section of code, even though it desperately needs it. Even if I was free to rewrite the entire piece of the system, I don't have a good enough understanding of it to be able to completely rewrite it without breaking it. I can, however, make changes to the code to make it easier to understand. I can accomplish this without changing any of the logic in the code. This will shrink down the amount of code I need to work with. I can start by taking a piece of code and break it out into its own method. This new method will do nothing different than what it was previously doing. It will receive a n

Heartland Developers Conference 2015

I had the opportunity to attend the Heartland Developers Conference this year. I had a really good time. I got to learn from really smart people, catchup with friends, and meet some new people. The biggest takeaway I had from this conference was how to evaluate which session to go to. With the first few sessions I attended, I tried to find topics that I already had familiarity with hopes of getting deeper understanding. I came to the conclusion that that was not a good approach. The sessions at conferences are not able to dig very deep into a topic. There just isn't enough time for the speakers to cover a lot of ground. So I changed my plan for which talks to attend and chose the ones on topics that I had no knowledge of. This worked out much better for me. I found a lot more new information and generally enjoyed the sessions more. I will highlight some of the other items that I found interesting below. Swagger is an open source abstraction for documenting your REST api wit

Finding Happiness

I listen to a lot of podcasts. They are great for entertainment as well as education. I finished listening to a recent podcast by Tim Ferris in which he interviews Naval Ravikant . The entire podcast was great, but one part really jumped out at me. You can find the podcast here , and I have detailed below what I found so enlightening. “Desire is a contract you make with yourself to be unhappy until you get what you want.”  – Naval Ravikant This is the pull quote for the podcast, so it must have struck Tim in a similar way that it struck me. I have experienced this, but haven't been able to see this wisdom before. When I want something really badly, it consumes my every thought. Then of course, once I actually obtain whatever it was, it doesn't actually make me happy. At least not to the extent that I was unhappy before I got it. Thinking about a desire with this mindset really changes the desire's affect on you. Naval then continues with, "In any situation in l

Using tsUnit to Unit Test TypeScript

I have been working on a project using TypeScript and needed to use TDD to build up some of that project. I wanted to find a way to write my Unit Tests in TypeScript so that I could continue to practice TDD and ensure that my code’s logic was sound. I found tsUnit , a TypeScript Unit Testing Framework. The documentation explains pretty well how to get started with simple unit tests. After getting a simple test running, I found the need to have a setup function happen before each of my tests run. I couldn’t find any documentation on how to accomplish this from the github documentation or through some quick Google searching. If I want to have something run once before my tests start up I can use the constructor of the TestClass, but I needed this to happen before each test so that they are in a known good state. I found the answer by digging into the tsUnit.ts file itself. To get a function to happen before each test, use the setUp function, this name is the same as the attribute that N

Mapping Objects

My purpose for this blog is to share what I learn as I become a better developer. Sometimes I have thought of an idea for a post but haven't come up with enough content to finish the entire post. I had a feeling like a post needed to be a certain length before it would be worth posting. That idea doesn't completely mix with my purpose for the blog. Sometimes you don't learn things in a large post, sometimes its just a little nugget of knowledge that doesn't require a ton of explanation. With that said, something I recently relearned is that mapping objects to other objects, especially with different property names is a bad idea. It leads to confusion when working with the code. It also creates more opportunities for bugs to exist. So if you need a property from one object to map to a property on another object, use the exact same name. And if you can just use the original object without mapping to another object, that is even better. 

Training With Dan Whalin

I had a great opportunity this week to be a part of a training course given by Dan Whalin . The focus of the class was on AngularJS, JavaScript, and a little bit about TypeScript. I learned a ton during these few days and want to share some the key points that I took away. First, Dan is a great teacher and presenter, if you have the chance to take one of his courses or see him at a conference, I would highly recommend doing so. Day 1 JavaScript Naming functions in JavaScript you should be consistent. A Good practice to follow is: Anything that needs to be "newed" up should be Pascal Cased (Upper first) If the item is static it should be camel cased (Lower first) If you have a function that accepts many parameters, change it to only accept one object with properties for all of the parameters you will need. Then when calling the function you can call using an object literal. This prevent parameters from being passed in the wrong order. Since JavaScript is dynamic i

Converting a Large AngularJS Application to TypeScript Part 2

In part 1 I was able to take an Angular controller written in JavaScript and convert it to a TypeScript file while doing very little to change the code. In this post I am going to explore transitioning that same controller to actually use the features provided in TypeScript. This is how I left off my controller: declare var angular: any; (function () { 'use strict'; var controller: any = function($scope){ ... } angular .module('app') .controller('controller', controller); controller.$inject = ["$scope"]; })(); While performing the translation from JavaScript to TypeScript, I would make sure at every step that the functionality I expected still worked, so if anything I did broke the system I would change it back and try again with another approach. Also if something seemed like it worked too easily, I would break it on purpose to make sure I wasn't getting a false result through browser caching a previously working

Unit Test Builder Pattern

I was recently introduced to a pattern for setting up Unit Tests with test data that I really like. It is called the Builder Pattern. It abstracts away the setup of your test data so that if properties or structure of your test data changes, you can make that change in one place and it will update all tests that would have otherwise been broken. It also makes it more clear exactly what you are testing for because you take the specific variables in your test data out of the tests and into the builder, leaving behind the intent of the test. Following the Arrange, Assert, Act layout for a Unit Test, the Builder Pattern helps you define what goes into the Arrange section, and makes that section more readable and adaptable to change. Lets look at an example of what some current unit tests might look like. [Test] public void TaxAmount_CountryEngland_Returns0() { var testData = new TestData() { Country = "England" }; var result = Target.GetTaxAmount(testData); Ass

Converting a Large AngularJS Application to TypeScript Part 1

I work on a project that uses AngularJS heavily. Recently we wondered if using a preprocesser like CoffeeScript or TypeScript for our JavaScript would be beneficial. If our team is going to switch languages, we would need to be able to convert existing code over without much pain and we would have to find enough value in switching that it would be worth the conversion. I had read an article that stated that because TypeScript is a SuperSet of JavaScript, you could convert a plain JavaScript file to TypeScript by changing the extension to .ts and not much else would need to change. I wanted to test out this claim, so I took a file that I was familiar with, an Angular Controller, and tried to convert it to TypeScript to see how much effort it would take and then try to figure out where we would benefit from using TypeScript. This is what the controller JavaScript file looked like to start out with: ( function () { 'use strict' ; angular .module( 'app'

Nebraska Code 2015

A year ago I started this blog after Nebraska Code Camp with a review of the sessions I attended. I want to just highlight the sessions I went to this year that I thought were good. This year I felt like I gained the most out of the sessions that were not targeted toward a specific language or tool, but rather the ones that would help me be a better person and become a better developer in general. I have been listening to the .NET Rocks podcast for a few years now, so I was really excited to get to see Carl and Richard record an episode live. It was a lot of fun as well as educational to watch them work and see how they put together a show. The guys were smart and funny, they clearly have great chemistry and can seamlessly flow in any direction the conversation takes them. I attended a session titled, "How to Learn: Grok it Faster". I really enjoyed this session. The speaker was Thuy Copeland , she did a really good job with her entire presentation. She recommended the

How is your team staying DRY

DRY (Don't Repeat Yourself) is one of the basic fundamentals that developers are taught. If you find repeated code throughout your project you should move that code it into a method that can be the one spot that that code will exist. This reduces complexity and reduces the likelihood of bugs because the code is only in one place. When I am presented with a new problem, I almost always immediately think of how I would solve that problem. What can I do, starting from scratch to solving the issue? DRY should also apply to new code that you write, others have likely solved the problem you face, perhaps even with your team. Many times the problem has already been solved or a pattern has been established that will assist in solving the problem.  If you can use an existing piece of code you will save time and effort completing your task and be able to spend more time and effort on something else. To keep myself and my team as efficient as possible, I need to first find out if someo