refacore

localStorage, sessionStorage getItem trả về null chứ không trả về undefined. Em kiểm tra lại code xem có dùng sai func không? Có thể gọi qua func ultility nào đó và nó check expire_at rồi trả về undefined nếu expired. Còn get trực tiếp từ localStorage hay sessionStorage, có thì nó phải trả về. Khả năng là em dùng thư viện và config storage của nó về localStorage. Vậy là do hàm getToken của thư viện. Nếu thế e dùng thư viện gì? Xem lại tài liệu của nó chưa?

https://www.youtube.com/watch?v=K4K7HNavK4U https://alvaromontoro.com/blog/68002/creating-a-firework-effect-with-css

cách cổ điền thì lưu vào cookie thôi.

phức tạp hơn thì lưu vào local storage

phức tạp hơn nữa thì lưu vào sql db. Việc xử lý lượng truy cập lớn là việc riêng. Lưu luôn vào memory chứ cũng ko cần redis cho to chuyện.

Lớn nhỏ gì đều dùng cả. Cần phải biết đặc thù của hệ thống để lựa chọn. Khi nảy sinh vấn đề tìm một message broker thì bài toán là một hệ thống gồm nhiều hệ thống con giao tiếp với nhau, tức là không phải nhỏ.

Tất nhiên Redis thì dễ tiếp cận hơn còn kafka thì tốn công học nhất. Một hệ thống đang dùng kafka không có nghĩa nó không có redis. Redis để chạy broadcast thì rẻ tiền và giảm đáng kể độ phức tạp.

Vấn đề của trigger là hiệu năng kém. Đối với các dữ liệu thay đổi nhiều, dùng trigger có thể tèo luôn db chứ chưa nói tới việc sync sang bên khác.

Cách đơn giản nhất là viết job index lại db mỗi ngày, mỗi giờ

Cách đơn giản nhì là viết 1 job query các thay đổi. Tùy vào yêu cầu mà đặt tần suất thích hợp. Đây là cách được áp dụng đa số.

Cách cũng đơn giản là Thực hiện song song upsert sql và upsert elastic trên code golang. Hoặc gọi upsert elastic sau khi upsert sql thành công.

Cách hoành tráng nhưng phải xem xét: Dùng mấy tool quan sát db log như Capture Data Change của Kafka. Cái này dùng khi không có quyền thay đổi code application, nhưng mất công học. Trong trường hợp này, mình viết code rồi thì sửa luôn trên golang thôi.

Do các hàm test và mark sai địa chỉ, dẫn đến thuật toán chạy liên tục mà không loại bỏ được nhiều phần tử.

1ULL<<(idx % 63) phải là 1ULL<<(idx % 64) (63 sẽ sai với idx = 63)

Một số điểm cần tối ưu:

1. Xác định chỉ test số lẻ, có thể chỉ tạo mảng số lẻ sẽ tiết kiệm bộ nhớ.
2. i * i < limit => tính trước sqrt(limit)
3. Trước hàm mark có thể tối ưu hơn nữa:

// bằng cách này, mình chỉ truy xuất bộ nhớ 1 lần, các tính toán hoàn toàn nằm trong cpu
// cách cũ, mỗi lần gọi hàm mark, cpu đọc lại từ bộ nhớ ô nhớ thứ j / 64
uint64_t marked;
uint64_t j;
for (j = i * i; j < limit; j += i * 2) {
  marked |= 1ULL<<(j % 64);
}
p[j / 64] = marked; 

PS: phần tối ưu hàm mark chưa đúng và không hiểu quả với i > 31

1. Combo cũng là một product.
2. Nên tách Price ra khỏi product. Nó là phần quản lý giá riêng. Để thế khi có biến động giá, việc process order có thể bị sai, giá ở quá khứ khác giá hiện tại -> lên đơn sai, và cũng ko có lịch sử giá để truy vết. Để giá ở đây có thể được (với ý nghĩa là giá gốc), nhưng thường giá hiển thị không phải giá này.
3. Nên tách quantity ra khỏi product. Nó là phần quản lý tồn kho riêng. (Như thiết kế ở trên, chỉ có tồn kho cho product nói chung mà không có tồn kho cho product theo size).
4. Các thông tin như Size, Color là thuộc về Product Variant. Các hệ thống ecommerce đều có phần quản lý Variant và bán thực tế là Product Variant chứ không phải Product. Vậy quan hệ Product - Size là n-n
5. Product - Category là quan hệ n-n
6. Store - Product là quan hệ n-n

project user like là mối quan hệ n-n. Cách toàn diện nhất là tạo collection mới với 2 key projectId, userId. Như vậy có thể tìm ra ai đã like project cũng như user like project nào nhanh chóng.

Nếu không yêu cầu hiển thị những ai đã like project, có thể lưu projectId được like trong collection users, đồng thời tạo totalLikeCount trong collection projects. Khi like hay unlike thì cộng trừ số total này, đồng thời thêm/xóa projectId trong collection users.

Với expire time ngắn, khi người dùng đóng tab và token expired, khi mở lại tab sẽ không sử dụng lại được nữa.

Với expire time dài, khi người dùng đóng tab, có rủi ro là người dùng khác mở trang web và vẫn trong phiên của người dùng cũ. (token sống lâu thì thường được lưu trong localStorage).

Về mặt lý thuyết thì accessToken và refreshToken là khá bảo mật vì được truyền qua header. Giao thức https sẽ mã hóa cả header nên sẽ ngăn chặn được việc nghe trộm từ hacker. So sánh với Authorization Code, authorization code được truyền qua url (dùng cơ chế redirect để authenticate), nên authorization code không chứa thông tin người dùng mà chỉ dùng để lấy access token. authorization code mặc dù dễ lộ, nhưng dễ bị phát hiện và vô hiệu hóa (authorization code chỉ dùng 1 lần, cấp phát 1 access token, nếu hacker tranh dùng thì sẽ có 2 request lấy access token với cùng 1 authorization code và access token sẽ bị invalidate ngay lập tức).

Việc cài đặt expire time tùy thuộc vào thực tế. Với mobile app, expire time thường được cài khá lâu vì các app chạy trên private device. Hay các mạng xã hội như FB cũng dùng expire time dài. Nhưng các app cần bảo mật cao như app ngân hàng, thậm chí còn không refresh token và mỗi phiên làm việc chỉ tồn tại trong vài phút.

3 cách để đếm.

1. Đếm ngay khi mở web. Chỉ có header hoặc cookie được gửi đi. Nếu dùng cookie thì có thể bỏ qua được vấn đề IP.
2. Đếm sau khi mở web, call api đếm riêng. Cái này thì dễ tùy biến, thường đi theo cả tracking.
3. Google Analytics.

Phía server: Cũng không cần thiết phải redis. Nếu dùng cookie thì chỉ việc check ở request rồi call lệnh increase (nếu redis). Không dùng cookie thì có thể thêm tham số browser agent cùng với ip, hash rồi lưu cờ ở redis, có thể tăng một chút độ chính xác.

Gọi api chủ động thì muốn làm gì thì làm rồi.

1. Chương trình học có khác nhau không? Học thêm 1 năm thì được gì?
2. Bằng cử nhân và kĩ sư đối với nhà tuyển dụng có khác nhau không?
3. Học cử nhân rồi lên thạc sĩ hơn hay kĩ sư rồi dừng lại?
4. Nếu muốn du học thì bằng nào lợi hơn?

Để so sánh 2 hướng thì mục tiêu của e ra trường là gì?

1. Đi làm: Về mặt lý thuyết, bằng kĩ sư sẽ chú trọng đến thực hành. Nhưng:

• Giáo dục ở VN vẫn bị bệnh xa rời thực tế.
• Không thực hành nào bằng làm thật. 1 năm học kĩ sư khó so với 1 năm đi làm thực tế.

Điều đó không có nghĩa bằng kĩ sư vô dụng. Theo anh hiểu (chương trình của anh ngày xưa rất khác nên cũng phỏng đoán thôi), kĩ sư sẽ học thêm một số bộ môn chuyên sâu, trang bị cho em những kiến thức mà những năm đầu đi làm sẽ rất khó được tiếp cận. Đối với junior thì không hiệu quả, nhưng sẽ tốt cho công việc sau này, khi tiếp xúc sâu hơn với ngành nghề, kiến thức đấy sẽ thành lợi thế. Nếu không vội gì thì bỏ thêm 1 năm kĩ sư cũng không thể nói là thiệt.

Để đi làm thì theo anh thấy bằng cấp trong ngành này không thực sự quan trọng, trừ khi ngay từ đầu em đã nhắm tới những tổ chức yêu cầu bằng cấp, chứng chỉ, các tổ chức truyền thống có quy mô lớn. Dù sao bằng cấp cũng là vật đảm bảo để em bước những bước đầu tiên, cũng như đảm bảo sau này nếu có bất cứ thay đổi nào về định hướng.

Để đi làm đối với AI thì sẽ đặc thù chút, học lên sẽ tốt hơn. Vốn chưa có các bộ môn về AI trong các trường nên muốn học thêm về AI thì chỉ có học lên.

2. Học lên Cái này thì rõ ràng là học cử nhân, thạc sĩ rồi tiến sĩ cho nhanh.

solr query dùng syntax index của cassandra, nên có vẻ không truy xuất được json field theo cách này. Có 1 cách là viết custom tokenizer cho solr để xử lý column thủ công, nhưng có thể tích hợp sẽ phức tạp. Cách 2 chắc dễ làm và dễ maintain hơn.

Redis thường được dùng cho Caching chứ không phải lưu trữ. Mặc dù Redis cũng hỗ trợ snapshot để lưu và tải lại, nhưng cơ bản nó không phải dùng cho việc "lưu trữ dài hạn". Redis là csdl thứ cấp, không phải sơ cấp. Như vậy, thực ra dữ liệu về user vẫn được lưu trong csdl nào đó, sau đó được tải lên Redis để tối ưu cho việc truy xuất. Có thể giải thích việc lựa chọn Redis cho việc lưu profile (ngoài việc Redis nhanh ra):

• Profile là dữ liệu dạng Key - Value với Key là userId => Phù hợp lưu trong Redis (Key-Value database).
• Profile có kích thước nhỏ nhưng số lượng lớn. Hash của Redis phù hợp để lưu dạng này.

Bên cạnh đấy thì Redis cũng không đáp ứng được các yêu cầu:

• Xây dựng bộ lọc. Redis là Key Value DB nên query language rất hạn chế.
• Searching. Redis là Key Value DB nên query language rất hạn chế.
• Full-text search.

Điều đó có nghĩa là chúng ta sẽ lưu profile user ở nhiều dạng DB khác nhau, đáp ứng cho những yêu cầu riêng biệt. VD:

• Relation DB cho persistency.
• Redis cho việc truy xuất nhanh liên tục.
• Elasticsearch cho việc searching + filtering.
• Output cache - cache luôn render result của phần profile.

Redis chỉ là 1 trong số những db được sử dụng.