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.
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. Photo credit: whinmobzappmedia via VisualHunt / CC BY
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?
When NgRX 4 came out and I discovered that the “right” way of creating Actions is to use TypeScript classes and not Object Literals, I was a bit surprised. Why would you use a Class that requires you to use the “new” keyword? Why would you put multiple classes in one file? This is insane! Photo credit: dkobras / CC BY-SA
Unless you are a CSS wizard, you are probably using one of two CSS frameworks for your Angular projects or some sort of adaptation of them. Bootstrap or Angular Material. These have served us well, but they have one major flaw. They target the “Mobile First” method of design. This is great if your application must work on a mobile device. But most corporate web applications target web applications.
Have you ever heard any of these objections from your end users?
Why is everything so big?
Why can’t I have the label NEXT to the input field?
And then you explain, it is so the screen can run on a mobile device and you hear, “But, this application will never run on a mobile device!” Which is a valid point.
Therefore, I was so excited to hear that VMWare has finally taken up the challenge of creating a Desktop First CSS Framework called Clarity.
Photo credit: [Sean Hering Photography](//visualhunt.com/author/2edd3b) on [Visual Hunt](//visualhunt.com/re/764a8a) / [ CC BY](//creativecommons.org/licenses/by/2.0/)
Once upon a time, there were Full Stack Developers, but as time progressed, they disappeared. Now, all we have are impostors. People trying to be full stack, but failing. The Full Stack Developer is now as obsolete as a unicorn.
Back when I started programming, you could get by only knowing one language and a couple of supporting “languages”.
My story is similar to many from my generation. I learned a little Basic to catch the programming bug. Then I tried Pascal and moved on to C before I went back to school where I learned COBOL, JCL and CICS. Mostly it was COBOL.
It didn’t take long to learn any of those languages because the language was the language. Things didn’t move quickly. CICS was simple. And we only needed enough JCL to get our programs to compile. Photo credit: Avariel Falcon on Visual hunt / CC BY
I’ve been programming now for 30 years. Over those thirty years, and more so over the last five to ten years, I’ve become increasingly frustrated by the attitude of managers and programmers alike toward programming.
One programmer I know is pretty vocal about this attitude. All he seems to care about is how fast he can write the code. “I got that application done in a month!” And then he’ll complain about how it is everyone else’s fault that he spent the next four months fixing bugs.
And it is no wonder he has this attitude. Most of the managers I’ve worked for will acknowledge that there is a lot of technical debt, but the pressure of getting the code written always outweighs the pressure of the debt.
I’ve said for years that I’m not at all surprised that software has bugs. What surprises me most is that any of our code works at all. If we are honest about our code, we recognize that our code is worse than a store front on the wild west. A nice facade on the front that everyone sees (if we are lucky) but look behind the facade and the store is barely standing up because the design, architecture and lumber is so bad.
But, if it is true that “How you do anything is how you do everything.” shouldn’t we spend a little time practicing quality in the not so obvious places so that we can get in the habit of quality? Maybe a culture of quality will rub off into our code and produce code that really does get written quickly and has very little technical debt. Not just in the area of bugs, but in flexibility, architecture, and design.
So, what could we change in our programming practice that wouldn’t require persuading a manager to make a change in how the whole organization worked? Photo on Visualhunt
Several weeks ago, I mentioned that I’ve been playing around with Property Based Testing. In particular, I’ve been using it with my Angular code. The framework I’ve chosen is jsVerify because it seemed like the most straight forward of the available tools and it has a documented way of integrating with Jasmine, which Angular test use by default. Angular with jsVerify. How does that work?
The documentation for how to use jsVerify seems to be written for people who already understand Property Based Testing from some other environment. This makes picking it up and using it awkward at best.
Over the last couple of weeks, I’ve been experimenting with Property Based Testing. While I’m probably doing it “wrong” by many definitions, I’m finding it useful enough that I’m adding it to my testing toolbox. Photo credit: abraham.williams on VisualHunt.com / CC BY-SA
I recently reviewed some Angular code that uses one module. The AppModule. To manage the entire code base. And, this isn’t tiny code base. The main excuse I’ve heard for this is that the code originated during the beta cycle, prior to NgModule being added to the framework. I call it out as an excuse because once it was added, it was clear that we needed to have more than one module. The fact that this code base doesn’t have more than one module shows a disregard for doing things right over doing things fast. In the best case, it shows ignorance.
But, the larger question this code base raises for me is this: “Why are more modules better than fewer modules?” After all, using one module obviously works. Isn’t the fact that it works sufficient enough?
Photo on 
