Request đi từ Windows live writer preview mode - tìm ra rồi

Vừa ăn Tết xong đã bị khách hàng dzí vì một issue trên plugin viết cho Windows Live Writer. Issue đơn giản như thế này:

Module mình vừa release là một plugin viết cho Windows Live Writer (một công cụ soạn thảo blog của Microsoft có thể tích hợp với nhiều blogging platform). Chức năng chính của module là cho phép tìm kiếm một số thông tin đặc biệt và nhúng nội dung tìm được vào cửa sổ blog editor của Windows Live Writer. Khách hàng mong đợi ở chế độ preview của editor này có thể nhìn thấy nội dung hiển thị như khi xem trên blog thật. Tuy nhiên, vì một số hạn chế kĩ thuật dưới đây nên ở preview mode, html content bị vỡ layout và không show được một số phần content liên quan đến business của khách hàng.
1. Windows Live Writer sử dụng một browser engine khác trong preview mode và chặn một số script đặc biệt
2. Cơ chế render nội dung của browser engine này xử lý không tốt cho CSS 2.0 => vỡ layout.

Chính vì những hạn chế này, product manager của khách hàng yêu cầu: chỉ render ra một nội dung HTML đơn giản (chỉ show image tag) ở chế độ preview mode.

Sau khi suy nghĩ về solution trong vài ngày đầu - mình hoàn toàn bị tắc nghẽn. Vì để làm được điều này ta cần biết được request nào đi từ Windows Live Writer và request nào đi từ browser mà user đang duyệt web bình thường. Biết được điều đó ta có thể chặn và render ra những đoạn javascript để sinh ra HTML đúng như mong đợi.

Dưới đây là những phương pháp tôi đã thử:
1. Phân tích http request header khi đi từ Windows Live Writer và request đi từ các browser khác.
Kết quả: hoàn toàn giống nhau. WLW sử dụng một browser engine build từ một version trước của Internet Explorer.
2. Kiểm tra URL referer ở phía client trên WLW và các browser khác:
Kết quả: đều bằng null. Điều này chứng tỏ: WLW preview page được render trực tiếp mà không đi qua trang trung gian nào

Đã trao đổi với technical team của khách hàng để họ hiểu được issue. Critical bug này được chuyển sang cho một developer của team họ để giải quyết. Kết quả: Họ cũng không có solution sau hơn 3 tuần mò mẫm.
Tuyệt vọng!!!

Ngày đầu năm, bị sếp dzí và cho biết khách hàng đang complain. Sếp yêu cầu viết mail cho Microsoft nhờ support. Lên trao đổi với anh T - production manager để giúp anh hiểu vấn đề về những khó khăn hiện tại.
Bước ra khỏi thang máy với cái đầu hoang mang trăm chuyện. Quyết định: uống một ly cafe cho sáng suốt. Đúng là cafe có tác dụng cho những hoàn cảnh như thế này. Uống xong bỗng lóe lên một hy vọng.
Phát hiện ra là mình chưa kiểm tra URL referer khi WLW request về phía server (lúc trước chỉ kiểm tra toàn http header).
Và dưới đây là kết quả:
Đứng từ WLW ở preview mode khi request về server thì URL Referer luôn bằng null. Thông thường, khi ta include một file javascript vào một trang - nếu chặn ở server ta sẽ thấy URL referer của request đến nó chính là URL của trang đang chứa đoạn script include này. Riêng với WLW, nó lại là NULL. Đây chính là tín hiệu giúp ta phân biệt được đâu là request từ Windows Live Writer và đâu là request đi từ browser bình thường.

Xong!

Tuyển dịch - Core J2EE patterns best practices and design strategies

Core J2EE patterns - best practices and design strategies là một trong những quyển sách hay dành cho lập trình viên - được biên soạn bởi Deepak Alur, John Crupi, Dan Malks. Cho dù bạn có là tín đồ của .NET, PHP, Ruby, ... tôi khuyên bạn vẫn nên đọc qua nó - nếu bạn muốn mình có thể đạt đến một trình độ kĩ thuật cao hơn (ở mức độ thiết kế và xây dựng kiến trúc hệ thống phần mềm).

Tôi sẽ lựa chọn một số chương mà tôi tâm đắc để dịch và giới thiệu đến mọi người.
Tuy nhiên tôi sẽ không dịch sát nghĩa trên nội dung mà sẽ viết lại theo cảm nhận và cách hiểu của mình. Nội dung dịch sẽ bám sát theo tư tưởng: phân tích và giải thích vấn đề không bị phụ thuộc vào ngôn ngữ. Do đó nếu bạn muốn hiểu sâu về chi tiết và cách hiện thực trên J2EE thì nên đọc từ ebook tiếng Anh.

Một quyển sách khác mà tôi cũng khuyên bạn nên đọc là: Enterprise Solution patterns Using Microsoft.NET. Đây là quyển dành cho lập trình viên .NET. Tuy nhiên xét về nội dung thì các pattern này cũng gần như tương tự nhau - chỉ khác nhau về cách hiện thực chi tiết trên mỗi platform.

Mục đích của việc dịch và giới thiệu quyển sách này là muốn chia sẻ với mọi người
Nếu các bạn thấy có những đoạn dịch chưa chuẩn hoặc làm mọi người hiểu sai ý nghĩa xin vui lòng đóng góp và gửi mail cho mình: tran.dang.khoa.khtn@gmail.com

Danh sách những chương sách đã dịch sẽ được cập nhật qua bài viết này
(hiện tại chỉ mới dịch xong chương 1)

Chương 1: Giới thiệu

Tết Trâu Vàng

Xuân này tiễn Chuột đón Trâu, xin post một câu đối xuân để tặng mọi người.
Chúc tất cả bạn bè, đồng nghiệp và những người thân của tôi một năm mới an khang thịnh vượng - may mắn và thành đạt.




Riêng tôi lại "già" thêm một tuổi nữa rồi...

Xuân khứ bách hoa lạc
Xuân đáo bách hoa khai
Sự trục nhãn tiền quá
Lão tòng đầu thượng lai
...
(Mãn Giác thiền sư)

Napoleon Hill và Cách nghĩ để thành công

Có nhiều quyển sách để lại ấn tượng trong tôi, nhưng ít có quyển sách nào để lại trong tôi những "ám ảnh" sâu sắc đến thế.

Cách nghĩ để thành công là quyển sách đầu tiên đưa ra triết lý của sự thành đạt - được viết ra từ vô số những câu chuyện có thật của những người vĩ đại như Edison, Henry Ford,... những con người phần lớn đi lên từ 2 bàn tay trắng và đôi khi còn bị xem là thất học. Tuy nhiên họ đã để lại những dấu ấn thành công rực rỡ và những đóng góp vĩ đại cho nhân loại. Tác giả Napoleon Hill đã dành cả cuộc đời mình để phỏng vấn những con người như thế và đã đúc kết những nguyên lý dẫn đến thành công trong một quyển sách - mà theo tôi là kim chỉ nam cho những con người luôn đặt câu hỏi cho mình: tại sao tôi chưa thành công?

Dưới đây là một số trải nghiệm của tôi từ quyển sách này
1. Biết rõ các mục tiêu trong đời đã là đi được một nữa chặng đường đến sự thành công"
2. Hãy biến mục tiêu của bạn thành nỗi ám ảnh và sự khát khao tột bực. Nỗi ám ảnh đó sẽ chi phối đến tư duy, tiềm thức của bạn để chỉ cho bạn con đường đến thành công.
3. Đừng bao giờ từ bỏ mục tiêu, bởi vì: kẻ chiến thắng không bao giờ từ bỏ. Kẻ từ bỏ sẽ không bao giờ chiến thắng
4. Đừng bao giờ lo lắng rằng khó khăn sẽ đến với mình và dù đó có là sự thật hiển nhiên thì cũng không được phép nản lòng.
5. Không người nào đạt đến những thành công vĩ đại mà không chấp nhận hy sinh
6. Để thành công cần phải có sự liên kết với những con người nhiệt huyết, có khả năng và có cùng chí hướng
7. Bạn không nhất thiết phải trở thành người xuất sắc nhất trong mọi lĩnh vực. Sức mạnh trí tuệ mà bạn có chính là kiến thức của những con người mà bạn liên kết được.
8. Kiến thức không phải là những gì bạn nên biết mà là những gì bạn cần áp dụng để đạt được mục tiêu.

Rất khó để diễn đạt những ám ảnh của tôi sau khi đọc xong "Cách nghĩ để thành công". Có thể bạn sẽ có những trải nghiệm khác với những gì tôi đã rút ra. Hãy đọc thử xem!

Không đề

Hôm nay có chút thời gian rảnh rỗi (vì phải install Mac OS và Ubuntu trên máy) nên quan sát một chút không khí làm việc của anh em xung quanh. Thấy một số bạn senior đang ngồi chơi game trong giờ làm việc. Chợt thấy buốn vô cùng. Tôi không trách các bạn, nhưng tôi tự đặt cho mình 3 câu hỏi:
1. Có phải các bạn đang chán công việc hiện tại? Điều gì làm cho các bạn cảm thấy chán? Liệu có ai hiểu được sự chán nản đó và chia sẻ với các bạn không?
2. Có phải các bạn không ý thức được việc mình đang làm ảnh hưởng đến bầu không khí văn hóa của công ty? là những vị trí ở cấp độ senior, nếu không thể kiểm soát được chính mình thì bạn không thể lead được người khác. Tôi mong các bạn không làm thế trong giờ làm việc nữa.
3. Phải chăng có một lỗ hỗng trong cơ chế xét duyệt promotion của công ty? nếu có, nó nằm ở đâu?

Chợt nhớ đến câu thơ của Vũ Đình Liên:
Những người muôn năm cũ.
Hồn ở đâu bây giờ?

... Than ôi, phải chăng những người tâm huyết ngày càng ít đi?

Đọc "Refactoring" của Martin Fowler

Refactoring là một trong những quyển sách đáng đọc cho lập trình viên. Sách được viết và biên soạn bởi những cây đại thụ trong làng kĩ nghệ phần mềm: Martin Fowler, Kent Beck, John Brant, William Opdyke và don Roberts




"Refactoring" không phải là một quyển sách mới. Quyển mà tôi đọc được ấn hành vào năm 2002 (có ghi một dòng: Another stupid release 2002
For all the people which doesn’t have money to buy a good book - dành cho những kẻ ko có tiền mua sách :-). Có lẽ tác giả cũng khá vui tính). Trước đây tôi chỉ đọc lướt qua, chủ yếu là học chiêu. Giống như bọn giang hồ chỉ thích học lóm chiêu pháp của người khác mà không luyện qua những chiêu thức căn bản. Đến sau này có thời gian đọc lại, tôi mới thấu hiểu những tinh hoa nằm sau nội dung sách.

Một chương trình, xét cho cùng cũng chỉ là một tập những dòng mã. Do đó giá trị của một chương trình ngoài những giá trị về chức năng - kinh tế nó cung cấp cho khách hàng, còn một yếu tố quan trọng nữa là: chất lượng mã nguồn. Mã nguồn được đánh giá là tốt khi nó thỏa mãn các yếu tố:
1. Có giá trị cao về mặt kinh tế
2. Độ bao phủ test gần 100%
3. Có tính đơn giản
4. Không trùng lặp
5. Có sức biểu đạt cao.
(Trích từ phát biểu của Robert C.Martin về "thế nào là mã nguồn tốt")

Refactoring - tạm dịch là tinh chỉnh mã nguồn - là hoạt động giúp ta đạt được 3 yếu tố (3) (4) (5). Trong đó yếu tố số 5 được xem là yếu tố then chốt cần đạt được trong refactoring.
Dưới đây tôi giới thiệu tổng quan một số chương sách để giúp bạn có một góc nhìn ban đầu.

Chương 1 của quyển sách đưa ra một ví dụ đầu tiên về refactoring thông qua một đoạn mã nguồn cụ thể và áp dụng refactoring để làm cho mã nguồn trở nên dễ đọc hơn.

Chương 2 nói về những nguyên tắc của refactoring. Đây là chương chưa đựng nhiều giá trị đáng đọc. Nó trả lời giúp tôi những câu hỏi thú vị: tại sao cần refactoring? tôi phải nói với sếp điều gì khi tôi muốn refactor mã nguồn của tôi? Mối quan hệ giữa refactoring và design? Mối quan hệ giữa refactoring và hiệu suất chương trình.

Chương 3: Giúp bạn phát hiện mã xấu. Đây cũng là một chương rất quan trọng vì nó giúp bạn hình thành nên ý niệm giữa cái tốt và xấu trong mã nguồn

Chương 4: Giúp bạn ý thức về việc viết Unit test để đảm bảo mã nguồn của bạn chạy đúng. Các unit test cũng giúp bạn phát hiện sai lầm trong quá trình refactoring.

Từ chương 5 đến chương 13 là những chương dạy cho bạn chiêu pháp để tinh chỉnh mã nguồn.
Chương 14 bàn thêm về những công cụ hỗ trợ refactoring

Tôi đánh giá rất cao 4 chương đầu tiên của quyển sách. Chúng được xem là những chiêu thức căn bản và tạo nên tinh hoa của quyển sách này.

Về các chiêu thức để refactoring (HOW), tôi tạm chia chúng ra làm 4 cấp bậc:

Cấp 1: các chiêu thức sử dụng để refactor những đoạn mã nguồn nhỏ (các quy tắc đặt biến, biểu thức điều kiện, loại bỏ parameter thừa, ...)
Cấp 2: Cấp độ phương thức (method)
Cấp 3: Cấp độ class
Cấp 4: Cấp độ thuật toán và thiết kế hệ thống


Thực chất, không cần phải nhớ hết tất cả những chiêu thức trong sách. Để đọc quyển sách này một cách hiệu quả, tôi làm như sau:
- Ghi nhớ tinh thần và các ý niệm của 4 chương đầu tiên.
- Mở lại những đoạn mã nguồn cũ - tìm ra những đoạn mã xấu.
- Xác định các module cần refactor
- Viết Unit test cho những hàm mà module cung cấp ra ngoài. (vì trước đây tôi ít viết Unit test cho những đoạn mã nguồn cũ)
- Đọc tiếp các chiêu thức còn lại. Sau mỗi chương, tôi thực hành ngay trên những module tôi xác định muốn refactor.
Đó là cách mà tôi đọc và thực hành trên quyển sách này. Còn bạn?

Tổ chức thông tin

Tôi là một người hay quên. Vì vậy tôi cố gắng tổ chức thông tin sao cho thật hiệu quả để tìm kiếm mà không cần phải nhớ quá nhiều. Có một tiêu chí tôi tự đặt ra cho mình: đối với mỗi vấn đề tôi đã từng gặp qua - khi cần thiết chỉ cần bỏ ra tối đa 5 phút để tìm lại.

Tôi chia sẻ với các bạn những công cụ mà tôi đã sử dụng (hy vọng là nó cũng hữu ích đối với các bạn)

1. Tổ chức thư mục hợp lý.

Máy tính là công cụ mà tôi sử dụng thường xuyên. Do đó tôi cố gắng tổ chức cấu trúc thư mục sao cho rõ ràng và dễ nhớ. Một cấu trúc thư mục ví dụ mà tôi đang dùng
+ Ebooks
(Phan loai ebook theo danh muc)
+ Projects
(Moi du an duoc to chuc thanh mot thu muc rieng)
+ R&D
(Nhung task research lien quan)
+ Personal
Notes (Ghi chu ca nhan)
Documents (Nhung tai lieu tu viet)
CV (CV ca nhan)
...

2. Tổ chức email cá nhân

Mỗi ngày tôi nhận được có khi gần 50 emails. Với số lượng email như vậy nếu không tổ chức/phân loại hợp lý tôi sẽ không thể nào quản lý thông tin một cách hiệu quả. Có một số cách tôi khuyên bạn nên dùng:
+ Filter những email ko cần thiết bằng cách tạo filter trên email client (Outlook, ThunderBird, ...)
+ Group email theo nhóm hoặc tổ chức thư mục để lưu trữ email. Mỗi khi đọc xong một email, tôi có thói quen kéo nó vào thư mục thích hợp (chỉ tốn maximum 5 s) nhưng khi cần tìm kiếm bạn có thể tiết kiệm được hàng phút hoặc có khi hàng giờ.

3. Tập thói quen ghi chú những thông tin quan trọng

Đối với những thông tin quan trọng như mật khẩu, tài khoản, thông tin về khách hàng, ... tôi không bao giờ lưu trữ chúng trên email hoặc archived messages. Tôi sử dụng những công cụ online dưới đây:
Google Docs: tạo những document để ghi chú những thông tin quan trọng và bảo mật. Tôi nghĩ rằng khả năng Google Docs bị sập hoặc Google phá sản thấp hơn rất nhiều so với khả năng máy tính tôi đang sử dụng bị crash.
Google Notebook: sử dụng cho các tình huống cần ghi chú nhanh.
Delicious: bookmark những link quan trọng cần nhớ + đánh tag rõ ràng để dễ tìm kiếm.
Mind map: (tôi đang dùng XMind - bạn có thể download từ xmind.net). Đây là công cụ tôi dùng để ghi chú những ý tưởng, những thông tin phức tạp về nội dung.

4. Đừng bao giờ bỏ phí bất kì lần tìm kiếm nào:

Mỗi lần tìm kiếm về một vấn đề là một lần mất thời gian. Tôi ghi nhận lại những thông tin tìm kiếm (những kết quả tốt nhất tìm được) vào một nơi. Trước đây tôi sử dụng chương trình KeyNote (chương trình này cho phép bạn lưu trữ ghi chú theo cấu trúc cây - rất hữu ích). Hiện tại đang chuyển sang dùng Google Notebook.
Mỗi lần search sẽ ghi lại các thông tin:
+ Chủ đề cần tìm kiếm
+ Những kết quả tìm được tốt nhất
+ Các hướng tìm kiếm dừng lại cuối cùng

5. Lập lịch nhắc nhở

Khi có những công việc quan trọng - tôi lập lịch biểu để nhắc nhở. Có thể sử dụng nhiều chương trình: Outlook, RemindTasks,...

Hôm trước có lần hỏi một em gái đồng nghiệp: em gửi lại cho anh danh sách những yêu cầu của Onshore PM cho đợt release này, em suy nghĩ một hồi rồi mở message archived của Yahoo để tìm lại. Buồn quá!
Hy vọng em đọc được bài viết này của anh nhé. Một chút chia sẻ hy vọng sẽ có ích cho những người bạn đồng nghiệp.