Thứ Bảy, ngày 14 tháng 12 năm 2013

Big Data là cái gì?

"Big data" ngày nay có thể xem là một thuật ngữ "thời thượng" của giới công nghệ, bên cạnh những thuật ngữ như "cloud", "web apps",... Thế nhưng, bạn có biết big data thật sự là thế nào?

Với tiêu chí "Dài quá không đọc" (TL;DR), tôi chỉ đề cập sơ sơ vài nét chính dưới dạng Q&A.


1. Ở đâu ra Big Data?


Tất nhiên là khi có nhiều người cùng tham gia tương tác trên các dịch vụ, thì dữ liệu của các dịch vụ này sẽ lớn.

Việc này đồng nghĩa với việc các trang web đưa tin truyền thống hay trang web giới thiệu công ty/sản phẩm ít khi được xem là Big Data, bởi vì data ở đó rất nhỏ bé.

2. Data lớn như thế nào mới gọi là Big Data?


Hãy nói về phương pháp đo độ lớn. Trong một bài viết như bài viết này, mỗi chữ cái chiếm 1byte, như vậy một bài tương đối dài sẽ chiếm khoảng 5KB (5*1024 byte). Nếu như một trang web có khoảng hơn 1000 bài thì data của trang web đó khoảng 5MB, đó là một con số khá lớn cho một trang blog hoặc tin tức.

Thông thường khi người ta đề cập tới Big Data, người ta thường nói tới data tới hàng Terabyte. Để dễ hình dung thì 5TB tương đương với hơn 1 tỷ bài theo cách tính của chúng ta. Đó quả thật là con số khổng lồ so với dung lượng RAM khoảng 16GB (phổ biến ở các server hiện nay).

Nói thêm về những "ông lớn" như Google hay Facebook thì dữ liệu của họ sẽ lớn tới mức phải tính bằng Petabyte hoặc hơn nữa...

3. Xử lý Big Data là thế nào?


Server thông thường chỉ có tối đa 16GB trên vùng RAM, và khi một người xem đọc một bài viết thì bài viết sẽ được server trả về từ RAM sẽ nhanh hơn rất nhiều so với trả về từ ổ đĩa.

Thế nhưng data thì có tới hàng trăm GB, do đó cần phải có một cơ chế caching thế nào cho việc truy xuất bài viết là nhanh nhất. Đó là mức thấp nhất của việc xử lý Big Data.

4. Tại sao phải quan tâm tới việc xử lý Big Data?

Xuất phát từ một nhu cầu cực kỳ có ý nghĩa kinh doanh: Phân tích (Analysis) và Báo cáo (Reporting).

Tại sao? Tại vì người ta muốn biết người xem muốn cái gì? Cái gì ở trang web hấp dẫn người ta nhất? Đâu là vị trí mà người xem dễ thấy nhất? Trang web của chúng ta có lỗi gì không? Và còn rất nhiều câu hỏi khác... Muốn trả lời được cần phải ghi lại các hành động của người xem và đem đi phân tích.

Tuy nhiên, dữ liệu về hành động của người xem thật sự là khổng lồ. Thực tế cho thấy thì khi trang web có lượng truy cập đồng thời chỉ 1000 người, thì dữ liệu access log đã ở mức 1GB/ngày. Như vậy một năm sẽ là 365GB. 365GB cho một dịch vụ "nhỏ" chỉ khoảng 1000 truy cập đồng thời đó cũng là một con số khá lớn rồi...

Đã vậy, mục tiêu lại phải trả lời những câu hỏi cực kỳ phức tạp như: "Cái gì ở trang web hấp dẫn người ta nhất?", như vậy cần phải tính toán và tổng hợp trên một dữ liệu khổng lồ kia, thì công việc sẽ phức tạp đến thế nào.

5. Sử dụng Database gì là thích hợp?


