Lessons Learned: Introducing Classes to a Web API

On a project of mine, I started off returning a C# object from a Web API that only had properties like string or int in it. I wanted it to be as small as possible and only return data that was necessary. Unfortunately, as the application continued to be built my team and I realized that we had similar data that needed to be returned in different api’s. For example, we had address data in multiple api’s.

This wasn’t an issue at first until the devs had different names for the same properties. This affected our front end as well when we discovered a bug. A dropdown was empty. So I fixed it by renaming the variable it was looking for. Then I wondered why it broke in the first place. It was an Angular directive that was used in multiple places, but I know it worked when I implemented it. The TFS history showed that another dev changed the variable name it was looking for.

After a quick chat we realized that we needed to create a standardized naming convention for the variable that ran through the application all the way to the C# class. As we stopped and looked at the application we could see that this needed to be done in multiple places. Some of the features were already complete so we couldn’t change them because the deadline was too tight. I decided to create an address object that we could all use. So I added it to my api and I was all set to go. But that did not solve the problem of the other api’s that could have used that class.

I added it to an existing api that I needed to call for a new feature. Instead of rewriting the api and the old feature to use the new class, I just added it to the bottom of the properties in the return object. I did not know if that was a good idea, but I created TFS work items for the future so we could go back and do it the new way.

Then a new project with an even tighter deadline came up that needed those api’s. A new developer for that project asked me which address to use. The one in the address object or the properties. My answer and story for what to do and how it happened did not please him. The look on his face said everything. My idea failed.

Lessons learned:

Looking back I could have done a few things better. I could have versioned the api to a new that only had the address object and slowly move the rest of the app to use that api. Future developers could see it was the latest version and use that instead without confusion.

I could have looked at the whole project before we started and see that the address object was going to be used in multiple places. I could have then created the address object ahead of time preventing this from happening.

I hope my experience and lessons learned can help others build better software.

Prototype Pattern vs. Revealing Prototype Pattern Memory Benchmark

Last week I benchmarked the Prototype Pattern and the Module Pattern in this post. This week I will add the Revealing Prototype Pattern to the list of benchmarks.

The Revealing Prototype Pattern is a hybrid of the Prototype Pattern and the Module Pattern. It is supposed to be the best of both worlds. The module will have private variables and functions and will only expose a public API while still conserving memory.

As you will see the memory used is very close to the Prototype Pattern. If the style of code you write uses the Prototype Pattern then switching to the Revealing Prototype Pattern will give you the benefits of private variables and functions with minimal memory cost.

Listed below are the benchmarks and code.

Table of Results:

Objects Created	Prototype Pattern Memory (MB)	Module Pattern Memory (MB)	Revealing Prototype Pattern Memory (MB)
1	0.001832	0.002624	0.001832
5	0.003224	0.004232	0.003296
10	0.003552	0.005552	0.003624
100	0.009320	0.031480	0.009392
1000	0.079240	0.294816	0.079400
10000	0.298288	2.378696	0.298544

Prototype Pattern vs. Module Pattern Memory Benchmark

I watched Jonathan Mills Pluralsight course Practical Design Patterns in JavaScript, which is about a few of the Gang of Four design patterns. His demo on the memory usage of the Flyweight Pattern inspired me to benchmark the memory usage of the Prototype Pattern in contrast to the Module Pattern.

One of the pro’s of the Prototype Pattern is to reduce memory because functions are on the object’s prototype. When new objects are created then memory is conserved because the new object’s functions all point to the parent object. In contrast, the Module Pattern creates new objects and functions. There are other pro’s and con’s to using each pattern, but I would like to only focus on the memory usage of each pattern.

Taking Jonathan's snippet of code that measures memory, I repurposed it to measure the Prototype and Module Pattern. I have included the code that I used to measure memory as well as a table of the results of a few test runs.

I hope this benchmark can help you decide when to use each pattern.

Table of Results:

Objects Created	Prototype Pattern Memory (MB)	Module Pattern Memory (MB)
1	0.001832	0.002624
5	0.003224	0.004232
10	0.003552	0.005552
100	0.00932	0.03148
1000	0.07924	0.294816
10000	0.298288	2.378696

How to use Code Katas in Deliberate Learning

I recently watched Dan North's video on Deliberate Learning vs. Deliberate Practice and I wholeheartedly believe in almost everything he said. I do believe that we should really know how to learn as efficiently as possible, which is different for each person. I also believe that we should go to meetups, listen to podcasts and various other methods of quickly learning what the trends are and what the new tech is at a shallow level. Then we can prioritize what we want to dig deeper into and learn more about.

