Convert VB6.0 sang .NET ... tương lai đen tối

Đây là lần đầu tiên mình thực hiện dự án convert VB6.0 một trong nhưng language mà mình chưa bao giờ thích. Lần đầu viết là khi thực hiện cái môn học CNPM hay QLĐAPM gì đó. Kể từ đó số project dùng VB6.0 chắc ko quá 3 ngón tay.

Vừa thoát nạn đi Nhật thì bị giao cái dự án này với nhân sự chẳng ai biết gì về khái niệm convert. Đau đầu thiệt. Một tương lai không sáng sủa. Nhưng không sao cứ gặm từ từ chắc là được. Mấy bữa này ngồi search và search lên schedule đuối ghê mà lại chết cái là tối mới cảm thấy tỉnh táo. Sáng mai lại có một cái máy chạy bằng cafe. Cố lên.

日本、左様なら。。。

皆さん、

もすぐお正月ですね。
さぁ！田園へ帰ろう。皆さん、一路平安。



楽しいお正月を過ごして下さい。

Cô gái ra đi từ hôm kia .......

Cô gái ra đi từ hôm kia ....... 

Hôm trước mình vô tình tìm thấy lại cuốn "Cô gái đến từ hôm qua". Phải nói là rất lâu rồi mình chẳng hề đọc một cuốn truyện nào. Ít có thời gian để đọc một cuốn truyện ... không nói chính xác là không có suy nghĩ sẽ đọc một cuốn truyện. Vậy đó không hề giống hồi xưa một chút nào. Hồi xưa mình rất hay đọc truyện và tha hồ có thời gian đọc truyện.

Và bây giờ đọc cùng một cuốn truyện như vậy, mình cũng có suy nghĩ khác hồi xưa. Hồi đó mình đọc và chỉ nghĩ rằng sao nó chuối thế, chẳng lẽ 1 chút xíu mà cũng ko đoán ra 2 con bé đó là một. Và mình đã ngồi kéo hết cuốn truyện thật nhanh để biết làm sao có thể quên một người chỉ trong vòng mấy năm...

Và bây cũng thì cũng khác, có thể hình dung làm sao thằng nhỏ đó có thể quên như vậy. Một lần đi tàu mình cũng đã từng không nhận ra mấy đứa bạn học chung lớp 9, dù ngồi rất gần :D. Mà đó là mấy năm trước rồi, chắc giờ còn quên nhiều hơn nữa. Hic đọc lại mới thấy có nhiều cái để nghĩ hơn. Lúc đọc cuốn truyện này lần đầu là thời gian suốt ngày ngồi một mình trong góc quán và chơi PS. Và lúc đó mình cũng không thể nào hiểu viết một bức thư là sao ... ặc ặc.
             
Mình cũng từng quen một người , chẳng biết có tương tự và được gọi là 'Tiểu Ly' không nữa.
Dù sao thì cái tên Tiểu Ly cũng hay, tất nhiên không phải theo cái nghĩa 'tiểu vào cái ly' ...
nếu nghĩ như vậy thì bó hand.

Tiểu Ly trong truyện là một cô bé nhỏ xíu.
Còn 'Tiểu Ly' mà mình quen là một cô bé đã vào ĐH. Trong truyện thằng nhóc thích con bé Tiểu Ly
còn mình thì không dành tình cảm cho 'Tiểu Ly' kiểu như vậy. Vậy có lẽ là không đúng rồi?? Nhưng có một chút cảm giác rất giống theo một cách khác. Mình có cảm giác bình yên, rất gần, cảm giác được đi học và dù gì có người bên cạnh trong 1 đám người xa lạ trên trường.

Rất là con nít nhưng chí ít cũng đã từng có cái gì đó rất đáng để nhớ. Và cũng giống như trong truyện cũng cảm như vừa đánh mất một điều gì đó vô cùng quý giá khi 'Tiểu Ly' ra đi và không bao giờ tìm lại được. Dẫu sao cũng tạm biệt 'Cô gái đã ra đi từ hôm kia ...', tạm biệt 'Tiểu Ly'.

