Vietnamese Developers' Blog

Umask là gì?

Trong Unix, khi một file hay một thư mục được tạo ra thì quyền truy nhập đối với chúng (r, w, x) sẽ được xác định dựa trên hai giá trị là quyền truy nhập cơ sở (base permission) và mặt nạ (mask). Quyền truy nhập cơ sở là giá trị được thiết lập sẵn từ trước, đối với file là 666 (rw-rw-rw) và thư mục là 777 (rwxrwxrwx). Mặt nạ là giá trị đựợc thiết lập bởi người dùng bằng lệnh umask. Giá trị mặt nạ sẽ “che đi” một số bit trong quyền truy nhập cơ sở để tạo ra quyền truy nhập chính thức cho file (tương tự như cơ chế của subnet mask).

Cụ thể, quyền truy nhập chính thức được tính bằng cách lấy giá trị nhị phân của quyền truy nhập cơ sở AND với dạng biểu diễn bù 1 của mặt nạ. Ví dụ: Vì quyền truy nhập cơ sở của file là 666 (tức 110110110), nên nếu giá trị mask là 022 (000010010) thì quyền truy nhập chính thức của file sẽ là:

110 110 110 AND 111 101 101 = 110 100 100 = 644 (rw-r–r–)

Như vậy, các bit trong quyền truy nhập cơ sở ứng với các bit 1 của mask sẽ bị xóa. Cũng có thể tính quyền truy nhập chính thức đơn giản hơn bằng cách lấy 666 – 022 = 644.

Giá trị mặt nạ được thiết lập như thế nào?

Giá trị mask được thiết lập nhờ lệnh umask trên terminal hoặc bằng hàm hệ thống umask. Các file được tạo ra sau lệnh umask sẽ chịu tác động của giá trị mặt nạ mới. (more…)

Nguồn: The Art of Agile Development by J Shore & S Warden.
Phần tiếp theo của: Agile Development: Giới thiệu Extreme Programming

Một đội dự án XP làm việc cùng nhau trong một không gian mở không có các phòng riêng hoặc vách ngăn. Vào đầu mỗi vòng lặp, đội tổ chức một cuộc họp kéo dài từ 2 đến 4 giờ để tổng kết những công việc vừa hoàn thành và lập kế hoạch cho phần việc tiếp theo. Hàng ngày, cả đội tham gia một cuộc họp ngắn từ 5 đến 10 phút thảo luận về công việc trong ngày. Ngoài hai kiểu họp chính thức này, từng thành viên tự lập kế hoạch làm việc cho mình. Hình thức “tự tổ chức” (self-organization) là một đặc điểm chung của các dự án theo triết lí Agile.
Trong một dự án phần mềm, những hiểu biết về sản phẩm luôn được nắm giữ bởi nhiều cá nhân. XP thừa nhận thực tế này bằng cách tạo ra một nhóm làm việc hỗn hợp với đầy đủ các vai trò cần thiết. Một đội dự án XP thường bao gồm các thành viên sau đây:
Đại diện khách hàng (onsite customer): Chịu trách nhiệm xác định các yêu cầu (requirement) cho phần mềm. Công việc quan trọng nhất của người này là lập kế hoạch. Khi bắt đầu dự án, đại diện khách hàng xác định các tính năng (feature/story) cần có của phần mềm, tìm cách nhóm các tính năng này thành các phần nhỏ có thể phát triển và bàn giao lần lượt và định ra lịch trình bàn giao từng phần. Trong quá trình thực hiện dự án, đại diện khách hàng nhận phản hồi từ các thành viên khác và điều chỉnh kế hoạch cho phù hợp.
Nhiệm vụ thứ hai của đại diện khách hàng là giúp các lập trình viên hiểu các yêu cầu chi tiết cho sản phẩm. Trong các dự án XP, tài liệu đặc tả (SRS) chỉ là công cụ trợ giúp cho đại diện khách hàng mà thôi. Người này sẽ đóng vai trò một tài liệu “sống”, luôn sẵn sàng trả lời các câu hỏi từ các lập trình viên.
Đại diện khách hàng không nhất thiết phải là khách hàng thật mà chỉ cần là một thành viên hiểu rõ các yêu cầu của phần mềm. Thực nghiệm cho thấy giữa hai nhóm có chất lượng lập trình viên tương đương nhau thì nhóm có sự tham gia của khách hàng tạo ra sản phẩm tốt hơn hẳn. Nếu khách hàng không thể đến ngồi ở văn phòng của bạn, hãy đưa đội dự án của bạn đến ngồi cùng với khách hàng!
Thực nghiệm cũng cho thấy tỉ lệ hai đại diện khách hàng cho ba lập trình viên là phù hợp. Tất nhiên, tỉ lệ này phụ thuộc vào độ phức tạp của sản phẩm. Hãy ghi nhớ rằng khối lượng công việc của các đại diện khách hàng là rất lớn bởi họ luôn phải “chạy trước” các lập trình viên. (more…)

Ba loại user ID của một tiến trình

Một tiến trình (process) trong Unix sở hữu 3 user ID sau đây:

Real user ID (user ID thật): Là user ID của người khởi động tiến trình.
Effective user ID (user ID hiệu dụng): Là một loại user ID được dùng trong những trường hợp sau đây:

• Khi tiến trình truy nhập một file, hệ điều hành kiểm tra xem effective user của tiến trình có quyền truy nhập file hay không.
• Khi tiến trình tạo mới một file, hệ điều hành lấy effective user của tiến trình làm chủ sở hữu (owner) của file.
• Khi tiến trình muốn gửi tín hiệu đến một tiến trình khác, hệ điều hành kiểm tra xem effective user của tiến trình gửi có quyền gửi tín hiệu hay không.

Saved user ID: Là giá trị của effective user ID được lưu trong bảng các tiến trình (process table). Mỗi tiến trình có một vùng dữ liệu tương ứng trong bảng các tiến trình. Saved user ID đóng vai trò như một bản backup cho effective user ID, được dùng khi tiến trình muốn quay lại effective user ID ban đầu.

Tương ứng với 3 loại user ID này là ba loại group ID: real group ID, effective group ID và saved group ID.

Vì sao cần effective user ID?
Effective user là một cơ chế quản lí truy nhập của Unix (access control hay authorization). Xem ví dụ sau đây: Alice là một kế toán và cô ta cần có quyền thay đổi file dữ liệu kế toán account_data của công ty. Tuy nhiên, để đảm bảo tính toàn vẹn dữ liệu, Alice không được phép thay đổi dữ liệu kế toán một cách thủ công mà phải thông qua một chương trình tên là account_program. Như vậy:

• Alice không có quyền ghi đối với account_data.
• account_program có quyền ghi đối với account_data.
• Alice có quyền chạy account_program.

Tuy nhiên, trong Unix chỉ có người dùng mới được coi là các chủ thể được cấp quyền sử dụng tài nguyên. Bởi vậy, giải pháp trong Unix là tạo ra một người dùng có quyền ghi đối với account_data, thiết lập effective user ID của account_program bằng ID của người dùng đó và trao cho Alice quyền chạy account_program. (more…)

Nguồn: The Art of Agile Development của J Shore & S Warden. Phần tiếp theo của: Agile Development: Giới thiệu chung

Extreme Programming (gọi tắt là XP, một số tài liệu tiếng Việt dịch là “lập trình cực hạn”) là một phương pháp phát triển phần mềm tuân thủ triết lí Agile. Trong số các phương pháp Agile thì XP là một trong các phương pháp hoàn thiện nhất và nhận được nhiều sự quan tâm nghiên cứu nhất. Một số phương pháp Agile khác là Scrum và Agile Unified Process (AUP).

Vòng đời của một dự án XP

Các hoạt động cơ bản của một dự án phần mềm là:

1. Lập kế hoạch (planning).
2. Phân tích yêu cầu (analysis).
3. Thiết kế (design).
4. Lập trình (programming).
5. Test.
6. Bàn giao sản phẩm (deploy).

Mô hình cổ điển thác nước (waterfall) sắp xếp các hoạt động này theo thứ tự tuyến tính, đầu ra của hoạt động này là đầu vào của hoạt động tiếp theo. Các mô hình lặp (iterative – chẳng hạn mô hình tăng trưởng hay mô hình tiến hóa) sắp xếp các hoạt động này xen kẽ lẫn nhau.

Hình 1: (a) Mô hình thác nước. (b) Mô hình lặp

XP hoạt động theo mô hình lặp. Sản phẩm được chia ra thành các phần tăng trưởng nhỏ, mỗi phần được phát triển trong vòng một hoặc vài tuần gọi là một vòng lặp (iteration). Với mỗi phần tăng trưởng, đội dự án thực hiện tất cả các hoạt động: lập kế hoạch, phân tích, thiết kế, lập trình, test và bàn giao. Ưu điểm của mô hình này là đội dự án nhanh chóng nhận được phản hồi từ phía khách hàng. Những thay đổi cần thiết sẽ được áp dụng ngay trong lần lặp tiếp theo. (more…)

Link: http://www.se-radio.net/
Nội dung: Các bài nói chuyện về những chủ đề thú vị của Công nghệ phần mềm dưới dạng các chương trình phát thanh. Có transcript và có thể download dưới dạng file mp3.
Một số chủ đề đáng chú ý:

Roles in Software Engineering

UML

The Semantic Web

Introduction to AOP

10 years of Agile Experiences

Software Components

Interview Erich Gamma

Introduction to Embedded Systems

Internals of GCC

eXtreme Programming

Nguồn: The Art of Agile Development by J Shore & S Warden.

Agile là gì?

Agile là một triết lí (philosophy) cho việc phát triển phần mềm. Nói cách khác, đó là một cách “tư duy” về các dự án phần mềm. Các triết lí của Agile được cụ thể hóa bởi một số phương pháp phát triển phần mềm (method), chẳng hạn như Extreme Programming (XP) hay Scrum, gọi tắt là các phương pháp Agile.

Mỗi phương pháp Agile bao gồm một tập hợp các quy tắc (pratice), chẳng hạn quy tắc về sử dụng công cụ quản lí mã nguồn, quy tắc về các chuẩn lập trình hay quy tắc trình diễn sản phẩm hàng tuần cho khách hàng.

Triết lí Agile được đưa ra trong một bản tuyên ngôn (manifesto) gồm 4 điểm và được làm rõ hơn bởi 12 quy tắc.

Vì sao chúng ta cần Agile?

Theo quan niệm truyền thống, một dự án phần mềm được coi là thành công khi sản phẩm được giao đúng hạn, trong ngân sách cho phép và làm đúng yêu cầu của khách hàng. Trên thực tế, nhiều dự án thỏa mãn tất cả các tiêu chí này nhưng rút cuộc vẫn bị coi là thất bại bởi phần mềm làm ra không được người dùng ưa thích, hoặc không mang lại nhiều lợi ích cho các cá nhân, tổ chức sử dụng chúng.

Ngoài các yếu tố truyền thống nói trên, một dự án phần mềm chỉ được coi là thành công khi thỏa mãn ba tiêu chí: Thành công ở mức cá nhân, thành công về mặt kĩ thuật và thành công ở mức công ty. Thành công ở mức cá nhân giúp kích thích các thành viên trong nhóm. Thành công về kĩ thuật đảm bảo khả năng bảo trì và tiến hóa của sản phẩm. Vị trí của nhóm sẽ được bảo đảm nhờ các thành công mà nhóm mang lại cho công ty. Các phương pháp Agile giúp cho dự án phần mềm đạt được ba thành công này.

(more…)

