It has been a while since I have posted and I just wanted to give a short update. Obviously the last couple of years have been atypical. Thanks be to God, I am still gainfully employed as of this writing. I've been engaged in more varied work outside of tech, as well as expanding my skillset as a developer, and working a lot more with my church, expanding my role there adding a chairmanship (temporarily) to help us navigate post-covid attendance and giving slumps.
On the technical side, I've been working more with Spring and JPA and getting deeper into how much utility there is there. Adding Thymeleaf early this year was a tough choice for me, but that has become a staple technology for my UI work these past 14 months or so. The reason for this is that, while it harkens back to JSP's and I dislike JSP (for reasons), it does represent a server-side composition method for views (in our trusty old MVC pattern) and works particularly well with JPA.
Surfacing a model or transitory bean in a Thymeleaf template is trivial once you have a working understanding of it. There is no shortage of free documentation and tutorials so I'll omit any code examples here except at a high level to say: once you define your JPA bean, taking advantage of javax, Lombok and Spring annotations (you only need define your fields, not even getters or setters), the generation of your database structure, the inherited repository structures and simplified controller authoring move the bulk of the work into your controller or helper layer and the authoring of your templates and any supporting JavaScript. Shorter; the work to create all of your layers in an MVC application is greatly reduced to mostly focusing on the UI and business logic.
Why does this matter? Because speed of delivery matters. Maintainability also matters. This is why I have backed away from using Spring Roo. While I think the pattern Roo offers provides a lot of utility, the generated code, while fully leveraging everything Spring has to offer, is now lagging behind and creates more code than is readily maintainable. As a bootstrap to a quick demo, it has tremendous utility, but if you're going to hand code to someone to maintain later, you set them up for an impossible task unless they are a Spring and Java master.
On the JavaScript front, I've been working on and off on my simplified Modular JS framework approach. For a time, I thought JSON defined forms was going to be the way to get a SPA the way I wanted it, without the arcanity of Angular or React. When I adopted Thymeleaf, I backed off from this a bit. I instead have adopted the use of a custom reflection engine to create a standard way to simply generate JQuery DataTables from beans, whereby a schema query is the only thing you really need to add to a custom repository implementation. I still very much like the modular approach, and I still think it is simpler than Vue, React or Angular. You don't need to learn anything other than the standard JavaScript Class and Module approaches to make use of this, so long term, it's easy to describe to others and highly maintainable without the need for framework specific knowledge.
And why, you may wonder, would a guy who has created frameworks of his own eschew popular frameworks? Because the frameworks have become self serving, in short. They exist more to establish the dominance of the framework and maintain its relevance than improve your life as a developer or system owner. Yes, you can do great and amazing things with them, but you buy a lot of future pain and agony when your webpacker or npm build blow up due to incompatibilities. Someone said several years ago, "modern web development has become a minefield" and they were 100% correct. The approach I'm taking gets off the train to Griefsville and lets us focus on development and quick turn arounds. Ultimately, your value as a provider of solutions hinges on speed of delivery and cost to the client. You can make more money making people happy with low cost and short turn arounds than you can milking a project for several years. My goal, maybe not yours, is to help as many people as possible get the most out of their investments in IT.
In other technical developments, I've been working at building my knowledge of Azure. I tried AWS for a while but didn't like the way it was difficult to estimate costs. Azure goes out of their way to illustrate and project costs and provides ample free access to help you get a solution to a testable stage. One caveat that is if you're trying to use integrated authentication with the above technologies I have discussed, you'll need to invest in an https certificate to make it work unless you're only testing on your localhost. Azure itself is undergoing some changes, and as a massively distributed cloud platform with an astonishing amount of abstraction of services into small slices, there are things that are being pruned from the vine as time goes on. To me, if you need to host something on Azure, the benefit is only in the ability to federate an existing client domain with the authentication you want to provide on an application. That's a narrow view, I know, because my experience and needs are thus far narrow when it comes to this platform. If I were to start from nothing, I might use more native MS technologies rather than try to apply my approach to app dev to their platform. As it stands, I may or may not be continuing with this work due to external reasons.
Outside of tech, I've spent time this year getting more into landscape design and architecture and have made a lot of progress on my homestead. I hope to write more about that in the future on my other blog. I'll summarize with some stats: 150 trees put into nursery this spring, currently planting those out as time permits, 1.5 tons of boulders hauled, 40 cu yds of gravel spread, 30 cu yards of dirt moved, 1 driveway redone, one grade revised (raised), 20 pumpkins, 40ish squash, and 15 lbs of potatoes grown.
Heading into 2022, I don't know if I'll still have a full time job, but I'll be busy.
