TIL: Caching Trolls You When Serving Images With Unchanged URLs

Oh, boy! It took me like 3 hours to figure this out.

Here’s the thing: I had a CRUD app with Blazor. In the Update page, I could change images—let’s say, a hinge and other parts used to build a closet. Nothing fancy.

The problem?

After updating the image and redirecting back to the List page, it still showed the previous image. Whaaat?! The API endpoint did update the image.

Since I can’t show you the real code, for obvious reasons, here’s a little corner of the app,

It only worked after pressing F5, to reload the entire page.

I tried to solve it by forcing a reload when redirecting from the Update page back to the List page. Like this,

private async Task OnSaveClicked(IBrowserFile? image)
{
    var response = await MyHttpService.HttpPut<SomePutResponse>("api/my-cool-endpoint", _someUpdateRequest);

    if (response != null && image != null)
    {
        await MyHttpService.HttpPostFile<SomeImageResponse>("api/another-cool-endpoint", image);
    }

    NavManager.NavigateTo(Index.Route, forceLoad: true);
    //                                 ^^^^^
}

But sometimes it still showed the old image. Arrggg!

After googling for a while, this SO answer saved my day. It was the browser trolling me all that time.

OK, the API endpoint powering the List page returned a public URL of every image, served from the same server. Every image file was named after the related object ID, something like /public-files/acme-corp/my-cool-object/123.png

Even though the backend changed the images, their URLs were the same. And the browser didn’t notice anything new, so it kept showing the same image, without requesting it from the server.

The solution?

Append a timestamp to every URL. Audit fields are helpful here…I ended up appending the modification date of every image. Like this,

public string GetPublicUrl(string path)
{
    var publicUrl = $"/files/{_companyName}/{path}";
    var modificationAt = GetLastModificationDate(Path.Combine(_someBasePath, path));

    return $"{publicUrl}?ts={modificationAt:HHmmssfff}";
}

private static DateTime GetLastModificationDate(string absolutePath)
{
    try
    {
        var file = new FileInfo(absolutePath);
        return file.LastWriteTimeUtc;
    }
    catch
    {
        return DateTime.UtcNow;
    }
}

Kudos to StackOverflow. Caching trolled me. Again. Total facepalm!

10 Tips to Write Posts (Technical or Not) People Can't Stop Reading

I’ve written 321 posts.

In fact, this is my post number 322. Over five years ago, I wrote my first post. Well, “post” is a strong word. It was a word vomit. I still keep my first post unedited to remind me how I started.

I only wrote when I thought I had something to say. It was once every full moon when I started. Then it was every other week. Since Nov 1st, 2024, I’ve been doing it daily. I already passed the 100 daily posts mark. My next goal: the 200 mark.

My blog is my time capsule. And it’s done more for me than a portfolio. These days, it’s part of my routine to be healthy.

All that to say, I’ve learned a thing or two about blogging and writing. Mostly, after lots of trial and error. And if you’re starting out, here are 10 quick tips for you:

#1. Write descriptive headlines: “How to do X with Y in order to Z” works perfectly fine for most of your posts, technical or not. Or steal your headlines, like an artist.

#2. Ditch long intros: Go straight to your main point. Don’t worry about introductions at the beginning. I wanted to jump straight to #1 in this post. But in a moment of inspiration, I wrote that introduction to “prove” I know what I’m talking about.

#3. Start with a 1-sentence paragraph: OK, if you decide to write introductions, start your posts with one sentence. Imagine your first line is like an extra headline. See what I did in this post. I learned this trick from my first writing class.

#4. Use subheads: Use h2 and h3 tags to break your post into parts. These tags help readers skim and digest your post. And this helps SEO bots understand your post. If you’re writing a how-to guide, use one subhead for every step/lesson/point of your post…You know what, I could have used one h2 tag for every point in this post.

#5. Write shorter paragraphs: Shorter paragraphs and sentences make your posts easy to digest.

#6. Use simple words: A post isn’t a New York Times column or a school essay where you’re chasing an A+ or a 10.

#7. Deliver your message fast: It goes hand in hand with #2. Your headline is a promise. Fulfill your promise in your post body. If you’re writing how to fix the air conditioning of your car, tell that in your post. Don’t go on tangents. Leave those tangents to write more posts. Give something and give it fast.

