Brodsky Blog

In Japanese there is a great word — 親孝行 (Oyakoukou) — which means that a child cherishes their parents and expresses their gratitude towards them with meaningful connection and appreciation.

親孝行とは、子が親を大切にし、感謝の気持ちをもって真心から尽くすことです。

単なる物質的な贈り物だけでなく、感謝の言葉や、顔を見せる、食事を共にするなど、親が喜ぶ行動を指します。

As I grew older, I started cherishing the time I got to spend with my parents a lot more. Especially now that I became a dad, I can empathise with my own parents and appreciate what they went through when I was born. And of course I want to support them in their more senior years and give them happy and exciting experiences. Because my parents love warm weather, delicious food (especially fruit), and travelling, what I set up for them ticked all these boxes.

This is the story of my oyakoukou.

---

Life in Sydney

A few years ago my parents helped me and Koto buy our first home—a two-bedroom apartment in Artarmon, Sydney. I knew I had to thank them for this somehow, and the perfect opportunity appeared this year: our baby. With us planning to give birth in Japan, our apartment in Sydney would be empty for a whole six months. And from that, a great idea came about: how about my parents live in the apartment for three months before they come visit us and our newborn baby in Japan?

This was the first piece of me expressing my gratitude and doing oyakoukou. I got to spend one month living together with my parents again, shopping with them, cooking with them, playing games, and travelling a bit. And then when I left, they got to really experience life in Sydney in summer with all our delicious fruit, fresh meat and fish, and gorgeous warm weather.

They said that it was an amazing experience for them, and especially dad didn’t want to leave the fruit paradise.

Travelling Japan

A month after our baby boy was born, my parents came to Japan to meet him. But they didn’t want to just visit for one day, so I set them up with a 10-day itinerary.

It includes a trip to Yamaguchi, Fukuoka, Kurashiki and Okayama, as well as two trips to Kotone’s childhood home.

Meeting the grandchild and in-laws

The main purpose of the trip to Japan was for my parents to meet and spend time with their first grandchild and the heir to the Brodsky name. And to see Kotone’s family again, who they haven’t seen since our wedding 3 years ago.

By visiting Kotone’s childhood home, they got to meet and talk to Koto’s family and spend time with their grandchild.

Of course, with him still being one month old, it was a very nostalgic feeling. 30 years ago they held me in their hands, and now they are holding my child.

It was such a warm feeling, seeing my mom become a grandma and my dad become a grandpa.

Yamaguchi - Yuda Onsen

A trip to Japan is not complete without a dip in an onsen. But this time we started with the onsen.

Yamaguchi is a very quiet prefecture, and honestly the area around Yuda Onsen was a bit run down. But the hotel we stayed at (Matsumasa) and their onsen (both indoor and outdoor) were amazing. I can never get tired of Japanese hot springs, and neither can my parents—they’re happy to go every day.

Near our hotel there were many bars and izakaya, but barely anything open for lunch. So we had no choice but to go to Gusto—which ended up being my parents’ first family-restaurant experience. And they loved it.

Fukuoka

Umi no Nakamichi Park

The first day in Fukuoka we spent in the large flower garden - Umi no Nakamichi. They had beautiful flower displays there, but because it was all spread across a large area we had to walk for over 10km total. They also had a small zoo there with a few exotic animals, which was fun to see. For dinner that night we bought a huge sushi platter for only 4600¥ from Lopia. It was delicious and such a good deal! Highly recommend.

Dazaifu Tenmangu Shrine

In the morning of the second day we went to the Dazaifu Tenmangu shrine. Unfortunately it was raining quite heavily and so we had to walk around with umbrellas all day. And the shrine itself was closed for renovations. Still cool to see it all, but not as pleasant of an experience as it could have been. But it’s ok, because this wasn’t the main purpose of the trip, it was actually what we had planned for the afternoon.

The Lexus factory

My dad has loved Lexus cars for the past 20 years and it has been his dream to see them being built in the factory live. And I wanted to fulfil his dream, so I booked us a tour in the Kyushu Toyota and Lexus factory. In the factory we were taken inside the welding and assembly halls of the main factory. My dad was seriously impressed by the robots that were performing all the tasks and the craftsmanship that went into the build of the cars.

There were also interactive displays where you could compete in painting, gathering bolts, plugging holes and comparing colors to workers of the factory. Both me and my dad tried but our skills could not compare to those of masters in the factory.

