Harry Winser.com

Well well well, 2025 is over. What a year it’s been. A lots happened. A lots changed. And a lot has stayed exactly the same.

Lets take a self indulgent look at 2025 from a personal perspective, but also look back at those goals and predictions I made in my Looking ahead into 2025 post.

Personal

I wrote last year:

So I’d like 2025 to be about moving forward. Using the amazing foundation I have with my partner, my home, and my friends, I want 2025 to be about taking “The next step”.

And while I can’t say this about my predictions and goals, I certainly have taken some bigs steps this year.

First, I asked my partner to marry me (she said yes);

We were in Rome for my soon to be Mother In Law’s 60th birthday. On the one day we had for ourselves, it was hammer it down with rain

But we walked to Fontana dei Fauni, and with only the geese to keep us company, I popped the question.

On the topic of marriage, I’ve always had this weird line from an unlikely source in my head:

You said a husband’s gotta put his wife before himself

-Spider-Man 3

Yep, that’s a Spider-Man quote.

It’s all about is being able to put someone else first. I’m not talking about little things, I’m talking BIG things. That might mean being willing to give up a promotion, or not dropping everything to live in another country. And when you meet the right person, you’re willing to do this. Though, if you meet the right person, they’re also willing to do these things, and so together you make the big things happen. You’re not trapped, you’re not contained. You’re moving together, each putting the other first.

And boy is it a great feeling to have that!

Since getting engaged, we’ve also been trying to buy a family home. My little cottage in Ivybridge isn’t going to cut it moving forward. And while we’ve found “the house”, we still haven’t quite got there yet. All fingers and toes crossed for the move in 2026.

From a career and work perspective, I’m still with Edozo. The biggest change there is that I’ve negotiated Friday afternoon off to work on some personal projects. I’m incredibly excited to show off what I’ve been working on. these side projects have sustained me through some of the more “boring” work periods, as well as exited me for the future. Hopefully will have more to write about these projects in the new year.

As for my goals and resolutions I set for 2025… I rather failed. I didn’t write a blog once a week (or even once a month), and I’d argue I have played even less guitar than I did in 2024. Though, with my side project becoming a major focus, and also being part of Panto in December, I certainly didn’t want for creative projects.

Previous predictions

So, last years predictions can be summed up as:

1. A.I. will fizzle out
   • I was totally wrong here. Swing and a miss. It’s gotten larger and more dangerous this year than I think most folks predicted. So much so, even Sam Altman thinks we’re in a bubble.
2. Trump Crypto bounce
   • I’d say i was right here; there was a large bounce and hit it’s peak in the Summer. It’s now a fair bit down as of time of writing
3. Apple won’t release anything exciting
   • I think I was wrong here. Liquid Glass + iPhone Air were at least interesting, if not exciting.
4. Starmer will still be in Number 10
   • I was on the money here. Though, the sharks have been circling…
5. Reform will consume the Conservatives
   • I’d give myself half a point. The Conservatives haven’t totally imploded yet, nor have Reform swallowed up all of their members / MP’s. It seems a little like the Tory’s are biding their time, while Reform have hit a bit of a ceiling.
6. Trump and Musk will have a falling out
   • This was an easy one to get right, and oof was it a falling out!

3.5 out of 6 predictions. Not bad if I do say so myself.

What I’m thankful for

I wanted to round out this post with an incomplete list of what I’m thankful for in 2025. The first and obvious one is my future wife. She brings me joy every day, and I look forward to what our future holds as we step forth together.

I’m also thankful for my job. The tech industry has been all over the place this year. I know a fair few folks who’ve lost their jobs. I’ve been at Edozo for 6 years, so I know and shape the lay of the land. It’s a real honour to work with such talented people. But it’s also a job that’s allowed me to focus on things outside of work, which is a weird “thank you”, but it’s true. I’ve been able to put energy into side projects, as well as Panto.

I’m thankful for my little cottage. It’s been great fixing it up, and making it a warm place of safety. It’s brought me a lot of joy. I’m sad to be selling and moving on though. This place was the first “home” I’ve had since I was 18. A place that felt like home. I’ve not felt homesick in years. Yet, this year I felt it. This house has taught me what “settling down” could feel like and I gotta say, it’s pretty great.

Finally, I’m thankful to all of my friendships. Those friendships come in so many different forms. From familial ones, to those that feel like family, to those that are based around a passion like music or technology. I’m thankful for them all.

A farewell to 2025

And with that, it’s time to say goodbye 2025. It’s been a… interesting… year. Lots of ups and downs. Bring on 2026!

Today i want to talk about exception handling in Java. I know a lot of folks have shared about this in the past, but I screw it here’s one more voice. This blog won’t be about if I think they’re good or bad in Java (it’s a complex subject, and ultimately they aren’t going anywhere), but instead how and where i think they should be used.

