Nhiều người than thở không thể tìm được việc dù đã nỗ lực tìm kiếm, trau chuốt hồ sơ, học cách tham gia phỏng vấn… Vậy vấn đề nằm ở đâu?
Theo các chuyên gia nhân sự, có nhiều lý do khiến một ứng viên bị loại, trong đó có những lý do phổ biến như ứng viên không tìm hiểu kỹ thông tin về công ty, về vị trí họ ứng tuyển… Thậm chí có ứng viên khi đi phỏng vấn đã “bê nguyên” phần giới thiệu trên trang web công ty để trả lời khi được hỏi “Anh/chị biết gì về công ty chúng tôi?”…
Vậy phải tìm hiểu thông tin công ty ra sao và trả lời phỏng vấn thế nào để gây ấn tượng? Các chuyên gia tuyển dụng mách bạn một số bí quyết:
1. Nói có mục đích. Hãy nói những điều giúp nhà tuyển dụng thấy được chuyên môn, kỹ năng của bạn cũng như phong cách làm việc, thành tích trước đây.
Nếu có thể hãy kể lại một vài tình huống mà bạn/công ty cũ đối mặt, và cách bạn giải quyết chúng. Có thể dành ít phút để nói về cảm giác của bạn lúc đó và những điều bạn rút ra được từ các thách thức này.
2. Nói đơn giản, không dùng ngôn từ khó hiểu. Hãy nói về bản thân một cách đơn giản, dễ hiểu, không lạm dụng các cụm từ hay các câu sáo rỗng. Nếu bạn nói: “Tôi là một người làm theo nhóm hướng tới kết quả, có động lực cao để thành công”, thì cho dù mô tả này là đúng, bạn cũng không gây ấn tượng được với nhà tuyển dụng.
3. Đừng là “máy nói”. Bạn tìm việc, đương nhiên nên tham khảo phần giới thiệu (About us) trên trang web công ty để nắm thông tin. Nhưng đừng lặp lại như vẹt các thông tin này khi đi phỏng vấn.
Thay vào đó, hãy tìm kiếm thêm thông tin về công ty từ nhiều nguồn khác nhau (báo chí, mạng xã hội, người quen, người làm cùng lĩnh vực với công ty…), chắt lọc và cô đọng các thông tin giá trị. Sau đó, dùng nó để chứng minh sự hiểu biết của mình về công ty, bạn sẽ khiến nhà tuyển dụng ấn tượng đấy!
4. Kể những câu chuyện có liên quan. Hãy chuẩn bị trả lời những câu hỏi mà qua đó nhà tuyển dụng muốn thăm dò về phong cách làm việc, tính cách và đạo đức của bạn. Họ sẽ phân tích câu trả lời của bạn một cách cẩn thận để xem liệu bạn có thích hợp với môi trường làm việc của công ty không.
Do đó, hãy chuẩn bị các câu chuyện minh họa ngắn để nhà tuyển dụng thấy bạn đã xử lý các tình huống căng thẳng trong công việc ra sao, bạn giải quyết xung đột cá nhân như thế nào; cho họ thấy bạn có thể đóng góp gì cho nhóm, khả năng giải quyết vấn đề/khả năng lãnh đạo nhóm của bạn ra sao…
5. Nhiệt tình và mỉm cười. Nếu bạn tỏ ra căng thẳng hoặc thiếu tự tin, hoặc nếu bạn ra vẻ quá tôn kính, bạn đã tự khiến mình mất điểm trong mắt nhà tuyển dụng. Thay vào đó hãy thả lỏng, tỏ ra lạc quan và sẵn sàng đối mặt với các câu hỏi khó, nhà tuyển dụng sẽ thấy thú vị với bạn đấy!
6. Hỏi sâu sắc. Những câu hỏi tiết lộ rất nhiều điều về bạn. Đó là cách để bạn chứng minh rằng mình đã suy nghĩ về vai trò đang tìm kiếm ở công ty. Thay vì hỏi: “Tôi sẽ làm việc X?” hãy hỏi: “Tôi có cơ hội để làm việc X?”, hoặc “Bạn làm việc X theo cách này hay cách kia?”.
7. Thận trọng khi nói về sếp cũ/nơi làm việc cũ. Công việc của người phỏng vấn là tạo ra môi trường thân thiện, tôn trọng để bạn cảm thấy thoải mái và bộc lộ bản thân. Tuy nhiên đừng nhầm lẫn nhà tuyển dụng là bạn, rồi “tuôn” ra hết mọi thứ trong lòng bạn, như bạn đã gặp phải ông sếp cũ khó chịu thế nào, các đồng nghiệp thiếu chuyên nghiệp ra sao…
Làm thế, bạn đã tự đánh mất cơ hội của mình, bởi không nhà tuyển dụng nào ưa một người chưa chi đã “nói xấu” người khác. Ngoài ra, những điều bạn nói cũng có thể sẽ tới tai sếp cũ/công ty cũ của bạn, phá hỏng mối quan hệ của bạn và họ.
Cạnh đó, cũng không hỏi xem liệu bạn có được tuyển, bạn sẽ được trả lương bao nhiêu hoặc bạn được nghỉ mấy ngày trong tháng/trong năm vì chưa phải lúc.
Nếu bạn vẫn tiếp tục đọc bài viết này thì có nghĩa là web font của bạn không quan trọng đối với nhãn hiệu cũng như nó không có giúp cho việc đọc dễ dàng hơn. Tuy vậy nó không có nghĩa là bạn không nên dùng tới nó.
Trừ khi bạn đụng tới Flash Of Unstyled Text (khiến các dòng chữ bị chập chờn do reload). Bởi vì nó cực xấu.
Hơn nữa, nó còn có nghĩa là ta phải load 542 KB fonts trên browser.
Dưới đây là trang web của tờ báo New Republic
Phần chữ trong bài viết hiện ra trong vòng 1.45 giây. Kết quả khá là tốt.
Tới giây thứ 1.65, hình ảnh đạ được load và hiển thị. Nhưng kể từ đây mọi thứ bắt đầu rối rắm lên.
9 giây sau, tại 10.85, web font cuối cùng cũng sẵn sàng, nội dung bài viết được đổi kiểu chữ từ system font qua web font.
Không dừng lại đó, ở giây thứ 12.58, nó lại lặp lại thêm lần nữa với font được load mới.
Ngoài ra, những font được dùng trong hình là ‘Balto’ và ‘Lava’ nặng tới 542 KB, và còn tốn chi phí khoảng $2,000/năm để sử dụng cho website của bạn.
Sẽ rất nhiều người khi mới đọc tựa bài viết liền cho rằng chủ bài viết đang than phiền và không hề thấy được giá trị của typography đẹp. Nhưng thật ra là hoàn toàn ngược lại. Tôi luôn đề cao sự hài hòa và chuẩn trong typography. Và hơn hết, những vấn đề trên có thể được giải quyết dễ dàng với system font.
…
Những có lẽ New Republic không hề muốn như vậy! Có lẽ đã có điều gì đó khiến cho mọi thứ sai đến như vậy!
Và làm thế nào để ta có thể tránh được vấn đề tương tự với trang web của mình?
Tôi nghĩ rằng có lẽ là trong quá trình phát triển, designer đã xem qua các bản Sketch, hoặc thử với những font được cài đặt local. Thế nên web font mới được cho là không có hệ quả và nhược điểm gì.
Đây hoàn toàn sai sự thật, điều mà bất cứ ai sài internet đều có thể nói cho biết.
Do đó hãy hiểu rõ web font theo cách nhìn của user và tránh xa FOUT, nếu không thể thì hãy chọn system font.
Bạn có muốn dùng cùng một font cho mọi thiết bị?
Tôi chỉ đưa câu hỏi này vào bởi vì có khá nhiều người nói về vấn đề này. Và quả thật là tôi không thể hiểu nổi.
Tại sao tôi lại muốn cùng một kiểu font trên mọi thiết bị? Theo như tìm hiểu, thì nhiều người đặt nặng vấn đề nhất quán. Nhưng liệu nó có cần thiết không?
Và thật sự thì tôi không hề quan tâm sự khác biệt giữa các font chữ trên những thiết bị khác nhau. Điều quan trọng nhất vẫn là dễ đọc.
Dưới đây là so sánh giữa hai font là San Francisco và Roboto, dùng trên desktop và mobile.
Nhưng điều này hoàn toàn đến từ cảm nhận của riêng tôi. Và có lẽ chỉ có mình tôi là không quan tâm cũng như không chú ý đến sự khác biệt font trong khi mọi người trên quả đất này thì ngược lại.
…
Tôi cũng có nghe rằng việc dùng cùng một font trên mọi thiết bị sẽ giúp bảo đảm sự sự nhất quán cũng như nó phân chia không gian giống nhau.
Điều đó là sai hoàn toàn.
Safari trên macOS
Chrome trên Windows
Tôi sử dụng macOS và Windows với tần suất gần như là ngang nhau và thường thì chữ trên windows nhìn sẽ dịu hơn. Nhưng Windows lại có vụ ClearType khiến cho trải nghiệm của mỗi user mỗi khác.
Do đó mà bạn sẽ phải chấp nhận rằng kể cả dùng chung một web font nhưng chúng sẽ được hiển thị khác nhau trên hệ điều hành khác nhau.
Nếu bạn đã hiểu rõ rằng việc chọn một font cho mọi thiết bị là điều không cần thiết nhưng vẫn muốn đi theo con đường đó thì web font chính là lựa chọn cho bạn. Còn nếu bạn cũng như tôi thì hãy đọc tiếp…
Bạn có thấy vui hơn không khi dùng web font?
Vậy là bạn có một font không quan trọng với nhãn hiệu, cũng không giúp việc đọc dễ dàng hơn, có thể load mà không làm chữ bị reload, và việc không nhất quán trên các thiết bị không hề là một vấn đề đối với bạn.
Có thế bạn cũng nhận ra rằng tôi không hề đả động tới câu hỏi “cái nào nhìn đẹp hơn?”. Tôi bảo đảm với bạn rằng không phải tôi không quan tâm tới cái đẹp.
Lí do cho việc bỏ nó là vì sự nhầm lẫn trong suy nghĩ khi cho rằng web font luôn đẹp hơn system fonts.
Hãy nhìn sâu hơn, kĩ càng hơn các “system” fonts này… với ‘San Francisco’ trên macOS và iOS, ‘Roboto’ trên Android, và ‘Segoe UI’ trên Windows.
Đây chính là những lựa chọn của Apple, Google và Microsoft cho khuôn mặt của interfaces của họ. Đã có rất nhiều công sức đổ vào việc phát triển chúng, thế nên chất lượng thì chắc chắn đã vượt mặt những người anh em họ như ‘Open Sans’, ‘Proxima Nova’ và ‘Lato’.
System fonts vẫn có thể đẹp như web fonts, và nếu bạn muốn chăm chút thì hãy thử site mình nhìn như thế nào với system font trước đã. Biết đâu được nó lại nhìn tuyệt hơn thì sao?
…
Chỉ nên dùng web font khi bạn thật sự muốn nó. Nhưng nếu bạn đã trải qua những bước tôi nói trên và cảm thấy rằng web font không phù hợp nữa thì hãy thử đổi qua sử dụng system font xem.
Ý kiến của tôi
Cái kết ở trên thật là nhàm chán đúng không? “Bạn cứ làm điều mà bạn muốn!”
Ôi giời ạ!
Giờ thì tới phần quan trọng nhất đây! Điều mà tôi nghĩ.
Tôi cho rằng web font nên được dùng như default mode luôn thay vì phải suy nghĩ chi cho mệt.
Tôi tin rằng là hơn phân nữa số lượng website nên bỏ quách web font đi cho khỏe.
Web font mà dở thì nó sẽ khiến load chậm và kết cục là làm giảm traffic.
Trường hợp trong hình là cực kì tệ khi user phải nhìn vào trang trắng không trong vòng tới 3 giây chỉ để load font.
Nó cũng như việc tôi mời bạn tới nhà chơi nhưng bắt bạn đứng quay mặt vào góc tường trong vòng 3 tiếng đồng hồ trong khi tôi lo chải tóc mình vậy.
Nếu như site của bạn cũng load như vậy, thì nó chả khác nào như bạn đang nói font nó quang trọng hơn nội dung trong cái site vậy.
Sau là đoạn văn được dùng với system font và với wunderfont, thứ bắt user phải chờ tới 3 giây để load.
Sự khác nhau hầu như không đáng kể nhưng đổi lại bạn hi sinh tới 3 giây vô giá của người dùng. Có thể nói đây là cuộc trao đổi tệ nhất trong lịch sử.
Dùng web font như thế nào cho đúng?
Trái ngược với những gì ở phía trên, tôi hoàn toàn tin rằng chúng ta không nên bỏ web font đi. Thay vào đó hãy suy nghĩ về cách dùng nó đúng đắn nhất có thể.
…
Lí do web font quá chậm là vì browser không hề biết tới nó mãi cho khi đến gần cuối quá trình load. Browser phải load vô số HTML và CSS trước khi biết được sợ thích bóng bẩy của bạn.
Mãi cho đến lúc đó thì web font mới được load.
Trong hình trên, thanh màu xanh là HTML, tím là CSS và xám là font file.
Bạn có thể thấy là trong lúc browser đang parsing HTML, nó hiện ra một reference liên quan tới CSS file và bắt đầu download nó. Bạn có thể nhận ra là chỉ sau khi CSS kết thúc thì browser mới nhận ra rằng trang bị thiếu font. Nói cách khác, website của bạn cầm đèn chạy trước font.
Và nội dung sẽ chỉ hiển thị khi font đã được tải về hoàn tất.
Lựa chọn khác cho bạn là load font thông qua CSS. Nói cách khác là ta load một CSS file define một số font-face rules chỉ đến font files trên Google’s servers. Vậy là nó sẽ load theo cách sau:
Màu xanh lá cây là font file. Kết quả gần như nhau, vẫn phải chờ quá lâu.
…
Nhưng nếu bạn có thể thêm vào một dòng code và bắt đầu download font sớm hơn thì sao…
Hãy bỏ code sau vào HTML trước khi bạn define CSS file.
Thêm một điều nữa… font của bạn giờ đã được download sớm hơn nhiều. Tuy vậy vẫn con vài trăm milliseconds giữa CSS cập bến và font cập bến.
Trong khoảng thời gian này, browser biết nên xài font gì nhưng vẫn chưa có nó. Điều thú vị là ta có thể defining font-display property trong @font-face rule để khiến browser làm theo ý ta.
Tôi muốn ngăn việc hiển thị nội dung cho đến khi font xuất hiện để tránh vấn đề FOUT bằng cách setting font-display thành block.
Dưới đây là codepen dùng để list các font và cho bạn biết cái nào có hỗ trợ cho thiết bị của bạn.
AWS là công ty con của Amazon, AWS cung cấp các dịch vụ hạ tầng trên điện toán đám mây dựa trên nền tảng công nghệ phía sau do Amazon sở hữu.
Theo công bố của công ty này, hiện dịch vụ AWS đang phục vụ hơn 2.300 cơ quan chính phủ, 7.000 tổ chức giáo dục và 22.000 tổ chức phi lợi nhuận trên toàn thế giới.
AWS với lợi thế dựa trên các nguồn lực về trí tuệ nhân tạo (AI), giải pháp lưu trữ và các giải pháp về ảo hóa , máy chủ… để giải quyết các bài toán này một cách nhanh nhất rồi cung cấp cho khách hàng, điều này rất hữu ích trong bối cảnh dữ liệu thu thập của khách hàng ngày càng có xu hướng phình to theo cấp số nhân.
Hiện AWS cung cấp hơn 90 dịch vụ, chẳng hạn như tính toán, lưu trữ, cung cấp nội dung, cơ sở dữ liệu, phân tích, các dịch vụ ứng dụng, quản lý và triển khai, mạng, truyền tải trực tiếp ứng dụng và máy ảo desktop, các dịch vụ di động, trí tuệ nhân tạo, năng suất kinh doanh. Ngoài ra còn nhiều dịch vụ điện toán đám mây khác cho phép khách hàng xây dựng ứng dụng, dịch vụ của họ và vận hành chúng trên nền tảng đám mây AWS.
Năm nay, các kĩ sư kinh nghiệm của Amazon Web Services sẽ mang đến chuỗi chuyên đề Serverless, giúp người tham dự có được những trải nghiệm thực tế với AWS & các ứng dụng Serverless, nắm rõ kiến thức cơ bản khi xây dựng ứng dụng Serverless & Microservices bằng AWS Lambda, Amazon API Gateway, Amazon S3, Amazon DynamoDB & Amazon Cognit.
Từ đây, bạn sẽ biết được cách build và deploy ứng dụng serverless của riêng mình, đáp ứng nhu cầu sử trường hợp trong thực tế như Web applications, Analytics…
Firebase là gì? Có nên lựa chọn Firebase cho phát triển ứng dụng của bạn không? Trước đưa ra quyết định, mời bạn đọc hết bài viết dưới đây của TopDev để có cái nhìn toàn diện về Firebase
Firebase là gì?
Firebase là một nền tảng mạnh mẽ cung cấp các dịch vụ backend-as-a-service (BaaS) giúp các nhà phát triển xây dựng, cải thiện, phát triển và duy trì các ứng dụng web và di động.
Firebase hỗ trợ các nền tảng Android, iOS, web và Unity, và cung cấp các dịch vụ như lưu trữ đám mây và cơ sở dữ liệu NoSQL.
Firebase được tạo ra vào năm 2011 và được Google mua lại vào năm 2014, từ đó nó đã trở thành một phần quan trọng trong hệ sinh thái phát triển ứng dụng của Google, giúp các nhà phát triển dễ dàng triển khai các tính năng mạnh mẽ mà không cần phải quản lý hạ tầng phức tạp. Vì vậy Firebase còn có tên gọi khác là Google Firebase.
Firebase hoạt động như thế nào?
Firebase hoạt động bằng cách cung cấp các SDK cho phía client, cho phép ứng dụng tương tác trực tiếp với các dịch vụ backend mà không cần thiết lập bất kỳ middleware nào giữa ứng dụng và dịch vụ. Dưới đây là cách Firebase hoạt động và tương tác với các thành phần khác nhau của ứng dụng:
Tương tác trực tiếp với dịch vụ backend
Các Client SDK do Firebase cung cấp cho phép ứng dụng của bạn truy cập và tương tác trực tiếp với các dịch vụ backend của Firebase. Điều này có nghĩa là bạn có thể viết mã để truy vấn cơ sở dữ liệu hoặc gọi các dịch vụ khác của Firebase ngay trong ứng dụng phía client mà không cần thông qua lớp trung gian.
So với phát triển ứng dụng truyền thống
Trong phát triển ứng dụng truyền thống, bạn thường phải viết mã cho cả phần frontend và backend. Mã frontend sẽ gọi các endpoint API được exposed bởi mã backend, và mã backend sẽ xử lý các tác vụ thực tế như truy vấn cơ sở dữ liệu, xác thực, và logic nghiệp vụ.
Tuy nhiên, với các sản phẩm của Firebase, phần backend truyền thống được bỏ qua, và công việc được chuyển sang phía client. Điều này giúp đơn giản hóa quy trình phát triển, đặc biệt là đối với các ứng dụng nhỏ hoặc các prototype nhanh.
Quản lý và điều hành
Quyền truy cập quản trị vào các sản phẩm của Firebase được cung cấp qua Firebase console. Firebase console cho phép bạn cấu hình và quản lý các dịch vụ của Firebase như cơ sở dữ liệu, xác thực, lưu trữ và các dịch vụ khác một cách dễ dàng.
Nền tảng dịch vụ
Với cách thức hoạt động như vậy, một số người có thể gọi Firebase là một nền tảng dưới dạng dịch vụ (Platform as a Service – PaaS) hoặc backend dưới dạng dịch vụ (Backend as a Service – BaaS). Tuy nhiên, Firebase cung cấp một hệ sinh thái riêng biệt với các dịch vụ tích hợp mạnh mẽ, nên việc xếp nó vào một trong các hộp này không hoàn toàn chính xác. Firebase cung cấp một bộ công cụ và dịch vụ giúp đơn giản hóa và tăng tốc quy trình phát triển ứng dụng.
Tóm lại, Firebase hoạt động bằng cách cho phép ứng dụng phía client tương tác trực tiếp với các dịch vụ backend thông qua các SDK mà không cần middleware. Điều này khác với phát triển ứng dụng truyền thống, nơi cần viết mã cho cả frontend và backend. Firebase console cung cấp quyền truy cập quản trị cho các dịch vụ này, và Firebase thường được xem như một nền tảng hoặc backend dưới dạng dịch vụ, mặc dù nó mang lại trải nghiệm và tích hợp độc đáo cho các nhà phát triển.
Các tính năng của Firebase
Firebase cung cấp một loạt các tính năng để hỗ trợ các nhà phát triển trong việc xây dựng, phát hành, giám sát, và tương tác với ứng dụng của họ. Các tính năng này được chia thành ba nhóm chính: Build, Release & Monitor, và Engage.
Firebase Build Features
Databases: Firebase cung cấp hai cơ sở dữ liệu trên đám mây là Cloud Firestore và Realtime Database để lưu trữ và đồng bộ hóa dữ liệu.
Machine Learning: Firebase ML giúp các nhà phát triển dễ dàng tích hợp các khả năng học máy vào ứng dụng di động của họ.
Cloud Functions: Đây là một framework serverless cho phép chạy mã backend để phản hồi các sự kiện kích hoạt từ các tính năng của Firebase hoặc các yêu cầu HTTPS.
Authentication: Firebase Authentication cung cấp thư viện giao diện người dùng dễ sử dụng, backend và SDK cho việc xác thực người dùng, hỗ trợ nhiều nhà cung cấp như Google, Facebook, và Twitter.
Cloud Messaging: Firebase Cloud Messaging (FCM) là một dịch vụ gửi thông báo và tin nhắn dữ liệu miễn phí, hỗ trợ đa nền tảng.
Hosting: Firebase Hosting cung cấp giải pháp lưu trữ có thể mở rộng cho các ứng dụng web và dịch vụ microservices.
Cloud Storage: Dịch vụ này cho phép lưu trữ và quản lý tài nguyên ứng dụng và nội dung do người dùng tạo ra một cách an toàn.
Emulator Suite: Firebase cung cấp Local Emulator Suite để tích hợp và thử nghiệm các tính năng khác nhau mà không tốn thêm chi phí.
Firebase Release & Monitor Features
Crashlytics: Firebase Crashlytics là một công cụ báo cáo lỗi theo thời gian thực, giúp các nhà phát triển xác định và sửa chữa các vấn đề về độ ổn định.
Analytics: Google Analytics được tích hợp với Firebase, cung cấp thông tin quan trọng về hành vi người dùng và hiệu suất ứng dụng.
Performance Monitoring: Tính năng này cung cấp thông tin chi tiết về các đặc điểm hiệu suất của ứng dụng trên iOS, Android và web.
Test Lab: Firebase Test Lab là một cơ sở hạ tầng đám mây để thử nghiệm ứng dụng trên nhiều thiết bị và cấu hình khác nhau.
App Distribution: Tính năng này đơn giản hóa quy trình kiểm thử beta bằng cách phân phối các phiên bản ứng dụng trước khi phát hành cho người thử nghiệm.
Firebase Engage Features
Remote Config: Firebase Remote Config cho phép các nhà phát triển thay đổi hành vi và giao diện ứng dụng mà không cần cập nhật ứng dụng.
Predictions: Tính năng này sử dụng học máy để tạo các phân đoạn người dùng động dựa trên hành vi dự đoán.
A/B Testing: Firebase A/B Testing giúp tối ưu hóa trải nghiệm ứng dụng bằng cách thử nghiệm các biến thể khác nhau của giao diện người dùng, tính năng và chiến dịch.
Dynamic Links: Firebase Dynamic Links là các URL thông minh dẫn người dùng đến các phần cụ thể của ứng dụng, bất kể ứng dụng đã được cài đặt hay chưa.
In-App Messaging: Tính năng này cho phép gửi các tin nhắn có mục tiêu và ngữ cảnh đến người dùng đang sử dụng ứng dụng.
Firebase cung cấp một bộ công cụ phong phú và mạnh mẽ giúp các nhà phát triển xây dựng, phát triển và duy trì các ứng dụng một cách hiệu quả và dễ dàng hơn.
Bảng giá sử dụng dịch vụ Google Firebase
Google Firebase cung cấp một gói miễn phí và một gói trả phí theo nhu cầu sử dụng. Dưới đây là chi tiết các gói dịch vụ:
Gói Spark (Miễn phí)
Gói miễn phí bao gồm 1 GB dung lượng lưu trữ cơ sở dữ liệu thời gian thực.
Gói Blaze (trả phí)
Gói Blaze là gói trả phí theo nhu cầu sử dụng với giá cả tăng dần khi người dùng mở rộng quy mô. Bảng giá chi tiết như sau:
Xác thực (Authentication): $0.01 cho mỗi xác thực sau 10,000 xác thực đầu tiên.
Người dùng có thể sử dụng công cụ tính toán giá của Blaze Plan để xác định tổng chi phí hàng tháng dựa trên yêu cầu sử dụng của từng thành phần Firebase mà họ sử dụng.
Firebase có an toàn không?
Google Firebase được coi là an toàn nhờ việc áp dụng nhiều biện pháp bảo mật và tuân thủ các tiêu chuẩn bảo mật quốc tế. Dưới đây là các biện pháp bảo mật chính mà Firebase sử dụng để bảo vệ dữ liệu của bạn:
Chứng nhận bảo mật: Các trung tâm dữ liệu của Firebase đều được chứng nhận SOC 2 Type 2 và ISO 27001, đảm bảo rằng chúng tuân thủ các tiêu chuẩn bảo mật và quản lý thông tin nghiêm ngặt.
Mã hóa dữ liệu: Mã hóa dữ liệu tại chỗ và khi truyền tải: Tất cả dữ liệu của Firebase đều được mã hóa cả khi lưu trữ và khi truyền tải qua mạng, đảm bảo rằng dữ liệu luôn được bảo vệ khỏi truy cập trái phép.
Kiểm soát truy cập dựa trên vai trò (RBAC): Firebase sử dụng kiểm soát truy cập dựa trên vai trò để cung cấp quyền truy cập chi tiết theo vai trò của người dùng. Điều này cho phép quản lý và kiểm soát ai có thể truy cập dữ liệu ứng dụng, giảm thiểu rủi ro từ truy cập trái phép.
Ghi nhật ký kiểm tra (Audit logging): Firebase ghi lại tất cả các hoạt động truy cập dữ liệu, cho phép các doanh nghiệp theo dõi ai đã truy cập vào dữ liệu ứng dụng và khi nào, giúp tăng cường khả năng phát hiện và phản ứng với các hành vi truy cập bất thường.
Nhờ các biện pháp bảo mật trên, Google Firebase đảm bảo dữ liệu của bạn được bảo vệ ở mức cao nhất
Ưu và nhược điểm của Firebase
Ưu điểm của Firebase
Gói miễn phí: Phù hợp cho người mới bắt đầu và các dự án nhỏ.
Cơ sở dữ liệu thời gian thực: Đồng bộ dữ liệu ngay lập tức giữa các người dùng.
Cộng đồng phát triển lớn: Nhiều tài liệu, ví dụ và hỗ trợ từ cộng đồng.
Nhiều dịch vụ tích hợp: Cung cấp lưu trữ, xác thực, phân tích, thông báo và nhiều dịch vụ khác.
Dễ dàng tích hợp: Firebase SDK dễ dàng tích hợp với các ứng dụng iOS, Android và web.
Bảo mật mạnh mẽ: Sử dụng các biện pháp bảo mật tiên tiến, bao gồm mã hóa dữ liệu và kiểm soát truy cập dựa trên vai trò.
Khả năng mở rộng: Dễ dàng mở rộng ứng dụng khi nhu cầu sử dụng tăng.
Hỗ trợ máy học: Tích hợp các API máy học giúp thêm các tính năng thông minh vào ứng dụng.
Hosting ổn định: Cung cấp giải pháp lưu trữ ổn định cho các ứng dụng web và dịch vụ microservices.
Phân tích và giám sát: Công cụ phân tích mạnh mẽ giúp theo dõi và giám sát hiệu suất ứng dụng.
Nhược điểm của Firebase
Sử dụng NoSQL: Có thể khó khăn cho những người đã quen với SQL.
Chi phí tiềm ẩn: Chi phí có thể tăng nhanh khi ứng dụng mở rộng và sử dụng nhiều dịch vụ hơn.
Khả năng tùy chỉnh hạn chế: Một số tính năng và dịch vụ có thể không tùy chỉnh được như mong muốn.
Phụ thuộc vào Google: Sự thay đổi chính sách hoặc dịch vụ của Google có thể ảnh hưởng đến ứng dụng.
Độ phức tạp khi tích hợp với hệ thống hiện có: Tích hợp Firebase với các hệ thống hiện có hoặc các nền tảng khác có thể gặp khó khăn.
Vấn đề quyền riêng tư: Phụ thuộc vào Google có thể gây lo ngại về quyền riêng tư và bảo mật dữ liệu.
Hạn chế về địa lý: Một số tính năng và dịch vụ có thể không khả dụng hoặc hoạt động không tốt ở một số khu vực.
Có nên dùng cho các ứng dụng lớn
Firebase cung cấp cho chúng ta 2 nhóm sản phẩm chính tập trung vào 2 đối tượng là:
Develop & test your app: phát triển và kiểm thử các ứng dụng được thiết kế.
Grow & engage your audience: Phân tích dữ liệu và tối ưu hóa trải nghiệm đối với người dùng.
Firebase đã quá nổi tiếng nên mình sẽ không phải giới thiệu nữa. Và mình chỉ nói riêng về Realtime Database của nó thôi chứ không phải tất cả. Chúng ta hãy xem xét trường hợp sau đây:
Bạn đang cần viết ứng dụng e-commerce và sử dụng Firebase lưu data, trong ứng dụng có tính năng WishList.
User sẽ được phép thêm rất nhiều sản phẩm vào wish list của họ, miễn là chúng không trùng nhau.
Liệu bạn sẽ xây dựng cấu trúc lưu trữ trong Firebase ra sao để tính năng này work tốt nhất có thể.
Giải pháp 1: Mỗi user có key “wish_list”, trong này chứa luôn các products họ yêu thích
Giải pháp này là dễ nhất, đơn giản là chỉ cần add nguyên cái object product vào đây là xong. Cần realtime chỉ cần listen trong wish_list của user logged in.
Tuy nhiên khi chúng ta update sản phẩm (giá, tình trạng sản phẩm), chúng ta phải quét qua hết tất cả user để update lại cái product trong wish_list của họ.
Mất rất nhiều thời gian và băng thông và dữ liệu bị mất tính nhất quán rất nhanh. Với lại cách này data nó không được flatten, không phải là best practice.
Giải pháp 2: Tạo riêng WishList ở ngoài, trong mỗi item có key UserID để biết là của ai.
Cách này cũng như cách trên, nhưng đỡ cái là khỏi phải đi quét qua tất cả user, update product nhanh hơn nhiều. Tuy nhiên cách này vướng phải 1 cái khó chịu hơn là mình cần realtime cho WishList riêng cho 1 user logged in thôi thì không được.
Client lúc nào cũng nhận event mỗi khi bất kỳ user trên hệ thống tương tác vào WishList. Điều này ảnh hưởng hiệu năng đáng kể.
Giải pháp 3: Làm theo kiểu RDBMS, chỉ nhớ Product IDs thôi.
Cách này có nhiều loại thi công: mảng productIDs trên mỗi user, 1 object riêng để map UserID và ProductID. Dù là cách nào thì khi chúng ta lấy thông tin sản phẩm trên WishList đều rất rắc rối. VD nhé wish list ta có [1,4,8], 3 sản phẩm với ID lần lược là 1,4 và 8.
Khi ta cần lấy các chi tiết các sản phẩm này (màn hình danh sách wish list của user chẳng hạn) thì chúng ta phải đi lấy sản phẩm có ID là 1, rồi 4, rôi 8. Mà hàm lấy details nó chạy async nên chúng ta phải dùng 1 cái group queue hoặc kỹ thuật lập trình tương đương để đảm bảo là đã fetch xong tất cả details cho mảng trên….
Ôi trời tất cả chỉ là do Firebase không có các câu lệnh query để join object hoặc kiểu aggressive hay map reduce gì cả. Bài toán trên nghe chừng khá đơn giản nhưng bắt gặp cũng không ít trên các ứng dụng phổ biến.
Chưa nói tới những ứng dụng có các mối quan hệ dữ liệu phức tạp hơn. Vậy ta có nên sử dụng Firebase cho ứng dụng lớn không ?? Thật ra là cũng CÓ, nhưng nó là 1 phần của hệ thống chứ không phải tất cả. VD app bán hàng có thể dùng Firebase cho phần chat với chủ cửa hàng, cập nhật trạng thái đơn hàng realtime chẳng hạn.
Firebase là một giải pháp toàn diện và linh hoạt cho việc phát triển ứng dụng, cung cấp nhiều tính năng mạnh mẽ giúp tiết kiệm thời gian và công sức cho các nhà phát triển. Tuy nhiên, việc sử dụng Firebase cũng đi kèm với một số thách thức, bằng cách hiểu rõ tính năng, ưu và nhược điểm của Firebase, các nhà phát triển có thể tận dụng tối đa các lợi ích mà nền tảng này mang lại, đồng thời tìm cách khắc phục những hạn chế để xây dựng và triển khai các ứng dụng thành công.
Liên tiếp 2 năm liền (2015 và 2016) KMS Technology có mặt trong danh sách 100 nơi đáng làm việc nhất Việt Nam do Anphabe và Nielsen bình chọn dựa trên những tiêu chí lương, thưởng, phúc lợi; cơ hội phát triển; đội ngũ lãnh đạo; văn hóa và giá trị; chất lượng công việc và cuộc sống; danh tiếng công ty. Cùng Techtalk khám phá KMS để lý giải vì sao KMS trở thành một trong những nơi đáng làm việc nhất tại Việt Nam.
KMS Technology, công ty 100% vốn đầu tư của Mỹ chuyên lĩnh vực phát triển sản phẩm và gia công phần mềm. Bắt đầu chỉ với 4 thành viên sau 8 năm hoạt động tại Việt Nam KMS đã xây dựng được đội ngũ hơn 800 nhân viên, 06 năm liên tiếp được vinh danh Top 10 Sao Khuê. Ngoài ra, KMS được bình chọn là top 5 công ty IT và top 32 nơi làm việc tốt nhất Việt Nam.
Các sản phẩm được phát triển bởi KMS: qTest, Kobiton, Katalon, Witurn và nhiều sản phẩm khác sẽ sớm ra mắt.
Với cam kết vào đầu tư phát triển con người, KMS Technology sẽ luôn hỗ trợ tạo mọi điều kiện tốt nhất cho nhân viên. Lập trình viên làm việc tại KMS sẽ có cơ hội:
➤ Học hỏi: Là đối tác của nhiều công ty lớn trên thế giới nên KMS luôn tạo cơ hội cho lập trình viên làm việc với hệ thống đủ phức tạp để thử thách, để học hỏi những điều mới
➤ Tham gia đóng góp cho sản phẩm: Tất cả các dự án tại KMS áp dụng mô hình Agile vào phát triển sản phẩm nên gần như mọi thành viên trong team đều được tham gia đưa ra ý kiến đóng góp cho sản phẩm mình tạo ra.
➤ Thay đổi vị trí công việc: Dù có khó khăn và mất nhiều thời gian thì KMS vẫn cố gắng thay đổi vị trí nhân viên nếu xem xét thấy nhân viên cần có sự thay đổi để tiếp tục phát triển các lợi thế và năng lực, ở cả mảng Outsourcing và Product.
Tiêu chí chung mà KMS áp dụng để xây dựng môi trường làm việc là: cởi mở, năng động, chuyên nghiệp và tạo tâm lý thoải mái nhất cho mỗi nhân viên của mình.
Cùng việc đầu tư văn phòng mới gần trung tâm Tp.HCM với đầy đủ trang thiết bị cần thiết phục vụ công việc theo tiêu chuẩn toàn cầu, KMS cũng chú trọng xây dựng văn hóa doanh nghiệp hài hòa với các hoạt động đào tạo, phát triển con người, sinh hoạt nội bộ và tham gia cộng đồng sôi nổi.
Vừa qua KMS vừa triển khai vườn ươm UpStar Labs, tập trung đầu tư và phát triển sản phẩm công nghệ cao cho thị trường quốc tế.
Địa điểm làm việc không còn là lựa chọn hàng đầu mà đang dần được thay thế bằng công nghệ, tính di động của thế hệ trẻ.
Theo báo cáo mới nhất của CBRE, nơi làm việc không còn là tất cả. Văn phòng từ lâu vẫn là yếu tố quan trọng chính cho việc kinh doanh, tuy nhiên công nghệ di động tân tiến đã giúp các công ty có nhiều lựa chọn hơn là các địa điểm cố định. Sự đổi mới của công nghệ và nguồn nhân lực đang làm thay đổi sự ưu tiên cho địa điểm.
Ít cần văn phòng trong tương lai
Việc phải di chuyển nhiều trong công việc hiện đang rất phổ biến tại Châu Á Thái Bình Dương, các công ty sẽ phải tạo ra một môi trường văn phòng mới, nhằm mục đích nâng cao sự hài lòng và thoải mái của nhân viên.
Trải nghiệm của nhân viên sẽ ảnh hưởng tới các chiến lược bất động sản, và công nghệ sẽ giúp nhân viên có thể tùy biến và linh hoạt trong thời gian, địa điểm và cách họ làm việc. Dựa trên nghiên cứu của CBRE, các doanh nghiệp sẽ tăng số lượng các nhân viên IT và nhân sự thuê ngoài; trong khi đó, sự suy giảm trong việc thuê văn phòng là điều tất yếu.
Điều này cũng giải thích cho việc xấp xỉ 50% khách thuê trả lời rằng họ sẽ ít cần sử dụng không gian văn phòng trong tương lai, chủ yếu là do diện tích văn phòng sẽ được tối ưu hóa và số lượng nhân công giảm.
Tuy diện tích văn phòng cần thiết sẽ giảm, nghiên cứu của CBRE lại chỉ ra rằng khách thuê sẽ yêu cầu chất lượng văn phòng cao hơn, thúc đẩy sự hợp tác, đổi mới và phúc lợi của nhân công. Các chủ đầu tư tương đối tự tin về triển vọng của nhu cầu mới này, vì sự tụt giảm nhu cầu sẽ đến từ các công ty co-working và start-up, với chỉ 32% số người được hỏi cho rằng con số này sẽ giảm.
Nhân viên sẽ ảnh hưởng tới các chiến lược bất động sản, và công nghệ sẽ giúp nhân viên có thể tùy biến và linh hoạt trong thời gian, địa điểm và cách họ làm việc. Các doanh nghiệp sẽ tăng số lượng các nhân viên IT và nhân sự thuê ngoài. Trong khi đó, sự suy giảm trong việc thuê văn phòng là điều tất yếu.
Tiến sĩ Henry Chin, Giám đốc Nghiên cứu thuộc CBRE Châu Á Thái Bình Dương
Do khách thuê giờ như những nhà “vận động” trong việc thay đổi môi trường làm việc, CBRE cho rằng các chủ tòa nhà cần phải hợp tác chặt chẽ hơn với khách thuê để phát triển mạng lưới các tòa nhà thông minh, tham gia giúp đỡ khách thuê trong giai đoạn lên kế hoạch để xác định những tính năng hoặc công nghệ mà họ cần. Việc tích hợp công nghệ cao và các tòa nhà mới sẽ tương đối đơn giản, tuy nhiên sẽ ngược lại đối với các tòa nhà cũ hơn.
“Công nghệ đang thúc đẩy một lực lượng lao động có tính di động cao. Cùng với việc sử dụng công nghệ hiện đại hơn, nhu cầu văn phòng sẽ giảm về không gian nhưng phải tăng về chất lượng, các chủ đầu tư cần phải hành động ngay để đảm bảo được tính cạnh tranh của họ”, Tiến sĩ Henry Chin, Giám đốc Nghiên cứu thuộc CBRE Châu Á Thái Bình Dương cho biết.
Tầm ảnh hưởng của nhân viên sẽ tăng dần
Từ trước tới nay, ý kiến của nhân viên rất ít khi được nhắc tới trong quá trình đưa ra quyết định của doanh nghiệp Bất động sản.
Tuy nhiên, theo nghiên cứu mới nhất của CBRE, sự phát triển chóng mặt của công nghệ đang đảo ngược quá trình trên và các nhân viên là người tạo ảnh hưởng tại nơi làm việc.
Theo đó, những quyết định của công ty trong việc thu hút và duy trì những người có năng lực đang dần được thông báo qua nền tảng công nghệ nhờ sự kết nối và tiếp cận dễ dàng hơn.
Chatbot, AI, Deep Learning, Recommendation System, Công nghệ tiền ảo đang phổ biến đến mức có thể bạn cũng không hay biết…
Domino’s sử dụng Chatbot kết hợp với tính năng Easy Order, cho phép khách hàng đặt pizza yêu thích chỉ với cú nhấp chuột.
Theo Samsung, có hơn 50% các công ty dịch vụ tài chính làm việc trong 1 dự án chatbot để khách hàng thực hiện các thao tác như kiểm tra số dư trong tài khoản, chuyển tiền và báo với ngân hàng về việc mất thẻ tín dụng, thẻ ghi nợ nhờ vào cải tiến công nghệ xử lí ngôn ngữ.
Hay đơn giản, khi bạn hỏi trợ lý ảo Siri của Apple hay Cortana của Microsoft về thời tiết hôm nay là bạn đang nói chuyện với 1 Chatbot.
Theo 1 chuyên gia đến từ Arimo, Google hiện đã có hơn 1000 AI projects và 10% Google Engneers ứng dụng AI trong công việc trong năm 2016. Trong khi đó, 25% Facebook Engineers đã & đang sử dụng AI trong năm 2017. Trong 3-5 năm tới thì AI sẽ trở thành một phần mặc định trong bất cứ hệ thống phần mềm nào và sẽ hỗ trợ đắc lực cho rất nhiều hoạt động, quy trình làm việc của doanh nghiệp.
Deep Learning & Machine Learning nhanh chóng trở thành tương lai của Personalized Recommendation và sắp tới là Personalized Web khi rất nhiều tập đoàn lớn như Amazon, eBay, CBS interactive, Forbes… đã thành công trong việc tận dụng những dữ liệu phí cấu trúc (hình ảnh, videos, chatlogs, văn bản) kết hợp với tiềm năng của Deep Learning và tạo nên các hệ thống Recommendation thông minh hơn
Phương thức kiếm tiền trực tuyến (MMO) đã trải qua nhiều thời kỳ với các phương pháp kỹ thuật khác nhau như: SEO Backlink, Affiliate marketing, Google Adsense,… và trong đầu quý 4/2017, phương thức đào tiền ảo thông qua ứng dụng Web đã trở nên rầm rộ trong cộng đồng các Miner
Tại Vietnam Web Summit, top những diễn giả kinh nghiệm sẽ giải đáp ứng dụng của Chatbot, AI, Deep Learning, Recommendation System, Công nghệ tiền ảo – những công nghệ mới ra đời đang len lỏi vào mọi lĩnh vực đời sống, tạo nên sức ảnh hưởng âm thầm mà mạnh mẽ bằng những topic “chất ngất”.
1/ Chủ đề Sử dụng Chatbot để tạo phễu bán hàng, Remarketing & giảm chi phí quảng cáo của diễn giả Ngô Ngọc Cường – CEO của Rabiloo
Giới thiệu tổng quan về hệ sinh thái Chatbot, những thành phần trong bức tranh tổng thể của hệ sinh thái Chatbot, các ứng dụng phổ biến của Chatbot trên thế giới. Đặc biệt, diễn giả còn phân tích bài toán cụ thể là bán hàng online với từng bước tạo phễu, remarketing & giảm chi phí quảng cáo hiệu quả.
2/ Chủ đề Ứng dụng AI trong lĩnh vực chăm sóc khách hàng – Bắt đầu như thế nào? cùng diễn giả Trần Tuấn Anh – Product Manager của FPT.AI
Với riêng lĩnh vực chăm sóc khách hàng, hiểu rõ nhu cầu người dùng là điều cực kì quan trọng và chỉ trong 2-3 năm trở lại đây, Trí tuệ nhân tạo (AI) đã giúp các doanh nghiệp làm rất tốt điều này. AI có thể gia tăng sự hài lòng của khách hàng nhờ khả năng thấu hiểu hành vi, từ đó giảm áp lực cho trung tâm dịch vụ, tránh lãng phí nguồn lực & hỗ trợ tối đa cho các chiến dịch Marketing, góp phần tạo nên trải nghiệm riêng, đẩy mạnh tương tác gắn kết mà chỉ có doanh nghiệp của bạn mới có thể mang lại.
Có thể nói, AI đang thay đổi hoàn toàn ngành Dịch vụ khách hàng và kinh nghiệm ứng dụng AI vào thực tiễn nhanh chóng & hiệu quả sẽ được giới thiệu từ A đến Z trong topic này.
3/ Topic From personalized recommendation to personalized Web: A Deep Learning approach của diễn giả Trịnh Xuân Tuân – CoFounder & CEO của NextSmarty
Trình bày cách áp dụng Deep Learning vào hệ thống Recommendation được cá nhân hóa dựa trên hành vi của users, bao gồm các ứng dụng cực kì hữu ích và thuận tiên như: trang personalized listing xếp hạng hàng ngàn items, search thông minh cả từ khóa phù hợp lẫn hành vi lịch sử của user, email marketing được cá nhân hóa theo sở thích người dùng.
4/ Topic Tiền ảo đã ký sinh trên trang web của bạn như thế nào? của anh Quan Minh Tâm – Trưởng phòng kỹ thuật Công ty TNHH Công nghệ Bảo Tín
Theo Trend Micro, các website của trường học, tổ chức từ thiện.. được phát hiện “dính” một loại mã đặc biệt để biến chính máy tính của người dùng thành một cỗ máy đào tiền ảo. Vậy đằng sau của kỹ thuật này là gì và người dùng truy cập ứng dụng web của bạn đã trở thành nạn nhân như thế nào? Diễn giả sẽ đưa ra một số phương án kỹ thuật khai thác và lẩn tránh các công cụ bảo mật để ký sinh cho việc kiếm tiền thụ động này.
5/ Chủ đề Recommendation System – Thách thức thập kỉ của diễn giả Nguyễn Tấn Triều – Head of Platform tại BlueseedTV
Hệ thống gợi ý (Recommendation Systems) là những công cụ và kỹ thuật nhằm cung cấp đề xuất về một item cho người dùng, là ứng dụng phổ biến của Data Science khi hàng loạt các hệ thống lớn như E-commerce, Mạng xã hội đều đã ứng dụng thành công. mọi kĩ thuật chuyên sâu hơn của Recommendation Systems sẽ được giới thiệu đến người tham dự trong topic này.
5 topic cực đỉnh này đang đợi bạn khám phá chỉ bằng 1 click “săn” những SLOT CUỐI CÙNG
tham dự Vietnam Web Summit 2017
Agenda chính thức tại Tp.HCM
Hotline/ Liên hệ hợp tác & đặt booth: ➤ Mr Bình: binh@applancer.net | 0904 392 888 ➤ Event team: event@applancer.net | 08 6273 3497
Thời gian & địa điểm sự kiện: ➤ 01/12/2017 tại Grand Palace, 142/18 Cộng Hòa, P.4, Q. Tân Bình, Tp.HCM ➤ 08/12/2017 tại CTM Palace, 131 Nguyễn Phong Sắc, Dịch Vọng Hậu, Cầu Giấy, Hà Nội
Thông tin chi tiết: ➤ Website: vietnamwebsummit.com ➤ Event page:
Tổng hợp: facebook.com/Topdevvietnam/events
HCM: facebook.com/events/897273157088258
HN: facebook.com/events/303631870103105
Tôi không là fan của việc thích tranh luận nên xài hay không xài web fonts nào, nhưng tôi nghĩ là mọi người đều cần có một guideline hướng dẫn để sử dụng chúng.
Bài viết này sẽ rất dài và được chia thành nhiều phần nhưng ý chính của nó là khi bạn làm một site và muốn chọn web font tốt nhất thì hãy ít nhất suy nghĩ tới việc dùng system fonts trước nếu có thể.
Thế nhưng tôi nghĩ là khá nhiều bạn khi chọn font thì sẽ có ý nghĩ như thế này:
Nếu thường xuyên xài web fonts thì có lẽ bạn cũng đã có ý nghĩ là “system fonts” quá xấu.
Tuy vậy, không có font xấu chỉ có người dùng xấu. Và để chứng mình rằng “system fonts” cũng có thể cho ra kết quả bắt mắt, bạn hãy xem hình sau:
Hoặc bạn có thể test mở rộng bằng Stylebot Chrome extension để set một font-family cho một CSS selector/site. Như mọi thay đổi sẽ được giữ nguyên mỗi khi navigate xung quanh site của mình.
Sau phần giới thiệu ngắn ngủi này, hãy cùng giải đáp những câu hỏi trong bảng map ở trên.
Font đó có quan trọng với nhãn hiệu (brand) của bạn không?
Đây hẵng là câu hỏi dễ nhất, nếu bạn trả lời là có thì không cần đọc tiếp nữa.
Nói cách khác nếu front đó định hình nên nhãn hiệu của bạn thì hãy sử dụng nó. Còn nếu không thì hãy đọc tiếp phần sau.
Font đó có khiến cho site của bạn dễ đọc hơn không?
Hãy nhìn vào nội dung dưới đây. Đừng quan tâm nó viết về vì mà hãy tập trung vào phông chữ.
Bạn thấy như thế nào? Lát nữa chúng ta sẽ bàn về điều này.
Nếu số lượng chữ trên site của bạn ít, thường chỉ 4 dòng thì vấn đề nhức mắt sẽ không quá đáng ngại. Có lẽ vì thế mà Facebook, Twitter, Gmail, và eBay đều dùng system font.
Nhưng nếu người đọc đến trang của bạn để xem trên 10 phút thì bạn sẽ muốn chữ thật dễ đọc.
(Nãy giờ tôi hay dùng cụm từ system font để ám chỉ setting của font-family: -apple-system, BlinkMacSystemFont, etc, vốn là những sans-serif font)
Medium.com là một ví dụ tuyệt vời, tôi nghĩ hẳn bạn cũng biết tới nó. Họ hẳn đã bỏ rất nhiều suy nghĩ vào typography. Với những khoảng cách hợp lí giữa từng chữ và hàng, với các kiểu font vô cùng dịu mắt, Medium sẽ không còn là chính nó khi thay bằng system font.
Nhưng bạn đừng nghĩ rằng một website dễ đọc là chỉ nhờ vào web font.
Là một developer, hẳn bạn cũng dành rất nhiều thời gian lên GitHub. Bạn có biết rằng không hề có một font file nào được load trong network để tạo ra những chữ đó không? Quá tuyệt vời!
Tôi nghĩ rằng nếu ngày mai, GitHub đổi từ system font sang ‘Source Sans Pro’, cũng không có ai biết. Cũng như vậy, tôi tin rằng nếu NPM bỏ Source Sans Pro và chuyển qua sài system font thì cũng chả người nào nhận ra.
Đó chính là điều mà tôi muốn nói tới. Liệu user có nhận ra sự khác biệt giữa web font và system fonts?
Đừng vội trả lời bởi vì….
Wikipedia – Một trường hợp kì lạ
Wikipedia thật sự đã bỏ rất nhiều công sức vào typography. Và họ đi đến kết luận cuối cùng là system font. Tốt thôi.
Những điều khiến tôi choáng váng là ở kích thước desktop. Họ không hề điều chỉnh về khoảng cách hàng và chữ trong khi vẫn giữ 14px font.
Tôi rât muốn biết cái lí do cho quyết định này. Tôi trước giờ vẫn quen dùng Wikipedia với 18px text và 700px chiều dài dòng.
Nên khi phải quay lại “default view”, nó khiến tôi nhức cả đầu
Bài học ở đây là nếu nội dung đã khó đọc thì ngay cả web font cũng không thể cải thiện nhiều được. Vì thế hãy làm cho đúng nền tảng của typography trước đi đã.
…
Nếu bạn không quan tâm đến typography, chỉ cần dễ đọc thì hãy thử những điều sau:
Kích thước font từ 18px trở lên
Khoảng cách các dòng nên là 1.6
#333 cho màu
Đồ dài dòng chỉ nên là 700px
Tuy vậy, bạn cũng không cần phải làm theo y hệt những gì tôi nói, hãy thử nghiệm dựa theo Medium, The New Yorker, Smashing Magazine, longform.org.
Sau khi đã xong bước nền tảng thì bạn hãy suy nghĩ tới việc nên dùng web font hay system font.
…
Giờ quay trở loại với ô chữ lúc nãy.
Nó có dễ đọc hơn không? Hay khó đọc hơn? Hay là như nhau?
Khi bạn để và so sánh giữa hai hình thì ta sẽ tự huyễn hoặc và cho là một bên dễ đọc hơn so với cái kia. Nhưng nếu bạn không thấy khác biệt thì có thể là bạn cảm thấy dễ chấp nhận hơn giữa cả hai bên.
Để cho dễ hơn, sau đây là 2 hình để bạn so sánh font chữ. Một bên là web font và cái kia là system font.
Tôi sẽ không nói là nó là font nào.
Trở về với câu hỏi “web font có khiến site của bạn dễ đọc hơn không?’. Tôi nghĩ rằng là sau tất cả những ví dụ trên thì hẳn sẽ có người sẽ có kết luận là không! Không hề khác mấy.
Nếu site của bạn không có nhiều chữ thì web font sẽ không làm cho nó dễ đọc hơn. Nhưng nếu trang của bạn là toàn về đọc thì quyết định là không hề dễ. Tôi tin rằng Medium’s font khá là dễ chịu và New Republic’s font thì không có khác biệt gì cả. Đây là câu hỏi hoàn toàn dựa vào cảm tính của từng người.
Và nếu bạn cho rằng web font không hề có tác dụng gì bạn đang gần hơn với mục tiêu tối cao – không cần gì về web font.
Tìm một công việc phù hợp đã khó, tìm một môi trường làm việc phù hợp với tính cách và con đường phát triển của bản thân lại càng thách thức, nhất là với các bạn trẻ nhiều hơn. Vậy, nên làm việc cho startup hay doanh nghiệp lớn? Câu trả lời là: Tuỳ vào định hướng của mỗi người.
Startup
Nếu như bạn có định hướng sẽ “làm chủ” trong 5 đến 7 năm tới thì việc đầu quân vào một công ty non trẻ sẽ là sự lựa chọn hợp lí hơn. BỞI VÌ:
Có cơ hội tiếp xúc với founder khác
Làm chủ một công ty, tổ chức cũng có nghĩa là bạn sẽ nắm trong tay rất nhiều quyền lực và cả trách nhiệm. Những kĩ năng để quản lí nhân sự, phát triển mô hình kinh doanh và duy trì mô hình kinh doanh ấy sẽ được học hỏi tốt nhất ở một người founder đi trước. Chưa kể, tham gia vào một startup, bạn có cơ hội để “mục sở thị” cách những đàn anh đàn chị làm việc, giải quyết khủng hoảng, điều hành, tuyển dụng,…hơn là chỉ nghe hay học qua sách vở, tài liệu hay nghe chia sẻ.
Chứng kiến một tổ chức từ con số không
Chứng kiến một công ty đi lên từ con số không cho đến khi trở thành một công ty kinh doanh vững mạnh, hoặc cũng có thể là…”sập” – trở về con số 0 tròn trĩnh như ban đầu. Dù bạn được chứng kiến quá trình nào thì việc tham gia, trải nghiệm quá trình hình thành và phát triển của một startup là kinh nghiệm vô cùng quý báu cho bản thân bạn sau này.
Phát triển khả năng leadership
Trong một môi trường chưa hoàn thiện, tất cả mọi thứ còn có phần “ngổn ngang” thì việc bản thân bạn phải tự đưa mình vào một khuôn khổ, tự tạo challenge cho mình là điều vô cùng cần thiết.
Khả năng thăng tiến
Chính vì là môi trường mới mẻ, nhiều thách thức, và có phần mạo hiểm hơn những doanh nghiệp lớn, startup có lợi thế về việc mở ra cho các thành viên của mình những cơ hội thăng tiến và thu nhập đáng kể, nếu startup thành công.
Doanh nghiệp lớn
Chuyên môn
Tuy không có sự bùng nổ và sức trẻ như startup, các doanh nghiệp lớn lại mang trong mình lợi thế với bề dày kinh nghiệm. Thích hợp với các những bạn có mong muốn trau dồi kiến thức chuyên môn, trở thành chuyên gia trong lĩnh vực của mình và trở thành partner của những công ty lớn. Lúc này, làm việc ở startup sẽ không thể cung cấp đủ cho bạn cả chiều sâu lẫn chiều rộng của kiến thức.
Thời gian
Ở các tổ chức lớn với số lượng lên đến hàng trăm, thậm chí hàng ngàn người, người quản lí sẽ cho bạn nhiều thời gian để sai, rút kinh nghiệm và làm tốt hơn. Có khi bạn sẽ mất đến cả năm trời chỉ để làm quen với môi trường làm việc, văn hoá công ty, thử sức mình ở nhiều vị trí khác nhau để tìm ra “nơi nương thân” thích hợp nhất. Trong khi mặc sai lầm như vậy, những đóng góp của bạn cho doanh nghiệp là rất ít, hầu như không có. Tuy nhiên, các doanh nghiệp lớn vẫn rất nhiệt tình giúp đỡ và đào tạo để bạn có thể gia nhập đội ngũ nhân sự thật sự “làm được việc” của công ty.
Những điều nói trên chắc chắn sẽ không thể có ở các Startup – một môi trường bấp bênh hơn rất nhiều so với các doanh nghiệp đã tồn tại lâu đời. Bởi vì bản thân chủ doanh nghiệp cũng đang phải lo lắng rất nhiều vấn đề cho sự sống còn của công ty mình. Ở startup không có chỗ cho những sai lầm và thời gian để học hỏi nhiều như doanh nghiệp lớn.
Sự chuyên nghiệp
Với lợi thế là kinh nghiệm và sự ổn định, hầu hết các công việc đều đã được thực hành bởi nhiều người, kinh nghiệm được truyền từ người đi trước, thậm chí, nguồn tài liệu hướng dẫn, cách thức thực hiện một công việc đều có văn bản hướng dẫn cụ thể. Bạn sẽ không phải lăn tăn xem mình làm như vậy đã đúng chưa, bởi luôn có tiêu chuẩn nhất định để bạn đối chiếu kết quả làm việc của mình, bạn cũng sẽ không gặp tình trạng hoanng mang không biết phải làm gì, vì nhiệm vụ đã được phân công rất rõ ràng, cụ thể.
Nhược điểm là bạn sẽ không thể phát triển trên nhiều phương diện đồng thời cùng lúc như ở startup được.
Khả năng thăng tiến
Mặc dù như đã nói ở trên, startup là môi trường dễ thăng tiến nhưng cũng rất dễ chết yểu, thậm chí là chết trong chính tay bạn nếu như bạn chưa đủ kinh nghiệm. Ngược lại, con đường thăng tiến trong các doanh nghiệp lớn, dù khó khăn hơn vì nhưng yếu tố khách quan cũng như chủ quan, lại là con đường “ăn chắc” hơn bởi với lượng nhân lực dồi dào, bạn chắc hẳn phải vượt trội hơn mặt bằng chung để được cất nhắc. Các chủ startup, đôi khi không có quá nhiều lựa chọn trong nhân sự như doanh nghiệp.
Nếu làm việc trong môi trường Agency thiết kế, trong studio game, thì designer bạn có thể thoải mái nghe nhạc, rung đùi, xem Youtube, đi dạo xung quanh để tìm cảm hứng. Còn trong môi trường startup, đặc biệt với các startup trong giai đoạn tăng trưởng mạnh, thì Designer chúng ta không có thời gian thư giãn nữa. Lúc đó, phải làm việc theo kế hoạch đã đặt ra, làm xong càng sớm càng tốt. Vì task done của một người, cũng chính là đầu vào cho task mới của một người khác trong team, task của design lại lúc nào cũng ở đầu chuỗi, là đầu vào của đội marketing và đội code, vì vậy càng phải sớm nhất.
Tại sao lại cần sớm và luôn gấp như vậy:
Bởi công ty luôn muốn đưa sản phẩm ra thị trường sớm, để lấy thế cạnh tranh, để sớm kiểm định với thị trường, từ đó mà có thêm cải tiến chỉnh sửa ở các phiên bản sau.
Bởi công ty phải tận dụng tối đa thời gian. Thời gian trống với startup là thời gian chết, không sinh ra lợi nhuận sớm thì đào đâu ra tiền nuôi tập thể. Với hầu bao eo hẹp, ưu tiên lớn nhất trong những năm đầu của một startup là tồn tại được. Cho nên tiết kiệm được chút thời gian nào là hay chút đó.
Designer thích thoải mái, thì làm thế nào để thích nghi với môi trường startup? Chỉ có 1 con đường duy nhất, đó là làm thật nhiều. Trong quá trình làm thật nhiều đó, một designer có thể đúc rút được rất nhiều thứ dưới đây:
Nhưng để áp dụng được 5 điều dưới đây, bạn phải “Không được phàn nàn” trong suốt quá trình làm việc của mình, thì mới thành công được.
Thứ nhất: Khi công việc quá nhiều, phải có công cụ để ghi chép và phân loại
Công cụ đơn giản nhất đó là giấy bút. Cứ ghi hết ra giấy, rồi có thể đánh số thứ tự ưu tiên. Cái nào cần trước thì làm trước, làm xong thì gạch task đó đi. Mỗi lần gạch sẽ là 1 lần thấy mình được việc, là động lực cho việc hoàn thiện những task còn lại. Công cụ hiện đại hơn thì là các phần mềm quản lý công việc, như các tool Todo List thông dụng, Asana, Trello và Jira với công việc của team.
Thứ hai: khi công việc quá nhiều, thì phải bớt thời gian cho những thứ không phải là công việc
Đó là: xem youtube, chat facebook, trả lời tin nhắn điện thoại, đọc báo mạng, suy nghĩ vu vơ, thậm chí là ăn uống trong giờ. Thời gian đầu làm việc bên Đức, để hoà nhập vào với tốc độ và văn hoá công ty, mình đã phải deactive facebook gần một năm. Đổi lại, đó lại là thời gian mình tập trung vào công việc, và tốc độ cũng tiến bộ hẳn. Bạn cũng có thể tự gây áp lực hoàn thành cho mình bằng việc bấm đồng hồ hẹn giờ cho mỗi đầu việc. Nhìn cái đồng hồ đếm ngược là bạn biết còn bao nhiêu phút nữa mình phải xong việc, nên sẽ hạn chế hơn việc làm việc riêng. Giữa các công việc chỉ cần dành khoảng 5’ đi lại, uống nước cho thư giãn là được.
Thứ ba: phải biết nói “Không” với những nhờ vả chen ngang
Nếu đang hạ quyết tâm làm 1 task, dẫu có giữa chừng một đồng nghiệp tiến đến nhờ hỗ trợ một việc gì đấy, hãy thẳng thừng nói “Không, xin lỗi vì tôi đang bận”. Cách khéo léo thì nói “Đợi tôi vài phút, tôi sắp xong rồi.” Nhưng mình sẽ là người quyết định cái “vài phút” đó dài bao lâu. Còn trường hợp đó là việc thực sự gấp, hoặc mình bị thua trong việc nói “Không” thì sao, thì hãy nói chuyện chớp nhoáng với họ để xem họ muốn nhờ vả gì, rồi sau đó đặt một cái hẹn khác, ví dụ như “OK, tôi có thể giúp, nhưng đợi 30’ nữa, để tôi làm xong việc này đã, vì nó còn gấp hơn việc của anh”.
Thứ tư: Tìm sự trợ giúp từ đồng nghiệp
Theo một nghiên cứu khảo sát những người tự nhận lúc nào cũng bị overload công việc, thì phần lớn nguyên nhân đều do bản thân đó cố gắng tự giải quyết một mình mà quên đi sự hợp tác với đồng nghiệp. Teamwork không chỉ là cách các bạn tích cực khi làm việc nhóm, teamwork còn là việc mỗi cá nhân biết sử dụng sức mạnh tập thể.
Thay vì ngồi mày mò tự học trên mạng, nếu trong công ty có 1 người đúng chuyên môn đó, hãy mạnh dạn mở lời xin trợ giúp hoặc giải thích về vấn đề này. Bạn nên nhớ, 1 phút từ chuyên gia có giá trị nhiều hơn cả tiếng mình ngồi mày mò, vậy tại sao phải mất thời gian làm khổ mình trong khi có thể tìm cách nhanh hơn ngay bên cạnh.
Ví dụ: Hôm nay tôi muốn thiết kế một màn hình tutorial loại chỉ cần 1 cái graphic thật đẹp là được. Nhưng vẽ máy không phải thế mạnh của tôi, trong khi đứa bên cạnh sử dụng wacom rất thành thạo. Vậy là tôi đã làm 1 cuộc trao đổi: tôi nhờ đứa bên cạnh vẽ hộ cái graphic để đưa vào màn tutorial – nó làm mất khoảng 15’; đổi lại, tôi sẽ giúp nó design một cái form Checkout cho cái app nó đang làm. Trao đổi rất sòng phẳng và được việc cả hai.
Thứ năm: cách tạo sự tập trung hiệu quả nhất tại văn phòng đó là ngồi cạnh sếp
Tôi nhớ trong một dự án quan trọng làm cho hãng Smart – hãng xe mini thông minh nổi tiếng thế giới, có trụ sở phân phối tại Đức – và tôi là designer duy nhất phụ trách dự án này. Trong 2 tuần, tôi phải thiết kế xong một hệ thống đặt và thuê xe, concept chỉ có vài bản vẽ nháp trên giấy và một số cuộc hội thoại. Tôi đã phải chuyển vào phòng của giám đốc, ngồi side-by-side ngay cạnh, đem cả màn hình và bàn của tôi vào ngồi bên cạnh bàn sếp. Sếp tôi là một con người rất đáng sợ, nhưng thời điểm này thì ông ấy cũng là người duy nhất hiểu về khách hàng này và dự án này. Vì ngồi cạnh, mà ngay lập tức mọi thắc mắc của tôi đều được giải đáp, tôi không có thời gian chết. Và cũng vì ngồi cạnh nhau, mà tôi được quyền bỏ qua hết tất cả việc vặt trong công ty, vì làm việc với giám đốc là quan trọng nhất rồi, còn ai dám cắt ngang tôi nữa.
Công việc phân công ban đầu không phải lúc nào cũng công bằng, vì số lượng việc rất nhiều mà số lượng người thì hạn chế. Vì vậy, là một designer trong môi trường startup, bạn phải thông thái và sáng tạo liên tục, tìm ra được cách làm việc hiệu quả cho riêng mình cũng như phối hợp nhịp nhàng với cả team. Mục đích sau cùng của join một team startup chính là học tập những thứ này, đừng chây ì qua ngày, không thì đến lúc rời công ty bạn sẽ chẳng tiến bộ mấy.
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…
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é!
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.
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:
Tuy nhiên, tôi nhận ra vài chuyện vô ý dẫn đến 1 vấn đề lớn:
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.
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.
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.
Đăng ký tên miền tại Việt Namhiệ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
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:
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.
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.
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:
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.
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.
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.
“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 softwareengineer 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
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ẩm. Zalo 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!
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:
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.
We did it! @christianalfoni and I combined forces and created a common NPM bundler for WebpackBin and CodeSandbox! 1/2 pic.twitter.com/6X3hxamLyN
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:
Metadata resolver: nó chuyên giải quyết các versions và peerDependencies sau đó request packager function.
Packager: nó chịu trách nhiệm cài đặt và bundling các dependencies.
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:
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.
Đ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.
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 estate và Democratizing 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.
Thời gian & địa điểm: 01/12/2017 tại Grand Palace, 142/18 Cộng Hòa, P.4, Q. Tân Bình, Tp.HCM
08/12/2017 tại CTM Palace, 131 Nguyễn Phong Sắc, Dịch Vọng Hậu, Cầu Giấy, Hà Nội
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.
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.
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ứ.