Có lẽ mọi chuyện giống một câu trong bài hát 'Cô gái đến từ hôm qua'. 'Dường như là vẫn thế em không trở lại và mãi là như thế anh không trẻ lại'. Dù bài hát và cuống truyện chẳng có quan hệ gì với nhau nhưng vẫn thấy 1 chút gì liên quan. Lại là một chút thời gian để nhớ về một thời đi học, nhớ về  tình đầu haizzz không nên nhớ nhiều mới phải hic hic ...Và một điều mình nhận ra là khi nghe những bài nhạc mình cảm thấy nó hay hơn, ý nghĩa hơn so với khi nghe cách đây 5 năm trước.

Để một chiều thứ 7 không làm gì, ngồi nhà ngắm trời và nghe nhạc cho thật thỏa thích. Cảm ơn tất cả nhưng gì đã qua....


Cô gái đến từ hôm qua
Sáng tác: Trần Lê Quỳnh


Và rồi ta hứa sẽ quay trở lại,
vào một ngày mai như hai người bạn
Một ngày đã quên tất cả lại nhớ về nhau
cùng năm tháng còn ấu thơ
Và ngày hôm nay anh như đứa trẻ
của ngày hôm qua xa xôi tìm về
Lời thề tựa như ánh lửa sưởi ấm lòng anh
như chính em, cô gái đến từ hôm qua

Tình yêu đầu trôi xa dư âm để lại
và nếu thuộc về nhau em sẽ trở lại
Và anh được thấy hoa rơi như cơn
mưa tươi thắm những con đường
Dường như là vẫn thế em không trở lại
và mãi là như thế anh không trẻ lại
Dòng thời gian trôi như ánh sao băng
trong khoảng khắc qua chúng ta
Nhiều năm xa hạnh phúc anh muốn bên em
Cuộc đời này dù ngắn, nỗi nhớ quá dài
Và cũng đã đủ lớn để mong bé lại
như ngày hôm qua.

Introduction to ACL (authentication, authorization and security)

Giới thiệu ACL (Access Control Lists)

ACL là tính năng quan trọng và hay được thảo luận nhất. Không chỉ bởi đây là tính năng được mong đợi mà còn bởi vì nó là tính năng gây nhiều thắc mắc và khó hiểu nhất (the most confusing).

Như chúng ta được nghe đến trong nhiều tài liệu online, ACL là cách thức để quản lý ứng dụng thuận tiện, khoa học, chi tiết và dễ dàng maintance. ACL quản lý 2 phần của một vấn đề: một bên cần sử dụng và một bên là thứ cần sử dụng. Trong ngôn ngữ của ACL, bên cần sử dụng (thông thường là users) được gọi là Access Request Objects tức đối tượng yêu cầu truy cập viết tắt là AROs. Và những thứ trong hệ thống đang được yêu cầu sử dụng gọi là Access Control Objects đối tượng cần quản lý truy cập viết tắt là ACOs. Các thực thể trên (entities) được gọi là objects bởi đôi khi requesting objects không phải là person- đôi khi chúng ta muốn limit access tới một controllers cụ thể nào đó có nhiệm vụ khởi động logic trong một vài phần khác.

Trong CakePHP thì nó như sau:

The entities are called 'objects' because sometimes the requesting object isn't a person - sometimes you might want to limit the access certain Cake controllers have to initiate logic in other parts of your application.

ACOs có thể là những thứ chúng ta muốn control, từ controller action tới web service ...

Review

ACO - Access Control Object - Something that is wanted

ARO - Access Request Object - Something that wants something

Khi đó ACL sẽ dùng để quyết định ARO nào có thể access ACO nào.

Nên nhớ rằng ACL không giống authenticate. ACL có thể xảy ra sau khi user đã authenticated. Mặc dù ACL thường dùng chung với authentication nhưng quan trọng chúng ta cần phân biệt rõ 2 vấn đề ai (authentication) và người đó được làm cái gì (ACL). Tức là sau khi tiếp cận được (authenticated) thì mới đến bước cấp quyền (authority). Ví dụ được vào nhà nhưng không được làm gì khác với không được phép vào nhà.

Theo truyền thống, hệ thống sẽ quản lý sử dụng một matrix, matrix này bao gồm danh sách các users và permissions liên quan tới các object. Thông tin như vậy chúng ta sẽ thực hiện lưu trữ trong một table (table cũng là một dạng matrix).

Nhìn thoáng qua thì system theo dạng này có vẻ work well: nhìn rất fine-grained (mịn, chi tiết) và dễ đọc.

Chúng ta sẽ đi thẳng vào ví dụ cụ thể như sau: giả sử có một site về game. Chúng ta có các class trong game (dựa theo game Granado Espada đang chơi) như sau: fighter chiến binh, musketeer ngự lâm, scout trinh sát, elementalist phù thủy, wizard pháp sư.