Nếu trang của bạn ít lượt truy cập hoặc không cần phân tích, hãy nghĩ một cách đơn giản và thiết thực: MySQL đã là đủ. Nếu bạn làm tốt, MySQL có thể chịu được data trên 10GB.

Nếu trang của bạn lớn, nhưng không cần phân tích, hoặc chỉ phân tích đơn giản, dữ liệu "nhỏ" ở mức khoảng dưới 1TB, tôi nghĩ những thứ NoSQL như MongoDB rất dễ tiếp cận và cũng hiệu quả.

Còn nếu dịch vụ của bạn cực kỳ lớn, số lượng user tới hàng triệu, phân tích chiến lược phức tạp,... lúc đó hãy nghĩ tới Big Data thật sự, nổi nhất hiện nay vẫn là Hadoop và một loạt công nghệ liên quan như HDFS, Hive, Pig,... Tất nhiên, chi phí để setup và làm quen với những thứ đó không phải là ít.

6. Cần phải chuẩn bị gì cho sân chơi Big Data?


Tất nhiên là bạn phải có dữ liệu cực lớn trước. Tuy nhiên, nhiều công ty đã có sẵn rồi và họ cần một đội ngũ để làm và hoàn thiện nó (như công ty của mình là một ví dụ).

Với cá nhân mỗi người, cái cần chuẩn bị là tư tưởng mở, sẵn sàng học hỏi và lao vào công việc bằng tất đam mê.

Tiếp theo, sân chơi này không phải dành cho tất cả mọi người, bạn chỉ nên tham gia khi bạn có nền tảng tốt về hệ thống, về kiến trúc phần mềm. Bạn cũng cần phải search bằng tiếng Anh và đọc hàng trăm trang tài liệu tiếng Anh mỗi ngày làm việc (bạn chỉ có thể làm khi bạn hiểu rõ về nó mà thôi).

Thêm một điều đặc biệt nữa là phải đọc code của người khác mỗi ngày, bởi có nhiều thứ không có tài liệu, cách duy nhất để bạn hiểu được đó là mở code của người ta mà đọc. Rất nhiều code opensource về big data này cho bạn, cái chính là bạn cần phải biết mình đọc cái gì và cần hiểu cái gì...

Và điều cuối cùng là: Phải thật sự cẩn thận. Nhiều khi chỉ vì bạn lỡ xóa một cái gì đó mà tất cả mọi công sức sẽ đem đổ sông đổ biển.

Kết luận


Big data thật sự đang là thứ challenge cho tất cả mọi người đam mê, và trở thành một trong những ngành hot nhất hiện nay. Trong tương lai xa nó vẫn sẽ hot, bởi vì lúc nào người kinh doanh cũng cần phân tích mà. Tuy nhiên, sân chơi này chỉ dành cho một số ít người thật sự có đam mê.

Chúng tôi đang tuyển...


Bạn nào muốn tham gia vào lĩnh vực này, có thể nộp đơn vào công ty GNT Vietnam của tôi.

Ngoài ra, các bạn có thể hỏi tôi nhiều hơn về Big Data trên Group mới lập: https://www.facebook.com/groups/ask.bigdata/ hoặc https://plus.google.com/communities/117413572964133445398 hoặc xem các bài trên Facebook của tôi: https://www.facebook.com/nkimkha (Nếu thích thì các bạn có thể Follow, đừng kết bạn)

Thông tin về tuyển dụng DBA (làm công việc liên quan tới Big Data)




Thứ Bảy, ngày 21 tháng 9 năm 2013

TLDR: Phân biệt OLAP và OLTP

OLAP và OLTP là hai công nghệ xử lý dữ liệu khác nhau và bù trừ nhau trong ngành IT "online" ngày nay. OLTP thì cực kỳ cần thiết và phổ biến, bạn sử dụng nó mỗi ngày. Trong khi OLAP lại được sử dụng khá rộng rãi trong giới quản lý/vận hành các công ty.

