Home Blog Page 217

Triết lý Marketing 0 đồng – tất cả nằm ở chữ “Mượn”

Các bạn đã từng nghe qua thuật ngữ “Zero cost-Marketing” hay còn gọi là marketing 0 đồng?

Lạ thật đúng không! bởi Marketing là một trong những ngành đòi hỏi kinh phí đủ lớn để có thể chạy một campaign thành công. Và bạn không hề sai, Marketing vốn rất phức tạp và cực kì tốn kém. Nhưng đó là với khuôn mẫu truyễn thống như quảng cáo qua TV, báo đài. Còn Zero cost-marketing là loại hình sinh sau đẻ muộn hơn, nhưng lại có tiềm năng vượt trội hơn hẳn các phương pháp truyền thông truyền thống, mà theo anh Nguyễn Ngọc Long – sáng lập truyền thông Trăng Đen đã nhận xét: “Zero cost-Marketing sẽ định hình lại bộ mặt của marketing”.

Trong buổi event với chủ đề: Triết lý Zero cost Marketing cho Star-up được tổ chức bởi TopDev, với sự tham gia của hai diễn giả: Nguyễn Ngọc Long – sáng lập truyền thông Trăng Đen và Nguyễn Minh Thảo – CEO Umbala, là hai nhân vật khá nổi tiếng trong cộng đồng marketing. Người tham dự cũng là những leader và CEO đầy tâm huyết từ các startup nên có thể nói buổi event diễn ra rất sôi nổi với nhiều câu hỏi mang tính thiết thực. Tôi cũng là một người đến tham dự và may mắn được lắng nghe những bài học quí giá từ 2 đàn anh đi trước.

Triết lý Zero cost Marketing cho Start-up cùng anh Nguyễn Minh Thảo – CEO Umbala và anh Nguyễn Ngọc Long – sáng lập truyền thông Trăng Đen

Trong bài viết ngắn này, tôi xin phép chia sẻ những quan điểm của anh Long và anh Thảo về Zero cost-marketing cũng như cách mà bạn có thể áp dụng nó vào trong chiến lược quảng cáo sản phẩm của mình.

Theo anh Minh Thảo: ” làm zero cost marketing là một điều mà không ai muốn bởi nó thể hiện rằng bạn và team phải “thắt lưng buộc bụng” và tận dụng mọi thứ mình có. Nói cách khác, Marketing không đồng có thể hiểu là thay vì bỏ chi phí cho quảng cáo thì dùng nguồn tiền đó để đâu tư cho nhân sự của team” . Do vậy, thuật ngữ zero cost marketing ở đây là chưa chính xác và dễ gây hiểu nhầm bởi ta vẫn phải bỏ tiền ra, nhưng tận dụng những nguồn lực sẵn có để marketing ít tốn kém nhất mang lại hiệu quả cao nhất.

Zero cost marketing đóng vai trò cực kì quan trọng, có thể nói là quyết định sự sống còn của một startup, anh Thảo cho biết. Có 3 nguyên nhân chính dẫn đến việc một startup bị thất bại. Đầu tiên là sản phẩm, nếu sản phẩm dở thì dù marketing có mạnh đến đâu vẫn là công cốc. Thứ hai là nguồn vốn, dù marketing có thông minh tới đâu thì ta vẫn phải rót tiền vào. Và nếu tiền cạn thì cũng là hết máu, marketing chết khô và startup phá sản. Cuối cùng chính là con người. Để làm được zero cost marketing thì phải cần có những con người có sự điên rồ cũng như khả năng thay đổi theo kịp với thời đại. Bởi bạn sẽ phải luôn làm cái mà phù hợp với thị trường và đồng thời phải là kẻ giỏi nhất. Do đó nhân sự giỏi thì marketing sẽ bớt tốn kém và hiệu quả tăng lên rất nhiều lần.

Vậy cách thực hiện zero cost marketing là gì?

Anh Thảo, cũng chia sẻ thêm: “trước khi quan tâm về cách thức thì hãy hiểu về bản thân trước. Anh cho rằng câu hỏi quan trọng hơn mà chúng ta luôn phải tự hỏi mỗi khi làm zero cost marketing là: nó để làm gì? Bạn có hiểu về sản phẩm chưa? Bạn đã biết gì về khách hàng bạn muốn nhắm tới rồi?”

Marketing 0 đồng thành công thì trong đó hơn 7, 8 phần nằm ở khâu này. Không quan trọng bạn nói gì, họ nghe gì từ bạn mới là điều quyết định. Vì thế hãy luôn chắc chắn rằng thông điệp bạn truyền tải phù hợp với đối tượng mình nhắm tới. Một vài ví dụ cho dễ hiểu là nếu khách của bạn là người trẻ, họ sẽ thích xem hình vui, clip chế. Còn nếu khách của bạn là người cao tuổi thì họ sẽ thích xem những bài post mang đậm tính giáo dục.Thế nhưng để làm ra những content “chất” như vậy, theo anh Thảo là vô cùng khó, thế nên zero cost marketing lúc này bao gồm 2 vấn đề là viral và content marketing. Nếu như viral là cách khiến cho tăng lượng người xem và biết tới thương hiệu một cách nhanh chóng thì content marketing sẽ giúp họ trở thành những người khách hàng đầy tiềm năng. Trong bài viết ngắn này thì tôi sẽ đi chuyên sâu hơn về phần Viral và phân tích phần của anh Thảo. Còn phần content marketing sẽ được giới trong bài viết  sau với anh Nguyễn Ngọc Long, có thể xem là một trong những người đi tiên phong trong lĩnh vực này.

Kế sách của người làm viral – content marketing: “Mượn”

Hẵn các bạn cũng nghe câu truyện cây cổ thụ và cơn bão. Vào thuở còn sơ khai, có một cây cổ thụ dài gần trăm mét, rễ bám sâu vào đất trong khi ngọn chạm đến trời. Nghe kể, cây vĩ đại tới mức nó nối được cả thiên giới với âm giới. Cây cổ thụ được người đời kính trọng nên khoái chí lắm. Mà thói đời hễ được xưng tụng thì lại bị xấu tính. Cổ thụ liền vênh váo, hách dịch. Đặc biệt là với mấy bụi tre ốm nhách kế bên mình. Lúc đó, trời đánh hơi được nên vô cùng nổi giận, liền cho bão nổi lên ầm ầm. Cổ thụ tuy rễ đụng tới tận nóc nhà của âm phủ cũng không thể chịu nổi mà phải chổng vó gẫy ngang cả người. Trong khi đó bụi tre người mèm dẻo ngả theo gió thì lại vẫn sống sót và được ông trời khen ngợi. Thế nên bạn cũng thấy được hễ làm gì, thì người Việt mình cũng dùng tới tre như làm lồng đèn, làm giáo, làm đũa… chứ tuyệt nhiên không xài tới cổ thụ. Làm zero cost marketing cũng phải như thế. Bạn phải như cây tre, đầy mềm dẻo và biết gió theo chiều nào thì mình theo chiều đó. Có trending nào thì mình phải mượn trending đó để làm marketing.

Anh Thảo cho rằng ta phải sống “kí sinh”, ăn theo và đứng trên vai người khổng lồ. Điều đó không có gì sai bởi làm start up thì làm gì có nhiều tiền. Mặt khác, để tạo ra một content chất thì nó mất rất nhiều tiền, thời gian và cả chất xám. Vì thế nó như một “con bài trùm”. Mà bài trùm thì có bao giờ đánh liền đâu, mà phải ém, để khúc quan trọng là tung ra để ăn cả giàn. Vậy trong thời gian chờ đợi đấy, hãy “mượn”. Mượn từ nội dụng, ý tưởng, mượn các trending đem về xào nấu lại theo phong cách của mình. Đó chính là tâm ý của viral marketing. Một ví dụ nho nhỏ là những hiện tượng như Sơn Tùng và các thể loại ăn theo như hình chế, clip chế, ….. với những ý tượng na ná nhau những vẫn là hit với trăm ngàn lượt hit và share.

Hi vọng qua bài viết này, các bạn đã có thêm cái nhìn rõ ràng hơn về marketing không đồng cũng như cách thức làm chúng. Lưu ý rằng đây chỉ như là bài hướng dẫn cho bạn hiểu cách một người làm marketing suy nghĩ. Sau đó việc thực hành là tùy vào mỗi người và khả năng tiếp thu của họ.

Techtalk

3 tools giúp bạn tăng hiệu năng của React App một cách bất ngờ

React rất đơn giản để học và làm, nhưng đôi khi vì quá dễ mà chúng ta hay mắc những lỗi nhỏ nhặt nhưng lại gây ảnh hưởng đến hiệu năng của chúng. Component mounts chậm, component trees quá rối rắm, cũng như những render cycle thừa thãi khiến cho user cảm thấy ứng dụng chạy chậm.

Thật may là có rất nhiều tool giúp phân tích và xách định vấn đề về hiệu năng trong React. Trong bài viết này tôi sẽ liệt kê ra những tool và mánh khóe để cải thiện tốc độ xử lí của các ứng dụng React.

Tool #1: Performance Timeline

React 15.4.0 vừa tích hợp vào tính năng mới là “performance timeline feature” cho phép bạn biết được chính xác khi nào components được mounted, updated, và unmounted. Nó còn có khả năng hiển thị component lifecycle cũng như mối quan hệ giữa chúng.

Note: Hiện tại tính năng này chỉ dành cho Chrome, Edge, và IE.

Cách nó hoạt động

  1. Vào app và nối đoạn query param sau: react_perf. Như thế này: http://localhost:3000?react_perf
  2. Mở Chrome DevTools Performance tab và chọn Record
  3. Thực hiện hành động mà bạn muốn được phân tích
  4. Dừng record
  5. Kiểm tra kết quả từ User Timing

Hiểu rõ kết quả (output)

Từng cột màu cho ta thấy thời điểm mà từng component hoạt động. Bởi vì JavaScript là single-threaded nên khi một component đang mount hoặc render, nó sẽ được chạy trong thread chính và các code phải ngưng lại cho đến khi quá trình trên hoàn thành.

Phần thông tin trong mục  [update] cho ta biết đang trong giai đoạn nào của component lifecycle. Cũng nhu thời gian cho từng bước để giúp bạn có thể so sánh giữa các phương pháp như  [componentDidMount], [componentWillReceiveProps] [ctor] (constructor) và[render].

Các cột được xếp với nhau nhằm tượng trưng cho component trees. Mặc dù theo thông thường thì chúng ta sẽ có component tree khá lớn trong React, nếu bạn đang tinh chỉnh một component thương xuyên được mounted, nó sẽ giúp làm giảm số lượng của wrapper component và kết quả là cải thiện hiệu năng của app.

Điều cần lưu ý là thời gian xử lí trong quá trình phát triển app luôn sẽ chậm hơn so với thông số thật. Tuy là bạn không nên quá dựa vào những thông số trên nhưng sự khác biệt cũng không nhiều và nó cho ta cái nhìn rõ hơn về chất lượng và hiệu năng của sản phẩm đang ở đâu.

Demo #1

Để cho vui, tôi thử phá TodoMVC app để khiến nó có những vấn đề nghiêm trọng về hiệu năng. bạn cũng có thể thử chúng tại đây.

Để xem timeline, mở Chrome dev tools, vào “Performance” tab, chọn Record. Sau đó thêm TODOs vào trong app, dừng record, và xem timeline. Hãy thử xem bạn có thể biết được component chính là nguyên nhân khiến cho hiệu năng bị ảnh hưởng không.

Tool #2: why-did-you-update

Một trong những nguyên nhân chính khiến cho các ứng dụng trên React chạy chậm là bởi có quá nhiều render cycle không cần thiết. Khi để ở chế độ mặc định, React components sẽ re-render khi ba mẹ chúng (component chứa chúng) reder cho dù là không có thay đổi bất cứ thứ gì.

Một ví dụ đơn giản là với component sau:

class DumbComponent extends Component {
  render() {
    return <div> {this.props.value} </div>;
  }
}

Tham khảo việc làm lập trình React lương cao cho bạn

Với một component mẹ như thế này: 

class Parent extends Component {
  render() {
    return <div>
      <DumbComponent value={3} />
    </div>;
  }
}

Mỗi khi component mẹ render thì DumbComponent re-render cho dù props của nó chả thay đổi gì.

Nói cách khác  render chạy nhưng DOM ảo vẫn không thay đổi gì và một render cycle bị phí phạm. Với một app lớn thì việc xác định ra nguồn ngọn sẽ rất khó khăn, may thay chúng ta đã có một tool cho trường hợp này.

Sử dụng why-did-you-update

why-did-you-update là một library dành cho React với chức năng phát hiện ra những component render không cần thiết. Nó sẽ theo dõi và ngay lập tức phát hiện ra những component’s  render mà prop lại không có thay đổi.

Setup

  1. Cài đặt với npm:  npm i --save-dev why-did-you-update
  2. Thêm phần dưới đâu vào bất kì đâu của app của bạn:
import React from 'react'
if (process.env.NODE_ENV !== 'production') {
  const {whyDidYouUpdate} = require('why-did-you-update')
  whyDidYouUpdate(React)
}

Demo #2

Để cho bạn thấy khả năng why-did-you-update, tôi cài library đó vào TodoMVC app trên Code Sandbox, một online React playground. Mở trình duyệt console và thêm một số TODOs để xem kết quả.

Bạn có thể lấy bản Demo tại đây.

Bạn sẽ thấy một số component trong app render một cách không cần thiết. Hãy thử dùng kĩ thuật trên để khắc phục chúng.

Tool #3: React Developer Tools

React Developer Tools Chrome extension có một tính năng là hiển thị component updates. Nó cực kì tiện lỡi cho việc phát hiện ra những render cycles không cần thiết. Để sử dụng nó trước hết bạn cần phải cài extension đấy.

Sau đó mở extension bằng bấm vào “React” tab của Chrome DevTools và chọn phần “Highlight Updates”.

Giờ thì chỉ việc dùng app, tương tác với compopnent và chứng kiến DevTool thực hiện phép thuật của nó.

Hiểu rõ kết quả (output)

React Developer Tools sẽ highlights các components có redering. Nó còn cho màu sắc khác nhau như xanh, vàng, đỏ tùy thuộc vào việc component có render thường xuyên hay không.  

Vàng và đỏ không có nghĩa là xấu bởi đôi khi ta update hoặc chạy nhiều tính năng nên khiến cho render diễn ra nhiều. Tuy nhiên nếu chỉ nhấn một nút đơn giản mà đã ra mà đỏ rồi thì khá là có vấn đề đấy. Mục đích của tool này là để chúng ta biết được update nào là không cần thiết. Và là một App developer, bạn sẽ biết khi nào thì enn6 update component.

Demo #3

Để bạn hiểu rõ hơn về tính năng component highlight, tôi đã sửa cho TodoMVC app update không cần thiết một số component.

Bạn có thể download bản Demo tại đây.

Vào đường link trên, mở React Developer Tools và chọn update highlighting. Khi bạn type trong text input, ta sẽ thấy toàn bộ TODOs highlight không cần thiết. Và khi bạn type nhanh hơn thì màu sắc cùa hightlight cũng sẽ biến đổi liên tục nhằm ám chỉ việc update thường xuyên.

Khắc phục renders thừa thãi

Sau khi bạn đã xác định được components nào re-rendering thừa thãi thì ta sẽ tìm cách khác phục chúng. Sau đây là một số phương pháp khá đơn giản.

Sử dụng PureComponent

Trong ví dụ trên,  DumbComponent là một pure function cho props của nó. Nói cách khác, component chỉ re-render khi Prop thay đổi. Có thể nói tính năng `PureComponent` trong React chính là để dùng cho trường hợp đặc biệt này.

Bạn có thể dùng React.PureComponent như sau: 

class DumbComponent extends PureComponent {
  render() {
    return <div> {this.props.value} </div>;
  }
}

Và thế là xong rồi đấy.

Tuy vậy, PureComponent chỉ quét sơ Props để phát hiện ra những thay đổi. Thế nên nếu trong trường hợp là một app phức tạp với nhiều Props khác nhau thì PureComponent đôi khi bỏ qua một số và sẽ không thay đổi.

Áp dụng shouldComponentUpdate

shouldComponentUpdate là một phương pháp của component khi ta call trước khi render  nếuprops or state có thay đổi hay không. Nếu  shouldComponentUpdate cho kết quả là true, thì render sẽ diễn ra còn nếu là false thì mọi thứ đều được giữ nguyên.

Với phương pháp trên, bạn có thể chỉ React cách tránh re-rendering thừa thãi với component mà props của nó không có thay đổi.

Chúng ta có thể áp dụng shouldComponentUpdate vào ví dụ trên như sau: 

class DumbComponent extends Component {
  shouldComponentUpdate(nextProps) {
    if (this.props.value !== nextProps.value) {
      return true;
    } else {
      return false;
    }
  }
render() {
    return <div>foo</div>;
  }
}

Debugging vấn đề về hiệu năng

The React Developer Tools chỉ hoạt động với app của bạn trong máy của bạn. Thế nên nếu bạn muốn biết những vấn đề hiệu năng khi khách hàng sử dụng sản phẩm của mình thì hãy thử LogRocket.

LogRocket giống như DVR dành cho web apps, nó record lại tất cả mọi thứ xảy ra trên website của bạn. Nhờ đó thay vì phỏng đoán một cách mơ hồ thì giờ bạn đã có thể nhanh chóng replay lại và xác định được ngay vấn đề dẫn đến việc hiệu năng bị giảm sút.

LogRocket sẽ khiến App của bạn record thông tin về hiệu năng, Redux actions/state, logs, errors, network requests/responses với headers + bodies, và browser metadata. Không chỉ thế, nó còn record cả HTML và CSS trên trang, tạo lại videos chính xác tới từng pixel của các app một trang phức tạp nhất có thể.

Cảm ơn vì đã đọc bài viết này và hi vọng nó sẽ giúp ích cho các bạn trong project React tiếp theo.

Nguồn: topdev via Medium

Tham khảo thêm vị trí việc làm ngành IT tại đây

Database conventions

1. Intro

(1) Thiết kế database là công việc thường ngày của engineer, nhất là các bạn database engineer. Giống với coding cần clean, database cũng cần tính chất tương tự nhằm giúp việc vận hành, thay đổi, chuyển giao nó đỡ tốn nhiều công sức hơn, do đó chúng ta cũng cần có một số quy tắc nhất định trong việc thiết kế.

Thường thì mỗi nhóm hay công ty sẽ có bộ quy tắc riêng cho mình, cho dù có được viết thành document rõ ràng hoặc không. Cũng giống như coding có nhiều trường phái khác nhau, ví dụ python thì có hai đại diện tiêu biểu là PEP8 và Google Python Style Guide, Database conventions cũng không nhất thiết phải tuân theo một chuẩn duy nhất, miễn sao nó mang lại những giá trị mà theo tôi là quan trọng nhất: Sự thống nhất (Consistency) và Dễ hiểu (Simplicity, Self-explaining)

(2) Đã bao giờ bạn nhìn vào thiết kế DB của hệ thống cũ khi gia nhập vào một công ty mới hoặc khi bạn tham gia vào một team khác và tự hỏi những câu giống như dưới đây không?

  • “WTF is this field?” (ca này hay gặp nhất :D)
  • “Cái field status này có giá trị là 0-1 hay còn gì khác không?” (chẹp, SELECT DISTINCT để tìm chân lý vậy)
  • (đang code) “Table random này thì PK là id hay random_id nhỉ?” (mở DB ra coi lại)

