Home Blog Page 180

PHPExcel – Import và Export xử lý Excel

phpexcel

Đôi lúc chúng ta sẽ cần phải truy – xuất dữ liệu bằng file Excel như: xuất dữ liệu thống kê ra cho người dùng, hoặc import nhiều dữ liệu từ file excel vào Database. Thư viện được sử dụng nhiều nhất hiện nay là PHPOffice/PHPExcel.

Đọc và ghi file excel bằng PHP thuần

Đọc file excel

Các bạn tải file data mẫu excel này mà mình đã tạo sẵn, có nội dung hình dưới và đặt nó nằm cùng cấp với thư mục Classes:

phpexcel

Tiếp theo, bạn sẽ tiến hành đọc file này bằng cách tạo thêm 1 file mới tên là docfile.php cùng cấp với thư mục Classes, và gõ theo nội dung bên dưới:

<?php
//  Include thư viện PHPExcel_IOFactory vào
include 'Classes/PHPExcel/IOFactory.php';

$inputFileName = 'product.xlsx';

//  Tiến hành đọc file excel
try {
    $inputFileType = PHPExcel_IOFactory::identify($inputFileName);
    $objReader = PHPExcel_IOFactory::createReader($inputFileType);
    $objPHPExcel = $objReader->load($inputFileName);
} catch(Exception $e) {
    die('Lỗi không thể đọc file "'.pathinfo($inputFileName,PATHINFO_BASENAME).'": '.$e->getMessage());
}

//  Lấy thông tin cơ bản của file excel

// Lấy sheet hiện tại
$sheet = $objPHPExcel->getSheet(0); 

// Lấy tổng số dòng của file, trong trường hợp này là 6 dòng
$highestRow = $sheet->getHighestRow(); 

// Lấy tổng số cột của file, trong trường hợp này là 4 dòng
$highestColumn = $sheet->getHighestColumn();

// Khai báo mảng $rowData chứa dữ liệu

//  Thực hiện việc lặp qua từng dòng của file, để lấy thông tin
for ($row = 1; $row <= $highestRow; $row++){ 
    // Lấy dữ liệu từng dòng và đưa vào mảng $rowData
    $rowData[] = $sheet->rangeToArray('A' . $row . ':' . $highestColumn . $row, NULL, TRUE,FALSE);
}

//In dữ liệu của mảng
echo "<pre>";
print_r($rowData);
echo "</pre>";

Tiếp theo bạn tiến hành thực thi file docfile.php này, sẽ thấy kết quả in ra màn hình là một mảng chứa tất cả thông tin của file excel product.xlsx.

Array
(
    [0] => Array
        (
            [0] => Array
                (
                    [0] => STT
                    [1] => product_name
                    [2] => quantity
                    [3] => price
                )

        )

    [1] => Array
        (
            [0] => Array
                (
                    [0] => 1
                    [1] => php ebook
                    [2] => 2
                    [3] => 100
                )

        )

    [2] => Array
        (
            [0] => Array
                (
                    [0] => 2
                    [1] => java ebook
                    [2] => 1
                    [3] => 50
                )

        )

    [3] => Array
        (
            [0] => Array
                (
                    [0] => 3
                    [1] => laravel 5
                    [2] => 3
                    [3] => 120
                )

        )

    [4] => Array
        (
            [0] => Array
                (
                    [0] => 4
                    [1] => angularjs
                    [2] => 5
                    [3] => 30
                )

        )

    [5] => Array
        (
            [0] => Array
                (
                    [0] => 5
                    [1] => python
                    [2] => 4
                    [3] => 60
                )

        )

)

từ đó bạn có thể sử dụng mảng này cho mục đích thích hợp của bạn, như lưu vào cơ sở dữ liệu chẳng hạn.

  10 điều bạn cần biết về PHP7

Ghi dữ liệu ra file excel

Tương tự như file excel, chúng ta sẽ tiếp tục dùng thư viện PHPExcel để ghi dữ liệu ra file.

Đầu tiên, các bạn tạo 1 file mới, đặt tên là ghifile.php và 1 file tên là product_import.xlsx (file này tạo ra và để trống, ko cần điền nội dung, vì chúng ta sẽ điền nội dung vào bằng thư viện PHPExcel) và đặt 2 file này cùng cấp với file docfile.php. Các bạn mở file docfile.php lên và gõ nội dung như sau :

Import dữ liệu từ file excel

Giả sử bài toán là 1 lượng lớn dữ liệu địa chỉ trong đó có phân cấp Tỉnh/Thành Phố, Quận/Huyện, Xã /Phường. Và ta đã biết 1 Tỉnh/Thành Phố có nhiều Quận/Huyện, 1 Quận/Huyện có nhiều Xã/Phường. Như vậy ta sẽ thiết kế DB với 3 bảng như sau: provinces, districts, wards.

phpexcel

Trong bài demo này mình sẽ sử dụng Laravel và dùng Seed để import dữ liệu. Mình đã tạo project, migrate các bạn có thể xem trong source code. Dữ liệu dùng để demo là Tổng hợp địa giới hành chính Việt Nam.

Trước hết ta cài đặt thư viện vào project Laravel bằng dòng lệnh:

composer require phpoffice/phpexcel

Nhìn vào dữ liệu của file excel trên ta thấy có 3 sheet tỉnh, huyện, xã đã được khai báo khá rõ ràng nên ta có thể tưởng tượng ra được cách làm là đọc dữ liệu từng sheet một và insert vào các bảng tương ứng. Hiện thực hóa ý tưởng trên ta được kết quả:

<?php

use Illuminate\Database\Seeder;
use App\Province;
use App\District;
use App\Ward;

class AddressSeeder extends Seeder
{
   /**
    * Run the database seeds.
    *
    * @return void
    */
   public function run()
   {
       $objPHPExcel = PHPExcel_IOFactory::load(base_path('addresses.xls')); // load file ra object PHPExcel
       $provinceSheet = $objPHPExcel->setActiveSheetIndex(0); // Set sheet sẽ được đọc dữ liệu
       $highestRow    = $provinceSheet->getHighestRow(); // Lấy số row lớn nhất trong sheet
       for ($row = 2; $row <= $highestRow; $row++) { // For chạy từ 2 vì row 1 là title
           Province::create([
               'id' => $provinceSheet->getCellByColumnAndRow(0, $row)->getValue(), // lấy dữ liệu từng ô theo col và row
               'name' => $provinceSheet->getCellByColumnAndRow(1, $row)->getValue(),
               'type' => $provinceSheet->getCellByColumnAndRow(2, $row)->getValue(),
           ]);
       }
   
   
       $districtSheet = $objPHPExcel->setActiveSheetIndex(1);
       $highestRow    = $districtSheet->getHighestRow();
       for ($row = 2; $row <= $highestRow; $row++) {
           District::create([
               'id' => $districtSheet->getCellByColumnAndRow(0, $row)->getValue(),
               'name' => $districtSheet->getCellByColumnAndRow(1, $row)->getValue(),
               'type' => $districtSheet->getCellByColumnAndRow(2, $row)->getValue(),
               'location' => $districtSheet->getCellByColumnAndRow(3, $row)->getValue(),
               'province_id' => $districtSheet->getCellByColumnAndRow(4, $row)->getValue(),
           ]);
       }
   
       $wardSheet = $objPHPExcel->setActiveSheetIndex(2);
       $highestRow    = $wardSheet->getHighestRow();
       for ($row = 2; $row <= $highestRow; $row++) {
           Ward::create([
               'id' => $wardSheet->getCellByColumnAndRow(0, $row)->getValue(),
               'name' => $wardSheet->getCellByColumnAndRow(1, $row)->getValue(),
               'type' => $wardSheet->getCellByColumnAndRow(2, $row)->getValue(),
               'location' => $wardSheet->getCellByColumnAndRow(3, $row)->getValue(),
               'district_id' => $wardSheet->getCellByColumnAndRow(4, $row)->getValue(),
           ]);
       }
   }
}

Ở đây mới chỉ sử dụng các hàm đơn giản của PHPExcel để đọc dữ liệu ra, mình có comment code rất dễ hiểu. Ngoài các hàm đơn giản trên thì PHPExcel hỗ trợ rất nhiều hàm liên quan đến việc đọc dữ liệu các bạn có thể xem document ở đây.

  10 Frameworks tốt nhất hiện nay cho PHP

Export dữ liệu từ DB ra file excel

Ở trên đã import dữ liệu từ file excel vào DB, bây giờ sẽ làm điều ngược lại. Để tăng độ khó bài toán ta sẽ không export ra file giống như cũ mà giả sử khách hàng yêu cầu mình export dữ liệu ra file excel có format như sau:

  • Tạo các sheet tương ứng với tên các tỉnh/thành phố.
  • Tương ứng với mỗi sheet ghi rõ tên quận/huyện và các xã/phường thuộc quận/huyện đó.

Tạo 1 artisan command để làm việc này. Nội dung như sau:

<?php

namespace App\Console\Commands;

use App\Province;
use Illuminate\Console\Command;

class ExportExcel extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'db:export_to_excel';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Export address to excel';

    /**
     * Create a new command instance.
     *
     * @return void
     */
    public function __construct()
    {
        parent::__construct();
    }

    /**
     * Execute the console command.
     *
     * @return mixed
     */
    public function handle()
    {
        $provinces = Province::with('districts')->get();
        $objPHPExcel = new \PHPExcel();
    
        foreach ($provinces as $key => $province) {
            $objPHPExcel->createSheet(); // tạo 1 sheet mới
            $activeSheet = $objPHPExcel->setActiveSheetIndex($key);
            $activeSheet->setTitle($province->name); // đặt tên sheet là tên tỉnh
            $activeSheet->setCellValue('A1', 'Quận/Huyện')
                ->setCellValue('B1', 'Xã/Phường')
                ->setCellValue('C1', 'Kinh độ, vĩ độ'); // set title cho dòng đầu tiên
            $i = 2;
            $j = 2;
            foreach ($province->districts as $district) {
                $activeSheet->setCellValue("A$i", $district->type . ' ' . $district->name); // set tên quận/huyện
                foreach ($district->wards as $ward) {
                    $activeSheet->setCellValue("B$j", $ward->type . ' ' . $ward->name); // tương ứng mỗi quận huyện set tên xã/phường
                    $activeSheet->setCellValue("C$j", $ward->location);
                    $j++;
                }
                $rowMerge = $j - 1;
                if ($i < $rowMerge) {
                    $activeSheet->mergeCells("A$i:A$rowMerge"); // merge các cell có cùng 1 quận/huyện
                }
                $i = $j;
            }
            
            foreach (range('A', 'C') as $columnId) {
                $activeSheet->getColumnDimension($columnId)->setAutoSize(true);
            }
        }
        $objWriter = \PHPExcel_IOFactory::createWriter($objPHPExcel, 'Excel2007');
        $objWriter->save(base_path('result.xlsx'));
    }
}

Kết quả nhận được là:

phpexcel

Tham khảo:

Có thể bạn muốn xem thêm:

Xem ngay những tin đăng tuyển dụng IT mới nhất trên TopDev

Top 20 API trong AI và Machine Learning bạn nên biết

API sử dụng trong AI

Application Programming Interface là một code được tạo sẵn để đơn giản hóa cuộc sống của một lập trình viên. Nó giúp số hóa các task đơn điệu và tự động hóa một số lượng lớn các function phức tạp, và kết quả là ta cắt giảm được chi phí sản xuất. Khi nói đến lập trình AI / ML, chúng ta thường thực hiện việc tích hợp API thương mại vào các platform hiện có. Nó cho phép tương tác với code snippet hiện tại, cho chúng tương tác với nhau và tất nhiên tương tác với user-base của bạn.

Trong bài viết này, tôi sẽ liệt kê những API ưa thích mà tôi thấy phù hợp với lập trình AI và ML nhất. Một điều cần lưu ý là danh sách này chỉ dựa trên mức độ hiệu quả, dễ sử dụng và chức năng của platform chứ không phải độ phổ biến của nó. Tôi cũng không liệt kê những tên tuổi lớn như các platform Google, IBM hay Microsoft bởi vì ai cũng biết về chúng cả.

Tìm việc làm Machine Learning lương cao 3000 USD

1. BigML

Tài liệu: https://bigml.com/developers

Công ty BigML đã mô tả sản phẩm Machine Learning của mình rất đơn giản và dành cho tất cả mọi người. Và nó đúng thực sự như vậy. Bạn có thể tìm thấy các feature như phát hiện bất thường (anomaly detection) hoặc SunBurst visualization cho các decision tree, và nhiều tính năng khác nữa. API này chính là một vũ khí hoàn hảo ngay cả khi bạn không hề có bất kỳ kinh nghiệm nào trước đó. Điều tôi thích nhất ở BigML là bạn có thể tìm thấy rất nhiều ví dụ về case cụ thể và hướng dẫn hoàn thành các task một cách chính xác hơn. Do đó, bạn có thể hiểu mọi thứ từ đầu và sử dụng API này mà không cần tấm bằng tiến sĩ.

2. PredictionIO

Documentation: https://predictionio.apache.org/datacollection/eventapi/

Demo: https://predictionio.apache.org/demo/community/

API này cho phép triển khai miễn phí, và cung cấp vô số template gần-như-hoàn-chỉnh để tiện cho việc tùy chỉnh theo các case sử dụng khác nhau. Bên cạnh đó, nó đáp lại các dynamic queries ngay lập tức khi được triển khai như là một web service. Nó cung cấp documentation được tổ chức tốt và rộng, bao gồm các chỉ dẫn dành cho developer, các bản hướng dẫn demo,… API luôn được cập nhập thường xuyên nên bạn có thể tìm thấy nhiều feature nâng cao hơn tại đây.

3. Anaconda

Documentation: https://docs.anaconda.com/

Là một API được cung cấp bởi Python, thích hợp cho các doanh nghiệp, an toàn và có thể điều chỉnh để đáp ứng nhu cầu lớn hơn trong tương lai, nó cung cấp quyền truy cập trực tiếp vào hơn 700 package dễ cài đặt. Điều bạn nhận được từ API này là khả năng kiểm soát đúng data science asset. Tuy nhiên, một trong những feature vượt trội của nó là triển khai các project vào các ứng dụng data tương tác, sổ ghi chép trực tiếp và ML-model

4. Blue Yonder Platform

Documentation: https://github.com/blue-yonder

Nếu task của bạn là tìm một API tuyệt vời cho ngành bán lẻ thì đây là lựa chọn tốt nhất cho bạn. Tại vì sao? Tại vì platform cho các ứng dụng dự đoán dựa trên cloud này sử dụng các phương pháp tiếp cận AI / ML dẫn đầu trên thị trường, cho phép phản hồi nhanh chóng để thay đổi động lực thị trường. Công ty cho biết các nhà bán lẻ có thể giảm tới 80% tỷ lệ xuất kho và khiến doanh thu và lợi nhuận của họ cải thiện hơn 5%. Ngoài ra, ngoại trừ việc xây dựng ứng dụng cần thiết, bạn cũng có thể tích hợp nó với hệ thống hiện có như ERP hoặc HR.

5. MLJAR

Documentation: https://docs.mljar.com/

Một API khác sẽ khiến bạn ấn tượng là MLJAR. Nó cung cấp một dịch vụ để tạo mẫu, phát triển và triển khai các thuật toán nhận dạng mẫu cần thiết. Tất cả những gì bạn cần làm chỉ là tải data lên, chọn các thuật toán ML cần thiết và sử dụng các module tốt nhất để dự đoán.

6. NuPIC

Documentation: http://nupic.docs.numenta.org/

API này là một nguồn cung cấp mở được viết bằng Python và C ++, thực hiện Thuật toán Numenta’s Cortical Learning và được duy trì bởi sự trợ giúp của Cộng đồng NuPIC. Lý do nó hấp dẫn tôi là vì nó là một công cụ đa năng mạnh mẽ cho phép các developer làm việc với các thuật toán raw, tập hợp nhiều lĩnh vực (như hierarchies) và tận dụng khả năng của các platform khác.

7. Recombee

Documentation: https://docs.recombee.com/

Recombee là một giải pháp SAAS và nó cung cấp các đề xuất thông qua API real-time trực quan. Recombee sử dụng khai thác records mining, ngôn ngữ câu hỏi và các thuật toán machine learning (ví dụ như tư vấn dựa trên nội dung) thông qua API RESTful. Quan trọng nhất là API Documentation rất thân thiện và sử dụng nó trong công việc rất thoải mái.

8. indico

Documentation: https://indico.io/docs/

Bạn không thể không biết indico vì nó là thuộc top những API phần mềm phân tích dự đoán phổ biến nhất. Bạn nhận được gì khi sử dụng nó? Nó có hai option chính: đánh giá văn bản (phân tích tâm lý đối tượng, sự tương tác, cảm xúc) và đánh giá ảnh (cảm xúc khuôn mặt, định vị khuôn mặt). Ưu điểm của API này là nó miễn phí và không yêu cầu training data, thế nên bạn có thể dùng thử ngay bây giờ.

  9 hiểu lầm "ngớ ngẩn" về machine learning

TOP API dùng để nhận diện khuôn mặt và nhận dạng khuôn mặt

9. Animetrics Face Recognition

Documentation: http://api.animetrics.com/documentation

Demo: http://api.animetrics.com/demo

Nếu bạn muốn tạo một phần mềm nhận dạng khuôn mặt hoặc đơn giản chỉ là tiến hành phân tích hình ảnh, thì Animetrics Face Recognition sẽ hỗ trợ bạn rất nhiều. Bạn có thể sử dụng nó để phát hiện khuôn mặt trong tấm hình hoặc hình ảnh nào đó và ghép chúng với một set khuôn mặt đã biết. Một lợi thế khác của nó là thông tin về các đặc điểm trên khuôn mặt hoặc các landmark được trả về dưới dạng tọa độ trên ảnh. Hơn thế nữa, API này cũng có thể tải lên hoặc hoãn một subject từ thư viện, và tải lên hoặc loại bỏ khuôn mặt khỏi một topic.

