Tục ngữ vốn chứa đựng ý nghĩa của nó, nhưng ngày càng có nhiều người chỉ diễn giải theo mặt chữ
Nếu mấy kiểu chủ trương như vậy thành trào lưu thì lại chẳng mấy chốc phòng họp bị biến thành một mớ hỗn loạn
Đám nghiện giấy tờ lại hưng phấn quậy phá, rồi cùng một thất bại ấy năm nào cũng lặp lại

Việc này gắn khá nhiều với tiêu chuẩn luật lao động của từng quốc gia.. nhiều công ty ở Mỹ thường chỉ luân phiên nhau, nếu có giai đoạn không thể đảm nhận thì đổi thứ tự cho nhau. Đó là cách làm phổ biến. Vì đây là việc khá vất vả.. cũng có những công ty có đội ngũ chuyên trách on-call.
Ở châu Âu thì gần như sẽ có khoản bồi thường riêng vì tính chất công việc đã thay đổi hoặc vì đó là làm ngoài giờ.
Còn ở Hàn Quốc thì thường làm qua loa do ảnh hưởng của chế độ lương gộp. On-call rõ ràng cũng là làm việc, nhưng lại được tô vẽ như thể khoản phụ cấp cho khoảng thời gian đó là một phúc lợi.

Thực ra dùng hết tất cả các dịch vụ đó cũng đã khó rồi, nên việc có MCP là một lợi thế lớn.
Nếu sau này chỉ cần duy trì API tốt thì có vẻ sẽ khá hữu ích.

Phần cứng của Apple đúng là rất xuất sắc, nhưng phần mềm thì đầy rẫy ý đồ muốn trói buộc người dùng.
Ngay cả khi chỉ muốn chạy một ứng dụng do chính mình tạo và build trên đúng thiết bị của mình, bạn cũng cần một gói đăng ký 100 đô la.

Nếu là lập trình viên dùng các ứng dụng mã nguồn mở quy mô nhỏ đến vừa và tự build để dùng,
thì trên thiết bị Apple, thay vì phải lợi dụng lỗ hổng để jailbreak rồi sideload, cứ dùng Android còn thoải mái hơn.

Bên mình trả cho thời gian trực chờ bằng một nửa lương theo giờ, hỗ trợ chi phí viễn thông, còn thời gian thực sự hỗ trợ thì được tính là làm thêm giờ với hệ số 1,5.

Có vẻ có phe C# đang ẩn mình ở giữa nhỉ

> Nói thẳng ra thì bây giờ phát triển Java cũng đâu nhất thiết phải dùng sản phẩm của JetBrains

Phần này thì... tôi hơi khó mà đồng ý được, huhu...

[đã xóa liên kết] Có vẻ tác giả đã để ảnh chụp màn hình phiên bản Android ở đây. Càng dùng càng thấy đây là một công cụ kỳ lạ theo cách riêng. Cộng đồng cũng rất geek và có nhiều điều đáng ngạc nhiên.

Chỉ cần mỗi Emacs là có thể làm đủ thứ. Gần đây còn cài được trên Android nên thật tuyệt khi có thể tận dụng nguyên các tính năng trên desktop. Tôi đang đào sâu với chủ đề công cụ quản lý tri thức bằng Emacs. Đến khi con tôi hiện đang học mẫu giáo vào tiểu học, có lẽ lúc đó sẽ dùng Emacs để lifelogging nhỉ haha. Vì chỉ cần thành thạo một công cụ thôi, nên về lâu dài đây là cách giúp giảm bớt những băn khoăn.

[đã xóa liên kết]

Nhưng nếu chỉ cần nói rõ nguyên lý làm rối mã cho người dùng, và nhận được sự đồng ý với điều khoản miễn trừ rằng có thể bị một số mô hình cụ thể phá được, thì có lẽ cũng không nhất thiết phải hoàn tiền đâu, bạn thật sự rất chu đáo với người dùng haha

Đây là một bài viết đã mang lại lời giải cho những trăn trở gần đây của tôi. Cảm ơn bạn rất nhiều vì đã chia sẻ một bài viết tuyệt vời như vậy.

Tôi đang tự build trực tiếp LSP để dùng. Đổi sang Go nên cảm nhận rất rõ là tài nguyên tiêu thụ đã giảm đi.

Dạo này cứ có cảm giác là họ cắt giảm nhân sự, việc bảo trì thì ngày càng khó khăn hơn, rồi lại đẩy sang mã nguồn mở để giao phó cho cộng đồng.

Ôi tuyệt quá, cuối cùng cũng ra rồi...!!!

MS thật sự quá đỉnh.

Dạo này cứ chuyển js sang rust / go là thành trào lưu để tăng hiệu năng

Ồ, quá đỉnh

Khi refactor, khá nhiều lần việc phân tích mã ở phía tsserver bị chậm khiến cả editor bị treo cứng, nên mong là nó sẽ sớm ra mắt để được giải thoát khỏi nỗi khổ này.

Tôi có cảm giác mọi người đang ném ra nhận định mà không thực sự nghĩ đến structural typing.
Nếu muốn viết lại bằng ngôn ngữ dùng nominal typing như C# hay Rust thì sẽ phải thay đổi quá nhiều cấu trúc nền tảng của dự án, nên chắc hẳn không dễ.
Trong số các ngôn ngữ áp dụng structural typing, nếu muốn đạt hiệu năng cao hơn nền tảng JS hiện có thì có lẽ chỉ còn C++ hoặc Golang, mà nếu tính cả năng suất phát triển thì gần như không có phương án thay thế.

Có vẻ như các sản phẩm thương mại như Oracle RAC hay DB2 pureScale có khả năng multi-write không nằm trong diện được cân nhắc nhỉ.