Code refactoring

Từ 1 comment status của thằng bạn trên facebook, nhớ lại về nguyên lý thứ hai của nhiệt động lực học. À, mà sao lại nguyên lý thứ hai nhỉ, có nguyên lý thứ nhất không nhỉ?

Học từ hồi cấp 3, bắt đầu từ câu chuyện không thể chế tạo động cơ vĩnh cửu loại 2, tức là động cơ dùng 2 nguồn nhiệt để có thể biến nhiệt hoàn toàn thành công. Tuy không vi phạm định luật bảo toàn năng lượng, nhưng vẫn không làm được.

Hiệu suất lý tưởng để chuyển nhiệt biến thành công chỉ đạt được = (T2- T1)/T2; T1,T2 là nhiệt độ nguồn nóng & lạnh tính theo nhiệt giai Kelvin.
Tại sao lại thế? qui luật gì đã chi phối cái đó. Trong quá trình giải quyết cái đó thì ông cụ Rudolf Clausius đã mang đến một khái niệm gọi là Entropy (kí hiệu là S), bản chất là đặc trưng cho tính hỗn loạn của hệ thống. Chốt lại là qui luật trên sẽ tương đương với việc phát biểu: Entropy của hệ cô lập không thể giảm. Tức là tính hỗn loạn của hệ thống cô lập sẽ tăng hoặc ít nhất là giữ nguyên.
Câu chuyện tưởng đến đây là hết, thì hóa ra mới bắt đầu. Trong lý thuyết thông tin, Shannon định nghĩa lượng thông tin của hệ thống thông qua Entropy, xem ở đây. Hệ thống càng hỗn loạn thì càng chứa nhiều thông tin, hệ thống càng trật tự thì lượng thông tin chứa trong đó càng ít, nghe cũng có lý đấy chứ nhỉ!. Vậy là từ cái máy nhiệt lại liên hệ mật thiết với chủ đề nóng, vấn đề thông tin.

Cái nghề làm phần mềm chắc chắn cũng không ngoài cuộc, vì nguyên lý phổ quát mà, bao trùm từ vũ trụ bao la bát ngát ( xem Lược sử thời gian – Stephen Hawking, thì biết) đến trà đá vỉa hè (cục đá đang tan dần trong cốc trà, chính là biểu hiện của việc Entropy đang tăng). Vậy phần mềm có xu hướng càng ngày càng lộn xộn, và thực tế đúng như thế. Lúc bắt đầu dự án, nếu là dự án tử tế thì basic design, detail design chuẩn mực thật. Nhưng theo tháng năm, ta thêm tí mắm, lâu lâu cho chút muối vào, thi thoảng thêm tí tính năng để phần mềm lúc đầu đặc tính giống Chó nhưng lại muốn bắt đc cả Chuột, và dần dần nó trở thành 1 đống lộn xộn. Và đâu đó cũng có Sofware entropy thật.
Nhưng chú ý, điều đó chỉ đúng với hệ cô lập, và để phần mềm không trở nên thành 1 đống hổ lốn theo tháng năm thì phải tìm cánh phá vỡ tính “cô lập” của nó, một trong những cách đó là REFACTORING, quyển sách cần đọc, nó nằm ở đây.  Mặc dù  không khuyến khích, nhưng trước khi mua sách tử tế thì có thể xem tạm ở đây

Tóm lại từ nguyên lý thứ hai của nhiệt động lực học, ta rút ra rằng để software không bị xuống cấp, ta phải học cách refactoring?

Zero start with USB

1. Lược sử USB.
Viết tắt của chữ Universal Serial Bus, cái tên nói lên tất cả. Và không hổ danh với tên gọi, đây là chuẩn kết nổi phổ biến nhất, đã và đang thay thế dần các kết nối ngoại vi khác.
Đồ sộ về cả đặc tả lẫn mã nguồn (ví dụ USB stack trong Linux), nếu không phải thánh thì nên tiếp cận từ từ, tránh “đột-thức” (đột quị vì nhiều kiến thức cần nắm).

Lịch sử tóm gọn, có vẻ khi ứng dụng cách mạng nhất là USB Mass Storage(usb flash, thường gọi tắt là USB) bị lấn lướt bởi việc phát triển mạnh mẽ của điện toán đám mây(cloud) và các dịch vụ trực tuyến, thì USB 3.0 lại vùng lên, tuy chưa rõ có nên cơm cháo gì không.
– Khai sinh 1/1996: USB 1.0, Low Speed 1.5Mbit/s, Full Speed 12Mbit/s
– 04/2000: USB 2.0, High Speed 480Mbit/s
– 11/2008: USB 3.0, SuperSpeed 5Gbit/s
– 07/2013: USB 3.1, SuperSpeed+ 10Gbit/s
– 09/2017: USB 3.2, SuperSpeed+ 20Gbit/s