A refresher

For a quick refresher lets go over the two main types of exceptions in Java:

• Checked exceptions - any exception that must be caught or declared to be caught.
• Unchecked exceptions - any exception that doesn’t need to be caught or declared to be caught.

An example of a checked exception:

public void exampleMethod () throws ExampleChecked {
    throw new ExampleChecked();
}

public void exampleMethod () {
	try {
		throw new ExampleChecked();
	}catch(ExampleChecked ex) {
		// Handle exception here
	}
}

An example of an unchecked exception:

public void exampleMethod () {
    throw new ExampleRuntime();
}

Cool, all on the same page. Now lets go into where and how I’d use them.

Checked exceptions

Checked exceptions are both excellent and an absolute pain in the arse.

I use checked exceptions when writing libraries, as a libraries API should be explicit and self documenting. As developers we should avoid surprising users with unexpected side effects. Of course, you should also properly document your library with Java Docs and Wikis, but there’s nothing quite like saying “Hey, this method you’re going to use? It could explode with this and you must handle it”.

To complement this, I avoid unchecked exceptions. I aim to wrap these, and re-throw them as a checked one. This way I can control the messaging and the stack trace to ensure the best language and structure. Remember: Your exceptions are part of your API.

Also I don’t let generic Java ones escape without some level of catch and re-throw. It’s a pain trying to understand where a NullPointerException came when it’s not been wrapped in a something specific to the library that’s imported.

On the flip side, I avoid putting these into my application code unless absolutely required / desired. There are two main reasons:

1. I’ll have to code every method to bubble up the exception to a root exception handler. Very messy.
2. Java Optionals and Streams don’t work overly well with Checked Exceptions (though, unchecked exceptions are still pretty ugly but I don’t have to code around them).

More on these below.

Unchecked exceptions

I’d argue these are, on the whole, more useful and less annoying than checked exceptions. They allow a developer (me) to be lazy in both the best and worst ways.

I spend a lot of my time in Spring Boot / web applications. So I use generic error handlers that look out for extensions of the RuntimeException class. So if one is throw, a 500 internal server error is automatically returned. Or if a UserNotFoundException is throw, then a 404 is returned. And so on.

This makes the applications I write to be a little easier to follow / have a generic safety net. It also means every method doesn’t have a load of declared exceptions because some item of code throws one 7 methods deep. This is kinda what I mean when it allows me to be lazy. That generic handler does a lot of the leg work.

So I avoid checked exceptions in my application code.

However, there is a bad way to be lazy here; I can throw them for everything. I’ve seen in a number of places where a devs catch a RuntimeException and then do something else. When I was younger, I certainly did this. However, this is expensive and a lot of additional lines for very little gain.

Here’s an example where getUser throws a UserNotFoundException when no user is found:

public User getUser () {
    try {
        return getUser(userId);
    } catch(UserNotFoundException ex) {
        return performUserSetup();
    }
}

In cases like this I would instead use Optionals, and a mix of or, orElseGet and so on. This makes for much cleaner code. More efficient code. And no need for any exceptions at all.

public User getUser () {
	this.findUser("someUserId")
			.or(() -> performUserSetup())
	        .orElseThrow(RuntimeException::new);
}

On a random side note; whenever I write methods that return an Optional, I tend to use find or something like that.

TL;DR

So, in summary here’s my approach:

Use checked exceptions in libraries as code should self document and shouldn’t surprise a developer.

Use unchecked exceptions in application code to avoid writing methods with huge signatures to leverage root exception handlers, and leverage Optional where possible

Happy programming!

Wow it’s been a while!

So, where have I been? Well, I proposed to my partner in Rome, and they said yes! Honestly I’m an incredibly lucky guy.

I’ve been working a lot too. Gotta grease the wheels of capitalism. Oh and of course I’ve been riding the Guzzie a lot. Stunning weather this year! I’ve also been playing a lot of music - even had a slot at the Totnes show! So was pretty cool.

But now the cold weather is closing in I’ve got more time to write again. Can no longer ignore the desire to write with a quick sea / river swim!

In between enjoying the sun and my job I’ve been working really hard on a technical side hustle that I’ll share soon. Basically, if I’ve been at my desk I’ve been writing code for my job, or for my side thing. And when it’s sunny, I really don’t want to be at my desk.

With the weather changing, I’d like to get back into my original “promise” to blog once a month. And I’ve got a load of blog ideas. Too many. Bound to be one good one in there somewhere.

My first blog (except for this one) will probably be a three parter. I want to do a deep dive into the Apple ecosystem from the perspective of someone new to it all. And oh boy do i have opinions! I’m aiming to break it down across hardware, software, and then finally ecosystem & culture.

Anyway, it’s nice to be back. Bring on the blogging!

