After 6863 days, yesterday was my final day at Google. Two months shy of 19 years.

Grateful for all the opportunities. The opportunity to travel the world, to work on the first iPhone app, to bring people together, to work with wonderful people, to redesign Google, to work on my favourite products and to eat all the free food.

There's no next thing, I'm retiring to spend time completing my side quests.

The main principle here is that it should be functional as a website and also (quasi-)functional as a command line but primarily for operating this website. This is based on an earlier Terminal prototype I vibe-coded a few months ago, but then subsequently extracted, and more or less rewrote by hand to fix a bunch of layout behaviors which was really hard to get Claude Code or Gemini/Antigravity or Codex to get right.

The code knows the structure of the website, and converts that into a virtual filesystem that exists in JS. The main commands that were necessary was cd and ls. Each page is a directory (no files), and if a cd command was detected, is does a proper page navigation using SvelteKit's goto(). As a bonus, the output of ls is slightly marked up and instrumented so clicking on the links will emulate typing the command in and navigating.

After moving to Japan and discovering there were resorts apart from Niseko and Hakuba, I wanted to know more about these slopes. I wanted to go to check them out. Not long later, I stumbled across a magazine that claimed to list all 430 resorts in Japan. I bought that magazine and proceeded to manually write down in a spreadsheet every ski resort there was.

I wanted to know more. I wanted to know how big it was, how popular it was, how much snow it was getting. So I began to collect this all in the spreadsheet, it grew and grew. Soon it outgrew the spreadsheet and migrated into a database.

The more data was in there, the more data I wanted. It expanded to course maps, it expanded to GPS traces, it expanded to even webcam images. Today, it is a 4GB database with 1.2TB of images/data and code base of 800+ files.

What about that magazine? Every year a new edition of this magazine was released and every year the number of total resorts would go down. This year, the magazine reported that there are now 391 ski resorts remaining in Japan. Snowline does count a few more because of the way we classify what constitutes a resort.

I'm building this because I want to use it. If only one person, myself, found it useful, it would of been worth it. The act of building it helped me understand these ski resorts more, find these small ones only a few people know about and plan these weeks long road trips to hit these resorts to fulfil my goal of riding all the resorts in Japan.

After about 1GB of transfers for Github Packages, it will "run out of quota" and you'll get a 403. I thought it was an authentication issue, so I racked my brains on why the Github Access Token was not working. But an authentication error will give you a 401.

Staying in Akakura, we had to at least try a day in Akakura, even though it’s not such an interesting mountain. Moreover, there must be a discount our hotel can offer us.

It was complicated.

Akakura has two resorts, the Kanko, and the Onsen. If you only do the onsen side, you can get a ticket just for that. And that’s what most of the hotels sell you, discounted tickets for JUST the Onsen side. The Akakura Kanko, Akakan if you will, is owned by the luxurious hotel up at mid mountain. Legend has it that the previous Japanese Emperor stays there for vacations. So no one has a discount except for guest at their fancy hotel. You can get a combined ticket for ¥6000, which isn’t too much, but why pay 100% more for just a few more lifts?

This particular day wasn’t spectacular, and our main event was to see my friend’s kids learn how to snowboard, so really we needed just to stay on the part of their resort they were in. Akakura Onsen it is then.

That’s where it started to go down hill. First, on paper, this place has 12 lifts! Twelve is a lot for a Japanese resort. Even Akakan only has 5. However, on the day we were on the mountain, only half the lifts were operating! Times are tough, so let’s give them a pass.

We started on the left side and slowly made our way across to the right. Once we got to the right, we got another punch to the gut. The high speed quad on the right hand side broke down. Our only way to get back to the other side of the mountain. So no way back, apart from the bus.

It was a packed powder day, there were some untouched patches here and there where we duly ruined. If you look at the map, it’s mostly green runs. And definitely can confirm, it’s a beginner’s mountain.

The top lifts were open unlike the previous day we were there. We thought the strategy would be to go where others hadn't gone yet. Every year I go to Sugi, every year I regret going to the top runs. They're much steeper, more bumpy than the runs below. Sure enough, every time I go, every time I get disappointed. 

In the end we went back down to the Panorama runs and did the trees and the wide open mellow fields of powder. Still lots of powder lines to be had on a blue bird day.

The other reason I like Suginohara is because not all the restaurants on piste are operated by the resort itself. At the bottom of the high speed lifts is a set of three four restaurants that are independent, my favorite being the St Anton. Along with delicious Japanese pork cutlet and the usual, it features a caramel popcorn machine!

Sugi hits all three in my book. The Panorama and Dynamic courses both end up on the High Speed Quad. Panorama is a super wide run, you can see the run from miles away. It's so wide that it's what I used to recognize as Sugi when I'm spotting ski resorts around Nagano.

