May Day holiday week, why are vacations 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 stuck with me:
-
那些年，那些学了也没用的知识【让编程再次伟大#5】
Algorithms/optimization aren’t that important, because the initial architecture design already decides the performance ceiling.
If you zoom out to the whole company, code becomes even less important. The stuff that brings real money (business/market) is what matters.
As long as you can sell it, even if the product is a pile of shit, people still have to pinch their nose and eat it(e.g. Snowflake, slow as a snail).The author also gave an example: if you need to analyze a 100GB log, the best approach isn’t some “advanced” distributed log analysis system, but simply buying a 128GB RAM stick and reading everything into memory.
The latter approach has a simple architecture and is easy to maintain. Also, finance will like it, because that 128GB 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 finished most of chapter 3. Only the last bit about streaming is left.
This chapter finally talks about the common Object-Oriented Programming (OOP). Based on the Functional Programming foundation in the first two chapters, it introduces state (status) via assignment and mutable variables, turning a program that is “same input => same output” into a program where “same input can produce different outputs depending on runtime state”.
Compared to functional programming, the OOP approach can do more things, but… it comes with a cost.
A program that used to behave predictably can now produce different results depending on state, and its behavior becomes hard to predict (this chapter feels like it spends a lot of time discussing how to keep state under control so it doesn’t create chaos).
By the time I got further in, I started wondering: the benefits of OOP seem far from enough to offset the complexity it introduces, and the time/energy spent dealing with that complexity.
Maybe it’s because I haven’t written any large systems yet. Is it that once a project gets complex enough, the functional style stops working and you can only do OOP? I don’t have enough experience to judge yet.
But since I started learning programming in 2023, when reading Eloquent JavaScript and other materials, people were constantly emphasizing immutable variables and no side-effect.
In a typical learning path, whether school or bootcamps, you probably start with OOP (and most likely only learn OOP), maybe because it’s easier to imagine?
But in SICP, it starts by drilling Functional Programming and recursive. I didn’t even notice that in the first two chapters, variables don’t change, which is a very important thing in functional programming.
Only when chapter 3 introduces state do variables truly become mutable variables.
So in SICP, Object-Oriented Programming is actually a more “complex” concept than Functional Programming, which is the complete opposite of the common impression that “functional programming is abstract and hard to understand”.
I find that pretty 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 doesn’t pay much, doesn’t improve my skills, and still takes up most of my time and energy.
Working feels like such a bad deal, but for the visa, I have no choice but to sit in this immigration limbo…
Hard.
Output
Astro Tutorial
As I said at the beginning, I finished Astro’s official tutorial Tutorial: Build a blog and built a static blog as practice.
The result is on GitHub: KassadinL - astro_tutorial
Compared to the official tutorial, it additionally supports Mermaid diagram, so you can draw diagrams directly in Markdown with code blocks.
Next I’m going to migrate this blog to Astro for real.
I’ll pick a decent theme and migrate first, and polish details later.
Otherwise I’ve procrastinated for so long that if I keep delaying, who knows when it will ever be done.
Travel
Enoshima
I originally wanted to go to Kamakura, but got off at Fujisawa, got on the Enoden (Enoshima Electric Railway), and we were like, “Let’s stop by Enoshima and take a look.”
Enoden really is perfect for taking photos and checking in.
Heisei year 1, meaning this train was made in 1989.
But in Japan I almost feel embarrassed calling it old. It’s only 36 years old, basically just reached the age where it gets “optimized” (laid off).
After getting off, we wandered around a bit and saw a small hill nearby, with just the tip of a temple tower peeking out, so we headed that way.
Saw a lot of birds with huge wings. No idea what species.
Enju no Kane (longevity bell). Somehow it hasn’t been smashed to bits.
When I saw this little house, my first thought was “a small bridge, flowing water, and a cottage”. No bridge, no water, but it has that quiet vibe.
Overall, my impression of this temple was: the garden is so refined, the vegetation is rich, and it’s very tranquil. It feels like being separated from the worldly bustle down the mountain.
This kind of refined scenery must cost a lot. Monks are rich (
After walking around the temple for a while, we ran to Enoshima.
May Day holiday week: crowds upon crowds upon crowds.
From halfway up the hill: tons of people on the bridge and in the small alleys.
Bocchi the Rock. Bocchi-chan.
Bocchi-chan in slime form.
Alcoholic.
I saw a lot of Bocchi the Rock ema (wooden prayer plaques). Only later did I recall there really is an episode where the four of them come to Enoshima.
But the anime scenery is way prettier: blue sky and white clouds, clean and tidy spots, bright and cheerful colors.
Today was cloudy. The whole sky was gray, and everything on the ground and the buildings also felt gray. Enoshima looked kind of shabby and poorly maintained.
Another thing: the anime did a “reverse scam”. The four of them looked like they were dying from climbing the hill, even debating whether to take the elevator.
So I thought this mountain must be tall. In reality, I came today with a camera in hand, and before I even got warmed up, I was already at the top.
That’s it? Just these steps and you call it hard? You need an elevator? And that elevator can even break even? Unbelievable.
This is probably also a popular photo spot, but the weather wasn’t great.
Some tower-ish thing on top of Enoshima.
By the time we left the island, it was already evening. Let’s watch the sunset for a bit.
But thick clouds blocked it, so we could barely see anything.
No time for Kamakura this time. Next time then. We will definitely come back.jpg
Misc
Skipped.
Closing
May’s Monthly Log, as usual, got dragged all the way to the end of June. I originally planned to start the blog migration right after finishing the May Monthly Log, but I procrastinated for a full month.
Can’t keep delaying. I’ll just slap something together first.
Next time you see me, it’ll be a new style. お楽しみに〜 (or… maybe don’t expect too much?)