Home Blog Page 210

FPT Telecom – tập trung vào viễn thông lấy khách hàng làm trung tâm

Từ một mạng thông tin với nhân sự chỉ gồm 4 người, đến nay, FPT Telecom đã trở thành một trong những nhà cung cấp dịch vụ Internet hàng đầu ở Việt Nam.

Là thành viên thuộc Tập đoàn Công nghệ hàng đầu Việt Nam, FPT Telecom hiện là một trong những nhà cung cấp dịch vụ viễn thông và Internet có uy tín và được khách hàng yêu mến tại Việt Nam và khu vực. Mặc dù ra đời sau, nhưng FPT Telecom đang là nhà cung cấp đi tiên phong trong việc triển khai hạ tầng trong hàng loạt dịch vụ số chiến lược như: Internet băng rộng ADSL, điện thoại băng rộng, truyền hình băng rộng, trò chơi trực tuyến…

Với sứ mệnh đưa Internet đến với người dân Việt Nam và mong muốn mỗi gia đình Việt Nam đều sử dụng ít nhất một dịch vụ của FPT Telecom cùng phương châm “Khách hàng là trọng tâm”, FPT Telecom không ngừng nỗ lực đầu tư hạ tầng, nâng cấp chất lượng sản phẩm – dịch vụ, là đơn vị đi tiên phong trong việc triển khai hạ tầng ftth, các ứng dụng công nghệ hiện đại vào các đường truyền internet và truyền hình

Với việc triển khai hạ tầng ftth vào triển khai cho cá nhân của FPT Telecom đã phát triển nên một cuộc cách mạng về việc đưa vào hoạt động các tuyến cáp quang biển mà các khu vực trên thế giới đã đưa vào hoạt động từ trước đó, với việc đưa vào hạ tầng ftth khai thác, Cá nhân được cam kết sử dụng đường truyền internet tốc độ cao, ổn định và hạn chế mức tối thiểu các yếu tố ảnh hưởng từ môi trường bên ngoài.

Sau 20 năm hoạt động, FPT Telecom đã lớn mạnh luôn đạt tốc độ tăng trưởng từ 70-100% mỗi năm. Tới nay, FPT Telecom đã có hơn 7,000 nhân viên chính thức, gần 200 văn phòng điểm giao dịch thuộc hơn 80 chi nhánh tại 59 tỉnh thành trên toàn quốc với các giải thưởng tiêu biểu trong nước lẫn quốc tế như:

➤ Giải thưởng Doanh nghiệp chuyển đổi kỹ thuật số ATSA 2016
➤ Huy chương Vàng ICT Việt Nam 2015 & Huy chương Vàng đơn vị Internet, Viễn thông 2012 & Huy chương Vàng đơn vị CNTT-TT Việt Nam 2006
➤ Thương hiệu Việt tiêu biểu 2014
➤ Doanh nghiệp dịch vụ được hài lòng nhất 2013
➤ ISO 9001, ISO 27001, ISO 50001, ISO 20000, Uptime TIER III
➤ Đối tác Vàng (Gold Partner) Microsoft 2016, Đối tác Vàng (Gold Partner) CISCO 2015, Đối tác Hiệu quả (Best Performance) DELL 2017…

Xem ngay: fpt shop tuyển dụng it

                fpt software tuyển dụng

Những cột mốc lớn của FPT Telecom:
➤ 2007: Trở thành thành viên chính thức của Liên minh AAG (Asia America Gateway – nhóm các công ty viễn thông hai bên bờ Thái Bình Dương).
➤ 2008: Trở thành nhà cung cấp dịch vụ Internet cáp quang băng rộng (FTTH) đầu tiên tại Việt Nam và chính thức có đường kết nối quốc tế từ Việt Nam đi Hồng Kông.
➤ 2009: Đạt mốc doanh thu 100 triệu đô la Mỹ và mở rộng thị trường sang các nước lân cận như Campuchia
➤ 2012: Hoàn thiện tuyến trục Bắc – Nam với tổng chiều dài 4000km đi qua 30 tỉnh thành
➤ 2015: Chính thức được cấp phép kinh doanh tại Myanmar và là một trong những đơn vị dẫn đầu trong triển khai chuyển đổi giao thức liên mạng IPv6.
➤ 2016: Khai trương Trung tâm Dữ liệu FPT Telecom mở rộng chuẩn Uptime TIER III với quy mô lớn nhất miền Nam. Được cấp phép triển khai thử nghiệm mạng 4G tại Việt Nam và là doanh nghiệp Việt Nam đầu tiên nhận giải thưởng Digital Transformers of the Year của IDC năm 2016.

Truy cập fpt.vn để tìm hiểu tất cả những sản phẩm, dịch vụ của “ông lớn” trong ngành công nghệ này & đừng quên đặt 1 slot tham dự Vietnam Web Summit 2017 tại https://vietnamwebsummit.com/vi/ve-tham-du/ để gặp gỡ FPT Telecom bạn nhé!

Làm thế nào để hack được hệ thống tracking bug của Google để đổi lấy $15,600 tiền thưởng

Bạn đã từng nghe đến Google Issue Tracker chưa? Nếu không phải là nhân viên Google hay developer từng report bugs trong các công cụ của Google gần đây thì có thể bạn sẽ chưa nghe đến. Thực ra tôi cũng vậy cho đến khi phát hiện các báo cáo lõ hổng xảy ra khi mở 1 thread mới, kèm theo các email notifications thông thường.

Vì vậy, tôi đã ngay lặp tức phá nó.

Vậy chính xác thì website này là gì? Theo documentation, Issue Tracker (được gọi nội bộ là Buganizer System) là 1 công cụ được sử dụng in-house tại Google để theo dõi các requests về bugs và tính năng trong quá trình phát triển product. Google cũng công bố rộng rãi Issue Tracker để cộng đồng và partner sử dụng khi muốn phối hợp với các teams của Google trong những dự án đặc biệt.

Nói cách khác, khi ai đó có vấn đề với 1 sản phẩm Google, thì vấn đề sẽ xuất hiện trên tracker issue. Chúng ta, những users bên ngoài chỉ có thể thấy được 1 phần của tảng băng trôi: 1 tập nhỏ các categories được chấp thuận trước và các vấn đề được người của Google thêm vào tài khoản bên ngoài, như các báo cáo về lỗ hổng bảo mật. Nhưng có bao nhiêu thông tin được che giấu dưới tảng băng đó?

Bằng cách quan sát các IDs số được chỉ định trong các public threads mới nhất, chúng ta có thể dễ dàng ước lượng được mức độ mà công cụ này được sử dụng nội bộ. Có khoảng 2000-3000 issues mỗi giờ được mở trong giờ làm việc tại Mountain View, và chỉ 0,1% trong số đó là public. Dường như lỗ hổng dữ liệu trong hệ thống này sẽ gây ảnh hưởng lớn, vậy nên cứ phá nó thôi!

Nỗ lực #1: Tạo 1 Google account dành cho nhân viên

Điều đầu tiên mà tôi phát hiện khi khám phá issue tracker là khả năng tham gia vào các cuộc thảo luận bằng cách gửi emails đến 1 địa chỉ cụ thể như là:

buganizer-system+componentID+issueID@google.com

(trong này componentID là số thể hiện 1 category và issueID là 1 unique identifier cho thread mà bạn đang làm việc)

Cái này làm tôi nhớ đến phát hiện gần đây gọi là Ticket Trick, cho phép hackers xâm nhập vào hệ thống chat của các tổ chức thông qua dạng email system tương tư. Vì đây là địa chỉ email @google.com, tôi đã cố gắng đăng nhập vào Slack team của Google đang sử dụng email này và trang xác nhận mà tôi có trông khá triển vọng:

Nhưng mà không có email của Slack hiển thị lên.

Điều tuyệt vời tiếp theo mà tôi có thể nghĩ đến là việc có 1 account Google với địa chỉ email chính là @google.com sẽ đem đến vài quyền lợi đặc biệt trên Buganizer. Bạn sẽ không được phép đăng kí 1 account như vậy ngoài Google:

Tuy nhiên, tôi nhận ra 1 method để vượt qua bước lọc này: Nếu đăng kí với địa chỉ email giả bất kì, nhưng không thể xác nhận tài khoản bằng cách click vào link nhận từ email, tôi được phép thay đổi email address không giới hạn. Sử dụng method này giúp tôi thay đổi email của 1 Google account hoàn toàn mới thành buganizer-system+123123+67111111@google.com.

Ngay sau đó, tôi nhận được email xác thực như 1 tin nhắn trên trang issue tương ứng:ge:

Tốt, tôi đã click vào link confirmation, đăng nhập vào Issue Tracker và…

Tôi được điều hướng đến trang login liên kết. Nhưng mà thông tin Google account của tôi lại không hoạt động được ở đó. Haizz.

Tuy nhiên, account này mang đến nhiều quyền lợi ở những nơi khác trên Internet, bao gồm khả năng hitch a ride (hình như miễn phí?), như vậy đây vẫn là 1 vấn đề bảo mật chào đón các users có ý đồ xấu.

Accepted: 11 hours | Bounty: $3,133.7 | Priority: P1


Nỗ lực #2: Nhận thông báo về các tickets nội bộ

Một tính năng khác của Issue Tracker thu hút sự chú ý của tôi khi đang làm quen với UI là khả năng đánh sao các items. Đánh giá 1 issue đồng nghĩa là bạn đang quan tâm đến vấn đề đang được thảo luận và bạn muốn nhận email notifications khi ai đó comment.

Tính năng đặc biệt thiếu đi các lỗi khi cố gắng sử dụng tính năng này trên các vấn đề mà tôi đã không thể tiếp cận được. Các quy tắc kiểm soát quyền truy cập dường như không bao giờ được áp dụng cho endpoint này, nên tôi đã đăng nhập vào account thứ 2 của mình và cố gắng đánh dấu sao lên 1 báo cáo lổ hổng từ account chính bằng cách thay thế Issue ID trong request. Sau đó, tôi thấy message này, đồng nghĩa là action của mình đã thành công.

1 person has starred this issue.

Có phải rất dễ dàng để do thám các lổ hỗng mở của Google không? Tôi nhanh chóng dăng 1 comment vào vấn đề để xác định xem thử liệu tài khoản tấn công hư cấu của mình có được thông báo không.

Nhưng 1 lần nữa, không có email nào hiện lên hết.

Vì vài lý do nào đó không nhớ rõ nữa, tôi đã quyết định thực hiện vài testing khác. Vì vậy, tôi đã có 1 issue ID mới, và ngoại suy hàng ngàn IDs trùng khớp với các issues mới nhất trong database. Sau đó tôi đánh sao hết tất cả.

Trong vòng vài phút, inbox của tôi trở thành như này:

Khi xem xét kĩ hơn, thực ra không có gì quá thú vị diễn ra trong những threads đó. Rõ ràng là tôi chỉ có thể “rình” được những đoạn trò chuyện liên quan đến dịch thuật, nơi mà mọi người sẽ tranh luận những cách truyền tải ý nghĩa của 1 câu nói theo nhiều ngôn ngữ khác nhau 1 cách tốt nhất.

Tôi thậm chí còn cân nhắc không report lỗi này, hy vọng sẽ tìm được cách để tăng mức độ nghiêm trọng lên. Cuối cùng tôi nhận ra team bảo mật của Google có thể sẽ hứng thú với việc tìm ra các methods & biến số then chốt có thể xảy ra nên là tôi cứ gửi thông tin chi tiết.

Accepted: 5 hours | Bounty: $5,000 | Priority: P0


Nỗ lực #3: Game over

Khi bạn xem xét Issue Tracker trên vai trò là 1 user bên ngoài, hầu hết tính năng của nó đã bị loại đi, nên bạn sẽ bị giới hạn nhiều quyền lợi. Nếu muốn thấy được những điều thú vị mà các nhân viên Google có thể làm được, bạn có thể tìm các API endpoints trong các files Javascript. Một vài function bị vô hiệu hoàn toàn, trong khi 1 số khác bị dấu trong interface.

Khi thiết kế bản giới hạn của hệ thống, 1 ai đó tốt bụng sẽ để lại trong 1 method để chúng ta remove bản thân khỏi danh sách CCs, trong trường hợp chúng ta không còn hứng thú với 1 issue hoặc không muốn nhận emails về nó nữa. Có thể làm được điều này bằng cách gửi 1 request POST như thế này:

POST /action/issues/bulk_edit HTTP/1.1
{
   "issueIds":[
      67111111,
      67111112
   ],
   "actions":[
      {
         "fieldName":"ccs",
         "value":"test@example.com",
         "actionType":"REMOVE"
      }
   ]
}

Tuy nhiên, tôi nhận ra vài chuyện vô ý dẫn đến 1 vấn đề lớn:

  1. Quyền tiếp cận không phù hợp: Không có quy trình kiểm tra rõ ràng khi user hiện tại thực sự tiếp cận được vào các vấn đề chuyên biệt trong issueIds trước khi nỗ lực thực hiện action được cho trước.
  2. Thất bại lặng im: Nếu bạn cung cấp 1 địa chỉ email không có trong danh sách CCs, endpoint sẽ trả lại 1 message nói rằng email đã được remove thành công.
  3. Chi tiết vấn đề trong response: Nếu không có lỗi xảy ra trong quá trình action, 1 phần khác của system sẽ giả định rằng user đã có quyền lợi phù hợp. Vì vậy, chi tiết về vấn đề ID sẽ được trả lại trong HTTP response body.

Hiện tôi có thể xem thông tin chi tiết về mọi vấn đề trong database bằng cách thay thế issueIds trong request ở trên. Chính xác!

Tôi chỉ cố gắng xem 1 vài IDs liên tiếp, sau đó tự tấn công chính mình từ 1 account không liên quan để xác nhận mức độ nghiêm trọng của vấn đề này.

Đúng vậy, tôi có thể xem hết chi tiết các báo cáo lổ hỗng, kèm theo tất cả những thứ khác được host trên Buganizer.

Tệ hơn là, tôi có thể xâm nhập dữ liệu về rất nhiều tickets trong 1 request đơn, vì thế việc điều chỉnh tất cả các hoạt động nội bộ theo thời gian thực có lẽ đã không kích hoạt bất kì rate limiters nào.

Tôi đã nhanh chóng gửi chi tiết những gì mình khai thác được đến Google và đội ngũ bảo mật của họ đã phải vô hiệu endpoint bị ảnh hưởng 1 giờ sau đó. Response time thật ấn tượng!

Accepted: 1 hour | Bounty: $7,500 | Priority: P0


Khi tôi bắt đầu quá trình tìm kiếm lỗ hổng thông tin này, tôi nghiễm nhiên cho rằng nó sẽ trở thành Chén Thánh của Google bugs, vì nó tiết lộ thông tin về tất cả các bug khác (như HackerOne đã trả tối thiểu $10,000 cho vấn đề tương tự).

Nhưng tôi đã nhanh chóng nhận ra ảnh hưởng sẽ rất hạn chế vì tất cả các lổ hổng nguy hiểm đều bị vô hiệu trong 1 giờ đổ lại.

Tất nhiên tôi rất vui với số tiền kiếm được, hy vọng sẽ tìm được bugs trong các product khác của Google.

Nguồn: TopDev via medium.freecodecamp.org

Một số kinh nghiệm lựa chọn nhà cung cấp tên miền

Đăng ký tên miền tại Việt Nam hiện nay khá đơn giản và nhanh chóng. Chỉ cần chưa đầy 15 phút là bạn có thể sở hữu 1 tên miền yêu thích, chỉ cần lựa chọn nơi mua tên miền rồi tiến hành đăng ký và thanh toán ngay trên website của nhà cung cấp. Nhưng giữa “thượng vàng, hạ cám” những nhà cung cấp tên miền hiện nay, làm thế nào để có thể lựa chọn đúng nhà cung cấp tên miền đáp ứng được như cầu của bản thân?

Một số kinh nghiệm lựa chọn nhà cung cấp tên miền 

Trước khi bạn muốn mua domain của một doanh nghiệp nào đó, bạn nên tìm hiểu thật kỹ về doanh nghiệp dựa trên tiêu chí sau:

  • Giá cả: Không phải cứ đắt tiền là sẽ tốt cho nên đừng quá phung phí vào vấn đề này nhưng cũng nên xem xét lại vấn đề tại sao chi phí đăng ký tên miền của dịch vụ này lại quá rẻ so với mặt bằng chung của thị trường.
  • Sự ổn định của nhà cung cấp: Nhà cung cấp cho bạn có thể tồn tại trên thị trường trong 1 thời gian dài? Rất ít công ty có thể trụ được trong ngành cung cấp dịch vụ cơ sở hạ tầng Internet ngày nay. Tuổi thọ của 1 công ty chính là dấu hiệu của sự ổn định.
  • Dịch vụ khách hàng: Bạn có nhận được sự trợ giúp khi bạn cần? Dịch vụ khách hàng đôi khi là một những khía cạnh mà mọi người sẵn sàng thỏa hiệp để có được chi phí thấp hơn. Nhưngtrước khi bạn quả quyết rằng yếu tố này không quan trọng cho lắm thì hãy xem xét đến sự thất vọng hay khả năng mất thu nhập khi bạn không nhận được sự trợ giúp khi cần.
  • Tham khảo những website xếp hạng cao những dịch vụ đó. Một website khá uy tín thì sẽ có xếp hạng cao về các dịch vụ hosting và domain dựa trên ý kiến của người dùng. Nếu bạn không thấy tên nhà cung cấp hosting mà bạn định đăng ký ở trong này, thì bạn nên suy nghĩ thật kỹ hoặc tham khảo kỹ lưỡng hơn nhé.

Verisign nhà cung cấp tên miền và dịch vụ DNS tin cậy

Là nhà cung cấp giải pháp hàng đầu toàn cầu trong lĩnh vực tên miền và bảo mật Internet, Verisign sở hữu các thư mục chính thức của các tên miền cấp cao như .com, .net, .cc, .tv và .name và hệ thống đăng ký của danh mục các tên miền cấp cao dùng chung, cũng như hai trong số 13 máy chủ gốc mạng Internet của thế giới.

Verisign cùng đội ngũ chuyên gia Internet của mình cũng đã xây dựng nên danh mục sản phẩm đáp ứng được nhu cầu của đa số các doanh nghiệp hiện nay gồm các dịch vụ DNS, đối phó với tấn công DdoS và Dịch vụ thông tin an ninh bảo mật iDefense. Đặc biệt, Verisign còn tư vấn các giải pháp để thương hiệu của bạn có được hiện diện trực tuyến tốt nhất.

Luôn đảm bảo an toàn, độ ổn định, độ sẵn sàng của các dịch vụ và cơ sở hạ tầng mạng Internet trọng yếu là lời cam kết chắc chắn mà Verisign mong muốn đến các khách hàng.

Bạn muốn tìm hiểu về tên miền và các dịch vụ DNS, bảo mật cho doanh nghiệp/ startup hay công việc của mình? Các chuyên gia Verisign sẽ giải đáp mọi thắc mắc của bạn tại Vietnam Web Summit 2017. Đăng ký tham dự ngay TẠI ĐÂY 

Sử dụng Laravel Mix với Webpack cho tất cả các assets

Laravel Mix cung cấp API để định dạng Webpack nhằm xây dựng các bước cho ứng dụng của bạn bằng rất nhiều pre-processors CSS & Javascript thông dụng.

Đây là định nghĩa lấy từ documentation. Nhưng ý nghĩa thực sự đằng sau đó là gì?

Laravel Mix

Laravel Mix được đặt trong các webpack configurations thông dụng và bạn có thể thêm nhiều configurations tùy chỉnh. Nếu bạn muốn sử dụng webpack thì cũng khá hay, nhưng thật ra configure webpack không hề dễ. Hoặc có thể các bạn muốn sử dụng ES2016 nhưng lại đọc phải rất nhiều bài phức tạp về loaders và modules.

Laravel Mix cho phép chúng ta sử dụng 1 line đơn để mô tả những gì bạn muốn và nó sẽ sử dụng các setting được preconfigure để xử lý 1 cách phù hợp.

Cài đăt Laravel Mix

Với Laravel

Nếu bạn đang sử dụng Laravel 5.4 trở về sau, thì mix đã được cài đặt. Tất cả những gì bạn phải làm là chạy npm install.

Standalone

Từ gốc ứng dụng của bạn, hãy chạy các commands sau:

npm init -y
npm install laravel-mix --save-dev
cp -r node_modules/laravel-mix/setup/webpack.mix.js ./

Trong file package.json hãy thêm đoạn sau:

    "scripts": {
        "dev": "NODE_ENV=development webpack --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js",
        "watch": "NODE_ENV=development webpack --watch --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js",
        "hot": "NODE_ENV=development webpack-dev-server --inline --hot --config=node_modules/laravel-mix/setup/webpack.config.js",
        "production": "NODE_ENV=production webpack --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js"
    }

Cài đặt đã xong.

Configure Laravel Mix

Hầu hết thời gian chúng ta sẽ dồn vào file webpack.mix.js. Trong file này, bạn sẽ thấy như thế này:

    let mix = require('laravel-mix');

    /*
     |--------------------------------------------------------------------------
     | Mix Asset Management
     |--------------------------------------------------------------------------
     |
     | Mix provides a clean, fluent API for defining some Webpack build steps
     | for your Laravel application. By default, we are compiling the Sass
     | file for your application, as well as bundling up your JS files.
     |
     */

    mix.js('src/app.js', 'dist/')
       .sass('src/app.scss', 'dist/');

Nó đã được preconfigured để compile 1 file ở src/app.js vào file dist/app.js và src/app.scss đến dist/app.css.

Có rất nhiều methods Mix khác và bạn có thể thấy tất cả các methods đó trong file default webpack.mix.js

    // Full API
    // mix.js(src, output);
    // mix.react(src, output); <-- Identical to mix.js(), but registers React Babel compilation.
    // mix.extract(vendorLibs);
    // mix.sass(src, output);
    // mix.standaloneSass('src', output); <-- Faster, but isolated from Webpack.
    // mix.fastSass('src', output); <-- Alias for mix.standaloneSass().
    // mix.less(src, output);
    // mix.stylus(src, output);
    // mix.postCss(src, output, [require('postcss-some-plugin')()]);
    // mix.browserSync('my-site.dev');
    // mix.combine(files, destination);
    // mix.babel(files, destination); <-- Identical to mix.combine(), but also includes Babel compilation.
    // mix.copy(from, to);
    // mix.copyDirectory(fromDir, toDir);
    // mix.minify(file);
    // mix.sourceMaps(); // Enable sourcemaps
    // mix.version(); // Enable versioning.
    // mix.disableNotifications();
    // mix.setPublicPath('path/to/public');
    // mix.setResourceRoot('prefix/for/resource/locators');
    // mix.autoload({}); <-- Will be passed to Webpack's ProvidePlugin.
    // mix.webpackConfig({}); <-- Override webpack.config.js, without editing the file directly.
    // mix.then(function () {}) <-- Will be triggered each time Webpack finishes building.
    // mix.options({
    //   extractVueStyles: false, // Extract .vue component styling to file, rather than inline.
    //   processCssUrls: true, // Process/optimize relative stylesheet url()'s. Set to false, if you don't want them touched.
    //   purifyCss: false, // Remove unused CSS selectors.
    //   uglify: {}, // Uglify-specific options. https://webpack.github.io/docs/list-of-plugins.html#uglifyjsplugin
    //   postCss: [] // Post-CSS options: https://github.com/postcss/postcss/blob/master/docs/plugins.md
    // });

Với đoạn code này, bạn có thể gói gọn nhiều nhất có thể và không cần phải lo lắng về webpack build căn bản.

Hỗ trợ SASS, LESS, Stylus, PostCSS, PlainCss… Và tất cả những gì bạn phải viết là 1 line single.

Compiling

Sau khi configure ứng dụng của bạn, có rất nhiều commands mà chúng ta có thể chạy.

npm run dev

Việc này sẽ build assets của chúng ta những không minify hay produce 1 build trong trạng thái sẵn sàng cho production.

Sử dụng Laravel Mix với Webpack cho tất cả các assets

npm run watch

Tương tự với npm run dev nhưng phải xem chừng các thay đổi với các assets của bạn và tự động recompile bất kì asset nào có thay đổi

npm run hot

Sẽ không chỉ refresh page khi 1 mảnh Javascript được thay đổi, nhưng nó cũng sẽ duy trì trạng thái hiện tại của component trong hệ điều hành.

npm run production

Sẽ compile tất cả các assets của bạn và produce 1 build sẵn sàng cho production. npm run production sẽ chạy tất cả tasks Mix và minify output.npm run production

Demo cơ bản

Hãy tạo 1 giao diện HTML “hư cấu” đơn giản với vài CSS & JS. Chúng ta muốn folder structure như thế này:

    app/
    |__public/ #webroot
    |    |__js/  #folder for JS files
    |    |__css/  #folder for CSS files
    |    |__media/  #folder for images and other files
    |
    |__resorces/
    |    |__scripts/ #folder for our source JS files 
    |    |__styles/ #folder for our source SASS files 
    |
    |__src/ #folder we want copied "as is" to the public directory.
    |
    package.json
    webpack.mix.js

Vậy file webpack.mix.js của chúng ta sẽ như thế này:

    let mix = require('laravel-mix');
    mix .js('resources/scripts/app.js', 'public/js/app.js')
       .sass('resources/styles/app.scss', 'public/css/app.css')
       .copyDirectory('src', 'public');

Trong ví dụ trên, chúng ta có 1 danh bạ public là nền tảng gốc. Chúng ta cũng có 1 file index.html sẽ là homepage của app.

Chúng ta muốn tất cả các files CSS sẽ nằm trong folder public/css. Hiện tại, chỉ có 1 file ở đó, là file app.css. Vì bạn đang sử dụng SASS, chúng ta sẽ sử dụng method sass() của  Laravel Mix để compile file app.scss vào app.css. Chúng ta sẽ sử dụng file tương tự để compile resources/scripts/app.js của chúng ta vào public/js/app.js.

Source code có sẵn ở đây và 1 bản demo được hiển thị ở đây.

Một ví dụ nâng cao hơn

Với dự án khác, chúng ta sẽ build nhiều sites tĩnh với cùng codebase. Nhưng source files compile đến các danh mục khác nhau. Cấu trúc folder sẽ như thế này.

 app/
    |__public/ #webroot
    |    |__site1/
    |    |    |__js/  #folder for JS files
    |    |    |__css/  #folder for CSS files
    |    |    |__media/  #folder for images and other files
    |    |    |__index.html 
    |    |
    |    |__site2/
    |         |__js/  #folder for JS files
    |         |__css/  #folder for CSS files
    |         |__media/  #folder for images and other files
    |    |    |__index.html 
    |
    |__site1/
    |   |__scripts/ #folder for our source JS files 
    |   |__styles/ #folder for our source SASS files 
    |   |__src/ #folder we want copied "as is" to the webroot
    |        |__media/ #folder for images and other files
    |        |__index.html 
    |
    |__site2/
    |   |__scripts/ #folder for our source JS files 
    |   |__styles/ #folder for our source SASS files 
    |   |__src/ #folder we want copied "as is" to the webroot
    |        |__media/ #folder for images and other files
    |        |__index.html 
    |
    |__package.json
    |__webpack.mix.js

Vì thế, chúng ta sẽ configure webpack.mix.js bằng cách này.

   let mix = require('laravel-mix');
    mix .js('site1/scripts/app.js', 'public/site1/js/app.js')
    .sass('site1/styles/app.scss', 'public/site1/css/app.css')
    .copyDirectory('site1/src', 'public/site1')
    .js('site2/scripts/app.js', 'public/site2/js/app.js')
    .sass('site2/styles/app.scss', 'public/site2/css/app.css')
    .copyDirectory('site2/src', 'public/site2');

Vì cả 2 sites đều tương tự nhau và có cùng dependencies, thì thay vì có 1 setup riêng cho mỗi site, chúng ta có thể dùng Laravel Mix để compile chúng đến các folders khác nhau, từ đây chúng ta có thể set thành các web roots riêng biết cho các sites tương ứng.

Sử dụng method này sẽ ngăn việc sở hữu 2 dự án riêng biệt và phải cài đặt, duy trì cùng set dependencies trong cả 2 dự án.

Structure này rất giống với bản demo đầu tiên, nhưng vì Laravel Mix cho phép chúng ta set đích đến compile, chúng ta có thể dễ dàng compile đến các folder khác nhau, và từ các folder này chúng ta sẽ sử dụng như webroot.

Chúng ta sẽ đặt tất cả source code cho site1 trong folder app/site1/, và site2 trong app/site2/. Trong những folder này, chúng ta sẽ có folder scripts/ cho các file JavaScript và folder styles/ cho các files SASS. Folder src dùng cho các files mà chúng ta chỉ muốn sao chép đến webroot.

Webroot cho các sites sẽ lần lượt ở trong public/site1/ và public/site2/

Source code nằm ở đây . Trong này, tên của các sites sẽ là Imperium và JustOfada, được host ở đây (imperium) và ở đây (justofada).

Webpack nâng cao

Laravel Mix thực sự có 1 file webpack.config.js được preconfigure mà Laravel Mix tham chiếu khi nó chạy. Nếu cần phải thêm vài config tùy chỉnh, bạn có thể chuyển webpack configuration bổ sung đến method mix.webpackConfig()

Để tùy chỉnh hoàn toàn Webpack configuration, hãy sao chép file node_modules/laravel-mix/setup/webpack.config.js đến root directory của ứng dụng. Sau đó chỉnh sửa file package.json và đưa tất cả các tham chiếu --config đến file configuration được sao chép mới.

Ví dụ:

   "scripts": {
        "dev": "NODE_ENV=development webpack --progress --hide-modules --config=webpack.config.js",
        "watch": "NODE_ENV=development webpack --watch --progress --hide-modules --config=webpack.config.js",
        "hot": "NODE_ENV=development webpack-dev-server --inline --hot --config=webpack.config.js",
        "production": "NODE_ENV=production webpack --progress --hide-modules --config=webpack.config.js"
    }

Kết luận

Khi nhìn vào các demo, bạn sẽ rằng ra Laravel Mix đã tiết kiệm được của chúng ta rất nhiều thời gian. Bạn sẽ không cần lo lắng về webpack configurations. Nếu chưa từng sử dụng webpack trước đây thì đây sẽ là công cụ tuyệt vời để bạn bắt đầu. Còn nếu đã từng sử dụng webpack thì công cụ này sẽ làm đơn giản hóa toàn bộ quy trình.

Tham khảo thêm các việc làm Laravel lương cao cho bạn

“Muốn đi nhanh phải dựa vào dev, muốn đi nhanh hơn nữa phải dựa vào khách hàng”

“Nếu bạn muốn cải thiện hiệu quả ở mọi lĩnh vực, hãy tập trung vào những gì quan trọng nhất. Không quan trọng bạn đang làm gì, hãy tập trung vào một số ít việc có ý nghĩa, và bỏ qua bớt những việc vô nghĩa” – Trích The 80/20 Principle: The Secret to Achieving More with Less (Richard Koch) –

Có lẽ bạn từng nghe đâu đó về “quy luật 80/20” hay còn được gọi là được biết đến với tên gọi là “quy luật Pareto” hay “quy luật nổ lực tối thiểu”. Đối với những bạn làm Marketing hay Sale thì không còn quá xa lạ gì với quy luật này, nhưng trong phát triển sản phẩm công nghệ thì việc vận dụng quy luật này có vẻ còn khá mới mẻ.

TopDev có may mắn được trò chuyện cùng anh Nguyễn Bá Thành – Customer Journey Project Director của Giao Hàng Nhanh (nay là Scommerce) được nghe anh kể về hành trình 5 năm của giaohangnhanh.vn và bài học kinh nghiệm ứng dụng quy luật 80/20 trong kinh doanh và phát triển sản phầm ở Scommerce.

Chào anh, anh có thể giới thiệu về Scommerce và các sản phẩm mà Scommerce đang cung cấp?

Scommerce khởi điểm là công ty giaohangnhanh, chuyên cung cấp dịch vụ giao nhận đầu cuối trong thương mại điện tử. Hiện nay, Scommerce đang phát triển các dịch vụ giao nhận bao gồm: giaohangnhanh, Ahamove, Cross-Board (giao  nhận quốc tế), dịch vụ vận tải đường dài, … và đang có kế hoạch phát triển một số sản phẩm khác nữa nhằm mục tiêu cải thiện tối đa trải nghiệm người dùng.

Sau 5 năm có mặt ở thị trường Việt Nam Scommerce cũng  đạt được một số kết quả đáng ghi nhận: top 3 (sau VNpost, Viettelpost) trong thị trường vận chuyển của thương mại điện tử, với hơn 8 triệu đơn hàng cùng 45 điểm gửi hàng và hơn 4000 nhân viên trong năm 2016, mạng lưới phủ rộng khắp 700 quận huyện trên cả nước, phục vụ 150.000 đơn hàng/ngày. Dự kiến trong năm 2017 Scommerce đạt doanh thu 1000 tỷ đồng với 27 triệu đơn hàng và 150 điểm gửi hàng.

Đó thực sự là những con số ấn tượng! Vậy điều gì đã giúp Scommerce đạt được những thành công “đáng ngưỡng mộ” đến như vậy?

“80% trải nghiệm khách hàng + 20% công nghệ = sản phẩm thành công”

Scommerce được xây dựng dựa trên nền tảng công nghệ nhưng công nghệ chỉ đóng góp 20% vào thành công của Scommerce, 80% còn lại là đến từ cải thiện trải nghiệm khách hàng.

Những giải pháp mà Scommerce cung cấp không chỉ là các giải pháp thuần công nghệ mà chủ yếu dựa vào các lợi thế sẵn có, hiện tại 2 lợi điểm lớn nhất mà Scommerce đang sở hữu là :

  • Hệ thống vận hành vận chuyển thuộc hàng tốt nhất ở Việt Nam hiện nay
  • Hệ thống mạng lưới điểm của Scommerce hiện nay đã phủ sóng toàn quốc ( kể cả ở các đảo Phú Quốc, Phú Quý, Cô Tô..)

80% thành công mà Scommerce có được đến từ giá trị cốt lõi mà Scommerce theo đuổi – customer first, suốt 5 năm qua Scommerce luôn tin tưởng vào giá trị “ tất cả vì sự hài lòng của khách hàng” .

Ví dụ: Khi phát triển một tính năng mới, nếu theo cách thông thường cần 1 tuần để đưa ra được giải pháp, nhưng nếu đứng từ góc độ của khách hàng thì chỉ tốn 2 ngày để phát triển tính năng mới. Sau đó, áp dụng quy trình Agile liên tục để cải thiện tính năng mới đó. Có thể thấy trong trường hợp này, các giải giải pháp công nghệ chỉ đóng vai trò là công cụ để thực hiện giải pháp, còn bản chất vẫn là dựa trên trải nghiệm khách hàng để đưa ra giải pháp.

“Muốn đi nhanh phải dựa vào dev, muốn đi nhanh hơn nữa phải dựa vào khách hàng”

Phát triển theo hướng không thuần Tech như vậy có khiến team dev của Scommerce gặp khó khăn gì không?

Thực ra, nó vừa khó vừa dễ. Đối với những bạn Dev có kinh nghiệm làm sản phẩm hướng tới khách hàng nhiều, có sẵn tư duy sản phẩm (product minset) thì không khó. Nhưng đối với các bạn Dev (đặc biệt với những bạn làm việc nhiều trong môi trường outsource) không có nhiều cơ hội làm việc với người dùng cuối thì có đôi chút khó khăn.

Các bạn sẽ gặp khó khăn khi khách hàng của các bạn không phải là người dùng đầu cuối nên có thể yêu cầu bị tam sao thất bản, chính vì vậy không thể nào hiểu chính xác yêu cầu của người dùng. Thứ 2 làm trong môi trường outsource bị chi phối bởi áp lực doanh thu nên nhiều khi nhu cầu của người dùng không phải là ưu tiên hàng.

Tìm ra giải pháp công nghệ không phải là điều quá khó, nhưng lựa chọn giải pháp nào là phù hợp nhất đảm bảo sự hài lòng của khách hàng mới là điều khó khăn nhất.

Sản phẩm của Scommerce cung cấp phải luôn được cải tiến từng ngày “ sản phẩm ngày hôm nay phải tốt hơn chính nó ngày hôm qua”, nó phải đáp ứng nhanh nhất nhu cầu của người dùng và thậm chí là đi trước nhu cầu của người dùng, vòng đời sản phẩm phát triển theo hình xoắn ốc mỗi ngày một phình to hơn.

Ở các công ty outsource thì quy trình sản phẩm không phát triển như vậy, nên những bạn lập trình viên từ môi trường Outsource sẽ gặp bất lợi hơn.

Anh có nói về tư duy sản phẩm, vậy anh định nghĩa như thế nào về tư duy sản phẩm? Và làm thế nào để có được tư duy sản phẩm?

Hiểu đơn giản tư duy sản phẩm là đặt mình vào vị trí khách hàng để làm ra sản phẩm, chứ không chỉ là làm sản phẩm cho ai đó dùng chứ không phải mình.

“Nếu khách hàng nói đó là ĐÚNG thì nhiệm vụ của mình là phải khiến cho điều đó trở thành ĐÚNG chứ không phải là chứng minh điều ngược lại”

Anh chia sẻ về câu chuyện ở Scommerce, các bạn software engineer ở công ty đôi khi vẫn phải đi giao hàng đó là yêu cầu “bắt buộc” (trong sự tự nguyện). Lúc trước khi công ty mới thành lập, nhân viên ít ngay chính bản thân anh vẫn phải dậy từ 5h sáng để giao hành cho khách ở sân bay, lúc đó là do yêu cầu khách quan. Bây giờ thỉnh thoảng anh ( cũng như các bạn software engineer khác) vẫn đi xuống kho, thực địa để trải nghiệm tính năng mới, hơn ai hết mình là người đầu tiên dùng sản phẩm và hiểu sản phẩm của mình.

Bên anh hiện tại không có bộ phận triển khai, chính các bạn software engineer sẽ là những người ra thực địa, trải nghiệm sản phẩm và tiến hành triển khai sản phẩm. Thực ra không có quy định bằng văn bản nào bắt buộc cả nhưng khi mọi người đều làm tự ra thực địa, tự trải nghiệm sản phẩm nếu mình không làm vậy thì sẽ bị đào thải. Ngay cả những đối tác của bên anh hiên nay cũng phải ra hiên trường, xuống kho, xuống đường trải nghiệm thử các sản phẩm trước khi bàn giao cho bên anh, thì có gì nhân viên của Scommerce không làm như vậy.Và thực tế đã chứng minh sau mỗi lần ra thực địa sẽ có một điều gì đó tốt hơn

Vấn đề lớn nhất mà Scommerce đang gặp phải hiện nay là gì?

Mỗi ngày Scommerce nhận được 150.000 đơn hàng/ngày, chỉ tính riêng dịch vụ Ahamove hiện tai có khả năng giao 45.000 đơn hàng/giờ. Câu hỏi đặt ra là: làm thế nào để rút ngắn thời gian giao hàng hơn nữa đảm bảo tính đồng bộ trong trải nghiệm cho tất cả khách hàng? là điều Scommerce quan tâm nhất hiện nay.

Anh đánh giá cao những ứng viên có tố chất như thế nào?

Đội ngũ mà mình mong muốn phải có tư duy 80-20, việc học hỏi công nghệ mới hoàn toàn có thể đào tạo được nhưng tư duy sản phẩm, nghĩ cho khách hàng là điều nhất thiết phải có.

Có 2 tố chất quan trọng mà anh đánh giá cao ở các bạn lập trình viên:

  • Trách nhiệm: ở đây trách nhiệm được hiểu theo nghĩa rộng, là trách nhiệm với toàn bộ sản phẩm chứ không chỉ là phần công việc mình đảm nhận.
  • Đặt hiệu quả của khách hàng lên hàng đầu, hơn cả việc khách hàng cần gì thì cung cấp cái đó mà ở đây là đứng về mặt hiệu quả cho khách hàng tức là cung cấp cho khách hàng trước cả những nhu cầu của họ.

Quy trình tuyển dụng lập trình viên của Scommerce sẽ bao gồm những bước nào?

Quy trình tuyển dụng hiện nay so với cách đây 5 năm so đã có nhiều thay đổi, dựa trên 2 tiêu chí quan trọng:

  • Góc nhìn về product:  đối với lập trình viên cấp bậc càng cao thì đòi hỏi các bạn có góc nhìn càng rộng, càng sâu từ phía khách hàng
  • Kĩ thuật : vì hiện nay Scommerce đang muốn hướng ra thị trường quốc tế nên các quy chuẩn tuyển lập trình viên phải đảm bảo quốc tế.

Cụ thể quy trình sẽ gồm các vòng:

  • Vòng test online : hiện tại bên anh đang áp dụng những bài test theo chuẩn quốc tế mà các công ty trên thế giới đang áp dụng. Bài test sẽ bao gồm tổng hợp nhiều kiến thức giúp đánh giá chính xác nhất điểm mạnh – điểm yếu của các bạn.
  • Từ cấp senior trở lên sẽ làm trực việc tham gia vào dự án để để đánh giá khả năng thích nghi với dự án của bạn đến đâu
  • Tiếp theo là làm việc với nhân sự hoặc với lead để xem kỹ năng mềm của bạn như thế nào
  • Đối với những bạn từ vị trí lead trở lên thì có một số buổi trò chuyện ( có thể là qua skype, đi ăn chung, cafe cuối tuần,..) để xem cách bạn quản lý team như thế nào, xử lý công việc ra sao, và gần như các thành viên trong team sẽ là người đánh giá bạn.

Vì sao lập trình viên nên chọn Scommerce để làm việc?

“Thử thách” chính là điều hấp dẫn nhất ở Scommerce.”

