The 2007 Honda Civic sedan is a beautiful car especially when you compare the car to its competition like the Mazda 3, Toyota Corolla, and Nissan Sentra. Compared to past Civic generations the progressive design of the 8th generation Honda Civic feels like it’s on a different class of cars – liberal, contemporary, and sophisticated. The two-tier dashboard felt like I was in a spaceship and with the big tachometer smacked right in the middle of your dashboard you’re either checking whether you’re at the optimum RPM to have the best miles per gallon or when you’re about to hit VTEC to get the best smiles per gallon.

I’ve driven this car all the way to Canada, California, Nevada, and Illinois from Colorado with no problems, all I had to do was make sure that I have my passport for the Canada road trip and that I have enough money to fill up and buy food along the way.

Cost of Ownership

I can keep praising the car as much as I want but I’m sure you would also like to know how much does it cost to maintain this car? Provided you are a decent driver and you actually take care of your cars.

I’ll break it down into two parts — regular maintenance which includes oil changes, tire rotations, wiper blade replacements, etc and the more expensive type of maintenance which includes new tires, new engine parts, etc.

Regular Maintenance

When it comes to regular maintenance, the car has cost me on average less than $50 per visit. Now mind you, I drive this car close to 9,000 miles a year. Not a lot compared to other commuters so my car maintenance schedule is a bit on the low-end of the spectrum — if there is nothing wrong with the car, I go twice a year for a total of $100.

Current Total Cost: $100 ($9/month)

Miscellaneous Maintenance

For over 10 years that I have owned this car, I had a total of five maintenance that will fall under “miscellaneous”.

• Tires: $700+
• Engine (VTEC related): $800+
• Wheel Bearing: $450+
• Brake Pads: $250+
• Oil Leak: $120+
• A/C Compressor: $800+
• Battery: $150+
• Tint: $170+
• Windshield: $350+

The total cost of all these miscellaneous maintenances that I had come close to $3800. You might think that it is starting to get expensive but you have to remember that these types of maintenance do not happen every year. In fact, if you average it out over the years that I have owned the car (10 years), it equates to roughly $380 a year.

Which brings us to an annual cost of $480 — $100 for regular maintenance and $380 for miscellaneous maintenance per year.

Current Total Cost: $480 ($40/month)

Gas and Miles per Gallon

I started tracking how much I spend on gas and how far can I go with it a couple of years ago. So far I am averaging $25 per fuel-up and driving close to 30 miles per gallon.

This occurs close to twice a month, so it’s safe to say that I need $50 every month for my gas which is $600 per year.

Current Total Cost: $1,080 ($90/month)

Does it still look like a lot? Let’s break it down even further. $1080 per year is roughly $90 per month!

The cost of having an extremely reliable car like the 2007 Honda Civic that will take you anywhere close to 600 miles at any given month cost less than two typical A+ Steam games ($49.99 each).

Most of these are pet peeves of mine where I start thinking–Why can’t they just <…>?!

Open your component’s top level class to extension.

This was one of the most requested features by our consumers when it came to overriding the styles for our components.

❌Before

The example above limits consumers to overriding the current classes being used by “MyComponent” and it makes the noise level quite high if you’re using CSS modules.

✔️After

We’ve added the classnames package to help us manage the external and internal classes a lot easier. Now the consumer can use their own class names if they want to override the styles.

Allow your consumers to pass in additional props to your top level component.

Let’s take into account our last component after adding the feature where consumers can use their own class names. This time, we’ve also added the feature where the consumer can set a custom greeting.

❌Before

Now let’s say the consumer wants to add an additional prop that was not specified, like a data-testid prop to enable tests to have a hook to MyComponent?

✔️After

By making sure that you are accepting other props through otherProps and spreading them at the top level element, you are ensuring that whatever the consumer wants to add will be added to the top level element. Since we have already taken out className through destructuring, we do not need to worry about the consumer not being able to take advantage of classnames.

Let your consumers customize the React components that you are using.

The examples that I’ve provided have mostly been simple components so let’s add some more complexity by using other components.

❌Before

We now have a Greeting component that consumes greeting as part of its message.

