giờ mới nhận ra là mình chả hiểu gì về kiểu tham chiếu hết tại trước giờ toàn sài int thôi, thank bài viết nhiều

protected function resolveNumber($number): array { if (! is_numeric($number)) { throw new InvalidArgumentException(sprintf('Number arg (%s) must be numeric!', $number)); }

    //$number += 0; // trick xóa các số 0 lẻ sau cùng của phân số đối với input là chuỗi.
    $number = (string) $number;
    $minus = '-' === $number[0];

    if (false !== strpos($number, '.')) {
        $numbers = explode('.', $number, 2);
    } else {
        $numbers = [$number, 0];
    }

    return array_merge([$minus], array_map('abs', $numbers));
}

Em thử comment và xóa cache nhưng vẫn hok được ạ.

@dao.thai.son như này mỗi lần thêm 1 queue là phải thêm trong file .conf rồi chạy các lệnh reload một lần

@hxtruong6 hi bạn,

1 note trước khi bắt đầu đó là web B hay các web client side rendering nói chung (Vue, React, Angular), khi đã build thì nó sẽ ra file static và nó không thể tự chạy được, mà nó phải được host ở đâu đó, bằng server nào đó (NodeJS, php, python,....) hoặc bằng webserver (nginx, apache....). Khác với SSR (NextJS - web A) hoặc thuần server (như server C)

Trước khi deploy thì bạn cần đặt câu hỏi: bạn có muốn deploy tất cả chúng ở trên 1 domain hay ko? kiểu example.com, example.com/admin, example.com/api. Dựa theo những điều bạn nói thì có vẻ như vậy. Kiểu này sẽ "khó" hơn chút (tí thôi ) (kiểu deploy mỗi cái 1 domain thì sẽ dễ hơn, vì đơn giản là nó tách biệt ko chung chạ ko cần proxy path, location,...)

Cách deploy:

• Build + start web A(nextjs) và server C, cho chúng chạy ở các cổng khác nhau, giả sử 3000, 3001
• Build web B (React JS) được folder static build

Cấu hình Nginx nom sẽ như sau:

server {
  listen 80;
  listen [::]:80;
  server_name example.com;

  # Web B (ReactJS)
  location / {
    root /path_to_build_folder;
    index index.html index.htm index.nginx-debian.html;
    try_files $uri $uri/ /index.html;
  }

  # Web A (NextJS)
  location /admin {
    proxy_pass http://127.0.0.1:3000; # -->> Notice this PORT
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_set_header x-forwarded-for $remote_addr;
    proxy_cache_bypass $http_upgrade;
  }

  # Server C (NodeJS)
  location /api {
    proxy_pass http://127.0.0.1:3001; # -->> Notice this PORT
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_set_header x-forwarded-for $remote_addr;
    proxy_cache_bypass $http_upgrade;
  }
}

Với cách này thì Nginx sẽ serve Web B (ReactJS) như các trang HTML thông thường, nếu client request vào url mà có prefix là /api hoặc /admin thì proxy request vào các backend tương ứng (backend ở đây sẽ là nextjs và nodejs)

P/s: còn 1 vài cách deploy khác, mình ko muốn bạn thấy rối khi giới thiệu nhiều cách, cứ làm dần dần tìm hiểu dần nhé, cách này mình hay dùng và thấy đơn giản nhất

@tvh95 việc lưu dạng display-time không phải là bắt buộc mà là một gợi ý 😄 và tất nhiên sẽ tùy vào trường hợp mới lưu ở dạng display (như thời gian lặp đi lặp lại của 1 ca làm việc, của các ngày lễ hằng năm...)

Chung quy mọi vấn đề liên quan đến ngày giờ đều nằm ở việc, các thành viên trong dự án có nhất quán với quy tắc thiết kế & lưu trữ đã đưa ra ban đầu hay không mà thôi.

đúng rồi bạn

@nambach custom timezone không vấn đề gì bạn ạ. DB sẽ lưu thiết định timezone của người dùng. Ví dụ người dùng đang ở VN nhưng muốn hiển thị thời gian theo giờ Nhật, thì chúng ta lưu trường timezone = 9 vào bảng user config nào đấy. Phía frontend sẽ call api để get ra 2 giá trị: thời gian và timezone của người dùng. Sau đó dùng thư viện moment.js để chuyển đổi. Ví dụ:

const startTime = moment().utc(dateString).tz(timezone);

console.log(startTime.format("DD-MM-YYYY HH:mm"));

Format hiển thị nên để cho frontend làm.

Hơn nữa, nếu lưu dạng display-time, thì sau này người dùng đổi thiết định timezone thì làm sao sửa một loạt các giá trị đã lưu từ trước đây.

Cảm ơn bạn, góp ý chuẩn quá.

Đây là một hướng tiếp cận "an toàn", nghĩa là chúng ta không đụng vào flow của dữ liệu từ back đến front. Tuy nhiên trong trường hợp user có nhu cầu tự custom timezone, thì lưu ở dạng display-time sẽ tiện hơn là timestamp, và nên có 1 số điều chỉnh trong thiết kế UI.