10. Eyedea Recognition

Documentation: http://face.eyedea.cz:8080/api/face/docs

Demo: http://cloud.eyedea.cz/api/face

Eyedea Recognition là tên khổng lồ trong lĩnh vực phát hiện đối tượng và nhận dạng đối tượng. API này xử lý một cách hoàn hảo các giải pháp phần mềm được chuẩn bị theo đặc điểm kỹ thuật của khách hàng và dựa trên kết quả nghiên cứu về Machine Learning và AI. Dịch vụ nhận dạng này rất linh hoạt, nó cung cấp phát hiện mắt, mặt, automobile, copyright và bảng biển. Giá trị tuyệt vời nhất của API là quyền truy cập thông tin tức thời của các object, khách hàng và hành vi.

11. Betaface

Documentation: https://www.betafaceapi.com/wpa/index.php/documentation

Demo: https://www.betafaceapi.com/demo.html

Tất cả những gì bạn cần biết về API này là nó là một platform mạnh mẽ và có thể mở rộng để quét các file đã được tải lên hoặc URL ảnh, phát hiện khuôn mặt và kiểm tra chúng. API này bao gồm các khả năng như phát hiện khuôn mặt, cắt xén khuôn mặt, phát hiện 123 điểm khuôn mặt (22 điểm cơ bản, một trăm lẻ một điểm nâng cao), xác minh khuôn mặt, cũng như tìm kiếm sự tương đồng trong các database rất lớn.

12. Imagga

Documentation: https://docs.imagga.com/

Demo: https://imagga.com/auto-tagging-demo

Đây là một API mạnh mẽ khác để phân tích hình ảnh, phân loại hình ảnh tức thì, khai thác màu sắc và cắt xén nội dung. Imagga cung cấp các API tự động gán thẻ cho ảnh của bạn và giúp hình ảnh của bạn dễ tìm thấy. Nó dựa trên một platform nhận dạng hình ảnh như một dịch vụ.

Video: IoT and AI Thinking Linking Things Age of VUI

API Phân tích văn bản và Natural Language Processing

13. Wit.ai

Documentation: https://wit.ai/docs

Demo: https://labs.wit.ai/demo/index.html

Đây là một platform NLP mở rộng. Nếu bạn muốn trao quyền cho các developer liên quan đến tự động hóa giọng nói, thì đây sẽ là lựa chọn tốt nhất. Cá nhân tôi là một fan lớn của API này. Lý do nó hấp dẫn tôi là sự tập trung của nó vào việc hiểu ngôn ngữ của con người từ mọi tương tác và thúc đẩy cộng đồng, điều đó có nghĩa là mọi thứ học được sẽ được chia sẻ giữa các developer. Wit tạo ra một giao diện giọng nói thông minh dùng cho các mục đích như tự động hóa gia đình, ô tô kết nối, robot, smartphone, thiết bị đeo,… Ngoài ra, nó miễn phí.

14. Bitext

Documentation: https://docs.api.bitext.com/

Demo: http://parser.bitext.com/

API Bitext là một tool phân tích ngôn ngữ sâu khác, cung cấp data mà dễ dàng export cho toàn bộ các tool quản lý dữ liệu. Sản phẩm của platform này có thể được sử dụng cho chatbot và assistant, CS và Sentiment, cũng như một số task NLP cốt lõi khác. Trọng tâm chính của nó là ngữ nghĩa, ngữ pháp, từ vựng và văn nói hay văn viết có sẵn cho hơn 80 ngôn ngữ. Thêm vào đó, khi nói đến việc tự động hóa phân tích feedback của khách hàng thì API này là tốt nhất. Công ty tuyên bố rằng nó cung cấp insight khách hàng với độ chính xác là 90%.

15. Geneea

Documentation: https://api.geneea.com/

Demo: https://demo.geneea.com/

Geneea thực hiện phân tích (Natural Language Processing) trên raw text được cung cấp, trên văn bản được trích ra từ URL đã cho hoặc trực tiếp từ tài liệu được cung cấp. Lợi thế nổi trội của nó là số lượng lớn các ngôn ngữ có sẵn (hơn 30). Geneea thực hiện các phân tích về các topic như ngôn ngữ, nhận dạng topic, phân tích tâm lý khách hàng, trích xuất thực thể, gắn thẻ tự động, cũng như thực hiện các điều chỉnh khác nhau.

16. Diffbot Analyze

Documentation: https://www.diffbot.com/dev/docs/

Demo: https://www.diffbot.com/

API này thực hiện nhận dạng, phân tích và trích xuất tự động mọi phần của data (văn bản, ảnh, video) từ bất kỳ URL nào một cách dễ dàng. Nó sử dụng một tập hợp lý tưởng của AI, ML, computer vision và NLP. Ngoài ra, bạn cũng có thể sử dụng nó với các API tùy chỉnh cho phép lấy data bằng các quy định thủ công.

17. Yactraq Speech2Topics

Demo: https://yactraq.com/contact-trial/

Đây là một platform phân tích giọng nói tuyệt vời với mục đích là giải phóng khả năng của dữ liệu âm thanh của bạn. API này chuyển đổi tài liệu nội dung nghe nhìn thành siêu dữ liệu subject thông qua nhận dạng giọng nói & NLP. Nó cung cấp một tập hợp các call operations solution cung cấp ROI quá mức, các ứng dụng thống kê lớn.

18. MonkeyLearn

Documentation: https://monkeylearn.com/api/v3/

Demo: https://monkeylearn.com/contact/

MonkeyLearn là một platform AI cho phép bạn phân loại và xuất data hành động từ các raw text như email, chat, webpage, document, tweet,… Nó đặc biệt tập trung vào việc giảm thiểu thời gian cần thiết cho tất cả các task này và vì vậy đây là một lựa chọn tốt dành cho bạn.

19. Hu:toma

Documentation: https://help.hutoma.ai/article/ym34wr87lx-hutoma-chat-api

Đây là một platform giúp đơn giản hóa việc truy cập data hành động thông qua các giao diện ngôn ngữ tự nhiên và trợ lý AI. Nếu bạn đang triển khai Natural Language Interface vào ứng dụng hoặc website của mình thì đây sẽ là ưu tiên số 1 của bạn. Lý do là bạn có thể dạy và đào tạo nó bằng cách cung cấp các ví dụ về các cuộc hội thoại (kịch bản phim,…).

20. nlpTools

Documentation: http://php-nlp-tools.com/documentation/

nlpTools là một open source framework xử lý văn bản đơn giản (một thư viện cho NLP được viết bằng php) để phân tích Ngôn ngữ tự nhiên. Nó decode online news media (mục đích chung, nhiều topic) để phân tích tâm lý đối tượng và phân loại văn bản.

Kết luận

Trong quá trình đọc, có lẽ bạn sẽ chọn được một vài cái để áp dụng. Nhưng trước khi kết thúc, tôi muốn nhắc tới một điều quan trọng. Các lập trình viên, đặc biệt là người mới bắt đầu không nên chỉ sử dụng một kế hoạch như vậy cho các giải pháp được đưa ra sẵn. Tại vì nếu bây giờ bạn không giải quyết các quy trình phức tạp hơn, bạn có thể không đối phó được với các task thực sự trong tương lai. Do đó, bạn cần giữ cân bằng giữa việc áp dụng những thứ này với việc thực hiện các công việc thực sự. 

TopDev via Medium

  Vì miếng ăn mà phá cả nồi cơm – Thực tại đáng lo của nghề lập trình

  Hành trình yêu lại từ đầu cùng Git

Cần trang bị những gì để trở thành một kỹ sư cho Google, Amazon, Facebook?

Trong bài viết này, tôi sẽ cho bạn thấy quy trình 6 bước để có được một công việc kỹ sư phần mềm không chỉ ở Google mà ở bất kỳ công ty công nghệ hàng đầu nào như: Amazon, Microsoft và Facebook. Ngoài ra, tôi cũng sẽ thảo luận về:

  1.   Cách học lập trình và đọc code
  2.   Những điều cần tìm hiểu sau khi học lập trình
  3.   Cách có công việc lập trình đầu tiên
  4.   Cách tốt nhất để xin vào vị trí software engineer
  5.   Cách tốt nhất để chuẩn bị cho các cuộc phỏng vấn lập trình
  6.   Bằng khoa học máy tính có quan trọng không?
  7.   Học tại đại học hàng đầu có cần thiết không?

Bước 1: Học cách viết code

Đây là trình độ tối thiểu tuyệt đối bạn cần phải có để trở thành kỹ sư phần mềm.

Đối với điều này, tôi khuyên bạn nên bắt đầu với một trang web học trực tuyến như Codecademy freeCodeCamp. Bạn có thể tìm hiểu hầu hết các kiến thức cơ bản của lập trình từ các trang web này.

Sau đó, bạn nên xem những video hướng dẫn để tìm hiểu thêm về các chủ đề nâng cao. Tôi khuyên bạn nên vào các trang như YouTube, Pluralsight, Lynda.com và Udemy. Trên các trang web này, bạn sẽ có thể tìm thấy các hướng dẫn về những chủ đề như:

  • Web development
  • Mobile development
  • Game development

Vậy thì tôi nên học ngôn ngữ lập trình nào trước tiên?

Câu trả lời ngắn của tôi là hãy chọn JavaScript hoặc Python, nhưng nó thực sự phụ thuộc vào sở thích của bạn.

Bước 2: Hãy làm một vài dự án cá nhân

Sau khi đã hoàn thành vài khóa lập trình trực tuyến thì bạn nên thực hiện một vài dự án cá nhân để vận dụng những kiến thức mình đã học.

Ví dụ: nếu bạn thích nhiếp ảnh, có thể bạn có thể tạo trang web để trưng bày tất cả các ảnh của mình. Nếu bạn thích cổ phiếu giao dịch, có thể bạn có thể xây dựng một hệ thống phân tích biểu đồ chứng khoán cho riêng mình. Hoặc, nếu bạn thích giải quyết vấn đề, bạn có thể thử cạnh tranh trong một cuộc thi lập trình.

Khi bạn làm project, trước hết hãy tự mình làm càng nhiều càng tốt. Sau đó, nếu gặp khó khăn, hãy kêu gọi sự trợ giúp từ người khác trên các diễn đàn trực tuyến.

Ví dụ: bạn có thể sử dụng Stack Overflow để hỏi các câu hỏi kỹ thuật cụ thể mà bạn đang mắc phải.

Bước 3: Nhận công việc lập trình đầu tiên hay chọn làm thực tập

Khi bạn đã xây dựng một vài dự án cá nhân của mình thì bạn cũng đã có thể nhận được công việc hoặc thực tập đầu tiên của mình. Với nó, bạn sẽ tích lũy một số kinh nghiệm trước khi bạn bắt đầu phỏng vấn với các công ty công nghệ hàng đầu.

Tất nhiên, bạn có thể nhận được công việc đầu tiên của mình tại một trong những công ty công nghệ hàng đầu, nhưng nó sẽ dễ dàng hơn khi vào một một công ty ít nổi tiếng trước.

Cách tốt nhất để xin vào vị trí software engineer

Tôi khuyên bạn nên sử dụng mạng xã hội của LinkedIn và mối quan hệ quen biết để có được công việc lập trình đầu tiên của bạn.

Trên LinkedIn, trước tiên hãy tìm nhà tuyển dụng của công ty bạn quan tâm. Sau đó, hỏi họ xem bạn có đủ điều kiện cho vị trí bạn quan tâm hay không. Bạn cũng nên hỏi họ cách bạn có thể chuẩn bị tốt hơn nếu như vẫn chưa đủ điều kiện.

Việc sử dụng mạng xã hội của LinkedIn sẽ rất hiệu quả nếu bạn đang nhắm tới các công ty vừa và nhỏ. Tuy nhiên, tôi nhận thấy rằng các chiến lược này kém hiệu quả hơn cho các công ty như Google và Facebook.

Đối với những công ty lớn này thì tôi khuyên bạn nên kết hợp ba chiến lược sau:

  1.   Tham gia hội chợ nghề nghiệp và sự kiện tuyển dụng tại các trường đại học
  2.   Nhờ vào sự giới thiệu từ những người bạn làm việc tại một trong những công ty này
  3.   Cứ việc đăng ký trực tuyến.

Kết hợp tất cả các chiến lược này sẽ giúp bạn tăng cơ hội có được một cuộc phỏng vấn với một trong những công ty công nghệ hàng đầu này.

Image result for engineers at big companies

Nguồn: engineering.com

Bước 4: Tìm hiểu cấu trúc và thuật toán dữ liệu

Các công ty công nghệ hàng đầu như Google và Microsoft thường đặt câu hỏi về cấu trúc dữ liệu và thuật toán trong các cuộc phỏng vấn của họ. Vì vậy, bạn nên tìm hiểu chúng.

Để tìm hiểu kiến ​​thức cơ bản, tôi khuyên bạn nên sử dụng series video này về cấu trúc và thuật toán dữ liệu.

Vì chỉ có 7 video trong loạt bài này nên bạn sẽ cần nhiều tài liệu hơn để tìm hiểu thêm về các chủ đề nâng cao.

Sau đây là một số lựa chọn tiêu biểu, bao gồm:

Các khóa học của Stanford trên Coursera

Khóa học MIT này trên YouTube

Sách hướng dẫn thiết kế thuật toán của Skiena

Algorithms

Bước 5: Chuẩn bị cho các cuộc phỏng vấn

Các cuộc phỏng vấn mã hóa tại các công ty như Google và Microsoft rất khó.

Khi bạn đã có kiến ​​thức vững chắc về cấu trúc và thuật toán dữ liệu, tôi khuyên bạn nên sử dụng ba khóa này để thực hành:

Leetcode – một nền tảng tương tác để thực hành các vấn đề về mã hóa thường được hỏi trong phỏng vấn.

Cracking the Coding Interview– một cuốn sách nổi tiếng về các cuộc phỏng vấn mã hóa.

Daily Coding Problem – Danh sách mail cung cấp cho bạn một vấn đề lập trình mỗi ngày.

Sau khi tập luyện trong vài tuần, bạn sẽ sẵn sàng để bắt đầu thử các buổi phỏng vấn giả.

Về cơ bản, ghép nối với bạn bè của bạn và đưa ra các vấn đề về lập trình từ 3 nguồn trên.

Sau đó, giải quyết từng vấn đề trên giấy và giải thích giải pháp của bạn cho họ nghe.

Khi bạn thực hiện được tầm 20 cuộc phỏng vấn giả thì có thể gọi là sẵn sàng rồi đấy!

Bước 6: Áp dụng, áp dụng và áp dụng lại

Sử dụng ba chiến lược tôi đã đề cập ở trên để xin vào làm cho các công ty công nghệ hàng đầu:

  1.   Sự kiện tuyển dụng / hội chợ nghề nghiệp
  2.   Nhờ bạn bè giới thiệu bạn
  3.   Và đăng ký trực tuyến.

Nếu bạn không nhận được trong lần đầu tiên, đừng lo lắng. Trong thực tế, bạn nên mong đợi một số thất bại bởi việc nhận được vào bất kỳ của các công ty này là rất khó.

Bản thân tôi cũng mất tới 5 lần trước khi được nhận vào Google tại vị trí công việc kỹ sư phần mềm.

Một vài lưu ý khác

 – Tôi có cần lấy bằng khoa học máy tính không?”

 – Không nhất thiết, Tuy nhiên, việc học chúng sẽ giúp ích cho bạn rất nhiều.

Ngoài ra, xin lưu ý rằng ngay cả khi bạn có bằng cấp đủ chuẩn cần phải mất rất nhiều thời gian để có được một công việc kỹ sư phần mềm tại một trong những công ty này.

 – Vậy tôi có cần học tại một trường đại học hàng đầu như MIT, Stanford, Carnegie Mellon, v.v. không?

Không. Nó có thể giúp một chút nhưng không hề cần thiết.

– Vậy Tôi có cần điểm GPA cao không?

Không.

Có điểm trung bình cao có thể giúp một chút để có được một cuộc phỏng vấn nhưng kinh nghiệm thực tế vững chắc và các dự án thú vị còn quan trọng hơn nhiều.

 – Làm thế nào để tôi có thể viết một CV – lý lịch tốt?

  – Nếu muốn, bạn có thể sử dụng bản CV – lý lịch mà tôi đã sử dụng để xin vào Google làm mẫu.

Đây là phiên bản PDF.

Đây là phiên bản Word.

Đây là phiên bản Pages.

Chúc cho những ước mơ còn dang dở sẽ sớm trở thành hiện thực. Thanks all!

TopDev via Medium

Thế nào là một lập trình viên Full-Stack?

full stack developer
Full-stack developer (FSD) là người có thể làm các công việc liên quan tới databases, servers, systems engineering và client work. Họ có thể là một FSD về di động (mobile stack), web (web stack) hoặc phần mềm (native applications).
full stack developer

Tham khảo thêm VỊ trí tuyển dụng Full Stack lương cao cho bạn

Full-stack Developer = Mr. Do It All!