2. Lướt qua đặc tả USB.
Đầu tiên cần nắm đặc tả, vào [1] để lấy đặc tả. Đặt tả là một ma trận chữ nghĩa và khái niệm, nên đọc [3] để biết tiếp cận đặc tả, nếu lười đọc tiếng Anh thì đọc nội dung ở [4], của 1 blog rất có tâm. Ở đây chỉ giới thiệu các tiếp cập đặc tả phiên bản USB 2.0[2], tuy nhiên các chắc các phiên bản tiếp theo cũng có thể tiếp cận theo cách tương tự.
Đồ sộ quá nên cần nắm vững những câu thần chú cơ bản. Đây là chân lý, không bao giờ được buông. NHƯNG nó chỉ đảm bảo cho các phiên bản trước USB 2.0, về sau có thể có thay đổi, sử dụng cần tỉnh táo.
●USB là chuẩn giao tiếp đơn, chỉ có HOST(chủ) và DEVICE(thiết bị, client-khách) giao tiếp với nhau, không phải là giao thức mạng.
●DEVICE chỉ nghe và trả lời khi có lệnh từ HOST, kể cả trường hợp giao tiếp theo interrupt.

Về mặt đặc tính truyền dữ liệu, thì có 4 loại cơ bản:
– Control Transfers: Sử dụng để truyền command (lệnh) hoặc status (trạng thái), ở quá trình DEVICE bắt đầu kết nối với HOST.
– Bulk Data Transfers: Dùng kết nối truyền lượng dữ liệu lớn, không cho phép mất mát, ex: usb flash.
– Interrupt Data Transfers: Dùng cho kết nối đảm bảo tính phản ứng nhanh, ví dụ chuột, bàn phím…
– Isochronous Data Transfers: Dùng cho các kết nối có tính realtime, tốc độ ổn định, ex: Camera, Audio …

Song song với sự phát triển của các thiết bị nhúng (embedded, lai tạp) thì sinh ra USB OTG (On-The-GO), cho phép nó có thể đóng vai trò HOST hoặc DEVICE. Việc lựa chọn vai trò quyết định trong quá trình đàm phán lúc kết nối.

3.Tài liệu tham khảo.
[1]http://www.usb.org/
[2]http://www.usb.org/developers/docs/usb20_docs/
[3]https://www.beyondlogic.org/usbnutshell/usb3.shtml#USBProtocols
[4]https://lazytrick.wordpress.com/category/usb/

 

Why emacs

1.Programming editor.
Ngoài việc đọc, sửa mã nguồn, programming editor còn cần một số tính năng giúp lập trình viên dễ dàng khi lập trình (code brower), ví dụ: jump to function, auto complete.
Cá nhân bạn đang sử dụng cái nào cho việc công việc lập trình? về cơ bản bất cứ phần mềm nào xử được file text thì đương nhiên đều có thể dùng để viết code, ví dụ notepad chẳng hạn.
Lập trình cho window thì dùng Visual studio kinh điển, cho macOS hay iOS thì Xcode sang chảnh, cho Android thì có Eclipse. Với những trường hợp này thì chỉ editor chưa đủ, mà cần đầy đủ môi trường phát triển (trình biên dịch tích hợp, trình gỡ rối …), nên gần như lập trình viên không có lựa chọn nào khác.

Vậy với lập trình viên nhúng (embedded software) thì sao? Biên dịch mã thường bằng dòng lệnh trên console hoặc các gói phần mềm chuyên dụng đi kèm (thường ko tích hợp đủ tính năng viết/đọc code dễ dàng). Do đó có thể dùng bất cứ editor nào tuỳ thích.

Dĩ nhiên lập trình viên nhúng vẫn có thể dùng Visual studio hay Eclipse …, không vấn đề gì cả, và trên thực tế số đông làm vậy. Nói chung không có cái nào tốt hơn cái nào cả, quan trọng năng suất công việc, bạn đang quen dùng cái nào thì với bạn cái đó tốt nhất.

Mình bắt đầu đi làm năm 2009, công việc về nhúng, mới vào được các ông anh chỉ cho SourceInsight thần thánh, nhỏ gọn, chạy cực nhanh, còn graph hoá quá trình liên kết hàm cực kì lợi hại. Thích nó đến mức không có SourceInsight là không muốn đọc code nữa, rất bị phụ thuộc.

Năm 2013, qua Nhật công tác dài hạn ở công ty khách hàng. Không có SourceInsight vì vấn đề bản quyền, rất đau khổ nhưng cũng tìm phương án thay thế bằng Eclipse, tuy hơi nặng nhưng cũng dùng ổn, đủ các tính năng cần thiết, dùng mãi rồi cũng quen.

Từ 2016 đến nay đổi sang Emacs.

2.Why emacs.
Đã nghe kể kỹ sư ở Nhật Bản toàn dùng Emacs hoặc Vim. Cũng đã đôi lần thử dùng nhưng cũng chỉ sửa vài cái nho nhỏ trên console, chứ không hiểu làm sao dùng đồ cổ này mà đọc được đống code. Sang Nhật làm việc thì đúng thế thật, toàn Emacs rồi thì Vim, Sakura (một loại editor) cũng lắm thằng dùng.
Cậu người Nhật làm cùng, sử dụng Emacs nên thi thoảng mình nửa đùa nửa thật, tao muốn dùng Emasc nhưng mãi không dùng được. Rồi đến một hôm đẹp trời, nó quảng cho các cục Emacs đã có thiết lập một số thứ cơ bản, rồi sang chỉ trỏ cho mình. Nó nhiệt tình quá, nên cũng thử cố xem sao. Lúc đầu chưa quen thì đúng là như đi tù luôn, nhưng thật kì diệu, sau tầm 1-2 tuần gì đó, cho đến giờ là kết luôn con Emacs.

emacs

Hỏi google, ta sẽ có 1001 lý do tại sao nên dùng Emacs, tất nhiên chắc cũng có tầm đó lý do tại sao không cần thiết hoặc không nên dùng chăng. Do đó cãi nhau editor nào ưu việt cho lập trình viên là không cần thiết.
Đối với cá nhân mình, dùng Emacs vì một vài lý do:
– Trông nguy hiểm, màn hình đen sì toàn code là code.
– Kết hợp với Gtag, có thể cung cấp các chức năng như code brower.
– Nhẹ, chạy được trên máy cấu hình không cần cao quá, phù hợp với kỹ sư VN (nghèo).
– Bỏ được con Chuột khi viết/đọc code (mình tuổi Mèo nên không ưa Chuột).
– Chạy trên mọi nền tảng từ Windows, Linux đến macOS.
– Tuỳ biến cao, có thể dùng LISP để tự viết thêm tính năng. (mình chưa làm thử, do chưa biết LISP).
– Không chỉ là editor, mà còn là nhiều thử khác (tự google để biết).

3. Thiết lập cơ bản.
Để đủ dùng Emacs đọc, viết code thì có thể thiết lập đơn giản trên Windows.
– Tải Emacs tại đây
– Tải gtags tại đây về, giải nén và sửa PATH environment để thêm đường dẫn tới thư mục bin của gtag.
– Tự google để biết cách thiết lập với gtags, hoặc lấy cái mình đã thiết lập ở đây , đè lên thư mục .emacs.d ( xem [2] để biết chỗ để thư mục .emacs.d).
– Xem [3] để biết cách sử dụng Emacs với gtags để đọc code.
– Đọc tài liệu chính thống ở đây, hoặc chế độ help, hoặc google khi không rõ keybinding chức năng muốn dùng.
Ác mộng lúc bắt đầu dùng Emacs là 1 đống phím tắt cần nhớ. Tuy nhiên bạn không cần cố nhớ, hãy bắt đầu bằng vài thao tác cơ bản, cái nào không biết hãy google hoặc dùng chế độ help. Dùng vài hôm, tay sẽ nhớ thay cho não.

4. Why not VIM.
Giới lập trình viên vẫn cãi nhau chí choé Emacs & Vim, nên dùng thằng nào. Một kiểu như Windows & Linux, Android & Iphone.
Riêng với mình cũng dự định thử dùng Vim cho nghiêm túc xem sao, nhưng giờ chưa dùng vì chưa có thời gian để thử. Ai đang dùng Vim nhờ chỉ bảo chút 🙂

