Home Blog Page 214

10+ tools và extensions tuyệt vời cho GraphQL APIs

10+ tools và extensions tuyệt vời cho GraphQL APIs

Với sự quan tâm ngày càng lớn dành cho GraphQL, một hệ sinh thái mới sôi động của phần mềm hỗ trợ đã nhanh chóng nổi lên. Cộng đồng mã nguồn mở, startups cũng xác nhận các trường hợp sử dụng GraphQL mới, hạn chế những khó khăn khi phát triển GraphQL, cho phép nhiều nhà phát triển áp dụng GraphQL ươn và giảm chi phí cùng với các công cụ tuyệt vời.

Đây là một tin tuyệt vời với các ngôn ngữ truy vấn, vì Lee Byron, một designer của GraphQL tại Facebook, gần đây đã lưu ý rằng để GraphQL phát triển phổ biến, các hệ sinh thái rất cần bổ sung thêm các công cụ:

Cho dù các công cụ xử lý phân tích hiệu suất của các dịch vụ đồ hoạ, đã được xây dựng trước tại GraphQL server, hoặc cung cấp IDEs để khám phá  GraphQL schemas, vẫn còn rất nhiều việc cần làm để cải thiện khả năng sử dụng và áp dụng GraphQL.

Trong bài viết này, chúng tôi sẽ giới thiệu một loạt các công cụ để khám phá các mối quan hệ của GraphQL, tài liệu về GraphQL API, tối ưu hoá và theo dõi GraphQL API, chuyển từ REST API thành GraphQL, hoặc nếu bạn đang có một kế hoạch khác, bạn có thể muốn coi qua các extensions dưới đây để bổ sung chp API stack của mình.

GraphiQL

Một IDE trong trình duyệt giúp khám pháp GraphQL APIs

Nhưng chúng ta đã thảo luận trước, nhiều GraphQL APIs sử dụng giao diện điều khiển mã nguồn mở này interactive API playground. GraphiQL là một môi trường phát triển tích hợp (IDE) để tương tác với các API GraphQL calls, cho phép các dev truy vấn dữ liệu và thực hiện mutations.

IDE này tương đối dễ thực hiện; cho các máy chủ Node.js, express-GraphQL có thể tự động tạo ra GraphiQL. Vì nó được xây dựng dựa trên React, GraphiQL cũng có thể được nối với CSS cho việc xây dựng tùy chỉnh.

Cột GraphiQL bên trái để nhập truy vấn với sytax editor để tìm kiếm lược đồ có liên quan bằng cách sử dụng tính năng autocomplete. Khi yêu cầu được chạy, phản hồi sẽ được hiển thị ở cột bên phải.

Sự trợ giúp trực quan dưới dạng sandbox API, playground, hoặc các phương tiện tương tác khác là một khía cạnh quan trọng để hỗ trợ API nhằm đáp ứng nhu cầu của các dev.

GraphQL Voyager

Thể hiện GraphQL API dưới dạng biểu đồ tương tác

Nếu bạn hi vọng nhìn thấy mối tương quan giữa các dữ liệu, hãy chạy nó thông qua GraphQL Voyager, nó sẽ cho bạn một trải nghiệm rất ngầu. Voyager lấy một GraphQL API và biến nó thành graph trực quan. Sau khi thiết lập một lược đồ gốc, bạn có thể xem trực quan các field được kết nối như thế nào. Voyager lựa chọn một loại làm nổi bật các field bao gồm, và liên kết đến dữ liệu có liên quan trong đồ thị.

The Star War API (SWAPI) được biểu diễn trực quan bằng GraphQL Voyager

Như Lee Byron, Ivan Goncharov founder của APIs.guru đã nói với Nordic API:

“Tạo ra một công cụ tiên tiến có thể làm việc bất kì GraphQL API nào có thể là một trong những điều quan trọng mà REST API bị thiếu”

GraphQL Voyager cung cấp một cột bên trái mô tả thông tin của fields và một giao diện trực quan cung cấp điều hướng nhanh. Người sử dụng cũng có thể đơn giản hóa các đồ thị bằng cách loại bỏ các lớp wrapper Relay. Ngoài việc thể hiện các hình ảnh mềm mại, Voyager có thể giúp các công ty hình dung mô hình dữ liệu của họ, tạo ra các cuộc hội thoại trên các quan hệ dữ liệu,… Cuối cùng, chúng ta có thể xem “graph” phía sau GraphQL.

Graph CMS

Xây dựng một GraphQL Content API trong vài phút

GraphCMS là một hệ thống quản lý nội dung (CMS) API mà gắn liền với GraphQL. Nó cho phép bạn lưu trữ một hosted GraphQL hỗ trợ cho các ứng dụng web, cung cấp công cụ để quản lý nội dung. Người dùng xác định cấu trúc dữ liệu, xác nhận chúng trong bảng điều khiển, và có thể xem trình bày ở giao diện người dùng, tất cả đều nằm trong cùng một nền tảng.

Mặc dù GraphCMS không phù hợp với nền tảng API hiện tại nhưng nó thích hợp cho blog, ứng dụng web, hoặc các cấu trúc nội dung khác đòi hỏi khả năng chia sẻ dữ liệu theo chương trình. Một CMS dựa trên GraphQL sẽ là một thay thế thú vị cho các CMS truyền thồng như WordPress hoặc Drupal, sẽ cho phép một framework quản lý trong tương lai được trang bị API và nó có thể quản lý linh hoạt hơn cho giao diện người dùng cuối.

GraphQL Docs

Tài liệu ngắn gọn dễ hiểu cho GraphQL API

Cần một tài liệu tĩnh cho giản đồ GraphQL API? Còn lựa chọn nào tốt hơn GraphQL Docs. Trang web sẽ tạo ra các tài liệu chức năng đơn giản trong 10 giây, cho GraphQL điểm đích là URL. Người dùng có thể chọn công khai danh mục tài liệu API của họ, hoặc giữ nó ở chế độ  riêng tư.

Một mã nguồn mở tương đương cho tài liệu tĩnh là graphdoc-fork, nó tự tạo và lưu trữ các tài liệu GraphQL. Đối với cả hai, kết quả trả về la2 một giao diện ngắn gọn, menu tìm kiếm, và liên kết với các lược đồ định nghĩa đối tượng, và nhiều hơn nữa.

GraphQL Faker

Làm giả hoặc mở rộng API GraphQL với dữ liệu fake

Nếu bạn đang làm giả một gốc API, tại sao không thêm một số dữ liệu lorem ipsum để kiểm tra mọi thứ? Với GraphQL Faker, các nhà phát triển API GraphQL có thể chèn dữ liệu thực tế để bắt chước kết quả thực. Nó được hỗ trợ với fake.js, cho phép nhà phát triển mô phỏng trên 60 loại dữ liệu thực tế, như địa chỉ – đường phố, tên và họ, avatar và nhiều hơn thế. Tất cả những gì bạn cần là viết một IDL GraphQL, GraphQL Faker cung cấp một số ví dụ để bắt đầu soạn thảo IDL. Nó rất đơn giản:

type Person {
  name: String @fake(type: firstName)
  gender: String @examples(values: ["male", "female"])
}

Swagger GraphQL

Chuyển từ REST sang GraphQL trong 5 phút

Đối với các nhà cung cấp API cố thủ với mô hình truyền thống REST, họ sẽ không quan tâm việc dùng thử GraphQL. Mô hình này chỉ cần đưa Swagger lược đồ, và nó sẽ tự động chuyển sang GraphQL.

GraphQL IDE

Một IDE rộng lớn để khám phá GraphQL API

Môi trường phát triển tích hợp, hoặc IDE thường là một trình soạn thảo mã nguồn tối đa hoá năng suất của nhà phát triển với những tính năng như debug, hoàn thành code, compiling và giải thích. GraphQL IDE là một thay thế cho GraphiQL, nhưng sự khác biệt là “phổ biến”. Nó cung cấp thêm các tính năng quản lý dự án, tiêu đề tùy chỉnh và năng động, khả năng nhập / xuất, khả năng lưu trữ các truy vấn và xem lịch sử truy vấn.

GraphQL Network

Chrome Devtool cung cấp một “network” kiểu tab để cho phép nhà phát triển debug dễ dàng hơn

Nhiều kỹ thuật viên của chúng tôi là một người dùng mạnh mẽ của Google Chrome, do đó một tab trình duyệt về GraphQL là một điều cần thiết và nghiêm túc. Được gọi là GraphQL Network, tab hữu ích này tương tư như việc xem request network trong Chrome DevTool – đây là một công cụ tuyệt vời để gỡ lỗi các cuộc gọi API RESTful, nhưng ngắn khi làm việc với GraphQL, vì thường “/graphql” được hiển thị dưới dạng điểm cuối.

Tab này hiển thị một danh sách ngắn các yêu cầu GraphQL gần đây, liệt kê tên phương thức HTTP, trạng thái và loại request. Ngoài ra, GraphQL Network cũng cung cấp một cái nhìn thô của chuỗi GraphQL được gửi, cũng như xem một tính toán đang được giải trên máy chủ. Có các mục nhập riêng biệt được đặt ra cũng như có thể xem các đoạn mã có thể đọc được, có thể hữu ích để theo dõi và debug các truy vấn GraphQL.

Graphcool

Back-end hỗ trợ linh hoạt kết hợp GraphQL + AWS Lambda

Với kiến trúc linh hoạt, khả năng mở rộng, không cần máy chủ, có một back-end được hình thành trước là một triển vọng thú vị, đặc biệt là khi nó tương tác với GraphQL out-of-the-box. Graphcool là một nền tảng để hỗ trợ thiết kế lược đồ GraphQL và phát triển back-end ứng dụng, đi kèm với một bảng điều khiển trực quan để thiết kế và chỉnh sửa giản đồ dữ liệu của bạn, với khả năng tạo ra mô hình dữ liệu GraphQL tiên tiến, field tùy chỉnh và quan hệ giữa dữ liệu. tích hợp với công nghệ phổ biến như AWS Lambda, Algolia, và Auth0, Graphcool có vẻ là một công cụ mạnh mẽ để quản lý cơ sở dữ liệu hiện đại.

Optics by Apollo

Nhìn một vòng quanh danh sách các công cụ dành cho GraphQL, cuối cùng nhưng không kém phần quan trọng là Optics, một sản phẩm để theo dõi GraphQL APIs. Optics là một giải pháp phân tích cho các API GraphQL để theo dõi các truy vấn chạy như thế nào, giúp bạn biết những loại truy vấn đang được thực hiện và tần suất của chúng. Như chúng ta đã thảo luận trước đây, chỉ số API rất quan trọng và bất kỳ API web nào cũng có thể có lợi từ việc thêm giải pháp phân tích vào nền tảng của họ.

Xem khối lượng yêu cầu được hiển thị trực quan cũng như nắm bắt tốt hơn về các điểm nghẽn như các vấn đề về độ trễ là cần thiết để tối ưu hóa hiệu suất và cải thiện thời gian tải trang.

Optics được phát triển bởi Apollo, những người đóng góp lớn vào hệ sinh thái của GraphQL – Apollo Client là một ứng dụng GraphQL chuẩn bị cho ứng dụng React và native app, và Apollo cũng tổ chức các sự kiện để truyền bá kiến ​​thức GraphQL.

Lời kết

Các công cụ quan trọng khác bao gồm Thunder, một máy chủ GraphQL cho Go, Join Monster, một gói NPM để phân xử các vấn đề giữa cơ sở dữ liệu GraphQL và SQL, hoặc Dgraph, một cơ sở dữ liệu nhanh làm việc với GraphQL.

“Những công cụ tuyệt vời sẽ làm cho GraphQL trở nên phổ biến”
– Lee Byron, GraphQL / Facebook

Có rất nhiều thứ dường như đang nổi lên hàng ngày, và hy vọng với sự ra đời của các công cụ như những cái được đề cập trong bài viết này, nhiều nhà cung cấp có thể gặt hái được những lợi ích của GraphQL và tăng khả năng mở rộng nói chung và tốn ít nỗ lực.

Nguồn: nordicapis.com

Firebase & 5 nhầm lẫn tai hại thường gặp

Gần đây tôi đã đọc được khá nhiều lời bình luận online về Firebase. Đa phần chúng đều từ những developer vốn dĩ ghét Firebase.

“Queries thì sao mà phức tạp được!”

“Data model của nó thiệt là ngu”

“Mọi thứ đều phải là về phía client”

Nhiều khi bạn còn có thể thấy cả khói đang xì ra từ đầu của họ.

Cũng không có gì là khó hiểu bởi đó đều là những vấn đề bế tắc mà họ gặp phải khi dùng Firebase. Tuy nhiên, đôi khi chúng xuất phát từ việc họ hiểu sai về Firebase cũng như chức năng của nó.

Sau khi làm quen với Firebase được vài tháng, chúng tôi dùng nó để tạo ra một project planning tool gọi là Min. Có rất nhiều lầm tưởng tai hại mà mọi người mắc phải khi nói về backend-as-a-service(BaaS) solution này. Vì thế tôi mong bài viết này sẽ giúp gỡ những khúc mắc này cho các bạn.

Sai lầm 1: Firebase chỉ về client-side thôi

Chỉ mới gần đây thôi, Firebase vẫn còn là công nghệ client-side. Tuy vậy nó vẫn cho phép lưu trữ và querying. Tuy vậy đa phần mọi thứ đều được thực hiện tại phần client. Đối với các developers thì đây thật sự là điều quá khó nuốt bởi có web application nào mà lại không cần đến back-end?

Firebase team sau đó đã lắng nghe phản ánh từ cộng đồng người dùng. Vào tháng 3 2017, nhóm đã giới thiệu Cloud Functions dành cho Firebase. Với cloud functions, bạn có thể save các đoạn mã code lên Google Cloud. Những code này sẽ chạy khi có một Firebase events hay HTTP requests xuất hiện. Ví dụ như bạn muốn thực hiện data processing khi đang lưu dữ liệu trong database thì giờ bạn đã có thể làm được với Firebase.

Nếu bạn muốn biết thêm thì tôi khuyên bạn hãy vào đọc bài viết sau Cloud Function for Firebase docs.

Sai lầm 2: Firebase là nguyên nhân cho các đoạn code dài lê thê

Có một câu ngạn ngữ rằng “Người dở luôn đổ lỗi”, với kinh nghiệm dùng Firebase của tôi thì nó không hề khiến bạn viết ra những “cọng” code dài ngoằng. Bởi Firebase phần lớn thuộc về bên client, thế nên backend logic của bạn cũng sẽ nhắm tới cho client. Do đó nếu bạn không cẩn thận thì rất dễ cho ra code xấu và rối rắm.

Trong giai đoạn đầu phát triển của Min, chúng tôi dành rất nhiều thời gian để lên kế hoạch cho app như Data sẽ được modeling như thế nào, database sẽ có cấu trúc ra sao và cách tốt nhất để tương tác với dữ liệu là gì? Nhóm quyết định tạo ra một connector để kết nối với Firebase. Nó có toàn bộ code dành cho CRUD operations cũng như tương tác với Firebase. Ngoài ra, chúng tôi còn tập hợp list các class để xử lí dữ liệu của object dựa theo cấu trúc của Firebase database. Nhờ đó mà mọi thứ luôn rõ ràng và giúp cho code dễ bảo trì và fix hơn.

Sai lầm 3: data modelling dở / có quá nhiều duplication

Như chính thành viên của Firebase đã nói, Firebase database chỉ là một JSON tree khổng lồ. Data được lưu trữ như các cặp key-value và có thể có giá trị tùy theo ý bạn. Có rất nhiều cách để lưu trữ chúng vì thế nên bạn phải rất cẩn thận nếu không muốn bị gặp nhiều rắc rối.

Giả dụ như bạn muốn tạo ra một project management application đơn giản. Bạn có users và tasks. Tasks có thể được chỉ định Users. Bạn sẽ muốn lưu trữ tất cả thông tin của task trong một database của tasks node:

tasks : {
    "001" : {
        name         : "Development Round 1"
        description  : "Lorem ipsum dolor sit amet elit..."
        startDate    : "20170101"
        endDate      : "20170201"
        loggedHours  : {
            "20170101" : "1.66"
            "20170102" : "7"
            "20170103" : "5.5"
        }
        assignedStaff : "Cathryn"
    }
    "002" : {
        name : "Development Round 2"
        description : "Mauris quis turpis ut ante..."
        startDate   : "20170206"
        endDate     : "20170228"
        loggedHours  : {
            "20170206" : "3"
            "20170207" : "1"
            "20170208" : "4.75"
        }
        assignedStaff : "Sam"
    }
    "003" : {
        name : "Browser Testing"
        description : "Vivamus nec ligula et nulla blandit..."
        startDate   : "20170301"
        endDate     : "20170303"
        loggedHours  : {
            "20170301" : "1"
            "20170301" : "3"
        }
        assignedStaff : "Cathryn"
    }
}

Giờ nếu bạn muốn hiện tên của tất cả các task của Cathryn. Để làm được điều đó, bạn có thể query database để trả về các tasks “assignedStaff” có giá trị là “Cathryn”.

firebase
.database().ref(“tasks/”)
.orderByValue(“assignedStaff”).equalTo(“Cathryn”).once(“value”);

Vấn đề là nó sẽ trả tất cả mọi task được chỉ định với Cathryn, chứ không chỉ là task name. Nói cách khác có quá nhiều data thừa thãi.

Để khắc phục tình trạng trên, Firebase khuyến khích bạn denormalize data. Denormalization là thuật ngữ ám chỉ lưu trữ các phiên bản copy của dữ liệu trong database, nhằm cải thiện quá trình xử lí và đọc.

tasksByUser : {
    "Cathryn" : {
        "001" : "Development Round 1"
        "003" : "Browser Testing"
    }
    "Sam" : {
        "002" : "Development Round 2"
    }
}

Giờ nếu chúng ta lấy tên các task được chỉ định tới Cathryn, chúng ta sẽ chỉ đơn giản đọc từ một vị trí trong database:

firebase
.database().ref(“/tasksByUser/Cathryn”)
.once(“value”);

So với query ở trên thì nó sẽ xử lí nhanh hơn rất nhiều.

Denormalization nghe có vẻ như hack. Nhưng nó bắc buộc phải có để thiết kế một Firebase database cho web application với qui mô lớn và phức tạp. Đòi hỏi bạn phải rất am hiểu về data mà bạn muốn lưu trữ cũng như cách dùng chúng.

Trước khi nhảy vào tạo Firebase database, hãy bỏ thời gian học về denormalization, cách tạo cấu trúc cho data,  cũng như cách bảo trì chúng.

Sai lầm 4: Firebase có thể dẫn tới tình trạng dữ liệu không nhất quán

Nếu bạn thiết kế Firebase database đúng cách thì rất có thể data từ khắp database của bạn đã được denormalized. Và nếu dữ liệu của bạn được lưu trữ ở nhiều vị trí khác nhau thì hẳn bạn sẽ tự hỏi rằng “Làm cách nào để giữ cho data được nhất quán?”.

Bình thường, khi gửi data đến Firebase, bạn chỉ định một database path cũng như là loại data mà bạn muốn lưu trữ. Trở về với ví dụ, để update một task name (trước khi dùng denormalization), tôi sẽ làm như sau:

firebase
.database().ref(“tasks/001/name”)
.set(“Here’s the new name”);

Giờ với denormalization, tôi có thể update một task’s name bằng hai operations:

firebase
.database().ref(“tasks/001/name”)
.set(“Here’s the new name”);
firebase
.database().ref(“tasksByUser/Cathryn/001”)
.set(“Here’s the new name”);

Tuy vậy nó sẽ dễ bị dữ liệu không được nhất quán. Lỡ đâu một operation bị fail trong khi cái còn lại thành công thì sao? Vì thế mà ta cần một write operation tự động để cho phép tạo ra các database paths cùng lúc. Do đó, Firebase đã cung cấp multipath updates nhằm giải quyết vấn đề trên. Bạn có thể xem cách dùng chúng tại đây. Giờ thì update một task name sẽ chỉ cần làm như sau:

firebase
.database().ref()
.update({
    “tasks/001/name” : “Here’s the new name”,
    “tasksByUser/Cathryn/001” : “Here’s the new name”
});

Sai lầm 5: Khả năng querying rất hạn chế

Firebase thật sự rất hạn chế khi nói về query. Bạn có thể sắp xếp data theo keys hoặc giá trị và filter data.

Dựa theo ví dụ trên, ta có thể tạo một query để lấy tasks bắt đầu từ, trước hoặc sau 20170601. Tuy vậy, ta sẽ không thể lọc ra bằng nhiều giá trị và keys. Nói cách khác, việc query để thu hồi tasks được chỉ định tới Cathryn và bắt đầu sau 20170601 là điều không thể.

Dĩ nhiên là việc như vầy luôn là chủ đề phàn nàn của nhiều developer. Tuy vậy, mọi thứ đều có nguyên do của nó, Firebase là một real-time database và được thiết kế với mục tiêu xử lí thật nhanh. Vì thể để có được một query phức tạp thì sẽ đòi hỏi việc bạn thiết kế database của mình cho đúng.

Ví dụ như bạn muốn làm một query thu hồi các tasks được chỉ định tới Cathryn và bắt đầu từ 20170201. Tôi có thể thêm một “staff_startDate” property vào tasks của mình:

tasks : {
    "001" : {
        ...
        startDate       : "20170101"
        assignedStaff   : "Cathryn"
        staff_startDate : “Cathryn_20170101”
        ...
    }
    ...
}

Như vậy, khi cần ta sẽ chỉ phải query như sau:

firebase
.database().ref(“/tasks/”)
.orderByChild(“staff_startDate”)
.equalTo(“Cathryn_20170101”);

Tôi khuyến khích bạn xem qua Common SQL Queries converted for the Firebase DatabaseFirebase Database Querying 101. Khi bạn đã hiểu rõ về cấu trúc cũng như query data thì bạn sẽ có khả năng làm được nhiều queries phức tạp hơn.

Nguồn: Medium

Hãy viết thư xin việc theo cách “kì quái” này, bạn sẽ tìm được công việc mình muốn!

Mẫu CV

Là biên tập viên chuyên trang tuyển dụng The Daily Muse, Lisa Siva đã viết một bài chia sẻ bí quyết viết thư xin việc giúp tăng tỷ lệ được trả lời từ 0 lên 55%.

Bạn đã từng trải qua cảm giác viết thư xin việc, gửi đi trong háo hức nhưng mãi mãi không nhận được hồi đáp? Bài viết này có thể sẽ giúp bạn cải thiện tỉ lệ thành công của mình gấp bội!

Lisa Siva là biên tập viên của chuyên trang tuyển dụng The Daily Muse. Mới đây cô đã viết một bài chia sẻ “bí quyết” viết thư ứng tuyển đã giúp cô tăng tỉ lệ được trả lời từ 0 lên tới 55% trên Business Insider.