Well, cá nhân tôi đã gặp khá nhiều và trở thành ám ảnh khi phải tiếp cận với một hệ thống lớn và phức tạp (ví dụ có 1000 table chẳng hạn) mà lại thiếu document. Đừng hiểu nhầm, tôi không kỳ vọng một bộ document cực kỳ lớn tới mức tôi phải lấy nhiều dũng cảm mới có thể đọc hết cho 1000 table kia, hoặc mỗi khi muốn biết 1 field là gì lại phải giở tài liệu ra tìm kiếm. Phần lớn các field đều có thể hiểu nhanh được nếu đặt tên tốt và có lúc cũng cần giải thích ngắn gọn đi kèm. Đây là 1 ví dụ:

A field with comment

(3) Vậy có cần DB document hay không? Tôi nghĩ là vẫn cần. Mỗi business/domain có các đặc thù riêng, dẫn tới các data field cũng khá đặc biệt nên nếu tôi không tìm hiểu kỹ thì sẽ chẳng hiểu nổi nó là gì, tương tác với dữ liệu đó sao cho đúng, như ví dụ dưới đây:

(4) Sẽ dễ dàng hơn nếu ngay từ khi thiết kế, chúng ta tuân theo một quy tắc là làm sao lần sau đụng tới thì tốn ít effort nhất có thể. Nhiều quy tắc được tổng hợp và thống nhất trong team thì trở thành bộ Database Conventions của team đó.

Trong bài này tôi sẽ đề cập tới một số conventions mà tôi và team của mình hay dùng.

Xem thêm: Việc làm Database lương cạnh tranh hấp dẫn

2. DB Conventions

2.1. Một số quy tắc chung về đặt tên

Nên Ví dụ Không nên Giải thích
Tên là danh từ tiếng Anh
Chỉ dùng danh từ số ít inventory
shelf
octopus		 inventories  octopodes
 shelves octopuses
octopi		 Đỡ mất thời gian nghĩ
Chỉ dùng lower_case  customer customer
Chỉ dùng dấu gạch dưới _ để nối các từ  first_name FirstName  firstName
 "First Name"		 – Dễ đọc hơn
– Đỡ thắc mắc khi nào thì có chữ hoa, khi nào thì có gạch dưới
 Tên có tính tự giải thích.
– Tránh dùng từ viết tắt
– Tránh dùng kiểu dữ liệu thay cho tên		  middle_name
 blog.content
amt		  mid_nm
 blog .text
amount		  Dễ hiểu
 Tránh dùng từ khóa của SQL  display_order
 updated_at
user_name
  order
date
 name		  Có thể bị báo lỗi syntax nếu không enquote
 Tên ngắn gọn, không nên dài quá 64 ký tự

2.2. Table

Nên Ví dụ Không nên Giải thích
Đặt prefix cho các table liên quan catalog_category
catalog_product		 Tìm kiếm table dễ hơn
Thêm suffix _tmp cho các table dùng tạm trong tính toán nhưng không xóa catalog_product_price_tmp
 Thêm prefix tmp_ cho các table dùng tạm, có thể xóa  tmp_im_calculating

2.3. Column

2.3.1. Column

Nên Ví dụ Không nên Giải thích
Tránh thêm tiền tố không cần thiết product.name product.product_name – Tên table đã nêu rõ context
Thêm prefix is_ cho các field dạng YES/NO is_active
 is_delivered
is_free_shipping		 active delivered
 free_shipping		 Nhìn field là biết chỉ có 2 giá trị
Nên lưu các thời điểm thay đổi dữ liệu với từng record created_at
updated_at
 deleted_at		 Theo dõi tính toàn vẹn dữ liệu
Không đặt tên chứa kiểu dữ liệu  return_code int_return_code Kiểu dữ liệu có thể thay đổi:
– date => timestamp
– int => bigint

2.3.2. Primary Key

Nên Ví dụ Không nên Giải thích
Chỉ nên dùng PK là id table .id table .table_id – Dễ nhớ
– Giảm effort khi đổi tên table sau này
Mỗi table nên có 1 PK, bên cạnh các UNIQUE KEY khác PRIMARY KEY (id),
UNIQUE KEY idx_unique (key1,key2)		 Làm việc với các record nhanh hơn
PK mặc định nên dùng kiểu Interger, Auto-increment

2.3.3. Foreign Keys

Nên Không nên Giải thích
Tên FK được kết hợp từ tên field và tên table mà nó tham chiếu tới person_id là FK của table và field person.id Dễ hiểu
Tùy chọn Cascading Update có thể dùng, nhưng Cascading Delete thì nên tránh Giảm rủi ro khi lỡ xóa record ở main table khiến cho toàn bộ dữ liệu liên quan biến mất

2.3.4. Indexes

Nên Ví dụ Giải thích
Thêm prefix idx_ ở đầu  idx_created_at Dễ nhớ, nhất là khi ALTER TABLE mà không dùng GUI Tool

3. Tổng kết

Có nhiều quy tắc để nhớ, tuy nhiên có thể dựa trên nguyên tắc thiết kế ban đầu là:

Be Consistent and Simple, don’t waste your brain any single second for any unnecessary thing

Bạn có best-practice hoặc các quy tắc nào khác hữu ích hơn cho việc thiết kế Database không? Nếu có hãy chia sẻ cho mọi người tại đây nhé!

Nguồn: kipalog

Review: phỏng vấn vào vị trí SDE của Amazon

Mình vừa kết thúc job interview với Amazon vào tuần trước và đang chờ kết quả. Trong quá trình chờ đợi này, mình quyết định viết 1 cái note để kể về quá trình phỏng vấn, giúp cho anh chị em bạn bè nào muốn apply vào công ty này có thể mạnh dạn hơn. Mình không đợi có kết quả rồi mới viết vì sợ lúc đó chả có hứng nữa..

Vì mình ký vào bản cam kết NDA của Amazon, nên sẽ không tiết lộ bất cứ câu hỏi phỏng vấn hay tài liệu Amazon cung cấp nào trong bài viết này. Mình chỉ mô tả các bước tuyển dụng, độ khó dễ và feeling của cá nhân thôi. Ví trí mình phỏng vấn đợt này là SDE (Software Development Engineer), làm việc tại Vancouver, Canada. Có lẽ mình nên bắt đầu câu chuyện bằng lý do tại sao mình lại apply vào đây. Bên Amazon người ta đi khắp các nước để tổ chức Hiring Event, và Việt Nam là 1 trong số các điểm đến.

Hiring Event ở VN được ấn định vào 18-20/4/2017. Do vậy, trước đó 3, 4 tháng, các recruiters của Amazon lùng sục khắp cộng đồng LinkedIn ở VN để tìm ứng viên. Và may mắn thay, profile của mình lọt vào tầm ngắm của họ, và vào ngày 25/2 họ gửi mail mời mình join hiring process này, đúng 1 tháng sau khi mình nghỉ việc ở Zalo. Lúc đó mình đang cày IELTS điên cuồng và không định apply vì… sợ mất thời gian (trước đó có myth là phỏng vấn vào mấy công ty to như thế này rất khó và phải chuẩn bị cả năm trời mới okay). Sau cùng nhờ sự động viên của 1 vài người anh em, mình quyết định nộp CV cho người ta.

Vì người ta đã chọn mình trước nên đương nhiên vòng CV mình sẽ pass. Nhưng với nhiều bạn, vòng CV có thể là 1 vòng khó, nếu bạn không biết trau chuốt và nêu các thế mạnh của mình ra. Do vậy các bạn nên nghiên cứu kỹ, ví dụ link này Sau khi nhận được CV của mình, recruiter lập tức move forward sang bước thứ 2 là coding challenge. Mình được cho 1 cái link, mở ra là 1 IDE online, đi kèm với đề bài, kiểu như trang hackerrank vậy. Mình phải giải quyết 2 problems trong vòng 90 phút. Problems không quá khó, khá cơ bản, nếu bạn nào từng thi Google Code Jam thì còn thấy mấy bài này dễ hơn.