Nhưng khoan đã! Bạn đã biết 2 khái niệm này chưa?


Vài dòng định nghĩa


OTLP - viết tắt của OnLine Transaction Processing (Xử lý giao dịch trực tuyến). Gần hết các "giao dịch trực tuyến" đều dựa trên cái này. Từ việc bạn vào facebook, xem blog,... cho tới việc bạn mua hàng trực tuyến hay giao dịch ATM, đều được quy về chung khái niệm OLTP.

OLAP - viết tắt của OnLine Analytics Processing (Xử lý phân tích trực tuyến). Được định nghĩa là những thứ "trực tuyến" khác liên quan tới vấn đề phân tích và xử lý khối lượng lớn dữ liệu, giúp người quản lý/vận hành đưa ra các chiến lược kinh doanh hợp lý.

OK. Tạm thời tôi định nghĩa là vậy, bạn có thể tìm thêm trên net.

Vậy tại sao ta lại phải quan tâm? Suy cho cùng thì cũng là vấn đề lưu trữ dữ liệu. Với OLTP, người sử dụng cần nhanh chóng và chính xác đến từng giao dịch, nên cần một DB hữu hiệu cho việc này. Ngược lại, OLAP phục vụ người quản lý, vốn chỉ cần biết dữ liệu để thống kê và phân tích nên cần khối lượng lớn dữ liệu và quan hệ phức tạp, nhưng lại cần truy vấn nhanh ở dạng tổng quan, bởi vậy DB phải thiết kế tối ưu cho việc đó.

TLDR Comparison - Dành cho người không muốn đọc nhiều



OLTP OLAP
Ứng dụng Vận hành: ERP, CRM, ứng dụng truyền thống, tin tức, weblog, ... Hệ thống quản lý thông tin, Hệ thống hỗ trợ ra quyết định,...
Người dùng chủ yếu Người dùng, nhân viên Quản lý, điều hành
Phạm vi xử lý Hàng tuần/tháng Hàng năm
Mức độ làm mới Ngay tức thì Định kỳ
Mô hình dữ liệu Entity-relationship, hoặc thích thì có thể BigData, key-value,... Multi-dimensional
Schema Normalized (Chuẩn hoá dữ liệu) Star hoặc snowflake
Nhấn mạnh Cập nhật Truy hồi thông tin
Số lượng người dùng Hàng ngàn tới hàng triệu Hàng trăm
Dung lượng ổ đĩa MB tới GB GB tới TB
Đo lường Số lượng giao dịch/người dùng đồng thời Số lượng câu truy vấn và thời gian phản hồi


OK. Vài dòng tóm lược như vậy thôi, mọi người có thể tìm hiểu sâu hơn nếu quan tâm.

Điều cuối cùng


Đừng bao giờ xử lý OLAP trên DB theo mô hình của OLTP, bởi vì chúng thật sự không giống nhau. Tuy nhiên, bạn có thể làm thế nếu bạn chỉ muốn phân tích bài toán nhỏ và đơn giản. Trade-off thôi...

---------
Bài viết này dựa trên bài http://www.cbsolution.net/techniques/ontarget/olap_vs_oltp_what_makes và một số nguồn khác.

Thứ Ba, ngày 17 tháng 9 năm 2013

TLDR: Bạn đã từng nghe về EventSource?