It was snowing all day, and every run there were fresh lines to be had, the groomed run was being buried under the snow. So much snow was coming down during the day that we broke for lunch and came back out to nearly fresh lines, even better conditions then at the start of the day. Even though the top lifts were not open, it didn't matter at all.

To be honest, it was a pretty ordinary day, we had a pretty relaxed go around the place, left a little early and was treated to a Hong Kong style Egg Waffle at the based of Mitsumata!

It's a sort-of-powder-day! Hey, not bad for December. It was snowing quite a bit on the mountain the day before, so I was getting excited about getting out early to the lifts. 

All my training getting up early at 5am for early morning meetings this year is now paying dividends. Getting to first lifts is easy for me. I went out as early as I could, though I didn't manage to get the first ropeway up. A lot of people showed up ahead of me on the way to the ropeway. The mountain ended up not getting too much new snow overnight though.

A few areas were still closed off, including what I considered the best area in Kagura, the Kagura Lift 5 that only opens for half a day, on a good day. On windy days they don't even bother. Neither for early season like today. This area is where you can drop through the trees into a huge open bowl that lands you back somewhere within the resort. Alas, it is not running.

Instead, I used the opportunity to try to ride the whole mountain. Even though I've been to Kagura a few times, I never managed to ride all the way across from end-to-end. After what seemed like a never ending series of lifts, I managed to get all the way to the far end of Tashiro. At this end there is a dramatically named Dragondola, a gondola that connects Kagura to Naeba. I was disappointed the gondolas were not shaped like a dragon.

On the Tashiro side, there were a few powder stashes and we rode around as a large group through the trees, destroying any smooth untouched powder we could find. I'd rate that a powder-ish day.

One of these are my lines:

A warm up trip before the main part of the season. This is the last week of December, usually considered a little too early. Conditions down in Honshu are usually a bit iffy at this time of the year. Going to Kagura is usually a good bet. Kagura is quite high up in elevation, so if there is any snow, Kagura will get it.

Yuzawa Kogen, Niigata, where Kagura is located, was not getting much snow at the start of the season. Many of the resorts in the area had snow cover but were delaying opening this week because it wasn’t enough.

For this trip, I'm driving from Tokyo to Kagura. Driving to the snow from Tokyo requires getting a car with snow tyres. As it rarely snows in Tokyo, rental cars from Tokyo don't usually have snow tyres. Finding those gems in the haystack, where the haystack is the unusable mess that are rental car company websites, can be a time consuming chore. In the last three years, I've been using this one branch of a popular car rental company here called NicoNico which surprisingly always has cars that come with snow tyres. They actually call these tires studless tyres, but that's too much of a rabbit hole to go down. 

The drive itself is about 4 hours, probably an hour less if I lived in northern Tokyo rather than the south. It's a pleasant drive, on the expressway for all but the last 20 minutes. Excitement built as we started seeing snow on the road.

We got there around 10am, so not even close to first lifts, but it looked like the conditions were pretty good there. I've been to Kagura on 3 separate trips, but never this early in the season. Surprisingly, there's some fresh powder lines to be had on our run.

Bonus was it started snowing during the day, so already I was getting excited about tomorrow. I had to remind myself that today is really getting to know my snowboard again after a season apart.

I spent the last two years exploring ski resorts by myself from Nagano to Iwate. Managing to get 56 different resorts (out of nearly 400 in Japan). This year was the first time I got to share some of my gems with friends, ride some amazing powder and experience surprises from off-the-grid resorts to the super-popular.

Starting tomorrow, I’ll be recapping the days I’ve been at the snow, powder days or not. 🏂

Background

I realized recently that the proliferation in ML techniques, tools and models presents a huge change in the tech industry. We're probably several years out from when ML is ingrained in software development, much like 15 years ago with the launch of the iPhone, mobile application development.

As a software developer (engineer), I wanted to understand this space, not just through using Midjourney, Dall-E or whatever new popular ML model outputs, but understand how to implement them, what are the easy and difficult parts of them and use that information to understand the potential of this space.

The Project

I wanted to do something that was a mix of some of my past experiences together with exploring the space using ML. I decided to try use the same image generation techniques that are present in image generation services but using it on a smaller domain of images, mobile screenshots.

The idea is to create my first trained Generative Adverserial Network to generate plausible looking screenshots of mobile apps.

Process & Tools

The data I'm using is the Rico dataset which consists of a corpus of around 60,000 Android screenshots from around 2017. This is not very recent, but its a large enough database for my first attempt.