Geospatial tech is a deep, rich, and complex sector of the tech industry. I work for a small startup, Edozo, which handles Commercial Property Data and Mapping. What this essentially means is that for the past 5 years I’ve been working within the GeoSpatial sphere, using things like PostGIS and GeoServer to deliver products.

I’ve learned a whole lot on this journey (and will probably be the subject of a number of blog posts in the future) but today I want to share a little side project I’ve been working on: geo.harrywinser.com.

The problem

On a day to day basis, I tend to work with a lot of different geometries; user inputted, or derived from user interaction. I also need to generate geometric test data, such as for unit tests or testing API endpoints.

With that in mind, I soon discovered a bit of an issue with the tools I was using, and I couldn’t find anything quite what I was looking for.

For example to convert a GeoJSON Feature to a different SRID I’d do:

1. Extract the Geometry from it
2. Read it in Postgres using ST_GeomFromGeoJSON
3. Set the SRID
4. Convert to a new SRID using ST_TRANSFORM
5. Convert back to GeoJSON

As you can see, this is quite a long and involved process. If the shape is large, DBeaver can start to crash. And if it’s a FeatureCollection, well then that’s extra hard.

With all this in mind, I thought “There has to be an easier way to do what I need doing!”.

So I went hunting on the net.

One of my first finds was geojson.io. It’s a good looking site, and very focused on creating and editing GeoJSON. However, I found the tools tricky and unintuitive (to me), and it cannot transform the shapes between different SRID’s * .

There is also QGIS which is a fantastic Desktop application for doing all sorts of GeoSpatial data manipulation. It can easily do what I need. However it’s not lightweight, has a many GB install, and uses a lot of RAM while in use. Not great if you just need to draw a shape and copy out some GeoJSON.

A Solution

So, I thought about it, and made a list of what I needed to get the job done:

1. Create/Edit shapes
2. Insert Shapes
3. Copy them as WKT’s or GeoJSON
4. Create GeoJSON Feature Collections
5. Transform shapes between different SRID’s
6. Fast and Lightweight
7. Make it at least mildly workable on Mobile (though, this is not the primary focus)

With the above in mind, I’ve started to build geo.harrywinser.com! As of time of writing, it’s still very much in progress. Half the features aren’t there yet, but i thought I’d share the work in progress, as it might already be useful to some folks.

Let me know if there are any additional features you’d like to see, or any bugs that are… ahem… bugging you!

*The standard SRID for GeoJSON is 4326, as per the standard. However, You can specify your own SRID as part of a Feature or FeatureCollection, which is where geojson.io falls down for me.

To do more, do less

I’m not quite sure where this adage came from, but it’s become something I now live work by.

Let me explain.

5 years ago I joined Edozo, which is a start up focused on Commercial Property technology. I’d never worked for a start up before, but coming from Rightmove it was a fairly big shock. Suddenly gone were all of the guard rails. Code quality, deployments, infrastructure etc. were all things I needed to really focus on and align. But the biggest thing; Work Management. Gone were the well ordered Planning Sessions. The multiple teams breaking down a large task and sharing it. Gone was the deployment platform and multiple Tech Leads to bounce concepts off of.

On top of this, I was thrown into a world where the work I was doing would have a direct impact on sales conversations, and ultimately revenue. Feedback was fast. That’s not to say the work I did at Rightmove didn’t effect real users, but it was certainly more removed than what I see at Edozo.

Those working for a small start up like this will know exactly what I mean.

What’s very easy in these situations is to get your “wheels” jammed. Though, some might say “wheels spinning”. There are so many needs; from potential/new/old customers, to maintaining infra, to smaller bits like keeping Java/Node up-to-date. It’s a lot. And when all of that falls onto a single 5 person team, Work Management becomes incredibly important. Get this wrong, and you and your team can be crushed.

So relatively early on, I started to say this in meetings:

“To do more, we need to do less”.

But what does this mean? Ultimately, it means you need to look at what your team can achieve and prioritise. Once you’ve picked what you’re doing, methodically work through it. One item at a time. Avoid doing it all at the same time. Get the dopamine hit of actually finishing something. That feeling will get you through the next thing that needs doing. And the next.

I’m not saying as a team you can have only one thing in flight. It’s more about being aware of the teams capacity, and those the team relies on. If you find yourself in more meetings than actually doing work, maybe “do less”.

You may of heard the term “Stop starting, start finishing” - this links perfectly with the above.

With this in mind, I should probably share the set up of the team; we have five full time developers. We build/maintain four products, multiple backend services to power them, and a load of data + ingestion. For a team of five, with some DevOps and a product manager / owner, that’s quite a lot. If you don’t believe me, here’s our release blog showing that our “wheels” aren’t jammed.

One day I’ll share my full journey at Edozo, and how we introduced Continuous Delivery, Open Telemetry, Docker, and more.

But first, I want to finish and post this. Because to do more, do less.