What if Greeting has other props like the colour of the message through color? You can’t use color anymore since it’s being used by Header. Now you have a collision that you want to avoid. You either rename color to headerColor and add greetingColor to solve the issue or stay with color and have greetingColor. You will continue to have this problems as your components get more complex.

Our first solution was to name space component props.

❌First Iteration

We could already see the problem when we want to scale this solution because if we want to use more props from either Header or Greeting then we have to modify MyComponent every single time — annoying especially when Header and Greeting also have their own Prop Types.

Our goal was to have the ability to extend but not necessarily modify the source code for MyComponent.

✔️Latest Solution

Here’s a list of advantages with this type of pattern that we really ❤️.

• If Header and Greeting are updated and you want to use them in MyComponent there is no need to update the implementation of MyComponent. The term we used was it just works.
• Since this is a pattern that we will be using on our components then it is safe to assume that both Header and Greeting can also be extended the same way as MyComponent.

Here is what it looks like on the consumer’s side.

Let me know what you think and if you’re using this pattern, let me know as well! Maybe tweet me @rodoabad!

It’s late at night, I’m writing a couple of tools for my personal project to help me compute for adjusted dividend amounts based on the amount of applicable splits that happened for that stock option.

Here’s what I came up with.

We’ll start withadjustDividendAmountForSplits because that’s our entry point. I’ll give you a couple of minutes to digest what’s happening and let you ponder on the screw up. Just remember though, this code passes the tests that I’ve written. However, you should always remember that one of the things I do is — refactor relentlessly.

Still not seeing it? Maybe this will help.

Now you’re seeing it and if you’re not here’s the screw up.

Look at applySplitsRatiosToMatchingDividendAmount and you’ll notice that this function is dependent on BigNumber, a Math library for JS. No problem right? We just do import BigNumber from 'bignumber.js' and it should fix it. While true, that’s not what I wanted to show you. If you notice, the dividendAmount parameter has to be wrapped with BigNumber since it will be the first index in our accumulator. And that my friends is the problem because now we are expecting that the dividendAmount that will be passed as the argument to be always wrapped with BigNumber or else our function does not work [because we’re using the multipliedBy method available only to numbers wrapped in BigNumber]. You’ll also notice that I did exactly that in adjustDividendAmountForSplits where I am wrapping dividend.amount with BigNumber.

Let’s fix that.

Now applySplitRatiosToMatchingDividendAmount can take in a normal number for dividendAmount, all the BigNumber magic happens inside the function and not outside of it. Perfection.

We’ve also cleaned up adjustDividendAmountForSplits so that the only time BigNumber happens is when we’re adjusting the decimal places. Other than that, we’ll always be returning a number [hence toNumber()] and not an instance of BigNumber so that our functions are highly reusable.

Now I can sleep. Goodnight!

As a software engineer, we write a lot of tests every single day — it’s one of the many ways we protect what we ship from ourselves and from other engineers.

The more tests we write and encounter the more Magic we see happening in these tests. Sometimes we’ll ask ourselves— what just happened in this test? Magic occurs when we’re reading a spec and suddenly we have no idea where it got a specific value or something — tl;dr things just happened in that test’s scope.

Say no to Magic boilerplate.

Here are the following requirements — if you’re not using these tools then you will probably have a different pattern but most of the time they are the same.

• Mocha (testing framework)
• Code (assertion library)
• Enzyme (testing utility for React)

Let’s assume for a second that this was the component that we’ve written tests for…

Judging from the code it’s a component that displays the taxable income and it has a label and value and the value is displayed in US dollars. In order for this component to render properly, a taxableIncome prop of type number is required.

What does our test look like?

It all started out with us writing a test for the section. Why? Because that’s the first thing we need, then the test for the label and eventually the value being displayed. BDD done!

Let’s focus particularly on line’s 40 to 49 real quick. We can see that we’ve repetitively called props() 4 times. What a waste of time and effort because all we really want to know is — in order to display the taxable income we need the following to be true.

1. It is FormattedNumber component and this component is a children of the current component that we’re rendering.
2. We should be using the following props in order for us to get the rendered HTML we want.

Instead of expecting 4 times, why not expect it once and be done with it? In order for requirement #2 to happen, all these props have to be there all at once. In short we should be testing them as a group.

Behold our first refactor iteration!

One expect to solve our problem! We can do this because Enzyme’s props() method returns an object. We can then do a deep comparison with our expectedTaxableIncomeProps [Yay naming convention!] If you’re not seeing .deep.equal it’s because we’re using version 3.x of code which automatically does a deep comparison.

Still not happy with this result.

You’re probably asking yourself (and me), well Rodo where the hell does mockProps come from anyway? How did it find its way in our atomic test? [Magic!]

With mocha we typically use beforeEach() to set things up to run before each test. I personally used to be a fan of these helper methods but they are often abused in a larger code base with multiple contributors and it can become cumbersome to maintain let alone look up if you’re wondering where stuff came from.

Let’s get rid of that magic and make sure that the next person who looks at this piece of art knows exactly what is going on and we’ll save them the time to find out where things are coming from.

Here is our old test setup with beforeEach().

And here is the new one.

Let’s break this down real quick.

Instead of just assigning values to component and mockProps we wrote two methods that we can call to generate the required props with requiredProps() and to render the component with render().

Why requiredProps()? We call it required props because this is the props that is required for our component to work — this is our bare minimum.

Do we override our required props? No we don’t. We do however pass a new props argument in render() if we want new props. In fact we should not even care about the values being returned when calling requiredProps() because they are simply there to make it work. They are not there for asserting if the prop value is properly being set.

How does our test look like now?

Boom shakalaka! Let’s go over this refactored test in detail so we know what is going on in our atomic test.

We now have a prop object that has our requiredProps() and the taxableIncome value that we are expecting for our test. Oh but Rodo! requiredProps() also returns a taxableIncome value that you can expect later! Y U MEK 1MORE?! The answer is pretty simple, for this test, we want to make sure that the taxableIncome value that we’re generating originated from this test and not some random method. Remember what we said about requiredProps() values not being used for assertion? It’s for real, dawg. It really is there so that you do not get any prop warnings.

We then render()the component and pass the props we’ve declared at line 3. Just like what we mentioned in #1, we want to make sure that for this test the props that we’re sending are originating from this test alone.

And that’s it! We reduced the amount of expectations and our test is a lot more concise now.

Final gist for you folks!

Before this all started I was earning $0 per month, now I am earning at least $6 per month! $6 might not seem like a lot in today’s money but for me that is a free movie night or a meal from a decent restaurant — I can do one of those each month without taking money from my income stream!

The best part of this is that it can only go up from here as I continue to put in money into this dividend growth taxable account per month. Since I won’t be taking any money from this account, that $6 per month will be used to buy even more stocks!

I am currently putting in around $500 per month in this account and from the looks of it, $500 earns me around $1.50 per month or around $4.50 per quarter. So, if I continue doing this then I will be going into double digits by the end of this year!

And to make things even better, I do believe that I will be earning money every month now since that was one of my early goals — to earn money each month instead of every quarter. Which is why I bought stocks that will not overlap one another (at least in the early days of this account). This makes it a joy to track so if you’re just starting out I recommend that you do this! It might not be ideal when it comes to maximizing profits but once you’re getting money each month the happier you’ll be!

One thing I’d like to add is that since I am using Robinhood for this account, I don’t have to pay any commission fees! One disadvantage though is that I cannot DRIP and I can only buy a full stock instead of a partial one. I don’t see that as a problem though because as I put in more money the income from the dividends will keep increasing until I can buy one or more stocks in the future! I would also like to invest my earnings in a different stock each time. Hooray for diversified portfolios!

Everyone has to start somewhere right? To me that would mean that I will be setting aside a minimum of $500 per month from my take home salary and invest it on dividend growth stocks.

I plan on using a taxable account for this investing experiment and I will re-invest all the dividend income that I get back into this taxable account. Moreover, since I will most likely have at least one transaction per month I will be using Robinhood as my broker to save on transaction fees.

What about my 401K, IRA, and other investment accounts?

Full disclosure here, I am already maxing my 401K and IRA accounts however, even though these and my other taxable investment accounts are earning dividends I will not include them since I consider these accounts as my over 65 years old retirement accounts so these accounts are automatically off-limits when concluding if I have reached FI (Financial Independence) or not. For this experiment we will only focus on one taxable account — the dividend growth stocks account to which I will be contributing a minimum of $500 per month.

