Blog

Imagine Cup 4 năm liền – Câu chuyện về niềm đam mê của tuổi trẻ

Nói kể về hành trình 4 năm liên tiếp thi Imagine Cup hoài mà chưa có dịp. Hôm nay tự nhiên trời nhẹ lên cao bỗng cảm xúc dâng trào và mình bắt đầu kể lại câu chuyện 4 năm vừa rồi của mình khi tham gia Imagine Cup. 1 phần cũng muốn ôn lại những đam mê của 1 thời tuổi trẻ. Thời mà như bị thèm thi. Cứ thấy có cuộc thi nào là nhào vô thi :)))). Thôi bây giờ mình bắt đầu kể đây….

Ngày xửa ngày xưa….

Lần đầu mình tham gia Imagine Cup là vào năm 2013. Lúc đó mình pass được vòng 1 – nộp ý tưởng. Đến vòng 2 là vòng hoàn thiện sản phẩm thì lại bị tạch. Do lần đầu còn ngây ngô nên mình chỉ làm web asp.net web form thông thường chứ ko làm mobile app mà mobile app thì được đánh giá cao hơn. Nên lúc đó mình dừng lại tại đó và phần thưởng là mỗi người trong team đc 1 cái áo thun và giấy chứng nhận đã tham gia cuộc thi.

399821_4044748335861_747017746_nHình team mình mặc áo đc tặng và cầm chứng nhận đứng cùng với thầy hướng dẫn

Cũng từ sau cuộc thi này, mình biết được trang fb fan page Microsoft Tech Students. Mình lượn vòng vòng vô những fb có tương tác trên đó và thấy được có mấy người để Microsoft Student Partner. Thế là mình tò tò lắm lắm… Bắt đầu tìm hiểu Microsoft Student Partner là cái quái gì. Rồi apply vào… thế là nhân duyên đưa mình đến với Microsoft bắt đầu từ đây.

Tiếp sang năm 2014, mình lại tiếp tục tham gia Imagine cup. Lập team cùng với 3 bạn khác (C, DA, T). Năm này mình bắt đầu có kinh nghiệm hơn chút. Thế là mới nộp ý tưởng, team đã bắt tay vào làm windows phone app luôn. Lúc đó vừa mò vừa làm. Nhưng tiếc thay, ở vòng ý tưởng lại tạch mất rồi T_T Do có nhiều lỗ hỏng gây bất hợp lý. Thế là buồn bã ngậm ngùi tiếc nuối….

Thất bại ko có nghĩa là dừng lại ở đó…

Mình lại tiếp tục kiên trì thi Imagine Cup 2015 nữa. Năm này thì có hẳn 1 sự đầu tư rất lớn. Ý tưởng kết hợp giữa cứng và mềm. Mình chiêu mộ nhân tài từ nhiều mảng. Lập được 1 nhóm với 3 người. 1 người chuyên lo về phần cứng, 1 người chuyên lo về web, 1 người chuyên về windows phone app. Còn mình thì có nhiệm vụ là xoay vòng vòng. Lo hoàn thiện cho proposal. Lên kế hoạch và quản lý tiến độ. Lo về kịch bản quay video, tìm diễn viên, quay và ghép video (Ở đây chú thích 1 chút dành cho ai chưa biết về cuộc thi Imagine Cup. Ở vòng 1, chúng ta sẽ nộp proposal ý tưởng sản phẩm. Vòng 2 sẽ là hoàn thiện app, nộp package app + source code + video demo). Đồng thời mình cũng tham gia vào 3 mảng kia. Nhờ năm này mà mình biết được khái niệm sensor. Biết được lập trình arduino là như thế nào. Rồi nó tương tác với điện thoại, truyền dữ liệu này nọ ra sao. Nói chung năm này mình học được khá nhiều về mặt kỹ thuật. Năm đó Tết mà đi chạy kiếm mua nón kết bảo hiểm rồi mua mấy cái đồ hơi bị con trai như xuống chợ chuyên bán đồ điện tử để mua pin, công tắc…

Tư duy lúc này của mình là thi Imagine cup là phải tập trung vào kỹ thuật là chủ yếu. Thế là cứ lo về mặt công nghệ phải ghê gớm lắm này nọ. Mà ko lo nhiều về mặt business.