Khi học Java, chúng ta thường bắt gặp những chương trình đơn giản về animation trong các sách dạy AWT và Swing, chẳng hạn như chương trình sau đây:

import java.awt.*;
import javax.swing.*;
 
public class Animation1 {
 
  public static void main( String[] args ) {
 
     Animation1 gui = new Animation1();
     gui.go();
 
  }
 
  private void go() {
 
     JFrame frame = new JFrame();
     frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
 
     panel_ = new MyPanel();
     frame.getContentPane().add( panel_, BorderLayout.CENTER );
 
     frame.setSize( 500, 500 );
     frame.setVisible( true );
 
     for( int i = 0; i < 400; i++ ) {
 
        x_++;
        y_++;
 
        panel_.repaint();
 
        try {
          Thread.sleep( 10 );
        } catch( Exception ex ) { }
 
     }
 
  }
 
  class MyPanel extends JPanel {
 
     public void paintComponent( Graphics g ) {
 
         g.setColor( Color.white );
         g.fillRect( 0, 0, this.getWidth(), this.getHeight() );
 
         g.setColor( Color.green );
         g.fillOval( x_, y_, 40, 40 );
 
     }
 
  }
 
  private JPanel panel_;
  private int x_ = 0;
  private int y_ = 0;
 
}

Chương trình này vẽ ra một vòng tròn trên một panel, tính toán lại tọa độ của nó rồi gọi repaint() để vẽ lại vòng tròn. Phương thức repaint() yêu cầu các component trên frame tự vẽ lại.Thao tác vẽ lại liên tục với các vị trí khác nhau sẽ tạo ra cảm giác vòng tròn chạy trên panel. Câu lệnh Thread.sleep(10) làm giảm tốc độ di chuyển của vòng tròn giúp người dùng dễ theo dõi.

Chúng ta thử sáng tạo thêm một chút bằng cách thêm vào frame một button dùng kể kích hoạt animation (học event handler và inner class luôn). Animation sẽ được kích hoạt khi người dùng ấn nút “Start animation”. Chương trình được cải tiến như sau: (more…)

Khi đã quen viết code trên vi/vim rồi thì chuyển sang editor khác thật khó chịu. Phiền hà nhất là các thao tác di chuyển con trỏ (phải dùng các phím mũi tên lên xuống rất mất thời gian), xóa một từ hoặc một dòng (phải giữ Backspace mỏi cả tay), nhảy giữa các từ…Tóm lại với những ai đã quen lập trình trên vi/vim thì việc phải chuyển sang các IDE khác sẽ không khác gì cực hình.

Giải pháp cho vấn đề này là cài đặt vim plugin cho IDE đang sử dụng. Một IDE đang được sử dụng rộng rãi là NetBeans. Để cài đặt vim plugin cho NetBeans, vào link dưới đây để tải về file cài đặt:

http://sourceforge.net/projects/viex/

Giải nén để nhận được file start-module-myvim.nbm. Từ menu của NetBeans, chọn Tools->Plugins->Downloaded->Add Plugins rồi chọn file start-module-myvim.nbm. Chúng ta sẽ thấy biểu tượng của vim nằm bên cạnh các icon khác như trong hình dưới đây. (Chú ý hình dáng của con trỏ, chúng ta đang ở chế độ lệnh của vim).

Bây giờ thì chúng ta đã có thể tận hưởng sự tiện lợi trong việc viết code bằng vim kết hợp với những tính năng phức tạp cung cấp bởi NetBeans. Tuy nhiên, plugin này vẫn chưa hỗ trợ một số thao tác edit trong vim như

- Không tự động indent khi xuống dòng bằng phím o.

- Không hỗ trợ shift-o

- Không hỗ trợ ctrl-r (redo).

- Không hỗ trợ xoá nhiều từ liền nhau (d 2 w, d 3 w, d $,…)

