Có lẽ không hẳn vì thực sự cần Internet, mà đúng hơn là nhân dịp đi tới một vùng hẻo lánh không bắt được tín hiệu di động, tôi rất muốn thử một lần dịch vụ Internet vệ tinh mà cả người dùng phổ thông cũng có thể sử dụng. haha
Việc sách giáo khoa có thể sáo mòn không có nghĩa là có thể xem nhẹ thẩm quyền của chúng, cũng như các lựa chọn thay thế khó có thể thay thế sách giáo khoa; tương tự, những cuốn sách kinh doanh nổi tiếng tự thân chúng tạo thành nền tảng hoặc phần cốt lõi của ngành quản trị kinh doanh và học thuật khởi nghiệp.
Tác phẩm lớn của giáo sư Steve Blank, phương pháp phát triển khách hàng, đã trở thành nền tảng lý thuyết của Lean Startup, và tôi cho rằng các học giả cùng những người tiên phong tham gia vào đó đã tạo ra rồi phổ biến những công cụ hiệu quả như Business Model Canvas và Lean Canvas.
Việc hạ thấp giá trị của chúng, hoặc quên mất mục đích ban đầu mà xem chúng như thuốc chữa bách bệnh, theo tôi là do chưa hiểu đúng mục đích nguyên thủy của chúng.
Tôi hoàn toàn đồng ý với nhận định rằng trong nhóm các cựu binh từng chinh chiến trăm trận, các giám đốc điều hành tập đoàn đa quốc gia, chỉ có Drucker là ngoại lệ. Sách thuộc mảng này thực sự chỉ lãng phí thời gian và giấy mực. Ngược lại, sách về lịch sử, kinh tế và nhân văn học hữu ích hơn nhiều.
Nếu chạy Trivy thì số lỗ hổng mức high hoặc critical ít hơn rất nhiều so với js NPM hay Java Maven nên an toàn hơn, vậy bài viết này muốn dùng Rust để lập luận điều gì?
Có một Slack dành cho các lãnh đạo kỹ thuật do Michael Lopp vận hành. RLS - Rands Leadership Slack
Nếu bạn quan tâm thì hãy thử tham gia. Hiện đây là một Slack khổng lồ với hơn 36.000 thành viên.
Để đăng ký, hãy đọc kỹ nội dung ở liên kết trên và gửi email cho Lopp.
Tên/nghề nghiệp/lý do bạn muốn tham gia/bạn đã biết đến RLS từ đâu/tài khoản LinkedIn hoặc Twitter của bạn
Đây không phải chỉ là vấn đề riêng của Rust.
Đó là ưu điểm chung đồng thời cũng là vấn đề tiềm ẩn của mọi ngôn ngữ có trình quản lý gói hỗ trợ kho lưu trữ gói công khai và phụ thuộc bắc cầu.
Cuối cùng thì vẫn là người mang về dùng phải dùng cho cho đúng thôi…
Dù đã có vụ việc leftpad của Node&npm, nhưng vẫn chẳng có gì thay đổi.
Theo cách hiểu tương tự, ngay cả khi tạo tài liệu để nộp cho khách hàng, nhà đầu tư hoặc cấp trên, có lẽ điều quan trọng là tiếp cận từ góc nhìn tạo ra thứ gì đó có thể bán được. Man page cực kỳ xuất sắc, nhưng nếu lấy định dạng đó làm chuẩn để viết bản thuyết trình gọi vốn thì chắc là toi đời.
Tôi nghĩ ở startup, microservice cũng có nhiều ưu điểm. Trước hết, tôi thật sự khuyến nghị dùng monorepo.
Khi định hướng sản phẩm thay đổi, với microservice thì những phần cần chỉnh sửa rõ ràng hơn và ít hơn so với monolithic. Tôi nghĩ đây là một điểm rất lớn.
Trong thời đại phát triển cùng AI, các đơn vị nhỏ của microservice dễ phát triển thông qua AI hơn. (Không có nghĩa là monolithic thì không làm được)
Tôi thừa nhận gánh nặng của CI/CD, nhưng cũng có những dịch vụ bị thanh lý ngay ở giai đoạn đang định hình hướng đi. Đến giai đoạn cuối cùng khi đã chốt được hướng, triển khai cũng gần như mức copy-paste nên có thể xây dựng trong vòng một tuần.
Có những mã nguồn mở có thế mạnh rất rõ theo từng ngôn ngữ. Ví dụ security và business logic làm bằng Java, còn AI làm bằng Python; trong kiến trúc microservice có thể tận dụng tối đa nhiều mã nguồn mở nhất có thể.
Chúng ta đã thành ra không thể sống nổi dù chỉ một ngày nếu rời khỏi thế giới được tạo nên bởi 1 và 0 sao... Nghe mà chẳng thấy giống chuyện của người khác chút nào...
Tôi đã từng nghe nói về digital detox, nhưng đây là lần đầu tiên nghe đến digital botox luôn đấy hahaha
Tôi vốn tò mò Starlink hoạt động cụ thể theo cách nào, và bài này đã giải đáp được khá nhiều thắc mắc của tôi.
Băng tần bảo vệ vô tuyến được nhắc đến trong bài này là 1400-1427 MHz; ngoài quan trắc đất và đại dương như bài viết đề cập, nó còn bao gồm cả sóng vô tuyến phát ra từ khí hydro trong các thiên hà mà ngành thiên văn vô tuyến quan sát (1420.405 MHz).
Vì vậy, các đợt gây nhiễu điện tử công suất mạnh phát sinh trong xung đột quân sự được cho là khiến thiên văn vô tuyến trở nên rất khó khăn.
Tham khảo thêm, có một trang web sử dụng dữ liệu vệ tinh được nhắc đến trong bài để hiển thị bản đồ nhiễu vô tuyến bắt được trong băng tần này theo từng tháng.
Điều rất đặc biệt khi xem trang này là quần đảo Nhật Bản. Những khu vực khác, trừ nơi có căng thẳng quân sự, chủ yếu chỉ hiện thành các điểm rải rác; riêng quần đảo Nhật Bản thì gần như toàn bộ các đảo đều hiện đỏ rực. Thậm chí dữ liệu cũ nhất mà trang web này hiển thị là tháng 4 năm 2015, và ngay từ đó toàn bộ lãnh thổ Nhật Bản đã phủ đỏ.
Vì vậy tôi đã tìm hiểu vì sao chỉ riêng Nhật Bản lại như vậy, và nguyên nhân được cho là các đầu thu truyền hình vệ tinh số phổ biến tại Nhật.
Nhật Bản đã chấm dứt phát sóng TV analog vào tháng 7 năm 2011, và đến tháng 12 cùng năm đã tăng số kênh phát sóng vệ tinh số BS lên 24 kênh. Tín hiệu phát sóng vệ tinh này dùng tần số cao 12 GHz, nhưng vì xử lý trực tiếp trên thiết bị là khá nặng nên bên trong sẽ chuyển đổi sang IF (tần số trung gian) để xử lý.
Vấn đề là với kênh số 21, tần số chuyển đổi trung gian là 1415-1450 MHz, chồng lấn với băng tần bảo vệ vô tuyến đã nêu ở trên; có vẻ như tiêu chuẩn liên quan của Nhật Bản vào thời điểm đó còn lỏng lẻo hơn hiện nay.
Kết quả là hàng triệu đầu thu và bộ khuếch đại phân phối bị rò rỉ một phần sóng vô tuyến trong băng tần đó đã được lắp đặt trên khắp Nhật Bản, và từ đó gây ra vấn đề. Lượng nhiễu rò rỉ từ từng thiết bị riêng lẻ vẫn nằm trong ngưỡng tiêu chuẩn, nhưng khi hàng triệu thiết bị cùng hoạt động đồng thời thì chính cả băng tần đó bị ảnh hưởng.
Từ sau năm 2018, Bộ Nội vụ và Truyền thông Nhật Bản đã siết chặt tiêu chuẩn sản xuất và lắp đặt đầu thu truyền hình vệ tinh, đồng thời trợ cấp cho việc thay thế các đầu thu cũ, nhưng vấn đề này đến nay vẫn chưa được giải quyết.
OpenSearch xuất hiện vào năm 2021 sau khi Elasticsearch thay đổi giấy phép, với mục tiêu trở thành một giải pháp thay thế tương thích. Dù phần lớn tương thích, đặc biệt là phiên bản 1.x với Elasticsearch 7.10, nhưng nó không phải là một giải pháp thay thế hoàn toàn theo kiểu drop-in. Elasticsearch đã tiếp tục phát triển hơn nữa, sở hữu nhiều tính năng và tối ưu hóa hơn, đặc biệt ở Kibana và các phép tổng hợp. Hiệu năng phụ thuộc vào từng ứng dụng, vì cả hai đều được xây dựng trên Lucene. Một số người dùng thấy OpenSearch chậm hơn và các bản fork của Kibana của nó có lỗi. Mặc dù Elasticsearch đã quay lại mã nguồn mở (AGPLv3) vào tháng 9 năm 2024, một số người vẫn thích OpenSearch vì tính chất thực sự mã nguồn mở và sự hỗ trợ từ AWS. Dù tìm kiếm vector là một điểm khác biệt quan trọng, các triển khai quy mô lớn đòi hỏi phải quản lý RAM cẩn thận. Cuối cùng, lựa chọn phụ thuộc vào nhu cầu cụ thể, vì cả hai đều có điểm mạnh và điểm yếu. Tôi đang làm việc về OpenSearch với Davidayo https://www.davidayo.com công cụ AI mạnh mẽ "AskPromptAI" https://askpromptai.com.
Dù ở phần bình luận cũng đã nhắc thoáng qua, nhưng hệ BEAM/OTP kiểu này quả là khá linh hoạt và tốt. Trường hợp của Gleam thì nhờ kết hợp cú pháp hay của cả Go lẫn Rust với độ ổn định của BEAM nên đã trở thành một ngôn ngữ khá ấn tượng. Tôi bắt đầu muốn thử dùng nó cho các dự án quy mô nhỏ.
Có lẽ không hẳn vì thực sự cần Internet, mà đúng hơn là nhân dịp đi tới một vùng hẻo lánh không bắt được tín hiệu di động, tôi rất muốn thử một lần dịch vụ Internet vệ tinh mà cả người dùng phổ thông cũng có thể sử dụng. haha
Việc sách giáo khoa có thể sáo mòn không có nghĩa là có thể xem nhẹ thẩm quyền của chúng, cũng như các lựa chọn thay thế khó có thể thay thế sách giáo khoa; tương tự, những cuốn sách kinh doanh nổi tiếng tự thân chúng tạo thành nền tảng hoặc phần cốt lõi của ngành quản trị kinh doanh và học thuật khởi nghiệp.
Tác phẩm lớn của giáo sư Steve Blank, phương pháp phát triển khách hàng, đã trở thành nền tảng lý thuyết của Lean Startup, và tôi cho rằng các học giả cùng những người tiên phong tham gia vào đó đã tạo ra rồi phổ biến những công cụ hiệu quả như Business Model Canvas và Lean Canvas.
Việc hạ thấp giá trị của chúng, hoặc quên mất mục đích ban đầu mà xem chúng như thuốc chữa bách bệnh, theo tôi là do chưa hiểu đúng mục đích nguyên thủy của chúng.
Tôi hoàn toàn đồng ý với nhận định rằng trong nhóm các cựu binh từng chinh chiến trăm trận, các giám đốc điều hành tập đoàn đa quốc gia, chỉ có Drucker là ngoại lệ. Sách thuộc mảng này thực sự chỉ lãng phí thời gian và giấy mực. Ngược lại, sách về lịch sử, kinh tế và nhân văn học hữu ích hơn nhiều.
Nếu chạy Trivy thì số lỗ hổng mức high hoặc critical ít hơn rất nhiều so với js NPM hay Java Maven nên an toàn hơn, vậy bài viết này muốn dùng Rust để lập luận điều gì?
Có dịch vụ nào cho phép chỉ cần gửi liên kết trang web rồi nhờ tóm tắt không?
Có một Slack dành cho các lãnh đạo kỹ thuật do Michael Lopp vận hành.
RLS - Rands Leadership Slack
Nếu bạn quan tâm thì hãy thử tham gia. Hiện đây là một Slack khổng lồ với hơn 36.000 thành viên.
Để đăng ký, hãy đọc kỹ nội dung ở liên kết trên và gửi email cho Lopp.
Tên/nghề nghiệp/lý do bạn muốn tham gia/bạn đã biết đến RLS từ đâu/tài khoản LinkedIn hoặc Twitter của bạn
Đây không phải chỉ là vấn đề riêng của Rust.
Đó là ưu điểm chung đồng thời cũng là vấn đề tiềm ẩn của mọi ngôn ngữ có trình quản lý gói hỗ trợ kho lưu trữ gói công khai và phụ thuộc bắc cầu.
Cuối cùng thì vẫn là người mang về dùng phải dùng cho cho đúng thôi…
Dù đã có vụ việc leftpad của Node&npm, nhưng vẫn chẳng có gì thay đổi.
Theo cách hiểu tương tự, ngay cả khi tạo tài liệu để nộp cho khách hàng, nhà đầu tư hoặc cấp trên, có lẽ điều quan trọng là tiếp cận từ góc nhìn tạo ra thứ gì đó có thể bán được. Man page cực kỳ xuất sắc, nhưng nếu lấy định dạng đó làm chuẩn để viết bản thuyết trình gọi vốn thì chắc là toi đời.
Tôi đồng ý rằng trong thời đại phát triển AI, việc triển khai theo các đơn vị nhỏ với trách nhiệm duy nhất là điều thiết yếu.
Tôi nghĩ ở startup, microservice cũng có nhiều ưu điểm. Trước hết, tôi thật sự khuyến nghị dùng monorepo.
Chúng ta đã thành ra không thể sống nổi dù chỉ một ngày nếu rời khỏi thế giới được tạo nên bởi 1 và 0 sao... Nghe mà chẳng thấy giống chuyện của người khác chút nào...
Việc giới hạn phạm vi được gọi là scoping. Khả năng chính là biết scoping tốt để có thể giành chiến thắng.
Tôi đã từng nghe nói về digital detox, nhưng đây là lần đầu tiên nghe đến digital botox luôn đấy hahaha
Tôi vốn tò mò Starlink hoạt động cụ thể theo cách nào, và bài này đã giải đáp được khá nhiều thắc mắc của tôi.
Băng tần bảo vệ vô tuyến được nhắc đến trong bài này là 1400-1427 MHz; ngoài quan trắc đất và đại dương như bài viết đề cập, nó còn bao gồm cả sóng vô tuyến phát ra từ khí hydro trong các thiên hà mà ngành thiên văn vô tuyến quan sát (1420.405 MHz).
Vì vậy, các đợt gây nhiễu điện tử công suất mạnh phát sinh trong xung đột quân sự được cho là khiến thiên văn vô tuyến trở nên rất khó khăn.
Tham khảo thêm, có một trang web sử dụng dữ liệu vệ tinh được nhắc đến trong bài để hiển thị bản đồ nhiễu vô tuyến bắt được trong băng tần này theo từng tháng.
Điều rất đặc biệt khi xem trang này là quần đảo Nhật Bản. Những khu vực khác, trừ nơi có căng thẳng quân sự, chủ yếu chỉ hiện thành các điểm rải rác; riêng quần đảo Nhật Bản thì gần như toàn bộ các đảo đều hiện đỏ rực. Thậm chí dữ liệu cũ nhất mà trang web này hiển thị là tháng 4 năm 2015, và ngay từ đó toàn bộ lãnh thổ Nhật Bản đã phủ đỏ.
Vì vậy tôi đã tìm hiểu vì sao chỉ riêng Nhật Bản lại như vậy, và nguyên nhân được cho là các đầu thu truyền hình vệ tinh số phổ biến tại Nhật.
Nhật Bản đã chấm dứt phát sóng TV analog vào tháng 7 năm 2011, và đến tháng 12 cùng năm đã tăng số kênh phát sóng vệ tinh số BS lên 24 kênh. Tín hiệu phát sóng vệ tinh này dùng tần số cao 12 GHz, nhưng vì xử lý trực tiếp trên thiết bị là khá nặng nên bên trong sẽ chuyển đổi sang IF (tần số trung gian) để xử lý.
Vấn đề là với kênh số 21, tần số chuyển đổi trung gian là 1415-1450 MHz, chồng lấn với băng tần bảo vệ vô tuyến đã nêu ở trên; có vẻ như tiêu chuẩn liên quan của Nhật Bản vào thời điểm đó còn lỏng lẻo hơn hiện nay.
Kết quả là hàng triệu đầu thu và bộ khuếch đại phân phối bị rò rỉ một phần sóng vô tuyến trong băng tần đó đã được lắp đặt trên khắp Nhật Bản, và từ đó gây ra vấn đề. Lượng nhiễu rò rỉ từ từng thiết bị riêng lẻ vẫn nằm trong ngưỡng tiêu chuẩn, nhưng khi hàng triệu thiết bị cùng hoạt động đồng thời thì chính cả băng tần đó bị ảnh hưởng.
Từ sau năm 2018, Bộ Nội vụ và Truyền thông Nhật Bản đã siết chặt tiêu chuẩn sản xuất và lắp đặt đầu thu truyền hình vệ tinh, đồng thời trợ cấp cho việc thay thế các đầu thu cũ, nhưng vấn đề này đến nay vẫn chưa được giải quyết.
Nguồn cho phần liên quan đến Nhật Bản:
Wow... trước giờ chỉ mới nghe nói về Starlink thôi, nhưng đọc trải nghiệm sử dụng thực tế thì thấy thật kỳ diệu. Mình đã đọc rất thích!
OpenSearch xuất hiện vào năm 2021 sau khi Elasticsearch thay đổi giấy phép, với mục tiêu trở thành một giải pháp thay thế tương thích. Dù phần lớn tương thích, đặc biệt là phiên bản 1.x với Elasticsearch 7.10, nhưng nó không phải là một giải pháp thay thế hoàn toàn theo kiểu drop-in. Elasticsearch đã tiếp tục phát triển hơn nữa, sở hữu nhiều tính năng và tối ưu hóa hơn, đặc biệt ở Kibana và các phép tổng hợp. Hiệu năng phụ thuộc vào từng ứng dụng, vì cả hai đều được xây dựng trên Lucene. Một số người dùng thấy OpenSearch chậm hơn và các bản fork của Kibana của nó có lỗi. Mặc dù Elasticsearch đã quay lại mã nguồn mở (AGPLv3) vào tháng 9 năm 2024, một số người vẫn thích OpenSearch vì tính chất thực sự mã nguồn mở và sự hỗ trợ từ AWS. Dù tìm kiếm vector là một điểm khác biệt quan trọng, các triển khai quy mô lớn đòi hỏi phải quản lý RAM cẩn thận. Cuối cùng, lựa chọn phụ thuộc vào nhu cầu cụ thể, vì cả hai đều có điểm mạnh và điểm yếu. Tôi đang làm việc về OpenSearch với Davidayo https://www.davidayo.com công cụ AI mạnh mẽ "AskPromptAI" https://askpromptai.com.
Dù ở phần bình luận cũng đã nhắc thoáng qua, nhưng hệ BEAM/OTP kiểu này quả là khá linh hoạt và tốt. Trường hợp của Gleam thì nhờ kết hợp cú pháp hay của cả Go lẫn Rust với độ ổn định của BEAM nên đã trở thành một ngôn ngữ khá ấn tượng. Tôi bắt đầu muốn thử dùng nó cho các dự án quy mô nhỏ.
WA!(SM)
Nếu chia nhỏ đội ngũ một cách quá mức, thì ngay cả việc tụ họp lại để trao đổi ý kiến cũng trở thành một khối lượng công việc khổng lồ.
Astro: phân phối JavaScript ở mức tối thiểu
Phát hành Astro 3.0