Khi mới chuyển tới New York, tôi đã từng là một cái máy viết thư xin việc (cover letter). Tôi đã từng viết thư cho tất cả các nhà tuyển dụng và thể hiện tình cảm với những vị trí mà trong thâm tâm cảm thấy chẳng chút hứng thú. Tôi tâng bốc những công ty trước giờ bản thân không hề biết tới sự tồn tại. Tỉ lệ thành công của tôi? Chỉ là số 0 tròn trĩnh.

Sau khoảng 10 lần không được hồi đáp, tôi bắt đầu cảm thấy mọi thứ gần như sụp đổ. Thậm chí, khi ngồi lướt tin tuyển dụng ở Starbucks, đã có những thời điểm tôi không thể kìm nén nổi và phải tự khóa mình trong phòng tắm khóc một mình.

Thế nhưng những trải nghiệm tồi tệ đó đã dạy cho tôi một bài học: Trên đời này không có gì là quá giới hạn. Tôi đã cho phép bản thân được thử nghiệm mọi kỹ thuật trong (và cả ngoài) các cuốn cẩm nang dạy viết thư giới thiệu, từ chèn thêm ảnh GIF Beyoncé cho tới giả vờ như mình và người quản lý là bạn bè thân thiết. Cuối cùng thì, sau 103 bức thư được gửi đi, tôi đã tìm ra công thức để thành công.

Chỉ trong vòng 1 giờ, tôi đã nhận được email hẹn phỏng vấn – hết cái này tới cái khác. Tỉ lệ thành công của tôi nhanh chóng tăng vọt từ 0 lên tới 55%, với những buổi phỏng vấn được lên lịch với Vogue, InStyle hay Rolling Stone. Nói cách khác, bức thư giới thiệu áp dụng một phương pháp viết đã có từ rất lâu rồi mà tôi sắp chia sẻ thực sự là đã thay đổi cuộc đời tôi theo hướng tích cực nhất.

Ngày hôm nay, tôi sẽ hé lộ công thức bí mật gồm 3 bước này cho các bạn.

1. Xác định vấn đề

55% nhà tuyển dụng không đọc thư ứng tuyển của ứng viên. Tại sao họ phải đọc khi ai cũng viết như Oliver Twists thời hiện đại, cầu xin họ “Làm ơn, hãy cho tôi một công việc”?

Sự thực là, nhà tuyển dụng không ở đó để biến giấc mơ của bạn thành hiện thực. Họ làm việc vì chính mình. Nghe thì có vẻ khắc nghiệt, nhưng đó là thực tế: họ muốn tìm kiếm những ứng viên tài năng giúp bộ phận (hoặc công ty) của mình phát triển hiệu quả và thành công hơn. Họ muốn tìm người giải quyết được các vấn đề thách thức của họ.

Chẳng hạn, khi được một người bạn giới thiệu cho một công việc tại tạp chí thời trang tôi đã là một fan ruột kể từ thời còn đi học, thay vì tỏ ra quá hào hứng, tôi đã bắt đầu thư xin việc của mình bằng câu:

“Là một cựu nhân viên Details.com và Vs. Magazine, tôi đã chứng kiến và hiểu rõ sự điên rồ và khối lượng công việc khủng khiếp trong các tháng thời trang.”

Chỉ với một câu ngắn thế này thôi, tôi đã gửi tới nhà tuyển dụng hai thông điệp: Tôi hiểu vấn đề anh/chị đang giải quyết và tôi đã từng trải qua vấn đề tương tự. Bí quyết ở đây là gì? Tìm ra và tập trung vào đúng vấn đề – thứ gần như không bao giờ xuất hiện trong bản mô tả công việc.

Khi bạn viết thư ứng tuyển của mình, hãy bắt đầu với danh sách các đầu việc nhà tuyển dụng yêu cầu và tự hỏi bản thân “Tại sao nhiệm vụ này lại quan trọng với công ty mình đang ứng tuyển?”. Hãy đào sâu hết mức có thể, thường thì nhu cầu thực sự của họ sẽ chỉ xuất hiện sau hàng loạt các câu hỏi tại sao.

2. Nhấn mạnh vấn đề

Sau khi đã xác định được vấn đề, phần tiếp theo mới hết sức thú vị.

Bởi lẽ không một nhà tuyển dụng nào nói rằng: “Tôi thích trả cho nhân viên hàng ngàn đô-la mỗi năm”, việc bạn cần làm là nhấn mạnh sự nhức nhối của vấn đề họ đang gặp phải, đồng thời chỉ ra giá trị mà giải pháp bạn có thể cung cấp mang lại. Đừng ngại nói quá lên một chút, giống như tôi đã làm trong đoạn thứ 2 thư ứng tuyển của mình:

“Nếu anh/chị đang tìm kiếm một người không chỉ có khả năng theo kịp tiến độ, mà còn có thể làm những bài slideshow dài 75 trang, chuẩn SEO và có phong cách như bài trên website 5 phút trước…”

Lưu ý rằng tôi không nói những thứ chung chung như “Nếu anh chị đang tìm một ai đó có thể xoay chuyển tình thế của các dự án một cách nhanh chóng…”. Tôi đưa nhưng ví dụ cụ thể nhằm thể hiện năng lực bản thân phù hợp cho vị trí biên tập viên mình đang ứng tuyển.
Còn nếu ngành hoặc vị trí bạn muốn ứng tuyển hoàn toàn mới lạ? Hãy hỏi. Tìm một ai đó trong công ty bạn đang muốn gia nhập, hỏi và chú ý lắng nghe cách họ đề cập tới các thách thức công ty đang gặp phải.

Trong giao tiếp, con người thường vô thức tin tưởng những người bắt chước ngôn ngữ cơ thể của bản thân. Chính vì vậy, hãy tranh thủ “bắt” những ẩn ý hay cụm từ cụ thể xuất hiện trong các cuộc trao đổi với nhân viên công ty và “bắt chước” ngôn ngữ nói của họ trong thư ứng tuyển của mình.

3. Đề xuất giải pháp

Tới thời điểm này, bạn đã bắt đầu khiến nhà tuyển dụng “đứng ngồi không yên” và muốn tìm hiểu thêm. Giờ là lúc đưa ra giải pháp. Và giải pháp đó chính là bạn.

Hãy nghĩ về thứ khiến bạn cực kỳ phù hợp để giải quyết vấn đề mới đặt ra. Trong trường hợp của tôi, tôi muốn nhà tuyển dụng nghĩ về mình và nói: “Lisa? Ồ, cô ấy giỏi về lập trình hệ thống và rất có năng lực.”

Và đây là cách tôi viết trong thư ứng tuyển để biến điều đó thành sự thực:

“Vì tôi rất thông thạo TeamSite (một nền tảng quản lý nội dung), tôi có thể làm quen và thành thục công việc mới rất nhanh chóng – từ sản xuất hàng tá bài viết blogs trong ngày cho tới liên tục làm mới trang chủ với những thông tin mới nhất về thời trang, tôi đã từng làm tất cả những việc như vậy. Quan trọng là, anh/chị sẽ không bao giờ thấy tôi kêu ca “Đây không phải việc của tôi!”

4. Chốt lại đầy tự tin

Sau khi hoàn thiện tất cả các bước trên, đừng kết thúc bằng những câu như “Hy vọng sớm nhận được phản hồi từ anh/chị”. Thay vào đó, hãy chốt lại bằng một câu văn thể hiện sự tự tin, năng lực và hứng thú với công ty bạn đang ứng tuyển:

“Tôi rất mong sẽ được biết thêm nhu cầu sản xuất tin tức của anh/chị và cách tôi có thể giúp đỡ mọi người!”

Boom. Bạn đã hoàn thành một bức thư ứng tuyển ấn tượng rồi đấy.

Dĩ nhiên, sẽ cần một chút dũng cảm để “dám” gửi đi những bức thư ứng tuyển thế này – trong lần đầu tiên, tôi đã sợ tới mức phải nhờ bạn trai ấn nút Gửi hộ mình.

Tuy nhiên, hãy nhìn mọi thứ theo cách này: Tất cả những người khác sẽ tìm mọi cách nhồi nhét đủ lời thề thốt thể hiện sự quyết tâm, đam mê, chăm chỉ của họ. Còn bạn thì sao? Bạn đã chứng tỏ bản thân từ chính thư ứng tuyển của mình, một cách hoàn toàn khác biệt.

Tạo CV Online miễn phí

Nguồn: Applancer Careers via Her Spiderum theo Trí Thức Trẻ/BI

Phân biệt Thực tế ảo (VR) vs Thực tế tăng cường (AR)

Một trong những sự nhầm lẫn lớn nhất trong thế giới thực tế tăng cường (AR) là sự khác biệt giữa Thực tế tăng cường và Thực tế ảo. Cả 2 đều nhận được rất nhiều sự chú ý từ truyền thông và hứa hẹn sẽ có sự tăng trưởng đáng kinh ngạc. Vậy sự khác biệt giữa thực tế ảo và thực tế tăng cường là gì?

Thực tế ảo là gì?

Thực tế ảo (VR) là một mô phỏng máy tính nhân tạo hoặc tái tạo một môi trường sống thật hay tình huống. Nó làm người sử dụng đắm chìm vào cảnh vật xung quanh bằng cách làm cho họ cảm thấy như họ đang trải qua những thực tế mô phỏng trực tiếp, chủ yếu bằng cách kích thích thị giác và thính giác của họ.

VR được sử dụng bằng cách đội 1 headset giống như Oculus của Facebook và sử dụng theo 2 cách nổi bật sau:

  • Tạo ra và tăng cường thực tế ảo để chơi game, giải trí và chơi ( Như video và computer game, phim 3D và màn hình hiển thị gắn trên đầu( Head mounted display))
  • Tăng cường đào tạo cho các tình huống thực tế bằng cách tạo ra các tình huống giả lập thực tế nơi con người có thể luyện tập trước ( Như việc giả lập các chuyến bay cho phi công)

VR được tạo ra thông qua ngôn ngữ lập trình VRML (Virtual Reality Modeling Language). Ngôn ngữ này có thể tạo ra hàng loạt hình ảnh và chỉ định các dạng tương tác khả dụng cho các hình ảnh đó

Thực tế tăng cường là gì?

Tăng cường thực tế (AR) là một công nghệ cải tiến các lớp máy tính tạo ra trên đỉnh một thực tế đang tồn tại để làm cho nó có ý nghĩa hơn thông qua khả năng tương tác với nó. AR được phát triển thành ứng dụng và sử dụng trên thiết bị di động để pha trộn các thành phần kỹ thuật số vào thế giới thực theo cách tăng cường lẫn nhau, nhưng cũng có thể tách ra một cách dễ dàng.

Công nghệ AR đang nhanh chóng trở thành xu hiện chính hiện này. Nó được sử dụng để hiển thị lớp phủ số điểm trên các trò chơi thể thao được truyền hình và bật ra email 3D, hình ảnh hoặc tin nhắn văn bản trên thiết bị di động. Các leaders trong ngành công nghiệp công nghệ cũng đang sử dụng AR để làm những điều tuyệt vời và mang tính cách mạng với hình ảnh ba chiều và các lệnh chuyển động kích hoạt.

Thực tế ảo và thực tế tăng cường

Thực tế tăng cường và thực tế ảo có phản xạ nghịch đảo của một trong 1 nhóm khác nhau với những gì mỗi công nghệ đang tìm kiếm để thực hiện và cung cấp cho người dùng. Thực tế ảo cung cấp một sự tái tạo kĩ thuật số của cuộc sống thực tế, trong khi thực tế tăng cường cung cấp các yếu tố ảo như một lớp phủ với thế giới thực.

AR và VR giống nhau như thế nào?

Công nghệ

AR và VR đều thúc đẩy các dạng công nghệ tương tự và chúng tồn tại để nâng cao và làm đa dạng trải nghiệm người dùng.

Giải trí

Cả 2 công nghệ này đều cho phép những trải nghiệm giải trí sẽ trở nên phổ biến và được ưa chuộng hơn. Trong khi đó trong quá khứ nhiều người cho rằng đó chỉ là một điều bịa đặt của khoa học viễn tưởng, thế giới nhân tạo mới đi vào cuộc sống dưới sự kiểm soát của người dùng, và các lớp sâu hơn của sự tương tác với thế giới thực cũng có thể đạt được. Các “ông trùm” công nghệ hàng đầu đang đầu tư và phát triển thích nghi mới, cải tiến và phát hành ngày càng có nhiều sản phẩm và các ứng dụng có hỗ trợ các công nghệ này cho người sử dụng ngày càng hiểu biết.

Khoa học và Y Dược

Thêm vào đó, cả AR và VR đều có tiềm năng lớn lao trong việc thay đổi cảnh quan của lĩnh vực Y Dược  bằng cách biến những thứ như phẫu thuật từ xa trở thành sự thực. Các công nghệ này thực tế đã được sử dụng để điều trị và chữa lành các điều kiện tâm lý như Rối loạn stress sau chấn thương (PTSD)

AR và VR khác nhau như thế nào?

Mục Đích

AR tăng cường trải nghiệm bằng cách thêm vào các yếu tố ảo như là hình ảnh kĩ thuật số, đồ họa, hoặc là các cảnh vật như là một layer mới trong việc tương tác với thế giới thực. Ngược lại, thế giới thực của VR hoàn toàn được tạo ra và điều khiển bởi máy tính.

Phương thức vận chuyển

VR thường được vận chuyển tới người sử dụng thông qua thiết bị điều khiển gắn vào đầu hoặc cầm tay. Thiết bị này cho phép kết nối con người với thực tế ảo và cho phép họ kiểm soát và định vị hành động của mình trong môi trường mô phỏng thế giới thực

AR ngày càng được sử dụng nhiều trong các thiết bị di động như latop, smartphone và tablet để thay đổi cách Thế giới thực và các hình ảnh kĩ thuật số, đồ họa giao nhau và tương tác lẫn nhau

Vậy làm thế nào để chúng làm việc cùng nhau?

Không phải lúc nào cũng là AR vs VR – không phải lúc nào chúng cũng hoạt động tách biệt với nhau mà thực chất thường kết hợp với nhau nhằm tạo ra trải nghiệm thậm chí còn tốt hơn cho người dùng. Ví dụ, haptic feedback là các chấn động và cảm giác được thêm vào sự tương tác với đồ họa lại được coi là một sự tăng cường. Tuy nhiên, nó thường được sử dụng cùng với thực tế ảo để tăng trải nghiệm người dùng thông qua các cảm nhận.

AR và VR đều là những ví dụ tuyệt vời của các trải nghiệm và tương tác người dùng nhằm tạo ra một vùng đất mô phỏng để giải trí và vui chơi hoặc để thêm một chiều hướng mới trong sự tương tác giữa thiết bị kĩ thuật số và thế giới thực. Cho dù là một mình hay kết hợp với nhau, chúng đều không ngần ngại mở ra thế giới thực và ảo như nhau.

Nguồn: augment.com

9 cách thể hiện cảm xúc khôn ngoan trong công việc

9 cách thể hiện cảm xúc khôn ngoan trong công việc
Success in business-group of excited people

Một trong những thách thức lớn mà bất cứ ai cũng phải đối mặt ở mọi nơi là học cách xử sự­ với đồng nghiệp ở nơi làm việc và tìm ra cách giải quyết tốt nhất có lợi cho tất cả những người liên quan.

Thông qua chỉ số IQ của một người chỉ thể hiện được kiến ​​thức và kỹ năng người đó có được trải qua giáo dục và kinh nghiệm, nhưng có thể sẽ đánh giá thiếu sót trong lĩnh vực khác, đó chính là EQ hay chỉ số thông minh cảm xúc.

Chỉ những ai có thể cân bằng chỉ số IQ và EQ ở nơi làm việc mới thực sự trở thành những người thành công như họ muốn. Sau đây là những bước để cải thiện chỉ số EQ của bạn để có thể bằng hoặc vượt chỉ số IQ.

1. Hiểu rõ nguồn cơn, đừng động vào chúng

Để nâng cao EQ, trước tiên phải hiểu về bản thân mình. Những điều gì thường làm bạn nóng giận hoặc là nguyên nhân gây ra những hành động phi lý của bạn hoặc làm bạn quá xúc động?

Nguyên nhân gì gây ra những cảm xúc, làm bạn thất vọng, giận dữ, khó chịu hoặc vô số cảm xúc khác? Một khi bạn biết nguyên nhân gây ra những điều đó, hãy nắm bắt chúng trước khi chúng xảy ra hoặc bắt đầu vượt ra khỏi tầm kiểm soát.

2. Biết cách kiểm soát

Con người ai cũng có cảm xúc. Có người bộc lộ cảm xúc ra ngoài, có những người không bao giờ biểu lộ cảm xúc. Những người có chỉ số EQ cao hiểu rõ cảm xúc của mình, nhận biết được cảm xúc và kiểm soát được khi nào và ở đâu nên bộc lộ ra ngoài. Họ giữ được bình tĩnh trong môi trường và những tình huống căng thẳng. Họ suy nghĩ có lý trí và làm việc có hiệu quả khi không để cảm xúc lấn át trong quyết định và phán quyết của mình.

3. Biết cách trở thành người giải quyết vấn đề

Nếu bạn muốn tăng chỉ số EQ, bạn phải học cách để giải quyết vấn đề một cách hiệu quả. Điều này có nghĩa là không vội vàng dùng cảm xúc để đưa ra quyết định mà nên suy nghĩ mang tính xây dựng thông qua các công cụ đưa ra quyết định như Delphi, Stepladder và 6 Lối Suy nghĩ để cân nhắc suy nghĩ và lựa chọn nhằm đưa ra những quyết định tốt hơn.

4. Biết cách dẫn dắt ý nghĩ

Để đi ngược lại suy nghĩ và những gì đang diễn ra trong đầu, một người có chỉ số EQ cao sẽ thường sắp xếp lại những suy nghĩ của mình để nhìn sự việc theo cách khác đi. Những tình huống căng thẳng sẽ không thể làm vô hiệu hóa họ mà sẽ trở thành thử thách đối với họ và họ sẽ phản hồi một cách khôn ngoan.

Một người có chỉ số EQ cao sẽ không rập khuôn hoặc lập tức nghe theo lời khuyên hay đề nghị của người khác. Họ sẽ cởi mở với những lời gợi ý và sẵn sàng nghe người khác chia sẻ ý kiến.

5. Biết khi nào nên bỏ đi

Nếu bạn muốn tăng chỉ số EQ, bạn phải học cách khi nào nên bỏ đi. Nếu bạn đang trong cuộc tranh cãi hay thảo luận và bầu không khí đang trở nên hết sức căng thẳng khi mọi người đều đang khăng khăng bảo vệ quan điểm của mình, bạn nên học cách bỏ đi. Một người trưởng thành khôn ngoan sẽ biết đưa ra lý do để xin một vài phút hoặc vài ngày xem xét lại vấn đề.

6. Biết cách tôn trọng tất cả mọi người

Khi tiếp xúc với người khác, bạn sẽ muốn đối xử tôn trọng với tất cả mọi người bất kể bạn cảm thấy họ là người ra sao. Đừng bao giờ để cảm xúc của bạn đối với một người hoặc nhóm người nào đó làm ảnh hưởng đến sự tôn trọng của bạn đối với họ. Hãy đối xử tôn trọng với họ như nhau trong mọi tình huống.

7. Biết và bày tỏ sự cảm thông, chia sẻ

Một kỹ năng của EQ cần phát triển đó là học cách bày tỏ sự cảm thông với người khác trong giao tiếp hằng ngày. Đây là khả năng đặt bạn vào địa vị của người khác. Bạn cần sẵn sàng đứng ở vị trí của người khác để nhìn nhận sự việc. Đây chính là bước cơ bản đầu tiên khi ứng xử với mọi người.

8. Biết cách xử trí những lời phê phán

Những lời phê phán không phải lúc nào cũng dễ nghe, nhưng nếu bạn muốn nâng cao chỉ số EQ, bạn cần học cách chấp nhận nó một cách thoải mái. Sau đó, nếu bạn thấy những lời phê bình đó là đúng, hãy áp dụng lời khuyên đó để tiến bộ hơn.

9. Hiểu rõ bản thân trong bất kì tình huống nào

Nếu bạn muốn tăng chỉ số EQ, bạn cần luôn thoải mái trong mọi tình huống trong xã hội. Bạn nên gây dựng sự tự tin khi nói chuyện với mọi người, ở bất kỳ đâu. Khi chỉ số cảm xúc càng tăng cao, bạn sẽ càng được đánh giá là một người giao tiếp giỏi, người có thể xử lý tốt những tranh chấp và xây dựng các mối quan hệ một cách chủ động.

Một người có năng lực, người có chỉ số IQ và EQ cao sẽ trở thành một người dẫn dắt những người khác và chính họ đến thành công lớn. Hãy dùng những ý kiến này để trở thành một người khôn ngoan trong công việc và gia nhập đội ngũ những người có chỉ số EQ cao.

Nguồn: Applancer Careers

8 tools cần có để tăng workflow khi lập trình web

8 tools cần có để tăng workflow khi lập trình web

Xuất thân từ developer, trước khi chúng ta deploy app hay ngay cả trước khi chọn bên cung cấp dịch vụ điện tử đám mây, ta nên cân nhắc những tools sẽ dùng cho khối lượng công việc hàng ngày. Những tools được liệt kê trong bài viết này sẽ giúp bạn tăng hiệu năng làm việc lên nhiều lần nhưng nếu không dùng đúng cách thì nó sẽ bị phản tác dụng, khiến cho project trở nên rắc rối và phức tạp gấp nhiều lần.

Một trong những phần quan trọng nhất để chúng ta có thể phát triển từ vị trí junior developer lên senior developer đòi hỏi ta phải biết sử dụng nhiều tools khác nhau để đơn giản hóa quá trình quản lí các task, giao tiếp với các team một cách dễ dàng cũng như kết hợp các tool lại với nhau để có được một stack hoàn hảo dành cho bạn và team của mình.

Là một technical startup co-founder, tôi có nhiệm vụ tạo ra một hệ thống làm việc phù hợp với mọi qui mô và dễ làm quen đối với người mới.

Trong bài viết này, tôi sẽ giới thiệu các tool mà các junior web developers thường dùng hàng ngày để quản lí, phân tích và bảo trì sản phẩm của họ. Bạn có thể đã biết qua một số chúng, thế nên tôi sẽ không đơn thuần nói sơ qua mà còn hướng dẫn bạn cách tốt nhất để dùng những tool này thật hiệu quả.

Slack

Mục đích sử dụng

Slack là một platform để giao tiếp giữa các team. Mặc dù ban đầu nó được tạo ra nhầm thay thế cho email mà theo tôi là vẫn chưa làm được, Slack vẫn có nhiều lợi ích khác. Cho dù bạn làm việc một mình đi nữa thì Slack vẫn là một tool rất tuyệt vời.

Slack đưa ra một cách giao tiếp trong nội bộ mới với các thành viên trong nhóm, cập nhật milestones, goals cũng như các vấn đề nổi bật. Nó còn giúp lên thời khóa biểu họp mặt, thậm chí cả việc đặt món ăn cũng được.