Đến hôm thuyết trình ở vòng chung kết (à, sau 1 năm bị loại ngay từ vòng 1, té ngã 1 bước thế là mình đã tiến hẳn lên được 1 bước. Mình đã lọt qua được vòng 2 và tiến đến vòng 3 – chung kết Việt Nam). Sensor mình mua loại dỏm (do ko có nhiều tiền mua sensor xịn), ko ngờ vô đó nó bị nhiễu sóng loạn xạ dẫn đến kết quả bị sai, app báo động loạn xạ. Dẫn đến demo tạch… à, năm đó mình làm 1 cái nón có gắn sensor để báo động vật cản cho người khiếm thị… Vậy là dừng lại ở vòng chung kết Việt Nam mà ko được giải nào. Buồn vời vợi….

11130392_10202690677466863_3095787841946047919_o

Năm 2016 quyết tâm thi thêm lần nữa, năm này cũng là năm cuối cùng của đời sinh viên. Và tư duy của mình cũng đã thay đổi hơn chút. Phải tập trung nhiều hơn về business như thị trường, nhu cầu người dùng… Năm này mình lại đc trải nghiệm thêm khá nhiều trải nghiệm mới mẻ.

Thật ra ban đầu mình ko có dự định thi năm này đâu. Do ko có ý tưởng…. Thế rồi bị mẹ Hương dụ dỗ. 1 đêm nọ rủ mình vô công viên, ngồi ghế đá bên bờ hồ, thì thầm vào tai mình về ý tưởng của mẻ. Xong kết lại đi vòng vòng trong công viên mẻ nói “Đó, ý tưởng của Hương vậy đó… Thảo suy nghĩ đi”. Rồi mình nhớ hình như là cảm xúc của bả lên luôn thế là kéo về nhà trọ mình rồi bàn 1 lèo. Viết tùm lum từa lưa ra giấy. Ngồi làm đến 10h mấy. Nếu mà được đi qua đêm chắc bả cũng ở lại quầng mình tiếp cả đêm ấy nhưng tiếc thay bả phải về nhà nên đành dừng lại.

Đùng 1 cái tự dưng bả ra Hà Nội học. Những ngày tháng deadline nộp ý tưởng cận kề. Lúc đó 2 con cứ nửa này nửa nọ. Hẹn giờ đó online skype để làm xong rồi thất hẹn. Cứ tưởng đâu bỏ thi luôn rồi. Đến trước giờ deadline mình còn trốn đi chơi để né tránh. Ai dè về bị mẻ lôi đầu lên làm. Làm gấp từ 10h đến hơn 11h thì nộp bài.

May thay ý tưởng của tụi mình được vô vòng 2. Thế là mình bắt đầu công cuộc chiêu mộ nhân tài về cho team. Thời đó có khi mình ở Sài Gòn, có khi mình ở Cần Thơ. Mà 3 người chung nhóm cũng ở 3 nơi khác. Có lần họp, người ở Hà Nội, người Đồng Nai, người Sài Gòn, người Cần Thơ. Những ngày tháng iu xa bắt đầu… :))))

Tới khi bà Hương về lại Sài Gòn là những ngày cận kề của deadline vòng 2. Do mỗi người ở mỗi nơi nên team toàn làm việc online. Chả hiệu quả miếng nào…. Thế là ngày nọ kéo lại nhà bả làm hackathon cả ngày. Nhưng mà làm được có 1 ngày chứ mấy. Rồi vì ko sắp xếp đc thời gian nên team lại làm việc online tiếp. Khoảng thời gian này ngoài làm sản phẩm tụi mình còn đi lấy khảo sát người dùng để đem vào proposal cho thuyết phục BGK. Rồi sau khi làm sản phẩm xong tụi mình lại có màn đi quay video demo app. Lần này nhờ có sự hợp tác của bà Hương mà video phong phú về kịch bản hẳn.

Hậu trường quay clip

Không ngờ sự song kiếm hợp bích của Hương + Thảo = Hương Thảo (Rosemary – tên team) lại may mắn dữ dội…. Tụi mình được vô tiếp vòng chung kết Việt Nam.

Đến vòng này thì tự dưng đội hình của team cũng có 1 chút thay đổi người. Nhưng mà nhờ tinh thần vững chắc và sự quản lý chặt chẽ của mình (Cho nổ chút. Hí hí) thì tình hình team vẫn ổn.

Nhờ kỹ năng thuyết trình hấp dẫn kết hợp với đánh sâu và nhiều về business. Trả lời thuyết phục được những câu hỏi của BGK. Thế là tụi mình được ẵm hạng nhất hạng mục Innovation.

12916126_10204485757342738_5719023378008873391_o

12983863_10204485760342813_5397999987754730543_o