Obviously there were no photos allowed in the factory itself, so we can’t share the experience we had. You will have to go there and check it out yourself. (It is completely free!)

And then to top off the day we had some delicious Hakata tempura and went to the onsen in the hotel.

Denim in Kurashiki

The next day the rain got even worse, but we had to continue our trip to Kurashiki. My mom learned about this place and really wanted to visit it, so I made sure we could stop by on our way back to Nagoya.

Kurashiki is a small and quaint town, with gorgeous old Meiji era buildings on a canal in the center of the city. Not only that but it is also famous for its jeans and denim. So I knew I had to buy a pair!

With the rain clearing in the evening, I got to take some gorgeous night shots of the town, so for me this also turned into a bit of a photography trip.

Okayama

The next day was completely sunny, a perfect day for us to explore Okayama Castle and the garden near it.

Okayama Castle is beautiful and had a great view from the top. And the Japanese garden was definitely worth the visit.

Nagashima and Nabana

Now that we’re back in Nagoya, we had one more thing we wanted to do—shop for some clothes at an outlet. So we went to Nagashima Outlet and spent most of the day shopping there.

But on the way back we stopped by the flower garden Nabana no Sato. This garden was surprisingly even more beautiful than the large flower park in Fukuoka. And not only did it have more flowers, it also had a night illumination show. This once again turned into a photography trip for me, as opposed to my parents who were admiring the gorgeous flowers.

At the Kamino home again

One more day of meeting the in-laws and spending time with the grandchild. It is always so nice seeing both families gather together—the Kamino and Brodsky families’ fates are connected.

I hope that we can one day again meet up like this somewhere in this world.

Time to head home

For my parents, their long journey has ended and they are now on a flight back to Riga (via Hong Kong and Amsterdam). But for me, I will be staying in Japan with Koto and our boy until the end of July and then we will return to our home in Sydney.

Over these past few months I got to spend a lot of time with my parents and cherished every moment of it.

We took a lot of photos during the trip and you can see them on my Flickr.

Well that’s it, that was my Oyakoukou.

For many engineers, especially earlier in their careers, the work looks like a straight line: step 1 → 5. Whatever product and design gave you before step 1 might as well be carved in stone; shipping exactly what was written down feels like the real requirement.

The steps themselves are familiar:

1. Break the problem into smaller chunks.
2. Assess how they fit into existing systems and what needs to change.
3. Weigh alternatives.
4. Estimate what it will take to build.
5. Build it!

The trouble is treating that sequence as strictly linear and the initial brief as immutable. I will admit I used to think the same way. I received requirements and tried to build what was asked. If another engineer were to push back on changes I proposed, I’d say: “That is the requirement.” I said it in a review on code one of Canva’s Distinguished Engineers owned and instead of understanding, I got this response:

---

Oh no, you used the “R” word. 😱

🛑 There is no such thing as a “requirement”🛑

There are only asks/desires/ideas, and it’s engineering’s job to refine every proposal through the lens of feasibility, in order to pick the most deliverable option that essentially addresses whatever the underlying need or hypothesis is.

That instantly rewired how I saw the relationship between engineering and product. Engineers are not bots that turn requirements into code; we are custodians of the codebase, we manage it’s complexity. Part of the job is to explain constraints early, work with product and design on feasibility, and steer toward experiences users will love without sacrificing quality or extensibility.

Doing that means treating early asks as hypotheses, not marching orders; having the conversation about risks, options, and trade-offs before commitment sets in. You become a co-owner of the experience - you can and should raise concerns and opinions. The strongest engineers I know pair deep technical judgment with product sense; they make trade-offs that leads trust rather than fear.

So I share this whenever someone uses requirements to justify a poor architectural call or a convenient shortcut. I hope it lands the way it landed for me - less automatic deference to the spec, more honest collaboration with product and design.

Booleans are the core of all software: the combination of true and false or 1 and 0 is what powers all modern computing. But in Software Engineering, the higher-level kind, booleans are seldom the tool that us programmers should be reaching for.

As my mentor at Canva so eloquently put it:

Booleans are bad, nobody likes booleans,

booleans have no friends, boo for booleans.

But why is that? Why should booleans be avoided? And what should we be using instead?

---

Inspiration