Thay vì chỉ có một chat room cho toàn team, Slack chia chúng thành nhiều channel khác nhau. Mỗi channel là một room chat riêng biệt cho từng lĩnh vực của công ty như development, sales, PPC campaigns, UI / UX và nhiều thứ khác.

Slack còn rất đa dạng về tính năng giúp bạn có cuộc nói chuyện tuyệt với những thành viên khác trong nhóm: emojis, chia sẻ hình ảnh, YouTube videos embedding và cả integrations.

Integrations cho bạn khả năng sử dụng 3rd party tools vào Slack. Bạn có thể lấy chúng từ marketplace của Slack hoặc tự mình tạo ra từ Slack API. Tích hợp Slack cho phép bạn lên kế hoạch meeting chỉ với một lần gửi mail, thông báo khi có người đang nhập vào room chat, đặt món ăn hay chỉ đơn giản là để giải trí.

Hệ thống search của Slack cực kì mạnh mẽ. Mọi message đều được indexed thế nên nó cực kì dễ phục hồi message bất kì trong mọi channel.

Ai nên dùng

Slack được tạo ra cho cả team. Nhưng, với tư cách là một developer thường làm các project nhỏ lẻ một mình, tôi khuyến khích bạn tự mở cho mình một Slack group và cứ tìm hiểu các tính năng của Slack. Bạn có thể tăng hiệu năng làm việc của mình bằng cách lên kế hoạch gửi message cho mình để nhắc nhở về meeting và thời khóa biểu làm việc.

Best practices

  • Tìm hiểu về những integration tốt nhất trên marketplace của Slack để tích hợp chúng vào Slack group của bạn
  • Phát triển integrations của riêng mình bằng các thư viện open source sử dụng Slack API.
  • Học các keyboard shortcuts của Slack
  • Luôn kiểm tra BitBucket integration cho Slack
  • Đọc qua All-in-one messenger tool trong phần dưới của bài viết để có thể dùng Slack tốt hơn trên desktop của bạn

Pricing model

Slack’s pricing model cho phép người dùng sử dụng miễn phí phiên bản Slack dành cho team nhỏ với tính năng search và hiển thị 10K messages gần đây nhất. Với Standard và Plus plans, bạn trả theo phí của từng thành viên tham gia và sẽ được cung cấp nhiều tính năng hơn.

Tip dành cho các người dùng lâu năm

Slack không chỉ dùng cho nội bộ của team mà còn có thể cho cộng đồng công cộng. Có hàng ngàn cộng đồng Slack cho bạn tham gia (phần đều miễn phí) để bàn luận và chia sẻ về sản phẩm, design, quá trình phát triển và nhiều nữa. Bạn có thể vào Slack List để tìm hiểu thêm.

Trello

 

Mục đích sử dụng

Trello là công cụ quản lý task vô cùng đơn giản nhưng khá mạnh mẽ. Trello có thể được dùng trong việc quản lý development workflow và tasks, cũng như các dự án marketing , blogs, online businesses.

User interface của Trello rất là tối giản hóa nhưng đầy đủ mọi thứ bạn cần để quản lí một project cho team từ 10 người trở xuống, bao gồm task labeling, attachments, task assignments và task scheduling.

Ai nên dùng

Là một developer với các side project của riêng mình, Trello có thể là câu trả lời hoàn hảo cho việc quản lí tasks và khối lượng công việc của bạn. Với một team 10 thành viên, Trello sẽ cung cấp mọi thứ bạn cần để quản lí project của mình thật hoàn hảo.

Best practices

  • Dùng các bảng khác nhau cho từng project của team. Bạn có thể những bảng dành riêng cho marketing, back-end development, front-end development etc.
  • Mỗi bảng nên có màu khác nhau để cho dễ nhận diện
  • Luôn để mở menu bên trái
  • Chỉ định các tasks cho từng thành viên trong nhóm hoặc xem tasks của riêng bạn bằng cách kéo bỏ hình profile vào menu bên phải cho một task cụ thể.
  • Khi bắt đầu một project, định nghĩa labels bằng cách mở một task và nhấp vào labels. Bạn có thể chỉ định label với các title khác nhau.
  • Sử dụng các cột khác nhau trong bảng để listing tasks hoặc component trong hệ thống của bạn, như listing To do, doing done tasks.

Pricing model

Toàn bộ những tính năng chính của Trello đều được tích hợp trong phiên bản miễn phí. Với integrations, nếu bạn muốn có bảo mật tốt cũng như support thì hãy thử Business and Enterprise plans, nó khá tuyệt vời khi bạn muốn mở rộng qui mô của project lên với nhiều task khác nhau.

Tip dành cho các người dùng lâu năm

Bạn có thể vào xem tại đây.

Redash


Mục đích sử dụng

Redash là một open-source tool tuyệt vời cho visualizing data trong một dashboard tinh tế. Nó cung cấp cho bạn tất cả mọi thứ cần thiết để team có thể query data, visualize và share nó.

Redash cũng tích hợp với tất cả các data sources nổi tiếng nhất như MySQL, PostgreSQL, MongoDB, ElasticSearch và nhiều hơn thế nữa.

Với Redash bạn có thể hiển thị hình ảnh minh họa data nhằm track milestones và giúp bạn cũng như team hiểu rõ hơn về những gì đang diễn ra trong project.

Redash còn có tính năng báo cho bạn biết về những thay đổi diễn ra cũng như ảnh hưởng của nó lên project.

Ai nên dùng

Khi bạn đã hoàn thành sản phẩm và tung ra thị trường, bạn bắt đầu phải thu thập dữ liệu cho database thì đó là lúc nên dùng tới Redash. Nó giúp bạn theo dõi các vấn đề có khả năng xảy ra, theo dõi tiến độ hoàn thành milestones cũng như thu thập insight từ data người dùng.

Best practices

Tích hợp daily metrics của Redash vào Slack giúp nó tự mở và hoạt động hằng ngày mà không phải mất thời gian mở từng phần mềm.

Pricing model

Redash hoàn toàn miễn phí.

Tip dành cho các người dùng lâu năm

Nếu bạn thấy có gì đó bị thiếu, hãy thử áp dụng và cải thiện nó cũng như đóng góp công sức của mình vào trong Github repository..

Zapier

 

Mục đích sử dụng

Đã biết bao nhiêu lần bạn tự nói với bản thân rằng: nếu ta có thể push data từ Facebook ads  vào một Google spreadsheet thì hay biết mấy!

Zapier là một tool để cho trường hợp trên. Nó chỉ cho chúng ta, các developers, rằng ta không cần phải chạy và dùng hết mọi integration thì mới có được kết quả như ý. Không chỉ thế, system càng ít code thì quá trình phát triển càng được rút ngắn, và như thế là tốt nhất.

Zapier tự động di chuyển thông tin giữa các web apps bằng việc tích hợp hơn 750 apps khác nhau. Nó cho phép bạn tạo ra những qui trình hoàn toàn tự động hóa và khối lượng công việc phức tạp chỉ với vài lần bấm nút.

Với Zapier, bạn có thể push mọi issue từ BitBucket lên Slack  chỉ với 2 phút setup hoặc tạo Trello cards từ các câu trả lời trong Google Form.

Ai nên dùng

Đã là developer thì việc phải xử lí APIs đã là chuyện như cơm bữa. Tôi khuyến khích bạn thử kiểm tra xem Zapier có những gì trước khi bạn dùng tới nó. Như vậy sẽ tiết kiệm được rất nhiều thời gian đấy.

Nếu bạn đang sở hữu một công ty của riêng mình, hãy dùng Zapier càng sớm càng tốt nhằm tránh gặp phải việc phát triển project dư thừa, bugs, cũng như dễ bảo trì hơn. 

Best practices

  • Đăng kí với Zapier
  • Vào xem tại đây để hiểu rõ hơn cách sử dụng Zapier

Pricing model

Zapier có phiên bản miễn phí nhưng sẽ bị giới hạn với chỉ 2-step zaps  và integrations. Tuy vậy cũng đủ để cho bạn tiềm hiểu và thử nghiệm rồi. Khi nào bạn cảm thấy chắc chắn cũng như tận dụng được giá trị của Zapier thì hãy chuyển qua hình thức trả phí.

Tip dành cho các người dùng lâu năm

Hãy thử dùng nó với Google Sheets  càng nhiều càng tốt. Nó sẽ giúp mọi thứ dễ dàng hơn rất nhiều.

Draw.io

Mục đích sử dụng

Draw.io là một tool khá tuyệt vời cho prototype, mock-ups và architecture design. Nó có thể được dùng trong nhiều trường hợp khác nhau nhờ vào bộ sưu tập template đồ sộ trong khi mục tiêu chính sử dụng Draw.io là để dành cho designing processes, systems, và views trước khi áp dụng chúng vào code.

Draw.io là một add-on cho Google Drive, thế nên nó phơi bài tất cả sharing và collaboration capabilities mà Google Drive có. Nhờ đó mà bạn có thể hợp tác một cách dễ dàng với các thành viên trong team để thiết kế ra servers architecture chẳng hạn.

Draw.io cung cấp nhiều components khác nhau cho việc chèn dễ dàng vào sketch. Bạn có thể đi từ flow charts cho tới Android, Bootstrap hay iOS screens.

Ai nên dùng

Draw.io là một trong những công cụ sketch tốt nhất mà tôi từng biết, và nó hoàn toàn miễn phí. Tôi khuyến khích bạn thử và dùng nó cho project tiếp theo trong giai đoạn design.

Pricing model

Draw.io hoàn toàn miễn phí

All-in-one messenger

Mục đích sử dụng

Phần lớn chúng ta đều có nhiều hơn một channel cho việc giao tiếp với đồng nghiệp, bạn bè và gia đình. Thường thì, mỗi channel giao tiếp, như WhatsApp, Slack hay Facebook Messenger, đều có web application riêng của nó do đó mà sẽ rất rối rắm cho người dùng.

All-in-one Messenger là một Chrome application tuyệt vời dành cho việc tập trung tất cả các channel giao tiếp vào một chỗ. Nó cho phép bạn mở những tab mới cho từng channel, các channel này đều hoạt động tốt và không bị thay đổi nên sẽ rất tiện dụng cho bạn.

Ai nên dùng

Từ các developer cho đến công ty, All-in-one messenger là một ứng dụng dành cho những người dùng sử dụng nhiều kênh giao tiếp khác nhau hằng ngày.

Best practices

Mặc dù nó không chỉ rõ, nhưng bạn có thể thêm tab vào trong cùng một channel giao tiếp. Ví dụ như nếu bạn là một thành viên của nhiều nhóm Slack khác nhau, bạn có thể chỉ định chúng với từng tab khác nhau và đặt tên theo ý thích.

Pricing model

All-in-one messenger hoàn toàn miễn phí.

Tip dành cho các người dùng lâu năm

Nếu bạn muốn có hiệu quả trong làm việc và không bị mất tập trung thì hãy cancel notifications trong mục setting tab.

BitBucket

Mục đích sử dụng

BitBucket là hệ thống quản lý distributed version nhằm giúp bạn dễ làm việc với nhóm hơn. BitBucket thuộc quyền sở hữu của Atlassian, công ty nắm trong tay Jira, HipChat, và Trello.

BitBucket, khác với Github, cho phép dùng repositories bản quyền nhưng miễn miễn phí cho tới 5 users. BitBucket user-interface cũng rất dễ nhìn và sử dụng. Không những thế integrations mà BitBucket cung cấp cũng rất hữu ích.

Ai nên dùng

Dành cho team các developer, với khả năng quản lí và đồng hóa các phiên bản khác nhau.  Tôi khuyên bạn nên dùng BitBucke để bảo đảm tính tương thích của các phiên bản code, deploy app suôn sẻ, cũng như tích hợp các tool của 3rd party để kiểm tra và nhiều nữa.

Best practices

BitBucket & Slack integration để push notifications từ BitBucket trực tiếp vào channel thuộc Slack group của bạn.

Pricing model

BitBucket cung cấp không giới hạn code repositories bản quyền cho 5 collaborators. Khi bạn muốn mở rộng qui mô của team cũng như project thì sẽ phải đăng kí trả phí.

Postman

Mục đích sử dụng

Các web developers luôn phải tạo API để bày ra backend code đến clients khác nhau như front end apps, mobile apps, và tổ chức bên thứ 3. Tuy vậy khi tạo ra và dùng APIs, nó khá là khó để theo dõi.

Postman là một Chrome application cho phép bạn dễ dàng gửi HTTP requests đến local hoặc global server tùy theo yêu cầu của bạn.

Postman, không như các tool khác, có GUI rất tuyệt vời để define HTTP request và phân tích response.

Ai nên dùng

Từ developer chuyên phát triển và test API của chính họ cho đến các công ty yêu cầu có hoạt động nhóm/team.

Best practices

Hãy luôn mở Postman  khi lập trình web applications, bạn sẽ thấy nó rất là hữu ích đấy.

Pricing model

Nếu bạn chỉ dùng cho bản thân thì Postman phiên bản miễn phí cũng cấp đầy đủ mọi thứ bạn cần nhưng nếu là cho team thì bạn sẽ cần căn nhắc đến việc trả phí.

Nguồn:Hackernoon

Làm sao tăng lương cho ngọt?

mẹo tăng lương

Mẹo tăng lương sao cho ngọt – Một bạn trẻ nhắn tin hỏi, chú ơi làm sao đề nghị tăng lương cho nó “ngọt”!

Đi làm ai lại không muốn được tăng lương, nhưng mở miệng đề nghị với sếp dễ thấy kỳ kỳ khó nói. Chắc rồi, nhất là đối với văn hoá Á Đông chung chung hay văn hoá Việt Nam nói riêng.

Nhưng khó nói cũng phải nói nếu nó làm mình bức bối quá. Vậy thì nói như thế nào cho nó ngọt đây? Dưới đây là những cách xin tăng lương khéo léo dành cho các bạn.

Không biết các chuyên gia về nhân sự nói sao chứ tôi thấy điểm mấu chốt của vấn đề nằm ở chỗ mình có thật sự xứng đáng được tăng lương hay không.

Nghĩa là những cống hiến của mình cho công ty là quá lớn so với đồng lương và vị trí công việc mà mình đảm nhiệm. Mình mà nghỉ việc thì khó mà tìm ra người thay thế. Tóm lại, công ty đang rất cần mình chứ không phải ai khác, chứ không phải chỉ cần có vị trí của mình.

Lúc đó thì nói như thế nào cũng không quá sai, chỉ có “ngọt” hay không ngọt thôi, vì vàng thật thì đâu bao giờ sợ lửa!

Ngược lại, nếu mình không ở trong vị trí “cửa trên” mà công ty đang cần nhiều đến như vậy thì có nói khéo như thế nào đi nữa cũng thấy sai sai. Đã vậy lời đề nghị mà còn được đưa ra sai thời điểm, ví dụ như ngay lúc công ty đang gặp khó khăn thì thôi khỏi nói, trở thành “lời đề nghị khiếm nhã” đúng nghĩa! Không ai duyệt cả, có khi còn mang hoạ vào thân!

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

mẹo tăng lương

Ngay cả trợ lý cận kề những 12 năm cho tỷ phú Elon Musk (chủ hãng xe hơi điện Tesla nổi tiếng thế giới) mà còn bị việt vị khi xin tăng lương. Không phải ông tỷ phú này hà tiện đâu, mà câu chuyện tăng hay không tăng lương có dính liền với sự công nhận mức độ cống hiến của nhân viên thuộc cấp, dính liền với sự công bằng, với mức lương của những người xung quanh nữa. Có khi chỉ làm một người vui thôi mà toàn thể cơ quan còn lại bị buồn và bất mãn, nên cái chi phí bỏ ra trong trường hợp này là quá lớn.

  Sếp nhớ trả lương em gấp 10 nha (phần 1)
  Sếp nhớ trả lương em gấp 10 nha (phần 2) - HĐH Ubuntu

Bởi vậy mà ngay cả ngài tỷ phú Elon Musk cũng phải đắn đo suy nghĩ. Rồi ông quyết định làm một bài test để thử xem vai trò của người trợ lý của mình quan trọng đến như thế nào. Ông cho người này nghỉ xả hơi 2 tuần, và trong thời gian đó không kêu ai thay thế mà tự mình cáng đáng hết công việc để xem sao.

Kết quả sau 2 tuần: ”không có mợ thì chợ vẫn đông”! No problem. Nghĩa là vai trò của nhân viên trợ lý này cũng không có gì là kinh khủng, vì vậy Elon Musk đã quyết định từ chối lời đề nghị tăng lương này. Hơi khô khan, nhưng đúng theo kiểu Mỹ, rất chuyên nghiệp. Dĩ nhiên người trợ lý đã không còn cơ hội để quay lại cái văn phòng mà mình đã gắn bó 12 năm.

Cho nên, không có gì nguy hiểm bằng lời đề nghị tăng lương. Phải bức bách lắm, phải thấy hợp lý hợp tình lắm mới dám mở miệng. Còn nói như thế nào cho nó “ngọt” thì có nhiều cách nói lắm.

Chuyên gia về nhân sự Lynn Taylor, cũng là tác giả của quyển sách “Tame your terrible office tyrant: How to manage childish boss behabior and thrive in your job” từng cho lời khuyên đại loại là, lựa thời điểm thích hợp rồi hỏi thẳng sếp đánh giá khả năng làm việc của mình thế nào, và theo sếp thì lãnh vực nào mình có thể trau dồi thêm để có thể đóng góp nhiều hơn cho công ty.

Theo tôi, mẹo tăng lương là chọn thời điểm thích hợp như thời điểm công ty thì đang làm ăn khấm khá, phát tài, thuận lợi, hanh thông, còn sếp thì lại đang vui vẻ và rõ ràng là đã tỏ vẻ hài lòng với công việc của mình. Coi như thiên thời địa lợi nhân hoà.

Theo lời khuyên của chuyên gia Lynn Taylor thì tuy là hỏi nhưng không phải hỏi, mà là nhắc khéo sếp nếu thấy khả năng em good như vậy thì có lẽ sếp đã quên điều chỉnh lương em rồi.

Cũng là xin tăng lương nhưng nghe tích cực hơn nhiều so với cách mà không ít người thường áp dụng, đó là “nói bóng, nói gió” là sẽ xin nghỉ việc vì đủ thứ lý do. Đặc biệt là lúc công ty đang thiếu người, dầu sôi lửa bỏng.

mẹo tăng lương

Đến khi sếp tra hỏi cho ra lẽ thì không có lý do nào là thuyết phục, ngoại trừ thông điệp là nếu không tăng lương thì tôi sẽ nghỉ việc. Ngay lúc này đây.

Đó là mẹo tăng lương không hay ho chút nào, vì nó giống như cưỡng bức, trấn lột người khác. Sếp có thể miễn cưỡng đồng ý đó, nhưng ấm ức ghim trong bụng và sực nhớ phải tìm người thay thế, dự phòng bất trắc từ ngay bây giờ. Mà cũng đúng, vì không ai muốn giữ chân người có ý định sẽ ra đi bao giờ.

  Bí quyết deal lương giúp bạn “lật bài ngửa” với nhà tuyển dụng

Coi như xong. Tăng lương kiểu này tưởng là “được” nhưng lại là “mất”, mất đi sự gắn bó, tin tưởng, sự thăng tiến tiềm năng, mất tất cả trong ánh mắt của sếp.

Tóm lại, đối đế lắm mới mở lời đề nghị tăng lương. Phải biết người biết ta, biết mình đang ở đâu trong đánh giá của mọi người xung quanh. Liệu khả năng và sự đóng góp của mình có thật sự vượt trội hay không. Liệu thời điểm mình mở lời có thích hợp hay không. Liệu cách mình đặt vấn đề có mang một thông điệp đầy tích cực hay không.

Và có lẽ mẹo tăng lương tốt nhất là phải đi kèm với tăng thêm trách nhiệm, tăng thêm vai trò trong sự thành công của công ty. Khi đó việc tăng lương chỉ là một hệ quả tất yếu.

Nguồn: Lý Quí Trung

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

Vì sao nút Like Facebook chiếm tới 16% lượng code của website

Dựa theo dữ liệu từ BuiltWith.com, 6% của hơn 10,000 site với lượng traffic cao nhất đến từ Facebook’s servers. Đa phần chúng là Facebook’s Javascript SDK, một đoạn code dành cho việc hiển thị các tính năng như nút Like và Facebook comment.

SDK code này có qui mô lớn tới mức nó chiếm tới 16% số lượng JavaScript được dùng trong web page.

Là một trong những software library nổi tiếng, Facebook SDK giúp chúng ta hiểu được vì sao các site ngày nay ngày càng nặng? Cũng như size bao nhiêu thì được xem là tốt nhất với webpage?

Vì sao lại nặng đến thế?

Facebook SDK có đầy đủ các tính năng cũng như tool cần thiết cho các developer sử dụng như: phương pháp thu thập dữ liệu từ các site khác, để xác định trình duyệt nào và thiết bị mà đối tượng đang sử dụng cũng như liên quan tới các yếu tố về UI. Nếu phải phân loại SDK thành những thành phần nhỏ thì chúng ta sẽ có được một bảng thông tin sau:

Trong đó, có 3 tính năng nổi bật nhất là:

 

“Canvas” là Facebook’s system cho app được load ngay trong Facebook page. Tuy vậy, chúng khá nhẹ và chỉ chiếm khoảng 1.5% kích thước của SDK.

Tiếp đó, chúng ta có legacy feature. Nó phản ánh việc một API sẽ tích lũy nhiều

interfaces để thực hiện một feature nhiều lần. Ví dụ như developers có thể viết code dùng để call FB.getLoginStatus() hoặc Auth.getLoginStatus(). Thường thì để ta có thể dùng cả hai thì phải cho ra hai phiên bản riêng biệt SDK, nhưng Facebook lại không muốn như vậy nhằm để đơn giản hóa cho developer cũng như giữ cho sự nhất quán trong loại file các site cùng sử dụng. Vì thế, SDK tốn khoảng 3.5% số code của nó để thực hiện legacy feature.

Ngược lại, Polyfill chiếm tới 15% số lượng code trong SDK. Nó được dùng để hỗ trợ cho các feature từ cũ tới mới, xuất hiện trong các phiên bản của trình duyệt web. Đa phần các Polyfill có trong Facebook SDK là nhằm cho các feature được số đông các internet user dùng ngày nay. Trong khi đó, nó chỉ hỗ trợ được cho khoảng < 1% các trình duyệt cũ như Internet Explorer 8, vốn đã bị nhiều trang web ngừng support.

~80% số lượng code còn lại của SDK bao gồm dành cho nhiều tính năng khác nhau. Thường chúng là những feature nhỏ nhưng kết hợp và hoạt động cùng nhau nhằm để tạo ra một trải nghiệm sử dụng tốt nhất có thể. Do đó, với chỉ một tính năng đơn giản là nút like thì ta cũng sẽ phải thêm những tính năng khác như comments, video embeds, login buttons, etc. Tất nhiên Facebook có thể hạn chế việc có quá nhiều tính năng nhưng theo góc độ kinh doanh, thì hãng luôn muốn người dùng xài càng nhiều sản phẩm từ hãng càng tốt.