Edited: và trong trường hợp rtime đã mô tả ở trên, với những case lặp lịch mang tính tuần hoàn, mà chúng ta muốn lazy-scheduling, thì mình nghĩ lưu display-time sẽ tiện hơn, miễn là kèm theo thông tin timezone (lưu theo user hoặc global trong hệ thống - tùy cách mình thiết kế) 😁

Không những vậy, việc mapping kiểu dữ liệu ở phía backend - DB cũng có thể gặp rắc rối nếu không xem xét cẩn thận ngay từ đầu. Mình có đề cập những vấn đề này ở bài viết tiếp theo, bạn có thể xem link cuối bài viết này nhe.

Em thì ko code Java, nên chỉ biết note lại sau này đọc. Em xin chia sẻ thêm với các bác kinh nghiệm khi xử lý thời gian có liên quan đến timezone ở phía frontend (bằng Javascript). Chuỗi thời gian bắt buộc phải có yếu tố timezone, tức là có định dạng "2020-10-04T01:55:00Z" (có chữ "Z" ở cuối), hoặc "2020-10-04 01:55:00 GMT+0700". Nếu không, khi khởi tạo đối tượng Date trong Javascript, nó sẽ hiểu đấy là thời gian của local, và nó sẽ tự động ghép múi giờ của local vào. Điều này dẫn đến bao nhiêu lỗi lệch ngày, lệch giờ khi xử lý timezone. Để thống nhất thời gian, cách tốt nhất là backend chỉ nên đọc nguyên vẹn thời gian kiểu timestamp từ DB, lúc lưu cũng phải lưu chuỗi thời gian kiểu timestamp, phía frontend cũng phải đọc nguyên vẹn chuỗi ấy để chuyển đổi hiển thị (không làm gì thì nó vẫn hiển thị đúng thời gian theo múi giờ của local). Nếu có yêu cầu chuyển đổi thời gian hiển thị theo thiết định timezone của người dùng thì cũng dễ dàng và không bị bug. Cả Javascript thuần hay thư viện đều có thể làm được. Nếu không có yếu tố timezone trong chuỗi thời gian thì có dùng thư viện trời bể gì đi chăng nữa cũng convert sai.

Chỗ này bị sai rồi, bạn sửa lại nhé sudo ln -s /etc/nginx/site-available/test-ssl /etc/nginx/site-enabled thành sudo ln -s /etc/nginx/sites-available/test-ssl /etc/nginx/sites-enabled

@hmquan08011996 cảm ơn bạn. do mình mới tiếp xúc tới IT và bắt đầu từ docker container luôn nên không hiểu trước đây người ta deploy như thế nào. giờ mình rõ hơn rồi. cảm ơn bạn nha.

@npham giờ thì mọi người đang chuyển dần dần sang xài container và chuyển server của mình lên AWS

@npham có nha bạn, trong thực tế có rất nhiều nha bạn. Thực tế thì người ta sẽ chạy nhiều webservice trên cùng một máy, ngồi dùng một con nginx để chỉa domain tới đúng webserivce. Đây là cách mà mọi người xài nhiều nhất và nhiều cty đang xài như vậy để tiết tiệm tiền. Đối với nodejs thì những hệ thống cũ hay xài pm2 để chạy nhiều webservice trên cùng một máy. Thí dụ minh họa như sau:

@hmquan08011996 mình thắc mắc là thực tế người ta có chạy cả 2 ứng dụng trên cùng một máy không? bạn giải thích trên bài viết thì mình hiểu được nhưng ví dụ bạn đưa ra mình thắc mắc là có trong thực tế không.

Ví dụ là bạn thuê con VM của Azure, rồi chạy một application sử dụng wordpress (php) cho trang blog, một application sử dụng nodejs cho API, mỗi thằng này sẽ lại dùng 1 cái database mysql. Là bạn sẽ có tổng cộng 4 ứng dụng chạy trên một máy. Đối với 2 thằng database nếu bạn không dùng container thì bạn phải settup nó chạy trên 2 port khác nhau, cài đặt sẽ khó hơn

Cho mình hỏi là với cách deploy truyền thống Chạy thẳng ứng dụng trên server thì mình có thể hiểu là ví dụ mình thuê một con máy ảo trên Azure, mình chỉ chạy duy nhất 1 website trên đó thì các app trên đó có phải dành tài nguyên với nhau không. Như trên bạn nói các app thì bạn có thể nêu ví dụ tên app đó là gì để cho mình hình dung cụ thể hơn được không? Cụ thể là server chạy Windows. Nếu các app ý bạn nói là các ứng dụng web thì mình nghĩ là không ai deploy nhiều app trên cùng một máy. Mong bạn giải đáp thắc mắc giúp mình.

Và làm cách nào để stop supervisor

tuyệt vời a ạ

Anh cho em hỏi với: em làm như hướng dẫn mà chạy lại lỗi này

@huongtran235 Đây bạn nhé: https://www.youtube.com/watch?v=N5zc3zFMPV0 Diễn giả trong hội thảo này cũng chính là anh mentor giúp mình rất nhiều trong việc sửa CV với revise pv thử