Anh chàng FSD Full-stack Developer quen thuộc với tất cả các mảng trong quá trình phát triển phần mềm. Anh ta có kiến thức bao quát về Mạng, CSDL, User Interface, API, Security, … Một FSD không nhất thiết phải thông thạo mọi công nghệ của Front-end và back-end nhưng có thể học và ứng dụng vào dự án một cách nhanh chóng khi họ cần. Các công ty và start-up với nguồn lực giới hạn luôn tìm kiếm những “super hero” như thế này. Tuy nhiên, cơ hội tìm được họ là rất thấp.
Nói một cách cụ thể hơn, một FSD có thể đảm nhiệm các công việc liên quan đến:
  • Máy chủ, mạng, và hosting. Họ hiểu biết về các yêu cầu về phần cứng, hệ điều hành, thiết lập môi trường hệ thống để triển khai ứng dụng.
  • CSDL. Họ có thể phân tích và thiết kế CSDL, sử dụng các hệ quản trị CSDL (MySQL, SQLServer, NoSQL, …) và viết được các câu truy vấn.
  • API/ Back-end code. Họ có thể sử dụng một hay nhiều ngôn ngữ server-side như Ruby, Python, PHP, Java, … để viết các ứng dụng, dịch vụ web (web service).
  • Front-end code. HTML5, CSS3, Javascript và các frameworks như Bootstraps, Jquery, AngualarJS, …
  • UI/UX.
  • Client work. Họ có thể giao tiếp và lấy yêu cầu (requirement) từ khách hàng. Họ viết ra các tài liệu kĩ thuật (technical specs, architecture documents) và documentation.
Nếu bạn muốn tìm kiểu về khái niệm FSD một cách đầy đủ và hệ thống hơn, bạn có thể xem các bài viết sau:
  • Being a Full-stack Developer
  • What is a Full-stack Developer
  • What does the term Full-stack programmer mean

Xem ngay những tin đăng tuyển lập trình viên Full-stack

Bạn muốn trở thành một Full-stack Developer?

Nếu bạn muốn bước chân trên con đường để trở thành một FSD thì chúc mừng bạn vì bạn đang bước đi trên con đường gian nan, tiêu tốnnhiều thời gian nhưng kết quả thì rất khả quan đấy.
Trước hết, bạn hãy bắt đầu học về các ngôn ngữ lập trình phía Front-end. bao gồm HTML5, CSS3, và Javascript. Mục tiêu bạn cần đặt ra là có thể tạo được một website tĩnh.
Sau đó, bạn hãy bắt đầu học một ngôn ngữ lập trình phía Back-end. Vì bản thân mình là một PHP Developer và mình thấy rằng PHP là một ngôn ngữ dễ học nên mình sẽ hướng các bạn học và làm việc với PHP. Khi đã nắm vững được một ngôn ngữ lập trình rồi thì bạn có thể học các ngôn ngữ mới dễ dàng hơn. Kết hợp với kiến thức phía Front-end, lúc này bạn đã có thể xây dựng được một website giống như GeekBoy rồi đấy!
Trong quá trình phát triển, bạn cũng cần có các công cụ để quản lý code của mình. Có khá nhiều công cụ phục cho việc này như Git, SVN, Mercury. Mình khuyên các bạn nên học sử dụng Git.
Tiếp theo đó, bạn hãy học về CSDL để có thể lưu trữ nội dung cho website của mình.
Khi đã xây dựng xong website bên dưới máy của bạn rồi, điều bạn cần làm tiếp theo là học các kiến thức về tên miền cho website, hosting hoặc server để chứa source-code. Nếu bạn có server riêng (hoặc VPS), bạn cần học các kiến thức về quản trị server, bao gồm cài đặt hệ điều hành, cài đặt web server, …
Xong các bước ở trên rồi, bạn cũng cần phải nghiên cứu làm sao cho website của mình được người dùng tìm thấy qua Google, Bing, Yahoo. Quá trình được gọi là Tối ưu hóa công cụ tìm kiếm (Search Engine Optimization, SEO).
  Lộ trình trở thành Fullstack Developer cho người mới bắt đầu

Và còn nhiều điều nữa bạn cần phải học lắm!

Mình xin trích dẫn đoạn trích bài viết của anh Bùi Hải An, là người sáng lập start-up công nghệ SSS:
Để một bạn dev ở SSS có thể được gọi là 1 Full Stack Developer thì cần:Kiên trì Dũng cảm. Còn về kỹ năng, tất cả đều có thể tự học được!
Kiên trì để liên tục đẩy bản thân mình không ngừng nghỉ. Với tất cả những bạn học IT tốt nghiệp ra đi làm, hầu hết các bạn đều có đủ kiến thức cơ bản. Tuy nhiên giống như 1 self-timer vậy. Kiến thức này expire và obsolete cực nhanh. Do đó bạn phải kiên trì liên tục học cái mới. Mỗi tuần bạn không biết thêm và làm thêm 1 cái gì mới coi như bạn đang đi thụt lùi.
Kiên trì cho 1 chuyên môn, 1 ngôn ngữ nhất định thì dễ (như PHP, Ruby, Android, Python, iOS, …). Bạn cứ làm, cứ nghiên cứu thì cũng là tiến bộ rồi. Nhưng bạn có đủ kiên trì để học 2-3 ngôn ngữ, tìm hiểu 2-3 nền tảng cùng 1 lúc không? Bạn có đủ kiên trì để trải qua những cung bậc cảm xúc khi bắt đầu lại từ đầu với 1 ngôn ngữ mới không?
Kiên trì tìm cho mình cơ hội. Cơ hội để được làm, được thực hành. Ngồi đọc 10 bài trên StackOverflow, Reddit, HackerNews mà không bắt tay vào làm thử thì cũng vô dụng. Do đó, tìm cho mình mọi cơ hội để được làm, để được thử. Bạn có thể tự làm project của mình, hoặc xin sếp cho làm thêm 1 project, tìm project freelance,… Bạn có đủ kiên trì làm như vậy trong suốt 2-3 năm trời không?
Dũng cảm để chọn con đường hơi khác người. Bạn có đủ dũng cảm và tự tin để sale bản thân mình với 1 bộ skillset không giống lắm với những bạn bè của mình.
Dũng cảm để có thể bỏ toàn bộ code làm 5-6 tháng trời để nâng cấp lên một ngôn ngữ mới. Dũng cảm để không dùng Code generator mà tự code để hiểu được architecture và nền tảng chuyên sâu bên dưới.
Dũng cảm để trở thành lại 1 newbie trong khi mình đang là hardcore khi nhảy từ 1 nền tảng ruột (Android), sang 1 nên tảng lạ hoắc (iOS). Và phải đi tầm sự học đạo 1 bạn junior vì bạn đó giỏi hơn mình (trong cái mới này).
Tóm lại, về chuyên môn thì ai cũng có thể trở thành 1 Full Stack Developer được hết (ít ra là tự cho mình là vậy). Nhưng về thái độ và bản lĩnh, chưa chắc nhiều bạn sẽ dám dấn thân và thử thách bản thân mình đâu.”Còn bạn thì sao? Bạn đã sẵn sàng để trở thành một Full-stack Developer?

via geekboy

Có thể bạn muốn xem thêm:

Truy cập ngay việc làm IT đãi ngộ tốt trên TopDev

Developer tranh cãi việc học IT ở Việt Nam là “lỗi thời” và “lạc hậu”?

Việc du học luôn là mơ ước của nhiều người bởi cơ hội được tiếp xúc với nền văn hóa mới cũng như cách học và làm việc của nước bạn. Tuy vậy, ngành lập trình lại là một trong những ngành yêu cầu sinh viên phải tự học rất nhiều, đôi khi chiếm tới 90% thời lượng tiếp thu và thực hành. Do đó mà so với việc học IT ở Việt Nam, có rất nhiều người cho rằng việc đi du học gần như là không cần thiết nếu bạn muốn theo nghiệp làm developer.

Đây cũng là một topic khá hot trên fanpage của cộng đồng Lap Trinh Vien Confession khi có rất nhiều ý kiến trái chiều được đưa ra.

Bắt đầu với chính người đăng confession khi cho rằng việc học lập trình tại Việt Nam có vẻ gần như… lạc hậu so với các nước khác, cậu thổ lộ:

“Em mới đi du học một khoá lập trình tại Canada được gần một năm, lúc ở Việt Nam chưa học lập trình ở đâu hết.

Sang bên này học, em thấy họ dạy những thứ rất sát với thực tế. Họ lấy Java làm ngôn ngữ mũi nhọn để dạy nền tảng lập trình và OOP, và xung quanh đó họ dạy cái cơ bản của những thứ cần thiết như SQL, GNU/Linux, Javascript/HTML/CSS, PHP, một chút low-level, một chút networking, một chút COBOL, một chút Kotlin để phát triển Android…

Toán của họ dạy trình độ ngang với học sinh lớp 9 ở VN, chỉ có thêm một môn Technical Communication (giao tiếp trong môi trường kỹ thuật), còn lại không có ba cái môn lăng nhăng nào khác. Học tương đối đơn giản, GPA rất dễ lấy > 3.5 (trên thang 4).

Khoá học không quá nặng nề để sinh viên có thể bỏ thời gian tự tìm hiểu mảng lập trình mình thích, điểm số rất thuận lợi để sau này đi xin việc. Em chưa học lập trình ở VN bao giờ nên thắc mắc không biết giờ này mấy trường đại học công lập nhà mình đang dạy cái gì nhỉ? Cấu trúc của khoá học ra sao?

Em nghe nói vẫn có những trường ôm giáo trình của mấy chục năm trước để giờ học sinh vẫn phải học mấy thứ ba lăng nhăng như Pascal với toán rời rạc phải không? Và nghe nói nữa là họ dạy những thứ khó một cách không cần thiết, không thực tế và thậm chí có những giảng viên còn tư duy theo kiểu lỗi thời? Thực sự các bác thấy học như vậy có ổn không?”

Tuy vậy, nhiều thành viên khác thì hoàn toàn không cho rằng đây là một cách nhìn đúng đắn về vấn đề và còn có phần thiển cẩn.

“Muốn học mấy cái này thì cần gì qua nước ngoài tốn tiền vậy? Qua Nhất Nghệ, Aptech hoặc mấy trung tâm lập trình họ cũng dạy vậy thôi :)))

Note nhẹ là mình tốt nghiệp Thạc Sĩ Computer Science, bằng giỏi, đại học top 10 UK nên cũng từng trải nghiệm chuyện học/làm nước ngoài rồi nhé” – Bạn Huy Hoàng Phạm chia sẻ.

Mình nghĩ khóa học của bạn chỉ tương tự một khóa học nghề thôi. Chứ còn trình độ đại học thì chắc chắn là phải học toán, các môn lý thuyết mà bạn kêu “ba lăng nhăng” nhiều.

Không tin bạn xem chương trình học Computer Science của Stanford (Stanford đang là một trong những trường đại học kỹ thuật hàng đầu thế giới, hình như năm vừa rồi xếp thứ 2 hay sao ấy), nó sẽ còn nhiều thứ ” lăng nhăng” hơn. Nhìn chung là việc học ngôn ngữ, công nghệ là những thứ có thể tự học đc, ngôn ngữ hay công nghệ thì cũng chỉ là công cụ thôi.

Còn ở đại học người ta dạy cho mình cái nền tảng, cái tư duy là chính. Học đại học xong có thể bạn không code giỏi, nhưng bạn lại có thể (mình nói là có thể) thiết kế ra những hệ thống khủng, khiến những hệ thống đó hoạt động hiệu quả (thứ mà những người chỉ học lập trình gần như không làm hiệu quả được)”

Nhìn chung, đa phần ý kiến đều không đồng tình với chủ confession và tin rằng việc học lập trình không có quá nhiều sự khác biệt giữa trong nước và đi du học. Tuy vậy, mọi người đều đồng tình rằng nếu có cơ hội thì nên đi du học để có thể học hỏi nền văn hóa của nước bạn. Hãy cho chúng tôi biết ý kiến của các bạn ở phần comment.

Tìm việc làm IT HOT nhất Việt Nam

Quy tắc 24×3 cho sáng tạo trong lập trình!

Innovation vốn dĩ ám chỉ những sáng kiến mới mẻ. Đó là một nỗ lực để làm những việc khác với những gì từ trước đến nay. Thế nhưng con người lại có xu hướng chỉ tiếp nhận những thứ quen thuộc với mình.

Ngày nay, đổi mới là thứ mà hầu hết các tổ chức luôn tuyên bố rằng họ đang theo đuổi. Tuy vậy, đa phần chúng ta luôn cố gắng tìm ra những lí do chỉ trích để thực hiện chúng hơn là cách để cải thiện tình hình và đánh giá một ý tưởng mới theo con mắt khách quan.

Nói cách khác thì đó là phản ứng liên quan tới cảm xúc của chúng ta hơn là logic từ bộ não.

Tác giả Anthony Tjan ủng hộ một quá trình mà ông đề cập đến là tư duy 24 x 3. Nó có thể được giải thích với ví dụ đơn giản sau. Một người nào đó mang đến cho bạn 1 ý tưởng mới của họ, và bạn đầu tiên chờ 24 giây trước khi trả lời. Nếu bạn đã hiểu về ý tưởng đó thì hãy thử và chờ 24 phút trước khi có quyết định tiếp theo, và tiếp tục chờ chờ 24 giờ trước khi đưa ra quyết định có thực hiện ý tưởng mới.

Ông tin rằng thời gian này cho phép bạn phân tích một cách hợp lý ý tưởng và giá trị của nó hơn là ra một phê bình nhanh chóng như bản năng của chúng ta.

Tuy nhiên, đây thường là một thách thức đối với các nhà lãnh đạo. Thật vậy, một nghiên cứu gần đây đã phát hiện ra rằng khi người ta ngồi vào vị trí “leader”, các thành viên khác của nhóm cảm thấy leader đã nhận được số tiền không cân xứng trong các nhiệm vụ, với các cuộc thảo luận này cũng được đánh giá là kém hơn về các khía cạnh khác nhau . Dẫn tới những đóng góp cho hiệu suất kém hơn. Chính vì điều này mà họ rất sợ sự thay đổi và có cái nhìn tiêu cực đối với những thay đổi mới từ trong công ty.

Đây là một điều vô cùng đáng tiếc bởi chúng ta đang sống trong một thế giới mà các nhà lãnh đạo thường được đánh giá cao bởi quyết định của họ. Vì vậy hãy tạm dừng suy nghĩ chỉ trích một ý tưởng mới và tập thói quen đánh giá chúng một cách thận trọng.

TopDev

  Bài học tôi rút ra được từ việc "clone" ứng dụng Uber
  Một số mẹo ít người biết để trang web chạy nhanh hơn gấp đôi!

CMS là gì? List các CMS phổ biến hiện nay

cms là gì

Trong quá trình phát triển và vận hành trang web, chắc hẳn bạn sẽ thường xuyên nghe tới từ “CMS”. Tuy nhiên trong thực tế có khá ít người hiểu được ý nghĩa của CMS là gì?

Bài viết này sẽ giải thích những điều cơ bản về CMS cũng như giới thiệu cho các bạn những ưu, nhược điểm của nó và các CMS phổ biến hiện nay.

CMS là gì?

CMS là chữ viết tắt của Content Management System. Còn gọi là hệ thống quản trị nội dung nhằm mục đích giúp dễ dàng quản lý, chỉnh sửa nội dung. Nội dung ở đây là text, video, nhạc, hình ảnh, files… CMS là nơi người quản trị Website có thể cập nhật, thay đổi nội dung trên Website. Một hệ thống CMS tốt sẽ cho phép vận hành Website mà không cần sự can thiệp, hỗ trợ từ người lập trình trang web.

Hệ thống CMS giúp tiết kiệm thời gian quản lý, chi phí vận hành và bảo trì nên hiện nay có rất nhiều công ty sử dụng. Không chỉ là công ty mà hiện nay các blog cá nhân cũng ra đời nhiều, giải pháp sử dụng CMS giúp dễ dàng xây dựng website và quản lý nội dung. Bên cạnh đó còn tiết kiệm được chi phí xây dựng website.

cms là gì
cms là gì

CMS hoạt động như thế nào?

CMS là nơi mà tất cả những người phụ trách liên quan đến các tính năng của Website phải sử dụng. Khi nhắc tới CMS bạn có thể hiểu nó như là phần quản trị (admin) của một Website. Nơi quản lý tất cả dữ liệu Website của bạn.

  Nhập môn lập trình web, có nên học Wordpress?
  Hướng dẫn cách fix và restore Wordpress bị shell hack hoặc chiếm quyền điều khiển

Chức năng cơ bản của CMS là gì?

CMS có các chức năng cơ bản sau:

  • Quản lý version
  • Quản lý nội dung
  • Sitemap
  • Tìm kiếm
  • Quản lý quyền sử dụng
  • Chức năng WYSIWYG
  • Cập nhật Homepage,…

Các loại CMS

1. CMS mã nguồn mở (Open Source)

Do sự phát triển của công nghệ và ngôn ngữ. Có rất nhiều mã nguồn mở được sử dụng phổ biến trên thế giới, giúp xử lý những bài toán xây dựng Website phục vụ cho cá nhân và doanh nghiệp như WordPress, Joomla, Drupal, Magento…

Do lợi thế của những ngôn ngữ trên là nền tảng mở, được phát triển và hoàn thiện trong một khoảng thời gian dài, nên việc quản trị Website trên những nền tảng này là khá thuận nhiều và có khả năng tùy biến nhiều thứ. Một người quản trị Website nếu có khả năng quản lý một trong các nền tảng trên thì rất dễ để quản trị những nền tảng và công cụ khác.

Đặc điểm của các CMS kể trên là ngay sau khi chủ website cài đặt nền tảng mở này lên trên Server (máy chủ) thì các tính năng cơ bản của nó đã có đầy đủ rất nhiều tính năng như: quản lý bài viết, quản lý trang, quản lý tài khoản, quản lý liên kết, tag, cấu hình….

2. CMS tự code hay xây dựng, Framework

Chúng hoàn toàn khác với các CMS Open Source kể trên. Khi tự xây dựng CMS, tất cả sẽ được xây dựng lại từ đầu. Mọi thứ sẽ vất vả hơn rất nhiều, nhưng đổi lại bạn có một CMS theo ý mình, có khả năng tùy biến linh hoạt nhất. Bạn có thể xử lý những bài toán đòi hỏi những thứ từ đơn giản tới phức tạp, theo mọi quy trình, mọi yêu cầu mà bạn muốn.

Nhưng có một vấn đề, thường những công ty xây dựng CMS bằng Framework, tự code họ có sự đầu tư, hiểu biết về trải nghiệm người dùng là khác nhau. Bởi vậy, CMS bạn sử dụng có thể thân thiện hoặc là không.

Do đó lời khuyên là nếu nhu cầu bài toán bạn cần là sử dụng CMS tự code, framework. Hãy xin đơn vị thiết kế Website một số demo CMS (phần quản trị) của họ và đánh giá.

3. CMS được build sẵn và mất phí

Đó là các CMS được build sẵn và đóng gói, bạn chỉ việc mua license, đóng phí support hàng năm và yên tâm làm nội dung hoặc bán hàng. Những việc như vận hành hệ thống, sửa lỗi hay nâng cấp đều do đơn vị cung cấp làm. Hệ thống có nhiều chức năng hữu ích có sẵn, hoạt động ổn định.

Các CMS thông dụng hiện nay

Phổ biến hiện nay người ta hay sử dụng WordPress, Magento (Opensource) hoặc làm shop có phí là Shopify…trong đó WordPress thích hợp với các website dạng blog, tin tức, giới thiệu công ty, shop bán hàng nhỏ và vừa… Magento thích hợp làm các website thương mại điện tử. Top các CMS nổi trội:

  • WordPress (Opensource)
  • Magento (Opensource)
  • Joomla (Opensource)
  • Drupal (Opensource)
  • Shopify (Có phí)
  • Và còn nhiều nữa…

Trong các website kể trên thì WordPress chiếm ưu thế hơn cả bởi tính đơn giản, dễ sử dụng và hỗ trợ nhiều plugin của nó.

Có thể bạn muốn xem thêm:

Xem thêm việc làm CMS hấp dẫn lương cao tại TopDev!

Console không chỉ có phương thức log!

Bài viết gốc đăng tải tại CodeLabo.

Người viết: Nguyen Hai Duc

console là công cụ đắc lực hỗ trợ chúng ta trong quá trình phát triển ứng dụng, đặc biệt là khi tìm và sửa lỗi. Tuy nhiên, console còn rất nhiều phương thức khác cũng thú vị và hữu ích không kém. Hãy cùng CodeLabo tìm hiểu trong bài viết này nhé!

console.log

console.log có lẽ là phương thức được sử dụng nhiều nhất để in giá trị của biến ra màn hình.

const name = 'CodeLabo'
console.log('Hello', name) // Hello CodeLabo

Bên cạnh đó, console còn có 3 phương thức khác có tính năng tương tự: .warn.info, và .error.

console.info('CodeLabo - more experiments, more knowledge')
console.warn('Hãy like Facebook Page của CodeLabo nhé!')
console.error('Đừng quên share cho mọi người cùng biết nha!')

Ngoài việc in giá trị, .warn và .info hiển thị kết quả ở một định dạng khác, giúp bạn phân biệt “mức độ nghiêm trọng” của thông điệp, trong khi .error in ra stack trace, giúp bạn xác định lỗi xuất hiện ở đâu.


Bạn có thể dùng tính năng lọc để lựa chọn hiển thị kết quả theo từng loại thông điệp. Tính năng này có mặt ở hầu hết các trình duyệt.

console.trace

Chúng ta cũng có thể in ra stack trace bằng cách sử dụng console.trace.

function hello(name = 'CodeLabo') {
  console.trace('name:', name)
  return `Hello ${name}!`
}

hello()

Kết quả:

EHKOO @ FACEBOOK

Like us on Facebook

Tặng một like thể hiện tình cảm nha!

console.dir và console.dirxml

console.dir in ra JavaScript sau khi đã được định dạng đẹp đẽ.

const fancyThings = {
  car: '🏎️ Ferrari',
  watch: '⌚ Cartier',
  clothing: {
    shoes: '👠 Christian Louboutin',
    dress: '👗 Versace',
  },
  boat: '🛥️ Sunseeker',
}

console.dir(fancyThings)

Riêng console.dirxml thì in ra markup của nút DOM. Ví dụ:

<!DOCTYPE html>
<html lang="en">

<head>
  <!-- ... -->
</head>

<body>
  <main>
    <h1>hello</h1>
    <p>this is a <strong>text</strong></p>
  </main>

  <script>
    console.dirxml(document.body);
  </script>
</body>

</html>

Kết quả trên Google Chrome:

console.assert

console.assert sẽ nhận 2 tham số. Nếu tham số thứ nhất trả về false, tham số thứ 2 sẽ được in ra màn hình.

// 1 + 1 == 2, trả về true, không có gì được in ra cả
console.assert(1 + 1 === 2, '1 + 1 khác 2')

// 1 + 1 == 3 trả về false, '1 + 1 khác 3' sẽ được in ra
console.assert(1 + 1 === 3, '1 + 1 khác 3')

console.clear

Bạn có thể gọi phương thức console.clear() để xóa đi những kết quả đã được in ra trước đó. Hoặc bạn có thể nhấn Ctrl + L trong Chrome, hoặc Ctrl + Shift + L trong Firefox, để đạt được kết quả tương tự.

console.clear()

console.count và console.countReset

Mỗi lần bạn gọi đến console.count(), phương thức này sẽ tự động tăng lên 1. Bạn có thể truyền vào một nhãn tùy ý để đánh dấu các bộ đếm khác nhau. Và bạn dùng console.countReset(label) để quay ngược bộ đếm về lại 0.

const arr = [1, 2, 3, 4, 5]
arr.forEach(nb => {
  if (nb % 2 === 0) {
    console.count('chẵn')
  } else {
    console.count('lẻ')
  }
})

// lẻ: 1
// chẵn: 1
// lẻ: 2
// chẵn: 2
// lẻ: 3

Đo thời gian thực thi

Để đo thời gian thực thi của một đoạn mã, bạn có thể dùng console.time và console.endTime. Phương thức console.time(label) nhận vào một chuỗi dùng làm nhãn cho bộ đếm giờ. Sau đó gọi đến console.endTime(label) với nhãn cùng tên, để hiển thị thời gian thực thi.

console.time('fetching data')
fetch('https://jsonplaceholder.typicode.com/users')
  .then(d => d.json())
  .then(() => console.timeEnd('fetching data'))

// fetching data: 424ms

Đặt kết quả vào nhóm

Sử dụng console.group và console.groupEnd để nhóm các giá trị được hiển thị lại với nhau. Ta cũng có thể đặt tên cho các group, và group này có thể nằm trong group khác.

console.group('🖍️ colors')
console.log('green')
console.log('orange')
console.group('HEX')
console.log('#1AB374')
console.log('#FF7B5F')
console.groupEnd()
console.log('blue')
console.groupEnd()

console.table

Phương thức console.table giúp chúng ta hiển thị array hoặc object dưới dạng bảng.

function Single(title, singer, year) {
  this.title = title
  this.singer = singer
  this.year = year
}

const s = new Single('Có ai thương em như anh', 'Tóc Tiên', '2018')

console.table(s)

Sử dụng CSS Style

Có bao giờ bạn mở console khi đang xài Facebook và nhận được thông báo như thế này:

Họ đã làm điều đó như thế nào? Hóa ra, ta có thể áp dụng CSS style trong console.log bằng cách dùng kí tự đặt chỗ %c.

console.log(
  'Hello %cCodeLabo%c!',
  'color: #1ab374; font-weight: bold; font-size: 2rem; text-shadow: 0 0 5px rgba(0,0,0,0.2);',
  'color: #ff7b5f; font-weight: bold; font-size: 2rem; text-shadow: 0 0 5px rgba(0,0,0,0.2);',
)

Mỗi %c sẽ định dạng cho những ký tự phía sau nó. Kết quả là:

Bên cạnh %c, console còn hỗ trợ những kí tự đặt chỗ khác như %o%f hay %d. Bạn có thể xem chi tiết ở đây.

Kết

Ngoài việc cung cấp phương thức console.log() rất hữu dụng khi tìm và sửa lỗi, console còn có những phương thức khác cũng rất tiện dụng trong quá trình phát triển dự án. Bạn có biết cách sử dụng console nào sáng tạo hơn nữa không? Hãy cùng chia sẻ nhé.

Có thể bạn quan tâm:

Xem thêm việc làm IT job trên TopDev

TopDev via ehkoo

The Product Mindset — Tư duy làm sản phẩm

Người viết: Đoàn Văn Tuyển

Lần trước mình đã từng viết về Product Mindset (Tư duy làm sản phẩm), nhưng sau gần 2 năm trải nghiệm những gì mình nghĩ về Product Mindset có chút thay đổi. Giờ mình xin chia sẻ lại những gì mình hiện tại mình cảm nhận. Dưới đây mình chỉ chia sẻ những thể hiện bên ngoài của của một tư duy làm sản phẩm tốt. (Nó chỉ là trải nghiệm cá nhân nên đôi lúc nó viết không được hoàn hảo, không được bài bản hay quy củ)

1. Deliver value, not feature

Đây chính là thứ đầu tiên mình muốn nói. Kết quả của sản phẩm không phải là những tính năng cho người dùng, cho hệ thống, mà là giá trị đem lại. Người dùng không cần những tính năng, họ cần những thứ giải quyết được vấn đề của họ. Để hiểu được điều này chúng ta cần thực sự hiểu được giá trị thực sự mà những thứ mà chúng ta làm ra mang lại cho người dùng. Hiểu được việc này thì team sẽ thực sự hiểu tại sao ta cần phải làm nó và thực sự làm sản phẩm CÓ ÍCH.

Để làm được điều này thì team cần biết được VẤN ĐỀ LÀ GÌ, chứ không chỉ GIẢI PHÁP LÀ GÌ. Business Analyst (PO/PM) phải hiểu được giá trị mà việc cần làm mang lại từ đó mô tả cho team Developer cách thức để giải quyết vấn đề (ko phải chỉ là tính năng là gì). Developer cũng phải hiểu được VẤN ĐỀ LÀ GÌ để có thể đưa ra được cách lập trình, tính năng phù hợp và có thể góp ý ngược lại với BA. Nếu developer chỉ hiểu tính năng thì chắc chắn sản phẩm họ deliver sẽ bị phụ thuộc vào BA rất nhiều. Nếu phương án của BA không hoàn toàn hợp lý thì có thể tính năng đưa ra chưa chắc đã giải quyết được vấn đề. Ngoài ra nếu không hiểu được câu hỏi TẠI SAO PHẢI LÀM mà chỉ biết LÀM THẾ NÀO (HOW) thì thông thường Developer yêu cầu BA mô tả phải thật sự rõ ràng.

Image result for value illustrationĐối với các team khác, nếu các bạn chỉ mô tả cho team Product tính năng thì có thể thứ bạn nhận được không hoàn toàn phù hợp. Nếu tính năng đó bắt nguồn từ đối tác thì chúng ta có thể mất 3 lần trao đổi để đến được người trực tiếp giải quyết vấn đề: Đối tác => Sale => BA => Developer. Với việc mô tả qua 3 cầu như vậy rất dễ có sự sai lệch thông tin, chưa kể góc nhìn của Sale không phải góc nhìn sản phẩm nên mô tả không triệt để. Do vậy thông thường BA (thậm chí Developer) cần phải được ra ngoài để nói chuyện với đối tác để có thể hiểu được phần nào những thứ đối tác THỰC SỰ mong muốn.

Ngoài ra một vấn đề nữa khiến cho sản phẩm không được như mong muốn là việc không có sự đồng nhất về cách đánh giá thế nào là hoàn thành tính năng / vấn đề (Define of DONE). Nếu không có được mô tả về Define Of DONE và có sự đánh giá bằng con số thì rất dễ có sự tranh cãi giữa các team sau khi vấn đề được giải quyết.

  Máy học - Machine Learning và một vài hạn chế.

2. Data-Driven Development

Một vấn đề nữa mình muốn rất rất muốn nói đến là vai trò của dữ liệu trong việc đưa ra quyết định. Data-Driven là thứ bắt buộc phải làm theo để có thể xây dựng sản phẩm thành công. Mọi thứ cần được đo đạc ở tất cả các khâu. Việc đo đạc nên được thực hiện trong hầu hết các bước và nó phải là nền tảng của việc ra quyết định.

Ví dụ ở bước đánh giá một lỗi phát sinh, một tính năng vừa hoàn thành… thì dữ liệu là thứ bắt buộc phải có để đưa ra quyết định. Ví dụ nếu ta chỉ nhìn vào thể hiện bên ngoài của lỗi thì rất khó đánh giá giá trị mà mình có thể mang lại sau khi sửa lỗi hoặc đánh giá hậu quả. Ví dụ cùng một thể hiện bên ngoài nếu ta đo được lỗi ảnh hưởng khiến cho doanh thu công ty sai lệch để cả trăm triệu đồng sẽ rất khác lỗi chỉ ảnh hưởng một vài ngàn đồng, lỗi ảnh hưởng đến toàn bộ đối tác sẽ rất khác lỗi chỉ ảnh hưởng rất ít đến đối tác nhỏ. Như vậy data sẽ rất cần để đánh giá giá trị của việc ta làm là gì => Từ đó đưa ra được quyết định lệu ta sẽ làm gì tiếp theo.

Image result for data driven illustration

Tương tự như vậy việc đánh giá một tính năng, một yêu cầu được hoàn thành cũng cần phải có các con số. Nếu ta biết được việc ta làm ảnh hưởng thế nào thì ta mới có cơ sở để đưa ra quyết định ta có tiếp tục làm hoặc nếu có một tình huống tương tự nếu ta chưa có dữ liệu thì cũng có thể phỏng đoán được kết quả. Túm lại nếu ta không đánh giá được kết quả ta tạo ra bằng một con số cụ thể thì việc ta có làm hay không làm cũng chả khác gì nhau, từ đó khiến cho ta có thể thấy việc ta đã làm là hoàn toàn vô ích.

Một việc cần phải xem xét là thang đo để đánh giá, từ đó ra quyết định. Việc lựa chọn thang đo quyết định đến hơn 50% giá trị của việc đo lường. Nếu ta chọn sai thang đo thì giá trị của dữ liệu rất thấp. Thang đo phải được đánh giá rất cẩn thận để có được dữ liệu có giá trị. Một điều cần ghi nhớ, không phải mọi dữ liệu đều có ý nghĩa như nhau. Thông thường ta không thể đo đạc mọi thứ thế nên câu hỏi luôn phải đặt ra là dữ liệu là dữ liệu quan trọng nhất trong tình huống này. Và bạn phải luôn ghi nhớ: không phải cái gì tăng cũng tốt, không phải cái gì giảm cũng xấu, không phải số to đã là to, không phải số nhỏ đã là nhỏ. Dữ liệu luôn phải đặt vào context cụ thể mới có ý nghĩa.

3. Focus on the Product, Not the Code.

Một điều nữa ta cần ghi nhớ, chúng ta không phải là những công nhân lập trình, không phải là thợ xây. Do đo đó Team làm sản phẩm không nên chỉ chú trọng vào kỹ thuật. Một lần nữa mình nhắc lại cái mà khách hàng, đối tác, các team khác cần là giá trị chứ không phải là công nghệ, không phải công sức ta bỏ ra. Tất nhiên khi ta lựa chọn một công nghệ mà nó giúp tạo ra giá trị lớn (và phù hợp) thì luôn được hoan nghênh. Nhưng công nghệ có tốt đến mức nào mà không giải quyết được vấn đề thì cũng vô nghĩa. Thông thường Developer hay bị chú tâm quá nhiều vào công nghệ, họ có thể điên cuồng với một công nghệ mới nhưng thực sự đó không phải là thứ ta nên quan tâm đầu tiên.

Đôi khi chúng ta cần đánh đổi giữa công nghệ, những thức “tốt” để tập trung vào giải quyết bài toán sản phẩm. Một số thang đo cần được đưa vào để đánh giá ngoài chuyện nó có “tốt” không như: công nghệ này đã thực sự ổn định chưa? Cộng đồng có lớn không? Người có dễ tìm không? Nó có dễ phát triển không, vận hành hay không? Đôi khi ta phải đánh đổi giữa những thứ về kỹ thuật để tập trung tạo ra sản phẩm tốt hơn. Quan điểm của mình là luôn lựa chọn những công nghệ đơn giản để giải quyết vấn đề, theo nguyên tắc 80/20.

Image result for code product illustration

Tuy nhiên thực sự thì sản phẩm không chỉ gồm những yêu cầu tính năng. Sản phẩm còn bao gồm cả những yêu cầu phi chức năng (Non-Functional Requirements). Những yêu cầu chỉ những người thực sự hiểu về kiến trúc hệ thống mới đưa ra được. Thông thường sản phẩm ngắn hạn thì Non-Functional Requirements ít được đặt ra, nhưng sản phẩm dài hạn thì điều này cần đánh giá. Những yêu cầu như Coding Convention, Coding Style, System Architect cần được viết/vẽ ra một cách rõ ràng. Nếu ta không đưa ra và làm tốt thì rất dễ đưa đến những sản phẩm có nhiều món nợ kỹ thuật (Technical Debt)

4. UX

Trong quan điểm của mình đối với team Product thì User ko chỉ gồm những đối tượng mà sản phẩm thực sự hướng tới (End-User, Đối tác). Mà user bao gồm cả những thành phần tham gia phát triển sản phẩm (Developer Team, BA), Các team nội bộ và đối tác. Khi đặt vấn đề như thế thì trải nghiệm người dùng bao gồm cả những trải nghiệm cho team phát triển. Với góc nhìn như thì ta để ý đến trải nghiệm của cả những “user” phát triển sản phẩm. Trong thực tế thì ta có thể thấy: BA viết Requirements phục vụ Developer & Tester, Developer có user là Tester & Debops, Tester lại có user là Developer… Như vậy thực tế khi xây dựng sản phẩm chúng ta cần hình dung ra toàn bộ quá trình để xây dựng sản phẩm, hình dung việc team tham gia vào vận hành sản phẩm khác như team sale, team marketing, team vận hành…

Image result for code product illustration

Tiếp để hiểu được UX cho user bên ngoài thì đầu tiên ta cần biết: user là ai? User có tính chất gì? User biết gì? User sử dụng tính năng X trong tình huống gì? Những sai sót, hiểu nhầm hay gặp phải? Thông thường khi Developer xây dựng một tính năng, chúng ta chỉ nhìn vào tính năng chúng ta cần xây dựng là gì, bỏ quên mất người sử dụng. Nếu chúng ta không tự đặt mình vào tình huống của người sử dụng, tinh thần, khả năng của người sử dụng thì chúng ta có thể xây dựng tính năng cho chính chúng ta. Bạn phải luôn ghi nhớ rằng người dùng của chúng ta hoàn toàn không giống chính chúng ta, họ thường không có được suy nghĩ và nền tảng để hiểu hết những gì chúng ta hiểu. Từ đó ta phải xây dựng tính năng mà người ta không cần phải “động não” (Mình hay nói vui là chỉ cần IQ kém cũng dùng được, hay như trong quyển sách gối đầu giường về UX “Don’t Make Me Think”). Các tính năng phải bản thân nói giải thích chính nó, chúng không nên cần có một hướng dẫn sử dụng để có thể sử dụng. Nếu tính năng cần có hướng dẫn sử dụng thì coi như tính năng vô ích.

Thực ra mình cũng không phải là người làm tốt về UX, thế nên để hiểu sâu hơn và rõ ràng hơn mọi người có thể xem slide mình chia sẻ bên dưới của Tùng Jacob (Slide là video khá dài kéo dài đến 1h)

5. Minimum Viable Product:

Đầu tiên ta cần hiểu MVP là gì? Tại sao cần có MVP? MVP là cách thức xây dựng sản phẩm đơn giản nhất có thể nhưng vẫn đảm bảo những tính năng cơ bản cần thiết và có thể giúp ta đánh giá được kết quả, từ đó đưa ra phương án tiếp theo là gì. Tại sao việc này lại quan trọng? Thực tế thị trường thường biến đổi rất nhanh, nếu ta chọn cách làm phân tích, thiết kế, triển khai theo mô hình thông thường thì sau khi sản phẩm được đưa ra thị trường nó đã lỗi thời. Ngoài ra cũng có thể những gì ta nghĩ chưa chắc đã đúng, điều này đôi khi rất khó để có thể đoán biết được. Do vậy cần một phương án có thể nhanh chóng kiểm chứng được những gì ta nghĩ và MVP là một trong những cách thức kiểm chứng như vậy.

Theo như trong cuốn sách “Lean Startup” (Khởi nghiệp tinh gọn), ta có thể triển khai MVP theo 3 bước đơn giản và xoay vòng: Xây dựng — Đo Lường — Rút ra bài học. Việc này được thực hiện lặp đi lặp lại, qua mỗi vòng lặp sản phẩm sẽ được thay đổi và sẽ có một diện mạo khác. Để triển khai MVP thì bạn luôn nhớ đến 3 bước trên. Vậy mọi thứ phải bắt đầu từ đâu: Để lựa chọn được phương thức để triển khai MVP bạn phải quay lại đọc các phần 1–2–3–4 trước sẽ hình dung ra được những gì mình phải làm: Bắt đầu từ câu hỏi điều gì tạo ra giá trị, từ đó hiểu được điều quan trọng nhất là gì (keypoint là gì), từ đó có thể chỉ lựa chọn một mục tiêu quan trọng nhất chứ ko đưa ra quá nhiều mục tiêu. Tiếp theo mình cần đo lường những chỉ số quan trọng từ đó đưa ra được đánh giá tốt nhất. Tiếp theo là trong lúc triển khai, với suy nghĩ rằng lập trình không phải là thứ quan trọng nhất ta nên lựa chọn những phương án đơn giản, dễ đánh giá thay cho những giải pháp “tốt” khác. Tương tự khi tìm hiểu về UX chúng ta có thể hình dung đối tượng chúng ta cung cấp là ai, chỉ cần tập trung UX cho user thực sự “tiềm năng”, những user phục vụ việc mình nhanh chóng đưa ra được đánh giá và quyết định tiếp theo.

Image result for product mindset

Sách tham khảo: 
Lean Analytics
Lean Startup
Don’t Make Me Think

Slide về UX: 
https://www.youtube.com/watch?v=Z6icneN4jEY

Có thể bạn quan tâm: 

Xem thêm việc làm Android Developer trên TopDev 

Bài viết gốc được đăng tải tại Medium

  Kỹ thuật phần mềm vs Khoa học máy tính - Nên chọn ngành nào/
  Máy học - Machine Learning và một vài hạn chế.

Kendo UI – HTML5

Mô tả công việc - Vị trí lập trình Front-end

Kendo UI là gì?

Kendo UI là 1 framework dựa trên nền tảng HTML5 và jQuery hỗ trợ chúng ta toàn diện trong việc xây dựng các ứng dụng Web hiện đại một cách dễ dàng và linh hoạt đến không ngờ.

Có thể bạn sẽ nghĩ rằng: Kendo UI chắc cũng giống như jQuery UI – một framework cũng được xây dựng dựa trên jQuery đang được sử dụng phổ biến nhất hiện nay.

Nhưng thật sự jQuery UI chỉ hỗ trợ mạnh việc xây dựng ứng dụng Web chuyên chạy trên Desktop và chỉ hỗ trợ một phần nho nhỏ để phát triển ứng dụng Web chạy trên Mobile.

Còn Kendo UI framework mà chúng ta đang cùng tìm hiểu thì lại hỗ trợ rất mạnh cả 2 phần này, ngoài ra Kendo UI còn rất mạnh trong việc trực quan hóa dữ liệu Data Visualization (Kendo UI DataViz) giúp ứng dụng Web trông và hành xử y như các ứng dụng thuần Mobile, hay thuần Desktop.

Như vậy có thể thấy Kendo UI bao gồm 3 phần chính:

  • Kendo UI Web: Hỗ trợ xây dựng một ứng dụng Web trên Desktop.
  • Kendo UI Mobile: Hỗ trợ xây dựng ứng dụng Web trên Mobile.
  • Kendo UI DataViz: Hỗ trợ thiết lập và tương tác dữ liệu trực quan.

Ngoài ra, Kendo UI còn có cả tính năng Kendo UI-Server Swapper độc đáo giúp chúng ta xây dựng 1 ứng dụng HTML5 mà không cần phải viết code JavaScript. Để làm được điều đó Kendo UI phát triển một số thư viện dưới dạng các helpers trên Server, Kendo UI-Server Swapper sẽ tiếp nhận các câu lệnh đơn giản của lập trình viên trong mã nguồn các ngôn ngữ lập trình ASP, PHP hoặc JSP và sau đó sẽ tự phát sinh ra (tự render) các mã HTML và JavaScript cần thiết.

Cài đặt

Chúng ta có thể download trọn bộ Kendo UI tại trang chủ của Kendo UI.

Sau khi download Kendo UI về và giải nén, chúng ta có thể thấy được cấu trúc thư mục như sau:

  • example: chứa các ví dụ minh họa
  • js: chứa file JavaScript đã được tối ưu hóa
  • src: chứa mã nguồn của Kendo UI (phần này sẽ không có trong bảng dùng thử)
  • styles: chứa các file CSS và theme
  • swapper: chứa thành phần server-side swapper đã đề cập bên trên.

Để sử dụng KenDo UI cho trang HTML, chúng ta cần include các tập tin CSS và JavaScript

Sử dụng

Bước 1: Download Kendo UI Web và giải nén
Bước 2: Copy thư mục js và style vào thư mục chính trong ứng dụng web của bạn
Bước 3: Include Kendo Ui Web JavaScript và CSS vào phần thẻ head trong trang HTML.

<html>
        <head>
            <title>Welcome to Kendo UI!</title>
            
            <link href="styles/kendo.common.min.css" rel="stylesheet" />

            
            <link href="styles/kendo.rtl.min.css" rel="stylesheet" type="text/css" />

            
            <link href="styles/kendo.default.min.css" rel="stylesheet" />

            
            <link href="styles/kendo.default.mobile.min.css" rel="stylesheet" type="text/css" />

            
            <script src="js/jquery.min.js"></script>

            
            <script src="js/kendo.all.min.js"></script>
        </head>
        <body>
            Hello World!
        </body>
        </html>

 

Bước 4 : Khởi tạo Widget.
Ví dụ sau minh hoạ làm thế nào để khởi tạo widget DatePicker:

<input id="datepicker" />
    <script>
    $(function() {
        // Initialize the Kendo UI DatePicker by calling the kendoDatePicker jQuery plugin
        $("#datepicker").kendoDatePicker();
    });
    </script>
<html>
    <head>
        <title>Welcome to Kendo UI!</title>
        <link href="styles/kendo.common.min.css" rel="stylesheet" />
        <link href="styles/kendo.default.min.css" rel="stylesheet" />
        <script src="js/jquery.min.js"></script>
        <script src="js/kendo.all.min.js"></script>
    </head>
    <body>
        <input id="datepicker" />
        <script>
            $(function() {
                $("#datepicker").kendoDatePicker();
            });
        </script>
    </body>
</html>

Xem thêm

Các bài viết khác về cách bắt đầu với Kendo UI:

  • Kendo UI CDN Services
  • Include Only What You Need
  • JavaScript Prerequisites
  • Initialize Widgets Using jQuery Plug-Ins
  • Initialize Widgets Using Markup
  • Access Widget DOM Elements: wrapper and element
  • Set Data Attributes
  • Widget Methods and Events
  • Destroy Widgets
  • Edit Widgets
  • Create Custom Widgets
  • Bower Packages
  • NuGet Packages

Tài liệu tham khảo

https://docs.telerik.com/kendo-ui/introduction
https://docs.telerik.com/kendo-ui/intro/installation/getting-started

Xem thêm các vị trí tuyển dụng lập trình HTML5 lương cao tại Topdev.

Làm sao Google cho ra kết quả tìm kiếm nhanh đến thế?

Làm sao Google cho ra kết quả tìm kiếm nhanh đến thế?

Bài viết được sự cho phép của tác giả Ngo Thang

Vào thời đại công nghệ như ngày nay thì việc tìm kiếm thông tin cũng trở nên rất quan trọng. Thử hỏi nếu 1 ngày Google không hoạt động thì thế giới sẽ như thế nào nhỉ? Chắc mình sẽ bị rơi vào thời kì đồ đá mất.

Dùng nhiều Google nhưng nhiều lúc băn khoăn không biết vì sao Google lại tìm kiếm cho ra kết quả nhanh như vậy.

Chỉ với từ khoá “lập trình hướng đối tượng” mà Google trả về trong 0.42 giây trong tổng 60 triệu kết quả. Quá nhanh.

Không chỉ tốc độ trả về nhanh mà kết quả trả về cũng khá gần với mục đích tìm kiếm của người dùng nên Google đã trở thành 1 trong những công cụ có lẽ mạnh nhất trên thế giới.

Vậy cùng nhau tìm hiểu xem vì sao Google lại trả về kết quả nhanh đến như vậy nhé.

Mục đích của bài viết:

  • Giúp các bạn có cái nhìn chung về 1 công cụ tìm kiếm nó gồm những bộ phận nào, vì sao nó hoạt động lại nhanh đến như vậy.
  • Bài viết sẽ không giải thích sâu về từng bộ phận, mà chỉ nói qua về từng bộ phận để ai cũng có thể hiểu được.

Kiến trúc Search Engine

Search Engine gồm 3 bộ phận chính. Đó là Search ServerIndexSearch Backend.

Trong đó:

  • Search Server đảm nhiệm việc trả về kết quả tìm kiếm cho người dùng.
  • Seach Backend đảm nhiệm việc thu thập thông tin toàn bộ website trên toàn thế giới.
  • Index giống như 1 cơ sở dữ liệu được sử dụng bởi Search Server và Search Backend.

Nhiệm vụ chính của Search Server là trả về kết quả tìm kiếm của người dùng nhanh nhất có thể. Bởi vì nếu không trả về ngay lập tức mà mất 10s, 1 phút, 2 phút mới trả về kết quả thì quả thực sẽ không thể trở thành 1 công cụ tìm kiếm được. Do đó Search Server sẽ được thiết kế để trả về kết quả nhanh nhất có thể.

Mặt khác, nhiệm vụ của Search Backend thì khác hoàn toàn với Search Server. Cho dù xử lí mất 5p, 10p hay 1 tiếng đi chăng nữa thì cũng không thành vấn đề. Miễn là nó thu thập dữ liệu từ toàn bộ website trên toàn thế giới và tạo ra Index mà Search Server dễ dùng là được.

Nhiệm vụ chính của thằng Index là lưu thông tin toàn bộ dữ liệu đã được thu thập từ Search Backend. Khi người dùng tìm kiếm, Search Server chỉ cần tìm trong Index và trả về kết quả là xong. Chứ không phải lúc đó mới bắt đầu đi thu thập dữ liệu và trả về đâu nhé.

Ví dụ như khi tìm kiếm với từ khoá “lập trình” thì khi đó từ khoá “lập trình” đã có sẵn trong Database (hay là Index) của Google rồi. Và nó chỉ trả về kết quả là xong.

Chính vì điều đó mà khiến cho Search Server luôn trả về kết quả ngay tức khắc là vì thế.

Đến đây ít nhiều chúng ta cũng đã hiểu được vì sao Google lại hoạt động nhanh đến thế. Vậy chúng ta thử đi tìm hiểu xem cụ thể bên trong nó hoạt động như nào nhé.

Search Server thì tốc độ là số 1

Bây giờ chúng ta thử tìm hiểu xem Search Server hoạt động thế nào nhé.

Về cơ bản thì Search Server nó cũng không khác gì Web Server cả. Nó chủ yếu đảm nhiệm những nhiệm vụ chính sau:

  • Quản lí truyền thông với người dùng
  • Phân tích request từ người dùng
  • Tìm kiếm thông tin cần thiết từ Index
  • Trả kết quả về cho người dùng

Quay lại với ví dụ bên trên, giả sử như người dùng tìm kiếm với từ khoá “lập trình”. Khi đó lúc này ở Index đã thực sự có kết quả về “lập trình” rồi. Và Search Server chỉ cần lấy kết quả từ Index trả về cho người dùng là xong nhiệm vụ.

Trong trường hợp mà Index không có kết quả nào, thì khi đó Search Search trả về kết quả là “Hiện tại không tìm thấy kết quả nào” đến cho người dùng.

Do đó việc tổ chức dữ liệu trong Index để làm sao mà Search Server có thể lấy nhanh nhất là 1 điều vô cùng quan trọng.

Search Backend luôn chuẩn bị trước dữ liệu

So với Search Server thì Search Backend quả thực nó phức tạp hơn rất nhiều. Về cơ bản Search Backend sẽ bao gồm 2 thành phần chính đó là “Crawling” và “Tạo Index“.

Crawling là có nhiệm vụ đi thu thập toàn bộ trang web trên toàn thế giới về để xử lý. Vì công việc này vô cùng mất thời gian nên nó đã phân tách ra thành nhiều bộ phận con hơn để xử lý, đó là Crawler.

Hiện nay trên toàn thế giới chắc phải có đến tỉ tỉ website mất. Vậy mà Google đi thu thập từng đó website về để phục vụ cho người dùng thì quả thực quá kinh khủng.

Nhưng vì quá trình crawl, thu thập đến việc tạo Index là vô cùng mất thời gian. Nên bạn nào có blog riêng mà sau khi viết bài xong, search trên Google nó không ra là vì thế. Phải đợi Google crawl đến trang web của mình thì lúc đó các bạn search trên Google mới ra được.

Những trang web mà Crawler thu thập sẽ lưu tạm thời vào 1 nơi giống như cơ sở dữ liệu, cái này được gọi là Repository (kho).

Bộ phận tạo Index (Index Creation) sẽ lấy trang web từ Repository ra để phân tích, xử lý và cuối cùng là tạo ra Index để cho Search Server dùng.

Đối với Search Engine thì đây là 1 công việc vô cùng vô cùng mất thời gian. Chính vì luôn có thằng tạo trước dữ liệu như vậy mà đã làm cho Google luôn trả về kết quả ngay như tức thì.

Vậy khi nào thì Google sẽ crawl trang web của mình?

Với trang web nào nhiều người yêu thích, nội dung chất lượng thì luôn luôn được ưu tiên crawl trước. Những trang web nào nội dung kém chất lượng thì sẽ mất tầm 3 đến 1 tuần mới được crawl.

Làm thế nào để thúc Google crawl trang của mình?

Google cung cấp 1 trang để gửi yêu cầu thực hiện crawl. Chỉ cần vào đó đăng kí tên website, gửi nội dung trang muốn crawl là được. Còn nếu không thực hiện thì mình khẳng định sẽ mất tầm từ 3 đến 7 ngày mới được crawl.

Index là linh hồn của việc tìm kiếm

Nhiệm vụ chính của Index là lưu dữ liệu 1 cách an toàn và giúp Search Server trả về kết quả nhanh nhất có thể. Để dễ hình dùng thì chúng ta có thể xem Index như là 1 Database.

Trong Index có rất nhiều thông tin, phù hợp với nhiều mục đích tìm kiếm khác nhau.

Ở trong 1 Search Engine thì Index chính là 1 “cấu trúc dữ liệu” mà chỉ có Search Engine mới có thể hiểu được.

Nên việc thiết kế Index như nào, tổ chức dữ liệu ra sao để cho Search Server có thể query và trả về kết quả nhanh nhất có thể là điều vô cùng quan trọng. Và bài hôm nay mình sẽ không đi sâu vào giải thích cách tổ chức dữ liệu của Index nữa. Vì như thế có thể sẽ rất dài và càng làm cho bài viết trở nên phức tạp.

Tổng kết

1 Search Engine sẽ bao gồm 3 bộ phận sau:

  • Search Server: nhận yêu cầu từ người dùng, truy vấn trong Index để lấy kết quả và trả kết quả về cho người dùng.
  • Search Backend:Có nhiệm vụ đi thu thập thông tin của toàn bộ trang web trên toàn thế giới, phân tích, xử lý và tạo ra Index để dùng cho Search Server. Search Backend này hoạt động 24/24 không ngừng nghỉ.
  • Index giống như 1 database được tổ chức dữ liệu hợp lý giúp cho Search Server có thể truy vấn 1 cách nhanh nhất có thể.

Các bạn thấy thế nào? Đã hình dung được tại sao mà Google luôn trả về kết quả nhanh như vậy chưa ak?

Mặc dù bài viết này không giúp các bạn tạo ra được 1 Search Engine nhưng ít nhiều cũng giúp các bạn có 1 chút hình dung Search Engine nó làm việc như thế nào.

Và đây là quyển mình đã tham khảo. Mình tìm mãi không thấy quyển tiếng anh đâu. Nên nếu ai biết tiếng nhật thì mình khuyên nên đọc quyển này. Theo mình cảm nhận khá là hay. Từ việc Search Engine làm việc thế nào cho đến việc tổ chức lưu dữ liệu ra sao, tối ưu server thế nào để cho chi phí vận hành là thấp nhất…

Xem thêm việc làm Software Developers trên TopDev

TopDev via Nghệ thuật Coding

Kiến thức ngành lập trình – Bạn có đang giới hạn bản thân?

Kiến thức ngành lập trình

Trước khi định hướng theo chuyên ngành, không chỉ sinh viên ngành lập trình mà còn là bộ phận sinh viên nói chung còn khá thụ động trong việc tiếp nhận kiến thức. Trong khi đó, kiến thức ngành lập trình lại rất nhiều và luôn thay đổi, cập nhật từng ngày.

Bài viết này sẽ phân tích kỹ hơn những lầm tưởng mà sinh viên hay gặp phải và làm mất điểm trong mắt nhà tuyển dụng.

“Em chưa được học cái này”

Câu nói thường gặp ở đa số các bạn sinh viên khi giải thích về những khiếm khuyết của mình thường là “Mấy cái này trường em không dạy”. Thật ra, với lượng kiến thức khổng lồ và luôn cập nhật trong ngành lập trình, những gì bạn biết hôm nay sang ngày mai đã trở nên cũ kỹ. Do đó, để kịp với sự thay đổi nhanh chóng này, cách tốt nhất là tự học.

Đại học là bước đệm cần thiết, nhưng chưa đủ vì những kiến thức ở đại học chỉ là nền tảng về lập trình, như cấu trúc hay cơ sở dữ liệu. Còn những bước cao hơn như code như thế nào, cách sử dụng ngôn ngữ lập trình ra sao, thì chính bạn phải tự dạy cho bản thân.

Đây cũng chính là lầm tưởng đầu tiên trên con đường học vấn, khi bị động trong việc tiếp nhận kiến thức. Nếu quá phụ thuộc vào những gì được dạy mà không tự tìm hiểu lộ trình học lập trình, yêu cầu công việc, xem xét và bổ sung cho bản thân, thì kiến thức của bạn sẽ nhanh chóng lỗi thời và cản trở sự thăng tiến trong công việc.

Nhà tuyển dụng giờ đây cũng không còn quá đề cao tấm bằng Đại học, mà chỉ quan tâm đến kỹ năng chính của bạn cũng như kinh nghiệm làm việc. Vì thế, những chuyện như kiến thức bạn có bắt nguồn từ đâu, do trường dạy hay tự tìm hiểu, đó là câu chuyện của riêng bạn.

Xem thêm các việc làm hấp dẫn tại TopDev

Biết nhiều là sẽ giỏi?

Mô hình hoàn hảo khi hiểu biết về một lĩnh vực là theo hình chữ T. Có nghĩa là không chỉ hiểu chuyên sâu về một thứ (chữ I) mà còn có kiến thức tổng quan về các khái niệm khác (như dấu gạch ngang trên đầu).

Phần lớn độc giả tại Việt Nam khá phong trào, và khiếm khuyết Tư duy phản biện (Critical Thinking). Khi thích tác giả nào thì ủng hộ ý kiến của tác giả đó, không thích cây bút nào thì bài trừ và không tiếp nhận.

Tuy nhiên, cách tiếp cận kiến thức như vậy sẽ làm hạn chế tầm nhìn của lập trình viên. Thay vào đó, hãy tham khảo từ nhiều nguồn, tập cách kiểm chứng thông tin khi tiếp nhận, không “nuốt chữ” của tác giả ruột chỉ vì nó nghe khá logic, …

Tổng kết

Những rào cản mà lập trình viên thường gặp chính là tự giới hạn kiến thức với nền tảng từ những gì “được dạy”, và chưa có tư duy phản biện khi tiếp nhận thông tin/kiến thức. Nếu khắc phục được và tránh khỏi hai vấn đề trên, bạn đã sẵn sàng là dev chính hiệu!

Có thể bạn quan tâm:

Cách đặt nút “Cancel” trong thiết kế UX tối ưu nhất

cách đặt nút cancel trong thiết kế UX

Bài viết được sự cho phép của tác giả Ngo Thang

Trong design, nút cancel ngoài cái tên gọi là cancel ra, nó còn 1 vài cái tên gọi khác nữa.「Not Now – Không làm bây giờ」 hay「Maybe Later – Làm lúc khác」 là 1 trong những ví dụ đó.

Nhưng đôi khi có 1 số trường hợp mà nút Cancel không thể đặt là Cancel hay những tên gọi tương tự khác. Vì có thể làm người dùng khó hiểu, hay nói cách khác sẽ khó thể thực hiện được hành động CTA (Call to Action).

Call to Action (CTA): là thuật ngữ viết tắt của call to action trong quảng cáo Google. Chúng được thể hiện thông qua văn bản hoặc hình ảnh nhằm mục đích kêu gọi người xem phải hành động bằng những cú click chuột. Như vậy, hiểu một cách đơn giản, CTA có nhiệm vụ tạo ra tỉ lệ chuyển đổi từ người dùng thành khách hàng tiềm năng.

Vậy chúng ta hãy cùng đi xem cách đặt nút Cancel trong thiết kế UX sao cho tối ưu nhất. Khi nào nút Cancel không nên đặt là Cancel các bạn nhé.

  Hiểu tất tần tật về UX Design với UX360: User Experience in a nutshell.

Phòng chống ấn cancel “nhầm”

Ví dụ như có 1 màn hình “cancel subscription” như bên dưới.

Khi nào nút "Cancel" không nên đặt là "Cancel"

Đây là sự nhầm lẫn của nút cancel. Nếu như chúng ta đặt 1 cái nút Cancel ở ngay bên trên nút Cancel Subscription thì theo các bạn điều gì sẽ xảy ra?

Như ở cái màn hình bên trái. Có thể dịch đơn giản như sau: Bạn có muốn huỷ subscription không?

  • Nút bên trên là “Huỷ”.
  • Nút bên dưới là “Huỷ subscription”.

Nếu để 2 nút như này đúng quả thật gây khó hiểu thật. Cả 2 nút đều là “Huỷ”. wtf @@

Vậy nếu đặt 2 nút như này thì có thể gây ra vấn đề gì?

Đó chính là người dùng có thể ấn nhầm vào nút Cancel Subscription ở bên dưới.

Với những ai đang muốn huỷ Subscription thì không sao, nhưng ai không muốn huỷ mà ấn nhầm vào nút Cancel Subscription thì quả thực gây thiệt hại cho công ty rồi đúng không nào.

Nếu chúng ta thay nút Cancel bằng nút Not Now hay là Maybe Later thì cũng vẫn gây hiểu nhầm. Bởi vì những nút này có ngụ ý là sẽ không huỷ subscription lúc này mà sẽ huỷ vào lúc khác.

Để giải quyết vấn đề đó thì chúng ta nên thay cái nút Cancel bằng nút Keep Plan – Vẫn giữ nguyên subscription sẽ thân thiện và an toàn với người dùng hơn rất nhiều.

Tên nút không được gây xung đột nhau

Khi nghĩ về 1 tên mà đối lập với “Cancel” có thể ai trong chúng ta cũng đều nghĩ là “Do not Cancel“. Nhưng cái tên này không phải là lựa chọn tốt bởi vì nó đang cùng sử dụng từ giống nhau đó là “Cancel“.

Đây cũng là lí do mà “Keep Subscription” sẽ không phải sự lựa chọn tốt, mà chúng ta nên đặt là “Keep Plan“.

Khi mà chúng ta cùng sử dụng 1 từ giống nhau cho 2 button thì có thể làm người dùng nhầm lẫn nút này với nút kia. Hay nói cách khác, để không bị nhầm lẫn người dùng sẽ bỏ ra khoảng thời gian nào đó để đọc thật kĩ 2 nút đó.

Với UX Design thì điều đó là không tốt 1 chút nào.

Hơn nữa, “Do Not Cancel” không phải là từ trái lập với “Cancel” bởi vì cả 2 từ này đều mang ý nghĩa là phủ định.

Nếu cả 2 nút đều mang nghĩa là phủ định thì khi đó người dùng sẽ xem 2 từ này như là “Huỷ“, và đây cũng chính là nguyên nhân gây nhầm lẫn.

Từ “Cancel – Huỷ” nó mang nghĩa phủ định. Nếu mà 1 lúc nhìn vào 2 từ “Do Not Cancel” và “Cancel Subscription” thì người dùng có cảm giác khi ấn vào 1 trong 2 nút này thì có thể làm mất đi “1 thứ nào đó”.

Để đặt tên nút an toàn hơn trong trường hợp này, thì từ “Keep Plan” có lẽ sẽ là giải pháp tốt nhất.

Cancel Subscription vs Unsubscribe

Đôi khi chúng ta nghĩ, sử dụng “Unsubscribe” có thể thay thế cho từ “Cancel Subscription“. Nhưng các bạn đã nhầm.

2 từ “Subscription” với “Subscribe” là 2 từ không thể thay thế cho nhau được. Bởi vì ngữ cảnh sử dụng nó là hoàn toàn khác nhau.

Khi nào nút "Cancel" không nên đặt là "Cancel"

Chắc xem nhiều Youtube chúng ta cũng đều nghe thấy từ “Subscribe” đúng không nào?

Ý nghĩa của từ “Subscribe” là muốn nói đến việc người dùng đăng kí theo dõi kênh đó, và sẽ nhận thông báo khi có bài viết mới.

Còn từ “Subscription” thì sao? Nó lại có ý nghĩa hoàn toàn khác.

Với những ai đăng kí dùng Netflix hay là Spotifyđể nghe nhạc thì cũng biết. Cả 2 dịch vụ này đều tính tiền theo tháng, và chúng ta phải mua thì mới dùng được. Nó có những plan khác nhau.

Nếu chúng ta đăng kí plan và trả tiền theo tháng, cứ đến đầu tháng sẽ bị rút tiền từ thẻ VISA. Cái hành động đó được gọi là “Subscription“.

Do đó tuỳ vào ngữ cảnh, nếu chúng ta không phân biệt cách sử dụng của 2 từ này 1 cách rõ ràng thì có thể gây nhầm lẫn cho người dùng.

Như ảnh ở bên trên, nếu chúng ta muốn hỏi người dùng là “Có muốn huỷ subscribe kênh hay không?” thì có lẽ câu trả lời tốt nhất vẫn là “Stay Subscribed” đúng không nào?

Qua đó ta thấy được, để làm rõ hành động của người dùng thì việc đặt tên nút phù hợp với từng ngữ cảnh là điều khá quan trọng.

Nếu sử dụng tên nút không thích hợp sẽ không chỉ làm người dùng nhầm lẫn, mà còn khiến người dùng “phải bỏ chút thời gian” để hiểu rõ xem nút này có ý nghĩa là gì.

Và còn rất nhiều ví dụ khác nữa cũng khá thú vị. Đặc biệt là Nitendo họ đã làm rất tốt điều này.

Nếu bạn nào biết tiếng nhật có thể tham khảo bài này về Design Nitendo (mình tìm mãi không thấy có bài viết về tiếng anh): Nintendo SwitchのUIはなぜ使い勝手がいいのか!? 全員で体験し、“あたりまえ”を磨く任天堂のもの作り【CEDEC 2018】

Kết luận

Các bạn thấy UX nó quan trọng thế nào với người dùng chưa?

Việc đặt tên nút dường như là 1 việc rất nhỏ trong design, thế nhưng nó lại mang lại 1 hiệu quả vô cùng to lớn.

Nếu tên nút đặt thích hợp, người dùng phán đoán nhanh, sẽ là nhân tố kết nối đến CTA (Call to Action) được cao hơn.

Chúc các bạn thành công.

Xem thêm việc làm UX/UI Design trên TopDev

Bài viết gốc được đăng tải tại nghethuatcoding.com

Có thể bạn quan tâm:

Call API trong VueJS theo cách thông minh nhất

cach-call-api-trong-vuejs

Bài viết được sự cho phép của tác giả Ngo Thang

Call API? Gần đây thấy VueJs có vẻ đang hot nên thử tìm hiểu xem thực sự nó như thế nào.

Mình cũng thử đọc code của 1 vài sample, tutorial thì thấy chỗ call API đa số đều dùng axios ở Component hay là ở bên trong Vuex.

Nếu mà áp dụng những cái đó vào trong dự án thực tế thì sẽ xảy ra những vấn đề sau:

  • Việc viết API trực tiếp trong component sẽ rất khó cho việc viết unit test. (Tìm hiểu thêm về component là gì?)
  • Tính mở rộng của Vuex(actions) (đối với những xử lý không dùng lại thì không nên viết ở trong Store)
  • Việc module hoá phần giao tiếp API với PureJS không làm giảm đi độ phụ thuộc. Vì API được định nghĩa trong component nên muốn thay đổi API hay logic sẽ phải sửa trong nhiều file khác.

  Cách tạo một Docker đơn giản cho Node.JS

Và còn rất nhiều vấn đề nữa…

Sau khi tìm hiểu thì mình thấy có rất nhiều design pattern có thể áp dụng cho việc gọi API. Nhưng có 1 design pattern mà mình thấy tốt nhất đó là Repository Factory. (Xem thêm Design Pattern là gì?)

Quả thực mình rất thích cái pattern này vì nó scale khá là dễ.

Mục đích bài viết

  • Biết cách áp dụng design pattern vào việc call API. Đặc biệt là Repository Factory pattern.
  • Mặc dù bài viết lấy ví dụ là VueJS nhưng mà Angular, ReactJS mình thấy đều có thể áp dụng được.

Tại sao lại dùng nó?

Đầu tiên mình sẽ dùng repository pattern để truy cập vào tài nguyên theo cách độc lập, không có bất kì logic nào ngoài việc trả về dữ liệu.

Cái thứ 2 là sẽ sử dụng factory pattern để khởi tạo logic của môi trường hay repository cần thiết cho từng case. Factory có 1 lợi thế là có thể khởi tạo 1 mock repository hoặc là production repository nếu cần thiết.

Chắc hẳn mọi người đọc example hay tutorial cũng đều thấy axios luôn được sử dụng trong component. Vậy có vấn đề gì xảy ra chỗ này:

  • Điều gì sẽ xảy ra nếu chúng ta muốn tái sử dụng việc call api?
  • Điều gì xảy ra nếu endpoint thay đổi?
  • Điều gì xảy ra nếu muốn tái sử dụng việc call api cho dự án khác?
  • Điều gì xảy ra nếu muốn refactor 1 vài lời gọi hàm hoặc muốn di chuyển nó đến Vuex actions?
  • Mình có nhiều hơn 1 cái resource, thế bây giờ phải định nghĩa tận 4 cái endpoint?
  • Làm thế nào có thể dùng 1 cái mock api cho việc test?

Đương nhiên là thay đổi 1 file sẽ dễ dàng hơn là thay đổi 30 file rồi đúng không?

Phương pháp đúng

Trong case này, để đơn giản hoá code và có thể định nghĩa được 1 vài loại resource khác nhau thì mình sẽ sử dụng POJO (Plain Old JavaScript Objects). Đương nhiên có thể sử dụng Class nếu bạn muốn.

Bây giờ cùng bắt đầu đi định nghĩa asxios nhé.

Mình sẽ đặt tên file là Repository.js vì nó đảm nhiệm việc kết nối đến các resources.

Cũng có 1 vài người thích cái tên Service hay là API, nhưng trong hoàn cảnh này mình thấy cái tên Repository có vẻ hợp lí hơn.

Call API

Tiếp theo chúng ta sẽ đi định nghĩa cho từng Entity của project.

Ví dụ như bạn có 1 blog. Khi đó chúng ta sẽ có 1 Entity là posts. Và bây giờ chúng ta sẽ đi định nghĩa tất cả các thao tác CRUD (Create Update Delete).