Các vấn đề gặp phải ở  Scommerce  nói thật là rất khó, đó phải không phải là vấn đề mà bạn đã từng gặp ở đâu đó, hay có thể tìm thấy nó ở đâu đó. Những vấn đề mà bạn phải đối mặt là những vấn đề “ nếu bạn không biết, thì không ai biết”. Chính vì vậy, mỗi lần tìm được giải pháp cho vấn đề gặp phải cảm giác rất sướng.

Tất nhiên, thử thách lớn thì kết tưởng thưởng bạn nhân được sẽ tương xứng với nổ lực của bạn.  Hiện tại bên Scommerce có 8 mức đánh giá năng lực, dựa trên những nổ lực của bạn sẽ có mức đánh giá năng lực khách quan nhất với năng lực của bạn

Anh có thể chia sẻ về kế hoạch trong thời gian tới của Scommerce?

Scommerce đang có kế hoạch mở rộng doanh nghiệp và phát triển thêm nhiều sản phẩm mới, chính vì vậy, đang rất cần nhiều tài. Câu chuyện lớn nhất mà Scommerce đang giải quyết là câu chuyện làm hệ thống Scommerce đang chuyển từ kiến trúc monolithic sang kiến trúc Microservice thử thách lớn nhất hiện nay là xây dựng một team dev có thể làm phát triển sản phẩm theo kiến trúc Micro service đồng thời cũng chuyển đổi được từ hệ thống cũ sang hệ thống mới.

Bên cạnh đó trong năm 2018 Scommerce sẽ đẩy mạnh chương trình training cho Junior và fresher, nếu bạn nào không ngại thử thách thích môi trường làm việc ở Scommerce thì có thể liên hệ với bên mình để được phỏng vấn và tham gia vào đội ngũ của bên mình.

Cảm ơn anh đã tham gia phỏng vấn và chia sẻ nhiều thông tin bổ ích cùng TopDev

Kinh doanh online hiệu quả hơn với Zalo Business

Trong thời điểm thị trường bán hàng qua Facebook đang dần “đất chật người đông”, rất nhiều cửa hàng, doanh nghiệp đã chuyển sang nền tảng Zalo để tìm kiếm những cơ hội mới.

Zalo là một ứng dụng thuần Việt đa phương tiện trên điện thoại di động, có tuổi đời còn khá non trẻ (thành lập năm 2012) nhưng đã nhanh chóng thu hút được sự quan tâm của đông đảo người dùng. Với số lượng người sử dụng liên tục tăng cao, được dự báo sẽ là kênh bán hàng online hiệu quả bên cạnh kênh bán hàng qua Facebook, giúp đa dạng hóa lựa chọn cho người bán. Vậy tại sao nên chọn Zalo để bán hàng online?

  • Zalo xuất hiện trong hầu hết thiết bị smartphone: Với 80 triệu người dùng, Zalo là nền tảng di động có lượng người dùng nhiều nhất tại Việt Nam.
  • Hạn chế lượng khách hàng “ảo”: Mỗi người đều cần có một số điện thoại riêng biệt thì mới có thể truy cập vào Zalo. Do đó, chúng ta có thể yên tâm về lượng khách hàng “bằng xương bằng thịt” của mình, tránh được tình trạng đơn hàng “ảo”.
  • Cách thức tiếp cận, chăm sóc khách hàng trực tiếp: Hệ thống Zalo Shop cho phép tạo ra 1 cửa hàng ngay trên ứng dụng Zalo, với giao diện và các tính năng được tối ưu nhất cho việc bán hàng trên di động. Chủ cửa hàng và khách hàng sẽ tương tác trực tiếp 1:1 với nhau từ khi khách hàng bắt đầu quan tâm đến sản phẩmZalo cũng cung cấp tính năng gửi tin nhắn BroadCast – cho phép chủ cửa hàng có thể cung cấp tin tức khuyến mãi, cập nhật sản phẩm mới hoàn toàn miễn phí.
  • Chính sách hỗ trợ ưu việt của Zalo: Là ứng dụng Việt Nam, nên Zalo hỗ trợ tốt cho các chủ cửa hàng, doanh nghiệp và nhà quảng cáo trong nước. Zalo Ads giúp các doanh nghiệp, chủ cửa hàng tự tạo quảng cáo và quản lý các chiến dịch nhắm tới khách hàng trên hệ sinh thái Zalo.

Zalo Business cung cấp các giải pháp giúp các doanh nghiệp kinh doanh và tiếp thị trên nền tảng ứng dụng nhắn tin Zalo bao gồm:

➤Messaging App: Xuất phát từ xu hướng người dùng chuyển từ Social Network sang nền tảng riêng tư hơn là ứng dụng nhắn tin
➤ Mobile E-commerce: Xuất phát từ xu hướng mua hàng qua thiết bị di động
➤ Omnichannel: Xuất phát từ xu hướng chủ doanh nghiệp bán hàng đa kênh, vừa có cửa hàng offline, vừa xây dựng gian hàng online và tích hợp chúng lại với nhau do hành vi của người dùng hiện tại có nhiều thay đổi khi thường research sản phẩm online nhưng lại mua hàng offline.

Zalo Business và những con số
➤ Người dùng Smartphone Việt Nam trung bình dành 68 phút trên Zalo mỗi ngày

➤Người dùng Việt Nam dành thời gian dùng Zalo cao gấp 10x các ứng dụng thông thường khác.

➤ 40.000+ cửa hàng trên Zalo Shop có tương tác mỗi ngày

➤ 80 triệu người dùng ứng dụng Zalo


🔥
 Còn chần chừ gì nữa mà không nhanh chóng đăng kí tham dự Vietnam Web Summit vào đầu tháng 12 này tại https://vietnamwebsummit.com/vi/ve-tham-du/ để gặp gỡ, trò chuyện cùng các chuyên gia của Zalo Business về Messaging App, Mobile E-commerce và Omnichannel!

Cách để npm packages chạy trong browser

Tôi thường để npm dependency hỗ trợ bên ngoài trong quá trình phát triển ban đầu của CodeSandbox. Tôi cứ nghĩ rằng việc cài đặt một cách tùy ý hay cho số lượng package trong browser theo ý thích luôn là việc không tưởng.

Ngày nay, hỗ trợ npm là một trong những tính năng làm nên CodeSandbox. Đã mất rất nhiều lần thử nghiệm và lặp để khiến nó có thể hoạt động được trong mọi trường hợp, chúng tôi cũng phải viết đi viết lại nhiều lần và tin rằng trong tương lai cũng phải như vậy. Tôi sẽ giải thích cách thức hỗ trợ NPM hoạt động, những gì đã được sửa và cũng như những cơ hội cải thiện thêm.

Phiên bản “đầu tiên”

Không biết bắt đầu như thế nào cho dễ nên tôi sẽ cho bạn xem hình dưới đây, vốn là phiên bản đầu tiên của hỗ trợ npm.

Có thể thấy tại phiên bản này, nó vô cùng đơn giản bởi còn không hẳn là hỗ trợ npm nữa. Tôi chỉ là tự cài đặt dependencies và quẹt các dependency call với chúng. Tất nhiên là cách này không thể thực hiện được với qui mô lớn khoảng 400,000 package, bao gồm nhiều phiên bản khác nhau.

Mặc dù “đầu tiên” không thể dùng được tốt, nó cũng đã tiếp thêm lửa nhiệt cho tôi tiếp tục làm thêm 2 dependencies hoạt động được trong một môi trường sandbox.

Phiên bản Webpack

Như nói trên, tôi đã rất hài lòng với phiên bản đầu tiên và cho rằng nó đủ khả năng cho một MVP. Tôi còn không nghĩ là nó có thể cài đặt bất kì dependency nào khác mà không phải cần tới phép màu nào cả. Mãi cho đến khi tôi gặp https://esnextb.in/. Họ đã hỗ trợ bất kì dependency nào từ npm, bạn chỉ cần define chúng trong package.json và nó sẽ tự hoạt động một cách thần kì.

Đây là một khoảnh khắc quan trọng của tôi do trước đó ý nghĩ hỗ trợ npm là bất khả thi luôn hiện hữu trong tôi. Sau lần bắt gặp định mệnh đó, ý tưởng mới liên tục nhen nhóm trong đầu tôi, quả thật đừng bao giờ từ bỏ khi bạn còn chưa thử qua.

Vậy là tôi dành thời gian suy nghĩ cách thức và nhận ra rằng phiên bản đầu tiên quá phức tạp hóa vấn đề lên thế nên tôi phải vẽ một sơ đồ đơn giản nó như sau:

Có một lợi thế trong cách tiếp vận phức tạp này: thực hiện nó hóa ra lại khá dễ.

Tôi đã học được rằng Webpack DLL Plugin có khả năng bundle các dependencies và cho ra một JS bundle với một biểu hiện (manifest) như sau:

{
  "name": "dll_bundle",
  "content": {
    "./node_modules/fbjs/lib/emptyFunction.js": 0,
    "./node_modules/fbjs/lib/invariant.js": 1,
    "./node_modules/fbjs/lib/warning.js": 2,
    "./node_modules/react": 3,
    "./node_modules/fbjs/lib/emptyObject.js": 4,
    "./node_modules/object-assign/index.js": 5,
    "./node_modules/prop-types/checkPropTypes.js": 6,
    "./node_modules/prop-types/lib/ReactPropTypesSecret.js": 7,
    "./node_modules/react/cjs/react.development.js": 8
  }
}

Mọi path đều được kết nối tới module của nó. Nếu tôi cần react thì sẽ chỉ cần call  dll_bundle(3) và tôi sẽ có React! Quá là tuyệt vời cho trường hợp của tôi nên ngay lập tức bắt tay vào làm và kết quả cho ra là như sau:

Cho mỗi request đến packager tôi sẽ phải tạo một directory mới trong /tmp/:hash, sẽ chạy  yarn add ${dependencyList} và để webpack được bundle ngay sau đó. Tôi thường lưu bundle mới này trên Gcloud như một cách caching. Đơn giản hơn so với biểu đồ, đa phần là vì tôi thay việc cài đặt dependencies với yarn và bundling với webpack.

Khi bạn load một sandbox, đầu tiên ta phải chắc chắn rằng phải có bundle và biểu hiện (manifest) trước khi đánh giá. Trong quá trình đánh giá, ta sẽ call dll_bundle(:id)  cho từng dependencies.

Tuy vậy, vẫn còn rất nhiều giới hạn trong hệ thống này. Nó không hề hỗ trợ những file nằm trong biểu đồ dependency của Webpack. Do đó, những trường hợp như require('react-icons/lib/fa/fa-beer') sẽ không hoạt động, bởi nó không bao giờ được yêu cầu bởi entry point của dependency.

Dù thế, tôi vẫn tung ra CodeSandbox với phiên bản này. Ngay sau đó, cha đẻ của WebpackBin, Christian Alfoni, đã liên lạc với tôi. Hóa ra chúng tôi đều có hệ thống khá tương tự nhau để hỗ trợ npm dependencies và đều gặp cùng một vấn đề. Do đó chúng tôi quyết định bắt tay hợp sức để tạo ra packager tối thượng!

Webpack với entries

Packager tối thượng vẫn giữ những tính năng có trong các phiên bản trước nhưng Christian có tạo một thuật toán sẽ thêm files vào bundle tùy theo tầm quan trọng của chúng. Điều đó có nghĩa là ta phải tự add thủ công các entry points vào để bảo đảm Webpack sẽ bundle cả những file đó. Sau rất nhiều chỉnh sửa, nó đã có khả năng hoạt động với bất kì tình huống nào.

Hệ thống mới cũng được nâng cấp về kiến trúc: chúng tôi có một dịch vụ dll với mục tiêu cân bằng load và cache. Ngoài ra, còn có nhiều packager thực hiện bundling.

Chúng tôi muốn mọi người đều có thể sử dịch vụ packager. Do đó mà chúng tôi đã làm ra một website để giải thích cách thức dịch vụ này hoạt động và cách mà bạn có thể dùng nó. May mắn thay ý tưởng trở nên cực kì thành công, CodePen blog cũng có nhắc tới chúng tôi.

Tuy vậy, vẫn có nhiều điểm yếu trong packager tối thượng. Chi phí tăng chóng mặt khi qui mô mở rộng. Ngoài ra, ta phải rebundle lại toàn bộ packager mỗi khi thêm vào một dependency mới.

Không cần máy chủ

Tôi luôn muốn thử qua công nghệ không cần máy chủ hay còn được gọi là ‘serverless’. Với nó bạn define một function vốn sẽ execute một request, function này sẽ tự hoạt động và thực hiện nhiệm vụ rồi sau đó tự xóa mình. Nhờ đó mà khả năng mở rộng của bạn là rất lớn, giả sử như bạn có 1000 request cùng một lúc thì sẽ không có vấn đề gì khi cho 1000 server thực hiện ngay lập tức. Điều này cũng có nghĩa bạn sẽ chỉ phải trả phí khi server chạy thôi.

Serverless nghe thực sự quá hoàn hảo cho dịch vụ của chúng tôi. Nó không hề chạy liên tục cũng như có thể chạy nhiều request cùng lúc. Do đó mà tôi khá hào hứng khi bắt đầu dùng tới Serverless.

Quá trình convert diễn ra khá là êm xui, mất chỉ 2 ngày để có một phiên bản chạy tốt. Và như vậy tôi tạo ra 3 serverless functions:

  1. Metadata resolver: nó chuyên giải quyết các versions và peerDependencies sau đó request packager function.
  2. Packager: nó chịu trách nhiệm cài đặt và bundling các dependencies.
  3. Uglifier: Giúp ngặn chặn các kết quả bị sai, lỗi khi bundle.

Tôi chạy song song hai dịch vụ mới và cũ khác nhau! Giá chi phí giảm từ $100 xuống còn có 0.18$  trong khi response time được cải thiện trong khoảng 40% tới 70%.

Tuy vậy, sau một thời gian dùng thì tôi nhận ra nó tồn tại một điểm yếu: một lambda function chỉ có tối đa 500MB disk space, như vậy có nghĩa là một số các dependencies sẽ không thể install. Đây là một yếu điểm chết người và tôi  

Serverless – Phiên bản mới

Một vài tháng trôi qua và tôi tung ra một bundler mới cho CodeSandbox. Nó cực kì mạnh mẽ, cho phép dễ dàng hỗ trợ nhiều libraries như Vue và Preact. Bằng việc hỗ trợ những libraries này chúng ta có nhiều requests khá thú vị. Ví dụ: Nếu bạn muốn dùng một React library trong Preact, thì sẽ cần thay  require('react') thành  require('preact-compat'). Còn với Vue, bạn sẽ muốn giải quyết `@/components/App.vue` tới sandbox files của mình. Packager của chúng tôi thì không làm cái này cho dependencies mà sẽ do bundler đảm nhiệm.

Đó cũng là lúc mà tôi chợt nghĩ sao không thử để browser bundler lo việc packaging? Nếu ta gửi các files cần thiết tới browser, chúng ta sẽ để bundler lo việc bundling của dependencies. Như vậy nó sẽ nhanh hơn, bởi vì ta không evaluate toàn bộ bundle mà chỉ một phần của nó.

Có một lợi thế cho cách thức này: chúng ta sẽ có thể install và cache dependencies một cách độc lập. Ta có thể hợp các dependency files trên client lại. Điều đó có nghĩa là nếu bạn request một dependency mới trên các dependencies đã có sẵn, chúng ta sẽ chỉ cần tập hợp các files cho dependency mới! Nhờ đó mà giải quyết vấn đề giới hạn 500MB từ AWS Lambda, bởi chúng ta chỉ install một dependency. Ta cũng có thể bỏ Webpack ra khỏi packager, bởi giờ đây nó chỉ chịu trách nhiệm việc phân loại file và gửi chúng đi.

Cách nó hoạt động

Khi chúng ta request một kết hợp các dependencies, đầu tiên sẽ check liệu nó đã có sẵn S3. Nếu không thì ta request từ dịch vụ api; khi đó nó sẽ request toàn bộ packager cho mỗi dependency. Ngay khi ta nhận được thông báo 200 OK thì sẽ lại request S3 lần nữa.

Packager installs các dependencies sử dụng yarn và tiếm kiếm tất cả các file liên quan bằng cách đi qua AST của mọi files trong directory của entry point. Nó tìm kiếm require statements và thêm chúng vào file list. Một ví dụ output (của react@latest) sẽ như sau:

{
    "aliases": {
        "asap": "asap/browser-asap.js",
        "asap/asap": "asap/browser-asap.js",
        "asap/asap.js": "asap/browser-asap.js",
        "asap/raw": "asap/browser-raw.js",
        "asap/raw.js": "asap/browser-raw.js",
        "asap/test/domain.js": "asap/test/browser-domain.js",
        "core-js": "core-js/index.js",
        "encoding": "encoding/lib/encoding.js",
        "fbjs": "fbjs/index.js",
        "iconv-lite": "iconv-lite/lib/index.js",
        "iconv-lite/extend-node": false,
        "iconv-lite/streams": false,
        "is-stream": "is-stream/index.js",
        "isomorphic-fetch": "isomorphic-fetch/fetch-npm-browserify.js",
        "js-tokens": "js-tokens/index.js",
        "loose-envify": "loose-envify/index.js",
        "node-fetch": "node-fetch/index.js",
        "object-assign": "object-assign/index.js",
        "promise": "promise/index.js",
        "prop-types": "prop-types/index.js",
        "react": "react/index.js",
        "setimmediate": "setimmediate/setImmediate.js",
        "ua-parser-js": "ua-parser-js/src/ua-parser.js",
        "whatwg-fetch": "whatwg-fetch/fetch.js"
    },
    "contents": {
        "react/index.js": {
            "requires": [
                "./cjs/react.development.js"
            ],
            "content": "/* code */"
        },
        "object-assign/index.js": {
            "requires": [],
            "content": "/* code */"
        },
        "fbjs/lib/emptyObject.js": {
            "requires": [],
            "content": "/* code */"
        },
        "fbjs/lib/invariant.js": {
            "requires": [],
            "content": "/* code */"
        },
        "fbjs/lib/emptyFunction.js": {
            "requires": [],
            "content": "/* code */"
        },
        "react/cjs/react.development.js": {
            "requires": [
                "object-assign",
                "fbjs/lib/warning",
                "fbjs/lib/emptyObject",
                "fbjs/lib/invariant",
                "fbjs/lib/emptyFunction",
                "prop-types/checkPropTypes"
            ],
            "content": "/* code */"
        },
        "fbjs/lib/warning.js": {
            "requires": [
                "./emptyFunction"
            ],
            "content": "/* code */"
        },
        "prop-types/checkPropTypes.js": {
            "requires": [
                "fbjs/lib/invariant",
                "fbjs/lib/warning",
                "./lib/ReactPropTypesSecret"
            ],
            "content": "/* code */"
        },
        "prop-types/lib/ReactPropTypesSecret.js": {
            "requires": [],
            "content": "/* code */"
        },
        "react/package.json": {
            "requires": [],
            "content": "/* code */"
        }
    },
    "dependency": {
        "name": "react",
        "version": "16.0.0"
    },
    "dependencyDependencies": {
        "asap": "2.0.6",
        "core-js": "1.2.7",
        "encoding": "0.1.12",
        "fbjs": "0.8.16",
        "iconv-lite": "0.4.19",
        "is-stream": "1.1.0",
        "isomorphic-fetch": "2.2.1",
        "js-tokens": "3.0.2",
        "loose-envify": "1.3.1",
        "node-fetch": "1.7.3",
        "object-assign": "4.1.1",
        "promise": "7.3.1",
        "prop-types": "15.6.0",
        "setimmediate": "1.0.5",
        "ua-parser-js": "0.7.14",
        "whatwg-fetch": "2.0.3"
    }
}

Lợi thế

Tiết kiệm chi phí

Với cái giá $0.02 cho 2 ngày deploy packager so với việc phải trả $100 một tháng.  

Hiệu năng cao

Giờ bạn có thể lấy một tỏ hợp mới của dependencies chỉ trong 3 giây trong khi với hệ thống cũ thì nó mất tới một phút.

Đa năng

Bundler giờ đây xử lí dependencies như là local files. Điều đó có nghĩa là error stack dễ theo dõi hơn, ta cũng có thể thêm bất kì file nào từ dependencies (như ,scss, .vue, etc.) cũng như dễ dàng hỗ trợ các thứ như aliases.

Release

2 ngày trước, tôi có dùng packager mới song song với cả cũ, để tạo cache. Nó đã cached 2,000 tổ hợp khác nhau và 1400 dependencies khác nhau.

Hãy dùng Serverless!

Tôi thật sự rất ấn tượng với serverless,nó khiến việc mở rộng server và quản lí cực kì dễ dàng. Điểm yếu duy nhất là khâu setup khá phức tạp, nhưng những thành viên tại serverless.com đã khiến nó trở nên dễ dàng đi rất nhiều. Tôi thật sự tin rằng serverless sẽ là tương lai của nhiều app trong thế giới lập trình.

Nguồn: TopDev via hackernoon

Liệu bạn có đang ngộ nhận kiến thức Digital Marketing của mình?

