The last time I posted on this blog was in July 2023. At that time, I had taken a three-month break and was ready to start a new job, full of ambition and looking forward to the future.
As it turned out, I left ByteDance after exactly one year, on August 1. I was in the Aeolus team, working on a data visualization product. The main reasons for leaving were related to scope and ROI issues:
Having goals is a good idea, and it’s even better to pursue them.
Last year, around this time, I came up with the idea of an “open diary” concept. It allows people to keep an open diary as a review and share it like a blog post. I wrote my first post back then, and now it has been a year.
However, I think that’s okay.
In the recent 2 days, I’ve spent some good time setting up this blog site… here’s the rough timeline:
gh-pages branchSummary from my experience, I think there’re a few learning points:
How it looks (in Ubuntu) in Startup Menu:
How it looks when opened as an App (electron-apps-ubuntu.png)
I recently started using a Ubuntu Desktop. However, quite a few apps are missing in Ubuntu.
Therefore, I have to use their web version.
Electron runs chrome internally, but we can run it like a desktop app. ()
When working in big companies like Grab, lots of times I’m just solving some simple CRUD.
Meanwhile, lots of my time needed to be spent upon different other things:
Turns out, there’re also other teams, solving the same problem again and again. This pattern has several issues:
When creating a merge request, we need to include more context information:
A pain point of reviewing a merge request, is to understand the context. The context includes:
These context should be communicated properly, so that the reviewer can actually have a clue to justify if the change is necessary & sufficient. Otherwise, the reviewer would have to eye-balling each change, and try to guess why such changes are needed - this is time consuming. With these cognitive overheads, reviewer would tends to:
When writing specs, I think the spec should describe implementation result, but not the implementation detail.
Take the ruby code below for example:
def add(a, b)
a + b
end
one can test like:
expect( add(1,2) ).to eq(3)
that’s testing the result; but if one write test:
expect( add(1,2) ).to eq(1+2)
that’s testing the detail.
The problem with testing the detail is that… say if the dependent method,
:+ got changed, then the result would actually be different, but the second
spec would still pass.
CSRF(Cross Site Request Forgery) is an attack that forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated.
In this post, I’ll explore, in the source code level, how Rails protect itself
from CSRF. It has two checks: based on token, and also the origin header.
We’ll first look at how rails put the token into the page, then see how the token is checked.
One should always reflect upon himself… to keep on the right track, to find out and correct mistakes, and to the greater self-awareness.
– by Myself.
I have been reading a lot this year. Not only the Tech Specs (which I always do), but also the blog posts (which I often do), as well as the books (which I mostly started this year only). To make my statement stronger, here’s a list of books I’ve read this Year. (I’m recording them down because there’s a line stating “to read more than 50 books this year” in my new year resolution).
I was reading about the book
Here’s the picture after the talk:
I prepared like.. 40 slides; and here’re some of my short insiprations.
Steamer Machine is the first machine age.. because the level of development of our human world boost right its invention.
Then the second machine age starts with Information Technology. It has the following characteristics: