Cảm ơn bạn. Mình cũng đã nghe lời khuyên là dùng 3 bảng trong đó có 1 bảng để tạo quan hệ giữa tag và video. Điều này hay ở chỗ dễ lọc dữ liệu, đặc biệt là kiểu như "video có chứa tag A và tag B". Cái này mình thấy phù hợp hợp hơn với các trang chuyên về lọc dữ liệu, hoặc có kèm công cụ search. Hiện tại nếu làm thêm bảng quan hệ giữa tag và video sẽ khó thực hiện vì phải cập nhật bằng tay. Do video thì upload lên Youtube, còn bài viết thì lưu trong database, sẽ khó chế ra công cụ để tự cập nhật cái bảng này, do vậy nó phải cập nhật bằng tay nên sẽ hơi phiền.
Theo mình thấy thi những gì bác trình bày bên trên thường là kiểu sinh viên hoặc lập trình viên non mới đi làm, và nhận dự án để làm thì mới gặp những vấn đề như thế
Có 1 vài điểm mình hoàn toàn đồng ý là việc confirm chức năng với khách hàng, phá giá, và lấy tiền dự án
Nếu được rất mong chờ bài viết về chủ đề nguồn dự án freelancer của bác
Ý tưởng đc nhưng ko thực tế mỗi sản phẩm nào đó có cả chục shop thi nhau bán, có chỗ auth, có chỗ fake...đánh giá chỉ duy nhất 1 sp/ 1 shop, làm ngta lầm tưởng sp này dỏm chứ ko ai nghĩ là ngta chửi do shop giao hàng chậm, bán hàng hết date...
Đánh giá tốt nhất là dựa trên transaction trung thực nhất, đồ dỏm thì chả ai bỏ tiền ra mua nhiều lần.
Bài viết cách đây cũng 3,4 năm rồi nhưng đúng thứ mình tìm, đúng thứ m cần, gãi đúng chỗ ngứa nên phải đăng nhập tạo tk để like cho bạn.Tks b rất nhiều
việc phân biệt object class "home" và object "add" theo như bạn trình bày trong bài này có vẻ sẽ chưa chính xác bởi vì nguyên quán và địa chỉ thường trú đều chung một kiểu dữ liệu, không những thế trên thực tế có rất nhiều trường hợp thông tin một thẻ có nội dung hai trường này hoàn toàn giống nhau. Vậy nên theo mình chỉ có thể tạo 4 class đối với các loại thông tin trên thẻ idcard_cmnd. Và việc phân biệt home và add phải được dựa trên tỉ lệ vị trí.
Về lý thuyết thì là như vậy, do trình biên dịch sẽ truyển đổi toàn bộ mã nguồn sang 1 mã trung gian, và máy tính sẽ tốn ít thơi gian hơn khi xử lý với mã trung gian. Nhưng đấy là nếu bạn có 1 app hoàn chỉnh, còn trong quá trình phát triển thì trình thông dịch sẽ tiết kiệm thời gian hơn, vì mỗi một thay đổi về code, dù thay đổi nhỏ hay lớn thì bạn đều không phải biên dịch lại toàn bộ chương trình. Chưa kể vấn đề khác của trình biên dịch là mã trung gian không phải chạy tương thích trên nhiều hệ điều hành.
@huukimit kinh phết, có giải thưởng cái là bắt đầu thấy có bạn gian lận sửa time bài từ năm ngoái để gắn tag happy new year rồi =))) không biết BTC có biết không
THẢO LUẬN
Cảm ơn chia sẻ của bạn. Bạn có thể nói rõ hơn giúp mình về khối "Route" được không? Nó là gì là, và ví dụ. Cảm ơn bạn
Cảm ơn bạn. Mình cũng đã nghe lời khuyên là dùng 3 bảng trong đó có 1 bảng để tạo quan hệ giữa tag và video. Điều này hay ở chỗ dễ lọc dữ liệu, đặc biệt là kiểu như "video có chứa tag A và tag B". Cái này mình thấy phù hợp hợp hơn với các trang chuyên về lọc dữ liệu, hoặc có kèm công cụ search. Hiện tại nếu làm thêm bảng quan hệ giữa tag và video sẽ khó thực hiện vì phải cập nhật bằng tay. Do video thì upload lên Youtube, còn bài viết thì lưu trong database, sẽ khó chế ra công cụ để tự cập nhật cái bảng này, do vậy nó phải cập nhật bằng tay nên sẽ hơi phiền.
Mình hỏi bổ thêm. Ví dụ sau khi server xác thực xong token là hợp lệ. Thì làm thế nào nó check được token đó là của user id nào bạn nhỉ?
khá chi tiết, thanks!
Ý kiến cá nhân
Thân ái!
Đang dự định chuyển sang làm freelance ...
Ý tưởng đc nhưng ko thực tế mỗi sản phẩm nào đó có cả chục shop thi nhau bán, có chỗ auth, có chỗ fake...đánh giá chỉ duy nhất 1 sp/ 1 shop, làm ngta lầm tưởng sp này dỏm chứ ko ai nghĩ là ngta chửi do shop giao hàng chậm, bán hàng hết date... Đánh giá tốt nhất là dựa trên transaction trung thực nhất, đồ dỏm thì chả ai bỏ tiền ra mua nhiều lần.
kiểu double float thì độ dài được bao nhiêu vậy anh
@hao3004
Ngắn gọn hơn một chút!
@bs90 user bị khiếm thị và camera phải hoạt động liên tục để nhận ra khoảng cách mà mô tả và cảnh báo ấy bạn
Like
Rất hay, giúp mình biết rõ thêm về CSS specificity 👍
Cảm ơn vì kiến thức bạn chia sẻ !
cho mình xin #2 với ạ, mình cảm ơn! Email: vtrinh111@gmail.com
Bài viết cách đây cũng 3,4 năm rồi nhưng đúng thứ mình tìm, đúng thứ m cần, gãi đúng chỗ ngứa nên phải đăng nhập tạo tk để like cho bạn.Tks b rất nhiều
việc phân biệt object class "home" và object "add" theo như bạn trình bày trong bài này có vẻ sẽ chưa chính xác bởi vì nguyên quán và địa chỉ thường trú đều chung một kiểu dữ liệu, không những thế trên thực tế có rất nhiều trường hợp thông tin một thẻ có nội dung hai trường này hoàn toàn giống nhau. Vậy nên theo mình chỉ có thể tạo 4 class đối với các loại thông tin trên thẻ idcard_cmnd. Và việc phân biệt home và add phải được dựa trên tỉ lệ vị trí.
Về lý thuyết thì là như vậy, do trình biên dịch sẽ truyển đổi toàn bộ mã nguồn sang 1 mã trung gian, và máy tính sẽ tốn ít thơi gian hơn khi xử lý với mã trung gian. Nhưng đấy là nếu bạn có 1 app hoàn chỉnh, còn trong quá trình phát triển thì trình thông dịch sẽ tiết kiệm thời gian hơn, vì mỗi một thay đổi về code, dù thay đổi nhỏ hay lớn thì bạn đều không phải biên dịch lại toàn bộ chương trình. Chưa kể vấn đề khác của trình biên dịch là mã trung gian không phải chạy tương thích trên nhiều hệ điều hành.
Khi muốn có thông tin về khoảng cách thì yêu cầu người dùng cầm vật tham chiếu giơ ra trước máy quay
@huukimit kinh phết, có giải thưởng cái là bắt đầu thấy có bạn gian lận sửa time bài từ năm ngoái để gắn tag happy new year rồi =))) không biết BTC có biết không