<code class="markdown-inline">The values for INT and LONG fields are represented using zig-zag encoding, so that smaller absolute values require fewer bits</code>, document của Netflix Hollow có 1 dòng như thế này, google thì cũng không có nhiều về topic này và khá sơ sài, vậy zig-zag enconding là gì mà có thể optimise được việc truyền và xử lí dữ liệu, mong nhận được giải đáp.

Hi anh em, mình đang muốn enable debug ui trên android simulator nhưng gặp lỗi này:<div class="markdown-block position-relative overflow-auto"> <pre> Error: Unable to resolve module ./debugger-ui/debuggerWorker.aca173c4 <span class="pl-k">from</span> /Users/xxx/Documents/projects/xxx/packages/mobile/.: <span class="pl-k">None</span> of these files exist: * debugger-ui/debuggerWorker.aca173c4(.native|.native.js|.js|.native.jsx|.jsx|.native.json|.json|.native.ts|.ts|.native.tsx|.tsx|.native.svg|.svg) * debugger-ui/debuggerWorker.aca173c4/index(.native|.native.js|.js|.native.jsx|.jsx|.native.json|.json|.native.ts|.ts|.native.tsx|.tsx|.native.svg|.svg) at ModuleResolver.resolveDependency (/Users/xxx/Documents/projects/xxx/packages/mobile/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js:114:15) at DependencyGraph.resolveDependency (/Users/xxx/Documents/projects/xxx/packages/mobile/node_modules/metro/src/node-haste/DependencyGraph.js:277:43) at /Users/xxx/Documents/projects/xxx/packages/mobile/node_modules/metro/src/lib/transformHelpers.js:169:21 at Server._resolveRelativePath (/Users/xxx/Documents/projects/xxx/packages/mobile/node_modules/metro/src/Server.js:1045:12) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at <span class="pl-k">async</span> Server._explodedSourceMapForBundleOptions (/Users/xxx/Documents/projects/xxx/packages/mobile/node_modules/metro/src/Server.js:993:35) at <span class="pl-k">async</span> Promise.all (index 1) at <span class="pl-k">async</span> Server._symbolicate (/Users/xxx/Documents/projects/xxx/packages/mobile/node_modules/metro/src/Server.js:945:26) at <span class="pl-k">async</span> Server._processRequest (/Users/xxx/Documents/projects/xxx/packages/mobile/node_modules/metro/src/Server.js:418:7) </pre> </div><p> Anh em có cách nào khác phục không? Mình search google mà không thấy. </p> <p> Phiên bản: </p> <div class="markdown-block position-relative overflow-auto"> <pre> <span class="pl-s">"react-native"</span>: <span class="pl-s">"0.72.4"</span> <span class="pl-s">"@react-native-community/cli-debugger-ui@11.3.6"</span> </pre> </div>

Hi anh,<p> Anh có best practice cho project chỉ có 2 branch là staging với prod ko, vấn đề em gặp phải là: </p> <ul> <li>Khi fix bug hay code 1 feature mới thì mọi người sẽ checkout từ prod và tiến hành dev- Khi xong -> merge vào staging để test -> test oke sau khi được approval thì sẽ merge vào prod</li> <li>Nhiều feature hoặc bug sẽ không được approval liền (kéo dài 2-3 tuần hoặc 1 tháng) và nhiều cái feature sẽ cần lên prod gấp=> branch staging hiện giờ rất nhiều feature hoặc function đang test, đang đợi approval, hoặc bị cancel</li> <li>nhiều feature được approval lên prod thì toàn phải coppy code qua branch khác rồi merge prod (lúc trước em hay làm), bây giờ thì em checkout 1từ prod dev,ví dụ feature/fnc-1, sau khi xong thì em tạo nhánh mới feature/fnc-1-staging từ feature/fnc-1 rồi merge staging, khi được approval rồi thì em merge feature/fnc-1 vào prod</li></ul> <p> Nhưng mà mỗi lần test trên staging lẫn lộn nhiều code nên ko chắc chắn là trên prod ko có bug, Anh có solutions nào cho vấn đề này ko ạ. </p>

A ơi. E có đọc bài của a nói về: "Ngày nay thì microservice, k8s nó là một cái mốt mà 99% anh em theo đuổi, ngay cả anh em FE cũng chạy theo nó, nhưng có những phần việc là của DevOps là một lập trình viên trước hết anh em cần master kỹ thuật lập trình cái đã, đó mới là cái gốc!".<p> Vậy a cho e hỏi làm thế nào để đạt master kỹ thuật lập trình ạ?? </p>

Em đang xây dựng tính năng cho phép người dùng úp ảnh sản phẩm lên, và những ảnh này sẽ được lưu trên Amazon S3. Hiện em đang làm như sau: mỗi lần upload thì generate ra presigned url có thời hạn valid 5 phút, và lưu đường dẫn file url vào trong database. Tuy vậy, các lần sau khi user vào lại trang (ví dụ trang danh sách sản phẩm), thì phía server lại cần chạy for loop để generate lại các presigned url từ file url đã lưu trong db để trả về cho người dùng. Vậy em muốn hỏi việc xử lý như này có tốt không? hay cách thiết kế nào là tốt với việc up ảnh và đọc ảnh từ s3 ạ? ở đây em không muốn set bucket trên S3 là public