What I did not fully agree with is that code katas were not the way to achieve deliberate learning. (https://youtu.be/SPj-23z-hQA?t=362) On their own katas and the metaphor may not be the right thing we need, but if you take the coding challenge tool itself and apply it in a different way then the kata will be more effective.

For example, the JavaScript group I am apart of at Sogeti has started a weekly coding challenge based on CodeWars katas. While I agree that development is not about writing the same code faster, it is about writing more maintainable, performant, SOLID, and clean code. The first time I write code to solve a problem will probably not be the best solution. I can then look over my code and compare it to other solutions and see if I can use built in functions, break out functions into smaller functions that make more sense, or use recursion.

I am currently learning about JavaScript arrays and the built in functions. As I complete these challenges I am going back and looking for places where I can use these built in functions. Instead of writing loops I can just use what is available. I’m learning to use what is in the language instead of reinventing the wheel. This can also be done when learning the new features of ES6.

I have also started a brown bag meeting to discuss our solutions as a group the day after a coding challenge is finished. At this point, we become the sensei and teach other what could have been done in a more efficient way or if a function or variable could have been written in a more readable manner. This code review is where the real value lies in doing code katas.

Dan North mentioned “Learn Python the Hard Way”, which is a series of exercises that force you to code and learn the python language. This is very much the same style of learning that I want to achieve except that I would like developers to redo the same exercise with a new way that they just learned. This would cement the new way in their mind.

Next time I start a new project and I have to write code that is similar to something I wrote, I will now be confident that I am aware of different ways of writing that code. I will also be confident that it is more readable, maintainable, and performant.

React on Node Learning Plan

I have put together a learning plan template to help me focus. In tech I believe that how effective I am at learning and then quickly implementing that knowledge is what I am being paid to do. Below is the first plan I have together to begin testing if a learning plan is worth while.

Question			Answer
What specific skills do you want to work on?			I want to learn React on Node
Why do you really want to learn a new skill?			I think React is a better framework than Angular
Assess current skill level			Novice
Research the skill and related topics.			JP said to read the react book
Set a clear goal about what you’re planning to learn.
	Specific:		I want to be proficient at building React web sites on Node.js
	Measurable:		I can build one website based on a tutorial using React/Redux/Express/Node
	Achievable:		One React website based on Pluralsight tutorial
	Relevant:		Because it is a framework that I believe is a long standing good framework
	Timely:		In one week
What mini goals/milestones do you want to set for yourself?			30 min a day of the course
How do you want to learn?			Pluralsight
Set specific concrete tasks for yourself to accomplish every day.			30 min a day of the course
What is smallest action you can take to start learning			Start the course
What is the 20% you can study that results in 80% of skill gain			The Pluralsight course will give me a broad view of React on Node
What is the foundational concept that all other concepts rely on			unknown. JS
Who is your learning accountability partner or online study group.			I will ask Crouch and JP to keep me accountable
How will explain the concepts you learned			I will post it on my blog and in the JS slack
Where will this go in your portfolio.			GitHub
Imagine the opposite of what you want.			I spend all this time on the course, but I don't learn react
What are the expectations practitioners have set.			JP said to read book
Make and test predictions.			unknown

JavaScript Garbage Collection

When I was reading about closures in JavaScript I became curious about how garbage collection worked. Why do closures have variables that stick around. At first I thought it might be by reference, but I did some research and learned that garbage collection occurs when an object is unreachable which is not the same as an object is not referenced. In the previous algorithm, reference counting, cycles were a problem. Circular references would lead to memory leaks.

function f(){
    var o = {};
    var o2 = {};
    o.a = o2; // o references
    o2 o2.a = o; // o2 references o
    return "azerty";
}
 f();

The mark and sweep algorithm solves this issue. Quote “In the first above example, after the function call returns, the 2 objects are not referenced anymore by something reachable from the global object.” At that point they are garbage collected.

Reference: Memory Management

JavaScript Safer 'this' in depth look

I am currently reading Kyle Simpson's series You Don't Know JavaScript (YDKJS) and I am learning a lot about JavaScript. I have been writing his code examples and other JavaScript blog code examples in my plunker. I decided to code out his warning for using a safer this.

Kyle mentioned that null could mutate or reference the global object in a function that makes a 'this' reference in either your own code or in a third party library.

The empty object literal {} still has __proto__ since it inherited from 'Object'.

If you use a third party library or you have code that checks for properties on 'this' then you could have a difficult bug.

Object.create(null) truly is more empty than {}. It has no properties which makes it the safer 'this' option.