#8. Avoid meta sentences: I blame writing in schools and their mantra: “tell readers what you’re going to tell them, tell the thing, then tell what you just told them.” Arrggg! Don’t do that. Don’t write “now, let’s cover how to…” or anything like that. I used to do that after every section. See #7.

#9. Write for 1 person: Next time you sit down to write, picture yourself explaining it to only one person: a friend, a coworker, or even your dog. It will give you the right tone to use and the right points to cover in your post. For example, again if you’re writing about how to fix the air conditioning of your friend’s car, you don’t have to explain what a car is to him. He already knows it.

#10. Avoid summary-like conclusions: Ditch conclusions the same way you ditch intros. And please avoid regurgitating everything back in a conclusion. Instead, ask your readers to do something after reading your post or promote other posts. Again see #2, #7, and #8.

I could give you more tips on SEO, but let’s keep it like that. If you followed these tips, especially #1 and #4, search engines will like you. Search engines love when we write for humans.

Keeping a blog helped me skip hiring lines the last time I was looking for a job. I showed my blog during the interview and the process went faster from there. No more rounds of interviews after that.

You don’t have to be an expert to write. Write to become one. But, please don’t start by writing your own blogging engine. That’s where blogging goes to die.

Always Automate Code Style (and Other Best Practices)

At one of my previous jobs, there was a new guideline:

Format all SQL queries using right-aligned style.

The problem?

During a pull request review, one or two managers, who didn’t code anymore, decided on that guideline.

And the next day, without telling anyone else, that guideline was set in stone and enforced throughout the codebase. Guess what was the most common comment on code reviews since then? “Please properly format this SQL query.”

Lesson: Always share new guidelines and coding style changes with the team, especially if you’re planning on enforcing them on all projects. Just send an email or a quick Slack update to make sure everybody is on the same page. No need for an all-hands meeting.

The other problem?

There was no clear way to format those files. Should every coder do it by hand? Using their favorite tool? Or using an “official” tool?

Being a lazy coder, I didn’t want to format my files by hand. Copying SQL queries from Visual Studio, going to a tool page, pasting them, and copying them back was too much effort—I told you I’m lazy.

Computers are designed to do boring and repetitive work. Formatting files definitely fit that description. In one afternoon of frustration, I hacked a Git hook to format my SQL files and shared it with my team lead.

Lesson: Make sure to have an automated and widespread tool so anyone can follow new guidelines and coding style changes as easily as possible.

We wasted so much time on code reviews, asking people to format those files, waiting 24 hours to finally merge things.

For better or worse, my next project at that job didn’t involve SQL. And months later, I was let go…so I don’t know what happened to that guideline or to my tool.

9 Must-Know Tips for Your Next Trip or Vacation

I’m far from collecting enough passport stamps for a world tour.

But, I’ve traveled abroad more than once. Thanks to coding, I saved enough to visit Spain and France before the pandemic. It was my final exam after studying French for a couple of years.

Here are 9 tips I’ve learned from those travels:

1. Always pack a jacket: Last time I was on vacation I visited a tropical country. Of course, I only packed shorts and swimsuits. But once I was thousands of feet in the air and inside a pressurized cabin, I was freezing.

2. Pack underwear and cleaning essentials in your handbag: In case, your baggage is lost or delayed. Better safe than sorry.

3. Visit your favorite destination first: For my travel to France, Paris was the last city I visited. By the time I got there, I didn’t have the energy to walk for hours and visit museums. I missed a lot of must-see places. And I didn’t truly enjoy the ones I visited. I was tired. Next time, I’m visiting my favorite destinations first.

4. Schedule a free day to wander around, sit in a park, go to a cafe, or simply do nothing. Often, we travel to rest and unplug but we end up exhausted from hours of walking, connecting flights, and museums.

5. Start with a walking tour: Often, they’re free. Or you can leave a tip at the end of the tour. And you have the chance to ask your tour guide for places to eat and hang around where locals go.

6. Bring eye masks and earplugs. Perfect for sleeping on planes or trains…And hostels can get loud sometimes.

7. If you’re crossing the Atlantic, from America to Europe, start your flight in the evening: This lets you get some sleep on the plane and arrive at your destination with daylight. It reduces the jet lag.

8. Wear pants that don’t need a belt and shoes without laces. It will save you a lot of time at security controls.

9. Keep your passport in your bag and only take it out at security checkpoints. Often there’s some stigma associated with our country of origin. I bet the first thing that comes to mind when you think of Colombia isn’t Encanto, just like Coco when you think of Mexico—both Disney movies. Keeping your passport in plain sight invites extra scrutiny from security personnel walking around airports.