What inspired this post is my favorite phrase from Dave, which has become my go-to during PR reviews at work, and also the video from Theo t3.gg on this exact topic. Theo’s video was based on an article by Nicole Tietz-Sokolskaya titled “That boolean should probably be something else”, where she said:

Booleans are sneaky. They feel like they make sense for our data, but they make sense for our logic. The data is usually something different underneath. By storing a boolean as our data, we’re coupling that data tightly to our application logic.

I highly recommend you read Nicole’s article and watch Theo’s video, and also read what I have to say about booleans:

Intro

Reaching for a boolean is often a sign that we’re encoding logic as data. It’s the easy option: “this thing should not look like this under condition X, ok, let’s make a boolean isX and pass it around”. This works, but it makes evolution harder: once you ship a boolean in your data model or API, you’ve committed to a two-state worldview, and you’ve hidden the underlying meaning.

Let’s look at the reasons why booleans don’t work for us as well as some may think they do, and I’ll outline alternatives as well.

Booleans aren’t really boolean

It is very rare to have code that is truly boolean in nature. Most code doesn’t neatly fit into an on or off state. It tends to grow beyond that dual state very quickly into:

• on
• on-for-some-users
• off-for-everyone-actually
• off-but-not-for-admins
• etc.

While a lot of concepts start off boolean, they quickly evolve to not be a set of 2. Preparing for that inevitable change will set your codebase up for the long term much better.

Booleans are trileans

Have you ever found yourself wanting to add a boolean to existing React props? But you don’t want to update every consumer of it, so you add it like this:

type Props = {
  // some other props
  canDoFoo?: boolean;
};

This is no longer a boolean; this is a trilean. It has 3 states: true, false, and undefined, which can all mean different things. One might argue that undefined and false mean the same thing. But how am I supposed to know that from just reading the type? I’d have to read the code to figure out how it is used before I would be convinced that they are the same. And if they are the same, why have both? For convenience? Just update the other callers around the codebase…

And in cases when false and undefined actually mean different things, then it is even more confusing. What does an undefined boolean mean??

Boolean names are confusing at best

If you see this in the codebase:

const open = ...

What do you think the type of open is? Is it a function that you can call like this: open(), or is it a boolean? In TypeScript, doing this:

if (open) {
  // do something
}

is valid for both cases! So I have seen many bugs in the codebase where people assume a variable is a boolean due to its naming, but in reality it is not.

One approach is to name the boolean better, with an is* prefix: isOpen - then this is obviously a boolean! Yes, you could, but then it becomes confusing as sometimes you will see is* and other times you will see are* or has* or will* or can*. Still better than not having them, but not as good as not using a boolean.

Boolean names are arbitrary

When naming a boolean, how do you choose which way to name it? What I mean by that: imagine you had a flag to turn a feature Foo on or off. Which name would you pick?

1. enableFoo: boolean
2. disableFoo: boolean
3. isFooOn: boolean
4. isFooOff: boolean
5. isFooEnabled: boolean
6. isFooDisabled: boolean

I hope we can all agree that options 4 and 6 are the worst, because there is nothing more confusing than reading a double negative: !(!isFooOff && isBarDisabled)

I have seen many cases of const isDesktop: boolean and const isMobile: boolean, and every time my question is: why did you pick desktop for the name and not mobile? With booleans like these it is never clear which is the “negative” because there isn’t one… they are both positive, they are just different states. And neither state should be taking priority over the other.

Boolean code is hard to parse

Code is still primarily read by humans. So making it easy to read is essential. Would you rather deal with figuring out:

if (a && b && (c || !d)) {
  // do something
}

or

if (a != null && b == 'something-meaningful' && (c > 0 || d == null)) {
  // do something
}

Sure, in the first case, if all the variables are very explicitly named, then the final condition can still be parsable. But in the second case, all the variables are actual pieces of state with meaning, and thus these comparisons describe the logic better. What I am saying is this:

if (event.endTime < new Date()) {
  // do something
}

is more readable than some arbitrary extra meaning that was given to the variable name for no reason:

const canBuyPancake = event.endTime < new Date();
if (canBuyPancake) {
  // do something
}

(I will acknowledge that if the variable was named isEventOver that wouldn’t be as problematic, but as I mentioned before, that can quickly grow out of hand, especially when the code gets refactored and the logic moves somewhere else)

Hard to parse in function calls

