Bỏ qua cache khi người dùng truy cập trang web

Bài viết này sẽ không được viết ra nếu không có trò nghịch dại của tôi, đại loại là vậy. Câu chuyện như sau, tôi có để một đoạn mã javascript nhỏ để check tên miền, nếu không đúng tên miền chỉ định thì sẽ chuyển hướng đến trang web cá nhân của mình. Và khi upload lên host cho người sử dụng, tôi quên xóa đoạn mã đó. Rất nhiều người dùng đã truy cập trang web và trình duyệt của họ đã lưu lại bản cache file javascript đó của tôi, dù tôi đã xóa đoạn mã đó đi nhưng vẫn không làm trình duyệt của người dùng ngừng chuyển hướng.


Tất nhiên, trái đất tròn có móng tay nhọn, ta luôn có cách để khắc phục điều này:
1, Xài .htaccess

<IfModule mod_headers.c>
  Header set Cache-Control "no-cache, no-store, must-revalidate"
  Header set Pragma "no-cache"
  Header set Expires 0
</IfModule>
2, Xài PHP HTML
Trong file PHP tôi thêm:

header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
sau đó thêm vào trong thẻ head:
<meta name="pragma" content="no-cache">
3, Thêm truy vấn ngẫu nhiên vào đường dẫn đến file javascript
<script src="myScript.js?random=[random]"></script>
Các cách trên sẽ làm cho trình duyệt người dùng bỏ qua cache đã lưu và load lại nội dung file javascript của tôi. Trong lúc tôi đang bối rối nên xài cả 3 cách luôn cho chắc chắn.Chúc bạn thành công.

MrCyclo

Chỉ cần biết số điện thoại, hacker có thể nghe lén và theo dõi vị trí của bạn


Trong show truyền hình "60 Minutes", một nhóm hacker người Đức đã chứng minh được họ có thể nghe lén và theo dõi vị trí của iPhone của bất kỳ người dân nào. Các hacker sử dụng lỗ hổng SS7 trong mạng di động toàn cầu cho phép họ có thể hack vào bất kỳ chiếc smartphone nào và nghe lén, đánh sập cuộc gọi, đọc trộm tin nhắn và theo dõi vị trí của bạn.



Lỗ hổng ở đây là lỗi bảo mật giao thức SS7 (phát hiện công khai từ 2014) của mạng lưới hơn 800 nhà mạng trên thế giới (Mobifone có dính, Vinaphone/Viettel chưa rõ) đang sử dụng để trao đổi thông tin với nhau.



Lỗ hổng SS7 thực ra là một bí mật mở giữa các cơ quan tình báo trên thế giới. Không có giải pháp toàn cầu nào cho SS7 và lỗi này ảnh hưởng tới mọi điện thoai ở mọi nền tảng.

Theo mình thì các nhà mạng vẫn chưa sẵn sàng động tay động chân gì đâu nên hãy tự trang bị kiến thức bảo mật cho mình, để tự bảo vệ mình và để không làm mồi ngon cho kẻ xấu.


Nếu có việc quan trọng mà cần nhắn tin hay gọi điện thì nên dùng mấy app như Whatsapp, Telegram, Signal hay iMess của iPhone là tốt nhất. Email thì dùng GMail/Google Inbox. Đừng xài sms bình thường, đừng dùng Zalo, đừng xài app của mấy nhà mạng nhà mình, mình éo tin được thằng nào hết.



(Tham khảo: TheHackerNews)

MrCyclo

Hãy biết nói KHÔNG


Mình từng post một comic khá đơn giản về chuyện “Thiết kế của một trang web có thể trở nên banh chành như thế nào“. Đó là một câu chuyện về ảnh hưởng của khách hàng đã làm “banh chành” một sản phẩm của designer. Tuy chỉ là chuyện hài, nhưng nó vốn là một chuyện buồn có thật mà những người trong nghề như chúng ta đều gặp phải. Tuy nhiên, thật ra ai có lỗi trong chuyện này …?
Sự khác biệt giữa “người lao động chân tay” và “chuyên viên” là ở chỗ: người lao động làm theo lệnh của cấp trên, còn chuyên viên thì đưa ra hướng giải quyết cho cấp trên. Người lao động được thuê để làm việc theo chỉ dẫn, còn chuyên viên được trả tiền để đưa ra chỉ dẫn đúng đắn.
*Khi chọn cách dịch này, mình không có ý coi thường hay xem nhẹ việc lao động chân tay nhé, mình chỉ dùng từ như vậy để dễ so sánh 2 đặc thù công việc khác nhau thôi.