EventSource (xem ở đây: http://www.w3.org/TR/eventsource/) là dạng phương thức gửi message từ server xuống client, mà server là người chủ động. Ngược hoàn toàn với HTTP Request thông thường, khi client chủ động gửi request lên server và server response. Nó được sinh ra để giúp server có thể gửi message xuống client để làm gì đó như là notification, tin mới,... theo cách cực kỳ realtime.

Nó còn có tên gọi khác là Server-Sent Events.


Vậy nó khác gì với WebSocket? Câu trả lời là chúng là 2 khái niệm khác nhau... Bạn nào muốn tìm hiểu chi tiết hơn có thể search trên Google, hoặc vào đọc bài viết này: http://www.html5rocks.com/tutorials/eventsource/basics/

TLDR Summary - Dành cho người không muốn đọc nhiều


Điểm lợi của EventSource so với WebSocket:
  1. Truyền nhận dữ liệu thông qua HTTP thông thường, thay vì phải "phát minh" ra một protocol mới.
  2. Có thể tự động chuyển sang dạng "hỗ trợ ngược" (backport) nếu trình duyệt không hỗ trợ WebSource.
  3. Hỗ trợ sẵn việc tái kết nối và event-id
  4. Protocol đơn giản hơn nhiều.

Điểm lợi của WebSocket so với EventSource:
  1. Real-time, và hỗ trợ kết nối cả 2 chiều.
  2. Nhiều trình duyệt hỗ trợ ở mức nền tảng.

Những trường hợp nên sử dụng EventSource:
  • Thông tin chứng khoán được push liên tục.
  • Cập nhật thông tin liên tục kiểu twitter.
  • Notification tới trình duyệt.

Cơ bản vài dòng thế thôi! Ai thấy hứng thú thì tìm hiểu thêm...

Thứ Bảy, ngày 27 tháng 7 năm 2013

Ứng dụng LinkChecker trong smoke testing

Hầu hết mọi lập trình viên đều biết đến khái niệm software testing (kiểm thử phần mềm). Có thể nói testing gồm 2 phần chính là manual testing và automation testing. Tất cả chúng ta đều rất quen thuộc với khái niệm manual testing, và nhiều người trong số chúng ta đều muốn làm automation testing thay vì manual. Thế nhưng, việc bắt đầu một thế giới gọi là automation testing sẽ là thế nào cho phù hợp với một mô hình nhỏ, nhất là các startup vốn đang tăng nhanh trong thời gian gần đây?

Bài viết này hi vọng sẽ giúp được phần nào cho câu hỏi: Loại automation nào dễ triển khai và cần phải có cho một ứng dụng web bình thường?

Smoke testing là gì?

Có thể bạn chưa nghe tới khái niệm smoke testing này. OK. Tôi sẽ dành một đoạn ngắn thời gian để giải thích, nhưng vì khuôn khổ bài viết tôi sẽ trình bày ngắn gọn thôi...

Về nguyên thủy, thì smoke testing là khái niệm xuất hiện trong ngành điện tử. Khi người ta làm ra một board mạch nào đó, việc đầu tiên là họ sẽ cắm nguồn điện vào, nếu mạch điện không "xì khói" thì có nghĩa là đã smoke testing thành công. Board mạch nào "xì khói" thì coi như hỏng, khỏi phải test các bước tiếp theo, vì có test cũng không thể test được. Nói tổng quát, smoke testing là bước test cơ bản để một sản phẩm có thể bắt đầu các bước testing tiếp theo.

Trong ngành phần mềm, và nhất là các ứng dụng web, smoke testing được hiểu là kiểm xem ứng dụng của bạn có bị "xì khói" khi khởi chạy hay không. Chúng ta không thể test nếu như vô trang chủ bị lỗi (vì trang chủ bị lỗi thì làm sao mà vô được những trang tiếp theo?), hay trang chủ không có link nào để bấm tiếp. Thông thường, người ta sẽ sử dụng smoke testing để kiểm tra 3-5 cấp độ sâu của trang web...

LinkChecker là gì?

Chỉ đơn giản nó là công cụ miễn phí và nguồn mở cho tất cả mọi người muốn test các link trong trang web của mình. Bạn có thể download nó tại: http://wummel.github.io/linkchecker/.

Cách thức hoạt động của nó là request một link, đọc nội dung của page đó và lấy các link trong page đó ra, đưa các link vào queue để xử lý tiếp. Một khái niệm cơ bản mà bạn phải nắm đó là độ sâu. Khi bạn đưa link của một page, thì page đó là độ sâu cấp 0, trong page đó có các link thì page tương ứng là cấp 1, và tương tự vậy cho cấp 3, 4, 5,... Với LinkChecker thì độ sâu -1 có nghĩa là vô hạn (cho tới khi nào không còn link nào nữa thì thôi).

Có thể trang web của bạn cần login, vậy làm thế nào? OK. Hãy đặt câu hỏi liệu bạn có thể bỏ qua vấn đề login hay không? Nếu có thì mọi chuyện thật dễ dàng. Nếu không thì bạn cũng đừng quá lo, bạn nên biết rằng bạn có thể đăng nhập bằng trình duyệt, sau đó copy cookie của trang và đưa vào LinkChecker, như vậy là có thể vượt qua được phần đăng nhập.

Copy cookie để đăng nhập? Nếu bạn ngạc nhiên như thế thì có làm hỏng vấn đề security trong trang web của mình không? Chúng ta sẽ bàn vấn đề này sau, và trở lại vấn đề smoke testing.

Trở về với LinkChecker, một thứ mà mặc định ai cũng nghĩ tới là tool này chạy hoàn toàn tự động, bạn chỉ cần cấu hình cho đúng với yêu cầu cụ thể của mình, chạy nó lên và chờ kết quả. Nói cách khác, đây là một ứng dụng automation testing ở mức đơn giản.

Áp dụng LinkChecker vào Smoke testing 

  1. Cài đặt LinkChecker lên một máy tính có cấu hình khá.
  2. Xác định độ sâu, tôi khuyên bạn nên chọn là 3-5 trong lần bắt đầu, đừng bao giờ nghĩ tới độ sâu vô hạn, vì nó là một thứ làm "cho vui" chứ không có ý nghĩa trong smoke testing lắm.
  3. Chuẩn bị sẵn sàng các vấn đề như đăng nhập, server web của bạn đã start OK hết.
  4. Run LinkChecker và đi kiếm một ly cà phê chờ kết quả.

Những thứ mà LinkChecker có thể làm được

Mục đích cuối cùng của smoke testing chính là kiểm tra ứng dụng web xem nó có bị lỗi khi vô các trang cơ bản hay không? Vì nếu vô các trang này mà còn bị lỗi thì không thể kiểm tra các chức năng khác được. Sau đây là một số thứ LinkChecker có thể làm được phục vụ cho mục đích smoke testing.
  • Kiểm tra các trang có bị lỗi nghiêm trọng như 500, 502, 503, 400,... Mức độ nghiêm trọng: 5/5.
  • Kiểm tra các link bị 404, kể cả link hình, css, js,... Mức độ nghiêm trọng: 4/5.
  • Kiểm tra các link có kích thước request quá dài. Mức độ nghiêm trọng: 2/5.
  • Kiểm tra các trang response quá lâu, bị timeout,... Mức độ nghiêm trọng: 4/5.
  • Tìm các link bị redirect quá nhiều lần hoặc redirect đệ qui vô hạn. Mức độ nghiêm trọng: 4/5.
  • Kiểm tra các trang có dung lượng quá lớn. Mức độ nghiêm trọng: 2/5.
  • Và nhiều thứ khác mà bạn có thể tìm thấy khi sử dụng...
Hi vọng là bài viết này có thể giúp ích cho các bạn phần nào... Xin cảm ơn vì bạn đã kiên nhẫn đọc tới dòng này...

Thứ Tư, ngày 24 tháng 7 năm 2013

Các nguyên lý thiết kế hệ thống web

Web là gì? Có rất nhiều định nghĩa trên thế giới, nhưng ở đây tôi chỉ muốn đề cập tới một khía cạnh: Hệ thống web được sử dụng để phục vụ hàng nghìn đến hàng triệu user đồng thời. Và bài viết này đề cập tới vấn đề các nguyên lý khi thiết kế hệ thống web với nhiều server.

Giống như những thứ khác trong cuộc sống, việc đầu tiên bạn làm là dành thời gian để lên kế hoạch cho dịch vụ của bạn, cân nhắc những thứ bạn sẽ đạt được và những thứ đánh đổi. Một hệ thống được thiết kế lúc đầu chắc chắn sẽ phải chạy một thời gian dài, và việc thay đổi sang một cách thiết kế khác thường kéo theo rất nhiều chi phí (lớn hơn nhiều so với việc đập bỏ và xây dựng lại). Một lưu ý nữa về tầm quan trọng của giai đoạn này đó là thiết kế của bạn sẽ ảnh hưởng trực tiếp hoặc gián tiếp tới quy trình làm việc, công sức của các dev, và việc "sống chết" của dịch vụ của bạn.

Ảnh minh hoạ

Do vậy, hãy cân nhắc kỹ và quyết định một cách thiết kế nào tối ưu nhất. Trong khuôn khổ bài viết này, tôi chỉ muốn đề cập đến các nguyên lý, dựa vào đó mà bạn có thể cân nhắc để chọn cách thiết kế nào:


  • Tính sẵn sàng (Availability): Đây là tiêu chí quan trọng gần như tuyệt đối ở hầu hết các dịch vụ ngày nay: Đừng bao giờ để web của bạn bị "chết". Với những cửa hàng bán lẻ online, việc có một vài phút không truy cập được có thể khiến thiệt hại lên đến hàng nghìn, hàng triệu đô la. Việc không truy cập được có thể có nhiều nguyên nhân, có thể do lỗi server, cũng có thể do nhiều lượt truy cập quá sức chịu đựng, hoặc có thể do bị tấn công... Và "lỡ" có một lần dịch vụ bị "chết" thì bài toán đặt ra là khả năng phục hồi lại dịch vụ là trong bao lâu.
  • Hiệu suất (Performance): Cũng là một tiêu chí quan trọng bậc nhất của hầu hết các website: Giảm tối đa tốc độ tải và xử lý các request. Tốc độ tải trang, tốc độ xử lý render trang,... ảnh hưởng trực tiếp tới hiệu quả sử dụng, tới sự hài lòng của user, và cả ranking của bạn trong các search engine nữa. Mà những chỉ số này lại ảnh hưởng tới doanh thu (revenue) và khả năng quay lại trang (retention).
  • Độ tin cậy (Reliability): Hệ thống của bạn dù được thiết kế thế nào đi nữa nó cũng phải tin cậy được, tức là một request tới một dữ liệu nào đó là luôn lấy được dữ liệu đó, hoặc khi bạn cập nhật thì luôn lấy được dữ liệu mới được cập nhật đó. Bạn có thể nghĩ làm sao mà có thể khác đi được. Nhưng thực tế khi triển khai hệ thống web lớn với hàng chục server thì bạn sẽ thấy khác, nếu thiết kế không tốt, rất có thể xảy ra tình trạng server này có dữ liệu mới rồi mà server khác lại chưa có, mặc dù chúng cùng một cụm server cho một dịch vụ nào đó. Đứng với góc nhìn user, họ biết rằng dữ liệu của họ nhập vào sẽ "nằm yên ở đó".
  • Khả năng mở rộng (Scalability): Khi hệ thống của bạn lớn lên, bạn chắc chắn sẽ phải tăng thêm dung lượng data, tăng số lượng server đáp ứng tải lớn, và rất nhiều thứ khác. Và thế là bạn sẽ lại đau đầu vì mấy câu hỏi như: Hiện tại có thể chịu tải tối đa là bao nhiêu? Việc thêm mới các resource (dung lượng data, số lượng server,...) có dễ dàng hay không? Hoặc bao nhiêu transaction mà nó có thể xử lý đồng thời được?...
  • Mức độ dễ quản lý (Manageability): Việc thiết kế hệ thống cũng cần quan tâm tới việc vận hành và bảo trì hệ thống đó có dễ hay không. Điều này ảnh hưởng tới cách thức mà nhóm vận hành thực hiện, nếu quá khó sử dụng, họ có thể gặp nhiều sai lầm, và từ đó phát sinh nhiều vấn đề nghiêm trọng khác. Một điểm nữa cần chú ý là nếu họ có sai lầm thì hệ thống làm sao có thể phục hồi về trạng thái trước đó thật nhanh và chính xác.
  • Chi phí (Cost): Là một hệ số quan trọng. Rõ ràng một hệ thống không thể gọi là tốt nếu ngốn nhiều chi phí cho việc setup và vận hành. Có rất nhiều loại chi phí như chi phí cho developer hiện thực, chi phí hàng tháng cho server, và thậm chí là chi phí cho việc hướng dẫn người vận hành sử dụng...
Khi bạn bắt đầu thiết kế một hệ thống web lớn, trước tiên hãy ngồi xuống và phác thảo chi tiết theo các nguyên lý trên, sau đó dựa vào business của dịch vụ mà bạn muốn cung cấp để xác định những vấn đề nào cần ưu tiên. Việc cuối cùng là chọn một giải pháp tối ưu, thông qua thiết kế hệ thống và chọn các framework hay ứng dụng.

Bạn có thể thấy điều tôi vừa nói là thừa, vì bạn luôn làm thế mà. Nhưng tôi chỉ muốn bạn chắc rằng bạn bắt đầu bằng những nguyên lý trên và business chứ không phải việc bạn thấy framework hay ứng dụng nào đó hay ho và muốn áp dụng liền để sử dụng.

Trước đây, tôi đã từng vấp phải điều tương tự. Tôi thấy một công nghệ hay, và muốn thử ngay tức thì, tôi bắt đầu cố gắng nối kết công nghệ đó với dịch vụ mà mình muốn triển khai, lên kế hoạch chọn database, chọn framework, nhanh tay chọn một cloud free nào đó để thử nghiệm, và bắt đầu mọi thứ trên đó. Mọi thứ đều ổn, database có thể scale được theo ý tôi, web server cũng scale được, việc quản lý cũng không quá phức tạp. Tất cả mọi chỉ số đều rất tốt, ngoại trừ một điểm là dần dần không có ai hiểu rõ được hệ thống ngoại trừ chính tôi. Có quá nhiều thứ bạn muốn làm, trong khi bạn không thể chia sẻ công việc và trách nhiệm với những người khác, đó là một thất bại. Phần lớn mọi người đều vấp phải sự mệt mỏi khi làm việc với một hệ thống hoàn toàn mới, không giống ai, ngôn ngữ database cũng lạ lẫm, các khái niệm trong framework cũng lạ lùng. Khó khăn khi bắt đầu đã đẩy họ vào con đường phải đầu hàng trong sự mệt mỏi. Suy cho cùng thì đây cũng là một loại chi phí, chi phí ownership.

Những nguyên lý mà tôi đề cập không phải là của tôi đưa ra, mà là tôi cóp nhặt được ở đâu đó, nhưng phải sau khi tôi "nghiền ngẫm" nó bằng một cái giá thực tế thì tôi mới hiểu ra đó là điều quan trọng. Trước đây, tôi đã từng nghĩ mấy cái nguyên lý vớ vẩn kia mình biết cả rồi, giờ mới thấy mình chả biết gì cả. Chỉ là tôi đang note lại để đề phòng mình quên... ^^

Chủ Nhật, ngày 21 tháng 7 năm 2013

Sự trở lại của blog chia sẻ công nghệ của KimKha

Bẵng một thời gian tôi dừng viết blog công nghệ... Chính xác là khi tôi có một công việc tại công ty GNT Vietnam, tôi hầu như chẳng có thời gian nào cả, một phần vì cuộc sống thay đổi và tôi cũng chẳng có hứng viết lách gì cả.

Nhưng giờ thì tôi đã nghĩ khác... Những kiến thức tôi đã học được tại môi trường này thật đáng quý, và tôi bỗng nghĩ liệu mình có nên viết lại một số kinh nghiệm nào đó hay hay, biết đâu lại có ích cho một người nào đó.

Nhưng bẵng một thời gian không viết, và blog cũ không hoạt động thế là tôi đã mất luôn cả blog, từ cái tên miền cho tới cái database chứa nội dung. Do hồi trước sử dụng host free, nên giờ mất gần hết nội dung, tôi đã cố gắng truy lục lại những bài viết cũ cũ, thời viết những bài vớ vẩn đó và đưa lên lại, để phần nào nhìn lại như một quãng đường trưởng thành của mình. Giờ thì blog cũ với domain http://kakalia.co.cc đã không còn nữa, nhưng tôi đã dựng lại với domain mới: http://blog.kimkha.com

Mong mọi người tiếp tục ủng hộ!

Thứ Ba, ngày 09 tháng 11 năm 2010

Tạo object trong Javascript

Trước khi bắt đầu nói về các đối tượng (object) trong Javascript (viết tắt là JS), thì cần phải lưu ý rằng JS không phải là ngôn ngữ lập trình hướng đối tượng, nhưng nó lại cho phép việc đó.

Cách cơ bản

JS hỗ trợ cách tạo object rất giống với các loại khác trong JS như mảng (array), số (number),…
var kha = new Object();
Chúng ta đã tạo được một object mới. và có thể thêm thuộc tính dễ dàng (bao gồm cả việc thêm function)
kha.name = "Nguyen Kim Kha";
kha.run = function(param) {
    alert("Param: "+param);
};
Và bạn có thể thực thi object này.
document.write("Name: "+kha.name);
kha.run("We are one!");

Sử dụng đúng chuẩn object

Các đúng chuẩn của object, và cũng là chuẩn theo JSON (JavaScript Object Notation), đó là khai báo tường minh một object. Ví dụ:
kha = {
    run: function(param) {
        alert("Param: "+param);
    },
    name: "Nguyen Kim Kha"
};
Tuy nhiên có một vấn đề nhỏ cần lưu ý, là giữa các thuộc tính/hàm, bạn phải có dấu phẩy và sau thuộc tính cuối cùng, bạn không nên có dấu phẩy (để đảm bảo là không bị lỗi trên IE).

Sử dụng hàm

Khác với các ngôn ngữ lập trình khác, bạn có thể tạo object mới bằng cách dùng hàm với câu lệnh return. Ví dụ:
kha = function(){
    run = function(param) {
        alert("Param: "+param);
    };
    name: "Nguyen Kim Kha";
    return this;
}();
Khi đó bạn có thể sử dụng object này ở bất cứ đâu (kể cả trong các thẻ <a>, hoặc các sự kiện onclick,…).

Nâng cao

Một khi đã có một object, bạn có thể thêm thuộc tính/hàm cho nó, theo cách đơn giản, với điều kiện thuộc tính/hàm này chưa tồn tại trong object đó:
kha.say = function(){
    this.run("We are one!");
};
Dĩ nhiên là đôi lúc bạn muốn override một hàm nào đó (tức là tạo hàm mà hàm này đã tồn tại), và khi đó chúng ta dùng prototype, được hỗ trợ ở hầu hết các trình duyệt.
kha.prototype.run = function(param) {
    alert("New function with param: "+param);
};
Và còn nhiều thủ thuật với object trên JS khác nữa mà tôi không thể nói ở đây (vì phức tạp quá).
—————
Bài viết thuộc sở hữu cá nhân của tác giả. Không ai được quyền chép nguyên văn bài viết, nhưng có thể dẫn trích vài đoạn nào đó, nhưng phải ghi nguồn rõ ràng và dẫn link đến bài viết này.