Have you ever seen something like this: calculatePayment(false). I have, many times, and it has stumped me every time. What does false mean here? Does it mean to not calculate the payment???

The internals of calculatePayment are not apparent to consumers at all. (Same thing goes for numbers and plain strings, btw.) A solution would be to require passing an object calculatePayment({ includeSurcharge: false }). But this once again suffers from the same problem of having to name the boolean, and encoding logic into data.

What to use instead

There are 3 alternatives to booleans:

• String unions (or enums) (enums vs string unions is a whole separate topic)
• Numbers or DateTimes
• Null

String Unions

A lot of booleans are just a combination of multiple states that are mutually exclusive. So instead of defining them as a boolean, define all the possible states.

// For example
// instead of:
const short: boolean;
// or
const isShort: boolean;
// or
const isLong: boolean;
// ^ good luck on deciding on which one is the right name
//
// set up a string union
const shape: 'short' | 'long';

This makes it extremely clear what the property is (shape) and what values this property can have. All of this can also be achieved with enums, but in TypeScript enums are finicky, so string unions are generally simpler to work with.

Number or DateTime

Instead of storing a boolean as data to represent state, it is almost always better to store a datetime or number to log when this state has changed. “Is the user’s email validated?”, “Are they logged in?”, “Is the event active?”, “Are there items left on sale?” All of these could be encoded with numbers to represent quantity / inventory and DateTimes to represent when an event occurred that caused the state to change.

For example, instead of storing: “hasPaid” in the DB, storing the amount paid, and the amount requested to be paid is a much better approach. Because it not only allows you to compute the value for the logic of “has the user paid”, but it also lets you use the actual amount for other things, like generating a receipt, etc.

Null

Null checks are one of the most powerful options we have, as the presence of data is fully boolean in nature: the data is there or it isn’t; there is nothing in between. If your data structures are set up the right way, then checking for null will tell you exactly what you need to know, without needing an extra boolean.

Even with null checks I still see people doing this:

const hasBooking = order.booking != null;

This is very rarely a good idea, because it was already easy to parse the null check, and it is also very transparent that it isn’t hiding anything else underneath. The hasBooking field could do that null check, but could evolve to do some extra thing or 2 later, and the code that relies on it might not need that extra logic. Which generally leads to more refactoring, or introduction of more functions, with more booleans, etc.

To wrap up

I believe booleans should be treated as a design smell. But the smell isn’t “a boolean exists”, it’s “a boolean became part of the data model or public API, and now it’s carrying hidden meaning”. Every time I see one there, I scrutinize it and ask: “what is the underlying concept I’m trying to model?” Good luck coding folks!

Apple recently released the MacBook Neo, the cheapest MacBook ever made, but a lot better than the majority of computers in the same price bracket. People are calling it the Chromebook killer, and the conquerer of the education market.

It is definitely a disruptive machine, but one thing the reviewers are focusing too much on is who this laptop is or isn’t for. Saying things like: “if you want to edit videos, photos, code on big projects, this laptop isn’t for you”. And while I don’t disagree with them, I much more agree with this article: “This Is Not The Computer For You” · Sam Henri Gold, saying that as a kid using a computer, you know it’s probably not the right tool for what you are trying to do and it doesn’t matter, it never did.

Nobody starts in the right place. You don’t begin with the correct tool and work sensibly within its constraints until you organically graduate to a more capable one. That is not how obsession works. Obsession works by taking whatever is available and pressing on it until it either breaks or reveals something. The machine’s limits become a map of the territory. You learn what computing actually costs by paying too much of it on hardware that can barely afford it.

---

When I was a kid, my first interaction with a computer was at my father’s workplace. He’d sit me down at the work computer, open solitaire and let me play it for hours. He’d also ask me to help him scan files from time to time, showing me that a computer is not just for games. Then when I got a bit older dad bought my my own computer at home, but it didn’t have a connection to the internet yet. I could only use the apps that were installed into it and the games that I bought with my allowance, or that friends gave me copies of. I was never the creative type, I never wanted to draw things, make music or videos, all I wanted to do is play games. And I played a lot of them: Age of Empires II, Warcraft III, Harry Potter, The Neverhood, GTA Vice City & SA, THAW, Sonic Riders, Truck Simulator 2, etc

