Pro Coder

Why hello there Substack!...

Sun, 23 Nov 2025 00:00:00 GMT

…what do you have for me today?

When I started writing technical articles, back in 2019, I did that around the same time I began making YouTube videos. The idea back then was to publish on Medium and maybe make a little extra money!

That may have been my thoughts six years ago, but I made a seismic shift earlier this year. I discovered I could rebuild Pro Coder into something new. Instead of a lightweight website, I could build a deeper platform. And the first thing I wanted to do was pull over all the Medium articles and server them from my own site. For free.

And with a little assistance from Chat GPT, I made that happen.

But why stop there?

I had heard from multiple people that Substack was exploding on popularity. So I pointed my attention at cross-posting all my past (and future) articles. Not to make money, but instead to share my experiences and help you grow.

I was fully committed to syncing every past, present, and future article, automatically with a script, to Substack when I discovered…they don’t have an API.

I looked for modules, pre-fab libraries, anything that would let me push an article. What did I find? Zip. Zero. Nada. Looks like Substack wants you to write there first.

Well that ain’t gonna happen!

So after trying various side tactics to slide content over to Substack, I finally chose to “go in through the front door.” That’s what I call it when you scriptify an application’s UI.

Having migrated to Claude Code, I fired up a session, rubbed my hands together, and typed “ready for a challenge?”

And Claude smiled back.

And a challenge it truly was. We worked up a Typescript library, far from perfect, that would typeset the original Markdown I write my newsletters and articles with. Then we created a chain of “finishers”.

Replace Markdown image directives with a series of steps to upload images
Replace link directives with hyperlinks
Replace boldface and italicized text

I’ll tell you, it wasn’t easy! Substack has various pop-ups. Things required certain delays for the widgets to act. And it took a LOT of iterations to get the image uploading to work right. I also wanted to “backdate” articles to their original pub date.

But the thing that really irritates me is that Substack is REALLY hostile to being downstream. They want you creating content with them, first! The first piece of evidence is the fact that they don’t do “canonical links”.

Canonical links are what you put in HTML when you want to say “the origin of this content was hyperlink”. It tells search engines where to go to find the source and avoids you getting dinged for duplicate content.

Medium has this feature. Substack doesn’t.

Five years ago, that might have ended my efforts. But not today, Zurg!

In this day and age of AI-powered synthesized search results, I imputed Google and its competitors with a little more trust. I wrote up a little footer to stick at the bottom of every article that reads “This article was original publishing on Pro Coder on ” and hyperlinked back to my own site.

Maybe the engineers behind Google etc. aren’t looking for that. But their AI processors may see it!

And so I bulk loaded almost 80 articles to Substack. I had my tool load them all in draft mode, because no matter how hard I tried, there was always a flub. I hand edited each of them. And now they’re ready for you.

Are you on Substack? Check it out!

— Greg

P.S. Articles are now posted on Substack. Subscribe today!

Claude Code is my new best friend...

Mon, 10 Nov 2025 00:00:00 GMT

…and maybe it should be yours as well?

I have been shelling out the big bucks on ChatGPT+ over the past 18 months. Yup…$20/month!

Okay, maybe this ain’t the BIG bucks. But I have certainly gotten my money’s worth out of that $20/month. This website wasn’t BUILT FOR ME by ChatGPT. But I certainly worked hand-in-hand with ChatGPT for it to carry out my bidding in a very fast-paced collaborative way.

And about a month ago I canceled my subscription.

Because I had found something better.

Claude Code, the CLI tool that hooks into Claude.ai from our overlords at Anthropic is the place where I activated a $20/month subscript.

You see Claude Code is an agentic AI tool. It closes a critical loop. With ChatGPT, I would copy-and-paste all the text from a given page, paste it into ChatGPT’s window, give it a command on what tweak I wanted, get the resulting output, and paste it back into my IDE.

With Claude Code, I launch it in a terminal inside my IDE where it can see all my files, tell it what I want done…

…and it just edits the file directly.

The first time, I said “whoah!”

And then I did it again. And again. And again. And again.

After about the 10th hop, where I’m simply handing out marching orders, and Claude Code is bending and twisting this website, it felt like I was sculpting a website.

Claude Code is almost like the Starship Enterprise’s central computer. On ST:TNG, they are always asking the computer to do this, that, and the other. Through simple, verbal commands.

Well here I am, telling Claude Code what to do, and it’s just…well…DOING IT.

That’s already a boost over the flow with ChatGPT. But there was more.

ChatGPT, once you give it a prompt, makes you wait until it’s done. Claude Code is always listening in. You can type more instructions. Clarificiations.

And when it gets a chance, it will look at what you said, and fold that into its process.

You see these agentic AI tools run on a sort of loop. They start an action and then they LOOK at what’s happening, and may alter what they’re doing, until they think they’ve done what the original prompt asked for.

That is much more constructive in getting stuff done.

The next big thing that I want to add to this site is, after having added the ability to send you e-books you signed up for (or purchased) is to build the ability to get audiobooks and videobooks.

12 Rules for Pro Coders has a paperback, hardback, e-books, audiobook and videobook versions available.

And I plan to make them available to you.

The e-books I got working (and already mentioned). I’m working with Lulu Direct to print paperbacks and drop ship them to you. (Not sure if they have hardbacks or not)

But the Holy Grail will be finally finishing up the audiobook and videobook versions.

I plan to make each of those a “private podcast”, meaning I can host the files on my own backend system, stream the content through my back-of-the-house order fulfulment system, and then send you a unique private “podcast” that will contain all the content for you to consume on your favorite podcast player. Since many podcast players now support video, that should work quite nicely.

And since I have the vision of how that will work architecturally, I have no doubt Claude Code can help me implement it with ease.

I’m amazed at the speed and scope of what I can do. Being able to apply my experience so deftly is amazing. And it also helps me learn as well. Topics I’m not as skilled out, these tools can coach me on. Considering the training is very contextual, the learning “sticks” much better than reading dusty opd textbooks ever were in grad school.

If you’re not subscribed to Claude Code, you may want to consider it. (And no, I’m not sponsored by Anthropic!)

It could be the power boost you’re looking for.

— Greg

P.S. Consider becoming a member if you want first dibs on EVERYTHING!

Liquid Glass on iOS...

Sun, 12 Oct 2025 00:00:00 GMT

…may be something Steve Jobs would have been proud of!

Ever since the great titan’s passing way back in 2011, people have questioned every design decision ever since. This may be The One!

Steve Jobs while complicated and full of questionable personal decisions was someone that invested serious time and effort in stuff like fonts. Look and feel. The shade of black.

Others thought he was crazy.

But who are we to question someone with enough artistic gravitas and business acumen that he ended up with more Disney stock and than Disney’s CEO at the time of the acquisition of Pixar.

And so with the passing of the only computer giant that gave Microsoft a run for it’s money, every single design decision ever since has been run through a lens of “would Steve Jobs approve of this?”

At one time the iPhone screen icons were curved and rounded. And then all of sudden they were flat.

But now with this emergence of Liquid Glass, I have to yet hear a single person ask that very question.

My gut reaction upon first seeing Apple’s own illustrative reel was “wow!” I’d like to Jobs would have been equally impressed.

Apple devices have always had some element of other world-ness. It’s part of what draws me to Apple. Sometimes that nature has been subdued. Other times not.

I’ll always remember that time I visited the Melbourne Square Mall, long before I ever owned a Mac. In the main thoroughfare between shops was a special setup showing off their latest line, the Power Mac G4 Cube and all it’s peripherals.

An antique today for sure. And something I didn’t know the specs of back then.

But the look and feel was burned into my mind. And the fact that they were playing The Fifth Element on one of them to show off it’s multimedia features put a nice touch on it all.

This was the sort of thing people that didn’t get Steve Jobs at all couldn’t comprehend.

To Jobs it wasn’t about art OR power. It was about both, at once. And in your hands.

I’ve seen people pose the question “why do you Apple fanbois like it so much?”

My answer was a long Tweet that told the tale of my wife’s discovery of Apple. The one that culminated in her breaking from her family pack. First getting her a MacBook Air. Then later, a possessor of lower-priced Samsung devices, she one night said “I think I want an iPhone.”

That post was followed by a legion of “👆this” responses.

I had jumped ship and got my first Mac when I joined the Spring team in 2010. The year before that, I had snagged an iPhone 3GS.

I later sunk my own hard cash into a fully leaded M3 Max the day after being told I would no longer be a part of the Spring team in 2023…using every nickel of VMware’s final au revoir bonus check before they vanished into the history books. (Purchase price exceeded $4,000.)

I watched my best friend hire a video editor/producer to help with his company’s training material…and reach out to me when this new hire requested a MacBook Pro. He needed to know how much budget to grant for her endeavors.

In none of these situations have I heard an ounce of buyer’s remorse.

So dragging us back to today…is Apple’s latest RIDICULOUS continuation of design aesthetics gone off the rails with Liquid Glass?

I don’t know.

Accessibility is important. Very important. In fact, accessibility has become one of the most important reasons you should favor tabs over spaces my fellow pro coder.

Does Liquid Glass violate accessibility?

Again, I don’t know.

But I’d like to see Liquid Glass tested in the marketplace. We’ll all learn something.

It’s easy to throw rocks. I’ve done my fair share. And the tech community appears to be up in arms over this.

But I’m glad Apple is continuing to try out new ideas. New concepts. New aesthetics.

Because the day they stop trying will TRULY be the day that Steve Jobs’ ideals will have died.

— Greg

P.S. Consider becoming a member if you want first dibs on EVERYTHING!

Keeping up with the times?

Mon, 29 Sep 2025 00:00:00 GMT

“Expertness and skill for the performance of special kinds of work lose their remunerativeness when new fashions or new methods of production narrow the opportunity for their employment.” —Ludwig von Mises, Human Action

The world is always changing. Skills we learned yesterday come with no guarantee that they’ll be usable tomorrow.

A strong piece of evidence for this point of view is the emergence of AI tools like ChatGPT!

I have actually ditched SaaS tools with ones that I built MYSELF. As a published author, one of the key things I need to do is put a book into your hands. I used to use a SaaS tool to handle that for me. This tool would generate unique download links, and then send out an email to the recipient. The download link would have a shelf life of two weeks. The handy thing was handing the tool a list of 200 emails and let it go to town.

But using AI tools, I’ve been able to supplant this $150/yr rather quite useful tool with one of my own. In fact, the website through which you read this newsletter has a portion of this feature! The link you should have received to Pro Coder’s Guide to AI (reply to this email if you haven’t and alert me) came partially this website (and partially through my back-of-the-house order fulfilment system)

I have also seen others in completely different industries say the same with regards to ditching various tools and building their own through the magic of AI assistance.

In Mises’s landmark publication Human Action: A Treatise on Economics (published in 1949), he argues that nothing is forever. The market is always changing. It’s rather silly to assume that anything will stay put. And most assuredly, a consistent steady paycheck is going against the grain.

My own experience with one day waking up and deciding I would throw my hat in the ring to join the Spring team (and succeeding), and then later having that bookended with a brand-new CEO deciding my tenure on that team was over, is one additional data point in Mises’ favor.

That and many other experiences have shown me the value to always to be learning. Always be reading. Always be picking up new toolkits.

To pick up one toolkit and presume that this will be your bread’n’butter for the rest of you career is foolish.

Part of what stimluates me to get up and write for you is my desire to share some of the realizations I have with you. Most of it is my own knowledge and awareness of this industry. But some is my desire to bring you knowledge I wouldn’t have found through the usual channels.

Human Action is something that I had heard referenced by multiple people, so one day I decided “I’m going to read it!” I didn’t realize the manuscript is approximately 450,000 words. That’s about 1800 pages if you were to print it like any other conventional novel. I also didn’t realize it was so “high brow”, i.e. academically flavored. I quickly deduced I can’t read it at the end of the day. I don’t have enough cerebral power at that point.

So I began reading it in the morning. Right after I read my morning passage of the Bible.

And what’s quite fascinating, is that this philosophical text has brought an awareness I didn’t expect.

Certain phrases I’d hear a politician or a pundit say would leap out at me. I could hear some of Mises’ arguments from his tome add color to what this person was saying.

And when I read the passage listed at the top, my experience in this industry seemed to line up perfectly.

Nothing is set. Nothing is guaranteed. Nothing is steady. The only guarantees we have are change, so plan accordingly.

Whatever nervousness I had about learning more and more about our modern-day AI systems had to be set aside.

I quickly realized that to survive in today’s software industry, you can’t ignore this AI revolution. Maybe you can if are some tenured CompSci professor? A) I ain’t that and B) Mises’ words suggest even tenured professors entrenched at well-funded universities may not be sacrosanct.

I am learning what I can. Some of those lessons have made their way into Pro Coders’ Guide to AI.

One thing is rather cute…MANY AI tools are simply wrapping up your request and then calling out to ChatGPT or Claude. Supposedly with some additional prompting. Is that really “new”? Or just plain old huxterism? I’ll let you evaluate that for yourself.

But this newsletter isn’t about AI. Not specifically. Instead, it’s about the fact you need to be constantly learning. Growing. Expanding.

People ask me all the time “Is XYZ a good tech to invest in?” As I’ve mentioned before, YES!

Considering the amount of competition out there, and the fact that someone I reached out to when I was cut in turn got cut in a recent round of layoffs, it’s critical! Keep reading. And if I’ve learned anything from reading an economic philosophy book, not EVERYTHING you read has to pure software. Simply reading (perhaps a hair above tabloid trash) a little bit every day can elevate your thinking and provide extra illumination to the things around you.

— Greg

P.S. Consider becoming a member if you want first dibs on EVERYTHING!

Ever taken up a hobby?

Wed, 17 Sep 2025 00:00:00 GMT

A couple years ago, the Mrs. had scooped up this little bitty iPad app called “Procreate”.

Well, as part of my new job at Cockroach Labs I needed my own iPad to function as part of my teleprompter setup.

So I sure as shootin’ I got on the app store and downloaded my own copy.

And then I thought to myself…

…how do you even DRAW?

As a YouTube content creator, my first thought was “there ought to be a video on that!” And there was. And another. And another. Well, you get the idea.

So I just started doing stuff.

In fact, I dug into oil paintings. I remember visiting Paris back in 2007 and seeing artists on the street scrambling to earn a living selling oil paintings. This art form always blew my mind, because when you look up close, it’s just clumps of paint with weird colors. Dark blue, purple, off-pink. If you’ve seen one, you know what I’m talking about.

But then you step back just a bit, and POW!

It LOOKS like something. Something AMAZING.

So…I went back to trusty old YouTube and inquired after “oil paintings with Procreate”.

I was not disappointed. An hour later, I had made this…

Today's sponsor...

Coding isn’t just about algorithms. There’s more. A LOT more. CI, security, team communication, meetings, career tips, you name it. I wrote 12 Rules for Pro Coders to give you actionable advice to accelerate your career. As a veteran pro coder, I want YOU to learn the same valuable lessons I did…but faster. Go and grab your copy and learn what your university or boot camp didn’t have time to teach you!

I wrote 12 Rules for Pro Coders to give you actionable advice to accelerate your career. As a veteran pro coder, I want YOU to learn the same valuable lessons I did…but faster.

Go and grab your copy and learn what your university or boot camp didn’t have time to teach you!

GET YOUR COPY NOW!

Needless to say, I was hooked.

I began watching more videos. I wanted to learn more ways to draw.

Talk about a rabbit hole.

But that ain’t everything. Turns out, Procreate also lets you export a time-lapse video built up out of every keystroke used to make your drawing.

At the same time, in the thick of building our slide show content for our customers, I had been imbued with a real love for our product, CockroachDB, such that I began a pencil sketch of all its bits and pieces.

When I showed this to our team’s social media manager, he begged me to turn that time-lapse into a YouTube Short.

I couldn’t resist, and so here it is.

Have you ever found something, be it a hobby or something else, that you found rewarding?

Reply to this email and let me know.

— Greg

P.S. Consider becoming a PREMIUM member if you want first dibs on EVERYTHING! I already shared with them my time-lapsed video of creating the cover for What Is A Database?, which you can now enjoy down below.

Are you optimizing too much?

Fri, 29 Aug 2025 00:00:00 GMT

I’m always reaching for something to speed things up. Databases queries. Server startup times. Render time of my website.

It’s easy to have picked a stack and push forward. You hit a bump so you optimize.

And push forward.

Hit another bump and optimize. Push forward again.

The thing is, when you take a given paradigm and continue to keep going down the path of optimizing it, you may not realize the assumptions that begin dragging you down.

Let’s take Wordpress. Wordpress was a popular answer to the LAMP stack. 20 years ago more or less, Linux/Apache Web Server/MySQL/PHP formed a nice little team.

For those of you not born in yesteryear…

L = Linux
A = Apache Web Server
M = MySQL
P = PHP

L + A + M + P = LAMP

LAMP was versatile. LAMP was easy to install. And Wordpress leveraged these pieces quite well.

People poured effort into Wordpress’s core. Untold plugins were built. Caching solutions were designed.

The whole thing hummed along. It took less and less effort for the user to stand up a site, create content, and publish. Getting a website for your customer up and running became easier and easier.

But there is an issue in optimizing this way.

What if you could build a website WITHOUT a database? Without dynamic endpoints? Without a traditional CMS (Content Management System)?

I was lured into Wordpress for so long it wasn’t until a hacker hit my websites that it shook me loose enough that I asked “is there another way?”

I began to think. I was curious.

Mind you, I had stood up a WP site simply to provide a URL shortener with my own domain (trnq.st). It was NEVER performant. And all its redirect stats were locked away. (What do you expect from a website where every single hit was a call to a database?)

I started having a little conversation with ChatGPT.

“I have this website used solely for URL shortening and redirects”. <--- me

In its exuberance, it offered to rewrite the whole thing with a Python script and a JSON data file!

In no time, we rez’d up a solution. A STATIC solution. Every redirect was captured as a JSON entry and the Python script would generate a simple HTML file for each entry.

And thanks to my eternal desire to have CI/CD pipelines perform all builds and releases, we also assembled a GitHub workflow. Every new addition to that JSON data file and the website would rebuild itself and redeploy as a static GitHub Page.

name: Generate and Deploy Redirects

on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout private repo (`trnq.st`) using GitHub Actions default token
        uses: actions/checkout@v3
        with:
          repository: gregturn/trnq.st
          token: ${{ secrets.GITHUB_TOKEN }}  # Uses default GitHub Actions token

      - name: Set up Python
        uses: actions/setup-python@v3
        with:
          python-version: '3.x'

      - name: Generate redirect pages
        run: |
          mkdir -p public
          python generate.py

      - name: Ensure clean `public_site` directory
        run: rm -rf public_site

      - name: Deploy to `trnq.st-site` (Public Repo) using `GH_PAT_DEPLOY`
        run: |
          git clone https://github.com/gregturn/trnq.st-site.git public_site
          cd public_site
          git config --global user.name "github-actions[bot]"
          git config --global user.email "github-actions@users.noreply.github.com"

          mv CNAME ../CNAME.bak || true
          git rm -rf .
          mv ../CNAME.bak CNAME || true
          cp -r ../public/* .
          git add .
          git commit -m "Auto-update from trnq.st" || echo "No changes to commit"
          git push https://x-access-token:${{ secrets.GH_PAT_DEPLOY }}@github.com/gregturn/trnq.st-site.git main

What a joy!

ChatGPT and I then went on to build some additional GitHub workflows that made it possible to add new redirects to that JSON data file through the magic of GitHub issues!

But building this gem of a website had unearthed something incredible.

A redirect website is one thing. Simple. Flat. Easy to grok because the essence of it was a single Python script.

But what about ProCoder.io? The flagship of my medium I had built to share all my mistakes with, well, you!

Could ChatGPT and I rebuild all THAT?

The Pro Coder website is much more. It lets me sell books. It facilitates signing up for my free newsletter (including a freely downloadable e-book).

What if I threw Wordpress out the window and rebuilt that?

Statically.

With no database. No CRM. No logins.

No administrative dashboard.

Just commits published to a private repo. What about that?

Spoiler Alert: You CAN.

We can talk about the specifics another time.

The point is that every now and then, it’s good to pause and question some of the core assumptions and arguments that led you to where you’re presently standing.

Are you making vast improvements? Or are you optimizing down a dead end at ever diminishing rates? It’s sometimes hard to see.

—Greg

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out this livestream where I figured out I’ve been spending too much time on social media!

I have a new book ready for you...

Sun, 17 Aug 2025 00:00:00 GMT

…and it’s free! Keep reading to secure your free copy of Pro Coders Guide to AI.

“In the realm of action there is nothing perpetual but change.” —Ludwig von Mises, Human Action

In my 28 year career as a pro coder I’ve seen a lot of changes in the industry. Some of the biggest changes I have seen include:

Search engines
IDEs with almost prescient awareness of what I need
Laptops today that run circles around the UNIX workstations of old

But nothing, and I mean nothing, beats the revolutionary arrival of AI tools to help with crafting code.

Yes AI tools introduce a new level of noise. And “hallucinations” isn’t something I ever expected to be a term of art that would enter our realm.

But I’ve actually been using various AI tools in a multitude of ways over the past year. It’s hard to share all the ways AI has helped me and all the ways AI has also fallen flat on its face in a newsletter.

So I instead wrote a book. And it’s free. For you.

Pro Coder’s Guide to AI book will eventually go on sale to the general public for a price. But today I’m making it free for you in e-book formst.

And I’m delivering it to you through my brand-new book delivery system I put together. To get it, you need to >>> click on this link <<< and enter your name and email address. My system will create a unique download link and send it to you in a separate email.

Click on that, and you’ll have a copy of my book!

Then, soon, I’ll start live-streaming where we can talk about how I rebuilt ProCoder.io from the ground up with a little help from you-know-who.

—Greg

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out this video where I basically have departed social media…for good!

Do you backup your systems?

Mon, 11 Aug 2025 00:00:00 GMT

At the end of March my sister-in-law’s house burned down. She and her family moved in with us that night for the next two months. We went from 5 residents of our little domicile to eleven. Overnight.

I’ve held off writing this because frankly, the whole thing was shocking. To all of us! I didn’t want to rush this before I could genuinely decide it was time.

It’s time.

(No one was hurt. And they have since found a rental to have their own space as they rebuild. Thanks for your concern.)

Watching the fallout of that made me start double thinking some of my backup systems!

If you ever build a RAID array to start doing backups…one of the first things you hear is “that’s not REALLY a backup!”

A backup to another system isn’t REALLY a backup at all!

And on some level that’s true. Why?

After all…if your house burns down you’ve got nothing. See?

But like anything, there’s no need to be pedantic. Standing up a RAID array and scheduling daily backups is the first step. It guards against immediate machine failure.

And so daily backups to a local RAID array IS a backup. At least it is to me.

I stood mine up years ago. But ever since I watched a family of six join us for two months, my mind has gone back to the drawing board.

And my conclusion? What we have ISN’T ENOUGH.

Now I’m contemplating buying a SECOND RAID array and linking it to the first. And then staging it at someone else’s house.

Maybe this is getting too specific. The idea of this article is to pique your interest. Do you have any backup solution at all? To lay it all on the table I have:

Synology 4-bay RAID array with a pair of 8 TB NAS drives. A real turnkey apparatus.
I run Carbon Copy Cloner on all my machines. Despite Time Machine’s delicious UI, it has failed me too many times!

That’s pretty much it.

Linux has a world of tools to build RAID systems with LVM. But the cost of a Synology device is low enough, and considering it’s using all that under the hood anyway, that it’s easier to just buy the box and get going.

Hence, buying a second box should be pretty easy. I just need to figure out the part where I have these two devices linked to each…over the Internet…without compromising security.

I experimented with Cloudflare’s Zero Trust product a bit. And got dragged down a rabbit hole.

It’s basically a VPN solution with a twist. Or rather multiple twists.

Founded on network edge management, they offer a lot of nice services. And as a side effect they really can build VPN tunnels. I just haven’t caught on to all the twists. Not yet.

So I’ll probably doing more reading on that front.

What are you doing? Any backups at all?

The first level of backing stuff is simply buying an external drive. They have ‘em everywhere. Can you rig it so that everyone out plug that external drive into your machine it takes a backup?

The second level is realizing that this isn’t good rough. This is what dawned on me as the Mrs. and I started taking more and more pictures of the kids as they grew. We had a treasure trove and i feared losing those digital memories. This was the reason to stand up an always-on NAS.

The third level is backing up your backup. That’s where I am right now.

If you’re wondering “are there any cloud based solutions?” The answer is yes.

And I used to use them. But somewhere along the way, maybe 10 years ago, they all pivoted toward a metered-based pricing model and the costs jumped. Too high IMHO.

I could actually keep yammering on and on about this, but I sense I may be wearing out my welcome. So let’s land the plane already!

I want you to think about what’s important to you. Digitally.

And then think about what would happen were you to lose those digital assets and had to start from zero.

And then start setting aside a little money to cover the cost of restoration. What a simple $20 in an envelope?

Eventually, that envelope will grow large enough, and the desire to not start from zero will be strong enough, that these two can meet and you’ll take action.

— Greg

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out this video of me painting one of my recent book covers! Who knows? I may show you HOW I did that in a future article.

I’m leaving social media...

Mon, 28 Jul 2025 00:00:00 GMT

…forever!

I’m done.

I’m signing off of X/Twitter. I already left Facebook two years ago. And I never really got far with Instagram or Pinterest.

And I’m not coming back.

Studies show people average 2 hours every day simply scrolling?

Here’s the kicker. It ain’t from sitting down and flipping through for a solid two hours. Nope. It’s a minute here. Two minutes there. In between your kids kicking a goal at a soccer match. Or those three minutes during a meeting at work.

If you wonder why the Pro Coder Show hasn’t aired an episode since September 2024, that’s a piece of it.

Now mind you, I’m not innocent in all this. There are ADDITIONAL reasons why all that I’ve squeezed out since then has been half-a-dozen members-only livestreams in the interlude. But 14 hours each and every week is certainly a decent portion of it.

To answer the question in the back of your mind, I’m not leaving for any political reason. I frankly find it loathsome to discuss political affairs online. If you search my social media presence you’ll find it devoid of political jabbering.

No, this is because I am reclaiming my life. Scrolling on social media platforms is documented to have depressive effects on people’s mentality and it’s frankly not good for business.

Social media used to offer gobs of “free traffic”. That was really useful for book sales, published articles, and your latest video. Anything you want.

But all that kind of ended around 2018. All the platforms switched to an “algorithm”.

This “algorithm” has been described as being in a stadium full of 100,000 people, all shouting. And all you can hear is whoever has the mic on stage RIGHT NOW, or someone right next you WHEN YOU’RE FACING them.¹

Kind of reminds me of a Jason’s Deli that opened years ago in Melbourne, FL when I lived down there. The sandwiches were stacked so tall, Dagwood Bumstead couldn’t get a bite! But after about six months, they stopped stacking ‘em so tall. Can you guess why?

The truth is, social media baited us all with “free” traffic. And then they cashed in. Well I’m cashing out.

Doesn’t mean I’m not making more content. Actually, the opposite. I’ll be creating MORE content. Just for you. Social media will no longer get between us.

If you want to continue hearing about my mistakes as a 28-year veteran in the industry and learn how to dodge some of the potholes, I encourage you to sign up for my newsletter.

I am also resuming the Pro Coder Show. You can either subscribe for it on YouTube or catch it on your favorite podcasting platform (or both!)

“He who has the gold makes the rules!”

—The Golden Rule as explained by Nelson Nash

I am taking my experiences and wisdom, my “gold” if you will, off social media and instead investing them 100% into this website in the form of articles, newsletters, and podcasts. All of which you are free to consume 100% at no charge.

I rebuilt Pro Coder to serve those needs, and will be delving into how I used my talent, experience, and a touch of AI to make it happen, so sign up if you want to catch that!

(If you choose to grab a copy of my latest books as they come out, be my guest.)

I invite you to join me on this journey. Feel free to share anything that tickles your fancy with a friend. In truth, content is best shared this way. Word of mouth is well documented as the most solid “sell” of any good.

I’ll do my best to make it worth your time.

— Greg

P.S. Don’t forget to sign up to get the latest lessons learned!

Writing Off Social, Ep. 1: Why We Left Social Media, Sandy and Mary K. ↩

Teaching software is harder than writing it

Wed, 19 Mar 2025 00:00:00 GMT

Being in the trenches of software development for 28 years, I’ve seen a lot. Writing software is HARD!

I remember an article that surfaced back in 2011 titled “Yes, Virginia, Scala is hard.” It was written by a prominent fan of Scala that seriously challenged some of what Scala embraced.

What it kicked off was a furious debate in multiple platforms that IMHO was about the trade off between more powerful constructs vs constructs used by the masses.

I’m not here to revisit THAT debate.

What I’m here to dig into is another age old wrinkle…training up the next generation of pro coders.

You may not know this but I used to study martial arts. Unfortunately I had to give it up due to arthritis in my knees. But something I had learned at the time was how to teach others.

There’s a mantra thst says:

The fastest way to learn something is to teach it to someone else.

That may sound kooky or flat out wrong. But it’s actually true.

You see to teach someone else, you need a certain amount of understanding yourself. Not 100%. But enough to get the basics.

The REAL challenge is when you start getting questions.

This is the feedback loop of the most common challenge with the content you’re sharing. And so you end up either knowing the answer by digging for the answers, thus forming mental pathways for yourself and the person you’re teaching.

As I helped junior Tae Kwon Do students with basics, I was getting schooled in the same.

Let me ask you, do world class athletes practice fundamentals? Ever?

You’re darn right they do!

Every day. Probably a key thing to maintain their skill.

Practicing your skills whether you’re a beginner or a pro is VITAL. I was practicing my martial arts discipline twice: once during my own lessons and once when helping others.

And the feedback was always there.

Either my own master coached me, or the questions from a junior student pushed back on me.

This ain’t something you can teach sitting on your dairy air!

Same goes for training pro coders.

As I host episodes of SELECT STAR, create drawings for slide decks, or assemble a challenge exercise, not only do I have to get it working, I want this content to align with our official documentation. I want it to match our best practices.

I’m constantly reviewing things and either taking feedback to the Docs team or to someone else.

Iterative feedback is GREAT! Intense, but great.

Are you aware that the span of time between the Wright brothers first powered flight and us landing on the moon is only about 60 years?

That’s what I think of as a solid 60 YEARS of engineering feedback. That is a golden era of development.

Feedback is INCREDIBLE. Don’t knock it when feedback is brought to you.

It’s been tough but quite gratifying. Training that genuinely strives for top notch content instead of summaries and simplistic boiled down artifacts can elevate whole teams. Empower fellow developers.

Who doesn’t want that?

— Greg

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out this video an old friend of mine and I discuss why YOU may be your best investment!

Been hacked? I have.

Wed, 26 Feb 2025 00:00:00 GMT

Being a pro coder, there is no shortage of questions that come my way when people “learn” what I do. The question I always want to know is, why are at least HALF of them all about tech support?!?

Whelp I guess it was prone to happen sooner or later.

My wife’s website which undergirds her publishing business gots HACKED.

The website was offline. I tried to get in. I couldn’t. I pinged tech support. They came back and told me the server was humming right along. I said “no it’s not.” They ran a scan. And…

Okay, I guess I’ve been LARPing as tech support long enough that the Good Lord has decided to serve me a dose of humility. Noted!

Time to get cracking, ehh?

Fun fact: I actually have five websites hosted on this server. They’re ALL offline. Alas, only one of them is the basis for my wife’s publishing business so I already know which one to focus on first.

Maybe I’m the CFO of my wife’s enterprise. Maybe I do the books and coordinate with our accountant.

But the truth is, I’m the one that makes all the software “go.” So taking my years of experience, and remembering what a friend of mine once said, “when a website is eaten up like that, just start with a fresh install.”

I can spend gobs of time trying to suss it all out, but I’ll probably be better if I start from scratch. And I will. However, there are a COUPLE things I’d like to bring along.

Like all the images that my wife uploaded to her Wordpress site. Now how in the world could I possibly grab all the existing images from her old site WITHOUT GOING to her old site and upload them to a new site?

Easy.

Find another source. Like…the Wayback Machine at the Internet archive!

I actually started writing another book, and a good chunk of is written. In one of the chapters, I demonstrate how I leveraged ChatGPT to create a tool that would let me download EVERY SINGLE IMAGE from another Wordpress site.

The book I’m in the middle of writing will be called PRO CODER’S GUIDE TO AI. As a content creator, the prudent thing would be to offer a pre-sale buy link right here in the middle of the article.

Unfortunately, the site where I would OFFER that pre-sale link was also hacked. So I’ll just have to trust that when the time is right, and my job as “tech support” has been carried out, I can solicit your support. 😇

Back to “tech support” crisis management!

Looks the script ChatGPT and I worked up is going to be needed sooner rather than later. Since this is a combo of database + PHP files + uploaded content, I am going to find out if the database is intact and this hack job is pure file-based.

If it’s just files on the server, then a scrape-and-load with a restored database won’t be quite as devastating a thing.

I am suspicious of some plugin I was using that was the culprit. I thought I had phased out that plugin and removed it altogether, but the scans from my hosting provider showed signs of it still being there.

Ho-hum. In the words of Willy Wonka, I’ll figure it out. I always do.

Sometimes being a pro coder and solving other people’s problems means putting aside your glorified authoring of beautiful majestic code, and instead being the janitor of someone else’s Wordpress site.

People come to us pro coders because we have experience. We have our “spidey senses” that guide on when it’s okay to push a button or when not to and instead read a little more.

I have patched many servers. Sussed out systems for 24x7x365 systems that sustained comm systems between air traffic controllers and aircraft in flight.

I have experience the Mrs. doesn’t. And so it’s my job to pick the most efficient route to resolve all this and get her website operational again. And to rinse and repeat for my other sites.

And once all is said and done, to offer you that pending book!

It’s not the most EXCITING task I’ve been handed. But I actually look forward to solving this catastrophe and restoring order. And hopefully, having better controls in place.

There is joy when we do what we are called to do. Software stuff is what I was called to do. And so when I accomplish something, even if it’s not “on the clock”, I still relish that accomplishment and smile.

What about you? Does pro coding provide satisfaction to you?

— Greg

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out this video where I show EXACTLY how to interview like a champ, even in a struggling economy!

To AI or not to AI, that is the question!

Fri, 17 Jan 2025 00:00:00 GMT

It’s no question that AI has emerged rapidly and swept not just the tech industry, but many other industries by storm!

Before we go any further, I understand that you may disagree with the term “AI”. These tools have no real “intelligence” whatsoever. You are probably right. But it doesn’t matter. This article focuses on the utility of these tools, not their metaphyiscal implications.

Part of the evidence that AI tools are “it” is the fact that every third ad I see on YouTube is for someone’s course on how you can making five-figures of passive income today. You and I both know THAT’s not going to happen.

So what IS AI good for? And what should we NOT be using it for?

For starters, since it’s probably at least ONE of the questions in the back of your mind, let me answer the following question: Greg, did you use AI to write this articles?

This article (nor none of my others) was NOT written using any AI tools.

I actually took a stand in my latest books against using AI to write any bit of prose. I even stated it outright, up front, for everyone to see, in the copyright page shown below of my first book to be published since my departure from the Spring team:

Soon after I released this book, Amazon added a REQUIRED prompt to the its upload process asking “Is this content generated by AI?”

People ARE writing books using AI. People are COMPLAINING about AI-written books. People FEAR the market being flooded with AI junk.

And I whole-heartedly agree that letting AI tools write your book for you is absolutely, 100%, as clear as I can say it WRONG.

I’ve been writing for years. I studied ad copy. Penned hundreds of blog posts, articles, and am have started what will soon be my 10th and hopefully 11th book (yes, I have two books in flight right now).

One of your most valued assets is the “voice” you develop.

Heck, I’ve had to push back on edits from a past publisher when they tried to “edit out” my voice!

This lovable, tech-oriented, snarky prose you are reading is 100% me. AI can’t replace that.

But I have to let you know…authors are pretty HORRIBLE at ad copy.

But Greg, why do authors need ad copy??

Ad copy is something that once you discover and learn what it is, you can’t help but see it. EVERYWHERE. It’s the stuff that reads kind of like “Grab your copy of 5 Ways To Do ___ and learn how to make money TODAY!”

That expression has some key aspects:

Action-based: Notice the comand to “grab”? This is a strong action.
Active: Notice usage of “you” and “today”? This is aimed at the person reading it, and creating a sense of urgency making it very active.
Appealing: Notice the drive to help the reader “make money”? This signals the value at taking on the offer.

If you’re going to write, you need a certain amount of this. After all, if you’re writing an article on Medium, you definitely want to convince someone seeing it for the first time to click on it. You just don’t want TOO much. Don’t want to sound like a slippery car salesman, right?

But you can see how ad copy is DIFFERENT than prose, right? Hence, authors can build up their prose-writing talent, but not know how to write ad copy. Not know how to write up a 1-paragraph pitch to convince an acquisition editor to convince them to give that person a book-writing contract!

Enter AI tools!

AI tools are GREAT at this:

Read this article and give me a 1-paragraph summary using middle school writing level ad copy that drives the person to click on the link at the bottom.

You type prompt into a tool like ChatGPT, then append your actual article, and in seconds, you have a nicely written up paragraph. It might be a tad off. Need a slight tuneup. But it’s probably better than what you would have written from scratch.

And this is a splendid usage of AI.

Were you going to hire someone to write it before the emergence of AI? Lots of authors don’t have much in resources, so probably not. You would have struggled to write it yourself, but that’s what you would have done.

Using AI to accomplish something you weren’t going to hire anyone else to do in the first place is probably okay.

Speaking of getting stuff done without having to hire someone else, check out the sponsor of this article…

12 Rules For Pro Coders is chock full of painfully learned lessons12 Rules For Pro Coders is probably the easiest way to grab someone else’s hard-won experience and using it advance your OWN career.

Grab your copy and learn from my mistakes with actionable advice to accelerate your career!

Now back to your fun AI article!

What about using AI at work?

As a content creator and training write in my current position, we have picked up and ran with AI tools!

In this context, its our team’s job to create slides, runnable exercises, write video scripts, and produce drawings. No one else. Us.

Remember how I mentioned hiring “someone else” up above? Yeah…that someone else in this situation…is just me.

We sit down, draw up the list of things we need to cover in a given course. We glean input from SMEs, field staff, and architects to curate that high-level list.

Then we fashion a multi-paragraph prompt where we describe the problem, explain “who” we are, explain “who” is receiving the training, explain what the output format is, and then feed it the list of material to cover. Then we sit back and watch it crank out a draft exercise.

With the exercise in hand, we deploy the newly minted exercise to our environment that runs it.

And then we test the HECK out of it!

Oftentimes, the prose is GREAT! And oftentimes, the code fragments are way off.

This is where we “do our job” and dig in to find out what the RIGHT way of doing each chunk of code (or each command).

There is still a LOT of work to get this challenge exercise operational. But the point is, we didn’t start from zero. No, we started at 40% with someone we can edit. We noodled through it, and were able to focus on the criticals.

The AI tool was able to help us knock out the prose and the structure, kind of like how an IDE can help you with formatting a Java class file including auto-generated getters and setters.

Is that it? Using a tool to skip over the beginning phase of something?

No.

We go way further than that.

Remember me mentioning slides earlier? We take our series of exercises and feed them back into the AI tool, and ask it to generate reveal.js/asciidoctor slides. The prompt has more details in it again describing who they are for, how the work with the exercises, and how we want to have Q&A review questions after the exercises.

And then the AI tool will crank out a round of slides.

And then we can iterate on THAT.

It’s really amazing how far you can get with this stuff. To top things off, we’ve noticed strengths in weakness in various AI tools. And we’ve figured out how to use them together.

To explain how that works, there’s a riddle you may or may not have heard of.

You are standing outside two doors. Behind one door is a vast trove of riches beyond your wildest dreams. Behind the other door is certain death. You can open either door. Next to the doors are two guards. They both know what is behind which door. One always tells the truth, one always lies. If you could ask one question, what would it be?

The answer is to ask one of them, “which door would the other guy suggest?” and then open the OTHER door.

If you are talking to the truth-teller, he will truthfully tell you that the other guy would lyingly recommend the door that offers death. So you pick the other door.

If you are talking to the liar, he knows that the other guardian will tell you the door with the riches behind it. But he will lie and tell you to take the door that portends your death. So you pick the other door.

You see, you are taking a shaky circumstance, and using BOTH of them together, to effect a positive change.

With AI tools, their strength is being able to process HUGE volumes of text and then give you a guided answer based on your prescription.

And so we will take the slide content generated by one AI tool, and carry it over to another AI tool and run it through a “finishing” process.

We basically have ANOTHER prompt where we instruct this finisher that its job is to “edit” the first AI tool. Don’t alter the structure. But help clean up any code blocks. Also look for glaring issues.

And in general, this has helped us crank out HUGE volumes of content.

Now remember the criteria I mentioned earlier! The only people getting displaced by this…is us! We are the team that is building this content. So any tool that helps us speed up the write-read-review-test-update process directly, is a boon!

What are you doing with AI?

Someone has to verify every spec of the content the crosses your desk. That someone…is you.

There is fear of these tools supplanting whole developers. That fear has some amount of justification. But there is going to be a growing number of people needed to cross-check and verify what is being generated.

AI isn’t destroying any industries. It’s just another tool that can accelerate some things. The idea is to learn its strengths, make certain principaled decisions about what to use it and not use it for, and then be comfortable in the places that you’re okay with doing that.

You’ve heard some of the ways I’m doing it (which includes generating banner images for these articles, someone I wasn’t going to pay anyone to do anyway). What about you? Have you used AI tools for anything? Put it in the comments!

— Greg

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out this video where I explain why the tech stack you use doesn’t REALLY matter as a pro coder!

Are you ready to commit yourself to being a pro coder in 2025?

Sun, 05 Jan 2025 00:00:00 GMT

There is a keen fact that separates hobbyists and amateur enthusiasts from career-seeking pro coders: hobbyists can stop and start whenever they wish. A hobbyist can carry out a tutorial, try out a new stack, or experiment with a new library recently released. This is true.

But a pro coder does all these things for the sake of their clients or the shop they work for.

There are naturally consequences to this.

We cannot stop and start as we wish.

While you should take breaks and re-energize suitably, you need to seek to move the needle. Drive things forward. Iterate on either a piece of code, a continuous integration job, or update the reference documentation even when we don’t feel the passion.

Sometimes you’ll be tired.

Sometimes you’ll be frustrated.

And sometimes no one around you will have the answer you seek. You must find it yourself.

A hobbyist in such a situation would set the issue on the shelf and go do something else. Perhaps another beginner’s tutorial. Or perhaps something else entirely.

A pro coder squints his or her eyes, feels a desire a PASSION to defeat the problem laid bare, and pushes forward!

We must learn all that we can learn

There is something called the arrival syndrome. A situation where you feel as if you’ve “mastered” some topic and that there is no more to learn.

The arrival syndrome is horrible and something that can take the most capable, most skilled people and let them decay into nothingness.

There is always more to learn. New stacks. New toolkits. New protocols. New WAYS of doing some of the old things.

I recently dig some digging into Cloudflare’s Zero Trust offering. I was interested in the possibility of accessing my RAID array’s internal Dropbox-equivalent FROM ANYWHERE ON THE INTERNET.

But I didn’t want to open any ports if possible. Zero Trust is a “newer” way of building a VPN. I have enjoyed Cloudflare’s other offerings, so I dug into Zero Trust.

I began reading docs. Configuring my home router in ways I didn’t know were possible. Gearing up my iPhone and my MacBook Pro to interact with Zero Trust. I’m not convinced it’s for me.

But the point is, I have learned new things despite having been in this industry for 27 years!

My favorite Christmas presents this year were three books. Two of them are Jack Reacher novels I haven’t read yet, the third being THE PIRATES OF MANHATTEN by Barry Dyke. I’m excited about all three.

If you’re still reading, there is hope for you. If you haven’t read for years, it could be a sign. Let me know in the comments when you last read something and if you’re bold enough, what it was.

In software development, the world changes rapidly. Learning is MUST. What you learned in college is probably obsolete if we’re talking about tech. But critical if what you learned include HOW TO LEARN.

AI is upon us. I have already began dipping into different AI tools to lend me assistance in content creation. I don’t use them to write the words you are now reading. But I sure as heck have leveraged it to help me create introductory content, Q&A post-session questions, graphics, even videos. We have no clue where this is going, but the potential for a revolution as great as the Industrial one is immense.

Don’t. Stop. Learning.

We must hone our craft with our tools

Have you ever wondered by doctor and dentists offices are called “practices”? It’s because while these people learned critical skills in medical school, it’s their daily work in which they PRACTICE their medical and dental arts.

As pro coders, we must practice as well.

This is why I am challenging you to explore working with at least THREE SPECIFIC IDEs this year. If you need a suggestion, I would recommend IntelliJ IDEA, VS Code, and Eclipse.

If you don’t use Java, but instead another stack entirely, you’ll have to make a different choice.

But the point is to pick up new tools and take them for a run. And to make it a real, sincere, learning experience, I suggest you commit to at least six weeks with each one.

The point is to learn how to navigate code. How to compile code. How to test code. How to “find” stuff. How to make the IDE serve you, and not you serving it.

You probably won’t learn all the hot keys. That’s okay. You’ll probably be less efficient than you’d like. Again, that’s okay. The point is to learn. To grow. To expand your knowledge.

Because when we practice learning, we become better at learning. And when it’s against something that truly challenges us, then the experience can a stronger effect on us.

Leave me a comment and tell me you’re going to commit. You’re going to try some new IDEs!

Are you ready for 2025? It’s here. It’s ready to throw you all kinds of curve balls.

Maybe you don’t have everything together. Maybe you don’t know all the answers. I’m not asking for that.

All I want you to do is be ready to GROW this year! Be ready to EMBRACE new things. Be ready to truly become a PRO CODER!

— Greg

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out this video where I chat with an old friend about some of the amazing/shocking AI trends that are hitting us from all directions!

Making rookie mistakes

Fri, 27 Dec 2024 00:00:00 GMT

As a pro coder, I made a terrible rookie mistake!

It was really embarrassing.

Just spent three days tracking down why my website wouldn’t let me enter edit mode… but my wife’s would!

Turns out that on Cloudflare I had enabled “Rocket Loader”.

I use Cloudflare because it has superior DNS management and lots of other great features.

I assumed that Rocket Loader was another great tool to deploy.

Turns out it was kind of like going into your Gentoo Linux machine and rebuilding everything with maximum GCC optimization switched on.

Might speed things up. But probably won’t work.

The webpage when I’d click “Edit” (i used Divi on all my websites), the edit spinner would pop up…

…and just keep spinning.

I disabled almost every plug-in I had on my website trying to figure out what had broken things.

Speaking of breaking things and putting them back together, check out the sponsor of this article…

12 Rules For Pro Coders is chock full of painfully learned lessonsI smart person learns from their mistakes. A WISE person learns from OTHER people’s mistakes. Grab 12 Rules For Pro Coders and learn from my mistakes with actionable advice to accelerate your career!

Now back to your regularly scheduled article!

I had even switched to “development mode” on Cloudflare!

Turns out that knob doesn’t disable EVERYTHING.

Truth is…I went too fast.

I kicked myself knowing I had just made this newbie mistake. I shook my head, upset with myself.

I had switched on Rocket Loader along with a few other optimizations without verifying it worked let alone sped things up.

And that was my fault.

As a pro coder we just always slow down and do things one step at a time.

Test one thing and verify it works.

Then test another thing. And another. And another.

Being a pro coder means taking your time and doing it correctly.

A series of correctly done steps and people that don’t code will thing your some kind if frickin’ genius. But you’re just moving things forward one step at a time.

It’s easy to say but this process requires discipline and commitment. Don’t make the mistake I made.

Test your changes. One by one.

— Greg

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out this video where I explain what the most IMPORTANT tool a pro coder can have!

I hate New Year’s Resolutions…

Mon, 23 Dec 2024 00:00:00 GMT

…and so should you!

If something is good enough to dedicate your time and energy, why wait until New Year’s Day?

For example, I saw this posted on Reddit the other day…

The OP is wondering if doubling down on SQL would be a good move for their budding career. (I’m assuming its embedded in a new-found love for SQL, a love I can certainly appreciate.)

To which my answer is an emphatic YES!

This person doesn’t need to wait until January 1st. They can start now!

What is something you either started doing this year…or delved into due to some task pushed onto your plate…and you find a sudden satisfaction doing it? (Share in the comments below!)

Whatever it is, don’t wait until 2025 to start doing MOAH!

And if I can nudge you a tad, consider making it a topic you start posting about on a weekly basis. Perhaps LinkedIn. Perhaps X. (Perhaps Medium??) Whatever is your favorite platform, I implore you to SHARE the fun you’re having by writing what you’re doing and why you’re doing it.

This is what is the gold that is social media. People sharing things they love. Not meaningless clickbait engagement tricks.

But NOTHING is drawing my attention this year!

I get it.

Maybe this past year (and perhaps the year before it) you drudged through some mind-numbingly boring stuff. Or perhaps you had to suffer working with a stack that wasn’t shall we say your cup of tea.

I’m not telling you to quit your job. But at least pause, perhaps use this holiday season to spend a couple hours, and review what you liked and didn’t like about this past year.

Spend some time and contemplate where things are going in your life. If it helps, consider creating a Google Document and making a 2-column table. List PROs on one side and CONs on the other.

Sometimes, that’s all it takes.

Writing down what you’ve done can make things clear where you want to go. From there, you can start to think about how to make the changes you want to make.

Is that possible at your own shop? Or is your future somewhere else?

Like I said, I’m not telling you to quite today. I’m just encouraging you to take stock of your current situation and formulate a plan. After all, this is your career.

Maybe the title of this article IS a little clickbaity. But the idea is sound. Don’t wait until the New Year is here. Start right now deciding what the future of your career will be.

Because no one else is doing that.

— Greg

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out this video where I explain why the tech stack you pick doesn’t really matter. And if you want to get content FIRST, then I encourage you to become a member!

What are you thankful for?

Mon, 09 Dec 2024 00:00:00 GMT

It was one year ago at the beginning of December that I felt a really BIG test thrust upon me.

I had been let go maybe a week or two earlier in the Broadcom acquisition of VMware and told I was no longer a part of the Spring team.

This wasn’t just a job…it was one of the best pieces of tech I had EVER worked on!

But that was over. And something that I was suddenly in the midst of was the fact that two of my kids had been picked to be part of the bible quizzing team going to the regional competition in St. Louis!

So I told myself that whatever angst I had, I would put it on the shelf and instead focus on spending time with them. After all, no one else was calling me up. No tickets. No pull requests to review. And I had keenly decided to NOT do any podcasting of livestreaming until the severance check (of which I qualified for the MAX, which combined with my accelerated equity option, gave me about 7 1/2 months of salary) was in my hands. I didn’t want to hand the incoming company any REASON to withhold that check. I doubted they would, but way put yourself into a position of playing defense?

So I loaded my two kids into the van, and off we went for a 5-hour drive.

And something happened on that trip.

Another family from the district, their dad was in St. Louis. Someone had asked me what had happened, and in mentioning Broadcom, his ears pricked up. So we started chatting over breakfast.

I came to discover that this guy had risen up through the ranks of network engineering and rigging up various systems. Eventually, he reached a point where we was principal technologist running a non-profit in the Greater Nashville Area.

And so I just shared my story. What I knew and had done.

I wasn’t interviewing, per se, but I needed to remember how to have a conversation from this perspective. It had been awhile since I had gone “job shopping” ( first was after college, second was to join the Spring team). This was my third EVER interviewing I’d be doing, so I figured I had to warm up to speaking techno lingo while ALSO being willing to share tid bits of my experience.

(BTW, if you ARE needing to interview to find a new position, I made this video FOR YOU!)

And no, this fine gentleman with whom we traded war stories was not my future.

But a couple weeks after that, someone ELSE…WAS.

Josh Long had introduced me to Doug Weatherbee, and despite insisting I wasn’t going to be rushing my resume into the hands of recruiters during the Xmas season (what recruiter is focused on their job amidst sleigh bells in the snow?!?), Doug and I ended up having a video chat.

It easily ran over an hour. And we easily shifted into shorthand discussing the industry, Spring, and more amazingly…CockroachDB.

Fast forward, a year, and here I am. Reminiscing about those early conversations.

I didn’t know what was going to happen. And I have friends and past colleagues going through some of the struggles. My heart goes out to them.

But I am incredibly blessed this Christmas season to have found a new home, to have written some really amazing content, and to have delivered it to a customer. All in this year.

I call that a great start. And I hope the best for you as well.

Merry Christmas!

— Greg

If you are a pro coder, or are planning to become one, then please subscribe to this newsletter. And if you want to get content FIRST, then I encourage you to become a member!

Do you code for profit…or for fun?

Mon, 08 Jul 2024 00:00:00 GMT

I don’t know how first came up with this attention-farming post, but have heard the question posted…

Do you write code for fun or for money?

This is absurd.

For starters, it’s a false dichotomy implying you can only be one or the other. You either code for money OR you code for fun. This is an arguing strategy I see far too often. The author is angling to get you to talk yourself into agreeing with them on some topic. Hence, they concoct the “opposite” of what is the “right” answer, and then proceed, probably with several strawman arguments, about how the “opposite” is wrong and what they started with is “right”.

And I’m assuming you KNOW this.

We ALL know this. We can see it from a mile away.

The real nut buried in this particular instance, is the idea that somehow, someway, making money is evil and wrong. And that if you are attempting to make money as a pro coder, then you are “impure” in some way.

I first saw this called out in the fiction. The author Derek Murphy in his work BOOK CRAFT mentions that too many authors have been told that “art” can only TRULY be art…when it’s not linked to revenue and profit.

And he summarily smashes the idea to pieces. It’s possible to have true, enjoyable art that you love. And to also earn a living doing it. In fact, the sooner you break yourself of that “starving artist” lie, the better off you’ll be. It will energize you and empower to REALLY make art. Instead of loathing it.

So why is software development any different?

There is a sense of “art” to that as well. I didn’t realize this until I began to observe HOW MANY members of the Spring team are also artists. Rod Johnson, Mark Fisher, Dave Turanski, Ben Corrie, Jeremy Grelle, myself (I play the guitar), and probably others that I’m not even aware of.

I once mentioned this, and someone on the team signaled that a software developer WHO ALSO embraces the artistic side the brain, can have a more holistic perspective on things.

And watching Rod Johnson play Chopin on the piano at a Spring Experience conference back in the day is truly inspiring.

It’s possible to engage in the art of software design, to work within the corridor of what a language demands while building something of beauty that serves multiple people.

And it’s possible to let people pay you handsomely for it.

If someone is hinting that accepting money is somehow wrong, then ask them if they perform their own work efforts free of charge. It’s okay to be paid for software, to be paid for TRAINING on that software, and it’s okay to be paid for other ancillary things surrounding the software.

And none of that precludes you from truly enjoying the process, from beginning to end, of PRODUCING that software.

In fact, this realization in myself is what has made it EASIER for me to pay others for software as well.

I once learned that Rod Johnson, in his attempts to sell Spring, had discovered that software developers tend to be cheap and stingy. He identified that you have to sell it to someone higher up. Fist bump that one. We do tend to be cheapskates.

I took me great effort to FINALLY pull the trigger on buying Final Cut Pro, the software I used to edit videos. I was sweating over shelling out $300.

Alas, it has become one of my favorite purchases ever. I use it all the time. It is powerful and effective. And I’ve learned to drive it in many scenarios. It’s okay to pay for software.

And so much so, that in their most recent release, where several key features + some rough bugs were ironed out, I DM’d a college friend of mine to thank him for that release.

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out this video and learn why investing in yourself may be the most important thing you do!

— Greg

Something NONE of us need!

Wed, 26 Jun 2024 00:00:00 GMT

There is a phenomena out there you may have run into, in one form or another…

The Arrival Syndrome

You’ve probably seen it in others. It’s scarier to see it manifest in yourself.

It’s basically a state of mind where you (or someone else) has a feeling of, “I’ve arrived!” It implies that you learned what had to be learned, you applied it, and now all is done and well.

So what’s wrong with that?

Simply put, it suggests a state of mind where you don’t have to learn any more. There is no more growing to be done. Almost as if everything is smooth sailing.

And that’s the problem.

There is a saying I first heard of in German:

Um ein Meister zu werden, muss man immer ein Schüler bleiben

Translated, it reads, “To become a master, one must always remain a student.” We must continue to grow and to learn. When we stop learning, then we began to atrophy.

As a keen example, I myself have studied and use SQL for years. I once had a textbook on ORACLE/SQL from college that I reached for all the time when I started working on a contract…in 2001!

Way back in 2001, I had no clue what a LEFT OUTER JOIN was. In case you didn’t know, that’s when the values on the left-hand side of the query are required, but the values on the right-hand side are optional. Suffice it to say, LEFT OUTER JOINs are used ALL THE TIME, so there was no NOT learning this concept.

By the time I left that contract to join the Spring team in 2010, LEFT OUTER JOINs were burned into my brain amidst other SQL and relational database concepts.

Another 14 years passes by, and I find myself as a technical content engineer with Cockroach Labs where I’m helping to fashion content to train our paying customers. This includes some of the most advanced SQL. Given CockroachDB’s distributed highly available nature, we are having to coach them on various SQL practices.

It’s in early 2024 that I first see mention of CTEs or Common Table Expressions.

Hmm. Never heard of that. Okay, I HAD heard of that, the previous year, when Hibernate 6 added CTEs to Hibernate Query Language and I modded Spring Data JPA’s query parser to handle them.

Time to study up on this technology…

…that became a part of SQL in 2001.

Gulp.

Way back when I didn’t know LEFT OUTER JOINs, CTEs had entered the arena. I knew nothing about them. It’s kind of humbling to get kicked in the gut like that after working in this industry for 27 years.

It’s vital that no matter how seasoned we become, no matter how much expertise we accrue, that we ALWAYS remain open to continued learning and growth.

The hard thing is, that requires a certain level of humility. Especially if the source of further growth comes from the next generation of pro coders.

But if you include learning as a key thing of being a pro coder, and make sure to not skip over present and future opportunies to keep learning, it will serve you well.

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out this video where it turns out, the tech stack you pick DOESN’T REALLY MATTER!

— Greg

Want to hear another story?

Tue, 23 Apr 2024 00:00:00 GMT

We all are given special gifts. Often time these gifts can sustain us, help us provide for our families and for others.

And sometimes, those gifts can serve a much deeper purpose.

This past weekend, I went down to visit my parents, who are now in their late 80s. I brought half of my YouTube studio gear with me. Cameras. Microphones. Tripods. Lights.

And I let my mother tell her story.

She has amazing memories back to before WWII. Times she spent with her grandparents, who were married in a state before that state joined the Union.

All my skills I’ve learned over the past five years at shooting and producing videos for you were now able to quickly and efficiently gather something greater than myself.

A recent reader of my latest book heralded my comments in the book that as SW engineers we carry certain duties to the profession. While I appreciate that reader’s words, this weekend I felt that I (we) carry an even higher duty to capture the past and preserve it for the future.

I have just transferred all the gathered video and stills onto my RAID array and am now importing it into a Final Cut Pro project where I can splice it together.

My father, since before I was born, has shot Super 8 films and taken literally thousands of photos. And I feel that I have now taken up a new mantle to carry on this duty to capture such memories in today’s day and age.

And as my parents have invested much in me to bring me to where I am today, I intend to invest hopefully as much into my own children, so that someday they can carry the torch forward.

This is what we all carry in some shape or form. A duty to serve those around us with the talents and gifts granted to us.

It may start with your job and your daily tasks. But don’t hesitate to help a friend, a family member, or a complete stranger when the opportunity presents itself.

I also had the chance to chat this weekend with a family friend I’ve known since I was quite young. He’s also a retired professor and someone I worked with during grad school. He’s also a pro coder.

He shaped much of whom I am today career-wise. He even got me in amateur radio.

When I saw him yesterday, one thing he said stuck with me. He said, “I’ve got a story for you. All I have now are stories.”

He said those words in a self-deprecating manner. But I realized in that moment, that if I were to someday reach his age, I too hoped that I would be filled with stories. Because stories are what really matter.

Our interactions with each other are what weave all of humanity together. That’s what is most important above all. Stories.

Do you have any stories? And what are you doing to make more of them?

— Greg

Returning to first principles…

Mon, 15 Apr 2024 00:00:00 GMT

Over the past few weeks, I’ve heard more than one person, from very different places, mention “getting back to first principles.”

First principles are axioms that we pin stuff to. Another way is to look at what your values are, and what flows from that.

As a pro coder, it’s easy to get sucked into processes, tools, concepts, and philosophies written by others. I mean come on, we can’t build this stuff all by ourselves. We need help! We need IDEs, compilers, frameworks, books, strategies, ticketing, tools, and gobs of other stuff to do this. So yes, we need others to help or nothing is happening.

But it’s also good, every now and then, to double check what we’re doing and compare it against our own values. One of the things I’ve reexamined multiple times is continuous integration. If you caught the latest episode of the Pro Coder Show, I went into detail about how I kind of sort of INVENTED continuous integration as one of my first assignments in my career.

But not really.

Let me put it like this…I spotted the value of building our system on a recurring nightly cycle in order to detect when errors would creep into the system. And that was useful. VERY useful.

And that fundamental idea has become a first principle to me.

Having joined the Spring team in 2010, I later became a part of its Spring Data department in 2017 and within a year’s time, took over as the manager of all their CI pipelines. I began migrating stuff off of our UX-heavy system (Bamboo) in favor of a source control-managed approach. I had already worked with Drone, Travis, and CircleCI and had seen I’d seen the pluses and minuses of various systems in various environments. I later shepherded Spring Data into using a Docker-oriented CI tool called Concourse. It had its own pros and cons, the biggest pro being its “every step inside a container” tactic, which I LOVED.

Simply put, containers provide the perfect tool to ensure the exact environment you wish a step to be executed inside is always there.

Nevertheless, it did NOT support another key thing I needed, branch builds. So after much analysis, I eventually migrated us to good ole’ Jenkins.

Suffice it to say, every time I dug in to solve another problem with a given CI solution, I constantly checked my assumptions and my values in that context and sought out the most critical axioms. And that is how I was able to set aside my accumulated distaste for Jenkins…and actually go back to it! (A biggie being that Jenkins now supported a source control-managed solution, allowing me to avoid its horrendous UX-based configuration!)

BTW something to take note of, is that no implementation of your values is ever perfect. Instead, you must understand your own thoughts and beliefs such that you can weigh any given tool against another and decide which is better. But be ready to accept that nothing will be EXACTLY what you seek.

The same goes for IDEs. I have seen lots of them. Years ago, I spotted certain aspects of IntelliJ IDEA that best fit my need for tools. What is your favorite tool? I spoke to one person that can’t give up VS Code.

I asked “why?”

“Because, I have all the hot keys wired into my fingertips!”

You may think that I’d either laugh or scoff at such an assertion given my adoration for IntelliJ IDEA.

Nope.

Picking a tool because of deep-seated familiarity is not bad reason. You know your tool. Inside and out. The current crop of modern IDEs generally support much of the same stuff, so if you can wield it with such intensity, no need to waste time moving off of it!

The point is when assessing tools, processes, and ideas, to try and spot the handful of characteristics that are most important TO YOU. Then…use them anytime you are evaluating something else.

What are YOUR 1st principles?

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out episode where I mention how I accidentally invented continuous integration!

— Greg

Most over engineered solution EVER…

Thu, 04 Apr 2024 00:00:00 GMT

I recently saw this “ah hem” challenge posted on X:

What is the most overengineered library/tool/framework/environment that you ever used at work? —Mario Fusco

I looked no further than my own coding experience to fine an answer

Early in my career I had read GoF Design Patterns.

It was read like magic! So naturally I had to use those patterns. I was that impressed by those incarnations of OOP.

So in my next project, a small one with few fellow teammates, I began using that.

All of them.

My solution was probably triple what it really needed to be.

And there was really no one there to tell me that what I’d built was ridiculous.

Later on when the anti-pattern movement arose and book after was published, I realized what a foolish decision that had been.

I have since become a bigger fan of “The Poutsma Principle”.

A tongue in cheek idea, it says that if Arjen Poutsma (creator of Spring @MVC and RestTemplate among others the things) doesn’t understand what you wrote, you’re probably wrong.

A more serious phrasing is to not do “cute” stuff but instead strive to make things as simple and straight forward as possible. And if you can’t find a less “hacky“ solution, perhaps you need to hold off on your supposed “solution”.

Complex and hacky solutions only put additional maintenance on our own plate and demand further hacks and tricks to sustain.

What about you? What’s the most over engineered thing you have done?

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out this video where I helped a fellow pro coder who fumbled an interview.

-Greg

Thank you, Spring!

Wed, 27 Mar 2024 00:00:00 GMT

14 years ago, a young coder with a wife and a baby girl, left his comfy, secure position and struck out to join the recently acquired Spring team. That someone was me.

My daughter’s reaction when I told here I was joining the Spring team!

I had never worked on such an elite team. I had been used to writing functioning code and shipping it out to our users. Of course I’d had feedback on proposed solutions and seen my handiwork reviewed to see if it was correct. But I’d never submitted code that was then “polished”.

I’d never done that before.

But here I was working for a team that was serving literally millions while my previous system’s users clocked in at less than 1000.

There was some awe being able to claim

I was part of this fantastic team. But there a much bigger dose of panic I was trying hold at bay!

And so I did my best to just listen to the feedback I received.

The Spring team is somewhat famous for “juergenization”. Some call it polishing. But that’s an oversimplification.

You see, the idea is to polish your code such that Juergen Hoeller (Spring founder and present lead developer of the Spring Framework) would approve your changes. Invariably, he would make a slight tweak…or a veritable rewrite (assuming your patch qualified) and make your code appear as if it had been there the whole time.

Over time, the more patches you submit, the more your work gets “polished”, it’s ultimately YOU that becomes juergenized. (Maybe I should write a book about juergenization itself? Let me know in the comments what you think!)

Today’s sponsor…

Coding isn’t just about algorithms. There’s more. A LOT more. CI, security, team communication, meetings, career tips, you name it.

I wrote 12 Rules for Pro Coders to give you actionable advice to accelerate your career. As a veteran pro coder, I want YOU to learn the same valuable lessons I did…but faster.

This advice has been put to the test. In my own process of being cut in the acquisition, I have actually leaned into what I wrote in the midst of coming up to speed on my new endeavor over at Cockroach Labs. This book can help you too.

So grab your copy and learn what your university or boot camp didn’t have time to teach you!

https://12rules.io

For several years I contributed not just tiny patches but instead whole features and new approaches to Spring HATEOAS under Oliver Drotbohm’s management. And I swear, not a single contribution was made without some form of juergenization. (Some called Ollie “mini Juergen”!)

I had constant feedback on style, structure, format, and purpose of every piece of code that I wrote.

But the Spring team doesn’t just polish code for fun…or sadistic pleasure. There is a reason.

Just like there is a reason that they often say “no” more often than “yes” to new ideas and new patches.

Spring is a slate of portfolio projects used around the globe by literally millions. For something to be absorbed into a Spring project means taking on a long window of maintenance and support. Because Spring doesn’t break users except in very strict and controlled ways.

The Spring team wants the upgrade experience to be smooth and easy. Patch releases should fix bugs…and just that. Minor releases may allow new features, but shouldn’t break existing behavior.

When I listened in on Juergen at a SpringOne conference birds-of-a-feather conversation, and heard him talking about Spring being “JDK 8 ready”, I was befuddled at what he meant!

So I did some digging. And found out that while it was baselined on JDK 6 at the time, it was being compiled using JDK 8 and had chunks of code that would activate to support various JDK 8 features like Optional return types for Spring MVC controller methods.

I didn’t know Java could even do such a thing!

I spotted places in Spring Data JPA where two solutions existed, based upon whether or not the JPA provider was on JPA 2.1+. What?!?

The more I learned and grew on the Spring team, the more I learned the levels of effort this team spent on this type of support for end users. A lesser toolkit might have simply jumped to the newer version of a given standard and called it a day.

But not Spring.

Part of this was borne of the fact that Spring used to be the underdog. They had to offer an overwhelming reason for people to turn away from “standard enterprise Java.”

And so they focused on user success. They focused on making it easy for developers to solve problems. After all, Rod’s vision for Spring was to reduce Java complexity and offer a better way forward.

And having such an ethos ingrained in me over the part 14 years has truly juergenized me.

When I joined Cockroach Labs and dove into all the content we are building for our customers, I began spotting places where we could improve things. I saw opportunities where I could apply lessons I’d already learned.

I saw the chance to begin juergenizing things here and affording our customers and community a better experience. And this is where all those years of continuous feedback to be now be turned to serve this community.

Thank you Spring team for honing my skills and desire to serve. Thank you for juergenizing me.

If you are pro coder or aiming to become one, then stay tuned for my next article. But if you simply can’t wait, then check out the video below where I talk about exactly what you must do to get promoted or received a merit increase!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about PRO CODING? Then SIGN UP FOR MY NEWSLETTER.

I survived the first three weeks…

Tue, 12 Mar 2024 00:00:00 GMT

…and you can too!

If you aren’t aware, last year while writing the manuscript for 12 Rules For Pro Coders, I penciled down tips on what to do on your first day a a pro coder at a new position.

I then went on with suggestions about the first week, first month, six months, and a year.

And then Broadcom decided to lay me off.

After securing a new position and starting last month, I felt like everything I had written down in that chapter of my book was being put to the test.

To catch you up, here are some key tips if you find yourself in new position.

1. First Day

On your first day, you should focus on getting hooked into your company’s email, instant messenger (Slack, etc.), and other systems.

Focus on filling out any paperwork they send to you. Whatever they give you, whether it’s a meeting invite, a video to watch, or a something to read, focus on completing it.

No one will be asking you to write software on Day 1.

Above all, listen. Your immediate manager will probably do most of the talking. Just take notes. No one is expecting you to memorize anything.

Start drinking from the firehouse…and while it may be a little crazy, enjoy it.

2. First week

For starters, do you have a work machine yet? That’s pretty important, right?

If they haven’t gotten one to you, then either reach out to your manager, or perhaps they have you linked up the system administrator. Someone should be facilitating getting you set up like this.

Assuming you DO have a work machine, have you grabbed a copy of the repository you are going to be working on? I suggestion you simply find time and start reading the code. Or the build files. Perhaps they have a Jenkinsfile spelling out their pipelines.

Start trying to drink in the information. You’ll have to get warmed on it sooner or later.

At Cockroach Labs, I have been assigned a “roachmate”, someone that meets with me once-a-week. On my first meeting, this person walked me through the high-level fundamentals on how CockroachDB works, and that helped massively.

Do you have a partner to check in with?

To top things off, my manager has a “Welcome” Google Doc with a stack of things to start working through. This might be a good time for you to do the same.

Today’s sponsor…

Coding isn’t just about algorithms. There’s more. A LOT more. CI, security, team communication, meetings, career tips, you name it.

I wrote 12 Rules for Pro Coders to give you actionable advice to accelerate your career. As a veteran pro coder, I want YOU to learn the same valuable lessons I did…but faster.

So grab your copy and learn what your university or boot camp didn’t have time to teach you!

https://12rules.io

3. First month

I’m three weeks in to my new position, and so far, I’ve been able to effect some actual change. The team I’m on is responsible to writing all the educational content, whether that’s for customers or the community.

I spotted an area that would benefit from a readjustment of tools. I cloned the repository the slides were in and then dug in and learned how to build the content. Next, I created a branch and applied my tentative tool change. Finally, I put together a short proposal and pinged them on Slack to ask about scheduling a meeting.

At the same time, I’ve dialed into a few reviews and given my $0.02. I had some tidbits to share, while at the same time, I was listening and paying attention to how they create graphics, how they conduct reviews, and have been making note of what everyone’s skillsets are.

At the same time, my manager and I have booked a couple meeting each week where we just talk for about an hour. In essence, he’s warming me up to where the plans are, where the outlines are, and how that ties into their ticketing system.

Basically, I’ve been learning the processes this team uses.

I encourage you to do the same. You can always ask your manager if you can have a chat, whether its to learn something, or if you just have a question.

4. First six months

I’d like to comment on this one, but like I said, everything I wrote down is being put to the test.

When my six-month mark at Cockroach Labs rolls around, I’ll share the results!

If you are pro coder or aiming to become one, then stay tuned for my next article. But if you simply can’t wait, then check out the video below where I show how you CAN interview for a new position even in the midst of a struggling tech sector!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about PRO CODING? Then SIGN UP FOR MY NEWSLETTER.

As a pro coder, it’s ALWAYS valuable to collect skills

Thu, 07 Mar 2024 00:00:00 GMT

“Is it okay to study Java?” Yes!

“Is JavaScript good to learn?” Yes!

“Is there any benefit in learning CSS?” Yes yes yes.

The answer is almost always an emphatic yes.

Years ago, I dubbed myself a “JavaScript Padawan”. That’s because several years ago, as part of a side role on the Spring team, I was able to work with John Hann and Brian Cavalier, two JavaScript masters who taught me MUCH.

A skillset I have used rarely has once again come back to serve me today!

I am investigating the usage of Asciidoctor.js + reveal.js in a Node.js environment for some top-dollar content creation, and I’m the one with The Knowledge™.

You’ll never know when a skill will serve you.

Don’t hesitate to keep on learning. “Arrival syndrome”, the feeling that you have learned all that there is, is insidious and will tell you “Don’t worry about that. You won’t need that.”

EVEN IF you never leverage that new skill EVER, the very process of learning it can enhance your ability to learn, your ability to see how that product influenced other products you DO use and obtain deeper understanding, and your ability to keep on growing, a vital thing we must all pursue.

But in this industry, things often come full circle. Opportunities open up and the one with the skill may be able to offer a solution where none was found before.

Be willing to learn that toolkit or that technology. In today’s searchable/AI-empowered world, when you seek out the ref docs someday in the future, it will be a snap to find them and get kicking.

I may have dropped “JavaScript Padawan” from my tagline, but I will always treasure having learned that crazy language and being able to use it to serve my team. I will always feel like I’m a JavaScript Padawan thanks to those two guys.

Now what skill are YOU being offered a chance to go and learn? Do it!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about PRO CODING? Then SIGN UP FOR MY NEWSLETTER.

“How do you deal with imposter syndrome? Asking for a friend… really.”

Wed, 21 Feb 2024 00:00:00 GMT

I first saw this question on Twitter, so I wrote the following response, sharing someone I had really done to help myself when I was squeezed into a corner. And amazingly, it helped me BEAT imposter syndrome!

I started a Google Doc where I log what I do on a daily basis. Not deep. Just track tasks as bullet points. You should do the same.

Worked a ticket? Grab a link to it. Read an issue? Grab a link to it. Had a meeting with someone? Write it down.

Real easy to track daily tasks in short, summary form, newest stuff at the top. Headline every day.

Commit to doing this everyday. It’s a new habit, so you may stumble, skip some days. That’s okay. Get back up and try again. Work to make a habit over the next 30 days. You can do this. This document is JUST FOR YOU.

Now here’s where it begins to pay off.

After a couple months of doing this, just pause. At the beginning of your day, before you lift a finger, just glance at your log of activity. Scroll your eyes down the page. That’s everything you just did over the past three days.

Want a little more? Start scrolling the page. A week’s work right there within seconds.

Haven’t looked in a while, go further back. Pages of actions YOU TOOK.

Your memory will fail you. Your attempts to “motivate” yourself will fail you from time to time.

But maintaining a running log of every contribution you make, big or small, won’t. Instead, you can SEE exactly what you did.

Because it’s not about knocking out big ticket items every day. It’s about generating a certain amount of momentum for your team, built up out of lots of tiny tasks that you are deliberately picking every day.

When I started doing this, whatever sense of Imposter Syndrome I did would evaporate in seconds.

And that’s not all.

This log begins to serve you in other ways.

Too many big ticket items lately? Perhaps today is a day where it’s too hard to focus on that sort of stuff? Switch to grooming your backlog of tickets. Log ’em all. Do that for 2–3 days. Clean up tickets/close tickets/resolve tickets. Log ’em all.

Seeing several days of dispositioned tickets is cool.

After a few days of that, you’ll find that such menial labor will have allowed your “big” thinking energy to charge back up.

That’s not all.

Your manager, from time to time, perhaps just once a year, will come by and ask, “What is the big stuff you did this year?”

He/she needs to attend that manager meeting where he needs to defend you.

“Can you give me an hour?”

Skim through your log of activity and try to spot all the key tasks you did over the last year. You can also tabulate HOW MANY tickets you cleaned up.

Put together an email to your manager and list it out.

“Hey boss, there’s the big stuff I did. A) I built that new parser with ANTLR, B) I upgraded the system to handle Whatchamadigit 2.0, and C) I cleaned up 58 tickets, reducing the backlog from 10 pages to 5. If you need more than that, let me know!”

To do that, you have to start today. And you have to commit. Want more tips like that? Check out https://12rules.io.

If you are pro coder or aiming to become one, then stay tuned for my next article. But if you simply can’t wait, then check out the episode below where I shared a handful of actionable tips to grow your career. In the meantime, go out there and be professional!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about PRO CODING? Then SIGN UP FOR MY NEWSLETTER.

The most important thing no one discusses in engineering!

Wed, 07 Feb 2024 00:00:00 GMT

During my senior year of computer engineering at Auburn University I had I take this one quarter course (yes, AU was on the quarter system back then).

It was almost nothing. And yet…it’s everything.

I studied Engineering Economics, and something that only took me nine weeks of study, its concepts and equations are something I reach for all the time, both in work and in life.

The name of the course and the corresponding textbook doesn’t do the subject justice, You see this is the class where I was introduced to TVM, the Time Value of Money.

The bedrock concept is that any payment has a present value (PV) as well as a future value (FV). For example, if you had:

$100 today.
You were to put it in a bank account with a 7.2% yield.
According to the equation FV=PV*(1+i)^n, it’s value in 10 years would be $200.

Where TVM begins to sizzle is when you take this simple equation and then dream up bigger scenarios.

Imagine 10 consecutive cash flow payments where each year you put $100 into that same bank (7.2% annual interest). The first payment has 10 years to grow, just like before. Now if we’re talking about figuring out the value of things in ten years, like the previous example, then the second payment of $100 only has nine years to grow. The third payment will only have eight years. Rinse. Repeat.

Using the equation above, you can grind through all ten cash flows. I realize that’s a chore, so I’ll go ahead and derive the sum future value for you as $1394.

On top of that, using the very same equation, you can handily equate this to a present value of $695. (We sometimes describe this as net present value, implying a sum of cash flows valued in present-day dollars)

Essentially, you can either set aside $695 today, or you can set aside $100 a year for ten years, and reach the same future value. To turn that around, ten payments of $100/year at 7.2% are equivalent to a $695 net present value.

If you ever go to one of those financial services company that offers to convert your “structured settlement” into a lump sum, you should understand that they KNOW this equation backward and forward. (Ever seen a J.G. Wentworth commercial??) Their whole business model is to turn those cash flows into a net present value and then buy it from you at a steep discount!

“Can you really wait for that $100/year payment? I’d be willing to pay you $400 right now! It’s your money. Use it when YOU want it!”

Just to hammer the point home, accepting $400 for that cash flow would cost you $592 of future value, or $58/month in annualized payments. Ouch!

Just so you know, there is actually a calculator from the 1980s that can do TVM on the fly. You enter all the variable but one, and it solves for the other (notice the top-left row of buttons down below). Present value, future value, payment, interest, or number of payments. It’s called the HP-12C (the “12” is important). You can still buy one on Amazon for a measly $38 (affiliate link). Or just do what I did and buy the $10 iPhone app equivalent.

Wasn’t this supposed to be about engineering, Greg??

Yes.

We can build all kinds of things, but we aren’t talking pure research. We’re talking engineering. Engineering involves buildings things COMBINED with economics.

To practice sound engineering, we need to not only develop the technology, we must analyze its economic impact. This means we need to translate things into dollars.

Every effort, every task, every investment can be translated from technology into dollars. All of our efforts, once converted into cash flows, can be assessed as to whether we’re working at a profit or a loss.

Many people balked at Cloudflare’s firing of a sales executive that had barely completed her onboarding process. I disagreed with that reaction. Strongly.

Companies operate based on cash flow, not good intentions nor by accumulating assets. If a new hire isn’t able to move the needle on cash flow, then it doesn’t matter how “well” they did at onboarding or much of anything else. To be honest, Cloudflare may have ramped up too many sales execs too late, and her fate may have already been sealed.

When it comes to engineering, it’s vital that all the various efforts at play MUST be transformed into cash flow and then viewed at how things are stacking up.

A team may be willing to invest in two years of negative cash flow because they are aiming to turn a profit in the 3rd year. The total cost of all those cash flows, once tallied up and converted back to net present value can inform management on whether or not the raised capital is sufficient for that investment. See?

The sooner you as an enginer grok this concept, the sooner you can speak on management’s level, and begin to make decisions that perhaps better impact cash flow of the business. Ultimately, it the business doesn’t succeed, there will be no engineering. We as engineers need to understand where little tweaks in efficiency will subsequently get applied to every cash flow, and how that may turn a loss into a profit.

We must also realize when we’re building something “too perfect” and causing the repeating cash flows to be come too heavy, hence turning a future profit into a loss.

This is what engineering is about. If you don’t grok TVM, then you may still be in the “junior” camp. One of the most important skills to pick up and understand is to how think in dollars over time. And this is why ALL pro coders benefit from understanding these concepts.

If you are pro coder or aiming to become one, then stay tuned for my next article. But if you simply can’t wait, then check out the episode below where former Spring advocate Mark Heckler and I discuss what it really means to invest in yourself. In the meantime, go out there and be professional!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about PRO CODING? Then SIGN UP FOR MY NEWSLETTER.

Docker — What is it good for?

Sat, 23 Dec 2023 00:00:00 GMT

Docker — What is it good for?

Docker is one of most useful technologies to befall continuous integration. Containers empower you to define precisely what tools are available in every stage of your CI pipeline without battling CI configuration stuff.

Consider this: in the olden days, if you wanted a new version of Java, you had to enlist your sys admin to install it into your CI tools. With Docker, you just update the container! (Or bake a new one.)

Of course, this requires a certain trust between you and the sys admin. It’s also advisable to have team agreement on certain things, like consistently using the same Java distribution across your team. Mixing distributions among other things can introduce risk.

But leveraging containers to encapsulate aspects of test infrastructure and putting those container definitions along with your pipelines under source control can wrest control of your entire CI process away from clicky buttons and effectively make it all “code” that is reproducible and much more manageable.

If you are pro coder or aiming to become one, then stay tuned for my next article. In the meantime, go out there and be professional!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about PRO CODING? Then SIGN UP FOR MY NEWSLETTER.

What is a pro coder’s most important tool?

Fri, 01 Dec 2023 00:00:00 GMT

What is a pro coder’s most important tool?

It’s not a grab bag of programming languages, though speaking multiple languages is useful.

What is a pro coder’s most important tool?

It’s not a grab bag of programming languages, though speaking multiple languages is useful.

It’s not that shiny new M3 Max MacBook Pro maxed out in cores & RAM with the 8 TB internal drive either. (Want to see how quickly Apple turns this article from edgy to antique with their high speed rollout of Apple silicon?)

And it’s CERTAINLY not that that Samsung 49” curved monitor (which can double as a boat anchor in an emergency!)

Nope.

While those are powerful tools, there is something else of much greater value. In fact, it’s such a powerful tool, you can’t buy it. At least not directly.

This asset that will pay ever increasing dividends for the life of your career can only be possessed when you invest your own personal time.

Professional relationships.

The people that you meet and serve as you forge your path are the most important thing you can add to your portfolio.

Remember how I said you can’t buy it with money? That’s true. Only an investment of genuine and sincere time will grow this bountiful asset.

You see, the thing this world runs on isn’t money or greed, though it’s easy to see the cynical side of things. This world runs on value creation.

When you provide value to others by solving problems for them, they will appreciate it on a deeper level than any business transaction ever can. As coders, our job is to solve problems for others. Look for ways to help others, to provide value, and eventually that genuine investment will pour back into you.

Remember me saying sincere investment earlier? It’s true. If you take a shallow approach of helping something simply to bum a favor off of them, it won’t work.

You can smell someone using you like that, right? Well other people sense the same coming from you. So put aside what you need right now, and instead simply listen. Find out what they need. And strive to meet that need.

Sometimes you’ll get paid right away. Sometimes you won’t. Sometimes you won’t see anything came your way for years. Or perhaps never, from that person.

But I promise, if you take a general attitude of serving others, of providing value to others and not sitting there with your hand out at the same time, but instead sincerely serve everyone you meet, you will witness a flow of abundance back to you over time.

And truth be told, as much as coding is about computers, it’s more so about the people using the computers. When I adopted an always-test approach to a non-functioning invoice reconciliation app and held true to that standard, it took me five months to get it working. But once I did, it began to gain momentum.

As excited as I was to see that growing sea of green checkboxes, it wasn’t until months later when I stopped in the break room and ran into once of people from accounts payable that used it. She remarked how the latest version of that app had let her finish ten invoices that morning. Something that she used to have to do manually and would have taken 2–3 weeks.

The look on her face and the excitement in her voice made it clear to me that this app wasn’t about me. It wasn’t about the tech it was written in or what patterns had been used.

It was all about the value afforded to a fellow colleague.

And that realization has forever steered me toward seeking the value I can provide to others on each and every task.

And when you build a career out of providing value to others, and you are in a pinch, it becomes a lot easier to ask for help. Because now it isn’t about business and money. Now it’s about the genuine value they can offer you when you truly need it.

If you are pro coder or aiming to become one, then stay tuned for my next article. In the meantime, go out there and be professional!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about PRO CODING? Then SIGN UP FOR MY NEWSLETTER.

Don’t be afraid to take a shot!

Sat, 07 Oct 2023 00:00:00 GMT

Don’t be afraid to take a shot!

A couple weeks ago, I pinged our fearless leader. I needed some direction before taking on a couple tasks. One of these tasks I was…

Don’t be afraid to take a shot!

A couple weeks ago, I pinged our fearless leader. I needed some direction before taking on a couple tasks. One of these tasks I was thinking about, which seemed tiny at the time, I joked “for THAT one, perhaps I should write a parser?”

He rolled his eyes. “We don’t need a parser.”

Two weeks later…

Spring Data JPA has a handy feature where you can dynamically feed it ORDER BY clauses with simple strings, e.g. Sort.by(“firstname”). This nicely gets turned into a JPA Criteria Expression object.

In the simplest of cases, this is an entity type’s property name. However, we have always offered this escape hatch where you can feed it ANYTHING. For example, you could feed it LENGTH(firstname) as your criteria to apply an ORDER BY to a query, where you order things not by the row’s firstname but instead by the length of the row’s firstname. Basically, anything that your JPA provider supports.

In my pre-op analysis, I uncovered a seemingly endless supply of hacks and workarounds on StackOverflow.com. I was beginning to think that this feature NEVER worked!

Quite naturally, as a test-bitten script junky, my first step was to write a test case. LENGTH(firstname) seemed like the textbook scenario that perfectly captured the situation while being easy to reason over.

Right there, in the middle, you can see LENGTH(firstname) nestled in the midst of JpaSort.unsafe(). To be clear, this query essentially says “find all objects and order them not by their firstname, but instead by the length of their firstname. (This query also has a paging argument, which I won’t delve into).

With this tasty string value at my finger tips, I cracked open JPA’s CriteriaBuilder interface and began scouring it, looking for the place where you feed it a string like that and get handed back an Expression.

There was none to be found.

You see, if you have a simple entity property like firstname, then you can submit a from.get(“firstname”) call. The from object is the root entity (User in this test scenario). from.get(“firstname”) is turned by the Criteria API into ORDER BY User.firstname.

But any sort of “parse this string” doesn’t exist!

My eyebrows narrowed. Having tamed the beast of HQL a few months ago with the power of ANTLR, my thoughts of writing some type of parser rapidly shifted from humor toward seriousness.

And then a lightbulb went off.

I didn’t have to write a parser. I already HAD a parser! The HQL one I had written months ago. You see in ANTLR, there is no requirement that you enter a parser at the “top”. That’s only required if you are parsing an entire query.

In this scenario, I only want to parse from the ORDER BY clause, which for HQL is the sortExpression.

In HQL parsing, it’s technically ORDER BY sortedItem, which sortedItem including things like ASC and DESC. However, our JpaSort already takes on aspects like direction, so I must enter one level deeper, the sortExpression.

And thus a method was drafted!

This is standard entry into ANTLR. You craft an HQL lexer to turn the string value of the JpaSort’s property value into a series of tokens. You then feed that stream of tokens into an HQL-based parser, and finally “visit” it by invoking the sortExpression() method in the ANTLR-generated class.

Hanging this inside a newly minted HqlOrderByExtractor class, with copies of JPA’s CriterialBuilder and From, I was ready to begin.

But WHAT was I ready to begin doing?

Simply put, I was going to write a brand new ANTLR visitor!

ANTLR has two ways to walk through a parsed structure. The visitor pattern is the only one that gives you one method to handle entering and exiting a given token, hence this was it.

The previous ANTLR visitor I wrote for fully parsing an entire HQL query is based upon transforming one string into another. That’s not what we’re doing here. Instead, the mission here is to transform an ORDER BY clause into a Criteria API Expression.

And away I flew! It turned out to not be that hard to capture our leading example of LENGTH(firstname) and turn it into an Expression. The code itself may appear tedious to those unfamiliar with ANTLR’s visitor paradigm, but for me, this was old hat.

I had that function working within a day. The question shifted to what OTHER expressions did HQL support?

A. Lot.

The screenshot below is but a sliver of the test cases I wrote.

You can really write an HQL query with ORDER BY CASE firstname WHEN ‘Oliver’ then ‘A’ ELSE firstname end, where if the firstname matches Oliver, it will swap in the value A, and otherwise it will simply use the row’s firstname, all for the purposes of ordering the data.

Once I captured all these scenarios and implemented them, I moved on to coding support for JPQL (Java Persistence Query Language) as well EQL (EclipseLink Query Language).

In the interests of bringing this article back to this world, suffice it to say, I spent another four days writing tests and implementing them. I even wrote some special test utilities that helped me “hide” Hibernate as well as EclipseLink from some of our classpath checks, making it a snap to verify our supported JPA providers.

After almost entire day spent simply polishing my changes, renaming things, and writing suitable comments, I submitted a pull request to our team leader. He happened to be on PTO the week I did all this work.

And perhaps that’s a good thing.

His absence provoked me to take this shot and implement support for a feature that looks as if it may NEVER have worked. And I’m quite proud of being able to leverage the knowledge I attained in building our HQL parser in the first place.

And I hope this provokes you to consider taking a shot on something that may at first sound like a lark, but could be the turning point in a system you are working on.

To be a pro coder, you sometimes have to take that shot.

Not a reckless gamble, but instead a fair minded attempt at something that may take more than a day to even figure out if it’s plausible. But an attempt that if successful, may be a turning point in the system you’re working on.

Because that’s one of the defining differences between a hobbyist and a pro coder. Pro coders implement things that aren’t always the easiest nor straight forward. But sometimes because we have little more than a hint that this may be the right thing to do.

If you are pro coder or aiming to become one, then stay tuned for my next article. But if you simply can’t wait, then check out this video below where Josh Long and I shoot the breeze over Spring Data during SpringOne @ VMware Explore in 2023.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about PRO CODING? Then SIGN UP FOR MY NEWSLETTER.

Have you said “thank you” to yourself lately?

Sat, 17 Jun 2023 00:00:00 GMT

Have you said “thank you” to yourself lately?

“What? Say ‘thank you’? What kind of column is this, Greg?”

Have you said “thank you” to yourself lately?

“What? Say ‘thank you’? What kind of column is this, Greg?”

I am trying to share with you some of the most important things you can be doing as a pro coder, and stopping to thank yourself is pretty high on the list!

When we slug it out, day in and day out, writing code, crafting automated tests, tracking down bugs, and working on releases, there are days when you’re flat out beat. Sometimes at the end of the day, your brain dissolves into goo.

Hopefully, writing the code is loads of fun and very exciting. Doesn’t mean it also doesn’t wear you out.

And so it’s OKAY to stop every now and then. Maybe this hour or the next, and say “thank you” to yourself. But I’m not talking about words. I’m talking about something a little more substantive than that.

It’s okay to stop and read another chapter of that latest book you’re on. (I’ve been reading Humble Pi by Matt Parker lately.)
It’s also okay to pause and watch a video from your favorite YouTube channel. (I love physics videos and calculus videos. Go figure!)

I’d mention stopping to check out your favorite social media for a bit, but there is a greater risk you’ll start scrolling and suddenly get sucked in for the next hour!

Taking a few breaks throughout the day and rewarding yourself with something enjoyable (but not TOO long) is OKAY.

I once met with someone that point blank told me it was okay for ME to take breaks like this. I…didn’t realize I was so instinctively apprehensive to the thought of taking breaks like that. But somehow, TELLING me it was okay brushed that aside.

Anytime I feel the slightest hint that I shouldn’t be doing it…I remember that voice. And I smile a bit. It’s okay to take a break. And so I’m telling YOU the same.

Anytime someone suggests you shouldn’t do it…tell them I said it was OKAY. Because we have an important job to do. That code requires the best of us, and taking a break to replenish your energy is actually a Good Idea.

We can’t operate systems if we’re hobbling along. It’s vital to eat, rest, and replenish our mental, spiritual, and emotional energies. If taking a break to read a chapter or watch a video is what it takes, then that’s what it takes.

If you dig Spring Boot and learning about being a pro coder, then please stay tuned for my next article. But if you simply can’t wait, then check out this video below where I get to the bottom of what it takes to make yourself absolutely indespensible to your team.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

I have to admit…Spring Data is ACTUALLY my favorite Spring project!

Sat, 10 Jun 2023 00:00:00 GMT

I have to admit…Spring Data is ACTUALLY my favorite Spring project!

I know I’ve previously written about how Spring Security just might be my favorite project. However, that opinion had to be put on the…

I have to admit…Spring Data is ACTUALLY my favorite Spring project!

I know I’ve previously written about how Spring Security just might be my favorite project. However, that opinion had to be put on the shelf when I realized that Spring Integration might actually be my favorite project. It’s really tough to hold onto that opinion when I stopped to realize how Spring MVC might be favorite project.

But I’ve been thinking real hard since I wrote those articles. And I have to be honest. Truthfully, spiritually, ecumenically honest.

Spring Data is ACTUALLY my favorite Spring project.

Spring Data is the thing that makes application development really sizzle. Why? Because every application has data. What kind of app doesn’t?

The number of times I’ve needed some quick-and-dirty solution to grab a piece of data, Spring Data lets me jump right to it using custom finders. Custom finders let you define all the details of a query with a simple method signature. No implementation. No Hibernate query. No SQL query. Just a method name and the parameters. Spring Data will write the query for me.

Just look at this example. These are three different custom finders.

The first one fetches a List of User domain objects based on a complete match of the firstName field. The user supplies not just the firstName, but also a Pageable, meaning you can pick the page of date you’ll get back.
The second one fetches a Page of User domain objects using the same page-based filtering. But instead of matching on a single firstName, it instead does a WHERE first_name IN (:firstNames) type criteria, allowing you to find multiple matches.
The third one is much more details. It find the first three User domain objects that match the firstName exactly against a result set ordered by firstName ascending and emailAddress ascending. But does it through Spring Data JPA’s new scroll API, meaning that you can fetch a Window of data, then move to the next window smoothly, and without being confined to the same page size for each iteration!

Just stop and try to imagine the time it would have taken using good ole’ JDBC to do the same!

You would have to open a connection to the database.
Come up with your query. Probably have to consult the team’s ER diagram. Make sure you have an entity object that maps to all the fields. With the query put together, which might take some testing against in a SQL shell, you could then plug it into JDBC.
Next you’d have to iterate over the result set handed back to you. If you were smart, you’d be using JdbcTemplate and simply define a mapper. But still, that’s a lot of effort. As you iterate, you’d have to populate the target data type. Notice how each method above has a slightly different container?
Then you’d have to close the result set.

Did I miss anything?

Oh wait! You also have to close the connection! (How many times have you fumbled over that?)

Spring Data JPA lets you step over ALL of that and begin thinking in business terms. Now I admit that JPA gives you a leg up by taking away the need for doing all the result set mapping onto domain objects. But nevertheless, there is a still a process to do that dance with the entity manager!

With Spring Data you can move right to the point of speaking in business-speak and writing the results that you want, while letting Spring Data “figure it out.”

But this is where Spring Data is just getting started. There are so many other options should you need them. For example, if you have a search box on your web page where the user can enter anything into any field, and you really have no idea what is filled out and what’s not, then custom finders aren’t the way.

This is the PERFECT scenario for Query by Example. This is where you fill out a “probe” with the inputs provided from the search box on your webpage.

When you turn it over to Spring Data, it simply matches on the fields that aren’t null, and ignores the rest. This pushes power into the user’s hands and takes the responsibility off of you.

Spring Data also has the ability to simply let you write the query, if you already know it, using the @Query annotation. And given Spring Data JPA’s recent addition of both JPQL and HQL parsers, it can still support flexible sorting options.

In a world where everyone and their cousin is learning a new web-based toolkit every week, and where security certifications and training is turning into an expensive, time-consuming beast to build your skill set, there lies a glimmer of hope.

That’s because if you can learn how to query for data, how to store it & fetch it at will from any database, and how to turn business requirements in database actions, you can make yourself incredibly valuable to your team!

And with Spring Data on your tool belt, it’s not as hard as perhaps it once was ages ago.

If you dig Spring Boot and learning about being a pro coder, then please stay tuned for my next article. But if you simply can’t wait, then check out this video below where you can get a deeper dive into EXACTLY what Spring Data has to offer.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Now that I think about it, Spring MVC may be my favorite Spring project!

Sat, 15 Apr 2023 00:00:00 GMT

Now that I think about it, Spring MVC may be my favorite Spring project!

I’ve said before how Spring Integration may in fact be my favorite Spring portfolio project.

Now that I think about it, Spring MVC may be my favorite Spring project!

I’ve said before how Spring Integration may in fact be my favorite Spring portfolio project.

While true, I simply can’t go any further without bringing up Spring MVC.

In case you didn’t know, Spring MVC is part of the Spring Framework, the origin of Spring’s goodness. And Spring MVC has been a core item for years. So no, it’s not a portfolio project. Nevertheless, it’s really hopping good!

Why is it possible my FAVORITE project? Let’s find out.

### 1 — Powerful support for any web app, with or without JavaScript

The web development landscape is ever-evolving. Heck, I’ve written past article citing the crazy game where you pick a noun and enter that word + “javascript” into Google, to see if there’s some Node library by that name.

As funny as that may be, we can’t ignore trends in the front end market. It’s vital to stay on top of them. And what’s key, is knowing that whether you’re building a lightweight app or a feature-packed behemoth, Spring MVC has your back.

Spring MVC offers unparalleled support for web applications, both with and without JavaScript front-end toolkits like Angular, React, or Vue. Those are the biggies, but frankly, and Node toolkit you need, you can integrate into your application and make it work.

When I was writing the web chapter of Learning Spring Boot 3.0, I frankly wasn’t sure where to start!

In prior editions, I had gone a tad too deep for what people expect from a Java-based book. So this time around, I sought to show the basics of how to stir in some Node-based code and get it off the ground. Where you take it is up to you.

That’s because Spring MVC frankly doesn’t care WHAT you put in your front end. Whether it’s a bunch of JS that violates every rule about globally scoped variables or something that upholds the highest standards of ES5 modules, Spring MVC won’t get in your way.

Its role is to integrate rock solid HTTP standards into your flow and make them work, and by golly, it does just that.

The beauty of Spring MVC lies in its versatility. You can harness its power to create a server-rendered app or a single-page application (SPA). The framework embraces the concept of modularity, allowing you to plug in your favorite front-end tools to create a bespoke solution tailored to your needs. So, whether you’re a seasoned JavaScript pro or prefer a more traditional server-rendered approach, Spring MVC is the reliable, adaptable partner you’ve been seeking.

2 — Easy to build simple web flows, scale up to complex problems as needed

There’s no denying that we want elegant, streamlined solutions. When it comes to Spring MVC, I’ve been amazed how I can slap together simplest web flows with finesse.

I’m no web expert. I don’t spin HTML and CSS together like some sort of web wizard. In fact, I usually have to look up stuff to do it right. But Spring MVC is always ready to help me along the way.

On a certain assignment, a few years ago, I dug in deep using React to build a complex GUI to pick out various options. Spring MVC didn’t bat an eyelash. It was, in fact, an eye-opening experience to the magic of React! And Spring MVC choreographed the data dance with elegance.

No sense of slogging through a morass of convoluted code. My web controllers and service layers nicely worked with the React UI I had built like a wonderful incantation.

So no matter what you are building, big or small, Spring MVC makes it snap to execute.

3 — Integrates tightly with Spring Security

Let’s face it. Today’s digital threat landscape is ever-expanding, and security is paramount. Spring MVC’s commitment to protecting our application is unwavering. That’s why it’s tight integration with Spring Security is built to ensure that our app remains secure and impenetrable to cyber threats.

Now it should go without saying that security is a multi-layered effort. Nothing is truly “impenetrable”. But we can at least make it difficult.

As mentioned in my previous article, Spring Security has gobs of sensible defaults activate when we choose to flip the switch on web security. Part of that is because Spring MVC makes it easy to craft filters that leverage the various HTTP standards to implement and enforce security protocols by communicating properly with the browser.

If you pause and start reading the specs on both security as well as HTTP security and headers, it’s honestly a long read. And it ain’t super exciting. But Spring MVC has built the mechanisms through which Spring Security can institute the right actions to take.

All while allowing US to write our OWN filters such that we won’t derail everything. It’s possible to plugin custom filters that meet our business needs, and not accidentally knock security out the window.

To top things off, whenever we need access to security, we can easily inject them into your web controller methods. Check out the following web controller method where we hand the current authentication object to the template engine:

By passing the authentication object along to the template, the template has the opportunity to conditionally render bits of HTML.

All we have to do is include the Authentication object in our web controller’s method signature, and Spring MVC will automatically inject it. Nothing else is needed!

4 — Works nicely with template engines, especially Thymeleaf

When it comes to crafting proper HTML, template engines are pretty much here to stay. We’ve seen many come and go, but no one is writing HTML by hand ever again.

Spring MVC works like a dream with a variety of template engines, but it truly shines when paired with Thymeleaf. This dynamic duo will make implementing any web solution a walk in the park.

Source: https://www.thymeleaf.org/doc/tutorials/3.1/thymeleafspring.htmlNow I have a confession: Whenever I write Thymeleaf templates, I absolutely must have the ref docs open and in front of me. I’m sorry, but I must.

Nevertheless, that templating engine is loaded with the power we need. And…it’s HTML compliant! Older templating engines like good ole JSPs were not. That means you can open a raw template in your browser, and it won’t look like pure garbage.

If you look at the fragment up above, all the fields prefixed “th:” are Thymeleaf directives. And with the DTD in place, you actually have some amount of code completion in your IDE!

Thymeleaf integrates seamlessly with Spring MVC, allowing you to create rich, interactive web applications with ease. The result is a powerful yet straightforward approach to web development, which simplifies your workflow and streamlines your code.

Thanks to Thymeleaf’s expressive syntax and Spring MVC’s robust architecture, you’ll be able to create stunning, responsive web applications with unrivaled efficiency.

5 — Doesn’t get in your way when solving problems

One of the most endearing aspects of Spring MVC is its unobtrusive nature. As developers, the last thing we need is a cumbersome framework that hinders our problem-solving prowess.

Spring MVC does what it’s SUPPOSED to do…and then it gets out of the way. This really lets me focus on the problem and not get bogged down in the “working the toolkit”.

Spring MVC’s non-intrusive approach is a testament to its thoughtful design. And when you chat with its creators including (but not limited to) Arjen Poutsma and Rossen Stoyanchev, you’ll find that they spent an INORDINATE amount of time carefully putting this type of usability into it.

Spring MVC was built to be flexible.

Spring MVC is a true gem in the realm of web development. It’s no wonder that some of the biggest shops out still use it to this day for some of the latest and greatest apps.

And that’s why, even though not REALLY a portfolio project, Spring MVC may nevertheless be my favorite Spring project.

If you dig Spring Boot and learning about being a pro coder, then please stay tuned for my next article. But if you simply can’t wait, then check out this video below where I found the most powerful programmer in the entire gaming world and had him help me build a web app with Mustache.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Actually, Spring Integration May Be My Favorite Spring Project

Sat, 01 Apr 2023 00:00:00 GMT

Actually, Spring Integration May Be My Favorite Spring Project

While Spring Security is wickedly powerful and essential for securing Java applications, there’s another Spring project that is equally…

Actually, Spring Integration May Be My Favorite Spring Project

While Spring Security is wickedly powerful and essential for securing Java applications, there’s another Spring project that is equally deserving of praise and admiration: Spring Integration.

Spring Integration is a lightweight framework that allows developers to build complex, scalable, and extensible systems by connecting components using a messaging paradigm.

If you’re wondering why this little ole’ toolkit originally built by still-active Spring veteran Mark Fisher has grown to such huge popularity, then hang on.

1 — Messaging Paradigm with POJOs

One of the most coolest aspects of Spring Integration is its messaging paradigm, which enables developers to connect components without having to implement any framework-specific code.

No RPC. No JMS calls. No REST calls. (Well, unless you’re aching for it!)

By allowing you to work with POJOs (Plain Old Java Objects), Spring Integration simplifies the process of building and maintaining your application’s architecture.

It must be pointed out that while you CAN use POJOs all over the place, it’s ALSO possible to use Spring tech-neutral Message type.

If you dig into just about any messaging solution (HTTP, AMQP, etc.) you’ll find they ALL have this paradigm of headers and a payload.

And Spring Integration codifies this as a barebones interface:

This generic container provides the means to capture both information about the task at end along with metadata to support routing, processing, TTL, and other aspects. In fact, you can do just about ANYTHING with this.

And something to be aware of, is that several OTHER portfolio projects. For example, if you dig into the guts of Spring Cloud Stream, you’ll discover that it harnesses the core concept of Spring Integration messaging, and dials it up to an 11.

Let go of your concept of synchronous remote calls and instead start thinking of bundling up information into messages. And think about incoming vs. outgoing messages. An incoming message could include the Work to Do while the outgoing message can contain the results.

Who is bringing the inputs, and who is consuming the outputs is not necessary to know by the worker.

This messaging paradigm promotes loose coupling between components and enables you to focus on implementing your application’s core functionality, rather than getting bogged down in the intricacies of integrating various components. As a result, Spring Integration facilitates the creation of incredibly maintainable, testable, and scalable applications. (Say that three times fast!)

But that is not all…

2 — Support for Multiple Protocols

Spring Integration offers support for a wide array of communication protocols, including FTP, JMS, HTTP, STOMP, SOAP, REST, RSocket and even email.

And by no means is this list exhaustive.

This extensive support makes it possible to “glue” together disparate systems in a powerful and flexible way.

You can easily consume data from an HTTP endpoint, route it through your processor, transform the data into a finished product, and publish it on STOMP channel for someone’s WebSocket to consume.

This arguably the real charm of Spring Integration. We’ve all done web apps. But the real challenge comes when the system architect waltzes into our office and pulls out a giant diagram showing all the components we need to talk to each other.

When you are just thinking about web calls and what not, this looks intimidating.

But when you put Spring Integration into your application, that diagram looks like a design document! That’s because one of Spring Integration’s building blocks is the MessageChannel:

Every Producer and every Consumer can either be one of YOUR components…or it could be another system as mentioned at the beginning of this section.

You can either setup a gateway to that remote endpoint, or simply hook in to one of YOUR custom components.

It’s this unified framework a la Spring Integration that enables you to build robust integration solutions that can bridge the gap between different systems and technologies. This capability is particularly valuable in complex, heterogeneous environments where multiple systems need to communicate with one another.

Speaking of learning about Spring, check out the sponsor of this article:

Do you want to build a Java app without wasting time?

Do you need to create a web layer backed by a powerful yet intuitive data layer?

Do you want to protect your users with the most up-to-date and widely used security tools?

Learning Spring Boot 3.0 3rd Edition will show you the way. Loaded with top-notch content and written by yours truly, this is the only book on Spring Boot 3.0 on the market written by a member of Spring team!

Check it out!

3 — Enterprise Integration Patterns

Spring Integration is originated as an implementation of (most of) the patterns found in Enterprise Integration Patterns (by Hohpe and Woolf). This books contains a collection of common integration problems combined with their solutions. These patterns enable developers to tackle non-linear problems by breaking them down into smaller, more manageable pieces.

Some of the key patterns included in Spring Integration include:

Channels
Aggregators
Filters
Transformers
Control Buses
Gateways
Endpoints

By incorporating these patterns, Spring Integration allows you to build flexible and modular integration flows. What’s even better, this modular approach is a lot easier to adapt to the changes we are ALL familiar with.

You can design your best solution, but when the customer comes back and indicates they need a change in the overall flow, you may not even have to alter the components themselves…just how they are chained together.

Of course, you can tune components as well. Sometime all you’ll need is some extra metadata passed along in the headers, allowing different conditions to be passed along.

It really makes it simply to think on a higher level WHAT each component does and HOW they are all orchestrated with each other.

This approach not only simplifies the development process but also makes it easier to maintain and evolve solutions over time.

4 — Embracing Simplicity

The power of Spring’s dependency injection framework is another reason why Spring Integration has really charmed me.

By leveraging dependency injection, you can write clean, modular, and testable code without having to extend interfaces or implement framework-specific classes. Heck, you can define YOUR OWN base interfaces if there is something consistent you want across your code base.

Spring Integration also enjoys the benefits of Spring Boot in that using spring-boot-starter-integration will activate the core aspects of Spring Integration.

If you throw in spring-integration-jmx, then a plethora of messaging metrics will automatically be collected across all your flows and published to JMX endpoints.
spring-integration-jdbc provides the means to use an underlying JDBC data store as the messaging mechanism.
spring-integration-amqp makes it possible to use RabbitMQ or any other AMQP-compliant broker as the primary mechanism to send messages between components

I could go on and on, but frankly, there’s too many options! Yikes!

This list should give you a hint of EXACTLY how much power Spring Integration has to offer.

When it comes to building powerful, flexible, and extensible integration solutions, Spring Integration may very well be my favorite Spring project.

Your ability to build complex business logic flows that serve your customers’ needs while keeping your application’s architecture clean, modular, and scalable its a real sizzler in my book. If you haven’t yet explored the capabilities of Spring Integration, I highly recommend giving it a try — it just might become your favorite Spring project too.

If you dig Spring Boot and learning about being a pro coder, then please stay tuned for my next article. But if you simply can’t wait, then check out this video below where I show you how to use Spring Boot to build an OAuth 2 application…and harvest YouTube data from Google!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Why Spring Security May Be My Favorite Spring Project

Mon, 27 Mar 2023 00:00:00 GMT

Why Spring Security May Be My Favorite Spring Project

Spring Security is a powerful, flexible, and extensible security framework for Java applications that is part of the larger Spring…

Why Spring Security May Be My Favorite Spring Project

Spring Security is a powerful, flexible, and extensible security framework for Java applications that is part of the larger Spring ecosystem.

It is my go-to solution for securing Java-based applications, and I will share with you the reasons it JUST MIGHT be my favorite Spring project.

1 — Sensible Defaults

One of the key reasons why Spring Security stands out is its sensible default configurations. The framework is designed to ensure that your app is protected against a wide range of security threats. And one thing I’ve learned from listening to Rob Winch’s many security talks (lead for Spring Security) is that I don’t know 1% of what this guy knows.

In fact, there’s a common expression amongst security geeks:

Don’t implement security on your own.

You and I, mere mortals in application development, don’t grok enough to guard against the many vectors of attacks. We NEED toolkits like Spring Security to apply good, standardized protections.

For example, if you create a Spring MVC application and hook up a templating engine like Thymeleaf, Spring Security will insert additional HTML directives that are aimed at protecting you. The simplest being that the browser is instructing, when logged-in users are accessing the system, to not hold into cached assets.

Essentially, when users log out, the browser shouldn’t be holding on to what that user accessed in the sense of images, JavaScript, or HTML. Any of this could be used to gain insight and attack the system. When a user logs out, the browser needs to REALLY log them out.

Betcha didn’t even KNOW that one. Well gear up…there a whole bunch of actions just like that that Spring Security stuffs into web pages to ALSO protect you.

Simply put, neither you nor I have the chops to understand all these attack vectors. But Spring Security DOES. Do you know about the following?

CSRF?
Session Fixation?
Clickjacking?

Even if you’ve HEARD of them, could you explain them in detail to your manager?

Integrate Spring Security into your application and you already have a strong foundation for a secure application without needing to be an expert in security.

2 — Customizable User Sources and Access Rules

Spring Security makes it easy to integrate custom user sources and define access rules for your application. It provides a straightforward and intuitive way to configure how users are authenticated and authorized, allowing developers to quickly implement their desired security policies.

How easily can you define a user source? Check out the code below:

All you have to do is define a UserDetailsService bean, just like that, and Spring Security will pick it up through the magic of Dependency Injection. In this scenario (courtesy of Learning Spring Boot 3.0 3rd Edition’s 4th Chapter code), by leveraging a Spring Data repository.

I won’t delve into the details of the repository, but essentially, by using a simple relational database, you can easily store your users. And an accessor like this grants Spring Security the ability to leverage it.

You can easily hook in other user sources such as LDAP directories, or other third-party identity providers. Spring Security provides easy-to-implement interfaces (UserDetailsService) where you can reach into any identity provider’s API and seamlessly link them.

This flexibility ensures that your application can easily adapt to your organization’s specific security requirements and infrastructure.

Speaking of learning Spring Boot 3.0, check out the sponsor of this article:

Do you want to build a Java app without wasting time?

Do you need to create a web layer backed by a powerful yet intuitive data layer?

Do you want to protect your users with the most up-to-date and widely used security tools?

Check it out!

3 — Extensible Authentication and Authorization

The extensible architecture of Spring Security enables developers to use a variety of authentication and authorization mechanisms.

Yes, username and password authentication are THE MOST POPULAR solutions on the planet.

Yes, OAuth 2 has risen in ridiculous popularity.

Nevertheless, I’ve spoken to enough people to understand that almost EVERY SINGLE SYSTEM developers have to deal with are slightly…different.

Whether you have to deal with X.509 certificates, Kerberos, or LDAP, Spring Security can help. Regardless of your organization’s preferred security standard, you can easily integrate Spring Security into your application.

Furthermore, the framework’s extensibility ensures that, as new security standards emerge, Spring Security can adapt and incorporate them, providing you with that little thing we in the industry like to call future-proof.

4 — Custom Extensions

There is a slim chance that YOUR system has some unique never-before seen security hook. And Spring Security isn’t ready to help you.

Except…it is.

You see, Spring Security’s architecture is modular enough that you can code your own extension. We’ve also seen the ability to look up user data earlier through UserDetailsService.

To implement your custom authorization hook, all you must do is implement Spring Security’s AuthorizationManager. This API only requires that you it’s single check() method. This gives you the chance to tie in to your new fangled authorization manager.

Once done, you are ready to go!

But that’s not the ONLY thing that makes Spring Security my favorite Spring portfolio project. Keep reading…

5 — Integration with Templating Engines

Spring Security integrates seamlessly with popular templating engines like Thymeleaf, providing developers with an easy way to secure various portions of their web applications.

Thymeleaf, for example, comes with built-in Spring Security hooks that enable you to apply sophisticated security features to your web pages. Just check out the fragment below:

By leveraging hooks like this, it becomes mind-numbingly simply to show various fragments of HTML on the page based upon the current user’s roles and access.

It becomes much simpler to imagine a read-only version vs. a updatable version of a web page. Buttons that only ADMINs should see can exist. All sorts of goodies.

This ensures that sensitive information is only accessible to authorized users, further enhancing the security of your application. When your manager asks you to “do this”, it becomes easy to meet.

While I’ve been a fan of Mustache’s simplicity as a templating engine, and Spring Boot’s keen support for it, any moderately complex system that has multiple security roles, would push me quickly toward Thymeleaf as the templating engine of choice.

6 — Spring Boot Compatibility

Spring Boot combined with Spring Security makes it easy to secure any type of Java application, be it web apps built on templates, JSON APIs, business-to-business systems, and SOAP-based services.

This allows us to quickly and easily add security features to our applications, regardless of the app’s architectural style. Whether we’re building a simple web application or a complex, multi-tiered system, Spring Security and Spring Boot can work together to provide a secure foundation for your project.

That’s why it’s easy for me to that Spring Security quickly become my favorite Spring project. In fact, long ago, I met the founder of Spring Security (Acegi Security at the time), Ben Alex. A shrewd coder, Spring Security was probably the first Spring project whose code I read top-to-bottom.

(Yours truly even implement a Python-based variant called Spring Python with a security module heavily built out of Spring Security’s architecture!)

And over its entire lifetime, Spring Security has been built in the open, by some of the sharpest security experts in the field.

If you’re looking to secure your Java application, I highly recommend giving Spring Security a try. Its combination of powerful features and ease of use make it an invaluable tool for developers seeking to protect their applications while focusing on delivering their core functionalities.

If you dig Spring Boot and learning about being a pro coder, then please stay tuned for my next article. But if you simply can’t wait, then check out this video below where I go into details about the pros and cons of JDBC vs. JPA.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Are test fixtures worth it in your automated testing strategy?

Sun, 12 Mar 2023 00:00:00 GMT

Are test fixtures worth it in your automated testing strategy?

Building automated tests for green field projects is a breeze.

Are test fixtures worth it in your automated testing strategy?

Building automated tests for green field projects is a breeze.

Or at least…it’s not as hard as taking code written by someone not even on the team anymore, and attempting to test it.

Legacy systems can make you sweat. Raise your hand if you know EXACTLY what I’m talking about. (And raise two hands if that part of the system gives you nightmares from time to time!)

Have you invested any time in coding test fixtures to automate your tests? Or do you work at one of those shops that STILL have a 27-page test manual that has you CLICKING THROUGH WEB PAGES to verify your code?

As a pro coder, it’s imperative that you invest in building test fixtures to improve the efficiency of your testing process.

What is a test fixture?

It’s a code construct that provides a fixed environment for testing. It includes everything required for a particular test, such as a setup routine, test data, and sometimes utilities methods to help manage it all. It’s the foundation upon which you build some, if not all, of your automated tests.

One more thing to build in order to engage with automated testing? Yikes!

Yes, it’s true that building test fixtures for legacy systems can be time-consuming. But it’s a valuable investment that will eventually pay off.

For instance, think of a system that scans electronic invoices and stores the results in a database. To automate testing for a system like that, a suitable test fixture might do something like this:

Cleans out the appropriate database tables.
Creates a new database schema that avoids collisions with other developers.
Stages the test file in a specific location so that the parser can find it.
Invokes the system.
Waits (fixed time, or looks for some signal).
Reads the final results from the database.

(BTW, this is EXACTLY one type of test fixture I built at my previous job, before joining the Spring team. It was quite painful to build.)

What worse is that more complex systems may require even MORE steps to properly handle a test run!

Just to be clear, my example above wasn’t about setting up databases. Instead, it’s about the fact that sometimes we have to write some extra machinery to make the systems we work with do our bidding in automated test scenarios.

If your system interacts with an LDAP server, for example, you may need to code a fixture that cleans out the directory structure and loads it up with test data, and then handles cleanup after the test is complete.

Writing any such test fixture can be quite daunting, but the investment will payoff as you write more and more test cases.

It will sharpen your skill set as a pro coder. (BTW don’t forget to update your LinkedIn profile!)

Building fixtures like the one above (or that LDAP one) may not seem like the fastest or most efficient way to test your system. But investing the time to build them empowers you to write automated tests.

And who knows?

Maybe with enough tests, enough time over target, and enough accumulated awareness of your own system, you’ll eventually be able to you to refactor your code to totally decouple it from the database or LDAP server?

Investing time in test fixtures is a valuable investment for automated testing. It’s the foundation upon which you build your tests, and it pays off in the long run by improving your efficiency and sharpening your skill set as a pro coder.

If you dig Spring Boot and learning about being a pro coder, then please stay tuned for my next article. But if you simply can’t wait, then check out this video below where I show you exactly what you need to do to land that dream job!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Why Coverage Isn’t Everything: Rethinking Your Testing Approach

Sun, 05 Mar 2023 00:00:00 GMT

Why Coverage Isn’t Everything: Rethinking Your Testing Approach

Do you take pride in high coverage scores? Do you compare coverage percentages with colleagues to see who is doing better?

Why Coverage Isn’t Everything: Rethinking Your Testing Approach

Do you take pride in high coverage scores? Do you compare coverage percentages with colleagues to see who is doing better?

This is probably wrong.

Unequivocally, undeniably, ecumenically wrong.

And probably time to rethink your approach.

Coverage reports are useful, but they aren’t everything. The goal of testing is not just to have high coverage scores, but to ensure that the code works as expected in real-world scenarios.

What does this mean exactly?

Those that get overfocused on coverage reports are probably sacrificing test quality to achieve those numbers.

And sacrificing test quality for the sake of coverage is a recipe for disaster.

Coverage reports can give us insights into what is being exercised and what is not, but they don’t tell the whole story. Simply because a line of code is being exercised doesn’t mean it is doing what it’s supposed to do.

How can we solve this?

We need not only generate the coverage reports, but must also analyze what they mean.

We need to analyze what is being covered and how well it is being tested. For instance, if a module has 70% coverage, it doesn’t mean that the remaining 30% is unimportant or that we need to write more tests that specifically target the uncovered parts.

Think of it like this…there are two schools of thought on how to approach this:

The first approach is to write new tests that target the uncovered parts without overlapping the original 70%. That’s because if we end up testing code that has already been covered in another test, we’re wasting time and resources!
The second approach is to write new tests that target scenarios that the code is expected to handle but haven’t been tackled yet. What was not covered should give us clues about what scenarios haven’t been tested yet.

The second approach is the better one. And yes, I wrote that in a rather leading fashion. But you get my point, yeah?

It’s important to write tests that are based on real-world scenarios rather than simply trying to increase coverage percentages. If we lean too much into mocking, stubbing, and other parlor tricks to exercise the uncovered code, we risk writing brittle test cases that will come back to bite us in the long run.

New tests could be a lot more brittle when not based on sound scenarios.
A major change to any of our algorithms could require us to totally rewrite these tests.
With mocking, it’s possible to mock the “real” system away and ultimately be testing the mock itself!

We should focus on improving the quality of our tests, covering more scenarios, and removing code that is no longer supported. Increasing coverage for the sake of coverage doesn’t lend itself to improving the quality of our system.

So, next time you are tempted to celebrate high coverage scores or compare coverage percentages between projects without any context, take a step back and reflect on your motives.

Are you doing it to improve the quality of your system…or just for the sake of coverage?

Remember, the goal of testing is not just to have high coverage scores, but to ensure the system is fully armed and operational!

If you dig Spring Boot and learning about being a pro coder, then please stay tuned for my next article. But if you simply can’t wait, then check out this video below where we learn how to test various security aspects of a Spring Boot application!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Testing Code: From Spaghetti to Safety

Sun, 26 Feb 2023 00:00:00 GMT

Testing Code: From Spaghetti to Safety

The world of software development is constantly evolving. New tools, techniques, and technologies are being introduced every day, and it…

Testing Code: From Spaghetti to Safety

The world of software development is constantly evolving. New tools, techniques, and technologies are being introduced every day, and it can be challenging to keep up with the latest trends.

However, there are some issues that never seem to go away, no matter how much progress we make: legacy code.

Yuck.

Can I get a high-five if you’ve ever dealt with legacy code?

Legacy code is something we’ve all had to had to deal with at one time or another. The code may be poorly documented, contain chunks of commented-out code, or have no comments at all. Often, there are few automated tests, making it challenging to know if the code is working as intended.

So, what do you do when you find yourself in this situation?

Easy: Start testing.

What??! That’s your whole thing? “Start testing?”

Let me clarify. It’s easy WHAT you must do and that’s to start testing. Before you alter any features, if possible, if you can hold off the minions of management and community and before you “fix” a single thing and first write a test case, that would be perfect. (I understand if you can’t.)

But deciding to “start testing” will not be easy to CARRY OUT. Believe me, I know.

In fact, it will be very VERY hard. So continue reading if you want to some tips that at least give you a decent shot and moving that boulder up the hill.

To start off, don’t get caught up in the purity of total isolation or worry about obscure test methods. Just start writing tests. It doesn’t matter if you use the right name or if you’re writing a unit test, a thread test, or an integration test. What matters is that you’re writing a test.

For example, consider a system I once dealt with that parsed electronic invoices and stored the parsed results in a database. The parsed results weren’t handed back through any API, so I had to write a test that checked the results in the database.

Yes, that’s ugly as all get out. It’s often un-recommended.

And sometimes…it’s EXACTLY what you must do.

I started my test case by programmatically emptying all the tables relevant to the application (test database NOT production!)
Then Ifound a user who had one of these electronic invoices and got a copy of it.
I added code to the test that invoked the top-level API to ingest that file.
Finally added some more code that pulled data out of the database and checked the results.

Whew! This took me a couple weeks to carry out these steps, but I did it. And it worked. And the test case took 2–5 minutes to run.

That was no unit test, but it was better than no test at all. And it was my first step forward. My first toward taming this beast.

And so I continued like this, one step at a time. Now here are some additional things to consider:

Since the database is where you assert results, you need to have a cleaned-out version before every run of your test. This is going to require coordination if other developers are using some of the same tables. You may need your schema allocated to you, so you can empty tables at will.
It’s important to recognize that if you try to jump immediately into “proper” unit-level testing, you’ll QUICKLY discover that refactoring is required to make the various modules support you. With little or no test suite safety net, the risk becomes incredibly HIGH. Does that make you nervous? Well it should.

In fact, if you try to stick to textbook unit testing, you’ll probably give up and deem automated testing as an impossibility.

Instead, take the first step and write the expensive, end-to-end automated test to build the first link in a chain. That test may take a long time to run and not be very comprehensive in what you can assert, but it’s a start.

Like I said, the concept of “just write a test” may sound simple, but the work is going to be hard. You’ll be forced to crawl through lots of APIs and find out exactly how they work. You probably won’t be handed lots of intermediate results to assert.

And just to be clear, understanding the API at first is more likely to just understand what is going where so you can track down the final destination of your data.

Now as you continue to write more tests, you will begin to build up a safety net. And the more tests you write, the easier it will be to refactor chunks of code. You’ll actually have an epiphany of realizing “I know how that part works! And I know how to change it!”

And…you’ll then have the suite of tests to support you as you make that change.

You will have built up confidence and accumulated a working knowledge of how the app does its thing.

So when you set out and the process feels slow, never let anyone tell you that you’re wasting your time building a long-running test case. An automated test suite that takes an hour to run and is exercised at least once a day will instill more confidence than clicking through the app’s web pages manually.

Something is better than nothing.

If you dig Spring Boot and learning about being a pro coder, then please stay tuned for my next article. But if you simply can’t wait, then check out this video below where I give you some of the most important tips you need to know to become a pro coder.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

4 Ways to Energize your Software Team

Sat, 18 Feb 2023 00:00:00 GMT

4 Ways to Energize your Software Team

This past week, the Spring Data team had a face-to-face meeting. And it was fan-TASTIC! I had entered the meeting with sort of an…

4 Ways to Energize your Software Team

This past week, the Spring Data team had a face-to-face meeting. And it was fan-TASTIC! I had entered the meeting with sort of an average-to-below average feeling and left feeling energized, excited, and with a stronger sense of purpose than I had felt in a while.

So what happened? Did our team leader tell jokes? Did we spend the whole time telling war stories of past and present work life? Did our team manager promise us a rich bounty of double bonus pay and equity grants?

No.

We did something very different. We connected on a HUMAN level. And in the rest of this article, I’ll share with you some of the tactics we used to do that.

1 — Put the technology away

For a software development team distributed around the world, we sure love our tech. Zoom chats, Slack channels, M1 Macs on standing desks, and cloud-based SaaS tools.

All of it is incredibly empowering from a tools perspective. And I can do my job from literally anywhere I can find an internet connection.

And for this week, we set it all aside. Instead, we used a whiteboard, giant sticky pin-up sheets with cute doodles (courtesy of our team leader!), and back-and-forth talking.

Tech is cool, but sometimes you need to get your head out of all that and connect with your fellow humans. And human interaction is one of those things that when given the opportunity, you should spend the time to invest in. The lot of us (United States, United Kingdom, Germany, and Austria) were all in one room for just a week.

Don’t squander this opportunity by spending it all doing coding and ticket management.

We spent a LOT of the time voicing thoughts and feelings. But what, exactly, did we say? Keep reading to find out!

2 — Take the time for a retrospective

Once-a-month we try to have an online retrospective. This is a change to reflect on things done in the past and ponder what’s coming. Online we usually confine it to an hour, but during our face-to-face meeting, we ended up spending two hours.

What, exactly, is a retrospective? Simply put, everything writes down on sticky cards topics which they either:

I’m glad that…
I wonder about…
It wasn’t so great…

You can also +1 someone else’s card. Basically, this is a chance to vent about things, pose questions, and also express the stuff that excites you. Then, each card is discussed by the team.

Typically, you give each card five minutes. In some cases, if there’s a lot to dig out, you can keep bumping the timer up. (Our team leader had a KickStarter clock that had things like 1 minute, 5 minutes, 10 minutes, and even 25 minute pomodora-style timers!)

The point is to get all those concerns out there. Not to solve. Sometimes, simply espousing concerns can rob them of their energy. Other things can result in action items gathered to deal with later.

This sort of self reflection is good for the team, and a 2-hour session was a GREAT way for all of us to truly get on the same page.

But that wasn’t the only thing we did face-to-face!

3 — Getting to know your teammates

Another thing we did was everyone was invited to write down various aspects about themselves including:

How I joined the Spring team
Things that excite me
Favorite movie/book/TV show
Sad times
Scary moments

It’s fun to hear all your teammates and learn how they discovered Spring and what drew them to join the team. It exposes their personal experiences, a hint of their skills, and sometimes…the things they were frustrated with.

But it’s ALSO cool discovering personal desires like TV shows and movies. These types of discoveries turn what may seem like a flat, impersonal avatar from Zoom into a real, multi-dimensional human that is closer to yourself.

You see, one thing that I learned in the midst of all this that we ALL struggle with some amount of imposter syndrome.

Impostor syndrome is a psychological occurrence in which an individual doubts their skills, talents, or accomplishments and has a persistent internalized fear of being exposed as a fraud.

Sharing more of yourself, including not just the “good” stuff but also the struggles and challenges, made it clear that all my teammates struggled. A lot like me. It drew me closer and quickly dissipated whatever imposter syndrome I was feeling.

One thing I was able to express to my teammates was one of my personalf ears. While I had 10+ years of experience writing SQL queries such that I can left outer joins and correlated subqueries in my sleep. My knowledge of JPA was NOT so tall. I had, in fact, watched my teammate’s 2018 SpringOne talk on JPA and was dumbfounded when he challenged the audience to guess how Hibernate would react in the certain situations.

Yikes!

Sharing that vulnerability was hard. But I’m glad that I did.

At the same time, my team leader had asked me to bring a proposal for a critical issue we were facing with Spring Data JPA. I had spent the previous week building a proof of concept and a presentation. By the end of my pitch, I had learned that I was the only one with the exact skills to implement it. And my experience in this area allowed me to assuage all of my teams’ concerns so much that they are EXCITED to see me implement it!

Imposter syndrome — gone!

4 — Take time off

I can’t stress this enough. Not everything has to involve work stuff. One night, our team leader met us in the lobby of the hotel…with a bag full of Rubik’s cubes!

Mark showed us the basics. Christoph threw in the towel pretty quickly. Ilaya tried hard. John, while he seemed challenged, apparently went back to his room and conquered it!

Me? I figured out how to solve the first two layers. And that was it for me.

My point is that spending time together doing non-work stuff during a team meeting is constructive and prepares you for working hard together in the coming year!

Whether you have a face-to-face time with your teammates, or you are working over Zoom, these tactics can help YOU build a better bridge. Better communication, better understanding, better support for each other. Let me know in the comments what YOU plan to do!

If you dig Spring Boot and learning about being a pro coder, then please stay tuned for my next article. But if you simply can’t wait, then check out this video below where I share everything you need to know to conduct a code review.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Code comments are DEAD…or ARE they??

Thu, 02 Feb 2023 00:00:00 GMT

Code comments are DEAD…or ARE they??

We’ve all dabbled with code comments. In fact, when learning programming, it’s one of the first little things you learn.

Code comments are DEAD…or ARE they??

We’ve all dabbled with code comments. In fact, when learning programming, it’s one of the first little things you learn.

/**  
 * We were all shown how to add our own comments to code,   
 * perhaps on Day 1.  
 */  
public class MyExample {  
 public static void main(String[] args) {  
 System.out.println("Really cool, ehh?");  
 }  
}

Stuff like this is something coding instructors love to show. And it’s cool, right? Write all the commentary you want about your code.

How it works
Why you picked this algorithm
Detailed explanation about HOW that algorithm works, to help you out the NEXT time you have to read that chunk

That last one is key. Why?

Because our ability to read code ebbs and flows. Sometimes, when we revisit a chunk we haven’t seen for six months, getting back up to speed can be tough. A comment explaining the algorithm in HUMAN can be vital.

And this is where comments can sabotage us.

Because what happens when we ALTER the code? What happens when we write a detailed explanation about how it works, but then we change it five times. And when the other person on our team makes a few tweaks of their own?

And that wonderful, beautiful comment was NEVER updated.

When it’s time to get up-to-speed, the comment may be worthless. It may flat out wrong. Or…it may actually be more insidious than that. What if the code had corner cases later fixed, but the comment doesn’t cover that?

This is the reason the sofware development community has generally declared comments to have little redeeming value. Talk to any pro coder with more than a few years under their belt, and they’ll tell you not to sink your hopes into code comments.

And such a sweeping generalization, would turn to be wrong.

Comments have a vital, critical value in our code. But they must be used judiciously.

Licensing and credit

Every file in your codebase should have its shorthand license in a comment at the top of the file. When people run into your code, the terms of interacting with it should be plain and clear. After all, it’s your moral duty.

This is information unlikely to change despite dozens of changes. And so there is little risk of drift.

But that is not all. I’m a fan of crediting people with contributions to source code. After all, Java has the @author tag. If someone contributes a patch, and don’t include their name on impacted files, I’m prone to add them to the credits with a polishing commit.

Yes, the list of contributors will grow over time. But that’s okay. There is nothing directly tied to the code’s functionality, so again, no risk of drift.

But that is not all. There are even more ways to apply comments to your code the doesn’t risk them falling out of date. Check it out below:

Linking back to tickets

One of the issues in software management is the fact the use tickets to manage change. Tickets are where we usually host any conversation about a given change.

So it makes sense for our code to point back to the ticket.

But not in the way you’re think. Yes, I mentioned linking to the ticket when crafting your commit message, but today we’re talking about comments. And your operational code shouldn’t be cluttered with comments.

Instead, you should be writing test cases that capture the various behaviors agreed to in the ticket. And those test cases can mention the ticket that brought them into existence in the comments.

This test case links back to https://jira.spring.io/browse/DATAJPA-253, where all the details behind this test class (and the code it exercises) can be found.

Pretty effective way to build the record between code and tickets.

Fundamental concept behind the code

Your code may shift and adjust HOW it implements something. But WHAT it does should not. At least, not on a fundamental basis.

At the top of a Java class, you can mention the class’s overall purpose. And one thing Java is really great at are all its links, such as connecting to related classes (CrudRepository and EntityManager) among other things.

So writing comments that describe WHAT a class or method does, its inputs & outputs, and even listing WHEN a function was added to the codebase using the @since tag, you can create a very practical batch of documentation.

Deprecations

One of the most vital things we need to engage in is API management. Public-facing methods and classes need to be sustained. At any time, if you need to migrate to a newer class or replacement method, you need to deploy Java’s @Depracated annotation.

Not only do you need to flag the method (or class) itself. But the Javadoc comment is your way to signal to your community HOW to migrate away from this API that you may remove in a future release.

Explaining what to use and how to use it is a splendid way to comment.

These are all good ways to use comments. To give your users key information to consume, interact, and use your code. And where, exactly, the guardrails are.

But trust me.

The minute you start trying to explain why you are having to sort the thingamabobs and push them onto a stack of whachamadigits, you’re in trouble. Because your code will change. Quickly. Rapidly.

Don’t do it. Comments like THAT are DEAD!

If you dig Spring Boot and learning about being a pro coder, then please stay tuned for my next article. But if you simply can’t wait, then check out this video below where I dive into how to write your version-controlled commit messages and most important what to NEVER put in a commit!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

What is code polishing…and why YOU should be doing it!

Thu, 26 Jan 2023 00:00:00 GMT

What is code polishing…and why YOU should be doing it!

One of the most amazing things I’ve discovered since joining the Spring team…was their affinity for polishing code. In fact, at the 2014…

What is code polishing…and why YOU should be doing it!

One of the most amazing things I’ve discovered since joining the Spring team…was their affinity for polishing code. In fact, at the 2014 GOTO conference, Rod Johnson mentioned Juergen Holler’s “unearthly commitment to code quality”.

What, exactly, is that? And by the end of this article, I hope you’ll realize not just WHAT this is…but why you should take up this mantle.

In its simplest incarnation “code polishing” is when you ensure that your entire code base has a consistent, equivalent, uniform nature. Speaking of Java code, this can include things like:

Consistent sorting of import statements
If you use wildcards in import statements, expand at the same amount (Spring Data requires 11+ imports before using a wildcard)
Curly braces begin and end at the same place, everywhere
Wrap ALL code blocks with braces (no single-line/no braces)

That’s not the whole list, but you perhaps can see the value in having every Java classfile adopt this same style. Thankfully, like many of software’s challenges, there are tools to help with that. The Spring Data team uses the Adapter for Eclipse Code Formatter, a plugin that lets us read an Eclipse code formatting file and apply it inside IntelliJ. This lets us share a common set of formatting choices.

If we’re all using the same formatting choices, it becomes a hotkey combo to reformat any source file we’re editing. And anytime we receive a community contribution, we can quickly apply our styling.

But why do we need to do this?

Because of physics.

You may not know this, but one of my hobbies when I’m not slinging code is physics and advanced math. I actually find it soothing to watch a video of a college math professor hammering out an incredibly complex piece of calculus. The math fascinates me!

But it doesn’t just stop there. I have become enamored with learning the math behind such complex things like General Relativity, to the point that I’ve watched hours of videos where they prove Einstein’s Field Equations, and then use them to solve complex problems.

To the point at hand, one of the most amazing things discovered in the past 200+ years is entropy. This is where things essentially fall into decay. The concept is simple and elegant, yet lack of awareness for entropy can allow things to go really badly.

Not paying attention to code can allow it to fall apart. If you accept contributions into your project from the community, it’s quite natural for the entire codebase to decay into an unmanageable mess.

Mathematically speaking, if you don’t expend energy to move it toward order it WILL move toward chaos. In other words, you simply HAVE to budget in time to clean and polish your code, or eventually it will fall into ruin.

Maybe not today. Maybe not tomorrow. But over time.

Several years ago, I participated in a joint effort with Netflix, Google, and some other big shot software companies. The codebase was owned by Netflix, but a certain section of it was ours. And after having worked on the Spring team for several years, I NOTICED the lack of consistent styling in the Netflix codebase.

I don’t mean to besmirch the Netflixers nor anyone else. However, on Day 1, I could see it, perceive it, and it tugged at me. Maybe that’s a bit nebulous. Nevertheless, everyday that I contributed to that codebase, it had a negative effect on me.

Going back to Spring’s codebase was a breath of fresh air.

Perhaps this is a personal problem, you say? Maybe. But there is something to be said for investing a little extra energy to clean things up and ensure a consistent formatting. On the Spring Data team, not only do we have the code formatting mentioned above, but we have additional rules that can’t be directly enforced by tools, so we must do them manually:

Favor default visibility (classes and methods being package-private) over “public” (which tends to be the default in IDEs)
Every method, if it has two more lines of code, must include a blank line at the beginning.

We spend a fair amount of time adding double-slash (//) comments at the END of lines of code so that our code formatter will nicely line things up on our behalf!

(BTW, that chunk of code from a contributor was later polished to add the extra blank line above flushTestUser!)

All of this helps A) increase readability, B) reduce cognitive overload, and C) make everything neater, tidier, and ultimately, staves off the decay of the source code.

Investing extra time and making your code more consistent, more readable is a worthy investment. It’s why I chuckled on Reddit a couple weeks ago, when someone asked the following question:

I get it. Not everyone likes the Spring Way™. But whether or not you agree with how our framework operates, you certainly can NOT impugn us on code formatting! I reckon it’s why my check on the OP’s question got 26 upvotes!

We have an expression for what happens when your code contribution to the Spring portfolio get polished. Over time, through repeated polishings, you adapt. You strive to get that contribution into a given Spring project WITHOUT NEEDING A POLISHING COMMIT. You try to buff it up yourself on the way in.

You run the same tools. You squint to see it as Juergen would (or mini-Juergen a.k.a. Oliver Drotbohm). You seek to make your work impeccable.

We call this “juergenization”. Because it’s ultimately YOU that is transformed. Not just your code. And then you start to do it in other places (like my book!) And the world of software development, a world that may be caught up in an exponential explosion, may have a fighting chance if we all seek to beat back the forces of entropy!

If you dig Spring Boot and learning about being a pro coder, then please stay tuned for my next article. But if you simply can’t wait, then check out this video below where I talk about the various things you must do to carry out a code review.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

As we move into January of 2023, it’s time to entertain some new ideas, new ways to streamline your…

Fri, 20 Jan 2023 00:00:00 GMT

As we move into January of 2023, it’s time to entertain some new ideas, new ways to streamline your…

1 — Create a worklog

4 Ways to Streamline Your Daily Coding Grind

As we move into January of 2023, it’s time to entertain some new ideas, new ways to streamline your coding lifestyle. I’ve gathered some of the easiest-to-use tips that have helped me. Maybe they can help you as well.

1 — Create a worklog

I have a Google Doc where I basically track my daily work. I paste in linked to GitHub tickets I worked on. To be clear, I write down every ticket I so much as glance at.

A day where I actually knocked out some Spring WS ticketsMaybe this sounds like a lot of EXTRA work you don’t need to take on. I get your point. I started doing this last year and it has actually helped me focus my thoughts.

Some days, when I feel my focus isn’t quite there, going back and reading a couple of the previous days really jobs my memory and helps pull me into a developer mindset. Which has helped me get cracking a lot faster.

So indeed, while the task itself can feel tedious at first, the payoff by committing to this adjustment to my process has been positive.

BONUS: There are many times when I feel like a couple weeks simply flew by. Being able to remember EVERYTHING I had done simply didn’t happen. But opening the worklog at the beginning of the day would refresh me memory on everything I HAD done recently. And seeing a stack of completed work at the end of the day also gave me a stronger feeling of accomplishment.

I should also note that you don’t have to write reams of content by each issue. Or summarize it. This is an activity log. The actual comments on each ticket belong, well, in the ticket!

2 — Pick out a 30-minute playlist and use it as a clock for breaks

Something else I started doing was exercising my playlist. (Use mine if you want a synth-heavy instrumental playlist!)

Not only does listening to TRON-ish style music warm me up to writing code, but when the playlist is over, I know it’s time to take a break. My playlist is about 37 minutes, but you get the idea.

When the playlist is done:

stop
walk around
walk the dog
watch a YouTube video

A five-minute break following by another coding stint will do wonders at refreshing your mind and resetting your fatigue.

Yes there are times when I play the list twice in a row. Sometimes, I’m really in the zone and don’t want to lose my groove. But twice through the playlist, and I’m stopping FOR SURE! (If you have a playlist, share it in the comments!)

3 — Permit yourself to do some non-work things

Something I used to feel quite guilty about was, when I would take a break from work stuff and watch some video. Whether that was a Mr. Beast video or some video where I watch a math professor solve a devilishly complex calculus problem (yes I watch them!)

Either way, I felt bad doing it “on company time”. But now, with my playlist-as-the-pomodoro-method, I actually go and do ANYTHING I WANT for that short break between my coding stints.

Want to watch a YT vid? Do it! Want to visit Twitter/Facebook/Reddit?

I hereby give you permission to visit your favorite site and splurge as you relax for your 5-minutes break!

It’s no biggie.

Just don’t take a 5-minute break and let it turn into watching an entire season of For All Mankind! Heh.

4 — Have a worksheet to focus on

A challenging thing can be when you’re ready to get cracking…but you have no sense of what to do. Having a worksheet of agreed upon tasks is the simplest way to do this.

There are different ways to approach this.

Maintain a Google Worksheet, where you write down every task someone asks you to do. As you complete the task, mark it off the list (vs. simply deleting)
Use GitHub’s Project Board as a way to manage the flow of tickets in your org. It’s quite easy to go in and filter down to only see YOUR tickets.
Check your project’s issues or pull requests.

The key here is to focus on actions that move the needle. And a great way is to either be knocking out tickets/pull requests that are getting opened on your project. Or to work off an action item list everyone is aware you are using.

The important thing to remember is that if you get stuck on one issue and are waiting for a response, be it on Slack or in a GitHub issue, you want to switch to a different task. That’s when you go back to your worksheet of choice, and pick up a different task. Maybe the ticket you started working on today simply isn’t going to be completed today. Doesn’t mean you can’t knock out a couple OTHER ones. (BTW, don’t forget to put note that ticket in your worklog!)

Worksheets are nice because you can easily apply some priority value, sort everything, and work off the top. Completed tasks can be pushed to the bottom. Once-a-week, you simply go in and readjust any priority’s. This gives you a list of what to work on next.

And as a bonus, if you get stuck on one particular task and are waiting on someone to come back to you, you can pivot to the task #2, and maintain your velocity!

These are just a handful of ideas to help increase your efficiency as a pro coder. Are there some tactics YOU have used that helps you? Share it below in the comments.

If you dig Spring Boot and learning about being a pro coder, then please stay tuned for my next article. But if you simply can’t wait, then check out this video below where I have a nice mix of music you can play in the background while you chew through your stack of work!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Diving into 2023 as a Spring developer

Thu, 12 Jan 2023 00:00:00 GMT

2022 is gone. 2023 is here. To be honest, I’m not fan of New Year’s Resolutions. After all, if something is good, why not just go head and DO IT?

That being said, the break time away from work at the end of 2022 and warming up to things in 2023, why not take advantage of this lull and figure out some SOLID THINGS to evolve in 2023 to make writing Spring apps easier?

1 — Cleaning out the cruft

Once a year it’s good to go through your work environment and clean out junk you don’t use.

And I mean it.

Physically touch everything on your desk and ask, “Did I use this last year? At all?” If not, take it down. If you used it once, take it down. If you used it every week, keep it. But anything less frequent than that, and you should take it down.

How to sort everything?

Things you use at least once a month can be gathered somewhere else, like your closet, a sorter, whatever. The point is, don’t clutter your daily environment with it.
Some things can be either sold off of given away to others that WILL use them.
Stuff that you worked with but won’t anymore can be archived. Got a storage room/closet? Maybe a file bin? Anywhere that you can put it away and access it should you need it.
Finally, some things simply should be thrown away. Even if it was once cool. Even if it was once very useful. If that’s no longer the case, it’s OKAY TO THROW IT AWAY.

You won’t believe the peace it brings to clear out junk that has no bearing on your daily tasks.

2 — Streamline your processes

Whether you’re writing code, shooting content for a YouTube channel, writing novels full time, whatever, one of the most effective strategies to increase your throughput is streamlining things.

The things you use every day should be easy to access from your desk. If they’re digital, like files, then it makes sense to create virtual shortcuts. I’ve been honing my list of shortcuts in my Mac’s Finder window for years.

You can see the most common things I access on the left-hand side. (The right-hand side is where I have all my source repositories checked out.)

Do you have gobs of projects checked out, all across your machine? I check almost all of them out in ~/src, while certain personal projects are at ~/personal.
Do you have an established flow of how you check out projects, how you download content off the Internet, how you capture images? (I changed the folder where screen captures go so I don’t have my Desktop getting cluttered!) If not, maybe you should consider it.
Anything you are doing over and over, stop and spend ten minutes asking, “How can I simplify this process?” It could take a few hours to actually implement these changes, but if it ends up saving you THOUSANDS of hours over the long term, then it will have been worth it!

3 — Set it up once

In case you didn’t know, I make YouTube videos in my spare time about Spring Boot, how to be a pro coder, and other topics. And one thing that has made this simpler is to simply have everything ALREADY SET UP.

Are you working up toward becoming a pro coder? Did you just finish your Uni/Boot Camp program and are shooting to get on a team (or maybe you just did)?

Then take the time to setup your work environment. And then LEAVE IT there. (This is why I encourage people to carve out a dedicated space to writing code!)

It’s okay here and there to take your machine to the dining table or the couch to do some coding. But in general, go to your dedicated space. Plus, it’s EASIER to go there if everything is ALREADY setup!

Last summer, I carved out the time in my studio space to setup my camera’s tripod, all the lights, and the microphone stand. I worked out exactly where they need to be such that I could A) setup a shoot real fast, and B) not have to move things around when I was done.

This made it SO EASY to simply go and shoot a video.

And doing the same for whatever YOU do is vital to increasing your own throughput.

4 — Review, revise, and revisit every six months

The odds that things will be perfect on Day 1 are pretty much nil.

But that doesn’t mean the steps I’ve mentioned won’t work. They could VERY WELL help you increase your throughput with out overloading you. But a critical thing is to plan on reviewing your setup six months from now.

Look at what worked, and what DIDN’T work.

Then revise your setup. Revise your streamlining. Adjust what is in your daily workspace and what is stowed in your closet. Tune things.

And then be willing to revisit it six months later. Small steps that you’re willing to take and later review to see if they worked can lead to real, positive change.

There’s a saying: Don’t try to make huge changes. Shoot for a 1% improvement. If you can improve just 1%, five days a week, 50 weeks a year (take a couple weeks off for pure rest), the resulting change can be huge.

That’s right. Improving things by 1%, only on weekdays, in a year’s time, can lead to a 12x improvement.

And if that sounds a bit aggressive, know this: improving things by 1%, 100 times over the next year can lead to a 2.7x improvement, a significant improvement nonetheless.

You see, it’s tiny, deliberate actions, taken consistently over time that can change our lives. We just have to think ahead and take them. And knowing that you have permission to pivot six months later means nothing it set in stone.

If you dig Spring Boot and learning about being a pro coder, then please stay tuned for my next article. But if you simply can’t wait, then check out this video I outline several steps in how to take that first step toward becoming a pro coder!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

5 reasons to pick up Java 17 today!

Thu, 05 Jan 2023 00:00:00 GMT

Java 17 is the latest version of one of the most popular programming languages out there. Being a core requirement to using Spring Boot 3.0, the de facto standard Java toolkit, it’s important understand some of Java 17’s most valuable features!

In this article, we will explore some of the key features of Java 17 and how to use them in your own projects.

Java 17 is here…and it’s awesome.### 1— Installing and Setting Up Java 17

Before you can start using Java 17, you will need to install it on your computer. It’s easiest to visit https://sdkman.io, install their JDK management tool, and then pick a distribution of Java 17 to install on your machine.

I have used either OpenJDK’s Adoptium Temurin distribution or BellSoft’s Liberica distribution. There are many others to pick from, but these two definitely are TCK-verified and rock solid.

If you have need to commercial support or more reliabilitity, you may need to investigate these distributions further and compare them to some of the others.

2 — Key Features in Java 17

Java 17 includes a number of new features and improvements that make it easier to write code and build applications. Some of the key features of Java 17 include:

Sealed Classes: Sealed classes allow you to specify which subclasses are allowed to extend a particular class, making it easier to maintain type-safety and control over your class hierarchy.
Text Blocks: Text blocks are a new type of string literal that makes it easier to write multi-line strings in your code. They automatically handle line breaks and indentation, making it easier to write and read code that includes large blocks of text.
Records: Records are a new type of data structure that make it easier to define simple classes that act as data containers. They provide a concise syntax for defining classes with a fixed number of fields, and automatically generate common methods such as equals and toString.

Why are sealed classes so cool?

In the past, you either kept your classes and interfaces basically public or private. There are differing flavors of this such as package private, which simply means public within a given package, but private beyond that. Once you open up a class or interface to public consumption, you open yourself up to risk.

If someone either extends your class or implements your interface, you may be seeing new tickets if you didn’t design it properly. Why do you think the purveyors of the JDK made java.lang.String final? Simple: they don’t want anyone extending any of its methods and mucking up their careful refinements.

The truth is, sealed classes gives you the ability to have something in between private and public. You are able to create a publicly visible interface…and define EXACTLY who can extend/implement it.

Sealed classes let you define a well-defined group of implementations and revise that down the road without opening the door to OTHER people extending it beyond your control. And that’s cool. True, it’s a bit early for us to see the full benefits, but I anticipate cool enhancements in the land of framework code.

https://stackoverflow.com/a/69218715/28214Text blocks move us closer to Pythonic apps. Python has had multiline text blocks for years. It lets you more stream-of-consciousness lay out description blocks, populate String-based annotation fields, and other stuff. No more fiddling with line breaks and “plussing” them together.

Finally, Java 17 records are the new way to model!

Seriously, I built a handy utility in just a few days to help me parse an app I use in my off hours that generate XML for Final Cut Pro. Using Java 17 records, I was able to model the source AND the transformed output in minutes.

Give it a spin!

3— Pattern matching switch statements

It used to be in the olden days, in the days of yesteryear, switch statements were clunky and tended toward code smells. That is, the limited usage of switch statements could often be rewritten into an OOP pattern.

If you didn’t, the pattern tended to get copied around.

However, Java 17 expands the power greatly, allowing slicker, more usable patterns. Check out the code block below:

return switch (obj) {  
 case Rectangle r -> 2 * r.length() + 2 * r.width();  
 case Circle c -> 2 * c.radius() * Math.PI;  
 default -> throw new IllegalArgumentException("unrecognized shape");  
};

Instead of being a statement, it’s now an expression whose operative feature is it can “returned”. In addition to that, we now have the arrow notation and no more need for break clauses.

Finally, notice how type support is now supported. This allows matching on class patterns, which further encourages algebraic types as discussed earlier.

NOTE: If the type of the switched object is a sealed class and all the types are covered, there would no need for a default clause. And your IDE can help you handle this!

4 — Pattern matching instance checks

One of the smaller features that really tickles my fancy is the ability to do an instanceof check with a built-in downcast. Look at the somewhat contrived code block below:

Object obj = "Hello World";  
if (obj instanceof String s) {  
 System.out.println(s.toUpperCase());  
}

A somewhat common pattern that has permeated code for ages is the need to test if a given object is a particular subtype. If so, downcase to it. This chunk of code introduces a name after the type in the instanceof check, granting us access to the downcast object.

Yes, it trims that single line which would have been String s = (String) obj, and yes, that simply ain’t a lot to get excited about.

But it’s a such a simple, elegant way to capture intent without the overload of casting, that I simply love it.

It’s tiny stuff like this that enriches a language to code the stuff we need.

5 — Conclusion

Java 17 is a powerful and feature-rich programming language that makes it easy to write code and build applications. With its new features and improvements, it is a great choice for developers looking to take their skills to the next level. Whether you are a beginner or an experienced programmer, there is something in Java 17 for everyone.

If you dig Spring Boot, then please stay tuned for my next article.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Tis’ the season to Spring Boot 3.0

Thu, 22 Dec 2022 00:00:00 GMT

As the yuletide season is upon is, this may be the time to not only pour yourself a glass of eggnog, but to give YOURSELF the gift of Spring Boot 3.0.

Spring Boot 3 has some of the most wickedly cool features out there. A boost in performance. And some reduced codebases overall. But I’m getting ahead of myself.

1 — Record types are the NEW way to model

When you start working on your delicious app, it’s time to pick up and run with Java records. This is courtesy of Java 17, Spring Boot 3’s new baseline.

Java records are something we’ve been asking for for years. It’s one of the features than any non-Java JVM-based language seems to lead with in any presentation. The old setter/getter paradigm may be hard to let go of, but once you do, it’s glorious.

I once hosted a live stream coding an OAuth 2 service that talked to YouTube’s API. Modeling every domain type I needed to deserialize their JSON (there were a lot), instead of being cringe-worthy became effortless.

Once I had rigged up the machinery to make remote calls to YouTube and had hooked in the OAuth credentials, surfing through their data types became FUN!

record SearchThumbnail(String url, Integer width, Integer height) {  
}

Java 17 records are immutable. They don’t have getters like getUrl(), but instead field accessor like url(). Don’t worry! JavaBean-based tools like Thmyeleaf and Mustache still work just the same.

You can write methods as needed to provide virtual fields and other things. But all in all, they are slim and trim. You can EVEN use them for your Spring Boot configuration property objects!

Simply put, try to use them as much as possible. There is simply no need to go back to the days of yesteryear, using clunky old POJOs.

WARNING: Any toolkit built on MUTABILITY won’t work with Java records. (I’m looking at you, JPA!) There are some tricks where you can use them as DTOs, and JPQL indeed supports DTO-based queries. But if you try to twist them into entity types, you’ll only bruise your ego.

Speaking of remoting services, Spring Boot 3 has a slick feature…

2 — HttpServiceProxyFactory is the NEW way to speak to remote services

We’ve all had to connect with remote services. RestTemplate has been there for ages and now we have WebClient as well. They both can ease the process.

But did you know that there’s a better way?

Spring Framework 6, the versiong underlying Spring Boot 3, brings us a way to implement interface-based remoting.

First, you must define your API as a Java interface:

interface YouTube {  
  
 @GetExchange("/search?part=snippet&type=video")  
 SearchListResponse channelVideos( //  
 @RequestParam String channelId, //  
 @RequestParam int maxResults);  
  
}

This interface defines the paths, params, and types involved in the exchange. The @GetExchange, analogous to Spring MVC’s @GetMapping annotation, defines the remote calls that are made. (There are matching annotations for other HTTP verbs). But the real magic is in HOW this interface is implemented.

Go into your @Configuration class and add this:

 @Bean  
 HttpServiceProxyFactory proxyFactory(WebClient webClient) {  
 return HttpServiceProxyFactory.builder() //  
 .clientAdapter(WebClientAdapter.forClient(webClient)) //  
 .build();  
 }

This bean will take your injected WebClient and use it as the engine for the proxy factory bean. (There’s also support for RestTemplate if you need it.)

Finally, you can link the two together, like this:

@Bean  
YouTube client(HttpServiceProxyFactory factory) {  
 return factory.createClient(YouTube.class);  
}

This little factory will create a proxy that honors the contract defined in the interface. Now, you need merely inject the YouTube object into any Spring bean, and POOF you can access remote services.

If you didn’t catch it, the WebClient that gets injected up above can be decorated in all kinds of ways. In Learning Spring Boot 3.0 3rd Edition, we explore how to register OAuth 2 handlers, allowing for remote calls to OAuth-protected APIs.

3 — Native applications

One of the biggest bumps in power and productivity is the emergence of native applications. Native applications are apps where you trade in Java’s long-standing promise of write-once/run-anywhere in exchange for compile-to-platform/dial-up-performance.

Native apps can switch from 30-second startups to sub-second startups. While not an issue for classic web server apps that are up all the time, for command line utilities, it’s revolutionary. If you’re using AWS Lambda Functions, you’ve shifted the cold-start time to virtually nothing.

And if you’re running 10,000 instances in the cloud, you can shave HOURS off your cloud bill, a real game changer in savings if you are also pushing out 100 commits a day.

The secret to unlocking native apps is:

Install GraalVM CE using sdkman on your local machine by typing sdk install java 22.3.r17-grl
Using start.spring.io, add all your existing app’s dependencies + GraalVM Native Support. Hit the EXPLORE button and copy the changes from the build file into your own project. Refresh your project.
After switching over to the GraalVM CE JDK, build your app natively by typing ./mvnw -Pnative clean native:compile

Once completed, instead of an uber JAR, you’ll have a native app compiled right into your target folder.

If you want to know how epic this is, my friend Maciej Walkowiak just released a new Spring tool called “just”. It’s a CLI that does Spring stuff for you. And he built it using Spring Boot + native app development.

With all these changes at your fingers, I wish you a cup of cheer as you embrace these latest changes from Spring Boot 3.0!

If you dig Spring Boot, then please stay tuned for my next article. But if you simply can’t wait, then check out this video where I live stream configuring a Spring Boot app to talk to YouTube and make our own video-serving app, using the very techniques listed above!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

When should I call for help as a software developer?

Thu, 15 Dec 2022 00:00:00 GMT

If you’re here, I’ll go right along and assume you are a Spring developer. You’re either building apps with Spring Boot, or you’re learning about Spring in your Uni/bootcamp program, or perhaps you’re responding to questions on stackoverflow.com.

If you are, great!

Spring is popular…for a reason. Spring has a long history of solving problems. Of COURSE people want to use it. But maybe you’re staring at a chunk of code and wondering, “what do I NOW??”

You’re beleaguered from moving forward because something stumps you. If you haven’t felt that yet, don’t worry. It will happen some day. ALL software developers run into this. And not just once. I have.

That’s why we need lifelines. One of the most powerful tools we as software geeks can have in our possession is a collection of fellow coders we can reach out to and ask for assistance.

Not only can getting help move us along…it’s one of our best instructional tools available.

When something goes wrong, and we make it then go right, we learn in the moment. The NEXT time we encounter something similar, we may solve it faster. Or perhaps we may spot it before it becomes a problem, and head it off.

But asking for help is hard. It requires surrendering our personal ego. A certain amount of vulnerability is communicated when we say, “I need help.”

At a previous position, I once inherited a Java Swing app. It “worked”, but was fraught with bad design practices, had horrible performance, and anytime someone hit the SAVE button, it would take 20 minutes to complete. I have shared this war story so many times, it ridiculous. I spent something like three weeks SIMPLY TRYING TO GROK the database operation behind that SAVE button.

There were no tests. No notes. Just a view and a UI.

I figured it out eventually. The original developer had reached for multiple database views that had what he needed, and had joined them together. If you didn’t know it, join views is BAD. The mega-query at work ended up joining the same table TWENTY TIMES.

After unravelling what it did, I wrote a fresh query that did the same…and it went sub-second. I rolled out that patch to the users, and alerted them to this small change, a change that probably saved them from thousands of hours of wasted time in the future.

This developer had worked EVERY hard to implement it. But didn’t pause and ask for help. I don’t know the story behind this person. Maybe they indeed were too proud? Or maybe help was simply short at the time.

My point is that this instance has reminded me over and over, throughout my career, that it’s usually better in the end if we check out pride at the door and instead reach out for feedback and inputs more often. If when things get a bit challenging, we reach out for help.

And if at all possible, don’t work silently, in a corner, in isolation, avoiding all the opportunities to learn and grow as a software developer.

So anytime YOU are challenged in a situation, reach out for assistance. Anytime YOU are given a task, you can simply share what you are doing, whether it’s with your instructor, your manager, or your technical leader.

Sharing what you’re doing in a consistent fashion opens up the lines of communication and makes it easier to THEN say, “You know that thing I’ve been working on for the past three days? I seem to have hit a wall. Can we Zoom for 15 minutes where I share what’s happening?”

The person you share with may not even say a word in the whole Zoom chat. Sometimes…simply enunciating the struggle you are facing can put the answer into focus.

My nephew who is about to graduate high school, has called me late at night in the midst of coding projects. And there has been more than one occasion where simply talking to me over the phone while are both looking at the same code, he figures it out. With little more than a “what’s that?” from me.

But even if you DO need actionable advice for a colleague, it’s okay. This is software REALLY works.

None of us REALLY survive by working weeks on end in a secret room all by our lonesome selves.

Nope.

We REALLY thrive when we work together. Everyone has different talents. Different skills. Different things we have a certain nose for.

One member of our team is REALLY good with JDK-type classfile-based stuff. We also experts on some of the deepest, most intricate details of the Java programming language. My super power is being able to hack my way through server-side dev-ops-ish type stuff and bending CI systems to do my bidding.

Understanding what you can (and CAN’T do) is a point of self awareness. And recognizing that while I’m great at relational databases and can write left outer joins and correlated subqueries in my sleep, I’m still growing my my knowledge of the depths of JPA. (Thankfully I’m surrounded by several experts!)

When we harness our strengths and reach out for others’, that’s when we thrive. And that’s when everyone thrives.

If you want to see more articles about Spring Boot in general, then please stay tuned for my next article. But if you simply can’t wait, then check out the video below where you can learn the differences between JDBC and JPA, and when to use what!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

What to do on your first day/week/month/year as a Spring developer!

Fri, 09 Dec 2022 00:00:00 GMT

So you’ve finally done it! You landed that dream position writing Spring Boot apps for a cool software company.

And then the shock of it hits you…what do you DO? Are you ready? Are you prepared? What should you be doing?

### 1 — What to do on your first day

It’s fair to assume that IT will onboard you access to email and whatever IM tool the team is using, be it Slack, HipChat, whatever.

Make a point of finding out who your immediate manager is as well as your immediate team mates. Write down their names.

That’s right. Be it a little sticky note, your iPhone’s Notes app, whatever. Write down these people’s names. You may never read that note again, but the very act of writing down this information will help commit it to memory. And knowing who your immediate teammates are is key.

You may get invited to a particular room/channel pertinent to the team you’ve joined. As you see messages posted, take note of WHO has written those messages. You can probably click on the person’s avatar and ideally see a picture of them as well.

That is not all.

While you are reading a flurry of messages, take it easy. No one is expecting you to solve the world’s problems on your first day. Just try to drink it all in. Read every message. If there’s a link to a blog post with comments, go read that article. If there is a link to a fragment of code, click on it and start reading the code.

Absorbing code starts with reading it. If you’re lucky, it could be something you’re already semi-familiar with. But that’s not always the case.

Also, your new manager may have a set of actions for you to carry out including: registration with various systems, filling out some e-forms, and other “paperwork”. Do it. It’s time to start showing you’re a team player by carrying out your immediate assignments.

And above all…listen. You’ll be getting fed a firehouse of information. Don’t sweat it, and simply listen and read. (And if you’re smiling with excitement at your new position, that’s okay as well.)

2 — What to do on your first week

We talked about what to do on your first day. But what are some key things to do on your first week?

Have you gotten in touch with the system adminstrator and registered your github id? Sophisticated teams may have already covered this in their onboarding procedures, but not everyone is this deft. Giving them your github id will enable them to grant you access to the repositories you will be working on.

Here’s a biggie: have they sent you a work machine yet? If you’re working remotely from home, maybe not. Make sure the provisioning department has your mailing address so nothing on your end delays sending you a work machine. (If you don’t even know who to contact in the provisioning department, this is a great time to reach out to your manager.)

Assuming you DO have a work machine, have you cloned the immediate repository you are assigned to and:

Started reading the code?
Installed the right tools to build it? (Java, Maven, Gradle, sdkman)
Inspected any CI tools used to build it? (Jenkinsfile, .circleci/, .github/)

Again, the idea isn’t to start building epic features, but to instead become familiar with how to build the systems.

Also, carve out plenty of time to start reading the code.

BONUS: After the first week, you may want to start reading the backlog of tickets. Start getting familiar with the problems the users are running into. One again, this isn’t so that you’re ready to solve them. Instead, to start getting a feel for the pain points the community is hitting.

3 — What to do on your first month

I have often seen a month as the MINIMUM amount of time for me to start getting the hang of a given project. This presumes I have been reading the code, building the artifacts (e.g., ./mvnw clean package), and trying to nudge little things here and there.

I mentioned earlier to start reading the code. This should include the reference docs, which many projects include inside the source code. If not, find out where they are and start reading that as well.

Because one of the first things you can “do” in your first month, is to submit a pull request (PR) patching the ref docs. Fixing a typo, rewording a sentence. Anything along these lines. BONUS: Learn how to render the docs and inspect your handiwork. (You can often find this is you read the CI files.)

Other stuff you can be doing within the first month is spotting any sloppy code, old patterns (e.g., missing generic parameters, missing usage of the diamond operator, etc.), or unused import statements. Anything that simply “cleaning up” the code without actually changing the code.

And you should be learning exactly how your team handles change. Have they given you free reign to simply commit to the main branch? (Unlikely) Or do they want you to submit a pull request to GitHub and then request a review? And do they let you merge the change, or does someone else handle that?

Finally, something else you should be taking notes on is exactly HOW your team curates the change log. In other words, how does your team format commit messages? And how do they DO merges? Create a branch, rebase, then merge back? Cherry picking? What about multiple supported versions? Are you supposed to work against the latest and backport…or work against the oldest and merge forward?

If this is starting to sound overwhelming, that’s cool. Learning HOW your team does commits may be more of a Month 2 or Month 3 thing. And this doesn’t mean you are DOING the process. I’m just asking you to BECOME FAMILIAR with how they are doing it. If you have an approved change, you can also ask to do a pairing session to help you walk through the process.

4 — What to do on your 6th month

By this stage, I hope you have:

Learned how your team handles changes, be they new features or bugs.
Become familiar with how they use CI and work with it, not against it.
Gotten ramped up on how tickets are managed.

Six months in, and you should be making changes. You may not be building the biggest stuff (yet), or maybe you are? However, what’s more important than implementing the biggest features is learning how the rhythm of your team.

Learning how to bring value to the table calmly and consistently. They hired you for a reason. It wasn’t to be combative, but instead contribute to the team. While implementing Big Stuff is cool, closing out a dozen tiny tickets with small stuff is always a good idea and will earn you some well-deserved allies.

We all make mistakes (myself included). If you have shown your ability to knock bugs and patches, teammates are willing to work through mistakes. If you aren’t pulling your weight, mistakes can turn against you much faster.

Again, focus on your team’s process and strive to contribute to it every day.

5 — What to do on your first year

Your anniversary of your new position rolls around. It might surprise you when it does! This is a time to celebrate.

And hopefully, it’s also a time to push forward with providing even more value. And ideally, at this stage, you have built up a sense of the tools and apps you are assigned to.

But don’t settle for that. Because you should also have a feel for the types of requests and bugs the community has been reporting. You need to start looking to the future, and asking, “What should we add that would support the community the best?”

You can’t always ask people what they want. They don’t always know. This is Apple’s mantra — building visionary products. Sketch out some ideas and discuss them with your team. This is the future, not just fixing bugs but instead figuring out where the app will go!

Also, you should be looking at ways your apps interact with other apps you don’t work with directly. The Spring team has multiple sub-teams, each working on various parts of the portfolio. And all these sub-teams work with each other to make all the tools work together. You should be seeking to do the same.

And with a year under your built, don’t stop. Because you’re just getting started. Where are you in your current journey? Share it in the comments below!

If you want to see more articles about Spring Boot in general, then please stay tuned for my next article. But if you simply can’t wait, then check out the video below where you can double check that you’re doing all you can to bring value to your team in these challenging economic times.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Using Micrometer to trace your Spring Data JPA application

Thu, 01 Dec 2022 00:00:00 GMT

In a previous article, we saw the goodness of stirring a little Micrometer into our Spring Boot 3 application to trace what our application did. We saw how to activate the Micrometer bindings buried deep in Spring Boot for web calls. And we piped all those good metrics into Zipkin, the open source distributed tracing system thanks to Docker.

But that wasn’t very “realistic” cuz we didn’t have a “real” database underneath it.

Everyone know that real apps have data, right? So why not put something together!

To kick things off, after fashioning an app using start.spring.io, Spring Data JPA, and H2, we need a domain object. Let’s craft something like this:

@Entity  
public class Employee {  
  
 @Id  
 @GeneratedValue private Long id;  
 private String name;  
 private String role;  
  
//...constructors/getters/setters ommitted for brevity...  
}

A basic domain object that lets us model the Employees in our payroll system. This entity class is properly annotated with @jakarta.persistence.Entity (remember Spring Boot 3 is on Jakarta EE 10!). It also has the id field marked up as the primary key using @jakarta.persistence.Id. We will also let the JPA persistence provider handle primary key generation by using @jakarta.persistence.GeneratedValue.

Even though Spring Data provides some cool features, we STILL have to model our entity classes properly for things to come together!

Since we’re using Spring Data JPA, we also need to define a repository. So let’s do something like this:

public interface EmployeeRepository extends JpaRepository<Employee, Long> {}

This barebones interface definition extends Spring Data JPA’s JpaRepository and defines its domain type as Employee and the primary key type as Long. Even though our interface definition is empty, it still comes packed with LOTS of options. (Just visit JpaRepository and its parent interfaces inside your IDE to see exactly what you get!)

The rest of the application is just a Spring MVC @RestController, much like what we had in the previous article, shown below:

@RestController  
public class EmployeeController {  
  
 private final EmployeeRepository repository;  
  
 public EmployeeController(EmployeeRepository repository) {  
 this.repository = repository;  
 }  
  
 @GetMapping("/api/employees")  
 List<Employee> all() {  
 return repository.findAll();  
 }  
  
 @GetMapping("/api/employees/{id}")  
 Employee one(@PathVariable Long id) {  
 return repository.findById(id) //  
 .orElseThrow(() -> new RuntimeException("Employee " + id + " not found!"));  
 }  
}

This REST controller will inject our EmployeeRepository bean into the controller and then use it to either find ALL employees, or just one.

So where is all this magical tracing?

Good question. The answer is…it’s not here yet. That’s because we need a few additional things in our project.

When building our app inside start.spring.io, we must also include Spring Boot Actuator.
We also need to add Micrometer and its bridge for Zipkin.

<dependency>  
 <groupId>io.micrometer</groupId>  
 <artifactId>micrometer-observation</artifactId>  
</dependency>  
<dependency>  
 <groupId>io.micrometer</groupId>  
 <artifactId>micrometer-tracing-bridge-brave</artifactId>  
</dependency>  
<dependency>  
 <groupId>io.zipkin.reporter2</groupId>  
 <artifactId>zipkin-reporter-brave</artifactId>  
</dependency>

Almost there. We just need one teensy little dependency:

<dependency>  
 <groupId>net.ttddyy.observation</groupId>  
 <artifactId>datasource-micrometer-spring-boot</artifactId>  
 <version>1.0.0-SNAPSHOT</version>  
</dependency>

This last dependency is a special module that will wrap ANY DataSource bean with a proxy that uses Micrometer APIs to log actions.

JPA speaks DataSource?

Yup.

DataSource is an interface from the JDBC spec. And JDBC is the standard through which ALL Java applications speak to database. So every JPA app, every jOOQ app, every Querydsl app speaks JDBC when it comes to linking up with relational databases.

Wrap a DataSource bean and you can trace ANY relational database application with Micrometer.

BTW, R2DBC is another Java standard used to talk to relational databases, and that is ONLY for reactive applications, not what we’re doing today.

Apply these settings to our application.properties file:

# Trace every action  
management.tracing.sampling.probability=1.0

…and we’re set! Time to launch the app and give it a spin. (Don’t forget to be running Zipkin from Docker Desktop).

Query the endpoint, and we have our outputs from that controller class we just built. Now let’s go see what it says in Zipkin.

Querying for traced, we can see http get /api/employees. Looks like what we want. Click on SHOW and we should see this:

We can see from the left-hand side, that Spring MVC traced the call to http get /api/employees. From there a connection was opened. Then a query was made against the database followed by processing a result set.

By clicking on the query box, we can see the tags on the right hand side, including the jdbc.query that was executed. And we see that a JPA query, fashioned for by Spring Data JPA’s query derivation layer, was ultimately transformed into a JDBC query by Hibernate’s Entity Manager.

And the query itself only took 270 microseconds. Looks like this query doesn’t much in the way of tuning, ehh?

But these tools now provide the means to track down what DOES take a long time. Maybe one of the queries you build is just not every efficient and needs to be rewritten? Or perhaps something else is fault in the assumptions made.

Either way, these give us some nifty tools to measure results and effect change!

If you want to see more articles about Spring Boot in general, then please stay tuned for my next article. But if you simply can’t wait, then check out the video below where we learn a little more of what JDBC is all about.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Twas the night before Spring Boot 3.0 went GA…

Thu, 24 Nov 2022 00:00:00 GMT

Spring Boot 3.0 goes GA tomorrow.

That is EXCITING! Why? Because this is another of those epic releases where the raw power of Java will again leapfrog forward. And the Spring team, once again, is there to help bring it to your fingertips…with ease.

### 1 — Java 17, baby!

Java for the longest time came in what seemed like tiny increments. But when Oracle took over and began making releases every six months, it suddenly got crazy…and fun, starting with Java 9.

While Java 8 has been a powerhouse including things like lambda functions, the Stream API, and other slick features, it’s time to move up to uber awesome Java 17.

Java 17 brings a fistful of enhancement including:

New and improved methods to the Collections library, e.g. List.of(1,2,3) (immutable!), List.copyOf(otherList) (again, immutable), and more.
Record types — build data types and DTOs with minimal effort
One of my favorite…types instanceof. Are you tired of doing an instanceof check against a variable and then downcasting to that type? Java lets you do that one statement. if (shape instanceof Rectangle r) /* refer to r as a Rectangle! */
Performance speed ups
var — ALERT: Use sparingly

There is certainly more, but this should already whet your appetite. Spring Boot 3.0 and the rest of the matching portfolio will be moving up to Java 17. Of course, older versions of Spring are still based on Java 8.

2 — Jakarta EE 9+

After Oracle turned the Java EE specs over to the Eclipse Foundation, they have since rebranded it as Jakarta EE. This includes servlets, JMS, JPA, and many others. What was once Java Messaging Service is now Jakarta Messaging Service.

And Jakarta EE 9 is the version where all these specs changes their package prefix from javax to jakarta. (Oracle wouldn’t grant Eclipse the javax prefix nor give them any sort of license).

Fun fact, Apache Tomcat 10 reached end of life sometime last month. To pick up the next iteration of Tomcat, Spring Boot has adopted Jakarta EE 10 regarding servlets. However, there isn’t a lot of differences between Jakarta EE 9 and 10, so various parts of the portfolio work with both.

Yours truly had to really work over the last few months to make Spring Web Services catch up to Jakarta EE 9+ considering SOAP stuff probably has the most hooks into Java…err…Jakarta specs.

But that is not all that is coming with Spring Boot 3.0.

3 — GraalVM and native images

The Spring team has been working for over a year at adding support for building native images so that your Spring Boot application could run in the mega-fast GraalVM, an alternative to the JVM.

It started as an experimental module called Spring Native, to be added to Spring Boot 2.7 apps. But with Spring Boot 3.0, GraalVM support has been brought into the portfolio projects themselves.

No Spring Native project needed.

The team has worked to ensure Spring apps of all flavors are easy to build for GraalVM. Why? Because GraalVM is mind numbingly fast and very saavy with memory management.

Again, why is this important? If you are running 1000 instances in your favorite cloud provider and you roll out a change, then 30 seconds of startup began to really add up (compared to native apps, which is for the sake of calculation, next to 0).

Trimming off that 30 seconds of startup time can result in over 8 hours of startup time shaved off your monthly cloud bill.

Imaging paying an 8 hour surtax for every commit! What if you pushed out a patch twice/week? That becomes 64 hours of needless time just to start up your app. The savings really kick in.

But these aren’t the only things coming with Spring Boot 3.0. Each portfolio project has some really cool changes, which I’m not going to dive into in this article. Tell me in the comments which Spring projects YOU use the most!

If you dig Spring Boot, then please stay tuned for my next article. But if you simply can’t wait, then check out this video where you learn what Jakarta EE is and why it’s so important to the Spring portfolio.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Deleting code is the way to go!

Thu, 17 Nov 2022 00:00:00 GMT

I spotted a fun tweet earlier today that brought up one of the happiest moments in my coding career.

The celebration is over a couple Spring geeks having ripped out a HUGE and unnecessary bunch of bloat known as Node.

Now before you laugh and howl (or cry and shout), this has nothing to do with Node. Instead, it’s about what’s needed vs. what’s cool. We ALL have a tendency to write using our favorite toolkits. It’s hard to shake!

In fact, I recently wrote an article about When to NOT use Spring Boot. This problem we software developers have is universal. I like Spring Boot, I tend to use it everywhere I go. Node devs like Node, they tend to use it everywhere they go.

A veteran software developer must learn to rise above such strong emotional desires to run with our favorite toolkit, and ask the question, “What is BEST in this scenario?” And oftentimes, the corollary question, “What will the readers/users of this most likely know/not know?”

Back when we published all the guides at https://spring.io/guides, we put forth a guiding vision that each guide in and of itself would be self-contained. A guide wouldn’t be much of a guide if someone had to read three other side articles to finish it. And it also wouldn’t help if they had to complete some other guide first.

No, none of that would fly. So we made the decision to make each guide self-contained, and to explain all the key bits by the end. Someone giving away their lunch break to try and grow their Spring knowledge needed to be rewarded with a feeling of accomplishment. And that’s exactly what we did.

At the top of this article I mentioned “one of the happiest moments of my career”. That would be the time before I joined the Spring team. I took over someone else’s back office application. Something that had cost literally MILLIONS in invested time (six previous developers had apparently handled it). And it was NON-OPERATIONAL.

This app, meant to digest about 300 monthly invoices and spot discrepancies, had been gobbled up in “patternization”. (Patternization is a word I just made up to indicate usage of patterns exceeds value of patterns.)

This app’s purpose for the accounting department to go through statements, spot problems, and issue corrections so we could not pay so much. And we’re MILLIONS of dollars. Every month.

The app simply didn’t work.

These invoices were spreadsheets and the app had a beautiful abstraction for rows and columns. But it simply didn’t work.

These 300 invoices actually had about five special formats (not 300), so they weren’t unpredictable. But it simply didn’t work.

The requirements were almost unchanging. But it simply didn’t work.

For something so small in scope, so simple in requirements, and so slow to change, it was strange (to me) that it didn’t work.

When I picked it up, I vowed to not change a single line of code without writing a test case first. (The app had next to NO test cases). And so I got busy.

I wrote painstaking test cases. And edited code. Another test case, another patch. Another test case, another tweak. And soon, in the span of 1–2 months, I built up a suite of tests.

And I reached a point of awareness where I KNEW that spreadsheet abstraction served no purpose. And I also knew I could rip it out without anything being damaged.

And so I did.

I deleted a chunk of code, and suddenly the whole app leaped forward in speed. I was running this test suite at least once a day. It would often take 30 minutes to execute. It would also creep up toward an hour, and I’d spend a day tracking down what needed to be fixed, be it tests or production code.

The spreadsheet abstraction wasn’t the only thing I ripped out. I yanked other stuff that my test suite exposed as unnecessary.

I also started meeting with program managers, the users, and others. I started to implement features they needed. I also kept writing tests.

Once, I ripped out a HUGE chunk of code…

…and break half the tests. Three hours later, it still didn’t work. So I scrapped all the changes I’d made for the day and went home worn out.

Next day, I started fresh, and moved in a different way. The tests had told me that I had gone too far, and gave me the confidence to back up and start over.

Merrily moving along over the next six months, I was meeting weekly with the users. The application was working. The users were actually doing their jobs much faster. We would get together, brainstorm new ideas which I’d collect in a slideshow. One page per “idea”.

And I’d go back to my desk, translate these slides into test cases (one test case per slide) using the lingo we had spoken in the meeting. And I’d code the corresponding solution.

Tests STILL took about 30 minutes to run. But then something happened.

My manager called me into his office. He was preparing for the next quarterly meeting with the VP of engineering and was putting together his report.

He showed me the lines of code they ran, and pointed at my application. Instead of having an exponential GROWTH curve, it instead had an upside-down PARABOLA shape. Indeed, I had REDUCED the total amount of code in this application by a HUGE amount.

And the application did more than EVER. And…

…it worked.

The application simply worked. It met the needs of the users. They were getting through monthly invoice reconciliation at a slim and trim speed. Considering these users operated on overhead, this had caught the attention of upper management.

And they couldn’t be more pleased. Total cost of maintenance was DOWN while throughput was UP.

All because of a solemn promise I made to myself.

Don’t fix anything without writing a test case to capture it.

If you dig Spring Boot, then please stay tuned for my next article. But if you simply can’t wait, then check out this video where you can learn EXACTLY what you need to do to increase the value you present to your team and how to cushion yourself from these economic challenges.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Using Micrometer to trace your Spring Boot app

Thu, 10 Nov 2022 00:00:00 GMT

If there’s one thing that eventually sneaks up on you after building and releasing an application, it’s that something breaks. Yup, applications break and not long after, our manager is asking, “What happened?”

That’s not the only thing we encounter in the Land of Production. We also sometimes see performance degrade. Certain parts of our system seem bogged down. And once again, the question arises, “What’s going on?”

This is what tracing affords us. A means to trace an operation through our application combined with metrics showing us what’s eating up all the time. And for this we turn to Micrometer.

Micrometer, launched in 2017 by the Spring team, it a metrics facade. It supports a whole host of tools, but for today we’ll use the open source distributed tracing system Zipkin.

Setting up a Spring Boot 3 application

Do you already have a Spring Boot 3 app you’d like to instrument? Great! You can skip on to the next section. In case you don’t, you’ll want to file some very simple steps.

Visit https://start.spring.io
Pick your favorite build tool. (I’ll be using Maven).
Pick the latest version of Spring Boot 3. (I’ll be using 3.0.0-SNAPSHOT).
Just leave the project metadata as is.
From the dependencies panel on the right, pick Spring Web and Actuator
Click on the GENERATE button, download the ZIP file, unpack it, and import it into your favorite IDE!

With that in place, you’re all set to get going!

Adding Micrometer to your Spring Boot 3 application

The first step to instrumenting your application is to add Micrometer. Now it’s important to understand that Micrometer actually has two key aspects: tracing and metrics.

Tracing — seeing WHAT happened
Metrics — seeing HOW LONG it took to happen

Sometimes people want one of the other. But for this article, we’ll do both. And to do that, you need to add the following to your build file:

<dependency>  
    <groupId>io.micrometer</groupId>  
    <artifactId>micrometer-observation</artifactId>  
</dependency>  
<dependency>  
    <groupId>io.micrometer</groupId>  
    <artifactId>micrometer-tracing-bridge-brave</artifactId>  
</dependency>  
<dependency>  
    <groupId>io.zipkin.reporter2</groupId>  
    <artifactId>zipkin-reporter-brave</artifactId>  
</dependency>

micrometer-observation — this pulls in the Micrometer code responsible for making Observations.
micrometer-tracing-bridge-brave — this pulls in the Micrometer Tracing facade along with glue code to use Brave, the tracing solution from the Zipkin team.
zipking-reporter-brave — a little more glue code to adapt Zipkin with Brave.

There’s a lot of terms thrown in there, so let’s discuss a little further. Micrometer has a concept called an Observation. This is when you essentially want to “see” what has happened during a key operation. This could be when a web request is made. Or when a database is accessed. The idea is that you A) start the Observation, B) do the action, and C) stop the Observation.

What if you wrap an Observation around a web method in your Spring MVC controller? Does this mean, that if inside the web controller, a Spring Data repository is invoked, we’d have to repeat the SAME PATTERN there too?

Yes…and no.

Instrumenting your code

Micrometer’s APIs are carefully designed such that when you start an Observation, the context of the scenario is stored and then passed along. For a a classic Spring MVC app, thread locals are used. This is done in a way such that every method in the call stack is able to grab the Observation and add to it. Essentially, more information can be gathered.

So this is the “yes” part of the answer. To trace every step in a call stack, you need to do this pattern in every method.

But the “no” part is that YOU DON’T HAVE to.

The Spring team has been working diligently at instrumenting all levels of the portfolio such that it’s already done. Building a Spring MVC controller? The DispatcherServlet and all its components will have already started an Observation before you web method is called.

Making a remote HTTP call to a 3rd party service? The Spring Framework team has instrumented RestTemplate and WebClient so the Observation pattern wraps around every remote call made. (And Micrometer is slick enough to pass along the tracing context over network boundaries!)

Running your own copy of Zipkin

To make the magic happen, you need to run your own copy of Zipkin. Using Docker, this is a snap. Just execute the following command:

docker run -d -p 9411 openzipkin/zipkin:latest

Once you execute this, you can then visit the it at localhost:9411.

With that in place, you just need to do some final tweaking to get your application ready to go.

Configuring your Spring Boot application for tracing

It doesn’t take much.

For starters, does your application include spring-boot-starter-actuator? The Actuator module is required for tracing to operate. If not, go update your build file. I’ll wait.

Now add the following attribute to your application.properties file:

*# Trace every action*management.tracing.sampling.probability=1.0

By default, Micrometer only traces 10% or 0.1 of the time. This is to avoid taxing your system too much. (Actually a problem I’ve seen in my career is that tracing can get WAY out of control.)

We’re ONLY dialing up the levels to make it easier to see the tracing. For a real world, production system, you may want to back off to 0.1.

Coding a Spring MVC controller

If you already have a controller, then you’re all set. If not, you can borrow mine!

@RestController  
public class EmployeeController {  
  
   private static final List<Employee> *DB* = new ArrayList<>();  
   static {  
      *DB*.add(new Employee("1", "Frodo", "ring bearer"));  
      *DB*.add(new Employee("2", "Bilbo", "burglar"));  
   }  
  
   @GetMapping("/api/employees")  
   List<Employee> all() {  
      return *DB*;  
   }  
  
   @GetMapping("/api/employees/{id}")  
   Employee one(@PathVariable String id) {  
      return *DB*.stream() *//* .filter(employee -> employee.getId().equals(id)) *//* .findFirst() *//* .orElseThrow(() -> new RuntimeException("Couldn't find " + id));  
   }  
}

With all this, we’re ready to do some tracing!

Tracing the application

Fire up the application by running the class that has the @SpringBootApplication annotation. Now on the command line, run this command:

curl -v localhost:8080/api/employees

You should see something like this:

(I actually use brew install jq and pipe the outputs through that, to make it easier to read)

This shows our little demo data being nicely printed out on the command line. But what can we expect to see if we hop on over to Zipkin at localhost:9411?

Hit the RUN QUERY button, and you should something like printed out below:

This is the Spring MVC web call just made. The whole duration of that Observation was about 18 ms.

Click on SHOW and you can see something like this:

You can see the same duration at the top. It’s also tagged contextually as an “application”.

You can see bonus tags that context additional content about the web request including:

exception: none
http.url: /api/employees
method: GET
status: 200

There is more.

You may also be interested to know that there is a movement afoot known as OpenTelemetry that strives to have a consistent set of tag names such that ALL tracing tools can offer a more consistent dialect, making it easier for you and I to consume this type of output.

Micrometer strives to uphold this standard and has shifted many of its tags to fit this nomenclature.

In fine print, you can find its Span ID. A Span ID is kind of a decoder ring issued by Micrometer. They are automatically generated every time you create a new Observation. And they are passed along in thread locals, in web request headers to remote services, returned in web response headers, and even propagated through reactive subscriber contexts. These spans and their IDs make it possible to track the performance of every hop along the way and bring home all the data to trace your app.

With all this, you are able to start tracing your application and see what’s happening.

Now if this felt a little contrived because there was no database layer or remote web service layer, I hear you. However, this article has gotten a little long, but I’m working on another one, where we will see how to hook in a REAL database!

If you want to see more articles about Micrometer and Spring Boot in general, then please stay tuned for my next article. But if you simply can’t wait, then check out the video below where we explore how to serve up web templates using Spring Boot 3!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

How to serve a web template with Spring Boot

Thu, 03 Nov 2022 00:00:00 GMT

How to serve a web template with Spring Boot

If you’re building a Spring Boot application, then odds are, you’re building a web app. Web apps have been on the rise for twenty years…

How to serve a web template with Spring Boot

If you’re building a Spring Boot application, then odds are, you’re building a web app. Web apps have been on the rise for twenty years. And with Spring Boot, it’s easier than EVER to build one!

So let’s get to it!

1 — Getting started

To build ANY Spring Boot application, you’ll want to visit https://start.spring.io. This magical web site lets you grab everything you need to build an app. Pick the following options:

Build system: Pick your favorite. I like Maven, but many love Gradle.
Language: Leave this on Java.
Spring Boot: Pick 3.0.0-SNAPSHOT (living on the edge!)
Project Metadata: Leave it be.
Dependencies: Spring Web and Mustache

With all this selection, click GENERATE. You’ll get a ZIP download. Unpack it and then import that new folder into your favorite IDE.

2 — Building a domain of knowledge

We need SOMETHING to put on it. Since this is Spring Boot 3 and we’re on Java 17, we can use records to define a nice simple type:

record Video(String name) {  
}

We’ll create a one-field record type that represents a YouTube video. (Why not?)

Java 17 records don’t require constructors, equals, hashCode, or toString methods. They come fully loaded. Yes, it’s possible to augment them, but for the simplest of POJOs, this is all it takes!

3 — Assembling a controller

Controllers are classes that process web requests. And so, to serve up a web template, we’ll need one!

Make a HomeController class like this:

@Controller  
public class HomeController {  
  
private List<Video> videos = List.*of*( *//* new Video("Need HELP with your SPRING BOOT 3 App?"), *//* new Video("Don't do THIS to your own CODE!"), *//* new Video("SECRETS to fix BROKEN CODE!"));

  @GetMapping("/")  
  public String index(Model model) {  
    model.addAttribute("videos", videos);  
    return "index";  
  }  
}

The @Controller annotation lets Spring Boot know that this class handles web requests and uses a templating engine.

The @GetMapping(“/”) annotation signals that this index() method will process HTTP GET / calls. Since we want to populate the template with data (well, canned data in this article), we have injected a Spring Model object.

We set attribute “videos” with the actual values from our little List of Video objects. Anything assigned to this model will be merged with the generated web page.

Finally, we return the name of the template we wish to render. Now Spring Boot will take this name and marry it with the templating engine of choice to actually find the template, which we’ll cover in the next section.

4 — Crafting a templating

Since we used Mustache, Spring Boot will expand the name “index” into src/main/resources/templates/index.mustache. Create a file of that name and add the following:

<h1>Greetings Spring Boot Learning readers!</h1>  
  
<ul>  
  {{#videos}}  
    <li>{{name}}</li>  
  {{/videos}}  
</ul>  
  
<form action="/new-video" method="post">  
  <input type="text" name="name">  
  <button type="submit">Submit</button>  
</form>

Mustache is incredibly lightweight. The {{#videos}} tag (notice the sideways mustaches?) is the directive to expand the list of the “videos” attribute into a separate

element for each entry in that list.

Each entry is then accessible by property name. Given our Video object has a “name” field, we can reach each it using {{name}}.

The rest is a simple HTML form with one text input for the “name” and a submit button.

5 — Processing a new entry

To consume this form, we need to go back to the HomeController and another web method handler, like this:

@PostMapping("/new-video")  
public String newVideo(@ModelAttribute Video newVideo) {  
  List<Video> extend = new ArrayList<>(videos);  
  extend.add(newVideo);  
  this.videos = List.*copyOf*(extend);  
  return "redirect:/";  
}

Spring Web’s @PostMapping annotation maps the HTTP POST /new-video call onto this method. And the @ModelAttribute will deserialize the incoming data from the HTML form into another Video object.

Earlier in this article, we initialized videos using List.of(), which creates an immutable list. To expand it, we have to effectively replace it with a bigger one. And so create a new list, add the new entry, and then use List.copyOf() to produce a new, immutable one.

Finally, with the new entry added, we can return back a “redirect:/”, which will tell the browser to redirect back to “/”, which should hit our first web method coded earlier, causing it to re-render the original template but with our new data.

With all this in place, we can now run the class original generated by start.spring.io that has the @SpringBootApplication annotation applied and take our application for a spin.

If you dig Spring Boot, then please stay tuned for my next article. But if you simply can’t wait, then check out the video below where you can get a deeper dive with the fun that is Spring MVC!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Spring Boot 3.0 approaches!

Thu, 27 Oct 2022 00:00:00 GMT

We’re getting into the home stretch. With Spring Boot 3.0.0-RC1 coming out last week, some wickedly cool stuff is headed your way.

1 — Jakarta EE 9

I recently created a video on exactly what Jakarta EE is in the grand scheme of Java, but the nugget to chew on is that Spring Boot 3.0 will be bearer of Jakarta EE 9.

This is the version where all the enterprise specs migrate from javax.* to jakarta.* .

Some specs are part of the Java SE and never were part of Java EE, so they are not part of Jakarta EE 9. This includes stuff like JDBC, which I flubbed my recent video by mentioning it as one of the standards that migrates. It does not. But JMS, servlets, JNDI, and most everything else is!

And it’s not just that the package names are moving. The latest releases for our most favorite packages will be there, including:

Apache Tomcat 10
Jetty 11
Hibernate ORM 6.1
ActiveMQ Artemis
more!

To keep up with the hottest, most popular Java packages out there, it’s time to pick up and run with Jakarta EE 9.

2 — Native applications on GraalVM

GraalVM is an alternative to the JVM and allows you to run “native” applications. This means faster start up times, more efficient memory usage, and other slick benefits.

To help you pick up and run with it, Spring Native was released as an extra package to ease usage with Spring Boot 2.7.

With Spring Boot 3.0, that support is built in. No Spring Native module required. And the rest of the Spring portfolio is also adopting the needed tweaks and adjustments to make Spring native-ready.

On top of that, the Spring team has been working hand-in-hand with Oracle, the purveyors of GraalVM, to ensure the entire experience is smooth and operational.

If you haven’t explored native applications, Spring Boot 3.0 may be the place to give it a go.

3 — Java 17 LTS

Spring Boot 3.0/Spring Framework 6.0 is moving the baseline of Java support up to the latest LTS (Long Term Support) version 17.

Now Spring has always been cautious to avoid forcing people to jump too soon to a newer version of Java. That’s why, in the past, there has been ample support for features found in newer versions of the JDK, without forcing their adoption.

But with Java 17 having gone GA in September of 2021, support from vendors like Oracle all the way into 2026 (and extended support off to 2029), Java 17 is a safe bet for your next Spring Boot application.

Java 17 also come chock full of some of the coolest features as well. Not only is it much more performant than Java 8, there are lots of cool features including:

Pattern matching for instanceof checks
Records
Sealed classes
Text blocks
Switch expressions
A huge bump in the various Collections operations (including things like List.of, Map.of, Set.of, etc.)
Pattern matching with switch operations (preview feature)

With this fully armed and operational JDK, who can say no?

4 — Project Loom arrives

Project Loom, through JEP-425, brings lightweight Virtual Threads as a new concurrency model to build applications on top of.

We’ve heard lots of rumors, promises, and even some strong back-and-forth. JEP-425 has landed Project Loom as a preview feature in Java 19.

Project Loom isn’t specifically a Spring Boot 3.0 feature. Instead, it’s an easy to grab thing since you’ll already be starting any new Spring Boot 3.0 application using Java 17. It’s as easy as sdk install java <your favorite vendor's v.19 JDK> to install, and simply bump java.versionto 19in your build file!

With that in place, you can easily start exploring. There is a LOT of hunger in the market for:

More efficient usage of existing resources.
Easier ways to scale applications.
Faster throughput on the whole.

We have been looking for silver bullets for years. Sadly, there are none. Nothing “magically” speeds anything up.

But there is no better time than now to evaluate which tactics are right for you. That’s why you should read Spring Data team leader Mark Paluch’s article Embracing Virtual Threads to get the long and short on what Project Loom ACTUALLY does, how it does it, and whether or not it will help your application scale or not.

5 — SpringOne is just around the corner!

Last but not least is the SpringOne conference coming the first week of December in San Francisco. It’s certainly not too late to register at https://springone.io/register.

I’ll be there along with the rest of the Spring team, excited to share with you the glory that is Spring Boot 3.0.

BTW, I’ll be giving my talk It’s 10 PM: Do You Know Where Your Relational Data Store Is?, so if you’re there, don’t miss it!

Even if you DON’T sign up for my talk, if you’re in the vicinity, don’t hesitate to say “Hey!”

If you dig Spring Boot, then please stay tuned for my next article. But if you simply can’t wait, then check out the video below where you can learn EXACTLY what it is about Jakarta EE that makes it so special…and made it controversial in the past!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

The way software will be in the future (or today!)

Thu, 20 Oct 2022 00:00:00 GMT

Software is eating the world. — Marc Andreeessen

You’ve probably heard this phrase, whether you read the original article in the Wall Street Journal back in 2011, or you’ve heard it echoed by CEOs, senior vice presidents, or a senior manager.

But it’s not just that. Not only has EVERY COMPANY had to pivot toward become a software-oriented company. Everyone is having to evolve toward a certain TYPE of software company.

You see there are several key factors which every software company is feeling the pressure to adopt which we’ll cover in this article.

1 — Continuous delivery pipelines

If there’s anything that has evolved over the past 25 years, it’s our ability to move from building our software every three months or twice a year toward a continuous integration/continuous delivery pipeline.

Shops are picking up and running the ability to have every single commit, when pushed to their source code repository, build the whole app.

Whether you’re using Jenkins, GitHub Actions, CircleCI, Concourse, or whatever, people want to know if their latest change broke anything.

Maybe if you’re building an app for a Uni program or some 12-week training program you aren’t doing it. But the shop you join after that PROBABLY is. I’ve mentioned this before.

A handy talent to build up is your ability to construct and manage pipelines.

I happen to be the “guru” for the Spring Data team’s CI operations and manage the pipelines we use for tracking all supported branches of our 17-module system. And if you were to visit Netflix engineering, you’d discover they have an even bigger undertaking as they use Spinnaker to manage the bulk of their online services.

Continuous integration is what lets you know that your latest patch or feature hasn’t broken the main line system.

And this is vital.

Research over the decades has revealed that the faster we can discover a bug and fix it, the lower our development costs will be. So it makes sense to let software…build our software, right?

On top of that, MANY shops are adopting a continuous delivery approach.

Continuous delivery is where go one step further than continuous integration and actually RELEASE your newly minted artifacts. This is usually a snapshot, so the people picking this up aren’t USUALLY the people running the most risk averse systems.

But look at shops like Netflix where they will upgrade their own systems to pick up tweaks and fixes. They even have rolling upgrades so perhaps 10% of the active nodes migrate to the fix, run it for a few hours, see if everything is good, and then let the rest of the nodes upgrade.

That is the extreme and probably NOT what most shops are doing.

But the ability to push out snapshots to maven central or artifactory, publish snapshot containers to Docker Hub automatically, and continuously push updates and bug fixes to tentative customers is slowly but surely becoming the norm and NOT the exception.

Don’t fight it…EMBRACE IT!

However, you can’t do ANY of this if you don’t do the next thing on the list.

2 — Secure pipelines

Secure pipelines are about controlling all the moving parts in your software release cycle and NOT about your continuous integration pipelines.

If your shop does NOT control every point between your source code repository all the way to your distribution location like Docker Hub, then you could be vulnerable to attack.

Maybe you remember the days of Leftpad, a developer that decided to unpublish an 11-line library from npm. A library that apparently was used by LOTS of other small libraries, that ultimately through a chain of tools, was used by some of the biggest JavaScript toolkits out there including ReactJS.

Secure pipelines isn’t just about managing 3rd party dependencies. It begins to cover the issue of what-happens-if-our-release-engineer-gets-run-over-by-a-bus scenario. If losing one person can take down your system, you’re vulnerable.

It also extends into the realm of what-if-your-release-machine-were-compromised scenarios.

The idea is to have controlled machines able to handle your entire release process instead of user-maintained ones. Yes, it’s nice to Do It All Yourself™, but this also makes your personal machine a tasty asset to hackers. Whereas if you can delegate that task to your CI server and entrust security engineering and the sys admins to properly harden and protect your system assets, the risk shrinks.

NOTE: Risk is NEVER 0. There will ALWAYS be risk. But we shouldn’t be foolhardy and take reasonable measures.

If your organization is trying to embrace security pipelines with controlled access to source code, CI servers, and release credentials for Docker Hub, maven central, etc., then don’t fight it. You are swimming upstream.

And I’m not saying to go along for no good reason.

Develop software locally on your work machine. But let properly protected and secured servers handle the infrastructure of it all. In the end, automated tooling will pay off and result in less weekend fires you have to put out. And you’ll sleep better at night.

Because you’ll need that to focus on the next point.

3 — Always ready

Over the past twenty years, the number of around-the-clock always-on systems has grown by leaps and bounds. Having worked on a 24x7x365 Ops center at my previous job, I’m all too familiar with the challenges of keeping things Always On.

But we live in an international market.

Just because you’re asleep doesn’t mean your custom is asleep. Your systems need to be up and operational. And this means more testing, more realistic test scenarios, and more 9’s of availability. (Bonus points if you know what 9’s of availability even are. Let me know in the comments below!)

This is where having continuous integration is awesome.

This is where testing with things like Testcontainers for more realistic scenarios begins to sizzle.

This is where being able to delegate to tools like Spring Boot which pour tons of effort into not just coding new features but responding to bug reports and feature requests to constantly be patching and refining your tools.

(I’ve used other toolkits where the main team mostly focused on new features and much LESS time on patching older stuff. Maybe cuz’ it wasn’t cool?? Who knows?)

The days of planning a release every three months that requires the whole development team come in at 2:00 AM Sunday morning to minimize impact are GONE. (And yes, I did that once, long ago.) The chances of the systems you are helping to build ALWAYS having SOMEONE using them is here and now.

So treat your system with respect and don’t balk at sometimes having to fix critical issues at weird times. Instead, learn how to build better processes that let you patch stuff more effectively. And be ready to embrace the fact that There Will Be Bugs, even in your bug patches!

Which we can do a better job at dealing with in the next section!

4 — Realistic testing

The last facet of software development in this decade is the need for more realistic testing.

Long ago, at the start of my career, it was common fare to manually test software bits. My first assignment was testing other people’s code. I’d fire things up and start clicking buttons. There was even a contracted “manual” that had our official test procedures.

But these test procedures were always out of date. So trying to reduce my OWN efforts…

…built something different. I started writing little functions that would call the production code, print out the results, and put them right next to the expect results. (This was before the days of JUnit, and it was Ada anyway.)

I had basically come up with “automated testing” on my own, and suddenly OTHER devs on the team spotted my cool idea and adopted it for themselves.

Then I had CRON jobs running at midnight to grab the last source code and exercise them, leaving me a report to inspect every morning.

But today ain’t like that. Today, we need the ability to spin up the EXACT same database the Op is using. We need the ability to pre-load the EXACT same data they were running. We need the ability to have the EXACT same collection of 3rd party dependencies the Op was using to replicate a bug.

And we can do that!

By taking start.spring.io and making a “reproducible example”, mixing in a little Testcontainers to replicate the database/message broker/whatever, feeding Spring Boot an initialization script, and leveraging Spring Boot’s test-oriented options, it’s easier than ever to create a more realistic scenario compared to canned data.

Yes, it’s okay to use stubs and mocks for unit-level testing. But Testcontainers and Docker have really opened things up for more accurate testing and our ability to code more scalable solutions.

The future of software is already here, and these tools are here to help us, not hinder us. What is YOUR favorite aspect of modern software development?

If you dig Spring Boot, then please stay tuned for my next article. But if you simply can’t wait, then check out the video below where you can find out whether or not you have the right skills to survive the current recession!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

5 way to go to production with Spring Boot

Thu, 13 Oct 2022 00:00:00 GMT

Spring Boot is pretty cool, what with things like autoconfiguration, property file management, and all. But did you know it’s ALSO really wicked at the different ways it simplifies taking your application to production?

1 — Deploying with Uber JARs

We’ve all created JAR files. In fact, most of the libraries we pick up and use, be it Spring libraries, Apache Commons, whatever, are JAR files.

But Java is really quirky in the sense that its one of those unique platforms where deployment…isn’t baked right in. Instead, you have to reach for something to host it.

That is, if you aren’t using Spring Boot.

Spring Boot brings us something called Uber JARs. It’s a JAR file that includes not just your application code, but also ALL the 3rd party dependencies your app needs to operate.

When you craft your Spring Boot application using start.spring.io, it will come loaded with the Spring Boot Maven Plugin (or Spring Boot Gradle plugin) which empowers your application during the build lifecycle to not only package up a standard JAR file with your code, but will also add those extra dependencies.

Since Java itself has never DIRECTLY supported JARs within JARs, the Spring Boot team has crafted a little glue code to handle this job for your. With all that applied, all it takes to run your app is:

$ java -jar myapp.jar

It’s something that’s always been in Spring Boot, and something that will always be there. And as Oliver Drotbohm once said, all you need on your target machine is a JVM!

2 — Docker containers

Something that has risen up FAST is the usage of Docker. Today, you can find just about anything you want, including Oracle databases, wrapped inside Docker containers.

So it’s natural that people want to bundle up their applications in Docker containers. In the past, this has always been tricky, because there is a certain nuance to “doing it right”.

Assembling a Docker container can involve a lot of wasted cycles if you mix your continuously changing code together with 3rd party dependencies that don’t.

It used to be that to put things together, you had to scour the wastelands of Google to find the right way to bundle your application along with JDK inside a container.

So the Spring Boot team set out to pull together all the right metadata and simplify the process. And now, with that application crafted a la start.spring.io, this is all it takes:

$ ./mvnw spring-boot:build-image

(Or gradlew bootBuildImage)

With this command, Spring Boot will assemble your Uber JAR and then bake a Docker container, ready to be run, pushed to the cloud, or published to Docker Hub.

3 — Native apps on GraalVM

What if startup time is VITAL for your application? Maybe you are running 10,000 copies and all that traditional Java startup time x 10,000 copies = a HUGE cloud bill? Or you are using Amazon’s Serverless Computing platform where spin-up time really NEEDS to be sub-second?

Say no more. GraalVM, the alternative to the JVM, can run Java apps in sub-second time by leveraging something known as AOT of Ahead of Time Compilation.

The Spring team has worked hand-in-hand with the GraalVM team to simplify and ease adoption of native applications. It principally involves folding in the right bits to the Spring portfolio making Spring Boot applications native-ready.

And the Spring team has coordinated with the GraalVM team to make tweaks and adjustments to enhance GraalVM itself.

For Spring Boot 2.x applications, all you need to do is add Spring Native when setting things up on start.spring.io, and all the right “extra settings” will be picked up in your application. As for Spring Boot 3 apps, native is, well, native! There will be no need. Stay tuned!

And if you’re wondering HOW to assemble a fully-loaded native Spring Boot application, you just do this:

$ ./mvnw spring-boot:build-image

Yes, the same command used to assemble a Docker container, when you have Spring Native applied, is used here as well. The difference is that Spring Boot’s build plugin will invoke Paketo Buildpacks to roll your a Docker container that has your code compiled via AOT mixed in with a GraalVM-based container.

4 — Creating Web Archive Files

Web Archive Files or WAR files are something that’s been around a long time. Everyone knows what they are.

And if you need a WAR file, all you must do on start.spring.io is click the tiny “War” radio button on the screen, right next to “Jar”. You’ll be setup just right!

WAR files are classic, work nicely on giant, lumbering application servers. Sluggish, slow to upgrade app servers.

Come to think of it, maybe we SHOULDN’T be assembling WAR files. This is 2022 and people are running thin, light servlet containers and Docker containers. They’re even using GraalVM, not giant app servers!

Forget I ever mentioned WAR files. What was I thinking?

### 5 — Executable JAR files

One key feature we sometimes need are applications that start when the server starts and stop when the server starts. Linux and BSD users will be somewhat familiar with “init 5” and “init 0”-type scripts used by the OS.

It shouldn’t surprise you that Spring Boot has a flag setting that lets you turn your JAR file into an executable that will obey the same runlevel settings.

You can truly make your JAR file executable by applying this tweak:

<project>  
    <build>  
        <plugins>  
            <plugin>  
                <groupId>org.springframework.boot</groupId>  
                <artifactId>spring-boot-maven-plugin</artifactId>  
                <configuration>  
                    <executable>true</executable>  
                </configuration>  
            </plugin>  
        </plugins>  
    </build>  
</project>

(Just check here for the Gradle equivalent!)

A key thing to point out, is that executable JAR files aren’t supported on all cloud platforms. There is a risk that it simply won’t run, so choose wisely.

And that, my friend, is five ways to take your Spring Boot app to production.

If you dig Spring Boot, then please stay tuned for my next article. But if you simply can’t wait, then check out the video below where you can learn three design patterns that DIED a just and deserved death in 2022!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

3 Java Patterns that died in 2022

Thu, 06 Oct 2022 00:00:00 GMT

If there’s something we LOVE when it comes to software development, it’s finding ourselves some fun little shortcuts.

Of course, we don’t call them that. We call them patterns. Patterns are like recipes for baking up software solutions. Solutions we see appear more than once. After all, if we’ve solved a problem, why not re-use the solution? Isn’t that what Object-Oriented Programming (OOP) is all about?

However, some of these patterns we solved for long ago, have turned out to be HORRIBLE and the source of misery. And so we’re going to see some of the most vile patterns that died a deserved death in 2022 starting with…

1 — Static Global Objects a.k.a. Singleton Pattern

This is that beast of a pattern where we use trickery and hacks to ensure that No More Than One of these things could exist. Often, they involved external resources, for which there can be only one!

Now what is bad about these things?

Well, the trickery used to implement them often involved statics and taking advantage of when static initialization happens. HOT TIP: It’s early in an application’s lifecycle when static initialization happens.

Static objects have certain side effects that make them truly detestable including:

Hard to test
Not overrideable
VERY visible

Static, global objects violate some key principles. Being global, it’s hard to override. That’s because EVERYONE could be using it. To override it could break some component YOUR component isn’t even aware of.

And because they are static (again, to ensure their lifecycle is fixed and under control across the lifetime of the application), automated tests have to deal with that.

Because they are so hard to mutate, the inevitably adopt another strategy. It was not uncommon to migrate a single-value static global into a map, to afford multi-valued support. And once you start making it possible for everyone to stuff anything they want into it, the thing basically turns into a magical Bag of Holding!

And at that point, it’s game over.

People USUALLY realize the impact on automated tests. And they see how it’s a road of no return. But to remove it is ugly and painful. It requires breaking EVERYONE. And no one wants to be The One that does that.

So everyone tends to shrug their shoulders and accept the fate.

And it’s one reason why developers like to escape those apps and get onto something newer and fresher…something that isn’t beleaguered by such ugliness.

In truth, the best solution is to use injectable types. An interface or a class. This is one of the slickest features baked into the core of Spring. Simply define the bean type you need. Define its operations. And INJECT it into the services, controllers, and repositories you need.

Need more stuff? Create another bean. Keep those beans somewhat light and focused. Don’t bog them down with too much cross-domain knowledge.

With Spring in your application, there was no longer any need to “trick” the application into FORCING your ONE THING as it is.

And with Spring, you then discovered you could inject test mocks. And with Spring Boot, you suddenly gained access to different flavors based on the environment.

And that’s why in 2022, no one is wanting to use singletons every again. But that’s not the only pattern that died in 2022. Another one that has collapsed is…

2 — Skyscraper Class Hierarchies

What in the world is a Skyscraper Class Hierarchy?? Simply put, it’s a series of classes that is so tall its acquired its own name, just like some of the world’s most famous skyscapers seen in the world.

Long ago, those of us new to Object-Oriented Programming were all too eager to build that perfect hierarchy of classes. (At least, I was!)

And no matter how much thought and design we put into the class hierarchy…it would end up being wrong somehow. And then you’re fighting the battle of figuring out where to put that nuance you didn’t predict into the pattern.

Then a month later, another “tweak” would come, and the process seemed to repeat itself. Class extending class extending class ended up becoming a maxim we’d all repeat: “composition over inheritance”.

The usage of extensive chains of classes simply isn’t an effective way to write code!

Why?

Because there are certain assumptions that would be in place when the class structure was crafted that simply couldn’t be captured in the language itself. The existing concrete classes would know this, because they’d be correct. But a “new” class added later on, or a new usage of the hierarchy would introduce some other aspect that broke whatever that “assumption” is.

This is why it has become MUCH more popular to apply the Open/Closed Principle. The Open/Closed Principle says a software entity should OPEN to extension but CLOSED to modification. My suggestion is to create an interface and implement it with a final class.

You see the interface is “extendable” while the final class will block any modification.

Are you wondering “doesn’t a sealed up class that is subclassed meet that definition?” It could, but it’s important to realize that ANY subclass of another class can result in a form of modification.

And it should be a testimonial that Java’s String class has been final since the early days. The Java team KNEW that locking down such a critical piece of code to prevent subclasses from potentially wrecking things was VITAL.

You may also be objecting from the perspective of having seen little class hierarchies deep inside the Spring portfolio itself. Those small collections of classes tend to be private or package private, and only serve as a “local” implementation. They usually aren’t publicly visible and open to public extension. Only internal usage, where all parties can meet and discuss changes.

Changes that extend beyond your team are harder if not impossible to rein in.

Maybe you STILL think I’m totally wrong on this? Maybe I’ve missed the boat on OOP? Tell me why in the comments below!

But before we wrap things up, let’s talk about the THIRD design pattern that has died a deserved death in 2022…

3 — Design Patterns

Yes, design patterns THEMSELVES have died a due death.

You see, design patterns were meant to capture buts of reusable knowledge. But the exceptions for when they don’t apply are either not capture, not written up, or in the situations where they are…we just overlook them.

There are too many exceptions to the norm to make them as valuable as they were once promised to us.

In fact, there were so many design pattern books, that it spawned the anti-pattern movement!

There’s an old saying…

Rules of thumbs work until they don’t.

Design patterns are the software version of rules of thumbs. Yeah, they’re useful, but often times we get in over our head and overengineer something.

Knowing when NOT to use patterns is usually MORE valuable.

That’s why one of my recommendations is that when you finish up your Uni or your bootstrap program, to find a seasoned veteran of the industry and try to work with them.

While software defies fitting COMPLETELY into the trade paradigm, the idea of apprenticing under a seasoned pro is INCREDIBLY valuable. It will help your career far better than any design pattern book, IMHO.

What patterns do YOU think died a deserved death? Which patterns have you been fed up with? Let me know in the comments.

If you dig Spring Boot, then please stay tuned for my next article. But if you simply can’t wait, then check out the video below where you can learn the ONE NINJA SKILL you need to clobber your next interview!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

5 Ways To Code a Spring MVC Method

Thu, 29 Sep 2022 00:00:00 GMT

Building web apps is the name of the game.

And when it comes to Spring Boot apps, it’s VITAL that you know how to make those controller methods do your bidding!

This article contains some of the KEY WAYS to build web controllers with Spring Boot!

### 1 — Declaring web controllers

The first and probably MOST important thing is to alert Spring MVC when you HAVE a web controller. And we do that using Spring’s @Controller annotation:

This little annotation, when applied to a class, will alert Spring Boot to register this class as a Spring bean. And when Spring MVC sees it, will configure it as a candidate for fielding web requests.

2 — Mapping HTTP calls to your controller method

The next key ingredient in building a web controller is mapping the HTTP verb (GET, PUT, etc.) and the path to your method.

The following controller shows this perfectly:

This controller maps HTTP GET /items calls onto ItemController.items() using Spring MVC’s @GetMapping annotation.

The default value of the annotation is the path. In this case, if someone visit http://localhost:8080/items, the “/items” part of the path is extracted and matched up with this annotation, matching the call to this method!

If you’ve use Spring MVC for awhile, you may remember using @RequestMapping. That annotation still works. @GetMapping is just a shortcut for @RequestMapping(method = RequestMethod.GET).

For standard controllers, the return value is the name of the template to render. Spring Boot will combine it with a standard prefix of “src/main/resources/templates/” and a suffix based on the templating engine you’ve chosen. If you are using Mustache, for example, then it will apply a suffix of “.mustache”.

Spring MVC will then render the template using the autoconfigured templating engine!

3 — Serving different media types

It’s possible to serve different types of data. For example, you may offer your users the option to render their data as either a PDF or as XML.

You can do this:

This shows two different controller methods responding to the same path. But they each have a different produces clause.

If the client submitted an Accepts: application/pdf header, the first method will get picked, and presumably the template will end up rendering a PDF file.

If the client submitted Accepts: application/xml as a request header, the second method will get picked, and that template should focus on serving up XML.

TIP: If you’re going to offer these specific types, you MAY want to consider offering a fallback for clients that don’t specify an Accept header, or ONLY offer this link from ANOTHER page of your own design where the Accept header is baked in.

4 — Consuming JSON data

So far, we’ve talked about serving up content. But web apps must also consume data, like JSON inputs.

Spring Boot will automatically include Jackson for any Spring MVC app, allowing you to ingest JSON data automatically. All you need is the following code:

@PostMapping is the way to flag your Spring MVC method to consume data instead of simply produce it.

And to get your hands on the incoming data, include an argument for the entire type. In this case, we are using a Java 17 record (not shown) for the Item. Spring MVC’s signal to deserialize incoming JSON data is using the @RequestBody annotation on the argument.

5— Consuming an HTML form

The previous section showed how to consume raw data like for an API call. But to receive a form from an HTML web page, we need something different.

This uses the same @PostMapping annotation. But the input argument is instead marked up with Spring MVC’s @ModelAttribute annotation. This is designed to handle forms bounds to Java objects.

This method also shows that after processing the new Item, it will then issue a redirect back to the home page using “redirect:/”.

With these tactics in place, you can easily start crafting your own web controllers using Spring Boot!

If you dig Spring Boot, then please stay tuned for my next article. However, if you simply can’t wait, then check out the following video where we dig EVEN DEEPER into various Spring MVC annotations and tactics!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

How to be prepared for ANY coding interview!

Thu, 22 Sep 2022 00:00:00 GMT

Someone recently shared their struggle with finding a new position as a fresh grad just out of Uni:

[F]or 1 year I focused on HTML, css, and JS from the bottom up. Then jumped into React…I learned React because it was most of what the market was looking for. But now it seems it has become angular + Java once again…the interviewer didn’t ask me anything on Spring or Java, and focused exclusively on Angular, despite React and other technologies being listed as requirements.

I frankly don’t get the issue with companies honing in on whether someone knew React or Angular specifically.

As for why they didn’t ask a question about Spring, well, interviewers can tend to carry certain biases. (But not the biases you may be thinking.)

As someone that has interviewed MANY new hires in the past, most straight out of college, I can tell you that if someone walked into my office with stack of experience in EITHER ONE…I’d entertain hiring them on the spot!

If there’s ONE THING I’ve learned in my 25-year career as a software engineer, it’s that toolkits, tactics, and patterns evolve. They change. Whatever you used last year may go by the wayside next year.

1 — A joke that reveals a truth

It’s a joke to pick a random noun and then google “ javascript”, and see if there is, in fact, a JavaScript toolkit by the name.

Want to have some fun? I’m at a coffee shop writing this article, and I spotted some scones for sale. Let’s google “scone javascript”. First entry?

Heh…and it’s a React library. Somehow fitting for our article, ehh?

The core point is that toolkits change. A candidate’s ability to effect change through code is WHAT WE’RE LOOKING FOR. So whether your history was building rich web apps with Angular OR building rich web apps with React…

…it’s the “building rich web apps” that hiring managers really want.

What does this mean for you?

Simply put, don’t worry. I know interviews can make you sweat. After all, we’re talking about the process to secure a position that pays the bills. Who WOULDN’T want to hit things off with a bang.

2 — What are they really looking in an interview?

Something you need to be aware of, is that you can interview for a position, not be perfectly aligned with what the interviewer’s question, and still succeed.

That person you are about to face off with (feels that way, right?) may have entered the meeting room with half a dozen question about your skills of using Angular. And you may have had ZERO runtime on Angular.

But you can still succeed.

How is this even possible?

Let me show you. Let’s pull back the curtain a little and reveal what’s REALLY happening so YOU can be better prepared for your next interview.

Anytime I get ready for an interview, I am generally looking for the following traits:

Has some experience with some coding toolkit. That’s because experience will have grown that person’s ability to code patterns and concepts that tend to TRANSCEND the toolkit itself.
I know that toolkits never have 100% of what we need, and so need some amount of creativity working around such limitations. Someone that has USED a toolkit for some amount of time will have learned this concept and be a great asset.
A candidate that has worked for some amount of time on a team, be it a professional team or perhaps a senior design project team will have learned the basics of team interactions. The more experience a person has working through communications, tradeoffs, and building a product WITH OTHERS will be able to work with OUR TEAM.

This is why experience is valuable. Not for the sake of it, but because you will have learned some of these universal concepts. We’re talking about more than if-then clauses, boolean logic, loops, and inheritance.

No, we’re talking about dealing with toolkit limitations, developer tool limitations, communication limitations, PEOPLE limitations.

Nothing is perfect. And your ability to weather development storms and still produce value for a customer IS WHAT I’M LOOKING FOR.

I just may HAPPEN to be using Angular as my vehicle to probe your experience. Partly because it’s what my team is using. Partly because it’s what I know the best (at least, right now).

3 — How you can know ZERO about some toolkit…and still get an offer!

Want to know how I managed to get on the Spring team back in 2010, despite having ZERO experience with writing servlets, deploying to Java app servers, and having never deployed a Spring bean to save my life?

I talked about how I had led a team of seven engineers in building and deploying a 24x7x365 application to your Ops center.
I mentioned provided on-call support for several years and coming in to resolve crises (once, I came in 3x in the same night!)
I shared how I had led the way in using management’s chosen platform to provide around-the-clock uptime to our client.
I pointed out some of my tactics to build CRON jobs that would monitor the system every 10 minutes and restore nodes that had gone down due to apparent memory leaks.
I wrapped up by pointing out my future plans to migrate this whole system to a Spring-based solution once management approved my proposal and gave me the green light.

How could it be that someone from the Spring team saw all this and yet extended me an offer?

To prepare for your next interview, try this: sit down and start listing what all you’ve accomplished. Try to go beyond credentials and certifications and instead think about the biggest PROBLEMS you solved. Even if it’s a project you did for a class.

Beside each project, try to list the value you provided to OTHERS.

The NEXT time you go into an interview, think about the top 3 things on your list and think about how to answer someone’s question that way, okay?

Interviewer: Have you ever used Angular to build a production-grade application?

You: No, but I actually used React to put together a system with two other teammates that is now serving about 10,000 hits every day. We deployed it on AWS thanks to some scripts I crafted.

Sometimes, interviewers are looking for very specific skills. Perhaps they need someone already ramped up on Angular. It’s possible in this scenario that they could pass on you.

But it’s MORE LIKELY they are looking for someone to join the team and to help shoulder the workload. They REALLY need someone that capable of learning and growing, and who will make things happen no matter what the challenges.

The toolkit at hand is often simply a vehicle to get to a deeper understanding of what you can do.

So either lean into that toolkit because you DO know it…or pivot toward another one and show your skill at SOLVING PROBLEMS.

Because someone with those types of real world skills will be irresistible!

If you dig Spring Boot, then please stay tuned for my next article. But if you simply can’t wait, then check out the video below where I show you how to prepare for your next interview!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

6 Ways to Become a SPRING Coder

Thu, 15 Sep 2022 00:00:00 GMT

So you’ve heard that Spring is the way? In your eagerness to dive into the workforce as a full fledge coder, you want to get crackin’.

And then it hits you…how do you get started?

1 — Start from the source

Several years ago, the Spring team released a slew lunchtime-sized guides. They’re free and updated to the latest stable version of Spring Boot.

Head over to https://spring.io/guides
Pick one and go through it. They are designed to NOT require completing OTHER tutorials or guides.
The next day, do another.
Rinse, repeat.

The guides aren’t specific to any Spring project. Instead, they each focus on solving a problem. There are about 60, so in the span of a 2–3 months, your knowledge of Spring can be widened considerably!

2 — Start reading This Week in Spring

If you want to catch the latest, then visit https://spring.io/blog. Not only is chock full of official news, but there’s a weekly post from Josh Long a.k.a. starbuxman dubbed This Week in Spring.

Josh has been writing this column since he joined the Spring (right after me), and he hasn’t stopped.

In his weekly roundup, he has some of the hottest news not just from the Spring team, but the Spring community at large.

And in case you didn’t catch it, the Spring community is HUGE. Which leads to the next way to ramp up your skills as a Spring coder…

3 — Tune in to the latest from the Spring community

There are multiple sources where you can catch interviews, news, and other Spring stuff.

A Bootiful Podcast (Josh Long)
The Spring Boot Learning Podcast (me!)
Java Pub House (Freddy Guime)

UPDATE: I have since pivoted my podcast to the Pro Coder Show and am no longer Spring-specific.

Podcasts are fun and exciting. They have a certain amount of tech knowledge mixed in with entertaining banter.

And all these podcasts are fun. Check ’em out!

4 — Grab a book!

Podcasts and news articles are great, but sometimes you need the information chained together with coding examples. And that’s where books really shine.

To get some of the latest check out:

Spring Boot: Up & Running (Mark Heckler)
Spring in Action (Craig Walls)
Pre-order Learning Spring Boot 3.0 3rd Edition (again, me)

(What person doesn’t mention their own book, right?)

Everyone consumes information in different ways. Whether that’s

5 — Check out some videos

There are multiple YouTube channels where you start learning Spring coding in video format.

Dan Vega (Spring Developer Advocate)
Josh Long (Spring Developer Advocate)
Spring Boot Learning (me!)

All these videos are 100% free. Check ’em out to see who if they suit your needs.

6 — Carve out some space to start CODING!

This may sound a bit weird, but if you want to be a pro coder in the land of Spring, then find a place in your home or apartment. Clean it out and make space.

Don’t just sit around at the dining table or in your living room chair.

No, find a REAL place to dedicate to writing code. It could be as simple as a small IKEA desk in the corner of a room…or a standing desk if you want. Making a dedicated space is the first step of commitment to start growing your skills.

Then…start coding. Use the guides, the books and the videos mentioned above. Whatever it takes.

Because one thing this all requires…is YOU!

YOU must commit to digging in and learning.

If you dig Spring Boot, then please stay tuned for my next article. However, if you simply can’t wait, then check out this video where I talk frankly and openly about what YOU need to be doing as a PRO CODER to raise your value in the midst of a RECESSION.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Thanks!

Thu, 15 Sep 2022 00:00:00 GMT

Thanks!

BTW, I fixed that link so you should now be able to access all the guides.

5 Tips to Protect Yourself from the RECESSION!

Thu, 08 Sep 2022 00:00:00 GMT

With a looming recession, are you doing everything you can to solidly your position within your team?

Maybe you’re put off by that question, but in truth, this is one of your stronger moves you could possibly make. Simply out, economic slowdowns can be temporary, but as Graham Stephan once said, “Upskilling makes you well positioned for sunny days.”

1 — Find out what skills you are lacking

For get started, do this:

Take some time one evening and scribble down on paper or your tablet the skills you have.
In another column list the skills they would be useful to pick up.
The following night, pick one item on your new “wish” list and go find a video or tuturial and DO IT!
The night after that, do another. Work your way down the list.

In a month’s time, you’ll have grown your skill set in a favorable direction.

For even more tips on upskilling that fit your current organization (or the one your shooting for), check out this video:

2 — Work on your code QUALITY

Learning new toolkits that support your current skills is one thing.

But there’s another skill NOT covered in any Uni class or bootstrap program. It’s called “code polishing”. While this skill doesn’t provide new functions or operational code, this practice can improve your efficiency.

One of the biggies in code development is our need to go back and read code we’ve written before. And if you’re code is an incoherent mess, then it becomes much HARDER to do so.

Adopt some of the practices found in the video below, and you can make yourself INCREDIBLY VALUES to ANY team!

3 — Look ma! No hand-run tests!

Something else that may get glossed over, if covered at all, is automated testing.

Indeed, more and more shops are adopting this, but the odds that this was covered in your university or boot strap program is slim. And if covered, may have been only mentioned briefly.

However, it’s one of those skills that will pay you back for years to come. So, why not give yourself an edge by deepening your skills there as well.

Considering how how widely automated has been adopted, I made an entire playlist devoted to it.

Pull up the playlist below.
Go to the one you know the LEAST about and WATCH it!
On another night (or during a lunch break), watch the NEXT one.

Once you finish this playlist, you’ll be a LOT more confident to run with automated testing OR EVEN INTRODUCE IT to your team!

NOTE: A developer that can SHOW a passing test suite is worth a FORTUNE to any manager!

4 — Making your ninja move

Buried deep in this article we now come to a slick, cool move you SHOULD be making.

Shhh! Don’t tell anyone. This is just between you and me, okay?

Now this may sound strange but one the FASTEST places to gain traction with your team is learning to query the database for data.

Why? It seems just about anyone can write a web controller and everyone and their cousin seems to have had a hand dabbling with JavaScript…

…but not EVERYONE groks databases and querying them for real data to populate those web forms.

Everyone around you, whether you’re surrounded by new hires or you’re vying for a position, can probably write a slick web control with some JS toolkit. That’s why YOU must pull the ninja move of being better at database queries!

If you need to get started, check out this deep dive live stream where we do some real database action:

5 — Acing the interview

All these skills are for naught if you don’t land that position, amirite?

That’s why you need to KNOW what hiring managers are LOOKING for! (And in recessionary times, even if you’re on a team, there is increased risk of being let go).

I’ve been involved in many hiring decisions. Trust me, you don’t want to get caught flat footed. Even if you’re on a team, you can learn what notes to start keeping so that you’re ready for your NEXT interview (which not happen when YOU want it!)

So watch this and see what TO do and what NOT to do!

I’ll wrap this article up with a warning.

Maybe you sensed it because I made no reference to security and locking down apps.

Security is a beast. For some it’s a passion. For others, it’s a completely different batch of studies and courses.

Unless you’re going to devote the time it takes to master security, you’re better off spending your present time on the other stuff mentioned in this thread. Yes, it’s beneficial for ALL software developers to grok security, but this article is about tactics to “upskill” yourself, quickly.

Security is a MAJOR time sink and something that would require SACRIFICING the other things mentioned.

So my super secret advice is to let one of your competitors be the person that excels at security while you succeed at the things listed above.

If you dig Spring Boot, then please stay tuned for my next article. Normally I like to include a link to a relevant video at the bottom, but if you visit even ONE of the videos above, your skills will improve.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Why Reactive Streams are the SECRET to CUTTING your monthly cloud bill!

Thu, 01 Sep 2022 00:00:00 GMT

In the world of software development, we are FOREVER battling two competing forces: bigger demands vs. more powerful machines.

Now this may SOUND like NOT an actual competition. In fact, it may sound like perfect alignment, because wouldn’t the more powerful machines meet the bigger demands?

Amazingly…no.

Because what REALLY happens is a little like this:

Demands for more users and more data come in.
We get bigger/more servers.
We catch up to the demands of step (1).
In the time span of steps (2) and (3), the demand increases another 25%, which simply repeats this vicious loop.

In fact, this is a KEY reason cloud computing took off like crazy. In previous decades, the very thought of growing your own data center was expensive, time consuming, and laborious. There was legit pushback when someone would say “we need more servers!”

But call up your favorite cloud vendor to say “we need 25% more than last month”, and instead of dread you’ll hear excitement!

Of course your cloud bill is going up 25% as well. But the capacity you need is readily available!

That’s great…if 25% more server power yields 25% or more sales. But what if it doesn’t? What if your cost-to-profit ratio isn’t like that? A growing monthly cloud bill doesn’t always translate to enough profit. And thus, you need to start looking for ways to CUT COSTS.

What if I told you…that you’re already wasting precious time. (And in the cloud, time is literally money.)

You have idle threads sitting around, waiting for a response. And when you scale to any appreciable size, the idle cost will kill you.

10,000 server processes, each with 100 threads sporting some appreciable amount of lingering idle time…well let’s just say it doesn’t have to BE that way!

Reactive Streams beats this crazy problem of over-consuming an underutilized resource by introducing: non-blocking.

The idea is simple: instead of holding up a thread waiting for a response, instead let that thread go do some other work. There is a little machinery to orchestrate this, but that is frameworks are good at, right?

While a thread awaits a response to a remote web call, process the database call?
While a thread awaits the database server to hand back some data, why not chew through that payload that just came back from the remote service?
While a thread awaits another thread awaiting ANOTHER thread making a remote call…why not let ALL of those idle threads DO SOMETHING ELSE?

This is what Reactive Streams does. It decouples work from the thread.

Reactive Streams is a VERY simple spec (just four interfaces) that, in fact, is so simple, it’s not recommended for direct application usage. Instead, the suggestion is to build libraries on top of it that others can use.

But as long as these libraries are compliant with these contracts, these libraries can integrate with each other.

Project Reactor is VMware/Spring’s implementation of Reactive Streams.
RxJava is Netflix’s implementation.
Vert.x 3.0, MongoDB, Ratpack, Akka Streams, and several other toolkits and framework also support Reactive Streams.

So what exactly does Reactive Streams DO that is so slick and cool?

Simple: Reactive Streams replaces the old paradigm of PUSHING things onto downstream consumers and INSTEAD waits for the downstream consumer to PULL. These requests can be “send me 1” or “send me 10” or “send me ALL you’ve got”.

The response, though, doesn’t have to come right away. Nor does it have to come on the same thread. Imagine there is a queue somewhere managing the work request. And the size of the queue is constantly dictated by the downstream puller.

This ability to push a flow limit upstream is known as “back pressure” and when using Reactive Streams, allows such signals to get pushed from the last consumer all the way to the first producer.

There is even a network protocol (RSocket) that mirrors this contract!

And it’s this ability to control flow across the whole system, that when properly adopted by ALL components in the system, allows a MUCH more efficient flow of data!

Nevertheless, despite all the challenges of adopting functional programming, despite the “new fangled way” this all appears, Reactive Streams DOES make it possible to better squeeze more usage out of current CPU cycles and even SHRINK the number of servers you are renting from AWS, thus lowering your cloud bill.

And while Reactive Streams may not, on a per-operation basis, be faster than conventional systems, the net gain in more efficient usage can result in your application having a substantially better throughput.

And lowering your cloud bill by significant factors by wringing out better usage of your AWS nodes, your application may leap forward in efficiency. Don’t dismiss this it because the paradigm is different.

If you dig Spring Boot, then please stay tuned for my next article. However, if you simply can’t wait, then check out this video where I go into the details of what reactive programming with Project Reactor is like!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

What no university will teach…but is VITAL to your career!

Thu, 25 Aug 2022 00:00:00 GMT

If you’re either wrapping up your college program or 12-week bootcamp (or just did), then you’re probably all fired up and stoked to GET OUT there! Yeah?

Ready to carve out your own piece of this thing we call Software Development.

Would it SURPRISE you to know that one of THE MOST IMPORTANT things you could learn to enhance your career was totally skipped over? One of those VITAL skills any pro coder needs is simply nowhere to be found in any 4-year collegiate program nor any 12-week bootcamp?

What is this magical skill we all need but isn’t being covered?

The answer: Continuous Integration

Continuous Integration (CI) is when you let a server build your software after every commit.

If it succeeds, it shows GREEN
If it fails it shows RED.
Some CI servers will email you. Others may send you an IM. But the point is that you let this CI server run every single change anyone makes.

Why is this so valuable?

And more importantly, why didn’t anyone TELL YOU about it during your studies?

The reason CI is so valuable is that we need feedback, CONSTANT feedback on whether or not our changes have broken anything. Even if we made a seemingly tiny change, having a CI server run our tiny change and detect breakage will help by STOPPING us and suggesting we back up and see what went wrong.

But that is not all.

CI servers don’t just build our software. They can do much more. If our code is consumed downstream, then publishing a snapshot to a repository will make it much easier for others to eat up our changes.

And…it makes it easier to BREAK them.

You heard me. Breaking downstream consumers of our module is GOOD because it exposes our lingering PROBLEMS sooner rather than later.

The Spring team is BIG on backward compatibility. If Spring Data JPA were to drop a publicly-visible method that Spring Boot takes advantage of, the sooner we can push that into their team, the better. They’ll either accept this change, or they’ll ring us up, asking “What happened?!?”

Okay, the Spring Boot team won’t REALLY react that way. But they would certainly inquire as to WHY we dropped a publicly visible API in the middle of a point release.

CI is good at catching stuff sooner rather than later. And there is a hint of possibility that your formal education in software development MAY have mentioned, the sooner bugs are caught, the less they cost to fix.

Which brings us back to WHY you’ll find NONE of this in your training!

Because they don’t CARE.

Or to be more precise…they care about a lot of stuff including: algorithms, language constructs, variables & functions, logical tactics, and development tools.

Maybe they DO care about other things like version control, CI, and operations, but not ENOUGH to bump any of these other topics. Relative to programming concepts and coding practices, no instructor views code hygiene as something they can fit into an already busy schedule.

And so it becomes something YOU must embrace and learn about. Something YOU must decide will help you stop FIGHTING MIDNIGHT FIRES. Something YOU must choose to pick up and learn to do.

Because in my 25-year career as a software engineering veteran whose first assignment was testing OTHER people’s code (and hence built an automated CI tool before CI had entered today’s lexicon), nothing has helped me MORE than knowing SOONER rather than LATER that a particular code change broke something.

And the sooner I knew it, the sooner I could fix it.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

If at first you don’t succeed…try, try, try, try, try, try again!

Thu, 18 Aug 2022 00:00:00 GMT

The land of software development has some dark corners.

We’re talking about the things we must all do from time to time to be a PRO CODER. It may be fun and glorious to build that Hello World app with our latest 5-minute tutorial leveraging some cool toolkit. But to think THIS will be the thesis of your day-to-day job as a professional is false.

I don’t know if you went to college or a 12-week bootcamp. I don’t know if you’re just reading this and THINKING about side hustling your way into the world of software development. (Kudos if you are!)

But I don’t want there to be ANY confusion that on some days, many days in fact, you have to simply, calmly, peacefully…

BRUTE FORCE your way through a PROBLEM!

On certain days/weeks, you must:

Try something.
See if it worked.
If not, circle to step 1.
Rinse and repeat.

And you must DO THIS 100x today. 100x tomorrow. 100x every day this week.

100x100x100 times…until something moves the way you want it to move.

This is what has SO MANY people stoked for automated testing. This is why JUnit and Spock testing toolkit and Groovy testing and Testcontainers and so many other wickedly awesome testing toolkits draw such huge fanbases.

The easier it is to capture a scenario or behavior in a repeatable piece of code that exercises your code, the easier it is to break out of that crazy loop I just listed up above.

Because as grand and glorious as Software Development is, and as much as we celebrate it as a discipline of ENGINEERING, many times (too many times?), not everything is solved with pen & paper.

Some problems are simply solved by trial and error.

Trial and error.

Random onlooker: “Yeah? So what! Lots of jobs require trial and error.”

Indeed, Grasshopper, this is true. But to be a successful developer on your team, there are some days where no one has the answer for YOU. There will be some days where Stackoverflow.com won’t have the answer for YOU. There will be some days where the ONLY answer, the only way forward to solving the caper your team is in the middle of…

…is you. Doing trial and error.

You can say, “Oh well. Couldn’t fix that! I’ll just let someone else deal with it.”

Good look getting tapped for something else. Good luck being handed the position of lead for a module.

Because if you can’t embrace our beloved try-something-until-it-works for three weeks, you don’t have what it takes to lead anything.

It’s true, we have ways to bounce ideas off each other. It’s true, you can reach out for help within your team or to online forums. But at the end of the day, there are times where it’s all you. And your ability to NEVER GIVE UP is what will make the difference.

And the sooner you appreciate this and accept this. The sooner you have that attitude of not simply pushing the code along but instead making it bend to YOUR WILL…

…well…the sooner you will be ready to apply This Same Tactic to a system where you don’t get the answer of your latest TRY in 2.3 seconds, but instead in 13 minutes.

I’ve been working on an adjustment to making our CI system do the bulk of the release process for all 17 officially released modules of Spring Data, and I can tell you…it’s been grueling.

It takes 20 minutes for Jenkins to run ALL the steps needed for a release.

And when the LAST step is the one that keeps failing…and when the last step can’t be run without all the preceding steps…

Well, let’s just say I have devoted additional time over the past three weeks watching LOTS of build jobs fly by. Yes, I pushed things as FAR AS POSSIBLE on a local level.

But at a certain point, you must test on the CI server itself.

Yes, I am leveraging Docker containers to ensure my machine and the CI server BOTH HAVE THE SAME ENVIRONMENT.

And yes, a MacBook Pro M1 Pro laptop and a Linux-based Jenkins server have differences I never expected, even in Docker.

But I learned long ago in the formation of my career, that Jenkins ain’t messing with some newbie. Nope.

Jenkins, as of midnight last night, began to crumble before me.

Jenkins, as of midnight last night, began to realize that no matter WHAT it threw my way, my Google Fu was unstoppable and would not yield.

Jenkins, as of midnight last night, began to regret picking this fight with me.

Jenkins, as of midnight last night, began to understand that defying me three weeks ago was a mistake.

Yes, this is emotional. Software development is. Always has been. The sooner you accept this, the sooner you can grow your OWN skills and conquer the systems put before you.

If you dig Spring Boot, then please stay tuned for my next article. However, if you simply can’t wait, then check out this video where I share a recent situation that threw ME for a loop…and how I dug my way out.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

5 tools every Spring developer should have

Thu, 11 Aug 2022 00:00:00 GMT

When it comes to building apps with Spring Boot, there are a handful of tools I turn to every day. Some are free. Some are not.

But ALL of them pay me back in time and value.

So let’s check it out!

1 — Sublime Text

Sublime Text is a KILLER text editor. To call it a text editor is an understatement. This thing has contextual awareness of just about any file type I’ve run into. Java, shell scripts, Python, XML. You name it.

It also can smell variable names and offer bits of completion not available in other text editors. In fact, some people use Sublime Text as their IDE.

Sublime Text has a free trial version. The trial period has no defined date, so you can use it free forever. If you like and enjoy it, I encourage you to purchase a license and help support it.

“Text editor” doesn’t really capture the power that is Sublime Text

2 — IntelliJ IDEA

Once, long ago, I was a hardy Eclipse user. Eclipse was pretty nifty. Much edgier and more functional than the commercial one we were provided (at at previous job).

But then I took IntelliJ for a test drive. I was blown away.

It had this “awareness”. As if, when I would try to do something…it KNEW what I was doing and offered me a shortcut. It was clearly looking at the type of file I would be editing (Java), seeing the non-existent variable I had just made a reference to, and when I went to the top of the class and started to define it, would offer me the SAME NAME of variable.

This type of situational awareness is hard to beat.

That’s not all. It’s loaded amazing code completion tricks, refactoring tools, and if you’re looking for files and classes, amazing ways to do partial matches and FIND what you’re looking for. Fast. With minimal keystrokes.

Code completion is AWESOME!

3 — AirPods Pro

This may sound weird, but wireless earbuds is a game changer. When I grabbed a pair of Apple AirPod Pros on Amazon Prime Day (with an $80 cut in price), I discovered how it became much easier to take my work environment with me.

I work remotely, and with three kids home for the summer, this sometimes involves working at the dining table, in the living room, and other places as well.

I also sometimes work in a coffee shop. While I’ve had wired earbuds for years, I never hardly used them. Too. Dang. Hard.

But with wireless, it became much easier to pull them out, fire up my favorite coding playlist, and focus.

They are REAL useful for team Zoom chats. And I even discovered that they sizzle during YouTube videos and live streams! Now I can have all the music and guest audio piped into my ears. Getting up to adjust a light or move the microphone is a snap.

Me, with my AirPod Pros!

4 — The “Stay” App

When I started working from home, and had bought a 39” 4K TV set as my main monitor, I ran into a really ANNOYING issue.

Anytime I hooked up my MacBook Pro, the windows would go all wonky. I would spend five minutes moving them around.

Later I’d unhook, and everything would be wrecked. I’d fix the window arrangement. But then the next, when I’d reconnect to that giant TV…again I’d be battling window layouts.

While five minutes isn’t a LOT, it’s DANG annoying!

So I spent a couple hours hunting down the Stay app. An app that would remember for ALL monitor configurations and let me record the location of every window.

For a tiny one-time fee of $15, I can now change environments with ease. When I hook up to my giant TV, all the windows jump to their proper position. When I unhook, they switch to my laptop-only mode. If I connect to a new environment like an overhead in a conference room, I can shuffle the windows around, hit a hotkey, and record THAT setup.

This tiny app makes it really easy to float around and not be sweating the small stuff.

5 — Docker Desktop

In this day and age, with the emergence of Testcontainers and other Docker-based things, it’s practically a requirement to have Docker Desktop, the current tool that lets you run Docker containers locally.

It used to be a bugbear if you weren’t on a Linux machine. But now, they sneak in a tiny virtual machine inside the product and handle all the ceremony of making it available.

And you really need to know some barebones knowledge about Docker. It turns out that running real instances of Postgres, RabbitMQ, MongoDB, and other things is quite handy when needed.

It’s free for small stuff, but if part of bigger shop, then that’s different.

If you dig Spring Boot, then please stay tuned for my next article. However, if you simply can’t wait, then check out this video where I dig in deeper about the tools you need, including IDEs, if you really want to become a pro coder!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

JDBC vs. JPA

Wed, 03 Aug 2022 00:00:00 GMT

In the land of software development, we sure love acronyms. Our acronyms in the land of Java-apps-talking-to-database, there is no shortage there.

And maybe this leads to confusion: What do I use? Everyone else is using JPA? Should I? But I heard about Spring Data JDBC? And what about Spring Data JPA?

In this article, we’ll talk about JDBC, JPA, where they came from, and the tradeoffs that exist.

Once, long ago, there was JDBC

JDBC is the Java Database Connectivity API. This is an old standard, going all the way back to the days of Java 1.1 in 1997. And this API has served us well.

It’s “old data”. Get it?Everything, and I mean EVERYTHING that talks to databases goes through JDBC. And that has its pros and cons. Basically, JDBC is the Java implementation of the standard dance ALL technologies have played to interact with databases.

Open connection.
Open cursor.
Submit query.
Iterate over result set.
Close result set/cursor.
Close connection.

And we’ve all probably suffered the fate of implementing twenty queries, and forgetting to CLOSE one of those resources along the way. And then, six weeks later, getting a scary stack trace because somehow our database has run out of connections or cursors.

We track down the issue. Patch it. Release it.

And then eight weeks later, we find another. This is what happens when we are on the hook for managing something that shouldn’t be that hard to manage.

And Spring saw this and took note. With one of its most popular and powerful coding patterns, Spring Framework release JdbcTemplate. A template that basically lets you focus on submitting queries and consuming the results.

All resource management was handled by the toolkit. Never again will you get a call at 3:00 AM because the database/your app has blown up.

Okay, maybe you still get those middle of the night calls. But not because you didn’t close a connection!

The thing is, once you’ve written two hundred queries, that amount of raw power capture in those strings becomes kind of overwhelming.

In fact, along the way, after your thirteenth query against that same Item object, you wondered, “why can’t Java SEE the type…and just do it for me?”

Welcome to Hibernate, the forerunner of JPA.

Hello, Hibernate

Two things we’ve battled with other the years includes mapping table rows to Java objects as well as variations between relational database implementations.

Do I REALLY need to rewrite my Oracle query when moved to Postgres??

Sometimes, yes. Because the ANSI SQL spec doesn’t cover all the gaps. So database providers fill gaps.

Hibernate promised the means to connect Java objects together in a unified way…if we just properly map those tables onto their related Java classes. It started with XML, but took off with Java 5 annotations!

And the world leaped forward at warp speed!

And while having a neutral way to talk to any database engine on the planet using the SAME query was really cool, there was something else we didn’t REALLY understand.

Okay, some people saw it coming, but most of us did not.

You never REALLY escape the concepts of relational table mapping. That’s right. Just because you picked up Hibernate and started using it didn’t mean you could actually STOP thinking in terms of relational databases.

For the simplest queries, yes you can.

select i from Item i where i.description like ‘%:partialDescription%’

That kind of query is straight forward. It makes sense. And it’s universal.

This was the kind of stuff that once you got things up and running, Hibernate really had you humming. In fact, it was so popular, people sometimes referred to Spring + Hibernate and peanut butter with chocolate.

And so they standardized it.

Hibernate, thy name is JPA

JPA is the Java Persistence API (acronym within an acronym FTW!) Hibernate became the reference implementation for it. Most shops using JPA today are in fact using Hibernate.

JPA was so profound that one could say JPA gives you wings!

But inevitably, we discover that there is a deep, dark secret to JPA. Something that either someone TOLD US, or something we assumed on our own.

You never, ever get away from the concept of a relational database tables. As you write more complex, more entangled, more business-oriented queries, you discover that sometimes your Java objects don’t FIT that paradigm.

You discover that you are simply exchanging your knowledge of SQL for your knowledge of JPA.

It’s possible. In fact, it’s quite powerful. And sometimes, that power needs a little assistance, hence the creation of Spring Data JPA.

Spring Data JPA can help you with simpler queries, and dodge the need to work TOO MUCH with JPA’s EntityManager.

But eventually, you have to get your hands into manually-written JPQL queries.

And if you believe you can write a highly detailed, complex, and finely tuned JPQL query and then SOMEHOW customize the SQL output, you are in for a rude awakening.

You see, it was common paradigm in the olden days to write several dozen queries for your system. Then, through the magic of DBA feedback and daily experience, to spot what queries were the most inefficient and taking too long. And by leveraging EXPLAIN PLANs, you could see HOW your query was wasting time.

You’d then attack things by:

Create better indexes.
Ensure statistics are running properly.
Rewrite certain joins.
STOP using UPPER (or LOWER) on everything to avoid full table scans.
Don’t join the same table ten times! (Yes, I once found a view that did that.)

And a dozen other tactics. You would tune your queries and something that may have taken twenty minutes could be optimized into a sub-second query. This was par for the course in database/application maintenance.

Let’s just say, you ain’t doing that with the output of JPA.

And this is what some have come to dub the 9th Circle of JPA.

Maybe this is your jam? Maybe this is cool for you? But for many, it can be a bad taste in their mouth.

And so can you imagine the enthusiasm when Spring Data JDBC emerged back in 2017? In fact, my teammate Jens’ talk at the 2018 SpringOne conference resulted in a room PACKED with people, eager to hear the news.

Spring Data JDBC offers a way to pull back from the edge of the JPA abyss. It’s pretty cool. Check it out if you want to understand more.

Spring Data JBDC attempts to do a lot of the work for you. But it doesn’t do EVERYTHING that good ole Hibernate would do. It presumes that if you were to handle a little bit yourself, you can retain some of the vim and vigor pure JDBC allowed. This where you now get the ability to see and understand your queries.

This is where you get the ability to tune SQL statements more to your liking. Face it, there must ALWAYS be some amount of tuning to make things hum.

And in exchange for handling a little more on your end, you can avoid getting pulled in potentially to the La Brea tarpit of ORMs!

No matter what you pick (JdbcTemplate, Spring Data JPA, Spring Data JDBC), hopefully by understanding more about their underlying standards that support them, you can make a solid choice about what best meets your needs.

If you dig Spring Boot, then please stay tuned for my next article. However, if you simply can’t wait, then check out this video, where we discuss entities vs. DTOs and what it all means!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

5 ways to find data with Spring Data

Thu, 28 Jul 2022 00:00:00 GMT

Spring Data provides all kinds of ways to interact with your data store. But do you know them ALL? Odds are, you haven’t seen them all.

And you may be suffering from wasting your time on some queries because of it.

In this article, find out ALL the ways you can access your data, and see which one is for YOU!

1 —Custom finders

The simplest and most eye-catching solution (to me) is your ability to write a custom query WITHOUT WRITING any, well, query, is this:

public interface ItemRepository extends CrudRepository<Item, Long> {  
    List<Item> findBySku(String sku);  
}

In a system where you have defined your Item type, and it has a field tracking its SKU value, you can do that by writing what’s above.

This tactic to craft a custom finder is known as query derivation. Spring Data simply parses the name of the method, sees the “findBy” prefix and also the names of the fields inside Item, and is able to craft a query. It also binds the incoming argument and then fashions the output to work with a standard Java List.

Spring Data also supports return types including Iterable, Stream, Flux, Optional, and more.

But what if you don’t know all the criteria needed to fetch? What if they keep changing? Then check out the next section.

2 — Query by Example

Query by Example is a way to allow someone else to provide the criteria for finding data. A simple example is building a search box on the web page where someone wants to search your inventory of Item objects.

If they entered SKU, name, or description, you can then feed those details into a probe. Any parameters that are NOT null will be queried against!

Item probe = new Item();  
probe.setSku(searchForm.getSku());  
probe.setName(searchForm.getName());  
probe.setDescription(searchForm.getDescription());

Example<Item> example = Example.of(probe);  
itemRepository.findAll(example);

The default behavior for Query by Example is to:

Ignore any fields that are null
Join all criteria as an AND
Match completely on each field

If you wanted to alter things, such as joining via OR, ignoring entire fields completely, or partially matching one (or all) fields, then you can.

But either way, this lets you quickly query for data based on varying criteria that may not be known until runtime.

But what if you need to harness some of that deeper more powerful huzzah your data store has? Then you need to check into the next few sections.

3 — Template-based

Spring Data MongoDB has MongoTemplate. Spring Data for Apache Cassandra has CqlTemplate. And Spring Data Redis has about a million various templates.

In case you’re wondering, old timey Spring Framework once had a JpaTemplate as well as a HibernateTemplate, but Hibernate/JPA evolved such that these templates no longer fit the bill. See further down how dropping down to the data store’s native API is always an option!

Basically, just about any Spring module has a template to help you dive into using native operations quickly and PROPERLY.

Item newItem = new Item("Smurf TV tray", "SKU-12345");  
mongoTemplate.insert(newItem);  
mongoTemplate.updateFirst(  
    query(where("sku").is("SKU-12345")),   
    update("price", 19.99),   
    Item.class);

Templates are geared toward giving you access to the data store’s power without getting caught up in resource management.

(BTW, this fragment isn’t all that MongoTemplate has to offer.)

While a powerful tool, your code will certainly NOT be portable! If a custom finder is getting too complicated, it may be time to switch to the data store’s template.

But what if using this template-based API is really just getting in the WAY of your need to write a store-specific query YOU ALREADY WROTE?

4 — @Query

All Spring Data modules offer you a really cool way to just Write The Query Yourself.

public ItemRepository extends JpaRepository<Item, Long> {

    @Query("select i from Item i where i.sku = :sku")  
    List<Item> myHandWrittenQuery(String sku);  
}

While the example above is a bit contrived, a business office query that took you three weeks to write and joins twenty different tables is real. (I once wrote one!)

And trying to twist and bend JPA to do the same thing may take you triple the time. If you already have the query, just stuff it into an @Query annotation like this and move on!

Spring Data will still handle opening and closing connections, mapping results, and all that good stuff. It will simply let YOU take the role of writing the queries!

And while this example is about Spring Data JPA, you’ll find counterpart annotations in most other modules as well.

But sometimes even THAT isn’t quite enough!

5— Dropping down to the data store

Sometimes you REALLY need Spring Data to get out of the way. Whether that means talking straight to JPA’s entity manager

Spring Data JPA lets you talk to the EntityManager. Spring Data MongoDB allows you to use a ClientSession. Spring Data Cassandra has the CqlSession.

All of these are native connections to talk directly to the data store using their own APIs. And Spring Boot autowires an instance into the application context. At any time, in any Spring bean, you can ask for an instance and talk straight to the data store.

Spring Data will get out of your way. This is only recommended as a last resort. It will be up to you to use the right interactions and properly manage resources. But if that’s what you need, then do it! (Just be sure to file any tickets with the original data store, okay?)

Spring Data is meant to ease your efforts at accessing data for your application and provides you with multiple ways to do it. And it gets in your way, you can sidestep it and go straight in. The choice is yours.

If you dig Spring Boot, then please stay tuned for my next article. However, if you simply can’t wait, then check out the following video where I show you how to test your Spring Data repositories…using a REAL database!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Software Patterns in 2022

Thu, 21 Jul 2022 00:00:00 GMT

Once, long ago, a fledgling coder grasped a beautiful tome titled “Design Patterns: Elements of Reusable Object-Oriented Software”. Otherwise known as the “Gang of Four” book.

And it was good.

He read through it after hours, his ears perking up. Pattern after pattern. And in his very next project, he tried to USE the patterns. ALL of the patterns.

And it was bad.

If you didn’t catch on, that was me. What I did was wrong. 100% wrong. Spiritually, ecumenically, grammatically.

Arrrgh!!! Too many patterns!And that’s when I realized that software wasn’t just about patterns. I began to learn that TRUE engineering is about tradeoffs. And so when I started writing my own software books, by golly, I included tradeoffs. I didn’t want another developer to suffer the same fate as me.

So what patterns should you look for in 2022? And what are THEIR tradeoffs? Let’s see!

1 — Templates

Templates offer developers shorthand ways to do stuff. They often arise when a full-blown API has too many options and lead to confusion. Templates can wrap such APIs and offer clear cut ways through the API confusion.

Spring is loaded to hilt with templates. One of my favorite being JdbcTemplate (the thing that drew me into the Spring Framework in the first place!) JdbcTemplate has a handful of operations including:

query(), update(), delete(), execute(), and call().
There are overloaded variations as well as things like queryForObject(), queryForList(), and queryForMap().
But NOT anything about opening and closing connections and cursors!

The whole POINT of JdbcTemplate is to take that off your hands. Use this template and you can focus on writing JDBC queries. Let the template handle resources.

Templates are still relevant today. Spring Data in recent months added a new fluent API to supporting modules to make it easier to express a query without getting bogged down in query language specifics. It’s basically another template.

RestTemplate is Spring Framework’s venerable tool to speak to remote services through HTTP. It’s creator, Arjen Poutsma, once presented to a packed room. Today, a newer variant with reactive programming supporting baked has emerged: WebClient. Both of these offer powerful ways to speak HTTP without having to get dragged into the complexity of the HTTP dance.

If you have some “recipe” you seem to keep copying everywhere, consider putting it into a template.

2 — Builders

A builder’s job is to gather all the information needed to assemble an object, but wait until the user invokes the build() method before assembling the object.

Can he build it? Yes he can!This one is trickier to assess whether it’s worth it to create the machinery. Sometimes, the best “builder” is a constructor call. Or two or three. Builders begin to shine when the information that must be provided isn’t in your hands all at once.

For example, if you need to ask the user a series of questions through various forms. Or if you need to make some other method calls. Builders let you plug in the values, as you gather them, building up this intermediate state. And then once you it all, you can MAKE the object.

This is also presuming you do NOT want to “make the object” BEFORE you have all the information.

Back in the day, setter injection was really popular. But the risk of a half-baked object has risen, and so today, it’s good practice to ONLY create an object when you have all the information on hand.

As tantalizing as they are, patterns are just a way to

Knowledge from on high, carried to the common coder. And just like the mythical tale of fire carried from Olympus to Earth, so, too, did this fountain of knowledge have dangers of untold tales.

You see, this book was chock full of ways to solve problems. But it came up short in trade offs. It said WHAT to do but not so much WHEN to do them.

3 — Injected Interfaces

This pattern may seem kind of strange, but hear me out.

If you have some concrete object that needs to act one way in this environment, but a different way in another environment, sometimes the simplest thing is to swap out that object for an interface. And then inject the concrete solution.

Imagine you had a KitchenService that provided Meal instances. It’s not hard to imagine building up all the actions this KitchenService would have. We could craft things like fetchIngredients(), cookMeal(), and plateTheFood(). Simple enough, right?

We always run into situations where the concrete scenario that we started with needs to evolve. Maybe we started this imaging our system serving up French cuisine, but something needs to pivot when we need an Italian-based kitchen?

While the French kitchen uses grabTheButter() relentlessly, the Italian one MUST have grateTheCheese()!

It’s okay to have a concrete instance buried deep early on. But in this evolving scenario, carry out the following steps:

Replace the class definition of KitchenService with an interface of the same name.
Implement it with FrenchKitchenService, migrating your existing code there.
Now implement ItalianKitchenService and inject it for your new scenario through an updated constructor call!

Make your code SAVORY using injectable interfaces!Another keen benefit is that you can now inject test mocks and stubs in testing.

What’s key in applying this pattern is to ONLY DO THIS when you NEED TO. Don’t start off with making EVERYTHING an interface!

Nope.

Start cobbling things together with concrete instances. Only when situations arise that demand variations should you consider this tactic. This type of litmus test can serve as a good gut check on whether or not something warrants an injection point or not.

4 — Strategies

Let’s wrap up this article with one more pattern that is still quite relevant today. And that is what is sometimes called a strategy interface or simply a strategy.

It’s kind of like the previous one, but not really. Yes, this is an injectable interface. But that’s about it when it comes to similarities.

The previous pattern speaks to injecting concrete instances that contain entire flows of operations. A strategy is more about turning this:

if (policy == NetworkMode.ONLINE) {  
    download();  
} else if (policy == NetworkMode.OFFLINE) {  
    skipDownload();  
}

into this…

public class OnlineStrategy implements NetworkModeStrategy {  
    public void download() {  
        // download it already!  
    }  
}

public class OfflineStrategy implements NetworkModeStrategy {  
    public void download() {  
        // do nothing!  
    }  
}

For example, an IDE that while in ONLINE mode would download artifacts from maven central, but in OFFLINE mode…doesn’t.

The idea is to capture a common operation (download()), and implement based on something like the user toggling a button. Or the system detecting a network outage. Or…whatever!

Swap out one strategy for another. This strategy can be changing…or it can be driven by startup conditions. Maybe your code publishes user-based events if the web page is loaded, but it doesn’t if you’re running in headless mode?

The scope of what the strategy does is much simpler. But this tactic is quite effective. And it opens the doors to expanding your options in the future. If you find yourself coding the same if-then clause (or switch statement) in multiple places, it could be a sign that you need to inject a strategy instead.

If you dig Spring Boot, then please stay tuned for my next article. However, if you simply can’t wait, then check out this episode of my podcast, where we learn how to effectively test Spring MVC web controllers using the tools of Spring Boot!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

When to NOT use Spring Boot!

Thu, 14 Jul 2022 00:00:00 GMT

Spring Boot is awesome. Spring Boot is great. It’s the bee’s knees. So why would you NOT want to use it? That’s what we’ll cover in this article.

1 — You already have a working application

Something we developers have a problem with is being handed an already-working application. It’s loaded with twisted paths of logic and coded with gnarly patterns. Oftentimes, this ball of mud before us screams “just rewrite me!”

And many-a-times, this is a mistake.

What we don’t realize is that this code contains a lot of information. A lot of knowledge. Many vital decisions, meetings, and analyses are tied up in this precious little hunk of code.

Simply rewriting it implies that not only can we write its immediate function better. We can handle all those nasty corner cases that had to be dealt with. Customer issues. Vendor wrinkles. The whole of it.

So before you reach for the almighty Spring Boot in the hopes of rewriting something written with a “lesser” toolkit, consider that maybe you’d be better off UNDERSTANDING the thing first.

Spend time learning its test kits. Make some additions and adjustments by first writing new tests. Once you’ve walked a few miles in that app’s proverbial shoes, you may just have a better understanding of how Spring Boot can help.

And maybe you won’t have to REWRITE it so much as ADAPT it to the world of Spring Boot.

ADAPT usually beats REWRITE!### 2 — You could use…something else!

We certainly love writing those Spring MVC controllers, crafting those Spring Data repositories, and locking it down with Spring Security policies. It’s fun to wield such power.

But is this really the best use of your time?

I recently wanted to roll my own “bit.ly”. A web site that would me create short links using my OWN domain. I had briefly looked up the cost of going bit.ly itself and paying to use a custom domain.

Nope.

*To code it myself or NOT to code it myself…that is the question!*Instead, I did a little extra research and opted to craft a lightweight Wordpress site with the Pretty Links plugin! The truth is, most of my time was hunting down the right domain and finding a domain provider that sell it to me. I found the official provider of .st domains in São Tomé, did some hunting, and found I could easily register https://trnq.st for just 29 EUR a year!

With that setup, I configured Cloudflare DNS and had a Wordpress site rolled and operational within 48 hours.

Now imagine trying to code a site that did A) random URL slugs, B) optionally custom URL slugs, C) metrics tracking, D) and the UI to go with it. Yikes!

Some things are easier to use already-baked solutions, and frankly NOT worth your personal time. The same can be said if you’re building a blog site or CMS system.

What’s that I hear? Isn’t https://spring.io a custom Spring Boot application? Yes it is. We initially crafted that back in 2014 and gave it a facelift just a couple years ago.

And it has required a bit of maintenance. Not because Spring Boot is trouble. But simply because ANY CUSTOM SITE YOU BUILD will have Ops-related issues, maintenance demands, and other issues you can’t ever foresee.

When you reach for someone else’s site-baking toolkit, be it Wordpress or Nuxt or whatever, you are taking advantage of literally MILLIONS of hours of development time from often huge communities. Why presume you can roll that in your off hours?

And even if you have to pay 29 EUR/year + whatever your hosting provider costs, it’s still a LOT cheaper than the hours YOU’LL have to spend getting it up and running and then sustaining it!

3 — Spring Boot just doesn’t fit

We all like to use our favorite solution everywhere, right? But sometimes, things just don’t fly. If you’re part of a big team, then odds are, more than one application is being built.

One of the backend systems MAY be using Spring Boot. But another one ISN’T!

And what if that OTHER system is built by the gulp JavaScript team!

“I am so scared!”All joking aside, the JavaScript team MAY be using Node to do everything. They may use it for the frontend AND the backend.

And that’s okay. You can’t get your fingers into everything. And if we’re talking about a huge team/contract, then you need to focus on your area of influence.

Getting bent out of shape because another team is NOT using Spring Boot isn’t the way to go.

The other piece in all this is that JavaScript-based systems have an entire WORLD of tools: build systems, deployment tools, IDEs, and management stuff.

Waltzing in and suggesting to a team of JavaScript pros that they need to cast it all aside isn’t likely to resonate.

So simply…let it go.

### 4 — It’s not your decision

Sometimes, when you join a new team, and they’ve already made a choice on which way to move forward, the opportunity to pick has passed. And it’s your job to implement it!

Perhaps this comment I’ve just made sounds a little rude? Well, if you’ve joined a team that just finished three weeks of meetings, discussions, and email threads in order to form a plan, then it may be YOU that is rude. That is, if you’re suggesting they drop EVERYTHING and pivot to Spring Boot.

If you want to be a professional software developer, then one piece of that is communication. And professionals don’t go out of their way to argue and push. Instead, try to learn what decisions were made. Invest time in groking the choices made. And write the best code you can!

Just write the best code you canBecause things change. People roll off projects. Some day, YOU may be the lead developer, and you’ll be faced with Yet Another Decision to make for either a new app, or an authorized rewrite of this one.

And that is the time to apply you’ve learned about the current app along with what you’ve gleaned from Spring Boot Learning, and pitch your best idea (which, hopefully, is Spring Boot!)

If YOU’RE facing down a decision to Spring Boot or NOT to Spring Boot, then leave me a comment.

If you dig Spring Boot, then please stay tuned for my next article. However, if you simply can’t wait, then check out this episode of my podcast, where I chatted with a Spring community contributor on the whole of Spring, Spring Boot, OSS, and working together.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content? Then SIGN UP FOR MY NEWSLETTER.

What books should I buy to become a Spring developer?

Thu, 07 Jul 2022 00:00:00 GMT

I wrote an article over nine years ago talking about this, and it’s woefully due for an update.

The struggle with answering this, is that when I was learning the ropes of software engineering, my circumstances were different. For one thing, SUN Microsystems was still a company! And Java was a newborn technology people didn’t fully grok.

But understanding the spirit of new grads and fledgling developers seeking to get a jumpstart on their coding careers, I have built up this list of recommendations I think will benefit you.

Look at all these people LOVING Spring books!### 1 — My books!

Well, duh! What author isn’t going to recommend their own?

Pre-order your copy today at https://trnq.st/book!On a more serious note, I recommend my own books because I strive to offer hands-on coding examples along with practical solutions. I also like to point out choice you have to make and the tradeoffs that involves.

Engineering is fraught with tradeoffs. There is rarely a hard rule that doesn’t have some exception. It’s important to understand the costs and benefits in making choices. And if there’s there one thing I can bring to the table, it’s experience with Real World(TM) systems.

I worked on a 24x7x365 operational system for ten years. I came in after hours to fix things if they broke. I once came in three times on the same night. Yikes! I built tools to me stave off outages. That sort of crucible hones your ability to build apps as well.

And so, I try to put some of that experience into my books.

2 — Spring in Action by Craig Walls

There’s a reason this teammate and personal friend has the biggest selling title at Manning. He is a real Spring pro! And he was an expert on Spring when I was but a wee lad. He’s not older. He’s just been in the trenches of Spring development from the early days.

Grab the latest version of Spring in Action at https://trnq.st/o2oa!And he knows LOTS of ins and outs. His content is gold.

And it’s entertaining. Having written probably more titles than anyone I know (including me), he has honed his writing style to where you can have fun AND learn valuable concepts.

And he’s always making updates to his tomes of knowledge. Maybe that sounds like a negative, but it’s really a positive. At first blush, you may feel like he’s simply trying to make an extra buck. In truth, you KNOW that he will have a new book in the next 1–2 years with the latest features. Spending $30–40 every other year is a reasonable price for some rock-solid information.

3 — Whatever your UI solution is

What is your team using to build its UI? React? Vue? Angular? JavaFX? Swing? Griffon?

If you even KNOW what Swing of Griffon are, leave me a comment below!

Whatever your team is using, it is of keen benefit to understand it even if you aren’t directly tasked with building it.

That’s right.

Even if you aren’t part of the UI-building team, understanding what they are building will be valuable. It will make YOU more valuable to understand it. To be able to contribute to it, here and there. And, on occasion, to chip in a pull request.

I’m no expert at JavaScript. I’m more of a Padawan. But this has helped me work with our UI experts and also interact with those on our team that are NOT.

If THIS is what YOU’RE building, I’d LOVE to see it!### 4 — Whatever your data store solution happens to be

Where are you storing all your data? Dimes-to-donuts it’s a relational database. Postgres? MySQL? MariaDB? Oracle?

Even if you’re using something like MongoDB of Apache Cassandra, it’s of benefit for you to go grab be best-selling title on that datastore.

Boning up your skill son Postgres or MongoDB will help you layer your application on top of that. Understanding tables or document structures will give you the ability to discuss deep-seated solutions that leverage your datastore with maximum power.

And don’t grab some foolish ANSI SQL book. That’s ridiculous. SQL itself has too many gaps and is spread across too many standards for those books to REALLY help you.

If your team is using Postgres, grab a Postgres book and start reading! Interoperability isn’t as valuable as leveraging that datastore to the hilt. The odds your management will decide to ditch Postgres and switch to MariaDB are pretty much nil.

### 5 — BONUS TIP

There’s one ADDITIONAL tip I want to offer.

It’s not something you’ll find in a book or a handout or a LinkedIn post.

It’s this — create a Google Document and start taking notes. Daily notes. Write down what you’re working on. Write down what you’re struggling with.

Create an engineer’s journal.

You see, when I started my career long ago, before Google was even a thing, I had a small notebook. I wrote down daily activities. Routine actions. Stuff I would do.

Journaling, “old school”That fell by the wayside, but I recently upgraded that concept and started writing myself a personal journal in a Google Document that is just for me.

And it has, more than anything, served as a way to gauge my activity. It gives me instant feedback on my personal development velocity.

And, because I write down everything I work on (not just completed code), it is GREAT at helping me beat back the beast of Imposter Syndrome. At a glance, I can see everything I’ve done in the past 4–5 days. And simply SEEING my efforts, research, and completion, means I no longer have to rely on my MEMORY to REMEMBER what I’ve accomplished.

I can SEE what I’ve accomplished. And I go to bed at night much more satisfied that I’m making the difference that I originally sought by becoming a software engineer.

And don’t forget — books are a means to learn some knowledge. But they don’t contain everything you need to grow as a developer.

Stay tuned for my next article. However, if you simply can’t wait, then check out this video below, where I ran into a problem I COULDN’T SOLVE despite being a pro coder!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Spring Boot is your ticket…to ticket resolution!

Thu, 30 Jun 2022 00:00:00 GMT

Ever had something go wrong?

Systems break. Bugs pop up. Things fall apart. As a scan tickets on Spring Data JPA, I run into this all the time. And what do I do?

Half the time, I try to create a “reproducer”. We all like a situation that reproduces someone’s problem, moving us one step closer to fixing the problem. Yeah, yeah, I know that I sometimes call myself a “test-bitten script junky.” That’s because I’m a HUGE fan of automated testing and capturing things into test case.

Heck, I’ve been known to add more tests to the system EVEN IF NOTHING GOT BROKEN.

So what happens when someone tells me their query isn’t working? Their JPA entity configuration isn’t working? Their CONFIGURATION of Spring Data inside their Spring Boot app isn’t working?

I reach for the Spring Initializr at https://start.spring.io, craft a barebones application, and start trying to replicate their setup. People are usually happy to share entity class definitions. Sometimes they’ll give me their SQL or JPQL statements.

With the power of H2 embedded databases, a fleet of test modules included with every project, and the fact that I can have a humming application setup and ready to go in five minutes (or less), Spring Boot + Spring Initializr is the ULTIMATE PRODUCTIVITY toolkit!

One of our past teammates, Matt Stine, once eyeballed this in Spring Boot’s early days. He had remarked “everything a Boot app!” When Spring Boot debuted back in 2014, everyone was blown away. But in that moment, they/we didn’t realize the power of being to throw together an app in no time.

Everything a Boot app!Nobody back in 2014 realized the power you hold in your hands by simply grabbing some basic dependencies and merrily start reproducing someone else’s application. Coupled with github and the ability to throw your application onto a source-sharing site, and you’ve got yourself collaboration we’ve never seen before.

Today alone, I’ve created two different application, attempting to replicate two different problems. And it worked! I tracked down someone’s problem to a single annotation that had been misconfigured. This was after I had created my own reproducer, and THEY had created a reproducer.

With two different Spring Boot apps, both tiny, I knew we could converge on the issue, quickly. And this fact drew me in. I was excited. Finding the crux of this was FUN! I submitted a PR to their reproducer and linked back to it in the original issue.

As you work through your own issues, I encourage you, at any time, to stop what you’re doing and simply RECREATE IT. That’s right. Stop working in your Big App, and see if you can create a Tiny App that hovers around this issue you’re having.

Because if you run aground and CAN’T figure it out, your Tiny App will provide the means to SHARE you problem with others. This also gives you a chance to sanitize if need be. But ultimately, it forces you to RETHING your problem. Can you capture your problem easily?

Because if you can do this, we are well on your way toward solving the problem and ultimately subsuming it into a test case of your Big App.

Spring Boot is the ultimate “noodling” tool. You can noodle out solutions by simply recreating things. And this is one of those things that Spring Boot really sizzles at.

If you dig Spring Boot, then please stay tuned for my next article. However, if you simply can’t wait, then check out this live stream where we dive into configuring Spring Boot applications and learn how things “fit together” in the land of Spring.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

How to Write a Software Book in 4 Steps

Thu, 23 Jun 2022 00:00:00 GMT

Step 1 — Come up with a great topic

It’s critical that you pick a topic people won’t be able to put down.

If you were to attend a technical conference today, imagine what are people talking about. Because if they’re talking about, they’re probably willing to purchase a book about it!

Back in 2014, Spring Boot made its first GA release. And the buzz was STRONG. In the midst of that year’s SpringOne conference, I received an email from my publisher asking about doing a Spring book. I looked around, and seeing all the chatter, hastily threw together a counter proposal, telling them we HAD to write a book about Spring Boot. They had never heard of Spring Boot, but leveraging my expertise and pointing out the excitement, my publisher agreed to a five chapter book deal.

Suffice it to say, that book was a slam dunk. Being the first Spring Boot to market, it sold FAST. The advance they gave me was earned back in six months.

I’d like to take credit as some phenomenal writer, but the truth is, Spring Boot as a topic is a gold mine and did much of the heavy lifting.

What are you an expert in? What is something you could talk about all day without hesitation? And contrast this with, what is something in the vicinity of your expertise that you KNOW people want to LEARN MORE about?

Redis? React? Spring? Project Reactor? MongoDB? Postgres? There are MANY opportunities.

Try this — carve out one afternoon, perhaps four hours. Sit down and try to write (or type into a Google Doc) a list of your skills. Not necessarily stuff you have committed to memory. Just imagine the areas of code you have written LOTS of code using. Also list book topics you would read about. This may reveal a topic others would like and you could write!

Alas, as important as this is, the next step is vital.

Step 2 — Start writing the code for it

There is no other genre of books I can think of that has the concept of writing both prose AND code.

For software-based books, we need the code. Your readers will WANT THE CODE. So plan on this — don’t be stingy. Considering GitHub organizations are now freely available, go carve one out and make a public-facing repository to hold all your book’s code.

And start writing code.

That’s right…plan on GIVING AWAY the code to your book.

Because that’s how open source works these days. People may not have free access to your prose, but giving away the code will create interest in the paid-for book you’ll later write.

As you knuckle down and start writing code, think about what struggles YOU had in using this toolkit or framework. Imagine what you WISH someone had shared with you early on. And shape your application.

I have found that some of the bits I need to show are in the core application. And some of the bits can be captured inside a test case class somewhere else.

And don’t forget — not ALL the code in the repository has to be in the book. You can have a fully developed operational application in your repository and plan on only putting the key bits in the manuscript. This leaves you room to tell the reader to GO TO YOUR REPOSITORY for more!

You don’t have to have ALL your code in place to begin what I like to call The Grind™, but it’s the part that will elevate you, in the next section.

Step 3 — Typeset everything

I once worked at a sports magazine. Not as a writer. Not as an editor. Instead, as a “gopher”, because my job to “go for” anything the editor told me to. Stories came in all the time from the editor’s freelance authors. He would hand them to me and tell to “typeset” them. That’s because the story had already been written. This was more like transcription. Simple moving the letters and words from one medium to another.

When it comes to software books, once you have the code written to hang the whole book upon, a lot of the heavy lifting has been done. I often will spend hours if not days hammering out the code.

Then I can simply paste in various fragments of it inside either a Word document or an Asciidoctor file.

Then I explain it. And expound upon it.

And while doing so, I often spot tradeoffs I made in writing the code. (This is critical! Your readers will want to know, for example, whether to inject the real service or use a mock if you’re talking about testing!)

And often what I find, is that I can extract a story in the process.

Right now I’m writing Chapter 5, Testing with Spring Boot of my Learning Spring Boot 3.0 book. And in covering all the various forms of testing, whether its domain objects, mocked out services, repositories built on top of embedded databases, repositories leveraging Testcontainers, or security-based testing, it all turns into a story.

SHOULD someone test their domain objects? WHAT ABOUT getters and setters? WHY would someone choose an embedded database over a mock one? SHOULD I choose a Docker-based Testcontainers approach over embedded.

I KNOW you can write code. But…can you EXPLAIN your code to someone else? This is what elevates you. This is what is grinding is all about. It’s not necessarily hard. It can just be tedious. Sometimes it takes me longer to spell out one method of functionality than it takes me to read and grok that code.

And like I said, embrace giving your reader the reasons you are doing this and that. Draw upon your skills and experience. This is why someone paid for your book. And…speak to your reader like you’re having a one-on-one conversation. Like you’re pair programming and you’re walking them through the code.

Anyone can see your publicly visible code. But only those that have chosen to give you money are waiting patiently for your depth and analysis ABOUT that code!

Now that you’ve written code and the explanation behind it, it’s time for some tips’n’tricks to market your tome.

Step 4 — Market your book

This step is key. You need to let people know about your book. However, there are some finer points that many people don’t realize that could catapult your book ahead of others.

First of all, DO NOT WAIT until your book is complete to begin this process.

You need to alert your friends and fans that you are writing a book the moment you start. This is a way to build anticipation so that when it’s released, they will be EXCITED to buy it!

But don’t just TELL people. And don’t BEG people to sign up either for a pre-release copy.

Instead, use something deeper and more meaningful. Build content around your book. Some of the most effective ways involves:

Live stream some coding sessions
Write blog posts, Medium articles, and LinkedIn posts
Start building an email list and send out campaigns to your fans
Etc., etc., and so on!

Don’t BEG people to sign up for your book. Instead, create value and then include a link somewhere in the middle or even toward the end.

You see, people will buy your book if it solves a problem they are having. That’s why a post titled “Please buy my book” will draw anyone, but a live stream on YouTube called “How to test with Spring Boot” can result in literally hundreds of people watching and sharing your content.

Let me introduce one additional concept that BLEW MY MIND when I discovered it: You can talk about the exact same thing…more than once.

You can make the SAME THING more than once!Imagine that you created a video where you talk about using Testcontainers to verify a service.

Use that video’s script or bullet points and then write an article on Medium.
Next, write a post for your paying members.
Create a newsletter campaign for the people that have signed up.

With this strategy, you write one chunk of code, but reuse it on multiple platforms. Meet your community where they are, whether that’s LinkedIn, YouTube, Twitter, Medium, your membership provider (I used to use Buy Me a Coffee), etc.

And when you embark upon the next chapter of your book, you can repeat the whole process using THAT chapter’s code.

And that’s okay.

You are NOT losing customers of your book when you use this strategy. As strange as it sounds, you will actually GROW YOUR BASE of interested readers.

You see, each platform works differently. For example, someone wanting to learn the ins and outs about Spring Boot can learn a LOT of that by watching all my videos on my YouTube channel. But that requires hours of effort. And they’d have to sift through which videos to pick depending on their needs.

A book offers that same person a more structured and condensed way to consume the same information. At the same time, someone that’s reading my book may want to see more details on a specific topic. That’s why my book has links to various videos on my channel where they can get an enhanced experience.

The ability to tie text with video and create a more synergistic experience is paramount.

It’s flat out foolish to ignore this opportunity.

And so I encourage you to take that leap. If you want to write a book, START TODAY! If you’re thinking about this, leave response and let me know.

Stay tuned for my next article. However, if you simply can’t wait, then check out my most recent live stream down below where I literally USED CODE FROM MY CURRENT BOOK to teach others about testing Spring MVC web controllers!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Unit tests saved my hide and helped me track down the REAL problem!

Wed, 15 Jun 2022 00:00:00 GMT

Unit tests saved my hide and helped me track down the REAL problem!

I recently picked up a curious ticket. Someone was using an obscure combination of features inside Spring Data JPA. In particular, DTO…

Unit tests saved my hide and helped me track down the REAL problem!

I recently picked up a curious ticket. Someone was using an obscure combination of features inside Spring Data JPA. In particular, DTO objects and paging.

Say what?

Did you know you can write JPQL statements like this?

SELECT new com.example.CustomDto(u.firstname, u.lastname) from User u

What you’re doing is essentially pre-converting the results into this DTO type instead of the usual entity type. There are some key requirements like having to spell out the FQDN (fully qualified domain name), but other than, it makes for a tidy arrangement.

In Spring Data JPA, this can manifest as either a named query in the entity’s definition, or you can apply it through the @Query annotation on your repository!

@Query(SELECT new com.example.CustomDto(u.firstname, u.lastname) from User u")  
List<CustomDto> findByNamedQueryWithConstructorExpression();

Maybe that is a little clunky? If you’ve just recently picked up JPA and are using to writing bare SQL, this can look super cray. Nevertheless, it’s actually a feature I learned about recently that I think is handy if you’re wanting to keep the entity-to-DTO translation close to each other.

BTW, IntelliJ IDEA totally can parse these strings! It even offers code completion. If you ever have doubts, put them aside. IntelliJ IDEA is always a step or two ahead of us, ready to do what’s key to maintaining code.

So what’s the problem in all this?

When you take this seemingly harmless statement above and alter it’s signature to return a Page of CustomDto objects, you may or may not have everything fall apart.

No, this isn’t Schrödinger’s Bug (though it may feel like it!)

If you instead have THIS in your repository definition:

@Query(SELECT new com.example.CustomDto(u.firstname, u.lastname) from User u")  
Page<CustomDto> findByNamedQueryWithConstructorExpression(Pageable pageable);

…then you are picking up Spring Data JPA’s ability to fetch a subset of results automatically. However, to do this, Spring Data JPA must first transform the query into a count-based query so it can, you know, count the results!

And that’s where a really quirky bug lives. Due to pattern matching rules written long ago, everything works great if this query has a DISTINCT. But if NOT, well, it blows up if there’s no comma anywhere inside that “new com.example.CustomDTO” expression.

BOTTOM LINE: Spring Data JPA can’t handle one of these DTO-oriented operations to fashion a Page if the DTO only has one argument.

Whew! That was, what’s the clinical term? Overcomplicated for describing a problem.

Suffice it to say, I spent all day JUST TRYING TO WRITE A TEST CASE. At first, I thought I had figured out the problem no longer existed. I was ready to commit my smug little tests, since there’s nothing wrong with submitting a new test case even if no code has changed.

I thought the issue no longer existed!But something in the back of my mind wouldn’t accept that. No, I sensed that I should poke and prod some more. And that proved correct. My original test case did NOT properly apply the Paging situation.

Once I wiggled things into place, I sure enough had a failing test case right in front of my very eyes.

But…I was wrong.With a nicely failing test case right in front of me, I could FINALLY engage with IntelliJ’s debugger. And boy howdy did I do that.

Something you may not know, is that Spring Data JPA does a lot of parsing upfront when you have repository definitions. What that means is that if you put a plain old breakpoint smack dab in the middle of its parsing algorithm, the debugger will stop FOR EVERY SINGLE REPOSITORY METHOD.

So I had to utilize conditional breakpoints. You just right-click on an existing break point and add a little pseudo-Java code to ONLY stop if the query string has my little CustomDto object in it.

I say pseudo-Java, because you not only have access to all in-scope methods, but IntelliJ seems to have some bean property shortcuts also at your beck and call.

Anywho, with conditional breakpoints in place, I started running the test cases relentless, until I narrowed everything down to a tiny sliver of code that used regular expressions to rip apart that query string and then wrap it with a nice count() operation.

And so I started down the regular expression logic and TRIED to figure out what it was doing. A day-and-a-half in, and I was looking at something I kinda sorta had a glimmer of an idea how it worked.

Me, trying to grok a regular expressionSuffice it to say, I tried this, that, and the other thing. And none of them worked. This little beasty of code kept tripping me up!

boolean useVariable = StringUtils.*hasText*(variable) *//* && !variable.startsWith(" new") *//* && !variable.startsWith("count(") *//* && !variable.contains(",");

This little fragment of code would end up as false for a 2-argument DTO (which worked) but true for a 1-argument DTO. It needed to be false for both!

So I subtly overrode it with false and then ran the entire test suite!

And what do you know! Almost everything PASSED.

Except for like TWO test cases. And they both had something to do with select distinct.

Now I had started at the tiny space right before new up in that code fragment more than once. Have you? Something weird about it? I had even tried removing the space. After all, isn’t that THE SAME THING?

Well, on a fluke, I decided to ADD another clause:

&& !variable.startsWith("new")

Same as the other one, but no spaces. I ran the battery of test cases. And they ALL worked.

And then I looked, dumbfounded and my jaw wide open, I saw it. I realized it.

startsWith(“ new”) and startsWith(“new”) are absolutely, positively NOT THE SAME THING. I was imagining contains(). But startsWith() is VERY CLEARLY different.

With a “whoop de doo”, I proceeded to polish it all up, and ensure that the information just gleaned from an entire day’s effort would NOT be lost, turning out this little fragment of code:

boolean useVariable = StringUtils.*hasText*(variable) *//* && !variable.startsWith("new") *// select [new com.example.User...* && !variable.startsWith(" new") *// select distinct[ new com.example.User...* && !variable.startsWith("count(") *// select [count(...* && !variable.contains(",");

The added comments were to help jog my own memory, in case we ran into this in the future.

I also was able to polish up test cases, ensuring we were testing every angle.

And once again, regular expressions turned out to not be as tragic as they could have! After making sure everything was up to Spring standards, I proceeded to backport the fix to all supported versions.

That last backport took a little extra finessing, but it was worth it. And nothing puts a smile more than seeing an emoji reaction on my final summary comment:

Emojis in GitHub are always welcome! Makes the whole effort worth it.If you are monitoring a ticket and have the chance to “thumbs up” or cheer someone’s effort, please do. It’s one of those tiny opportunities we all have to spread a little cheer.

Stay tuned for my next article. However, if you simply can’t wait, then check out the video below where I find the most powerful coder in all of gamingland to help me write a web app!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

How I stopped worrying and learned to love regular expressions

Wed, 08 Jun 2022 00:00:00 GMT

How I stopped worrying and learned to love regular expressions

As mentioned in my previous article, people select relational over NoSQL databases for new projects. Big time. We’re talking 80% of the…

How I stopped worrying and learned to love regular expressions

As mentioned in my previous article, people select relational over NoSQL databases for new projects. Big time. We’re talking 80% of the time. That’s 4-to-1 for you odds makers. And because no app is truly complete without data, it makes Spring Data JPA rank VERY high in most-selected modules when people pull together a new app over at https://start.spring.io.

Seriously, when someone wants to whip up and app and they use that wickedly cool website, they most often reach for Spring Boot (cuz its baked in), Spring Security (your app isn’t real until its secured) and Spring Data JPA.

And what happens when you’re popular? People open tickets against the project. We’re talking on a daily basis. And someone was needing to use PostgreSQL’s JSONB functions.

This ain’t your grandpa’s relational database.

No, today all the cool kids are using hot features like JSON-manipulating functions rolled straight into their SQL code. In this case, PostgreSQL has support parsing and gleaning JSON. And this includes some slick operators. Look at this:

'{"a":1, "b":2}'::jsonb ? 'b'

That little puppy will query a JSON structure to test whether or not HAS “b” as a key in the structure. Nice, ehh? Probably better than pulling out some string-based data, running it through a JSON parser, and THEN querying for something.

Why NOT put that RIGHT INTO THE DATABASE?

Did I mentioned Spring Data JPA earlier in this article? Spring Data JPA doesn’t do JPA directly. No, we offload actual JPA operations to a JPA provider, whether thats Hibernate or EclipseLink. But we provide some handy integrations.

For example, if you declare an interface method, we can glean the nature of the entity type, parse the method name, and essentially talk to the JPA entity manager on your behalf to assemble a query. If you’ve worked with the EntityManager SPI directly, then you’ll understand why this is really slick for something like 80% of standard queries.

We also provide some other ways to take domain-level knowledge of your application and transform it into JPA styled queries.

But if there’s one thing Spring does, it’s provide you with an escape hatch. Maybe your query is flat out too complicated for our easements. In that situation, you can simply apply an @Query annotation to your query method and roll the JPQL yourself!

Which has proven to be quite handy for your Spring Data community.

Unless you happen to be using one of these new-fangled JSON operators! Something we try and guard against is people mixing what are called “JDBC style parameters” (?) with “JPA style parameters” (:foo or ?2). When you fashion a query, you really need to pick one or the other.

The error message from the JPA provider may be cryptic, so we try to catch that early on. Well guess what this type of query would look like:

@Query("SELECT * FROM table WHERE (json_col->'jsonKey')::jsonb \\?\\? :param ")  
List<User> customQueryWithQuestionMarksAndNamedParam(String param);

Hibernate will allow a double question mark (??) through, turning it into a single question mark (?) on the other side. I’m not sure if JPA itself covers this, or if this is outside the spec.

But either way, our existing pattern detectors viewed this as a JDBC-style parameter. And the named (:param) argument is deemed JPA-style. And thus, this query was viewed as a mixer, which meant we shut it down as BAD!

Mixing of ? parameters and other forms like ?1 is not supported!

So I spent probably 2–3 hours today simply grokking the problem at hand. I fashioned a test case to sniff out that double-? and ignore it, but realized we needed much more comprehensive testing.

@Query("SELECT * FROM table WHERE (json_col->'jsonKey')::jsonb \\?\\? :param ")  
List<User> customQueryWithQuestionMarksAndNamedParam(String param);

@Query("SELECT * FROM table WHERE (json_col->'jsonKey')::jsonb \\?\\? ? ")  
List<User> customQueryWithQuestionMarksAndJdbcStyleParam(String param);

@Query("SELECT * FROM table WHERE (json_col->'jsonKey')::jsonb \\?\\? ?1 ")  
List<User> customQueryWithQuestionMarksAndNumberedStyleParam(String param);

@Query("SELECT * FROM table WHERE (json_col->'jsonKey')::jsonb \\?\\? ?1 and other_col = ? ")  
List<User> customQueryWithQuestionMarksAndJdbcStyleAndNumberedStyleParam(String param1, String param2);

Essentially, we need laser-focused resolution on what’s happening so only legit queries are allowed through. And sometime, when solving a problem, you need to watch out for the edge cases right next door to your current scenario. I didn’t want to solve this problem and have a nigh-identical ticket get opened the next day.

And so I ended up, knee deep in Spring Data JPA code, writing a regex pattern detector for JDBC-style (?), numbered-style (?1), and named-style (:foo) parameters.

If there is something that makes any coder squirm and shake, it’s maintaining regex patterns. Well, I’ve done them for years. PERL, Python, and even the scary Java variants. And I knew, KNEW, that what we needed in this scenario was something called a “zero width lookahead” pattern.

Basically ask the question “does this string contain a space, following by a question mark, and NOT followed by a number”. Spoiler alert: it looks like this…

Pattern JDBC_STYLE_PARAM = Pattern.compile(" \\?(?!\\d)");

That pattern starts with a space. It then has the question mark. And to avoid this being an “optional” modifier, has a backslash in front of it. (And a 2nd backslash to escape the backslash. Welcome to Java pattern matching.)

That last pattern is extra complex, so I’ll pull it down below first:

(?!\d)

Wrapped with parentheses, the first character is a ?, indicating it’s a lookahead or lookbehind pattern. The !-character signals this as a negative match, i.e. a NOT. And \d signals that we’re looking for a digit.

So this little thing means to look head, and see if there is NOT a digit, without consuming any characters. (That’s what zero lookahead means).

The alternative way to write “…and not followed by zzz” is so convoluted I’m not even putting it here. This little pattern lets you find a question mark NOT followed a digit.

And I didn’t know this before today. Or better stated, someone ELSE submitted a patch to Spring Data JPA a few weeks ago using the same construct but on another pattern. And this was the first time I realized THAT was the solution I needed! And reached for it today.

And it worked beautifully.

I’ll let you read the following pattern and deduce what each of them does:

Pattern NUMBERED_STYLE_PARAM = Pattern.compile(" \\?(?=\\d)");  
Pattern NAMED_STYLE_PARAM = Pattern.compile(" :\\w+");

HINT: In look aheads, = is the match, and ! is the NOT match. To look behind, you use ?<.

JPA parameters are basically numbered OR named. Using these handy little patterns made it possible for me to rewrite our handlers. After all, we only want to sniff out someone using JPA and JDBC in the same query. Anything else, and we turn it over to the JPA provider and then let them pass it on to the database engine.

If the engine itself doesn’t handle JSONB queries, well that’s between you and your database engine.

Stay tuned for my next article. However, if you simply can’t wait, then check out the video below and get a taste of querying for data with Spring Boot!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Writing tests is NEVER a mistake…

Wed, 01 Jun 2022 00:00:00 GMT

Writing tests is NEVER a mistake…

…even if the “main” code doesn’t need to change.

Writing tests is NEVER a mistake…

…even if the “main” code doesn’t need to change.

As the lead for Spring Data JPA, I have had to learn a LOT of details about how this toolkit works. Nothing shakes you up more than being handed the reins to a critical project and then opening up your first “new” issue the next day.

And being The One that has to deal with it.

People often open new tickets against Spring Data JPA. With people selecting SQL-based data stores over NoSQL-based data stores at an average of 4-to-1 on new projects, it makes this project popular. And when have troubles, they open tickets.

So one of my first steps is to simply glean what went wrong. Sometimes it’s plain as day and I can point it out. But more often than not, they have a specific situation in their application where something went awry.

And so the first thing I reach for, if not spotting it as an Already Solved issue, is to see how easy it is to write a test case.

And this is where I smile.

Because automated test cases are the key toward learning a new project. Every time we write a test case, it forces us to understand how the system works. How a single module works. How a single function works.

And with each test case, our understanding grows.

It takes patience. It takes endurance. If you want to become a pro developer, this is the kind of thing you will experience day in and day out. Not the glittery, uber-existing thing where you assemble a Twitter-lookalike in 45 minutes like I’ve seen at conference talks. That stuff is fun, but it’s not representative of the grind software geeks face.

We must reproduce problems, diagnose if they REALLY exist, and if so, decide what the solution is. (Or..wink wink…what the solution is NOT. Sometimes, a solution isn’t warranted, but that’s for another article.)

And over time, as we write more and more tests, we will learn more and more of the system. We will, over time, build up a knowledge of how all the parts work together.

And this is why, sometimes even if there is no actual problem to fix in a given issue, I’ll sometimes add the newly minted test cases to the codebase!

Extra test cases are NEVER a mistake to add to a codebase.

And then comes that “ah-ha” moment. That day when you wake up, brew your coffee, look out the window as the sun rises, and have a brain blast. You realize that part of the system that keeps cropping up in bug reports was built sub-optimally. It doesn’t have the “right” structure and hence the source of multiple issues.

And you’ll run up the stairs, to the end of the hallway, into your office, power up your machine, and start coding with speed and excitement. Because you can FINALLY see the project as a whole and HOW it needs to be pivoted in order to Do Something Right.

And you’ll sit back, grinning with your coffee cup in hand, confident in your knowledge. It may have taken six months, nine months, maybe eighteen months. But your knowledge isn’t exactly something picked up from reading the reference manual.

No, you have deep, intimate knowledge and can effect change that will serve users AS WELL AS yourself. And that’s part of the deep satisfaction that will affirm this was what you were meant to be.

If you enjoyed this article, then follow me to catch the next one. But if you simply can’t wait, then check out the video below, where do deep, talking about DTOs vs. entities and why that’s a thing!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Want to secure your Spring Boot 3 app with OUT managing all those users?

Wed, 25 May 2022 00:00:00 GMT

Want to secure your Spring Boot 3 app with OUT managing all those users?

There’s a saying:

Want to secure your Spring Boot 3 app with OUT managing all those users?

There’s a saying:

The best things in life are free.

While I’m not convinced this is even remotely true, when it comes to offloading user management on a major tech company at no cost, Google is the way to go!

In my previous article, we explored how to register an OAuth 2 application with Google, grab creds, and hook them into Spring Boot.

The cherry on top, which we’ll cover in THIS article, is how after you let Google authenticate your users FOR YOU, you can then scarf some of that free YouTube data, and sport it on your own web site!

In that previous article, we managed to configure all the Spring Boot 3 + Spring Security OAuth 2 goodness along with a Spring Framework WebClient wired up to use the OAuth 2 credentials to do all its leg work, making it possible to do remote calls.

And part of the magic included designing an OpenFeign-like remote client pure using a Java interface like this:

interface YouTube {  
  
  @GetExchange("/search?part=snippet&type=video")  
  SearchListResponse channelVideos( *//* @RequestParam String channelId, *//* @RequestParam int maxResults, *//* @RequestParam Sort order);  
  
  enum Sort {  
    DATE("date"), *//* VIEW\_COUNT("viewCount"), *//* TITLE("title"), *//* RATING("rating");  
  
    private final String type;  
  
    Sort(String type) {  
      this.type = type;  
    }  
  }  
}

In case you didn’t catch word, Spring Boot 3 is based on Java 17. And one of the coolest features in Java 17 are records, a perfect tool for capturing all the DTOs defined in YouTube’s API

The YouTube service defined up above sports a SearchListResponse return type. Based on a simple reading of YouTube’s API, this record definition should do the trick!

record SearchListResponse(String kind, String etag, String nextPageToken, String prevPageToken, PageInfo pageInfo,  
  SearchResult[] items) {  
}

That’s it! This tiny definition provides fields, setters & getters (slightly different than traditional Java beans), and an all-arg constructor. It’s possible to add additional methods as needed, but as shown, Jackson, the JSON serialization engine autoconfigured by Spring Boot will perfectly convert the JSON response from YouTube into this type.

Now most of these fields are simple Java types. However, we need to capture PageInfo and SearchResult. Time for more records!

record PageInfo(Integer totalResults, Integer resultsPerPage) {  
}

record SearchResult(String kind, String etag, SearchId id, SearchSnippet snippet) {  
}

In these two records, there are a couple additional records needed:

record SearchId(String kind, String videoId, String channelId, String playlistId) {  
}

record SearchSnippet(String publishedAt, String channelId, String title, String description,  
  Map<String, SearchThumbnail> thumbnails, String channelTitle) {  
}

The only additional type in these records not seen earlier is a SearchThumbnail:

record SearchThumbnail(String url, Integer width, Integer height) {  
}

Since these final records don’t require any more records, we are done!

It’s Spring MVC controller time, baby.

@Controller  
public class HomeController {  
  
  private final YouTube youTube;  
  
  public HomeController(YouTube youTube) {  
    this.youTube = youTube;  
  }  
  
  @GetMapping  
  String index(Model model) {  
    model.addAttribute("channelVideos", *//* youTube.channelVideos("UCjukbYOd6pjrMpNMFAOKYyw", 10, YouTube.Sort.*VIEW\_COUNT*));  
    return "index";  
  }  
}

This slim little web controller will autowire that YouTube service defined earlier, granting us access to YouTube’s API. The parameters include:

The ID for a given YouTube channel (no vanity URLs). (Feel free to plug in your own!)
The number of videos to return for the first page of data.
The sorting mechanism to use (sort by most views)

For the tl;dr on the previous article, we already chose Mustache as the templating language of choice. It’s slim and trim, making it easy to get a lot done without keeping a reference manual open on your tab-heavy browser (amirite?)

Since the web controller is returning “index” from the index() method, you need to go down to src/main/resources/templates and create a file named index.mustache. Then start writing your own YouTube user experience:

<!doctype html>  
<html lang="en">  
<head>  
    <link href="style.css" rel="stylesheet" type="text/css"/>  
</head>  
<body>  
<h1>Greetings Learning Spring Boot 3.0 fans!</h1>  
  
<p>  
    In this section, we are learning how to make  
    a web app using Spring Boot 3.0 + OAuth 2.0  
</p>  
  
<h2>Your Videos</h2>  
<table>  
    <thead>  
    <tr>  
        <td>Id</td>  
        <td>Published</td>  
        <td>Thumbnail</td>  
        <td>Title</td>  
        <td>Description</td>  
    </tr>  
    </thead>  
    <tbody>  
    {{#channelVideos.items}}  
        <tr>  
            <td>{{id.videoId}}</td>  
            <td>{{snippet.publishedAt}}</td>  
            <td>  
                <a href="https://www.youtube.com/watch?v={{id.videoId}}" target="\_blank">  
                <img src="{{snippet.thumbnail.url}}" alt="thumbnail"/>  
                </a>  
            </td>  
            <td>{{snippet.title}}</td>  
            <td>{{snippet.shortDescription}}</td>  
        </tr>  
    {{/channelVideos.items}}  
    </tbody>  
</table>  
</body>

This page is mostly good ole’ HTML 5. But in a few places, you’ll notice some Mustache directives, denoted by the double curly bracket wrappers. {{#channelVideos.items}} is a signal to take the channelVideos model attribute (defined up in the web controller), and navigate to its items property.

And if you remember from the SearchListResponse record type, items is an array of SearchResult objects. The pound sign (#) inside a Mustache directive is a signal to iterate. Every chunk of HTML inside that directive is repeated for every entry.

Inside the directive, you’ll parts like {{id.videoId}}. This tells Mustache to grab the SearchResult object, look up its id field, and because it’s a subrecord, go into SearchId to find the videoId field.

TIP: With Mustache, it sometimes take longer to explain a directive with words than just glance and grok.

Now there are a couple show stoppers in this template that may surprise you. The first one is the fact that YouTube actually has more than one thumbnail for each video. First time I rendered this template, I spotted FOUR thumbnails. Not exactly elegant.

And here’s the rub: Mustache is known as a logic-less templating engine. While engines like Thymeleaf have support for “if” checks, and Mustache has the ability to skip over null-valued fields, anything much slicker than this isn’t possible.

It means we need to go back to the record backing structure and add more “virtual” fields. And, as you may discover, many YouTube videos have LONG descriptions. So we can ALSO add a “short description” that shortens the description field.

So let’s revamp things like this:

record SearchSnippet(String publishedAt, String channelId, String title, String description,  
  Map<String, SearchThumbnail> thumbnails, String channelTitle) {  
  
  String shortDescription() {  
    if (this.description.length() <= 100) {  
      return this.description;  
    }  
    return this.description.substring(0, 100);  
  }  
  
  SearchThumbnail thumbnail() {  
    return this.thumbnails.entrySet().stream() *//* .filter(entry -> entry.getKey().equals("default")) *//* .findFirst() *//* .map(Map.Entry::getValue) *//* .orElse(null);  
  }  
}

This updated SearchSnippet now has shortDescription, which is a record’s description field is greater than 100 characters, will return back a substring.

It also grabs the map of thumbnails and iterates over all the entries until it finds one named “default”.

TIP: To be honest, I kind of prefer having this sort of logic in my Java code, not my template!

With all this in place, we can launch our application! Visit localhost:8080, and Spring Security OAuth 2 should bounce you over to Google’s famous login page:

Yes, I have more than one Google account. (Another GOOD reason to offload such user management to Google!)

Once you pick your Google account, because you’re requesting YouTube data, Google will further ask you to pick a specific channel:

Yes, I have more than one YouTube channel that I manage in my spare time. (Again, do you really want to manage any of this?)

Anywho, pick your channel, and then…voila!

The template, rendered in all it’s glory! The thumbnails even have anchor links to open a new tab and watch the video.

Feel to play around and see what else you can glean from their API. Perhaps other ways to leverage OAuth 2?

And before you start rubbing your hands in excitement, you should know that not EVERY metric that is served up inside YouTube Studio is available through their API. So don’t be surprised if you can’t replicate every single facet. But still…the thought of building your own system to potentially test out different thumbnails for a new video AUTOMATICALLY is kind of gnarly.

Stay tuned for my next article, where we’ll delve into writing test cases and why it’s NEVER a bad idea! However, if you simply can’t wait, then check out the video below and get a taste of testing with Spring Boot!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Spring Boot 3 + OAuth 2 = YouTube!

Wed, 18 May 2022 00:00:00 GMT

Spring Boot 3 + OAuth 2 = YouTube!

One of the coolest things people reach for in building web apps, is off loading authentication to one of the three biggies: Facebook…

Spring Boot 3 + OAuth 2 = YouTube!

One of the coolest things people reach for in building web apps, is off loading authentication to one of the three biggies: Facebook, Twitter, or Google.

Why maintain a list of users when there is someone else (with considerably bigger budgets) ready to do that for you?

So as part of my latest book writing endeavor, I wanted to dig in and show you The Way. Spring Boot 3 + Spring Security’s amazing OAuth 2.0 support!

Before we can move forward, there’s a little something YOU have to do. And that’s create “an app” in Google. This is the part, where you tell Google about your app, and they give you credentials. It’s not hard. Just…tedious.

Go to Google Cloud’s dashboard.
Click on the drop down right next to Google Cloud Platform and then hit New Project. Accept the default values.
Select your new project so it’s showing in the dropdown at the top.
On the left-hand panel, scroll down and hover on APIs & Services. On the pop-up menu, click on Enabled APIs & Services.
On the list below, look for YouTube Data API v3. Click on it, then hit Enable API.
Back at your application’s dashboard, look on the left-hand panel and select Credentials.
Click on +CREATE CREDENTIALS. Select OAuth Client.
For Application type, select Web Application.
In Name, give your web application a name.
This part is critical. In the Authorized redirect URIs, enter http://localhost:8080/login/oauth2/code/google
Once these client credentials are credited, capture the Client ID and Client secret in the top right corner.
Go back to the left-hand column from earlier, and click on OAuth Consent Screen. Underneath Test User create an entry for each email address you want to login under.

This should get you off the ground. It’s a little tricky, but possible.

TIP: You do NOT have to publish or release your application to get warmed up on OAuth! You can tinker with this application where you (and only you) can access it.

Once you have your OAuth client ID and client secret, you are ready to proceed with the magic that is Spring Boot 3. To make this as fast as possible, just visit https://start.spring.io and plugin the following options:

Spring Boot version: 3.0.0-SNAPSHOT (there’s some other goodies we’ll use further down in the article that depends on snapshots!)
Dependencies: Mustache, Spring Web, Spring Reactive Web, and OAuth 2 Client

And that’s it! Just hit GENERATE, unzip, and import your newly minted Spring Boot 3 app into your favorite IDE, and let’s get cranking.

Perhaps the first question on your mind is “why Spring Web and Spring Reactive Web?” Because we building a servlet-based app (Spring Web) but taking full advantage of WebClient (Spring Reactive Web), which we’ll get to in a Spring minute.

Before we can hook into Google and the YouTube API, we first need to plugin that clientId and clientSecret we produced up above. And to do that, we need to open up our project’s application.properties file (look in src/main/resources if you haven’t found it!):

spring.security.oauth2.client.registration.google.clientId=**ClientId**

spring.security.oauth2.client.registration.google.client-secret=*Secret*

spring.security.oauth2.client.registration.google.scope=openid,profile,email,https://www.googleapis.com/auth/youtube

These three properties are the key bits that signal this as your app. Since your clientId and clientSecret are different than mine (I hope), I’ve put some stubbed out values in the first two properties in this snapshot. Just plugin your own. The third lists the “scopes” or permissions you wish to use. For this article, this is enough to load up some informata about a YouTube channel!

TIP: Spring Security comes with prebaked settings for Google, Github, Facebook, and Okta found inside CommonOAuth2Provider*. We’re using Google, given by the google portion of the property name.*

Something that comes with Spring Boot’s autoconfiguration is fashioning lots of key beans needed to make your app come alive. But in certain scenarios, it needs a little more information. One of these required pieces of information is how your app plans to manage OAuth clients.

You see in OAuth land, your app is the direct client to the service (Google) while the user is someone your app is working on behalf. Traditional client/server paradigms are trickier, and thus can lead to confusing terminology.

You need to configure a OAuth2AuthorizedClientManager bean which is responsible for handling all interactions between your users and the OAuth service, like this:

@Configuration  
public class SecurityConfig {  
  
  @Bean  
  public OAuth2AuthorizedClientManager authorizedClientManager(  
    ClientRegistrationRepository clientRegistrationRepository,  
    OAuth2AuthorizedClientRepository authorizedClientRepository) {  
  
    OAuth2AuthorizedClientProvider authorizedClientProvider = *//* OAuth2AuthorizedClientProviderBuilder.*builder*() *//* .authorizationCode() *//* .refreshToken() *//* .clientCredentials() *//* .password() *//* .build();  
  
    DefaultOAuth2AuthorizedClientManager authorizedClientManager =new DefaultOAuth2AuthorizedClientManager( *//* clientRegistrationRepository, *//* authorizedClientRepository);  
    authorizedClientManager *//* .setAuthorizedClientProvider(authorizedClientProvider);  
  
    return authorizedClientManager;  
  }  
}

This bean needs to be inside an @Configuration class, so that Spring Boot will detect it and automatically register it with the application context. With that in place, we can finally wire up a little magic!

To really sizzle, we are using Spring Framework’s support for OpenFeign (only available in 6.0.0-SNAPSHOT at the time of writing). This means we can define all the remote means of accessing the YouTube API using an interface, and nothing more! To do that, we need a WebClient, which is the reason we added Spring Reactive Web earlier in the article.

And so, we need another @Configuration class…

@Configuration  
public class YouTubeConfig {  
  
  private static final String *YOUTUBE\_V3\_API* =   
                      "https://www.googleapis.com/youtube/v3";  
  
  @Bean  
  WebClient webClient(OAuth2AuthorizedClientManager      
                             authorizedClientManager) {  
  
    ServletOAuth2AuthorizedClientExchangeFilterFunction oauth2 = *//* new ServletOAuth2AuthorizedClientExchangeFilterFunction( *//* authorizedClientManager);  
    oauth2.setDefaultClientRegistrationId("google");  
  
    return WebClient.*builder*() *//* .baseUrl(*YOUTUBE\_V3\_API*) *//* .apply(oauth2.oauth2Configuration()) *//* .build();  
  }  
  
  @Bean  
  YouTube client(WebClient oauth2WebClient) {  
    HttpServiceProxyFactory factory =   
         HttpServiceProxyFactory.*builder*(  
                   new WebClientAdapter(oauth2WebClient)) *//* .build();  
    return factory.createClient(YouTube.class);  
  }  
}

This @Configuration class has two key beans: WebClient and YouTube.

The WebClient bean definition builds a new WebClient using the root URL of YouTube’s Data API as the baseUrl. It then grabs the OAuth2AuthorizedClientManager and builds an exchange filter function out if, setting the registration id to “google”, aligning with the “google” key in our application.properties file.

Essentially, this WebClient instance will have YouTube as its base URL and will pipe all requests through this OAuth2-handling function. Because of the clientId and clientSecret registered in our application.properties, everything else will be handled effortlessly on our behalf.

The second bean definition, YouTube, takes this WebClient and wraps it inside a WebClientAdapter, then hooking it into Spring Framework’s OpenFeign feature, HttpServiceProxyFactory. This adapter makes it possible to plugin WebClient as the worker in this scenario, but there are plans to support things like RestTemplate and potentially other HTTP service utilities in the future.

Maybe you’re wondering what YouTube is? It’s the interface we’re about to define!

interface YouTube {  
  
  @GetExchange("/search?part=snippet&type=video")  
  SearchListResponse channelVideos( *//* @RequestParam String channelId, *//* @RequestParam int maxResults, *//* @RequestParam Sort order);  
  
  enum Sort {  
    *DATE*("date"), *//  
 VIEW\_COUNT*("viewCount"), *//  
 TITLE*("title"), *//  
 RATING*("rating");  
  
    private final String type;  
  
    Sort(String type) {  
      this.type = type;  
    }  
  }  
}

This lightweight interface is all it takes to start talking to YouTube’s Data API. This one has a single method, channelVideos.

The @GetExchange annotation is analogous to Spring MVC’s @GetMapping annotation. It signals that we wish to do an HTTP GET call with the /search content appended to WebClient’s baseUrl.

Tip: Feel free to visit YouTube’s reference docs to read more about the search API.

In addition to specifying the path, you can also declare arguments for the request using @RequestParam. In this case: channelId, maxResults, and order. It should be pointed out that the names in the signature are the same names in the API, ensuring we have alignment. While the first two are pure strings, the third is an enum, confining the options.

This application will nicely let you start talking to YouTube and displaying valuable content on your web page…a topic best saved for the next article!

While waiting for my next article where we plugin YouTube content right into our webpage, be sure to click the link below and get ramped up on Spring Security!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Building Spring Boot 3 apps is easier than ever!

Thu, 05 May 2022 00:00:00 GMT

Building Spring Boot 3 apps is easier than ever!

If you’re a coder, and you’re reading this, then the odds are ever in your favor that you’re building an app.

Building Spring Boot 3 apps is easier than ever!

If you’re a coder, and you’re reading this, then the odds are ever in your favor that you’re building an app.

And let’s cut to the chase. This probably isn’t some dream app YOU came up with. In all likelihood, you’re building an app for boss/customer/contract. There are hobbyists and enthusiasts. But the vast bulk of building writing software are pro developers (or those studying at Uni/Bootcamp to become pro developers.

And so, building apps is our mission. And let’s be honest. We LOVE writing code. We enjoy the taste of crafting cryptic prose inside an editor or IDE and seeing it come to life when our app runs.

So it certainly is no fun if we have to climb over several hills, crawl through muck, and dig our way through the swamp of configuration and infrastructure to simply set up an environment to RUN our app!

Back in the olden days, when I learned to write BASIC apps (I know I’m dating myself), I could write something as simple as this:

10 PRINT "Hello, world!"

And POOF, I had an app! And every language can do this. Granted, Java can be a bit clumsy to do the same thing, but it’s possible.

public class App {  
    public static void main(String[] args) {  
        System.out.println("Hello, world!");  
    }  
}

But if you want to graduate to what clients and bosses want, you suddenly enter the realm of servlet containers and what not. And strange as it may seem, Java for the longest time, required that we provide some 3rd party service to do that!

But ever since Spring Boot entered the scene back in 2014, that idea of going somewhere else on the Internet, downloading a servlet container like Apache Tomcat, installing it on every target machine, and then having to deploy your to it has been swiftly removed from our lexicon.

Because Spring Boot comes loaded with support for embedded Apache Tomcat. And by “support”, we mean, it includes it. That’s right. Spring Boot actually goes out and finds the binaries for Apache Tomcat, pulls it down, wraps it up inside your JAR file, and hands it to you, ready to unwrap like a sweet tasting chocolate egg from Easter.

So Step 1 of any app developer, find a suitable environment to run your app, is taken care of.

Maybe this should really be Step 0. Simply finding something to run your app you’d THINK would be a part of your app, right?

The next step, actually building an app, is critical. And that’s when you start to move the bits that make a website come alive. Yes, I know not EVERYTHING is a web app. But for the 99.999% of apps that are, this piece is critical.

Do make things sizzle, you want to get your hands on Spring MVC. Now back in the olden days, you know, when people trekked to Oregon via a Conestoga wagon (or maybe I’m mixing that up with playing The Oregon Trail video game?), you were better off getting a book to guide you on ALL the beans you had to configure. Spring MVC is powerful. But it require careful configuration.

View resolvers, path handlers, all kinds of stuff. The set up was intricate.

And in the immortal words of Buzz Lightyear, “Not today, Zurg!”

Spring Boot 3 does ALL OF THIS for you through the magic of autoconfiguration. By simply adding spring-boot-starter-web to your project file, Spring Boot will pull down embedded Apache Tomcat, Spring MVC, and Jackson (for JSON serialization/deserialization).

It will then proceed to wire it all together with nary a peep. It just sits there, comfortably starting at you, ready for you to write a web controller.

@Controller  
public class HomeController {  
    @GetMapping  
    public String index() {  
        return "index";  
    }  
}

That’s about all it takes to get off the ground. This light weight class contains everything needed to start rendering some HTML for the end user. This web controller signals to Spring that this is a class made for handling web requests.

The @GetMapping annotation defaults to “/”, meaning it will map HTTP GET / calls onto this index method. And the method itself will return the name of a template.

That’s right. You’re not QUITE done. You indeed need to craft a template. But we haven’t talked about templates. Because the thing is, Spring tries to pick reasonable defaults. And up until this point, it has. The assumptions include things like:

embedded Apache Tomcat
root servlet path of /
local port of 8080

But Spring leaves it up to YOU to decide what templating engine you desireth. There are many to pick from. For something lightweight and simple, use spring-boot-starter-mustache . For something more sophisticated and powerful, I’d use spring-boot-starter-thymeleaf .

Add the dependency of your own choosing to your project file, and BAM! Spring Boot will autoconfigure that as well. No need to register Mustache view resolvers or other stuff and nonsense. Instead, you jump to crafting a template underneath src/main/resources/template/index.mustache . (Your IDE probably even supports Mustache!)

Slide in a little HTML and all ready to go!

<h1>Greetings Spring Boot Learning fans!</h1>  
<p>  
Spring Boot 3 is your ticket to less setup and more  
writing code that actually moves the needle for the projects  
you're working on.  
</p>

What is Step 3? That would involve building JSON APIs and more! But this article is already getting a little long. Click on FOLLOW and catch my next post!

In the meantime, if you simply cannot wait, check out this video below where you can get a deeper glimpse into the power of web apps with Spring Boot 3!

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

What if I wanted to reproduce a build?

Sat, 05 Mar 2022 00:00:00 GMT

What if I wanted to reproduce a build?

There is a movement afoot in the open source world. It’s called reproducible builds.

What if I wanted to reproduce a build?

There is a movement afoot in the open source world. It’s called reproducible builds.

What exactly is that? And why would we need it?

To answer the first question, it may be better to answer the second question. When it comes to delivering software, there can be a lot of steps. And I’m not just talking about compiling and packaging.

I mean getting it to its destination. I’m old enough to remember building an app, burning it to a CD, and walking into a production room that had NO NETWORKED CONNECTION to the outside world. This CD was the only way to bring in a new release of software.

And that was by design.

With these types of restrictions, it becomes easy to run checksum reports on the CD, on the binaries in the production environment, and any steps along the way. You can verify that what is running in production IS THE EXACT SAME THING as what you built.

And that was stuff I did at my old and haven’t touched in years. Because that was government contracting and I departed that world when I joined the Spring team back in 2010.

Open source systems need reproducibility as well. But I’ve not seen anyone clamoring for a checksum report since. I haven’t run into a customer that wants a complete snapshot of all the source, burned to a portable drive, with instruction on how to rebuild from scratch. Offline.

Oh wait. I have.

Before I joined the Spring Data team, I worked with a customer that had paid for the option of having every single tag of the system captured and stored away with the option to rebuild devoid of the outside world.

When my manager handed me that task, I kind of blinked.

“Everything?” I asked.

My manager nodded yes.

“Built offline?” My mind was struggling to accept this task.

My manager continued to nod.

Ever cloned a repository and built every tag? Using maven, but in offline mode?

Yeah, that last one took me a LOT of experimenting and tinkering. (You essentially build it ONLINE, but then switch on a couple flags, pointed at your local maven repository cache).

Anywho, once I figured that out, loaded it all onto a portable drive, I shipped it off to IronMountain to be added to their vault and closed that task up.

Maybe that sounds a little crazy to you. Well, that’s because it is. At least for 95% of the situations you’ll run into.

But there’s valid suggestion that buried in that task is the need to go to any tag, check it out, build it using the same tools as always, and run it. Perhaps in a different way? On a different machine? With different parameters? Or perhaps to replace the server that just got fried by the tech who accidentally switched it from 120V to 240V power during a routine maintenance task?

In these types of situations, people are willing to pay for reduced risk. And introducing software changes to systems that have been running stable for months or years often isn’t acceptable.

We try to hedge risk with new-and-improved continuous integration and continuous deployment systems. But the world still needs the ability to reduce risk and run stable, secure builds.

With the security issues popping into headlines, log4j being the latest, the world still needs to know that they can move from one stable release to another through processes that are controlled and not subject to individual whim.

CI systems have made such release processes a lot more automated and a lot more scaleable. Sure am glad I know longer turn over tags to some CM person that literally had to walk around and get physical signatures from department heads before handing me a CD to carry into production.

But that doesn’t mean we can’t do better with reproducible build environments, reproducible version of software, controlled keys, and proper checks.

Sure you can debate whether a JAR file built six months later using the same version of Java, source code, and Maven is REALLY the same. After all, the timestamp on that JAR file along with dates injected into its metadata may vary. But if you crack it open and run a checksum report on every individual class file, you may be able to prove you have the exact same logic and data as the first version.

And that breathes stability and confidence.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

What does it take to SUCCEED as a pro Spring Boot developer?

Sat, 12 Feb 2022 00:00:00 GMT

What does it take to SUCCEED as a pro Spring Boot developer?

Do you dream of becoming a professional Spring Boot developer? Find out EXACTLY what tools you need to make it a reality!

What does it take to SUCCEED as a pro Spring Boot developer?

I posted a poll to my YouTube channel’s Community tab a couple months ago asking “What best describes you?”

The options sought out whether the reader was studying coding, a fledgling developer, or a seasoned pro.

Since over 2/3 of the audience responded to being relatively new to the field, I figured this was the perfect time for a series of videos sharing some of MY successful tips on what being a pro coder was like!

The first thing I wanted to tackle was what kind of tools and practices you needed to take on to make it a reality…

The next idea I had penciled out on my list of pro developer skillsets was how much time I spend simply communicating with fellow developers and colleagues.

This doesn’t just mean email or Slack.

In my 24-year career, I’ve had to learn how to communicate ideas, ask questions, and go hunting for information.

While I was working on this video series, I had actually run into a coding issue that threw me for a loop.

I had run into a tricky situation with Spring Data JPA, and while in the thick of it…realized THIS would be a GREAT addition to this video series!

Debugging involves more than just clicking on the IDE’s “bug” icon. There are tactics that you NEED to LEARN to solve problems!

If you know ANYTHING about the Spring portfolio, it’s that we all like to polish the code.

I mean polish, polish POLISH!

That is, we like to get things working, then clean it up so it is as clean and consistent as possible for future readers…even if that is for us!

I couldn’t continue this series without carving out time showing exactly WHY this is so valuable and tips and tricks YOU can take to give your code extended longevity.

(Getting Morgan Free to do a voice over was tricky…but worth it!)

My series of lessons on what it takes to be a pro coder would all be for naught if I didn’t give some tips on how interview.

I’ve been involved in MANY hiring decisions over my career, and it only makes sense to help YOU know the sorts of things people are looking for when they discuss a potential candidate!

While I had new and fledgling developers in mind for these videos, everything in there is applicable to the most seasoned veteran. Today!

And if it’s easier for you, you can watch them all from within a single playlist.

LET ME WATCH IT ALL AT ONCE

With that series done, I’m already drafting my NEXT video series: Building My First Spring Boot App

(BTW, I’m soon going to share the actual scripts and filming process with the PREMIUM members of my group.)

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

What is the good, the bad, and the ugly of CI?

Sat, 05 Feb 2022 00:00:00 GMT

What is the good, the bad, and the ugly of CI?

CI has lots of nooks and crannies. What does it take to pull things together that best serves you?

What is the good, the bad, and the ugly of CI?

If there’s one thing I do, it’s jumping in feet first when I find something I like. A keen example is: Docker.

I don’t mean everything in Docker. Quite the contrary. I find the usage of Docker for development actually gets in my way. No, I’m talking about using Docker as a core piece of building any continuous integration or CI solution.

I’m a big fan of building every single commit pushed to github. And by “building”, what I mean is, “test against a matrix of compatible profiles, publish the artifacts to a repository, and generate documentation”.

The Problem

The Spring portfolio has a strong reputation of backward compatibility. To ensure this on the projects I manage (Spring Web Services, Spring Session for MongoDB, and Spring HATEOAS), I need to test each version against multiple versions of the Spring Framework, Spring Security, and Spring Data.

This was a chore nonetheless when we used the old CI system (Bamboo by Atlassian). You went into a web page, configured all kinds of stuff, then hoped for the best. It sort of worked. But every time you wanted to make a change, you had to revisit the web site and learn it all over again.

Want to upgrade Maven? Contact the sysadmin.
Want to install a different version of Java? Contact the sysadmin.
Want to use a particular OS? Contact the sysadmin.

See the pattern? Trying to do something edgy, like testing against multiple versions of the JDK was out of the question. No way do any of us have the time for that.

Several Solutions

This is the reason I wholeheartedly embraced Travis CI years ago when it emerged. Visit their website and enable your project. That’s it! All you must do is add a single file with build details to your code base, and you’re set.

With a huge growth in Travis, other similar CI systems emerged. One that really caught my fancy was CircleCI. The biggest difference was your ability to specify the Docker container your builds would run inside. That meant pulling down images from Docker hub, not just what the CI company offered.

That came in handy when I spotted minor versions of Java breaking Spring Web Services due to tiny wrinkles inside the JDK’s SOAP libraries.

That’s when I realized Docker was the ticket to CI nirvana. Docker combined with the Maven wrapper would absolutely obliterate those CI configuration issues.

The Spring Data release train has grown to 15 officially supported modules. Team leaders Oliver Drotbohm and Mark Paluch had built a tool to automate releasing this beast, but a small gap had grown huge — the Bamboo jobs set up long ago to monitor each module couldn’t keep up.

There was no way to spot, for example, that someone’s patch in Spring Data Commons would break Spring Data REST due to a change rippling through Spring Data JPA. Discovering these sorts of issues on the day of a release was no way to operate.

A Challenge

So Oliver put out the call for someone to attack our CI system. He didn’t care what the solution was, just that it had to not be rocket science so we all could handle it.

I raised my hand. This sort of server-side, infrastructure honing is one of my “things.” And so for several months, I hammered away at building a pipeline.

Did I mention pipelines? Historically, CI systems used to be these mammoth single-job runners. But certain shops (cough Netflix) raised the bar by defining pipelines where smaller tasks would get chained together. And so other CI systems began defining pipelines. CircleCI introduced one that I used for certain things. But it was clunky and hard to reason what was happening.

That’s when I discovered Concourse. Oh my, talk about an elegant solution. Everything is boiled down to a job with a set of tasks. And every task is a Docker-managed script with inputs and outputs. You chain together a series of tasks where one task’s outputs are the next task’s inputs. VERY easy to reason about.

I rapidly added parallel jobs that would compile different profiles against different versions of Java. That, my friend, was the ticket toward creating confidence.

But there were still a few wrinkles. The Spring Data team must publish branched artifacts without stomping on released ones. Anytime an official branch is pushed to github, we needed a pipeline to run. And Concourse flat out could NOT handle that. You configured it to monitor one and only one branch.

Revisiting an Old Enemy

So after trudging through thick and thin, I had to put Concourse on the shelf and turn to my old nemesis: Jenkins.

Jenkins is arguably the oldest CI system you’ll ever find. And it has a history of big, clunky configuration screens with pages and pages of options. This, to me, was worse than Bamboo!

But Jenkins in the past couple years had apparently adopted a pipeline approach. And had adopted a Groovy-based DSL. And (drum roll) had introduced 1st class support for Docker.

Jenkins also has about 3–4 different dialects to configure a job. I sought out the purist, simplest DSL approach I could find. I had to scrap certain features. But the idea was to make a given version of a given Spring Data module as simple to read as possible. So my teammates would embrace it fully.

And so I have finally come to accept that the true solution for CI is Jenkins (at least for me). Why? For these key reasons:

Every stage run inside a Docker container (except actually building containers).
Pipeline captured as code in the project.
Ability to run certain stages in parallel with conditional settings.
Easy to read and comprehend, hence easy to alter as needed.

If you ever bump into me at a conference, be sure to say “hey!”

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

I have a pair of 8TB NAS drives[1].

Wed, 02 Feb 2022 00:00:00 GMT

I have a pair of 8TB NAS drives[1].

Under the hood, it’s basically a Linux server running LVM.

I have a pair of 8TB NAS drives[1]. The Synology device itself comes with software to manage it over SMBFS. You can use standard RAID levels, but I’ve adopted SHR-1, Synology’s enhanced variant of RAID 5.

Under the hood, it’s basically a Linux server running LVM.

[1] https://amzn.to/3ARqhaH

You have failed me for the last time, Time Machine!

Sat, 29 Jan 2022 00:00:00 GMT

I recently purchased a Synology DS420j RAID chassis.

The TL;DR is that this beast is a 4-bay RAID chassis loaded to the hilt with tools to make building redundant disk arrays a snap.

The first thing I did was point my MacBook Pro as well as the Mrs.’s newly purchased M1 Macbook Air. Time Machine backups at the shiny new memory-alpha NAS.

(Yes, I assigned it the hostname of memory-alpha. Welcome to Geekland).

And promptly forgot about it.

And that was a mistake.

^ — — — me, force-choking Time Machine

Guess what?

A month later, the Mrs. couldn’t find a Keynote presentation she given last fall to a virtual writers conference. A talk she is slated to present later this year.

Nothing via Alfred. Nothing via Spotlight. All our tools couldn’t find this one little presentation.

“Enter Time Machine,” I said! And so we did.

And so we couldn’t find anything. Or at least we couldn’t find anything PRIOR to the setup of memory alpha.

You see Time Machine works through the magic of hard links.

Hard links are files that when copied, only copy references. Not the contents. Copy a file 50 times…still only one “copy” of the file. But 50 different records in 50 different folders. Hence, nicely structured but without wasting any disk space.

Hourly backups running on top of a RAID chassis built on Linux Volume Management, and you are in backup Nirvana.

That’s what is was SUPPOSED to be.

The Mrs. was giving me the Evil Eye, consigning herself to the fate of having to recreate a slide show.

And I was giving Time Machine the Evil Eye for failing what was supposed to be simple.

Only it started back with cold, lifeless disregard.

Until the Mrs. pulled out her previous solid state external drive. “What about here?”

I snatched it from her hands and cried “maybe?!” with exuberance.

(Okay, it wasn’t QUITE like that. But it adds a little action ehh?)

After plugging it in and attempting to navigate THIS thing via Time Machine (which also failed), I finally expanded it’s folders and found a small folder named “01–26–2021”.

After digging around in this ancient folder, we managed to unearth a copy of that Keynote deck. Apparently the file had gotten saved into the iCloud folder INSTEAD of “our” folders, hence never making the journey from her old Mac to the new frontier.

I shoved a copy into her hands, ejected the solid state backup, and promptly went to sulk over the misery Time Machine had befallen me.

“Time Machine…I thought we were best friends!”

Because I also wondered what other files were missing because it this flub. And how would we find them?

I started googling for alternatives.

Turns out that “time machine alternatives” yields about a bazillion articles. And one pointed me toward Carbon Copy Cloner. I promptly downloaded the trial version and fired it up.

The UI was…amazing. The thing took a peek at my laptop’s hard drive and instantly recognized characteristics I had never known of. And was ready to leverage them. (Look up Apple APFS snapshots if you’re in the mood.)

I quickly created a task to backup the DATA portion of my hard drive into a specific folder of the NAS. I scheduled it to run hourly BUT DON’T WAKE UP THE MACHINE. And then I tuned it to exclude Dropbox and VMware OneDrive.

And I clicked “Start”.

Waking up the next day, it appeared to have finished that backup around 1:30 AM…

…and complete several more snapshot backups every hour since.

Going through it’s UI, I was able to “View in Finder” the backup made at 3:30 AM.

Wow.

THIS Is what Time Machine is SUPPOSED to be doing!!

24 hours haven’t even passed and I’ve already defined a similar task to backup my machine to my 2 TB Passport external drive. (Redundant backups FTW!)

I also created a task that backs up the “Movies” folder from that 2 TB drive to the “Movies” folder of our glorious RAID chassis, ensuring NOTHING supporting our YouTube channels is lost. And it runs ANYTIME I plug in that external drive.

I even ran a one-time task that pulled that old Time Machine backup from the Mrs.’s external SSD drive and stuffed it onto memory-alpha.

That way, if she DOES need a file from yesteryear, there is a snapshot ready, willing and able…located on our already-hard-at-work RAID chassis. Available to search.

And I plan to backup her data both to the RAID chassis as well as her external drive. So she can take it with her whenever needed.

THIS is what backups are meant to be. Set it and forget it. And make them easy to consume.

— Greg

Do you want to get a free tech e-book, be alerted to my discounts, and get even MORE content about SPRING BOOT? Then SIGN UP FOR MY NEWSLETTER.

Arrow functions are the first/best feature of ES6.

Fri, 21 Apr 2017 00:00:00 GMT

Arrow functions are the first/best feature of ES6.

The thought of writing THIS one more time…

Arrow functions are the first/best feature of ES6. It’s the #1 reason I now setup babel.js for any JS-based project.

The thought of writing THIS one more time…

var self = this  
toolkit.do(function() {  
    ....self...  
})

…makes me shudder!

toolkit.do(() => ...this...)

Isn’t that easier?

And once you take this on, the rest flows.

Pro Coder

Why hello there Substack!...

Claude Code is my new best friend...

Liquid Glass on iOS...

Keeping up with the times?

Ever taken up a hobby?

Are you optimizing too much?

I have a new book ready for you...

Do you backup your systems?

I’m leaving social media...

Footnotes

Teaching software is harder than writing it

Been hacked? I have.

To AI or not to AI, that is the question!

So what IS AI good for? And what should we NOT be using it for?

What about using AI at work?

Is that it? Using a tool to skip over the beginning phase of something?

Are you ready to commit yourself to being a pro coder in 2025?

We cannot stop and start as we wish.

We must learn all that we can learn

We must hone our craft with our tools

Making rookie mistakes

I hate New Year’s Resolutions…

But NOTHING is drawing my attention this year!

What are you thankful for?

Do you code for profit…or for fun?

Something NONE of us need!

The Arrival Syndrome

Want to hear another story?

Returning to first principles…

Most over engineered solution EVER…

Thank you, Spring!

I survived the first three weeks…

1. First Day

2. First week

3. First month

4. First six months

As a pro coder, it’s ALWAYS valuable to collect skills

“How do you deal with imposter syndrome? Asking for a friend… really.”

The most important thing no one discusses in engineering!

“Can you really wait for that $100/year payment? I’d be willing to pay you $400 right now! It’s your money. Use it when YOU want it!”

Docker — What is it good for?

Docker — What is it good for?

Docker — What is it good for?

What is a pro coder’s most important tool?

What is a pro coder’s most important tool?

What is a pro coder’s most important tool?

Don’t be afraid to take a shot!

Don’t be afraid to take a shot!

Don’t be afraid to take a shot!

Have you said “thank you” to yourself lately?

Have you said “thank you” to yourself lately?

Have you said “thank you” to yourself lately?

I have to admit…Spring Data is ACTUALLY my favorite Spring project!

I have to admit…Spring Data is ACTUALLY my favorite Spring project!

I have to admit…Spring Data is ACTUALLY my favorite Spring project!

Now that I think about it, Spring MVC may be my favorite Spring project!

Now that I think about it, Spring MVC may be my favorite Spring project!

Now that I think about it, Spring MVC may be my favorite Spring project!

2 — Easy to build simple web flows, scale up to complex problems as needed

3 — Integrates tightly with Spring Security

4 — Works nicely with template engines, especially Thymeleaf

5 — Doesn’t get in your way when solving problems

Actually, Spring Integration May Be My Favorite Spring Project

Actually, Spring Integration May Be My Favorite Spring Project

Actually, Spring Integration May Be My Favorite Spring Project

1 — Messaging Paradigm with POJOs

2 — Support for Multiple Protocols

3 — Enterprise Integration Patterns

4 — Embracing Simplicity

Why Spring Security May Be My Favorite Spring Project

Why Spring Security May Be My Favorite Spring Project

Why Spring Security May Be My Favorite Spring Project

1 — Sensible Defaults

2 — Customizable User Sources and Access Rules

3 — Extensible Authentication and Authorization

4 — Custom Extensions

5 — Integration with Templating Engines

6 — Spring Boot Compatibility

Are test fixtures worth it in your automated testing strategy?