Em đang làm web hỗ trợ 2 ngôn ngữ là Anh và Việt. Bên trong web có chức năng cho phép user thay đổi ngôn ngữ. Em thấy băn khoăn giữa 3 cách làm sau ở phía web: <ol start="1"> <li>Tạo các route riêng biệt /en và /vn để hiển thị các ngôn ngữ khác nhau</li> <li>Dùng chung route, nhưng truyền khác param: ví dụ: ?lang=vi</li> <li>Dùng chung route. Biến current language sẽ được lưu ở local storage để lấy ra khi bắt đầu chạy app</li> </ol> <p> Ở phía server, mỗi lần Call api, em định sẽ gửi biến current language lên HTTP header, từ đó server đọc và trả response đúng với ngôn ngữ mà user đang gửi lên. Ví dụ: nếu gửi header lên là en, thì trả về giá trị String hello, còn nếu gửi lên vn, thì trả về giá trị String xin chào. Web chỉ cần hiển thị lên là xong. Cách làm như thế có đúng k, hay phía server nên gửi về một object có đủ multi language( kiểu {en: hello, vi: xin chao} ), từ đó web tự xử lý để hiển thị đúng thông tin vs ngôn ngữ đang chọn </p>

Bên khách hàng em đang có yêu cầu dự án mới có tính năng tạo Avatar generator cho khách. Như kiểu họ gửi ảnh mặt họ lên, chọn thêm 1 hình ảnh hoạt hình, sau đó hệ thống sẽ gen ra một avatar cho user theo phong cách hoạt hình đó. Vậy tính năng này mình sẽ làm như nào anh nhỉ. Em đang hướng tới tìm 1 giải pháp open source hoặc api gì đó.

Em có hệ thống thương mại điện tử có 2 app client: app mobile cho end user, app mobile cho store owner (cả 2 đều login bằng email, password hoặc mạng xã hội, 1 người vừa có thể là store owner vừa có thể là end user). Ở đây em thiết kế 1 microservice là user service để quản lý user. e băn khoăn giữa 2 cách thiết kế: <ul> <li>dùng 1 bảng user duy nhất, trong đó có cột role là dạng list để phân biệt</li> <li>dùng 2 bảng riêng cho end user và store user.</li></ul> <p> 1 cách khác nữa là làm hẳn 2 cái user service riêng, 1 cái cho end user, 1 cái cho store user. Theo anh hướng nào hợp lý ạ? </p>

em đang thiết kế hệ thống microservice với khoảng 10 service. em đang băn khoăn về hướng xử lý các master data trong hệ thống mà sẽ có nhiều service dùng chung: như country, city, district, street, store, ...<p> Liệu em có nên dùng riêng 1 service gọi là master data service chuyên để crud các data này hay không? nếu có thì khi lưu sang các service khác, ví dụ update city vào trong user hoặc city vào trong đơn hàng, mình sẽ chỉ lưu city id, thì khi thay đổi tên city trong master data thì cơ chế update sẽ thế nào </p>

Hiện em đang thiết kế hệ thống cho website công ty theo hướng microservice. trong đó có 1 cái là payment service chuyên xử lý kết nối cổng thanh toán, lưu kết quả transaction ... Em có 2 hướng sau cho việc authentication, a xem nên chọn hướng nào: <ul> <li>dùng jwt token gửi lên ở authorization header. dùng cách này thì web sẽ lưu token ở local storage</li> <li>web sẽ lưu token ở cookie và gửi cookie lên server. server sẽ validate token ở cookie</li></ul> <p> Ngoài ra thì vì payment là 1 hệ thống quan trọng, cần bảo mật cao, nên anh có cách thiết kế gì bổ sung để tăng cường security không, hay chỉ cần validate bằng jwt như trên là đủ? </p>

Thật sự em k bị layoff vì công ty vẫn lạm dụng đc, nhưng nhiều ae dev em thấy bị layoff vì công ty k cần, mà họ có tuổi h 2 tháng r k chỗ nào gọi em k biết làm sao trải qua áp lực kinh khủng khiếp như này ạ. Các a ý toàn 8 9 năm KN, đang nuôi con, trả nợ tiền nhà :((( nếu là em, em k biết làm sao

Em từng hỏi a về 1 câu design pattern. Em cứ suy nghĩ mông lung cuối cùng nó là cách tổ chức cái source code 1 cách Scalable. Scalable ở đây k phải scale về performance mà scalable em muốn nói nó là tổ chức dễ dàng Mở rộng, không phải code lại quá nhiều<p> Ok, lấy ví dụ về DP phổ biến Factory Pattern : </p> <p> Em có 3 loại thẻ : Agribank, Mbbank, VIBbank cùng có chung các thuộc tính : name, status, và method : draw(), transfer(). deposit(), payment() </p> <p> Em có thể tạo 3 class Agri, Mb, VIB ok không sai </p> <p> Nhưng nếu dùng Factory : tạo 1 interface chung cho 3 class Agri, MB, VIB,.. có đủ thuộc tính(em k sure vì chưa thấy ai đặt thuộc tính trong interface) và các abstract method, sau đó viết 3 class Agri, MB, VIB.. </p> <p> Vậy vấn đề xảy ra : khi có 1 class VPbank mới, em chỉ cần tạo thêm class VP implement interface kia phải không ạ thay vì tạo 1 class hoàn toàn mới </p> <p> Cuối cùng : Sự khác biệt Factory và Abstract Factory là gì ạ. 2 pattern này có nhất thiết luôn song hành cùng nhau </p>