But through gaming I realised that computer specs matter: CPUs, GPUs, RAM can all impact how well your game runs and if it runs at all for that matter. Then, when I got an internet connection I started learning that you could modify games! Add your own cars, weapons, etc. So the next thing I learned was how change values in database tables of GTA San Andreas to make cars go faster and drift better. Add newer Ferraris into the game and make them fly.

In 2004 blizzard releases World of Warcraft and I absolutely had to play it. But it was a subscription, and there was no way I could afford that. Of course my parents weren’t paying 10$ per month for me play a game. So I did what most kids of my age would: find a free version somehow - private servers! But I went one step further. I set up my own private server. I learned how to host a server, how to manage the connection, and a lot more about the database. With each game I couldn’t play I was secretly learning more about hardware limitations, software limitations and actual software engineering with databases and networking. And by showing my parents that I cared a lot about how things worked, they let me upgrade and push the limits further. The photo at the top of this post is me getting a brand new computer as a Christmas / New Years gift in 2007, playing WoW now on the official servers and leveling my dwarf paladin to level 70 in Nagrand.

My parents never got me the perfect computer for software engineering, or for gaming. I got the computer that they thought would be enough for a kid my age. And I think that is the key message of the Apple MacBook Neo should be: this is a computer for everyone to learn what kind of computer they need.

It has taken over 6 years, but I have finally fixed up my blog. I got to the point where I had topics I wanted to write about, but couldn’t because my blog was an absolute disaster. It got so bad that I legitimately had no way of fixing it aside from nuking the whole thing and started from scratch.

Let me show you what happened, how it all went wrong, and what I did to get to this new and improved blog post. Welcome to my new blog - Fen the fennec fox brings you a Fen-cy new theme!

---

My old blog was hosted on a Digital Ocean droplet running Ubuntu 18.04 with a 2019 version of WordPress. It was out of date to say the least. Software is a funny thing, if you leave it alone and don’t change anything, you’d think it will be stable for many years. But that is definitely not the case.

What happened here was that my blog got overrun with various crypto bots and scam posts for random products in many different languages. They must’ve broken into my account, because they were creating new posts as me.

So closer to the end of 2025 I started researching what the modern tech stack for simple blogs is. A couple of things became clear:

1. Digital Ocean is no longer the best choice as it was in 2014.
2. Nobody recommends WordPress (and PHP) anymore; there are plenty of CMS alternatives.

Replacing Digital Ocean

I paid AU$9.00 per month for a Linux machine running Ubuntu to host my WordPress instance with a MySQL DB on Digital Ocean. And I thought that was a good deal.

You know what is a better deal? Paying $0. And the way to get that is to deploy via Vercel. For small personal projects with little traffic, it’s FREE.

Deploying with Vercel is super easy as well - just create a GitHub repo and make a Vercel project connected to it. It will handle the rest. Every time I push a new commit to the repo, Vercel picks that up and deploys the changes, it’s quick and effortless, feels like magic sometimes.

So now I can decommission (destroy) my old Digital Ocean droplet - Shimakaze. You have served me well!

Replacing WordPress

There are many many options for how to serve the content of a blog. With the simplest being plain static HTML files. But that wouldn’t allow for any kind of client-side interactivity that I intend to introduce. So I need a framework that would allow me to write React and TypeScript code that would then be transpiled to HTML + JS, but in such a way that the core - the blog articles - can be static.

There is a perfect framework for this that is highly praised in the software engineering space (specifically by Theo.gg), it is called Astro. Astro allows you to build basically static pages, and specifies which components need to be interactive and require JS execution on the client. This is great for performance and the overall experience - exactly what I was looking for.

But this doesn’t solve the CMS problem. WordPress was both a frontend UI and a CMS for managing the content. Astro is a framework for serving the UI. But it actually allows for a very simple way to set up a blog: markdown files.

So what I have now is that all my posts are in .md files in my repo, no expensive DB on the site. They are easy to edit in any text editor, and by committing the changes to the repo on GitHub I can push the update up.

For all the old posts, I exported them from WordPress as an XML file, and then converted it into separate markdown files. It was a relatively painless process, which I am really glad about.

Now I could’ve used something like Sanity Studio, which we use at SMASH!, but I figured it would be overkill for my needs: a single user updating the site once in a while, when I have a new post available.

Styling the Fency theme