Đa phần những người làm Digital Marketing thời kì đầu đều không xuất thân từ Marketing, mà từ Web Designer, Web Administrator, Coder… nên dù bạn là ai, chỉ cần làm việc trong kỉ nguyên số thì nhất định không thể bỏ qua những chủ đề Digital Marketing hấp dẫn của Vietnam Web Summit tại Tp.HCM & Hà Nội trong tháng 12 này.

Xây dựng lại nền móng Digital Marketing từ những ngộ nhận sai lầm

Cách đây chừng 10 năm, nói về Marketing chúng ta sẽ nghĩ về 4P, Promotion Mix, SWOT… Nhưng gần đây, cụm từ Top-of-mind khi nhắc đến Marketing chính là Digital Marketing, thứ tự xếp hạng & từ khóa trên Google, là lượng traffic vào website, lượng like/ tương tác trên Facebook, là lượt view Youtube. Các thuật ngữ như Ad network, Publisher, CPM, CPC, Display Advertising, DSP, SSP, Performance Marketing… ngày càng được nhắc đến với tần suất dày đặc mà bất kì 1 nhà làm truyền thông, quảng cáo nào cũng không thể ngoảnh mặt làm ngơ.

Tất nhiên, Digital Marketing đã mở ra những giải pháp mới hiệu quả hơn, góp phần thay đổi và tạo nên cuộc cách mạng lớn trong ngành Truyền thông tiếp thị nhưng theo nhiều chuyên gia, không ít Digital Marketer hiện nay đang làm việc dựa trên những nền tảng sai lầm và sự thổi phồng quá mức của truyền thông khiến các bạn trẻ hình dung không đúng về công việc thực sự của các Digital Marketer – các Marketer trong kỉ nguyên Digital.

Chính vì vậy, các diễn giả của Vietnam Web Summit sẽ giúp bạn thoát khỏi những ngộ nhận chưa chính xác về Digital Marketing bằng những nội dung chia sẻ sâu sát và thực tế nhất.

  • Topic Đánh giá hiệu quả của chiến dịch Marketing cho KOLs & Viral TVC trên Facebook & Youtube của diễn giả Phan Dũng – CoFounder của Big Cat Entertainment
  • Topic Làm sao để tạo được content hiệu quả khi làm truyền thông? của diễn giả Diễn giả Nguyễn Ngọc Long – Sáng lập Truyền thông Trăng đen
  • Topic Xu hướng Digital Marketing 2018 của diễn giả Phạm Minh Toàn – CEO & Founder của Time Universal
  • Topic Tìm hiêu A/B Testing & tối ưu quảng cáo thời gian thực của diễn giả Nguyễn Văn Vững – Founder & CEO của AdTop
  • Topic Công việc thực sự của 1 Digital Marketer là gì? của diễn giả Nguyễn Duy Vĩ – CoFounder của Tugo
  • Topic How to optimize Google Conversions with Google Analytics của diễn giả Dương Quang Anh – Giám đốc MasOffer thuộc Eway
  • Topic All About Email Marketing của diễn giả Lại Tuấn Cường – CEO & Founder của Repu Digital

Trong đó, nổi bật nhất là “màn đấu khẩu” tranh luận hỏi xoáy đáp xoay, không ngại va chạm và tranh luận nẩy lửa để “tìm ra chân lý” của Viral Content & KOLs giữa anh Nguyễn Ngọc Long – Sáng lập Truyền Thông Trăng Đen và anh Phan Dũng – CoFounder của Big Cat Entertainment.

Đặc biệt, một trong những chủ đề “đinh” chắc chắn sẽ làm “nức lòng” cộng đồng Digital Marketer và Web developer của Vietnam Web Summit năm nay là Giải mã cách Thế Giới Di Động và Điện Máy Xanh làm Thương mại điện tử hiệu quả của diễn giả Nguyễn Thanh Tùng – Product Director của Thế Giới Di Động & Điện Máy Xanh.

Với tốc độ tăng trưởng cán mốc 22%/ năm, thị trường thương mại điện tử Việt Nam vừa là “miếng bánh hấp dẫn” với nhiều doanh nghiệp vừa là đấu trường cạnh tranh vô cùng khốc liệt. Với Thế Giới Di động sở hữu hơn 1500 siêu thị, 31.000 nhân viên phủ khắp 63 tỉnh thành, Điện Máy Xanh có gần 600 siêu thị, liệu công nghệ – phần mềm quản trị – quy trình kĩ thuật nào có thể đảm đương được toàn bộ hệ thống này? Làm thế nào để tất cả hoạt động của các bộ phận từ nhân sự, cung ứng, Marketing, hành chính, quản lý…. đều được tự động hóa một cách tối đa, tiết kiệm nhân lực để vừa đáp ứng được nhu cầu mua hàng lớn vừa mang đến những trải nghiệm tốt, vận hành mượt mà, nhanh và chính xác nhất? Rốt cuộc thì sau những chiến dịch Marketing rầm rộ với hình ảnh và âm nhạc độc đáo, vui tươi lan truyền khắp mạng xã hội, đội ngũ kĩ sư đã làm những gì để giúp Thế Giới Di Động và Điện Máy Xanh vươn lên trở thành những tập đoàn Thương Mại Điện Tử hàng đầu Việt Nam? Anh Nguyễn Thanh Tùng sẽ giải đáp tất cả những thắc mắc này tại Vietnam Web Summit!

Tầm nhìn thế giới để thoát khỏi tư tưởng ao làng

Vẫn như thường lệ, Vietnam Web Summit sẽ không thể trọn vẹn nếu thiếu đi sự tham gia của các chuyên gia công nghệ, giám đốc điều hành đến từ các tập đoàn lớn trên thế giới. Với những số liệu cập nhật mới nhất, nội dung chia sẻ của Amazon Web Services, Lazada Tech Hub, Nielsen, Microsoft, MasterCard tại sự kiện sẽ phần nào định hình xu hướng công nghệ và truyền thông trong tất cả mọi chiến lược kinh doanh của doanh nghiệp.

  • Chuyên đề Bước tiến công nghệ ảnh hưởng đến hành vi tiêu dùng online của bộ đôi diễn giả Đoàn Duy Khoa và Đặng Thúy Hà – hai Giám đốc Bộ phận Nghiên cứu Hành vi Người tiêu dùng đến từ Nielsen Việt Nam
  • Chuyên đề Transform your business with a modern data estateDemocratizing Artificial Intelligence with Microsoft lần lượt của diễn giả Phạm Anh Vũ –  và diễn giả Huỳnh Bảo Toàn – Technical Evangelist đến từ Microsoft Việt Nam
  • Chuyên đề Culture of Innovation của diễn giả LeX Nguyen, Head of Territory Development đến từ Amazon Web Services
  • Chuyên đề Real-world Microservice Architecture của diễn giả Viachesláv Poturaễv – Manager Core Engineering Platform đến từ Lazada
  • Chuyên đề Cash to Digital: The next big things của MasterCard

Bên cạnh các kĩ sư và chuyên gia quốc tế, ngày hội Vietnam Web Summit 2017 cũng đón chào những đại diện lớn của Việt Nam là Zalo Business, Chili, FPT Telecom, Appota, Kdata, Verisign, Luxoft, Cốc Cốc, Vietguys, KMS Technology, Piktochart… với các hoạt động gian hàng giới thiệu ý tưởng & sản phẩm mới, đem đến cơ hội tuyển dụng cho hơn 400 doanh nghiệp và 9000 lập trình viên ở cả 2 miền. Có thể nói, với gần 100 topic chia sẻ, Vietnam Web Summit chính là nơi gặp gỡ, học hỏi kết nối, đẩy mạnh hệ sinh thái Web & Digital Marketing, đưa thị trường Việt Nam từng bước phát triển và tiệm cận tầm vóc của thế giới.

Người trẻ đi làm: Cứ im thin thít đi rồi “chết”!

Sau khi chứng kiến nhiều câu chuyện, tôi đã hiểu ra rằng việc tự biến mình thành Hello Kitty nơi công sở chính là hậu quả của những hiểu lầm trong môi trường làm việc. Nỗi sợ hãi đã khiến các bạn trẻ câm lặng, và rồi, thiệt thòi mà chẳng biết kêu ai!

Ông bà ta có câu: “Im lặng là vàng”. Rất nhiều bạn trẻ đã áp dụng lời dạy này vào công việc. Nhưng rốt cuộc, vàng đâu không thấy, chỉ thấy sự im lặng giống như một loại virus phá hủy mọi mối quan hệ, cơ hội và cả công việc của mình. Rốt cuộc, lời ông bà sai hay chúng ta sai?

Trong công việc, suốt hơn 10 năm qua tôi đã có cơ hội cộng tác với rất nhiều bạn trẻ, sinh viên cũng có, mà ra trường cũng có. Giới trẻ Việt Nam nhìn chung rất năng động, ham học hỏi, nhưng cũng có rất nhiều bạn phạm phải một sai lầm chết người khi đi làm: Tự biến mình thành những chú Hello Kitty “không có miệng” ở công sở, xem im lặng là vàng, rốt cuộc tự chuốc cho mình rất nhiều thứ đáng tiếc.

Nhưng rốt cuộc là tại sao?

Sau khi chứng kiến nhiều câu chuyện, tôi đã hiểu ra rằng đó chính là hậu quả của những hiểu lầm trong môi trường công sở. Nỗi sợ hãi đã khiến các bạn trẻ câm lặng!

Một trong những nỗi sợ hãi lớn nhất và phổ biến nhất của các bạn trẻ ở công sở chính là: Sếp! Mà chẳng cứ gì là bạn trẻ, nhiều người đi làm đã lâu vẫn luôn xem sếp là “ông kẹ” công sở. Người lao động nhìn chung vẫn e ngại khi nhìn vào một quyền lợi của mình: Quyền được đối thoại, ngay cả là với ông sếp bự nhất!

Một ví dụ đơn giản mà tôi từng trải qua: Ngày trước tôi từng tuyển một bạn trẻ có background khá tốt, là sinh viên giỏi của một trường đại học thuộc hàng top. Gặp nhau bàn bạc, trao đổi công việc, bạn cứ dạ dạ gật gật, rồi tự dưng sau đó lặn không sủi bọt, nhắn tin không trả lời, điện thoại không bắt máy.

Một thời gian sau, tôi tình cờ biết được bạn đi than vãn là bị tôi ép buộc làm việc quá sức (bạn chưa chính thức làm việc được ngày nào), bạn không kham nổi deadline nên tự rút không làm nữa , nhưng lúc giao deadline bạn chỉ gật đầu dạ dạ, khi được hỏi ý kiến cũng dạ dạ gật gật. Tôi đương nhiên là sửng sốt vô cùng, nhưng ngay lập tức hiểu ra bạn này thuộc vào kiểu bạn trẻ mới đi làm nào.

Tham khảo các bài viết:

  "Ngành IT này học rất dễ, tài liệu ko bao giờ thiếu. Quan trọng là phải có đam mê và chịu cày"
  1001 câu hỏi của học sinh cuối cấp muốn theo đuổi ngành công nghệ thông tin

Đó là bạn mang điểm yếu rõ ràng về mặt giao tiếp.

Cốt lõi nhất của làm việc là mạnh dạn trao đổi với nhau. Nếu thấy có bất cứ điều gì vướng mắc thì cứ mạnh dạn nói ra. Nhưng nhiều người lại chọn giải pháp im lặng, bất mãn, rồi nghỉ việc. Trong khi câu chuyện hoàn toàn có thể diễn ra theo một chiều hướng khác!
Hành động này xuất phát từ tâm lí nhiều người cứ nghĩ: Sếp là những kẻ chả bao giờ quan tâm bạn bận rộn thế nào hay đang có khó khăn gì, họ chỉ muốn kết quả, nếu bạn không thể đáp ứng yêu cầu thì xin chào tạm biệt. Tôi nghĩ đúng là có kiểu sếp này tồn tại trên đời, nhưng đây hoàn toàn là kiểu quản lí không hợp lý.

Những người quản lí có kinh nghiệm thừa hiểu rằng nhân sự nào cũng là một con người với cuộc sống riêng của họ. Vì thế trong công việc, họ luôn cân bằng giữa đòi hỏi và thực tế, cụ thể như thế này:

Tôi muốn anh làm cho tôi 10 điều này – đây là mặt lí tưởng, nhưng người quản lí tốt luôn hiểu rằng về mặt thực tế có thể có rất nhiều phát sinh: Thời gian để thực hiện cần dài hơn vì lí do ABC, hoặc nhân sự này chỉ có thể thực hiện được 8 điều vì lí do XYZ.

Môi trường làm việc tốt luôn là sự điều chỉnh hài hòa giữa đòi hỏi và thực tế, giữa sự cố gắng hết sức của nhân viên và sự cảm thông lẫn dẫn dắt động viên của người quản lí. Đó cũng là lí do vì sao không phải người có tài nào cũng có thể làm sếp. Tài năng đòi hỏi IQ, nhưng khả năng quản lí còn đòi hỏi cả EQ nữa.

Chính vì thế, các bạn trẻ hãy hiểu rằng sếp chỉ đặt ra cho bạn bài toán A chứ không phải là mệnh lệnh A. Mà “làm toán” thì chúng ta cùng làm. Khi sếp hỏi: Em có gì muốn trao đổi không? Thì đây chính là lúc để bạn đưa ra ý kiến phản hồi: Bạn nghĩ mình có thể giải được bao nhiêu %, mất bao lâu, cần thêm trợ giúp gì.

Sếp không phải là ông kẹ công sở, người mà nhất nhất chỉ ra mệnh lệnh hay chực chờ vùi dập bạn như ngáo ộp yêu ma. Bạn có quyền đối thoại, trao đổi với sự cầu tiến và cố gắng hết mức.

Trường hợp của bạn gái mà tôi vừa kể chỉ là mức nhẹ nhất của việc áp dụng sai câu “Im lặng là vàng”. Nhưng đáng tiếc là cô bạn này mất đi cơ hội mà bạn chưa bao giờ được nhìn thấy, thành ra có thể với cô ấy nó chẳng mang lại bài học gì.

Nhưng với nhiều bạn trẻ khác, việc áp dụng sai lời ông bà dạy: “Im lặng là vàng” lại mang đến khá nhiều hậu quả. Đó là với các bạn đã thực sự ở vào môi trường công sở và sống với nó mỗi ngày.

“Hello Kitty” công sở thường im lặng trước những điều mà lẽ ra cần phải trao đổi vì trong họ còn rất nhiều nỗi sợ hãi khác.

Không hỏi những vấn đề mình chưa biết

Nhiều sinh viên đi làm thêm hoặc mới ra trường và lần đầu bước vào công sở thường hay được khuyên rằng “Im lặng là vàng”. Lời dạy này thường được phiên ra thành: Đừng có dại mà thắc mắc quá nhiều kẻo bị chửi, bị khinh. Sự im lặng bỗng chốc bị đánh đồng thành thụ động, khép mình.

Trong khi lẽ ra nó phải là thái độ cầu thị khôn ngoan mà không cần đến mồm mép tép nhảy. Bạn không nói nhưng phải quan sát, không nói nhiều nhưng phải hỏi đúng trọng tâm đâu là chỗ mình còn mơ hồ. Đó mới chính là ý nghĩa thực sự của câu “Im lặng là vàng”!

Thực ra phân tích tâm lí của những người trẻ đi làm là công việc khá phức tạp và cần nhiều giấy mực.

Không lên tiếng thắc mắc còn có thể xuất phát từ nguyên nhân khác. Sợ bị chửi ngu dốt là một phần, nhiều bạn trẻ không lên tiếng hỏi còn là vì nghĩ… mình đã biết tỏng hết rồi. Cuối cùng, dù không biết gì hay nghĩ mình biết tuốt đều có thể dẫn đến những sai phạm nghiêm trọng.

Đến khi hậu họa ập tới mới chống chế yếu ớt: “Tại em không biết?”. Không biết tại sao không hỏi?

Nhưng thực ra, có sai sót xảy ra để thức tỉnh đã là chuyện may. Vì có làm thì có sai, sai mà biết sửa thì thành ra lại tốt hơn. Có những kẻ ăn may dù không hỏi han thắc mắc gì nhưng hậu họa không xảy ra nên càng lúc càng tưởng rằng “ngu si sẽ hưởng thái bình”. Nhưng họ không hiểu rằng việc im lặng thụ động nơi công sở sẽ dẫn đến hậu quả không thấy được ngay trước mắt nhưng thực sự nguy hại về sau: Các bạn có thể làm đến vài năm trong một vị trí mà thực sự chẳng học hỏi được thêm điều gì, ù ù cạc cạc về lĩnh vực mình đang làm việc.

Làm việc tức là hướng tới sự phát triển chứ đừng chỉ mưu cầu sự ấm êm. Chính vì cứ mong đợi một chỗ ngồi ổn định nên nhiều người ngại hỏi, ngại vỡ ra vấn đề. Nhưng nếu thế, bạn sẽ không bao giờ tiến lên được. Hãy làm việc như cách mà Leah LaBelle đã nói: “Làm việc thật vất vả đẻ đạt được thứ bạn muốn vì không thứ gì đến với mình mà không có sự đấu tranh.”

Không đề nghị những vấn đề quyền lợi cho mình, không thắc mắc về những thứ cảm thấy chưa hợp lí hoặc bất công

Đây chính là hai khía cạnh khác mà các bạn trẻ thường e ngại nói đến. Không đề nghị những vấn đề quyền lợi cho mình, tại sợ bị đánh giá mới đi làm đã đòi hỏi này nọ. Không thắc mắc về những thứ mình cảm thấy chưa hợp lí hoặc bất công, tại sợ bị ghét, bị đuổi, bị trù dập cho chết luôn khỏi thắc mắc nữa.

Những trường hợp này lại phân công sở ra làm hai hạng người: Hello Kitty và “Bà nội thiên hạ”. Những người không bao giờ lên tiếng thắc mắc và những người lúc nào cũng sồn sồn đòi hỏi dù chưa thực sự làm nên cơm cháo gì.

Ở giữa hai kiểu người này chính là những người hiểu được sự khéo léo trong giao tiếp. Hỏi làm sao để là lời đề nghị chứ không phải yêu sách. Nói làm sao để là sự trao đổi chứ không phải là gây hấn.

Nhưng thực ra bạn cũng không cần quá lo lắng. Vì điều này hiếm khi là khả năng sẵn có, mà là hình thành qua kinh nghiệm. Tốt nhất vẫn là bạn cứ phải lên tiếng đi, cứ cân nhắc câu chữ, rồi dần dần sẽ học được cách giao tiếp tốt nhất.

Nguồn: Applancer Careers via Kenh14

Vì sao SQL tốt hơn NoSQL? (Phần 2)

PHẦN 1

Part 3: Return of the SQL – Sự trở lại của SQL

Sau khi bị cám dỗ lạc vào trong đêm tối, công đồng software bắt đầu nhìn thấy ánh sáng và trở về với SQL.

Tiếp theo đó sự trỗi dậy của NewSQL mới: Một databases có khả năng mở rộng và hoàn toàn dành cho SQL. H-Store (2008), thành quả của các nhà nghiên cứu của MIT và Brown, là một trong những OLTP databases đầu tiên. Google tiếp tục dẫn đầu cuộc đua với SQL-interfaced database trong Spanner, theo sau đó là CockroachDB (2014).

Cùng lúc đó, cộng đồng PostgreSQL bắt đầu sống lại, thêm vào những tính năng vô cùng quan trọng như JSON datatype (2012), cũng như trong PostgreSQL 10: native support tốt hơn, text search support cho JSON, và nhiều hơn nữa. Các công ty khác như CitusDB (2016) và yours truly (TimescaleDB) cũng đã tiềm ra cách máy để mở rộng PostgreSQL để tập trung vào data workloads.

Hơn thế TimescaleDB cũng như tấm gương phản chiếu lịch sự của chính SQL. Khi trong nhưng phiên bản đầu tiên, TimescaleDB cũng sử dụng ngôn ngữ query từa tựa SQL gọi là “ioQL.”. Ban đầu, chúng tôi cũng bị cám dỗ và nghĩ việc tạo ra một ngôn ngữ riêng đầy mạnh mẽ thật sự rất có ích. Nhưng khi bắt đầu đi sâu thì nó có rất nhiều vấn đề nảy sinh từ thuật toán cho đến việc hướng dẫn user.

Và sau một thời gian, chúng tôi nhận ra rằng việc tạo ra một ngôn ngữ mới hoàn toàn phí công và ta nên tìm cách để thật sự sử dụng SQL. Ngay lập tức một thế giới mới như mở ra trước mắt chúng tôi. Hiện nay, dù database chỉ mới được 5 tháng nhưng các user đã có thể làm nhiều việc khác nhau như visualization tools (Tableau), kết nối tới ORMs, etc…

Hãy dõi theo Google

Google rõ ràng là người dẫn đầu trong cuộc thi công nghệ trong hơn một thập kỉ vừa qua. Do đó, khi nói đến việc tìm hiểu về công nghệ mới thì không có gì hơn việc theo dõi nguồn tin từ ông lớn công nghệ này.

