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.
Dave's Notebook
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.
How to Avoid Binding to Computed Values in Angular
In my previous article about Angular Performance, I indicated that one of the many ways you can produce an Angular application that performs well is by ensuring that you bind to a computed value.
First, what did I mean by that?
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.
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.
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.
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.
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?”
LinkedIn Tips For Programmers
As I was sharing my LinkedIn tips with a co-worker this past week that made me realize that I’ve accumulated an incredible amount of knowledge about using LinkedIn that I should probably share. Things that aren’t obvious to the typical user.
But first, I have to ask a question.
TypeScript Basics for Angular Developers
For the most part, TypeScript feels a lot like JavaScript. Most people pick it up without having any formal training.
But, here’s the deal. “Just because you can, doesn’t mean you should.”
The thing that makes me most nervous about Angular is that it is structured so that you can write some really clean code. But, you don’t have to. Which mean most won’t.
In fact, recruiters continue to contact me about Angular jobs with rates that make it obvious that hiring an Angular programmer is the same as hiring an HTML “programmer” 10 years ago. Sorry gang, JavaScript has grown up and so has Angular.
So, here are a few things you need to know about TypeScript that will make you a better Angular developer. 