คำเตือน: blog นี้ยาวมาก พยายามจะเล่ารายละเอียดให้ได้มากที่สุด เผื่อเป็นประโยชน์ให้คนกำลังวางแผนจัดงาน ผมจะเน้นในมุมมองของผู้ชาย ที่จะต้องขอผู้หญิงแต่งงานเป็นหลักนะครับ ผมจะเล่าเป็นเรื่องราว ไม่ได้เล่าเป็นโครงสร้างแบบเข้าใจง่าย
หลายคนไม่รู้ว่าจะต้องเริ่มยังไง ต้องขอผู้หญิงแต่งงานก่อนหรือเปล่า ผู้ใหญ่จะโอเคมั้ย ต้องทำอะไรก่อน ในตอนแรกก็งงเหมือนกันครับ แต่ก็ได้คุยกับหลายๆ คนที่แต่งงานไปก่อนหน้า ถามเค้าว่าเค้าทำอะไรบ้าง
So you want to migrate legacy systems that no one knows in detail and no one wants to touch it. That system might be very brittle, cause a lot of trouble, can't scale to handle the business growth, and your team doesn't want to deal with that anymore.
One day, the team was in the room to discuss fancy ideas of how we can change the system, and how we can utilize amazing modern technologies. Someone shared their own experiences about the best way to achieve the migration without causing too much pain, burden, and issues to the team.
The system was just 3-tiers monolith architecture — Mobile app, API server, and DB. The team decided to move forward with microservices with a fancy horizontal scalable database, a cache server, and a centralized message queue for event-driven applications.
Woah, that's too many changes! Should you do that? Is that possible? Or how could we possibly make that? Let's find out.
This part in #careers, I will write about the way to effectively acquire skills which help accelerate your career progress. I wrote about my own progression framework, which consist of 2 major key points — skills and scopes that play a vital part of prohibiting or allowing anyone to grow.
TL;DR: Acquiring skills by doing the real job. Always keep looking for more challenging tasks, projects, and expand scopes. Asking someone more expert to be your mentor and learn from them.
I have done some experiment about knowledge sharing. I shares knowledge, interesting topic, trends to the team regularly (e.g. weekly or bi-weekly). Here's what I did and observed.
I've talk with many people — engineers in my company, candidates in interview sessions, meetups, etc. They are often excited about new technologies, frameworks, tools and eager to learn, try, and talk about it. They may listed those tools as what they have experiences in CV. This is good but I think that over the half of those people are “tools' user” — who know how to use tools but don't understand it deeply.
There's types of task's complexity that engineer will have to solve. CRUD or defined business workflow maybe classified as “Clear” so any engineer can simply write a program in a very straight forward way and this type of task is suitable for junior level.
This is going to be a very long post series in #careers. It started from a discussion among my engineering manager team as well as my observation to individual engineers. There's a challenge for anyone who don't know exactly how to advance their career. Even a company provides a guideline, some of them still struggle to actually make progresses.
I'm going to be a stereotype here. I'm pretty sure it won't cover all the cases, it’s just for simplicity and I hope that it should cover at least 70% of the cases.
I divided the problem into 2 sub-problems: Lack of skills and Lack of scope.
Each of these problems could be fixed independently. I'll write more about what I believed a learning process should be. The important thing that you should know is fixing these problems is not a sequential, but it is a cycle to fix a little bit of each sub-problem many times.
I've just bought a new laptop, Lenovo ThinkBook 13s Gen 4, which I think it's lightweight, with good performance (AMD Ryzen 7 6700u), last-long battery, and it's not too expensive.
There's a problem with keyboard, which at first, I think the laptop might have a defect from manufacturer but it only happen when I'm using on Linux. I was trying to plug external USB keyboard after I installed Linux and It's fine.
I search through internet and found this thread. Turns out it was a bug in linux kernel with new AMD Ryzen platform. Somebody who use Arch linux can apply patch by themselves but for me I use fedora so I have to find a way.
Config needs restart to be updated, static, stored in file, override by env variable, small number of config
Example: DB config, server listen port, remote host location
Feature flag and settings can be changed at runtime without restart or down time. Both are similar but I want to draw a bold line separate them.
Feature flag is temporary, has to be clean up or removed someday in the future. It is about roll out, release, use context to decide who, when, where, which version to enable which can be apply to users partially, or globally. It is usually controlled by engineers, or technical operation team.
Setting is permanently. It has been designed to be in the code without creating technical debt.
It likes a feature which has a real user use case for example to adjust behavior of the system.
It should be safe to be uses, changes, enables, disables in numerous times. It should be test throughout.
Any feature flags that has been rolled out and stable, can be transitioned to setting such as kill switch.
Example: Site title, User role & Permission, Look & feel, Content to be shown
Below is a comparison table:
| Config | Feature flag | Setting | |
|---|---|---|---|
| When to changes | Before start | Runtime | Runtime |
| Lifetime | Temporary/Permanently | Temporary | Risky, moderate tested |
| Safety | Very safe, well tested | Permanently | Safe, well tested |
| User | Engineer/Operator | Engineer/Operator | Normal user |
| Affects | Global/All users | Partial/Global | Global/Depends on each feature |
| Tech Debt | Low | High | Medium |
| Amount of configurable | Low | High | Medium |
| Rate of changes | Rarely | Occationally | On demand |
Related to Opinionated guide on how to write a log
I would like to write in more detail about where to put log, the benefits, disadvantages, and how to mitigate that.
I want to put a context that we're developing web services, whether public access or internal use. No matter what protocol is used, HTTP with JSON, gRPC, Thrift, etc. I think my guide may adapt to all of these kinds of technology.
So, where to put logs?
ผมพบว่ามีหลายวิธีที่จะ manage source code และ manage pull request (หรือ merge request) แต่ผมยังไม่เจอว่ามีใครเขียนรวบรวมไว้
ผมจะ focus ในเรื่องที่เกี่ยวกับ การ Approve code การ Run CI และการ Merge code
การ review สามารถทำได้ทั้ง offline และ online เช่น
กฎเกณฑ์ในการ approve code มีหลายแบบที่สามารถเลือกใช้ได้ ไม่ว่าจะ review แบบ offline หรือ online เท่าที่ผมรู้จักมีประมาณนี้
เคยลองเปิด log message ที่ตัวเองเขียนไหมครับ? รู้สึกอย่างไรกับ log เหล่านั้น? มีประโยชน์ตามที่ต้องการหรือเปล่า? และเมื่อระบบมีปัญหาลองเปิด log message อ่านดูอีกครั้ง คิดว่า log เหล่านั้นให้ประโยชน์กับเราขนาดไหน?
ผมลองใช้เทคนิคเหล่านี้ในการเขียน log มันทำให้ log มีประโยชน์มากขึ้น
ส่วนตัวผมแนะนำ log เป็น JSON format เนื่องจากสามารถใส่ข้อมูลชนิดต่างๆ ได้หลากหลาย มีโครงสร้างชัดเจน หากจะใช้ structure แบบอื่นก็ทำได้ ขอให้ parse ข้อมูลใน log ได้ง่าย แต่สิ่งที่ไม่ควรทำคือ log แบบไม่มีโครงสร้างที่ชัดเจน
ตัวอย่าง:
{"timestamp":"2021-04-21T10.30.15.412Z","level":"INFO","message":"Order created","orderId":"ORD1","userId":"U1","subsystem":"SvcName.Package.Class.Method"}