Blog by hung.dev

Q&A 01

Mon, 26 Sep 2022 11:18:27 GMT

Một bạn độc giả có nhắn tin hỏi mình mấy câu. Mình nhận thấy có thể nhiều bạn cũng sẽ có những câu hỏi tương tự. Nên mình chia sẻ câu trả lời của mình tại post này luôn.

If you were to start learning to program again, what would you learn first and from where? (I am happy if you can attach the reference)

Nếu mình có cơ hội học lập trình lại, mình sẽ vẫn học như đã làm trong quá khứ. Đó là bắt đầu xây dựng kiến thức nền tảng về khoa học máy tính (Computer Science foundation) thật chắc, trước khi học bất cứ một công nghệ nào. Cá nhân mình thấy không có khoá học introductory nào tốt hơn CS50’s Introduction to Computer Science của Harvard University, được cung cấp miễn phí trên nền tảng giáo dục edx. CS50 là một món quà của thượng đế, với cách truyền tải các kiến thức máy tính khô khan qua những ví dụ vô cùng sinh động, trực quan và dễ hiểu. Điểm đặc biệt đó là CS50 được thiết kế để dành cho những người chưa có chút nền tàng gì về khoa học máy tính. Theo thống kê, 78% học sinh tham gia CS50 chưa từng biết khoa học máy tính là gì. mình đã từng giới thiệu CS50 cho rất nhiều bạn có background kinh tế, marketing, luật, thậm chí cả cháu mình mới 11 tuổi (với phụ đề tiếng Việt), và tất cả đều feedback rất tích cực về những gì họ học được từ CS50. Đối với bản thân mình, những kiến thức tiếp thu được từ CS50 là những viên gạch đầu tiên quan trọng tạo nên nền móng vững chắc giúp mình phát triển trong sự nghiệp IT sau này.

Link khoá học: https://www.edx.org/course/introduction-computer-science-harvardx-cs50x

Review về khoá học: https://huwng.wordpress.com/2015/05/30/bat-dau-hoc-lap-trinh-nhu-the-nao-gioi-thieu-khoa-hoc-cs50/

Nguồn tài liệu tham khảo về Computer Science Foundation https://vn.got-it.ai/blog/cs-foundation-101-phan-2-nguon-tai-lieu-tham-khao-cs-foundation-hay-nhat

What is your learning path? (I don’t know what I need to learn right now)

Mình học qua vài nguồn sau:

Công việc: Công việc hàng ngày của mình cần dùng đến cái gì thì mình sẽ chủ động đào sâu kiến thức phần đó. Sau khi tìm ra solution và giải quyết xong vấn đề, thay vì chỉ push code đi về thì mình cố gắng dành thêm một chút thời gian để tìm hiểu các vấn đề xung quanh nó và đặt ra các câu hỏi liên quan. Ví dụ nếu không sử dụng đoạn code này thì có cách nào khác không? Hay tại sao lại sử dụng thư viện A và không sử dụng thư viện B? Liệu ko sử dụng thư viện C thì mình có giải quyết được vấn đề đó không? Mình có thể tự implement lại được không? Vân vân và mây mây. Ngoài ra trao đổi với đồng nghiệp qua các buổi design review/ debate hay các hoạt động như code review cũng giúp mình cải thiện khả năng implement và tổ chức code.
Mã nguồn mở: Ngoài việc tham gia các hoạt động code chung với các đồng nghiệp tại công ty, mình mở rộng thế giới quan về ngành phát triển phần mềm qua cộng đồng mã nguồn mở (Open source software - xin được gọi tắt là OSS). Khi tham gia OSS, mình sẽ hiểu hơn về các phần mềm mình hay sử dụng hàng ngày để tạo nên các sản phẩm cho công ty. Mình cũng sẽ được những engineer top đầu review code cho một cách HOÀN TOÀN MIỄN PHÍ, một điều mà hàng ngày có trả rất nhiều tiền mình cũng không có cơ hội đó được. Mình học được rất nhiều điều khi tham gia vào các hoạt động đóng góp cho OSS.
Chia sẻ kiến thức: Một điều rất hay trong cộng đồng phát triển phần mềm hiện nay đó là việc chia sẻ kiến thức. Những năm gần đây phong trào này cũng phát triển rất mạnh mẽ. Thay vì biết cái gì đó thì giấu nhẹm đi chỉ để cho bản thân mình thì software engineer họ rất thích chia sẻ những gì họ biết, ví đó là cách để bản thân họ hệ thống lại kiến thức một cách tốt nhất. Vì thế nên anh khuyên tất cả các engineer nên có ít nhất cho mình một blog kỹ thuật, để có thể ghi chép lại những gì mình biết, mình học được trong quá trình làm nghề.

Why do you love programming? What do you think about the new technologies of FE? How long will AI replace the front end? :D (I’m a bit confused about my career)

Why do you love programming?

Có nhiều lý do để mình thích lập trình, mình sẽ chia sẻ một vài lý do khách quan và chủ quan

Mình thấy nó công bằng và dễ tiếp cận. Lập trình không phân biệt bạn đến từ đâu, nói ngôn ngữ gì, bao nhiêu tuổi, làm nghề gì, tôn giáo gì, ngoại hình ra sao. Miễn bạn có một chiếc máy tính, một đường truyền internet tạm ổn và một trái tim nóng, một tinh thần nhiệt huyết là đủ. Bạn có thể tìm kiếm bất cứ thứ gì về lập trình từ internet mà không gặp bất cứ một trở ngại nào. Đúng là lập trình đôi lúc cũng khó, nhưng mình tin bất cứ ai, nếu đủ yêu thích và kiên trì, đều theo đuổi ngành lập trình được.
Lập trình rất cần sự sáng tạo. Em đồng nghiệp cũ có phàn nàn với mình rằng “Làm sao bọn anh có thể ngồi nhìn vào cái màn hình máy tính xanh xanh đỏ đỏ 8 9 tiếng một ngày được? Thật khó hiểu quá đi.” (Cái “xanh xanh đỏ đỏ” đó chính là syntax highlighting 😂). Thì cũng đúng, nhưng đằng sau những dòng “xanh xanh đỏ đỏ” đó là vô cùng nhiều sự sáng tạo trong cách suy nghĩ của rất rất nhiều lập trình viên trên thế giới. Trước mình có xuất phát điểm là học sinh chuyên toán, nên mình thích làm các công việc yêu cầu sự sáng tạo nhưng vẫn phải rất chặt chẽ và logic.
Có thể tạo ra “impact”. Với khả năng coding, mình có khả năng tạo ra các phần mềm có thể tạo ra nhiều giá trị và có sức ảnh hưởng tốt đến người khác và xã hội.
Vẫn còn nữa nhưng tạm thời thế nhớ 😂

What do you think about the new technologies of FE?

Một điểm đặc trưng của thế giới FE đó là mọi thứ move rất nhanh. Đôi khi một framework ra chưa kịp học đã có framework khác thay thế rồi. Việc này là hoàn toàn bình thường. Lý do để giải thích thì có rất nhiều, như tính “mở” của Javascript, hay việc ai cũng dễ dàng có thể publish một thư viện lên các package manager (e.g: npm) cũng thúc đẩy việc ngày càng nhiều các framework FE ra đời. Nó có cả mặt lợi và hại, nhưng theo mình thì mặt lợi vẫn nhiều hơn. Khi có nhiều người cùng cạnh tranh ở một thị trường ngách, thì người hưởng lợi sẽ là người tiêu dùng. Hãy nhìn vào hạ tầng internet tại Việt Nam năm 2022 và 10 năm trước. 10 năm trước, việc download speed lên được đến 500kb/s đã là điều không tưởng, lại còn không trọn gói. Còn bây giờ. Tốc độ download lên đến 5 hay 10MB/s là chuyện hết sức bình thường. FE frameworks cũng vậy. Càng nhiều công ty, tổ chức phát triển thì các FE engineer sẽ càng hưởng lợi. Tuy nhiên công nghệ FE có phát triển đi thế nào đi chăng nữa, thì vẫn xoay quanh câu chuyện UI có đẹp ko, UX có tốt không, page load có nhanh không, hay đi sâu hơn thì sẽ là HTML, CSS, Javascript. Hãy nắm chắc những thứ cơ bản thì không bao giờ sợ bị ngộp trước những công nghệ mới

How long will AI replace the front end?

Mình chịu. Chắc đành tử tế với robot bây giờ không về sau lúc nó chiếm thế giới rồi nó ghim mình thì chết.

Setup Jest with Vite (featuring SWC)

Mon, 14 Mar 2022 17:39:03 GMT

Motivation

Web applications are becoming an indispensable part of our lives. We can build literally everything on the web app nowadays from reading the news, composing email, learning, to video conferences, even gaming. Going hand in hand with that development is the growth in complexity and the unpredictable quality of web applications. Speaking of web application, Create React App (CRA) used to be the first choice when it comes to bootstrapping a React application and it fulfilled its duty. Now CRA is in maintenance mode and the ecosystem gives us a lot of good tools to start a React project like Vite, Parcel, NextJS… I had a chance to use Vite in my daily work and I’m very happy with that, my Developer Experience (DX) and productivity have increased dramatically, it’s blazing fast. However, speed is not the only factor to make a high quality web application. We also need tests. Even though I’m happy with Vite, it took me a while to successfully integrate Jest with Vite. In this post, I am going to setup Jest to a React Typescript Vite project (spoiler alert: swc)

You can find the final code here: https://github.com/nvh95/jest-with-vite

Integrating Jest to Vite

First, generate React Typescript project using Vite. I’m gonna using npm, you can use yarn or pnpm:
```
npm init vite@latest
```
Then, install the main dependency jest:
```
npm i jest --save-dev
```
Install react-testing-library packages:
- @testing-library/jest-dom: provides a set of custom jest matchers that you can use to extend jest (e.g: toBeInTheDocument())
- @testing-library/react: say no to implementation details testing
- @testing-library/user-event: interacts with our UI (fun fact: it can be used in production for real interaction!)
```
npm i @testing-library/jest-dom @testing-library/react @testing-library/user-event --save-dev
```
Exclude test files from typescript type checking when building for production, you don’t want a typescript error in your test file breaks your build in production.
1. Create tsconfig.prod.json which inherits tsconfig.json, exclude test files from the project:
```
// tsconfig.prod.json
{
  "extends": "./tsconfig",
  "exclude": [
    "./src/__tests__/**",
    "./src/__mocks__/**",
    "./src/test-utils"
  ]
}
```
1. Use tsconfig.prod.json when building:
```
// Package.json
-"build": "tsc && vite build",
+"build": "tsc -p tsconfig.prod.json && vite build",
```

Add a script test to package.json :

// package.json
+  "test": "NODE_ENV=test jest"

Let’s write a sample test. However, just comment out the render statement for now:

// src/__tests__/App.test.tsx
import { render, screen } from "@testing-library/react";
import App from "../App";

describe("App", () => {
  it("should work as expected", () => {
    // render(<App />);
    expect(1 + 1).toBe(2);
  });
});

Attempt to run it, this error will show up

Jest encountered an unexpected token
Jest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax.
Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration.
By default "node_modules" folder is ignored by transformers.
...
Details:

/jest-vite/src/__tests__/App.test.tsx:1
({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,jest){import { render, screen } from "@testing-library/react";
                                                                                   ^^^^^^

SyntaxError: Cannot use import statement outside a module

  at Runtime.createScriptFromCode (node_modules/jest-runtime/build/index.js:1728:14)

Before moving forward, let’s tip the iceberg on what makes Vite so fast. One of the reasons is the native ECMAScript Modules. In the development mode, build tools such as CRA bundles all of your code into a single file and serves via a dev server. Vite took a different approach by not bundling your code at all. It leverages the native support for ESM of modern browsers. It sends your file directly without being bundled.

So, Vite takes advantage of ESM, on the other hand, Jest uses CommonJS (it actually has experiment support for Native ESM but it’s not 100% ready now - March of 2022). That’s the reason why you see the error message as above when using import and export. So we have a few options here:
- Use Jest experiment support for ESM
- Use babel to compile ESM to CommonJS (similar to what CRA does)
- Use high performance build tools like esbuild and SWC
  - esbuild: created by Evan Wallace, co-founder of figma. esbuild is written in Go and it is one of core components for the speed of Vite.
  - SWC: created by Donny (강동윤), a young talent developer from Vercel. SWC stands for Speedy Web Compiler and is written in Rust. SWC is adopted by Vercel and replaced babel to be the compiler of NextJS since version 12.
I did try Jest Native ESM support but it’s not stable right now. So the safe option is just to compile ESM to CommonJS. It’s a tough decision to make between esbuild and SWC.

	esbuild	SWC
Pros	- Dependency of Vite already. So addition third party code will not be much. - @swc/jest is developed by author of swc - @swc/jest is in active development	- Used in NextJS
Cons	- esbuild-jest (which is a community package to use esbuild with jest) is not very active. The last commit is March 2021 (This post is published in March 2022)	- another library to install

Choosing a third party package is always a hard problem. So after considerations and experiments, I chose SWC.

Install SWC by this command:

npm i @swc/core @swc/jest --save-dev

Configure swc by creating .swcrc file at the root of the project:

// .swcrc
{
  "jsc": {
    "target": "es2017",
    "parser": {
      "syntax": "typescript",
      "tsx": true,
      "decorators": false,
      "dynamicImport": false
    },
    "transform": {
      "react": {
        "pragma": "React.createElement",
        "pragmaFrag": "React.Fragment",
        "throwIfNamespace": true,
        "development": false,
        "useBuiltins": false,
        "runtime": "automatic"
      },
      "hidden": {
        "jest": true
      }
    }
  },
  "module": {
    "type": "commonjs",
    "strict": false,
    "strictMode": true,
    "lazy": false,
    "noInterop": false
  }
}

Note that if you use JSX runtime (likely that you do) that’s introduced in React 17, you need to set jsc.transform.react.runtime to automatic (as above). If you use React.createElement, you must set it to classic.

Configure Jest

Create a file jest.config.js at the root project:

module.exports = {
  roots: ["<rootDir>/src"],
  collectCoverageFrom: [
    "src/**/*.{js,jsx,ts,tsx}",
    "!src/**/*.d.ts",
    "!src/mocks/**",
  ],
  coveragePathIgnorePatterns: [],
  setupFilesAfterEnv: ["./config/jest/setupTests.js"],
  testEnvironment: "jsdom",
  modulePaths: ["<rootDir>/src"],
  transform: {
    "^.+\\.(ts|js|tsx|jsx)$": "@swc/jest",
    "^.+\\.css$": "<rootDir>/config/jest/cssTransform.js",
    "^(?!.*\\.(js|jsx|mjs|cjs|ts|tsx|css|json)$)":
      "<rootDir>/config/jest/fileTransform.js",
  },
  transformIgnorePatterns: [
    "[/\\\\]node_modules[/\\\\].+\\.(js|jsx|mjs|cjs|ts|tsx)$",
    "^.+\\.module\\.(css|sass|scss)$",
  ],
  modulePaths: ["<rootDir>/src"],
  moduleNameMapper: {
    "^react-native$": "react-native-web",
    "^.+\\.module\\.(css|sass|scss)$": "identity-obj-proxy",
  },
  moduleFileExtensions: [
    // Place tsx and ts to beginning as suggestion from Jest team
    // https://jestjs.io/docs/configuration#modulefileextensions-arraystring
    "tsx",
    "ts",
    "web.js",
    "js",
    "web.ts",
    "web.tsx",
    "json",
    "web.jsx",
    "jsx",
    "node",
  ],
  watchPlugins: [
    "jest-watch-typeahead/filename",
    "jest-watch-typeahead/testname",
  ],
  resetMocks: true,
};

A lot of magic happens here but I can brief some important points.

Transform code to CommonJS using SWC:

transform: {
    "^.+\\.(ts|js|tsx|jsx)$": "@swc/jest",
...
},

Transform css and files:

transform: {
  "^.+\\.css$": "<rootDir>/config/jest/cssTransform.js",
  "^(?!.*\\.(js|jsx|mjs|cjs|ts|tsx|css|json)$)":
    "<rootDir>/config/jest/fileTransform.js",
...
},

Create config/jest/cssTransform.js and config/jest/fileTransform.js to transform css and files. Those 2 files are from CRA.

// config/jest/cssTransform.js
"use strict";

// This is a custom Jest transformer turning style imports into empty objects.
// http://facebook.github.io/jest/docs/en/webpack.html

module.exports = {
  process() {
    return "module.exports = {};";
  },
  getCacheKey() {
    // The output is always the same.
    return "cssTransform";
  },
};

// config/jest/fileTransform.js
"use strict";

const path = require("path");
const camelcase = require("camelcase");

// This is a custom Jest transformer turning file imports into filenames.
// http://facebook.github.io/jest/docs/en/webpack.html

module.exports = {
  process(src, filename) {
    const assetFilename = JSON.stringify(path.basename(filename));

    if (filename.match(/\.svg$/)) {
      // Based on how SVGR generates a component name:
      // https://github.com/smooth-code/svgr/blob/01b194cf967347d43d4cbe6b434404731b87cf27/packages/core/src/state.js#L6
      const pascalCaseFilename = camelcase(path.parse(filename).name, {
        pascalCase: true,
      });
      const componentName = `Svg${pascalCaseFilename}`;
      return `const React = require('react');
      module.exports = {
        __esModule: true,
        default: ${assetFilename},
        ReactComponent: React.forwardRef(function ${componentName}(props, ref) {
          return {
            $$typeof: Symbol.for('react.element'),
            type: 'svg',
            ref: ref,
            key: null,
            props: Object.assign({}, props, {
              children: ${assetFilename}
            })
          };
        }),
      };`;
    }

    return `module.exports = ${assetFilename};`;
  },
};

Remember to install camelcase as a dev dependency (do not install version 7, since it dropped the support for CommonJS):

npm install --save-dev camelcase@6

Then, add ability to search test files and test names in pattern mode. Note that if you using Jest ≤ 26, please install jest-watch-typeahead@0.6.5, if you use Jest ≥ 27, please use jest-watch-typeahead^1.0.0:

watchPlugins: [
  "jest-watch-typeahead/filename",
  "jest-watch-typeahead/testname",
],

// For jest <= 26
npm i jest-watch-typeahead@0.6.5 --save-dev
// For jest >= 27
npm i jest-watch-typeahead --save-dev

Everything you want to do to your test environment such as extends the jest matchers with @testing-library/jest-dom, mock some APIs that’s not implemented in jdom, you can put to config/jest/setupTests.js:

  setupFilesAfterEnv: ["./config/jest/setupTests.js"],

// config/jest/setupTests.js
import "@testing-library/jest-dom/extend-expect";

window.matchMedia = (query) => ({
  matches: false,
  media: query,
  onchange: null,
  addEventListener: jest.fn(),
  removeEventListener: jest.fn(),
  dispatchEvent: jest.fn(),
  addListener: jest.fn(),
  removeListener: jest.fn(),
});

Object.defineProperty(URL, "createObjectURL", {
  writable: true,
  value: jest.fn(),
});

Uncomment the render in the test file and run npm test.

// src/__tests__/App.test.tsx
-    // render(<App />);
+     render(<App />);

At this moment, you can run the test successfully.

Using @swc/jest to compile code to CommonJS is much faster than babel-jest, ts-jest which have long cold starts when executing tests in a large project.

Outro

Hooray. Congratulations, you’ve successfully integrated Jest with Vite. But our journey is not over yet. In the next post, we’re going deal with Vite variable environment with special syntax import.meta.env together. And some preview on a blazing fast unit-test framework powered by Vite: Vitest. Stay tuned! Happy coding!

Things I learned in 2021

Sat, 29 Jan 2022 18:13:34 GMT

At the beginning of 2021, I knew that I’m in the middle of Valley of Despair of the Dunning-Kruger Effect. I also realized that I was having a lot of gaps in my knowledge. So I forced myself to learn and practice harder than previous years to fill these holes. In this post, I want to share something that I did and learned through the year, with some context on each item. I think it’s good for me to look back, and it also helps me to plan better this year (2022). Moreover, I love sharing 😬

Updated my open source library to version 2.0.0 and got ~4000 downloads per week

I did release an open source package 4 years ago (2018). It basically helps you to integrate the Login with Linkedin feature to a React application easily. When I start this, I just do it for fun and thought no one was gonna use this library. But after a long time, I see that there are some people who actually installed my package. I also received bug reports and feature requests. (All of that happens without zero advertising). I decided to spend some weekends working on this little project. People started to thank me for helping them. I felt wonderful that my work can save some people’s time. I also learned a lot (I will write a post on what I learned when doing open source). I realized that I actually received more than I gave to the community.

In October, I wanted to release the package to version 2.x to tackle some major problems in version 1.x. I learned a lot. I converted my code to Typescript, I learned more about Typescript. I used Rollup to bundle my code instead of webpack to support ECMAScript modules, to leverage the Tree Shaking feature. For the first time, I knew about Vite, and use it for the example while developing the package. I had so much fun working on these items and learn so much. After investing some time in the project, I see the strike in the number of weekly downloads that amazed me. It reached about 4000 downloads per week. There are many things to do for this little project and I hope I can make it better in 2022.

Participated more actively in the open source world

I love open source. I use open source software every-single-day. I use React, Node.js, VS Code and many many other things. I think open source plays a big role in bringing humanity this far. The good thing about open source is that everyone can make their lives and others’ lives much easier and more enjoyable. Anyone can contribute to the open source. It does not require you have to write code to core services of a framework or application. It can be anything, from a typo to the recommendations, the feedback about the software. This year, besides using open source software, I started to give back the community by contributing commits, participating discussions, answering questions, sharing my solutions to the problem I couldn’t google. I feel great and I did learn a ton. Next year, I target to contribute more to some projects that I like and am interested like msw and Next.js.

Adopt Typescript

I worked with Javascript every day for more than 4 years. You might hear “Javascript is great”. Yeah, I love it. You might hear “Javascript is terrible”. Well, I… don’t disagree. I knew the good and the bad things about javascript but I still love it overall. It gives me flexibility, but also gives me “Cannot read properties of undefined” 😂. Until one day, Microsoft introduced Typescript. I heard about it and thought: “Ok, javascript with types, just another tech. No thanks, I’m good with pure javascript”. But a few months ago, I decided to experiment Typescript for a greenfield project at my company. My teammates and I were amazed by how Typescript helps us improve the quality of our code and catch almost all the potential bugs early. Most important, Typescript gives us a high level of confidence to ship our code to production. Typescript also gives Github Copilot a lot of context, so Copilot can be really helpful on giving suggestions. I have much fun working with both Typescript and Copilot. Typescript is not just a “type system” as I imagined before. It’s truly your best sidekick.

Study CSS

It sounds ridiculous when I was a frontend engineer for more than 4 years but still needs to learn CSS. You are correct, I learned it from scratch, not googled some weird issues we all encounter in our everyday jobs. Previously, in my company, frontend engineers don’t really need to style. We are given CSS from CSS Engineers. Our main duty is to handle and implement the business logic, writing tests, etc… In the past, I did not consider myself a true frontend engineer.

Luckily, last year I found Josh Comeau’s css-for-js course. It’s not only the best CSS resource I’ve ever seen, it’s also one of the best courses I’ve learned. The way he organizes CSS knowledge unit with the approach of practice-first is effective and I had a lot of joy learning CSS. After the course, I gain in depth knowledge of CSS such as the box model, flow layout, flexbox, grid, responsive, modern CSS architecture, animation and the most important, the solid CSS foundation that I can explore my CSS journey by myself. Now, I am very comfortable building any UI I see on the internet and it boosts my productivity by at least 50%. I am no longer dependent on CSS Engineer and feel much enjoyable when working with UI.

Start to explore Rust

Rust is an interesting programming language that promotes safety and high performance. It isn’t like any other programming languages that you can pick up the syntax then use your knowledge of other programming language on it. Rust introduces the concept of Ownership, remove the necessity of garbage collector. People in the frontend world are building tools written in low level programming languages (including Rust) to reduce run time significantly. Rust can also be used to write code for WebAssembly, which is a super cool technology, used for super cool product like Figma. I don’t want to stay out of this move of the technology world, so I decided to dip my toes in the Rust world. I just began my journey with Rust by reading The Book. I hope I will have a good time with Rust in 2022.

(Re)Learn Computer Network with Wireshark

Having a Bachelor of Computer Science, I think everyone knows about Network, OSI model, DNS, HTTP/ HTTPS… I also do, but that’s it, I forgot a lot after I graduated (sorry my teacher 🙏😥). My everyday work is mainly on the application layer. But it helps to understand deeply how computer network works at the zero and one level. I took the course Analyzing Network Protocols with Wireshark and this quick course helped me recall much knowledge about common protocols such as UDP, TCP, TLS, IPv4, IPv6, DNS, ARP, ICMP, DHCP, FTP… It also equips me with the skill of using Wireshark to understand how those protocols actually work. This skill actually helps me solve some hard problems in my daily work.

Get familiar Next.js

I heard a about Next.js for quite a long time, especially when some of my users on react-linkedin-login-oauth2 submitted issues related to Next.js. In the React world, Create React App (CRA) used to be a de facto solution to bootstrap a react application. But I learned that CRA was put in the maintenance mode. CRA was born to have a purpose of leading the ecosystem and it served well. Now it’s time for other frameworks to make the react world grows such as Gatsby, Vite, Next.js, Hydrogen…To adapt to the movement, I started to look into Next.js as a replacement for CRA. Many people think of Next.js as a framework of Server Side Rendering only. It used to be true but not anymore. Now it is suitable for Server Side Rendering, Static Site Generation, Client Only apps. I’m playing with Next.js by migrating my blog to Next.js and I have a lot of fun so far.

Join the first CTF

CTF (Capture The Flag) is a security competition, participants are hackers, it’s not for someone who is not focused on security. That’s what I thought for almost ten years. Last year, one of my friends invited me to a CTF for students in high school, organized by CyberJutsu and CyberKid. He persuaded me that it would be fun. It intrigued me and I accepted his invitation. I was surprised that CTF is not something “just for hackers” as I thought before. It’s all about things we already know, but do we actually understand them? All the challenges contain no new knowledge and concept, but the way those existing concepts combine and are being used smartly really dazzled me. I learned a lot from the competition and I have to look back seriously about what I thought that I already know and understand. After that, I also join 2 workshops hosted by CyberJutsu and learn much knowledge about computer security and exploit skills such as attacking using file, path traversal, template injection…

Take Web Security course from Standford

Aside from joining a CTF, I also took a course about Web Security. My daily job is developing a web application. Besides making software that helps my users on their jobs, I should also figure out how to protect them from the dangerous threads while they use my software. To achieve that goal, I need to understand basic and advanced web security concepts. I also need to know how to perform an attack, then I will be able to prevent them. Through the course, Feross did a great job of guiding learners through these above items. The course helped me write a significantly better code than before.

Shape the product that the market needs

In the beginning years of my career, my everyday job is to receive a ticket, write the software following the requirements, test, write tests and deliver. But in recent years, I have chance to work closely with product team. I understand the reason for each ticket/ requirement. I understand the purpose of each line of my code to the company’s vision and strategy. I have a better view of a software product, from product and user perspective, not only from a technical perspective as before. I can make brainstorm ideas to build a feature, suggest product team about the pros and cons of each solution to a single problem. I can find the balance point between a business’s need and the system quality. Eventually, having users is more important than having a perfect technical system.

Work as a backend engineer

I am a fulltime frontend engineer since 2017. I forgot many things about database already 😅. Last year, I revised my understanding of backend systems and I was able to produce production code for backend side. I feel great to develop software both at frontend and backend sides. This year, I will keep sharpening my skills and hope to work more on the backend side, in addition to frontend work.

Management skills

Coding is hard. Making software is hard. But managing people is way harder. When developing software, our duty is to make the software do its job, also make the software better over time. Similarly, our duty when managing people is to help them finish their job well, also make them better every day. I learned a lot about these skills and there are many to improve in the next year.

Get familiar with AWS

We are living in a cloud era. The age of every company that needs to have a physical server is over. People are using cloud services like AWS, Microsoft Azure, Google Cloud Platform for their convenience, reasonable price, easy to scale. I don’t want to stay out of the trend so I started to research AWS lately. I target to have an AWS Cloud Practioner in the next 3 months and AWS Solution Architect in the next 6 months.

Start to use twitter to learn

I had a twitter account for a long time. But twitter is not very popular in my country, so I just do not use it. This year, I use twitter to follow some cool people in the technology industry, famous guys specializes in frontend in particular. I was surprised that I learned so much on twitter. I can see the current trending technology, also follow and participate in technical discussions with like-minded people. If you’re using twitter, let’s connect. Following are some of my favorite resources which I knew through twitter:

2021 is a very hard year for all of us. However, as Newton’s third law “to move forward, we have to leave something behind”, we are leaving the pandemic behind, please take care, and keep improving ourselves. I feel thankful for having a decent job during the pandemic, having a chance to learn something new every day and having many wonderful people around me supporting me to do this. Best wishes to all of my readers and I’m looking forward to seeing you again in 2022.

Be authentic với tích xanh trên Github

Thu, 30 Dec 2021 18:34:58 GMT

Mở đầu

Facebook có tính năng “tích xanh” để xác minh rằng một tài khoản là chính chủ. Vậy đối với developer - người chơi hệ code, liệu có tính năng tương tự không? Câu trả lời là có. Nếu bạn sử dụng Github đủ lâu, bạn sẽ biết github cũng có tính năng tích xanh, nhưng là xanh lá cây.

Commit “chính chủ”

Trong bài viết này, chúng ta sẽ cùng tìm hiểu tính năng này là gì và làm sao để sử dụng tính năng đó nhé.

Commit Signature Verification

Tính năng “tích xanh” của github tên đầy đủ là Commit Signature Verification, là một tính năng để xác thực rằng, commit được đẩy lên là do chính chủ đẩy lên, không phải là một ai khác. Vậy câu hỏi đặt ra là: “Liệu tôi có thể giả vờ làm người khác commit code, rồi push code lên sao?”. Thì câu trả lời là: “Có. Chắc chắn rồi”. Giống như facebook, bạn hoàn toàn có thể lập một tài khoản với tên bất kì (ví dụ: Đen Vâu), và viết một bài đăng như thể chính Đen Vâu đang trò chuyện với Đồng Âm vậy. Tuy nhiên, tài khoản của bạn sẽ không có tích xanh như tài khoản của Đen Vâu, và sẽ nhiều người nhận ra tài khoản bạn mới lập là pha-ke. Quay trở lại với code, nếu còn chút ngờ vực, hãy nhìn vào hình ảnh dưới đây:

Giả mạo @tamhoang1412 và @Songuku95. Nguồn: https://github.com/nvh95/fake-committers/commits/master

Hình trên là ảnh chụp từ repo fake-committer, trông thì có vẻ như @nvh95, @tamhoang1412 và @Songuku95 mỗi người có 1 commit. Tuy nhiên thực tế thì @tamhoang1412 và @Songuku95 không hề biết đến sự tồn tại của repo fake-committer, hai commit của hai bạn này hoàn toàn bị @nvh95 giả mạo.

Tính năng tích xanh hoạt động như sau: Bạn sẽ kí (sign) commit bằng một khoá bí mật, đồng thời bạn upload khoá công khai lên github. Khi đó, mỗi khi bạn push code lên github, nó sẽ sử dụng khoá công khai để xác thực xem có đúng bạn là người tạo ra commit đó hay không.

Lợi ích của “tích xanh” Github

Như ví dụ bên trên, lợi ích rõ ràng nhất của “tích xanh” đó là để xác nhận rằng commit của mình tạo ra là “chính chủ”, là “hàng auth”. Một commit có tên mình là committer chưa chắc chắn đã là commit do mình tạo ra (nhỡ ai đó chơi xấu mình commit bug rồi đẩy lên thì sao 😂), nhưng một commit có “tích xanh” thì chắc chắn đó là commit authentic. Ngoài ra, một lợi ích khác mà mình thấy cũng rất quan trọng, đó là trông nó “pro” hơn rất nhiều 🤣🤣🤣. Giữa một rừng các commit trắng toát, commit của mình có tích xanh trông rất xịn xò và nổi bật.

Nổi bật trong PR với tích xanh

Các bước để tạo “tích xanh”

Có vài cách để có được tích xanh, nhưng đơn giản và phổ biến nhất đó là sử dụng GPG (GNU Privacy Guard). Bạn đọc có thể tham khảo docs chính thức tại đây GPG commit signature verification. Trong khuôn khổ bài viết này, mình sẽ tóm tắt sơ lược các bước thực hiện:

1. Kiểm tra đã có GPG key trên máy chưa

Kiểm tra bạn đã có gpg chưa bằng cách gõ gpg vào terminal. Nếu chưa có vô đây download (download ở phần GnuPG binary releases nhé).
List các GPG key đang có ở máy bằng lệnh:
```
gpg --list-secret-keys --keyid-format=long
```
- Nếu chưa có GPG key, chuyển sang bước 2.
- Nếu có GPG key rồi, chuyển sang bước 3.

2. Tạo GPG Key

Chạy lệnh dưới đây, làm theo hướng dẫn điền để chọn loại mã hoá, tên, email, passphrase của bạn để tạo ra một GPG key mới:

gpg --full-generate-key

Lưu ý trong câu hỏi What keysize do you want?, key của bạn phải dài ít nhất 4096 bits.

Chạy lệnh dưới đây để hiện long form của GPG key:

gpg --list-secret-keys --keyid-format=long

Copy long form của GPG key ID, ví dụ như ở trường hợp này nó là 3AA5C34371567BD2:

$ gpg --list-secret-keys --keyid-format=long
/Users/hubot/.gnupg/secring.gpg
------------------------------------
sec   4096R/3AA5C34371567BD2 2016-03-10 [expires: 2017-03-10]
uid                          Hubot
ssb   4096R/42B317FD4BA89E7A 2016-03-10

Chạy lệnh dưới đây để lấy ra GPG key, thay thế 3AA5C34371567BD2 bằng long form của GPG key ID:

gpg --armor --export 3AA5C34371567BD2

Copy GPG key bắt đầu bằng ----BEGIN PGP PUBLIC KEY BLOCK----- và kết thúc bằng ----END PGP PUBLIC KEY BLOCK----- để chuẩn bị cho bước 3.

3. Thêm GPG key vào github

Copy key ở bước 2 vô đây https://github.com/settings/gpg/new. Sau đó nhập password vào để confirm.

4. Báo cho git biết bạn có GPG key mới

Chạy lệnh sau, với 3AA5C34371567BD2 là long form của GPG key ID như ở bước 2:

git config --global user.signingkey 3AA5C34371567BD2

Command bên trên sẽ có tác dụng global. Trong trường hợp bạn muốn sử dụng GPG key khác cho một local repo, bạn có thể sử dụng lệnh:

git config user.signingkey BAF7C50535B4A174

5. Kí

Bước cuối cùng bạn chỉ cần kí các commit là được. Bạn có thể kí từng commit một bằng option -S, ví dụ:

git commit -S -m "Commit nay chinh chu"

Tuy nhiên bạn sẽ muốn việc kí mọi commit trong tương lai mà không cần phải thêm -S mỗi khi commit. Để làm được việc đó, bạn chạy lệnh:

git config --global commit.gpgsign true

Tada, vậy là xong, mọi commit của bạn lên github sẽ trông rất authentic trở từ giờ trở đi.

Bonus: Vigilant Mode

Quay lại câu chuyện trước khi kí, nếu ai đó giả mạo bạn commit, thì commit đó cũng chỉ trắng xoá. Vậy có cách nào tốt hơn không? Câu trả lời chính là Vigilant Mode. Khi bật chế độ này lên, nếu các commit nào của mình mà không được kí, sẽ có tag Unverified màu vàng bên cạnh, sẽ dễ dàng để người khác biết được commit đó có được kí bởi bạn hay không. Chi tiết hơn các bạn hãy xem tại Displaying verification statuses for all of your commits.

Các bạn có thể bật chế độ đó lên bằng đường dẫn sau https://github.com/settings/keys.

Kết luận

Vấn đề pha ke người khác là một vấn đề nhức nhối trong không gian mạng hiện nay. Tuy rằng mình nghĩ vấn đề này cũng không có xảy ra nhiều trong thế giới lập trình, nhưng hi vọng qua bài viết này, với khoảng 5 phút thiết lập, bạn sẽ có cho mình các commit chính chủ, có tích xanh (lá cây), Verified, trông đẹp và vip pr0 hơn nhiều. Happy coding!

How to choose a third party package

Mon, 29 Nov 2021 17:24:56 GMT

I would like to express my sincere thanks to @tamhoang1412 and @mattmurph9 for reviewing and proofreading this post.

Introduction

A wise man once said “don’t reinvent the wheel”. It’s true for every industry, including software development. When developing a feature, sometimes you are in a situation “I need a third party package”. So, how to correctly choose a library or package? In the past, whenever I thought I needed an external library, I just googled it (e.g: react charting libraries), chose a random package, then tried it. If it worked, I used it. But it turned out that this strategy was not optimal. In this article, I will share some personal tips for choosing a javascript package. But these tips can be applied to any other language, framework, or even when choosing a language for your team.

1. Fit your need

It sounds obvious that you should choose a solution that solves your problem. A package usually tries to solve a set of problems in general. Meanwhile, your use case is particular to your situation, and the package might not fit. Please make sure the third party code you are going to install handles sufficiently, but not too much. Don’t over-engineer a solution. Many times, DIY is a good option.

2. Easy to adopt

In the industry, you don’t work alone. So, pick a solution that your team members are able to adapt to quickly. You don’t want to choose a solution that only you can implement and maintain.

3. Popularity

It’s usually true that a good solution is a popular one (if a solution is good, why isn’t it popular)? I measure the popularity of a javascript package by the number of github stars and the number of weekly downloads on https://npmjs.com. A package with a large community proves that it solves the problem for many people. It comes with the advantage of having better support when we run into an issue. A more popular package will have more maintainers, contributors and users, so it’s more mature than a less popular one. It usually has good documentation and tutorials, which help to easily adopt and use it correctly and efficiently.

Bonus: https://stateofjs.com/ is a great resource for you to know about what’s trending in javascript each year

4. In active development

It’s very important that you are choosing an active project instead of a dead/unmaintained project. An active project improves over time through community feedback. An unmaintained project does not move forward, fix functional bugs or patch security issues. Sometimes, a very popular package can be abandoned and go into a “frozen” state with many open issues and pull requests. It might have been a great solution in the past, but this is a sign that we have to move on. An example is react-loadable. It was a great solution for a very long time for code-splitting in React. I totally loved it. But it’s stale now with many issues and PRs since 2018 (this post is written at the end of 2021). Now, if I need to split code in React, I use loadable-components, which is in active development, becoming more popular, patches bugs reported by the community, and most importantly, solves my problems. My personal advice: choose a package that’s active in the last 3-6 months, with issues that are being resolved and PRs that are being merged.

5. License

It’s very important that the package you install grants you the permission to use it for commercial purpose in production. Packages in the wild are great. But not all of them are free to use.

Let’s take an example. If you are working with charts, you might have heard of Highcharts - a rock-solid and incredibly flexible charting library made for developers. You download it from npm, make a chart, it looks great, and you are ready to roll out the feature. But please note that Highcharts is not free for commercial use. So if you are writing code for your company and your company hasn’t bought a license to use this package in production, you are basically breaking the law. We don’t want that, right? So please buy a license before using Highcharts in production. Myself, I use Recharts instead, a free package powered by D3 with MIT license and in very active development.

Software licenses are quite complicated and go beyond the purpose of this post. But in general, packages with MIT, Apache 2.0 and BSD are safe to use for commercial purpose. If you choose a package with a license that is not one of those, please read the license carefully.

6. Reasonable size

You don’t want to bloat your web application’s bundle size by installing a 700kb package. Sometimes it is necessary, but most of the time it is not. Please consider the size of a library before making a decision. You need to know about the unpacked size, the bundle size, and the gzipped size. A larger package means you need more hard disk and bandwidth, which means more money you need to pay, also it takes a longer time for users to load your app.

7. DIY

As mentioned in Fit your need, many packages try to solve a general problem (thus the size of the package is large). You may only need a small part of the package. Sometimes, your problem is unique and there are no existing third party packages out there that solve it. In those cases, it’s a great time for you to do it yourself. I found myself in the early days in the industry spending much time finding a third party package to help me build features. But over time, I more rarely used external packages for my daily tasks. It doesn’t mean that I always reinvent the wheel. It means that I know what I am doing and I can seek help from the community when I truly need to (for example I will never sanitize user input by myself, but use DOMPurify)

Bonus: For some problems, if you cannot find a package that helps you, make one and give it to the world by making it an open source software. The open source sofware community will give you back many things, more than you can expect.

Conclusion

Above are my very personal tips, they might be true and they might not be true. If there’s something you don’t agree with, that’s OK. Just ignore it, or better, let me know why you don’t agree. If you have additional tips, please let me know in the comment section. I would love to hear from you. I hope this helps you choose the right packages for you and your team. Happy coding!

Các cách đơn giản để sử dụng internet an toàn

Tue, 24 Aug 2021 16:18:17 GMT

Hơn một năm rưỡi trước, không ai nghĩ dịch bệnh sẽ lây lan và ảnh hưởng đến đời sống xã hội một cách nặng nề như hiện nay. Các ca bệnh từ khi còn ở rất xa chúng ta, dường như “không phải chuyện của mình”, đến khi ngày càng nhiều nơi trên cả nước có người nhiễm, đến khi chúng ta nghe tin dãy nhà bên cạnh có các ca dương tính, và khi đó, nguy cơ đã hiện hữu quanh mỗi chúng ta. Nếu trong vài tháng đổ lại đây, bạn có nghe ai đó nói: bị hack facebook rồi lừa người quen chuyển khoản, bị hacker hack tiền trong tài khoản ngân hàng…, thì xin đừng chủ quan, vì giống như đại dịch COVID-19, các mối nguy hại khi sử dụng internet luôn luôn hiện hữu và lây lan rất nhanh, không chừa một ai cả. Giống như phòng dịch, chỉ có bổ sung kiến thức và nâng cao ý thức của mỗi cá nhân, chúng ta mới có thể an toàn trước thế giới số được. Trong bài viết này, mình xin chia sẻ một vài cách để an toàn hơn khi sử dụng internet.

1. Không để trùng password

Để trùng password giữa các dịch vụ là lỗi cơ bản nhất mà hầu như ai cũng mắc. Kể cả những chuyên gia trong ngành CNTT - những người có những hiểu biết sâu sắc về các hệ thống máy tính. Hãy thử tưởng tượng bạn dùng chung một mật khẩu cho tất cả các dịch vụ online. Một ngày (không) đẹp trời, một trong các dịch vụ bạn sử dụng bị hack, tất cả các mật khẩu của người dùng bị lộ. Bạn cũng không ngoại lệ. Và hacker sẽ thử dùng email và mật khẩu của bạn ở hệ thống bị hack để đăng nhập vào rất nhiều nơi khác. Và nếu may mắn, hacker sẽ có thể đăng nhập được vào các dịch vụ khác của bạn như mạng xã hội, ngân hàng… Đó là lúc mọi chuyện sẽ trở nên rất phiền phức và nguy hiểm. Nhiều người sẽ cố gắng giải quyết vấn đề này bằng cách có một mật khẩu chung cho các tài khoản “không quan trọng”, và có độ 2 đến 3 mật khẩu riêng cho các mật khẩu quan trọng hơn như tài khoản facebook, gmail, tài khoản ngân hàng… Cách này mặc dù an toàn hơn một chút nhưng nhìn chung vẫn rất nguy hiểm. Bạn sẽ không thể hình dung được những tài khoản “không quan trọng” lại chứa cực nhiều thông tin về bạn, và có thể là bước đệm mở ra các cuộc tấn công nhắm tới bạn với mức độ nghiêm trọng hơn. Độc giả đọc đến đây có thể thắc mắc: “Nếu mỗi dịch vụ lại phải đặt một mật khẩu mới, vậy thì làm sao mà tôi có thể nhớ được hết???“. Vâng, thắc mắc đó là rất hợp lý, và câu trả lời đơn giản là… bạn không cần phải nhớ. Cụ thể hơn, bạn hãy xem thêm ở bài viết Quản lý mật khẩu làm sao để không bị hack - Bảo vệ bản thân với mật khẩu an toàn nhé

2. Không đặt mật khẩu quá đơn giản

Lại là mật khẩu! Vâng, thực ra theo cá nhân của mình hầu hết các cuộc tấn công vào người dùng phổ thông đều là câu chuyện liên quan đến mật khẩu. Một mật khẩu quá đơn giản sẽ dễ dàng bị hacker mò ra một cách nhanh chóng. Để minh hoạ, nếu mình đặt mật khẩu là viethung, hung95 hay 01011990, thì các hệ thống máy tính chỉ mất không đến 10 phút có thể dò ra mật khẩu của mình rồi.

Mật khẩu quá đơn giản như tên và ngày sinh sẽ nhanh chóng bị các hệ thống máy tính crack

Tuyệt đối không đưa các thông tin cá nhân của mình vào mật khẩu như: tên, ngày sinh, số điện thoại của mình và người thân, bạn bè, tên thú cưng, địa chỉ nhà…

Yếu tố quan trọng nhất để có một mật khẩu an toàn là độ dài, hãy đặt một mật khẩu dài ít nhất 12 ký tự, ví dụ như sau:

Mất đến 6 năm để có thể crack được mật khẩu này (12 kí tự)

Để nghĩ ra các mật khẩu phức tạp kể ra cũng đau đầu, nên để giải quyết các vấn đề 1 và 2, hãy tham khảo cách 3

3. Sử dụng phần mềm quản lý mật khẩu

Mình đã viết một bài viết chi tiết về vấn đề này ở đây. Tuy nhiên, mình sẽ tóm gọn lại các lợi ích khi sử dụng phần mềm quản lý mật khẩu:

- Có thể đặt các mật khẩu khác nhau giữa các dịch vụ, chỉ cần nhớ duy nhất mật khẩu chủ (master password)

- Các mật khẩu sẽ rất mạnh. Ví dụ: yL^t7GsM3&ESwwxt4baW

- Tự động điền mật khẩu vào các trang web, phòng chống Phishing

Với các bạn trẻ thì việc làm quen và sử dụng các phần mềm quản lý mật khẩu sẽ không là vấn đề gì. Tuy nhiên, với nhiều người lớn tuổi thì tương đối khó dùng. Nhiều các cô các bác có thói quen ghi mật khẩu vào Note trên điện thoại. Trước đây việc này là một việc gần như tối kị. Tuy nhiên gần đây mình để ý thấy các ứng dụng như Notes trên iPhone hay Samsung Notes đã bổ sung tính năng khoá một ghi chú lại bằng mật khẩu. Mình không khuyến khích cách này, nhưng ít ra, các cô các bác nếu gặp khó khăn trong việc sử dụng các phần mềm quản lý mật khẩu thì hãy bật tính năng khoá các ghi chú quan trọng lại nhé.

4. Bật chức năng xác thực hai lớp

Có một nguyên tắc cơ bản đó là:

Sự an toàn nó không miễn phí, nó có cá giá của nó.

Và cái giá của sự an toàn chính là sự tiện lợi. Hãy lấy ví dụ về chiếc cửa nhà bạn. Nếu bạn không khoá, sẽ rất tiện lợi, đi ra đi vào chỉ cần đẩy nhẹ là xong. Nhưng như thế trộm có thể dễ dàng vào nhà khuôn đồ đi. Ngược lại, nếu bạn khoá trong, khoá ngoài, thì mỗi lần mở cửa, bạn sẽ mất công mở vài lần, khó chịu hơn, nhưng trộm sẽ khó có thể vào nhà bạn. Sự an toàn trong thế giới số cũng vậy. Nếu mật khẩu của bạn rất đơn giản như tên của bạn, nó sẽ rất tiện lợi, dễ nhớ, nhưng ai cũng đoán được. Nếu mật khẩu của bạn phức tạp, bạn bật cả xác thực hai lớp lên, bạn sẽ khó nhớ mật khẩu hơn, mỗi lần đăng nhập phải mở điện thoại để nhập OTP. Điều này đúng là sẽ phiền hơn, nhưng bạn sẽ an toàn hơn khi ở trên mạng.

Như ví dụ bên trên, đôi khi cửa mình khoá hai lớp khoá, để trộm có phá được khoá ngoài thì cũng phải phá thêm khoá trong nữa. Bảo mật hai lớp cũng thế. Nó phòng tránh việc giả dụ mật khẩu của bạn bị hack mất, nếu bạn bật bảo mật hai lớp, hacker sẽ không thể đăng nhập vào tài khoản của bạn được.

Thực tế cho thấy hầu hết các vụ hack facebook đều là do mất mật khẩu, và hoàn toàn có thể phòng tránh được nếu bật chức năng Bảo mật hai lớp. Hacker dù có hack được mật khẩu của bạn, nhưng không có điện thoại hay khoá bảo mật thì không thể làm gì được bạn. Nếu chưa bật Bảo mật hai lớp cho Facebook thì bạn hãy dành vài phút để bật lên nhé.

Các phương thức xác thực hai lớp như tin nhắn SMS, Authenticator Apps, khoá bảo mật

5. Không gửi thông tin lên các trang web không có hình chiếc khoá

Không bao giờ submit các form trên các trang web không có hình chiếc khoá, đặc biệt là các thông tin cá nhân và mật khẩu. Khi truy cập các trang web không có hình chiếc khoá, toàn bộ thông tin bạn gửi đi sẽ không được mã hoá và ai cũng có thể đọc được. Ngoài ra, bạn có thể đang là nạn nhân của các cuộc tấn công Man in the Middle như ssltrip…

Một trang web có hình “chiếc khoá”, được mã hoá đầu cuối, sử dụng HTTPS

Không bao giờ gửi thông tin cá nhân lên các trang web không có hình chiếc khoá.

Lưu ý: Điều này không đồng nghĩa với việc các trang web có hình chiếc khoá thì sẽ luôn an toàn để gửi thông tin đi. Hacker vẫn hoàn toàn có thể tấn công bạn bằng các phương thức khác như Phishing

6. Nhận biết các trang web phishing và không nhập mật khẩu vào các trang web đó

Đây là hình thức lừa đảo phổ biến bậc nhất và rất khó để những người không chuyên về công nghệ để có thể phân biệt được. Trước tiên phishing là gì? Hiểu nôm na, phishing attack là hình thức tấn công dụ người dùng vào một trang web của kẻ tấn công và dụ người dùng nhập password vào. Các trang web phishing có thể thiết kế trông y hệt một trang web mà bạn vẫn hay vào như facebook, gmail, iCloud…, hay núp bóng các hình thức như để có thể bình chọn, hay nhận thưởng, bạn phải kết nối tài khoản facebook, google… Một khi bạn thực hiện các thao tác trên, tài khoản của bạn sẽ bị mất, mặc cho mật khẩu của bạn có phức tạp như thế nào.

Hãy cùng điểm qua một vài hình thức phishing nhé

- Giao diên y hệt trang gốc

Url không phải là facebook.com mà là facebook-support.something.xyz - là một trang phishing

- Nhận thưởng, bình chọn…: Khi nhận được email hay tin nhắn nhờ bình chọn hay nhận một phần thưởng nào đó, sau đó bạn phải nhập mật khẩu vào

- Subdomain đánh lừa người dùng

Trang web bên trên đánh lừa người dùng rằng họ đang truy cập vào gmail.com. Tuy nhiên, thực tế thì người dùng đang truy cập vào active-inbox.com. Hãy tìm hiểu thêm về cấu trúc của một đường link nhé.

- Trang web nằm trong trang web (Picture in Picture)

Trang web giả mạo paypal.com bằng cách thiết kế hệt như đang có một cửa sổ trình duyệt mở Paypal.com

Trang web giả mạo Steam.

Một tin vui đó là nếu bạn sử dụng các phần mềm quản lý mật khẩu, nó sẽ giúp bạn tránh khỏi phishing. Ví dụ, khi bạn truy cập trang web faceb00k.com (phishing web), phần mềm quản lý mật khẩu sẽ không điền mật khẩu của facebook.com vào trang faceb00k.com.

7. Bật tính năng auto update trên máy tính và điện thoại

Cách đây từ 5-10 năm, việc tắt tính năng tự động cập nhật các phiên bản mới trên máy tính và điện thoại rất phổ biến, đặc biệt là trên điện thoại. Có nhiều lý do được đưa ra như là để tiết kiệm pin hay để tránh lỗi khi nâng cấp lên các phiên bản mới. Tuy nhiên về vấn đề pin thì thực tế cho thấy hiện nay không có nhiều sự khác biệt khi bạn bật chế độ auto update và tắt nó đi cả. Ngoài ra bất cứ phần mềm nào đều cũng có lỗi, các nhà phát triển phần mềm ngoài việc phát triển các tính năng mới thì họ còn vá các lỗi phần mềm đang tồn tại, giúp bạn sử dụng các phần mềm đó ngày càng an toàn hơn. Thử tưởng tượng phần mềm X có một lỗi nghiêm trọng có thể giúp hacker chiếm quyền kiểm soát máy tính của nạn nhân. Sau đó đội ngũ phát triển nhanh chóng tung ra một bản vá để người dùng có thể an toàn. Nhưng bạn lại… tắt tính năng auto update. Vậy trong trường hợp này, bạn chính là con mồi béo bở cho hacker rồi.

Bật tính năng autoupdate trên máy tính (Windows, Mac) và điện thoại (CH Play, App Store) bạn nhé

8. Không dùng các phần mềm crack

Sẽ có nhiều ý kiến cho rằng “Vì nghèo nên đành dùng phần mềm crack”. Ý kiến này cũng… một phần đúng. Ngày trước khi Việt Nam mới bắt đầu bùng nổ internet, các phần mềm bản quyền là một cái gì đó rất xa vời với đại bộ phận sử dụng máy tính và internet. Tuy nhiên hiện nay giá bản quyền phần mềm đã rẻ đi rất nhiều, có những phần mềm giá cả tính ra chỉ bằng vài bát phở, hay thậm chí rẻ hơn một bộ quần áo nữa. Bản quyền windows đi kèm khi mua laptop cũng rất rẻ. Vì thế nên nhận định trên theo thời gian đang dần không còn đúng nữa. Khi bạn cài phần mềm lậu, bạn hay thấy hướng dẫn Tắt phần mềm diệt virus đi để nó không nhận nhầm phần mềm crack là virus. Ơ, nó khác gì người lạ nói với mình Bạn mở cửa nhà bạn ra, đi ngủ một giấc, mình hứa chỉ vào nhà xem nhà bạn tí thôi, mình không ăn trộm cái gì đâu. Có thể người lạ đó vào nhà bạn… chỉ xem thật. Nhưng chỉ có trời biết người ta làm gì nhà bạn khi bạn đang đi ngủ. Việc sử dụng các phần mềm crack tiềm tàng rất nhiều nguy cơ mất an toàn. Mà cái đáng sợ nhất là khi sử dụng các phần mềm crack, bạn sẽ thấy “dùng mãi chả sao cả”. Nhưng lúc bạn trở nên quan trọng, bạn có tiềm lực về tài chính, lúc đó hacker mới tận dụng các thông tin cá nhân mà họ đã thu thập được suốt thời gian qua để chống lại bạn.

Nói chung, sẽ rất khó để thuyết phục một người quen sử dụng phần mềm crack bỏ thói quen đó chỉ sau ngày một, ngày hai. Giống như nghiện thuốc lá hay nghiện rượu, cần một quá trình để bỏ, thì nghiện sử dụng phần mềm crack cũng cần một quá trình để nâng cao nhận thức và thay đổi hành vi.

Không sử dụng các phần mềm crack để tránh các nguy cơ bị lộ lọt thông tin hay theo dõi

9. Luôn cập nhật nâng cao các kiến thức về bảo mật

Các hình thức lửa đảo và tấn công mạng ngày càng tinh vi, nên chỉ có một cách duy nhất để đối phó đó là nâng cao nhận thức và cập nhật các kiến thức về bảo mật thường xuyên. Có rất nhiều nguồn tài liệu để giúp bạn đạt được việc đó. Trong khuôn khổ bài viết này, mình xin giới thiệu đến mọi người một Facebook page, đó là Cookie Hân Hoan. Fanpage với sứ mệnh “Đánh thức tiềm năng nhận thức an toàn bảo mật thông tin. Đồng thời hướng dẫn bạn sinh tồn, an toàn hơn trên Internet.” truyền tải các thông tin về bảo mật dành cho mọi người một cách rất dễ hiểu và vui, vừa nâng cao kiến thức, vừa thư giãn, giải trí. Giống như tiếng Anh cần “mưa dầm thấm lâu”, nâng cao kiến thức về bảo mật cũng cần “mưa dầm thấm lâu” vậy

Fanpage Cookie Hân Hoan rất đáng yêu

Chúng ta đang sống trong 1 thế giới vô cùng đặc biệt. 20 năm trước, có nằm mơ chúng ta cũng không thể tưởng tượng được công nghệ có thể phát triển như ngày hôm nay. Nhưng cái gì cũng có hai mặt, bề nổi là sự tiện lợi hiện đại nhưng cũng tiềm ẩn cực nhiều nguy cơ gây mất an toàn trong thế giới số. Là công dân thời đại 4.0, trách nhiệm của chúng ta là trang bị những kiến thức và kỹ năng liên quan đến an toàn thông tin, đề có thể vừa bảo vệ bản thân, bảo vệ cộng đồng trong thế giới hiện đại ngày nay. Trong tình cảnh dịch bệnh còn phức tạp, chúc mọi người luôn luôn mạnh khoẻ trong thế giới thực, cũng như luôn luôn an toàn trên thế giới ảo.

Hãy nói về Referrer-Policy - Bạn có đang bị dòm ngó khi duyệt web không?

Thu, 27 May 2021 17:24:44 GMT

Dẫn nhập

Như chúng ta đã biết HTTP Header Referer thể hiện rằng bạn đến từ đâu khi truy cập một trang web. Giả dụ rằng bạn đang lướt www.facebook.com, bỗng nhìn thấy một chiếc link đến cửa hàng bán chiếc áo đang sale. Bạn click vào đó để xem chiếc áo vì tò mò, có thể bạn cũng sẽ mua chiếc áo đó. Một điều không bất ngờ lắm đó là ngay thời điểm bạn click vào chiếc link, cửa hàng quần áo kia sẽ biết được bạn đến với trang web của họ từ facebook. Hơn nữa, họ có thể đong đếm được tỉ lệ số người mua hàng đến từ facebook so với các kênh marketing khác là bao nhiêu. Từ đó có thể có những sự điều chỉnh phù hợp cho chiến dịch quảng cáo. Cách hoạt động thì tương đối đơn giản, mỗi khi người dùng ấn vào một đường link, một header referer sẽ được đính kèm.

Hình dưới đây mô tả việc referer được gửi đi khi bạn đọc báo dantri.com.vn

Tuy nhiên, hãy xem xét đến một ví dụ khác, đó là Google Docs. Như chúng ta vẫn hay sử dụng Google Docs để chia sẻ tài liệu với nhau. Đơn giản nhất đó là qua hai bước:

Share quyền của văn bản đó là “Anyone with link can view/edit”
Gửi link cho người khác

Mỗi link của một văn bản đều có dạng https://docs.google.com/document/d/some-random-id/edit. Về cơ bản some-random-id đủ phức tạp để không ai có thể tự mò ra được, ngoại trừ việc được chia sẻ. Cho nên về cơ bản việc chia sẻ link cho nhau là tương đối an toàn.

Lấy ví dụ với văn bản https://docs.google.com/document/d/1QHmwfKoekal9HJDu-_3zol5Ht2TGtfiSumHWVD9LRgo/edit. Trong văn bản này có chứa đường link của báo Dân Trí và báo VnExpress, đồng thời cả thông tin tài khoản ngân hàng của mình. Nếu bạn ấn vào đường link trong file bên trên, liệu rằng request đến báo Dân Trí và VnExpress có được đính kèm header dưới đây hay không?

Referer: https://docs.google.com/document/d/1QHmwfKoekal9HJDu-_3zol5Ht2TGtfiSumHWVD9LRgo/edit

Nếu câu trả lời là có, vậy nghĩa là người quản trị web của Dân Trí và VnExpress có thể biết được link của tài liệu của mình, đồng nghĩa với việc họ biết được thông tin tài khoản ngân hàng của mình, nếu mình lại chia sẻ tài liệu này với quyền Anyone with link can edit, thì mọi chuyện còn tệ hơn, người đó có thể đổi mật khẩu trong tài liệu này khiến mình lần tới không thể đăng nhập được.

Nghe có vẻ bất ngờ, bạn có chột dạ rằng mình có thể bị lộ bao nhiêu tài liệu từ trước đến nay có phải không? Vậy bạn hãy dành ra 2 phút để tự mình kiểm chứng nhé.

OK. Nếu bạn đã check, thì có thể sẽ thấy ngạc nhiên vì đúng là có header Referer gửi đi khi click vào trang báo thật, nhưng giá trị của nó chỉ là https://www.google.com/ chứ hoàn toàn không có giá trị của some-random-id.

Vậy nghĩa là bạn vẫn an toàn. Nói cách khác, nếu bạn ấn vào một đường link trong Google Docs, thì người quản trị trang web đó chỉ biết bạn vào trang web của họ từ trang web của google, chứ không thể biết chính xác là link nào. Vậy tại sao lại thế?

Referrer-Policy

Cứu tinh của chúng ta chính là Referrer-Policy. Trong ví dụ bên trên, hiểu nôm na là, google docs không cho phép gắn link đầy đủ vào header referer, mà nó chỉ gắn duy nhất origin, có nghĩa là some-random-id không được tiết lộ cho Dân Trí và VnExpress, hay bất cứ trang web nào khác. Vậy chính xác Referrer-Policy là gì?

The Referrer-Policy HTTP header controls how much referrer information (sent via the Referer header) should be included with requests.

Referrer-Policy là một HTTP Header điều khiển việc mình gửi thông tin referrer đi. Tuỳ thuộc vào nhu cầu mình muốn gửi đi bằng nào thông tin về referrer, hay bảo vệ thông tin đến mức nào mà có thể lựa chọn rule cho phù hợp. Chúng ta hãy cùng đi qua một vài các rule của Referrer-Policy nhé.

Một vài rule của Referrer-Policy

unsafe-url: Luôn gửi referrer

no-referrer: Không gửi referrer

no-referrer-when-downgrade: Không gửi referrer khi điểm đến có protocol có tính chất bảo mật kém hơn (HTTPS => HTTP, HTTPS => files)

origin: Chỉ gửi origin. Ví dụ bạn đang ở https://example.com/page.html thì khi đến một trang khác, giá trị của referrer sẽ là https://example.com/

same-origin: Gửi referrer full url khi cùng origin, nếu khác thì chỉ send origin
Ví dụ: Nếu đang ở https://example.com/page.html, sau đó sang trang https://example.com/about.html, thì referrer sẽ là https://example.com/page.html.
Còn nếu đang ở https://example.com/page.html mà sang https://google.com, thì referrer sẽ chỉ là https://example.com/

Các rule khác của Referrer-Policy các bạn có thể tham khảo chi tiết tại đây

Set rule bằng HTML

Ngoài HTTP Header, chúng ta hoàn toàn có thể set Referrer-Policy sử dụng HTML

<meta name="referrer" content="origin" />

New default

Từ tháng 11 năm 2020, giá trị mặc định của Referrer-Policy là strict-origin-when-cross-origin trên nhiều trình duyệt (e.g: Chrome 85, Firefox 87,…), mô tả của nó như sau:

Send the origin, path, and querystring when performing a same-origin request. For cross-origin requests send the origin (only) when the protocol security level stays same (HTTPS→HTTPS). Don’t send the Referer header to less secure destinations (HTTPS→HTTP).

Trước đó giá trị mặc định của Referrer-Policy là no-referrer-when-downgrade . Sự thay đổi này có nghĩa là nếu bạn click vào một link trên trang web, trình duyệt sẽ giấu đi thông tin bạn đến chính xác từ url nào. Ví dụ bạn đang ở https://docs.google.com/document/d/1QHmwfKoekal9HJDu-_3zol5Ht2TGtfiSumHWVD9LRgo/edit rồi ấn vào Dân Trí. Dân Trí chỉ biết rằng bạn đến từ google, chứ không hề biết bạn đến từ văn bản có chứa cả tài khoản ngân hàng của bạn. Việc này vô hình trung đã đảm bảo an toàn và tính riêng tư của bạn hơn khi sử dụng internet. Nhưng đối với các bạn web developer cũng nên chú ý xem trong hệ thống của bạn đang có feature nào dựa vào thông tin referrer hay không, nếu có thì từ Chrome 85, Firefox 87 đổ đi nó có còn hoạt động đúng hay không, nếu không thì hãy lên kế hoạch chỉnh sửa cho phù hợp nhé.

Fun fact:

Header Referer viết sai chính tả, đúng chính tả phải là Referrer, nhưng đến khi nhiều người dùng quá rồi thì không ai dám sửa cả. Sợ hỏng cả hệ thống internet vốn đã phức tạp. Đây là ví dụ rất đặc trưng cho cách mà toàn bộ hệ thống số trên toàn cầu được xây dựng và vận hành 😅. Và là mảnh đất màu mỡ cho các hacker trên toàn thế giới để khai thác.

Kết luận

Qua bài viết này, chúng ta có thể học được vài điều:

Hiểu được Referrer-Policy là gì?
Không nên lưu mật khẩu vào google docs, Note,… 😂
Nếu tài liệu có thông tin nhạy cảm nên hạn chế share kiểu Anyone with link can view/edit
Nếu làm sai cái gì nên sửa càng sớm càng tốt, đừng để đến khi nó gây ảnh hưởng lớn quá không ai dám sửa 🙈

Chúc các bạn khoẻ mạnh an toàn qua mùa dịch bệnh và cùng nhau học hỏi để tiến bộ mỗi ngày nhé.

Slack API hay là câu chuyện giật lì xì

Thu, 11 Feb 2021 18:11:23 GMT

Mở đầu

Trước tiên, mình xin gửi đến bạn, những độc giả đang theo dõi blog hung.dev một năm mới Tân Sửu thật nhiều niềm vui và sự may mắn. Cầu mong sự an lành và thịnh vượng sẽ tới với bạn và gia đình trong năm 2021 này.

Quay trở lại chủ đề chính, hôm nay mình mới biết đến ở Got It có rất nhiều anh em đi làm chỉ vì đam mê, mà điển hình là câu chuyện của cậu em rất thân với mình.

Tóm gọn là cậu em sẽ phát lì xì cho 20 người đầu tiên reply vào thread bên trên trên Slack, và người nhanh tay nhất sẽ nhận được nhiều tiền nhất. Mình cũng rất muốn ăn được số tiền nhiều nhất đó, nhưng thời khắc đất trời chuyển mình mình lại ngồi mở máy tính, nhìn đồng hồ, tay rà phím enter thì cũng không có vui lắm, mình còn phải đi xông đất nữa. Lại được inspired bởi AI Dinesh trong bộ phim Silicon Valley. Mình quyết định sử dụng Slack API để có thể ăn được giải đó nhưng vẫn không cần ngồi canh đồng hồ.

Thực thi

Nói sơ qua về cách làm: (1) mình sẽ sử dụng một con Slack Bot, sau đó (2) trao quyền cho nó để nó có thể (3) gửi tin nhắn dưới danh tính của mình.

Tạo slack bot

Rất đơn giản, bạn chỉ cần truy cập vào https://api.slack.com/apps/new để tạo một con bot (App) mới, điền thông tin về App name và Workspace mà bạn muốn tích hợp nó vào

Trao quyền cho bot

Bước quan trọng tiếp theo đó là cần trao quyền cho con bot để nó có thể gửi tin nhắn thay mình (send message on your behalf). Ở màn hình sau khi tạo app xong, chọn OAauth & Permissions, sau đó scroll xuống và chọn quyền chat:write ở dưới mục User Token Scopes.

Tada. Vậy là bạn đã cấp quyền xong cho con bot. Bây giờ hãy install con bot ở mục Install App. Sau khi hoàn thành, bạn sẽ có token để sử dụng Slack API.

Gửi tin nhắn

Để gửi tin nhắn, ta sẽ sử dụng endpoint https://api.slack.com/methods/chat.postMessage. Tới đây bạn có thể sử dụng SDK của Slack để gửi tin nhắn bằng ngôn ngữ mà bạn quen thuộc (Python, Javascript…), hoặc tạo request bằng Postman hay cURL. Trong tình huống của mình, mình sẽ sử dụng công cụ Tester ngay trên trang document của Slack API. Về cách sử dụng trong document cũng nói rất rõ nhưng tóm gọn lại sẽ có vài trường cần lưu ý:

- token: Token của con bot bạn mới có từ bước trước

- channel: channel mà bạn muốn gửi tin nhắn. Có thể là một kênh bất kỳ hoặc Direct Message. Bạn lấy giá trị của channel bằng cách chuột phải vào cuộc hội thoại và chọn Copy Link, phần giá trị sau cùng sẽ là giá trị bạn cần truyền vào. Ví dụ C1234567890

- as_user: set là true, nếu bạn muốn con bot gửi tin nhắn dưới danh tính của mình

- text: nội dung bạn muốn nhắn

- thread_ts: trong trường hợp bạn muốn gửi tin nhắn đến một thread, bạn cần truyền giá trị này vào. Cái này hơi tricky một chút. Bạn cần copy link của thread rồi biến đổi một chút, ví dụ link thread của bạn là

https://yourworkspace.slack.com/archives/G01N6H4GUSV/p161305029701030

thì thread id sẽ là 1613050297.010300. Mình có viết một hàm để transform từ link thread sang thread_ts, các bạn có thể sử dụng luôn:

function getThreadId(link) {
  const matches = link.match(/\d+/g);
  const id = matches[matches.length - 1];
  const threadId = id.slice(0, 10) + "." + id.slice(10, id.length);
  console.log("threadId", threadId);
  return threadId;
}

Ví dụ mình muốn gửi một tin nhắn Hello World tới một channel, nó sẽ có dạng như sau:

Tuy nhiên, với chat.postMessage, bạn chỉ có thể gửi tin nhắn ngay tại thời điểm gửi request đi. Nếu muốn “hẹn giờ” thì làm thế nào? Thật may, Slack cung cấp cho ta thêm chat.scheduleMessage, có thể sử dụng để gửi một tin nhắn tại một thời điểm hẹn trước trong tương lai. Cách sử dụng y hệt chat.postMessage, chỉ thêm duy nhất parameter post_at nhận vào là một UNIX timestamp, bạn có thể tính toán ra từ https://www.epochconverter.com.

Giật lì xì

Voilà. Vậy là bên trên là khái quát cách bạn có thể sử dụng Slack API để gửi tin nhắn dưới danh tính của mình. Mình đã sử dụng cách này để giật lì xì từ cậu em, schedule một message vào đúng 12 giờ 1 giây, với suy nghĩ buffer thêm 1 giây chắc cũng chẳng có ai nhanh hơn được. Nghĩ rằng kèo này thơm rồi. Cho đến khi… có đến ba người khác ngồi rình đồng hồ, reply nhanh hơn và lì xì giá trị cao nhất tuột khỏi tầm tay 😭😭😭

Known issue

Với các tin nhắn gửi bởi API, nó sẽ không khác gì tin nhắn gửi bởi chính bạn khi sử dụng Slack App/ Slack Web. Nhưng nếu bạn xem bằng Slack Mobile App, có thể avatar của tin nhắn đó sẽ có vấn đề.

Kết thúc

Bài viết đã sơ lược cách bạn có thể gửi tin nhắn dưới danh tính của bạn bằng API, thậm chí có thể hẹn giờ gửi tin nhắn đó đi được nữa. Hi vọng nó sẽ giúp ích được bạn trong trường hợp cụ thể. Chúc mừng năm mới!

Bài học cho tâm trí khi chạy chậm

Mon, 17 Aug 2020 18:28:58 GMT

Bài viết được dịch sang tiếng Việt từ bài viết Mind lessons from slow running với sự đồng ý của của tác giả Carolina Perez Sanz. Các bạn có thể đọc bài viết gốc tại địa chỉ sau đây https://carolinaperezsanz.com/2020/08/13/mind-lessons-from-slow-running

Bài học cho tâm trí khi chạy chậm

Khi tôi tìm hiểu về việc chạy ở Zone 2, tôi nghĩ đó là điều gì đó chỉ những người chơi ultra-marathon mới cần thực hiện. Chạy mà lại giữ cho nhịp tim thấp? Điều đó là không thể. Nhưng nó được biết đến là một phương pháp luyện tập với rất nhiều lợi ích: tăng sức bền, giảm chấn thương, giảm cân. Điều đó khiến tôi thực sự muốn thử nghiệm.

Tôi lại là một người hiếu thắng, nếu người khác làm được, tôi phải chứng tỏ rằng tôi cũng làm được.

Ngày đầu tiên thực sự đau đớn: tôi chạy 1 dặm trong 16 phút (pace ~ 10: 00) để giữ cho nhịp tim dưới ngưỡng Zone 2. Thật là xấu hổ khi tôi cần phải mất đến 16 phút để hoàn thằng 1 dặm.

Trong đầu tôi liên tục có những lời nói “Mày có phải là một runner không vậy?” “Nhìn mày kìa! Mày đang lê lết từng bước một và mày nghĩ mày có thể chạy được marathon?” Mỗi lần có một người chạy vượt qua, là một nhát dao đâm ngay vào lòng tự trọng của tôi vậy. Có những người đi bộ thậm chí còn đi nhanh hơn tôi!

Nhưng tôi không bỏ cuộc, sự hiếu thắng chính là năng lượng cho tôi.

Hôm nay, sau năm tháng cố gắng liên tục không ngừng nghỉ, lúc lên lúc xuống, đôi lúc thất bại cũng như thành công, tôi thấy một sự thay đổi lớn. Sự bền bỉ của tôi ngày hôm nay tốt hơn rất nhiều, chân tôi không bị đau sau các buổi chạy dài, và tôi không cần phải dành cả một ngày để hồi phục nữa.

Nhưng quan trọng hơn hết là những bài học về tâm trí mà tôi đã đúc kết được.

Hiện tại (Presence)

Mọi hướng luyện viên đều bảo bạn rằng hãy chạy cây số hiện tại, chứ đừng chạy những cây số ở phía trước. Điều đó đúng cho mọi kiểu chạy, và nó đặc biệt quan trọng với tôi khi tập luyện ở Zone 2.

Tâm lý của tôi muốn tăng tốc để hoàn thành bài tập một cách nhanh nhất có thể. Nhưng để giữ cho nhịp tim thấp, và giảm pace xuống, yêu cầu sự tập trung ở hiện tại với mọi bước chạy. Nó làm tâm trí tôi chậm lại, khiến cho cả năm giác quan của tôi chỉ tập trung vào một thứ - đó là bài chạy .

Phần thưởng thật sự to lớn: Tôi yêu thích mọi thứ tôi làm, và tôi sẽ làm nó tốt hơn, vì tôi làm với toàn bộ tâm trí và sự tập trung của mình.

Và khả năng tập trung ở hiện tại giúp ích rất nhiều trong cuộc sống của tôi. Đó là khi tôi cần phải giải quyết bất đồng với khách hàng của tôi, hay là như khi tôi lắng nghe một người trong đội nói với tôi điều gì đó quan trọng đối với họ, hay là khi nghe con trai tôi chia sẻ về việc cậu bé cảm thấy mất hứng thú trong việc học ở trường.

Khi tôi hoàn toàn sống ở hiện tại, mọi người cảm thấy được chia sẻ và lắng nghe. Tôi thể hiện sự quan tâm vì tôi quan tâm đến họ. Với tôi, điều này là nền tảng cho việc tin tưởng và thấu hiểu nhau.

Tập trung (Focus)

Tập trung là việc giải phóng tâm trí ra khỏi những việc không cần thiết khi đang làm một công việc cần sự chú ý cao độ.

Khi tôi chạy ở Zone 2, tôi hướng tâm trí vào những yếu tố giúp tôi đạt được mục đích giữ nhịp tim dưới 125 nhịp trên một phút. Tất cả những thứ khác đều không quan trọng. Tôi tập trung vào hơi thở, bước chạy (cadence), dáng chạy. Tôi không quan tâm đến nhiệt độ, quãng đường phía trước, thời gian còn lại, và những runner khác.

Cái tôi của tôi đã biến mất và tôi không còn quan tâm đến người khác (hay chính bản thân tôi) nghĩ gì hay cách tôi chạy có hoàn hảo hay không.

Khả năng tập trung cao độ giúp tôi làm mọi việc với năng suất cao hơn. Tôi hành động thay vì để cho tâm trí mình sao nhãng bởi những thứ không quan trọng.

Tôi lập ra kế hoạch và thực hiện: tôi viết khi đó là thời gian viết bài, tôi gọi điện thoại khi đến thời gian gọi điện thoại.

Tư duy: từ cố định đến phát triển (Mindset: from fixed to growth)

Tôi có thể hoàn thành được điều gì nữa? Tôi có thể đi được bao xa? Tôi sẽ là ai sau khi tôi hoàn thành buổi chạy này, buổi chạy ngày mai và buổi chạy tuần tới? Điều gì sẽ mở ra với tôi khi tôi hoàn thành cuộc đua ultra-marathon?

Liệu còn điều gì là có thể nữa không?

Sự tò mò về bản thân trái ngược hoàn toàn với tư duy ngờ vực mà tôi có trước khi tôi tập chạy Zone 2. Tôi không còn chỉ trích các bài chạy cũng như khả năng và phong độ của mình nữa.

Thay vào đó, tôi tò mò về bản thân và tâm trí của mình: đâu là giới hạn của tôi hôm nay? Đâu là giới hạn của tôi ngày tới, tuần tới, năm tới?

Bây giờ tôi biết rằng tôi có thể làm bất cứ điều gì nếu tôi đặt toàn tâm toàn ý vào nó. Tôi biết rằng kỹ năng tôi có hôm nay không dự đoán được khả năng trong tương lai của tôi vì tôi có thể học hỏi. Tôi biết rằng tương lai của tôi sẽ không bị bó buộc vào việc tôi là ai vào ngày hôm nay, vì tôi luôn có thể thay đổi - nếu tôi muốn.

Bạn là ai ngày hôm nay? Bạn muốn trở thành ai vào ngày mai? Giới hạn hôm nay của bạn là gì? Bạn muốn điều gì vào ngày mai?

Quản lý mật khẩu làm sao để không bị hack - Bảo vệ bản thân với mật khẩu an toàn

Mon, 03 Aug 2020 15:10:47 GMT

Đôi khi bạn lại thấy một dòng trạng thái “Bạn A bạn mình bị mất nick facebook, xin mọi người đừng chuyển tiền nếu nhận được tin nhắn”, hay nhận được lời than thở “Mình mới bị mất nick instagram”, hay một fanpage/ group bị bay màu do admin bị hack nick. Đó đều là những vụ tấn công, và phần nhiều trong số đó là các vụ tấn công liên quan đến việc mật khẩu bị đánh cắp. Trong bài viết này mình xin chia sẻ về tầm quan trọng của việc có mật khẩu an toàn và cách để chúng ta bảo vệ bản thân bằng cách cài đặt mật khẩu an toàn.

Bài viết này lấy cảm hứng từ buổi livestream Hỏi đáp về sử dụng internet an toàn. Mình rất khuyến khích các bạn dành thời gian xem livestream này (đã được ghi lại trên youtube), thực sự rất hay và cung cấp rất nhiều thông tin chuyên sâu và bổ ích.

Chúng ta hãy cùng nghe câu chuyện của anh K nhé.

K là một nhân viên của một công ty tư vấn bất động sản. K có một email công ty để trao đổi với sếp và tư vấn khách hàng, một email cá nhân, một tài khoản facebook, một tài khoản ngân hàng và rất nhiều tài khoản trên các diễn đàn, dịch vụ khác. K sử dụng riêng một mật khẩu cho email công ty, còn lại tất cả các dịch vụ khác K đều để chung một mật khẩu mặc định.

Một ngày nọ, diễn đàn Hoa Phượng mà K tham gia bị hack, hacker lấy được toàn bộ mật khẩu của người dùng diễn đàn. K cũng là một nạn nhân. Kẻ tấn công sau khi có được mật khẩu của K thì tiến hành thử đăng nhập vào các dịch vụ khác như Facebook, Gmail, Internet Banking bằng mật khẩu của K tại diễn đàn Hoa Phượng. Thật may mắn cho tên hacker đó, K đặt mật khẩu các dịch vụ giống nhau, nên hắn đã truy cập được vào hầu như tất cả các dịch vụ K sử dụng.

Hắn vào được facebook giả danh K mượn tiền bạn bè K.

Hắn đăng nhập vào tài khoản ngân hàng của K, tiến hành chuyển khoản toàn bộ số tiền K tích cóp trong 3 năm trời (mã OTP có thể nhận qua email cá nhân).

Hắn tìm thấy địa chỉ email công ty của K nhưng không thể đăng nhập, nhưng có thể reset mật khẩu sử dụng email cá nhân của K. Không lâu sau, rất nhiều thông tin nhạy cảm về khách hàng và chiến lược bán hàng của công ty K đã bị bán cho công ty đối thủ, khiến công ty của K thiệt hại rất nhiều tiền, công ty đối thủ tiết lộ K chính là người đã làm lộ thông tin nhạy cảm và K đang đứng trước nguy cơ mất việc. Và tất cả bắt nguồn từ việc K đặt tất cả các mật khẩu giống nhau.

Câu chuyện trên nghe có vẻ hơi đen tối và “chắc nó chừa mình ra”. Nhưng thực sự kịch bản trên là hoàn toàn có thể xảy ra nếu chúng ta vẫn giữ cho mình một thói quen đặt mật khẩu không an toàn. Mật khẩu không an toàn là mật khẩu quá dễ đoán như tên tuổi nguyenvank, ngày sinh 01021997, hay quá ngắn như 123456, hay quá phổ biến như password, iloveyou… Đặc biệt đó là sử dụng một mật khẩu cho tất cả các tài khoản khác nhau. Hàng ngày chúng ta sử dụng hàng trăm dịch vụ trực tuyến, không thể biết khi nào một hệ thống gặp sự cố bị lộ mật khẩu. Hay khi nào chính chúng ta vô tình làm lộ ra mật khẩu của một dịch vụ nào đó. Và khi đó, hacker hoàn toàn có thể truy cập vào các tài khoản khác của bạn bằng cách thử với mật khẩu bị lộ, một viễn cảnh tương tự như K hoàn toàn có thể xảy đến với bạn (có thể ít đen tối hơn).

Lời khuyên đưa ra đó là bạn cần có một mật khẩu phức tạp, tốt nhất là trên 12 kí tự trở lên, bao gồm cả kí tự chữ, số và kí tự đặc biệt. Một tip để sinh ra mật khẩu an toàn đó là hãy nghĩ ra một câu thật dài và những cách mã hóa cho riêng mình. Ví dụ: cuoituanthid1ch0iodaub@ygio, hay belen3bedima^~ug1ao, hay daylam0tcaimatkhauratdai!. Và điều quan trọng nhất đó là CÁC TÀI KHOẢN KHÁC NHAU PHẢI CÓ MẬT KHẨU KHÁC NHAU. Nhưng đến đây, bạn đọc có thể sẽ thắc mắc: Tôi sử dụng 10 dịch vụ khác nhau, mỗi dịch vụ tôi lại mất công nghĩ ra một mật khẩu phức tạp, thì làm sao tôi có thể nhớ được hết? Thôi tôi đặt vài mật khẩu phức tạp cho các dịch vụ quan trọng như email, ngân hàng. Còn các dịch vụ không quan trọng lắm thì cứ để chung hết một mật khẩu đơn giản đi, đằng nào cũng “không quan trọng” mà. Nhưng, hãy xem lại câu chuyện của bạn K, bạn ý đã đặt mật khẩu quan trọng cho email công ty rồi, nhưng vẫn bị hack mất đó thôi. Nên việc suy nghĩ “tài khoản không quan trọng thì chung mật khẩu cũng được” là một suy nghĩ chúng ta nên thay đổi.

Một điểm cần lưu ý thêm đó là việc an toàn sẽ có cái giá của nó, nó không miễn phí. Ví dụ như cái cửa ra vào. Nếu muốn tiện lợi thì có thể không cần khóa, chỉ khép cửa vào thôi, rất tiện. Nhưng trộm có thể vào nhà bạn và khiêng hết đồ đạc đi. Ngược lại, nếu bạn muốn an toàn, bạn phải khóa trong, khóa ngoài, khóa trên, khóa dưới, khóa thêm cả vân tay. Như thế sẽ khiến trộm khó có thể vào nhà bạn được nhưng bạn lại đánh mất đi một chút tiện lợi.

Nhưng làm thế nào đặt được mật khẩu phức tạp, lại còn nhiều, nhưng vẫn có thể quản lý được chúng? Có phải đây chính là cái giá mà mình phải trả khi muốn an toàn không. Và đó là khi các phần mềm quản lý mật khẩu như một vị cứu tinh khiến cuộc sống dễ dàng hơn rất nhiều.

Phần mềm quản lý mật khẩu (QLMK - Password Manager) là phần mềm giúp người dùng tạo ra các mật khẩu an toàn, lưu trữ các mật khẩu đó (và có thể tự điền vào khi người dùng cần đăng nhập). Các phần mềm QLMK sử dụng công nghệ Vault để lưu trữ toàn bộ mật khẩu của người dùng dưới dạng mã hóa, chính bên cung cấp cũng không thể đọc được mật khẩu của bạn, chỉ có thể giải mã bằng master password. Phần mềm QLMK giúp việc đặt mật khẩu khác nhau cho các dịch vụ khác nhau bỗng trở nên dễ dàng. Phần mềm cũng giúp người dùng tạo ra các mật khẩu đủ phức tạp và an toàn, ta thậm chí còn không cần phải nhớ mật khẩu đó. Việc duy nhất và quan trọng nhất chúng ta cần làm đó là bảo vệ master password. Sử dụng các phần mềm QLMK còn giúp chúng ta phòng chống tấn công phishing (giả mạo trang đăng nhập), vì các phần mềm QLMK sẽ tự động điền vào form đăng nhập, nếu trang web không đúng, nó sẽ không tự điền, ta có thể nhận ra được mình đang bị lừa phishing. (Một điều buồn cười đó là chúng ta thường bị phishing vì chúng ta nhớ mật khẩu. Nếu chúng ta không nhớ mật khẩu, thì sẽ không bị phishing nữa).

Có rất nhiều phần mềm QLMK trả phí và miễn phí. Dĩ nhiên, tiền nào của nấy, các phần mềm trả phí thường sẽ có trải nghiệm người dùng tốt hơn các phần mềm miễn phí một chút. Trong bài viết này, mình xin giới thiệu với các bạn phần mềm bitwarden vì các lý do:

Nó có phiên bản miễn phí.
Nó có phiên bản trả phí. Giá của phiên bản trả phí cũng rất hợp lý.
Open source
Hỗ trợ tất cả các nền tảng phổ biến. Có phần mềm trên Windows, Mac, Linux, có các extension cho tất cả các trình duyệt phổ biến, có app trên Android và iOS, có web app.
Trải nghiệm người dùng (UX) tương đối tốt.

Download tại đây: https://bitwarden.com/download/ Đăng ký tài khoản miễn phí tại đây: https://vault.bitwarden.com/#/register

Vì Bitwarden vận hành với mô hình Freemium nên ta có thể yên tâm về việc sử dụng phiên bản miễn phí của nó. Bạn có thể trả tiền để sử dụng bản trả phí với nhiều tính năng bảo vệ hơn. Vì là mã nguồn mở nên việc phát hiện và cung cấp các bản vá lỗi nếu có cũng sẽ rất minh bạch và nhanh chóng. Bitwarden cung cấp phần mềm cho tất cả các nền tảng phổ biến khiến cho trải nghiệm của người dùng khi sử dụng nhiều thiết bị khá mượt.

Dưới đây là một vài hình ảnh khi sử dụng bitwarden:

Đăng ký https://vault.bitwarden.com/#/register

Tạo một mật khẩu an toàn mới và lưu vào Bitwarden Vault bằng Bitwarden Chrome Extension

Sinh ra mật khẩu an toàn

Tự động điền mật khẩu bằng Bitwarden Chrome Extension

Việc sử dụng Bitwarden là rất đơn giản và trực quan. Trên đây là các thao tác cơ bản với Bitwarden Chrome Extension. Bitwarden trên Windows, Mac, Linux, Android, iPhone cũng rất đơn giản và dễ dùng, mọi người hoàn toàn có thể cài đặt và làm quen nhanh chóng.

Kết luận: Chúng ta ngày càng sử dụng nhiều dịch vụ trực tuyến, kết nối với internet ngày càng nhiều hơn. Điều đó đồng nghĩa với việc chúng ta càng cần phải cẩn trọng hơn trong việc bảo vệ bản thân mình. Việc có các mật khẩu tốt là tiền đề cho việc sử dụng internet an toàn hơn. Khi đó, không những bảo vệ bản thân, mà bạn đang bảo vệ người thân, gia đình, công ty mình, và rộng ra là toàn xã hội.

Clean Code 1 - Câu chuyện về Code xấu giết chết công ty

Tue, 23 Jun 2020 20:20:39 GMT

🌍 English translation by whoz.dev

Bài viết sử dụng tư tưởng của Uncle Bob trong chuỗi video về Clean Code

Câu chuyện

Bước đầu thành lập team

Hãy tưởng tượng bạn là một lập trình viên tài năng, đã có vài năm kinh nghiệm. Công ty của bạn quyết định xây dựng một sản phẩm phức tạp, nhưng vô cùng thú vị, và cũng tương đối thử thách, được kì vọng sẽ đem đến thành công xuất sắc cho công ty trong tương lai. Team gồm 5 engineer tốt nhất trong công ty, trong đó có bạn, được chọn ra để xây dựng sản phẩm này.

Thật tuyệt khi được làm việc ở một dự án mới hoàn toàn. Mọi thứ sẽ được làm mới từ đầu. Star Team (gọi tắt của team 5 người được chọn) sẽ có thể áp dụng những công nghệ mới nhất, hot nhất hiện tại để áp dụng vào dự án mới này. Họ thử nghiệm, rồi chọn ra được một stack họ cho là tốt và hợp lý nhất với công ty: hiệu năng nhanh, tốc độ phát triển nhanh chóng, nhiều tài liệu có sẵn, cộng đồng hỗ trợ tốt. Và. Bùm. Năng suất làm việc của Star Team cực cao.

Đó là sáng thứ hai đầu tuần, sau khi kickoff meeting về kế hoạch phát triển sản phẩm. Tính năng đầu tiên Star Team sẽ làm đó là tính năng Authentication. Bình thường một tính năng như này team sẽ cần mất từ 3 đến 4 ngày để có thể hoàn thiện. Nhưng, Star Team, đã deliver tính năng này ngay… 4 giờ chiều hôm đó. PM không tin. CTO không tin. CEO không tin. Và chính các thành viên của Star Team cũng không tin vào chuyện đó. Làm sao chuyện đó có thể là sự thật được? Nhưng rất tiếc nó lại là sự thật. Với một stack cực tốt được các gã công nghệ khổng lồ như Google, Facebook sử dụng và chống lưng. Cộng với việc được implement bởi một team ngựa giống. Năng suất việc bây giờ còn nhanh hơn cả tốc độ lật bánh tráng Đà Lạt.

Một tháng sau đó, việc này vẫn tiếp tục tiếp diễn và chưa có dấu hiệu sẽ dừng lại. Các feature cứ nối đuôi nhau được release. Feature lâu nhất chỉ mất có hai ngày là hoàn thành. Chức năng chính của sản phẩm đã có thể hoạt động tương đối tốt để đem đi chào hàng, thậm chí nhiều khách hàng đã mạnh tay chi tiền mua sản phẩm, sẵn sàng sử dụng sản phẩm khi còn đang ở bản alpha.

Mọi chuyện diễn ra rất êm đẹp. Engineer rất hạnh phúc vì năng suất làm việc của họ lên tận mây xanh. Đội ngũ quản lý sung sướng vì ngày càng nhiều khách hàng mua sản phẩm. Hợp đồng về ngày càng nhiều, yêu cầu về việc thêm các feature cũng tăng thêm, họ cũng feedback về các feature cũ để phù hợp với nhu cầu hơn. Tiền về, quản lý, engineer đều được tăng lương, thưởng. Với các feature request và feature feedback với tốc độ phát triển hiện tại như tên lửa thế này, team không lo thiếu việc, sản phẩm sẽ ngày càng hoàn thiện hơn và lại có nhiều khách hàng hơn. Một tương lai sáng lạn mở ra trước mắt toàn bộ Star Team và ban quản lý công ty. Star Team ngày càng làm việc chăm chỉ, rất chịu khó update và học hỏi, áp dụng những cái mới vào project. Manager thì đã họp và lên một Business Plan cực kì chi tiết cho 6 tháng tới với một sự tự tin cực kì lớn.

Nhưng, có vẻ như có cái gì đó không đúng ở đây. Nhưng chưa ai phát hiện ra cả

Sang tháng thứ hai, mọi chuyện đã ổn định hơn. Tốc độ phát triển cũng không còn “crazy” như tháng đầu tiên nữa. Trung bình Star Team ship một tính năng mới trong thời gian từ 2 đến 3 ngày. Dù không nhanh như tháng đầu tiên, nhưng đó vẫn là một tốc độ siêu nhanh. Họ vẫn có những khách hàng mới mua sản phẩm trong tháng này.

Sang tháng thứ ba, với lượng khách hàng B2B (khách hàng là Business) và B2C (khách hàng là người dùng đơn lẻ) tăng lên nhiều, các feedback về các tính năng đã xây dựng, feature request từ người dùng tăng lên đột biến. Cộng với các tính năng trong roadmap có sẵn từ trước, Star Team có rất nhiều việc phải làm. Tốc độ ship tính năng trung bình khoảng 4 ngày. Mọi chuyện vẫn tươi đẹp với cả Star Team và đội ngủ quản lý trong tháng này. Họ có họp với nhau tại sao thời gian ship một tính năng lại lâu hơn so với những tháng trước. Và họ đưa ra vài lý do:

Vì các tính năng ban đầu tương đối đơn giản, phần lớn là MVP (Minimum Viable Product), nên phát triển khá nhanh.
Hệ thống đã có khung sườn, nên ghép các tính năng mới vào mất thời gian hơn là chỉ ghép vào một trang trắng. Đây cũng là lẽ dĩ nhiên, không có gì đáng ngại cả.
Các tính năng khách hàng yêu cầu, bug fix ở thời điểm này khó hơn thời gian đầu, nên làm lâu hơn là lẽ dĩ nhiên.
Lúc đầu vì muốn đưa sản phẩm ra nhanh nhất có thể, tránh đối thủ hốt mất khách hàng, nên Star Team đã tình nguyện OT rất nhiều nên việc code nhanh là dễ hiểu. Bây giờ khi đã có một tập khách hàng sẵn sàng trả tiền, nên nọ không cần phải như thế nữa.

Những lý do trên, tựu chung lại, đều là những nguyên nhân khách quan, mà một sản phẩm khi lớn dần lên sẽ phải gặp. Cả team đều đồng ý là không có vấn đề gì cả.

Bước ngoặt

Nhưng bước ngoặt của câu chuyện lại nằm ở tháng thứ bảy. Khi Star Team deliver feature X mất đến 2 tuần, trong khi ở trong roadmap của Manager Team, chỉ là 1 tuần. Manager Team đã thất hứa với một khách hàng B2B, khiến họ hủy hợp đồng. Star Team và Manager Team có buổi họp với nhau về vấn đề năng suất làm việc không được như kì vọng, không còn nhanh như tháng đầu tiên. Nhưng Star Team chỉ giải thích là hệ thống phức tạp hơn nên cần nhiều thời gian để tích hợp tính năng mới vào.

Những tháng sau đấy, chuyện tương tự cũng xảy ra một vài lần. Thời gian trong Business Plan và thời gian phát triển thực tế chênh nhau một khoảng lớn dần. Đó là Scary Gap.

Đến tháng thứ 9, thời gian develop feature vẫn tiếp tục tăng. Star Team họp với Manager Team để tìm ra giải pháp. Và họ quyết định một phương án, đó là: thuê thêm engineer.

Tháng thứ 10, 5 bạn engineer mới được tuyển chọn khắt khe gia nhập team, đem đến một hi vọng lớn lao năng suất làm việc sẽ tăng gấp đôi. Tuy nhiên, trong tháng thứ 10, năng suất làm việc lại có chút… giảm. Nhưng điều đó là dễ hiểu, vì Star Team mất khá nhiều thời gian để phỏng vấn các ứng viên. Và sau khi các bạn mới vào làm việc, các bạn cần thời gian để onboard, và chính các thành viên hiện tại của Star Team là những người hướng dẫn các bạn mới.

Tháng thứ 11, các bạn mới đã quen với code base structure, convention, năng suất làm việc của cả team đã trở lại như tháng thứ 9.

Đến tháng 12, năng suất làm việc cũng đã tăng lên. Tháng thứ 13, 14 năng suất làm việc… vẫn như tháng thứ 12. Manager Team không hiểu tại sao. Đáng ra năng suất làm việc phải tăng gấp đôi chứ (10 = 5x2). Chỉ duy có engineer team hiểu, vì họ biết rằng có một định lý

Một việc một engineer làm trong 1 ngày thì hai engineer sẽ làm trong hai ngày 😂😂

—Ai đó trên mạng

Manager Team dần chấp nhận với việc engineer team đông gấp đôi nhưng năng suất làm việc chỉ tăng gấp 1.3 lần. Dĩ nhiên, họ không vui vì quỹ lương phình to ra nhưng kì vọng lại không đạt được. Họ tiếp tục thuê thêm 5 kỹ sư nữa nhưng năng suất làm việc ngay sau khi thuê thêm nhân công lại giảm và tăng dần sau 1 tháng, nhưng cũng chỉ đạt đỉnh điểm 1.8 lần so với ban đầu (kì vọng 15 người sẽ tăng năng suất 3 lần)

Tháng thứ 15, công ty chuyển hướng sang phát triển duy nhất sản phẩm này.

…

Vậy là đã 1.5 năm từ khi công ty bắt đầu quyết định xây dựng sản phẩm. Hệ thống đã khá phức tạp và lớn, năng suất làm việc thì ngày càng giảm. Một buổi họp đã được diễn ra để giải quyết vấn đề này. Việc thuê thêm nhân công có vẻ không khả thi vì tính không hiệu quả của nó được chứng minh trong quá khứ. Và sau một buổi chiều brainstorm, cả engineer team đã đi đến một giải pháp chung, đó là:

ĐẬP ĐI XÂY LẠI

Manager Team rất không vui, nhưng họ không còn lựa chọn nào khác khi giữ nguyên hệ thống hiện tại với năng suất làm việc thảm hại. Thực sự thì engineer team không lười. Họ chăm, họ rất chăm ở đằng khác. Nhưng một hệ thống đã quá lớn, quá nhiều những logic đặc biệt để chiều lòng khách hàng không ai dám xóa, những tính năng làm vội để chạy deadline dính đầy technical debt với lời hứa hẹn: “sẽ sửa sau”/ “khi nào rảnh thì sửa”, một kiến trúc đồ sộ đã cũ kĩ, khiến cho engineer dù làm việc 8 - 10 tiếng một ngày cũng không thể ship/ release feature nhanh được.

Business Plan thì vẫn phải tiếp tục, Manager Team không thể bảo khách hàng chờ vài tháng nữa chúng tôi sẽ có một hệ thống hoàn toàn mới, tốt hơn, nhanh hơn cho bạn sử dụng (thực ra khách hàng họ cũng chả quan tâm hệ thống mới làm gì, miễn họ có sản phẩm dùng được là được). Việc add feature, fix bug vẫn phải diễn ra trên hệ thống cũ. Và việc xây dựng hệ thống mới, được approve, nhưng chỉ với 5 thành viên nguyên thủy của Star Team đảm nhận, vì họ có kinh nghiệm nhất, hãy gọi họ là Tiger Team. Những người còn lại vẫn tiếp tục làm việc ở code base cũ, với một sự thèm thuồng nhất định.

Tiger Team tìm ra được một stack mới, tốt hơn stack hiện tại về mọi mặt. Họ bắt đầu implement hệ thống mới. Năng suất làm việc lại cực kì nhanh như xưa. Nhưng một vấn đề hiện hữu đó là: “Requirement là gì?“. Chẳng có một cái tài liệu nào cụ thể về tất cả các requirement đang có ở hệ thống hiện tại cả. Nó lắt nhắt, rải rác ở ticket, ở các đoạn chat public, private trên Skype, Slack giữa PM và engineer. Thậm chí nó còn ở … mồm PM sang tai của engineer. Tại thời điểm phát triển, có engineer, PM và trời biết tính năng đó là gì. Bây giờ thì chỉ có trời mới biết chính xác requirement là gì. Thực ra vẫn còn một nơi duy nhất chứa đầy đủ các requirement trong quá khứ, đó chính là code base cũ. Tiger Team lục lại code base để đọc lại các logic cũ, đôi khi là cop nguyên logic một hàm dài 2 trang sang, chỉ đổi lại ngôn ngữ lập trình thể hiện.

Nhưng câu chuyện không dừng lại ở đó. Vì bug fix và new feature được thêm vào liên tục bên hệ thống cũ, nên hệ thống mới cũng cần có những thứ đấy. Bây giờ, một cuộc chạy đua mới thực sự bắt đầu.

Và cuộc đua đó diễn ra tới tận 2 năm trời. Ngày release phiên bản mới, shut down phiên bản cũ, cả công ty tập trung tại nhà sếp tổng, mở tiệc ăn mừng, quyết tâm nhậu không say không về, kể cả say cũng không thể về được. Và rồi 2h sáng, các cuộc gọi từ bên Customer Support liên tục đến với cả team vì những trục trặc lớn mà khách hàng phàn nàn khi họ chuyển sang hệ thống mới. Các lập trình viên ma men thở vẫn còn ra đầy hơi rượu đành hot fix, patch ngay lỗi, tìm ngay ra logic ở bên hệ thống cũ họ sót chưa bê qua hệ thống mới. Họ deploy ngay lúc 3h sáng, rồi lại chìm vào cơn mộng mị lúc nào không hay…

Liên tục những ngày sau đó, việc tương tự xảy ra. Manager Team đã quyết định dựng lại hệ thống cũ và sẽ duy trì đồng thời cả 2 phiên bản thêm một thời gian nữa, và khách hàng sẽ có quyền lựa chọn phiên bản cũ hoặc mới để sử dụng. Phiên bản mới được khuyến nghị, thậm chí còn được tặng ưu đãi để sử dụng phiên bản mới. Một loạt các engineer mới được thuê thêm để phát triển cả hai phiên bản cùng lúc.

Sau đó 4 tháng, hệ thống mới cũng bắt đầu phình to ra, năng suất làm việc giảm dần, một vòng lặp xuất hiện.

8 tháng sau đó công ty đóng cửa!

Thảo luận

Độc giả có thấy câu chuyện này quen không? Tôi tin chắc ít nhiều nếu làm đủ lâu trong ngành công nghệ bạn sẽ thấy đâu đó có những công ty gặp những vấn đề như thế này, sau đó đưa ra những giải pháp na ná như thế này, và cũng gặp những khó khăn na ná thế này về mặt tài chính, nhân sự, năng suất làm việc, sau cùng thậm chí phải đóng cửa.

Vậy tóm lại, nguyên nhân thất bại của công ty trên đó là gì?

Đó là code xấu. Việc code xấu đã dẫn đến hệ thống quá cồng kềnh, phức tạp, không realiable. Động chỗ này hỏng chỗ kia, không ai dám sửa. Nhìn một đoạn code rõ ràng không dùng nữa rồi, nhưng lần đầu xóa đi, app chết, khách hàng kêu oai oái. Lần hai xóa đi, logic chạy sai, khác hàng chửi, manager kêu oai oái. Lần thứ ba, à không có lần thứ ba nữa. Vì lần thứ ba engineer đã quá sợ để xóa đi một đoạn code “có vẻ như không dùng đến rồi”. Họ luôn tìm cách tránh phải động vào những đoạn code khó hiểu, những đoạn code thừa. Tựa như việc bạn dọn dẹp nhà cửa nhưng cứ tiếc một món đồ, sợ sau này sẽ cần, không dám vứt đi, nhưng thực tế là chả bao giờ dùng đến cả. Cộng với việc liên tục mua thêm những món đồ mới. Kết cục là nhà bạn chật kín với những món đồ không cần thiết và bạn chẳng thể bước chân ra khỏi nhà được nữa. Và thay vì sửa code xấu, team sợ hãi code xấu, và hi vọng code xấu sẽ hết khi xây dựng một hệ thống hoàn toàn mới. Nhưng thực chất, team vẫn copy rất nhiều logic cũ, đã “bẩn” từ hệ thống cũ sang hệ thống mới. Và việc năng suất làm việc tăng cao khi bắt đầu một hệ thống mới khiến chúng ta có một ảo tưởng đó là “đập đi xây lại” sẽ giải quyết được mọi vấn đề.

Việc đánh đổi chất lượng phần mềm, chấp nhận nợ kỹ thuật (Technical Debt) để đổi lấy thời gian release sản phẩm nhanh hơn cũng đóng một vai trò quan trọng trong sự thất bại của công ty trên.

Vậy giải pháp ở đây là gì?

You cannot deal with a mess by running from it. The only way to effectively deal with that mess is to turn around and face it, and find the rot and clean it

Chạy trốn khỏi code bẩn không phải là cách làm đúng đắn. Có nợ thì phải trả, hãy sống đẹp như những con thiên nga của Tchaikovsky. Nợ kỹ thuật tương tự như nợ ngân hàng. Nợ ngân hàng nếu cứ chần chừ không trả, sớm muộn cũng bị lấy nhà. Nợ kỹ thuật không trả, sớm muộn cũng bị lấy mất công ty.

Kết luận

Tóm lại, việc code clean ở trong môi trường công nghiệp là rất quan trọng. Nhưng nó cũng khá khó, nhất là với tốc độ phát triển phần mềm siêu nhanh như hiện nay. Sự khác biệt trong tư duy của đội ngũ kỹ sư phần mềm và đội ngũ quản lý sản phẩm cũng là một rào cản lớn khiến cho việc triển khai clean code khó khăn hơn. Mỗi kỹ sư không những cần trang bị cho mình những kỹ năng lập trình tốt, mà còn cần trang bị cho mình những kỹ năng lập trình sạch. Còn những nhà quản lý công nghệ cũng nên trang bị cho mình kiến thức về các công nghệ đang sử dụng, nhận thức về tầm quan trọng của một hệ thống sạch, để ngoài phát triển tính năng nhiều và nhanh còn cải thiện chất lượng sản phẩm qua thời gian nữa. Một tính năng được phát triển nhanh không có nghĩa là chất lượng tốt và tương lai tính năng đó sẽ không “hành” mình nữa.

Cảm ơn các bạn đã đọc. Trong bài viết tiếp theo, mình sẽ thảo luận tại sao code để lâu lại “bốc mùi” hay “hết hạn”. Các bạn hãy đón chờ các bài tiếp theo trong chuỗi các bài viết về Clean Code nhé.

Tham khảo:

https://www.oreilly.com/library/view/clean-code/9780134661742

Hello Hung.Dev

Wed, 27 May 2020 17:58:06 GMT

Xin chào các bạn. Mình đã quyết định chuyển nhà từ Wordpress sang hung.dev

Mình rất phấn khích khi chuyển từ nền tảng blog lớn số 1 thế giới, sang một nền tảng tương đối mới và thú vị là Gatsby. Với Gatsby, mình có thể tùy chỉnh mọi thứ theo ý thích của mình một cách nhanh chóng. Và ấn tượng ban đầu của mình với trải nghiệm viết trên đây cũng khá tốt.

Các bài viết mới sẽ được mình update qua Facebook Fanpage hung.dev và qua email qua tính năng Subscribe tại hung.dev

Hi vọng các bạn sẽ thích blog mới này. :D