Bước tiếp vào vòng chung kết khu vực APAC. Ở vòng này tụi mình thi online. Bằng việc quay video thuyết trình + demo sản phẩm. Đồng thời tụi mình cũng lồng ghép luôn đoạn quay khảo sát nhu cầu người dùng và đoạn feedback của người dùng sau khi dùng sản phẩm để tăng thêm tính thuyết phục. Nhưng tiếc là may mắn của tụi mình chỉ dừng lại tại đây…

Ở năm này, mình học được khi thuyết trình thì:

  1. Kể về 1 câu chuyện đã dẫn mình tới ý tưởng đó.
  2. Đưa ra phân tích về 1 khảo sát nhu cầu người dùng.
  3. Giải pháp: lúc này là mình nêu lên ý tưởng của mình
  4. Demo app
  5. Wrap lại mục đích của app bằng những screenshots
  6. Nói về những công nghệ sử dụng trong app
  7. Chiếu 1 đoạn video về feedback của người dùng khi sử dụng app
  8. Nêu lý do vì sao người ta phải sử dụng app của mình
  9. Nói về business model: ở phần này mình phải nêu ra được đối tượng sử dụng của mình là ai, partner là ai, mình sẽ kiếm tiền bằng cách nào
  10. Tương lai phát triển của app

Nói chung kết lại, mình thấy mỗi cuộc thi mình tham gia qua đều để lại cho mình 1 cái gì đó. Về kiến thức, về kỷ niệm…. có cái gì đó để mà nhắc lại sau này…. Để như bây giờ khi ko có thi cái gì nữa thì cứ nhìn lại rồi nhớ. Trời hồi đó mình thiệt có nhiều passion mà bây giờ thì ko được như vậy nữa… chắc già…. Mà mới bây giờ đã bớt vậy rồi ko biết sau này sẽ có gì để nhắc lại. Chẳng lẽ lại cứ nhắc về những cuộc thi kia hoài sao? Hừmmmm…. Chắc là nên làm gì đó…. Hừmmm…. Thôi mình đi làm cái gì đó đây… 😛

Advertisements
Giới thiệu

Đồng bộ thư viện chung với nhiều dự án con bằng git submodule

Tình cờ mình mới biết được vụ án về git submodule khá là hay ho nên hôm nay mình xin mạn phép chia sẻ với các bạn về vụ án này ^^

Vấn đề


Bài toán đặt ra ở đây là ví dụ như bạn có nhiều module riêng rẽ cho 1 dự án (chẳng hạn như tiếp tục với dự án ví dụ của bài Microservices kỳ trước) nhưng đến thời điểm hiện tại hệ thống đã bắt đầu phình lên, có vẻ phức tạp hơn tí… Giờ thì mình lại cần 1 thứ gì đó mà lại dùng chung cho nhiều nơi được nhưng lại ko muốn code ở nhiều nơi. Chẳng hạn như bây giờ 4 modules, và cả 4 modules đều muốn xài bạn này. Á à…. Vậy phải làm sao đây ta? Copy đống code đó bỏ ra hết cho 4 modules luôn hỉ? Vậy coi bộ thấy giống đi clone code quá…

Ờ thì viết 1 thằng xong rồi mình build thư viện đó ra dll xong rồi add reference cho mấy thằng kia? Ờ, cách này có vẻ được… Nhưng rồi lỡ muốn thêm cái gì hay cập nhật cái gì vô thì phải sửa xong build xong rồi xóa reference rồi add vô lại hở? Ố ồ… có vẻ phiền nhờ?!?!?? Thôi, đọc tiếp đọc tiếp 😛

Giải pháp

git submodule là mô hình cho phép bạn sử dụng một git project khác làm submodule cho project của mình mà ko cần bận tâm về chuyện source code của submodule kia. Đại loại là cái submodule đó cũng như là 1 cái package chung đó. Xong rồi thay vì những thằng khác import/add reference vô thì đằng này mình trỏ tới submodule đó là sẽ có đống code đó đó.

Hí hí… Nghe có vẻ vui vậy? Ủa vậy rồi làm sao?

Thực hiện

Bước 1: Code và đẩy submodule lên

Cứ bình tĩnh, bây giờ mình cứ việc code cái thằng chung chung mà nhiều thằng xài trước đã, đại loại gọi tên nó là Common chẳng hạn… Rồi sau đó cứ đẩy Common lên git như bình thường

Bước 2: Cấu hình liên kết tới thư viện trên git server