5.Tham khảo.
[1]http://labang.sourceforge.net/articles/emacs-tutorial-vi.html
[2]https://viblo.asia/p/my-friends-emacs-config-al5XRBlkGqPe
[3]https://astraybi.wordpress.com/2015/08/01/how-to-setup-gnu-global-for-emacs-mac/

 

Ngụy khoa học

Khoảng cuối 2013, thằng ku em, giờ đang phD Vật lý ở Pháp, gọi lên viện Vật lý nghe seminar đủ mọi thứ từ Vật lý đến lịch vực nghệ thuật rồi nghe đâu có lúc ra cả Biển Đông… do thầy của nó, GS. Nguyễn Văn Liễn, tổ chức chủ yếu cho học sinh phổ thông, một việc làm rất đáng quí, không rõ đến giờ còn duy trì nữa không.
Giai đoạn đó công việc đang bận nên mình chỉ ghé qua vài lần, nhớ nhất là chuỗi câu chuyện về Feynman, nhà vật lý đa tài người Mỹ, đạt giải Nobel vật lý 1965, tham gia dự án Manhattan (dự án làm bom nguyên tử của Mỹ), học phá khóa két sắt và giải mã kí tự của người Maya làm thú tiêu khiển. Tiện thể xin giới thiệu phương pháp đơn giản để học nhanh kiến thức mới của Feynman ở đây[2], mời các bạn áp dụng để khám phá chân trời kiến thức bao la bát ngát.
Ấn tượng nhất để lại với mình là tính trung thực của Feynman, thể hiện rõ nhất là quá trình tham gia điều tra và đấu tranh với NASA để có báo cáo trung thực về nguyên nhân của vụ tai nạn tàu Challenger[4,5].
Ở đây trích dẫn 1 phần mà bản thân cũng thường hay mở ra xem lại nhất, nói về việc trung thực trong nghiên cứu khoa học, trong quyển “Feynman chuyện thật như đùa!“, do Nguyễn Văn Liễn và Nguyễn Huy Việt dịch từ “Surely you’re joking, mr.Feynman”. Bạn nào tò mò muốn đọc thêm thì có thể mua sách có hình như dưới.

feynman

… Một ví dụ: Milikan đo điện tích của electron bằng thí nghiệm các giọt dầu rơi và thu được kết quả, mà bây giờ ai cũng biết là không thực sự chính xác. Có một chút sai lệch do ông ấy đã dùng giá trị không chính xác của độ nhớt không khí. Thật thú vị khi nhìn vào lịch sử các phép đo điện tích electron được thực hiện sau Milikan. Nếu biểu thị các kết quả đó theo thời gian, bạn sẽ thấy một kết quả lớn hơn Milikan một chút, rồi một kết quả tiếp lại lớn hơn một chút, và cuối cùng chúng qui về một con số lớn hơn.

Vì sao họ lại không phát hiện ra ngay rằng, con số mới là số lớn hơn? Đây là câu chuyện, mà các nhà khoa học phải cảm thấy xấu hổ, bởi vì rõ ràng người ta đã hành xử như thế này. Khi họ thu được một kết quả quá cao so với kết quả của Milikan, họ nghĩ rằng chắc chắn có sai sót nào đó, họ tìm kiếm và rồi cũng tìm ra một nguyên nhân có thể dẫn đến sai sót. Còn, khi họ nhận được kết quả gần hơn với kết quả của Milikan, thì họ không xem xét cẩn thận. Rồi họ loại bỏ những sai lệch nhiều so với giá trị của Milikan, hay làm những việc tương tự như thế. Ngày nay, chúng ta đã biết những xảo thuật này, nên không còn mắc những bệnh như thế nữa.
Tuy vậy, lịch sử lâu dài của việc học cách không tự lừa phỉnh mình – của việc có được trung thực khoa học tuyệt đối là, tôi xin lỗi phải nói, cái mà chúng ta chưa chú tâm đưa vào bất cứ môn học nào, mà tôi biết. Chúng tôi hi vọng là, bạn sẽ học được bằng cách ngấm dần.
Nguyên tắc đầu tiên là bạn không được tự lừa phỉnh chính mình – bạn chính là người dễ bị lừa nhất. Vì thế bạn phải rất thận trọng với điều đó. Sau khi bạn không còn bị lừa phỉnh nữa, bạn sẽ dễ dàng không lừa phỉnh các nhà khoa học khác. Sau đó, bạn chỉ cần trung thực theo cách thông thường.

