Because this is a frequent problem, because it is so often done incorrectly and because there are some pretty great alternatives, 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.
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.
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.
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?
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.
Here’s what I’ve learned along the way.