This is going to be excruciatingly slow at the start but I am prepared to deal with it mentally and financially.

There is not going to be any magic of some sort happening here where suddenly I will be earning more than what I am spending in a few years. Believe me folks when I say that this is going to be a painful grind for me at the start. But since I have the power of compounding interest involved, I will be able to document what is going on and share my experiences with you guys.

Ever since I got behind the steering wheel of an automobile I’ve always enjoyed the drive and experience. I remember sitting on my father’s lap as he drove around the small streets of Manila and I will try and take control of the steering wheel — I was around two years old. Fast forward thirty-some years later and I still enjoy driving. I can drive for long periods of time and I will never get tired or bored regardless of what kind of automobile I drive. The longest one that I’ve done is from driving from Colorado to Toronto and back.

To me it’s not about the car that I’m driving but more about the journey itself. I’ve driven cars that are as old as me and I still enjoyed it— I don’t care as long as I get to drive. That’s all that matters.

I am now in my mid-thirties — well -paying job, homeowner, paid-off car, maxed-out retirement plans, investor, and currently still saving money.

Life is good but not without major sacrifices.

There’s nothing inherently wrong with what I did, it’s just that when I think about it I’ve never really rewarded myself with all that hard work. Sure I’ve made some huge purchases like a house and a normal car but those are in my humble opinion necessities — things that I need, not want.

I’ve been slaving myself away since my early twenties trying to save as much money as I can. My life back then literally was wake up, work, and sleep. It was a boring life.

And lately, I’ve been thinking that maybe it’s finally time to reward myself before I settle down with my life — be a husband and a father.

I want to buy a car with a true motorsport pedigree.

A car that not only can take me from point A to point B but also a car that will put a smile on my face every time I drive it. That’s why I’m taking delivery of the new 2017 BMW M2 this year, a car that I bought as a gift for myself.

Having an actions list is an important part of reducing the boilerplate needed in Redux. It helps keep your naming convention consistent since all the actions are located in one place. Something very important when you have a lot of collaborators working on a large project.

So let’s assume that your Redux-enhanced application already has a list of actions and each action already has a test for it.

Why are these tests important? It’s because you want to make sure that when you use CREATE_TODO that the action that you see logged is also called CREATE_TODO and not something else. You don’t want to be calling UPDATE_TODO and then have it appear as DELETE_TODO in your logger. Right? Exactly.

However, this can get very repetitive. And you can probably see where I’m going with this especially after line 12. If you need 100 actions, then you’ll need to write 100 tests. One for each action that you add.

So let’s take a step back and ask ourselves what do we really want to test…

• Is our action list immutable?
• Does each action have the same key and value?

Time to refactor our test

When we refactor our test we want to make sure that it still tests the behaviours that we want.

Our first refactor session is us removing the copy/paste behaviour to reduce test boilerplate and reduce the risk of forgetting to update the test description.

This happens a lot when you forget to take a double take on your tests.

By iterating over the actionsToTest array, we can also use it for writing our test descriptions through JavaScript template literals. Now each test description is correct.

So far so good then. But what if we have someone else add an action without writing a test first?

If we stick to our first refactor, then this test will still pass. So how do we prevent people from adding a new action first without testing it? Or at least making sure that each action added is tested?

The second refactor session is us removing the use of forEach and instead use a deep compare of the array against the object.

Now you have a guard against untested actions. But this is also a problem in itself because of this possible error.

Since we’re comparing the object values of actions against the object values of actionsToTest then as long as they look the same the test will pass.

So how do we fix this? By testing the object keys from actions against the object values of actionsToTest.

One thing to note though is that this is possible with the help of another tool — ESLint’s plugin eslint-plugin-sorting which lets you sort your object properties alphabetically.

Not only do you have a unit test that will test the following.

• Is your action list immutable?
• Does each action have the same key and value?
• Is each action tested?

But you also have a unit test that scales.

Let’s assume we already have a TDD’d method called getFruits and it calls fetch to that will then respond with a collection (array) of fruits.

The corresponding unit test for this looks like this.