Và khi đó postsRepository.js sẽ trở thành như sau:

Call API

Tiếp theo chúng ta sẽ đi tạo Factory.

Call API

Nhìn vào trên ta thấy việc tạo Repository từ Factory trở nên thật simple phải không?

Hơn nữa ở đây ta cũng dễ dàng tạo mock repository (phù hợp với từng môi trường ví dụ develop, staging, production) hay thêm 1 vài logic vào trong hàm get ở trên cũng đều được hết.

Còn đây là cách áp dụng vào trong component:

tuyển dụng it

Nhìn vào chúng ta thấy nó simple phải không nào? Vì phần logic đã được tách ra ở 1 chỗ khác nên việc dùng 1 endpoint khác như GraphSQL cũng hoàn toàn có thể.

Xem thêm việc làm VueJS hấp dẫn tại TopDev

Kết luận

Hiện tại pattern này mình đang áp dụng vào dự án thấy khá ngon. Nhưng điều đó cũng không có nghĩa là nó phù hợp với dự án của các bạn.

Tuy nhiên, theo mình thấy thì pattern này có 1 số ưu điểm sau:

  • Có thể dễ dàng test 1 đoạn code nào đó 1 cách đơn giản
  • Code của component trông đẹp hơn
  • Có thể dễ dàng mở rộng (Đúng không ta?)
  • Có thể đảm bảo tính DRY (Donot repeat your self)

Bài viết gốc được đăng tải tại Nghệ thuật coding

Có thể bạn muốn xem thêm:

Mẫu bảng mô tả công việc lập trình Java

Mẫu bảng công việc lập trình Java

Lập trình Java có nhiệm vụ chính là xây dựng các ứng dụng cấp doanh nghiệp, quản lí quá trình phát triển ứng dụng bằng Java/ Java EE, đồng thời tham gia vào toàn bộ quá trình phát triển sản phẩm, từ lên ý tưởng, phân tích, thiết kế đến kiểm tra, vận hành thực tế theo kế hoạch. Hy vọng, Mẫu bảng công việc lập trình Java này sẽ giúp các bộ phận nhân sự dễ dàng hơn cho việc tuyển dụng những vị trí này.

Về lập trình viên Java: Để thành một Java Developer giỏi, các lập trình viên cần nắm rõ cấu trúc dữ liệu và giải thuật, kỹ thuật lập trình hướng đối tượng cũng như có kiến thức hoặc kinh nghiệm về Spring/ Hibernate/ Struts để cùng tham gia nghiên cứu, thiết kế, phát triển và tích hợp các các giải pháp và hệ thống ứng dụng phục vụ công việc quản trị, vận hành và điều hành cho sản phẩm công ty/ khách hàng.

Mẫu bảng công việc lập trình Java

YÊU CẦU CÔNG VIỆC

  • Thành thạo lập trình với ngôn ngữ Java/J2EE
  • Nắm vững lập trình OOP, MVC
  • Có kinh nghiệm lập trình với các framework: Struts, SpingMVC, Hibernate
  • Có kiến thức tốt về HTML/CSS, JQuery, Oracle, SQL Server, MySQL
  • Có kinh nghiệm với các công nghệ Springboot, Mybatis, JUnit, Redis, Docker, Microservices là lợi thế
  • Kỹ năng tư duy logic và thuật toán tốt, phân tích và giải quyết vấn đề
  • Có khả năng đọc hiểu tiếng Anh chuyên ngành

MÔ TẢ CÔNG VIỆC

  • Lập trình Java tham gia quá trình triển khai dự án lập trình trên nền tảng Java, đưa hệ thống, sản phẩm đã phát triển vào vận hành thực tế theo kế hoạch
  • Nghiên cứu công nghệ mới để áp dụng cho các dự án của công ty
  • Duy trì và phát triển các website, code và cấu trúc dữ liệu có sẵn của công ty
  • Thực hiện nâng cấp đều đặn để giúp phần mềm và các hệ thống trở nên bảo mật và hiệu quả hơn.
  • Phối hợp với các technical writers để viết các tài liệu hỗ trợ người dùng
  • Hỗ trợ các thành viên trong nhóm với các chức năng phức tạp, tham gia nhận xét, đánh giá source code của các thành viên trong nhóm.

Tham khảo thêm những công việc lập trình hot nhất thị trường tại đây

Tâm sự về nỗi lo khi là một lập trình viên amateur

nỗi lo khi là một lập trình viên amateur

Mình đã từng suy nghĩ khá nhiều về cái nghề lập trình viên của mình. Và những suy nghĩ này chẳng dễ chịu chút nào.

Từ lúc đảm nhận một công việc lập trình thực sự, mình luôn lo lắng về công việc này. Không một lời cảnh báo hay tư vấn nào từ bạn bè, đồng nghiệp, hay bất cứ ai làm dịu đi nỗi lo của mình. Luôn có một nỗi sợ ngự trị, nỗi sợ bị khiếm khuyết về kỹ năng lập trình, các kỹ năng mềm, networking, kỹ năng học hỏi, hay tất cả những thứ khác, sẽ một ngày hạ gục chính mình.

Nhiều lần mình có cảm giác hoảng loạn, khi chứng kiến thành công từ những người khác. Đôi lúc mình cô lập bản thân để tránh khỏi những cảm xúc tiêu cực đó. Vì rõ ràng nó chẳng hề giúp ích cho sự nghiệp hay cuộc sống này.

  5 điều NÊN và KHÔNG NÊN khi review tăng lương mà lập trình viên nào cũng nên biết!

Cảm nhận sự bất an dưới góc độ khác

Mình thử đủ mọi cách để thoát khỏi cảm giác lo sợ, nhưng có vẻ như chưa đủ. Thế nên thay vì loại bỏ nó, mình tìm cách để nhìn nhận vấn đề dưới một lăng kính khác.

Lo lắng về kiến thức lập trình cơ bản, nên mình tìm kiếm và take note những khái niệm JavaScript cơ bản như curry và coercion.

Lo lắng về kiến thức Ruby on Rails vì nó liên quan nhiều đến công việc hiện tại, mình sưu tầm nhiều tài liệu để có cái nhìn tổng quát hơn.

Lo lắng khi không hiểu những thay đổi code từ đồng nghiệp, nên mình bắt đầu đọc lại những pull request để tìm hiểu vì sao họ lại thay đổi và họ đổi những gì. Bất kỳ những gì không hiểu thì mình sẽ tiếp tục nghiên cứu sâu hơn.

Lo lắng khi nhận feedback về chủ đề hay tool mà mình không nắm rõ, nên sau đó research nhiều hơn khi sửa chúng. Gần đây mình nhận feedback liên quan đến validations in Rails, nên mình research thêm về ActiveRecord và ActiveModel gems.

Lo lắng về những kỹ năng mềm, mình đọc “Burn Your Portfolio” và đọc thêm những cuốn sách được giới thiệu trong đây.

Lo lắng về lộ trình sự nghiệp, mình thử đọc và tìm hiểu những chuyên gia trong ngành, lộ trình của họ đa dạng thế nào, những thăng trầm trong nghề, những khó khăn họ trải qua và đa phần là những lo lắng của họ nữa.

Cách xua tan những bất an – quản trị nỗi sợ bản thân 

Mình có rất nhiều sự lo lắng nhưng trên một góc độ khác, chúng cũng là công cụ giúp mình luôn tiến về phía trước và cố gắng làm tốt hơn. Đôi lúc mình cũng không chế ngự được sự bất an này, đôi lúc mình tự ti với chính bản thân và chỉ muốn dừng lại.

Liệu những cảm giác này có cấp độ không nhỉ? Đủ mạnh để thúc đẩy bản thân cố gắng, hay quá yếu để không gây tác động gì?  Và chúng có đáng để mình tự đấu tranh hay không?

Mình chưa tìm được câu trả lời cho vấn đề này, nhưng trước mắt những nỗi lo này sẽ chưa biến đi. Cho nên mình sẽ tìm cách làm chủ chúng, ít nhất là vậy.

Có thể bạn quan tâm:

Xem thêm việc làm Software Developers tại TopDev

Tại sao nhiều lập trình viên giỏi không đưa ra lời khuyên để người khác có thể được như họ?

Câu hỏi “sốt dẻo” của Quora:

“Tại sao nhiều lập trình viên và hacker tài năng không đưa ra những lời khuyên để những người khác đều được như họ?”

Trả lời bởi Vincent Guidry – Software Engineer của Great Big Story (2016 đến nay):

Trùng hợp ghê! Sáng nay mới mở mắt ra đường, đang trên đường đi làm thì một nhân viên đã hỏi tôi làm nghề gì. Tôi nói mình là một kỹ sư phần mềm, và anh ta mừng như bắt được vàng, đúng kiểu “Oimeoi CƠ HỘI!” và bắt đầu dò la hỏi đủ thứ trên đời. Thì ra là ảnh đang học một trường về bảo mật phần mềm nào đó.

Tôi nói anh nên tải nhiều phần mềm vào và bắt đầu nghiên cứu dò xem nó có lỗ hổng không, người ta hay gọi là pentest (có thể hiểu là một phương pháp đánh giá độ an toàn của hệ thống bằng cách tấn công nó). Ngoài ra cũng không ít các khoá học phần mềm hướng dẫn chi tiết cho bạn cách làm nữa. Thiệc tình thì, tôi cũng chẳng biết gì nhiều ngoài những cái căn bản cả, tôi làm kĩ sư phần mềm chứ có phải bảo mật đâu!

Tôi viết cho ảnh cái URL tới Hacker News với kèm theo một vài tên tuổi nổi tiếng của những người làm về bảo mật hoặc có tư duy bảo mật tốt, toàn những người dễ tiếp cận thôi. Hết! Đó là tất cả những gì tôi có thể làm.

Tuy nhiên, có một điều mà mọi người quên mất rằng, để có thể làm những công việc của một chuyên gia thì bạn phải là một chuyên gia cái đã! Khi anh đang chơi thể thao, thì tôi đang học cách lắp ráp máy tính. Rồi học cách build web. Sau đó học cả cách “dạy” Windows làm những việc tôi muốn nữa. Tiếp đến là học Linux. Tôi còn cài cả đống bản distro và bằng mọi cách ép nó hoạt động.

Có một câu chuyện mà tôi hay kể với mọi người là 4 năm trước, tôi có một chuyến đi dài hai tháng tới Colombia. Tôi dành phần lớn thời gian của chuyến đi đó để học cách phát triển web một cách “thực tế”. Tôi rất hạnh phúc khi biết rằng quán trọ mình đang ở có sẵn một chiếc bàn để tôi có thể ngồi làm. Liệu tôi có đi chơi đây đó tán gái không ấy hả? Có chứ – vào những lúc tôi không làm.

Tôi yêu công nghệ và yêu code, chưa kể là tôi cũng hơi bị giỏi nữa.

Những người như anh nhân viên ấy chỉ đến gặp tôi và muốn trở thành “tôi” bởi họ thấy tôi kiếm được quá nhiều tiền mỗi năm và sống trong những nơi xa hoa lộng lấy, tất cả đều nghĩ rằng chỉ cần chịu khó học một vài năm là có thể được như vậy. Họ chỉ nghĩ rằng vấn đề nằm ở chỗ mình chưa có được những công cụ học cần thiết mà thôi.

Nhưng thực tế thì, tôi cũng chỉ có bấy nhiêu tài liệu mà các bạn cũng có thể sở hữu mà thôi. Khác biệt ở chỗ tôi đã quyết định là nếu có được chúng là sẽ phải sử dụng chúng. Còn bạn thì dùng thời gian của mình để làm việc khác mất rồi.

Tôi đã tiêu tốn vô số giờ đồng hồ để tìm bug, nhúng hết não vào các bản hướng dẫn sử dụng, đọc bao nhiêu sách lập trình, build hết thứ này đến thứ khác và rồi lại phải vứt hết khi nhận ra rằng những thứ đó sẽ chẳng thể nào chạy hiệu quả nổi… Dù có lâu hay mau thì tôi cũng đâu thể nhét hết những thứ trên đây vào đầu bạn được.

Cách đây không lâu một người bạn lâu năm đã đến gặp tôi và thú thật là cậu ấy muốn học viết code. Cậu bạn đó cực kỳ thông minh và rất quyết tâm, tôi đã nghĩ rằng mình chỉ cần đưa cho cậu ấy một số định hướng đúng là đủ. Vì thế mà – khúc cao trào đây – bằng chính tiền của mình, tôi đã mua cho cậu ấy khóa học Ruby on Rails của Michael Hartl và bảo với cậu rằng nếu có vấn đề khó khăn gì thì chỉ cần gọi là tôi sẽ đến. Thậm chí tôi còn offer sẽ ngồi làm việc cùng cậu ấy hàng tuần và kiểu “cầm tay chỉ việc” giúp đỡ cậu ấy làm từng thứ một.

Vậy đoán xem, tôi có nhận được cuộc gọi nào không? NOPE – Không nhé. Tôi đã theo sát cậu ấy khi có thể, và đã sớm nhận ra rằng khóa Ruby ấy vượt quá sức của cậu. Khối lượng thông tin quá nặng nề, ngay cả các giáo trình nhẹ hơn cũng sẽ cần khoảng vài năm mày mò, và cậu ấy không có từng ấy thời gian đâu.

Ai cũng muốn đi sao cho nhanh, “đánh nhanh thắng nhanh” cả. Và có lối tắt cho bạn luôn! Không đâu khác là các “trại” code (Code Camp): chỉ cần chi khoảng X000 đô là bạn sẽ được học một khoá được thiết kế RIÊNG dành cho những người như bạn – từ chỗ chẳng có chút kỹ năng nào đến mức level skill “vừa đủ xài” để bạn có thể tìm được một công việc ở mức căn bản nhất trong phát triển phần mềm. From ZERO to HERO đúng nghĩa!

Nhưng NO! Các bạn lại không thích đường tắt này – “Tốn quá” là cách diễn đạt phổ biến nhất. Các bạn lại muốn có lối tắt MIỄN PHÍ cơ. Hỡi ôi xin lui… Tôi ước tôi giúp được, thật đấy, tôi thực sự mong rằng mình có thể phát minh được ra được cách đó để cứu rỗi những linh hồn ấy. Tôi mà phát minh được ma thuật này thì bạn chẳng cần trả tiền cho tôi đâu – Tôi sẽ phát FREE cho bạn luôn… (Lạy chúa trên cao)

Nhưng tạm thời là, tôi không nghĩ mình làm được việc này. Và trong tương lai gần xa hằng hà xa số nào đấy, cũng sẽ chẳng có ai làm được đâu…

TopDev via Quora

  Hot trend AI, không hề "gắt" như bạn nghĩ
  Quy tắc 24x3 cho sáng tạo trong lập trình!

Truy cập ngay việc làm IT đãi ngộ tốt trên TopDev

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.

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.
  Tại sao không bao giờ nên sử dụng utf8 trong MySQL?

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.

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.

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.

TopDev via Bloghoctap

Đánh giá điểm mạnh và điểm yếu của PHP

diem-manh-va-diem-yeu-cua-php

Bài viết được sự cho phép của tác giả Đoàn Văn Tuyển

Có quá nhiều ý kiến chê PHP. Thế nên dựa trên kinh nghiệm làm việc với PHP nên mình muốn viết lại những đánh giá của mình với ngôn ngữ trên. Những đáng giá bên dưới vừa so sánh với những thứ khác trên quan điểm PHP là Web Programing chứ không so với những mảng khác. Phần bài viết sẽ gồm 4 phần, phần đầu nói qua về cách thiết kế và thực thi của PHP, hai phần sau sẽ đánh giá điểm mạnh và điểm yếu của PHP dựa trên thiết kế đó, phần cuối mình viết khi nào nên sử dụng PHP, khi nào không:

1. Cách thức thực thi của PHP

Như đã nói ở trên, mình chỉ nói về PHP Web (ko tính đến PHP chạy dưới dạng Command Line, thực thế PHP CLI có khác một chút nhưng không quá nhiều).

1.1 Kết nối với Web Server

PHP không được thiết kế để trực tiếp handle request mà thông qua Web Server (Thông thường là Apache hoặc Nginx). Khi client (Web Browser / HTTP Client) gửi request lên Web Server. Web Server sẽ kết nối với PHP và tạo ra một tiến trình độc lập để xử lý request đó. Những tiến trình đó có thể là Process (với apache) hoặc thread (với Nginx / PHP-FPM). Tuy nhiên dù là process hay thread thì có một đặc điểm là những tiến trình đó không chia sẻ tài nguyên với nhau. Nghĩa là hai request của 2 client gửi lên thì tạo 2 tiến trình hoàn toàn tách biệt tài nguyên xử lý. Tài nguyên tách biệt bao gồm: RAM, CPU, kết nối… Sau khi request hoàn thành, kết quả trả về cho Web Server và client thì tiến trình đó kết thúc. Những tài nguyên đã được cấp phát (Bộ nhớ, CPU, kết nối I/O khác…) được giải phóng.

điểm mạnh và điểm yếu của PHP
điểm mạnh và điểm yếu của PHP

1.2 Kết nối với PHP Extension

PHP không thiết kế dưới máy ảo như JAVA, PHP chạy trên nền Zend Engine. Zend Engine đảm nhận việc thông dịch mã PHP thành mã máy và thực thi nó. Toàn bộ việc quản lý tài nguyên của PHP được Zend Engine đảm nhận. Bản thân Zend Engine cung cấp sẵn một số thư viện để PHP có thể chạy trực tiếp mà không cần thư viện ngoài, tuy nhiên phần lớn những thư viện đó là những thư viện xử lý Text. Những thư viện khác của PHP được viết dưới dạng extension, những thư viện này chủ làm việc với PHP thông qua Zend Engine. Đã số những những xử lý I/O của PHP là thông qua thư viện ngoài chứ không phải hỗ trợ từ core: ví dụ kết nối DB, làm việc với HTTP, xử lý ảnh…