The ML library I'm using is Keras & Tensorflow, mostly because that is the one I'm most familiar with. For the environment, I'm using Google Colab. Google Colab is a great choice because it's relatively inexpensive on the Pro plan to get access to a GPU for training purposes.

I've also started exploring some different ML ops tools that are starting to popup, including Hugging Face for access to a wide range of user-contributed datasets, Neptune and Weights and Biases for training tracking.

Learnings

For any type of problem in ML, there are numerous tutorials online. GANs are no different. There are so many different ways to do it, I followed the three most promising ones and combined parts that I liked.

I decided to begin at a small size and work my way up, looking at generating a 64x32 image, which is roughly double the size of the MNIST datasets that most tutorials use as their example data set (28x28).

The first attempt I made at this, I essentially trained a noise generator that just would not produce anything that resembled a screenshot at all. I really couldn't understand what I was doing wrong. ML models are hard to debug on their own, but with GANs being a combination of two different models, it's even harder to figure out what was wrong.

The problem here was there isn't much variety, and more training just seemed to cycle through different colors and splotches in the generated images.

In order to debug this, I went back through every line of the code, from how the model is constructed to the training look and looked to understand what everything was doing. When following tutorials, its tempting to just copy and modify parts you want. This turns out to be great if the dataset you have is the same. Because I'm using a totally different dataset, all the training hyperparamters needed to be different. Probably the most important is the training rate. Turns out, my training rate was 2 orders of magnitude lower than it should be, hence none of the models were getting far at all.

The models themselves were also buggy, lots of the layers in model had various scalar numbers that weren't self explanatory, it was until I read more tutorials where the authors explained more why certain numbers were chosen that I realized what they were for.

The state of the art for training GANs have also evolved since they were first introduced, people had discovered what they made them not converge or stall, and introducing improvements to it. But it was hard to tell whether those improvements were made with the tutorials I was following.

In the end, I ended up taking quite a lot of inspiration from the tutorials but tweaking them.

As I was using Google Colab, the runtime itself would occassionally disconnect (inactivity or time limits.) Even with my paid plan, this would still happen. So I had to turn how to do training checkpointing, saving model outputs to a file and restoring back the state.

Finally, I wanted to be able to monitor the state of the training outside of Google Colab, so I encountered ML tools like Neptune and Weights and Biases which provide a simple python library that allowed me to send progress metrics to a server which I could monitor during the training process.

Training and Faliures

As I had suspected, it is not easy at all to train a GAN. I did get it to start generating some decent low-res screenshots for a few attempts. Though, the quality never got to a point where I was really happy with.

It seemed like tweaking the learning rates is important as you are trying to keep the discriminator and generator error rates to be close to one another. Yet, I couldn't get mine to converge no matter how long I trained them. My takeway was that after about 50 epochs, you can generally know whether the model was working by seeing if there's any downward trend in the generator model.

When I trained this for longer, it would inevitably get worse! This was not what I was expecting, it seemed that the longer I trained it, the more the generator model would output less variety. For instance, generating screenshots for Android, I would expect quite a lot of Material Design looking apps with different colored bars, FABs, etc. But the longer I trained the model, the more white/grey looking it would become.

When I trained it to produce higher-res images, like 128x64 (4x the size), the model would experience Mode Collapse, which is that it would stop generating variety of different images to fool the discriminator, but it would zero in on only several variations. This meant that the results looked very similar to one another.

Next Steps

I'm going to continue to learn how to create a properly working GAN for my small domain set. The things I'm going to try is to learn more about data processing of the data set to balance it more.

Maybe will work on training it with a much smaller but cleaner dataset to see whether I end up with something better.

This will mean some time to explore image labelling and improve the image loading code that I have with my demo.

The goal is to get the model to the point that it can generate some good enough plausible screenshots that I'd share a demo of it.

I’m writing this from Tohoku, those snowy and cold prefectures at the northern tip of Honshu (main island). It’s been a dream of mine to travel around here and experience the mountains of Tohoku.

This is my first time snowboarding in Tohoku, it is something I’ve been trying to do for the past two years but have failed. First attempt was in 2020, I planned out a two week ski trip out in Iwate with friends. But because of the terrible snow season that year, we made a last minute change of plans and went up to Hokkaido (Kiroro, Furano and Asahidake). The following year, in 2021, I had plans to do a few weeks in Zao Onsen and further north, but got injured in Togari Onsen, Nagano before I could realize my plans.

The resorts here are surprisingly less well known than their Nagano and Hokkaido counterparts. In terms of travel time, these places are just as quick to get to from Tokyo, even quicker than Hakuba or Hokkaido. Because these places are less well known to foreigners, they don’t have the style of accommodation like serviced apartments or AirBnbs.