Hãy thử xem Spanner của Google (Spanner trở thành một SQL System, 2017), và bạn sẽ nhận thấy rất nhiều chi tiết thú vị.

Ví dụ như khi Google bắt đầu tạo nó trên Bigtable, họ phát hiện ra việc thiếu SQL gây ra nhiều vấn đề nhức đầu:

“Trong khi những hệ thống này cung cấp một vài lợi ích của một database system, chúng lại thiếu nhiều database feature mà các developer vẫn thường hay dựa vào. Do không có một ngôn ngữ query mạnh mẽ nên developer phải bỏ ra rất nhiều thời gian cũng như phải thực hiện nhiều bước phức tạp. Do đó mà chúng tôi đã quyết định biến Spanner thành full featured SQL system, với query execution được tích hợp chặt trẽ với các tính năng khác của Spanner”

Sau đó, hãng cũng nói rõ thêm vì sao lại lựa chọn chuyển đổi từ NoSQL qua SQL:

“API của Spanner cung cấp NoSQL methods cho point lookup và range scan. Trong khi NoSQL methods cung cấp một cách thức đơn giản để launch Spanner, và tỏ ra rất hữu ích trong những trường hợp đơn giản, SQL vẫn đưa ra những giá trị vô cùng to lớn khi có khả năng xử lí các data access pattern phức tạp và push thuật toán tới data.”

Không chỉ dừng lại với spanner mà SQL còn được Google áp dụng vào nhiều system của hãng:

SQL engine của Spanner cùng sử dụng chung một SQL dialect, được gọi là “Standard SQL”, cùng với các hệ thống nội bộ khác tại Google như F1 và Dremel cũng như hệ thống bên ngoài như BigQuery…

Với user trong Google, nó giúp giảm độ phức tạp khi làm việc giữa nhiều hệ thống khác nhau. Một developer hay nhà phân tích data khi viết SQL cho Spanner database vẫn có thể chuyển qua Dremel mà không phải lo về sự khác biệt trong ngôn ngữ”.

Cách tiếp cận này đã thành công vượt ngoài tưởng tượng với spanner đóng vai trò chủ chốt trong hệ thống của Google, bao gồm AdWords và Google Play, “Các khách hàng đám mây điển tử cũng rất quan tâm và thích thú với SQL.”

Điều này có ý nghĩa gì cho tương lai?

Trong computer networking, có một thuật ngữ gọi là “eo hẹp”

Nó ám chỉ việc trong hệ thống network với nhiều lớp hardware ở dưới và software ở trên. Mỗi phần cứng và phần mềm luôn khác biệt nhau nên ta phải bảo đảm bất kể là phần cứng gì thì phần mềm vẫn có thể kết nối với network. Ngược lại, bất kể phần mềm nào thì phần cứng vẫn xử lí được network requests.

Trong networking, vai trò của “eo hẹp” được thực hiện bởi Internet Protocol (IP) như một interface thông thường giữ networking protocols cấp thấp (dành cho local-area network) và application and transport protocols cấp cao. có thể nói IP đóng vai trò như người thông dịch cho phép kết nối và giao tiếp giữa các thiết bị.

Chúng tôi tin rằng SQL đã trở thành “eo hẹp” trong phân tích data

Chúng ta đang sống trong thời đại mà data chính là nguồn tư liệu quí giá nhất. Kết quả là sự bùng nổ về databases (Olap, time-series, tài liệu, graph, etc), tools xử lí data (Hadoop, Spark, Flink), data buses (Kafka, RabbitMQ), etc. Đồng thời chúng ta có ngày càng có nhiều app dựa trên cấu trúc data này.

Tương tự như network chúng ta cũng có một stack phức tạp với cơ sở ở dưới và app ở trên. Do đó mà ta thường phải viết khá nhiều code để gắn chúng lại với nhau. Nhưng những code thì rất dễ “vỡ” nên đòi hỏi phải được chăm sóc và bảo trì.

Điều chúng ta cần là một interface chung để các phần trong stack trên có thể giao tiếp với nhau. Và sẽ là rất lí tưởng khi ta có một interface chuẩn cho phép việc thay ra/vào các thành phần mà không phải lo về việc crash hoặc lỗi.

Đây chính là lúc SQL tỏa sáng bởi cũng như IP, SQL là một interface chuẩn chung.

Không những thế mà SQL còn rất dễ đọc

SQL đã quay trở lại

SQL đã trở lại. Không phải chỉ vì NoSQL quá ư là tởm lợm. Cũng không phải chỉ do việc phải học ngôn ngữ mới quá phiền phức. Cũng không phải chỉ là do SQL đạt chuẩn.

Mà còn là vì thế giới này tràn ngập Data. chúng ở khắp mọi nơi và liên kết lẫn trói buộc chúng ta. Ban đầu ta có thể dựa vào các giác quan và não để giải quyết. Sau đó, khi mà máy móc trở nên thông minh hơn thì chúng thay ta làm những công việc này. Việc có thể xử lý càng nhiều data càng giúp chúng ta có khả năng nhận thức cao hơn, rõ ràng hơn và đồng thời nó khiến cho hệ thống lưu trữ data phát triển hơn bao giờ hết.

Chỉ có 2 lựa chọn cho chúng ta: phải sống trong một thế giới với đống data lộn xộn, code dễ hư với hàng triệu interface khác nhau, hoặc là chọn SQL và thống nhất mọi thứ.

Nguồn: TopDev via timescale

Kết quả chung cuộc benchmark hiệu năng giữa PHP 7.0 và HHVM

Thật tuyệt vời cho tất cả những ai sử dụng PHP mỗi ngày, không chỉ các developer hay các công ty hosting mà còn cả user nữa. Chúng ta có những website nhanh hơn và dịch vụ web cho tất cả mọi người.

Vì nghiện việc tối ưu thời gian load của các website và để xem phiên bản mới của PHP này cải tiến và đáp ứng được bao nhiêu so với mong đợi, chúng ta sẽ đưa một phiên bản đã public của PHP 7.0 vào kiểm tra và so sánh với PHP 5.6.16 và HHVM 3.10.1 trên một server vật lý(vì ảo hóa không phân biệt được kết quả). Việc kiểm tra bao gồm WordPress 4.3.1, Drupal 8, Magento 2.0 CE, OctoberCMSbuild 309, PyroCMS v3 beta2, và Flarum v0.1.0-beta.4.

Server vật lý dùng để benchmark có cấu hình Intel Xeon E5-2630v3 processor(8 CPU cores và 16 threads), 64 GB RAM và 2 x 4 TB SAS 7200 rpm HGST disks in RAID 0.

Chúng tôi dùng MariaDB 10.1.9 cho MySQL server và Nginx 1.9.7 cho web server.

WordPress 4.4

Dùng dummy content từ wptest.io và đã benchmark trang home trong một phút với 15 CCU. WordPress là lần test duy nhất chúng tôi có thể sử dụng chế độ Repo Authoritative của HHVM mà không cần tốn thời gian sửa đổi phần mềm này. Nó giúp tăng thêm một chút tốc độ nữa nhưng không dành cho mọi người vì đòi hỏi phải thêm một số bước nâng cao để có thể chạy được.WordPress 4.4 PHP7 HHVM Benchmarks

Kết quả benchmark của WordPress 4.4 HHVM RepoAuthoritative: 358.33 trans/sec
Kết quả benchmark của WordPress 4.4 HHVM: 335.13 trans/sec
Kết quả benchmark của WordPress 4.4 PHP 7.0: 287.92 trans/sec
Kết quả benchmark của WordPress 4.4 PHP 7.0 không dùng opcache: 84.87 trans/sec

WordPress 4.3.1

Sử dụng dummy content từ wptest.io và benchmark trang chủ trong một phút với 15 CCU.

WordPress 4.3.1 PHP Benchmarks

Kết quả benchmark của WordPress 4.3.1 HHVM RepoAuthoritative: 375.48 trans/sec
Kết quả benchmark của WordPress 4.3.1 HHVM: 357.69 trans/sec
Kết quả benchmark của WordPress 4.3.1 PHP 7.0: 306.24 trans/sec
Kết quả benchmark của WordPress 4.3.1 PHP 5.6.16: 106.45 trans/sec

Ứng tuyển ngay các vị trí PHP tuyển dụng mới nhất trên TopDev

Drupal 8.0.1

Cài đặt bản tiêu chuẩn với 50 posts dữ liệu mẫu. Benchmark trang chủ trong một phút với 15 CCU. Kết quả đáng ngạc nhiên, chúng tôi đã gỡ Drupal hoàn toàn và cài lại từ đâu rồi đo lại, tất cả đều chung một kết quả!

Drupal 8 PHP Benchmarks

Kết quả benchmark:
Drupal 8 HHVM: 1739.28 trans/sec
Drupal 8 PHP 7.0: 917.10 trans/sec
Drupal 8 PHP 5.6.16: 794.20 trans/sec

Magento 2.0 Community Edition

Cài đặt bản tiêu chuẩn với dữ liệu mẫu chính hãng. Cache của Magento đã được bật. Benchmark trang chủ trong một phút với 15 CCU

Magento 2.0 PHP BenchmarksKết quả benchmark:
Magento HHVM: 192.19 trans/sec
Magento PHP 7.0: 183.87 trans/sec
Magento PHP 5.6.16: 113.34 trans/sec

OctoberCMS

Hệ CMS nổi tiếng dựa trên Laravel này cho chúng ta cơ hội tốt để test framework này! Chúng tôi chọn theme Vanilla trong suốt quá trình cài đặt user system, blog và forum. We chose the Vanilla theme during installation which has a user system, a blog and a forum. Benchmark trang chủ trong một phút với 15 CCU.

OctoberCMS

Kết quả benchmark:
OctoberCMS HHVM: 583.07 trans/sec
OctoberCMS PHP 7.0: 407.89 trans/sec
OctoberCMS PHP 5.6.16: 248.19 trans/sec

PyroCMS v3 beta2

Một CMS khác dựa trên Laravel. Chúng tôi cài đặt mặc định và post một bài blog rồi test nó trong một phút với 15 CCU.

PyroCMS 3

Kết quả benchmark:
PyroCMS HHVM: 177.39 trans/sec
PyroCMS PHP 7.0: 145.95 trans/sec
PyroCMS PHP 5.6.16: 75.17 trans/sec

Laravel 5.1.11

Chúng tôi cài đặt mặc định và test “welcome screen” của nó mà không kết nối database. Đừng quên là OctoberCMS ở trên cũng được built trên Laravel vì vậy dường như HHVM lấy lại phong độ khi chúng ta thêm vài thứ khi kiểm tra. Chúng tôi tối ưu thủ công bằng cách sử dụng –force và config:cache cho ra kết quả tốt hơn 1.5x lần kết quả bên dưới.

Laravel 5.1 PHP7 Benchmark

Kết quả benchmark:
Laravel 5.1.11 HHVM: 1128.41 trans/sec
Laravel 5.1.11 PHP 7.0: 1363.24 trans/sec
Laravel 5.1.11 PHP 7.0 không dùng opcache: 245.60 trans/sec

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

Sự thật về 4.0, Trí tuệ nhân tạo & Robots

Hầu hết những gì bạn thấy trên báo chí đều là chiêu trò marketing và giật tít.

Sự thật về 4.0

Những gì báo chí đang viết về CMCN4.0 hầu hết là không chính xác hay nói nhẹ là không đầy đủ về bức tranh toàn cảnh của CMCN4.0. Những gì CMCN4.0 đang hướng tới, là một CHUỖI các công nghệ mới cho phép con người làm việc và sản xuất hiệu quả hơn. Để có thể áp dụng thành công CMCN4.0, tất cả các công nghệ trong chuỗi đó cần phải được áp dụng. Hãy thử tưởng tượng một nhà máy X nào đó.

Để bắt đầu tiến tới 4.0, toàn bộ các thiết bị,công cụ hay những phần quan trọng trong nhà máy đều phải gắn các chip cho phép đo lường các thông số cần thiết, cho phép lưu trữ những thông số này, đồng thời phải nối mạng để cho phép truy suất những thông số này từ xa. Chúng ta cần phải biết được tại một thời điểm hay trong một khoảng thời gian, những máy móc nào hoạt động, năng suất ra sao, công nhân nào sử dụng, hay hỏng những chỗ nào, bao lâu thì hỏng. Những dữ liệu này cần phải sẵn sàng mọi lúc, mọi nơi, và thời gian thực. Đây hay được gọi là Internet of Things (IoT). Để có thể bắt đầu CMCN4.0, IoT là công nghệ bắt buộc phải có, vì nó sẽ cung cấp nguyên liệu đầu vào cho những công nghệ tiếp theo trong chuỗi. Đó là DỮ LIỆU (Data). (Tất nhiên nó cũng cung cấp các tiện ích khác, như cho phép quản lý, điều hành nhà máy từ xa, giảm chi phí..v.v.)

Những dữ liệu này được thu thập trên diện rộng và trong thời gian dài sẽ tạo nên một công nghệ tiếp theo là Big Data. Tuy nhiên, không phải cứ nhiều dữ liệu thì được gọi là Big Data. Những dữ liệu được thu thập về cần phải được sắp xếp, dọn dẹp, xử lý một cách hợp lý để có thể nhận ra các pattern trong dữ liệu. Ví dụ, từ các dữ liệu đã thu thập được từ nhà máy, chúng ta có thể biết được tuổi thọ của từng chi tiết máy, lúc nào sắp hỏng, lúc nào phải thay để lên lịch thay thế. Chúng ta sẽ biết được tốc độ làm việc của từng thiết bị, hiệu quả làm việc của từng công nhân, từ đó có cách lên kế hoạch làm việc và sản xuất. (Big Data đang tạo ra một ngành nghề mới đang rất hot và khát nhân lực là Data Scientist – Nhà khoa học dữ liệu) Big Data sẽ làm nguyên liệu cho công nghệ tiếp theo.

Sau khi được xử lý một cách hợp lý, dữ liệu Big Data sẽ được dùng để huấn luyện cho các thuật toán Machine Learning (dân ta hay gọi là Máy học, nhưng mình thấy từ này không chuẩn lắm, cứ gọi là Machine Learning thôi. Deep Learning là một nhóm nhỏ của Machine Learning). Những Machine Learning này sẽ tự động phân tích để tìm ra các pattern trong dữ liệu đã có rồi dùng những pattern này để dự đoán các sự kiện trong tương lai. Ví dụ sử dụng các dữ liệu năng suất làm việc của máy móc và công nhân, để đưa ra một lịch làm việc hiệu quả nhất, công nhân nào làm với máy nào, vào lúc nào thì tốt nhất). Các thuật toán Machine Learning được phát triển lên một trình độ cao sẽ được gọi là AI. Khi đó máy tính sẽ có thể hỗ trợ/thay thế con người đưa ra những quyết định điều hành nhà máy.

Thế đó, CMCN4.0 cần ít nhất 3 công nghệ cốt lõi là IoT, Big DataAI mới thành công. Ngoài ra có thể nhắc đến thêm các công nghệ như Cloud, AR, VR trong từng ngành công nghiệp cụ thể.

Hiện nay các nước công nghiệp phát triển mới chỉ bắt đầu triển khai IoT vào các nhà máy. Big Data đã có nhưng do IoT chưa hoàn toàn sẵn sàng nên mới chỉ được áp dụng nhiều trong các tập đoàn công nghệ là chính. AI vẫn đang trong quá trình nghiên cứu. Do đó mọi người không phải vội vàng. Như bác Trương Đình Tuyển đã nói: “Việt Nam cứ nói nhiều về công nghiệp 4.0, Singapore, Trung Quốc, Hàn Quốc mới chỉ nhận họ đang ở kỳ 3.5 mà thôi”

Sự thật về Trí tuệ nhân tạo

Yann LeCun, người đứng đầu bộ phận phát triển AI của Facebook, nói AI còn chưa thông minh bằng một con chuột. Andrew Ng, chuyên gia hàng đầu về Machine Learning và AI cho rằng nghiên cứu thế đủ rồi, bắt đầu xây dựng AI thôi – nghĩa là giới khoa học còn chưa bắt tay vào xây dựng AI thực thụ.

Thế mà báo chí cứ chém như AI ngội bên cạnh bạn rồi.

Các thuật toán Machine Learning, công nghệ nền tảng của AI, vẫn đang chật vật xử lý các bài toàn đơn lẻ, như nhận diện hình ảnh, xử lý chữ viết tay mà còn gặp nhiều lỗi và vẫn hay bị lừa bởi những mẹo đơn giản. Khi nói về các thuật toán Machine Learning sẽ có 3 dạng chính:

  1. Các thuật toán Machine Learning cổ điển xử lý các bài toán dựa trên xác suất thống kê. Tức sau khi phân tích dữ liệu lịch sử, thuật toán nhận ra rằng sau khi các sự kiện A, B, C diễn ra, thì có 70% khả năng sự kiện D sẽ diễn ra, 30% sự kiện E sẽ diễn ra. Khi đó, mỗi khi 3 sự kiện A, B, C diễn ra, nó sẽ dự đoán sự kiện D sẽ diễn ra tiếp theo (do có xác suất lớn nhất) (trong thực tế sẽ phức tạp hơn và thuật toán cho độ chính xác cao hơn, tầm 80%-90%, tuy nhiên vẫn có thể lừa được)
  2. Các thuật toán Deep Learning. Các thuật toán này hoạt động theo mô phỏng hệ thần kinh của con người (neural network) cho độ chính xác cao hơn 9x% gì đó. Tuy nhiên các nhà khoa học vẫn chưa hoàn toàn hiểu được nguyên lý hoạt động của chúng. Tức là họ xây dựng một thuật toán neural network, cho dữ liệu đầu vào vào, rồi ngồi đợi kết quả đầu ra, sau đó họ thay đổi các thông số thiết lập sao cho thuật toán cho ra một kết quả có độ chính xác cao nhất. Còn vì sao thuật toán tính ra như thế thì chưa rõ ràng. Các nhà khoa học vẫn gọi neural network là blackbox, từ là họ chỉ biết nhét X và thì sẽ Y, còn chưa biết blackbox làm thế nào mà ra được cái kết quả đó.
  3. Reinforcement Learning (RL) (Học tăng cường). Đây chính là thuật toán đứng sau thành công của AlphaGo, AI liên tục đánh bại con người trong môn cờ vây. Nhiều người cho rằng đây chính là cột mốc máy móc vượt qua con người, nhưng không hẳn. RL được xây dựng theo kiểu thử sai, tức là học kiểu trâu bò, làm cho đến khi nào đạt được kết quả thì thôi. Tuy nhiên RL mới chỉ tỏ ra hiệu quả trong các trò chơi, đơn giản vì trò chơi có một mục tiêu hết sức cụ thể (Đạt điểm số cao hơn đối thủ), mỗi khi đi một nước cờ, thuật toán sẽ biết được nó sẽ được bao nhiêu điểm. Tuy nhiên để giải quyết các bài toán thực tế của con người, khi mà mục tiêu không cụ thể. Ví dụ giải quyết tắc đường ở Hà Nội thì lại là vấn đề khác.

Tóm lại, AI còn rất ngu, nên các bạn chưa phải quá lo. Tuy nhiên sức mạnh của AI đang tăng lên theo hàm số mũ, nên các bạn cũng phải tự chuẩn bị cho bản thân.

Sự thật về Robot

Robot, đã xuất hiện từ rất lâu trong sản xuất công nghiệp rồi chứ không phải bây giờ mới có. Từ CMCN lần 3, robot đã là giải pháp cho tự động hóa rồi. Tại Việt Nam, còn rất nhiều nhà máy vẫn hoạt động theo cách thủ công, dựa trên sức người, đến gần đây mới bắt đầu thay thế bằng robot mà báo chí cứ nói đó là CMCN4.0, điều đó là thiếu chính xác. Đấy mới chỉ là chúng ta đi từ 2.0 lên 3.0 thôi.

Robot trong CMCN 4.0 khác biệt so với các robot đã có là ở chỗ chúng được tăng cường bởi AI. Những robot trước đây chỉ có thể thực hiện một, hoặc một vài tác vụ lập trình từ trước, nếu muốn thực hiện các tác vụ mới thì phải lập trình lại, đấy là chưa nói đến việc phải thay thế phần cứng. Robot 4.0 được tăng cường bởi AI, sẽ dễ dàng học tập các tác vụ mới hơn. Con người chỉ cần cung cấp dữ liệu liên quan đến tác vụ, AI sẽ tự học và tìm cách thực hiện tác vụ đó, thậm chí là cải tiến cách thực hiện qua thời gian.

Tuy nhiên các giới hạn về phần cứng sẽ hạn chế rất nhiều khả năng của robot4.0. Con người có thể dễ dàng thực hiện nhiều thao tác phức tạp nhờ kết cấu tự nhiên của bàn tay. Chúng ta có thể vặn ốc vít, hàn xì, vung búa với hai bàn tay. Nhưng robot sẽ cần 1 bàn tay cho mỗi một công cụ. Việc robot mô phỏng bàn tay của con người là có thể nhưng rất phức tạp và cho đến nay chưa có ai thành công.
Đường đến Terminator còn rất xa!