Before we begin refactoring our unit test, let’s have a quick breakdown explaining why the fruits repository is being tested this way. You might also notice that I am using the BDD Given-When-Then concept of writing test descriptions. This helps organize our test and makes it a lot easier to grok.

We import four modules in our unit test file.

We want to stub fetch with sinon because it is an external asynchronous call. We do this by stubbing the fetch method in the global object.

We will not stub fruits-repository because it is the System Under Test (SUT).

Never stub the system that you are testing. Ever.

You never stub the system that you are testing because by stubbing it you are then modifying the behaviour of the system that you want to test. By modifying the behaviour of your SUT, you are no longer able to test its actual behaviour which is the primary reason why you are writing a unit test anyway.

Before each test starts we will sandbox sinon stubs so that each stub that’s going to be used inside a test will be isolated. We then restore it to its original functionality after each test.

Our first test is all about verifying that we actually call the fetch service every time we call getFruits.

Given the fruits repository. When getting a collection of fruits. It should call fetch.

Now that we’ve verified that we actually call fetch every time we try to get a collection of fruits, it’s time to find out if we get the data when the call is successful.

Since we’ve stubbed fetch we need to stub some of the methods that we need inside of it like json. By definition it returns a promise that resolves with an object literal containing the JSON data.

We also need to make sure that our resolving our promise will never run our catch clause. So we add a failing test where we check that false is equal to true.

Given the fruits repository. When getting a collection of fruits and is successful. It should return an array of fruits.

Now that we know that we’re getting the right data. We need to find out if we’re going to get the right error message when getting a collection of fruits is unsuccessful.

Just like our successful test, we need to make sure that rejecting the promise does not run the then clause.

Given the fruits repository. When getting a collection of fruits and is unsuccessful. It should return an error object.

tl;dr

• Test if fetch is called with exactly the right arguments
• Test the happy path — when service is successful
• Test the sad path — when service is unsuccessful

It’s now time to refactor our source file and its corresponding unit test.

We already have Promise why do we need async/await?

async/await lets you feel like you’re writing synchronous code while still writing asynchronous code. For simple queries a Promise is easy to understand. However, as soon as requirements start getting more complex, having a synchronous feel greatly reduces complexity.

Now that we’re using async/await we can go back to using try/catch/finally which makes it feel like synchronous code.

Just like the source file we will refactor our unit test.

Since can now use finally you will notice that our first test is now a lot easier to understand. The finally clause executes after the try and catch clauses execute. This is exactly what you need because regardless if your promise resolves or not, you want to know if fetch is called once and with exactly the right arguments.

The same goes for our successful test expect instead of finally we’ll make sure that our catch clause never runs. And if it does, we should get alerted by a failing test.

As far as our unsuccessful test is concerned the try clause will always execute so there is no need to have an expected failing test.

And there you have it. You’ve refactored your asynchronous code to use async/await.

Let’s assume that the data we’re getting from an API has the following structure — a list of employees that contain their first and last names.

Since we’re using tcomb, our data structure for this would be something like.

However, we want to display these employees in a HTML list that contains checkboxes — each employee can be selected. So now we have to track if either an employee is selected or not.

The problem that we now have is that an Employee does not have a selected property that says whether the employee has been selected or not.

So why not just add a selected attribute to your Employee structure? Well, we can’t. That’s because the struct combinator drops additional properties when we add them.

So how do we add additional properties without mutating the original data structure for an employee?

All struct constructors can be extended using the extend function. By using the extend function, we can now add an additional property to our employee.

Here’s a working example of it.

So not only did we avoid mutating our original data structure for Employee but we’re also able to solve our problem of not having a property to track if an employee has been selected or not.

Now what if we need to send back a list of selected employees?

Sending back a data structure that is quite different from what you received should always be avoided. We want the back-end services to know exactly what type of structure they’re about to receive. Everything else should be discarded.

tcomb makes it easy to transform your data back to it’s original form. Since we know that passing unknown properties get discarded when using struct. All we have to do is use the Employee struct and pass extendedEmployee as the argument. By doing so, the Employee struct will discard all the extra properties that we’ve added in ExtendedEmployee.

If you prefer to see some animation…

Now you can send your list of employees back to your back-end without having to worry that you’ve changed the data structure.