With Astro building it and Vercel hosting it, we have the new blog foundations. Time to design a theme! To do that I challenged myself to learn a different way of doing CSS. In 2016 I learned SASS and was fully sold on the idea that SASS is the way to do CSS (together with CSS Modules). However, during these 10 years, a new CSS framework has gained a lot of traction - Tailwind. I of course knew about it, but rejected it, as I believed it was worse than SASS. It required you to learn a proprietary syntax, conform to predefined sizes and colors, and most egregiously put all the CSS into the component (HTML / React file). So you no longer had a separation between style and structure.

But this is where, if you think at a higher level, you will see that we’ve been moving in that direction for a long time now. Our React components already have both the HTML structure and the JS logic in them. We don’t separate them like we used to with PHP or handlebars, where the template was separate from the logic and separate from the styling. So what if we combined the styling as well?

I tried it here, in my Fency new theme, and it wasn’t too bad. I’m still skeptical, but acknowledge that this is not as bad as I once believed it to be. I’ll report back on how it feels in a few years.

TL;DR

I completely rebuilt my blog using Astro as a framework with Tailwind styling. GitHub is my CMS, and Vercel deploys and hosts it all. Welcome to my new blog!

In April 2017, I got myself the top-of-the-line Canon DSLR, the 5D Mark IV. And it has been my workhorse for the past 9 years. I’ve taken so many beautiful photos with it that you can find on my Flickr.

Unfortunately, misfortune has struck. On my latest sunrise shoot, it was on a tripod, and when the waves came in, the tripod tilted and the camera fell into the water and sand. Corrosion got the best of the wide-angle lens; it no longer worked. The body miraculously survived, but without my main lens for landscape photography, I was left with a puzzling situation: do I fix it, get a new one, or get a completely new camera?

---

Why would I get a completely new camera? Well, in the almost 10 years since, camera technology has greatly advanced. Not only for photography but also in the video space. My old Canon was completely useless for video. So I have actually been thinking about whether I should swap to a more versatile all-rounder. But since I never did so much video, it was never worth it.

But now with my main lens destroyed and fixing it costing more than getting the same lens second hand, I started researching what would be the best option for me if I didn’t have a camera at all.

All roads led me to the not-yet-released Sony a7V. It was about to be announced in a few weeks, and there were plenty of leaks about it. So I decided to wait for the announcement, and then if it was the same as what the leakers posted, then I’d get it.

And as you can probably tell by the title of this post, it met (and exceeded) my expectations. So I got it and bought all new lenses for it. I went with almost the same combo as I had before:

• Wide angle: FE 16-35mm F2.8 GM II
• Zoom: Full Frame E-Mount 70-200mm F2.8 GM OSS II Lens
• Prime: Sonnar T* Full Frame E-Mount FE 55mm F1.8 Zeiss Lens

The wide angle is basically the same as I had on the Canon, 16-35mm and f/2.8, so not much changed there.

The zoom is quite different in that it is only up to 200mm (not 300mm), but to compensate, it’s now at a fixed f/2.8 instead of variable f/4-5.6. And this specific GM lens is also very fast at autofocus, which will greatly help with wildlife photography.

For the prime, I also decided to splurge a bit more, so instead of just getting a cheap nifty fifty at f/1.8, I went for a slightly fancier Zeiss lens at 55mm. Zeiss lenses are known for their clarity and sharpness, so I figured it would be a good upgrade.

Overall, I am very happy with the camera and all of its new features (which I have yet to figure out how to use), and the new lenses. Looking forward to taking some amazing photos and videos!

COVID times hit global travel hard. People couldn’t leave their own homes for months, and neither could I. But the time to travel has finally come again and our first trip is to the UAE - Dubai.

Dubai is one of the only places in the world that actually accepts tourists right now and it has the other large convenience of being right in the middle between Riga, where my parents are, and Sydney, where Koto and I are.

While I’ve already been there, this will be the first time for Koto, first time in the Middle East even. Koto is very open minded about travel and very curious to learn and experience different cultures (that’s why we are getting married), so she was keen to go. The Arab world is not really a travel destination that many Japanese people choose, it’s just not that popular. So by going, Koto is going to score some sweet bragging rights to her friends and relatives.

---

Because of COVID regulations we had to wear masks almost everywhere and do RAT tests a couple of times, but aside from that it felt like a normal holiday.

We swam in the pools and beaches, ate at various delicious restaurants, visited some amazing places, and even went for a ride on a yacht and a hot air balloon. #just_dubai_things