Kích cỡ có quan trọng không?

Bởi vì Facebook’s SDK được dùng rộng rãi, lại được update thường xuyên, nhiều user có thể đã download nó về trước cả khi load một website. Nói cách khác, đây cũng là một trong những nguyên nhân Facebook lại cung cấp những file khá bự, thay vì những file nhỏ cho từng tính năng như nút Like. Mặt khác, tốc độ download giữa chúng cũng không có mấy khác biệt.

Tuy vậy, cho dù browser của bạn đã download SDK hay chưa, ta vẫn cần rất nhiều công đoạn để có thể chạy nguyên một khối Javascript code, đặc biệt là trên mobile. Với một Macbook Pro, Facebook’s SDK mất khoảng 50ms (1/20 của 1 giây) để chạy những site như buzzfeed. Không tệ khi mà ta phải load với một đống JS code, Ad cũng như những tính năng nhỏ lớn khác nhau.

Trên smartphone thì thời gian xử lí tăng lên gấp đôi với 1/10 giây:

Dựa vào số liệu thì sự khác biệt rất nhỏ nhưng do ta còn scroll và xem, do đó nên với SDK thì quá trình tương tác với webpage sẽ trở nên khá thô và lag. Đây là một vấn đề khá lớn khi các website ngày nay đều có code được đến từ một nhóm thứ 3.

Có thể nói, với sự tịch hợp các tính năng cũng như dữ liệu từ nhóm thứ 3 sẽ khiến cho việc khối lượng kích thước file sẽ bị tăng cao. Chưa kể, cảm giác khi bạn bỏ công làm ra hàng trăm, ngàn hàng code rồi phải bỏ đi 10% chỉ đơn giản là để bảo đảm hiệu năng, để rồi lại thấy người khác chèn cả đống code vào.

Bạn có nên dùng nó hay không?

Nếu bạn cần phải dùng một feature như Facebook Comments, thì Facebook SDK là điều bắt buộc. Tùy vào cấu trúc cũng site mà bạn có thể hạn chế sự ảnh hưởng của SDK và chỉ dùng nó khi cần.

Nếu bạn muốn xài nút Like, thì hãy ngừng và suy nghĩ lại. Facebook không còn hiển thị Like của một page như trước nữa. Vì thế hãy chuyển qua sài một nút share đơn giản. Nó cũng giúp bạn không phải lo về việc facebook theo dõi cũng như gián đoạn bạn.

Nguồn: blog.topdev.vn via Medium

8 lợi thế khi sử dụng Polymer so với Angular và React

polymer

Vì sao một số người lại không thể thành công?

Vì sao một số người lại không thể thành công

Hôm nay Edward lý giải một cách logic vì sao sẽ có một nhóm người – không thể nào thành công được, ngay cả khi họ rất nỗ lực và cố gắng. Hãy cùng xem xét thông qua việc phân tích dưới góc nhìn tâm lý.

Nhiều bạn trẻ, khi còn ngồi trên ghế nhà trường luôn mơ mộng về một ngày mình sẽ được làm việc trong môi trường chuyên nghiệp, lương cao, công việc nhẹ nhàng, sếp dễ tính, đồng nghiệp thân thiện, nói chung tất tần tật từ A-Z phải chiều theo ý của mình. Và rồi họ cũng hơi chút ảo tưởng về năng lực thực sự cũng như bằng cấp của mình. Thời nay, tấm bằng không đo được năng lực cũng như kinh nghiệm và đẳng cấp của bạn. Kết quả bạn thể hiện trong công việc, thái độ bạn thể hiện với mọi người mới nói lên bạn là ai.

Theo thống kê hơn 300,000 cử nhân thạc sỹ thất nghiệp sau khi ra trường. Con số ấy ngày nay vẫn tiếp tục tăng cao. Và rồi những bạn trẻ ấy quay sang đổ lỗi, than phiền. Họ kêu ca công ty thiếu chuyên nghiệp, sếp bóc lột, đây không phải là công việc theo đúng sứ mệnh mình sinh ra để làm. Theo phản ứng thông thường, nhóm người này bỏ cuộc quá sớm để tìm một công việc mới, hoặc tự tay “làm nên nghiệp lớn”. Và rồi sự thật phũ phàng là việc nào thì cũng khó khăn hết, công việc nào họ cũng chỉ cố làm ở mức hời hợt, theo kiểu làm cho có kinh nghiệm chứ cũng chẳng định gắn bó lâu dài gì cả. Còn chuyện khởi nghiệp, thì 90% doanh nghiệp “chết” tươi ngay sau 1 năm đầu, đó là thống kê. Để rồi khi ra trường vài năm, họ vẫn cứ loanh quanh, luẩn quẩn ở mức lương ba cọc ba đồng, sự nghiệp thì chưa có, kinh nghiệm cũng không, kỹ năng thì hổng chỗ nọ, kém chỗ kia.

KHỦNG HOẢNG TUỔI TRUNG NIÊN

Theo thời gian, họ phải đối mặt thêm với nhiều trách nhiệm và áp lực. Nếu lập gia đình là trách nhiệm với gia đình, nuôi con, mối quan hệ với họ hàng. Kéo theo là áp lực tài chính, áp lực công việc, áp lực với mối quan hệ. Chưa kể áp lực khi đồng trang lứa bạn bè thành công, mà mình nhìn đi nhìn lại vẫn đang chỉ là con số 0. Khi bước qua tuổi 30, có một hiện tượng tâm lý nhóm người này rất dễ mắc vào, đó là “khủng hoảng tuổi trung niên” – tức đánh mất niềm tin vào bản thân. Họ không còn tin mình có thể thành công. Và rồi họ buông xuôi tất cả. Lúc này cuộc sống với họ chỉ đơn thuần là lo chuyện cơm áo gạo tiền, giải quyết mớ trách nhiệm: nào hóa đơn tiền điện, nào hóa đơn tiền nước, nào tiền học phí cho con, sự nghiệp không thể tiến triển, cứ dậm chân tại chỗ, đầu tư cho bản thân cũng chẳng có cơ hội. Và rồi một ngày nào đó, họ chỉ còn biết “Giá như ngày xưa, mình đã làm gì đó khác đi.”

Đây là kịch bản của rất rất nhiều người ngoài kia. Ngày còn trẻ, ai cũng sung sức, ai cũng đầy nhiệt huyết hết. Nhưng khi còn trẻ mà không có nền tảng vững vàng, không làm đúng những bước đầu thì sau này sẽ rất khó, thậm chí là không thể thành công. Giống như trồng cây, bạn không thể nào gieo hạt bưởi mà lại mong khi lớn nên nó sẽ mọc thành cây xoài. Tương tự như vậy, tuổi ngoài 30 là kết quả của 10 năm đầu đời – những gì bạn làm ở tuổi 20s. Cho nên, hóa ra lúc bạn phải nỗ lực nhất, lúc bạn phải làm đúng nhất, lúc bạn phải cày cuốc, khổ ải nhiều nhất, lúc bạn phải học nhiều nhất lại là những năm tháng tuổi 20s – lúc bạn vẫn nghĩ mình là tỉ phú thời gian.

HỌC, LÀM THÌ ÍT – CHƠI THÌ NHIỀU – ĐI LÊN BẰNG CHIÊU TRÒ

Tỉ phú thời gian là câu nói cửa miệng của sinh viên, và cả những người mới đi làm. Nhưng thực sự mọi chuyện không đơn giản như vậy. Giống như cơn sóng thần, nó ập đến một cách rất bất ngờ, và trước đó trời thường quang, mây thường tạnh. Khi ra trường, cùng một lúc đủ mọi áp lực ập đến, là công việc, là gia đình, là môi trường mới,.. Hóa ra, các bạn sinh viên chỉ có một vài năm ngắn ngủi để chuẩn bị cho ti tỉ việc họ sẽ phải làm. Thế nhưng, họ chuẩn bị bằng cách nào? Học, làm thì ít – chơi thì nhiều.

Nói đến học, là kêu chán. Than phiền phòng đào tạo, than phiền cơ chế, giờ học thì ngồi ngủ. Lỗi một phần có thể do giảng viên, nhưng phần còn lại là do các bạn trẻ. Thời gian rảnh họ làm gì? Là con sâu cày phim, cày game, cày youtube. Buổi tối thì là chuyên gia đi nhậu. Mỗi khi sinh nhật, đâu chỉ đi một tăng. Phải đi tăng hai, tăng ba, tăng tư. Mà sinh viên tiền đâu ra, là trợ cấp của cha mẹ chứ đâu, hay đi làm thêm kiếm ít tiền mà đổi lại những cuộc vui chơi tốn kém như thế liệu có đáng? Chưa kể, họ cũng là vua đi chơi. Nay phải đi phượt cung này, mai lại đi phượt cung kia. Nói thẳng ra, thi thoảng đi thì có trải nghiệm sẽ rất vui. Nhưng mà đi liên tục, sinh viên vừa ít tiền, lại ít lựa chọn, chưa kể rủi ro nhiều. Trong khi thời gian đó, cân bằng lại, trải nghiệm vừa phải, đi chơi vừa phải; tập trung sức mạnh cho việc học, học chuyên ngành, học ngoại ngữ, phát triển bản thân, rèn luyện thể chất để đến khi đi làm ngay lập tức tạo ra sự khác biệt.

Chưa kể, có nhiều bạn trẻ hay thích dùng thủ đoạn khôn lỏi, luồn lách, lươn lẹo, tìm kiếm kẽ hở để ăn chặn, làm trò gian dối. Tuy nhiên, sự thật là cái kim trong bọc lâu ngày cũng lòi ra. Không có sự giả dối nào sống mãi với thời gian, và không sự thật nào không lớn lên cùng năm tháng. Với những chiêu trò, thủ đoạn thì đi đêm lắm cũng có ngày gặp ma, sớm muộn gì cũng bị phát hiện. Khi ấy tiền mất, tật mang, ảnh hưởng danh dự, mất hết mối quan hệ, mất công việc, nhìn đi nhìn lại thiệt hại đủ mọi đường. Cho nên, bạn trẻ làm ơn đừng vội nghĩ đến thủ đoạn, bởi có thể bạn thông minh, khôn lỏi nhưng hãy nhớ núi cao còn có núi cao hơn. Đó là chân lí. Sẽ có người nhìn thấy những điều đó, vấn đề chỉ là thời gian.

Ví dụ, Edward có một đứa em sinh viên trường Ngoại thương ngoài Hà Nội đi phỏng vấn ở một tập đoàn lớn đa quốc gia, vào vòng trong câu hỏi cuối cùng họ hỏi là “What’s your MBTI? Tell us about you?” Câu này làm gì có giáo trình Mác Lênin nào dạy, phần nhiều các bạn ú ớ nó là cái gì thế? Trong khi phân loại tính cách là công cụ mà Top Fortune 500 (500 công ty hàng đầu thế giới) họ đều xài. Con nhỏ thấy trúng tủ, vì hóa ra thời gian rảnh rỗi tìm hiểu sâu về tâm lý, phân loại tính cách, ứng dụng hiểu bản thân biết tất tần tật; lại thêm việc cũng chịu khó học Tiếng Anh mỗi ngày, trả lời vanh vách tính cách của mình, lại nói rõ điểm yếu, điểm mạnh phù hợp công việc. Nhà tuyển dụng thích quá, họ chốt luôn. Vừa thực tập một thời gian, quản lý đã đề xuất em nên vào trong Sài Gòn – trụ sở chính tập đoàn mình để học hỏi được nhiều kinh nghiệm trước khi quay trở lại trường học. Cho nên, bớt chơi bời, bớt lười nhác, bớt thời gian vô bổ, lo mà rèn luyện, mà học cho sau này.

HIỆN TƯỢNG ĐỨNG NÚI NÀY TRÔNG NÚI NỌ

Rất nhiều bạn trẻ gặp hiện tượng này. Họ bắt đầu một công việc, làm nó một cách hững hờ, được một thời gian thì chán, và họ nhảy việc. Sang công ty khác, được cái này thì mất cái kia, rồi gặp rắc rối, mâu thuẫn họ lại tiếp tục nhảy việc. Cứ như vậy, mỗi lần đi xin việc, nhìn trong CV thì hoành tráng: kinh nghiệm làm chỗ nọ, chỗ kia, trong thời gian ngắn mà làm tới mấy công ty liền. Mà cứ nhảy việc liên tục như vậy thì lấy đâu ra kinh nghiệm và năng lực thực tiễn.

Với nhà tuyển dụng chuyên nghiệp, dĩ nhiên đó sẽ là ứng viên họ ưu tiên loại đầu tiên bởi lẽ tuyển mấy bạn như vậy về để làm gì khi mà kinh nghiệm duy nhất họ có là kinh nghiệm nhảy việc. Trong tuyển dụng, có hai trường hợp tuyển dụng sai lầm nhiều nhà tuyển dụng rất lưu ý đó là tuyển dụng người nhưng sau đó không làm việc được (False Positive – FP) và không tuyển dụng người có thể làm được việc (False Negative – FN). Nhận biết FN thì bất khả thi nhưng nhận biết FP thì dễ, chỉ cần cho làm thử vài tháng là kiểm tra được ngay trình độ, lúc ấy họ loại cũng chưa muộn.

Với những người như này, họ luôn luôn không được làm bài bản và thành thục một kỹ năng chuyên nghiệp nào đó. Bởi lẽ thời gian đầu công ty nào cũng phải đào tạo bài bản hết cho nhân viên. Chưa kể, nhân viên còn phải thích nghi với văn hóa doanh nghiệp, ít nhất cũng cần phải có 1 năm để hiểu. Xong rồi cần từ 2-3 năm để thành thục công việc, để được giao thêm nhiều việc lớn hơn. Nếu cứ nhảy việc liên tục, làm sao họ có thể thành thục công việc ở tầng chuyên gia được. Mà như thế, làm sao họ có thể thành công được.

CÔNG THỨC CỦA THÀNH CÔNG LÀ NGUYÊN TẮC 10.000H

Đây là công thức mà nhiều sách, nhiều người đã đúc kết lại. Nếu đo lường bằng thời gian làm việc nó vào khoảng từ 7 – 10 năm trong nghề để có thể tích lũy đủ 10.000h. Trong thời đại công nghệ, nếu bạn có thêm kỹ năng sử dụng công nghệ và cập nhật công nghệ liên tục, cũng như có khả năng tự học tốt thì có thể rút ngắn xuống từ 5 – 7 năm. Thêm vào đó, nếu có sự tác động của thầy giỏi – người có kinh nghiệm thực sự kèm cặp thì thời gian và khả năng cập nhật kỹ năng, kinh nghiệm sẽ nhanh hơn rất nhiều.

Tuy nhiên, công thức này đúng nhưng chưa đầy đủ. Bạn có thể thấy có nhiều người họ làm việc 25 – 30 năm trong nghề, mà vì sao lại không tạo ra sự đột phá? Câu trả lời ở đây là do họ làm đi làm lại một việc nhưng không cập nhật, nâng cấp, cải tiến, tích lũy bổ sung kinh nghiệm cho mình. Thêm vào nữa, ở đây có một bẫy tâm lý gọi là “mắc kẹt ở mức trung bình”. Khi con người ta làm việc ở mức độ trung bình, không quá kém, mọi thứ ổn, họ rất dễ bị dậm chân tại chỗ. Đó là lý do vì sao có những người sẽ vẫn không đột phá và trở thành chuyên gia nếu không liên tục nâng cấp bản thân mình.

CÓ NHỮNG CHUYỆN, PHẢI CHUẨN BỊ TRƯỚC KHI QUÁ MUỘN

Có nhiều thứ lúc chúng ta học thì không cần dùng đến. Và nghịch lý nằm ở chỗ, khi có việc cần phải có kiến thức đó thì chúng ta lại không kịp học. Chẳng hạn, khi bạn học Tiếng Anh – bạn chưa chắc đã dùng đến ngay (chưa có cơ hội). Nhưng giả sử cơ hội đến (ví dụ bạn được đi du học) mà bạn lại chưa có Tiếng Anh, thì chắc chắn lúc đó không thể nào kịp. Cho nên, có những chuyện phải chuẩn bị trước khi quá muộn.

Ở các nước phương Tây, chẳng hạn ở Mỹ – các bạn trẻ được giáo dục về sự tự lập từ khi rất sớm. Chẳng hạn như khi bước vào trường đại học, ở tuổi 18 – họ bắt đầu lập các tài khoản khác nhau để tiết kiệm dần. Và một trong số đó, có một tài khoản mà ít người chú ý, nhất là khi còn trẻ, là tài khoản tiết kiệm tiền để nuôi con. Có thể khi mới là sinh viên, chưa thể kiếm được nhiều tiền nhưng tư duy cần chuẩn bị từ sớm là một tư duy rất đúng đắn. Vô tình như vậy, họ ý thức sớm cho tương lai của mình và dĩ nhiên sẽ không còn lãng phí tiền bạc. Đó chỉ là một ví dụ. Thêm một ví dụ khác, có nhiều người lúc sinh con – vẫn chưa hề chuẩn bị kiến thức về nuôi dạy trẻ. Mà khi đó đủ thứ áp lực, đủ tình huống phát sinh thì sao mà kịp thời cập nhật kiến thức. Cho nên, lúc cần học kiến thức về nuôi con, giáo dục con, giáo dục sớm hóa ra lại là khi mà chưa có con. Nhưng khi chưa có con mà lại đi học kiến thức nuôi dạy con, có khi lại bị nói là khùng, đó là nghịch lý.

Nếu muốn thành công sau này, ngay từ bây giờ bạn trẻ nên dành thời gian để chuẩn bị. Hãy nhớ “Thành công trong chuẩn bị là chuẩn bị cho thành công” hay “Không chuẩn bị là chuẩn bị cho thất bại”. Sự chuẩn bị toàn diện mọi yếu tố để bản thân có CÁI TÂM (đạo đức) – có CÁI TẦM (tầm nhìn) và có CÁI TÀI (tài năng thực sự). Chuẩn bị thì có đủ thứ, nhưng sớm bao nhiêu, chuẩn bị được nhiều bao nhiêu tốt bấy nhiêu, chẳng hạn như:

  • Chuẩn bị thật tốt về thể trạng và thể lực. Tuổi trẻ là phải khỏe mạnh thực sự.
  • Chú ý cẩn trọng về ăn uống, ngủ nghỉ, chế độ tập luyện thể dục, thể thao.
  • Chuẩn bị về ngoại ngữ. Tiếng Anh là ngôn ngữ bắt buộc. Và ráng thì ngày nào cũng đọc, học bằng tài liệu nước ngoài để nâng tầm tư duy.
  • Chuẩn bị kiến thức về tài chính, làm giàu. Sự giàu có chân chính mang lại sự tự do, chỉ đơn giản vậy thôi.
  • Chuẩn bị kiến thức và kỹ năng về làm chủ bản thân và các mối quan hệ. Ngày nào chúng ta cũng phải giao tiếp, đây là việc không thể tránh khỏi.
  • Chuẩn bị về chuyên môn. Làm nghề gì cũng được, miễn là lọt vào TOP 1% những người giỏi nhất. Mà muốn thành chuyên gia, ngày nào cũng phải học và đầu tư kiến thức vào lĩnh vực mình theo đuổi.

Còn nhiều thứ nữa, bạn đọc có thể cùng liệt kê ra.

Ngay từ bây giờ, khi bạn còn trẻ, có thời gian thực sự thì phải trân trọng quãng thời gian này. Tích lũy những thứ cần phải tích lũy, làm những việc mình cần phải làm, sống cuộc đời bạn muốn sống bởi lẽ chẳng ai mong muốn một ngày nào đó trong tương lai, mình lại bị rơi vào nhóm người không thể thành công.

Nguồn: Bài viết độc quyền tại Tâm lý học ứng dụng

Sử dụng Machine Learning để visualize customer preferences

Sử dụng Machine Learning để visualize customer preferences

Năm 2012, tôi đã thấy một trong những hình minh họa chữ ( word cloud visualization) tuyệt nhất tại New York Times. Được tạo ra bởi Mike Bostock, và team của anh ấy. Vốn là những chuyên gia về data visualization (minh họa data) để giúp người đọc hiểu rõ thêm về những vấn đề trong chiến dịch tái ứng cử của Obama.

Khi chúng tôi giới thiệu Soylent, đã có hàng lũ lượt các bình luận trên Hacker News, Twitter, và Reddit. Feedback nhiều vô kể, cả tích cực lẫn tiêu cực. Thật tiếc là chúng tôi không thể nào đọc hết từng ấy bình luận. Để đối mặt với vấn đề đấy, chúng tôi đã tìm cách để có thể những vấn đề quan trọng và nổi bật nhất đến từ cả 2 phía supporters và detractors. Sau đây tôi sẽ nêu ra cách thức mà để thiết kế ra hệ thống đó, sau đó dùng Elon Musk’s Hyperloop làm ví dụ.

Cách mà NYTimes tạo nên những hình minh họa như vậy

Nó so sánh việc các ứng viên thường xuyên dùng từ, câu văn nào. Dựa trên một phân tích từ transcripts của Federal News Service

Hiểu một cách đơn giản, vòng tròn càng to thì từ đó càng được dùng nhiều trong bài diễn văn của ứng viên, như từ “traditional” chẳng hạn. Thế nhưng hình minh họa của NYT có chút khác biệt bởi nó giúp bạn hiểu rõ hơn về những vấn đề mà 2 phe đối lập muốn hướng tới. Bình thường thì các hình minh họa chữ chỉ làm nổi bật đề tài chứ không cho biết thêm gì khác.

Một ví dụ minh họa chữ nhưng khá vô dụng

 

Ở hình trên, bạn không biết được gì ngoài tên của chủ đề và những thứ liên quan tới nó. Ngay cả việc dùng màu sắc cũng chả giúp ích được gì. Đã có rất nhiều bài viết chỉ trích việc thiết kế một cách mù quáng và không chưa đựng một ý nghĩa nào.

Hàng “thật” thì sẽ như thế nào?

Hình minh họa chữ các bạn được thấy của NYT là hàng “thật” bởi nó không chỉ cho chúng ta biết về những chủ đề nổi bật mà còn chỉ ra chúng thường được dùng bởi phe phái nào. Tương tự như việc phân tích customer feedback, chúng ta hiểu được một phần nào đó về họ cũng như những điều mà họ muốn nghe. Nói cách khác, ta biết rõ lập luận cũng như trường phái giữa phe cộng hòa và dân chủ. Khi tung ra một sản phẩm mới, đặc biệt là khi nó có nhiều phản ứng trái chiều. Cực kì quan trọng là bạn phải phân biệt được những vấn đề nào nổi bật nhất và đến từ ai.

Sử dụng machine learning / natural language processing, chúng ta có thể tự động phân loại bình luận nào tích cực/tiêu cực/ trung lập với phân tích tình cảm và sau đó xác định vấn đề gốc rễ thật sự của chúng.

Cách tạo ra một hệ thống tự động để làm công việc phân tích trên

