Dave's Notebook

Every Programming Issue Solved

As I’ve considered all the issues I’ve seen over the years and, as I’ve talked with and interviewed with other developers, I’ve come to the conclusion that our industry has two main problems. Fix these and all the other issues we face will solve themselves.

Read More

Rethinking Action Names (Redux/NgRX)

If you’ve been using some form of Redux, you are familiar with the basic flow of data through the Redux loop. Central to this flow are Actions, the messages that trigger code in our Reducer or Effect/Epic/Saga (depending on what flavor of Redux you are using).

The model allows us to disconnect our code so that it only cares that an action was triggered in some way. That is, “when this action occurs, I will run this code.”

Because of this, we can create an action that triggers multiple code blocks to run. Our only concern is that the code that gets triggered can’t depend on each other.

In fact, much of the official literature encourages this practice.

And, this is where all our troubles begin.

Read More

rxjs-conditional-logic

The temptation, when using RxJS is to include conditional logic inside your map, tap, or subscribe blocks. But there is a much better way to deal with conditional logic that will make your code much easier to read and reason about. It also should make your code easier to test. But of course, once you have code that is easy to test, you probably no longer need to test it.

Read More

Fixing Single Responsibility

The Single Responsibility principle is a well-known, Object Oriented principle that states that we should narrow the scope of the code in our Module/Class/Function so that is it only responsible for one thing.

By doing so, this reduces the size of our code that needs to be tested.

Linting rules can generally help enforce this rule by making sure your Class file isn’t too long, and your functions are not too complex. But there are other ways of violating this principle that linting rules can not pick up.

Read More

Optimizing Angular For Speed

I was recently asked how I would optimize an Angular site for speed. Interestingly, I’ve never written about this explicitly even though I’ve actually done quite a bit of work related to this issue.

For the purposes of this article, I’m going to assume you have already implemented most of the things that Angular gives you “for free.” For example, we won’t talk about “Tree Shaking”, that’s a given.

So, I give you my 30 or so tips on how to optimize an Angular application for speed.

Read More

You Aren’t Doing Scrum If…

You Aren't Doing Scrum If...I’ve been frustrated lately by the flippant use of the words “Scrum” and “Agile” in our industry.

Actually, I’m STILL frustrated. I originally wrote this article January 2015. Not only is it still true. It is more true.

Our industry has been treating Scrum and Agile as “buzzwords that mean nothing.” These words get slapped onto job requirements like the typical requirements we’ve all seen.

  • Must be able to communicate
  • Must be able to work in a team environment
  • Must be able to work under pressure
  • Must be able to work in an Agile environment

What’s really funny is when I see

  • Meet tight deadline
  • Expert in Agile

together in the same job request.

And even if it doesn’t show up in the job description. Once you get into the organization, you find out they are no different than any other organization. All those promises about running “Agile” or “Scrum” as a well of figuring out how long a project will take fly right out the window as soon as a manager wants something done by a specific date.

If management ain’t Agile, ain’t no one Agile.

Read More

An Angular Application Architecture That Works

The purpose of this article is to specify a working architecture that everyone can use for any Angular applications. This architecture aims to achieve the following goals:

  • Ensure that all parts of an application have a home so that anyone can pick up any application that uses this architecture and modify the application without having to learn where everything lives.
  • Reduce the overall complexity of any one application by using well-established design patterns that work within the Angular ecosystem.
  • Reduce the number of bugs introduced into an application by reducing the need for duplicate code.

Read More

What If Unit Testing Wasn’t Necessary? #noTDD

I recently read (yet another) post proposing that TDD “doesn’t work” and that we shouldn’t use it, or should use it very little. What was shocking about this article wasn’t the content, but the fact that it is hosted on a Microsoft site.

While I’m not entirely on board with throwing out TDD, the one thing I will agree to is that learning TDD is difficult. I am also willing to admit that, to a large extent, TDD is broken. If you’ve been following my post for a while, this SHOULD be shocking news.

And so, I’ve been thinking.

Maybe we’ve been asking the wrong question. Maybe, instead of asking “How do we encourage people to implement TDD?” We should be asking, “How do we make TDD either unnecessary, or trivial to implement?”

Photo credit: abraham.williams via VisualHunt.com / CC BY-SA

Read More