Ở bước này chúng ta có 2 cách làm:

  • Cách 1: dùng giao diện trực quan của bên thứ 3 chẳng hạn như Source tree

    Trong Source tree, bạn chọn Repository -> Add Submodule…


    Sau đó, chỉ định đường dẫn git của submodule và thư mục lưu


  • Cách 2: Dùng cú pháp

    git submodule add [URL] [PATH_TO_SUBMODULE]

Thật ra với 2 cách làm này thì git sẽ tạo ra 1 file có đuôi là .gitmodules bên trong chứa các thông tin như:

[submodule "common"]
path = common/
url = git://foo.com/git/common.git

Vậy là xong… Ủa vậy nếu khi mình update submodule, mình push code lên thì những cái module kia có tự động pull code về cho mình ko ha?

À, đối với trường hợp thì git cung cấp cho bạn cơ chế recursive.

  • Nếu add bằng source tree thì bạn chọn Advanced Options, bạn tick vào Recurse submodules là xong
  • Còn với cách dùng cú pháp thì khi đánh cú pháp bạn chỉ việc thêm –recursive vào là được.

Ưu điểm

  • Hạn chế sai sót, thiếu sót mỗi khi cần thêm hay cập nhật gì
  • Có thể chỉnh sửa code trong submodule từ các module con rồi push thẳng lên chứ ko cần phải vào đúng repo của submodule mới sửa được rồi push lên, rồi mấy module kia mới được pull về.
  • Đỡ tốn thời gian xóa rồi import/add reference thư viện lại

Nhược điểm

  • Luôn phải pull submodule sau khi có thay đổi gì đó trên submodule (nhưng nếu setup recursive thì khỏi lo)
  • Chiếm dung lượng ổ cứng do khi pull code về thì trong mỗi module đều phải có thư mục code của thư viện chung đó

Bonus thêm cho mấy bạn làm .NET

Hơi tốn công xíu là sau khi clone code hết về rồi mình phải vào thư mục của module A mình build submodule Common cái, rồi phải vào thư mục của module B build submodule Common thêm cái nữa. Cứ có bao nhiêu module thì phải build bấy nhiêu thằng do file proj của common nó trỏ về thư mục packages nên nếu ko build thì nó ko có được dll để trỏ vào.

Hiện tai module A sẽ có cây thư mục như sau:

Module A
—– Common
—– A.sln

Để tiện cho việc build và quản lý, ở phần thực hiện chúng ta có thể bổ sung thêm bước 3 là liên kết submodule vô solution. Bạn cứ việc mở A.sln lên rồi add existing project… -> trỏ tới project Common. Rồi save lại thì sau này khi mình mở A.sln lên là mình cũng build được sub module Common luôn òi 😀

Chốt

Để các bạn dễ hình dung sau đây mình có 1 minh họa nhỏ cho cây thư mục của cả dự án như sau:
Gateway
----- Common
--------------- pakages (trong này chứa các nuget package + dll)
--------------- common.sln
----- Gateway.sln

Module A
—– Common
————— pakages
————— common.sln
—– A.sln

Module B
—– Common
————— pakages
————— common.sln
—– B.sln

Module C
—– Common
————— pakages
————— common.sln
—– C.sln

Giới thiệu

Microservices – Đế chế chia để trị

Dạo này cái khái niệm “microservices” đang được nhắc đến nhiều trong giới lập trình. Hồi trước mình cũng ko hiểu nó là cái quái gì. Nhưng vô tình mình chui vô được 1 nhóm đang làm dự án theo kiến trúc microservices. Tuy là cũng chưa chắc mình đã biết nhiều và đúng hết, hiểu hết về nó đâu nhưng mình thấy nó hay ho và muốn chia sẻ một chút ngắn gọn lại cho các bạn nên nếu lỡ vô tình có “cao thủ” nào đó vô đọc bài này của mình, thấy chỗ nào sai thì góp ý hoặc bổ sung dùm mình hén 😛

Tại sao lại gọi là “chia để trị”?

Hồi trước mỗi khi xây dựng một ứng dụng, chúng ta sẽ gom tất tần tật mọi thứ vào chung một khối. Nhưng đến khi ứng dụng phình to quá chúng ta lại ko biết nên quản lý nó thế nào. Thế là kiến trúc microservices được ra đời.

Microservices… micro-services… cái tên nghe man mán cũng hiểu được là các dịch vụ siêu nhỏ. Thế là có thể hiểu được là… à, microservices chẳng qua chỉ là việc tách các module thành những services siêu nhỏ. Mỗi service sẽ được host trên một server riêng.

