Trần Xuân Thắng

Cách 2 sẽ là cách tốt hơn

Nếu bạn mở trực tiếp qua đường dẫn, hay nói cách khác là nháy đúp chuột vào file html để mở, thì bạn có thể sẽ gặp khó khăn nếu file html đó có truy cập các file lân cận (gặp lỗi Not allowed to load local resource: file://...) vì quy định bảo mật của trình duyệt.

Ngoài ra, cách đơn giản để tạo một live server (mà không phụ thuộc vào VSCode) là sử dụng package serve: https://www.npmjs.com/package/serve. Bạn chỉ cần cd vào thư mục có file html tĩnh cần mở và gõ serve . là xong.

Các dạng dịch vụ ổ đĩa cá nhân như OneDrive hay Google Drive thì API khá là cùi và khó thao tác.

Có 2 lựa chọn bạn có thể dùng là:

• Lưu file trực tiếp vào ổ đĩa của server
• Lưu file đến một dịch vụ lưu trữ "thân thiện" với thao tác qua API hơn (AWS S3 hoặc các dịch vụ tương thích với S3)

Đơn giản là vì Safari không hỗ trợ Web Push API:

https://caniuse.com/push-api

Theo mình biết thì Google AMP đã hết trend từ lâu, Google cũng ngừng ưu tiên trang AMP đến thứ hạng tìm kiếm và cũng ngừng hiện huy hiệu tia sét ở trang kết quả tìm kiếm. Nên thực chất bạn không cần quá quan tâm đến AMP trong năm 2022 nữa (hoặc tốt nhất nên bỏ hẳn AMP vì đỡ phải tạo ra 2 phiên bản trang khác nhau để maintain).

C++ hay Java là ngôn ngữ đã lâu đời và gần như đã có chỗ đứng vững vàng cũng như vô số dự án đã được xây dựng từ nó rồi, nên rất ít có khả năng ngôn ngữ này "biến mất" hay ngôn ngữ nào khác thay thế được. Tuy nhiên, theo mình thì Rust sẽ là lựa chọn của rất nhiều dự án mới (thay cho C/C++, Java hay ngôn ngữ nào khác) trong nhiều năm sắp tới, nhất là ở các dự án yêu cầu hiệu năng rất cao, ở mảng lập trình hệ thống hay lập trình nhúng,...

Rust có ưu điểm lớn nhất là có thể viết chương trình với hiệu năng ngang ngửa với C/C++ trong khi vẫn đảm bảo memory safety/thread safety ngay từ lúc biên dịch. Việc Rust không hề có khái niệm NULL mà thay vào đó là Option/Result type cũng là lợi thế lớn (đọc thêm ở The worst mistake of computer science).

Nhược điểm của Rust thì mình có thể điểm qua một vài cái là biên dịch chậm, quy tắc ownership/borrowing trong cú pháp ngôn ngữ khó tiếp cận với người mới, cũng như người lập trình cũng cần viết code dài và nhiều hơn, ví dụ như để xử lý việc unwrap các type Option hay Result.

Tóm lại, nếu bạn đang cân nhắc việc học Rust thì mình sẽ cho rằng Rust hoàn toàn đáng học nhé. Không chỉ là về độ phổ biến hay cơ hội nghề nghiệp, mà Rust cũng là ngôn ngữ rất tốt, tránh được nhiều pitfall của các ngôn ngữ khác, đồng thời qua quá trình học Rust, bạn cũng sẽ học được thêm về cách OS/memory/CPU hoạt động, hay về khoa học máy tính nói chung, từ đó học được cách viết chương trình nhanh và an toàn hơn cả ở các ngôn ngữ khác nữa.

Cái bạn cần là các search engine có khả năng full-text search, và thường có cả xếp rank cho các kết quả tìm kiếm, xử lý trường hợp không dấu & có dấu, từ đồng nghĩa và trái nghĩa,...

Vài ứng cử viên cho bạn bắt đầu tìm hiểu là meilisearch (nhẹ và mới nổi) hoặc elasticsearch (tốt nhất nhưng tốn tài nguyên).

Các cơ sở dữ liệu như mysql hay postgresql cũng có khả năng tìm kiếm full-text search, tuy không mạnh bằng mấy engine search chuyên biệt, nhưng nếu trường hợp bạn cần không nhiều thì có thể dùng luôn nó cho đơn giản.

Unused javascript code là những đoạn code javascript mà có được tải cùng với trang nhưng lại không được thực thi. Nguyên do thì có khá nhiều, nhưng bạn có thể vào bài viết Remove unused JavaScript ở trên web.dev để đọc.

Một nguyên do phổ biến của cái này mà có thể trong trường hợp của bạn mắc phải là do project sử dụng kèm theo thư viện ngoài nhưng lại import full chức năng của nó mà bạn không dùng đến. Ví dụ với package lodash, nếu import tất cả các function của nó mà chỉ dùng duy nhất có một function:

import _ from 'lodash'
...
_.groupBy(...)

Thì bạn sẽ gây ra có code dư thừa không sử dụng trong lúc tải trang. Thay vào đó, bạn chỉ nên import những thứ bạn có sử dụng thôi:

import groupBy from 'lodash/groupBy'
...
groupBy(...)

Ngoài ra, có thể bạn dùng cả những library khá nặng mà không hỗ trợ code splitting, thì bạn nên tìm những thư viện thay thế nhẹ hơn để dùng. Ví dụ, package dayjs có thể thay thế cho moment.

Bạn có thể nhận biết lỗi này trong project khá dễ bằng cách dùng công cụ webpack-bundle-analyzer. Nuxt có hỗ trợ sẵn nó nếu bạn chạy lệnh nuxt build --analyze.

Vấn đề tương đối đơn giản:

• Bạn cần một cách để tự động chạy một script định kỳ vào 0h mỗi ngày. Cách đơn giản nhất là sử dụng cronjob của linux.
• Ở trong script chạy định kỳ đó, bạn cần tìm những row có thời gian tạo (thường được lưu thành một field có tên như created_at) lớn hơn 7 ngày và xóa những row đó (DELETE FROM transaction_history WHERE created_at < adddate(now(),-7))

Dùng javascript disable button, form ... cách này không ổn vì nó chỉ giải quyết phía client sẽ ko triệt để được

Cách này trên thực tế lại khá hiệu quả, và được vài framework như mình biết là Rails (https://guides.rubyonrails.org/working_with_javascript_in_rails.html#automatic-disabling) dùng để ngăn người dùng double click.

Trong trường hợp cần ngăn chặn triệt để hơn ở phía backend, một cách đơn giản là chỉ cần thêm rate-limit để cùng một người dùng không thể submit quá nhiều lần trong khoảng thời gian ngắn. Giống như cách đa số các mã nguồn diễn đàn dùng, mỗi lần người dùng đăng bài/lập thread mà bài đăng gần nhất của họ đăng cách đây không lâu thì trả về thông báo lỗi.

• Bạn kiểm tra xem đã thay biến môi trường đầy đủ chưa? Bắt đầu bằng việc tìm ở file .env chẳng hạn, ở cả 2 dự án react và laravel của bạn.
• Bạn grep thử ở source code của cả 2 project xem có những chỗ nào có nội dung là localhost không?

Mình chưa thử nhưng đang nghĩ đến cách sử dụng watch để reload lại data khi thấy route hiện tại thay đổi thành chính nó. Bạn thử theo hướng này xem.

export default {
  ...
  methods: {
    loadData () {
      // Load data ở trang chủ
    }
  },
  watch: {
    '$route.params.name'(to, from) {
      if (to === from) {
        this.loadData()
      }
    }
}
}

Error: ENOSPC: System limit for number of file watchers reached

Bạn cần tăng số fs.inotify.max_user_watches lên, lý do sơ sơ là server vue cần phải quan sát các file để tự động restart lại server cho bạn khi có sự thay đổi, và số max_user_watchers mặc định của các hệ điều hành thường khá nhỏ (so với số lượng file "khủng long" của một dự án javascript/nodeJS thông thường).

https://github.com/guard/listen/blob/master/README.md#increasing-the-amount-of-inotify-watchers

Cái này gọi sơ sơ là kỹ thuật scrape nội dung của một trang web. Về tổng thể thì bạn cần phải:

• Lấy được nội dung HTML của trang web bạn định scrape dữ liệu. Với PHP thì cái này có thể sử dụng curl hoặc một client hiện đại như GuzzleHttp.
• Sau khi có dữ liệu HTML dạng string thì bạn cần tiếp một thư viện HTML parser dùng để trích xuất dữ liệu từ đoạn HTML đó, ví dụ như package paquettg/php-html-parser.
• Làm theo hướng dẫn của HTML parser mà bạn dùng để duyệt đến đúng element có chứa các kết quả xổ số bạn muốn. Ví dụ như trang xoso.net chứa kết quả trong thẻ table thì bạn có thể tìm ra cái table chứa kết quả bằng cách query $dom->find('table').
• Lấy dữ liệu dưới dạng text và lưu vào database của bạn, hay bất cứ đâu bạn muốn.

Thực ra kỹ thuật này khá đơn giản và phổ biến, nhưng để áp dụng thì hơi cần tỉ mỉ chút. Bạn nên thực hành với những trang có cấu trúc DOM đơn giản hơn trước để làm quen.

Nếu các tác vụ chạy nền không quan trọng, bạn có thể thử throttle nó lại, hay thiết đặt rate limiting cho Sidekiq.

Còn với lượng job lớn và phải xử lý càng nhanh càng tốt thì nên nghĩ đến nâng cấp phần cứng.

Kết quả trên có thể là do markup structured data dạng product của bạn có chứa sai sót. Bạn thử sử dụng công cụ kiểm tra của Google check xem liệu markup có sai ở chỗ nào không.

Cách đúng và an toàn nhất theo mình:

• Chuyển biểu thức kia từ dạng infix hiện tại (rất kém thân thiện với máy tính) thành một dạng khác dễ phân tích đối với máy tính hơn như postfix hay AST. Có thể thực hiện chuyển đổi ngay khi lưu vào database.
• Thực hiện tính toán phép toán ở dạng postfix. Trong quá trình tính toán, thay thế giá trị tương ứng vào các biến a, b, c,... Lúc này việc tính toán khá đơn giản rồi, như với postfix thì có thể dễ dàng dùng stack để tính.

Các thuật toán chuyển từ infix sang postfix hay thực hiện tính giá trị biểu thức ở dạng postfix đều không quá khó và có rất nhiều trên mạng. Và với php mình cũng tin là có nhiều library cung cấp khả năng parse các phép toán đơn giản thế này. Cái bạn cần tránh dùng ở đây là sử dụng eval() của php, nó tiềm ẩn nhiều nguy cơ bảo mật nếu bạn không xác thực đầu vào cẩn thận.

Bạn cần sử dụng công cụ có tên ffmpeg. Câu lệnh đơn giản với ffmpeg để chuyển file từ gif sang mp4 ví dụ như này:

ffmpeg -i in.gif -movflags faststart -pix_fmt yuv420p -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" out.mp4

Để dùng ffmpeg trong các ngôn cứ lập trình thì có 2 cách là chạy các dòng lệnh (tương tự phía trên) như một shell command hoặc sử dụng một thư viện wrapper như fluent-ffmpeg (cho Nodejs) hoặc streamio-ffmpeg (cho Ruby).

Thực tế thì ffmpeg là công cụ cần thời gian dài để làm quen và thành thạo. Bạn có thể bắt đầu qua việc tham khảo một bài blog của Giphy: How to make GIFs with FFMPEG

Rất tiếc là không có cách hợp lý nào để bạn giới hạn hay bảo vệ public API của bạn khỏi bị người khác sử dụng cả. Ở phía trình duyệt thì mặc định đã có CORS, và bạn có thể gửi kèm theo CORS header từ API của bạn để hạn chế trình duyệt chỉ cho API được fetch từ những domain trong whitelist mà bạn mong muốn. Tuy nhiên, đấy chỉ là với trình duyệt, còn bất cứ ai cũng có thể truy cập API từ bất cứ chương trình/script nào khác ở trên máy.

Bạn có thể tự làm vài cách khác để bảo vệ (hay đúng hơn là làm rối) như: thường xuyên thay đổi API, mã hoá json trả về của API và giải mã nó ở phía app SPA của bạn,... nhưng hiệu quả thấp và chỉ làm ứng dụng rắc rối thêm.

Cách tốt nhất là bạn không cần quan tâm đến bảo vệ public API, thay vào đó là luôn cho rằng bất cứ ai cũng dùng được API của bạn và tránh để vào đó thông tin nhạy cảm, và coi app SPA của bạn như bao client khác và thêm những giới hạn cho nó phù hợp (rate limit,...).

Nguyên nhân đơn giản là do mã nguồn của bạn có sinh ra exception mà chưa được xử lý. Cách giải quyết là bạn cần kiểm tra kỹ lại stack trace, xem cái gì đã throw ra lỗi ở phía trên và sửa lại (hoặc catch đầy đủ) exception đó.

Ở phía câu lệnh if (err) throw err phía trên thì thay vì việc throw error ra, bạn có thể chỉ cần ghi log lại lỗi để app vẫn tiếp tục hoạt động như bình thường:

if (err) console.error(err)

Có thể do ngrok ở lần tắt trước đó chưa được gracefully shutdown, bạn thử kill tiến trình đó đi bằng cách gõ lệnh:

sudo pkill ngrok

Bạn cũng có thể theo hướng dẫn này để tìm xem port bạn cần đang bị chiếm bởi tiến trình nào: https://www.cyberciti.biz/faq/unix-linux-check-if-port-is-in-use-command/