The Yacht

Dubai has a gorgeous marina and in winter, when it’s not scorching hot, the wealthy businessmen of Dubai go on their yachts and party on the sea. My father knows one such man and he invited us to his yacht for an afternoon of champagne drinking, sunbathing and swimming in the bay. We totally lived the life of wealth and glamour for a few hours.

For Koto this was a surreal experience. She grew up in a rather small town near Nagoya, and now she is sunbathing on a yacht in the Dubai marina, who would have thought that life would take her here.

Burj al Arab

Ever since I was a kid I heard about this 7 star hotel in Dubai, and I always wanted to visit it. I knew staying in it would be way out of my budget, but at least seeing what it’s like inside would be pretty cool.

Thankfully they have tours there and we went for it! The interiors are lavish, a lot of the times too extravagant for my tastes.

It’s interesting to know that there are people who want to be in this kind of environment. I honestly don’t, I’m happy to just take a look at it all for my own curiosity.

Birthday Balloon

On your birthday there are usually plenty of balloons all over. Balloons are a sign of celebrations and parties. I love balloons, but I’ve only ever looked and touched them from the outside, I think it’s time to be on the inside of one.

And that’s what I did this year, we booked a trip on a hot air balloon! Woke up early, got taken into the middle of nowhere and rode on a hot air balloon through the desert on my birthday. Oh and we got to ride some camels afterwards as well.

It was a surreal experience and I am glad I got to spend my birthday with my parents and the love of my life.

Burj Khalifa

And then to top it all off (pun intended) I really wanted to go to the top of the tallest building in the world: the Burj Khalifa. So Koto and I went for a wild ride up 500+ meters into the sky to the highest observation deck with no windows! The photos I got there are incredible. We also got offered Arab coffee and dates (they offer dates everywhere…) as well as other snacks and refreshments.

Expo

Oh and one more thing, Dubai was hosting the world expo at the time. It was actually supposed to end in 2020, but due to Covid it got postponed all the way into 2022. We went there for a day to check it out. My parents and I really don’t care that much about all the deep details of every country’s showpieces, so to the shock of Koto we went through them all quite quickly.

Photos and Video

This time around not only did I take a lot of photos with my DSLR and iPhone, but Koto and I took a lot of videos as well, creating a beautiful travel vlog.

Photos are on my Flickr as always.

Here is the short version video:

And we have 2 long versions as well, 1 from my perspective and 1 from Koto’s.

I think it’s no surprise to anyone that I love trains. I’ve been fascinated by anything rail related since I was a kid. So of course when I heard about the historic steam locomotive adventure - the Picnic Train, I straight away wanted to experience it. It is still COVID times some parts around the world, but here in Sydney we’ve all got our vaccines and are freely moving about again.

The train journey starts from Sydney Central Station and goes to Kiama down the NSW coast. It takes about 3 hours 1 way, which is double the time compared to a modern electric train. But it is totally worth it for the experience of riding on the vintage cars of a 100 year old train.

We actually found out about the Picnic Train from my Latvian friends Deniss and Valentina, so it was a sort of a double date for us.

Overall a very pleasant experience, even though we did get covered in ash and coal bits while going through the tunnel. Would recommend to anyone who likes trains or historical machines.

Check out the photos I took here: https://adobe.ly/3qbvPrD

Not every day you become a citizen of a country! In fact for most folks this is once in a lifetime event. But for me, after spending 11 years in Australia living, studying, working, Australian citizenship was finally no longer a dream, but a completed life goal.

Latvia allow’s its citizen to have dual citizenship, so naturally I opted for that.

But there was more thing I wanted to do before I got my Australian passport: change my legal name. My name is Russian language is: Vadim Brodsky, but in Latvia its Vadims Brodskis, because thats how the Latvian language works, all masculine words must have an -s at the end of them. And that has been the reality of my life since I was born. I can not change it in Latvia. But I can change it in Australia!

So I applied for a name change with the New South Wales Registry of Births, Deaths & Marriages and it got approved. So my name legally in Australia is now Vadim Brodsky. No ‘s’s at the end anymore. And that is what it says on my Australian passport. However I can not change my Latvian passport. Thus I am stuck in a reality where I have 2 passports with 2 different names. I’m sure that wont cause any problems to me whatsoever, right?…