Với HackerNews API, Google’s Natural Language API, và D3.js cũng như kết nối chúng bằng Python. Tôi muốn tạo ra một web tương tác, tự động phân tích và cho ra kết quả tương tự như hình minh họa chữ của NYT. HackerNews API được host trên Firebase và có tài liệu hướng dẫn kĩ lưỡng từ Github. Nó cho phép ta pull rất dễ dàng các bình luận về một nội dụng. Sau đó, Google’s Cloud Natural Language API giúp ta phân tích và lọc. Cuối cùng, khi đã biết được các nội dung nổi bật cũng như những ai thường nói tới nó thì việc làm hình minh họa chữ chỉ là việc cỏn con.

Code của ta thực chất sẽ làm những việc như sau:

  1. Dùng HackerNews ID để lấy IDs của bình luận từ HackerNews API
  2. Đến mấy cái threads của bình luận và thu thập chúng
  3. Submit từng bình luận đến Natural Language API và lưu trữ kết quả.
  4. Biến kết quả thành JSON object cho việc làm hình minh họa chữ bằng D3
  5. Dùng D3 để vẽ và cho ra hình minh họa chữ

Bước quan trọng nhất chính là khi phân biệt các comment tích cực hay tiêu cực. Đây là lúc chúng ta cần đến machine learning để phân loại chúng (tiêu cực hay tích cực, ý kiến của nhà đầu tư hay là của khách hàng). Ở hình trên, bạn có thể thấy kết quả từ Google’s Natural Language API. Nhờ vào API này mà chúng ta bớt đi khối lượng lớn công việc phức tạp và tốn thời gian khi phải xài một learning machine model mới, bởi Google model vừa chính xác lại giá cả phải chăng. Có thể thấy trong hình, toàn bộ các comment đã được phân chia dựa theo mức độ cảm xúc – tích cực, tiêu cực và trung lập. (điểm giao động từ -0.1 đến 1.0).

Với từng comment đi qua Natural Language API, điểm sẽ được cho và chúng được phân loại vào từng nhóm riêng. Sau đó, tùy vào điểm mà sẽ có màu khác nhau ví dụ như xanh cho nhóm khách hàng và đỏ cho nhóm đầu tư. Cuối cùng JavaScript library D3.js sẽ vẽ thành hình minh họa chữ cho chúng ta.

Sử dụng phân tích này trên Hyperloop launch của Elon Musk

Tôi nghĩ chúng ta có thể lấy Hyperloop launch làm ví dụ để sử dụng cho công nghệ trên vì một số lí do sau. Đầu tiên, Elon Musk vừa mới công bố rằng team của ông đang chế tạo và phát triển Hyperloop như trong phim giả tưởng. Các nhà đầu tư vẫn đang đổ tiền vào các dự án phát triển tương tự. Không chỉ vậy với sự hiện diện của KickStarter, các công ty cũng bắt đầu mạnh dạn hơn trong quá trình lên ý tưởng và testing chúng. Tuy vậy,  Elon Musk thật sự đã bức phá cược chơi với tuyên bố trên.

Sau đây là các comment trên HackerNew khi nghe tin Hyperloop launch, được minh họa chữ:

 

Sau đây là một số key-note chúng ta có thể rút ra:

  • Các nhà đầu tư lo lắng nhất về chi phí cũng như tính an toàn. Họ lo rằng tiền cần cho cơ sở hạ tầng của project sẽ vượt mức đạt ra và mất quá nhiều thời gian để hoàn thành.
  • Các người ủng hộ/khách hàng thì tin rằng Elon Musk là thiên tài có thể đạt được bất cứ thứ gì ông đề ra. Có thể thấy ông có khá nhiều ảnh hưởng lên độc giả tại HackerNews.
  • Vấn đề chính trị cũng khá được quan tâm bởi hai phía. Việc Hyperloop có khả năng sẽ lách được nhiều qui định nhưng chính quyền sẽ không dễ dàng gì làm ngơ.
  • Nhóm ủng hộ cũng khá quan tâm về các chi tiết thiết kế như nhiệt độ, áp lực, và nhiều yếu tố khác.
  • Các nhà đầu tư thì lo về tính khả thi của project hơn với các chi phí phát sinh khi phát triển project.

Tuy đây chỉ là một phần nổi của tảng băng nhưng nó cũng đã cho ta biết được rất nhiều thông tin quí giá và thú vị về suy nghĩ cũng như những vấn đề mà người dùng và nhà đầu tư quan tâm.

Áp dụng vào quá trình kinh doanh của Soylent

Tại Soylent, nhờ vào cách thức phân tích trên, chúng tôi hiểu rằng khách hàng của mình rất quan tâm tới những khía cạnh của sản phẩm như lành mạnh, tiện lợi và giá cả phải chăng. Nhờ đó mà Soylent nhận ra hướng phát triển mới cho sản phẩm của mình với khả năng mang lại cả 3 giá trị trên.

Nếu bạn cũng đang phát triển một công ty non trẻ và may mắn có được sự đóng góp nhận xét tích cực từ cộng đồng người dùng và nhà đầu tư. Tôi khuyến khích bạn sử dụng machine learning để có thể lọc ra những thông tin quan trọng và đầy quí giá về thị hiếu cũng như các giá trị mà khách hàng của bạn quan tâm tới.

Tham khảo thêm: Việc làm cho lập trình viên Machine Learning mới nhất

Nguồn: topdev via Hackernoon

Làm đúng một vị trí trong 2 năm, ổn hay không ổn?

Laptop and coffee cup on conference room table

Bạn có thể đang rất mong đợi được thăng chức, nhưng không phải lúc nào điều đó cũng có thể thực hiện được vào đúng thời điểm bạn cần nhất.

Một lúc nào đó, bạn sẽ nhìn vào hồ sơ của mình và nghĩ rằng “Ồ, mình đã làm ở vị trí này cho đến nay là đã hai năm rồi đấy.” Khoảng thời gian đó là lâu hơn so với bất kỳ vị trí nào khác bạn đã từng làm trước khi được lên vị trí này. Và bạn bắt đầu thắc mắc không biết có gì đó chưa tốt về mình hay không, hay liệu có điều gì bạn có thể làm để có thể cải thiện được bản thân mình hay không để có thể được thăng chức.

Trên thực tế, trong tình huống đó, sớm hay muộn bạn cũng sẽ nhận ra rằng không phải lúc nào việc đứng yên một chỗ trong hai năm cũng là điều gì đó kém cỏi. Tất nhiên nói một cách công bằng, cũng có những lúc điều đó cho thấy rằng có điều gì bạn cần phải cố gắng hơn. Hãy cùng nhìn vào cả hai trường hợp.

Sẽ là bình thường nếu bạn vẫn nhận được cơ hội để nhận lãnh đạo các dự án mới

Có thể bạn sẽ cảm thấy buồn bực vì những nỗ lực trong thời gian qua của mình chưa được công nhận bằng cách thăng chức, nhưng điều đó cũng không có nghĩa rằng bạn không phải là chỗ dựa vững chắc của các đồng nghiệp trong các dự án khó hơn so với trách nhiệm chính thức với vị trí của bạn.

Hãy nhìn kỹ vào danh sách những việc cần làm của mình. Liệu có phải sếp của bạn đã bắt đầu tin tưởng vào giao cho bạn những công việc rất quan trọng hay không? Bạn có cảm thấy rằng mình đang được đãi ngộ xứng đáng hay không? Nếu câu trả lời cho cả hai câu hỏi là có, thì khả năng cao là bạn đang làm nhiều hơn những gì được yêu cầu và mọi người xung quanh bạn đều công nhận điều đó.

Sẽ là không ổn nếu trách nhiệm của bạn từ trước đến nay vẫn vậy

Ngược lại, có lẽ bạn sẽ cần phải xem lại nếu như bạn vẫn phải làm những công việc bạn được giao từ những ngày đầu tiên bạn nhận vai trò này. Mặc dù một số yếu tố khác cũng có thể ảnh hưởng, nhưng khả năng cao là bạn vẫn đang làm những việc đó bởi vì bạn chưa thể chứng tỏ được với ai rằng bạn có thể làm được hơn thế cả.

Nếu bạn không chắc chắn được khả năng làm việc của mình là như thế nào, đừng ngại ngùng hỏi chính sếp mình để được nghe nhận xét thẳng thắn, để hiểu rõ hơn rằng bạn cần phải làm gì. Bạn có thể sẽ không thoải mái khi phải nghe những điều đó đâu, nhưng bạn sẽ hiểu rõ hơn bạn cần phải làm gì để có thể đặt bước tiếp theo trong sự nghiệp của mình.

Sẽ là bình thường nếu bạn vẫn đang học được những kỹ năng mới

Tất nhiên sẽ là khá khó chịu nếu như sếp không chịu vỗ vai bạn và nâng cho bạn thêm một bậc lương trong khi bạn vẫn đang học thêm được các kỹ năng mới hàng ngày. Tuy vậy, không có nghĩa là bạn sẽ phải từ bỏ những kỹ năng đó nếu như bạn có bao giờ quyết định nghỉ việc.

Khi bạn đang cảm thấy buồn bực, hãy nhớ một điều rằng: Bạn đang đặt mình vào một vị trí tốt hơn rất nhiều để có thể giành được một vai trò lớn hơn và cao cấp hơn trong tương lai.

Sẽ là không ổn nếu bạn đang cảm thấy chán nản

Vấn đề là thế này: Nếu bạn đang cảm thấy chán chường ở chỗ làm và trách nhiệm của bạn trong vài năm vừa qua vẫn chẳng có gì thay đổi, thì bạn chỉ đang làm hại chính mình mà thôi.

Bạn có đang tìm kiếm thêm những cơ hội phát triển mới không? Bạn có đang tình nguyện nhận thêm những công việc năm ngoài vùng an toàn của mình hay chưa? Nếu câu trả lời là không, thì việc bạn đang dậm chân tại chỗ có lẽ đang phản ánh chính mức độ chăm chỉ của bạn.

Sẽ là bình thường nếu hiện tại không có công việc nào phù hợp đang mở ra cho bạn

Trừ khi bạn đang làm việc cho một vài công ty, thì đội ngũ của bạn có lẽ sẽ không có thừa tiền để sẵn sàng thăng chức bất kỳ ai một cách cảm tính được. Bạn có thể đang làm rất nhiều việc—và rất nhiều trong số đó còn vượt xa trách nhiệm chính của bạn—nhưng sự thật ở đây có thể chỉ đơn giản là hiện tại chưa có chỗ để thăng chức thêm được cho ai cả. Và mặc dù điều đó khá là khó chịu, điều đó cũng không phản ánh được nỗ lực của bạn. Đến một lúc nào đó, bạn sẽ được công nhận vì khả năng và sự cố gắng của mình.

Sẽ là không ổn nếu như bạn không chịu đăng ký cho những vị trí đang mở

Sẽ rất dễ dàng để bạn tự thuyết phục bản thân rằng bạn không có đủ khả năng cũng như chưa sẵn sàng cho việc thăng chức. Đó là một nơi thoải mái để sống. Nhưng mặt trái của tâm lý này đó là bạn sẽ không bao giờ nỗ lực đặt bản thân mình vào một vị trí để có thể hiểu được rằng bạn có thực sự đủ khả năng làm được hay không.

Không bao giờ là dễ dàng để chấp nhận lời từ chối. Nhưng nếu như bạn cứ liên tục trốn tránh những cơ hội để đi bước tiếp theo trong sự nghiệp của mình, thì không một ai sẽ bắt bạn làm điều đó.

Sự thật là, được thăng chức sẽ là một sự khích lệ tinh thần rất lớn, cho nên sẽ là rất tự nhiên nếu bạn đang cảm thấy bồn chồn khi mãi mà vẫn chưa được thăng chức như mình mong muốn. Nhưng hãy nhìn kỹ lại tình trạng công việc hiện tại của mình.

Nếu bạn đang làm nhiều hơn so với những gì được yêu cầu và bạn thực sự tin rằng mình xứng đáng cho một vị trí mới, đừng ngại ngần nói chuyện với sếp của mình. Nếu bạn cảm thấy đó không phải là một lựa chọn tốt, hoặc bạn đã thử rồi nhưng không thành công? Vậy thì, bạn ạ, đã đến lúc phải đi tìm một công việc mới thôi.

Nguồn: Applancer Careers via Nhịp Sống Kinh Tế/QZ

Tản mạn về Testing

Alpha và Beta testing

Tôi đang làm việc cho một công ty có định hướng là một công ty công nghệ. Gần đây trong công ty tôi *talk* khá nhiều về Automation Test, TDD, BDD, blah blah như một mốt thời thượng, tuy nhiên lại không hiểu bản chất là gì, áp dụng thực tế như thế nào. Tôi nhận ra rằng tuyệt đại đa số nhân sự cốt lõi công ty tôi đều đang mắc kẹt trong “Hazard zone”, thích google rồi chém gió như những vị thần hơn là thực sự học hỏi, phát triển chuyên môn để nâng cao chất lượng sản phẩm. Điều này đem lại cảm giác giống như việc tôi vẫn đang tự hỏi làm sao để Việt Nam mình có thể “đón nhận và đi đầu cách mạng công nghiệp 4.0” với một nền giáo dục tệ hại như hiện tại.

Tuyển dụng it tester cho bạn

Thay vì tập trung vào các mỹ từ, tôi nghĩ cần hiểu cái cốt lõi trước: Test. Bạn sẽ auto hay TDD cái gì khi bạn chưa thực hiện test một cách đúng đắn, T(Test) is DD (Dump and Die) chăng? Đây cũng là chủ đề bài viết này tập trung chia sẻ, trong phạm vi khi thêm mới hay thay đổi một chức năng của ứng dụng web, một case gặp quá phổ biến dù trong công ty sản phẩm hay công ty gia công phần mềm. Bài viết cũng không sử dụng các khái niệm hàn lâm, mà tập trung vào sự vận dụng trong thực tế.

Test thực sự là phải làm gì?

Rõ ràng là khi làm một chức năng nào đó, bạn phải kiểm tra xem chức năng đó có hoạt động đúng như yêu cầu không. Thuở hồng hoang của phát triển sản phẩm, việc bạn ngồi bấm bấm nhập nhập để xác nhận, đó là test. Khi chức năng nhiều lên, bạn cần phải tài liệu hóa việc bấm bấm nhập nhập đó, ví dụ các file excel lưu các test case và kết quả, để tái sử dụng, tránh thiếu sót và cũng là để xác nhận quá trình test của bạn.

Rồi bạn nhận ra rằng, khi bạn thêm mới hay thay đổi một chức năng, để đảm bảo chất lượng sản phẩm, bạn cần thực hiện lại toàn bộ các test case chứ không chỉ test case cho chức năng đó, người ta gọi là kiểm thử hồi quy (Regression Testing). Và khi thực hiện việc này một cách đúng đắn, bạn lại tiếp tục nhận ra rằng nếu làm bằng tay, sẽ rất tốn chi phí, bạn cần một phần mềm thực hiện việc này giúp bạn. Tôi khá là tin rằng Selenium, rồi các Testing Framework xuất hiện đều theo sự tiến hóa tự nhiên này. Và khi bạn có JenkinsTravis CI hay những phần mềm tương tự, giúp tự động hóa các quy trình trong phát triển phần mềm, khái niệm Automation Test mới ra đời.

Điểm chung của quá trình nói trên đó là việc tạo ra các test case như là output và đây cũng là thứ tạo ra giá trị gia tăng của bạn trong phần test. Nếu như trước đây, bạn chỉ phải lưu các test case vào excel và thực hiện nó một cách thủ công thì ngày nay, bạn cần phải tạo ra các TaaC (Test Case as a Code) kiểu như:

<?php
$I->visit('/login')
  ->fill('email', 'john@doe.com')
  ->fill('password', 'secret')
  ->click('Login')
  ->amOnPage('/dashboard')
  ->see('John Doe');

Nếu trong dự án của bạn, các test case đều được viết đầy đủ và cover các chức năng theo kiểu TaaC như trên thì, xin chúc mừng!

Ai sẽ phải viết test?

Câu hỏi “Dev thì có phải viết test không?” có lẽ là được đặt ra khá nhiều. Câu trả lời rất đơn giản, giống như khi bạn làm ra cái gì, bạn phải kiểm tra nó có hoạt động không, đương nhiên các developer phải viết test.

Theo tự nhiên, câu hỏi tiếp theo sẽ là “Vậy Dev sẽ viết test nào, bộ phận QA để làm gì vậy?”. Để trả lời câu hỏi này, chúng ta cần đi phân loại test.

Để phân loại, tôi nhớ đến kiến thức đã được học ở khoa CNTT, ĐHBKHN, phân loại theo phương thức tiếp cận: phương thức kiểm thử hộp đen (black-box testing) và phương thức kiểm thử hộp trắng (white-box testing).

Black-box testing, nôm na là cái hộp đen, bạn sẽ không cần quan tâm những gì xử lý trong cái hộp đen đó, chỉ cần cho đầu vào và xác nhận đầu ra, nghe khá giống với những gì với bộ phận QA độc lập thực hiện.

White-box testing, nôm na là cái hộp trắng, bạn sẽ cần quan tâm những gì xử lý trong hộp trắng đó, vì trắng nhìn xuyên qua mà. Nếu quan tâm tới cụ thể code được viết như thế nào, kiến trúc ra sao, nghe khá giống với những gì developer cần làm.

Với suy nghĩ đơn giản như vậy, tôi đã phải bật cười khi đọc trên JIRA (công ty tôi dùng JIRA bản quyền để quản lý dự án) có những task kiểu như “Viết unit test cho …” song hành cùng với “Viết automated test cho…” hay giật mình khi một “senior” 20 năm kinh nghiệm phân loại rằng bộ phận QA sẽ làm kiểm thử hộp trắng.

Để phân loại chi tiết hơn có khá nhiều cách, mỗi sách lại có một định nghĩa riêng, nói chung tất cả đều hợp lý tùy vào trường hợp cụ thể. Tuy nhiên, qua kinh nghiệm thực tế trong môi trường phát triển phần mềm ở Việt Nam, tôi ủng hộ một cách phân loại đơn giản nhưng có giá trị áp dụng thực tiễn: Black-box testing sẽ là Acceptance Testing do bộ phận QA thực hiện, White-box testing sẽ chia thành Unit Testing và Functional Testing do developer thực hiện.

Acceptance Testing

Acceptance Testing về cơ bản là mô phỏng các thao tác của người dùng sử dụng sản phẩm để xem kết quả người dùng nhận được có đúng như mong muốn không. Nó giống như việc test được mô tả ở phần đầu bài viết.

Suy cho cùng, dù bạn làm gì, mục tiêu của bạn vẫn luôn là làm hài lòng khách hàng, và tôi không nghĩ là khách hàng sẽ hài lòng với một sản phẩm chất lượng không chấp nhận được. Nếu được hỏi bắt đầu viết test từ đâu khi tiếp nhận maintain một dự án legacy, tôi sẽ trả lời là từ đây. Acceptance Testing là chốt chặn cho chất lượng sản phẩm bạn bàn giao khách hàng.

Ngày nay, thế giới đã cung cấp khá đầy đủ những công cụ “make tester’s life easier”, giúp bạn viết Acceptance Testing dễ dàng. Ví dụ tôi dùng Laravel Dusk để test chức năng cho phép người dùng đăng nhập thêm các SSH key, sau đây là hai case đơn giản cho chức năng này:

<?php
namespace Tests\Browser;
use App\User;
use Tests\DuskTestCase;
use Laravel\Dusk\Chrome;
use Illuminate\Foundation\Testing\DatabaseMigrations;
class UserKeysTest extends DuskTestCase
{
    use DatabaseMigrations;
    
    protected $user;
    
    public function setUp()
    {
        parent::setUp();
        
        $this->user = factory(User::class)->create([
            'email' => 'john@example.com',
        ]);
    }
    /**
     * Test an user can add a ssh key.
     *
     * @return void
     */
    public function test_an_user_can_add_a_ssh_keys()
    {   
        $this->browse(function ($browser) {
            $browser->loginAs($this->user)
                ->visit('/user/keys/create')
                ->type('name', 'Macbook')
                ->type('public_key', 'ssh-rsa xxx')
                ->press('Create')
                ->assertPathIs('/user/keys')
                ->assertSee('Macbook');
        });
    }
    
    /**
     * Test name is required.
     *
     * @return void
     */
    public function test_name_is_required()
    {
        $this->browse(function ($browser) {
            $browser->loginAs($this->user)
                ->visit('/user/keys/create')
                ->type('public_key', 'ssh-rsa xxx')
                ->press('Create')
                ->assertSee('The name is required.');
        });
    }
}

Khi thực hiện Acceptance Testing, có những việc chưa hoặc khó mô tả bằng code, ví dụ kiểm tra tin nhắn OTP có được gửi về khi người dùng đăng nhập chẳng hạn, hay kiểm tra các chi tiết của giao diện sản phẩm, bộ phận QA vẫn phải thực hiện thủ công. Tên gọi User Acceptance Testing (hay Beta Testing) được sử dụng để chỉ việc kiểm thử chi tiết với vai trò người dùng cuối như vậy.

Nếu trong dự án bạn đang làm, Acceptance Testing đơn giản chỉ là vài dòng Excel, hay thậm chí là một thứ xa xỉ, tôi nghĩ là sự cải tiến là cấp bách, vì như vậy có nghĩa là bạn khó đảm bảo được chất lượng sản phẩm, và đang tụt hậu so với thế giới nhiều năm rồi.

Unit testing

Unit testing bản thân nó là cái gì đó khá trừu tượng vì tùy dự án, bạn có thể quy định “unit” ở mức độ nào. Thông thường, “unit” sẽ được quy định giới hạn trong một hàm (method) hay một class. Trong một dự án web thực tế, tùy vào kinh nghiệm và kĩ năng, developer sẽ đưa ra quyết định viết các Unit testing như thế nào cho phù hợp, có thể test đầu vào đầu ra của hàm, hay kiểm tra một phần hoặc toàn bộ class.

Một ví dụ unit testing đơn giản của bài toán Fizz buzz, cho đầu vào là 3, kiểm tra đầu ra của hàm fizzbuzz() có là fizz không:

<?php
use PHPUnit\Framework\TestCase;
class FizzBuzzTest extends TestCase
{
    // ...
    
    function test_3_is_fizz()
    {
        $this->assertEquals(fizzbuzz(3), 'fizz');
    }
    
    // ...
}

Hay trong một side project, tôi viết một unit testing thể hiện việc model Usercó quan hệ 1-n với model Server:

<?php
namespace Tests\Unit;
use Tests\TestCase;
use Illuminate\Foundation\Testing\DatabaseMigrations;
class UserTest extends TestCase
{
    use DatabaseMigrations;
    
    protected $user;
    
    public function setUp()
    {
        parent::setUp();
        
        $this->user = create('App\User');
    }
    
    public function test_an_user_has_servers()
    {
        $this->assertInstanceOf(
            'Illuminate\Database\Eloquent\Collection', $this->user->servers
        );
    }
}