Hãy tượng tượng 1 cuộc nói chuyện giữa bệnh nhân và bác sĩ :
Bệnh nhân: Tôi đau tay.
Bác sĩ: Giờ anh muốn tôi làm gì?
Bệnh nhân: Làm tay tôi hết đau
Bác sĩ: Để tôi cắt tay anh là xong nhé? Dễ lắm
Bệnh nhân: Không, tôi chỉ muốn hết đau thôi
Bác sĩ: Cắt hết dây thần kinh nối tới tay anh là xong, hết đau ngay
Bệnh nhân: Còn cách nào nhẹ nhàng hơn ko?
Bác sĩ: Xin lỗi, hết giờ làm rồi
Dĩ nhiên bác sĩ bình thường không hành xử thế này. Dù bệnh nhân là khách hàng, bệnh nhân trông cậy vào bác sĩ đưa ra câu trả lời, phương pháp giải quyết
Một phiên bản khác của cuộc nói chuyện này
Bệnh nhân: Tôi muốn chặt tay.
Bác sĩ: Tay anh bị gì?
Bệnh nhân: Đau vl, mệt lắm rồi, cắt cmn đi
Bác sĩ: Đưa tay tôi xem? Chắc bị bong gân hay trật khớp thôi. Phải chụp X-quang.
Bệnh nhân: Không, cắt cmn đi
Bác sĩ: Xin lỗi anh, tôi không chặt tay lành lặn
Bệnh nhân: Nhưng tôi trả tiền mà. Tôi nói gì ông phải làm chứ?
Bác sĩ: Không. Nếu chặt tay anh, tôi sẽ vi phạm đạo đức của một người hành nghề y.
Bạn muốn làm một bác sĩ thế nào? Quay lại ngành của chúng ta, bạn muốn là một developer như thế nào?
Lập trình viên, cũng là “chuyên viên”. Bạn có nhiều kiến thức về thiết kế, hiện thực phần mềm hơn khách hàng/cấp trên của bạn. Bạn được trả tiền cho chuyện đó. Tất cả quy kết lại một điều. Chuyên viên là người phải dám nói KHÔNG. Khi cấp trên/khách hàng đưa ra 1 định hướng, yêu cầu vô lý, nhiệm vụ của bạn là phải từ chối yêu cầu đó. Có nguy hiểm gì không? Đương nhiên là có. Nhưng, là một chuyện viên, đồng nghĩa với việc bạn phải dám giữ lập trường của mình. Có những chuẩn mực mà người chuyên viên không bao giờ nên vi phạm.
Dĩ nhiên, nói KHÔNG chỉ là một phần. Là một chuyên viên, bạn phải sử dụng kĩ năng của mình, đưa ra những lựa chọn thay thế khả thi, phù hợp. Người chuyên viên phải biết đàm phán với cấp trên, để đưa ra những định hướng, giải pháp thỏa mãn yêu cầu của cả hai bên.

Trong mẩu truyện mình đã đăng, chàng web-designer đã không hành xử như một chuyên viên. Anh làm việc như một “người lao động tay chân”. Đống shit ở cuối truyện là do lỗi của anh. Lẽ ra anh phải biết nói KHÔNG, và đàm phán/giải thích với khách hàng, thay vì làm mọi việc khách hàng yêu cầu. Trong truyện, chàng designer là nạn nhân – giỏi giang nhưng yếu thế, còn khách hàng là một gã ngu đần lại còn lậm quyền. Sự thật thì, anh designer đã tự biến mình thành nạn nhân, chối bỏ trách nhiệm, không chịu nói KHÔNG trước những yêu cầu vô lý của khách hàng.
Là một lập trình viên/chuyên viên, bạn đừng bao giờ để mình trở thành một nạn nhân như vậy nhé.

Bài viết được lược dịch từ trang :https://sites.google.com/site/unclebobconsultingllc/blogs-by-robert-martin/saying-no. Tác giả bài viết là Robert Martin, người viết cuốn sách Clean Code. Ông cũng là một cây đa cây đề trong ngành phần mềm.

