Categories
Web Programming

MySQL ngoại truyện

Cuối tuần vừa rồi mới vừa clear gần 50% table trong database của Teamcrop, đây là những table của những tính năng không còn sử dụng và đã trải qua thời gian deprecated (chờ xử trảm), thấy có lẽ nên viết một bài về database nhân dịp đầu năm mới cũng như khai blog 2019.

Cũng giống như nhiều đàn anh, đàn chị thời nay, mình đã sớm tiếp xúc với PHP từ 2003 khi xu hướng diễn đàn lớp, diễn đàn trường, diễn đàn vớ vẫn nở rộ. Những đoạn code đầu tiên là những mod diễn đàn viết bằng PHP, cũng như những câu truy vấn database MySQL đầu tiên cũng xuất hiện từ thời điểm này. Bài viết mang tính chất cổ súy MySQL nói riêng (RDBMS nói chung) nên nếu ai không biết nó là gì thì nên tìm hiểu hoặc làm với nó ít ít rồi hẳn đọc tiếp và đối tượng bài viết có thể là DB Administrator hoặc Developer có nhiệm vụ làm việc với MySQL, hầu hết chúng ta – web developer cũng là những người maintain database schema.

Làm việc với MySQL hơn 15 năm (và hiện nay vẫn chỉ tin và dùng MySQL), nên ít nhiều có chút kinh nghiệm khi sử dụng cũng như hình thành những quy trình, đường lối cho cá nhân và team khi tham gia xây dựng dự án. Mỗi khi có Web developer mới tham gia vào công ty thì những kiến thức này lại được truyền đạt, tuy nhiên đó giờ vẫn chưa có một tài liệu cụ thể nên bài blog này cũng là một phần phục vụ việc training này.

Tại sao lại gọi là ngoại truyện?

Hầu hết những gì mình chia sẻ ở đây có thể các bạn sẽ rất ít thấy đề cập ở các sách hay giáo trình về MySQL. Thậm chí có những thứ có thể được coi là đi ngược với những gì bạn biết về MySQL.

Để dễ chia sẻ thông tin, mình sẽ tách thành 3 giai đoạn khi các bạn làm việc với MySQL, đó là trước khi có dữ liệu (data), trong khi có dữ liệu và khi không còn dữ liệu. Ở mỗi giai đoạn sẽ có những kinh nghiệm khác nhau và phù hợp với ngữ cảnh để mọi người tiện theo dõi.

1. Trước khi có dữ liệu

Theo quan sát và kinh nghiệm, rất nhiều bạn khá hời hợt và xem thường giai đoạn này, tức giai đoạn phân tích và thiết kế database, hay nói 1 cách dân dã là tạo bảng (CREATE TABLE..). Rất nhiều vấn đề phát sinh bởi việc thiết kế bảng hời hợt, thậm chí là thiết kế sai, kéo theo technical debt sẽ ngày càng lớn và thậm chí là phải bỏ cả tính năng / bảng đang sử dụng để refactoring lại thành tính năng mới, tạo table mới và migrate dữ liệu từ bảng cũ sang bảng mới.

Ngoài việc thiết kế bảng đúng, duy trì tính dễ hiểu (understandable), dễ bảo trì (maintainable) và đồng nhất (consistent) cũng là một số yếu tố luôn được cân nhắc khi thiết kế một table. Bên dưới là một số “guideline” mà ai muốn tham gia vào team của Tuấn sẽ được training và bắt buộc phải theo:

Về database:

  • Trong một Database, tất cả tên bảng phải có tiền tố giống nhau (prefix). Ví dụ: crp_, abc_…
  • Để tăng khả năng chuyển đổi DBMS và tương thích với các hệ SQL, không sử dụng các khái niệm “phức tạp” của database như Store procedure, View, Constraint
  • Không sử dụng khái niệm ràng buộc khóa chính, khóa ngoại cài đặt trong DBMS. Chỉ sử dụng khái niệm này trong quá trình trao đổi thông tin giữa các developer và thiết kế bảng.
  • Áp dụng kiến trúc Microservices để chia nhỏ database theo từng domain/context riêng để giúp giảm tải chung cho toàn Database. Ví dụ: Mỗi service sẽ cần 1 kiến trúc / server DB riêng để vận hành riêng biệt.
  • Những phiên bản MySQL khác nhau sẽ có một số config khác nhau kéo theo những lỗi không ngờ tới khi nâng cấp phiên bản.
  • Không sử dụng docker / VM cho MySQL Server.

Về bảng (table):

  • Khi đặt tên bảng, tên cột thì không sử dụng chữ HOA hoặc ký tự đặc biệt. Cho phép a-z, 0-9 và underscore (gạch dưới “_”).
  • Tên bảng luôn là tiếng anh và sử dụng từ số ít. Ví dụ: crp_product, crp_news
  • Nếu tên bảng là tổ hợp nhiều từ, thì mỗi từ cần cách nhau gạch dưới (underscore). Ví dụ: abc_product_category, abc_order_detail
  • Trừ các cột khóa ngoại, các cột dữ liệu riêng của một bảng luôn có tiền tố giống nhau, và tổng hợp từ chữ cái đầu tiên của tên bảng (không bao gồm tiền tố database). Ví dụ: bảng abc_product_category thì các cột của bảng này phải có tiền tố là “pc_”, như “pc_id”, “pc_name”..
  • Tên cột ngoài tiền tố bảng thì là các từ tiếng anh, số ít và không có khoảng cách, các từ phải viết liền nhau. Ví dụ: p_countview, p_datecreated..
  • Khóa chính của một cột trong bảng luôn là tiền tố của bảng + “id”. Ví dụ: “pc_id”, “p_id”, “n_id”..
  • Khóa ngoại của một bảng sẽ được nằm đầu tiên trong danh sách cột của bảng này, trước cả cột khóa chính. Tên cột khóa ngoại phải giữ nguyên tên cột mà nó làm khóa chính trong bảng của nó. Ví dụ: u_id là User ID và là khóa chính trong bảng “abc_user”, thì khi làm khóa ngoại trong bảng “abc_product” thì nó vẫn là cột “u_id”.
  • Collation của database / table / text column là “utf8_general_ci”
  • Table luôn có engine mặc định là MyISAM (tối ưu cho SELECT dữ liệu)
  • Có thể tận dụng engine MEMORY để tối ưu truy vấn vì toàn bộ dữ liệu của table loại MEMORY sẽ nằm trong RAM thay vì ổ cứng.

Về kiểu dữ liệu của cột trong bảng:

  • Kiểu dữ liệu của khóa ngoại và khóa chính phải trùng khớp nhau (data type & data length)
  • Không sử dụng kiểu dữ liệu DATETIME trừ trường hợp lưu ngày sinh.
  • Không sử dụng kiểu dữ liệu ENUM trong trường hợp cần lưu theo logic này, chỉ cần lưu INT (11) hoặc SMALLINT(3) và trong Model của code sẽ khai báo constant.
  • Tất cả cột thời gian đều lưu Timestamp và kiểu dữ liệu INT(10).
  • Các cột dữ liệu thời gian luôn là những cột nằm cuối cùng của bảng. Hầu hết các bảng luôn có cột: datecreated (ngày tạo) và datemodified (ngày cập nhật).
  • Trường IP Address luôn là BIGINT (20), và sử dụng hàm ip2long() và long2ip() của PHP để encode/decode.
  • Giá trị tiền nên là DECIMAL (18), tốt nhất là DECIMAL (18,4)
  • Cẩn thận khi thiết kế dữ liệu cho việc lưu ký tự emoji.

Việc tuân thủ các guideline này sẽ giúp rất nhiều trong việc debug cũng như đoán được nguồn gốc, xuất xứ của 1 cột khi làm việc, và tạo sự nhất quán trong toàn team để dễ trao đổi, debug. Ví dụ bên dưới là thiết kế cho table user, product.