Nếu cần thêm các ví dụ, bạn có thể tham khảo thêm Unit testing được viết trong các thư viện mã nguồn mở trên Github.

Functional Testing

Functional Testing, hay cá nhân tôi hay gọi là Feature Testing, đúng với nghĩa của nó, test chức năng với các xử lý business logic bên trong chức năng đó đồng thời cô lập (mock) với các thành phần bên ngoài khác.

Ví dụ cụ thể, trong một side project, tôi cần thêm API cho phép user thêm mới một server, luồng xử lý là như sau:

  • Đăng nhập bằng một user.
  • Gửi POST request đến URL /api/servers với payload {"name": "small-snowflake", "ip_address": "1.1.1.1"}.
  • Response trả về thành công (có HTTP code là 200).
  • Đọc public key của bản thân web server.
  • Thêm mới bản ghi vào bảng servers, lưu thông tin server và public key vừa đọc được.
  • Gọi queue job AddServerToKnownHostsFile (để thêm địa chỉ IP của server vào known_hosts file).
  • Fire sự kiện RefreshServers.

Đọc public key của bản thân web server là hành động tương tác với bên ngoài, cái tôi thực sự cần chỉ là public key để lưu vào DB, cho nên tôi sẽ cô lập việc đọc này, giả định nó chạy đúng và trả về chuỗi public key.

Gọi queue job AddServerToKnownHostsFile là một chức năng bên ngoài, tôi giả định là nó chạy đúng và chỉ cần quan tâm là job này có được gọi hay không. Tương tự với fire sự kiện RefreshServers. Bản thân job AddServerToKnownHostsFile hay sự kiện RefreshServers có thể được test trong các unit testing hay functional testing độc lập khác.

Tôi có thể viết functional testing của chức năng này như sau:

<?php
namespace Tests\Feature;
use Tests\TestCase;
use App\Events\RefreshServers;
use Illuminate\Support\Facades\File;
use App\Jobs\AddServerToKnownHostsFile;
use Illuminate\Foundation\Testing\DatabaseMigrations;
class CreateServerTest extends TestCase
{
    use DatabaseMigrations;
    
    protected $user;
    
    public function setUp()
    {
        parent::setUp();
        
        $this->user = create('App\User');
    }
    
    public function test_an_user_can_create_new_servers()
    {
        File::shouldReceive('get')
            ->once()
            ->andReturn('public-key');
        
        $this->expectsJobs(AddServerToKnownHostsFile::class);
        
        $this->expectsEvents(RefreshServers::class);
        
        $this->actingAs($this->user, 'api')
            ->postJson('/api/servers', [
                'name' => 'small-snowflake',
                'ip_address' => '1.1.1.1',
            ])
            ->assertStatus(200);
        
        $this->assertDatabaseHas('servers', [
            'user_id' => $this->user->id,
            'name' => 'small-snowflake',
            'ip_address' => '1.1.1.1',
            'public_key' => 'public-key',
        ]);
    }
}

Kết luận

Một khi dự án của bạn thực sự có các TaaC, tôi khá tin tưởng rằng năng suất của dự án tăng lên nhiều lần cả về chất lượng, chi phí, lẫn khả năng delivery. Khi bạn sử dụng Jenkins để tự động quy trình thực hiện các TaaC đó, bạn sẽ có Test Automation. Khi bạn có Test Automation, bạn sẽ có khả năng kiểm soát rủi ro khi phải giao hàng sớm và thường xuyên cho khách hàng. Và khi bạn có thể làm vậy, bạn đã có một trong những điều kiện tiên quyết để trở nên Agile, Agile thực sự chứ không phải khuôn sáo, vẽ vời lý thuyết như bán hàng đa cấp.

Về quy trình phát triển phần mềm, khi bạn có các TaaC, bạn sẽ nhận ra rằng, việc viết test trước sẽ giúp bạn có cái nhìn rõ ràng hơn về yêu cầu khách hàng, bạn có Test-Driven Development chứ không phải Test is Dump and Die nữa :).

Thực sự viết được các TaaC cho một dự án, không phải điều dễ dàng, nếu không muốn nói là khó, đòi hỏi hiểu biết về kiến trúc và thiết kế tổng quan, hiểu yêu cầu của sản phẩm, viết code testable, các kĩ thuật mocking. Để làm được cần kiến thức cơ bản tốt, thực hành và rèn luyện kĩ năng, với mindset tập trung vào việc làm ra những sản phẩm chất lượng, liên tục cải tiến năng suất và chứng minh điều đó qua sự hài lòng của khách hàng. Chứ đừng như một số “senior” tôi vẫn hay gặp, *talk* như là expert về những thứ mà chỉ biết qua google, không có kĩ năng và kinh nghiệm làm bao giờ, và khi training cho các fresher, junior thì làm liên tưởng đến những giáo viên tiếng anh ngày xưa dạy học sinh phát âm sai vì ngay bản thân mình cũng không biết phát âm thế nào. Nếu không, thì tôi không nghĩ chúng ta có thể sớm thoát khỏi được cái mác nhân công giá rẻ, mặt bằng chất lượng tệ hại và mãi là vùng trũng của phát triển phần mềm.

*talk*: nó mang sắc thái trong câu nói nổi tiếng của Linus Torvalds: “Talk is cheap. Show me the code”.

Nguồn: medium.com

10 lời khuyên để giảm thiểu mối đe doạ an ninh nội bộ

Mối đe doạ nội bộ có thể gây rủi ro lớn hơn cho dữ liệu của công ty hơn các cuộc tấn công đến từ. Dưới đây là một số kỹ thuật giúp bạn phát hiện và giảm thiểu chúng càng nhanh càng tốt.

Một báo cáo gần đây được phát hành bởi Viện Critical Infrastructure Technology (ICIT) đã chỉ ra rằng hầu hết các sự cố cybersecurity (cố ý và tình cờ) là kết quả của một số hoạt động nội bộ.

Đầu năm nay, tôi đã giới thiệu một số cách để làm giảm nguy hiểm nội bộ. Là một người quan sát, tôi luôn muốn xem xét thêm các chiến lược có thể giúp người quản trị hệ thống nhanh chóng phát hiện và giảm nguy cơ rủi ro nội bộ – một yêu cầu quan trọng cho một thực  tế rằng một số vi phạm an ninh nội bộ đã không bị phát hiện ra trong 1 tuần, 1 tháng hay có thể là cả 1 năm.

Dưới đây là 10 lời khuyên để giảm thiểu mối đe doạ nội bộ.

1.Thành lập đội ngũ an ninh và phản ứng

Thậm chí nếu nó chỉ là 1 cá nhân, một đội ngũ chuyên dụng là điều cần thiết cho bảo mật thông tin. Nhóm này phải có trách nhiệm phát hiện, ngăn chặn và xử lý sự cố, cần phải có tài liệu, kế hoạch và thủ tục cho mỗi sự cố này. Đào tạo cho họ cũng như các nhân viên khác về an ninh để theo kịp trên các chiến thuật mới nhất cùng các mối đe dọa, đó là một yếu tố quan trọng trong việc xác định sớm các mối đe dọa.

  1. Sử dụng tài khoản tạm thời

Thiết lập cho các nhân viên của bên thứ ba (như các nhà thầu hoặc thực tập sinh) các tài khoản tạm thời. Với thời gian hiệu lực kết thúc vào ngày hết hạn hợp đồng hoặc dự án của họ. Điều này đảm bảo rằng các tài khoản này không thể tiếp cận khi các cá nhân rời đi. Bạn có thể gia hạn thêm thời gian tài khoản của họ nếu cần thiết.

  1. Tiến hành kiểm tra thường xuyên

Kiểm tra các tài khoản không sử dụng để vô hiệu hoá hoặc gỡ bỏ chúng nếu có thể

Cách đơn giản nhất là dùng lệnh ”dsquery” trên Windows Active Directory Domain Controller.

Giả sử bạn có một domain tên là company.com và bạn muốn kiểm tra tài khoản không được sử dụng trong 12 tuần vừa rồi. Gõ:

dsquery user dc=company,dc=com -inactive 12

Bạn có thể kiểm tra rõ ràng OU bằng cách chỉnh sửa lệnh trên. Ví dụ: Nếu tài khoản người dùng được lưu trữ tại CompanyUsers OU, bạn chỉ cần:

dsquery user ou=CompanyUsers,dc=company,dc=com -inactive 12

Bạn cũng có thể dẫn nó đến một tập tin văn bản nếu bạn muốn đề cập đến nó hoặc ghi lại tài liệu của bạn:

dsquery user ou=CompanyUsers,dc=company,dc=com -inactive 12 >> c:\inactive.txt
  1. Thực hiện nguyên tắc chấm dứt hợp đồng một cách cẩn thận.

Xoá quyền truy cập và vô hiệu hóa tài khoản càng sớm càng tốt khi nhân viên rời đi. HR và nhân viên nên tiếp xúc trực tiếp với các tài khoản khi nhân viên rời khỏi hoặc có một kế hoạch từ trước. Nhiều công ty tài chính cảnh báo với nhân viên IT trước về kế hoạch chấm dứt những nhân viên chủ chốt, để truy cập bị chặn lại khi họ chỉ vừa bước ra khỏi cửa.

  1. Xác định nhân viên không hài lòng

Nhân viên bất mãn có nhiều khả năng đưa ra mối đe dọa nội bộ với mong muốn để trả thù, một kế hoạch để ăn cắp dữ liệu và bán cho các đối thủ cạnh tranh, hoặc chỉ là sự tham. Không chỉ phải theo dõi, bạn nên nỗ lực để giảm bớt nguồn gốc của việc không hài lòng của họ, để cải thiện tình hình.

  1. Sử dụng xác thực 2 lần

Thường được mô tả như là “một cái gì đó bạn có và một cái gì đó bạn có biết”, ví dụ phổ biến nhất là sử dụng một RSA token mà hiển thị một chuỗi quay số mà bao gồm một mã xác thực. Người dùng cần phải gõ mật khẩu hoặc mã PIN thay đổi liên tục để được truy cập vào một hệ thống, vì vậy bất cứ ai có được mật khẩu hoặc token (nhưng không phải cả hai) sẽ bị chặn.

  1. Sử dụng mã hoá các dữ liệu

Cái này rất đơn giản; dữ liệu mã hóa sử dụng bất cứ phần mềm hoặc phần cứng công nghệ phù hợp với bạn, và chắc chắn rằng nó được lưu trữ hoặc chuyển đổi trên mạng. Bằng cách đó, nếu ai đó đang hack lưu lượng truy cập, đánh cắp một ổ cứng từ máy chủ, hoặc có được file sao lưu họ sẽ không thể có được các dữ liệu liên quan.

  1. Xem xét sản phẩm của bên thứ 3

Một trong những loại sản phẩm mà có thể giúp quản lý là giải pháp nhận dạng, nó có thể cung cấp các quyền truy cập qua việc nhận dạng cá nhân.

Công tác phòng chống mất mát dữ liệu và giám sát hoạt động của người dùng của được tham chiếu trong báo cáo của ICIT là hai giải pháp quan trọng để giảm thiểu rủi ro nội bộ.

Theo kinh nghiệm, một sản phẩm như Tripwire cũng có thể là một món quà ở đây. Tripwire kiểm soát hệ thống và thông báo cho bạn khi có thay đổi bất kỳ yếu tố nào trên chúng, chẳng hạn như một tập tin mật khẩu, một bảng tính bí mật hoặc một khoá SSH. Bây giờ, nhiều tập tin có thể và thay đổi mỗi ngày, vì vậy có thể có một tỉ lệ cao các tín hiệu nhiễu lúc đầu, nhưng bạn sẽ có thể để lọc ra các hoạt động bình thường từ các hoạt động bất thường sau khi thiết lập các cơ sở mẫu của các hoạt động để phát hiện các hành vi đáng ngờ.

  1. Đừng quên bảo vệ từ phía ngoài

Còn nhớ bộ phim “When a Stanger Call”? Trong phim một người giữ trẻ giữ nhận được cuộc gọi điện thoại đe dọa và có cảnh sát theo dõi họ, sau đó đã nói, “chúng tôi đã tìm ra… cuộc gọi nó đến từ bên trong nhà!” Bạn có thể tranh luận rằng điều này là mối đe dọa nội bộ cuối cùng, nhưng phải luôn suy nghĩ rằng các đối thủ đã trà trộn vào bằng cách nào đó. Đừng nghĩ rằng bạn chỉ bảo vệ phần mạng nội bộ; tập trung các sáng kiến an ninh và các nỗ lực trên tất cả các thiết bị bên ngoài.

  1. Hãy xem xét đầu tư vào các sản phẩm và đội ngũ nhân viên nhiều, hơn chỉ là “bảo hiểm”

Đây thực sự là một suy nghĩ hơn là một lời khuyên, nhưng nó có giá trị thảo luận. Quá nhiều giám đốc điều hành dường như nghĩ rằng các sản phẩm an ninh là chỉ bảo hiểm, họ phải trả tiền cho nó hoặc nếu không thì điều gì tồi tệ có thể xảy ra. Đó là cách tiếp cận sai lầm và có thể ảnh hưởng ngân sách. Chắc chắn chúng tôi không xem cảnh sát như một sự lãng phí trong ngân sách thành phố, đặc biệt là khi chúng tôi cần sự giúp đỡ của họ.

Nhiều công nghệ và sản phẩm tôi đã thảo luận rằng có thể làm nhiều hơn là chỉ cung cấp bảo mật. Ví dụ như Splunk,có thể gửi các thông báo liên quan đến tất cả các loại vấn đề hệ thống như sự hư hại phần cứng hoặc khả năng vượt quá ngưỡng. Thực hiện tốt về bảo mật có thể làm giảm giám sát (hoặc hình phạt) từ kiểm toán cho công ty. Và điều quan trọng là hãy nhớ rằng chi tiêu một chút (hoặc nhiều) về bảo mật có thể giúp ngăn ngừa các chi phí lớn hơn xuất hiện, chẳng hạn như doanh thu bị mất trong sự phát tán dữ liệu công cộng.

Nguồn: techrepublic.com

12 hành động nhỏ của nhân viên được lãnh đạo coi trọng “như vàng”

12 hành động nhỏ của nhân viên được lãnh đạo coi trọng

Nhìn lại cách đây 13, 14 năm, lúc mình còn đi làm ăn lương và đạt được sự thăng tiến tốt và có được ngày hôm nay là cả một hành trình dài. Những đức tính bên dưới đã giúp mình và chắc chắn sẽ giúp bạn phát triển hơn bao giờ hết, cho dù bạn là nhân viên hay chủ doanh nghiệp cũng nên ghi nhớ. Đọc hết nhé!

Trong công việc đa số nhân viên đều mong muốn có được sự coi trọng và tín nhiệm của lãnh đạo, tuy nhiên muốn được lãnh đạo coi trọng và tín nhiệm lại hoàn toàn phụ thuộc vào sự biểu hiện cụ thể của bạn.

Một khi bạn đã không được lãnh đạo tín nhiệm, dù bạn có làm được bao nhiêu việc đi nữa, sau này cũng không thể phát triển theo chiều hướng tích cực hơn được. Vì vậy, chúng ta phải làm sao để được lãnh đạo coi trọng và tín nhiệm đây?

1. Sự trung thành

  • Đứng trên lập trường của lãnh đạo để suy nghĩ
  • Chia sẻ suy nghĩ của bạn với cấp trên
  • Luôn bảo vệ lợi ích của công ty
  • Tìm cách kiếm tiền về cho công ty
  • Vượt qua mọi cám dỗ từ bên ngoài

Công ty có thể sẵn sàng sa thải nhân viên có năng lực, nhưng đối với một nhân viên trung thành sẽ không có một lãnh đạo nào muốn cho anh ta ra đi, anh ta sẽ trở thành một chiến sĩ thép trong công ty và sẽ trở thành nhân viên có tương lai phát triển nhất trong công ty sau này.

2. Sự đam mê với công việc

  • Mục đích của công việc không phải chỉ vì mỗi mức lương
  • Nỗ lực phục vụ hết mình, thậm chí vượt qua cả mức lương
  • Hy sinh việc cá nhân vì công việc
  • Không quan tâm đến khái niệm hết giờ làm là đi về, mà làm xong việc mới nghĩ đến nghỉ ngơi.
  • Coi trọng từng chi tiết trong công việc

Với sự tiến bộ từng ngày của xã hội, nhận thức của con người cũng hội tụ nhiều cái thay đổi. Bằng cấp, học lực không còn là điều kiện tiên quyết cho sự tuyển dụng nhân viên trong các công ty. Mà rất nhiều công ty cần sự đam mê, sự tận tâm với công việc của nhân viên, tiếp đó mới đến trình độ chuyên môn.

3. Tính tích cực trong công việc

  • Từ “ muốn tôi làm” thành “tôi muốn làm”
  • Chủ động gánh vác thêm một số việc ngoài công việc mình được phân công
  • Làm trước, nói sau để lãnh đạo vụi vẻ ngạc nhiên (khác với nhiệt tình + thiếu hiểu biết)
  • Xung phong và chủ động làm việc
  • Yêu cầu một phải làm được ba

Đừng để việc gì cũng phải đợi phân công mới làm, mà chúng ta nên chủ động làm tốt tất cả, dù khởi điểm có kém hơn người khác thì chúng ta cũng sẽ phát triển được nhanh chóng.

4. Có tinh thần trách nhiệm trong công việc

  • Bất cứ việc gì, kể cả việc nhỏ nhất cũng phải làm tốt
  • Nói là phải làm, mà làm là phải có kết quả
  • Sai là sai, đừng tìm cách biện minh
  • Không vì sơ suất nhỏ mà hình thành sai lầm lớn

Năng lực cá nhân có thể thua kém người khác nhưng tinh thần trách nhiệm thì không thể không có, nếu gặp việc gì cũng đùn đẩy, đổ cho nguyên nhân khách quan mà không tự ngẫm lại bản thân thì bạn sẽ dễ dàng đánh mất sự tín nhiệm của lãnh đạo.

5. Tính hiệu quả trong công việc

  • Tạm biệt những việc không đâu vào đâu
  • Tập trung chuyên tâm với công việc
  • Làm nhiều, làm tốt, làm cẩn thận từng công việc
  • Nói không với sự trì trệ, ngăn chặn sự cầu toàn khiến làm giảm hiệu quả công việc
  • Luôn ghi nhớ và biết sắp xếp công việc nào cần ưu tiên làm trước

Thói quen làm việc phải đem lại hiệu quả cao là điều cần thiết đưa bạn đến thành công, và cũng là điều được các công ty vô cùng xem trọng.

6. Kết quả công việc

  • Ngay từ khi bắt tay làm là phải nghĩ cách làm sao hoàn thành công việc
  • Phương pháp luôn luôn nhiều hơn vấn đề
  • Làm việc một cách thông minh chứ không phải chỉ là làm việc chăm chỉ
  • Không có điều kiện vậy hãy tự tạo điều kiện
  • Hoàn thành công việc sớm hơn dự kiến

“Bất kể mèo đen hay mèo trắng, mèo nào bắt được chuột thì đó là con mèo giỏi”. Bất kể bạn làm việc chăm chỉ, hay làm việc thông minh, miễn đạt kết quả tốt thì bạn sẽ được mọi người công nhận. Doanh nghiệp xem trọng bạn lập được bao nhiêu “công lao”, chứ không phải xem bạn vất vả thế nào.

7. Khả năng giao tiếp

  • Giao tiếp khác với buôn chuyện
  • Không nói hoặc nói quá nhiều cũng là một sai lầm
  • Đưa vấn đề ra bàn luận và đưa ra phương pháp giải quyết
  • Tiếp thu sự phê bình
  • Nội bộ có thể có mâu thuẫn nhưng ra ngoài phải đồng lòng

Người giao tiếp kém dù có tài cũng khó mà tiến bộ được, còn người giỏi giao tiếp dù có bình thường thì họ có thể vừa làm vừa học nên nhanh chóng chứng minh được giá trị bản thân.

8. Tinh thần đoàn kết

  • Hòa đồng với tập thể
  • Tuân theo sự sắp xếp của tập thể
  • Tuân thủ kỷ luật mới đảm bảo được năng lực chiến đấu
  • Suy nghĩ và làm được nhiều việc hơn cho tập thể

Bất kể bạn tài giỏi ra sao, nếu như bạn làm tổn hại đến tập thể, doanh nghiệp cũng sẵn sàng sa thải bạn. Đừng ảo tưởng rằng vì thiếu một mình bạn mà tập thể không thể làm nên việc gì.

9. Sự cầu tiến

  • Luôn học hỏi và cầu tiến
  • Đừng để kinh nghiệm một năm dùng lặp lại cho mười năm
  • Dùng thời gian để nâng cao năng lực bản thân, nạp năng lượng mới cho mình
  • Phát triển lợi thế, ưu điểm của bản thân

Mỗi người cần phải theo kịp với tốc độ phát triển của doanh nghiệp, còn doanh nghiệp phải bắt kịp tốc độ phát triển của thị trường. Vì vậy bất kể trong công sở hay thị trường, cá nhân hay doanh nghiệp, đều không muốn mình bị đào thải thì cần phải cầu tiến, đứng yên tại chỗ tương đương với từ bỏ, và bị gạt ra ngoài.

10. Sự khiêm tốn

  • Đừng khoe công đòi thưởng
  • Khắc phục tâm lý “ta giỏi mà làm việc không xứng tầm”
  • Tôn trọng tất cả mọi người
  • Nỗ lực làm việc, xứng đáng với vị trí của mình
  • Thành tích chỉ là khởi đầu, vinh dự làm nên động lực

Tài giỏi nhưng chớ tự cao, đừng nghĩ rằng nếu mình không khoe, không kể ra thì người khác không biết đến công lao của bạn, đừng có khoe khoang trước mặt đồng nghiệp.

11. Sự thành thật

  • Báo cáo doanh thu cần trung thực
  • Đừng tham cái lợi trước mắt
  • Không lãng phí tiền của của công ty, dù chỉ là một trang giấy
  • Trân trọng từng phút làm việc
  • Ghi nhớ rằng: những thứ mình tiết kiệm được cho công ty đó cũng là lợi nhuận.

Tiết kiệm không phải là keo kiệt, mà là một đức tính tốt. Đừng nghĩ rằng tiền của công ty không phải là tiền, mà hãy nhớ rằng “nồi” của công ty có gì, “bát” của ta sẽ có cái đó, “nồi” của công ty có nhiều, “bát” của ta ắt sẽ đầy, và người cầm thìa múc lại chính là chúng ta.

12. Lòng biết ơn

  • Cảm ơn sếp cho bạn cần câu cơm
  • Cám ơn công việc không chỉ đem lại cho bạn tiền lương mà còn cho bạn nhiều kinh nghiệm và bài học.
  • Cảm ơn đồng nghiệp hỗ trợ, giúp đỡ bạn
  • Cảm ơn khách hàng cho bạn cơ hội làm nên thành tích
  • Cảm ơn đối thủ cho bạn sự trưởng thành
  • Cảm ơn người phê bình bạn khiến bạn hoàn thiện bản thân hơn