Tác động của AI & Robots 4.0

Theo đánh giá của cá nhân mình, thì AI sẽ tác động đến giới cổ cồn trắng (nhân viên văn phòng) nhiều hơn cổ cồn xanh (lao động chân tay). Vì như đã nói, các giới hạn về mặt phần cứng sẽ hạn chế rất nhiều khả năng linh hoạt của robot, do đó các công nhân con người vẫn sẽ có những chỗ đứng nhất định trong dây chuyền sản suất. Nhưng nhân viên văn phòng thì lại khác, sự tiên tiến của các thuật toán Machine Learning cộng với khả năng tính toán vượt trội của máy tính thời nay, AI sẽ chẳng mấy chốc thay thế được con người. Lớp nhân viên văn phòng bị thay thế đầu tiên sẽ là những người thuộc lớp giữa (mid-level) của quá trình hoạt động trong công ty. Quá trình sẽ như sau:

Công ty đầu tư xây dựng một AI. Quá trình này khá đơn giản, chỉ cần một server đủ mạnh, một mã nguồn AI, và một ổ cắm điện là AI có thể hoạt động. AI sẽ theo dõi và chia nhỏ nội dung công việc của từng vị trí công việc (kế toán, pháp chế, admin ..v.v.), những phần AI có thể đảm nhiệm được ngay, AI sẽ làm, những phần chưa làm được sẽ để dành cho con người (công ty có thể thuê nhân viên hoặc outsource). Tuy nhiên, AI vẫn sẽ liên tục theo dõi và cập nhật dữ liệu về quá trình thực hiện tất cả các phần, cả phần AI làm được lẫn chưa làm được. Cái nào AI làm được rồi, sẽ cải tiến tốt hơn. Phần nào AI chưa làm được, nó sẽ học cách làm thông qua dữ liệu làm việc của con người. Như vậy AI sẽ dần dần, thay thế con người từng bước một. Cứ như thế, từ mid-level, AI sẽ tiến tới thay thế gần như toàn bộ công ty, trừ giới lãnh đạo cấp cao, những người vạch ra đường lối hoạt động.

Tất nhiên khi có công việc cũ mất đi thì sẽ có công việc mới xuất hiện, nhưng sẽ có một giai đoạn bước đệm lúc nào AI đã thay thế con người trong công việc cũ mà con người lại chưa sẵn sàng cho công việc mới. Nguy cơ bị thay thế đối với những người trung niên sẽ lớn hơn giới trẻ do họ khó thích nghi hơn (trình độ, tuổi tác khiến họ khó có thể thay đổi công việc)

Nguồn: Nguyễn Linh tại group Quản Trị & Khởi Nghiệp

Tại sao chẳng ai quan tâm đến các Push Notifications trên Android & lời giải kĩ thuật đằng sau

Push Notifications chẳng thể chạy được trên điện thoại Android. Và đây là lý do tại sao.

Gần đây tôi có thêm phần support cho Push Notifications trong Kayako App. Tôi đã test & ra mắt ứng dụng. Tưởng là mình đã làm tốt rồi, ai ngờ users của tôi lại trả lời là 95% thời gian app không hề hiển thị notifications. Ban đầu, tôi nghĩ là lỗi từ việc Push Notifications được mặc định chạy trên emulator & các thiết bị của tôi. Nhưng khi nghiên cứu sâu hơn, tôi phát hiện ra vấn đề thực ra không hề đơn giản như thế. Gần như 50% người dùng app Android bị ảnh hưởng bởi chuyện tương tự.

Vậy, vấn đề ở đây là gì?

Tuyển nhân viên android lương cao cho bạn

Push Notifications không hoạt động tốt trên 1 vài dòng điện thoại Android chuyên biệt.

Tôi dùng từ “không tốt” vì users nhận được push notifications khi mở ứng dụng nhưng không hề nhận được gì khi đóng ứng dụng, điều này trái với mục đích của các push notifications.

Tôi dùng từ “các dòng điện thoại Android” vì vấn đề này chỉ xảy ra trên các điện thoại được sản xuất bởi Xiaomi, Oppo, One Plus, Vivo, Lenovo, Huawei, Vivo, Samsung…

Lý do & cách khắc phục

Để hiểu rõ vấn đề này, đầu tiên bạn cần nắm được Android UI và hành vi được mong đợi từ Push Notifications.

Trên Android, chúng ta có 3 buttons ở đáy của Navigation Bar. Khi click button vuông sẽ mở ra màn hình Recents. Màn hình Recents sẽ liệt kết tất cả các tasks hoặc apps đang hoạt động được mở gần đây. Bạn có thể xóa các ứng dụng này bất cứ lúc nào.

Trên stock ROMs (hệ thống vận hàng của Android được tùy chỉnh bởi các nhà sản xuất thiết bị), xóa 1 ứng dụng đồng nghĩa sẽ “giết” ứng dụng đó và các background services của nó, trong khi chúng ta lại cần background services để hiển thị Push Notifications.

Khi server thông báo thiết bị Android của Push Notification mới, theo lẽ thường nó sẽ restart background services của ứng dụng để hiển thị notification đến user. Điều này hoàn toàn đúng vì background services sẽ tự động hiển thị push notifications.

Hình bên dưới cho thấy hành vi được mong đợi đối với vanilla ROMs. Đây là Android firmware gốc không được các nhà sản xuất tùy chỉnh.

Tuy vậy, 1 vài dòng điện thoại Android sử dụng app Kayako vẫn không nhận được Push Notifications khi ứng dụng được xóa khỏi màn hình Recents. Lý do là vì các nhà sản xuất điện thoại như Oppo, Xiaomi và One Plus sử dụng 1 stock ROM vô hiệu khả năng restart của background services với hầu hết các ứng dụng. Lúc này chúng ta phải quay lại nơi bắt đầu là chẳng có cách nào hiển thị Push Notifications.

May thay, những stock ROMs này có trang Settings để kích hoạt chức năng restart của background services. Mặc dù việc autostart của background services bị vô hiệu mặc định nhưng user có thể kích hoạt bằng tay.

Mục đích của các nhà sản xuất ở đây là để tiết kiệm pin và tăng hiệu suất. Người sử dụng app giờ sẽ phải mở setting app, điều hướng đến đúng trang, cuộn xuống danh sách ứng dụng và sau đó kích hoạt tính năng autostart cho app Kayako.

Nhưng khoan, tại sao những apps như Gmail và Slack cũng có những vấn đề này?

Những ứng dụng top như Gmail, Slack và Whatsapp được các stock ROMs này kích hoạt auto-launch mặc định.

apps-auto-launch

Tuy nhiên, app của bạn, cùng với rất nhiều app khác được cài đặt vô hiệu auto-launch mặc định.

Bạn không thể tìm thấy phần settings để kích hoạt autolaunch. Chúng nằm ở đâu?

Các bước để kích hoạt autolaunch cho 1 ứng dụng sẽ khác nhau tùy theo các nhà sản xuất vì đây không phải là tính năng native của Android và chuyên biệt theo stock ROMs.

Thậm chí thuật ngữ mà mỗi nhà sản xuất sử dụng cũng khác nhau. Tính năng autolaunch có thể ám chỉ đến app auto-start, start-up manager, auto-start manager, app optimisation, các apps được bảo về hoặc background app management.

Trang settings auto-launch cũng rất khó tìm. Đối với các thiết bị One Plus, bạn cần phải mở Settings, chọn Apps, sau đó icon bánh răng hiển thị trên toolbar, sau đó apps Auto-launch dưới sub-category Advanced ở phần dưới cùng.

Vậy vấn đề là gì?

Cuối cùng, user phải hoàn tất các bước này bằng tay vì tính năng không được thiết lập bằng máy tính trên tất cả các thiết bị.

Viết bài hỗ trợ user

Kelly O’Brien và tôi đã viết 1 bài để nhận diện tất cả các nhà sản xuất thiết bị đang có vấn đề với chuyện này, cũng như giải thích các bước để kích hoạt Push Notifications trên các thiết bị này. Đọc thêm tại đây.

Thông báo in-app cho users

Tôi đã hiển thị phần footer nhở trong trang Push Notifications Settings để users where the article is available to the user at all times.

Mở settings page in-app

Có nhiều câu trả lời trên Stack Overflow như cái này đề xuất lập trình khả năng mở trang settings được đề cập ở trên bằng cách detect nhà sản xuất thiết bị.

Nguồn: TopDev via medium.freecodecamp.com

Tham khảo thêm các vị trí việc làm it hấp dẫn tại đây

Vì sao SQL tốt hơn NoSQL? (Phần 1)

Kể từ khi máy tính chào đời, chúng ta đã chứng kiến sự phát triển về khối lượng data, đòi hỏi công nghệ lưu trữ data, xử lí và phân tích cũng phải được nâng tầm theo. Trong thập kỉ vừa qua, software developer xem SQL như là một di tích khi không thể theo kịp tốc độ phát triển của data volume, dẫn đến sự nổi lên của NoSQL: MapReduce và Bigtable, Cassandra, MongoDB, và nhiều nữa.

Thế nhưng SQL đã bắt đầu sống dậy. Tất cả các bên cung cấp dịch vụ cloud giờ còn có cả dịch vụ managed relational database như: Amazon RDS, Google Cloud SQL, Azure Database cho PostgreSQL. Theo Amazon, PostgreSQL- và MySQL-compatible database Aurora database của hãng là dịch vụ có tốc độ phát triển nhanh nhất trong lịch sử của AWS. SQL interfaces của Hadoop và Spark liên tục được cải thiện. Tháng vừa rồi thì Kafka launched SQL support.

Trong bài viết này chúng ta sẽ tìm hiểu nguyên nhân cho sự hồi sinh của SQL, cũng như ý nghĩa của nó đối với tương lai của data engineering và analysis.

Part 1: A New Hope – Một hi vọng mới

Để hiểu được vì sao SQL trở lại ta phải quay về cội nguồn xuất phát của nó.

Câu chuyện của chúng ta bắt đầu với ngiên cứu của IBM trong những năm đầu của thập niên 70s. Khi đó, các ngôn ngữ query vẫn còn dựa rất nhiều vào thuật toán phức tạp. Donald Chamberlin và Raymond Boyce, hai chàng trai còn “non” trong thế giới lập trình, đã vô cùng ấn tượng với relational data model nhưng họ nhận ra các ngôn ngữ query sẽ chỉ làm “nghẽn lỗ chai”. Do đó cả hai quyết tâm tạo ra một ngôn ngữ query mới, dễ hiểu cho ngay cả user không giỏi toán học  và computer programming.

Đây là thời điểm trước cả internet, máy tính cá nhân, khi mà C chỉ vừa mới được giới thiệu với toàn thế giới, đã có 2 nhà khoa học máy tính trẻ nhận ra rằng sự thành công của ngành công nghệ đa phần đến từ việc phát triển một nhóm người dùng thay vì bỏ công đào tạo các chuyên gia lập trình. Họ muốn một ngôn ngữ query dễ đọc như tiếng anh.

Kết quả là thế giới biết tới SQL vào năm 1974. và trong vài thập kỉ tiếp theo, SQL sẽ trở nên vô cùng nổi tiếng. Các database như System R, Ingres, DB2, Oracle, SQL Server, PostgreSQL, MySQL cũng nhanh chóng đô hộ cả ngành công nghệ software. SQL được xem như cầu nối tới database cũng như là lingua franca giúp tăng sự đa dạng cho ecosystem.

Trong một khoảng thời gian, SQL gần như là một ông hoàn cho đến khi Internet xuất hiện.

Part 2: NoSQL Strikes Back – NoSQL tấn công

Trong khi Chamberlin và Boyce đang phát triển SQL, cả hai đều không hay biết việc một nhóm engineer tại California đang thực hiện một project mà sau này đe dọa tới sự tồn tại của SQL. Nó có tên gọi là ARPANET, chào đời vào ngày 29 tháng 10 năm 1969.

Thế nhưng SQL vẫn sống khỏe cho đến khi một engineer khác xuất hiện và sáng tạo ra World Wide Web vào 1989.

Như cỏ dại sau mưa, Internet và Web phát triển mạnh mẽ, ảnh hưởng đến thế giới của chúng ta tại nhiều phương diện khác nhau, nhưng với cộng đồng data thì một vấn đề mới đã xuất hiện: các nguồn mới generate data với volume và vận tốc ngày càng cao.

Và khi Internet ngày càng to lớn thì cộng đồng cũng phát hiện rằng relational databases tại thời điểm đó không đủ khả năng để load khối lượng data như vậy dẫn đến hiện trạng overload của rất nhiều database khác nhau.

Ngay lúc đó 2 ông lớn Internet đã đột phá khi phát triển ra các distributed non-relational systems mới để cứu vãn tình hình: MapReduce (2004) và Bigtable (2006) bởi Google, Dynamo (2007) bởi Amazon. Chúng còn dẫn tới sự ra đời của các non-relational databases, bao gồm Hadoop, Cassandra MongoDB. Do các systems này được tạo ra từ con số không, chúng cũng xung đột với SQL, dẫn tới sự bùng nổ của NoSQL.

Không có gì ngạc nhiên khi cộng đồng software developer chào đón NoSQL vô cùng nồng nhiệt. Sao mà không phấn khích khi NoSQL vừa mới vừa đẹp, chứa đựng sức mạnh và qui mô lớn, cứ như rằng nó chính là con đường thành công dành cho engineer. Thế rồi vấn đề mới lại xuất hiện.

Developer nhanh chóng nhận ra việc thiếu vắng SQL hóa ra lại khiến mọi thứ khá giới hạn. Do mỗi NoSQL database đều có một ngôn ngữ query riêng cũng như qui luật riêng, kèm theo đó hệ ecosystem nghèo nàn khiến cho không chỉ việc học chúng đã khó mà kết nối các database tới app cũng trở nên phức tạp. Đó là chưa kể các công ty còn phải tự phát triển tool phù hợp cho riêng mình.

Những ngôn ngữ NoSQL này do còn mới nên chúng cũng chưa thật sự trưởng thành, trong khi với SQL thì đã có nhiều năm phát triển relational databases giúp các tính năng của nó đã được cải thiện. Do đó, sự non nớt của NoSQL khiến tăng mức độ phức tạp khi làm app. Sự thiếu vắng của JOINs cũng gây ra các vấn đề đối với data.

Một vài NoSQL databases đã thử phát triển những ngôn ngữ Query tương tự như “SQL” (Cassandra’s CQL) nhưng nó lại khiến mọi thứ tệ hơn với việc các engineers bị nhầm lẫn khi sử dụng nó.

Sau một thời gian khổ cực, ngày càng có nhiều developer chán nản với NoSQL.

(Hết phần 1)

Nguồn: TopDev via timescale

Bộ chuyển đổi lương Gross/Net nhanh và chuẩn xác nhất

Lương Gross là gì? Lương Net là gì?

Lương Gross được hiểu đơn giản là tổng thu nhập của người lao động, trong đó gồm tất cả các khoản đóng bảo hiểm và thuế. Lương thực lãnh của người lao động sẽ thấp hơn lương Gross vì họ sẽ phải trích ra một phần để đóng bảo hiểm và nộp thuế thu nhập cá nhân.

Lương Net được hiểu đơn giản là số tiền lương chính xác mà người lao động sẽ nhận được sau khi đã trừ hết tất cả các khoản chi phí bảo hiểm và thuế thu nhập cá nhân.

Ví dụ: Mức lương Gross là 8,000,000 VND sẽ tương đương với mức lương Net 7,160,000 trong trường hợp đóng bảo hiểm trên lương chính thức
– Vậy nên khi NTD quyết định trả bạn mức lương Gross là 8,000,000 VND, thì lương Net của bạn sẽ là 7,160,000 và ngược lại. Về cơ bản lương bạn nhận được vẫn không đổi dù bạn đàm phán lương Net hay Gross.
Theo quy định mới nhất (Từ 1/7/2020)

 

Ví dụ: Mức lương Net là 10,000,000 VND
– Nếu bạn đóng bảo hiểm trên mức lương chính thức lương Gross sẽ là 11,173,184 VND
– Trong đó:

  • Bảo hiểm xã hội chiếm 8% tương đương 893,855 VND
  • Bảo hiểm y tế chiểm 1.5% tương đương 167,598 VND
  • Bảo hiểm thất nghiệp chiểm 1% tương đương 111,732 VND

Theo quy định mới nhất (Từ 1/7/2020)

 

Tool chuyển lương Gross sang Net

Lợi ích khi bạn biết rõ về Gross/Net

Khi bạn có sự hiểu biết về lương Gross và lương Net, bạn sẽ dễ dàng tránh được những hiểu lầm không đáng có với Công ty/ Doanh nghiệp tuyển dụng bạn. Ngoài ra bạn cũng sẽ dễ dàng bảo vệ và đòi hỏi được những quyền lợi đáng có của bản thân khi ký hợp đồng lao động.

Khi thỏa thuận dựa trên lương Net bạn sẽ nhận được đúng số tiền mà bạn đã thỏa thuận từ trước mà không cần phải tính toán hay chịu bất kỳ khoản chi phí nào vì công ty sẽ là người giải quyết những vấn đề đó.

Ngược lại, khi thỏa thuận dựa trên lương Gross thì bạn sẽ nhận được đầy đủ tất cả các quyền lợi về bảo hiểm, đồng thời bạn cũng có thể tự chủ động để tính toán mức lương bạn sẽ nhận được.

Nhìn chung, lương Gross và Net sẽ không làm bạn quá đau đầu khi bạn hiểu rõ về nó, nếu bạn hiểu rõ về nó bạn vẫn sẽ nhận được đúng số tiền mà bạn đã thỏa thuận dù là lương Gross hay Net.

Cách đơn giản hơn hết là bạn tự đặt cho mình 1 mức lương bạn có thể chấp nhận được cho vị trí đó. Sau đó bạn chỉ cần lấy kết quả từ tool chuyển đổi lương Gross Net của TopDev để deal với công ty. Với cách này, bạn chắc chắn sẽ không bao giờ bị “hố” khi deal lương với bất kỳ công ty nào!

 

“Chúng tôi không làm outsource, chúng tôi chính là source!”

Cốc cốc – trình duyệt tìm kiếm đầu tiên “made in Việt Nam” chính thức ra mắt vào tháng 05/2013, với tham vọng “điên rồ”trở thành trình duyệt số một tại Việt Nam, sau đó là vươn ra thế giới. Khi thị trường các trình duyệt tìm kiếm ở Việt Nam gần như là sân chơi của các “ông lớn” như Firefox, Safari, Chrome,… tham vọng đó không khỏi khiến nhiều người “lắc đầu ngao ngán”.

Nhưng chỉ 1 năm sau (năm 2014), Cốc Cốc đã khiến giới truyền thông trong và ngoài nước phải bất ngờ, thán phục khi trở thành trình duyệt web phổ biến thứ hai tại Việt Nam với 14 triệu lượt người dùng hàng tháng, vượt qua cả IE, Firefox, Safari để vươn lên thứ hai và đe dọa soán “ngôi vương” mà Chrome.

Hiện nay Cốc Cốc là công cụ tìm kiếm mặc định trên Mozilla Firefox, chứng tỏ mức độ phổ biến của 1 trong những công cụ tìm kiếm phổ biến hàng đầu tại Việt Nam với hơn 22 triệu người dùng và gần 400 triệu lượt tìm kiếm mỗi tháng. Thậm chí Google Trends cũng dự đoán Cốc Cốc sẽ vượt qua Chrome tại Việt Nam.

“Bạn muốn tìm hiểu các bí quyết kĩ thuật, kinh nghiệm làm Marketing đứng đằng sau 1 trong những công cụ tìm kiếm hàng đầu như Cốc Cốc?”

Với đội ngũ hơn 500 nhân sự, các chuyên gia & kĩ sư của Cốc Cốc mang trong mình sứ mệnh nâng cao chất lượng cuộc sống của người Việt thông qua nhiều sản phẩm công nghệ dành riêng cho người Việt như Bản đồ Cốc Cốc, Quảng cáo Cốc Cốc, Cốc Cốc Big Data, Alô Cốc Cốc… Đây đều là những sản phẩm ứng dụng các nền tảng công nghệ mới, thu hút sự chú ý lớn của người dùng lẫn các Tech team khác.

“Chúng tôi không làm outsource, chúng tôi chính là source!” chính là tuyên ngôn thể hiện tinh thần trẻ và tiên phong trong đổi mới sáng tạo, luôn sẵn sàng trao quyền cho mọi thành viên để đưa ra quyết định dựa trên mục tiêu chung của Cốc Cốc. Nhìn chung, bên cạnh một môi trường tốt để trau dồi kiến thức và kinh nghiệm, mang đến chế độ lương thưởng xứng đáng với khả năng và đóng góp cùng nhiều chế độ phúc lợi hấp dẫn như hỗ trợ chăm sóc sức khỏe lên đến 24 triệu/năm, việc phát triển những sản phẩm công nghệ mà mọi người xung quanh đều sử dụng chính là niềm tự hào mà Cốc Cốc mong muốn mang đến cho mỗi cá nhân. Ngược lại, sự chủ động, tinh thần trách nhiệm và khả năng làm việc theo đội nhóm là những gì mà Cốc Cốc muốn nhìn thấy ở con người Cốc Cốc.