Tuy nhiên với những tính năng hiện có của plugin này thì công việc lập trình trên NetBeans đã trở nên thú vị hơn rất nhiều. Hi vọng những khiếm khuyết nói trên sẽ được khắc phục trong những phiên bản sau.

Bài viết này trình bày những mô hình phát triển phần mềm cơ bản.

Một dự án phát triển phần mềm thường trải qua các hoạt động sau đây:

- Phân tích yêu cầu.

- Thiết kế và lập trình.

- Test.

- Bảo trì.

Mỗi mô hình phát triển phần mềm đưa ra một cách tổ chức sắp xếp khác nhau của các hoạt động này.

1. Mô hình thác nước (waterfall)

Đây là mô hình phát triển phần mềm cổ điển nhất. Mô hình này đề nghị các hoạt động được tiến hành như các giai đoạn tách biệt, giai đoạn sau sẽ không bắt đầu chừng nào giai đoạn trước chưa hoàn thành. Sản phẩm đầu ra của giai đoạn trước trở thành đầu vào của giai đoạn sau.

Những mũi tên ngược từ dưới lên trên cho thấy những sai lầm ở giai đoạn trước có thể được phát hiện ở giai đoạn sau và đòi hỏi việc quay ngược lên để làm lại giai đoạn trước. Tuy nhiên ,hoạt động quay lui này chỉ nên được coi là các ngoại lệ mà thôi.

Mô hình thác nước có ưu điểm là dễ quản lí. Đây chính là mô hình ưa thích của các nhà quản lí dự án. Thời gian hoàn thành dự án thường được dự báo với độ chính xác hơn so với các mô hình khác. Các tài liệu đầu ra của từng giai đoạn cũng được xây dựng đầy đủ và hệ thống hơn. Tuy nhiên mô hình này có một số nhược điểm lớn là:

- Mô hình đòi hòi một bản yêu cầu (requirement) đầy đủ và chính xác từ phía khách hàng. Yêu cầu này hiếm khi đạt được bởi khách hàng ít khi xác định được chính xác họ muốn gì ở ngay giai đoạn đầu của dự án, sở thích của họ cũng thay đổi khá thường xuyên. Việc làm lại các giai đoạn ban đầu để đáp ứng sự thay đổi của khách hàng thường mất rất nhiều công sức và phá vỡ cấu trúc của phần mềm.

- Khách hàng cần phải kiên nhẫn. Họ chỉ được tham gia vào dự án ở giai đoạn phân tích yêu cầu và test mà thôi. Ngoài ra, sản phẩm sẽ chỉ được bàn giao khi tất cả các công việc liên quan đã được hoàn thành.

Mô hình thác nước chỉ nên được sử dụng khi đội dự án đã có kinh nghiệm, yêu cầu từ khách hàng được xác  định rõ ngay từ đầu và ít có khả năng thay đổi. Hiện nay, mô hình thác nước vẫn được sử dụng rộng rãi do tính gần gũi với các mô hình phát triển trong các ngành kĩ thuật khác.

(more…)

Lấy từ tài liệu tuyệt vời này về linked list của trường Stanford mà tôi muốn khái lược lại bằng những đoạn mã trong đó. Danh sách liên kết (linked list) là một kiến thức rất cơ bản của cấu trúc dữ liệu và giải thuật. Hiểu được những ưu và khuyết điểm của nó sẽ giúp chúng ta hiểu các vấn đề về thời gian, không gian bộ nhớ và cấu trúc dữ liệu nói chung. Hơn thế nữa học về linked list là một cách rất tốt để hiểu về pointer. Những bài toán về linked list là sự kết hợp rất “đẹp” giữa giải thuật (algorithms) và các phép toán với con trỏ (pointer manipulation). Linked list là cách các lập trình viên luyện tập để thực sự hiểu về pointer và bạn sẽ thấy ngôn ngữ C “đẹp” vô cùng Hãy tham khảo thêm tài liệu của Stanford để hiểu kỹ thêm (Highly recommend!)

(more…)