CREATE TABLE `crp_user` (
  `u_id` int(11) NOT NULL,
  `u_email` varchar(128) NOT NULL,
  `u_password` text NOT NULL,
  `u_ipaddress` bigint(20) NOT NULL,
  `u_status` smallint(3) NOT NULL,
  `u_datecreated` int(10) NOT NULL,
  `u_datemodified` int(10) NOT NULL,
  `u_datelastloggedin` int(10) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;


CREATE TABLE `crp_product` (
  `u_id` int(11) NOT NULL,
  `p_id` int(11) NOT NULL,
  `p_name` varchar(255) NOT NULL,
  `p_description` text NOT NULL,
  `p_price` decimal(18,4) NOT NULL,
  `p_status` smallint(3) NOT NULL,
  `p_ishot` tinyint(1) NOT NULL,
  `p_datecreated` int(10) NOT NULL,
  `p_datemodified` int(10) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Với những tiêu chí trên thì đảm bảo team bạn sẽ dễ dàng làm việc trên các bảng dữ liệu của các dự án.

2. Trong khi có dữ liệu

Sau quá trình thiết kế bảng hoàn tất và đã được đưa lên hệ thống, tính năng cũng đã được chạy và bạn bắt đầu có dữ liệu, không gì tuyệt hơn là có dữ liệu. Đến giai đoạn này, việc duy trì cho hệ thống đang chạy là ưu tiên hàng đầu, và một số chia sẻ ở giai đoạn này cũng nhằm giúp việc đảm bảo hệ thống DB không bị gián đoạn.

  • Không thay đổi tên cột trong bất kì tình huống nào.
  • Không xóa cột trong bất kì tình huống nào.
  • Chỉ đổi kiểu dữ liệu cột sang cùng loại và sang dung lượng lớn hơn. Ví dụ cho phép đổi từ VARCHAR(50) -> VARCHAR (100), SMALLINT(3) -> INT (11).
  • Cần áp dụng replicate database (Master / Slave) dữ liệu để giảm tải. Để tránh rắc rối không cần thiết, chỉ nên sử dụng 1 Master và có thể cho phép nhiều Slave.
  • Trong bất kì tình huống nào liên quan đến vấn đề đồng bộ giữa Master & Slave và liên quan đến lỗi đồng bộ binlog, tốt nhất là disable replicate, chỉ sử dụng Master, tìm ra nguyên nhân cụ thể để khắc phục và phần lớn vấn đề liên quan đến networking, ổ cứng mạng, tắt bất tử.
  • Lưu ý “Delay Gap” (thời gian bất đồng bộ dữ liệu) giữa Master và Slave(s).
  • Đồng bộ dữ liệu vào thời gian ít truy cập nhất
  • Backup dữ liệu định kì và upload lên một hệ thống / server khác hệ thống đang chạy. Bên mình kết hợp S3cmd để đẩy file backup sql lên Amazon S3 để backup mỗi ngày.
  • Tuyệt đối lưu ý đến max connection mặc định của MySQL là 150 để tránh lỗi MySQL connection.
  • Nếu cài đặt max connection lớn thì lưu ý việc MySQL server sẽ block IP do cơ chế security.
  • Hạn chế đến mức tối đa việc sử dụng JOIN TABLE để tăng khả năng refactoring, migration cũng như giảm thiểu vấn đề về performance / SQL execution. Chỉ JOIN khi đây là hoạt động bất khả kháng và không còn phương án nào tối ưu hơn cho việc truy vấn (tìm kiếm).
  • Không sử dụng JOIN cho các entity không liên quan đến nhau hoặc cùng 1 domain/service. VD: không join user & comment, product & comment..Có thể JOIN order & order detail.
  • Luôn có Cache layer ở tầng Application (Redis, memcached) để hạn chế truy vấn vào Database cũng như hỗ trợ việc hạn chế JOIN.

3. Khi dữ liệu không cần thiết

Hầu hết dự án nào cũng có những tính năng “không còn sử dụng” và có nhu cầu xóa bỏ luôn dữ liệu thì bạn cũng cần có những quy định cho việc này. Vì sao phải xóa dữ liệu? Theo thời gian, giữ liệu sẽ ngày một phình to, nếu vẫn cố giữ những dữ liệu không còn sử dụng thì sẽ kéo theo thời gian backup / migration / recovery lớn hơn, dẫn đến nhiều rủi ro tiềm ẩn không cần thiết, do đó, tốt nhất là xóa những gì không dùng. Hoặc nếu muốn giữ lại thì cũng nên tách data này sang 1 nơi mà không ảnh hưởng đến performance / rủi ro chung của toàn hệ thống.

Bên dưới là một số bước mà bên mình dùng để xóa dữ liệu, các bạn có thể tham khảo và áp dụng.

  • Bởi vì không có cài đặt ràng buộc tự động (Constraint) nên tầng Application cần có các tính năng (cronjob) tự động để xóa các dòng dữ liệu không cần thiết hoặc update các cột dữ liệu bị lỗi.
  • Đảm bảo các bảng cần xóa không được tham chiếu bởi bất kì tính năng nào. Nếu có tham chiếu thì cần đảm bảo tính năng này hiện đã không còn sử dụng.
  • Kiểm tra ngày cuối cùng mà bảng này có dữ liệu mới, hay modified date của bảng.
  • Không có bảng ngay mà chỉ đổi tên bảng và thêm tiền tố. Ví dụ: thêm OLD_, DEPRECATED_
  • Chờ tối thiểu 1 tháng -> 3 tháng và chỉ xóa các bảng có tiền tố định trước là sẽ xóa.
  • Hạn chế tối đa việc gõ tên bảng, nên copy tên bảng ra trước rồi copy vào CMD.
  • Khi xóa bảng thì không nên dùng MySQL Client / GUI để thao tác mà thông qua MySQL CLI và thực thi SQL mà thôi.
  • Theo dõi hệ thống support / CS tối thiểu 1 ngày để phát sinh những support ticket liên quan đến mất dữ liệu, lỗi tính năng do khách hàng report.

Trên đây là tất cả những quy trình, kinh nghiệm mà team mình áp dụng khi làm việc với MySQL. Hy vọng mọi người cũng có những quy trình để giúp bảo vệ dữ liệu tốt hơn và cải thiện quá trình lưu trữ và làm việc nhóm liên quan đến cấu trúc dữ liệu.

Categories
Technology Web Programming

Apitoy – Free Restful Documentation

Apitoy.com

Chắc hẳn là lập trình web thì mọi người đã từng một lần kết nối đến một hệ thống khác thông qua Web Service, có thể là SOAP, RESTful…Nội dung bài viết này mình sẽ chia sẻ với mọi người một số vấn đề và giải pháp mà mình đang gặp phải khi triển khai các Restful service.

Restful Documentation

Trong quá trình thiết kế Restful API, documentation (docs) cho API là một trong những thứ cực kỳ cần thiết để giúp bạn cũng như công ty, khách hàng dễ dàng làm việc trên API mà bạn thiết kế.

Docs API đơn giản có thể là các ghi chú, word, excel hoặc các SaaS base service để giúp tạo API nhanh chóng và tiện lợi hơn cũng như hỗ trợ làm việc nhóm hiệu quả hơn.

Đã thử dùng rất nhiều công cụ và nhiều phương tiện khác nhưng không có cái nào phù hợp nhu cầu nên đành tự phát triển một công cụ tạo docs API riêng cho mình, đơn giản và linh hoạt hơn, đó là Apitoy.com.

Cũng như hầu hết các công cụ SaaS based khác để làm Restful API Docs, Apitoy.com cũng cho phép tạo nhiều dự án, mỗi dự án sẽ có nhiều nhóm request (group). Mỗi request sẽ có quy định loại request (GET, POST, PUT..), tham số đầu vào, định dạng cũng như các thông tin request / response của một request.

Một số hình ảnh của Apitoy:

apitoy-zone
Danh sách Zone (Project)
Danh sách các Request của một zone.
Danh sách các Request của một zone.
Chỉnh sửa chi tiết một Request
Chỉnh sửa chi tiết một Request
Chi tiết một Request Docs
Chi tiết một Request Docs

Mock Server

Cũng như các lập trình viên thiết kế Restful API khác, việc dựng một Mock server từ một API Docs là một nhu cầu cực kỳ cần thiết để việc test cũng như tách biệt giữa web service consumer & service producer trong quá trình phát triển ứng dụng. Nhờ có Mock server mà phía frontend có thể có data giả (fake data) nhưng có cấu trúc đúng với cấu trúc của API thiết kế và sẽ không lệ thuộc vào backend phải hoàn thành API trước khi thử.

Apitoy có một tính năng rất thú vị và độc đáo là cho phép tự tạo một mock service dựa vào một request mà bạn đã thiết kế và response data (fake data) sẽ được auto-generate khi có request vào đúng mô tả request của bạn như đúng HTTP Method (GET, POST< PUT…), đúng URL…
Lưu ý là để mock service có thể chạy thì bạn bắt buộc phải tạo ít nhất 1 response cho request. Các snippet động “{{…}}” sẽ được bỏ khi xem docs và được thay thế khi có request để lấy mock data.

Apitoy hỗ trợ một số hình thức generate dữ liệu động sau:

Kiểu dữ liệu chuẩn

Nếu các giá trị có dạng “Integer”, “Float”, “String” thì sẽ được thay thế bằng các dữ liệu ngẫu nhiên tương ứng với kiếu giá trị như “100”, “3.14”, “Hello world”…

Faker Snippet

Apitoy có tích hợp thư viện https://github.com/fzaninotto/Faker để giúp bạn generate các dữ liệu ngẫu nhiên trông “thật” hơn ví dụ:

String{{phoneNumber}}: Thay thế bằng số điện thoại ngẫu nhiên
String{{email}}: thay thế bằng email ngẫu nhiên
Integer{{randomNumber}}: thay thế bằng một số ngẫu nhiên
Integer{{randomNumber:5}}: thay thế bằng một số ngẫu nhiên có 5 chữ số

Bạn có thể tham khảo website https://github.com/fzaninotto/Faker để biết tất cả các Snippet hỗ trợ trong Apitoy để generate các dữ liệu “giống thật” hơn.

Apitoy Snippet

Bên cạnh các snippet hỗ trợ từ thư viên Faker, apitoy còn cung cấp 2 snippet khác là “enum” và “repeat”.

– String{{enum:option1:option2:option3}}: chọn ngẫu nhiên một giá trị trong danh sách option. Ví dụ: Integer{{enum:0:1}}, String{{enum:”Yes”:”No”}}…

– {{repeat:repeat_id:repeat_count:repeat_seperator}}…{{/repeat:repeat_id}}: lặp lại một đoạn code được đánh dấu. Trong đó: “repeat_id” để đánh dấu đoạn code cần lặp, không có 2 đoạn repeat có cùng “repeat_id”. “repeat_count” số lần lặp lại của đoạn code bạn đánh dấu. “repeat_separator” ký tự phân cách giữa các lần lặp, mặc định là dấu phẩy “,”.

Ví dụ một đoạn code có đánh dấu cho Mock service:

{
    "total": Integer,
    "items": [
        {{repeat:item:2}}
        {
            "id": Integer{{randomNumber:5}},
            "internalid": String{{uuid}},
            "jobtitle": String{{sentence:3}},
            "phone": [
                {{repeat:phone:2}} String{{phoneNumber}} {{/repeat:phone}}
            ],
            "address": String{{streetAddress}},
            "isdeleted": Integer{{enum:0:1}},
            "datecreated": Integer{{unixTime}},
        }
        {{/repeat:item}}
    ]
}

Khi có request vào, server sẽ trả về dữ liệu sau:

{
    "total": 2834983,
    "items": [

        {
            "id": 86279,
            "internalid": "fa25b791-e185-37c1-8830-37ad177e6832",
            "jobtitle": "Nisi architecto laudantium aperiam.",
            "phone": [
                 "499.613.9008" , "(616)119-4152x20704" 
            ],
            "address": "730 Alene Wall",
            "isdeleted": 1,
            "datecreated": 264592903,
        }
        ,
        {
            "id": 90095,
            "internalid": "140abd91-3aba-3562-9dc1-d8f9ce275444",
            "jobtitle": "Tempore et ad quisquam.",
            "phone": [
                 "1-275-835-9601x690" , "05349335502" 
            ],
            "address": "796 Hauck Garden Suite 358",
            "isdeleted": 0,
            "datecreated": 364877373,
        }

    ]
}

——

Hy vọng bài viết này sẽ giúp các bạn có cái nhìn chi tiết hơn về cách triển khai một hệ thống Restful API.

Categories
Business PHP Tech Startup Web Programming

Reader.vn (2011 – 2014)

readervn-mang-xa-hoi-sach-viet-nam-2011-2014

“Lùi một bước trời cao đất rộng” là câu mình hay nói với mọi người khi gặp một vấn đề khó, bởi khi có một góc nhìn rộng hơn, với nhiều thông tin hơn dù cho phải lùi lại một bước thì cũng đáng phải làm vì điều này sẽ giúp ích được nhiều khi ra các quyết định. Reader.vn là một dự án “thú cưng” của mình từ 2011, đến này đã chạy hơn 3 năm 6 tháng và có trên 40,000 thành viên và hơn 50,000 đầu sách. Tuy nhiên, do hiện tại có một số “sóng gió” nên mình đóng cửa mạng xã hội này để chờ thời cơ ra mắt một Reader.vn mới.

Categories
PHP Web Programming

Xây dựng hệ thống load balancer cho web

load-balancer

Dạo này với xu hướng mọi người bắt đầu làm Tech startup ngày càng nhiều (cụ thể là web & app startup), tuy nhiên do chưa có kinh nghiệp triển khai kiến trúc server nên đôi khi các bạn đâu đó sẽ gặp tình huống khóc dỡ là web quá nhiều lượt truy cập (có thể do chạy campaign hoặc ngày ra mắt…) làm cho web bị treo vì không trở tay kịp.

Mình viết bài này với hy vọng các anh chị em tech startup hoặc anh chị em IT chịu trách nhiệm lo về phần scaling cho website có một chút thông tin về xây dựng hệ thống Load balancer phòng trường hợp server quá tải.

Categories
Web Programming

Làm “đạo diễn web” trong 7 ngày – Ngày 5,6,7: Hoàn tất

7-ngay-lam-dao-dien-ngay-567-hoan-tat

Sau chuyến đi chơi dài ngày thì hôm nay mình viết nốt bài cuối trong loạt bài viết chia sẻ cách thức nhanh chóng lên kế hoạch và triển khai website trong thời gian ngắn nhất và đảm bảo các quy trình thiết kế, mô hình và triển khai.

Sau 4 bài trước, hiện giờ chắc bạn đã có trong tay website để chuẩn bị quá trình triển khai website đến cho người dùng. Các ngày cuối cùng mặc dù không nặng phần kỹ thuật và thiết kế, nhưng nếu không cẩn thận và chuẩn bị chu đáo thì việc release dự án của bạn sẽ dễ dàng gặp nhiều trắc trở và không thuận buồm xuôi gió.

Categories
Web Programming

Làm “đạo diễn web” trong 7 ngày – Ngày 4: Dựng phân đoạn

7-ngay-lam-dao-dien-ngay-4-dung-phan-doan

Đến hẹn lại lên, hôm nay mình sẽ viết về ngày thứ 4 trong chuỗi 7 ngày làm đạo diễn web. Sau khi có được kịch bản, diễn viên cũng đã biết mình phải diễn gì, sân khấu đã có thiết kế, việc tiếp theo là mang các diễn viên lại và bắt đầu tập diễn các cảnh trong vở kịch để đem đến một vở kịch hoàn chỉnh cho khán giả.

Qua các ngày trước, mình đã có được bảng các tính năng, kèm theo các thiết kế và đã chuẩn bị sẵn HTML, CSS để ráp giao diện thực tế trong code, tức là phần Front-end. Hôm nay, chúng ta sẽ tiến hành hoàn tất phần Front-end và các công đoạn cuối cùng của việc…coding.

Categories
Web Programming

Làm “đạo diễn web” trong 7 ngày – Ngày 3: Thiết kế sân khấu

7-ngay-lam-dao-dien-ngay-3-thiet-ke-san-khau

Chào mọi người, vậy là cũng đã một tuần trôi qua kể từ bài trước nói về xây dựng Model cho website của bạn. Trong bài này, mình sẽ nói về “Thiết kế sân khấu” cho vở kịch web của bạn.

Dù cho bạn có sở hữu một kịch bản tuyệt vời, dàn diễn viên khủng với các kỹ năng diễn xuất đỉnh nhưng nếu không có một sân khấu với các thiết kế, bố trí hợp lý và logic, nổi bật lên nội dung vở kịch cũng như làm nền cho các diễn viên biểu diễn thì vở kịch cũng sẽ khó mà thành công. Vở kịch web của bạn cũng không ngoại lệ.

Categories
Web Programming

Làm “đạo diễn web” trong 7 ngày – Ngày 2: Nghệ sỹ

7-ngay-lam-dao-dien-ngay-2-nghe-sy

Mọi người nghỉ lễ chắc vui vẻ nhỉ, thế là đã bắt đầu tuần làm việc mới. Hôm nay, mình sẽ chia sẻ tiếp với các bạn bài thứ 2 trong loạt bài làm “đạo diễn web” trong 7 ngày. Bài này sẽ nói về “nghệ sỹ”. Là một đạo diễn, sau khi có bản phác thảo nhân vật trong vở kịch thì việc tiếp theo là tìm kiếm các “nghệ sỹ” sẽ biểu diễn.

Categories
Web Programming

Làm “đạo diễn web” trong 7 ngày – Ngày 1: Kịch bản

7-ngay-lam-dao-dien-ngay-1-kich-ban

Có nhiều bạn mới (hoặc cũ) trong nghề (web) sẽ luôn có những thắc mắc về quy trình làm 1 dự án web hoàn chỉnh. Và cũng có nhiều người thắc mắc là mình ra nhiều dự án web trong thời gian rất ngắn (vài ngày đến 1 tuần) nên mình dự định viết một loạt bài về “các bước” xây dựng một dự án web hoàn chỉnh cho tới khi launch mà mình luôn áp dụng cho các dự án nhỏ và nhanh của mình.

Nếu không có các bước cụ thể và theo thói quen thì việc xây dựng một website đối với các bạn sẽ rất khó khăn và mất thời gian, đặc biệt là với các bạn mới làm web. Mình đặt tên cho loạt bài của mình (7 bài) là làm “đạo diễn web” trong 7 ngày. Trong mỗi bài, mình sẽ nói về một bước cụ thể khi làm web và sau 7 ngày thì các bạn có thể theo đúng tiến độ để cho ra 1 website hoàn chỉnh và có thể launch (ít ra cũng là beta ^^).

Categories
Web Design Web Programming

Góp ý về việc phát triển trang Hỏi Đáp

question-and-answer-website

Chào các anh chị em đồng đạo, nhận thấy các bạn tham gia trong mảng lập trình và thiết kế web ngày càng đông đảo và nhu cầu hỏi đáp, chia sẻ, trao đổi thông tin ngày càng tăng, Tuấn có ý định làm 1 trang hỏi đáp nho nhỏ để các bạn có thể chia sẻ, giải đáp các thắc mắc trong quá trình lập trình và thiết kế web cũng như xây dựng một site hỏi đáp bằng tiếng Việt để anh em ta có nơi để giao lưu, học hỏi.

Các tính năng thì có thể dựa trên một số tính năng cốt lõi của Stackoverflow để làm theo như hệ thống hỏi đáp, voting, reputation…