“Bạn muốn ứng tuyển gia nhập môi trường công nghệ năng động này?”

Tháng 12 này, Cốc cốc sẽ tham gia Vietnam Web Summit 2017 sẽ là cơ hội tuyệt vời để gặp gỡ cac chuyên gia đến từ Cốc cốc chỉ 1 click tham dự TẠI ĐÂY

Top 15 thư viện Python tốt nhất cho Data Science trong 2022

Khi Python ngày càng nhận được nhiều sự quan tâm của cộng đồng Data Science trong những năm gần đây, tôi đã muốn tổng hợp cho các data scientists và engineers những thư viện được sử dụng nhiều nhất, dựa trên kinh nghiệm làm việc của bản thân.

Và vì tất cả các thư viên đều là nguồn mở, nên chúng tôi đã thêm các commits, số lượng các contributors và các chỉ số khác từ Github với vai trò là các chỉ số proxy thể hiện mức độ nổi tiếng của thư viện đó

Việc làm python lương cao trong tháng

Các thư viện core

1. NumPy (Commits: 15980, Contributors: 522)

Khi bắt đầu giải quyết task về khoa học bằng Python, tập hợp phần mềm được thiết kế riêng cho scientific computing trong Python sẽ không thể không hỗ trợ SciPy Stack của Python (đừng nhầm lẫn với thư viện SciPy – là 1 phần của stack này, và cộng đồng của stack này). Tuy nhiên, stack này khá rộng, có hơn cả tá thư viện trong nó và chúng ta thì lại muốn tập trung vào các core packages (đặc biệt là những packages quan trọng nhất).

Package cơ bản nhất, khi computation stack về khoa học được xây dựng là NumPy (viết tắt của Numerical Python), cung cấp rất nhiều tính năng hữu ích cho các phần operations trong n-arrays & matrics trong Python. Thư viện này cung cấp khả năng vector hóa các vận hành về toán trong type array NumPy, giúp cải thiện hiệu suất và theo đó là tốc độ execution.

2. SciPy (Commits: 17213, Contributors: 489)

SciPy là 1 thư viện phần mềm cho engineering và khoa học. Một lần nữa bạn cần phải hiểu sự khác biệt giữa SciPy Stack và thư viện SciPy. SciPy gồm các modules cho đại số tuyến tính, optimization, tích hợp và thống kế. Chức năng chính của thư viện SciPy được xây dựng trên NumPy, và arrays của nó sẽ tận dụng tối đa NumPy. Nó mang đến rất nhiều hoạt động hữu ích liên quan đến số như tích hợp số, optimization… qua các submodules chuyên biệt. Các hàm trong tất cả các submodules của SciPy đều được document tốt.

3. Pandas (Commits: 15089, Contributors: 762)

Pandas là 1 package Python được thiết kế để làm việc với dữ liệu đơn giản, trực quan, được “gắn nhãn” và có liên hệ với nhau. Pandas là công cụ hoàn hảo để tinh chỉnh và làm sạch dữ liệu. Pandas được thiết kế hỗ trợ cho các thao tác, tập hợp và visualize dữ liệu.

Có 2 data structure chính trong thư viện này:

“Series” — 1 chiều

“Data Frames”, 2 chiều

Ví dụ, khi muốn nhận Dataframe mới 2 loại structure này, bạn sẽ nhận DF bằng cách nối 1 hàng đơn với 1 DataFrame bằng cách đem tới 1 Series:

Danh sách những thứ bạn có thể làm với Pandas:

  • Dễ dàng xóa và thêm cột từ DataFrame
  • Chuyển data structures đến các objects DataFrame
  • Xử lý các data bị mất, như NaNs
  • Khả năng bhóm lại theo chức năng

Lịch sử Google Trends

Lịch sử pull requests của GitHub

Visualization.

4. Matplotlib (Commits: 21754, Contributors: 588)

Một core package của SciPy Stack và 1 thư viện Python khác được xây dựng riêng cho việc generation các visualizations mạnh mẽ, đơn giản là Matplotlib. Matplotlib là 1 phần của phần mềm giúp cho Python (cùng với sự hỗ trợ của NumPy, SciPy và Pandas) trở thành đối thủ nổi bật với các công cụ khoa học như MatLab hoặc Mathematica.

Tuy nhiên, thư viện này ở cấp độ thấp, đồng nghĩa là bạn sẽ cần phải viết nhiều code hơn để tiếp cận các cấp độ visualization cao cấp và bạn sẽ phải nỗ lực hơn so với khi sử dụng các công cụ cấp cao, tuy nhiên nỗ lực này là hoàn toàn xứng đáng.

Chỉ cần nỗ lực 1 chút, bạn có thể tạo được các visualization bất kì:

  • Line plots;
  • Scatter plots;
  • Bar charts và Histograms;
  • Pie charts;
  • Stem plots;
  • Contour plots;
  • Quiver plots;
  • Spectrograms.

Có rất nhiều công cụ để tạo nhãn, lưới, các biểu tượng/ kí hiệu/ chú giải và rất nhiều yếu tố format khác với Matplotlib. Về cơ bản, mọi thứ đều có thể custom được.

Thư viện này còn được rất nhiều platform hỗ trợ và tận dụng các GUI kít khác nhau để mô tả các visualizations kết quả. Thay đổi các IDEs (như IPython) sẽ hỗ trợ chức năng của Matplotlib.

Có vài thư viện bổ sung giúp việc visualization trở nên dễ dàng hơn.

  Dùng Python như các CLI tool

5. Seaborn (Commits: 1699, Contributors: 71)

Seaborn hầu như tập trung vào việc visualization của các models thống kê; các visualizations như thế gồm heat maps tổng hợp dữ liệu nhưng vẫn mô tả được toàn bộ mức độ phân tán. Seaborn được phát triển dựa trên Matplotlib.

6. Bokeh (Commits: 15724, Contributors: 223)

Một thư viện visualization cực hay khác là Bokeh, hướng đến các visualization tương tác. Trái ngược với thư viện trước, Bokeh hoàn toàn độc lập so với Matplotlib. Bokeh tập trung chính vào tính tương tác và nó tạo các presentations qua các hệ điều hành hiện đại theo style của Data-Driven Documents (d3.js).

7. Plotly (Commits: 2486, Contributors: 33)

Plotly là toolbox cho web để xây dựng các visualizations, APIs được xây dựng bằng vài ngôn ngữ lập trình (như Python chẳng hạn). Có rất nhiều graphics mạnh mẽ, sáng tạo trên trang plot.ly. Để sử dụng Plotly, bạn sẽ cần set up API key riêng. Các graphics sẽ được xử lý phía server và được post lên internet, tuy nhiên vẫn có cách để ngăn việc này.

8. SciKit-Learn (Commits: 21793, Contributors: 842)

Scikits là các packages bổ sung của SciPy Stack được thiết kế cho các chức năng chuyên biêt như xử lý ảnh và hỗ trợ Machine Learning. Riêng với mảng Machine Learning, một trong những ưu điểm nổi bật của các packages này là scikit-learn. Package được xây dựng trên nền tảng của SciPy và tận dụng các operations về toán.

Scikit-learn có giao diện đơn giản, nhất quán, exposes a concise and consistent interface to the common machine learning algorithms, hỗ trợ việc mang Machine Learning vào các hệ thống production trở nên đơn giản hơn. Thư viện này bao gồm các code chất lượng và documentation hay, dễ sử dụng, hiệu suất cao, là chuẩn mực thực tế cho xây dựng Machine Learning bằng Python.

Deep Learning — Keras / TensorFlow / Theano

Liên quan đến Deep Learning, 1 trong những thư viện nổi bật và tiện ích dành cho Python là Keras, có thể hoạt động trên nền tảng của TensorFlow hoặc Theano.

Xem chi tiết bên dưới.

  Chiến trường sinh tử phiên bản lập trình : Python vs Ruby vs Golang

9. Theano. (Commits: 25870, Contributors: 300)

Theano là package Python định dạng các arrays đa chiều tương tự như NumPy, đi kèm với các operation về toán và expressions. Thư viện này được compiled, chạy hiệu quả trên tất cả các architectures. Do đội ngũ Machine Learning của Université de Montréal, Theano được sử dụng chính cho các hoạt động liên quan đến Machine Learning.

Lưu ý là Theano tích hợp với NumPy ở mức độ operation cấp thấp. Thư viện này cũng tối ưu hóa khả năng sử dụng GPU & CPU, giúp cho hiệu năng của computation thiên về data nhanh chóng hơn.

Hiệu quả và sự ổn định cũng mang đến những kết quả chính xác hơn, dù đó là những giá trị rất nhỏ như computation của log(1+x) sẽ cho ra kết quả chính xác đối với các giá trị nhỏ nhất của x.

10. TensorFlow. (Commits: 16785, Contributors: 795)

Do các developer của Google phát triển, TensorFlow là thư viện nguồn mở của graphs computations thuộc luồng dữ liệu, thích hợp với Machine Learning. TensorFlow đáp ứng các requirement cao cấp trong môi trường Google để train Neural Networks và thư viện kế nhiệm của DistBelief – 1 hệ thống Machine Learning dựa trên Neural Networks. Tuy nhiên, TensorFlow không chỉ sử dụng cho mục đích khoa học trong Google mà có thể áp dụng trong các dự án thực tế.

Tính năng quan trọng của TensorFlow is hệ thống nút đa layer, cho phép huấn luyện các neural networks trên datasets lớn 1 cách nhanh chóng, hỗ trợ khả năng nhận diện giọng nói và định vị vật thể trong ảnh của Google.

11. Keras. (Commits: 3519, Contributors: 428)

Keras là thư viện nguồn mở được viết bằng Python dùng để build các Neural Networks ở cấp độ cao cấp của interface. Thư viện này đơn giản và có khả năng mở rộng cao. Keras sử dụng backend là Theano hoặc TensorFlow nhưng gần đây, Microsoft đã cố gắng tích hợp CNTK (Cognitive Toolkit của Microsoft) thành back-end mới.

Cách tiếp cận đơn giản về thiết kế nhắm đến quy trình experimentation dễ dàng, nhanh chóng từ việc build các compact systems.

Bắt đầu dùng Keras rất đơn giản, tiếp theo là prototyping nhanh. Keras được viết bằng Python, theo mô-đun và mở rộng được. Không chỉ đơn giản và có tính định hướng cao, Keras vẫn hỗ trợ modeling rất mạnh mẽ.

Ý tưởng chung về Keras là dựa trên các layers và mọi thứ khác cũng đều được xây dựng xung quanh các layer này. Data được chuẩn bị trong các tensors, layer đầu tiên chịu trách nhiệm về input của các tensors, layer cuối cùng chịu trách nhiệm output và model được build ở giữa.

12. NLTK (Commits: 12449, Contributors: 196)

Tên của bộ thư viện này là viết tắt của Natural Language Toolkit & thư viện này được sử dụng cho các tasks đơn giản liên quan đến Natural Language Processing. NLTK từng dùng để hỗ trợ NLP & các lĩnh vực liên quan dạy và research (các lĩnh vực như Linguistics, Cognitive Science Artificial Intelligence…)

Chức năng của NLTK là giúp thực hiện các operations như text tagging, classification và tokenizing, định dạng các thực thể name, xây dựng cây corpus tiết lộ các dependencies inter & intra-sentence, stemming, semantic reasoning. Tất cả các building blocks hỗ trợ việc xây dựng các hệ thống research phức tạp cho các tasks khác nhau, ví dụ như các phân tích tâm lý hay tổng hợp tự nhiên.

13. Gensim (Commits: 2878, Contributors: 179)

Là 1 thư viện Python nguồn mở, Gensim implement các công cụ làm việc với vector space modeling và topic modeling. Thư viện này được thiết kế phù hợp với các text lớn, chỉ có trong xử lý in-memory. Sử dụng NumPy data structures và SciPy operations sẽ mang đến hiệu quả cực tốt. Cả hai đều hiệu quả và dễ sử dụng.

Gensim được thiết kế để dùng với các digital text thô và chưa được structure. Gensim implement các thuật toán như Dirichlet processes theo thứ bậ (HDP), phân tích ngữ nghĩa tiềm ẩn – latent semantic analysis (LSA) và phân bổ Dirichlet tiềm ẩn (LDA), cũng như tf-idf, projections ngẫu nhiên, word2vec và document2vec hỗ trợ việc kiểm tra các text để tái hiện lại các patterns words trong set documents (thường được đề cấp đến như 1 corpus). Tất cả các thuật toán đều là unsupervised —input duy nhất là corpus.

14. Scrapy (Commits: 6325, Contributors: 243)

Scrapy là thư viện để tạo các chương trình crawling, được biết đến với cái tên thông dụng spider bots, để thu hồi dữ liệu đã structure như thông tin liên hệ hoặc các URLs từ web.

Scrapy được viết bằng Python, nguồn mở, mục đích chính là để scraping nhưng cũng đóng vai trò như 1 framework đầy đủ tính năng, có thể tập hợp data từ APIs và hoạt động như crawlers đa năng.

Thư viện này còn hỗ trợ nguyên tắc Don’t Repeat Yourself nổi tiếng trong thiết kế interface design — nó khuyến khích người dùng viết code chung, universal, tái sử dụng được, để từ đó xây dựng và scaling các crawler lớn.

Kiến trúc của Scrapy được xây dựng xung quanh class Spider, đóng gói set instruction theo sau bởi Crawler.

15. Statsmodels (Commits: 8960, Contributors: 119)

statsmodels thư viện Python cho phép người dùng thực hiện data exploration bằng rất nhiều methods ước lượng các mô hình thống kê và thực hiện các xác nhận và phân tích thống kê.

Thư viện này cũng có nhiều tính năng hữu ích như các thống kê mô tả & kết quả khi sử dụng các models hồi quy tuyến tính, các mô hình tuyến tính tổng quán, mô hình lựa chọn rời rạc, mô hình tuyến tính, mô hình phân tích chuỗi thời gian, các estimators đa dạng khác.

Thư viện này còn cung cấp các chức năng phát họa được thiết kế chuyên biệt trong phân tích thống kê và được tinh chỉnh để tối ưu hiệu suất với các sets big data của data thống kê.

Kết luận

Trên đây là những thư viện được rất nhiều data scientistengineers đánh giá cao. Bên dưới là biểu đồ chi tiết về hoạt động trên Github của mỗi thư viện:

Dĩ nhiên, danh sách này vẫn chưa hoàn thiện và còn rất nhiều thư viện, framewoks đáng lưu ý khác. Chẳng hạn như các packages khác nhau của SciKit tập trung vào các domains riêng biệt như SciKit-Image làm việc với hình ảnh.

Nguồn: TopDev via medium.com

5 điều phiền toái nhất của CSS

CSS có tuyệt vời không? Những điều bực bội sau đây là quan điểm cá nhân tôi.

Vào năm 1996, các trình duyệt vẫn chưa hỗ trợ hoàn toàn CSS khiến cho các we designer phải code khá nhiều để lách nhằm cho CSS của họ chạy đúng. Sự thật là cho đến trước năm 1999 thì không có bất kỳ trình duyệt nào tích hợp đầy đủ các đặc tả của CSS1. Internet Explorer 5.0 dành cho Macintosh được phát hành vào tháng 3/2000 là trình duyệt đầu tiên hỗ trợ hoàn toàn CSS1. CSS2 đã được phát hành vào năm 1999 nhưng các web desginer đã do dự khi sử dụng nó bởi vì vẫn chưa có browser nào hỗ trợ hoàn toàn.

Cấp độ thứ ba của CSS được bắt đầu phat triển vào khoảng năm 1998. Cho đến năm 2009 nó vẫn đang được phát triển. CSS3 mang những thứ mới mẻ đáng được chờ đợi như rounded corners, shadows, gradients, transitions, animations, cũng như là các layout mới như multi-columns, flexible box hay grid layouts.

May mắn là ngoài những nỗ lực của W3C nhằm cải tiến những đạc tả kỹ thuật để đáp ứng nhu cầu của developer, cộng đồng front-end đã cho ra đời nhiều giải pháp thông minh xoay quanh việc làm cho CSS dễ dàng hơn trong một môi trường phức tạp. Giới thiệu về các biến CSS, loại bỏ kiểu dáng dự phòng khiến cho việc viết CSS trở nên ngắn gọn, dễ đọc và dễ quản lý hơn.

CSS chắc chắn là một cải tiến của HTML thuần già cỗi nhưng những hạn chế của nó thật đáng kinh ngạc và thiếu sự hỗ trợ của ngành công nghiệp đã kềm hãm các nhà thiết kế  trong nhiều năm, đó là lý do tại sao nó không chiếm được một chỗ trong tim của các developer 🙂

Ngay cả ngày nay, cho dù bạn gọi mình là “full stack developer” hay là “front end developer” … dù bạn có “một năm kinh nghiệm” hay “8 năm kinh nghiệm”, CSS vẫn sẽ ném bạn vào vòng lặp ngay tắp lự.

Sau đây là một danh sách các vấn đề chủ yếu của CSS:

1. CSS là ‘hướng markup’ chứ không phải ‘hướng design’

Các designer nên dành nhiều thời gian để thiết kế các site trông đẹp hơn và bớt thời gian vô dụng với những cái tag markup và vấn đề tương thích trình duyệt. Khi tôi nói “hướng markup” có nghĩ rằng các công cụ thiết kế CSS ép người dùng qua chế độ lập trình thay vì nên giúp họ “hướng design”. CSS trở nên tệ bởi vì nó ép các designer nghĩ về kỹ thuật hơn là theo quan điểm thiết kế.

2. Cuộc chiến trình duyệt

Bạn thiết kế một layout hoàn hảo cho website mới sắp ra mắt. Nhưng giờ khi chuyển đổi tất cả các file Photoshop PSD hay Sketch đẹp đẽ sang mã lập trình là một thử thách lớn. Thậm chí nó không phải thử thách nữa mà là rào cản không chỉ bởi vì bạn không biết code mà còn ở sự khác biệt ở cách hiển thị của các trình duyệt khác nhau, ngay cả khi bạn viết mã CSS đúng. Càng bực bội hơn nữa khi mà sửa lỗi ở browser này sẽ tạo ra một lỗi lớn khác ở browser khác

Mẹo nhanh:

  • Luôn dùng Normalize.css. Nó làm cho browser hiển thị tất cả các element đúng đắn hơn theo chuẩn hiện đại. It makes browsers render all elements more consistently and in line with modern standards. Chính xác là chỉ nhắm mục tiêu vào các style cần bình dân hoá.
  • Bạn có thể dùng các CSS Frameworks như BootstrapBulma & Materialize. Chúng tương thích với hầu hết các browser phổ biến.
  • Hãy thử dùng các công cụ CSS3 auto-generator. Nó giúp các developer tạo ra các mã CSS cross-browser và tùy chỉnh toàn diện bao gồm border-radiustext-shadow, RGBa, box sizing và box resizing. Ví dụ như: CSS3 Generator.
  • Validate: W3C Validation Service sẽ xác thực nhiều version của XHTML và HTML, nó cũng hiển thị nhiều thông điệp báo lỗi và cảnh báo hữu ích để giúp người dùng tạo nên một website hoàn hảo. W3C Validator: http://validator.w3.org/
    W3C Css Validator: http://jigsaw.w3.org/css-validator/
  • Testing: Không khả thi để thực hiện việc kiểm tra trang web của bạn trong thiên hà rất nhiều trình duyệt và hệ điều hành, các công cụ kiểm tra chéo trình duyệt đã đến để giải cứu bạn! Bạn có thể sử dụng BrowsershotsBrowserStackCross Browser Testing...

3. Responsive Layout

Ngày càng nhiểu thiết bị với nhiều độ phân giải, kích thước khác nhau. Thiết bị mới với kích thước màn hình mới đươc phát triển mỗi ngày, mỗi một trong số các device đó lại có sự khác nhau về kích thước, chức năng và kể cả màu sắc. Một số thì nằm ngang, một số lại nằm dọc, số khác thì hình vuông. Như chúng ta cũng biết về sự nổi tiếng của iPhone, iPad và các smartphone cao cấp đều có chế độ xoay màn hình. Vậy design thế nào trong các tình thế này?

Ngoài việc thiết kế cho cả nằm ngang và dọc, chúng ta phải cân nhắc đến hàng trăm sự khác nhau của màn hình. Bên cạnh đó, rất nhiều user không mở rộng hoàn toàn browser của họ, khiến tồn tại hàng tỷ kích thước màn hình khác nhau.

