Golden Week, why are holidays always so short?
Post Structure
-
Input
Learning: books/novels/good articles, videos/podcasts, any format, anything that feels rewarding after finishing
Anime: new shows / old shows, TV season / movies, notes on what I watched
Others: movies, TV series, etc., put here -
Random Thoughts
Maybe I will write down whatever I’m thinking -
Output
Maybe a blog, but I’m not good enough, so maybe I have no output for a whole month (lol) -
Travel
If I went somewhere, I’ll jot it down. If not, then whatever -
Misc
Small things that don’t fit in the categories above
Input
Learning
Astro Tutorial: Build a Blog
Getting ready to migrate the blog framework from Hexo to Astro.
Why Astro
I don’t really have any complaints about Hexo. I just wanted to learn some frontend stuff recently, and happened to run into the framework called Astro.
It started a few weeks ago when I saw this post: maple3142 - 把部落格從 Hexo 遷移到 Astro, which explains the migration process in detail. After reading it I felt like I could do it too.
Before that, I had also seen a few blogs built with Astro. They felt really smooth, and when I clicked the footer links, yep, Astro. For example: Frost’s Blog (quietly filing Astro away in my brain).
The official docs Astro Docs - Why Astro? says “zero JavaScript by default”, basically just HTML + CSS, so it’s naturally fast.
Beyond that, what attracted me most is that Astro can use its own components, and also mix multiple frontend frameworks together: React, Preact, Svelte, Vue… You can even use different frameworks for different components. You’re not locked into one ecosystem, which makes migration easier (doesn’t that mean I can learn React, Vue, and Svelte all in one project? that’s insane).
Start with the official tutorial: Build a blog
Astro’s official tutorial Tutorial: Build a blog walks you through building a static blog step by step.
If you follow it once, you should be pretty much good to go.
I put my result on GitHub: KassadinL - astro_tutorial. Compared to the official tutorial, I added Mermaid diagram support, so you can draw diagrams directly in Markdown with code blocks. Very elegant (
YouTube 原子能
As mentioned above, Astro is “zero JavaScript by default”, so it’s very fast. Recently I happened to see a video from a tech creator on YouTube.
-
在你不知道的角落，前端的未来正在回归本源【让编程再次伟大#27】
The video says the trend in frontend in recent years is to return to HTML/CSS/JS: ditch layers of abstraction and use native Web APIs.
JavaScript has also been getting proposals that make development easier, likeTemporal(native time handling) andSignals(syncing data changes) to minimize re-rendering.There are also some new directions in frontend frameworks:
- Svelte: replacing the older-generation APIs of React/Vue with more native interfaces (e.g. React’s Virtual DOM)
- Lit: using native Web Components
- Htmx: a frontend framework implemented in 5000 lines of JavaScript (seems a bit ahead of its time; I don’t really understand it yet)
I found this creator pretty interesting. I’ve been watching more of their videos on and off, and got a lot out of them.
The biggest takeaway is that local algorithm optimizations aren’t that important. If you look at things at the architecture level, there are more optimizations you can make, and the effect is obvious.
Going further: if you understand the business and the market, you can lead projects, manage upward, or influence clients. That’s the best.
A few videos that stayed with me this month:
-
那些年，那些学了也没用的知识【让编程再次伟大#5】
The point was that algorithms and low-level optimization are not nearly as important as people like to pretend, because the initial architecture already sets the ceiling for how far performance can go.
And if you zoom out from the codebase to the company as a whole, code matters even less. The things that really bring in money, like business and market positioning, matter far more.
If the thing sells, people will still pinch their nose and use it even if the product is garbage(for example, Snowflake, slow as a snail).He also gave an example: if you need to analyze a 100 GB log, the best answer may not be some “advanced” distributed log analysis system at all, but just buying a 128 GB stick of RAM and reading the whole thing into memory.
That solution is architecturally simpler, easier to maintain, and apparently even easier to justify to finance, because the RAM stick can be booked as an asset.The performance chart above also showed up in a similar discussion elsewhere: Telegram - codedump 的电报频道
Andrej Karpathy 的一条推：
A major mistake I made in my undergrad is that I focused way too much on mathematical lens of computing - computability, decidability, asymptotic complexity etc. And too little on physical lens - energy/heat of state change, data locality, parallelism, computer architecture. The former is interesting; The latter bestows power.
(A major mistake I made in my undergrad was focusing too much on the mathematical lens of computing, and too little on the physical lens. The former is interesting; the latter bestows power.)My quick take.
The mathematical lens is the classic algorithm lens: analyzing time/space complexity, etc.
The physical lens considers storage medium characteristics, data locality, and so on. A few examples:- LSM-like storage engines treat “write to WAL” as a successful write. This leverages the physical fact that append writes are faster than random writes.
- B-tree-like storage engines use pages as the smallest storage unit. Reads and writes happen in page-sized chunks, which leverages both bulk I/O and locality.
The famous latency numbers that Jeff Dean often mentions for different storage layers are also part of the physical lens.
You’ll often find that an algorithm can look great mathematically, but if you ignore physical characteristics, it loses its advantage. -
为什么程序员都应该学用容器技术【让编程再次伟大#26】
k8s is good stuff. Go learn it. -
为什么关系数据库的挑战者都没有好下场【让编程再次伟大#25】
Relational databases are rock solid. Go learn pg.
MongoDB is the “number one scammer in the database industry”. Stay away from MongoDB.
SICP
I’ve made it through most of chapter 3. Only the last bit on streams is still left.
This is the chapter where SICP finally gets to the more familiar Object-Oriented Programming side of things. On top of the Functional Programming foundation from the first two chapters, it introduces state through assignment and mutable variables, turning a program that used to mean “same input, same output” into one where the same input can lead to different results depending on the current runtime state.
Compared with functional programming, OOP can definitely do more. But… the bill comes due.
Once state enters the picture, a program that used to behave in a fixed and predictable way can start behaving differently from run to run. A lot of this chapter feels like a long discussion of how to stop state from turning the whole system into a mess.
The more I read, the more I started wondering whether the benefits OOP brings are really enough to offset the complexity it introduces, plus all the time and energy spent managing that complexity.
Maybe that reaction is just because I still haven’t worked on anything truly large. Maybe once a system gets complicated enough, the functional style stops being practical and OOP becomes unavoidable. I honestly don’t know yet.
Still, ever since I started learning programming in 2023, whether in Eloquent JavaScript or elsewhere, I kept running into the same advice over and over again: use immutable variables, avoid side effects.
In a normal learning path, whether at school or in a bootcamp, you probably start with OOP, and often stop there, maybe because it feels easier to picture.
But SICP does the opposite. It starts by hammering in Functional Programming and recursive thinking. I didn’t even notice, through the first two chapters, that “variables do not change” is itself one of the most important parts of the whole approach.
Only in chapter 3, once state appears, do variables actually become mutable.
So in SICP, Object-Oriented Programming ends up feeling like the more complicated idea, not the more intuitive one. That’s almost the exact reverse of the usual impression that “functional programming is the abstract, difficult stuff.”
I found that surprisingly interesting.
Speaking of OOP drawbacks, this also reminds me that Eloquent JavaScript mentioned Don’t overuse inheritance.
Because the common inheritance in OOP increases coupling between modules. When inheriting from a class, you must understand the parent class in detail, which goes against the black-box idea.
On the other hand, encapsulation (aka abstraction) and polymorphism can reduce coupling between modules, so you don’t have to care about the internals of the black box, only how to use it.
Inheritance allows us to build slightly different data types from existing data types with relatively little work. It is a fundamental part of the object-oriented tradition, alongside encapsulation and polymorphism. But while the latter two are now generally regarded as wonderful ideas, inheritance is more controversial.
Whereas encapsulation and polymorphism can be used to separate pieces of code from one another, reducing the tangledness of the overall program, inheritance fundamentally ties classes together, creating more tangle. When inheriting from a class, you usually have to know more about how it works than when simply using it. Inheritance can be a useful tool to make some types of programs more succinct, but it shouldn’t be the first tool you reach for, and you probably shouldn’t actively go looking for opportunities to construct class hierarchies (family trees of classes).
Anime
-
末日后酒店
cy 王朝. The script and production both feel effortless.
Episode 6 was god-tier: romantic and restrained. I really like this approach. -
Summer Pocket
Up to episode 6. The production is okay, but still a bit rushed. The plot progresses too fast. -
时光流逝，饭菜依旧美味
Watched two episodes. Not bad. -
忍着与杀手二人组
Watched a few episodes, but I don’t really feel motivated to continue. -
高达 GQuuuuuuX
Haven’t watched the TV version at all ( -
mono 旅
The 360 camera is ready,so where do I pick up the friends to go out with? -
Witch Watch
Watched a bit. I’ll watch more when I have time. -
ざつ旅
Watched two episodes, but it felt boring. Dropped.
Others
Recent dramas/movies I’ve watched. I’ll try not to spoil too much.
無名の人生
An indie animated film. I didn’t quite get it, especially the later part that suddenly jumps into near-future sci-fi. Also I’m not that into idol-themed stuff.
Random Thoughts
This job pays little, teaches me little, and still swallows most of my time and energy.
From any normal cost-benefit perspective, working feels like a bad deal right now. But for the visa, I still have to sit through this immigration limbo.
It’s rough.
Output
Astro Tutorial
As mentioned at the top, I finished Astro’s official tutorial Tutorial: Build a blog and built a small static blog as practice.
The result is on GitHub: KassadinL - astro_tutorial.
Compared with the official tutorial, I also added Mermaid diagram support, so diagrams can be written directly in Markdown code blocks.
Next comes the real migration: moving this actual blog over to Astro.
The plan is to grab a theme that’s good enough, migrate first, and polish the details later.
I’ve already dragged this out for way too long. If I keep trying to perfect everything before starting, I’ll probably never finish.
Travel
Enoshima
I originally meant to go to Kamakura, but after getting off at Fujisawa and boarding the Enoden, we looked at each other and went, “Why don’t we hop off at Enoshima and take a quick look?”
The Enoden really is great for photos and check-ins.
Heisei year 1, which means this train was built in 1989.
But in Japan I almost feel embarrassed calling it old. It’s only 36 years old, basically just reaching the age where it gets “optimized” (laid off).
After getting off, we wandered around a bit and spotted a small hill nearby, with just the tip of a temple tower peeking out, so we headed that way.
Saw lots of birds with huge wings. No idea what kind they were.
Enju no Kane, the longevity bell. Honestly impressive that no one has smashed it to pieces yet.
The moment I saw this little house, the phrase “small bridge, flowing water, humble home” popped into my head. No bridge, no water, but it has that same quiet feeling.
My overall impression of the temple was that everything felt carefully maintained: delicate gardens, dense greenery, and a kind of quiet that made the hill below feel very far away. Almost like it was cut off from the mundane world down there.
Keeping a place this refined in shape must cost a lot. Monks really do have money (
After wandering around the temple for a while, we headed for Enoshima proper.
Golden Week: people, people, and more people.
From halfway up the hill, the bridge and the little alleys were both absolutely packed.
Bocchi the Rock. Bocchi-chan.
Bocchi-chan in slime form.
Alcoholic.
There were a lot of Bocchi the Rock ema, and only afterward did I remember there really is an episode where the four of them come to Enoshima.
That said, the anime version looks much nicer: blue sky, white clouds, clean tourist spots, bright colors everywhere.
We got a cloudy day instead. The whole sky was gray, which made the ground and buildings feel gray too. The real Enoshima ended up looking a little run-down, like everything had aged in place.
Another thing: the anime was a complete reverse scam.
The four girls looked like that hill was going to kill them, to the point that they were seriously debating whether to take the elevator.
So I came here assuming it must be a proper climb. In reality, I showed up with a camera, barely got settled, and was already at the top.
That’s it? You were suffering over this many stairs? You need an elevator for this? And the elevator still manages to stay in business? Completely baffling.
Probably another popular photo spot, but the weather really wasn’t helping.
Some tower-like thing on top of Enoshima.
By the time we left the island, it was already evening. We figured we’d stay a bit and catch the sunset.
But thick clouds blocked it, so there was barely anything to see.
No time for Kamakura this round. Next time. We will definitely be back.jpg
Misc
Nothing much to say here this month. Skipped.
Closing
May’s Monthly Log, as always, ended up slipping all the way to the end of June. I had originally planned to start the blog migration as soon as I finished writing it, and then still managed to waste another month.
I really can’t keep dragging this out. Better to post something rough now than keep waiting for the ideal version forever.
Next time you see me, it should be in the new style. お楽しみに〜 (or… maybe don’t expect too much)
Comments