It’s snowy here. The mountains though generally lower than ones in Nagano, but not as low as Hokkaido, yet still receives plenty of snow. Aomori City is one of the snowiest cities in Japan, Geto Kogen in Iwate boasts the highest snow depths in Japan, while Zao Onsen in Yamagata is famous for their field of snow blasted trees in February resulting in some amazing scenery. Not to mention, Hakkoda Ropeway in Aomori, a backcountry mecca.

So this is a bit of a problem, maybe what I can do is isolate the light and move it around instead and capture each light separately? I’m not quite sure what to do.

As I’m modifying the lights, I realized that I am using a directional light, point light, hemisphere light and the ambient light. So that’s a lot of lights. The hemisphere light is not really needed here, I think it was there just for my experimentation. The ambient light needs to be there for global illumination.

I don’t like the DirectionalLight though because it appears from infinity and goes to infinity so I can’t change the cut-off or frustrum so it only lights a certain area. Point light is nice but it also cannot limit to a certain area unless you change the decay.

Rather, I’ve replaced those lights with a Spotlight which I can change the frustrum and it lights it in a circular area. Changed the light to be placed at the top of the mountain at some fixed height. Likely need to move to relative to the height of the area.

A weird thing happened in the last few days where I couldn’t push my debugging console that is on Firebase. The few times I tried to push, my internet would stop working. It turns out firebase hosting doesn’t like it when I tried to deploy something like 1000 PNG files. So instead, I moved all the textures and maps on to cloudstorage instead of deploy with the firebase hosting.

The result is in Observable as a prototype which I’ll move the implementation into my codebase to run for the 3D map.

I had been looking at react-three-fiber and also trios (Vue equivalent) and I really like the declarative way to construct a scene and possibly allow for reuse. I am tempted to rewrite all my rendering code to take advantage of that model, but I’m not sure if I’ll regret it. Maybe I’ll leave that for later.

I fixed the minor issues I had after my refactoring to get my multi-mountain renderer working again — this time, instead of rendering just a few mountains, its rendering 300 mountains which makes it really slow. The whole render took 11 minutes to do, without any of the trees and lift lines! This is a proof of concept render to see if I could render that many mountains in the scene. I had to make a few adjustments like expanding the clipping plane.

A few things are missing still, obviously the models that sit on top of the mountains, and also the texture maps I want to put on the top. I’m expecting that adding those will increase the render time more. I want to add back the shadows by adding a light per mountain, or maybe just faking the shadows using ambient occulsion. I’d like to figure out a way to draw a perspective label on each mountain.

The final piece which I’m using Observable to do, is to develop an algorithm to place each mountain in the scene. Right now the mountains are all in a grid which already looks nice, but I want to make it a little more packed, more space around the big mountain like Shiga Kogen and less space between the tiny mountains.

There’s enough manual things I’m doing already with collecting the data that I want the rest of it to be algorithmic as much as possible.

I went and tried to play around with Observable. I’m a heavy user of d3, and think Observable is probably the best designed data-vis platform around, built by the creator of d3. I used it to prototype my initial rendering of the Japan outline so here I’m going to try use it to play with different layout algorithms.

The first thing though was just to get the data to load, so I built up a way to just draw the rectangles that represent the size of the resort. I draw out all the rectangles manually on my “data input days”, so it’s nice to see them all in one map, like a ski resort constellation.

It’s such a thing of beauty to see it all working. However, I encountered a weird bug and resulting knowledge.

All the bounding boxes for the ski resorts are drawn by hand myself. I have been steadily using an open source GeoJSON editor to allow me to draw shapes on a map that I then export into GeoJSON, stored in a database (Firestore). For this visualization, I exported all that data into a single GeoJSON file and loaded it in. Once loaded, I used d3-geo to map the lat lons to screen coordinates, output an SVG path and the label of the resort area on the map.

However, when I first did this, there were a few issues, one was that some areas would render as huge world size rectangles and second, some of the areas, the centroid could not be found using the regular path.centroid() methods. I was stumped as to why.

After a good night’s sleep, I imagined that maybe the Polygon vertices had directionality (aka winding rule). Since I had seen that you can define a hole that could be cut out of a polygon, I imagined that the polygons follow some sort of winding rule. And indeed, that was the reason, Since I had haphazardly draw these bounding box manually, sometimes I would draw the bounding box clockwise, sometimes anti-clockwise, and so all the anti-clockwise ones ended up being negative-space polygons causing d3-geo to get confused by them.

I used turfjs to convert the polygon into a LineString, detect whether it the clockwise-ness booleanClockwise and then reverse the order of the points if it was. That fixed the problem for me. And so now I have a beautiful collection of bounding boxes.