Mẹo nhanh:

  • Ưu tiên và Ẩn Nội dung trên điện thoại di động. Theo tôi, sẽ tốt khi hiển thị các nội dung có liên quan nhất trên màn hình nhỏ. Đôi khi việc loại bỏ nội dung trên điện thoại di động là không thể. Trong trường hợp đó, bạn có thể ẩn nội dung đằng sau các vùng có thể áp dụng được.
  • Dùng Scalable Vector Graphics (SVGs). Không như các định dạng ảnh truyền thống như PNG hay JPG, SVG dễ dàng phóng to từ nhỏ đến lớn mà không giảm chất lượng. SVG thường nhỏ hơn nhiều so với các ảnh khác, vì thế nó cũng giúp website của bạn load nhanh hơn
  • Khi dùng các input(buttons, forms…), tập trung vào thiết kế “thiết kế cho người béo” bằng cách làm cho kích cỡ của các nút và khu vực nhấn được thật to ra
  • Nếu là các smartphone có màn hình nhỏ, các nút nên có kích thước 44 điểm theo như khuyến nghị của Apple tại iOS Human Guidelines
  • Test thiết kế của bạn với ít nhất 5 user trên thiết bị của họ
  • Sử dụng CSS framework cho responsive designs như Bootstrap. 

4. Làm màu đỏ thêm xanh

Đa số các khách hàng đến với các yêu cầu kỳ lạ, sai kỳ vọng, thêm các tính năng mà chưa bao giờ được trao đổi khiến cho việc chỉnh sửa không dừng và luôn lặp lại. Các khách hàng thay đổi xoành xoạch mỗi giây, đặc biệt là khi thiết kế, nhà thiết kế cuối cùng cảm thấy bị chê bai hoặc ngược đãi (đó là lý do tại sao chúng tôi có các trang web như Khách hàng đến từ địa ngục)

Mẹo nhanh:

  • Tạo các bản mẫu hoạt họa là cách tốt để trình diễn ý tưởng của bạn. Dùng các tool như  Adobe XD, SketchInVision etc. Chỉ bắt đầu quá trình phát triển khi thiết kế đã được duyệt.
  • TỐt nhất là thiết lập một timeline phù hợp khi bạn bắt đầu. Mọi nhu cầu phát sinh thêm vào timeline và cột mốc của dự án sẽ sinh ra những điều không mong đợi.
  • Giữ bình tĩnh!! Đừng để cảm xúc xâm chiếm bạn, hãy nhớ rằng các khách hàng họ chưa từng trải qua các trường lớp đào tạo nghệ thuật và họ không biết rằng text màu đỏ trên một background xanh lá cây không phải là lựa chọn tốt cho việc dễ đọc. Hãy giải thích lý do quyết định của bạn.
  • Hãy nhớ rằng website đó là dành cho khách hàng của bạn, bạn muốn họ hạnh phúc với nó, việc tốt nhất là cần đưa ra những khuyến nghị thay đổi, nếu họ không đồng ý, hãy làm hết sức theo ý họ 🙂

5. CSS bị đánh giá thấp

CSS đa phần gây bực bội vì không ai thực sự dành thời gian học các thứ liên quan. Họ luôn mắc kẹt với cùng một vấn đề.

Tôi từng làm việc với vài kỹ sư back-end thiên tài, những người rành OOP và họ nghĩ rằng responsive CSS là thứ gì đó ma thuật

Đó là lý do vì sao thôi tìm truyện tranh này cho bạn

CSS cũng như hầu hết các thứ khác, cần phải có thời gian để nắm bắt nó.

CSS chỉ vài phút để hiểu nhưng có thể tốn cả đời để master!

Nguồn: Blog Techtalk via blog.geekyants.com

Điện toán đám mây – Công nghệ mới cho doanh nghiệp vừa và nhỏ

Ở Việt Nam, khi nhu cầu điện toán đám mây của các doanh nghiệp trong nước đang trở nên rõ rệt hơn bao giờ hết, các nhà cung cấp dịch vụ lớn của thế giới đã nhanh chóng đổ bộ.

Với lợi thế, không mất chi phí đầu tư, giảm chi phí vận hành, nâng cấp hệ thống, chi phí hoạt động thường xuyên khác (chi phí cho đội ngũ IT, chi phí hạ tầng, chi phí bảo trì nâng cấp phần mềm, nâng cấp phần cứng,…)… Sử dụng điện toán đám mây trở thành “cứu cánh” cho các doanh nghiệp, đặc biệt là đối với các doanh nghiệp SMEs.

Tuy nhiên, với hạ tầng Internet Việt Nam, sử dụng các trung tâm dữ liệu đặt tại nước ngoài đi kèm với những rủi ro khác về hạ tầng mạng như: kết nối chậm, mất kết nối, chậm tốc độ truyền tải dữ liệu hay ứng dụng.

Do đó, việc lựa chọn bên thứ 3 cung cấp dịch vụ với hạ tầng trung tâm dữ liệu đặt trong nước với đường truyền ổn định hơn, hoạt động hỗ trợ linh hoạt hơn, phù hợp với văn hóa kinh doanh.

Là một trong những đơn vị tiên phong trong lĩnh vực cho thuê máy chủ, Cloud VPS, Cloud Server, Colo-cation, CDN, Cloud Hosting, Dedicated Server… cùng kinh nghiệm hơn 6 năm uy tín cung cấp dịch vụ điện toán đám mây, với mạng lưới hơn 1000 máy chủ, hàng ngàn khách hàng trong và ngoài nước, đồng thời cũng là một trong những đối tác lớn của VNPT, FPT, Viettel… KDATA sẵn sàng cung cấp hệ thống mạng luôn ổn định, mạnh mẽ và bảo mật cao cho các doanh nghiệp SMEs, doanh nghiệp khởi nghiệp cũng như cá nhân.

Trong tháng 12 này, KDATA cùng đội ngũ chuyên gia giàu kinh nghiệm sẽ cùng nhau xuất hiện tại Vietnam Web Summit 2017. Người tham dự sẽ không thể bỏ qua các dịch vụ tiêu biểu mà KDATA đang phát triển:

  • Shared hosting: Dịch vụ share hosting trên nền Windows và Linux với tài nguyên không giới hạn
  • Máy chủ ảo: Dịch vụ CloudVPS với độ bảo mật cao
  • Máy chủ riêng: Cung cấp dịch vụ cho thuê máy chủ cấu hình mạnh mẽ, giá rẻ
  • Chỗ đặt máy chủ: Cung cấp chỗ đặt máy chủ tại datacenter VNPT, Viettel, FPT,CMC
  • CDN: Cung cấp dịch vụ CDN với mạng lưới rộng khắp
  • Tổng đài ảo: Cung cấp tổng đài ảo trên nền điện toán đám mây
  • Private Cloud: Bạn có thể tự thiết kế và vận hành private cloud theo ý mình, với máy chủ của KDATA cung cấp

Nhanh tay đăng kí tại https://vietnamwebsummit.com/vi/ve-tham-du/ để gặp gỡ các chuyên gia của KDATA tại Vietnam Web Summit 2017 nhé!

KDATA đang tuyển dụng các vị trí:

  • 03 Quản trị hệ thống
  • 03 Network
  • 02 Marketing
  • 03 Sale

Contact Information:

  • Email:lanlt@kdata.vn
  • Tel:  028.73002299 or 028.73002299-101
  • Website: https://kdata.vn/

 

6 lý do khiến cho nền tảng kết nối (platform) thất bại – Dành cho các founder đang xây dựng platform

Đây là bài phân tích của Sangeet, tác giả của quyển sách Platform Revotulion.

Sự thành công của các công ty hoạt động theo mô hình nền tảng (Platform) Airbnb và Uber là rất ấn tượng, vì thế chúng ta rất ít bàn tới những khó khăn mà những doanh nghiệp này phải đối mặt trong giai đoạn mới thành lập. Mỗi doanh nghiệp nền tảng kết nối đều luôn có rất nhiều khó khăn cần phải giải quyết. Và Apple cùng với Google, hai công ty giá trị nhất trên thế giới, cũng có những thất bại nhất định trong việc phát triển nền tảng, chúng tôi sẽ dẫn chứng cụ thể ở phần sau. Bằng việc nghiên cứu những thành công và thất bại, chúng ta có thể xác định 6 lý do chính gây ra sự thất bại của các doanh nghiệp này. Tất cả chung quy đều là sự hiểu biết chưa được thấu đáo của những nhà quản lý trong việc vận hành và thực hiện chiến lược cạnh tranh cho doanh nghiệp nền tảng của mình.

Các doanh nghiệp nền tảng mang nhà sản xuất và người dùng đến với nhau và tạo ra sự trao đổi giá trị một cách có hiệu quả – ví du như công ty Uber đã kết nối những tài xế và khách hàng, hay như Youtube kết nối các người làm video và người xem. Và họ thúc đẩy hiệu ứng mạng lưới này – càng có nhiều người tham gia vào nền tảng đó thì càng có nhiều lợi ích được sinh ra. Những sai lầm trong việc quản lý khi ngăn cản sự trao đổi giá trị hay các hiệu ứng mạng lưới có thể hủy hoại một doanh nghiệp nền tảng kết nối. Bây giờ chúng ta đi vào chi tiết những sai lầm này.

1. Thất bại trong việc tối ưu hóa về “độ mở” của nền tảng

Bởi vì các nền tảng phụ thuộc vào giá trị mà những người tham gia tạo ra, do đó cần quản lý hiệu quả về “độ mở” của các nền tảng kết nối – độ mở ở đây chính là mức độ tiếp cận của khách hàng, nhà sản xuất và những người khác tới các nền tảng kết nối, và những điều mà họ được phép thực hiện trên nền tảng này. Nếu một nền tảng quá khép kín sẽ ngăn cản những người tham gia tiềm năng, lúc đó các hiệu ứng mạng lưới sẽ không được phát huy; còn nếu như quá rộng mở thì sẽ có các nhân tố phá hủy các lợi ích, ví dụ như những đóng góp kém chất lượng của người tham gia hoặc là một vài người hành xử không đúng mực khiến những người khác rời bỏ nền tảng.

Steve Jobs đã thất bại trong việc quản lý về độ mở của Apple vào những năm 1980. Ông đã tính phí những nhà phát triển cho bộ phát triển phần mềm toolkits – điều này đã ngăn cản những nhà sản xuất phần mềm tham gia vào nền tảng Apple của ông. Kết quả là Apple phải vật lộn để tạo ra một nền tảng rất mạnh để kết nối khách hàng của Apple với các nhà sản xuất phần mềm. Trong nhiều năm, sự thâm nhập thị trường của Apple giữ ở mức một chữ số. Apple đã giải quyết sự cân bằng này bằng cách mở nền tảng iOS cho các nhà phát triển phần mềm cùng tham gia. Trái ngược với trường hợp của Apple, Bill Gates lại mở Windows cho cả các nhà phát triển phần cứng và phần mềm, khiến cho Windows trở thành nền tảng máy tính nổi bật nhờ khả năng kết nối khách hàng với các nhà phát triển phần cứng và phần mềm.

Tuy nhiên các nền tảng có thể trở nên quá rộng mở. Các nền tảng phải duy trì đủ quyền kiểm soát đối với tài sản cốt lõi để kiểm soát hệ sinh thái và tạo ra doanh thu. Google đã học được điều này khi mà Amazon và Samsung đã tạo ra hai nhánh của nền tảng mở Android để tạo ra những phiên bản mã nguồn mở cho chính mình (Amazon, Samsung). Google Android đã nhanh chóng mất thị phần vào tay các phiên bản mới này. Google nhanh chóng lấy lại quyền kiểm soát hệ thống Android bằng việc giới hạn quyền truy cập các dịch vụ khó tái tạo như bản đồ và di chuyển các giao diện lập trình ứng dụng (API) quan trọng sang Google Play Store độc quyền của họ. Câu chuyện của Android đã chỉ ra rằng độ mở của các nền tảng là một trong những quyết định quản lý then chốt để xác định sự thành công hay là thất bại của nền tảng đó.

2. Thất bại trong việc liên kết với các nhà phát triển

Xác định đúng về độ mở của các nền tảng là điều cần thiết nhưng chưa đủ. Chủ sở hữu nền tảng cũng phải chỉ ra những điều mà các nhà phát triển phần mềm có được nếu họ đóng góp vào nền tảng. Năm 2013, công ty Johnson Controls mời các nhà phát triển giúp họ xây dựng Panoptix, một nền tảng về hiệu suất năng lượng cho các tòa nhà và không gian văn phòng. Nhưng tới đầu năm 2015, họ đã dừng việc chấp nhận những đề xuất mới cho việc mở rộng thị trường và ngừng hỗ trợ giao diện lập trình ứng dụng API cho những nhà phát triển bên ngoài. Nền tảng Panoptix không còn đủ hấp dẫn các ứng dụng mới để biện minh cho việc đổ các tài nguyên để hỗ trợ phát triển bên ngoài giới hạn này.

Việc mở cửa và đưa ra các lợi ích là chưa đủ. Những nền tảng thành công cần phải quảng bá, cung cấp cho các nhà phát triển nguồn lực để đổi mới, phản hồi về thiết kế và hiệu quả, và có phần thưởng cho những người tham gia. Hiểu đơn giản là: Để tổ chức một sư kiện thành công bạn phải lên kế hoạch cẩn thận, mời khách mời phù hợp, cung cấp đồ ăn ngon và cạnh tranh được với các sự kiện khác. Nếu Android đưa ra một bữa tiệc ở Hawaii gồm có năm món, với việc di chuyển miễn phí, các khách mời được gặp gỡ Robert Downey Jr. và Sandra Bullock. Cùng đêm đó, công ty Johnson Controls mở tiệc chỉ có bánh qui ở Cleveland và khách mời phải tự chi trả. Vậy các nhà phát triển sẽ tham gia bữa tiệc nào?

3. Thất bại trong việc chia sẻ lợi nhuận

Lý do để tham gia một nền tảng là việc có những tương tác giá trị. Khách hàng, những nhà sản xuất và nền tảng đều chiến thắng nếu có sự phân chia lợi ích phù hợp cho tất cả mọi người tham gia. Nếu một bên mà không nhận được đúng lợi ích thì chẳng còn lý do gì để họ tham gia cả. Quay lại năm 2000, rất nhiều nhà sản xuất ô tô bao gồm Daimler-Chrysler, Ford, GM, Nissan và các hãng khác đã đầu tư vào Covisint, một thị trường trực tuyến kết nối người mua và nhà cung cấp phụ tùng ô tô. Không may là cấu trúc quyền sở hữu của Covisint và sự đấu giá đã tạo ra sự thiên vị cho một vài công ty (là khách hàng trên nền tảng này) trong khi đó lại ép các nhà cung cấp tham gia vào một cuộc cạnh tranh về giá rất khốc liệt, khiến họ có ít đi hoặc không có lợi nhuận. Vì vậy mà các nhà cung cấp phụ tùng này rời khỏi nền tảng và thị trường này không bao giờ có lợi nhuận bền vững. Năm 2014, số tài sản còn lại được bán với giá 7 triệu USD, một con số rất nhỏ so với 500 triệu USD, số tiền mà các công ty sản xuất ô tô đã đầu tư vào đây.

Một qui tắc đơn giản cho các nhà quản lý nền tảng là hãy lấy ít hơn giá trị mà bạn tạo ra và chia sẻ những giá trị đó một cách công bằng với những người người tham gia vào nền tảng.

4. Thất bại trong việc xác định đúng phía của nền tảng

Một nhà quản lý nền tảng phải xác định cận thẩn phía nào của thị trường nền tảng cần chú trọng và khi nào cần chú trọng. Khi mới ra mắt, đôi khi cần tập trung thu hút khách hàng hơn là nhà sản xuất, đôi khi là ngược lại, và cũng có lúc lại cần tập trung vào cả hai.

Mặc dù được quảng bá rầm rộ và có nhà lãnh đạo nền tảng giàu kinh nghiệm, nền tảng Google Health vẫn thất bại. Google Health được dự định là địa chỉ hàng đầu để khách hàng tập hợp các thông tin về sức khỏe của mình. Google đầu tiên đã ưu tiên chiến lược tập trung vào người tiêu dùng, chiến lược này hoạt động rất tốt qua các công cụ tìm kiếm, email và bản đồ. Tuy nhiên thời điểm đó, Google cần tập trung trước tiên vào những nhà cung cấp – phía bên kia của thị trường. Khách hàng có thể sẽ sử dụng dịch vụ nếu như bác sĩ và các công ty bảo hiểm, những người có những thông tin của họ, sẵn sằng tham gia. Nhưng họ lại không hoan nghênh sự giám sát hay việc mất kiểm soát đối với những dữ liệu mà họ có. Nền tảng thông tin y tế muốn thành công thì phải đảm bảo sự tham gia của họ.

5. Thất bại trong việc ưu tiên thu hút người dùng hơn là việc tạo doanh thu

Bạn có nhớ đến Billpoint? Đó là hệ thống thanh toán kĩ thuật số mà eBay đã phát triển trước khi bỏ cuộc và mua lại PayPal. Là một phần trong nền tảng đã được thiết lập (eBay), lẽ ra Billpoint sẽ có được chiến thắng. Nhưng mà trong khi Billpoint tập trung vào sự ngăn chặn lừa đảo thì PayPal tập trung vào sự đơn giản khi sử dụng. Trong khi Billpoint tính phí giao dịch cao hơn thì PayPal lại tặng cho người sử dụng với số tiền là 5 USD và 10 USD cho những người sử dụng giới thiệu cho những người khác. Việc ngăn chặn lừa đảo có thể làm giảm chi phí nền tảng trong thời gian dài nhưng điều này tạo áp lực cho những giao dịch của người sử dụng và ngăn cản các hoạt động tạo giá trị. PayPal đã chấp nhận các chi phí gian lận và tập trung vào sự tăng trưởng nhanh chóng bằng việc đơn giản hóa giao dịch và khuyến khích những người tham gia giới thiệu cho những người khác. Vì vậy, PayPal đã nhanh chóng vượt qua Billpoint khi được lựa chọn là hệ thống thanh toán của eBay. Thừa nhận thất bại vào năm 2002, eBay đã mua lại PayPal với giá 1,4 tỉ USD và từ bỏ Billpoint một năm sau đó. Billpoint đã mắc sai lầm khi mà ngay từ đầu đã tập trung vào doanh thu thay vì thu hút nhiều người tham gia.

6. Thất bại trong việc nhìn ra được viễn cảnh

Có lẽ thất bại lớn nhất của nền tảng đơn giản là không nhìn thấy được viễn cảnh trong tương lai. Đây cũng là một trong những điều mà các công ty truyền thống khó tránh khỏi. Sai lầm ở đây là họ không bao giờ chấp nhận quan điểm là họ có thể bán sản phẩm thì họ nên xây dựng một hệ sinh thái. Sony, Hewlett Packard (HP) và Garmin đã mắc sai lầm khi chú trọng vào sản phẩm hơn là xây dựng nền tảng. Trước khi iPhone được giới thiệu vào năm 2007, HP đã thống trị thị trường máy tính cầm tay cho ngành khoa học và tài chính. Mặc dù ngày nay, khách hàng có thể mua các ứng dụng máy tính (mobile app) gần như hoàn hảo trên iTunes hoặc trên Google Play với một chi phí rất nhỏ so với một chiếc máy tính vật lý. Apple và Google không tạo ra các giả lập này; họ đơn giản là cung cấp một nền tảng để kết nối các nhà sản xuất ứng dụng và những người cần đến máy tính.

Sony đã bán một vài sản phẩm điện tử tốt nhất mà họ từng sản xuất ra: Sony đã từng chiếm lĩnh thị trường máy nghe nhạc cá nhân với máy nghe nhạc Walkman. Nó đã từng là máy nghe nhạc tốt nhất thế giới. Đến năm 2011, PlayStation của hãng trở thành hệ thống máy chơi game bán chạy nhất mọi thời đại. Dù vậy, với tất cả năng lực công nghệ của mình, Sony quá tập trung vào sản phẩm mà không đủ để tạo ra một nền tảng. (Cái gì đã trở thành thay thế cho máy nghe nhạc của Sony? Một nền tảng – iOS – đã nuốt chửng luôn họ.) Garmin, giống như một bản đồ tích hợp, cũng chịu chung một số phận như vậy. Garmin đã bán được 100 triệu đơn vị sau 23 năm có mặt trên thị trường. Nhưng mà iPhone bán được 700 triệu đơn vị chỉ sau tám năm. Ngày càng nhiều người tìm đường qua iPhone hơn là qua Garmin, không chỉ vì bản đồ của Apple mà còn của Google và Waze. Khi là một nền tảng, iOS và Android có một hệ sinh thái các nhà sản xuất, khách hàng và những người khác, điều này giúp họ giành chiến thắng trước các sản phẩm như camera của Cisco Flip, the Sony PSP, the dịch vụ ảnh Flickr, máy ghi âm the Olympus, the Microsoft Zune, đèn pin Magnus, và các thiết bị theo dõi sức khỏe Fitbit.

Khi một nền tảng gia nhập thị trường, các nhà quản lý sản phẩm tập trung không chỉ vào việc đo lường những lỗi sai của sản phẩm, mà còn suy nghĩ về những tư duy sai hướng.

Tham khảo thêm các vị trí tuyển dụng việc làm ngành it lương cao tại Topdev