điểm mạnh và điểm yếu của PHP
điểm mạnh và điểm yếu của PHP
  10 PHP Instagram Scripts & Widgets tốt nhất

2. Điểm mạnh

Đơn giản, linh động:

Từ thiết kế của PHP, cộng với việc PHP là ngôn ngữ Script và cú pháp khá thoải mái nên nó rất linh động. Cú pháp PHP cũng rất dễ học nên rất nhiều người biết PHP. Với một người chưa biết gì về lập trình chỉ cần một khóa học vài ba tháng có thể bắt đầu với PHP và thậm chí có thể bắt đầu… kiếm tiền được rồi. Chính vì sự dễ dàng đó nên số lượng developer rất đông và hung hãn.

Support bởi cộng đồng lớn:

PHP sở hữu một trong những cộng đồng developer lớn nhất. Số lượng job về PHP cũng luôn thuộc hàng top. Chính vì có cộng đồng rất lớn như vậy nên hầu như vấn đề kỹ thuật nào bạn gặp phải cũng có thể có người hỗ trợ ngay lập tức. Nếu bạn đã từng sử dụng những ngôn ngữ lập trình ít phổ biến thì sẽ thấy tầm quan trọng của cộng đồng lớn đến thế nào.

Hỗ trợ xử lý text rất tốt:

PHP có rất nhiều phần xử lý liên quan đến text cực tốt. PHP được viết dựa trên Perl, một ngôn ngữ lập trình sinh ra để làm việc với Text. PHP cực tốt để giải quyết các bài toán liên quan đến Text, mà HTML hay Web lại là bài toán xử lý text. Do vậy thật dễ hiểu tại sao PHP lại là ngôn ngữ phổ biến nhất để xây dựng các Website.

Có rất nhiều Framework, thư viện:

Cùng với việc sở hữu cộng đồng lớn, PHP cũng sỡ hữu vô số bộ thư viện, extension, rất nhiều Framework. Do vậy PHP có thể giải quyết rất nhiều bài toán khác nhau. Hầu như nói đến vấn đề gì cũng có thể có những thư viện liên quan để PHP. Do vậy đôi khi người ta còn tưởng PHP là lời giải cho mọi vấn đề.

Xem tin tuyển lập trình viên PHP đãi ngộ tốt trên TopDev

3. Điểm yếu

Mặc dù có nhiều điểm mạnh nhưng PHP cũng sở hữu những điểm yếu chết người. Những điểm yếu khiến cho ở một số bài toán PHP rất khó giải quyết thậm chí không thể giải quyết.

Không chia sẻ tài nguyên

Vấn đề đầu tiên mình cũng nghĩ là vấn đề hạn chế lớn nhất của PHP chính là việc không chia sẻ tài nguyên giữa các tiến trình. Việc đóng khung các tiến trình giúp ích rất lớn cho việc PHP không phải đối mặt với những vấn đề như: quản lý bộ nhớ (chả mấy khi PHP Developer quan tâm đến vấn đề này), crash hệ thống (một hai tiến trình chết thì chả ảnh hưởng gì đến hệ thống). Tuy nhiên việc này lại dẫn đến rất nhiều hạn chế khác.
Đầu tiên là việc không chia sẻ tài nguyên khiến cho tài nguyên sử dụng (RAM, CPU, I/O connection) tăng lên rất nhanh.

Bạn tưởng tượng cùng lúc có 100 request được xử lý, tương đương 100 tiến trình được chạy. Nếu một biến cùng được sử dụng thì số lượng RAM sử dụng sẽ là 100 lần (các ngôn ngữ khác vì sử dụng chung RAM nên những phần việc memory cache rất đơn giản), số lượng kết nối DB phải là 100 kết nối cùng lúc (ở phần tiếp theo mình sẽ phân tích tiếp ví dụ về kết nối này) … Điều này hoàn toàn khác xa so với những ngôn ngữ như JAVA, .NET, Node JS…. Do vậy khi sử dụng PHP cho hệ thống lớn thì cực khó để scale hệ thống, ngưỡng của PHP.

Quá linh động

Đây được nêu ra như một điểm mạnh của PHP, nhưng cũng là điểm chết người của nó. PHP quá dễ dễ, quá linh động, điều này khiến cho Developer có vô số cách để đạt được kết quả. Cùng với việc nó quá dễ để học khiến cho chất lượng của PHP developer thấp hơn khá nhiều so với đa số các ngôn ngữ lập trình khác. Chuyên môn kém lại gặp ngôn ngữ quá linh động, kết quả thường thấy là chất lượng code rất tệ, quá nhiều Technical Debt được tạo ra.

Điều này khiến cho việc maintain một dự án PHP trở lên quá kinh khủng (Đấy là còn chưa kể đến tính tương thích ngược của những framework và một vài yếu tố bên ngoài nữa). PHP cũng có quá nhiều thư viện bên ngoài, đôi khi chất lượng cũng rất tệ khiến cho tình trạng càng trở lên tồi tệ hơn.

Phụ thuộc quá nhiều vào extension:

Những xử lý hỗ trợ từ Core của PHP rất hạn chế do vậy PHP phải phụ thuộc nhiều vào các thư viện Extension ngoài. Những Extension ngoài không tương tác trực tiếp mà làm việc với PHP thông qua Zend Engine. Cơ chế này cũng khiến cho mọi thứ trở lên chậm hơn. Do vậy nhiều khi Extension không giúp cải thiện quá nhiều. Mình lấy ví dụ điển hình rất hay xảy ra là kết nối Database. Trong khi các ngôn ngữ lập trình khác thường sử dụng Connection Pool để quản lý kết nối với DB. PHP sử dụng cơ chế khác là persistent Connection để tăng tốc kết nối. Persistent Connection giúp cho việc khi một request được hoàn thành thì kết nối DB tạo ra bởi Request đó không được “đóng” mà lại được tiếp tục sử dụng ở request tiếp theo. Điều này giúp giảm thời gian kết nối với DB.

Tuy nhiên khi Request chưa dừng thì kết nối này không được share với một request khác (cho dù ở thời điểm hiện tại, request đó không thao tác DB đi nữa). Điều này dẫn đến nếu PHP phải xử lý 100 request đồng thời thì cần có 100 kết nối đến Database (nếu tăng lên 1000 thì số đó là 1000). Điều này hoàn toàn khác với cơ chế connection pool của các ngôn ngữ như JAVA. Connection Pool đảm bảo chỉ có tối đa x Connection đến DB được tạo ra (x do Developer set được).

Kể cả có 100 request, hay 1000 request đồng thời đến Web Server ở thời điểm đó thì con số x không đổi (Nếu cùng lúc có nhiều hơn x request cần kết nối thì sẽ có một số request phải chờ, chú ý ở đây hoàn toàn có thể có 1000 request đồng thời nhưng cùng một thời điểm có thể chỉ có 100 thằng kết nối DB, còn 900 thằng khác đang xử lý dữ liệu nào đó khác). Điều này giúp JAVA kiểm soát được số kết nối đến DB, qua đó đảm bảo được performace của DB, còn PHP thì không thể.

  Lập trình PHP và những câu hỏi thường gặp khi phỏng vấn
  Học lập trình web với 13 tài liệu lập trình PHP không thể bỏ qua

Sau khi nhận feedback của nhiều bạn mình xin phép cập nhật lại bỏ phần đánh giá liên quan đến Non-Blocking I/O đi. Thực tế PHP có nhiều phương án support phần này rồi. Phần Performace của ngôn ngữ thì thực ra cũng không phải là vấn đề quá lớn, chủ yếu liên quan đến những bài toán xử lý dữ liệu lớn hoặc hình ảnh, video.

Không hỗ trợ Non-blocking I/O, Performace kém:

Một trong những điểm yếu khác của PHP là không hỗ trợ Non-blocking I/O. Điều này có nghĩa là nếu một tiến trình cần gọi vào I/O thì tiến trình đó sẽ “chờ” cho đến khi việc xử lý I/O được thực hiện xong. Trong suốt quá trình chờ đó thì toàn bộ tài nguyên của tiến trình đó vẫn bị chiếm giữ (đặc biệt là CPU). Một tiến trình của PHP tốn ít tài nguyên hơn khá nhiều so với những ngôn ngữ khác (ví dụ JAVA Web). Nhưng 1000 tiến trình cùng chạy thì lại tốn hơn rất rất nhiều so với những thằng khác. Một điểm nữa có thể nhắc đến là các hàm xử lý trong core của PHP cũng chạy chậm hơn khá nhiều khi so sánh với những ngôn ngữ lập trình khác. Nếu so với JAVA, nếu vòng lặp lớn có thể thấy PHP kém hơn cả trăm lần, so với C++ thì thậm chí còn kém cả ngàn lần.

4. Vậy thì khi nào nên sử dụng PHP, khi nào không:

PHP phù hợp với những dự án:

  • Không quá phức tạp về mặt xử lý tính toán
  • Số lượng truy cập ít hoặc trung bình, hoặc số lượng truy cập lớn nhưng logic không quá phức tạp.
  • Đặc biệt phù hợp với các bài toán liên quan nhiều đến giao diện Web
  • Chất lượng Developer ở mức trung bình khá trở lên (Chất lượng dev kém qua thì khó làm việc)

PHP không phù hợp để phát triển các dự án:

  • Yêu cầu realtime, cực kỳ nhiều kết nối với thời gian xử lý cực nhanh
  • Sử lý số lượng rất lớn request với logic rất phức tạp
  • Cần xử lý Data lớn, các bài toán Big Data.

Túm lại PHP tuy không thiết kế để giải quyết các bài toán cực kỳ phức tạp nhưng thực tế nó vẫn dùng tốt để handle lượng lớn request và vẫn là một ngôn ngữ lập trình mạnh. Ngoài PHP rất tốt cho những bài toán Web-base nói chung, nhất là những bài toán liên quan đến quản lý hoặc bán hàng.

P/S: Nếu tối ưu tốt PHP vẫn có thể Handle được lượng request rất lớn, lên đến khoảng vài chục ngàn req/ phút. Xem thêm slide của mình ở đây.

Bài viết gốc được đăng tải tại Medium

Có thể bạn muốn xem thêm:

Xem ngay những tin đăng tuyển dụng IT mới nhất trên TopDev

5 điều NÊN và KHÔNG NÊN khi review tăng lương mà lập trình viên nào cũng nên biết!

kinh nghiệm review lương cho dev

Kinh nghiệm review lương cho Dev là chủ đề chính của bài viết dưới đây. Tăng lương là vấn đề nhạy cảm và không dễ để mở lời với sếp. Để gia tăng cơ hội review lương thành công lập trình viên nên lưu ý một số điểm sau:

Những điều lập trình viên nên làm để được tăng lương

1.Chọn đúng thời điểm

Bạn cần xác định thời gian và địa điểm lý tưởng cho việc này, một nơi chỉ có bạn và sếp. Không đề cập đến vấn đề này trong một buổi tiệc đông đúc càng không nên nói đến việc tăng lương trước mặt những đồng nghiệp khác.

Hãy lựa chọn thời điểm sếp của bạn đang có tâm trạng tốt, thỏa mái và có thời gian rảnh để lắng nghe đề xuất của bạn, đây là kinh nghiệm review lương cho dev đầu tiên và rất thiết thực.

Bạn có thể tận dụng thời điểm vào những buổi review nhân viên được tổ chức định kỳ. Lưu ý đừng bắt đầu buổi review ngay với chủ đề lương bổng, hãy để sếp của bạn chia sẻ hết những gì ông ấy đã chuẩn bị, lắng nghe tất cả và kết thúc buổi review với đề xuất về lương sẽ hiệu quả hơn.

2. Yêu cầu sếp đánh giá về hiệu quả công việc hiện tại

kinh nghiệm review lương cho dev

Hãy tìm kiếm cơ hội để xin đánh giá của sếp về hiệu quả công việc hiện tại mà bạn đang đảm nhận. Lưu ý đừng tùy ý đánh giá năng lực của bản thân một cách chủ quan vì có thể nó sẽ gây ra tác dụng ngược. Nhiều khả năng bạn sẽ nghe những đóng góp tích cực và cả tiêu cực.

Nếu có nhiều phản hồi tích cực thì chúc mừng khả năng review lương của bạn thành công được hơn một nữa, còn nếu ngược lại những review không mấy tốt thì xin chia buồn cùng bạn 🙁

  Làm kỹ sư AI, mức lương 500 triệu là bình thường
  3 workhack để duy trì năng lượng tích cực tại công sở cho kĩ sư phần mềm

Nhưng đừng vội nản chí, hãy chân thành cảm ơn những đóng góp của sếp và xin lỗi về những thiếu sót của mình, quan trọng hơn là hãy cho sếp của bạn thấy bạn thực sự quyết tâm khắc phục những thiếu sót. Sau đó hãy mở lời: Như anh/chị đã nói hài lòng với công việc hiện tại của em/tôi vì.. em/tôi rất vui vì điều đó, và em/tôi thực sự thích công việc hiện tại của mình, chỉ có một điều em/tôi chưa hài lòng về mức lương hiện tại của mình..”

3. Đề cập đến những thành quả mà bạn đã đạt được trong công việc

Suy cho cùng việc quan trọng nhất mà sếp của bạn quan tâm chính là lợi ích mà bạn mang lại, được thể qua doanh số, thành công của dự án, hiệu quả làm việc. Vậy thì không lý gì bạn không tận dụng những thành quả mà mình đã đóng góp để thuyết phục sếp, rằng bạn hoàn toàn xứng đáng với mức lương tốt hơn.

4. Đề cập đến những đóng góp của bạn vào công việc chung của team

Đừng quên nhắc đến việc bạn đã nỗ lực như thế nào để giúp team mình đạt được những thành công: giúp đỡ đồng nghiệp mới, chuẩn bị tài liệu cho buổi báo cáo, đóng góp ý tưởng mới cho team, đại diện team tham gia các sự kiện, tham gia các khóa học kỹ năng,.. Những đóng góp này tuy không tạo ra những giá trị hữu hình, nhưng nó cho sếp bạn thấy rằng bạn thực sự nghiêm túc và nỗ lực đóng góp cho sự phát triển của công ty.

5. Nhắc lại những công việc mà bạn đang đảm nhận

Cần nhắc lại những đầu việc mà bạn đang phụ trách ví dụ: chịu trách nhiệm về một phần mềm, các chức năng, các dự án con, tổ chức các buổi họp, chịu trách nhiệm training người mới, … bất cứ thứ gì mà bạn đang làm (chỉ ngoại trừ những công việc bạn làm không tốt)

Trải nghiệm công cụ tính lương gross to net chuẩn tại TopDev

Những điều lập trình viên không nên làm để được tăng lương

1. Không so sánh mình với những đồng nghiệp khác

Đừng bao giờ bắt đầu với “Tôi đang làm việc chăm chỉ hơn XY”, đó chưa bao giờ là một lý do chính đáng để sếp cân nhắc tăng lương cho bạn. Bạn không biết liệu rằng mình có đang chỉ trích một nhân viên yêu thích của sếp hay không đâu, và rõ ràng ông ấy sẽ rất không vui khi bạn chỉ trích người mà ông ấy yêu thích. Giả dụ trong trường hợp sếp bạn không hài lòng với nhân viên đó thực thì ông cũng chỉ nghĩ đơn giản: công việc của bạn không quá khó để bạn có được hiệu quả tốt hơn những người khác.

2. Không so sánh công ty mình với những công ty khác, đặc biệt là công ty đối thủ

Việc so sánh mức lương của bạn ở công ty hiện tại với vị trí tương đương ở những công ty khác chưa bao giờ là một ý tưởng hay, ngay cả nó thực sự là cao hơn thật. Điều đó chỉ khiến sếp bạn nghĩ bạn không đủ trung thành và không còn tin tưởng bạn nữa. Bạn chỉ nên đề cập đến điều này chỉ khi bạn chuẩn bị nghỉ việc.

  Chuyện Elon Musk sa thải trợ lý gắn bó với anh 12 năm vì đòi tăng lương và bài học dành cho tất cả chúng ta
  Làm sao tăng lương cho ngọt?

3. Không dùng các lý do cá nhân làm cái cớ cho việc tăng lương

Không lấy những vấn đề cá nhân: gia đình đông con, mẹ già, con bệnh,… là cơ sở cho việc tăng lương- nó không hề thuyết phục. Điều đó chỉ là bạn trở nên yếu đuối hơn. Công ty không phải là tổ chức từ thiện, và họ chỉ trả tiền cho những đóng góp của bạn chứ không phải là dựa trên tình yêu thương.

kinh nghiệm review lương cho dev

4. Không đề cập đến điểm yếu của bạn

Sẽ tốt nếu bạn biết điểm yếu của mình là gì, nhưng thời điểm review lượng không phải là lúc để đề cập đến những vấn đề này. Trong trường hợp này chúng ta nên chứng minh mình là một nhân viên tốt, ngay cả khi đó chưa hẳn là sự thật.

5. Đừng nôn nóng

Có thể ngay tại thời điểm bạn đề cập đến vấn đề tăng lương sếp của bạn hứa sẽ cân nhắc về việc này. Hãy thực sự kiên nhẫn chờ đợi, đừng hỏi về chuyện đó mỗi ngày, hãy cho sếp của bạn thời gian để suy nghĩ.

Nếu bạn có ý tưởng mới về kinh nghiệm review lương cho dev hãy chia sẻ nó với chúng tôi!

Có thể bạn muốn xem thêm:

Xem thêm việc làm IT mức lương lương hấp dẫn nhất thị trường