[C#] Format Drive - Định dạng ổ đĩa

Trong Dot NET (.NET) không hề cung cấp một hàm hay công cụ nào phục vụ cho việc định dạng ổ đĩa cả, vì vậy trên lý thuyết thì bạn không thể làm điều đó với VC ++, VB, C#. Nhưng không gì là không thể, luôn luôn có cách xử lý.



Bạn cũng có thể áp dụng cách này đối với bất kỳ ngôn ngữ nào 
Câu lệnh DOS mình dùng ở đây là:
FORMAT G: /Y /FS:NTFS /V:My_LABEL /Q

  • G: ổ đĩa mình sẽ format
  • /Y: bỏ qua xác nhận Yes/No (Do you really want to format the drive ? Yes /No)
  • /FS: định dạng file system như NTFS hay FAT21
  • /V: tên ổ đĩa sau khi format
  • /Q: format nhanh hay không (quick format ý)


Rồi, mớ kiến thức bòng bong đã xong, giờ đến phần thực hành 
Đầu tiên mình tạo một file .bat:
StreamWriter w_r;
w_r = File.CreateText(@"Phoenix.bat");
w_r.WriteLine("format /y" + type + "/fs:" + filesystem + " " + name);
w_r.WriteLine(labelofdisk);
w_r.Close();
Sau đó viết đoạn mã thực thi file .bat vừa tạo:
System.Diagnostics.Process Proc1 = new System.Diagnostics.Process();
Proc1.StartInfo.FileName = @"Phoenix.bat";
Proc1.StartInfo.UseShellExecute = false;
Proc1.StartInfo.CreateNoWindow = true;
Proc1.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
Proc1.Start();
Proc1.WaitForExit();

Code hoàn chỉnh 

Cảnh báo: Chạy bằng quyền Administrator (Run as Administrator)
Bài viết được dịch từ http://buffernow.com/format-drive-using-c/ và người viết chưa có điều kiện để làm chuột bạch 

Một số mẹo tăng tốc xử lý khi lập trình PHP

Tối ưu và tăng tốc xử lý khi lập trình PHP không chỉ giúp website chạy ổn định mà còn giúp tiết kiệm tài nguyên xử lý của máy chủ website.





1 - Dùng echo thay thế print

Echo luôn luôn hoạt động nhanh hơn print, vì echo không có return gì cả, trong khi print thì luôn return true hay false (0 | 1).
<?php
print('Hello world!');
echo 'Hello world!';
?>


2 - Nháy đơn luôn nhanh hơn nháy kép

Xét ví dụ sau:
<?php
$str = 'world';
$a = 'Hello ' . $str;
$b = "Hello $str";
?>

Vì nháy kép luôn kiểm tra nội dung bên trong có cái nào là biến hay không. Trong khi nháy đơn thì không kiểm tra, vì nội dung bên trong nháy đơn chắc chắn là chuỗi.


3 - Vòng lặp for trong PHP

Mỗi khi thực hiện vòng lặp for() để duyệt một phần tử mảng. Ta thường sử dụng hàm count để đếm số lượng của các phần tử trong mảng. Điều này sẽ làm cho ứng dụng của chúng ta trở nên chậm chạp. Vì lý do mỗi lần thực hiện việc kiểm tra điều kiện thì ta lại phải gọi lại hàm count để đếm số phần tử trong mảng.
Cụ thể:

<?php
for($i=0; $i<=count($a); $i++) {
    // Hành Động...
}
?>

Khắc phục:
<?php
$b = count($a);
for($i=0; $i<=$b; $i++) {
    // Hành động...
}
?>


4 - Đừng back folder khi gọi lại file

Thói quen back folder của một số lập trình viên cần phải xem xét lại vì khi back folder, hệ thống phải cần thời gian tìm kiếm và định hình đường dẫn. Điều đó sẽ làm cho ứng dụng tốn tài nguyên trong việc thực hiện thao tác này.

Cụ thể:

<?php
require_once '../../path/config.php';
?>

Khắc phục:
<?php
require_once BASE.'/path/config.php';
?>

BASE là một hằng được định nghĩa từ đầu để chỉ ra đường dẫn vật lý tới thư mục của ứng dụng.


5 - Nối chuỗi bằng dấu "," sẽ nhanh hơn dấu "." (chỉ áp dụng với hàm echo)

Thói quen khi lập trình PHP thường là nối chuỗi và biến bằng dấu ".". Nhưng thực tế là khi nối chuỗi bằng dấu "," thì tốc độ xử lý của ứng dụng sẽ được cải tiến và nhanh hơn rất nhiều. Nhắc lại, chỉ áp dụng với hàm echo.
<?php
echo $str1 . $str2;
echo $str1 , $str2; // Nhanh hơn
?>


Trên đây là một số thủ thuật dành cho các bạn học tập và thích tìm hiểu về lập trình PHP.

Chúc các bạn thành công!

Một số chiêu trò đối với Chrome Developer Tools

1. Chuyển code xấu thành code đẹp

Nhiều khi chúng ta viết code ẩu, tất cả để chung một dòng, rất khó đọc. Hoặc ta sử dụng thư viện với code đã minify, rất khó đọc hay debug. Rất đơn giản, chỉ cần nhấp vào icon {} để “tút lại nhan sắc” cho code.

2. Chuyển đổi trạng thái của các element (hover, active)

Khi dùng Developer Tools kiểm tra css của các element, ta phải rê chuột lên element, hoặc click vào element đó, đôi khi khá rắc rối. Tab Element có một khung cho phép chúng ta set trạng thái của các element này luôn.

3. Chỉnh sửa nhanh nội dung các element

Khi muốn chỉnh sửa nội dung (text) của các đoạn văn, các đề mục trong trang web, ta phải bật Developer Tool lên, chọn element cần chỉnh sửa, sau đó sửa HTML. Chỉ cần vào cửa sổ console, đánh dòng lệnh document.body.contentEditable=true, bạn có thể thoải mái sửa text của trang web một cách dễ dàng.

4. Tìm những event được bind vào một element

Khi debug, mình luôn đau đầu vì không biết những hàm nào sẽ được gọi khi click vào một button, hover qua một div. Với Developer Tool, ta có thể gõ hàm getEventListeners(element) vào cửa sổ console, hoặc tìm những event được bind vào element đó trong tab Elements.7

5. In object ra console nhờ log và table

Chắc 90% các bạn web developer đều biết dùng console.log() để in ra một object trong cửa sổ console, giúp việc debug được dễ dàng. Chrome Developer Tool còn có một hàm rất thú vị nhưng ít người biết, đó là hàm console.table(). Hàm này có thể in 1 mảng các object ra dưới dạng 1 bảng, rất trực quan và dễ nhìn.


6. Lưu trữ console log, không mất log khi refresh lại trang

Một khi refresh lại trang web, cửa số Console sẽ bị xóa trắng trơn. Để nội dung cửa sổ Console vẫn giữ nguyên khi refresh lại trang, ta chỉ cần tick vào ô “Preserve Log”.

7. Lấy màu của các element khác trên trang web

Tab Element của Developer Tool có một công cụ để lấy màu vô cùng tiện lợi. Hãy click vào css nào liên quan tới màu sắc (color, background-color), một bảng màu sẽ hiện ra, cùng với một cây bút lấy màu cho phép bạn “chôm” màu từ element khác.

Thiết kế của một trang web trở nên “banh chành” như thế nào

Một button trị giá 300 triệu đô – Cái nhìn khác về UI và chức năng

Đây là một chuyện nho nhỏ, về một button nho nhỏ và một số tiền… không nhỏ chút nào.
Mình đọc được chuyện này được trong cuốn Don’t make me think – một cuốn sách khá hay về UI/UX. Ngày xửa ngày xưa, ở một đất nước nọ, có một trang web bán hàng… Chức năng cơ bản của một trang web bán hàng thì ai cũng biết: hiển thị hàng, cho hàng vào giỏ, và thanh toán.
Câu chuyện của chúng ta bắt đầu ở chức năng “Thanh toán”, khi người dùng đã cho hết hàng vào giỏ, một form nho nhỏ xinh xinh hiện ra, với 2 trường username và password, 2 nút Login và Register, một link Quên mật khẩu. Thế nhưng, chính cái form be bé xinh xinh này đã gây thiệt hại đến 300.000.000$/năm cho trang web bán hàng.

Vấn đề ở chỗ, người dùng phải đăng nhập trước khi muốn thanh toán. Đội lập trình nghĩ rằng “Chỉ cần đăng ký tài khoản, thông tin người dùng có thể được lưu lại, ở những lần sau họ không cần nhập địa chỉ, thông tin thanh toán nữa. Người dùng tiết kiệm được thời gian, web cũng khuyến khích được người dùng quay lại mua hàng, hai bên cùng có lợi còn gì?”.

Lũ lập trình viên luôn nghĩ rằng mình hiểu người dùng

Đội ngũ UI/UX đã làm một cuộc thử nghiệm, đưa tiền cho người dùng để họ thực hiện quá trình mua hàng – thanh toán. Đối với những khách hàng mới của trang web, họ phát hiện ra một điều: người dùng rất ghét việc đăng ký, với suy nghĩ “Mình muốn mua hàng, chứ không phải muốn đăng ký đăng kiếc gì cả”. Chưa kể, người dùng còn sợ bị mất thông tin cá nhân, bị gửi mail spam hộp thư.
Với những người dùng quay lại lần 2,3 – đối tượng mà developer nhắm tới, tình cảnh cũng chẳng khá hơn. Họ không nhớ được username/mật khẩu của mình. Mặc dù chức năng “Quên password” vẫn hoạt động, đến tận 160.000 người dùng chức năng này mỗi ngày, 75% trong số đó không tiếp tục quá trình thanh toán sau khi đã request mật khẩu.
4271907178_5801fa223f
Chiếc form nho nhỏ xinh xinh kia, hóa ra lại là thứ ngăn cản người dùng mua hàng – rất nhiều người dùng. Thế mới biết, developer lúc nào cũng nghĩ mình hiểu được người dùng, nhưng thật ra không phải vậy.
Chiếc button trị giá 300 triệu đô la
Đội ngũ designer đã giải quyết vấn đề này một cách vô cùng đơn giản. Họ bỏ đi nút Register, thay vào đó bằng nút Continue và dòng chữ “Bạn không cần đăng ký, hãy bấm nút Continue để thanh toán. Để thanh toán nhanh hơn ở những lần sau, bạn có thể đăng ký một tài khoản vào lúc thanh toán”.
Kết quả: Lượng thanh toán của khách hàng tăng lên đến 45%. Sau tháng đầu tiên, doanh số tăng 15.000.000$. Sau năm đầu tiên, thu nhập của web tăng đến tận 300 triệu đô la. Tất cả những việc mà họ đã làm là gì? Chỉ là thay một button mà thôi.





Ảnh minh họa
Ảnh minh họa

Một cái nhìn khác về UI/UX và chức năng

Một số bạn còn nhầm lẫn về hai khái niệm này, nên mình xin đưa ra một khái niệm tổng quát:
  • UI (User Interface) – Giao diện người dùng: Đây là những gì người dùng nhìn thấy, tương tác được (Form, button, website).
  • UX (User Experience) – Trải nghiệm người dùng: Đây là những gì người dùng trải nghiệm, bao gồm cảm xúc, suy nghĩ, quá trình. UI chỉ là một phần của UX. VD như khi bạn mua hàng trên tiki. Các trang web thanh toán, web mua hàng chính là UI. Quá trình mua hàng/nhận hàng, sự thoải mái khi thanh toán, sự hỗ trợ của Tiki với khách hàng chính là UX.
Trong câu chuyện trên, bằng cách thay đổi UI (Thay một button), họ đã trực tiếp cải thiện UX (Thay đổi trải nghiệm mua hàng, mua nhanh hơn, không cần đăng ký), từ đó làm tăng doanh số bán hàng.
UserExperience
Hẳn nhiều bạn lập trình viên vẫn còn suy nghĩ: Chức năng mới là quan trọng, còn mấy thứ ruồiiii bu như giao diện thì làm thế nào cũng được (Một phần chắc là do lúc mới học lập trình toàn phải viết chương trình Console, trước đây mình cũng vậy). Đây là một suy nghĩ hoàn toàn sai lầm.
Nếu chỉ viết vài tool đơn giản cho chính mình hoặc bạn bè xài thì đúng là giao diện không quan trọng. Nhưng nếu đã tạo ra sản phẩm, hướng tới người dùng, thì UI/UX là những thứ quan trọng nhất nhì, có khi hơn cả chức năng.
Nếu không tin, bạn hãy thử đọc The Inmates Are Running the Asylum– cuốn “thánh kinh” của dân thiết kế UI/UX, để hiểu rõ hơn về tầm quan trọng của hai thứ này. Hãy nhớ một điều mình muốn nói qua câu chuyện này: Đôi khi chỉ một button nho nhỏ lại có giá trị đến 300 triệu đô đấy.

Nguồn: https://toidicodedao.com/2016/01/07/mot-button-tri-gia-300-trieu-do-cai-nhin-khac-ve-ui-va-chuc-nang/