Ủa rồi chia vậy rồi nó có lùm xùm tùm lum quá ko? Tại sao phải như vại?

Ưu điểm

  • Giảm thiểu sự phức tạp của hệ thống.
  • Dễ quản lý, bảo trì, nâng cấp.
  • Vạch định ranh giới rõ ràng.
  • Ko chết trùm: Do các service tách biệt với nhau nên một module bị lỗi thì module khác vẫn hoạt động bình thường.

Nhược điểm

  • Xử lý chậm do chẳng hạn server bên module B có vấn đề thì kéo theo module A phải chờ đợi và phản hồi chậm.
  • Việc tương tác với cơ sở dữ liệu trở nên rắc rối.
  • Việc quản lý và theo dõi hệ thống sẽ phức tạp hơn. Chẳng hạn như mình có 3 modules và cần phải deploy lên 3 môi trường thì suy ra cần phải quản lý đến 9 cái server. Mỗi lần đụng tới việc build thì ôi thôi…. Mà nhờ thế thì chúng ta lại có cơ hội tận dụng công nghệ quản lý vận hành tự động. Và anh bạn Docker cũng vì thế mà nổi lên 😀

Demo

Chẳng hạn như mình có một ứng dụng web phân chia như mô hình bên dưới. Bạn Web UI sẽ đại diện cho front-end và bạn Gateway sẽ là cha của phía backend. Bạn Module A sẽ chịu trách nhiệm cho việc quản lý user, admin đồ chẳng hạn. Bạn Module B sẽ chịu trách nhiệm quản lý danh sách các bài blog. Bạn Module C thì sẽ chịu trách nhiệm quản lý hình ảnh, video đồ…


Khi người dùng thực hiện thao tác xem danh sách các bài blog. Thì Bạn Web UI sẽ gửi request lên server. Tất cả các request dù cho muốn truy xuất đến Module A, B hay C thì đều cùng phải gọi lên bạn Gateway hết. Lúc này bạn Gateway bên trong mới xử lý cắt cái chuỗi request đó ra để nhận dạng được là bạn Web UI bản đang muốn gọi bạn Module nào lên. Sau đó sẽ điều hướng request sang cho bạn Module tương ứng. Nội dung được truyền lên như Header hay Body đều được giữ nguyên.

Trong trường hợp bạn Web UI bản gọi cái gì đó mà cần sự kết hợp của cả 2 bạn Module luôn. Chẳng hạn như user muốn đăng bài Blog Microservices. Thì việc lưu nội dung của bài blog xuống là do bạn Module B chịu trách nhiệm và việc upload hình là do bạn Module C chịu trách nhiệm. Thế là khi bạn Web UI gọi lên bạn Gateway, thì lúc này bên trong bạn Gateway phải có 1 cái service để xử lý cả 2 việc đó xong thì mới trả về kết quả cho bạn Web UI.

Hoặc VD khác là trường hợp hiển thị bài blog Microservices lên. Lúc này bạn Gateway phải forward request đến cho cả 2 module B và C để lấy dữ liệu về sau đó sẽ combine data lại và trả về cho bạn Web UI.

Kết luận

Kiến trúc một khối (monolith) sẽ tốt cho những ứng dụng đơn giản, ít chức năng. Còn microservices sẽ phù hợp với những ứng dụng lớn, phức tạp. Cái gì cũng có lợi hại riêng của nó. Nên tùy thuộc vào tương lai project của chúng ta thế nào mà chúng ta sẽ quyết định nên sử dụng kiến trúc nào. Cảm ơn bạn đã dành thời gian đọc đến đây 😀

===============================

Ps: Trong bài này mình ko giải thích nhiều khái niệm cũng như viết bài bản như mọi người hay viết do mình ko thích nói sâu nhiều về lý thuyết. Do lý thuyết thì nhiều nơi có rồi lắm. Vậy nên nếu bạn muốn nghiên cứu kỹ hơn, sâu hơn về kiến trúc Microservices, các bạn có thể download free ebook: Microservices: From Design to Deployment

Hướng dẫn

Customize the Azure AD B2C user interface (UI)

Azure Active Directory B2C là 1 giải pháp quản lý xác thực cho các ứng dụng web và điện thoại bằng cách sử dụng email hoặc các tài khoản socials (facebook, twitter,…). Nói sơ vậy hoy, khái niệm về Azure AD B2C là gì thì các bạn tự tìm hiểu thêm nha. Trong bài này mình sẽ hướng dẫn các bạn từng bước để custom cho giao diện các trang login, signup,… của nó. Tại nó hữu dụng mà giao diện nó xấu òm hà. Vầy nè vầy nè…