Tại sao chúng ta có thể chấp nhận được những sai lầm của bản thận mà đối với người khác hay công ty lại không ngừng khó chịu và phàn nàn. Bạn nên biết rằng, dù bạn có tài giỏi thế nào thì đôi khi bạn vẫn cần người khác cho bạn cơ hội để thể hiện hay có khi cần sự giúp đỡ dù to dù nhỏ từ người khác. Hạnh phúc hiện tại của bạn không phải do một mình bạn có thể làm nên.

Nguồn: Applancer Careers via Trí Thức Trẻ

Beautiful UX và ứng dụng Real Time cải thiện trải nghiệm người dùng

Beautiful UX và ứng dụng Real Time cải thiện trải nghiệm người dùng

Vài năm trước đây, công nghệ như WebSockers đã đạt được những phát triển vượt bậc nhờ vào sự trợ giúp của tính năng Real time. Sau này tính năng Real time được phát triển và được xem như một tính năng “ không – thể – thiếu” trong hầu hết các ứng dụng được yêu thích hiện nay như: Facebook với thông báo qua ứng dụng điện thoại, Uber với hiệu ứng dò tìm địa điểm ngay lập tức, tính năng đa người dùng của Google Docs và chat trực tuyến của Slack,… Tính năng real time có tác dụng truyền tải thông tin đến người dùng ngay tức thì, làm gia tăng những trải nghiệm chân thực nhất cho người dùng. Nhưng làm thế nào để áp dụng tính năng Real time giúp cải thiện sản phẩm và đáp ứng mong muốn của khách hàng?

Anh Đỗ Vũ Hoàng Trình – Director of Project Management của POETA, với nhiều năm kinh nghiệm trong lĩnh vực cung ứng giải pháp trải nghiệm người dùng, trong buổi trò chuyện gần đây với TopDev đã có những chia sẻ quý báu về kinh nghiệm cải thiện trải nghiệm người dùng, cũng như những vấn đề cần quan tâm khi tích hợp tính năng real time vào ứng dụng để cải thiện trãi nghiệm người dùng.

1. Anh có thể giới thiệu đôi nét về POETA cho cộng đồng lập trình viên được biết?

Được thành lập năm 2007 với 2 chi nhánh ở Seattle (Mỹ) và ở Việt Nam tên công ty ban đầu là VinaSource. Mục đích là giúp khách hàng dễ đọc, nhanh chóng biết được công ty đang làm gì ? ở đâu? Nhưng qua thời gian thì vấn đề dễ đọc không còn là yếu tố quan trọng hàng đầu, công ty mong muốn mang đến nhiều cảm xúc hơn cho khách hàng, bắt đầu từ chính tên công ty, vì vậy công ty đã quyết định đổi tên thành POETA. Sở dĩ có cái tên POETA (tiếng La Tinh) có nghĩa là nhà thơ, với POETA code không chỉ đơn thuần là code, nó phải thực sự tinh tế mang lại cảm xúc, mang lại giá trị cho người dùng. POETA không tham vọng tạo ra những sản phẩm hàng trăm ngàn người dùng, nhưng mỗi sản phẩm POETA tạo ra là một “tác phẩm nghệ thuật” chính là mang lại cảm xúc cho người dùng.

2. Anh có thể chia sẻ thêm về dự án mà anh tâm đắc nhất cho tới thời điểm hiện tại?

Từng làm qua rất nhiều sản phẩm, nhưng sản phẩm khiến anh tâm đắc nhất cho tới bây giờ đó là 1 sản phẩm về giáo dục từ khách hàng Mỹ. Sản phẩm này cung cấp thư viện những bài test hỗ trợ cho giáo viên đánh giá năng lực sinh viên. Nhớ lại khi đó team chỉ có 2 người, gần như phải tự làm tất cả mọi thứ. Điều khó khăn nhất là khâu thuyết phục khách hàng chấp nhận giải pháp của mình đưa ra thay vì bằng lòng với giải pháp của khách hàng. Giải pháp bên mình đưa ra là một giải pháp toàn diện cả về business chứ không chỉ là giải pháp về kỹ thuật – điều mà rất ít công ty Outsource lúc bấy giờ quan tâm đến. Từ những ngày đầu rất sơ khai bây giờ sản phẩm đó có thể tự scale để đáp ứng được lượng người dùng truy cập lớn. Từ quá trình làm sản phẩm đó, mình học được rất nhiều điều quý báu: quy trình làm hệ thống, biết cách nói chuyện với khách hàng, hiểu khách hàng, làm sao để thiết kế hệ thống đáp ứng được nhiều người dùng,…

3. Tính năng Real time hiện nay được xem là “tính năng không thể thiếu” trong hầu hết các ứng dụng được yêu thích hiện nay, được biết hiện tại POETA cũng có phát triển một số sản phẩm liên quan tới tính năng này, anh có thể chia sẻ thêm về việc áp dụng Real time vào sản phẩm của công ty?

Việc áp dụng tính năng real time vào sản phẩm cải thiện trải nghiệm người dùng rất nhiều. Hiện tại POETA có phát triển một số tính năng real time liên quan đến video. Một sản phẩm mà POETA đã phát triển có áp dụng real time khá thành công liên quan đến du lịch tại chỗ. Về cơ bản sẽ có 1 người là tourguide làm nhiệm vụ hướng dẫn, người dùng sẽ thông qua ứng dụng di động để “điều khiển” tourguide di chuyển theo mong muốn của mình, đi đến những nơi mình muốn, tất nhiên đó hoàn toàn là Real Time. Điều này khiến cho người dùng ứng dụng có được những trải nghiệm du lịch chân thực mà không cần phải đến tân nơi, chỉ cần dùng thiết bị di động.

Khi làm Reat Time cần lưu ý về chất lượng tải, vì làm real time (đặc biệt là với video) phụ thuộc rất nhiều vào đường truyền. Bài toán cần giải quyết là tối ưu hóa tốc độ tải, để ngay cả khi người dùng sử dụng gói dịch vụ giá rẻ thì tốc độ đường truyền vẫn phải đảm bảo, và cần phải chủ ý tới khả năng tự động phát hiện lỗi và cách khắc phục lỗi nhanh nhất.

4. POETA đã có nhiều năm làm việc với trải nghiệm người dùng, vậy anh quan niệm như thế nào là “Beautiful UX”?

Thực ra “đẹp” hay” xấu” cũng chỉ là mang tính cảm tính, có rất nhiều định nghĩa khác nhau về “beautiful UX” như cấu trúc cân đối, đơn giản, tiện dụng, dễ sử dụng,.. Còn đối với anh thì đó là “thôi thúc” hành động.

Beautiful UX phải mang đến trải nghiệm thôi thúc người dùng thực hiện 1 hành động nào đó. Ví dụ: khi làm1 trang web bán hàng phải thôi thúc mua hàng, 1 trang book vé thì phải thôi thúc người dùng book vé.

Để có thể làm được điều đó, điều quan trong nhất là phải hiểu được người dùng. Vì mỗi đối tượng khách hàng khác nhau có đặc điểm nhân khẩu học khác nhau ví như: khách hàng ở Mỹ họ thích những thiết kế đơn giản, rõ ràng với 1 text box rất lớn. Bởi khuynh hướng của người dùng ở Mỹ là vào 1 website là để làm gì đó, còn đối với người dùng ở Nhật, Hàn thì lại rất nhiều chữ và nhiều màu, đối với họ thì nhiều là tốt, nhiều có nghĩa là có nhiều giá trị. Còn đối với người dùng Việt Nam thì vào website là để xem có gì hấp dẫn, thì mới quyết định có hành động tiếp theo. Thói quen người dùng khác nhau, đó là lý do phải nghiên cứu hành vi người dùng thật kỹ trước khi đưa ra thiết kế. Có như vậy mới cho người dùng cái họ muốn.

5. Có ý kiến cho rằng: “Làm Outsource không có tư duy sản phẩm” với nhiều năm kinh nghiệm là Outsource anh nghĩ gì về ý kiến này?

Thực ra, ý kiến này cũng không hoàn toàn sai. Ở Việt Nam hiện nay chủ yếu vẫn làm Outsource cho các công ty nước ngoài là chủ yếu, rất ít có cơ hội được tiếp xúc trực tiếp với khách hàng, cái mình nhận được chỉ là những yêu cầu. Sự tách biệt với khách hàng là nguyên nhân dẫn đến thiếu tư duy về sản phẩm. Hơn nữa, trong chuỗi quy trình từ tạo ra sản phẩm tới đưa sản phẩm tới người dùng, lập trình viên Outsource chỉ làm ở giai đoạn hiện thực hóa sản phẩm, nhiều khi không được tham gia cả khâu thiết kế, và khâu quan trọng nhất là lấy ý kiến người dùng thì gần như hoàn toàn không được tham dự. Chính vì vậy, tư duy Outsource cũng bắt đầu từ đó. Muốn thay đổi tư duy điều quan trọng là cần có bước chuyển.

Nhìn về bản chất một chút, trong chuỗi giá trị của người dùng, từ giai đoạn nắm bắt nhu cầu người dùng, lên ý tưởng, thiết kế, build sản phẩm, marketing, logictic,… có rất nhiều việc mình có thể làm. Để bắt đầu thì mình cần phải làm tốt hơn yêu cầu của khách hàng. Các công ty Outsource thường suy nghĩ đơn giản là khách hàng yêu cầu gì thì chỉ làm vậy, như thế sẽ không thể làm tốt hơn yêu cầu của khách hàng, tức là đưa ra nhiều lựa chọn tốt hơn (có thể) thay thế cho giải pháp của khách hàng. Để làm được điều đó cần xem khách hàng như những partner của mình, tức là cùng khách hàng phát triển sản phẩm, cùng xây dựng sản phẩm, hơn là chỉ xem khách hàng đơn thuần là những người đưa ra yêu cầu và mình là người thực hiện yêu cầu. Khi đó mình đã có tư duy cùng với khách hàng rồi, mình có thể làm trọn gói phân tích nhu cầu người dùng của họ, sau này mình không chỉ duy trì về mặt công nghệ mà mình còn có thể tham gia vào nhiểu phần khác trong chuỗi giá trị sản phẩm. Đó chính là bước đầu hình thành nên tư duy sản phẩm dù làm Outsource hay làm Product.

6. Anh có thể chia sẻ đôi chút về văn hóa công ty ở POETA?

Môi trường làm việc ở POETA khá thỏa mái, trẻ trung, năng động, khuyến khích sự sáng tạo, nhưng cũng đòi hỏi sự chuyên nghiệp.

Ở POETA không đòi hỏi các bạn lập trình viên phải biết quá nhiều công nghệ, điều các bạn cần nhất là kiến thức căn bản tốt và nắm được tinh thần của ứng dụng mình làm. Mình tâm niệm, công nghệ chưa biết, làm sẽ biết, ngoài ra công ty cũng thường xuyên tổ chức các buổi training cho nhân viên, nên các bạn không cần quá lo lắng.

7. Đối với các bạn lập trình viên ứng tuyển vào POETA, anh có lời khuyên gì dành cho các bạn?

Một điều nữa anh rất quan tâm khi phỏng vấn các bạn lập trình viên là một CV ấn tượng. Anh thấy nhiều bạn ứng viên rất tiềm năng nhưng đọc CV rất chán, hay liệt kê khả năng này, bằng cấp nọ, làm ứng dụng kia,… Nhưng điều anh thực sự muốn biết là các bạn đã làm được gì trong từng dự án và kết quả đạt được là gì thì gần như không thấy. Các bạn lập trình viên cần viết CV sao cho toát lên được giá trị của bản thân, cho nhà tuyển dụng thấy được đam mê của các bạn.

Anh cũng đánh giá rất cao những bạn có đam mê, bởi có đam mê bạn sẽ luôn biết cách làm thế nào để làm tốt mọi việc. Đôi khi niềm vui của coder chỉ là code ra 1 dòng code rút ngắn được thời gian, cảm giác rất “sướng”. Chính anh cũng từng là lập trình viên anh hiểu rõ cảm giác đó như thế nào. Nói về code nhiều bạn vẫn nghĩ là “thợ” nhưng thợ có tâm khác rất nhiều với thợ bình thường. Anh có lời khuyên với các bạn nào cảm thấy code là một gánh nặng thì nên chuyển sang các lĩnh vực khác.

Cảm ơn anh đã nhận lời tham gia phỏng vấn cùng TopDev

Làm thế nào để chọn được framework phát triển Mobile app tốt nhất?

Sự khác biệt trong cách phát triển các ứng dụng Hybird và Native Cross Platform cùng các yếu tố tác động

Hybird cross platform framework là một bộ công cụ phát triển, cấu hình và xây dựng, cho phép các công nghệ web chuẩn (HTML, CSS và JavaScript 5, 3) đã được đóng gói và triển khai trên thiết bị di động.Thông thường, các assests sẽ được tải lên Apple Store đối với iOS và Playstore đối với Android. Trong thời gian runtime, ứng dụng sẽ sử dụng trình duyệt web trên mobile (webview).

Xem thêm tuyển mobile app lương cao

Native cross platform framework cũng có cách hoạt động giống như phương pháp Hybird. Tuy nhiên, nó cắt HTML và CSS từ phương trình và cho phép các ứng dụng đã được đóng gói nói chuyện trực tiếp với hệ điều hành điện thoại di động. Điều này cung cấp hai lợi thế hơn Hybird. Trước hết, các ứng dụng có thể sử dụng native user interface để điều khiển (chứ không chỉ bắt chước), điều này có thể phát triển dễ dàng hơn kể từ khi có sự nhất quán trong thiết bị và các ứng dụng có khả năng sẽ chạy nhanh hơn (kể từ khi có ít quy trình cần xử lí hơn)

Phương pháp Native sử dụng các công cụ nguyên bản của Apple và Google nhằm target các thiết bị di động. Chúng được phát triển độc lập và sử dụng ngôn ngữ khác nhau cùng môi trường phát triển trong từng ngữ cảnh.

Các yếu tố quyết định framework phù hợp

Cần cân nhắc 4 yếu tố chính khi chọn một framework để phát triển mobile app phù hợp như sau:

Tốc độ

Điều đầu tiên cần cân nhắc chính là tốc độ khi app chạy. Các app có tốc độ nhanh thường là  native app viết bởi Java ( Android) và Swift (IOS) sau đó là native cross platform và cuối cùng là Hybird. Đáng chú ý là sự khác biệt về tốc độ giữa các app là không đáng kể và chỉ quan trọng nếu bạn đang phát triển các ứng dụng games. Tốc độ vàng khi nói đến phát triển ứng dụng di động là 60fps. Nếu ít hơn sẽ được coi là “laggy”. Thường khi sử dụng Hybird sẽ không đạt được con số vàng này.

Tính năng hỗ trợ

Nếu bạn xây dựng cross platform app thì có thể sẽ có nhiều tính năng đặc biệt mà cross platform và hybird framework không hỗ trợ. Thường các tính năng sẽ được add thêm bởi maintainer của các framework này tuy nhiên thời gian sẽ rất lâu.

Rủi ro liên quan đến framework

Bằng các chọn shop bên ngoài các framework được hỗ trợ chính thức việc phát triển mobile app (Android Studio / Xcode) bạn sẽ gặp nhiều rủi ro hơn vì bạn đã đặt nhiều layers của abstraction và nền tảng mục tiêu và code đang chạy trên đó

Đây không phải là vấn đề nhưng bạn nên tìm kiếm các hợp đồng hỗ trợ mà bất kỳ nhà phát triển Hybrid hoặc Cross Platform cung cấp. Hãy thử tìm kiếm online và tìm hiểu những vấn đề người ta gặp phải với các framworks trước khi tiến hành và thực hiện sự lựa chọn của bạn.

Chi phí

  • Bạn nên suy nghĩ về kinh nghiệm phát triển hiện tại mà bạn đã có hoặc có thể dễ dàng tìm hiểu từ bên ngoài. Nếu bạn có nhiều web dev thì Hybrid lựa chọn tốt nhất vì nó cung cấp khả năng tiết kiệm chi phí thúc đẩy bởi vì nó cần ít thời gian để học hơn
  • Sử dụng cross platform sẽ cho phép chia sẻ mã và do đó làm giảm đáng kể chi phí phát triển.

Nguồn: topdev.vn via logicroom.co

Cách viết CV dành cho Software Developer

Cách viết CV dành cho Software Developer

Bài này do mình, một IT Technical Recruiter viết; đối tượng hướng tới là các bạn Software Developers đã có kinh nghiệm làm việc.

  • Bài này cũng thể hiện quan điểm và sở thích cá nhân khi nhận và đọc CV của ứng viên, nó không phải là chuẩn chung cũng như sẽ có thể khác hoặc trái ngược quan điểm của các recruiter hay nhà tuyển dụng khác, vậy nên các bạn đọc kỹ hướng dẫn sử dụng trước khi dùng, đừng chết vì lười đọc.
  • Bài này được viết do ngẫu hứng, không được chuẩn bị trước, chủ yếu dựa trên những bức xúc bấy lâu khi đọc CV của ứng viên, nên chắc chắn sẽ có nhiều vấn đề chưa đề cập đến. Ai muốn bổ sung hay góp ý hay gì gì đó thì cứ email cho mình (khuyen.le-minh @ jobseeker.vn)
  • Mình viết dựa trên kinh nghiệm làm việc với các công ty nước ngoài, nên bài viết có thể sẽ không đúng với các bạn muốn apply vào các cty Việt Nam hay Nhà nước.
  • Không có cách viết hay mẫu CV/Resume nào gọi là chuẩn cho tất cả, mà nó tùy thuộc và kinh nghiệm bản thân, ngành nghề cũng như yêu cầu của nhà tuyển dụng.

Đầu tiên cần phân biệt giữa CV (Curriculum Vitae) và Resume (or Résumé)

  • CV: Viết dài, ghi chi tiết về thời gian, các kinh nghiệm, kỹ năng, quá trình học tập, etc .. CV cover toàn bộ quá trình sự nghiệp của bạn. Thường thì CV tốn nhiều trang A4 để viết (tầm 2~4 trang là đẹp). CV chuyên dùng để bạn show hàng đến từng sợi lông cho nhà tuyển dụng thấy
  • Resume: Ngắn gọn, súc tích, chỉ thể hiện những ý chính, thành tích nổi bậc, không đi sâu vào chi tiết. Thường thì Resume chỉ nên gói gọn trong 1 trang,. Resume rất hiệu quả để bạn bước ra khỏi đám đông, cho recruiter một cái nhìn overview về bạn,, giúp bạn nổi bậc hơn so với hàng chục hay hàng trăm ứng viên khác.

>>> Xem thêm: Resume và CV là gì? Điểm khác biệt quan trọng khi xin việc

Hai thứ này tạm dịch ra tiếng Việt là Sơ yếu lý lịch, nhưng nó không giống với Sơ yếu lý lịch mà các bạn hay đem ra phường chứng thực, nên không cần phải ghi số CMND, nhà có mấy anh chị em, ba má trước 1975 làm gì hay ở đâu…. Cái này tập trung vào bạn, kinh nghiệm làm việc cũng như kỹ năng của bạn, và không cần phải ra phường để xác nhận.

Cá nhân mình là recruiter và mình thích các bạn gửi cho CV mình hơn. Resume không thích hợp cho developer vì nó quá ngắn, recruiter không đủ dữ liệu để đánh giá về kinh nghiệm cũng nhưng kỹ năng của các bạn, nhất là các recruiter không có background hay knowledge bên mảng IT.

Nên viết CV bằng tiếng Việt hay tiếng Anh

  • Đầu tiên là bạn phải xem kỹ công ty yêu cầu nộp CV bằng tiếng Việt hay tiếng Anh. Nếu họ không đưa yêu cầu cụ thể, thì bạn nên tìm hiểu xem đó là cty của nước nào, nếu không phải là công ty của Việt Nam thì nên nộp hồ sơ bằng tiếng Anh. Ngoài ra một số công ty có thể yêu cầu CV bằng tiếng Trung hay tiếng gì đó mà họ thích.
  • Còn riêng cá nhân mình thì mình thích nhận CV tiếng Anh hơn. Nếu bạn gửi CV tiếng Việt cho mình, mình sẽ reply lại và yêu cầu 1 CV khác bằng tiếng Anh.

>>> Xem thêm: Các mẫu CV IT đẹp dành cho lập trình viên

Nên viết gì trong CV?

Personal Information:

  • Họ và tên đầy đủ, nên viết bằng tiếng Việt không dấu (thật ra có dấu cũng được, nhưng mình thích không dấu hơn)
  • Thông tin liên lạc: chuẩn nhất là có email, số điện thoại di động và địa chỉ liên lạc để recruiter có thể liên lạc bạn theo cách nhanh nhất (điện thoại) và formal (email) và gửi thư từ, giấy tờ cho bạn (địa chỉ liên lạc, chứ không cần phải ghi địa chỉ hộ khẩu). Tuy nhiên, nếu có skype hay yahoo thì cũng tiện lợi trong nhiều trường hợp. Ngoài ra còn có thể đưa link của blog/web cá nhân, profile trên Linkedin, gitHub hay stackoverflow, …. Tóm lại, thông tin liên lạc và những thứ liên quan có focus vào công việc
  • Hình: Có nhiều quan điểm trái ngược nhau về việc có nên để hình vào CV hay không. Theo mình thì nếu bạn tự tin bạn đẹp trai hay xinh gái khi lên hình thì hãy để vào, còn không thì không cần, không nên. Tuy nhiên,  nếu bạn không để hình và tên của bạn nó lưỡng tính, khi người ta đọc vào không (hay khó) phân biệt là trai hay gái (ví dụ như mình là male, tên là Lê Minh Khuyến, nếu không để hình thì 7/10 người kêu là *chị*), thì bạn nên để thêm phần giới tính vào, không quan trong lắm, nhưng để tránh nhầm lẫn.

Career Objective/Goals

Hãy cẩn thận khi bạn đưa mục này vào CV, vì nó có 2 mặt

  • Tích cực: thể hiện cho nhà tuyển dụng thất tinh thần cầu tiến, đặt mục tiêu và có kế hoạch của bạn, có thể goal của bạn phù hợp với công ty.
  • Tiêu cực: nhà tuyển dụng có thể cho rằng mục tiêu của bạn không phù hợp với vị trí bạn đang làm, có thể bạn sẽ không gắn bó với cty, ….. Ví dụ: 1 công ty tuyển người cho vị trí .NET Developer, trong job description có ghi “If your career objectives have the non-technical path within the next xxx years, this position is not suitable for you”, nhưng bạn ghi objectives là muốn trở thành Project Manager trong 5 năm tới thì coi như thua hết 70% cuộc chơi rồi.

Career Summary

  • Có thể có hoặc không có mục này, cái này nó chỉ đơn giản là liệt kê lại thời gian nào bạn đã làm ở công ty nào và ở vị trí gì, giúp recruiter có cái overview về jobs và số năm kinh nghiệm của bạn
  • Nếu liệt kê, bạn hãy ghi theo thứ tự thời gian từ gần đây nhất trở về trước

