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?
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?
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.
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.
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.
What’s really funny is when I see
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.
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:
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?”
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.
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.
Emotions are a weird element of being human. They can propel us forward or hold us back. Sometimes they are violent. Most of the time they whisper.
Several events have occurred recently that have me thinking about this more.
To start with, I’ve started paying more attention to my health. There were a lot of things holding me back from this in the past. It turns out, most of what was holding me back was just a lie.
I’ve started interviewing again. The nature of what I do means I get to do this a lot. You’d think I’d get used to it. But, I don’t like the interview process. I don’t like changing jobs. I really don’t like code interviews. But, I do them because I like to program for a living.
And for those of you who know me, just because I’m interviewing doesn’t mean I don’t like where I am and have any intention of leaving. I interview when I have work so I still have the skill when I don’t have work. And who knows? I may just find something I like better than where I am.
Some of the interviews I’ve been on have revealed that managers think in similar short-term ways that I have. Short-term thinking is so easy to see when it is someone else.
Because this is a frequent problem, because it is so often done incorrectly and because there is a great alternative, today I want to discuss where to store Angular configurations. You know, all that information that changes as you move from your local development environment to the Development, QA and Production servers?
There’s a place for that!