It’s real easy to get lost in the day-to-day of software development, especially if what you’re doing doesn’t fall under a heading that most people would call “game-changing.” As a result, we don’t really feel like talking about it. The downside to that is it means you’re not keeping your public-facing work updated with what’s going on, what technologies you’re using, or really anything else that would indicate that you’re still working at all. It’s tempting to go silent, but I’m beginning to think it’s good to just talk about the uneventful and non-noteworthy stuff, just to remind ourselves that the normal day-to-day is…well, normal.
As far as my day job goes, I’m spending a lot of time helping do some Angular front-end development (I had largely written Angular off when Angular 2 was in development, but here it is on version 10, and honestly, I think I like it better than my brief forays into React and Vue). An even bigger chunk of my time has being spent writing unit tests. We’ve been pushing hard to get features out the door, and that’s the sort of thing that leads to tests being skipped, especially if most of your front-end development experience consists of “read some online tutorials, and Google around until you find a StackOverflow answer that you can adapt for your situation.” I barely know enough to make something that can be built and deployed to QA, so writing tetss is not a strong suit of mine. They’re still an important part of software development, so I’m trying to go back and add tests to any component that I touch (most of which don’t have any right now), and that’s about as much of a time drain as you’d expect. It can seem discouraging, especially if there are non-development team members that are wondering why you’re not just taking on new work, but it’s all worth it when 1 of those tests later manages to expose a bug, even though I was the one who caused the bugan
Post on most company’s tech blogs seem to fall into 1 of 2 categories – “Here’s some cool, new, innovative thing we built,” or “Here’s a cool thing we built that’s not necessarily new, or innovative, but that scratches our ‘Not Invented Here’ itch because {insert reason existing software here} doesn’t work for our (special) business case.” Obviously the developers there are doing really cool stuff, which sort of makes a lot of our day-to-day seem pithy in comparison. It’s important to remember – we’re making software that people use. It doesn’t have to be the flashiest, or the coolest software out there, it just needs to get done on time and work consistently. A lot of that is unflattering, or involves learning things that are useful to us, but are ultimately more like blurbs about our day rather than something new and completely noteworthy. That said, if they help you, they can help others, so it’s worth publishing what you’re learning just in case there’s another developer that
Speaking of – I have learned that setting Angular’s ChangeDetectionStrategy to OnPush can cause some issues trying to detect changes in the DOM after you do anything. The good news is that you can override that ChangeDetectionStrategy back to default in the unit test, which I recommend just based on how much easier it made writing test cases. I still have a couple of @Injectable() adapters that extend existing Angular built-in adapters that I still need to figure out how to test, but I’ll have to get back to Googling around for that issue later.
Another Angular tidbit I learned – you apparently need to be as careful to unsubscribe from any subscriptions you set up as you are about closing streams on the back-end – for exactly the same reason. You’d think that when you navigate to a new page and the old component is destroyed any subscriptions would be destroyed too, but that is apparently not the case. There’s a couple of ways to handle this. The first is:
ngOnInit() {
myObservable.pipe(takeUntil(this.destroyed).subscribe(/* Do your stuff here */);
}
That lets you stay subscribed to all changes emitted until the component is destroyed. If you know you only want to subscribe to a certain number of events, you can listen for just that number of changes using:
myObservable.pipe(take(1)).subscribe(/*Do your thing here*/); // Change the number in take() to match the number of events you need.
Generally I only use that second option if I just need to get 1 updated state value from a particular action, but obviously fee free to change the parameter to whatever works for you.
Speaking of closing things, here’s a friendly reminder to always be sure you close streams in the back-end too. That’s something that usually gets covered in school when you learn about file I/O, but it’s also something that’s easy for us to forget. I know, because I work with people who have been doing this for years, and we still had a bug caused by a memory leak that stemmed from not closing streams we opened calling external services. In the spirit of “I’ve been doing this for {X} years and I still Google {Y},” here’s another reminder we’re never too experienced for, don’t forget to include a
finally {
myConnection.close();
}
whenever you connect to any external resource.
Another classic that’s still worth noting, remember that Java’s URLConnection has no default connection timeout value. You’re going to have to call the setConnectTimeout() every time you open a new URLConnection. That’s not a new issue, but it’s something to look for every time you see that class in a pull request (or you can ignore it and get memory leaks from attempts to open connections to servers that aren’t responding, I’m not the boss of you).
Just getting things done on time, consistently, and without burning yourself out, is an impressive feat in and of itself. And even if you aren’t building something bleeding edge, you’re still developing your craft (or at least you should be), and learning more (even if it’s just a little bit). Just hang in there, and keep getting a little better every day.