Technical Skill Summary:

  • Có thể có hoặc không, nó chỉ đơn giản là liệt kê những technical skills mà bạn biết, có kinh nghiệm sử dụng, ….
  • Tuy nhiên, nếu bạn public CV của bạn lên internet, thì mục này rất hữu ích giúp CV của bạn dễ dàng được recruiter tìm thấy thông qua search engines

Professional Experience/Employment History

  • Phần này quan trọng nhất và khó nhất, hãy liệt kê theo thứ tự thời gian từ gần nhất đến cũ nhất các công việc bạn đã làm
  • Mỗi một công việc, bạn cần ghi đầy đủ *tên công ty, tháng/năm bắt đầu làm – tháng/năm nghỉ việc, vị trí*. Bên dưới, hãy gạch đầu dòng những trách nhiệm/công việc chính của bạn khi làm ở vị trí đó. Cố gắng ghi ngắn gọn nhưng đủ ý, tránh dài dòng hay đi sâu vào chuyên môn.
  • Nếu bạn đã làm qua nhiều công ty/vị trí thì CV sẽ rất dài khi liệt kê hết, bạn có thể:
  • Chỉ liệt kê những công việc trong thời gian vài năm trở lại
  • Chỉ liệt kê những công việc giúp cho CV bạn phù hợp hơn so với vị trí bạn sắp ứng tuyển
  • Ngoài ra, là developer, bạn có thể trình bày kinh nghiệm làm việc theo cách khác, đó là liệt kê theo những dự án bạn đã làm:

Tên dự án (nếu được phép ghi tên, vì một số dự án phải ký NDA, không được tiết lộ thông tin ra ngoài), làm ở công ty nào, thời gian nàoMô tả ngắn gọn dự ánMan-days/months của dự ánTeam sizeVai trò của bạn trong dự ánNhững kỹ thuật bạn đã sử dụng trong dự án (programming language, frameworks, ….)Link đến những dự án đang chạy mà bạn đã làm (nếu có)

  • Bạn không cần ghi lý do rời khỏi công ty hay mức lương ở những vị trí trước đây, công ty sẽ hỏi bạn khi họ muốn biết

Education, Training, Soft-skills, Languages

  • Nên có, nhưng không có cũng không sao
  • Bạn chỉ nên đưa những bằng cấp phù hợp và có tính hỗ trợ cho công việc mà bạn sắp apply vào. Việc ghi quá nhiều bằng cấp hoặc bằng cấp quá cao có thể làm nhà tuyển dụng nghĩ bạn không phù hợp hoặc sẽ đòi lương cao hơn mức họ có thể trả, … nói chung là quá nhiều so với nhu cầu.
  • Chỉ liệt kê những soft-skills nào mà bạn thực sự có và phù hợp cho vị trí ứng tuyển
  • Quá nhiều bằng cấp hay chứng chỉ, khóa học soft-skills không liên quan hay hỗ trợ nhau, nhà tuyển dụng có thể đánh giá bạn rất ba phải hoặc không có định hướng hoặc là nổ.
  • Nếu bạn biết thêm ngôn ngữ nào khác ngoài tiếng Anh, hãy ghi vào và ghi cụ thể trình độ của bạn về ngôn ngữ đó

References/Achievements/Recommendation

  • Có thì tốt, không có cũng không sao. Công ty sẽ yêu cầu bạn cung cấp thông tin người tham khảo khi họ cần.
  • Nếu bạn có để thông tin người tham khảo, bạn nên xin phép hoặc báo trước với những người đó. Chỉ để thông tin kham khảo của cấp trên/đồng nghiệp/cấp dưới, những người có thể nhận xét bạn về công việc, đừng để vào đó nhưng người có quan hệ cá nhân.
  • Chỉ để những achievement/recommendations đáng tự hào nhưng liên quan tới công việc bạn muốn ứng tuyển.
  • Nếu có nhiều quá, hãy bỏ bớt và giữ lại 3 cái tốt nhất và liên quan gần nhất.

Tham khảo tin tuyển dụng Software Developer mới nhất trên TopDev

Trình bày CV như thế nào?

  • Format, font và màu chữ đồng bộ xuyên suốt CV. Chỉ nên dùng font Unicode (Time New Roman, Arial hoặc Tahoma), font size từ 10-12 tùy font và màu đen. Ở những chỗ như title hay tên mình, header thì nên dùng font lớn (cỡ 14-16) và in đậm/gạch chân để nổi bật hơn
  • Chú ý lỗi chính tả và độ chính xác thông tin,  đọc đi đọc lại nhiều lần
  • Nên save CV ở format *.doc, *.docx hoặc *.pdf, nhưng mình khuyến khích là *.doc hoặc *.docx. Vì sao? Vì dễ lưu trữ, tìm kiếm, chỉnh sửa và in ấn. Một số công ty còn dùng ATS (applicant tracker system) để quản lý CV, nghĩa là robot sẽ đọc CV của bạn. Bạn gửi CV bằng file MS Word thì recruiters sẽ rất cảm ơn bạn vì họ sẽ tiết kiệm được nhiều thời gian cho việc nhập liệu và dễ ghi chú

Nếu bạn cảm thấy quá phức tạp để ghi nhớ những lưu ý này thì công cụ tạo CV chuẩn tại ToDev sẽ giúp bạn, trải nghiệm ngay!

Tạo CV IT online, chuẩn ATS miễn phí trên TopDev

Bao lâu thì nên update CV 1 lần?

  • Đừng xem việc viết CV là 1 công việc nặng nhọc, hãy xem nó như là 1 công cụ ghi lại chi tiết sự nghiệp cũng như quá trình thăng tiến của mình.
  • Đừng dùng 1 bản CV duy nhất và gửi cho tất cả nhà tuyển dụng. Hãy viết 1 CV khác, lọc ra những kinh nhiệm, kỹ năng, khóa học, phần thưởng, recommendations… phù hợp nhất hoặc có thể support cho công việc mà bạn đang muốn apply vào. Như vậy sẽ làm cho nhà tuyển dụng thấy bạn phù hợp với công việc và cũng giúp CV của bạn sạch sẽ, dễ nhìn hơn.
  • Tốt nhất là bạn nên làm 1 CV có liệt kê đầy đủ thông tin nhất có thể, khi bạn có gì mới thì hãy update vào CV này. Mỗi khi bạn muốn apply vào công việc mới hay có recruiter kêu bạn gửi CV cho họ, bạn chỉ cần copy ra 1 bản khác và tốn 15 phút để delete những thông tin không phù hợp và gửi đi. Nhanh gọn lẹ!

Quảng bá CV của mình đến các recruiters

  • Bạn có nhu cầu xin việc, bạn gửi CV cho nhà tuyển dụng. OK!
  • Trường hợp bạn chưa muốn chuyển việc, nhưng luôn open cho những challenges mới hoặc dọn đường trước để lãnh lương tháng 13 xong rồi biến, hãy quảng bá CV của bạn đến các *job owners* tiềm năng. Hãy tạo profile của bạn trên mạng xã hội (linkedin), cố gắng tạo nhiều connections trong lĩnh vực mà bạn quan tâm, hãy connect với nhân viên tuyển dụng của công ty, HRM, headhunters, CTO hay CEO của công ty, dev ở những cty khác, …những network  này sẽ giúp bạn rất nhiều cả khi bạn chủ động tìm việc hoặc được *săn* bởi các công ty săn đầu người.
  • Tuy nhiên, public thông tin cá nhân lên internet đồng nghĩa với việc bạn sẽ bị spam của bạn gia tăng, bằng cách này hay cách khác

Chú ý khi nộp hồ sơ qua email

  • Thành thật mà nói mình không thích các bạn đến gặp trực tiếp để đưa hồ sơ ứng tuyển (trừ khi được yêu cầu), mình thích nhận hồ sơ online qua email hơn. Lý do thì có rất nhiều, nhưng đại khai là vấn đề về nhập liệu, lưu trữ, tìm kiếm và quản lý. Đó là chưa kể đến việc khi bạn đến công ty mà không thông báo trước, nhiều lúc đang lười mà cũng phải ra tiếp, rất bực.
  • Khi nộp hồ sơ qua email, bạn có thể gọi điện hoặc chat với recruiter để báo, phòng trường hợp email của bạn rơi vào spam box. Tuy nhiên, cũng có 1 vài recruiters không thích việc nhắc này.
  • Tiêu đề email: Tên mình và vị trí mình muốn apply (để tiện việc search emails cũ). Nếu công ty có yêu cầu cụ thể về cách viết tiêu đề thì hãy làm theo yêu cầu của họ.
  • Viết cover letter, tức là khi bạn gửi email để ứng tuyển vào vị trí nào đó, thì ngoài cái attachment là CV ra, thì bạn nên viết vài dòng cho nhà tuyển dụng trong email, tránh việc để cái email không có chữ nào. Cá nhân mình thì không cầu kỳ về cái letter này, vì mình cũng hiểu là nhiều bạn cũng muốn viết cho hay, nhưng mà không biết viết cái gì. Vì vậy, khi viết cover letter bạn nên có những thông tin tối thiểu như sau:

Title of email: Le Van Teo – apply to Senior PHP Developer position

Attachment: yes (dưới 500kb là đẹp)

————————————

Dear Mr Lê Minh Khuyến,

I’m Lê Văn Tèo, a 5 years experience PHP Dev. I would like to apply to the position of Senior PHP Developer (http://www.link-to-the-job-posted )

Attachment is my CV and I can be reached via mobile phone number: 01234567890

Thank you

Lê Văn Tèo

Các bạn lưu ý một số lỗi hay gặp mà có thể làm cho recruiter ghét ngay ở khi chưa kịp gặp:

  • Viết ngôn ngữ teen hoặc viết tắt nhiều quá, đọc vào không hiểu là viết cái gì
  • Dear sai tên người, sai tên cty, sai thông tin (thường là do rải CV nhiều cty cùng lúc, lười hoặc bất cẩn khi update)
  • Apply cùng lúc nhiều cty, nhưng bỏ tất cả vào *To* mà không biết dấu vào *Bcc*
  • Không ghi rõ vị trí muốn apply
  • Gửi email không có tiêu đề, nội dung
  • Nội dung email xài nhiều font và màu chữ khác nhau (thường là do rải CV nhiều cty cùng lúc, lười hoặc bất cẩn khi update)
  • Gửi CV ở định dạng *.png hay *.jpg (rất bất tiện để lưu trữ, tìm kiếm và ghi chú)
  • Bỏ CV trong file nén (không cần thiết)
  • CV màu mè, nhiều hình ảnh, download rất lâu, nhiều khi xài iPad download tốn tiền 3G
  • Gửi quá nhiều hình hay files làm attachment rất nặng (thường đính kèm bản điểm, bằng cấp khi chưa được yêu cầu)
  • Gửi nhiều file nhưng không rename file, nhìn vào không biết là file gì
  • Ghi cover letter dài dòng và nổ quá nhiều
  • Địa chỉ email quá nhố nhăng. Ví dụ email nhưng hungphpcoder@….com hay myfirstjavaclass@….com.vn thì còn tạm chấp nhận được. Nhưng nhiều bạn còn sử dụng địa chỉ email nhưboyxitin@…com hay tommydispacy@….com, nếu gặp recruiters khó tính họ có thể delete luôn email của bạn

CV mẫu:

  • Rất nhiều mẫu CV đẹp dành riêng các bạn lập trình viên tại đây. Công cụ tạo CV online miễn phí cho phép bạn tạo CV cực nhanh trong 5 phút theo chuẩn ngon lành.
  • Có rất nhiều mẫu trên internet, các bạn cứ tìm, download về và chỉnh sửa theo ý muốn
  • Nội dung vẫn quan trọng hơn layout, nhưng mà cũng đừng có xấu hay màu mè quá
  • Một số công ty outsourcing lớn như Harvey Nash hay Axon Active có mẫu profile (CV) cho nhân viên của họ, dùng để show hàng với clients về khả năng của team khi kiếm project hay đại loại vậy, mình cũng không rành. Các bạn cố gắng kiếm 1 cái về coi thử. Theo kinh nghiệm của mình thì những mẫu đó rất rất rất tốt cho 1 developer, ngoại trừ nó rất là dài dòng do liệt kê nhiều projects
  • Hãy tự tin khi viết CV và cover letter, nhưng mà đừng nổ nhiều quá hay nói xạo nhà tuyển dụng.
via Review Company

Laravel, bạn đã viết đúng?

Chào các bạn trong bài trước mình đã chia sẽ cho các bạn những lời khuyên để học nhanh Laravel rồi phải không nào.

Qua nhiều lần khảo sát cũng như trao đổi với nhiều bạn làm về Laravel mình nhận thấy đa phần các bạn đều viết sai cách. Sai ở đây mình không nói về Logic mà mình nói về cách viết trong OOP (Hướng đối tượng).

Hôm nay mình viết bài này để chia sẽ cho các bạn code Laravel sao cho đúng (ý kiến cá nhân mình ^^) nhằm tăng performance website cũng như tính thẳm mỹ trong code.

Nói đến hướng đối tượng thì không riêng gì Laravel mà các Framework cung như thế. MVC là gì mình không cần phải nói ai cũng biết phải không nào ?. Nhưng liệu chúng ta có hiểu được mỗi thành phần trong đó xử lý những gì không nào. Đây là cái mình sẽ nói chính trong bài viết này.

1. Sử Dụng MVC theo đúng nghĩa !

Qua nhiều lần trao đổi với nhiều bạn. đa phần các bạn viết sai công dụng của các thành trên. Controller nhiều bạn gọi Models và viết cả câu query để truy vấn dữ liệu như vậy là sai nhé các bạn. viết như thế sẽ không còn mô hình MVC nữa nhé.

Vậy viết sao cho đúng nghĩa MVC ?
Với Models chúng ta nên viết function xử lý trong chính Class bạn muốn lấy dử liệu. Sau khi có fucntion mong muốn Controller chỉ cần đều hướng tới Models gọi function can thiết và trả về dữ liệu. Các bạn hãy xem qua ví dụ sau.

//Models
 
Class User extends Model
{
     protected $table = 'users';
 
 
     public function getListUser()
     {
        return self::get();
     }
}
 
//Controllers
 
use App\User;
 
Class UserController extends Controller
{
    function __construct(User $user)
    {
        $this->user = $user;
    }
 
    public function index()
    {
        $listUser = $this->user->getListUser();
        return view('viewName', compact('listUser'));
    }
}

Khá là đơn giản phải không nào. Trong ví vụ trên tôi có dùng __construct trong việc khởi tạo models. Nhiều bạn vẫn thường dùng New ModelClass đều này không sai nhưng việc cứ lặp đi lặp lại mỗi function bạn phải gọi new Model nhin code không đẹp cho lắm. Thì __construct sẽ giúp các bạn trong việc này.

Qua ví vụ trên các bạn thấy code có ngắn gọn hơn không nếu code bạn cũng đang mắt phải tình trạng mình vừa nói thì hãy thử theo cách của mình nhé.

2. Request hãy để nó làm việc theo đúng những gì nó có !

Cũng như Models. Request sẽ quản lý các xữ lý liên quan gữi và nhận yêu cầu từ phía người dùng (Views). Nhiều bạn vẫn dùng nó ngay tại controller đều này không sai. những nó sẽ dẫn tới việc lặp đi lặp lại làm cho function chức năng của chúng ta như một mớ hỗn độn khó mà quản lý.

Cách giải quyết hợp lý nhất là ta nên xây dựng một nơi để quản lý vấn đề này bằng cách tạo một Request riêng. Với Laravel chúng đã tích hợp sẵn lệnh tạo một Request thông qua Artisan Console các bạn có thể thực hiện như sau:

php artisan make:request ten_request

 

Đây là nội dung Request ta vừa tạo. Tôi đã tạo một file Request có tên là UserRequest:
//app/Http/Requests/UserRequest;
 
namespace App\Http\Requests;
 
use App\Http\Requests\Request;
 
class UserRequest extends Request
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return false;
    }
 
    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            //
        ];
    }
}

Chúng ta sẽ làm gì với nó. Nhiều bạn chua sử dụng qua chắc chắn sẽ bối rối phải không nào. tại đây chúng ta sẽ xử lý Validate input từ form được gửi lên từ người dùng. mà những Rules validate này đã có sẳn trong Laravel Doc. Các bạn có thể xem qua ví vụ sau:

/**
 * Get the validation rules that apply to the request.
 *
 * @return array
 */
public function rules()
{
    return [
        'username' => 'required'
    ];
}

Khá quen thuộc phải không nào. Không dừng ở đó tại đây các bạn có thể custom được cả thuộc tính Attribute của input và custom được message sẽ hiện thị khi bắt lỗi

/**
 * Get the validation attributes that apply to the request.
 *
 * @return array
 */
public function attributes()
{
    return [
        'username' => 'Tên người dùng'
    ];
}
/**
 * Get the validation custom message that apply to the request.
 *
 * @return array
 */
public function customMessages()
{
    return [
        'username.required' => 'Tên người dùng bắt buộc nhập',
    ];
}

Vậy sử dụng Request này như thế nào. Đơn giản thôi tại controller ban muốn sử dụng các bạn hãy gọi NameSpace của nó ra để khái báo rằng bạn sẽ sử dụng nó.

use App\Http\Requests\UserRequest;
 
Class UserController extends Controller
{
    //
}

Tiếp theo chúng ta cần làm gì. Truyền tham chiếu nó vào action bạn cần xử lý Request. Ví vụ tôi có action đăng ký người dùng như sau:

use App\Http\Requests\UserRequest;
 
Class UserController extends Controller
{
    //
 
    public function userRegister(UserRequest $request)
    {
        // your code here.
    }
}

Ở function userRegister các bạn sẽ không cần phải gọi Validator rồi make rules các kiểu nữa vì UserRequest đã thay bạn làm cả rồi.^^

3. Tạo Helper hãy vận dụng OOP thông qua Namespace

Nhiều bạn mắc lỗi nho nhỏ khi tạo thư viên helper cua mình nhằm giúp xử lý các tác vụ nhỏ khi cần thiết nhu xử lý chuỗi, mảng ,…Mọi người thường xử lý theo dạng php thuần trong khi các bạn đang viết OOP.

funtion getString($string)
{
    return $string;
}

 

Đây cũng là một cách. nhưng thật sự không tối ưu khi chỉnh sửa và thường gặp lổi với autoload khi các bạn thêm vào composer.jon autoload. ý kiến cá nhân của mình các bạn nên tận dụng cái mà OOP đang làm cách mà Laravel đang sử dụng. mọi thứ đều viết với dạng các lớp , thuộc tính và phương thức.
namespace App\Helpers;
class Helper
{
    public function getString($string)
    {
        return $string
    }
}

 

Việc sử dụng cũng khá dẽ dàng các bạn chỉ cần khai báo namespace tại controller và gọi phương thức của nó ra.
use App\Helpers\Helper;
 
Class UserController extends Controller
{
    function __construct(Helper $helper)
    {
        $this->helper = $helper;
    }
 
    public function userRegister(UserRequest $request)
    {
        $this->helper->getString($string);
    // your code here.
    }
}

Lời kết:

trên chỉ là ý kiến cá nhân của mình. mọi góp ý các bạn có thể comment bên dưới. Hy vọng bài viết giúp ích cho các bạn trong việc học tập cũng như rèn luyện code của mình.

Còn khá nhiều thủ thuật khác mình sẽ đề cập trong bài viết tiếp theo nhé!. Chúc các bạn thành công. Nếu thấy bổ ích các bạn hãy share cho bạn bè nhé.

Tham khảo thêm các vị trí tuyển dụng Laravel lương cao cho bạn.

Nguồn: Techtalk via codevivu

Người ta không rời bỏ công ty- họ từ bỏ những người lãnh đạo

Tôi đã tuyển dụng hàng ngàn người trong những năm qua. Và mỗi khi nhận được đơn xin nghỉ việc, một phần trong tôi dường như đã chết (đồng ý, tôi nói dối. Tôi đã thậm chí nhảy múa ăn mừng trong một vài trường hợp nhưng đó là trong một bài viết khác).

Phần lớn, phản ứng tức thời của tôi rất bản năng là tôi tự hỏi: lý do thật sự khiến cho họ làm điều đó? Có chuyện gì xảy ra với họ? hay thậm chí: cô ấy phải ra đi vì tiền. Thật ngốc nghếch!

Nhưng tôi đã khôn dần lên theo sự nhiều lên của năm tháng.

Phần lớn, mọi người không thay đổi công việc vì tiền. Họ cũng không xin nghỉ vì thích hay trong cơn nóng giận. Họ vào làm việc ở công ty của bạn bởi vì họ tin là họ thích hợp và ai cũng muốn quyết định đó đúng đắn. Đôi khi, tại một số thời điểm, có những điều khiến cho điều đó trở thành sai. Và nếu như bạn thực sự dành thời gian để “đào sâu” tìm hiểu lý do mà họ để lại – thực ra là bạn phải làm điều đó – thì bạn sẽ nhận ra rằng đó hoàn toàn không phải là “vì công ty” như họ đã nói. Đó không phải vì địa điểm làm việc, vì nhóm, vì hệ thống hay vì không khí làm việc.

Đó là vì người lãnh đạo!

Chắc chắn những người ấy không nói như thế. Và bạn chẳng thể tìm thấy được một từ đề cập đến vấn đề quản lý ở đây.

Nhưng khi họ nói về “tinh thần”, khi họ nói về “giao tiếp nghèo nàn”, khi họ bày tỏ sự thất vọng ở sự mập mờ, thiếu rõ ràng trong con đường thăng tiến, chính là họ đang đề cập đến những người lãnh đạo. Muốn rõ ràng hơn? Lãnh đạo là người có trách nhiệm trong việc gây dựng tinh thần – giao tiếp và con đường sự nghiệp của nhân viên.

Có lẽ vì thế mà tôi đã rất bực mình với những nhân sự cấp cao và ngăn họ lại giữa chừng – khi họ bắt đầu dùng những từ như ngu ngốc, vô ơn và dối trá để nói về những người nghỉ việc.

“Công ty” chỉ là một thực thể pháp lý. “Kinh doanh” chỉ là một bộ sưu tập bàn làm việc và máy tính. Không ai nghỉ việc vì những thứ đó.

Đó là quyết định, là động lực, là không khí làm việc, là sự hỗ trợ, đào tạo, tậm nhìn và sự chỉ đạo được xuất phát từ chính những người lãnh đạo mà họ đi theo.

Vì thế, lần sau khi bạn nhận được đơn xin nghỉ việc của nhân viên, hãy cố gắng đừng phấn khích và cười nhạo những người ra đi vì: đã thêm một kẻ ngu ngốc không thuộc về nơi này.

Hãy dùng ít phút để ngẫm nghĩ về lý do thực sự khiến họ ra đi.

Họ không từ bỏ những thứ họ không có được – cũng không phải từ bỏ công ty.

Họ từ bỏ bạn!

– dịch từ Poeple don’t leave companies. They leave leaders của Greg Savage

Nguồn: KIEN THUC KINH TE