10 Tips Every New Coder Should Know to Succeed

I remember the first day of my first coding job.

It was over 10 years ago. I wore a long-sleeved shirt and fancy shoes. I brought a CD to install Visual Studio 2010. Yes, a CD. And yes, Visual Studio 2010.

After getting my corner and shaking hands, someone handed me a book. It was a book about SQL Server 2008. I read and googled for a couple of weeks until I got my first task. I was coming from Java and I needed to know C# in a few days.

My first task was to port a legacy ASP.NET WebForms app into a desktop app. I wrote Java code with C# keywords.

I had to figure out lots of things. Coding was the easy part. Everything else was the difficult part.

If you’re like me over 10 years ago, here are 10 tips you should know to succeed as a new coder—this is what I wish I knew back then:

1. Learn one basic coding skill

Learn to do one thing and do it well.

If you’re a frontend developer, practice turning a mockup into a webpage and calling existing API endpoints to make it work. Use React or Angular or whatever is the shiny thing these days.

If you’re a backend developer, practice writing API endpoints that validate user data, put it into a database, and read it back.

You’ll spend most of your time on those types of tasks.

2. Ask for help

When you get an error message (it will happen a lot), don’t simply send it over to a coworker.

Take the time to solve it on your own. Or at least, try. The first step? Google the same error message. Forget about AI for now. Only then, if you’re still stuck, ask a coworker, showing what you found and tried.

You’ll get more help if you show you tried rather than simply saying “help me.”

3. Ask questions

You’ll have to ask lots and lots of questions. Like a lot.

For me, everything was new at my first job. The coding part, the business domain, working on a corporate job…

Always ask why. Why this task? What’s the real problem? And why solve it now?

It’s better if you annoy people with questions than with mistakes from not asking.

4. Find good role models and mentors

A good mentor will make a huge difference in your career.

But don’t simply ask, “would you like to be my mentor?” Everybody will tell you no. Being a “mentor” implies commitment, most of the time, for free. Find alternative ways to be mentored.

Often, books are your best mentors too.

5. Be comfortable with the struggle

At the beginning, it sucks.

You feel like you don’t know anything. Everybody around you is way more competent. You go to bed while leaving something broken to wait for you the next day.

Take it step by step. It gets easier with time and effort. And the feeling of not knowing anything never goes away. You simply change the things you don’t know now with others.

Trust the process. The struggle is part of it.

6. Learn the right things at the right time

At the beginning, I tried to learn about everything at once.

I was into Python, learning C#, reading Clean Code, and keeping up with PHP…Lots of passion, without direction.

Coding isn’t simply one skill, but lots of subskills: language syntax, problem solving, databases, development practices…Tackle them one by one. Only move to the next skill once you understand one enough.

Remember you don’t need to know everything. And you don’t need to know everything at once either.

7. Learn to look for your own answers

University, bootcamps, and YouTube won’t teach you everything you need to know.

You have to read and study a lot. Like a lot! Nobody taught me about C#, version control, or unit testing…and on and on. I had to study them on my own.

Being a good coder also means being a lifelong learner.

8. Be willing to learn and follow instructions

As a new coder, you stand out by showing that you’re able to learn and follow instructions.

For example, when you ask for help (See #2), do or at least try doing what you’re being told.

9. Introduce yourself, network, and write CVs

It’s hard to land a job when you have almost 0 hours of flight time.

You don’t know many people. You don’t have much to show off on your CV. You have to resort to networking. Find clever ways to get an introduction.

Back in my day, I got my first job because I knew someone who knew someone. These days, I’d try starting with social media. Go with LinkedIn if you don’t know where to start.

And when you get an introduction, say you’re starting out and you’re willing to learn. See #8.

10. Real coding isn’t like University or bootcamps

In real life, often there’s no documentation, standard procedures, development workflows, or software methodologies. Or it’s more like a zombie methodology disguised as Agile. And on top of that, the existing code is a mess. Welcome to coding!

My last piece of advice: once you’re in a job, forget about the job description you read before joining. Learn and absorb everything you can, don’t be afraid to experiment. Embrace every opportunity to grow and challenge yourself. When your current role becomes second nature, it’s your signal to move one for new challenges. Never stop learning.

To read more, here’s a free mentorship session in 8 lessons and four lessons I wished I knew before becoming a Software Engineer.