Screen Shot 2017-06-04 at 9.36.23 PM

Vậy làm sao để có được hình nền, logo hay bố cục giống ý mình muốn đây?

Screen Shot 2017-06-04 at 11.11.02 PM.png

Đó, nó khác hơn đồ gốc rồi đó thấy hơm? Tuy là có hơi í ẹ tí nhưng mà mình tin bạn sẽ làm được đẹp hơn mình mà há ^^

Bước 1: Làm đẹp UI

Tạo 1 trang html trong đó có element là <div id=”api”>< /div> đặt ở đâu đó trong thẻ body. Phần này khi hiển thị lên web thì nội dung của Azure AD B2C sẽ được tự động thêm vào.  Rồi sau đó cứ style cho nó như 1 trang web thông thuờng.

Chẳng hạn như ở đây mình tạo file unified.html có nội dung như sau:

Screen Shot 2017-06-04 at 11.32.33 PM.png

Còn css thì mình style kiểu kiểu vầy

Screen Shot 2017-06-04 at 11.32.54 PMScreen Shot 2017-06-04 at 11.37.28 PM.png

(Bạn có thể tham khảo thêm ở đây: https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-ui-customization)

Bước 2: Host files

Bạn có thể up các file html, css, hình,… ở đâu đó. Ở đây, mình sử dụng Azure Blob Storage

  • New -> Storage -> Storage account – blob, file, table, queue
  • Điền thông tin
  • Tạo container với access type là blob
  • Up hết các files vào đây. Có thể sử dụng Microsoft Azure Storage Explorer (http://storageexplorer.com/) để quản lý files cho dễ dàng.

Bước 3: Configure CORS

Trong phần setting của storage, bạn chọn CORS.

  • Click vào Add.
  • Đặt giá trị cho Allowed origins là *.
  • Chọn GET và OPTIONS cho phần Allowed verbs.
  • Đặt giá trị cho Allowed headers là *.
  • Đặt giá trị cho Exposed headers là *.
  • Maximum age (seconds) là 200.

Screen Shot 2017-06-04 at 10.34.29 PM.png

Bước 4: Tạo policy và trỏ tới Custom page URI

Trong Azure AD B2C Settings. Bạn sẽ tạo các policy mà mình muốn. Chẳng hạn như ở đây mình tạo Sign-up or sign-in policy. Ở phần điền thông tin bạn chọn vào “Page UI customization” ở dưới cùng. Xong nó sẽ có phần “Unified sign-up or sign-in page”. Trong phần này bạn sẽ thiết lập để trỏ tới đường dẫn chứa các file của mình:

Screen Shot 2017-06-04 at 10.08.53 PM.png

Ok, done. Bạn có thể vào trang này https://aadb2cplayground.azurewebsites.net/ để test thử các policies của mình cũng được nè.

Blog

Chuyện ở OSD

Cho dù giữa cuộc đời khô cằn, mình vẫn muốn bày tỏ sự chân thành của mình đối với những người mà mình đáng quý. Bài blog này xem như là món quà chia tay mình dành cho OSD. Thật ra thì cũng không định viết blog đâu. Chỉ là chia tay một cty mới làm đây chưa được 1 năm cơ mà. Nhưng mà ko biết ở đâu những kỷ niệm về khoảng thời gian vừa qua tự nhiên nó lại ùn ùn ùa về.

Có một anh lead cực kỳ tận tuỵ, cứ đi sớm về trễ. Việc bù đầu bù cổ nhưng chưa bao giờ một lần lớn tiếng với ai trong team. Mỗi lần vướng cái gì khó, ảnh ngồi kế bên vừa làm vừa chỉ mình. Lúc đó mới thấy nể ảnh gì đâu. Giỏi gì giỏi dữ. Rồi mỗi lần muốn hỏi gì cái mình tung ta tung tăng chạy lại hỏi, ảnh ngước lên cười hiền hoà rồi hỏi “Sao em?”. Phái phái, nhỏ này mê trai bây…. Thật ra thì hỏng phải vậy đâu, giữa những giây phút làm việc căng thẳng áp lực mà thấy ai cười rồi nói chuyện nhẹ nhàng với mình là thấy lòng ấm hẳn lại (Nói hồi sao vẫn thấy còn hơi lộ mê trai quá. Thôi mình xin dừng ở đây và ko nói gì thêm *mặt ngại* )

Có anh, task chưa xong mà cứ nhiệt tình bỏ thời gian ra để ngồi chỉ cho mình. Xong rồi việc của ảnh chưa xong nên tối tối lại phải về muộn.

Có chị, tuy là lời nói hơi lạnh lùng cũng chút bạo lực. Chẳng hạn như “ta vặn đầu mi bây giờ”. Vậy đó mà lại cực kỳ quan tâm mình.

Có anh, chắc cũng bận lắm mà tự nhiên mình muốn hỏi gì cái ảnh lại nói “Hỏi đi. Đang ngồi buồn mong có người hỏi gì đó nè”.

Thôi, có cơ hội để thổ lộ ra với những người mình đáng quý nhiêu đây là đủ rồi. Giờ nói về mình học được gì ở OSD ha.

Nhiều khi vô tình hỏi mình học được những gì trong thời gian qua rồi cái cũng ko biết nói sao. Theo cảm nhận của mình thì thấy nó cứ ngang ngang nhau, chả nổi trội gì cả. Nhưng rồi trong đêm tâm trạng như hôm nay, ngồi ngẫm lại thời gian qua mình học được cũng bộn thứ:

Về kỹ thuật:

  • Biết rành hơn về HTML, CSS
  • Từ 1 đứa ko biết gì về angular, giờ biết chắc cũng được 40-50% gì đó. Mà rành về angular 2 hơn.
  • .NET chắc cũng tăng level lên được hơn.
  • Biết thêm được về Elasticsearch.
  • Có cơ hội vọc vạch và biết sâu hơn về Azure

Ngoài ra thì về mặt để tạo nên 1 lập trình viên giỏi, mình cũng học được về nguyên lý SOLID (hông sure là mình nắm rõ nó nhưng ít ra cũng biết sự có mặt của nó và biết được sơ sơ để chém gió tỏ vẻ nguy hiểm. hí hí hí) vận dụng vào để code cho chuyên nghiệp hơn (cốt là cũng muốn tỏ vẻ nguy hiểm tiếp) mà cũng để dễ dàng quản lý và bảo trì.

Rồi được biết về clean code nè. Rồi về scrum nè. Biết nhiều hơn và hiểu sâu hơn về git và tfs. Rồi sơ sơ về deploy trên jenkins nữa. Pla pla pla…

Ồ, kể ra mình học cũng được nhiều dữ ta. Có đôi lúc thấy nó chả là gì nhưng có đôi lúc nói chuyện với bạn, có thể về mặt kiến thức thì mình thua người ta nhưng về cách làm việc đồ này nọ thì mình sẵn sàng chém gió. Huý huý…

À mà mình cũng hờn OSD về chuyện ăn sáng nữa. Sáng sáng đi làm vô ăn đồ ăn sáng của OSD xong là no bể bụng. Mỗi lần tới giờ cơm là cứ ngao ngán nói “no quá sao ăn cơm giờ” 😦

Hơizz… Chợt thấy, tình cảm là thứ gì đó thiệt ghê gớm… Hừm, thiệt khó để chấm dứt… Hừm, lời chia tay thiệt khó để nói ra 😥 Đêm nay và cả những ngày tiếp theo chắc sẽ là những đêm dài đầy tâm trạng…

Hướng dẫn

Bảo mật file trên Azure Blob Storage với Shared Access Signatures (SAS)

Trong cả đống chức năng của Azure thì em này ẻm có tính năng lưu trữ file như document, hình, video, pla pla pla…. gọi là blob storage. Cụ thể về blob storage là gì thì mình sẽ ko nói trong bài viết này, các bạn có thể google để biết rõ hơn về nó. Mình xin phép đi thẳng vào vấn đề chính là bảo mật file trên Azure Blob Storage.


Vấn Đề

Chúng ta lưu file trên Azure Blob Storage, nếu có đường dẫn của file là ai cũng có thể truy cập vào cái file đó được. Vậy rồi làm sao bảo mật cho file đó được đây?

Giải Pháp

Hừmmm…. Để bảo mật cho một file nào đó của mình trên Azure Blob Storage thì giải pháp của mình là sẽ sử dụng Shared Access Signatures (SAS). Với SAS, chúng ta có thể gán quyền truy cập vào file cho client mà ko cần chia sẻ account keys của blob storage. SAS sẽ thiết lập các quyền đọc ghi file. Mà nếu set quyền chung chung như vậy thì ai cũng có quyền truy cập vào file đó được mà? Vậy nên mình sẽ làm theo kiểu là đầu tiên mình sẽ tạo ra 1 cái SAS với cái quyền là đọc file đó trong 1 khoảng thời gian. Sau đó mình sẽ đọc nội dung file bằng cách truy cập vào link có chứa 1 đoạn token do SAS tạo ra rồi lưu ra binary. Khi hoàn tất, mình sẽ xóa cái SAS đó.

Khi chúng ta thiết lập quyền ko cho truy cập file, nếu bạn truy cập đến đường dẫn đó thì sẽ nhận được thông báo:

Còn khi bạn truy cập vào đường dẫn có token mà trong thời gian hết hiệu lực của SAS thì sẽ nhận được thông báo:


Thực Hiện

Bước 1: Đặt access type của container thành “Private”

Bạn có thể thiết lập access type của container thành “Private” bằng 2 cách:

  • Thiết lập bằng tay trên Azure Portal


  • Thiết lập bằng code


Bước 2: Tạo quyền cho file

Đầu tiên chúng ta sẽ khai báo access policy name và gọi tới hàm CreateSharedAccessPolicy


string shareAccessPolicyName = "testPolicy";

CreateSharedAccessPolicy(blobClient, container, sharedAccessPolicyName);

Chúng ta có thể tạo quyền truy cập mới mỗi khi chúng ta muốn truy cập đến file. Ở đây có một vấn đề là nếu tên của access policy mà ko đổi thì link truy cập file sẽ ko thay đổi nên mình nghĩ chúng ta có thể đặt tên cho cái access policy là dạng username + ngày giờ hiện tại để mỗi lần tạo ra nó sẽ tạo ra các đường link khác nhau.

Hàm CreateSharedAccessPolicy sẽ như sau:


Bước 3: Lấy blob uri có policy


Bước 4: Đọc file


Bước 5: Xóa quyền truy cập


Bước 6: Lưu binary data ra file vật lý hoặc hiển thị popup download cho user down về

VD như mình viết 1 cái API làm mấy chuyện ở trên, giờ qua client mình sẽ call API để lấy về được binary data sau đó sẽ hiển thị popup cho người dùng download file về:

Hướng dẫn

Tạo project Angular 2 dễ dàng với Angular CLI

Để tạo 1 project Angular 2 chúng ta phải thiết lập nhiều thứ khá phức tạp. Tại sự kiện ng-conf 2016, đội ngũ Angular đã giới thiệu 1 công cụ giúp chúng ta tạo 1 ứng dụng Angular 2 với cái khung có sẵn một cách nhanh chóng và dễ dàng. Thiết lập thư mục git rồi unit test rồi e2e test đồ cho mình luôn. Ghê chưa ghê chưa?!??!!


Các bạn có thể vào trang https://cli.angular.io/ để xem thêm thông tin chi tiết. Còn bây giờ mình xin bước vào vấn đề chính là hướng dẫn các bạn từng bước để tạo ra được một ứng dụng Angular 2.

Cài đặt Angular CLI

Để cài đặt CLI, chúng ta sẽ dùng câu lệnh

     npm install -g angular-cli

Khởi tạo ứng dụng

Để tạo một ứng dụng Angular 2 mới, chúng ta chỉ cần gõ

     ng new project-name

VD: ng new sampleApp

Run, Build, Test các kiểu

Giờ chúng ta bắt đầu chạy thử ứng dụng bằng lệnh

     ng serve

Để build ứng dụng thì chúng ta sẽ dùng lệnh

     ng build

Roài, để chạy unit test thì chúng ta sử dụng lệnh

     ng test

Còn test e2e thì dùng lệnh

     ng e2e

Mới có 2 câu lệnh mà đã chạy được cả đống như vậy. Kinh chưa?!??

Tạo Component

Hồi trước tạo component là phải ngồi tạo từng file, nào là html rồi css rồi ts các kiểu. Lại còn phải khai báo định nghĩa này nọ để liên kết các file lại với nhau.

Giờ một đống này sẽ tự động phát sinh khi bạn dùng lệnh

          ng g component my-new-component

VD: ng g component hello


Tương tự, để tạo một cái gì đó thì bạn cứ thẳng tay gõ:

Directive ng g directive my-new-directive
Pipe ng g pipe my-new-pipe
Service ng g service my-new-service
Class ng g class my-new-class
Interface ng g interface my-new-interface
Enum ng g enum my-new-enum
Module ng g module my-module
Route ng g route my-route