Tham khảo
[1]https://vi.wikipedia.org/wiki/Richard_Feynman
[2]http://genk.vn/nha-vat-ly-doat-giai-nobel-chia-se-phuong-phap-hoc-nhanh-moi-thu-tren-doi-chi-voi-3-buoc-20161204110349259.chn
[3]https://vi.wikipedia.org/wiki/Dự_án_Manhattan
[4]http://www.feynman.com/science/the-challenger-disaster/
[5]https://www.youtube.com/watch?v=6Rwcbsn19c0

Versatile Video Coding

1. Tên gọi chuẩn nén video mới.
Cuộc cuộc họp thứ 10 diễn ra ở San Diego – Mẽo, từ 10~20/04/2018 của JVET, nhóm hợp tác để thiết kế chuẩn nén video mới của ISO/IEC và ITU-T, đã đánh dấu mốc quan trọng của dự án, khi toàn bộ các đề xuất công cụ nén bắt đầu được đánh giá, thảo luận để tích hợp vào đặc tả. Thêm vào đó tên của chuẩn video tiếp theo sau HEVC được chính thức đặt là VVC, viết tắt của cụm từ Versatile Video Coding, nghe có vẻ khá uyên bác, và trông nguy hiểm.
Bản thân ISO/IEC và ITU-T sẽ quản lý chuẩn nén bằng tên mã riêng của từng tổ chức nên thường có qui định rõ của mỗi bên, còn cái tên VVC một kiểu tên riêng của dự án, thường đặt do ngẫu hứng nên nó trở nên rất thú vị, mặc dù chỉ mang tính hình thức. Trước đó đã có ý kiến thảo luận muốn chấm dứt kiểu tên gọi xVC bằng một kiểu đặt tên mới, đại loại như đặt theo địa điểm mà đội JVET chưa bao giờ đặt chân tới là Antarctica (châu Nam Cực)… Tuy nhiên với tên gọi VVC thì ISO/IEC và ITU-T vẫn tiếp tục duy trì phong cách như 2 chuẩn video trước đây AVC, HEVC. Xem chừng tiếng anh khá phong phú.
Về quá trình thành lập dự án và cách làm việc có thể xem lại tại đây

2. Kết quả hiện tại và kế hoạch tiếp theo.
Hưởng ứng kêu gọi đề xuất, trong cuộc họp lần thứ 10 này 32 tổ chức (công ty, học viện, trường đại học) khác nhau đã công bố 46 đề xuất. Các công cụ mã hoá được đề xuất gồm có 22 thuật toán nén cho SDR (standard dynamic range) , 12 mục HRD (high dynamic range), và 12 đề xuất cho video 360.
Toàn bộ các đề xuất được thảo luận vào đánh giá, chi tiết có thể tham khảo ở tài liệu[1].

Kết quả hiện tại đã đạt được khả năng nén lên tới 40% so với HEVC. Bản đặc tả chuẩn nén phiên bản tạm đầu tiên đã được thiết lập[2].
Cuộc họp lần này cũng đã quyết định sử dụng test model mới có tên là VTM (Versatile Video Coding Test Model)[3] thay thế cho JEM. Bản chất VTM được tái cấu trúc từ JEM do Fraunhofer HHI[6] thực hiện và đề xuất. So với JEM thì VTM được cải thiện thiết kế phần mềm, hiệu năng, nên dễ dàng tích hợp các thuật toán đề xuất vào hơn, đồng thời cho phép disable/enable các coding tool lúc runtime trong khi đó JEM bắt buộc phải biên dịch lại giúp tăng hiệu suất làm việc.

Như vậy theo như kế hoạch lúc JVET đưa ra lúc kêu gọi các đề xuất[7] thì còn tầm 30 tháng nữa, phiên bản đặc tả chính thức sẽ ra mắt, cùng lúc với Olympic ở Tokyo.

2018/04 Test model selection process begins
2018/10 Test model selection established
2020/10 Final standard completed

Tài liệu tham khảo.
[1]http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=3489
[2]http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=3538
[3]http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=3539
[4]http://blog.chiariglione.org/the-mpeg-machine-is-reasy-to-start-again/
[5]http://www.streamingmedia.com/PressRelease/Versatile-Video-Coding-(VVC)-Project-Starts-Strong-with-the-Joint-Video-Experts-Team_47071.aspx
[6]https://www.hhi.fraunhofer.de/en.html
[7]https://www.itu.int/en/ITU-T/studygroups/2017-2020/16/Documents/video/JVET-H1002-CFP-VCBHEVC-Final-v6.pdf