Các vũ khí có được bao gồm sword kiếm, dagger dao găm, pistol súng ngắn, rifle súng trường, staff gậy phép và bracelet vòng tay phép (chỉ trích ra 1 số vũ khí).

Tất nhiên wizard pháp sư sử dụng gậy phép, elementalist phù thủy sử dụng vòng tay phép, scout trinh sát sử dụng dao găm, musketeer ngự lâm dùng súng các loại. Fighter rắc rối nhất có thể dùng kiếm, dao găm, và súng ngắn. Và tất nhiên là tay không tất cả đều sử dụng được.

Theo bảng matrix thông thường chúng ta sẽ hình dung như sau:

	Sword	Dagger	Pistol	Rifle	Staff	Bracelet
Fighter	Allow	Allow	Allow
Musketeer			Allow	Allow
Scout		Allow
Elementalist					Allow
Wizard						Allow

Tuy nhiên mỗi loại vũ khí lại có thể chia thành từng loại nhỏ riêng biệt và có khả năng việc chia nhỏ này sẽ thực hiện trong tương lai. Trong trương lai có thể có cả những trường hợp cá biệt.

Vấn đề đặt ra là với hệ thống nhỏ matrix có thể dễ dàng setup và work nhưng khi hệ thống phát triển, số AROs và ACOs tăng lên thì table phình rất nhanh (theo cấp số nhân với mỗi chiều và còn hơn như vậy nếu cả 2 chiều cùng tăng). Hãy tưởng tượng nếu phải quản lý cả hàng trăm đối tượng theo từng unit. Điều này càng khó khăn khi thực hiện grouping permissions cho một group sections of user.

Giả sử một wizard sử dụng được tất cả các bracelet nhưng nếu chia nhỏ bracelet ra làm fire lửa, wind gió, ice băng, lightning sét thì bẳng matrix này không còn đáp ứng được. Khi đó chúng ta phải chia nhỏ thành 4 loại bracelet giống như đã chia gun thành pistol và rifle.

Nếu tổ chức group và decide permissions cho một group thì việc phải giải quyết individual permissions cho user. Giả sử một fighter đặc biệt vì một lý do nào đó không thể sử dụng pistol chúng ta sẽ đáp ứng bằng cách nào trong khi vẫn đảm bảo không có gì đặc biệt thì fighter vẫn sử dụng được súng.

Tất cả những điều này làm cho việc dùng ACL dạng matrix là không hợp lý vì không thể hiện rõ những lợi điểm của group của cả AROs và ACOs.

Với các tiếp cận ACL chúng ta thấy ACL hầu hết được implemented theo cấu trúc cây. Thông tường sẽ có một cây cho AROs và một cây cho ACOs. Với cấu trúc này có thể quản lý invidual hay group như một node.

Giả sử chúng ta có hệ thống các characters (các character của tui) theo dạng tree như sau:

Tuy nhiên có một điểm đặc biệt fighter Carol không sử dụng được pistol (bé Carol này không thích súng ). Tuy nhiên trường hợp đặc biệt như Nil thì khác, có thêm khả năng đặc biệt là dùng được rifle súng trường chẳng hạn.

Trong khi đó khi tổ chức một site về các weapons bằng một tree of ACOs sẽ như sau:

Áp dụng mô tả trên permissions trên ta có:

Với cách áp dụng này chúng ta có khả năng thay đổi wide-reaching permissions tuy nhiên có thể điều chỉnh một cách rất mịn fine-grained.

Với trường hợp thông thường như April với staff chúng ta có bảng ACL như sau:

ARO node	Permission info	Result
All characters	Deny all	Denying access to staff
Elementalist	Allow staff	Allowing access to staff
April	--	Still allowing staff

Như chúng ta thấy với một trường hợp đặc biệt như Carol dễ dàng nhận ra tất cả mọi fighter đều sử dụng được pistol trừ Carol. Để kiểm tra Carol với pistol ta thực hiện kiểm tra access theo path: All characters -> Fighter -> Carol, theo cách từ trên xuống như vậy thì thông tin permission liên quan tới pistol như sau:

ARO node	Permission info	Result
All characters	Deny all	Denying access to pistol
Fighter	Allow pistol	Allowing access to pistol
Carol	Deny pistol	Denying pistol