Chủ yếu mấy bài này test kiến thức Data Structure và Basic Algorithm thôi. Các bạn có thể dễ dàng search các đề bài kiểu này trên internet. Nếu các bạn thiếu tự tin thì có thể lên trang hackerrank để luyện tập. Mình thì hôm đó nhảy vào làm luôn vì lười luyện (lúc này vẫn đang tập trung cày IELTS. 1 tuần sau Coding Challenge, mình nhận được kết quả là đã pass và move forward tới vòng Phone Interview. Ở vòng này, người ta bảo rõ với mình là sẽ hỏi về DS (Array, List, Tree, Graph, HashTable…), Algorithm (BFS, DFS, Tree Traversal, Recursive function…) và quan trọng là hỏi về 1 vài example của mình trong công việc. Câu hỏi đó thường là “tell mReview: phỏng vấn vào vị trí SDE của Amazone about a situation in which you ….”.

Các câu hỏi kiểu này cũng dễ tìm thấy trên mạng nên mình ko nêu ra ở đây. Chỉ lưu ý các bạn là phải chuẩn bị trước kỹ càng cho các câu hỏi này, vì nó đóng vai trò rất quan trọng trong việc đánh giá của người ta. Phone Interview chỉ kéo dài 30 mins thôi nên đừng lo lắng quá. Cố gắng tập luyện để nói cho trôi chảy và hiểu được câu hỏi của recruiter cộng với review lại kiến thức để trả lời cho chắc chắn.

Hơn 1 tuần sau vòng Phone Interview, mình nhận được kết quả báo đã pass và được join hiring event. Hiring Event sẽ là face-to-face interview theo dạng loop. Có nghĩa là trong 1 buổi, kéo dài 4 tiếng, mình sẽ có 4 cuộc interview nhỏ với 4 nhóm Interviewers khác nhau. Hiring Event được tổ chức tại khách sạn Pullman, Ho Chi Minh City, và toàn bộ interviewers lẫn coordinators sẽ bay từ Canada sang Việt Nam để tổ chức. Từ lúc nhận tin đến lúc phỏng vấn thì mình chỉ có gần 20 ngày để chuẩn bị. Recruiters rất chu đáo khi gửi mình đầy đủ toàn bộ topic lẫn document cần phải nghiên cứu để chuẩn bị cho phỏng vấn.

Chỉ mỗi tội là khối lượng là khá nhiều nên khó để mà chuẩn bị được chu đáo trong 20 ngày. Nếu vượt qua được vòng này thì mình sẽ nhận được offer của Amazon, nên mình quyết tâm tạm dừng cày Ielts để dấn thân vào ôn luyện. 4 interviews sẽ có format tương tự nhau. Mỗi interview kéo dài 50 mins. 25-30 mins đầu dành cho việc hỏi các example (câu hỏi kiểu “tell me about a situation…” mà mình đề cập ở trên).

Người ta xoáy khá sâu vào các câu trả lời của mình, hỏi tường tận từng gốc rễ. Các example mà mình đưa ra vì vậy cần phải trung thực, bịa là biết liền. Quan trọng nhất là các example đó phải align với leadership principles của Amazon. Với phân nửa thời gian dùng để hỏi mấy cái này nên mình nhận thức được nó quan trọng như thế nào và cũng chuẩn bị khá kỹ, mặc dù vậy, có 1 vài câu hỏi vẫn không nghĩ ra được example ngay, phải xin họ 1 phút để ngồi ngẫm. Phần thời gian còn lại của interview là dành cho coding exercise (khoảng 20-25 mins).

Đề bài khá đa dạng, và toàn bộ code của mình phải viết trên bảng trắng (white board), chứ không phải bằng keyboard (cái này sinh viên BKHN chắc master luôn vì toàn phải thi lập trình trên giấy). Loop 1 mình được cho 1 đoạn code dài 1 trang A4 và yêu cầu viết lại cho dễ maintain và develop về sau. Key để solve được bài này là phải hiểu và vận dụng được cái Abstract Factory để thay cho 1 đoạn check if else quá dài. Do vậy, kinh nghiệm là phải nắm rõ được các Design Pattern cơ bản để giải. Loop 2 là 1 bài dạng Tree, áp dụng đệ quy linh hoạt chút là giải okay.

Loop 3 là 1 bài dạng graph, cũng không phức tạp lắm. Khó nhất là loop 4, là 1 bài Object Oriented System Design. Đề bài là 1 tình huống trong đời thực và mình phải vận dụng các kỹ năng thiết kế hướng đối tượng để mô hình hóa thành các class, viết các phương thức giao tiếp chính giữa các class. Mình vận dụng hết aggregation với inheritance, Queue, Timer, EventListener… để giải bài này.

Tuy không được hoàn chỉnh nhưng interviewer cũng accept cách làm của mình. Trong lúc giải các bài coding, mình contact liên tục với interviewers, hỏi họ bất cứ thứ gì mà mình thấy confuse, thỉnh thoảng họ cũng đưa ra gợi ý hoặc hỏi thêm mình 1 số câu hỏi. Điều đó giúp cho mình giải quyết các vấn đề nhanh hơn và tối ưu hơn. Mình coi các interviewers như những người đồng nghiệp đang trao đổi về bài toán với mình, chứ ko phải examiners trong 1 cuộc thi. Đây cũng là cách mình học hỏi qua cuốn Crack the Coding Interview. Các bạn quan tâm có thể đọc cuốn này, rất bổ ích. Cuối mỗi interview, các interviewers sẽ cho mình thời gian khoảng 5 phút để đặt câu hỏi cho họ.

Ban đầu mình chỉ chuẩn bị có 2,3 câu, hỏi 1 lần là hết, nên sau đó vào giờ nghỉ giải lao, phải vắt óc nghĩ xem nên hỏi người ta câu gì cho hay, cho ý nghĩa Nếu có lần sau chắc chuẩn bị hẳn chục câu từ ở nhà luôn. Mình vẫn đang đợi kết quả cuối cùng từ Amazon, nếu fail thì đây là bài viết duy nhất của mình nói về Hiring Process của Amazon.

Còn nếu pass thì mình sẽ có 1 số bài viết cụ thể hơn để nói về cách mình vượt qua từng vòng, từng vòng. Dù sao thì việc được tham gia phỏng vấn cũng là 1 trải nghiệm thú vị và đáng nhớ đối với mình Do vậy mình ko hề tiếc vì đã tiêu tốn thời gian cho sự kiện này. Cảm ơn các bạn đã bớt chút thời gian để đọc À một điều may mắn đối với mình là Amazon lại liên hệ đúng lúc mình đang nghỉ Zalo để học Ielts, nên trình nói tiếng Anh đang lên, và cũng có nhiều thời gian để chuẩn bị. Chứ nếu vừa đi làm vừa chuẩn bị thì chắc fail từ vòng gửi xe Update mới nhất 11h20pm ngày 26/04/2017: recruiter gọi điện cho mình báo pass interview. Chờ deal lương và làm thủ tục

Nguồn: Ken Nguyễn

Đây là cách Node.js được sử dụng

Node.js Foundation vừa công bố kết quả khảo sát trên toàn thế giới, tìm hiểu về mục đích sử dụng Node, nhằm xác định các thay đổi tiềm năng cho framework mã nguồn mở này.

Cuộc khảo sát được tiến hành trực tuyến từ ngày 30 tháng 11 đến ngày 16 tháng 1 năm 2017 với sự tham gia của 1.405 người. Các câu trả lời được phân tích bởi một hội đồng tư vấn nghiên cứu độc lập.

Hãy xem Node.js dùng để làm gì!

Trước hết, cuộc khảo sát kết luận rằng …

“Node.js đang nổi lên như là một framework phát triển dành cho việc chuyển đổi kỹ thuật số với nhiều ứng dụng đa dạng”

Các nhà phát triển chủ yếu sử dụng Node.js cho back-end, nhưng nó cũng được sử dụng như một giải pháp tốt cho cả Full-stack và Front-end.

Một trong những điểm mạnh của Nodejs là có thể sử dụng cùng 1 ngôn ngữ trong toàn bộ stack.

Bởi vì tất cả developer có thể dễ dàng hiểu điều gì đang xảy ra và những thay đổi nếu cần.

Foundatinon đã hỏi những người trả lời về những gì họ build với Node.js

Kết quả cho thấy Node.js được sử dụng chủ yếu để xây dựng các ứng dụng web, nhưng chúng tôi cũng nhận thấy rằng nó cũng là một sự lựa chọn rất phổ biến để xây dựng các ứng dụng doanh nghiệp.

‘“Sự phát triển của Node.js trong các công ty là một minh chứng cho sự linh hoạt của platform này. Nó không chỉ đơn giản là một nền tảng ứng dụng được sử dụng để thử nghiệm với dữ liệu và công ty, ứng dụng hiện đại hóa, và các giải pháp IoT. (Nguồn: Phân tích của Forrester)”

Cuộc khảo sát cho phép chúng ta tìm hiểu về những lựa chọn mà developer sử dụng Node để tạo ra. Kết quả cho thấy AWS là lựa chọn chính để chạy các ứng dụng Node.js trong sản xuất – nhưng có vẻ như các cơ sở hạ tầng tại chỗ (hoặc tự chủ) cũng rất phổ biến.

Dữ liệu này phù hơp với những dữ liệu chúng tôi thu được tại RisingStack đo cách đây một năm qua khảo sát Node.js. Sự khác biệt duy nhất đáng chú ý là cách đây một năm trước, Heroku và DigitalOcean là những đối thủ ngan cơ nhau trong cuộc chiến Node, giờ đây dường như Heroku đã có một chút lợi thế.

Ai sử dụng Node.js?

Vì Node.js có LTS (một kế hoạch hỗ trợ dài hạn tập trung vào bảo mật và ổn định) từ năm 2015, không có gì ngạc nhiên khi các tập đoàn lớn liên tục bổ sung nó vào các stack của họ.

Note không chỉ chinh phục các doanh nghiệp, mà còn trên phạm vi toàn cầu. Cộng đồng người dùng Node.js trải rộng trên 85 quốc gia và nói hơn 45 ngôn ngữ.

Theo cuộc khảo sát, phần lớn các nhà phát triển Node đang sống tại Châu Âu (41%), chứ không phải ở Bắc Mỹ.

Tại sao lập trình viên yêu thích Node.js?

Những người tham gia khảo sát cho rằng, Node.js cải thiện năng suất và hiệu suất ứng dụng một cách đáng kể.

Ngoài ra, thật tuyệt vời khi thấy rằng những lợi ích của việc sử dụng Node tăng tỷ lệ thuận với thời gian sử dụng

Các nhà phát triển và nhà quản lý sử dụng Node.js trong hơn hai năm đã khen ngợi các tác động tích cực này.

“Cuộc khảo sát cho thấy các nhà phát triển và chuyên gia phân tích dữ liệu / kinh doanh lớn nhận ra được những tác động tích cực lên kinh doanh sau khi Node.js tham gia vào cơ sở hạ tầng của họ với những lợi ích chính là năng suất, sự hài lòng, giảm chi phí và tăng hiệu suất ứng dụng.”

User “điển hình” của Node.js là cử nhân với 6-9 năm kinh nghiệm lập trình

Theo bảng điều tra đặc điểm nhân khẩu học người dùng của cuộc khảo sát, hầu hết các nhà phát triển sử dụng Node v6 (57%) và dành một nửa thời gian của họ bằng cách viết code trong Node.

Khảo sát cũng cho thấy rằng phần lớn các nhà phát triển nâng cao kiến thức của họ bằng việc tham gia các khóa học trực tuyến và các nguồn lực và thật tuyệt vời khi thấy NodeSchool cũng khá phổ biến.

Tương lai của Node.js

Theo báo cáo của TechCrunch vài tháng trước đây, Node.js đã trở thành một loại mã nguồn mở cấp doanh nghiệp.

Điều này có nghĩa rằng platform này là một trong những công nghệ mới nhất của doanh nghiệp hiện nay. Do đó, nhiều công ty lớn – từ những người khổng lồ về tài chính đến các nhà bán lẻ cho các công ty dịch vụ – đang xây dựng các doanh nghiệp của họ trên nền tảng Node.js thay vì các ngôn ngữ cũ như PHP hay Java.

Một điều chắc chắn là:

Với hơn 8 triệu lượt sử dụng Node.js trực tuyến, 3 trong số 4 người dùng cho biết sẽ tăng việc sử dụng của họ trong 12 tháng tới.

Học Node.js

Trong trường hợp bạn muốn nâng cao kiến thức về Node.js của mình, chúng tôi khuyên bạn nên kiểm tra hai khóa học trực tuyến miễn phí của chúng tôi và một số sách điện tử của chúng tôi:

Các bài hướng dẫn trực tuyến miễn phí:

  • Node Hero là một loạt hướng dẫn cho người mới bắt đầu tập trung vào các vấn đề cơ bản của Node. (Tổng cộng 13 chương)
  • Node.js at Scale là một tập hợp các bài viết tập trung vào nhu cầu của các công ty có cài đặt Node.js lớn hơn và các nhà phát triển đã học được những điều cơ bản về Node. (Tổng cộng 19 chương)

Sách điện tử miễn phí:

Nguồn: blog.topdev.vn via hackernoon

Một số mẹo vặt dành cho Developer trên Chrome

1. Animation

Nếu như trang web của bạn có animation, bạn có thể giảm tốc độ hiển thị animation xuống còn 10% hay 25% để kiểm tra các bug lỗi dễ dàng hơn

2. Pretty screenshotting

Khi truy cập một trang web dưới chế độ mobile mode thì chrome hỗ trợ một tính năng chụp ảnh màn hình, đồng thời ảnh được chụp sẽ được tải ngay về máy tính. Trong phiên bản mới nhất của chrome, bạn còn có thể chụp full màn hình cho dù nội dung có dài đến đâu đi chăng nữa

Nếu bạn bật thêm chế độ show device frame thì hình ảnh tải về có cả hình điện thoại đi kèm như dưới đây

3. Chỉnh sửa text trực tiếp trên web

Giả sử trong quá trình phát triển bạn muốn thay đổi một vài đoạn text cho mục đích testing, có thể bạn sẽ nghĩ ngay tới Inspect HTML rồi sửa giá trị HTML là xong. Cách đấy cũng được, tuy nhiên còn một cách thú vị hơn nhiều đó là bạn chuyển trang web sang chế độ designMode bằng cách mở console gõ lệnh document.designMode=’on’ là xong

4. Chỉnh sửa với màu sắc

Trong chrome, mỗi khi chúng ta muốn thiết lập màu sắc cho background hay font chữ thì có thể chọn màu sắc thông qua popup đơn giản này. Hơn nữa chrome cũng hỗ trợ 2 mẫu mầu mắc đó là material design và các màu có sẵn trên trang web hiện tại

5. Kiểm tra font family

Đôi khi thật khó để biết được trang web đang sử dụng mẫu font nào. Chúng ta có một cách đơn giản hơn là vào tab computed, để ý vào phần filters (nhớ tích chọn show all)

Bây giờ kéo xuống dưới một chút, bạn có thể nhìn thấy mục font family có chứa những tên font mà đôi khi bạn không thể inspect nổi

6.  Code snippet

Bạn có thể lưu lại các đoạn script hay dùng để test vào mục snippet của chrome

Tham khảo thêm các vị trí tuyển dụng ngành cntt hấp dẫn tại Topdev

Ứng dụng chrome mà mình sử dụng trong bài viết này là Chrome Canary – được khuyên dùng bởi google dành cho các lập trình viên. Mình có chọn lọc một số nội dung và lược dịch từ bài viết gốc tại đây

5 thói quen ngày thứ 2 giúp bạn xây dựng app tốt hơn

Khi build 1 sản phẩm kỹ thuật có rất nhiều điều cần lưu ý. Nếu bạn là 1 Product Manager hoặc bạn là trưởng nhóm phát triển sản phẩm, có lẽ một trong những vấn đề hàng đầu bạn có thể gặp phải là một loạt những vấn đề “khẩn cấp” đòi hỏi sự chú ý của bạn. Và sớm hay muộn, điều đó cũng dẫn tới hệ quả là những điều quan trọng sẽ không được quan tâm một cách thích đáng.

Tôi tin tưởng một cách mạnh mẽ vào sức mạnh của thói quen. Vì vậy, theo lời khuyên của Eisenhower, tôi lên thời gian biểu vào mỗi buổi sáng thứ hai, và đây là 5 điều tôi chắc chắn rằng mình sẽ làm.

1/ Phân tích thống kê và KPIs

Tôi có thể nói điều này có lẽ nên là một thói quen hàng ngày. Tôi đoán không cần phải nói thêm về tầm quan trọng của nó. Theo Drucker, nếu bạn không thể đo lường nó, bạn không thể quản lý nó.

Ngay cả khi bạn nhìn vào các KPI của bạn mỗi ngày, dành thêm thời gian vào thứ Hai phục vụ 2 mục đích:

  • Xác định thời gian cụ thể trong tuần để so sánh kết quả giữ các tuần .
  • Khám phá hành vi người dùng: có thể đây là một phần của đánh giá hàng ngày của bạn bao gồm các KPI chính cho các sản phẩm của bạn. Nhưng điều này sẽ không cung cấp cho bạn bất kỳ cái nhìn sâu sắc về hành vi người dùng … những gì đang chi phối KPIs? (nó thực sự sẽ hữu ích cho quyết định sản phẩm). Khám phá hành vi và nhận được những hiểu biết này là một cách tuyệt vời để bắt đầu một tuần mới với những việc cần thực hiện sau đó.

Ví dụ:

Trong khi làm việc về thương mại điện tử, tôi đã dành thêm thời gian vào buổi sáng thứ hai để khám phá hành vi “người mua” liên quan đến việc sử dụng bộ lọc. Mặc dù mức sử dụng bộ lọc thấp, nhưng những người sử dụng chúng có khả năng mua gấp đôi. Khám phá Insight khách hàng cung cấp cái nhìn sâu sắc rõ ràng hơn về khả năng chuyển đổi hành vi người mua.

2/ Kiểm duyệt sản phẩm

Điều này nghe có vẻ rõ ràng, nhưng điều làm tôi ngạc nhiên là rất nhiều người không làm điều này.

Trong trường hợp của tôi, tôi tiến hành kiểm duyệt sản phẩm một cách ngẫu nhiên, vào những thời điểm bất kì.

Khi tôi thiết lập nó như là một thói quen, tôi tạo ra danh sách các trường hợp lỗi thường gặp và cố gắng nhắc nhở mình thường xuyên.

Nhưng tôi nhận thấy rằng mình muốn đưa nhiệm vụ kiểm duyệt sản phẩm lần cuối vào list những công việc cần làm ngày thứ 2. Vì vậy, tôi đã tạo ra một “backlog” nhỏ để đánh giá lỗi thường xuyên, cố gắng dựa trên kinh nghiệm của người dùng đang sử dụng sản phẩm đó (tương tự như tôi sẽ yêu cầu người dùng làm thử nghiệm khả năng sử dụng)

Ví dụ:

Trước đây khi làm việc cho một công video game, tôi đã sử dụng sản phẩm (chơi trò chơi: D) trong 5-10 phút mỗi ngày.

Nhưng tôi nhanh chóng nhận thấy rằng tôi đã không trải qua những kinh nghiệm với tần suất đủ để hiểu về trải nghiệm người dùng. Tùy thuộc vào từng giai đoạn của vòng đời sản phẩm, mỗi tháng chúng tôi có từ 20% đến 80% số người dùng mới, do đó, tại bất kỳ thời điểm nào, nó là một con số lớn.

Đó là lý do tại sao tôi buộc bản thân phải trải nghiệm sản phẩm mỗi 2 tuần, nhờ thói quen này mà các tính năng mới sẽ luôn phù hợp với trải nghiệm người dùng mới.

3/ Kiểm tra đối thủ cạnh tranh và các sản phẩm liên quan

Tôi tin rằng bất cứ ai làm việc liên quan đến các sản phẩm kỹ thuật đều kiểm tra đối thủ cạnh tranh.

Tương tự như với sản phẩm của tôi, trước khi tôi xây dựng thói quen này tôi đã kiểm tra đối thủ cạnh tranh nhưng vào những theo một cách ngẫu nhiên và với mục đích ngẫu nhiên. Điều này, tất nhiên, đã khiến tôi bỏ qua rất nhiều cải tiến quan trọng, hoặc các tính năng mới không được kiểm soát.

Bây giờ tôi có một danh sách các đối thủ cạnh tranh tôi muốn đảm bảo kiểm tra thường xuyên các đối thủ của mình và cập nhật những thay đổi mỗi tuần.

Tôi cũng có một danh sách các công ty không phải là công ty đối thủ nhưng là nguồn cảm hứng cho sản phẩm của tôi. Ví dụ như Amazon, làm cách nào tôi có thể cải thiện thanh toán dựa trên kinh nghiệm tuyệt vời mà họ cung cấp?

Có một vài trường hợp tôi thường xử dụng, bao gồm cả các công việc ở thói quen #2 để đảm bảo rằng không có bất kì sự trùng lặp thông tin nào

Dựa vào ví dụ cuối ở duóiw, tôi bắt đầu kiểm tra sản phẩm của các đối thủ cạnh tranh trực tiếp, thường xuyên và các sản phẩm có liên quan phổ biến tại thời điểm đó.

4/ Tuần này bạn muốn trả lời câu hỏi gì?

Có thể bất cứ lúc nào, bạn cũng có thể đưa ra những giả thuyết và ý tưởng, và rất có thể có nhiều người sẽ đến mang theo những ý tưởng và giả thuyết khác và thuyết phục bạn thêm chúng vào danh sách của bạn.

Buổi sáng thứ hai là một thời điểm tuyệt vời để tổ chức lại chúng. Trong trường hợp của tôi, chỉ cần trải qua thói quen phân tích KPI, đánh giá sản phẩm và điểm chuẩn, cho tôi cái nhìn tổng thể vấn đề để quyết định ưu tiên trả lời những câu hỏi nào trước.

Cho dù bạn có một “backlog ý tưởng”, một sơ đồ cơ hội-giải pháp, hoặc một danh sách các việc đang làm, tôi vẫn khuyên bạn sử dụng buổi sáng thứ hai để tập trung và đưa ra một câu hỏi bạn muốn trả lời trong tuần đó.

Trở lại trải nghiệm của tôi trong trò chơi game, chúng tôi đã có phiên bản alpha cho một trò chơi mới, tỷ lệ người chơi cao hơn so với phiên đầu tiên. Theo thói quen # 1 chúng tôi đã xác định được một mô hình: chúng tôi thấy rằng khi người chơi đạt đến “Cấp 5”, sự gắn bó của họ tốt hơn nhiều. Vì vậy, cơ hội / giả thiết / câu hỏi mà tôi muốn trả lời trong tuần đó chỉ đơn giản là: điều gì sẽ làm cho nhiều người đạt đến cấp 5?

Tôi sẽ trở lại phân tích ví dụ này ở thói quen tiếp theo.

Hãy nhớ rằng câu hỏi để trả lời có thể liên quan đến nhiều khía cạnh của sản phẩm. Bạn có thể có các câu hỏi nghiên cứu theo định hướng (nghĩa là chúng ta đang giải quyết vấn đề gì?) Hoặc có nhiều đề xuất về giá trị liên quan (ví dụ: ai sẽ muốn tính năng này?). Có rất nhiều lựa chọn. Điều quan trọng là nắm bắt cái gì đó mà bạn muốn có thêm thông tin để đưa ra quyết định sản phẩm.

5/ Thúc đẩy trải nghiệm / tương tác khách hàng

Sau khi chọn một giả thuyết hoặc một câu hỏi mà bạn muốn giải quyết trong tuần này, bước tiếp theo là để suy nghĩ cách để trả lời.

Thông thường, điều này trở nên hoặc là:

  • Thử nghiệm: thiết lập 1 cửa giả hoặc trang đích để thử nghiệm đề xuất giá trị, giải pháp trợ giúp đặc biệt hoặc bất cứ điều gì bạn có thể chạy nhanh để tìm hiểu về những kết quả có thể xảy ra với những gì bạn dự định xây dựng.
  • ( Hoặc là ) Một cuộc phỏng vấn / kiểm tra khả năng sử dụng: với mục tiêu cụ thể này, hãy đối mặt với khách hàng trong các cuộc đối thoại trực tiếp để tìm hiểu thêm về sản phẩm (trên sản phẩm hiện tại của bạn hoặc một nguyên mẫu cho những ý tưởng mới).

Ví dụ:

Tiếp theo ví dụ “mức 5” của thói quen số 4, chúng tôi đã sử dụng UserTesting.com để thuê 5 người dùng, với 4 nhiệm vụ được dự định để họ chơi trò chơi thông qua các giai đoạn đầu.

2 ngày sau chúng tôi đã có 5 video video 1 giờ sử dụng trò chơi.

Chúng tôi tìm thấy 2 vấn đề:

  • Một vấn đề về khả năng sử dụng thông thường: khi mà hướng dẫn các bước không rõ ràng, vì vậy chúng tôi đã cố gắng thay hướng dẫn chơi rõ ràng hơn
  • Thứ hai đòi hỏi một số ngữ cảnh phù hợp: Trò chơi có một “cơ chế năng lượng” đặc biệt, đã cạn dần theo thời gian và người chơi phải đợi cho đến khi nó được sạc lại để tiếp tục chơi (hoặc trả tiền để có thêm năng lượng). Đây là một cơ chế rất phù hợp với các trò chơi online, khá giống với trò chơi Candy Crash là một ví dụ thiết thực nhất.

Chúng tôi phát hiện ra rằng năng lượng này đã cạn kiệt trước khi đạt đến cấp độ 5. Vì vậy, giả thuyết mới chúng tôi tạo ra là: “Nếu người chơi có thể tiếp tục trò chơi của mình mà không có những hạn chế về năng lượng đến cấp 5, nhiều người sẽ đạt được và cải thiện mức độ duy trì tổng thể”.

Vì vậy, quay trở lại mục tiêu ban đầu, chúng tôi đã có thêm thông tin về câu hỏi chúng tôi có trong tuần đó và nó cũng cung cấp một mục tiêu rõ ràng cho tuần sau mà chúng tôi có thể dễ dàng kiểm tra A / B.

Tại sao lại là thứ 2

Đối với tôi, bắt đầu tuần mới với những hoạt động quan trọng cảm giác như mọi thứ đều trở nên cấp bách, nếu không giải quyết sẽ giết chết những điều quan trọng. Và nó cũng cho bạn một cái nhìn về những gì cần tập trung và làm rõ các bước tiếp theo cần làm trong tuần: nếu bạn quản lý một cuộc thử nghiệm mỗi tuần, chắc chắn bạn sẽ làm tốt hơn hầu hết các công ty khác.

Thói quen hàng tuần của bạn là gì? Tôi nên thêm gì vào danh sách?

Tôi hy vọng điều này sẽ giúp người khác xây dựng sản phẩm tốt hơn

Nguồn: blog.topdev.vn via hackernoon

Bí kiếp học front-end của Grab – Phần 3

PHẦN 1 – PHẦN 2

Là phần cuối cùng trong series về bí kiếp học front end của Grab, chúng ta hãy cùng tìm hiểu thêm về những tools được dùng trong giai đoạn cuối của quá trình phát triển front-end cho một web app

Types — Flow

Static typing có rất nhiều lợi ích khi viết app. Nó giúp ta phát hiện ra những lỗi thường gặp từ rất sớm. Types cũng là một hình thức lưu trữ code và nó ảnh hưởng đến tính thẩm mỹ cũng như rất dễ đọc. Khi code base của bạn bắt đầu lớn dần, thì nhờ vào type mà việc sắp xếp lại cũng trở nên dễ thở hơn rất nhiều. Mặt khác, các thành viên mới cũng sẽ nhanh chóng làm quen và bắt kịp với tiến độ nhờ vào việc code được viết gọn gàn và dễ hiểu.

Gần đây, tôi phải sửa lại vài lỗi trong một code base mà cả tháng trời chưa đụng tới. Rất may là nhờ vào types mà tôi không mất quá nhiều thơi kiếm lỗi và sửa chúng.

Hiện nay có 2 ứng viên nổi bật nhất trong static types cho JavaScript là Flow (bởi Facebook) và TypeScript (của Microsoft). Tại Grab, chúng tôi chọn Flow vì nó dễ học hơn so với TypeScript cũng như ít đòi hỏi việc phải thay đổi trong code base. Mặt khác do là đứa con của Facebook, Flow có khả năng tương thích rất tốt với React ecosystem.

Tuy vậy, TypeScript cũng không hề thua kém và việc chuyển giao giữa chúng cũng không tốt mấy công sức do cú pháp cũng khá giống nhau nên việc thay đổi vẫn có thể xảy ra.

Thời gian ước tính: 1 ngày – Flow rất là đơn giản và có thể xem như là một phần mở rộng thêm của JavaScript. Hãy thử cho nó vào project của bạn và chứng kiến sức mạnh kì diệu của Flow.

Links Học

Lựa chọn thay thế

Xem ngay các tin đăng tuyển dụng Front-end lương cao trên TopDev

Build System — webpack

Phần này sẽ được giữ ngắn bởi quá trình setting up webpack đôi khi sẽ rất nhàm chán và dễ khiến developer bỏ cuộc bởi phải học quá nhiều thứ mới khi bước vào thế giới của front end developer. Nói ngắn gọn, webpack  là một module bundler với khả năng compile một front end project và các dependencies của nó thành một bundle thống nhất để user sử dụng. Thường thì project đã có sẵn webpack configuration set up và developer cũng rất ít khi chỉnh sửa nó. Tuy vậy bạn vẫn sẽ cần phải có kiến thức về webpack.

Chúng tôi thấy webpack walkthrough của SurviveJS là một nguồn học cực kì tuyệt vời cho những bạn muốn biết về webpack.

Thời gian ước tính: 2 ngày (không bắt buộc)

Links tham khảo

Tham khảo khác

Package Management — Yarn

Nếu bạn thử vào xem node_modules directory, hẳn bạn sẽ nhận ra ngay nỗi kinh hoàng khi nhìn vào số lượng đồ số của các directories. Từng babel plugin, lodash function đều là một package riêng rẽ. Và khi bạn cùng lúc phải chạy nhiều project thì số lượng tăng một cách chóng mặt. Như vậy mỗi lần bạn chạy  npm install trong một project mới, thì những packages này sẽ được download lặp đi lặp lại dù bạn đã có sẵn trong các project khác trong máy tính của mình.

Mặt khác khi sài npm install thì việc cài đặt rất dễ bị lỗi do các bản update thường chưa những thay đổi khiến cho việc không tương thích lẫn nhau xuất hiện hoặc đơn giản là bị trùng lập các file.  

Yarn giúp giải quyết triệt để những vấn đề trên với yarn.lock file, giúp bảo đảm mỗi lần cái đặt đều có file structure giống nhau trong node_modules giữa các máy tính. Yarn cũng tối ưu hóa một global cache directory nhờ đó mà không cần phải download lại những packages bạn đã có. Hơn nữa, nó còn cho phép bạn cài đặt offline luôn.

Một số các Yarn commands nổi bật nhất bạn có thể vào xem tại đây.  Thật sự thì chúng đều tựa như  npm. Một trong những Yarn command mà chúng tôi thích nhất là  yarn upgrade-interactive giúp cho việc dependencies sẽ tự động được update cho các JavaScript project.

Thời gian ước tính: 2 giờ

Links tham khảo

Continuous Integration

Tại Grab, chúng tôi dùng Travis CI cho continuous integration (CI) pipeline. Travis là một CI rất nổi tiếng trên Github cũng như build matrix của nó có khá nhiều tính năng vô cùng hữu ích khi bạn phải quản lí nhiều dự án khác nhau như Grab. Chúng tôi cài đặt để Travis thực hiện những nhiệm vụ sau:

  • Chạy lintingcho project.
  • Chạy unit tests cho project.
  • Nếu qua được bài tests:
  • Test coverage được tạo bởi Jest sẽ được uploaded lên Codecov.
  • Tạo một production bundle với webpack vào trong một build directory.
  • tar  build directory với  <hash>.tarvà upload nó lên một S3 bucket lưu trữ toàn bộ các build của chúng tôi.
  • Post một notification đến Slack để thông báo về kết quả của Trais build.

Links tham khảo

Tham khảo khác

Hosting — Amazon S3

Thông thường thì web sau khi nhận được request cho một webpage sẽ render nội dung trên server và return một HTML page với nội dung theo yêu cầu của user. Đây còn gọi là server-side rendering. Như đã nói ở phần Single-page Apps, web applications thời nay không đụng tới server-side rendering nữa mà giờ đây ta có thể dùng web server để cung cấp static asset files. Nginx và Apache là 2 lựa chọn khá tốt bởi nó không đòi ta phải bỏ công sức tìm hiểu cũng như setup quá nhiều. Tuy nhiên chúng ta cần phải biết là web server sẽ được điều chỉnh sao cho mọi request route sẽ được tập trung vào một điểm để client-side route có thể tiếp nhận. Dòng chảy cho front end routing sẽ như sau:

  1. Web server nhận một HTTP request cho một route nào đó, như /users/john.
  2. Khi đó server sẽ cung cấp index.html từ static assets directory.
  3.  index.html sẽ bao gồm scripts với khả năng load up một JavaScript framework/library với client-side routing.
  4. The client-side routing library sẽ đọc route, và thông báo với MVC framework về nó.
  5. MVC JavaScript framework renders ra view dựa theo thông tin của route đưa đến , thường là sau khi nó thu data từ một API.

Chúng tôi chọn Amazon Simple Storage Service (S3)  là bởi vì nó có thể host cũng như hoạt động như một CDN  cho nội dung của static website. Thật sự mà nói, S3 là một phương pháp vừa chắc ăn mà phù hợp với túi tiền của chúng tôi.

Một project mà chúng tôi có sử dụng S3 là Hub. Ngoài ra chúng tôi cũng dùng nó để tạo các  .tar files từ các Travis build.

Links tham khảo

Lựa chọn thay thế

Deployment

Bước cuối cùng chính là gửi sản phẩm của chúng ta đến tới user hay nói cách khác là deploy. Chúng tôi sử dụng Ansible Tower, một phần mềm tự động hóa cực kì mạnh mẽ giúp việc deploy build trở nên vô cùng dễ dàng.

Những đã nếu ra trong các phần trước, toàn bộ những build thành công đều được upload lên S3 bucket. Khi các bản update, patch được tung ra thì bản note lại những thay đổi cũng sẽ tự động được cập nhận và gửi tới cho user. Khi một thay đổi được đưa ra, Grab sẽ gửi command tag cho commit tới code hosting. Lúc đó Travis sẽ chạy các bước CI trên commit đó và upload một tar file (ví dụ như  1.0.1.tar) với phiên bản phù hợp với S3 bucket.

Trong Tower, chúng ta chỉ cần đơn giản là đưa ra tên của .tar  mà ta muốn deploy nó tới hosting bucket và Tower sẽ làm hết những công đoạn sau:

  • Download  .tar file đó từ S3 bucket
  • Trích xuất nội dung và điều chỉnh file tùy theo yêu cầu
  • upload nội dung tới hosting bucket
  • Gửi tin nhắn báo deploy thành công tới Slack

Tất cả quá trình trên đều diễn ra trong vòng 30 giây, có thể nói là tower đã giúp mọi thứ trở nên dễ thở hơn rất nhiều.

Links tham khảo

Mọi thứ chỉ mới bắt đầu thôi

Chúc mừng bạn đã theo dõi đến giờ này! Thật sự mà nói, phát triển Front end thời nay rất khó nhưng nó cũng trở nên thú vị hơn. Những gì mà chúng tôi vừa viết ra sẽ giúp các developer non trẻ nhanh chóng nắm bắt và theo kịp tiến độ công việc tại Grab. Vẫn còn rất nhiều thứ để học nhưng quan trọng nhất vẫn phải là việc bạn đã có một lượng kiến thức cơ bản vững chắc cái đã. Front end web developer roadmap sẽ giúp bạn hiểu rõ hơn cũng như có thêm nhiều lựa chọn thay thế trong việc chọn học các ngôn ngữ lập trình.

Chúng tôi hi vọng là sau 3 phần của bài viết này sẽ giúp các bạn hiểu rõ hơn về những công nghệ trong front end mà Grab đang sử dụng cũng như có được hướng đi riêng cho mình.

Nguồn: topdev.vn via Medium

Tìm việc IT lương cao, đãi ngộ tốt trên TopDev ngay!

“Luật 5 giây” giúp Steve Jobs thách thức mọi giới hạn sáng tạo

Bạn có biết Steve Jobs là một người cực kì khó tính và dữ tợn? Ông ấy chẳng quan tâm đến gì ngoài hiệu quả công việc. Và “luật 5 giây” khó nhằn của ông hóa ra lại là một bí quyết để giúp nhân viên của mình thách thức mọi giới hạn của sự sáng tạo.

Thomas Koulopoulos, tác giả bài viết này là một nhà báo, một tác giả nổi tiếng và là một nhà lãnh đạo, ông đã có dịp trò chuyện với Steve Wozniak, đồng sáng lập Apple, để hiểu “luật 5 giây” tài tình của Steve Jobs.

Tôi buộc phải thú nhận mình là một kẻ “máu lạnh” đối với đồng nghiệp của mình. Tôi sẵn sàng đối mặt với những thách thức dường như không thể bước qua và mong đợi những người cộng sự của mình sẽ làm điều tương tự. Lớn lên cùng những câu nói khắc cốt ghi tâm của cha tôi, “Lửa thử vàng, gian nan thử sức”. Vì lẽ đó, tôi chẳng mấy ngạc nhiên khi nhìn thấy những người lãnh đạo luôn cố gắng hết sức ở vai trò của mình.

Tôi thật sự rất may mắn vì đã nhiều lần được gặp những người như vậy, nhưng vẫn không sao có dịp gặp Steve Jobs. Dù vậy, tôi đã có lần trò chuyện cùng Steve Wozniak, đồng sáng lập của Apple.

Là một người sử dụng Apple từ những ngày đầu tiên của dòng máy tính Macintosh, tôi phải thừa nhận rằng được gặp Woz là cơ hội ngàn năm có một. Trong buổi họp đầu tiên, chúng tôi nói rất nhiều, từ thước lô-ga (bạn biết đấy, loại thước mà NASA sử dụng trong Apollo 13 để giải quyết những vấn đề toán học rắc rối khiến máy tính bị chậm!), đến chuyện chiếc máy tính đầu tiên của Texas Instruments và cả quan điểm của ông ấy về an ninh mạng.

Rồi chúng tôi cùng nhau lật lại từng trang lịch sử của máy tính, bàn về những năm tháng “chào đời” của Apple, sự phấn khích tột độ khi tạo nên những bước đột phá và lý do tại sao bo mạch được bố trí hợp lí lại được xem là một kiệt tác nghệ thuật.

Cuối cùng thì cuộc trò chuyện cũng ngã hướng về Steve Jobs. Vào thời điểm Jobs công khai rằng, mình cần phải giải quyết một số vấn đề về sức khoẻ, về căn bệnh cuối cùng đã tước đi mạng sống của ông.

Tôi không hiểu mấy về bệnh tình nghiêm trọng của Jobs, tuy vậy, tôi phải hết sức cẩn trọng với ba điều: Bối cảnh của cuộc trò chuyện, những lùm xùm xung quanh mối quan hệ giữa Jobs và Woz và cuối cùng là vai trò hiện tại của Woz. Vì thế, tôi chỉ vô tình đả động nhẹ đến những vấn đề này. Nhưng quả thật tôi rất tò mò về danh tiếng của Jobs, vì ông được xem như một kẻ máu lạnh chẳng quan tâm đến bất cứ điều gì ngoài hiệu suất công việc đạt chuẩn cao nhất. Tôi luôn tự hỏi làm sao Jobs có thể quản lí tốt những nhân viên của mình khi tính cách cá nhân của ông ấy dường như rất “máu lạnh” như thế.

“Ai cũng đều thích được khen ngợi, nhưng sự thách thức sẽ giúp ta cảm thấy hài lòng với những thành quả của mình”.

Đáng ngạc nhiên thay, Woz vô cùng thẳng thắn trước những câu hỏi của tôi. Vì vậy, tôi cũng khá thẳng thắn hỏi rằng, liệu Jobs có phải là một người rất khó để làm việc chung hay không. Câu trả lời tôi nhận được từ Woz khiến tôi nghĩ ngay đến cố vấn Peter Drucker của mình. Một lần tôi đã hỏi ông ấy một câu tương tự, và ông ấy xem rằng đó là câu hỏi hết sức nực cười. “Này, chẳng ai lại đi hỏi câu đó cả” là câu trả lời của ông ấy. Woz cũng đã trả lời tương tự, và sau đó chia sẻ câu chuyện về Steve Jobs trong những ngày đầu tại Apple.

Woz kể rằng, Steve Jobs hay có thói quen xông vào các cuộc họp. Ông ấy lướt một vòng quanh căn phòng, xem xét trực tiếp vấn đề đang được bàn bạc để tìm phương án giải quyết, và không cần đến năm giây để thông báo như sét đánh ngang tai: “Mọi người có thể làm tốt hơn nữa đấy.” Và ngay sau đó mất hút qua cánh cửa phòng. Giọng điệu của ông ta chẳng hề biểu lộ nét thất vọng hay kiêu ngạo gì cả, chỉ vỏn vẹn một câu nói, “Chưa ổn đâu!”

Mệt mỏi với ông già lắm chiêu này, nhỉ? Phản ứng đầu tiên của Woz khi nghe thấy những câu như thế là: “Ông biết cái quái gì mà nói ổn hay không chứ? Này nhé, chúng tôi đã ngồi vắt óc bàn bạc từ sáng đến giờ, đó là điều tốt nhất có thể rồi!”.

Đó quả là một điểm mấu chốt khi Jobs nói rằng, bạn có thể làm tốt hơn thế, và bạn sẽ muốn biết “tốt hơn” là như thế nào.

Khi nghe Woz kể, tôi chợt nhớ đến những đứa con của mình lúc nhỏ, lúc đó tôi đang dạy chúng về cách giải quyết những vấn đề sáng tạo có tên là “Cực điểm Sáng tạo”. Đây là một chương trình “khó nuốt” đối với trẻ con nói chung, vì chúng sẽ phải tự giải quyết những vấn đề phức tạp mà không hề có sự hướng dẫn hay giúp đỡ từ bố mẹ.

Câu hỏi đặt ra ở đây là, cần gì phải có một người hướng dẫn nếu họ không thể giúp bạn tìm ra giải pháp? Đúng vậy, tôi thật sự rất ngạc nhiên khi vai trò chủ đạo của tôi chỉ là khuyến khích chúng tìm ra giải pháp tối ưu hơn thế. Bằng cách đó, chúng sẽ tìm ra cách để phá vỡ mọi giới hạn về sức sáng tạo. Kết quả thật đáng bất ngờ khi chúng hoàn toàn có đủ bản lĩnh để làm tốt hơn những gì chúng đang làm.

Giả sử như thế này, với tư cách là một người lớn đang huấn luyện những đứa trẻ, bạn sẽ có một lợi thế tiềm ẩn, vì chúng sẽ tin ngay khi bạn nói rằng, chúng có thể làm tốt hơn thế. Và đương nhiên, đó là vai trò thực sự của người lãnh đạo. Xét trên nhiều phương diện, có lẽ Jobs đã sai. Ông có những khí chất khiến những hành động và lời nói của mình có sức nặng hơn bao giờ hết. Với tư cách là những nhà lãnh đạo, chúng ta cần phải thiết lập một cơ chế hoạt động cho tổ chức, cho nhân viên, và cho cả chính ta.

Khen ngợi nhân viên cấp dưới khi họ làm tốt là một điều hiển nhiên, vì điều đó sẽ tiếp thêm động lực cho họ. Nhưng trước hết phải mang đến cho họ những thử thách. Ai cũng đều thích được khen ngợi, nhưng sự thách thức sẽ giúp ta cảm thấy hài lòng với những thành quả của mình.

Đừng trở thành kẻ ngủ quên trong chiến thắng. Drucker luôn luôn nhắc nhở tôi rằng vai trò mấu chốt của người lãnh đạo là thử thách mọi người. Ông ấy cảm thấy rằng, đức tính này là giá trị cốt lõi nhất của các nhà lãnh đạo và quản lí. Thông qua những thử thách ấy, chúng ta có thể chứng minh với những người tin tưởng sát cánh bên chúng ta rằng, khả năng của họ đủ để bứt phá mọi giới hạn.

Nhưng hãy nhớ, đừng bao giờ đặt ra những thử thách phi thực tế và không hợp lí. Bạn là một nhà lãnh đạo, không phải một kẻ sát nhân!

Không còn điều gì có thể ý nghĩa hơn khi bạn tạo cơ hội cho một người để họ cảm nhận được rằng, họ thật sự mạnh mẽ, thông minh và kiên cường hơn họ nghĩ. Một người trao cho bạn những trải nghiệm khó quên ấy sẽ là người bạn đi theo đến tận cùng trái đất, dù họ có “máu lạnh” đến mức nào!

Nguồn: brandsvietnam.com

Bí kíp học Front-end của Grab (Phần 2)

Nối tiếp PHẦN 1, chúng ta sẽ tiếp tục đi sâu hơn những tool chúng ta cần biết để làm được một React project một cách dễ dàng nhất.

Quản lí State  — Flux/Redux

Khi app của bạn bắt đầu phát triển và bành trướng, bạn có thể sẽ thấy cấu trúc của app bắt đầu trở nên quá lộn xộn. Cho dù Components trong React vẫn hoạt động tốt nhưng cách làm lại khá “thô”. Bời dù sao đi nữa, React vẫn chỉ là view layer, nó không h liên quan hay ảnh hưởng lên cấu trúc của các layer khác trong app, như model và controller. Để giải quyết vấn đề trên, Facebook đã tạo ra Flux, một kiến trúc app bổ trợ cho React bằng cách dùng một dòng data không hướng (unidirectional). Nói tóm gọn thì Flux có những đặc điểm sau:

  • Dòng data không hướng (Unidirectional data flow) – Giúp cho theo dõi app hoạt động dễ dàng vì có thể check update tùy ý.
  • Hoạt động độc lập – Mỗi phần trông kết cấu của Flux đều có chức năng rõ ràng và hoạt động độc lập.
  • Phù hợp với lập trình declarative – updates được truyền thẳng tới view mà không cần phải chuyển đổi giữa các state.

Xem thêm các việc làm front end lương cao cho bạn

Vì Flux không phải là framework nên các developers đã thử nhiều cách thức khác nhau để lợi dụng những đặc điểm ở trên của Flux. Nhờ đó mà Redux ra đời. Redux kết hợp ý tưởng từ Flux, Command pattern và Elm architecture cùng với state management library mà các developer thường dùng cho React:

  • App state được miêu tả bởi một JavaScript object đơn (POJO).
  • Dispatch một action (cũng là POJO) để chỉnh sửa state.
  • Reducer là một pure function với khả năng nhận một state vào và tạo ra một state mới.

Nghe có vẻ đơn giản nhưng thật sự chúng rất mạnh mẽ bởi cho phép apps:

  • render state trên server và bootup trên client
  • Trace, log và backtrack những thay đổi trong app
  • Sử dụng undo/redo function dễ dàng

Cha đẻ của Redux, Dan Abramov, bỏ nhiều công sức để viết tài liệu hướng dẫn đầy chi tiết cho Redux, ngoài ra còn có cả video chỉ cách sử dụng nó với hai level khác nhau là cơ bản và nâng cao. Chúng đều là những nguồn học Redux vô cùng tuyệt vời mà bạn không nên bỏ qua.  

Kết hợp view và state

Tuy Redux không bắt buộc phải dùng cùng với React, nhưng bạn nên làm như vậy bởi chúng giúp cải thiện cho nhau rất nhiều. Cả React và Redux đều có những điểm chung như:

  • Có những chức năng giống nhau – React tạo ra views (pure functions) trong khi Redux tạo ra pure reducers (cũng là pure functions)
  • Dễ đọc dễ hiểu – Bạn có khả năng kiểm soát và khi có vấn đề thì việc xác định chúng cũng dễ dàng. Với kinh nghiệm của chúng tôi, debug luôn khỏe hơn với React và Redux. Bởi dòng data không hướng (unidirectional data flow) nên việc trace hướng đi của data rất dễ cũng như xác định được nhanh chóng layer nào có lỗi.
  • Cấu trúc layer (tầng) – từng layer trong cấu trúc của app/ Flux đều được xem là pure function và có chức năng rõ ràng. Nhờ đó mà việc test các layer này cũng khá là nhẹ nhàng.
  • Trải nghiệm phát triển – Rất nhiều công sức bỏ ra để tạo ra những tools giúp debug cũng như kiểm tra và theo dõi app trong quá trình phát triển như Redux DevTools.

App của bạn sẽ phải đối mặt với những vấn đề từ async calls như API requests. redux-thunk và redux-saga được tạo ra để giải quyết những vấn đề này. Tuy vậy bạn sẽ cần bỏ nhiều thời gian để tìm hiểu về nó nên bạn chỉ nên đụng tới nó khi cần thiết thôi.

react-redux chính là kết hợp React giữa redux và rất dễ học.

Khoảng thời gian để hoàn thành: 4 ngày. Các khóa học sẽ khó xơi hơn nhưng nó hoàn toàn xứng đáng với những gì bạn bỏ ra. Sau khi đã hiểu về  Redux thì bạn đã có thể áp dụng nó ngay vào một số React project. Liệu Redux có giải quyết được những vấn đề liên quan tới quản lí state mà bạn gặp phải trước đó.

Links học:

Lựa chọn thay thế

Coding với Style — CSS Modules

CSS (Cascading Style Sheets) là những tiêu chí mô tả cách hiển thị của HTML. Và viết CSS tốt luôn không phải là chuyện dễ dàng. Thường mất vài năm kinh nghiệm gian khổ mới có thể viết và quản lí CSS ở mức độ cao. CSS, với namespace toàn cầu, vốn được thiết kế cho web documents, chứ không dành cho web app với kiến trúc component. Do đó mà các front end developers lão làng đã tạo ra nhiều phương thức khác nhau để hướng dẫn người mới cách viết CSS dành cho những project khủng như SMACSS, BEM, SUIT CSS, etc.

Có lẽ bạn cũng đã nhận ra, front end ecosystem thật sự bão hòa với tools, và không có gì ngạc nhiên khi tools được tạo ra để giải quyết vấn đề của CSS khi dùng trong những project lớn. Nói cách khác là mỗi người có cách dùng CSS khác nhau và trong thời điểm hiện tại vẫn chưa có cách chính thức để viết CSS trong JS, hi vọng trong tương lai sẽ có cải thiện giống như sự ra đời của Redux. Còn hiện tại thì chúng ta vẫn phải dựa vào CSS Modules. CSS modules là phiên bản nâng cao của CSS nhằm khác phục vấn đề về namespace; nó cho phép bạn viết theo style của mình và encapsulated cho component. Đây là tính năng thông qua sử dụng tool CSS modules, giúp cho team phát triển có thể thoải mái làm modular và reuse CSS mà không phải lo bị xung đột hoặc override các phần khác của app. Tuy vậy, CSS modules vẫn sẽ được compiled thành globally-namespaced CSS để trình duyệt web có thể nhận diện được nên rất quan trọng việc hiểu rõ cách thức hoạt động của CSS.  

Nếu bạn hoàn toàn là tay mơ với CSS thì khóa học online HTML & CSS course của Codecademy sẽ là điểm khỏi đầu lí tưởng. Tiếp theo bạn cần đọc Sass preprocessor, một bài viết nâng cao về ngôn ngữ CSS.  

Khoảng thời gian để hoàn thành: 3 ngày. Hãy thử nghiệm nhiều style khác nhau như SMACSS/BEM hoặc CSS modules.

Links học

Lựa chọn thay thế

Bảo trì

Chúng ta dành nhiều thời gian để Code hơn là viết chúng. Điều đó càng đúng đối với Grab, khi mà qui mô team rất lớn lại có nhiều project khác nhau. Chúng tôi rất đề cao khả năng dễ đọc trong code, dễ bảo trì cũng như ổn định. Để đạt được những mục tiêu trên thì ta sẽ cần có vài cách sau: “Test mở rộng”, “style code nhất quán” và “type checking”

Testing — Jest + Enzyme

Jest là một testing library của Facebook với mục tiêu đơn giản hóa quá trình testing. Với các project của Facebook, Jest giúp trải nghiệm phát triển trở nên dễ thở hơn rất nhiều. Các bài test được chạy đồng loạt nhằm giúp rút ngắn thời gian. Trong watch mode, được đặt default, chỉ có tests cho những files bị thay đổi là được phép chạy. Một tính năng mà chúng tôi rất thích là “Snapshot Testing”. Jest có thể lưu trữ output của React component và Redux state dưới dạng files nên bạn không phải mất công lo những việc đó. Jest còn có tính năng như built-in mocking, assertion và test coverage. Có thể nói là một “soái ca” lo hết mọi việc.

React có tích hợp sẵn một số testing utilities, nhưng Enzyme bởi Airbnb giúp generate, assert, manipulate và traverse React components’ output dễ dàng hơn với API tương tự như trong jQuery. Vì thế mà chúng tôi khuyến khích bạn dùng Enzyme để test React components.

Jest và Enzyme giúp front end test trở nên nhẹ nhàng và “vui vẻ” hơn. Nó cũng giúp cho các developer bỏ công ra test kĩ lưỡng hơn. Mặt khác, React components và Redux actions/reducers cũng đã khá là dễ cho quá trình test bởi vai trò rõ ràng cũng như interface dễ nhìn. Với React components, chúng ta có thể test  props, khi đó DOM sẽ được render, và callbacks sẽ cho phép hiển thị kết quả của user interaction. Với Redux reducers, chúng ta có thể test bằng state và action, với kết quả là một  state mới được tạo ra.

Các tài liệu về Jest và Enzyme đều khá là chi tiết nên bạn cứ thoải mái tìm hiểu.

Khoảng thời gian để hoàn thành: 2-3 ngày. Hãy thử dùng Jest + Enzyme tests cho các React + Redux app của bạn!

Links học

Thay thế

Linting JavaScript — ESLint

Linter là một tool chuyên về phân tích code và xác định lỗi trong chúng cũng như bugs/runtime errors. Ngoài ra, Linter còn giúp coding style được nhất quán. Thời gian cũng được rút ngắn khi Pull request reviews với reviewer không phải mất công ghi comments trên coding style. ESLint là một tool để lint cho JavaScript code với khả năng mở rộng và tính tùy chỉnh. Các team đều có những luật về lint của riêng mình. Tại Grab, chúng tôi dùng Airbnb’s eslint-config-airbnb preset, đã được tinh chỉnh với style coding khá chất lượng trong Airbnb JavaScript style guide.

ESLint thật sự rất đơn giản, cứ như là chỉnh sửa một configuration file vậy. Bãn sẽ không phải học thêm gì nhiều ngoài mấy cái luật do mình đưa ra. Nhưng hãy lưu ý một số lỗi và google style nào tốt nhất.

Khoảng thời gian để hoàn thành: ½ ngày – Chả có gì nhiều phải học cứ cài ESLint vào project của bạn và quất thôi.

Links học

Lựa chọn thay thế

Nguồn: topdev.vn via Medium

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

“Chuyện thường ở huyện” tại ZALORA

Bạn đã bao giờ thử trải nghiệm 1 ngày làm việc tại ZALORA – nơi được xem là môi trường làm việc lý tưởng của dân công nghệ? Có những điều tưởng chừng rất đặc biệt tại nơi khác nhưng với ZALORA thì đó lại là chuyện thường. Liệu có hấp dẫn thật vậy không? Phải khám phá mới biết!

Văn phòng mới đúng chuẩn kiểu “Silicon Valley”

ZALORA sở hữu văn phòng đặc biệt mô phỏng theo không gian mở của các công ty ở Silicon Valley, nơi trung tâm công nghệ của thế giới, nơi tồn tại những cái tên công nghệ lớn như Google, Facebook, Microsoft, Intel, Uber, Deloitte, PwC… và một loạt các công ty có tên tuổi lẫy lừng khác.

Dạng thiết kế văn phòng mở này chứa đựng nhiều ưu điểm lớn mà ngày nay không chỉ riêng ZALORA mà các công ty công nghệ khác cũng đang dần ưa chuộng theo xu hướng này. Điều ưu điểm đầu tiên có thể nói đến chính là việc cải thiện giao tiếp cho mọi người trong công ty bởi sự gắn kết và thống nhất cho một tổ chức. Theo trích dẫn lời ông Steven Jobs, nhà sáng lập Apple: “Ý tưởng không đến từ phòng họp mà chúng đến từ các cuộc gặp trên hành lang.” Đó là lý do tại sao không gian mở được xem là môi trường làm việc lý tưởng để sáng tạo.

Lợi thế nổi bật tiếp theo ở đây chính là sự đẩy mạnh hiệu quả trong công việc, chưa kể đến một phần còn tiết kiệm được chi phí mở văn phòng với các tiện ích đầy đủ được dùng chung. Không dừng lại ở việc nâng cao chất lượng hiệu quả, thiết kế này còn mang lại không khí tích cực cho môi trường làm việc, giúp cho các nhân viên tại ZALORA cảm thấy thoải mái, hạnh phúc hơn.

Trải nghiệm tool xịn và học hỏi toàn công nghệ mới

Các anh chàng Engineer nhà ZALORA phải nói lúc nào cũng thích thú và hăng say trong công việc. Lý do vì sao ư? Bởi vì mỗi ngày code là mỗi ngày nâng cao tay nghề. Tại ZALORA, các Engineer chẳng bao giờ sợ thiệt thòi vì họ được học hỏi rất nhiều thứ, từ Test Driven Development cho tới việc optimize những chi tiết nhỏ như HTTP Header, kế đó là giao thức HTTP/2. Thỉnh thoảng các anh làm front-end bỗng dưng “không hiểu vì sao chán” thì có thể đổi gió bay qua gõ code Golang cũng rất thú vị.

Làm việc tại ZALORA thì phải nhắc đến các tool xịn cực kì hữu ích để bổ trợ công việc. Có thể nói đến như Slack, AWS stack, còn Deploy code lên live chỉ cần gõ 1 dòng lệnh trên slack. Có phải là quá tuyệt vời không? Chưa nói đến việc hệ thống còn tự động integration test và soi code, quả nhiên là vi diệu. Ấy thế mà mới gia nhập còn được ZALORA cấp cho cả Macbook Pro cực xịn, bước ra đường là sang chảnh, vào công ty là thấy ai ai cũng mang phong thái chuyên nghiệp theo kiểu “tây tây”. Hỏi sao mà dev nào không mê cho được?

Làm việc hiệu quả… xả stress cũng hiệu quả

Mô hình văn phòng mới tại ZALORA còn được trang các thiết bị công nghệ tiên tiến nhất. Mọi người sau khi làm việc còn được giải trí với các tools xả stress vô cùng thú vị như Pingpong, PS4, Foosball, Billiards v.v… Đó cũng là lý do mà các anh chàng dev nhà ZA rất ít khi kêu ca, trái lại họ còn cảm thấy rất thích thú sau mỗi giờ làm việc khi được xả stress hết mình.

Nhưng nhiêu đó vẫn chưa sao kể hết được những đãi ngộ rất riêng mà ZALORA ưu ái dành cho các Engineer của họ. Gia nhập ZALORA là cả một quá trình cho bạn tiến lên và phấn đấu hoàn thiện tay nghề, chưa kể các kỹ năng khác của bạn từ đó cũng dần tiến bộ, điển hình như tiếng Anh, các Engineer sẽ được tham gia khóa học nâng cao và được ZALORA hỗ trợ đến…70% chi phí. Chỉ nhiêu đó thôi đã đủ thấy muốn vào ZALORA làm liền trong hôm nay.

Với các chàng dev mong muốn có thân hình 6 múi đúng chuẩn hay các cô nàng dev cá tính muốn sở hữu dáng bốc lửa thì hãy đến với gym. Thẻ gym tại đây luôn sẵn sàng cho bạn tập luyện, vừa có sức khỏe tốt, vừa là cách xả stress hữu hiệu nếu muốn quên đi các căng thẳng thường xuyên trong cuộc sống.

Đồng nghiệp thân thiện, sếp tâm lý

Tại ZALORA, bạn có thể cùng ngồi chung với team để hỗ trợ, học hỏi lẫn nhau vì mọi người nơi đây luôn thân thiện, nhiệt tình sẵn sàng giúp đỡ. Hoặc bạn cũng có thể ngồi riêng một góc miễn sao bạn cảm thấy phù hợp, nếu gặp khó khăn bạn có thể chủ động xin ý kiến của sếp. Có thể đôi lúc bạn sẽ gặp một vài vấn đề gì đó trong công việc hay kể cả cuộc sống, thay vì cứ giữ khư khư thì hãy tìm đến sếp chia sẻ thử. Biết đâu họ là người có thể cho bạn lời gợi ý và hướng giải quyết tốt nhất thì sao. Ở ZALORA, cứ mạnh dạn chia sẻ.

Để có được những trải nghiệm mua sắm online tốt nhất cho khách hàng thì sự phối hợp chặt chẽ, khéo léo giữa đội ngũ Engineer siêu giỏi và vị sếp lý tưởng chính là cái “keyword” phát triển tại ZALORA. Chưa kể sếp và nhân viên đều có thể vui chơi giải trí thoải mái với nhau sau giờ làm việc. Bạn đã từng thấy vị sếp nào mà thỉnh thoảng chiều chiều hay cùng chơi foosball với anh em hay chưa? Tại ZALORA thì có đó.

Qua những “chuyện thường” ở trên cũng có thể lý giải được phần nào tại sao ZALORA lại có sức hút đối với các Developer đến thế. Nếu bạn cũng đang mong muốn được trải nghiệm môi trường tuyệt vời như tại ZALORA thì đừng chần chờ gì mà không khám phá ngay cơ hội việc làm tại đây

Đếm 123, bạn đã sẵn sàng trở thành Software Engineer (PHP, Java, Python) tại ZALORA hay chưa?

Bí quyết chọn laptop để lập trình

Việc chọn một cái laptop phù hợp cho lập trình đôi khi là một việc rất khó khăn.

Bởi có quá nhiều lựa chọn khác nhau khiến bạn rối cả trí mỗi khi vào google search về chúng. Không những thế mỗi nhãn hiệu điều có những phiên bản khác nhau với điểm mạnh yếu tùy theo nhu cầu sử dụng của từng người.

Có một sự thật là bạn có thể code hầu như trên mọi loại máy laptop hiện nay. Tuy nhiên, năng suất của bạn sẽ tăng đáng kể nếu dùng laptop đúng theo nhu cầu của mình.

Có nhiều lĩnh vực phát triển, tools và ngôn ngữ khác nhau tùy theo ngành học của bạn. Thế nên không thể nào có một cái máy tính toàn năng, phù hợp với mọi yêu cầu mà giá thành lại rẻ được.

Tôi viết bài này là để dành cho các bạn web developer và chỉ có laptop để làm lập trình.

Sau đây là những lưu ý mà bạn cần phải nghĩ tới trước khi ra quyết định mua máy.

Tính di động

Laptop có đủ thể loại với kích cỡ hình dáng khác nhau. Bạn sẽ cần phải xác định rõ bạn muốn tính di động của laptop đến mức nào.

Nếu không phải mang laptop đi nhiều thì bạn nên chọn cỡ 15-inch. Những loại này thì thường được trang bị ngon lành hơn cũng như thực hiện được nhiều task khác nhau cùng một lúc.

Thế nhưng nếu bạn phải di chuyển rất nhiều thì hãy nên dừng ở mức 13~14 inch thôi. Chúng vừa nhẹ mà lại khá tiết kiệm pin.

Trừ khi bạn bắt buộc phải xài hoặc đó là hàng tặng thì đừng nên mua mấy cái laptop có touch-screen bởi nó chả cần thiết trong khi giá thì bị đội lên rất nhiều

Màn hình

Màn hình của laptop chính là thứ quan trọng nhất, đặc biệt là với programmer. Khi phải phát triển các ứng dụng đồng nghĩa với việc nhìn vào màn hình trong một thời gian dài bởi bạn phải tập trung vào rất nhiều chi tiết khác nhau.

Các Laptop giá rẻ thường có màn hình cỡ 1366 x 768, theo tôi thì chỉ thuộc dạng trung bình là cao nhất rùi. Chả đủ không gian để bạn làm nhiều việc cùng một lúc, đã thể chữ hiển thị cũng không đủ rõ để mắt bạn được dễ chịu mỗi khi đọc.

Còn màn hình 4K thì quá là lãng phí bởi bạn chả cần tới nó, chưa kể nó tốn tiền kinh khủng và ăn pin như hạm.

Nói chung, dù là gì đi nữa đừng bao giờ mua laptop mà có màn hình dưới Full HD 1920 x 1080 (1080p). Nếu có tiền thêm chút cho màn hình phân giải tốt hơn thì càng tốt.

Mà hãy chắc rằng bạn thấy thoải mái khi nhìn vào màn hình, không có gì tệ hơn khi nó phản chíu ánh sáng quá nhiều và trông chẳng khác gì một chiếc gương.

Processing Power (CPU)

CPU ảnh hưởng rất lớn đến hiệu năng của laptop thế nên bạn đừng nên ham rẻ xem nhẹ phần này. Có rất nhiều CPU khác nhau tùy vào nhu cầu của người mua. Một số thông số quan trọng bạn cần biết đến bao gồm cache, số core, frequency cũng như khả năng tỏa nhiệt của chúng.

Thường thì Intel core i5 hoặc i7 processor với frequency 3GHz hoặc hơn là lựa chọn tốt nhất cho bạn.

Memory (RAM)

Tôi không nghĩ bất cứ ai mà muốn theo nghiệp lập trình lại chọn mua laptop với ít hơn 4GB ram. Theo tôi, thấp nhất nên là 8 gb ram, với ngần đó cũng chỉ mới vừa đủ chạy một số ứng dụng khá tốn ram. Còn nếu dư dả thì bạn rất nên mua cái 16GB ram.

Ổ cứng – Dung lượng bộ nhớ

SSD (Solid State Drive) nên là một trong những ưu tiên bạn nên cân nhắc tới bởi sự cải thiện rõ rệt trong hiệu năng khi so sánh với các ổ cứng thông thường khác. Với SSD, tốc độ xử lí của OS, compile code. launch app hay load project đều được tăng rõ rệt.

256GB SSD là một khởi đầu tuyệt vời và nếu bạn điều kiện khá giả thì hãy mua 512GB hoặc 1TB SSD. Tất nhiên SSD không rẻ nên bạn chỉ nên để hệ điều hình và những software quan trọng vào SDD và những thứ khác như game, phim, nhạc, etc vào ổ cứng HDD.

Bàn phím

Bạn đừng xem nhẹ điều này bởi bàn phím là nơi mà bạn dùng để gõ code cả ngày đấy. Thường thì tôi sẽ ưu tiên những bàn phím rộng, thoải mái và có nút bấm nhạy.

Quan trọng nhất là bạn phải ngồi thử xài cái bàn phím trước khi ra quyết định có nên mua nó không. Lưu ý là nó phải khiến bạn cảm thấy thoái mái và không bị vướng víu khi gõ văn bản. Bàn phím có khả năng phát sáng trong đêm cũng khá là hay nếu bạn hay viết code vào đêm.

Thời lượng pin

Có thể không quan trọng mấy nếu laptop của bạn luôn được cắm sạc đầy đủ cũng như chả phải mang đi đâu xa. Dù vậy, tiêu chuẩn bạn nên nhắm tới cũng không ít hơn 6 tiếng.

Đừng nghe lời quảng cáo từ hãng mà hãy lên google tìm đọc những bài review của bên thứ 3 về chúng.

Hệ điều hành

Cái này thì không có gì phải nói, tùy vào nhu cầu của bạn mà nó sẽ khác nhau. Window thì bạn sẽ có khá nhiều lựa chọn nhưng nếu thích macOS thì bạn sẽ bị giới hạn với chỉ các dòng Macbook thôi.

Linux thì chạy tốt trên bất cứ máy nào nhưng bạn nên chọn những máy có hỗ trợ Linux chính thức. Thường thì Dell và System 76  về mặt này làm khá tốt.

Card đồ hoạ chuyên dụng hoặc tích hợp

Card rời không thật sự cần thiết cho việc coding thế nên bạn có thể tiết kiệm bằng cách chọn card on-board và lấy số tiền đó cho SDD hoặc CPU.

Và thế là bạn đã có thể tự tin trong việc kiếm cho mình một “chiến hữu” trong con đường trở thành lập trình viên rồi đấy!

Nguồn: blog.topdev.vn via Medium

 

Bí kíp học Front-end của Grab (Phần 1)

Lập trình Front end chưa bao giờ phức tạp và đầy thú vị như thời điểm này. Các tools, libraries, frameworks, và plugins mới cứ thi nhau xuất hiện từng ngày. Có quá nhiều thứ để cho ta học.

Vì vậy mà nhóm lập trình web của Grab luôn cập nhật những công nghệ mới nhất cũng như tích hợp JavaScript ecosystem vào các ứng dụng của công ty.

Do đó mà các thành viên trong nhóm, dù mới hay cũ, cũng đều cảm thấy khá choáng ngợp với khối lượng kiến thức mới cần phải cập nhật. Thế nên chúng tôi đã lập ra một bản hướng dẫn nhằm giúp các bạn học nhanh hơn và theo đúng hướng để có thể navigate ecosystem một cách dễ dàng, cũng như việc shipping code cho user trở nên hiệu quả hơn.

Bài hướng dẫn này lấy cảm hứng từ “A Study Plan to Cure JavaScript Fatigue” cũng như kết hợp với những ý kiến riêng từ các thành viên trong nhóm với mục tiêu là chọn ra những libraries/frameworks phù hợp cho từng lĩnh vực của phát triển front-end cũng như đúng theo nhu cầu tại Grab.

Chúng tôi sẽ giải thích cặn kẽ vì sao những library đó được chọn và gợi ý những nguồn học để người xem có thể nâng cao kiến thức ngay luôn. Ngoài ra, những lựa chọn thay thế cũng sẽ được nêu ra nhằm giúp người đọc có thêm lựa chọn.

Nếu bạn đã rất quen thuộc với front end cũng như liên tục cập nhật công nghệ thì bài viết này có thể sẽ không giúp ích gì nhiều bởi nó dành cho người mới muốn học về front-end.

Và nếu công ty của bạn đang muốn tìm kiếm một JavaScript stack mới thì bài hướng dẫn này cũng sẽ rất hữu ích! Cứ thoải mái sửa đối tùy theo ý bạn. Bài viết sẽ được update thường xuyên nhằm giữ cho tính chính xác cũng như hữu ích cho người đọc.

  Lối đi nào cho newbie IT - Front End, Back End hay Full Stack?

Điều kiện tiên quyết phải có trước khi bạn xem tiếp

  • Nắm vững về khái niệm lập trình
  • Thoái mái với basic command line actions cũng như quen thuộc với các source code version control systems như Git.
  • Có kinh nghiệm với lập trình web. Đã từng tạo ra các server-side rendered web apps với những frameworks như Ruby on Rails, Django, Express, etc.
  • Hiểu rõ cách thức hoạt động của web. Có kiến thức về web protocols như HTTP và RESTful APIs

Những topic chúng tôi sẽ nói đến trong bài viết

  • Single-page Apps (SPAs)
  • New-age JavaScript
  • User Interface
  • State Management
  • Coding với Style
  • Testing
  • Linting JavaScript
  • Linting CSS
  • Types
  • Build System
  • Package Management
  • Continuous Integration
  • Hosting
  • Deployment

Cứ thoải mái bỏ qua những topic nào bạn đã biết.

Xem ngay các tin đăng tuyển dụng Front-end lương cao trên TopDev

Single-page Apps (SPAs)

Web developer ngày nay thường ám chỉ sản phẩm của họ là web app chứ không gọi là website nữa. Tuy không có nhiều sự khác biệt nhưng web app có tính tương tác cao hơn cũng như tầm ảnh hưởng lớn hơn, cho phép user thực hiện một hành động và nhận lại kết quả được gửi từ web app.

Bình thường, các trình duyệt web sẽ nhận HTML từ server và render nó. Khi user chuyển hướng đến một URL khác thì full-page refresh sẽ diễn ra và trình duyệt gửi một HTML mới dành cho trang mới mà user muốn xem. Đây còn gọi là server-side rendering.

Thế nhưng trong SPAs đời mới, client-side rendering được sử dụng thay thế cho cách trên. Trình duyệt sẽ load page ban đầu từ server, kèm với scripts (frameworks, libraries, app code) cũng như stylesheets cần thiết cho cả app đó. Khi người dùng chuyển hướng URL, page refresh sẽ không bị kích hoạt. Thay vào đó, URL của page sẽ được update thông qua HTML5 History API. Các data cần thiết cho page mới mà user muốn vào xem, thường là thuộc định dạng JSON, sẽ được thu thập bới trình duyệt thông qua AJAX request tới server. SPA sau đó sẽ update page với data mới bằng JavaScript, vốn đã có sẵn sau khi được download ở initial page. Đây là cách thức hoạt động tương tự như của native mobile apps.

Lợi ích:

  • App trả lời nhanh hơn và user sẽ cảm thấy page load được nhanh hơn nhờ vào không phải dùng tới full-page refreshes.
  • Giảm thiểu HTTP requests tới serve cũng như không cần download nhiều data mỗi lần phải load page.
  • Phân chia rõ ràng giữa client và server; bạn sẽ dễ dàng tạo một client mới cho một platform khác mà không cần phải chỉnh sửa lại code của server. Ngoài ra, việc thay đổi technology stack của client và server đều có thể làm riêng rẽ miễn API contract vẫn được giữ nguyên.

Bất lợi:

  • Initial page load sẽ nặng hơn do phải download về framework, app code, cũng như các thành phần cần thiết cho nhiều page khác nhau.
  • Bạn sẽ phải điều chỉnh sao cho requests đều đi qua một điểm và cho phép client-side routing được quyền quản lí ở đầu bên kia.
  • SPAs dựa trên JavaScript để render nội dung, tuy vậy, không phải tất cả search engine đề chạy JavaScript trong quá trình tìm kiếm khiến cho nội dung thu được sẽ bị thiếu hụt. Kết quả gián tiếp lên việc SEO của app bạn bị giảm hiệu quả.

Mặc dù server-side rendered apps vẫn còn là một lựa chọn tốt, client-server redered apps vẫn thích hợp hơn khi nói đến sự phức tạp cũng như qui mô lớn, đòi hỏi việc client và server code được phát triển và chỉnh sửa độc lập. Điều này rất là chính xác với Grab bởi chúng tôi có tới hàng chục client apps nhưng có chung API server.

Như đã nói, web developers hiện nay tập trung vào việc phát triển các web app hơn là page, nhờ đó cộng đồng JavaScript ngày càng trở nên quan trọng hơn. Trong server-side rendered pages, ta thường dùng snippets của jQuery để thêm tính tương tác user cho từng page. Tuy vậy, với các app lớn thì chỉ có jQuery là không đủ, bởi nó chỉ là một library cho việc điều khiển DOM chứ không phải là framework. App của bạn sẽ không có được một cấu trúc rõ ràng nếu như chỉ dùng jQuery.

Do đó mà JavaScript frameworks được dùng để giải quyết vấn đề trên. Mặt khác việc sử dụng các frameworks quen thuộc cũng rất tiện lợi bởi giúp cho team dễ hiểu về code cũng như app hơn. May thay những framework nổi tiếng thì cũng có nguồn học rất phong phú và cực kì đa dạng.

Links tham khảo:

New-age JavaScript

Trước khi nhảy vào tìm hiểu về cách viết ra một JavaScript web app, bạn sẽ phải làm quen với ngôn ngữ lập trình web –  JavaScript, hoặc ECMAScript. JavaScript là một ngôn ngữ cực kì linh hoạt bởi bạn có thể dùng làm web servers, native mobile apps và desktop apps.

Vào 2015, ECMAScript 5.1 chỉ mới được tung ra kể từ 2011. Thế nhưng trong những năm gần đây, JavaScript đã phát triển bùng nổ mạnh mẽ. Trong 2015, ECMAScript 2015 được tung ra với hàng chục tính năng để viết code dễ dàng hơn. Nếu bạn muốn biết rõ thêm thì có viết một bài khá hay là lịch sử và mẹo hay về JavaScript. Cho đến thời điểm hiện tại, vẫn chưa có trình duyệt nào thực sự có thể tận dụng hết tất cả tính năng và sức mạnh của ES2015. Các tool như Babel cho phép developers viết ES2015 trong các app của mình và Babel sẽ chuyển tiếp chúng xuống ES5 để giúp tương thích cho các trình duyệt web.

Biết cả ES5 và ES2015 là rất cần thiết. Bởi ES2015 vẫn còn khá nhiều open source code và Node.js apps vẫn được viết bằng ES2015. Nếu bạn debugging trong trình duyệt console thì có thể bạn sẽ không dùng được ES2015 syntax. Mặc khác, các tài liệu và libraries vẫn còn xài ES2015. Tại Grab, chúng tôi sử dụng babel-preset-env nhằm tăng hiệu năng nhờ vào sự cải thiện trong syntactic của JavaScript.  babel-preset-env rất thông minh khi biết xác định các Babel plugins cần thiết (cũng như tính năng nào không thương tích và cần bị chuyển đi) bởi trình duyệt web đang tăng khả năng native support dành cho nhiều tính năng của ES hơn. Nếu bạn muốn dùng một số tính năng ngôn ngữ chạy ổn và bảo đảm, bạn có thể tìm thấy tại babel-preset-stage-3, một list các tính năng và thông số kĩ thuật sẽ được áp dụng trong trình duyệt web.

Hãy dành 1 đến 2 ngày để khám phá và tìm hiểu ES5 cũng như ES2015. Những tính năng nổi bật trong ES2015 bao gồm “Arrows and Lexical This”, “Classes”, “Template Strings”, “Destructuring”, “Default/Rest/Spread operators”, and “Importing and Exporting modules”.

Khoảng thời gian để hoàn thành: 3–4 ngày. bạn có thể học/tìm hiểu về syntax khi học về các libraries cũng như trong quá trình viết ra một app cho mình.

Links tham khảo:

User Interface — React

Khi nói đến các JavaScript projects hấp thụ hệ thống front end ecosystem nhiều nhất thì React sẽ phải đứng đầu. React là một library với open-sourced được tạo ra bởi Facebook. Trong React, developer viết các components cho web interface và kết hợp chúng lại với nhau.

React khuyến khích các developer luôn tìm tòi, suy nghĩ cách thức sử dụng tốt nhất. Các web developer luôn được dạy rằng nên viết HTML, JavaScript và CSS riêng rẽ. React thì hoàn toàn ngược lại, nó khuyến khích ta viết HTML và CSS trong Javascript của mình. Nghe có vẻ thật điên cuồng nhưng sau khi bạn thử thì nó sẽ trở nên có lí hơn. Đó là nguyên nhân việc có sự thay đổi trong việc phát triển front-end với mô hình component làm chủ đạo. Các tính năng của React:

  • Declarative (tuyên bố): bạn mô tả điều mà bạn muốn thấy chứ không phải cách để có được nó. Vào thời của jQuery, developers phải nghĩ ra rất nhiều bước để điều khiển DOM nhằm từ app state này sang cái khác. Trong React, bạn chỉ cần thay đổi state trong component luôn và mọi thứ sẽ tự động update theo state. Ngoài ra cũng rất dễ để xác định cách component sẽ như thế nào nhờ vào render() method
  • Functional: View thật sự chỉ là function của  props và  state. Trong phần lớn các trường hợp, một React component sẽ được define bằng props (external parameters) và state (internal data). Với  props và  stateđó thì view sẽ được tạo ra. Pure functions rất dễ để test và điều đó cũng đúng với functional components. Nguyên nhân cho việc test trong React rất dễ dàng là bởi vì component’s interfaces đã được define rất kĩ và bạn chỉ cần thay đổi props và state  để so sánh kết quả output thu được của render.
  • Maintainable  (Bảo trì): Khi viết view theo component-based fashion cũng sẽ giúp tăng khả năng tái sử dụng. Chugn tôi nhận ra rằng khi define một component của  propTypes khiến cho người đọc React code hiểu rõ hơn về những thứ cần có cho component đó. Mặt khác, view và logic của bạn sẽ tự động chứa trong component, và nó sẽ không bi ảnh hưởng hay tác động đến các component khác. Nhờ đó mà việc thay đổi các component dễ dàng hơn, miễn là  props vẫn được giữ nguyên.
  • Hiệu năng cao – Bạn hẳn cũng từng nghe qua rằng React sử dụng một DOM ảo (khác với shadow DOM) và nó re-renders lại mọi thứ khi state có thai đổi. Vì sao lại cần một DOM ảo? Đó là vì dù JavaScript engine khá nhanh, việc viết và đọc từ DOM vẫn còn chậm. Do vậy, React sẽ có sẵn một phiên bản ảo của DOM trong bộ nhớ. “Re-rendering mọi thứ” là một cụm từ bị dùng sai. Trong React thì re-rendering lại thực chất chỉ diễn ra trong phiên bản ảo của DOM. Như vậy khi có bất kì thay đổi trong data của component, một hiện thị (ảo) được tạo ra và so sánh với phiên bản cũ. Những khác biệt (nằm trong phạm vi cho phép) sau đó sẽ được patch nhờ vào DOM (thật) của trình duyệt.
  • Dễ học – Học React rất dễ. React API trông rất là nhỏ gọn khi bạn thử so sánh với một library khác. Bạn chỉ cần học một vài API và chúng có rất ít thay đổi. Hơn nữa, cộng đồng React rất lớn, có hẳn một ecosystem riêng cho tool, open-sourced UI components, và vô số nguồn học online vô cùng hữu ích cho bạn.
  • Kinh nghiệm của Developer –  Có rất nhiều tools giúp cho developer lên trình rất nhanh với React. React Developer Tools là một  browser extensioncho phép bạn xem và kiểm tra component, view cũng như tinh chỉnh  props và state của chúng. Hot reloading với webpack cho phép bạn theo dõi các thay đổi của code trong trình duyệt của mình mà không cần phải refresh nó. Lập trình Front end đòi hỏi việc phải tinh chỉnh code rất nhiều, save rồi refesh trình duyệt. Hot reloading giúp bạn bỏ qua bước cuối cùng. Mỗi khi library được update, Facebook  sẽ cung cấp một codemod scripts để giúp bạn chuyển code của mình lên APIs mới. Điều này khiến cho quá trình update trở nên thật nhẹ nhàng.

Qua nhiều năm, các view libraries  với hiệu năng cao hơn cả React đã bắt đầu xuất hiện. React có thể không còn nhanh nhất nữa nhưng nếu xét về hệ ecosystem, trải nghiệm người dùng cũng như lợi ích thì nó vẫn là một trong những top libraries. Ngoài ra, Facebook cũng đang tập trung để phát triển React khi hãng bỏ công ra viết lại các thuật toán gốc cho nó. React giúp chúng ta viết code một cách gọn gàn hơn, tốt hơn cũng như để việc bảo trì và phát triển web app dễ dàng hơn.

Chúng tôi khuyến khích bạn nên thử qua lập trình một game Tic Tac Toe trẹn React homepage để hiểu rõ hơn về nó. Để hiểu sâu hơn về React, bạn có thể vào học khóa React Fundamentals  cực kì hữu ích của tác giả của React Router, một chuyên gia trong cộng đồng React. Create React App là một tool khác giúp giản đơn các tính năng của React nên rất phù hợp cho người mới học React.

Khoảng thời gian để hoàn thành: 3–4 ngày. Hãy thử làm những project đơn giản như to-do list, Hacker News clone với React. Bạn sẽ tăng level rất nhanh và có thể gặp phải một số vấn đề mà React cũng không giải quyết được, và như vậy chúng ta sẽ đến topic tiếp theo trong phần 2…..

Links học

Một số lựa chọn khác

Đừng bỏ lỡ những bài viết hay về Front-end:

TopDev via Medium

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

Một số lời khuyên nhanh để tiếp cận Trí tuệ nhân tạo

Để tiếp cận được trí tuệ nhân tạo nên bắt đầu như thế nào?

Đầu tiên cần hiểu cách máy tính nhìn nhận thế giới, bằng cách xây dựng được model, chuẩn hóa dữ liệu, ví dụ cần xử lý ảnh, video, âm thanh, xử lý chuỗi rồi cho ra input đầu vào….

Sau đó cần làm quen với các thuật toán tiếp cận gần đúng và tổng quát, là đặc trưng kiểu trí tuệ nhân tạo, kể cả đơn giản như dùng giải thuật di truyền, sinh ngẫu nhiên tập kết quả và chọn ra kết quả tốt nhất dựa trên sai số với hàm lượng giá là thấp nhất, học không giám sát chỉ là phân cụm dữ liêu, về cơ bản các mạng nơ ron cũng là lặp lại sao cho sai số là thấp nhất.

Cuối cùng là áp dụng thử vào các bài toán thực tế, như phân loại dữ liệu, nhận dạng số, khuôn mặt..v.v

Deep learning về cơ bản không phải là thuật toán gì cao siêu, bản chất của trí tuệ nhân tạo không nằm ở thuật toán cao siêu mang tính tuyệt đối, mà nó nằm ở khả năng có thể học cực tốt, không giới hạn, học sâu thể hiện qua mạng nơ ron rất nhiều lớp, học thêm, học tất tần tật, và chắc là không giống như dùng nhiều trick để xử lý dữ liệu đầu vào siêu chuẩn và nhận dạng bằng máy tính thường, học sâu học bất kỳ, như captcha là học cả ảnh nhiễu chứ ko cần bóc tách.

Về tương lai trí tuệ nhân tạo có thể phát triển mạnh dạng các service và chúng ta build model, sau đó tái sử dụng kết quả training. Bởi vì sau khi train xong, chúng ta có mạng nơ ron được hiệu chỉnh trọng số, dùng để thực hiện nhiệm vụ cơ bản nhất là reduce đầu vào thành tập nhỏ kết quả đầu ra để quyết định, và tương lai gần thì robot cũng không lắp kịp một CPU đủ khả năng tính toán siêu khủng để thông minh như con người, nên chắc sẽ cập nhật kết quả học từ server, mà nghe nói chỉ để đánh cờ thắng con người cũng đã cần server khủng rồi, nên thực tế nhất nên sử dụng nó vào data mining ví dụ như recommendation system.

Nguồn: Thanhtu Pham

8 câu hỏi phỏng vấn dành cho các lập trình viên Mobile app

Cơ hội việc làm dành cho các mobile dev đang ngày càng mở rộng với số lượng tăng cao các doanh nghiệp ứng dụng công nghệ mobile vào công việc kinh doanh của mình.

Vì vai trò này rất quan trọng đối với các startups tương lai, việc tuyển chọn các ứng viên managers phù hợp đòi hỏi tính chọn lọc cao và rất khắt khe.

Nếu bạn là 1 dev mobile app tài năng và đã từng ứng tuyển vào các công việc ở mảng này, bạn có thể đọc tiếp. Chúng tôi liệt kê danh sách 8 câu hỏi mà bạn có thể nhận được khi đi phỏng vấn cho vị trí Mobile Apps Developer

1. Loại smartphones mà bạn sử dụng là gì?

Đúng là câu hỏi vô nghĩa nhỉ! Bạn đang lập trình ứng dụng cho di động, tất nhiên smartphone của bạn phải là 1 trong các công cụ chính. Tôi đoán là bạn sẽ chẳng có vấn đề gì khi trả lời câu hỏi này nhưng nếu bạn thể hiện sự quen thuộc và kiến thức sử dụng nhiều hơn 1 hệ điều hành/ thương hiệu thì sẽ tốt hơn nhiều.

2. Kể tên 3 mobile apps mà bạn thích

Nếu bạn chọn lập trình app là nghề nghiệp mà bản thân theo đuổi, bạn phải cập nhật kiến thức về những apps mới nhất. Người quản lý mảng tuyển dụng sẽ muốn bạn luôn thử nghiệm và kiểm tra nhiều app khác nhau, từ đó đưa ra những tiêu chuẩn chắc chắn về những điểm được xây dựng tốt và những điểm cần cải thiện trong app. Đảm bảo chắc chắn là bạn sở hữu vài app yêu thích trong smartphone của mình và sẵn sàng thảo luận về chúng từ chức năng đến các điều kiện lập trình.

3. Bạn đã từng tham gia quy trình làm app được đưa lên iTunes hay Android stores?

Đây là lúc để bạn phô diễn về công việc và kinh nghiệm của bản thân. Hãy chỉ ra vai trò của bạn trong giai đoạn lập trình của mỗi dự án và những khó khăn bạn gặp phải khi tạo app. Nếu bạn chưa từng làm app chuyên nghiệp, bạn có thể khoe khoang những app mà bạn tự lập trình hoặc trong các bài tập thực hành tại trường. Tạo 1 nguồn app mở trước khi nộp đơn xin việc là 1 ý tưởng tốt.

4. Hãy nói cho chúng tôi vài điểm bất lợi của cả Android và iOS

Nếu bạn đang lập trình 1 app cho 1 platform chuyên biệt, bạn nên biết những điểm bất lợi của nền tảng đó. Đây là lúc bạn có thể đề cập đến các vấn đề kỹ thuật mà bạn gặp phải khi phát triển cho mỗi platform, cũng như những giải pháp cho các vấn đề đó. Chú ý là các ví dụ mà bạn cung cấp phải cụ thể.

5. Điểm khác biệt giữa lập trình ứng dụng desktop/ web so với lập trình ứng dụng di động?

Các màn hình và kích thước khác nhau, tốc độ kết nối đa dạng, khả năng tiêu thụ pin, giới hạn dung lượng bộ nhớ… là những vấn đề ở các thiết bị mobile và hãy cho nhà tuyển dụng thấy bạn thực sự biết cách quản lý, kiểm soát chúng.

6. Làm thế nào để giải quyết các vấn đề bảo mật?

Bảo mật luôn là vấn đề nhạy cảm, đặc biệt là khi đề cập đến các thiết bị di động. Thể hiện kiến thức của bạn về bảo mật và các ý tưởng để giảm thiểu các vấn đề bảo mật trong app. Theo tin mới nhất, chẳng phải có 1 cuộc tấn công vào phần mềm gần đây sao? Hãy đề cập đến nó và chuẩn bị các giải pháp cho vấn đề này.

7. Vai trò quan trọng của giao diện người dùng/ trải nghiệm người dùng (UI/UX) trong lập trình ứng dụng di động?

Giao diện người dùng và trải nghiệm người dùng trở thành chìa khóa thành công của các ứng dụng mobile, vì vậy chắc chắn các nhà tuyển dụng sẽ đặt ra cho bạn rất nhiều câu hỏi liên quan đến UI/UX. Nêu rõ ý kiến và các mẹo của bạn để tận dụng tốt nhất giao diện mobile. Bạn có thể chỉ ra app nào mà bạn nghĩ có UI tốt và những app UI không tốt. Ngoài ra, 1 số doanh nghiệp có thể yêu cầu bạn vẽ nhanh 1 giao diện.

8. Bạn đã từng tích hợp app từ 1 platform sang 1 platform khác chưa?

Hầu hết các apps đều sử dụng được nhiều hơn 1 hệ điều hành, vì thế việc học cách cấu hình lại hoặc chuyển app từ 1 platform sang platform khác là 1 phương án tốt. Hãy kể về kinh nghiệm trong lĩnh vực này và nêu chi tiết về những app mà bạn đã từng cấu hình lại cũng như các giải pháp mà bạn đã thực hiện. Nếu bạn không có bất kì kinh nghiệm nào, hãy trình bày lý do bạn nghĩ bản thân đã chuẩn bị kỹ thuật cho nó.

Giải pháp của JobFluent

Rèn luyện sự tự tin, đảm bảo an toàn khi phỏng vấn bằng cách tự đặt câu hỏi cho bản thân. Đây là vài ví dụ dành cho bạn:

  • Bạn đã từng sở hữu dự án lập trình nào chưa?

Thể hiện sự hứng thú với những gì bạn đang làm, phân tích chi tiết và đưa ra vài gợi ý liên quan đến dự án.

  • Bạn có viết code review không?

Một trong những cách nhanh nhất để phát triển thành 1 developer là để người khác đọc và trả lời trên code của bạn. Những review code thường xuyên đồng nghĩa là team của bạn đang tốt dần lên.

Ok, bây giờ thì bạn đã sẵn sàng rồi! Hãy tìm hiểu về công ty mà bạn đã ứng tuyển và thể hiện thái độ tốt và sự tự tin nào. Chúc may mắn!

Nguồn: Jobfluent 

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

Chiếc nón học tập – Ai cũng nên biết!

Tiến trình Đọc – Học – Vọc hay Biết – Hiểu – Hành nói ra thì dễ nhưng cứ phải tới khi đụng và ngã ngửa rồi mới hiểu ra và khi có được động lực kèm môi trường thì chịu học.

Bạn sửa bài cho, rồi đọc lại tôi mới thấy những cái bị sửa đơn giản vô cùng và toàn là những cái tôi đã biết và hiểu nhưng tôi chẳng nhớ, chẳng dùng. Bạn bảo bởi “passive learning”, tức học thụ động, được hiểu rằng chỉ có nạp và xử lý rồi để đấy mà không hành. Với ngôn ngữ, nó là chuyện đọc nhiều, nghe nhiều, biết phát triển ý, biết đặt câu hỏi nhưng không chủ động nói, không viết thường xuyên và sử dụng những gì đã học vào quá trình này, vậy nên biết nhưng không làm được.

Cái hình dưới của nhà giáo người Mỹ Edgar Dale ra đời cách đây cũng tầm 70 năm nhưng vẫn còn xài được. Nó cụ thể hóa cái quá trình trên bằng mấy con số và mấy cách thức mà Dale đã khảo sát và nghiên cứu. Tháp đồ đơn giản này có ý nghĩa quan trọng trong định hình phương pháp giảng dạy chủ động, kết hợp các hình thức khác nhau để kích thích mọi giác quan của người học. Với người học, họ cũng có thể tham khảo để biết cách học chủ động sao cho tiếp thu hiệu quả và thực hành được chính xác những gì đã học.

Cách đây mấy hôm tại Sài Gòn, vị tỉ phú người Mỹ, Jeff Hoffman, người là đồng sáng lập và giám đốc của mấy công ty du lịch siêu bự, dạng trùm thế giới cũng nói về chuyện học chủ động kết hợp với các phương tiện kỹ thuật số để phục vụ cho đổi mới sáng tạo. Ngoài việc chia sẻ các công nghệ mới đang định hình lại cách ta học tập, làm việc, và tầm quan trọng của khai thác các công nghệ này như (thực tế ảo, hologram, gương thông minh, …), ông cũng chỉ một cách nữa nằm ở trên đỉnh của tháp đồ Dale, là đọc. Hãy đọc thật nhiều và đọc mỗi ngày. Đọc sách là chuyện hiển nhiên rồi, nhưng hãy đọc thêm những tài liệu khác. Đọc mọi chủ đề chứ không chỉ 1 chủ đề. Vì bài nói của ông đề cập đến đổi mới sáng tạo, ông cho hay chính nhờ mỗi ngày dành ra 10 phút đọc những cái mới hay những chủ đề khác lạ so với chuyên ngành của mình trong suốt 30-40 năm nay mà ông, một kỹ sư, mới mang đến những thành công từ việc biết áp dụng những kiến thức từ ngành khác vào đổi mới lĩnh vực du lịch. Ông học chủ động bằng cách áp dụng nó ngay vào công việc của mình.

Tài liệu về đọc, học chủ động trên mạng cũng nhiều, chịu khó tìm kiếm thì có cả đống để đọc đó nghen.

Nguồn: Gương Nga

Developer Việt còn thiếu gì để thành công?

Sở hữu trên 100 giải thưởng lớn nhỏ về công nghệ thông tin trong và ngoài nước, là tác giả của ứng dụng BusMap với hơn 300 000 lượt tải; là người trẻ nhất trong số 10 gương mặt được trao giải “Quả cầu vàng”-giải thưởng do T.Ư Đoàn TNCS và Bộ Khoa học – Công nghệ tổ chức, sinh viên duy nhất trong danh sách 6 Công dân trẻ tiêu biểu 2014, một trong 7 sinh viên Việt Nam thực tập tại Google, và còn vô số những thành tích mà chàng trai 23 tuổi- Lê Yên Thanh đã đạt được những thành công khiến người khác phải khâm phục.

Tuy nhiên, hôm nay tôi gặp Yên Thanh không phải tư cách là gương mặt trẻ tiêu biểu, hay chàng trai vàng của công nghệ Việt Nam, càng không phải người từ chối Google để về Việt Nam làm Start-up. Tôi gặp Yên Thanh với tư cách là một Backend Developer của Umbala-đấu trường ngôi sao. Chúng tôi nói về những câu chuyện về nghề lập trình, kinh nghiệm xây dựng sản phẩm, những tiềm năng và cơ hội cho developer Việt.

  • Yên Thanh có thể chia sẻ về công việc hiện tại của bạn

Mình đang làm Back-end tại Umbala. Hiện tại Umbala đang thực hiện một dự án hợp tác với Viettel triển khai các gói giá trị gia tăng, khi người dùng đăng kí 1 gói 4G của Viettel có thể sử dụng ứng dụng Umbala miễn phí, ngoài ra còn có những dịch vụ nạp tiền vào ứng dụng, sau này sẽ có nhiều tiện ích được tích hợp trong ứng dụng Umbala. Chính vì vậy, bên cạnh làm back-end mình còn phụ trách cả phần thuê máy chủ, bảo mật vào nội dung bên trong của ứng dụng.

  • Bạn có thể nói rõ hơn về ứng dụng Umbala

Umbala là một sản phẩm tạo video clip với nhiều hiệu ứng vui nhộn, độc đáo, thú vị. Tính năng đặc biệt nhất giúp Umbala khác biệt so với các ứng dụng video hiện tại có trên thị trường là các hiệu ứng hình ảnh có thể tự điều chỉnh theo tiết tấu nhạc. Hiện nay chưa có nhiều ứng dụng làm được điều đó. Chất lượng video tốt, thỏa mãn thị giác người dùng, cũng chính là 1 điểm killer features của ứng dựng Umbala.

Hiện tại Umbala đang phát triển theo hướng tương tác real time. Tương tác Real time giải quyết được các nhu cầu thực tế từ các nhà quảng cáo. Không giống như các sản phẩm quảng cáo banner hay hiển thị không thể đo lường được hiệu quả quảng cáo. Với tương tác thời gian thực- Real time tất cả mọi thứ đều diễn ra cùng 1 lúc nên có thể đo lường chính xác hiệu quả quảng cáo trong thời gian thực. Chính vì vậy việc nhận diện thương hiệu cũng trở nên hiệu quả hơn. Hơn thế nữa, vì sử dụng video nên có thể dễ dàng thêm bất kì nội dung gì theo yêu cầu từ nhà quảng cáo.

  • Trong quá trình triển khai dự án Yên Thanh có gặp khó khăn gì không?

Với dự án phối hợp với Viettel, do hiện tại Viettel đang sử dụng hệ thống viết bằng swap còn hệ thống của Umbala viết API bằng resfull, vì vậy gần như phải xây dựng hệ thống lại từ đầu. Với hệ thống SMS truyền thống chỉ chủ yếu là nhắn tin cú pháp nhưng trong dự án này yêu cầu nhiều hơn thế, chính vì vậy, cần phải làm cho nó tương thích với ứng dụng của mình cũng là một bài toán cần phải giải quyết.

Với đặc thù User ở Viêt Nam chỉ tập trung vào một số khung giờ nhất định nên phải thiết kế hệ thống có khả năng tự Scale để tối ưu hóa chi phí nhất có thể. Bên cạnh đó Umbala cũng đang nỗ lực để cải thiện tốc độ tải cũng như chất lượng Video để giúp người dùng có được trải nghiệm tốt nhất.

  • Đã từng có cơ hội được làm việc ở nước ngoài tại sao Thanh lại trở về Việt Nam?

Tuy làm việc nước ngoài cuộc sống tốt hơn, còn ở Việt Nam có nhiều thứ rất khác, đặc biệt khi làm việc ở 1 StartUp thì càng có nhiều vấn đề, và gần như mình phải tự thân vận động toàn bộ, không ai hỗ trợ mình.

Nhưng mình cảm thấy ở Việt Nam còn rất nhiều cơ hội, nếu bây giờ không nắm bắt sẽ bị những người giỏi khác cướp mất.

  • Làm việc ở công ty lớn khác gì với làm cho Start-Up 

Ở công ty lớn sẽ ít việc hơn vì công việc được chuyên môn hóa cao, hệ thống tốt hơn, có thể yêu cầu máy chủ, mua framework đều rất đơn giản. Làm ở công ty lớn không cần phải tốn thời gian để xây dựng hệ thống cấu trúc máy chủ. Còn ở công ty Start-Up luôn phải đối mặt với áp lực deadline, khối lượng công việc nhiều vì vậy OT là chuyện rất bình thường, và luôn phải giải quyết vấn đề tối ưu hệ thống tiết kiệm nhất nhưng mang lại hiệu quả cao nhất.

Nhưng làm việc ở công ty Start-Up mình được tự quyết định cái mình muốn, không phụ thuộc vào người khác.

  • Theo Yên Thanh lập trình viên Việt Nam mình còn yếu và thiếu ở điểm nào?

Mình thấy ở Việt Nam xét mặt bằng chung lập trình viên còn thiếu về kinh nghiệm, ở giai đoạn này mình không phải thiếu kiến thức nền nữa, cái quan trọng là phải có kinh nghiệm. Không chỉ là kinh nghiệm làm việc mà còn phải có kinh nghiệm về quản lý nữa: kinh nghiệm phỏng vấn lập trình viên, phân công công việc như thế nào cho phù hợp. Những điều đó chỉ có thể có được qua tích lũy qua những trải nghiệm của bản thân, không có sách vở nào dạy những điều đó. Phải vừa có kiến thức nền vừa có kinh nghiệm làm việc thì mới hoàn hảo được. Dù có kiến thức tốt nhưng không có kinh nghiệm thì chỉ có thể làm công ăn lương sẽ luôn bị người có kinh nghiệm chỉ đạo. Còn nếu có kinh nghiệm mình sẽ tự đi được.

Một điểm nữa là lập trình viện Việt Nam mình còn hơi yếu về tư duy, chủ yếu về tư duy theo kiểu software engineer, chỉ biết làm theo yêu cầu. Tức là chỉ biết Input và Output rõ ràng, không có tư duy sản phẩm. Điều mình hướng tới không phải là Software Engineer mà là Product Engineer, phải tư duy về mặc sản phẩm. Mình Không chỉ nghỉ mình làm tính năng gì, bấm cái nút đó ra làm sao, mà mình phải nghĩ là người dùng sẽ được cái gì, tức là khi làm tính năng đó thì người dùng sẽ tương tác ra sao, cảm nhận của người dùng như thế nào.

  • Vậy làm thế nào để khắc phục được những yếu điểm đó?

Muốn có tư duy tốt phải chủ động sáng tao, phải đọc sách nhiều, phải học người khác cách họ tư duy như thế nào, học cách tư duy trong mọi vấn đề của cuộc sống. Đặc biệt với những bạn làm Outsourcing đừng để bị chi phối bởi lối tư duy Software Engineer, vì làm như vậy một thời gian sẽ bị vùi đầu vào việc Input – Output sẽ không còn khả năng tư duy sáng tạo như vậy rất nguy hiểm. 

  • Yên Thanh có dự định gì cho riêng mình không?

Hiện tại mình đang cố gắng để trở thành Full Stack có thể build một hệ thống hoàn thiện. Làm quản lý không nhất thiết phải làm hết mọi thứ nhưng mình cần biết bên dưới làm những gì, phân công nhiệm vụ cho từng người phù hợp để không chỉ phát huy được năng lực của nhân viên mà còn phát triển được doanh nghiệp của mình. Hiện tại mình cũng đang ấp ủ một dự định nhưng chưa có thời gian thực hiện, phát triển ứng dụng Umbala là ưu tiên hàng đầu của mình lúc này.

Cảm ơn Yên Thanh vì những chia sẻ thú vị, chúc cho những kế hoạch, dự định của bạn sớm được thực hiện.

Cùng khám phá sức mạnh của ES6 Generators

Generators có thể xem như là cách áp dụng của iterables

Điều khiến generators trở nên đặc biệt bởi vì chúng là những functions có khả năng hoãn lại quá trình execution mà vẫn giữ nguyên được context.

Đây là một tính năng rất quan trọng khi ta phải dùng tới những executions đòi hỏi phải có quãng pause nhưng context phải được để nguyên nhằm để recover lại trong tương lai khi cần đến.  

Bạn có từng nghe qua quá trình phát triển async chưa?

Syntax – Cú pháp

Syntax (Cú pháp) cho generators bắt đầu với function* declaration của chính nó (nhớ lưu ý cái asterisk) và  yield dành cho khi generator muốn dừng (pause) execution. 

function* generator() {
    // A
    yield 'foo'
    // B
}

Với  next function, chúng ta có thể kiểm soát được quá trình tạo ra một generator từ  generator sẵn có.

Khi chạy  next function, thì code của  generator sẽ được thực hiện (execute) và cho đến khi gặp  yield thì sẽ ngừng lại.

Lúc đó,  yield sẽ xen vào và khiến cho  generator execution bị đình chỉ (pause).

const g = generator()

g.next() // { value: 'foo', done: false }
// Our generator's code A gets executed
// and our value 'foo' gets emitted through yield.
// After this, our generator's execution gets suspended.

g.next() // { value: undefined, done: true }
// At this stage the remaining code (i.e. B) gets executed.
// Because no value is emitted we get 'undefined' as the value,
// and the iterator returns 'true' for iteration done.

yield được sinh ra cùng lúc với generator và cho phép chúng ta đưa ra các giá trị mà mình muốn. Tuy nhiên, nó chỉ thực hiện được khi ở trong phạm vi của generator.

Nếu thử dùng yield  với một giá trị trong callback thì cho dù đã declared trong generator thì nó vẫn sẽ bị lỗi.

function* generator() {
    ['foo','bar'].forEach(e => yield e) // SyntaxError
    // We can't use 'yield' inside a non-generator function.
}

 

yield*

yield* được tạo ra nhằm có khả năng gọi một generator nằm trong một generator khác.

 

function* foo() {
    yield 'foo'
}

// How would we call 'foo' generator inside the 'bar' generator?
function* bar() {
    yield 'bar'
    foo()
    yield 'bar again'
}

const b = bar();

b.next() // { value: 'bar', done: false }
b.next() // { value: 'bar again', done: false }
b.next() // { value: undefined, done: true }

Bạn có thể thấy b iterator, thuộc  bar  generator, không hề chạy như đúng ý ta khi call foo.

Đó là mặc dù foo  execution cho ra một iterator, nhưng ta sẽ không có lặp lại (iterate) nó được.

Vì thế mà ES6 cần có operator  yield*

function* bar() {
    yield 'bar'
    yield* foo()
    yield 'bar again'
}

const b = bar();

b.next() // { value: 'bar', done: false }
b.next() // { value: 'foo', done: false }
b.next() // { value: 'bar again', done: false }
b.next() // { value: undefined, done: true }

Đồng thời nó cũng hoàn toàn có thể áp dụng với data consumers

for (let e of bar()) {
    console.log(e)
    // bar
    // foo
    // bar again
}

console.log([...bar()]) // [ 'bar', 'foo', 'bar again' ]

 

 yield* có khả năng kiểm tra và chạy qua hết tất cả ngõ ngách trong generator để yield ra phần nó cần.

function* bar() {
    yield 'bar'
    for (let e of foo()) {
        yield e
    }
    yield 'bar again'
}

 

Generators cũng chính là Iterators

Generators thực chất là những iterables đơn giản. Nói cách khác chúng cũng sẽ theo luật của iterable và  iterator .

Luật của iterable cho ta biết một object sẽ nên return một function itera với key là  Symbol.iterator.

const g = generator()

typeof g[Symbol.iterator] // function

 

Còn luật của iterator cho ta biết iterator nên là một object chỉ tới yếu tố tiếp theo của iteration. Object này phải chứa một function gọi là next

const iterator = g[Symbol.iterator]()

typeof iterator.next // function

 

Bởi vì generators là iterables nên chúng ta có thể dùng data consumer  for-of, để iterate (lặp lại) giá trị của generators (values).

for (let e of iterator) {
    console.log(e)
    // 'foo'
}

 

Return

Chúng ta còn có thể add vào return cho generator, thế nhưng return sẽ hoạt động hơi khác đi tùy thuộc vào cách generators’ data được iterated.

 

function* generatorWithReturn() {
    yield 'foo'
    yield 'bar'
    return 'done'
}

var g = generatorWithReturn()

g.next() // { value: 'foo', done: false }
g.next() // { value: 'bar', done: false }
g.next() // { value: 'done', done: true }
g.next() // { value: undefined, done: true }

Khi ta thực hiện iteration bằng tay, sử dụng  next, sẽ nhận được returned value (i.e. done ) cũng chính là value cuối của iterator object và khi done  đưa ra kết quả true.

Mặt khác, khi sử dụng defined data consume như for-of hoặc destructuring thì returned value sẽ bị bỏ qua.

 

for (let e of g) {
    console.log(e)
    // 'foo'
    // 'bar'
}

console.log([...g]) // [ 'foo', 'bar' ]

yield*

Như bạn đã biết  yield* được tạo ra nhằm có khả năng gọi một generator nằm trong một generator khác.

Ngoài ra, nó còn cho phép chúng ta lưu trữ value returned bằng executed generator.

function* foo() {
    yield 'foo'
    return 'foo done'
}

function* bar() {
    yield 'bar'
    const result = yield* foo()
    yield result
}

for (let e of bar()) {
    console.log(e)
    // bar
    // foo
    // foo done
}

 

Throw

Chúng ta có thể dùng throw trong một generator và next  sẽ truyền exception ra.

Và khi một exception bị đẩy ra, iterator (lặp) sẽ bị phá và state của nó sẽ được set thành  done: true

function* generatorWithThrow() {
    yield 'foo'
    throw new Error('Ups!')
    yield 'bar'
}

var g = generatorWithReturn()

g.next() // { value: 'foo', done: false }
g.next() // Error: Ups!
g.next() // { value: undefined, done: true }

Generators cũng chính là Data Consumers

Generators ngoài khả năng như một data producers, với yield, nó cũng có thể consume data khi dùng next.

function* generatorDataConsumer() {
    // A
    console.log('Ready to consume!')
    while (true) {
        const input = yield; // B
        console.log(`Got: ${input}`)
    }
}

 

Có một vài điểm khá thú vị sau đây

// (1)
var g = generatorDataConsumer()

// (2)
g.next() // { value: undefined, done: false }
// Ready to consume!

// (3)
g.next('foo') // { value: undefined, done: false }
// Got: foo

Generator Creation (1)

Ở stage này, chúng ta đang tạo ra generator g.

Và execution sẽ dừng lại tại điểm A.

Next đầu tiên (2)

Execution đầu tiên của next giúp cho generator được executed cho tới khi gặp phải yield.

Tất cả các giá trị (value) trong stage này khi đi qua  next sẽ bị lơ đi. Nguyên nhân là vì vẫn chưa có gặp một  yield nào cả.

Và execution của chúng ta chỉ dừng lại tại điểm B  khi một  value nào đó được đưa ra bởi  yield.

Next tiếp theo (3)

Lúc này thì value đã đi qua yieldvà như vậy execution sẽ bị ngừng lại.

Hãy dùng Cases

Implement Iterables

Bởi generators là một iterable implementation, khi chúng được tạo ra thì chúng ta cũng sẽ có một iterable object với từng yield đại diện cho một giá trị sẽ được đưa ra trên từng iteration. Nói cách khác chúng ta có thể dùng generators để tạo ra iterables.

Ví dụ sau đây sẽ thể hiện generator như là iterable  với khả năng lập một dãi các số nguyên cho tới khi nó đạt  max. Và ta cũng dùng for-of  để lập những giá trị trên.

Các bạn cũng cần lưu ý rằng yield sẽ khiến các execution bị dừng lại tại một điểm và các iteration sẽ khiến cho execution chạy tiếp tại các điểm đó.

function* evenNumbersUntil(max) {
    for (let value = 0; value <= max; value += 2) {
        // When 'value' is even we want to 'yield' it
        // as our next value in the iteration.
        if (value % 2 === 0) yield value;
    }
}

// We can now user 'for-of' to iterate over the values.
for (let e of evenNumbersUntil(10)) {
    console.log(e)
    // 0
    // 2
    // 4
    // 6
    // 8
    // 10
}

 

Asynchronous Code

Ta còn có thể dùng generators  với những async code như  promises.

Tiện thể thì cũng coi như là để giới thiệu về async/await trên ES8.

Ví dụ dưới đây cũng sẽ cho ta thấy cách tìm kiếm một JSON file nhờ vào  promises. Đây là ví dụ của Jake Archibald thuộc developers.google.com.

function fetchStory() {
    get('story.json')
    .then(function (response) {
        return JSON.parse(response)
    })
    .then(function (response) {
        console.log('Yey JSON!', response)
    })
}

Nhờ vào co library và một generator, code của chúng ta sẽ nhìn giống như synchronous code.

 

const fetchStory = co.wrap(function* () {
    try {
        const response = yield get('story.json')
        const text = yield JSON.parse(response)
        console.log('Yey JSON!', response)
    }
})

Với async/await thì nó vẫn sẽ khá giống so với phiên bản trên

async function fetchStory() {
    try {
        const response = await get('story.json')
        const text = await JSON.parse(response)
        console.log('Yey JSON!', response)
    }
}

 

Lời Kết

Dưới đây là một map thể hiện mối quan hệ giữa generators và iterators, bởi Axel Rauschmayer trên Exploring ES6.

Generators chính là một cách thực hiện của iterable và nó dựa theo luật của  iterable của iterator . Vì thế mà chúng có thể dùng để tạo ra iterables.

Tính năng tuyệt vời nhất của Generator là khiến execution bị hoãn lại. Với  yield nếu xài ES6.

Không những thế với  yield*, ta còn có thể gọi một generator nằm trong một generator khác.

Generators chính là cách thức để giúp việc phát triễn không đồng bộ trở thành đồng bộ.

Nguồn: Topdev via Medium

Java đang ngăn cản sự phát triển của Android và Kotlin không phải là cách giải quyết

Dưới đây là một số chia sẽ của Topdev tổng hợp được cho bạn về Android và Kotlin.Quá trình phát triển của Android từ 5 năm về trước như thế nào? Java đang ngăn cản sự phát triển của Android và Kotlin không phải là cách giải quyết. 

Hãy cùng tìm hiểu thêm từ bài viết dưới đây:

Java quá là rườm rà

Bnh thường thì bạn có thể dùng 2 phương pháp calls để làm nó nhưng với Java thì lại phải OOP rất nhiều cho cái solution rồi chạy code generation bởi với Google thì đó là cách duy nhất cho in-app purchase API. Như vậy, với một ngôn ngữ mà bạn không thể nào dùng callback khi thiếu class và platform (phụ thuộc rất nhiều vào hành vi không đồng bộ) thì kết quả là một đống code hỗn tạp lộn xộn.

Mặc dù Kotlin có giúp cho mọi chuyện bớt phức tạp hơn khi sử dụng cấu trúc nhôn ngữ hiện đại hơn. Tuy vậy, Android APIs vẫn được thiết kế để sử dụng với Java. Để cho công bằng thì Google thật sự đã cố gắng để đưa ra nhiều cải thiện với Java 8 support cho Android Studio 3.0 tuy nhiên nó sẽ cần mất nhiều năm nữa chúng ta mới thấy được thành quả của chúng.

Bản chất chậm chạp của Java khiến cho việc phải bỏ nhiều công sức hơn vào quá trình phát triển của một app

vòng đời hoạt động/dịch vụ/phát triển của các Android events quá phức tạp. Rất nhiều developer không hiểu rõ về nó cũng như bạn sẽ chẳng thể yêu cầu ai cũng bỏ quá nhiều thời gian chỉ để sử dụng chúng một cách rành rọt. Trong thời đại mà các ngôn ngữ đề cố gắng đơn giản hóa mọi thứ như iOS hoặc Windows Phone thì Java lại khiến mọi thứ phức tạp hơn.

Kotlin thì thêm overhead vào runtime, thế nhưng nó lại khiến cho ta phải bỏ ra thêm nhiều công sức hơn. Hị vọng rằng với Android reactive libraries mới cùng tính năng automated app lifecycle sẽ giúp khác phục vấn đề trên.

Ứng dụng nặng với quá trình xử lí phức tạp khiến cho việc thực hiện các iteration nhanh trở nên bất khả thi và làm cho Andiord không thân thiện với người dùng

Nếu bạn muốn ứng dụng của mình sử dụng được Google APIs, Firebase hay một libraries của nhóm thứ 3 mà vẫn giữ được tốt độ lặp nhanh (iteration) thì phải có một workstation  với CPU và SSD cực khủng. Google hiện vẫn đang tập trung đầu tư phát triển Java nhưng nó vẫn chưa thật sự thích hợp cho máy tính phổ thông chạy tốt ở thời điểm hiện tại. Như vậy các developer sẽ phải chi tiền ra để nâng cấp máy tính của mình và như vậy phần lớn bộ phận người dùng sẽ bị cho ra rìa. Theo tôi, các ngôn ngữ lập trình phải thật đơn giản và tiện lợi cho người dùng để họ có thể tạo sản phẩm phù hợp với mình chứ không thể đi theo hướng ngược lại khi mà bắt họ phải tự bơi hoặc là chết chìm được.

Kotlin cũng hỗ trợ các libraries cũng đòi hỏi việc ta tốn nhiều chi phí nếu bạn thật sự muốn nó đoàng hoàng. Ít ra thì Google cũng đang cố gắng giải quyết vấn đề trên bằng cách cải thiện quá trình tối ưu hóa của nó.

Web Apps

Rất vui khi Google I/O tung bố Android web app integrations. Google có lẽ đã hiểu rằng để Android có thể phát triển thì phải tập trung vào mảng web apps cho nó.

Trong tương lai không xa thì sẽ không ai dùng Java hay Kotlin để làm app cả. Google đang rất nổ lực để cải thiện tình hình trên khi hãng liên tục hỗ trợ cộng đồng lập trình viên của Java. Và Topdev hi vọng web app sẽ trở lại một cách huy hàng trên ngôn ngữ lập trình Java và Kotlin.

Nguồn: Topdev via Hackernoon

Tham khảo thêm các vị trí tuyển dụng lập trình android tại đây

Tình hình AI tại thị trường Việt Nam – Đầy khó khăn và thách thức

Cứ thử nhắc tới “artificial intelligence”, “machine learning”, hay “neural nets” cho bất kì nhóm software engineers nào mà bạn gặp, tôi bảo đảm bạn sẽ nghe một đống chuyện từ họ. Trong thời đại này, tất cả các ông lớn về công đều sẵn sàng chi mạnh tay để có thể tối ưu hóa những công nghệ đấy vào sản phẩm của họ. Kể cả những cá nhân software engineer trẻ cũng cố gắng tham gia vào mỏ vàng trên.

Artificial intelligence thực chất chính là cách ta tái tạo và mô phỏng theo trí não của con người. Mục tiêu là để cho ra đời những bộ máy có khả năng nhận ra những chi tiết mà chỉ có con người mới hiểu được như cảm xúc. Và đó không phải là một điều dễ dàng. Chính vì thế mà hôm nay, Vietcetera phỏng vấn anh Herve Vu Roussel, Head of Data Engineering tại AI firm Sentifi, để chia sẻ về những suy nghĩ của anh về AI tại Việt Nam. Chúng ta sẽ hiểu thêm về một trong những người đi đầu về Vietnam’s AI cũng như cộng đồng và khả năng phát triển cho AI tại thị trường Việt Nam.

Tình hình phát triển AI của Việt Nam như thế nào?

Đây là một câu hỏi khó. Bởi không như San Francisco hay Montreal, Vietnam’s AI  vẫn chưa thật sự được phát triển hết tiềm năng của nó. Chúng ta vẫn còn đang đi lên. Nói đến một số cá nhân/ tổ chức nổi bật thì tôi nghĩ tới Tinypulse và Trusting Social. Với khảo sát, phân tích cảm xúc, natural language processing, Tinypulse nhắm tới cải thiện tinh thần cho nhân viên và khiến họ gắn bó với công ty. Trusting Social, theo tôi, là một ngôi sao đang lên. Là đối tác với Viettel, công ty vừa kêu gọi vốn thành công lên đến vài triệu đô. ý tưởng đằng sau Trusting Social là liên quan đến việc tính toán và phỏng đoán các con số. Khá là thú vị bởi khả năng ứng dụng cho nhiều lĩnh vực khác nhau của nó.

Tình hình AI tại thị trường Việt Nam - Đầy khó khăn và thách thức

Tôi nghĩ thì hiện tại Sentifi vẫn đang đứng đầu những công ty mạnh về AI tại Việt Nam. Chúng tôi là công ty đi tiên phong về sử dụng mảng trí tuệ nhân tạo trong non-trivial applications. Nhóm data engineering của chúng tôi sử dụng machine learning, deep learning, và AI để phân tích hơn một tỉ tweets mỗi tháng để thu được insight từ đám đông. Sau đó dựa vào những data đó chung tôi liên hệ với những phân tích từ thị trường tài chính. Đó là cách giải thích đơn giản nhất mà tôi có thể đưa ra. Điều làm khác biệt Sentifi với các đối thủ khác nằm ở việc các sản phẩm của hãng đều tích hợp những công nghệ đi đầu thị trường Việt Nam

Tình hình AI tại thị trường Việt Nam - Đầy khó khăn và thách thức

Tôi tin rằng trong tương lai không xa, AI sẽ giúp cải thiện chất lượng dịch vụ tại Việt Nam. Ví dụ như giờ bạn đã có thể khám online, có một AI chuyên theo dõi sức khỏe và chăm sóc nhắc nhở bạn hay việc gửi hình X-quang để cho nó phỏng đoán bệnh tình mà không hề thua kém một bác sĩ thực thụ.

Có cộng đồng AI nào lớn tại Việt Nam không?

Thật không may là hiện tại vẫn chưa có. Chỉ vài nhóm nhỏ lẻ trên Facebook với tính tương tác thấp. À mà tháng 3 vừa rùi, IBM AI XPRIZE có tổ chức sự kiện AI đầu tiên tại Việt Nam. Với hơn trăm người tham dự. Bạn có thể nói mọi người đều rất tò mò và muốn tìm hiểu về AI nhưng phần lớn đều chưa có kinh nghiệm hay đủ trình độ để hiểu sâu về nó. Vì vậy mà chúng tôi cũng đang cố gắng thúc đẩy AI tại Việt Nam nhưng nó sẽ mất thêm một khoảng thời gian nữa lận.

Từng làm việc vài lần với AI XPRIZE cũng như hướng dẫn nhiều teams tại Việt Nam, XPRIZE là một tổ chức phi lợi nhuận chuyên khuyến khích tranh tài nhằm cải thiện kiến thức chung của thế giới. Tổ chức này cũng lên một kế hoạch phát triển AI trong vòng 4 năm nhằm giải quyết các vấn đề nan giải của nhân loại. Phần thưởng cho team thắng cuộc là 5 triệu đô và cơ hội được diễn thuyết tại TED 2020. Ngoài ra nhiều công ty và nguồn lực sẽ hộ trợ cho các nhóm tham gia XPRIZE. Tôi muốn gửi thông điệp rằng Việt Nam có tiềm năng rất lớn trong AI.

Tình hình AI tại thị trường Việt Nam - Đầy khó khăn và thách thức

Nói về công việc của tôi với XPRIZE, tôi chủ yếu nắm vai trò hướng dẫn và giúp các team Việt Nam. Hiện các nhóm đều có cho mình những project khá thú vị. Như Altoera với ý tưởng kết hợp computer vision, hardware, và software nhằm tạo ra tính năng image recognition để phát hiện sâu bệnh của cây trồng. Hiện mọi thứ chỉ ở software nhưng trong tương lai thì chúng tôi sẽ phát triển cả robot để chúng theo dõi và diệt trừ sâu bệnh luôn. Một project khác cũng rất có triển vọng là Dropdeck, với ý tưởng kết nối các nhà đầu tư với  startup entrepreneurs và giúp bảo đảm các startup có thể tìm kiếm nguồn vốn đầu tư dễ dàng hơn.

Tham khảo các vị trí tuyển dụng AI lương cao tại đây:

Lời khuyên của anh đối với những bạn muốn đột phát vào ngành này?

Hãy tìm kiếm thông tin tuyển dụng của các công ty AI và vào làm cho họ. Ngoài ra hãy có những project của riêng mình cũng như tham gia một số cuộc thi trên Kaggle. Ngoài ra còn rất nhiều nguồn online với hình thức tượng tự như Coursera, gồm các khóa học từ các đại học danh tiếng trên thế giới. Không có lí gì mà bạn không thể tự học trong hời đại internet này.

Tình hình AI tại thị trường Việt Nam - Đầy khó khăn và thách thức

Điều gì đang cản trở sự phát triển của AI tại Việt Nam?

Một trong những vấn đề lớn nhất là đầu vào quá khó. Mất 1 đến 2 năm chỉ để nghiên cứu tìm hiểu là chuyện thường ở huyện, rồi việc thiếu hụt về sức người – không có đủ người giỏi hiểu biết về machine learning cũng như data scientists. Hơn nữa, AI còn khá mới lạ, ngay cả trên thế giới thì số lượng công ty chuyên về trí thông minh nhân tạo cũng còn khá ít, như vậy sẽ khiến chi phí cho phát triển tăng rất nhiều.

Một vấn đề nan giải khác tại Việt Nam là việc có quá ít dữ liệu và thông tin. Mà khi nói về AI thì data luôn đứng top quan trọng hàng đầu. Việt Nam rất nghèo về khoảng này. Nói chi đâu xa, khi bạn xài Google Maps, thỉnh thoảng sẽ có những đường không hề có trên map. AI thực chất chính là việc chúng ta thu thập và sử dụng data để tạo ra nó. Như vậy nếu không có dữ liệu thì AI coi như chết.

Tình hình AI tại thị trường Việt Nam - Đầy khó khăn và thách thức

Cái nữa là việc phát triển AI vẫn chưa được ủng hộ và khuyến khích tại Việt Nam. Bởi vì do giá lao động còn thấp nên việc áp dụng AI thật sự không hiệu quả. Đơn cử như việc dùng robot bảo vệ. Nội tiền phát triển và bảo trì nó thôi đã mắc  gấp mấy chục lần việc thuê bảo vệ. Vậy AI chỉ thực sự có đất dụng võ khi người Việt mình được cải thiện về đời sống về có mức lương cao.

Tuy vậy, giờ chúng ta đã bắt đầu nghiêm túc hơn về vấn đề trí thông minh nhân tạo. Bạn có thể thấy Google đang dần trở thành một công ty về AI. Điều Việt Nam có thể làm là đẩy mạnh nhiều chương trình cho data engineering, data mining, và databases. Nhưng quan trọng nhất là tạo ra một cộng đồng và nuôi dưỡng nó. Thật may là công nghệ phát triển rất nhanh. Hồi 10 năm trước, để kiếm được việc liên quan tới AI có thể gọi là không thể bởi nó như chỉ dành cho phim ảnh viễn tưởng thôi. Nhưng giờ thì các start-up AI bắt đầu xuất hiện trên toàn thế giới.

Tình hình AI tại thị trường Việt Nam - Đầy khó khăn và thách thức

Anh có muốn gửi lời chia sẻ gì đến các bạn đọc không?

Bởi việc AI trở nên khá hot nên nhiều startup cứ áp dụng nó tùm lum vào mọi thứ họ có thể. Tôi mong các bạn start-up nên nhớ quan trọng nhất vẫn là sản phẩm của mình có khả năng giải quyết vấn đề thật cho khách hàng thật vẫn là điều quan trọng nhất, AI chỉ là một phương tiện giúp ta đạt được điều đó.

Nguồn: Vietcetera

1...216217218...230Page 217 of 230