Tôi phác họa vài kí tự trong một cuốn sổ tay cũ, vì muốn tạo ra một phông chữ cao, không chân, hiển thị có thể được sử dụng trong các poster, ảnh nghệ thuật lớn. Trong những ngày đầu tiên tại Men’s Health, tôi đã phải sử dụng các phông như ‘Tungsten’ hay ‘Heron’, thật tệ vì những mảnh của nét chữ, nhưng lại tuyệt vời khi sử dụng trong các tiêu đề, hoặc cho quảng cáo. Đây là phong cách thiết kế của tôi.
Nét vẽ thô
Một giờ chiều, thứ Tư
Tôi đã mở ngay Adobe Illustrator với hai, ba kí tự mà tôi đã phác hoạ. Tôi thiết lập năm đường grid line trên Artwork của tôi, một cho mỗi dòng descender, đường cơ sở, x-height, cap height và ascender line. Sau đó tôi quyết định chiều rộng cho chữ in hoa, và từ đó độ dày của thân chữ (ví dụ chiều rộng của chữ I).
Tôi đã thực hiện rất nhiều nghiên cứu về tỷ lệ của các kí tự, và đo một số phông chữ hiện có, tìm ra cách các chữ thường phải liên quan đến “cap”. Từ đây, tôi đã thực hiện một số quy tắc:
X-height = 2 x chiều cao ascender/descender.
Chiều rộng chân = 1/4 chữ cái in hoa
Chữ thường chiều rộng = 3 chữ viết in hoa
Quy luật vẽ
Tôi đã tạo ra các chữ O và B đầu tiên. Tôi đã quyết định rằng bất kí tự nào thường có đường cong, sẽ có góc tròn. Hầu hết các kí tự sẽ là hình khối cao, nhưng với các kí tự như O, B và D, các cạnh có đường cong sẽ có góc tròn.
Góc bên ngoài có bán kính 12mm, bên trong là 6mm. Với những quy tắc này, cộng với chiều cao cho thanh ngang (giống chữ H) tôi bắt đầu tạo ra các kí tự viết hoa.
Phông chữ của tôi rất đơn giản, nhưng với một định nghĩa “flourish”, nếu bạn muốn. Với bất kì khẩu độ nào, đó là sự mở đầu trong một kí tự, giống như sự cắt bỏ trong chữ C, , như phần cong ở đuôi chữ J, sẽ bị cắt một góc. Những chữ cái khó tạo ra nhất ở đây là G và K.
Với các kí tự viết hoa đã xong, tôi chuyển sang các kí tự viết thường. Thật khó nhưng với các quy tắc ở trên, chỉ là chuyển từ chữ in hoa sang. Tôi đã sử dụng rất nhiều ‘lourishes’ ở đây, đặc biệt là vào cuối ascender và descender. Các chữ cái f, g, a và e là những kí tự khó nhất, vì chúng hoàn toàn mới.
9 giờ đêm, thứ 4
Bây giờ tôi đã chuyển sang một số ký tự bổ sung, như dấu chấm hỏi và dấu chấm than. Tốc độ đã nhanh hơn, và trước khi đi ngủ, tôi đã có thể tạo ra khoảng 35 kí tự.
Sáng thứ ba
Vào buổi sáng, tôi hoàn thành các con số từ 0 đến 9 khá nhanh, và sau đó bắt đầu tạo ra các tập tin font.
Đây là font hoàn toàn mới. Ian Barnard, một calligrapher trên twitter, đề nghị một chương trình gọi là Glyphs, bạn có thể tải xuống và dùng thử miễn phí trong 30 ngày.
Tôi đã tải Glyphs Mini và theo dõi một vài video hướng dẫn, sau đó nhận ra rằng tôi đã tạo tệp minh hoạ hoàn toàn sai. Vì vậy, tôi đã phải dán mỗi nhân vật bằng tay và mở rộng nó để phù hợp với hướng dẫn.
10 giờ sáng, Thứ ba
Với các kí tự đã có, tôi tiếp tục với spacing và kerning. Phần này tốn rất nhiều thời gian. Có một loạt các phím tắt trong ứng dụng này mà hoàn toàn phải nắm vững trước khi đặt ra về điều này. Và trước khi bắt đầu quá trình kerning, bạn cần phải có khoảng cách chữ cái càng gần càng tốt.
Rõ ràng có một quy luật, đo chiều rộng của chữ O (phần hổng ở giữa) và chia cho ba. Đó là khoảng cách space bạn nên bắt đầu ở bên trái và bên phải của các kí tự với nhau.
11 giờ trưa, Thứ ba
Với khoảng cách đã được cài đặt (chiếm chữ cái rộng hơn như M và W) tôi bắt đầu với kerning. Nó mang lại cho tôi rất nhiều khó khăn. Tôi truy cập website này, và dán vào văn bản kerning.
Sử dụng các phím tắt (sử dụng hướng dẫn này) Tôi lướt qua và điều chỉnh kerning cho mỗi khoảng cách không nhìn thấy. Những khoảng cách rõ ràng là giữa V và A, nhưng có rất nhiều cặp chữ cái mà tôi không nghĩ đến.
Sau khi hoàn tất, tôi đã chuyển đổi kerning sang viết hoa và thực hiện lại toàn bộ, để ghép cặp chữ hoa.
12:59 chiều, Thứ ba
I exported my font and converted it to a .ttf file ready to submit to Google. With quite a few glyphs still missing (like square brackets and copyright symbols), I was certain that it wouldn’t be accepted. I also didn’t have time to include the multitudes of accents required for full language support.
Tôi đã xuất phông chữ ra và chuyển nó sang một tệp .ttf để sẵn sàng gửi tới Google. Với một vài kí tự vẫn còn thiếu (như dấu ngoặc vuông và biểu tượng copyright), tôi chắc chắn rằng nó sẽ không được chấp nhận. Tôi cũng không có thời gian để bao gồm vô số dấu cần thiết cho hỗ trợ ngôn ngữ đầy đủ.
Nó không phải là vấn đề lớn nhất của phông chữ, nhưng nó không phải là xấu cho lần đầu tiên. Và khi xem xét tôi đã phải tự học cách sử dụng phần mềm Glyphs từ đầu, và nó đã được hoàn thành trong một ngày. Thật đáng tự hào
Còn về tên?
Odibee Sans
…đọc là “oh-dee-bee”.
Phần sau
Tôi đã gửi Odibee Sans cho Google Fonts vào tháng 5 năm 2017, và vì nó vẫn còn phông chữ vẫn đang được bổ sung. Team khá đúng khi cho rằng tôi nên dành thêm thời gian cho phông chữ để tinh chỉnh thiết kế (mặc dù họ thừa nhận rằng điều này trái với tinh thần của project).
Tôi đã dành một ngày để chỉnh sửa phông chữ. Tôi đã kể từ khi thêm tất cả các extra glyphs (tôi nghĩ) cần thiết để hỗ trợ latin. Tôi cũng đã thực hiện một số thay đổi lớn cho khoảng 30 kí tự, bao gồm cả phong cách mới cho các kí tự in hoa (mũ) S, B, R, và trường hợp viết thường như s, c, y, a, e, r, f, t, p, q và j, cũng như một vài điều chỉnh số.
Trên hết, bây giờ có hơn 1.500 kerning đôi, đã có một cải tiến lớn cho các font chữ.
Những công cụ quản lý sản phẩm dành cho các Product Manager
Tác giả: Shaun Juncal
Giới thiệu
Khi nói về các công cụ dành cho người quản lý sản phẩm, chúng ta thường đề cập đến một số tiêu chuẩn mà hầu hết các Product Manager sử dụng hàng ngày. Các công cụ quản lý sản phẩm này thường bao gồm phần mềm phân tích sản phẩm, công cụ theo dõi phát triển và phần mềm lập bản đồ. Chúng cho phép các Product Manager dễ dàng hơn trong việc nắm bắt dữ liệu và quản lý sản phẩm. Vậy những công cụ dành cho Product Manager là gì?
Các công cụ quản lý sản phẩm tốt nhất cho Product Manager là gì?
Công cụ theo dõi và phân tích người dùng (như Pendo và Amplitude)
Những công cụ này là một nguồn hữu ích và cho bạn cái nhìn sâu sắc về cách người dùng sử dụng phần mềm của bạn hoặc khách truy cập trang web của bạn thực sự tương tác với sản phẩm và nội dung sản phẩm. Trong khi các cuộc khảo sát hoặc phỏng vấn trực tiếp với khách hàng sẽ chỉ cho bạn biết khách hàng nói gì và nghĩ gì, thì các nền tảng phân tích sản phẩm có thể nắm bắt và giúp bạn phân tích những gì khách hàng thực sự đang hướng đến.
Công cụ tạo biểu đồ cho Product Manager là gì? (như ProductPlan)
Phần mềm tạo biểu đồ là thứ cần phải có trong bất kỳ danh sách công cụ quản lý sản phẩm nào. Sử dụng các trình soạn thảo và duy trì lộ trình làm việc với sản phẩm của bạn (chẳng hạn như bảng tính hoặc trang trình bày) sẽ tạo ra nhiều công việc hơn, kém linh hoạt và dễ chia sẻ hơn và dễ gặp các vấn đề về kiểm soát phiên bản có thể làm chậm sản phẩm của bạn phát triển. Biểu đồ sẽ giúp các Product Manager đơn giản hóa những điều này.
Công cụ tạo biểu đồ giúp thông tin được thể hiện trực quan hơn
Chẳng hạn như ứng dụng ProductPlan giúp bạn dễ dàng xây dựng và chia sẻ lộ trình sản phẩm một cách đẹp mắt. Một lộ trình tương tác, trực quan sẽ hiệu quả hơn nhiều trong việc truyền đạt chiến lược sản phẩm và giúp gắn kết nhóm của bạn với tầm nhìn sản phẩm của bạn.
Các công cụ khảo sát khách hàng (như SurveyMonkey hoặc Typeform)
Cái hay của các công cụ khảo sát dựa trên web như SurveyMonkey hoặc Typeform là chúng có rất nhiều loại câu hỏi được định dạng trước, cho dù bạn muốn đưa ra câu hỏi trắc nghiệm, danh sách kiểu thả xuống hay chỉ mở các trường nhận xét, bạn có thể tạo một cuộc khảo sát trong vài phút. Sau đó, bạn có thể gửi khảo sát cho khách hàng của mình và dễ dàng theo dõi cũng như phân tích kết quả.
Công cụ ghi âm (như GoToMeeting hoặc Zoom) và ý nghĩa với Product Manager là gì?
Khi làm việc với khách hàng, ghi âm lại cuộc trò chuyện là một yếu tố cần thiết và quan trọng. Sử dụng những công cụ như GoToMeeting hay Zoom sẽ giúp bạn dễ dàng ghi lại các cuộc hội thoại đó và tham khảo lại sau này. Bạn không bao giờ biết khi nào khách hàng sẽ cung cấp thông tin chi tiết có giá trị, đặt một câu hỏi mà bạn nhận ra rằng nhiều người dùng khác sẽ có, hoặc chỉ chia sẻ với bạn một cuốn tiểu thuyết tại sao họ sử dụng sản phẩm của bạn mà bạn có thể không nghĩ đến.
Ứng dụng làm việc tập thể (như Slack hoặc Confluence)
Việc sử dụng các nền tảng trò chuyện khi làm việc nhóm đương nhiên là rất cần thiết, nhất là với Product Manager và team xây dựng sản phẩm của mình. Khi quá trình phát triển sản phẩm của bạn hoặc bất kỳ sáng kiến phức tạp nào được đưa ra, bạn sẽ muốn có một phương tiện giao tiếp dễ dàng và tức thì cũng như duy trì hồ sơ liên tục về tất cả các thông tin liên lạc liên quan đến vấn đề đó.
Phần mềm trình bày, thuyết trình (như PowerPoint hoặc Keynote)
Với các chương trình Product Manager tuyển dụng, người phỏng vấn rất quan tâm đến kahr năng trình bày vấn đề của ứng viên. Trình bày về kế hoạch làm việc sẽ giúp Product Manager truyền đạt các chiến lược, tầm nhìn và kế hoạch cấp cao trong tổ chức của bạn và cho các đối tượng bên ngoài như khách hàng. Ví dụ, giới thiệu về tầm nhìn sản phẩm sẽ là một cách mạnh mẽ để truyền đạt tầm nhìn về sản phẩm của bạn cho một nhóm các bên liên quan điều hành và thu hút sự quan tâm của họ. Thuyết trình cũng có thể là một cách hiệu quả cao để thực hiện đào tạo bán hàng hoặc giáo dục các nhà phân tích trong ngành về sản phẩm của bạn.
Khả năng thuyết trình rất quan trọng với Product Manager
Các công cụ quản lý dự án (như Jira, Pivotal Tracker hoặc Trello)
Giống như các công cụ nhắn tin nhóm đã được giới thiệu ở trên, các ứng dụng quản lý dự án ngày nay mạnh mẽ hơn nhiều và cung cấp một phương tiện đơn giản hóa để theo dõi và ghi lại chi tiết. Các công cụ quản lý dự án phổ biến khác bao gồm Microsoft Project, thường sắp xếp ở định dạng biểu đồ Gantt và Jira, với cấu hình như một công cụ theo dõi vấn đề ít trực quan hơn. Và các công cụ như Pivotal Tracker sẽ giúp bạn thực hiện theo lộ trình của mình và giữ cho công việc tồn đọng của bạn được ngăn nắp.
Công cụ tăng lưu lượng (như Visio) của Product Manager là gì?
Khả năng làm việc và tính dễ sử dụng của các công cụ tăng lưu lượng khiến chúng trở thành một công cụ tuyệt vời để thực hiện một bước mà nhiều Product Manager bỏ qua dù không nên, đó là lập bản đồ hành trình của khách hàng.
Tạo bản đồ hành trình của khách hàng rất hữu ích trong việc cung cấp cho Product Manager và team của họ cái nhìn rõ ràng hơn về trải nghiệm đầy đủ của khách hàng với sản phẩm của công ty. Khi được tạo đúng cách, bản đồ hành trình sẽ hiển thị tất cả các điểm tiếp xúc mà một cá nhân có với tổ chức của bạn từ lần đầu tiên truy cập trang web của bạn (hoặc cuộc gọi đầu tiên từ một trong những đại diện bán hàng của bạn) thông qua việc mua và sử dụng sản phẩm của bạn.
Kết luận
Để quản lý sản phẩm hiệu quả, các Product Manager nên biết cách kết hợp nhiều công cụ khác nhau để cân bằng với “sức người” và cho ra sản phẩm chất lượng, hiệu quả nhất. Trên đây là một số công cụ quản lý sản phẩm mà các Product Manager nên tham khảo.
Tuyen dung IT là ngành có một trong những thách thức lớn hiện nay. Nó bao hàm vấn đề tìm kiếm và thu hút những ứng viên tài năng, đặc biệt là lĩnh vực nhân sự IT.
Đừng lo lắng, vì qua bài viết sau đây, TopDev sẽ bật mí cho bạn về 6 bí quyết tuyển dụng IT giúp thiết lập giải pháp chinh phục các ứng viên tài năng.
Xác định rõ vị trí tuyển dụng IT và nhu cầu cần có ở ứng viên
Để thiết lập được một chiến lược nhân sự IT hoàn hảo, bản thân nhà tuyển dụng phải tự vạch rõ những vị trí nào cần tuyển dụng. Cụ thể sẽ là: mục đích, nội dung công việc mà ứng viên chịu trách nhiệm thực hiện. Đồng thời, một bản đánh giá chi tiết với những tiêu chí cụ thể về các kỹ năng có liên quan là điều cần thiết.
Đối với các ứng viên, điều này đôi khi họ thường bỏ qua. Tuy nhiên bạn cần phải biết đâu là những đặc điểm quan trọng giúp mình trở thành một ứng viên IT hay freelancer IT thực sự tiềm năng. Từ đó, trau dồi và phát triển bản thân. Đối với nhà tuyển dụng, cần thật sự quan tâm đến vấn đề này vì việc xác lập rõ các vị trí tuyển dụng sẽ giúp quá trình tuyển dụng trở nên hiệu quả hơn.
Tạo ra thách thức cho ứng viên và thiết lập nền tảng đánh giá ứng viên hiệu quả
Thu hút nhiều ứng viên tiềm năng hơn. Và đâu là giải pháp phù hợp cần được áp dụng?
TopDev giới thiệu đến bạn Coding Assessment – Bài thực hành code đánh giá năng lực. Đây được xem là thách thức được tôi ưu trực tiếp; giúp ứng viên trải nghiệm những thử thách về năng lực cá nhân một cách nhanh chóng, hiệu quả.
Đặc thù ngành IT với nhiều kỹ năng quan trọng. Do vậy, Coding Assessment sẽ là bài tập đầy thiết thực với các ứng viên. Thông qua bài test, nhà tuyển dụng có thể đánh giá được điểm mạnh, điểm thiếu sót của từng ứng viên. Từ đó có sự sàng lọc phù hợp, sát với tiêu chí đã đề ra.
Ngoài ra, việc tích hợp nền tảng đánh giá ứng IT mới được xem là một nước đi thông minh. Và nền tảng đánh giá ứng viên mới TopDev x HackerRank là giải pháp khá hoàn hảo cho vấn đề này. HackerRank được biết đến là một trong những trang web thực hành code; cung cấp các loại bài tập thực hành – đánh giá coding hàng đầu hiện nay.
Những bài thực hành đánh giá này có thể giúp đơn giản hóa quá quy trình tuyển dụng IT hay các freelancer IT của bạn rất nhiều.
Truyền tải những thông điệp quan trọng dưới ngôn ngữ lập trình
Mối liên hệ sâu sắc giữa một đội ngũ nhân sự đầy nhiệt huyết và nhà quản lý nhân sự sẽ được thúc đẩy mạnh mẽ nếu bạn dành sự quan tâm đến thứ ngôn ngữ của tư duy này.
Bạn không cần phải là một master về code, đơn giản bạn chỉ cần có những kiến thức cơ bản về ngôn ngữ lập trình và nó đảm bảo tính thông dụng trong đặc thù phát triển của ngành mà thôi.
Việc nắm bắt những kiến thức về ngôn ngữ IT sẽ giúp bạn trình bày và mô tả về các vấn đề một cách chính xác, rõ ràng và hiệu quả hơn. Đừng lo lắng, vì việc tự chuyển mình thành một nhân viên IT dù bạn là người tuyển dụng IT sẽ giúp bạn có thể tiếp cận các ứng viên một cách tốt hơn.
Tuyển dụng IT hiệu quả với các nền tảng phỏng vấn thông minh
Phỏng vấn là một bước quan trọng trong quá trình tuyển dụng nhân sự và đối với nhiều công ty công nghệ, việc tạo ra một quy trình phỏng vấn đánh giá mới là thật sự cần thiết. Trong số nhiều giải pháp đang được ra mắt và không ngừng cải tiến gần đây, phỏng vấn qua video – Video Interview từ TopDev được nhiều nhà quản lý lựa chọn để tăng hiệu quả cho công tác tuyển dụng nhân sự.
Phỏng vấn một chiều (One-way video interviews): Có thể dùng để thay thế phỏng vấn điện thoại (phone call) không hiệu quả. Cho phép các ứng viên ghi lại câu trả lời của họ một cách thuận tiện để gửi cho nhà tuyển dụng; hoặc thuê người quản lý đánh giá khi tuyển dụng IT hay bất cứ tuyển dụng nào. freelancer it
Phỏng vấn video hai chiều (Two-way video interviews)Cho phép cả ứng viên và người phỏng vấn/tuyển dụng IT phát trực tiếp trong thời gian thực. Phỏng vấn hai chiều có hiệu quả cao để khắc phục khoảng cách và tình huống khi các cuộc phỏng vấn vật lý có thể không thực hiện được. Chẳng hạn trong mùa vụ dịch COVID-19
“Săn” ứng viên tiềm năng từ các sự kiện lớn về công nghệ
Có thể nói, các sự kiện lớn về công nghệ là một trong những cách hiệu quả nhất để thu hút ứng viên trong lĩnh vực IT.
Các sự kiện không chỉ mở ra những cơ hội gặp gỡ mà còn tạo cầu nối giúp thiết lập các mối quan hệ, giúp những nhà quản lý nhân sự trực tiếp giới thiệu và chia sẻ về con người, văn hóa, định hướng của doanh nghiệp mình.
Đồng thời, các sự kiện IT, sự kiển tuyển dụng IT còn là nơi gặp gỡ, giao lưu và học hỏi giữa các tài năng về công nghệ. Điều này là lợi thế lớn vì nó giúp cho việc tìm kiếm, khoanh vùng và tiếp cận những nhân tố tiềm năng trở nên thuận lợi hơn.
Một số event nổi bật mà TopDev đã thực hiện và tạo ra sự ảnh hưởng lớn, thu hút nhiều cá nhân có sự quan tâm với ngành IT. Cụ thể như Vietnam Mobile Day, Vietnam Web Summit, Tech Summit,… Đặc biệt hơn, Vietnam Web Summit được đánh giá là sự kiện IT lớn và quy mô nhất Việt Nam tập trung về Công nghệ với diễn giả gồm quản lý cấp cao và chuyên gia hàng đầu.
Đẩy mạnh phát triển tuyển dụng thông qua Digital Channels
Việc thúc đẩy các nội dung thông qua các hình thức khác nhau như banner hay email marketing được xem là cách thức hữu hiệu. Đây là giải pháp không chỉ giúp phát triển sự nhận diện về thương hiệu nhà tuyển dụng đồng thời tiếp cận chính xác insight tiềm năng.
Theo Khảo sát toàn cầu của Stack Overflow, có đến tổng số 64% tài năng về công nghệ thích được nhận thông tin và liên hệ về việc làm thông qua địa chỉ email cá nhân của họ. Đồng thời, cũng theo khảo sát này, nền tảng liên lạc qua các mạng xã hội được xếp hạng là kém hiệu quả nhất đối với những ứng viên IT.
Nhiều nhà quản lý cho rằng mối lo hiện tại chính là làm thế nào để có lượng database ứng viên IT dồi dào và sáng tạo được nội dung cực kỳ thu hút? Với cả 2 điều trên đều là những điều cực kỳ quan trọng để có một chiến lược marketing hiệu quả nhất. TopDev được nhiều đối tác tin tưởng và đồng hành vì có thể giúp kế hoạchEmail Marketing của doanh nghiệp hiệu quả hơn với kho dữ liệu 300.000 ứng viên IT, tỉ lệ mở (open rate) trung bình lên đến 20% và tỉ lệ chuyển đổi cực ấn tượng.
Lời kết
Tìm kiếm và tuyển dụng những ứng viên IT tài năng trong thời buổi hiện nay là không hề dễ dàng. Nhất là lời thời điểm biến động lớn sau mùa Covid-19.
Để có đủ sức bật cạnh tranh và gia tăng giá trị thương hiệu tuyển dụng trên thị trường, mỗi doanh nghiệp cần có những giải pháp thực sự hiệu quả. TopDev hy vọng bài viết xoay quanh tuyển dụng it vừa rồi sẽ cung cấp những thông tin bổ ích đến bạn đọc. Thị trường tuyển dụng cứ thế mà biến động và vấn đề thu hút các nhân tài công nghệ sẽ là một cuộc đua đầy thú vị.
Tuyển Dụng Nhân Tài IT Cùng TopDev Đăng ký nhận ưu đãi & tư vấn về các giải pháp Tuyển dụng IT & Xây dựng Thương hiệu tuyển dụng ngay!
Hotline: 028.6273.3496 – Email: contact@topdev.vn
Dịch vụ: https://topdev.vn/page/products
Với tư cách là Android developer, chúng tôi chủ yếu tạo ra các ứng dụng dành cho người dùng nhưng đừng quên những developer tuyệt vời tạo ra các ứng dụng cho các developer khác.
5 ứng dụng sau đây xuất hiện trong thư mục ‘Developer’ của tôi trên Pixel XL. Chúng không phải là những ứng dụng duy nhất trong thư mục đó nhưng chúng là những app mà tôi thấy không thể thiếu đối khi làm việc.
Tôi có thể viết toàn bộ bài viết về Termux để thể hiện sự tuyệt vời của nó.
Termux là một trình mô phỏng Linux terminal với một gói các trình quản lý, các tính năng chủ đề, floating widget – tất cả đều có. Nó có một danh sách khổng lồ các gói có sẵn để tải về và nó đơn giản như
apt-get install { package-name }
Tôi sử dụng Termux để chạy sever đẩy thông báo node.js cho một trong những ứng dụng của mình trên Nexus 7 năm 2013. Điều đó có nghĩa là tôi đã phải cài đặt các node.js, một loạt các node_modules trên Termux.
Hôm qua, tôi tìm cách cài đặt một trình TypeScript bởi vì tôi muốn xem JavaScript nó xuất ra như một bài tập học tập. Tôi đã bị bummed khi đã không làm các trick, cho đến khi tôi nhận ra rằng cài đặt gói typescript thông quacác trick làm ra npm.
apt-get install tsc
Tôi đã bị damned, thực sự có là một node package tuyệt vời.
Termux miễn phí trên Play Store, mặc dù một số tiện ích phải trả phí nhưng hoàn toàn xứng đáng.
Screener
Bạn đã tạo ứng dụng của mình và bây giờ muốn xuất bản ứng dụng đó trong Play Store.
Bạn biết điều gì sẽ làm cho danh sách của bạn trông tuyệt vời? Đưa những ảnh chụp màn hình này vào khung thiết bị!
Screener cho phép bạn tải xuống một khung thiết bị và đặt ảnh chụp màn hình của bạn trong đó. Bạn thậm chí có thể thêm screen glare (loại tốt) và một cái bóng phía sau thiết bị cho sự extra snazziness. Thêm vào đó, nền được tạo ra được tô màu dựa trên ảnh chụp màn hình. Tất cả đều miễn phí.
khi bạn có thể đăng bài này
trừ khi bạn là một người không có khiếu thẩm mỹ?
Material Cue
Nếu bạn định tuân theo các nguyên tắc thiết kế Material Design, bạn sẽ cần Material Cue.
Google không cần Material Cue.
Nhưng bạn cần
“Tôn trọng grid và grid sẽ tôn trọng bạn” – Leviticus 5:12
Material Cue đặt một lớp phủ gird trên màn hình của bạn để bạn có thể kiểm tra vị trí của element. Đối với các nội dung như yếu tố điều hướng, vị trí FAB,… điều này là vô giá.
Graphice
Graphice là một công cụ chiết xuất color của Francisco Franco. Sau một thời gian ngắn làm nhà độc tài phát xít, Francisco đã quyết định tự chuộc lại bằng cách tạo ra các ứng dụng Android và Graphice là một trong những app dẫn đầu mới nhất.
Kể từ khi giới thiệu API Palette, các ứng dụng chiết xuất color đều tốn phí trong Play Store (thậm chí tôi đã có một phần crack), nhưng Graphice có lẽ là một trong những ứng dụng tốt nhất. Vâng, thậm chí còn tốt hơn.
Một điều mà Graphice làm mà tôi đã không nhìn thấy bất kỳ ứng dụng khác có là nó cho phép bạn chọn khu vực trong bức ảnh mà bạn muốn trích xuất các palette. Nó cũng cho phép bạn xác định số lượng màu sắc mà bạn muốn trích ra từ mỗi bức ảnh.
Vì vậy, nếu bạn đang tìm kiếm color palette cho ứng dụng tiếp theo của mình, bạn sẽ biết đi đâu.
Đây là những người có kiến thức cao với khách hàng rất am hiểu và bạn không thể đủ khả năng để bỏ lỡ buổi biểu diễn của họ.
Extra recommendation: ở giữa các Android show, bạn sẽ muốn nghe Beef & Dairy Network podcast. Tin tưởng tôi, bạn làm. Nhưng đừng nói với ai về Fifth Meat.
Dishonorable mention: AIDE
Tôi đã từng yêu thích AIDE khi đó là một cách tuyệt vời để lập trình các ứng dụng Android, đặc biệt là khi mới bắt đầu.
7 lý do tại sao Product Manager vẫn sẽ nắm giữ vai trò quan trọng trong công nghệ SaaS?
Tác giả: Robin Dechant
Giới thiệu
Trong bối cảnh công nghệ SaaS vẫn sẽ tiếp tục phát triển và là nền tảng cho các mô hình bán hàng tự phục vụ và dịch vụ, vai trò của các Product Manager là gì trong những dự án này? Các Product Manager sẽ vẫn là những nhân vật chủ chốt để đảm bảo rằng công ty đang tạo ra sản phẩm mà khách hàng mong muốn và thực hiện lộ trình sản phẩm để không chỉ đáp ứng tình hình hiện tại mà còn tập trung vào thành công lâu dài.
Những lý do cho vai trò quan trọng của Product Manager là gì với công nghệ SaaS?
Họ là người làm việc trực tiếp với khách hàng
Xây dựng mối quan hệ với khách hàng từ sớm là chìa khóa thành công cho bất cứ dự án nào. Điều quan trọng là thị trường cũng như nhu cầu của khách hàng thay đổi theo thời gian, trong môi trường ngày nay có lẽ còn nhanh hơn bao giờ hết. Và một phần công việc của Product Manager là để nắm được những điều này. Trải nghiệm đầu tiên với sản phẩm có ý nghĩa rất lớn với cả người tạo sản phẩm và khách hàng. Việc dùng thử sẽ tăng cơ hội tạo ra giá trị và cảm nhận tốt hơn về sản phẩm.
Product Manager phải đảm nhận nhiều vai trò khác nhau
Sản phẩm tốt hơn gấp 10 lần và trải nghiệm người dùng sẽ tuyệt hơn
Điều này còn chính xác hơn nữa nếu sản phẩm mà bạn đang build xuất hiện đầu tiên trên thị trường. Trong một thị trường cạnh tranh khốc liệt, chẳng hạn như trong lĩnh vực nhân sự với hệ thống theo dõi ứng viên, có thể rất khó để làm nổi bật những điểm riêng của sản phẩm nếu sản phẩm của công ty bạn chỉ tốt hơn gấp 2 hoặc 3 lần.
Ở đây, vai trò của Product Manager là phân biệt rõ ràng sản phẩm của công ty bạn với sản phẩm của công ty đối thủ. Các PM phải đưa ra cách tiếp cận mới và suy nghĩ khác biệt. Nếu chỉ nói về việc ai đang làm cho các tính năng của sản phẩm đương nhiệm đẹp hơn, thì thật khó để tạo ra một “doanh nghiệp 100 triệu đô la”.
Tạo ra giao diện sản phẩm tốt hơn với suy nghĩ của Product Manager là gì?
Là người tiêu dùng sẽ sử dụng sản phẩm, chúng ta đã quen với trải nghiệm người dùng liền mạch từ tất cả các ứng dụng tuyệt vời mà chúng ta đang sử dụng và có tiêu chuẩn ngày càng cao cho các ứng dụng và sản phẩm mới. Những kỳ vọng cao này đang chuyển ngày càng nhiều vào thị trường phần mềm B2B. Nhất là với những sản phẩm đòi hỏi công nghệ phần mềm cao hơn.
Điều này thậm chí còn quan trọng hơn đối với các công ty SaaS, nơi người dùng không muốn dành nhiều thời gian để tìm hiểu về cách sử dụng sản phẩm hoặc quy trình làm việc mới. Trong môi trường ngày nay, nếu một Product Manager tuyển dụng vào công ty không thể xây dựng sản phẩm của mình bằng cách sử dụng các mẫu mới nhất, sẽ rất khó để thúc đẩy việc hình thành thói quen của người dùng. Nếu người dùng phải thay đổi thói quen liên quan đến kỹ thuật số của họ, họ khó có thể trở thành thành khách hàng lâu năm của công ty bạn.
Thương hiệu tạo nên tên tuổi sản phẩm
Khách hàng luôn đánh giá cao các thương hiệu nổi tiếng, đã có tên tuổi vì chúng đảm bảo độ tin cậy, tạo ra ý nghĩa và có thể thiết lập các mối quan hệ bền vững dẫn đến việc thu hút khách hàng mạnh mẽ hơn. Thương hiệu là một công cụ mạnh mẽ để giao tiếp với khách hàng. Nó cũng có thể làm cho một thương hiệu B2B hoạt động tốt hơn. Một số thương hiệu B2B SaaS tuyệt vời đã phát triển trong thời gian gần đây như Salesforce, Slack, Mailchimp hoặc Intercom chẳng hạn đã tạo ra những bước đột phá riêng cho sản phẩm của mình. Và vai trò của Product Manager là gì? Chính là xây dựng và tích hợp thương hiệu vào sản phẩm.
Các công ty này luôn quan tâm đến trải nghiệm của khách hàng và mỗi tính năng mới của sản phẩm sẽ tác động đến khách hàng như thế nào. Họ phải định hình sản phẩm và lên phương án thiết kế từ rất sớm. Trong suốt quá trình đó, các công ty phải lấy khách hàng làm trung tâm, để áp dụng các đặc tính văn hóa của họ vào sản phẩm. Điều này cũng đúng đối với các công ty B2C và nếu bạn nhìn vào các công ty công nghệ được đánh giá cao hiện nay, bạn sẽ thấy rất nhiều đồng sáng lập có nền tảng thiết kế – có thể là Brian Chesky từ Airbnb hoặc Evan Spiegel từ Snapchat, người đã học Thiết kế sản phẩm ở Stanford.
Product Manager cũng chịu trách nhiệm thiết kế sản phẩm
Sự quan trọng của thời gian trong việc hoàn thiện một sản phẩm
Cách hoạt động của phần mềm thường tuân theo chu kỳ. Theo thời gian, các công ty có thể hưởng lợi từ công nghệ mới nhất và có thể tạo ra cùng một sản phẩm và tính năng trong một khoảng thời gian ngắn hơn so với các công ty trước đó. Để hạn chế những điều này khi build một sản phẩm mới, Product Manager nên quan tâm đến dữ liệu để tìm được phương án thích hợp. Có các chỉ số được xác định rõ ràng, học hỏi từ dữ liệu và tối ưu hóa chúng. Trong hầu hết các trường hợp, vấn đề không phải là ai có thể xây dựng nhiều tính năng nhất mà là ai có thể xây dựng sản phẩm tốt nhất.
Trách nhiệm và ảnh hưởng của Product Manager là gì?
Một Product Manager sẽ phải bắt đầu công việc từ việc hiểu và thực hiện theo tầm nhìn của công ty để duy trì lộ trình sản phẩm trong khi luôn tìm hiểu thêm về khách hàng và thị trường của bạn. Bạn cũng đang làm việc trong sự giao thoa giữa kỹ thuật và kinh doanh, cố gắng hoàn thành những kỳ vọng không thực tế.
Trong vai trò này, công việc của Product Manager không chỉ là việc liên kết các phần khác nhau lại với nhau mà còn áp dụng các công nghệ mới có thể gia tăng giá trị như machine learning. Mục đích của việc làm này không phải vì lợi ích mà để thực sự giải quyết một vấn đề hoặc cải thiện trải nghiệm của khách hàng. Tóm lại, Product Manager đảm nhiệm nhiều vai trò khác nhau và tôi nghĩ điều này nhấn mạnh ảnh hưởng của họ đối với khách hàng cũng như đối với công ty và tầm nhìn cũng như tương lai của công ty.
Kết luận
Rõ ràng công việc của Product Manager vẫn sẽ tiếp tục có ảnh hưởng đến nhiều quyết định quan trọng trong việc phát triển lộ trình sản phẩm. Nhất là với các sản phẩm liên quan đến phần mềm. Do đó những ai đang quan tâm đến công việc Product Manager trong phát triển công nghệ SaaS, nên có sự tìm hiểu ngay từ đầu để nắm bắt đúng những việc cần làm.
Hầu như mọi trang web bạn truy cập vào ngày hôm nay đều được HTTPS bảo vệ. Nếu bạn chưa có, hãy setup 1 ssl cert cho web của bạn. Việc sử dụng HTTPS cho web nhà bạn đòi hỏi các request từ đây ra ngoài cũng đòi hỏi các service khác cũng phải sử dụng HTTPS, bằng không nó sẽ không cho phép service hoạt động vì không đảm bảo đồng nhất và bảo mật. Điều này gây ra 1 vấn đề cho các developer coding trên local và cần test trên HTTPS cho đồng nhất với production.
Ngay khi bắt đầu dự án, chúng tôi quyết định secure AWS Elastic Load Balancer với HTTPS như là một phần của việc tăng cường tính bảo mật. Tôi gặp phải một tình huống là request từ local của tôi đến máy chủ bị từ chối.
Trong một cuộc tìm kiếm Google, tôi đã tìm thấy một số bài báo như thế này, đây là bài viết này hay hướng dẫn chi tiết về cách giúp tôi triển khai HTTPS trên localhost. Không có hướng dẫn nào làm việc ngay cả sau khi tôi làm từng bước giống y hệt họ. Chrome luôn ném một lỗi NET::ERR_CERT_COMMON_NAME_INVALID vào tôi.
Vấn đề
Tất cả các hướng dẫn chi tiết tôi đã tìm thấy phù hợp với thời điểm mà họ viết, còn bây giờ đã được thay đổi khá nhiều (nhất là đối với Chrome)
Chúng ta sẽ dùng OpenSSL để cấp tất cả các chứng chỉ.
Bước 1: Root SSL cert
Bước đầu tiên là tạo một chứng chỉ Root Secure Sockets Layer (SSL). Chứng chỉ này sau đó có thể được sử dụng để chứng thực bất kỳ số chứng chỉ nào bạn có thể tạo ra các tên miền riêng lẻ.
Tạo một RSA-2048 và lưu nó vào một file rootCA.key. Tập tin này sẽ được sử dụng như là một key để tạo ra chứng chỉ Root SSL. Bạn sẽ được nhắc nhập pass để sau này khi tạo chứng chỉ nhưng theo toi bạn cũng cần phải nhập chi cho lằng nhằng.
openssl genrsa -des3 -out rootCA.key 2048.
Bạn sử dụng key mà bạn generate bên trên để tạo mới một chứng chỉ Root SSL. Lưu nó vào một file tên rootCA.pem. Chứng chỉ này sẽ có hiệu lực là 1.024 ngày. Bạn có thể thay đổi nó vào bất kỳ số ngày nào bạn muốn.
Trước khi bạn có thể sử dụng chứng chỉ gốc Root SSL đã được tạo để bắt đầu phát hành cert cho tên miền, thêm một bước nữa. Bạn cần phải cho Mac trust chứng chỉ gốc để tất cả cert được phát hành bởi nó cũng được tin cậy.
Mở Keychain Access trên máy Mac và đi đến mục Certificates trong System keychain. Khi đó, nhập rootCA.pem bằng File> Import Items. Nhấp đúp vào chứng chỉ đã nhập và thay đổi phần “When using this certificate:” thả xuống thành Always Trust vào Trust section.
Chứng chỉ của bạn sẽ trông giống như sau trong Keychain Access nếu bạn đã thực hiện đúng các hướng dẫn cho đến giờ.
Bước 3: Domain SSL certificate
Cert Root SSL có thể được sử dụng để phát hành chứng chỉ đặc biệt cho các thiết bị local tại localhost.
Tạo một tệp server.csr.cnf với cấu hình OpenSSL mới để bạn có thể nhập các cài đặt này khi tạo chứng chỉ thay vì nhập chúng vào dòng lệnh.
Tạo mã khóa cho chứng chỉ cho localhost bằng cách sử dụng các cài đặt cấu hình được lưu trữ trong server.csr.cnf và mã khóa này được lưu trữ trong server.key.
Yêu cầu ký chứng chỉ (certificate signing request) được cấp qua cert Root SSL mà chúng tôi đã tạo trước đó để tạo chứng chỉ miền cho localhost. Đầu ra là một tập tin chứng chỉ được gọi là server.crt.
Bạn đã sẵn sàng để secure localhost với HTTPS. Di chuyển các tệp server.key và server.crt đến một vị trí dễ access và include chúng khi khởi động web server.
Trong một ứng dụng Express được viết bằng Node.js, dưới đây là cách bạn thực hiện. Hãy chắc chắn rằng bạn làm chỉ cho môi trường local. Không sử dụng trong production.
var path = require('path')
var fs = require('fs')
var express = require('express')
var https = require('https')
var certOptions = {
key: fs.readFileSync(path.resolve('build/cert/server.key')),
cert: fs.readFileSync(path.resolve('build/cert/server.crt'))
}
var app = express()
var server = https.createServer(certOptions, app).listen(443)
Cảnh sát Victoria là cơ quan thực thi pháp luật chính của Victoria, Úc. Với hơn 16.000 xe bị mất cắp ở Victoria trong năm qua – tổn thất khoảng 170 triệu đô – cơ quan này đang thử nghiệm nhiều giải pháp kỹ thuật nhằm giải quyết nạn trộm xe. Họ gọi hệ thống này là BlueNet.
Để giúp ngăn chặn việc bán xe ăn cắp, đã có một dịch vụ dựa trên web tên VicRoads để kiểm tra tình trạng đăng ký xe. Bộ cũng đã đầu tư vào một máy quét tấm giấy cố định – một camera cố định quét qua lưu lượng để tự động xác định các xe bị đánh cắp.
Đừng hỏi tôi tại sao, nhưng một buổi chiều tôi đã có mong muốn mẫu thử nghiệm một chiếc máy quét nhãn đĩa xe gắn máy sẽ tự động thông báo cho bạn nếu một chiếc xe đã bị đánh cắp hoặc đã không đăng ký. Hiểu rằng những thành phần cá nhân này tồn tại, tôi tự hỏi làm thế nào để kết hợp chúng với nhau khó khăn đến thế nào.
Cảnh sát Victoria vừa mới tung ra bản thử nghiệm về một phần mềm tương tự, và chi phí phát hành ước tính đã ở đâu đó trong khoảng 86.000.000 đô. Một người bình luận đã chỉ ra rằng với 86 triệu đô để trang bị cho 220 chiếc xe thì sẽ tính ra trung bình 390,909 đô mỗi chiếc.
Chắc chắn chúng ta có thể làm tốt hơn một chút.
Các tiêu chí làm nên thành công
Trước khi bắt đầu, tôi lên kế hoạch về yêu cầu chính cho thiết kế sản phẩm:
#1: Việc xử lý hình ảnh phải được thực hiện local
Streaming video trực tiếp đến nơi xử lí trung tâm dường như là cách tiếp cận hiệu quả nhất để giải quyết vấn đề này. Bên cạnh tuyệt vời cho lưu lượng truy cập dữ liệu, bạn cũng giới thiệu độ trễ mạng vào một quá trình có thể đã được khá chậm.
Mặc dù một thuật toán về centralized machine learning chỉ có thể có được sự chính xác hơn theo thời gian, chúng ta muốn tìm hiểu nếu một local thực hiện trên thiết bị sẽ là “đủ tốt”.
#2: Phải làm việc với hình ảnh có chất lượng thấp
Bởi vì tôi không có Raspberry Pi hoặc webcam USB nên tôi sẽ sử dụng footage của dashcam – nó có sẵn và là nguồn lý tưởng cho dữ liệu mẫu. Giống như added bonus, dashcam video đại diện cho chất lượng chung của footage mà bạn mong muốn từ các camera gắn trên xe.
#3: Cần được xây dựng dựa trên công nghệ mã nguồn mở
Dựa trên một phần mềm độc quyền có nghĩa là bạn sẽ get stung mỗi khi bạn yêu cầu thay đổi hoặc tăng cường – và tiếp tục stinging cho mỗi yêu cầu được thực hiện sau đó. Sử dụng công nghệ mã nguồn mở là không cần suy nghĩ.
Relying upon a proprietary software means you’ll get stung every time you request a change or enhancement — and the stinging will continue for every request made thereafter. Using open source technology is a no-brainer.
Kết luận
Ở level cao, giải pháp của tôi lấy một hình ảnh từ dashcam video, đưa nó qua qua một hệ thống nhận dạng tấm giấy phép mã nguồn mở được cài đặt cục bộ trên thiết bị, truy vấn dịch vụ kiểm tra đăng ký, và sau đó trả về kết quả.
Dữ liệu được trả lại cho thiết bị được cài đặt trong xe thực thi pháp luật bao gồm xe và mô hình (mà nó chỉ sử dụng để xác minh các xe đã bị đánh cắp), tình trạng đăng ký và bất kỳ thông báo nào của chiếc xe được báo cáo bị đánh cắp.
Nghe có vẻ đơn giản, đó là bởi vì nó thực sự là. Ví dụ, xử lý hình ảnh tất cả có thể được xử lý bởi thư viện openalpr.
Tất cả được dùng để nhận diện các ký tự trên license plate:
openalpr.IdentifyLicense(imagePath, function (error, output) {
// handle result
});
Đây là những điều của tôi chứng minh khái niệm như sau:
// Open form and submit enquire for `rego`
function getInfo(rego) {
horseman
.userAgent('Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0')
.open(url)
.type('#registration-number-ctrl input[type=text]', rego)
.click('.btn-holder input')
.waitForSelector('.ctrl-holder.ctrl-readonly')
.html()
.then(function(body) {
console.log(processInfo(body, rego));
return horseman.close();
});
}
// Scrape the results for key info
function processInfo(html, rego) {
var $ = cheerio.load(html);
var vehicle = $('label.label').filter(function() {
return $(this).text().trim() === 'Vehicle:';
}).next().text().trim();
var stolen = $('label.label').filter(function() {
return $(this).text().trim() === 'Stolen status:';
}).next().text().trim();
var registration = $('label.label').filter(function() {
return $(this).text().trim() === 'Registration status & expiry date:';
}).next().text().trim();
return {
rego,
vehicle,
stolen,
registration
};
}
Kết quả
Sự công nhận về giấy phép mã nguồn mở được không được công nhận. Ngoài ra, các thuật toán nhận dạng hình ảnh có thể không được tối ưu hóa cho tấm giấy phép của Úc.
Giải pháp đã có thể nhận diện tấm giấy phép trong một lĩnh vực rộng.
Mặc dù, giải pháp này đôi khi gặp vấn đề với các chữ cái trên biển số.
Nhưng … các giải pháp cuối cùng sẽ có được sự chính xác.
Như bạn thấy trong hai hình ảnh trên, việc xử lý hình ảnh một vài khung hình sau đó đã nhảy lên từ mức độ tự tin là 87% đối với tóc trên 91%.
Với tính chính xác có thể được cải thiện bằng cách tăng tỷ lệ mẫu và sau đó sắp xếp theo thứ hạng độ tin cậy cao nhất. Ngoài ra, một ngưỡng có thể được đặt chỉ chấp nhận sự tự tin lớn hơn 90% trước khi tiếp tục xác nhận số đăng ký.
Đây là các bản sửa lỗi code đầu tiên và không loại trừ việc đào tạo phần mềm nhận dạng license plate với bộ dữ liệu cục bộ.
Còn về 86,000,000 đô
Để công bằng, tôi hoàn toàn không biết có bao nhiêu con số 86 triệu đô – và tôi cũng không thể nói về tính chính xác của công cụ mã nguồn mở của tôi mà không cần đào tạo so với hệ thống BlueNet.
Tôi hy vọng phần của ngân sách đó bao gồm việc thay thế một số cơ sở dữ liệu và các ứng dụng phần mềm để hỗ trợ truy vấn các cấp phép có tần số cao, độ trễ thấp trên mỗi xe.
Mặt khác, chi phí khoảng 391k đô mỗi xe dường như khá tốn kém – đặc biệt nếu BlueNet không chính xác và không có các dự án công nghệ thông tin quy mô lớn để ngừng hoạt động hoặc nâng cấp các hệ thống bị phụ thuộc.
Các ứng dụng tương lai
Mặc dù rất dễ bị cuốn vào bản chất Orwellian của một mạng lưới những người tán thành tấm giấy phép luôn có nhiều ứng dụng tích cực của công nghệ này. Hãy tưởng tượng một hệ thống thụ động quét người cùng đi xe và tự động cảnh báo các nhà chức trách và thành viên gia đình đến vị trí hiện tại của họ.
Xe của Teslas đã được làm đầy bằng camera và cảm biến với khả năng nhận được các bản cập nhật OTA – hãy tưởng tượng biến những chiếc xe này thành một đội quân tốt. Các tài xế của Ubers và Lyft cũng có thể được trang bị các thiết bị này để tăng đáng kể phạm vi bảo hiểm.
Sử dụng công nghệ mã nguồn mở và các component hiện có, có vẻ như có thể cung cấp một giải pháp cung cấp một tỷ lệ lợi nhuận cao hơn nhiều – cho một khoản đầu tư ít hơn 86triệu đô.
Tôi là Lydia, một cô gái 19 tuổi sống ở Stockholm, và tôi là một developer JavaScript (React)!
Tôi bắt đầu viết code từ lúc 15 tuổi. Đồng thời, tôi cũng có một blog về sức khoẻ và lối sống trên Tumblr với hàng chục ngàn người xem. Đây là lúc tôi bắt đầu tạo layout của riêng mình với HTML, CSS và jQuery. Do tôi không thích các themes có sẵn trên thị trường nên tôi đã quyết định tự lực gánh sinh! Kể từ đó, tôi tiếp tục nâng cao kỹ năng và kiến thức. Tuy nhiên, tôi không hề nghĩ rằng những việc này là coding bởi tôi chỉ đơn giản là thích tạo ra các thiết kế của riêng cho mình.
Trong thời gian này, tôi vẫn học chính qui cho đến khi được 18 tuổi. Tuy vậy, tôi cảm thấy như mình đã lãng phí rất nhiều thời gian cho các thứ hầu như chả mang lại ích lợi gì cho bản thân. Tuy vậy, tôi vẫn rất chăm chỉ để có bằng tốt nghiệp tốt cũng như làm thêm cho nhiều dự án bên lề.
Sau khi tốt nghiệp trung học, tôi quyết định không lên đại học. Đây là một quyết định rất đáng sợ đối với tôi, vì tôi luôn được nhồi ép rằng chỉ có đại học là cách duy nhất để có một tương lai thành công! Tôi đã dành rất nhiều thời gian để đạt được điểm số cao nhất trong trường trung học để có thể vào một trường đại học tốt. Và quả thật là tôi thực sự đã lãng phí rất nhiều năm trong cuộc đời mình. Nhưng tôi không hề hối tiếc! Hầu hết mọi người xung quanh tôi không hiểu và nghĩ tôi mắc phải một sai lầm lớn, nhưng vẫn có một số ít hiểu và ủng hộ tôi.
Bản thân vốn rất độc lập: do đó mà tôi đã chuyển đến một quốc gia khác khi tôi chỉ mới 18 tuổi. Song song đó, tôi cũng đi du lịch rất nhiều và luôn bận rộn làm bất cứ điều gì để cải thiện tương lai của mình. Sau khi tôi quyết định không đi học đại học, tôi đã tham gia chương trình đào tạo về code trong 3 tháng tại Tampa Bay, Florida. Nó đã giúp tôi rất nhiều khi củng cố một lượng kiến thức nền tảng quan trọng cũng như gặp gỡ những người bạn cùng niềm đam mê. Tôi đã học một cách điên cuồng, liên tục thử thách bản thân và đã nỗ lực rất nhiều vào các dự án cá nhân của tôi để cải thiện kỹ năng lập trình cũng như học được nhiều công nghệ mới.
Thật bất ngờ là ngay cả trong suốt 3 tháng, một nhà tuyển dụng liên tục hỏi tôi có thể làm việc cho họ hay không. Quả thật, tôi đã không hiểu được: họ có lẽ đã không đọc hồ sơ LinkedIn của tôi? Bởi tôi đã không đi học đại học hoặc có bất cứ bằng cấp gì cao cả.
Và tôi hiểu ra rằng bạn không học cách lập trình ở trường. Bạn học nó bằng cách viết các chương trình và phần mềm. Hầu hết các công ty sẽ không quan tâm nếu bạn có học lập trình ở trường đại học, họ chỉ quan tâm tới kĩ năng cũng như niềm đam mê của bạn.
Đừng hiểu nhầm. Nếu bạn thích cuộc sống ở đại học, hoặc đơn giản là bạn muốn có một số kiến thức cơ bản thì đại học chắc chắn là một quyết định tốt. Tuy nhiên, nó không phải là con đường duy nhất.
Cuộc sống hàng ngày của tôi (ngoài công việc)
Sau khi bootcamp kết thúc, tôi bay về Stockholm. Tôi rất vui mừng khi bắt đầu chương mới này trong cuộc đời, và không thể chờ đợi để tiếp tục phát triển. Vậy hôm nay tôi phải làm gì bây giờ?
Tôi thức dậy và cố gắng thư giản. Chúng thật sự rất quan trọng bởi bạn đã phải ngồi hàng giờ đồng hồ, và cơ thể của bạn chắc chắn sẽ bị tổn thương nếu bạn không chăm sóc nó.
Tôi cố gắng xem các khóa học code trực tuyến ít nhất 2 giờ mỗi ngày. Tôi thích xem chúng bởi vì tôi luôn luôn học những điều mới và lấy cảm hứng từ việc nhìn thấy người hướng dẫn viết code một cách dễ dàng như vậy. Tôi cố gắng tạo ra nét riêng mình bằng cách làm một dự án tương tự ở bên cạnh, hơi khác một chút, vì vậy tôi không chỉ đơn giản sao chép những gì mà người hướng dẫn đang làm.
Tôi cố gắng để làm việc với các dự án cá nhân của mình trong ít nhất 4 giờ. Trong đó, tôi luôn cố gắng sử dụng các ngôn ngữ hoặc kỹ thuật mới lạ để tích lũy kinh nghiệm. Và hãy trung thực, nó có thể sẽ rất khủng khiếp! Tôi sẽ không nói dối và nói rằng nếu bạn làm việc chăm chỉ, bạn sẽ thành công. nhưng tôi cũng thực sự muốn nhấn mạnh vào thực tế là việc học một cái gì đó mới có thể sẽ rất gian khổ thời gian đầu. Bạn sẽ cảm thấy bị mất tinh thần, như rằng bạn sẽ không bao giờ hiểu nócũng như mất tự tin với kỹ năng code của mình. Tuy vậy, việc trải qua những cảm xúc này không quan trọng mà là những gì bạn làm về nó mới là quan trọng nhất. Hãy nghiên cứu nó, viết câu hỏi lên Stack Overflow và chỉ cần tiếp tục cố gắng cho đến khi bạn tìm ra giải pháp.
Tôi cố gắng đọc ít nhất 2 bài báo. Tôi thực sự thích nhìn thấy những điều từ một góc nhìn khác nhau và chúng có thể là về bất cứ điều gì: làm thế nào để giải quyết một vấn đề lập trình nhất định? tại sao đôi khi CSS lại khốn khổ? hay những công nghệ mới tuyệt vời nhất. Điều quan trọng là đừng để mình bị kẹt trong một suy nghĩ lối mòn.
Tôi cố gắng giải quyết ít nhất 5 CodeWars Kata. CodeWars là người bạn thân nhất của bạn khi bạn bắt đầu viết code. Các giải pháp cho những vấn đề họ cung cấp cho bạn thường rất hữu ích bởi bạn sẽ cải thiện được cú pháp của mình rất nhiều bằng cách chỉ cần tham khảo các giải pháp của người khác. Và một điều quan trọng khác nữa: khi bạn đi phỏng vấn, họ sẽ thường cung cấp cho bạn những câu hỏi rất giống với những câu hỏi trên CodeWars!
Tôi cố gắng không ăn đồ ăn vặt và chuyển qua những thực phẩm bổ dưỡng nhằm giữ cho tôi tỉnh táo và vui vẻ hơn! Tôi cũng cảm thấy tràn đầy năng lượng và động lực hơn khi đã có một bữa ăn sáng và trưa lành mạnh. Điều này chắc chắn cải thiện khả năng code của tôi.
Bằng cách viết bài này, tôi hy vọng sẽ truyền cảm hứng cho một số người tham gia vào thế giới công nghệ, và nó thực sự không đáng sợ như nhiều người nghĩ. Lập trình không chỉ dành cho những siêu nhân hoặc các cá nhân siêu phàm như họ miêu tả trong phim. Nghề lập trình luôn dành cho những ai yêu thích việc tạo ra công nghệ, những người yêu thích được thử thách bản thân, và cho bất cứ ai mong muốn cải thiện bản thân mình!
Để kết luận, sau đây là những lời khuyên của tôi:
Bạn thực sự không phải đi học đại học, miễn là bạn có thể thực sự thúc đẩy bản thân và có niềm đam mê cho code!
Luôn luôn 110% sức lực của bạn cho bất cứ khi nào bạn có thể. Tuy nhiên, luôn luôn ưu tiên cho sức khoẻ bản thân. Giấc ngủ là rất quan trọng!
Nó là hoàn toàn bình thường để cảm thấy không thoải mái và nghĩ rằng bạn đang thực sự dở với code nhưng đừng để điều này kéo bạn xuống.
Luôn nhắc nhở bản thân rằng bạn đã đến bao xa. Nó thật sự dễ quên việc bạn đã cải thiện rất nhiều so một tháng trước! Tôi có thể đảm bảo với bạn sẽ ngạc nhiên với những thay đổi từ bản thân.
Đừng để người khác làm cho bạn cảm thấy như ngôn ngữ mà bạn đang học là một ngôn ngữ xấu! Mọi thứ đều có vai trò mà nó tốt nhất, đặc biệt là bạn!
The grouping of two or more database servers is known as database clustering.
Liên kết của hai hoặc nhiều database server thì được hiểu là database clustering
Như đã đề cập ở trên, trường hợp thiết kế Scalable Web Application, rất có thể một hoặc nhiều web service sẽ kết nối chung tới một Database. Cần nhiều web service là do ta cần handle một số lượng lớn request.
Liên kết ở đây được hiểu là dữ liệu ở các cụm Database không hệ khác nhau, được đồng bộ hóa trong quá trình thao tác.
Mô hình Database Clustering. Nguồn ảnh / Source: docs.oracle.com
Cùng có thể hiểu Database Clustering như là cách liên kết. Nhiều các DB liên kết với nhau để tăng cường sức mạnh, đảm bảo ứng dụng hoạt động trơn tru.
Với Database Clustering, có những ưu điểm rõ ràng có thể nhận thấy khi thao tác, bảo trì hệ cơ sở dữ liệu như sau:
2.1 Load Balancing
Bản thân một hệ cơ sở dữ liệu không hề có cơ chế cân bằng tải (Load Balancing) ngay từ ban đầu. Về cơ bản mà nói thì
Basically, what load balancing does is allocating the workload among the different computers that are part of the cluster.
Về cơ bản, những gì cân bằng tải thực hiện là phân bổ khối lượng công việc giữa các máy tính khác nhau là một phần của cluster
Trường hợp số lượng request tăng đột biến, chỉ một services sẽ không thể handle nổi, lúc này sẽ có nhiều web services thực hiện đồng thời, phân bổ và điều tiết số lượng request. Điều này sẽ khả thi với Database Clustering, bởi vì tất cả các web services đó đều sử dụng chung một database
2.2 High Availability
Tính sẵn có cao cũng là một yếu tố để cân nhắc cho việc sử dụng Database Cluster. Sẵn có tức là khi cần truy cập tới database, ta có thể truy xuất được.
High availability refers the amount of time a database is considered available.
Tính sẵn sàng cao đề cập đến khoảng thời gian cơ sở dữ liệu được coi là có sẵn
Trường hợp số lượng request lớn hoặc xử lý ở phía server tương đối phức tạp, rất có thể xảy ra trường hợp các request bị từ chối.
2.3 Data redundancy
Dự phòng dữ liệu cũng là một điểm mạnh khi sử dụng Database Clustering. Do các DB node trong mô hình Clustering được đồng bộ. Trường hợp có sự cố ở một node, vẫn dễ dàng truy cập dữ liệu node khác.
Việc có node thay thế đảm bảo ứng dụng hoạt động mượt mà. Ngay cả khi một hoặc một vài node trong mạng bị down.
3. Khi nào nên sử dụng database clustering?
Ngày nay, các ứng dụng web (web application) thường được yêu cầu hoạt động mượt mà trong tất cả các trường hợp. Vậy khi nào thì cần tới database clustering?
If you’re an entrepreneur, director, or database administrator, you care about database clustering because it helps keep your applications online a greater amount of the time.
Nếu bạn là doanh nhân, giám đốc hoặc quản trị viên cơ sở dữ liệu, bạn quan tâm đến việc phân cụm cơ sở dữ liệu vì nó giúp giữ cho các ứng dụng của bạn trực tuyến trong một khoảng thời gian dài hơn.
Nắm vững khái niệm là một chuyện. Thực tế ở các hệ cơ sở dữ liệu khác nhau sẽ cần tìm hiểu thêm MySQL Cluster CGE
Con đường sự nghiệp của một Product Manager là gì? Nó được đánh giá là rất thú vị với nhiều cung bậc khác nhau từ chuyên môn cho đến cảm xúc. Các yếu tố như quy mô công ty, ngân sách, mục tiêu kinh doanh,… đều sẽ tác động rất nhiều đến cách xây dựng một chiến lược sản phẩm và định hình nên quá trình làm việc của họ cũng như những thành tựu mà họ đạt được.
Lộ trình công việc Product Manager trải qua nhiều giai đoạn khác nhau
Career path của một Product Manager là gì?
Associate Product Manager là gì?
Ở mức độ này, một Product Manager phải chứng minh rằng mình hiểu rõ công việc quản lý sản phẩm là gì và bạn có mối quan tâm cũng như niềm đam mê rõ ràng trong việc làm việc với khách hàng. Điểm dừng đầu tiên này trên con đường sự nghiệp của một Product Manager không giống như khi còn ở trường học. Nó không phải là biết nhiều nhất, làm việc chăm chỉ nhất, hoặc đánh bại đối thủ cạnh tranh. Nó đòi hỏi nhiều yếu tố chuyên môn hơn như thế.
Đó là thể hiện sự đồng cảm của bạn đối với người dùng, làm nổi bật khả năng xác định các vấn đề và cơ hội của bạn cũng như trong việc cộng tác với những người khác. Điều quan trọng là bạn phải chứng tỏ rằng bạn có thể nghe thấy tất cả các khía cạnh của một câu chuyện, tổng hợp và đánh giá mọi thứ và đi đến một quyết định rõ ràng.
Về công việc hàng ngày, một Associate Product Manager tuyển dụng vào công ty sẽ tham gia vào mọi việc mà một Product Manager thường làm, chỉ là ở quy mô và mức độ nhỏ hơn. Nói cách khác, bạn có thể không thiết lập chiến lược sản phẩm nhưng bạn sẽ phải ưu tiên cho các dự án của chính mình. Bạn có thể không trình bày các kế hoạch sản phẩm nhưng bạn sẽ chịu trách nhiệm cập nhật cho các đồng nghiệp và người quản lý của mình.
Product Manager
Đến được với vị trí này đòi hỏi bạn phải là những người đã có kinh nghiệm. Bạn không nhất thiết phải có kinh nghiệm quản lý sản phẩm một cách trực tiếp, nhưng bạn cần phải có một số kinh nghiệm chuyên môn thể hiện rõ ràng như các kỹ năng giao tiếp, làm việc hiệu quả. Mặc dù bạn có thể không cần trải nghiệm sản phẩm thực tế, nhưng chắc chắn bạn sẽ cần phải có hiểu biết về các khái niệm cơ bản và bắt đầu dự án với thái độ hoạt động tích cực.
Để có thể đạt được những bước tiến mới trong sự nghiệp, một Product Manager cần phải tự tin rằng bạn đang làm tốt công việc của mình và được thúc đẩy để giúp team hoàn thành các mục tiêu rộng lớn hơn. Bạn cũng nên có hiểu biết rõ ràng về lợi ích khách hàng mà sản phẩm của bạn cung cấp, có thể trình bày rõ các vấn đề khách hàng cụ thể mà sản phẩm đang giải quyết và có thể gắn các chỉ số sản phẩm với mục tiêu kinh doanh một cách hấp dẫn.
Với vị trí này, có thể nói bạn đã là người có tay nghề “cứng cáp” và có nhiều kinh nghiệm làm việc. Ít nhất một Senior Product Manager thành công sẽ có kinh nghiệm chuyên môn, thể hiện được khả năng tư duy của mình, có trách nhiệm với các quyết định, dẫn dắt và đưa ra các quyết định dựa trên dữ liệu và vô số các yếu tố phức tạp, phụ thuộc lẫn nhau. Vai trò này cũng sẽ đòi hỏi kiến thức sâu về sản phẩm và thị trường.
Senior Product Manager là những người đã có nhiều kinh nghiệm làm việc
Mỗi ngày, Senior Product Manager phải thực hiện hầu hết các nhiệm vụ tương tự như một Product Manager nhưng với các sản phẩm có tác động cao hơn, khả năng hiển thị cũng cao hơn. Họ lãnh đạo các Product Manager cấp dưới khác và làm việc chặt chẽ với các nhà lãnh đạo sản phẩm trong công ty để đóng góp và thực hiện chiến lược sản phẩm. Trong khi các Product Manager khác có thể chú ý đến dữ liệu hoặc tham gia nhiều hơn vào các cuộc phỏng vấn và phản hồi của khách hàng, các Senior Product Manager bắt đầu xem xét nhiều hơn về quy trình sản phẩm rộng hơn và bắt đầu có tiếng nói hơn đối với nhóm sản phẩm.
Vai trò Director of Product yêu cầu kinh nghiệm lãnh đạo và khả năng xây dựng, thể hiện sự tin tưởng một team thực hiện công việc mà bạn đã làm trước đây với tư cách là người đóng góp duy nhất. Vai trò Director of Product cũng sẽ tập trung hơn nữa vào việc xây dựng các quy trình tốt hơn và trau dồi những quy trình hiện có, cải thiện hiệu suất chung của nhóm và xây dựng sự đồng thuận trong toàn bộ tổ chức.
Bạn sẽ thường xuyên gặp gỡ các đồng nghiệp của mình trong toàn công ty, đây là điều đang xảy ra và tại sao, bạn cần gì ở sản phẩm, bạn phải làm gì để sản phẩm tốt hơn,… Công việc này chủ yếu dựa vào dữ liệu. Bạn có một team tập trung vào các KPI riêng lẻ nhưng bạn vẫn sẽ chịu trách nhiệm kết nối những con số quy mô nhỏ đó với các chỉ số thành công rộng hơn của doanh nghiệp nói chung.
Để thành công ở bất cứ công việc nào đều đòi hỏi chúng ta phải đi qua nhiều vị trí, với nhiều thử thách và khó khăn. Nhưng chắc chắn đích đến sẽ là những điều tốt đẹp chờ đợi bạn ở phía trước. Nắm rõ về lộ trình nghề nghiệp của một Product Manager sẽ giúp bạn lên kế hoạch làm việc tốt hơn cho công việc của mình.
Nhà quản trị nhân sự giỏi cần có sự dẫn dắt, truyền đạt tốt cho các nhân viên của mình. Nhiều hệ giá trị được thể hiện như: niềm tin, sự hợp tác, sự dấn thân, tính trách nhiệm với mọi nhiệm vụ. Cùng TopDev điểm qua những phẩm chất mà một nhà nhân sự giỏi nên tạo dấu ấn đối với nhân viên.
Khả năng truyền cảm hứng
Dù doanh nghiệp của bạn có quy mô nhỏ, vừa hay rộng khắp thì không gian văn hóa của doanh nghiệp phải thật sự có ý nghĩa. Vì thế, người lãnh đạo/tuyen dung it cần có một năng lực truyền cảm hứng thông qua “sân nhà”.
Truyền cảm hứng làm một năng lực cần có của nhà lãnh đạo.
Những biểu hiện cụ thể như: tính sáng tạo, chủ động, sự tập trung và chuyên nghiệp trong tác phong nghề nghiệp,…Tất cả đều phản ánh năng lực của mỗi nhà quan trị nhân sự tuyen dung it.
Bạn sẽ là nguồn cảm hứng lớn đối với nhân viên khi tạo cho họ những động lực trên cơ sở các phẩm chất tốt đẹp.
Đồng thời, nhờ sự truyền cảm hứng ấy, nhân viên họ có cách hành xử và nhìn nhận đúng đắn; góc nhìn của họ cũng trở nên đa dạng hơn. Nhờ các động lực, họ có thể phát triển bản thân mình nhiều hơn. Từ đó, lập kế hoạch rèn luyện, trở thành phiên bản tốt hơn mỗi ngày.
Chinh phục sự tử tế
Con người là nổi bật với óc sáng tạo linh hoạt. Không có một giới hạn nào cho các giá trị tốt đẹp mà con người có thể tạo ra. Và sự tử tế cũng vậy. Nó là một phẩm chất tốt mà mỗi nhà tuyen dung it cần gợi nhắc; giúp nó bật lên được trong tính cách mỗi nhân viên. Sự tử tế có thể giúp bạn tiến xa trong nghề nghiệp.
Thiếu đi sự tử tế, sợi dây định hướng về nhân cách cua bạn sẽ có ngày bị biến dạng. Nếu cá nhân người lãnh đạo có sức ảnh hưởng, dùng tiếng nói và cách hành xử của mình để thuyết phục được nhân viên, đó là một dấu hiệu đáng mừng!
Nhiều nhà quản trị nhân sự họ đã quan tâm đến vấn đề này. Đó là lý do tại sao nhân viên họ ngày càng nhiều nhân viên họ quan tâm nhau nhiều hơn. Chính sự tư tế đã giúp họ thay đổi tích cực.
Yêu bản thân
Nếu bạn không biết yêu thương chính mình thì quả thật là một điều đáng tiếc. Mỗi cá nhân nhân sự dù chính thức hay freelancer it đều cần phải biết quan tâm đến chính mình. Đó có thể là về vấn đề sức khỏe, tâm lý, bồi dưỡng tâm hồn,…
Nếu là người đứng đầu tổ chức, bạn không khác gì người anh lớn đang làm gương cho các em mình.
Do vậy, hãy đảm bảo một chế độ luyện tập lành mạnh. Đồng thời, thực hiện một chu trình làm việc gắn liền với những thói quen tốt. Có như vậy, bạn và cả nhân viên sẽ luôn duy trì được nguồn năng lượng tràn đầy trong công việc lẫn cuộc sống cá nhân.
Hãy thật sự quan tâm đến thể trạng của chính bạn. Cả lãnh đạo nhân sự và nhân viên cần rèn luyện hiệu quả. Kết quả công việc quan trọng. Nhưng trạng thái sức khỏe – tinh thần vẫn quan trọng hơn. Chăm sóc tốt nó, bạn sẽ không phải e ngại bất kỳ một thách thức khó khăn nào.
Bài viết được sự cho phép của tác giả Edward Thiên Hoàng
REDUNDANCY
Là phương thức sao lưu các dữ liệu quan trọng của hệ thống với mục đích tăng độ tin cậy (Reliability) của hệ thống. Ví dụ dữ liệu được lưu trên duy nhất một Server, nếu Server đó mất có nghĩa là tất cả dữ liệu đó mất, do đó việc tạo ra các bản sao lưu là để giải quyết vấn đề này. Redundancy là một điều kiện để xóa bỏ những “single points of failure” và tạo ra các bản sao lưu lúc cần thiết, ví dụ ta có hai máy chủ Database đang chạy trên production và dữ liệu luôn được sao lưu đồng bộ giữa hai máy chủ, và nếu có một trong hai máy chủ bị down thì ta có thể failover sang máy chủ còn lại. Redundancy nó giống như duplicate lại node/server dùng cho mục đích back-up vậy.
Gần tương tự với với Redundancy là ta cũng tạo ra một bản sao lưu dữ liệu của Server chính (Master) sang Server backup (Slave), nhưng khác nhau cơ bản là Replication sẽ update dữ liệu giữa Master và Slave là luôn luôn giống nhau và mọi thời điểm (real time synchronization) để tăng độ tin cậy (reliability), đặc biệt là khả năng chịu lỗi của hệ thống (fault-tolerance) và khả năng truy cập (accessibility). Replication được sử dụng rộng rãi ở các CSDLQH (RDBMS) trong mô hình master/slave, dữ liệu giữa master-slave luôn luôn được đồng bộ, trong trường hợp master down thì slave sẽ lên thay master sau khi master vừa down sống dậy nó sẽ trở thành slave mà sẽ thực hiện đồng bộ dữ liệu chưa được update trong thời gian nó bị down.
Một phần quan trọng nhưng thường xuyên bị đánh giá thấp trong việc phát triển phần mềm là Kiểm thử. Kiểm thử, từ trong định nghĩa, đã là một thách thức. Nếu một con bug là dễ dàng tìm thấy, nó sẽ không xuất hiện trên phiên bản đang phát triển, chứ chưa nói đến phiên bản dành cho kiểm thử. Một kỹ sư kiểm thử cần phải think-out-the-box để có thể tìm được những con bug mà người khác bỏ qua. Trong nhiều trường hợp, nắm vững kiển thức nền tảng của hệ thống, cả nghiệp vụ lẫn kỹ thuật, là rất quan trọng cho việc kiểm thử một cách hiệu quả.
Trong các dự án mã nguồn mở, chất lượng sản phẩm được quyết định bởi sự đóng góp và hợp tác giữa nhiều nhà phát triển. Kiểm thử đơn vị, thành phần và dịch vụ thường được làm tự động một cách hiệu quả. Điều này cho phép dự án có thể tiến về phía trước kể cả khi có quá nhiều sự đóng góp. Kiểm thử tự động một cách toàn diện cả chiều rộng và chiều sâu sẽ tăng tính ổn định cho sản phẩm/dự án.
Ngược với dự án mã nguồn mở được xây dựng bằng cách sử dụng sự đóng góp của nhiều người, không có sự liên kết chặt chẽ, mô hình dự án DevOps có thể theo cách tiếp cận Scrum hoặc Kanban mà ở đó, sự phát triển và phát hành sản phẩm là đồng thời và liên tục. Quá trình này phụ thuộc nhiều vào tính toàn diện và liên tục của việc kiểm thử tự động. Bất cứ khi nào có một phiên bản mới (thậm chí là một thay đổi nhỏ trong một tập tin mã nguồn), hệ thống kiểm thử cũng cần kiểm tra rằng hệ thống vẫn hoạt động. Đồng thời, bản thân những mã kiểm thử tự động, kể cả những mã kiểm thử dùng cho kiểm thử giao diện, cũng phải hoạt động chính xác.
Tháp kiểm thử, đề xuất bởi Mike Cohn trong quyển sách của ông, Succedding with Agile, đặt kiểm thử giao diện như là phần nhỏ nhất của quá trình kiểm thử. Hầu hết các kiểm thử nên được tập trung ở mức độ kiểm thử đơn vị và kiểm thử thành phần. Như vậy, việc thiết kế kịch bản kiểm thử dễ dàng hơn, và tự động hóa việc kiểm thử ở mức độ đơn vị hay thành phần/dịch vụ cũng dễ hơn và ổn định hơn.
Tôi đồng ý rằng đây là một chiến lược tốt. Tuy nhiên, từ những gì tôi quan sát được từ nhiều dự án khác nhau, kiểm thử giao diện cũng là một phần quan trọng. Trong thế giới web, ví dụ, các chức năng của các công nghệ như Ajax hay AngularJS cho phép các kỹ sư phát triển tạo ra các trải nghiệm người dùng thú vị và đầy tính tương tác, mà nhiều phần của hệ thống cần phải được kiểm thử chung với nhau. Một ví dụ khác về giao diện là các ứng dụng một trang (single-page application), nơi mà toàn bộ, hay hầu hết, các chức năng của ứng dụng được mang ra cho người dùng ở trên một trang duy nhất. Sự phức tạp của giao diện là một sự thách thức cho kiểm thử tự động hơn hẳn mô hình client-server truyền thống.
Do đó, tôi thích để nhiều không gian kiểm thử ở trên đỉnh hơn, như hình dưới đây:
Ngay cả với kiểm thử giao diện, mặt kỹ thuật cũng khá là đơn giản. Với những công cụ kiểm thử, ví dụ như công cụ mã nguồn mở như Selenium hay công cụ thương mại TestArchitect của chúng tôi, chúng ta có thể tương tác với giao diện, giả lập các hành vi của người dùng trên hệ thống/ứng dụng. Kiểm thử giao diện cũng có thể pha trộn thêm các loại kiểm thử không giao diện khác như kiểm thử dịch vụ API hay truy vấn dữ liệu SQL.
Vấn đề của kiểm thử giao diện xuất hiện chính là ở giao đoạn bảo trì – maintainance. Chỉ một thay đổi nhỏ ỡ giao diện hay hành vi người dùng có thể ảnh hưởng một số lượng lớn số lượng kịch bản kiểm thử tự động tương tác với nó. Lý do cơ bản là thành phần giao diện không còn tồn tại hay những khoảng thời gian chờ đợi không mong muốn để một nghiệp vụ được hoàn thành, những yêu cầu mới để hoàn thành một nghiệp vụ. Việc bỏ qua các lý do đó sẽ làm cho việc tự động hóa khó có thể thành công.
Bài viết được sự cho phép của tác giả Nguyễn Hữu Đồng
Vào một ngày đẹp trời, đang ngồi code lan man mình nhận được thông báo từ xếp, một con service tracking của một project cũ đang gây nghẽn database, chuyện là cty đó đang ăn nên làm ra traffic vô site tăng gấp 15 lần, user tương tác nhiều dẫn đến các con service khác cũng tải nhiều hơn, db thì càng ngày càng bị hấp diêm nhiều hơn, ko chỉ đến từ còn service tracking mà còn đến từ nhiều con khác.
Tracking thì ngàytrước mình code theo mô hình đơn giản, Client gọi API, đẩy message vào 1 cái queue, có tầm 100 con consumer ngồi hốt message ra process rồi ghi vô database.
Nhưng đến nước này thì chỉ có thể giảm tải cho database bằng cách giảm số lượng con consumer xuống, hạn chế tải đồng thời cho database. Trước kia code vô nhân đạo nên mình ko handle chuyện cần restart lại App thì mới update config. Tranh thủ lúc đang nhàn rỗi, mấy dự án đang ngồi chờ chốt requirement nên tranh thủ update sửa cho em nó.
Nhu cầu cần thiết lúc này là
Chỉ cần update file config là app tự động update số consumer
Khi deploy new code thì phải graceful shutdown, chờ mỗi consumer xử lí xong message và cho em nó nghỉ ngơi.
Viper có sẵn tính năng watch config file nên mình sẽ dùng luôn
func watchConsumerCount() {
viper.WatchConfig()
viper.OnConfigChange(func(e fsnotify.Event) {
fmt.Println("Config file changed:", e.Name)
n := viper.GetInt("consumer_count")
if n != consumer_count {
fmt.Println("resize consumer count to => ", n)
go ResizeConsumerCount(n)
}
})
}
Khi config có sự thay đổi thì nếu là thay đổi giá trị số consumer thì mình tiến hành chạy function ResizeConsumerCount để update lại số lượng consumer
Để quản lí mỗi consumer sẽ thì mình có cái slice mỗi phần từ có type như sau
type ConsumerRoutine struct {
Id int // ID của consumer
Exit chan bool // Channel để nhận lệnh exit
Channel *amqp.Channel // AMQP channel
Delivery <-chan amqp.Delivery // AMQP delivery chan,để nhận message từ queue
Done chan bool // Channel báo cáo lên thằng quản lí tao xong hết rồi, chuẩn bị thoát
}
Mỗi consumer khi chạy sẽ ôm cái biến này để giao tiếp với thằng quản lí.
Khởi tạo consumer và các thần phần cần thiết khác.
Bắt đầu tạo consumer, mỗi consumer sẽ được chạy trong 1 goroutine và update tình trạng vào cái biến mà nó đươc giao
func startNewConsumer(m *ConsumerRoutine) {
m.Exit = make(chan bool)
m.Done = make(chan bool)
m.Channel, _ = amql_conn.Channel()
m.Channel.QueueDeclare(queue_name, true, false, false, false, nil)
m.Delivery, _ = m.Channel.Consume(queue_name, "", false, false, false, false, nil)
fmt.Println("Consumer : ", m.Id, "started")
for {
select {
case <-m.Exit: // Lắng nghe lệnh exit từ bên ngoài
m.Channel.Close() // Đóng amqp channel
m.Channel = nil
m.Done <- true // Báo cáo là sẵn sàng thoát
fmt.Println("Consumer ", m.Id, " ended")
return
case msg := <-m.Delivery: // Chờ message từ queue
// Xử lí message ở đây
fmt.Println("Consumer ", m.Id, "recived message = ", string(msg.Body))
// Ack hoặc Reject message, ở đây để luôn có data test nên mình reject luôn :pikatroll:
msg.Reject(true)
}
}
}
Mỗi khi chạy một con consumer mới thì nó sẽ lắng nghe lệnh exit từ bên ngoài thông qua channel m.Exit , nhận message từ queue qua channel m.Delivery . Có message thì sẽ xử lí khi nào xong thì nghe tiếp.
Đến lượt function thay đổi số lượng consumer
func ResizeConsumerCount(n int) {
// scale up
// Chỗ này thì thêm phần từ vô slice và sau đó thì chạy một con
// consumer và truyền biến vào để giao tiếp
if n >= consumer_count {
val := consumer_count
consumer_count = n
for i := val; i < n; i++ {
consumer[i] = &ConsumerRoutine{
Id: i,
Exit: make(chan bool),
Done: make(chan bool),
}
go startNewConsumer(consumer[i])
}
return
}
// scale down
// Giả sự số lượng hiện tại là consumer_count
// và số consumer sau khi giảm là n thì mình sẽ
// gửi lệnh exit cho những con consumer từ n->val-1
// vì slice được đếm từ 0
val := consumer_count
consumer_count = n
for i := n; i < val; i++ {
fmt.Println("shuting down consumer : ", i)
go func(m *ConsumerRoutine) {
fmt.Println("Exit Chan Pointer = ", &m.Exit)
m.Exit <- true
}(consumer[i])
<-consumer[i].Done
}
}
Và function main nơi mà mọi thứ bắt đầu.
func main() {
// Mình chạy consumer_count con consumer từ file config
for i := 0; i < consumer_count; i++ {
consumer[i] = &ConsumerRoutine{
Id: i,
}
go startNewConsumer(consumer[i])
}
// khởi tạo 1 channel để lắng nghe signal
stop := make(chan os.Signal, 1)
signal.Notify(stop)
for {
v := <-stop
fmt.Println("SIGNAL : ", v.String())
// nếu signal là hangup thì mình sẽ tắt hết consumer và thoát app
if v.String() == "hangup" {
ResizeConsumerCount(0)
os.Exit(0)
}
}
}
➜ resizeConsumer go build && ./rc
Consumer : 0 started Exit pointer val = 0xc00019a018
Consumer : 1 started Exit pointer val = 0xc00019a058
SIGNAL : urgent I/O condition
SIGNAL : urgent I/O condition
SIGNAL : urgent I/O condition
SIGNAL : urgent I/O condition
SIGNAL : urgent I/O condition
Config file changed: /Users/vimftw/Desktop/code/resizeConsumer/config.yaml
resize consumer count to => 1
shuting down consumer : 1
Exit Chan Pointer = 0xc00019a058
have to exit now
Consumer 1 ended
shuting down consumer : 2
Exit Chan Pointer = 0xc00005a718
have to exit now
Consumer 2 ended
shuting down consumer : 3
Exit Chan Pointer = 0xc00005a758
have to exit now
Consumer 3 ended
SIGNAL : urgent I/O condition
SIGNAL : urgent I/O condition
Thử tắt luôn con app
SIGNAL : urgent I/O condition
SIGNAL : urgent I/O condition
SIGNAL : hangup
shuting down consumer : 0
Exit Chan Pointer = 0xc00019a018
have to exit now
Consumer 0 ended
Bài viết được sự cho phép của tác giả Kien Dang Chung
Hiện nay, thương mại điện tử đang đạt đến đỉnh cao, rất nhiều các chương trình được đưa ra nhằm tăng doanh số bán hàng, quảng bá sản phẩm mạnh mẽ hơn. Một trong những cách thức đó là các chương trình giới thiệu bán hàng (referral system), nó giống như mô hình truyền thống trong việc mở rộng các đại lý phân phối sản phẩm, tuy nhiên có một điểm khác biệt là các đại lý truyền thống cần có sản phẩm để bán thì với chương trình này, đại lý chỉ việc giới thiệu các sản phẩm, dựa trên uy tín của mình, đại lý có thể giới thiệu được nhiều sản phẩm và có thu nhập tốt.
Các chương trình giới thiệu bán hàng đã tận dụng được lợi thế về quảng bá trên Internet giúp bạn nhanh chóng mở rộng được đại lý bán hàng, tuy nhiên bạn cũng phải thường xuyên tạo ra các chương trình chia sẻ lợi nhuận hấp dẫn, thiết kế các mẫu quảng bá thu hút người xem (hoặc do các đại lý thiết kế) và quan trọng hơn nữa là thường xuyên tạo ra các chương trình chi ân nhằm giữ chân khách hàng lâu dài. Như vậy, có thể thấy Referral là hệ thống quan trọng đối với một website bán hàng, với các website khác áp dụng hệ thống referral cũng là cách tốt để có được lượng traffict lớn ngoài các thành viên thường xuyên.
Trong mô hình trên, bạn có thể thấy tất cả các đối tượng tham gia đều được hưởng lợi:
Người giới thiệu (hay còn gọi là đại lý): sẽ nhận được hoa hồng khi giao dịch thành công.
Người được mời (người mua): nhận được các chương trình giảm giá, chương trình chi ân khách hàng từ hệ thống. Các hệ thống bán hàng có thể giảm giá tốt hơn với các khách hàng tiềm năng này.
Nhà phân phối (có hệ thống giới thiệu bán hàng – referral system): tăng doanh số bán hàng, tiếp cận được nhiều khách hàng tiềm năng.
Xây dựng hệ thống giới thiệu bán hàng – referral system trong ứng dụng Laravel
Bước 1: Tạo các bảng liên quan trong CSDL
Chúng ta sẽ tạo ra hai bảng referral_programs và referral_links:
c:\xampp\htdocs\laravel-test>php artisan make:migration create_referral_programs_table --create=referral_programs
Created Migration: 2017_04_24_075438_create_referral_programs_table
c:\xampp\htdocs\laravel-test>php artisan make:migration create_referral_links_table --create=referral_links
Created Migration: 2017_04_24_075503_create_referral_links_table
c:\xampp\htdocs\laravel-test>php artisan make:migration create_referral_relationships_table --create=referral_relationships
Created Migration: 2017_04_24_081042_create_referral_relationships_table
Thêm nội dung tạo các bảng liên quan, với file 2017_04_24_075438_create_referral_programs_table:
<?phpuseIlluminate\Support\Facades\Schema;useIlluminate\Database\Schema\Blueprint;useIlluminate\Database\Migrations\Migration;classCreateReferralProgramsTableextendsMigration{/**
* Run the migrations.
*
* @return void
*/publicfunctionup(){Schema::create('referral_programs',function(Blueprint $table){$table->increments('id');$table->string('name');$table->string('uri');$table->integer('lifetime_minutes')->default(7*24*60);$table->timestamps();});}/**
* Reverse the migrations.
*
* @return void
*/publicfunctiondown(){Schema::dropIfExists('referral_programs');}}
Với file 2017_04_24_075503_create_referral_links_table:
<?phpuseIlluminate\Support\Facades\Schema;useIlluminate\Database\Schema\Blueprint;useIlluminate\Database\Migrations\Migration;classCreateReferralLinksTableextendsMigration{/**
* Run the migrations.
*
* @return void
*/publicfunctionup(){Schema::create('referral_links',function(Blueprint $table){$table->increments('id');$table->integer('user_id')->unsigned();$table->integer('referral_program_id')->unsigned();$table->string('code',36)->index();$table->unique(['referral_program_id','user_id']);$table->timestamps();});}/**
* Reverse the migrations.
*
* @return void
*/publicfunctiondown(){Schema::dropIfExists('referral_links');}}
Thêm nội dung tạo referral_relationships:
<?phpuseIlluminate\Support\Facades\Schema;useIlluminate\Database\Schema\Blueprint;useIlluminate\Database\Migrations\Migration;classCreateReferralRelationshipsTableextendsMigration{/**
* Run the migrations.
*
* @return void
*/publicfunctionup(){Schema::create('referral_relationships',function(Blueprint $table){$table->increments('id');$table->integer('referral_link_id');$table->integer('user_id');$table->timestamps();});}/**
* Reverse the migrations.
*
* @return void
*/publicfunctiondown(){Schema::dropIfExists('referral_relationships');}}
Tiếp theo thực hiện tạo hai bảng này bằng lệnh php artisan migrate
Sử dụng câu lệnh artisan make:model để tạo ba model là ReferralProgram, ReferralLink và ReferralRelationship
c:\xampp\htdocs\laravel-test>php artisan make:model ReferralProgram
Model created successfully.
c:\xampp\htdocs\laravel-test>php artisan make:model ReferralLink
Model created successfully.
c:\xampp\htdocs\laravel-test>php artisan make:model ReferralRelationship
Model created successfully.
Trong project này chúng ta sẽ sử dụng package ramsey/uuid là một thư viện làm việc với Universally Unique Identifiers (UUID) tương thích với tiêu chuẩn RFC 4122 phiên bản 1, 3, 4 và 5. Thực hiện cài đặt vào dự án bằng lệnh composer.
c:\xampp\htdocs\laravel-test>composer require ramsey/uuid
Using version ^3.6for ramsey/uuid
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations:0 installs,1 update,0 removals
- Updating ramsey/uuid (3.6.0=>3.6.1): Loading from cache
Writing lock file
Generating autoload files
>Illuminate\Foundation\ComposerScripts::postUpdate
> php artisan optimize
Generating optimized classloader
The compiled services file has been removed.
Ngoài ra chúng ta cần cài đặt thêm gói moontoast/math được sử dụng trong các thuật toán của ramsey/uuid:
c:\xampp\htdocs\laravel-test>composer require moontoast/math
Using version ^1.1for moontoast/math
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations:1 install,0 updates,0 removals
- Installing moontoast/math (1.1.2): Downloading (100%)
Writing lock file
Generating autoload files
>Illuminate\Foundation\ComposerScripts::postUpdate
> php artisan optimize
Generating optimized classloader
The compiled services file has been removed.
<?phpnamespaceApp;useIlluminate\Database\Eloquent\Model;useRamsey\Uuid\Uuid;classReferralLinkextendsModel{protected$fillable=['user_id','referral_program_id'];protectedstaticfunctionboot(){static::creating(function(ReferralLink $model){$model->generateCode();});}privatefunctiongenerateCode(){$this->code=(string)Uuid::uuid1();}publicstaticfunctiongetReferral($user,$program){returnstatic::firstOrCreate(['user_id'=>$user->id,'referral_program_id'=>$program->id]);}publicfunctiongetLinkAttribute(){returnurl($this->program->uri).'?ref='.$this->code;}publicfunctionuser(){return$this->belongsTo(User::class);}publicfunctionprogram(){ // TODO: Check if second argument is requried
return$this->belongsTo(ReferralProgram::class,'referral_program_id');}publicfunctionrelationships(){return$this->hasMany(ReferralRelationship::class);}}
Tiếp theo chúng ta cần giám sát các đường link có tham số ref và lưu chúng vào cookie, như vậy mỗi khi có một hành động nào đó của người dùng chúng ta có thể biết và tặng quà cho cả hai bên tham gia. Để thực hiện được việc này chúng ta tạo ra một middleware (Xem thêm Laravel middleware).
c:\xampp\htdocs\laravel-test>php artisan make:middleware StoreReferralCode
Middleware created successfully.
và thay đổi nội dung app\Middlewares\StoreReferralCode.php như sau:
Phương thức handle() của middleware StoreReferralCode sẽ thực hiện kiểm tra tất cả các request nếu có tham số ref sẽ tìm kiếm
Bước 4: Tạo Event và Listener quản lý các hành động người dùng
Khi hành động như mong muốn được người dùng thực hiện (ở đây là đăng ký tài khoản mới), chúng ta thực hiện tạo ra một event và dùng listener để bắt sự kiện đó, trong listener sẽ thực hiện tặng thưởng cho người dùng. Thêm cấu hình vào EventServiceProvider.php trong thư mục app\Providers:
Sau đó sử dụng lệnh artisan event:generate để tự động tạo ra Event và Listener (Xem thêm Quản lý sự kiện với Laravel Event để hiểu hơn về câu lệnh này):
c:\xampp\htdocs\laravel-test>php artisan event:generate
Events and listeners generated successfully!
Thay đổi nội dung của Event app\Events\UserReferred.php:
<?phpnamespaceApp\Events;useIlluminate\Broadcasting\Channel;useIlluminate\Queue\SerializesModels;useIlluminate\Broadcasting\PrivateChannel;useIlluminate\Broadcasting\PresenceChannel;useIlluminate\Foundation\Events\Dispatchable;useIlluminate\Broadcasting\InteractsWithSockets;useIlluminate\Contracts\Broadcasting\ShouldBroadcast;classUserReferred{useDispatchable, InteractsWithSockets, SerializesModels;public$referralId;public$user;/**
* Create a new event instance.
*
* @return void
*/publicfunction__construct($referralId,$user){$this->referralId=$referralId;$this->user=$user;}/**
* Get the channels the event should broadcast on.
*
* @return Channel|array
*/publicfunctionbroadcastOn(){returnnewPrivateChannel('channel-name');}}
Thêm nội dung của app\Listener\RewardUser.php:
<?phpnamespaceApp\Listeners;useApp\Events\UserReferred;useIlluminate\Queue\InteractsWithQueue;useIlluminate\Contracts\Queue\ShouldQueue;classRewardUser{/**
* Create the event listener.
*
* @return void
*/publicfunction__construct(){ //
}/**
* Handle the event.
*
* @param UserReferred $event
* @return void
*/publicfunctionhandle(UserReferred $event){$referral= \App\ReferralLink::find($event->referralId);if(!is_null($referral)){
\App\ReferralRelationship::create(['referral_link_id'=>$referral->id,'user_id'=>$event->user->id]); // Tặng thưởng cho cả người share link và người sử dụng link
if($referral->program->name==='Bonus Credits'){ // Người chia sẻ link
$provider=$referral->user;$provider->addCredits(15); // Người sử dụng link
$user=$event->user;$user->addCredits(20);}}}}
Ok, tiếp theo chúng ta sẽ tạo ra một event app\Events\UserReferred.php khi người dùng đăng ký bằng cách can thiệp vào phương thức create() của RegisterController.php nằm trong app\Http\Controllers\Auth:
/**
* Create a new user instance after a valid registration.
*
* @param array $data
* @return User
*/protectedfunctioncreate(array$data){$user=User::create(['name'=>$data['name'],'email'=>$data['email'],'password'=>bcrypt($data['password'])]);event(new\App\Events\UserReferred(request()->cookie('ref'),$user));return$user;}
Tạo view referral.blade.php trong resources/views/fontend:
@extends('layouts.default')
@section('title','Referral system - Allaravel.com')
@section('content')
@forelse(auth()->user()->getReferrals()as$referral)<h4>
Chương trình:{{$referral->program->name}}</h4><code>
Referral link:{{$referral->link}}</code><p>
Số user sử dụng referral link:{{$referral->relationships()->count()}}</p>
@empty
Không có chương trình referral nào!
@endforelse
@endsection
Thêm menu Referral System vào resources/views/layouts/menu.php:
Trước khi đi vào kiểm tra hoạt động hệ thống referral, chúng ta cùng xem qua luồng hoạt động của nó.
Các bước thực hiện kiểm thử cũng sẽ tuân thủ theo hoạt động mô tả ở luồng hoạt động hệ thống ở trên: Đầu tiên, đăng nhập vào hệ thống laravel.dev tại http://laravel.dev/login, sau khi đăng nhập chuyển sang menu Ví dụ->Referral System. Nhưng trước tiên chúng ta cần tạo ra một chương trình giới thiệu bán hàng trước đã do hiện tại bảng referral_programs đang chưa có bản ghi nào. Sử dụng Laravel Tinker để nhập nhanh một bảng ghi (Nếu bạn chưa biết Tinker là gì xem thêm Công cụ debug và kiểm thử trong Laravel):
Như vậy, thành viên này đã có referral link, thành viên này muốn kiếm tiền có thể đưa đường dẫn này vào bất kỳ đâu: – Mạng xã hội Facebook, Google Plus, Twitter, Github…
Website: Blog, trang tin tức…
Email: Gửi email trong nội dung có đường dẫn này.
…
Bất kỳ ai khi thực hiện click vào đường dẫn này, hệ thống sẽ ghi xuống máy tính của họ một cookie chứa id bản ghi trong referral_links, cookie này có thời gian hoạt động mặc định là 7 ngày, do trong phần tạo bảng referral_programs chúng ta để là:
Trong khoảng thời gian này, nếu người dùng trên thực hiện đăng ký tài khoản, referral system sẽ biết do đã cài đặt các Event và Listener. Khi đó tùy thuộc vào chương trình giới thiệu bán hàng chúng ta sẽ xử lý trả thưởng cho cả người chia sẻ link và người dùng link trong phương thức hanlde() của Listener.
/**
* Handle the event.
*
* @param UserReferred $event
* @return void
*/publicfunctionhandle(UserReferred $event){$referral= \App\ReferralLink::find($event->referralId);if(!is_null($referral)){
\App\ReferralRelationship::create(['referral_link_id'=>$referral->id,'user_id'=>$event->user->id]); // Tặng thưởng cho cả người share link và người sử dụng link
if($referral->program->name==='Bonus Credits'){ // Người chia sẻ link
$provider=$referral->user;$provider->addCredits(15); // Người sử dụng link
$user=$event->user;$user->addCredits(20);}}}
Để kiểm tra các công đoạn này, chúng ta mở một trình duyệt khác và dán vào đường dẫn referral ở trên (Trong bài viết này, người chia sẻ link dùng Chrome, người dùng link sử dụng Firefox):
Khi thực hiện đăng ký xong, quay trở lại với người chia sẻ link chúng ta sẽ thấy số lượng người sử dụng link tăng lên:
Ok, như vậy referral system của chúng ta đã hoạt động tốt. Với khung ứng dụng này, chúng ta hoàn toàn có thể thực hiện các hệ thống referral với các sự kiện phức tạp hơn.
Chắc hẳn ai trong chúng ta cũng đều mong muốn trải nghiệm tại các công ty có môi trường thoải mái. Đơn giản vì đó là môi trường tốt bạn học hỏi nhiều hơn. Khi tuyen dung it da nang, nhiều ứng viên cũng quan tâm đến vấn đề này. Tuy nhiên, bạn nên cẩn trọng trước những phát ngôn để không vạ miệng trước cấp trên của bạn. Và điều đó cũng cho thấy kỹ năng giao tiếp rất quan trọng. Cùng TopDev khám phá xem đâu là 5 phát ngôn cần tránh nhé!
1. “Tôi bắt đầu hơi chán vì quá tải”
Áp lực công việc là điều hiển nhiên tồn tại khi bạn quyết định đồng hành cùng công việc nào đó một cách lâu dài. Áp lực đôi khi làm bạn mệt mỏi. Thế nhưng, thực tếchính nó tạo nên động lực giúp bạn khám phá ra được giới hạn về năng lực của chính mình.
Một điều quan trọng nữa, môi trường văn phòng là nơi làm việc chứ không phải nơi bạn kêu ca.
Mọi thứ cần phải chuyên nghiệp và tuân thủ theo nguyên tắc. Nếu công việc quá tải, bạn nên xem xét lại các đầu công việc; sắp xếp theo thứ tự; cân bằng lại thời gian biểu của mình.
Đừng mãi phàn nàn và đổ lỗi cho hoàn cảnh! Cũng đừng biện hộ vì điều đó sẽ khiến người khác đánh giá thấp bạn. Thay vì phát ngôn như vậy, bạn nên tự nỗ lực giải quyết nó.
Hãy suy nghĩ đơn giản hơn, xem những áp lực như một thách thức mà bạn cần phải vượt qua; cố gắng tìm ra giải pháp hoặc đề xuất những cải tiến công việc để nhận lời khuyên và sự hỗ trợ từ người quản lý. Khi tuyen dung it da nang, bạn nên lường trước những vấn đề này chuẩn bị tinh thần cho nó.
2. “Nếu không tăng lương, tôi sẽ nghỉ việc”
Cách bạn nói như vậy không tạo ra sự đe dọa với sếp dù bạn nghĩ rằng nó sẽ thành công. Phát ngôn ấy có thể khiến bạn bị loại khỏi cuộc chơi nghề nghiệp.
Trong tuyen dung it da nang, freelancer it, việc tuyển dụng và đánh giá lại quá trình làm việc của bạn sẽ được diễn ra định kỳ. Thậm chí còn rất cạnh tranh. Thế nên, dù bạn có “ngỏ ý” muốn nghỉ việc trong bất kỳ trường hợp, công ty sẽ không e ngại điều gì mà có thể từ chối bạn ngay lập tức. Và tất nhiên, một lá đơn xin nghỉ việc không cần phải xảy ra nữa. Bởi lẽ, cuộc chơi nghề nghiệp không dành cho những kẻ chỉ biết cho bản thân.
3. “Chúng tôi đã luôn xử lý vấn đề theo cách này…”
Bản thân mọi nhà tuyen dung it da nang rất khuyến khích và mong muốn nhân viên của mình tham gia vào cuộc đối thoại cởi mở. Lúc đó họ có thể đưa ra những ý tưởng hay. Tuy nhiên, câu nói “chúng tôi đã luôn xử lý vấn đề theo cách này…” là điều không một người đứng đầu doanh nghiệp hay tổ chức nào muốn nghe cả. Bạn phải luôn lưu tâm kỹ năng giao tiếp thật sự cần thiết.
Thật ra, phát ngôn này đôi khi bắt nguồn từ cá tính nhân viên; từ năng lực biểu lộ sự tự tin và niềm tin về năng lực kỹ năng giao tiếp bản thân. Tuy nhiên, điều này dường như trái ngược với các giá trị cốt lõi về trách nhiệm, sự minh bạch, văn hóa làm việc chung tại tổ chức.
4. “Tôi không muốn làm việc cùng anh A/chị B/bạn C”
Những mâu thuẫn cá nhân là điều khó tránh khỏi ở môi trường công sở.
Điều quan trọng là làm thế nào để giải quyết chúng để có được tiếng nói chung. Sẽ là một sai lầm lớn nếu bạn than vãn điều này với sếp của mình. Bạn cần biết rằng, để có thể phát triển xa hơn trong nghề nghiệp bạn cần phải làm việc; trao đổi với nhiều đồng đội khác nhau.
Không một người thành công nào lại không biết cách giải quyết xung đột. Vì vậy, nếu có bị “đánh bay” khỏi công việc, bạn cũng đừng thắc mắc vì khả năng nghề nghiệp của bạn thật sự chưa toàn diện.
Điều quan trọng là bạn phải cố gắng hoặc tập cách làm việc theo nhóm để đáp ứng được nhu cầu công việc. Bạn không nên vội từ bỏ khi đã quá quen làm việc độc lập. Nếu có khó khăn với đồng nghiệp, bạn nên chia sẻ với sếp. Cụ thể đó là mong muốn của bản thân. Đừng để những đánh giá cảm tính, chủ quan của bạn làm ảnh hưởng đến sự nghiệp của bạn.
5. “Đó không phải việc của tôi”
Phát ngôn này được cho là tạo ra sự khó xử với chính người cấp trên của bạn.
Ngay cả khi đó không phải công việc của bạn, nhà quản lý không bao giờ muốn nghe bạn thẳng thắn từ chối. Bạn có thể kiệt sức vì quá tải công việc, nhưng điều đó là không thể chấp nhận được ở góc độ nhà quản lý. Nghe có vẻ khó khăn, nhưng điều đó thể hiện sự thiếu chuyên nghiệp và tinh thần không hợp tác trong công việc.
Rõ ràng, bạn hoàn toàn có thể lựa chọn một cách trả lời khôn ngoan hơn. Vậy tại sao bạn lại không thử?
Khi được hỏi một công việc không liên quan đến bạn, hãy giữ thái độ cởi mở. Nhà quản lý sẽ rất vui khi thấy một tập thể cân bằng và hỗ trợ lẫn nhau. Do đó, hãy thể hiện rằng bạn sẵn sàng giúp đỡ họ bất cứ lúc nào.
Lời kết
Ranh giới giữa người quản lý và nhân sự luôn tồn tại. Nhưng chẳng có sếp nào muốn xa lánh nhân viên mà không có lý do cả. Vì thế, hãy cẩn trọng và tinh hết trong mọi phát ngôn. Hãy là một nhân viên chuyên nghiệp nhất trong kỹ năng giao tiếp của mình.
Bài viết được sự cho phép của tác giả Edward Thiên Hoàng
Proxy server là một server trung gian (intermediary) nằm giữa client và back-end server. Client kết nối với proxy server để yêu cầu (request) những dịch vụ (service) cần thiết như API, web page, file hay connection, v.V… Nói tóm lại, proxy server là một phần của hệ thống phần mềm hoặc phần cứng đóng vai trò trung gian kết nối các yêu cầu từ client tới các thành phần khác trong hệ thống.
Proxy được sử dụng chủ yếu để lọc hoặc ghi log các yêu cầu (filter request, log request) hoặc để thay đổi các request (như thêm hoặc xóa các header, mã hóa/giải mã hay nén các resource). Hoặc một ứng dụng rất hữu ích khác là dùng để cache response rồi trả về cho nhiều request cùng loại, như trong trường hợp nhiều client request tới cùng một resource thì Proxy có thể cache resource đó rồi trả về cho các client mà không cần gọi tới các “remote server” khác.
Mô hình Proxy Server hoạt động
CÁC KIỂU PROXY SERVER
Open Proxy
Một Open Proxy Server là một máy chủ mà bất kỳ người dùng Internet nào cũng có thể truy cập. Thông thường nó thường được sử dụng để kiểm xoát băng thông hoặc lưu và chuyển tiếp các dịch vụ mạng như DNS hoặc các dịch vụ Web của một nhóm người dùng sử dụng chung Open Proxy đó. Có hai loại Open Proxy là
+ Proxy ẩn danh (Anonymous Proxy): Proxy server này có thể che dấu các IP thật của các user sử dụng nó khỏi các dịch vụ nó truy cập đến. Proxy ẩn danh có tác dụng tăng độ bảo mật cho người dùng vì địa chỉ IP thực của người dùng có thể được sử dụng để truy dẫn ra thông tin về người dùng và để thâm nhập vào máy tính của người đó. Hoặc dùng để vượt qua tường lửa của các tổ chức hoặc quốc gia Ngoài ra, proxy ẩn danh còn được dùng để lách qua sự kiểm duyệt Internet của các chính phủ hoặc tổ chức.
+ Proxy minh bạch (Trаnspаrent Proxy): Trái ngược với anonymous Proxy, thì proxy này cho phép các dịch vụ truy cập tới biết được IP thật của user bằng các HTTP header (ví dụ như X-Forwarded-For). Ưu điểm của Proxy này là khả năng cache response như website để tăng tốc độ kết nối mạng của những người dùng bên trong máy chủ Proxy.
Reverse Proxy
Reverse proxy là một proxy server mà khi đứng trước client, có tác dụng chuyển tiếp request đến một hoặc nhiều back-end server và nhận kết quả từ các server này rồi trả về phía client (forwarder), giúp che dấu danh tính của các back-end server bên dưới. Reverse proxy được cài đặt trong một private network của một hoặc nhiều server, và tất cả lưu lượng truy cập đều phải đi qua proxy này.
Thông thường, những server sẽ sử dụng cơ chế reverse proxy này để bảo vệ các ứng dụng có khả năng xử lý HTTP yếu kém hơn. Ví dụ như khả năng xử lý cực lớn các request, những hạn chế về xử lý sự đa dạng của các loại request (các dạng request có thể kể đến như: HTTP(S) 1.x, HTTP(S) 2.x, …) hay khả năng chuyển đổi HTTPS thành HTTP, cache request, xử lý dữ liệu của cookies/session, chia một request thành nhiều request nhỏ hơn rồi tổng hợp lại các response, …
Vì các task cần estimate thường là những task mới, mơ-hồ và có nhiều yếu tố không-xác-định xuất hiện trong suốt quá trình thực hiện. Tôi cảm thấy estimate giống như việc dự đoán tương lai, phải may mắn lắm mới có một kết quả chính xác. Việc này tương tự như trò ném phi tiêu trúng hồng tâm vậy… xác suất trúng là rất thấp! Tôi không thích suy nghĩ này. Để tránh những tổn thất sau mỗi lần release muộn, tôi bắt đầu tìm kiếm những đội khác cũng gặp phải vấn đề tương tự, tổng kết lại các phương pháp xử lý và lấy ra các giải pháp hiệu quả nhất.
Và đây là giải pháp mà anh em tổng kết lại “Sau khi estimate thời gian để hoàn thành một tính năng X, hãy x3 con số này lên. 😅”
Hiển nhiên, đây không phải là công thức estimate chính xác.
Trong quá trình tìm kiếm giải pháp cho vấn đề này, tôi đã học được một thứ đó là không hề có mẹo hay lối tắt để giải quyết vấn đề. Chúng ta cần thực hiện đầy đủ tuần tự các bước để có kết quả estimate chuẩn nhất.
Dưới đây là 4 bước mà tôi đã sử dụng để estimate cho các dự án của mình
Bước 1. Phân bổ thời gian dành cho việc estimate
Nếu bạn thực sự muốn đội của mình có thể đưa ra estimate chính xác nhất, cố gắng đừng bắt đầu câu chuyện bằng những câu kiểu như “tôi cần bạn hoàn thành toàn bộ các đầu việc này trước thời điểm X”.
Đưa ra thời điểm cần hoàn thành trước, rồi mới yêu cầu anh em estimate sẽ khiến cho việc estimate không còn đúng với lẽ tự nhiên. Kéo theo kết quả estimate sẽ không gần với thực tế.
Khi anh em dev bị giới hạn thời điểm deadline và liên tục bị giục hoàn thành việc estimate, mọi người sẽ khó có thể nhìn nhận các yếu tố phức tạp của bài toán để estimate, và sẽ estimate theo kiểu cố gắng làm hài lòng người quản lý là chính.
Do vậy, tốt hơn hơn là cho phép cả team một khoảng thời gian, tùy vào khối lượng của project để nhận ra được các vấn đề phức tạp tiềm ẩn và không đề cập tới hạn deadline của các tính năng trước khi estimate.
Việc này để để sau khi estimate xong, để quyết định xem có nên xóa một phải chức năng phức tạp quá hay không.
Bước 2. Chia nhỏ công việc thành các công việc con
Thông thường vào thời điểm bắt đầu dự án, bạn không có đủ thông tin chi tiết về tính năng phải làm. Do vậy, số ngày mà bạn estimate được thường không phản ánh đúng số ngày thực tế.
Tuy nhiên, nếu bạn chia nhỏ công việc cần estimate thành những công việc nhỏ hơn, bạn sẽ có khả năng nhìn thấy được cụ thể những bước cần phải. Do vậy, bạn sẽ estimate được chính xác hơn.
“Khi bạn còn chưa biết được cụ thể bạn sẽ làm những gì, bạn sẽ không thể biết khi nào bạn sẽ hoàn thành nó” –Joel Spolsky, Stack Overflow CEO
Nguyên tắc ở đây là bạn cứ tiếp tục chia nhỏ task cho đến khi thời gian estimate hoàn thành mỗi task nhỏ là từ 8-10h.
Bước 3. Phân loại task
Sau khi chia nhỏ công việc thành những công việc nhỏ hơn, bạn cần lùi lại một chút để nhìn được tổng thể những công việc sẽ phải làm. Bạn sẽ để ý thấy được có vô vàn những việc bạn có thể bắt tay vào làm luôn, một vài việc vẫn còn lờ mờ, và một vài việc vẫn có nhiều điều bí ẩn như là vùng tối phía bên kia của mặt trăng.
Cụ thể hơn, chúng ta có 3 loại công việc sau:
Task đã rõ những việc phải làm (Known Tasks)
Đây là những task mà bạn đã biết rõ input, output và cụ thể các bước cần phải làm để có được output. Do vậy thời gian estimate để hoàn thành công việc này là xác định.
Task mới chỉ rõ một phần những việc phải làm (Partially Known Tasks)
Đây là loại task mà bạn mới chỉ nắm được input, output và nắm được sơ bộ cách làm. Tuy nhiên bạn ước lượng sẽ mất chừng 15-30 phút để tìm hiểu thêm hoặc cần thêm sự trợ giúp từ những người đã gặp vấn đề tương tự để có thể hoàn thành được task.
Task không xác định (Unknown Tasks)
Thường những task này sẽ cần bạn dành khoảng vài giờ tới cả ngày để hiểu công nghệ mà bạn sẽ định sử dụng để hoàn thành task.
Hiếm có dự án nào mà DEV không cần phải học thêm một cái gì đó mới để có thể làm được. Việc phải học thêm các công nghệ mới để hoàn thành dự án là không thể tránh khỏi. Thông thường bạn sẽ cần phải tìm những công cụ, nền tảng API khác khau để giải quyết các bài toán. Do vậy, thời gian dành cho việc tìm hiểu hay nghiên cứu là yếu tố quan trọng cần phải được tính vào estimate.
Sau khi phân loại task, bạn cần cố gắng đặt mục tiêu tìm hiểu thêm về project để cố gắng chuyển task Partially Known Tasks và Unknown Tasks về loại Known Tasks
Bước 4. Estimate lại
Tới bước này, tất cả các task của bạn đã được chuyển thành Known Task, bạn đã có thêm nhiều thông tin cụ thể hơn cho công đoạn implement. Do vậy, kéo theo là kết quả estimate sẽ chính xác hơn.
Hãy quan sát biểu đồ sau để thấy được sự liên hệ giữa thời gian estimate và mức độ rõ ràng của các yêu cầu cũng như các giải pháp để thực hiện các yêu cầu.
Một ưu điểm của bước này là bạn có cơ hội xem lại các yêu cầu, có cái nhìn tổng quan hơn. Và sẽ có thể phát hiện ra những vấn đề mà ở các bước trước bạn chưa kịp nhìn ra. Một điểm chú ý ở đây là, mỗi khi bạn có thêm thông tin gì mới về project, bạn nên estimate lại để có con số chính xác nhất.
Hãy chú ý 4 thứ sau trong khi bạn đang estimate project
Điều 1. Lưu ý những câu có từ “Chỉ” – “Just”
Có một luật bất thành văn là thường những task có nhiệm vụ “Chỉ” làm một tính năng nào đó lại là những task tốn kém nhất.
Task này chỉ nhỏ như con muỗi ấy mà!
Chắc chỉ mất 5 phút để fix lỗi thôi
Chắc task này không chiếm quá 15 phút đâu.
Những task này ban đầu nhìn có vẻ tốn ít thời gian, nhưng té ra lại thường là loại task tốn kém nhất khiến team trễ deadline.
Nguyên nhân chính khiến những loại task này chiếm nhiều thời gian hơn mong đợi là chúng thường xuất hiện từ các cuộc họp stand-up meeting hàng ngày hoặc qua những cuộc trò chuyện giữa mọi người. Khi DEV không có đủ thời gian để xem xét độ phức tạp của task, họ sẽ đánh giá thấp độ phức tạp và dẫn đến estimate sai.
Do đó, có một TIP cho anh em DEV, là nếu bất chợt PM có yêu cầu làm task gì, hãy cố gắng nhớ cho kỹ yêu cầu của task, sau đấy bình tĩnh về chỗ tìm hiểu estimate và hẹn đưa thông tin estimate cho PM vào một thời gian khác. Anh em còn làm ăn với nhau lâu dài, không việc gì phải vội. Thà làm lâu mà tính năng hoạt động ổn định, còn hơn làm vội mà sau đấy phải mất rất nhiều thời gian để fixbug.
Điều 2. Người nào làm, người đó estimate
Người được giao nhiệm vụ làm task thường là người hiểu rõ hoặc có động lực để hiểu rõ nhất công việc phải làm. Người này sẽ có khả năng nhìn thấy những chi tiết lặt vặt mà cũng không kém phần quan trọng của công việc. Đây là những yếu tố quan trọng để có được estimate chính xác nhất.
Điều 3. Đừng bỏ qua những task lặt vặt
Thường trong quá trình thực hiện project, bạn sẽ nhận được mộ lô những task lặt vặt kiểu như:
Checkbug
Fixbug
Review code
Build App
Deploy App
Nhìn qua thì những việc này không tốn thời gian lắm. Tuy nhiên luôn có vấn đề nào đó xảy ra. Và bạn sẽ khó mà lường trước được độ phức tạp. Hơn nữa, ngay cả khi không có vấn đề, khi bạn cộng gộp thời gian lại, bạn sẽ có được con số không hề nhỏ.
Điều 4. Xem xét tới một vài khả năng gây ra việc delay bất thình lình
Một thành viên nào đó đột nhiên bị ốm, hoặc có kỳ nghỉ mát, hoặc có một vài ngày nghỉ bắt buộc, hoặc một vài bug khủng xuất hiện vào những lúc không ngờ tới. Bạn cố gắng dựa vào kinh nghiệm đã làm của mình, để xem xét đưa những yếu tố này vào kết quả estimate của mình.
Chú ý ở đây là trong quá trình làm project, bạn cố gắng để ý tới các sự kiện không mong đợi, khả năng xuất hiện của bug theo thời gian để có thể có những chú ý cho những lần estimate tiếp theo
Kết luận
Đối với việc estimate, tìm ra các kết quả chính xác thường rất khó. Do vậy, anh em DEV chúng ta nên chấp nhận thực tế này. Tuy nhiên, chúng ta cũng nên estimate càng sát với thực tế càng tốt, dẫu có không thể tìm được kết quả chính xác, nhưng phải luôn cố gắng nỗ lực để làm được điều đó. Quá trình này sẽ giúp anh em DEV chúng ta hiểu biết rõ-ràng và nắm được chính-xác các bước để giải quyết các vấn đề.
Cuối cùng, chúc dự án của anh em hoàn thành đúng hạn!
Thật sự cũng không quá lâu khi chúng ta – những người quyết định sự nghiệp của bản thân là giúp đỡ các tổ chức/công ty mang lại cho người dùng những sản phẩm tốt nhất, tự hỏi làm sao để chúng ta phù hợp trong thế giới phát triển Agile. Trong khi các công ty độc lập và giới kỹ sư phần mềm cố gắng đáp ứng và quyết định rằng Agile là phù hợp với nghiệp vụ và mục tiêu của mình, một sự tiến bộ quan trọng khác đã sẵn sàng xuất hiện trong giới phát triển phần mềm: DevOps. Một vài người còn nhận định, DevOps chỉ đơn giản là một hình thái tiến hóa kế tiệp của Agile.
DevOps thật sự là một sự thay đổi lớn, mà ở đó, nhấn mạnh sự hợp tác giữa các nhà phát triển phần mềm và các chuyên gia trong các lĩnh vực IT khác trong khi tự động hóa việc đưa sản phẩm ra thị trường và thay đổi các cấu trúc hạ tầng. Nó nhằm mục đích xây dựng một môi trường mà ở đó, phát triển, kiểm thử và đưa sản phẩm phần mềm ra thị trường nhanh hơn, thường xuyên hơn và đáng tin cậy hơn.
Về cơ bản, mô hình DevOps phấn đấu để phá vỡ các rào cản truyền thống giữa các bên trong quá trình phát triển, bao gồm cả kiểm thử, nghiệp vụ; và cố gắng đạt đến mức độ tự động hóa việc triển khai sản phẩm phần mềm, nơi mà bất kỳ sự thay đổi và cải tiến nào cũng có thể được triền khai ngay khi cần thiết.
Nếu mục tiêu của chúng ta, như là những kỹ sư kiểm thử, là xây dựng và mang lại sản phẩm nhanh hơn, thường xuyên hơn và đáng tin cậy hơn, chúng ta cần phải sắp xếp và kết hợp các hoạt động kiểm thử, công cụ kiểm thử, kịch bản kiểm thử, dữ liệu kiểm thử và môi trường kiểm thử vào trong một thế giới liên kết liên tục, kiểm thử liên tục và triển khai liên tục các sản phẩm. Xa hơn nữa, chúng ta cần áp dụng các mô hình mới và tập trung vào cách kiểm thử theo hướng phòng ngừa hơn là chăm chăm vào việc tìm kiếm lỗi, và tập trung vào triển khai các chức năng mới vào sản phẩm hơn là vào nghiệp vụ. Nếu không làm như vậy, chúng ta khó hy vọng vào việc nhanh chóng mang lại sản phẩm chất lượng cao cho khách hàng.
Từ đó, chúng ta có cơ hội nhìn lại vai trò, trách nhiệm và công việc kiểm thử của chúng ta trong môi trường DevOps một cách khác biệt. Dưới đây là một vài ví dụ:
Đào tạo, cố vấn và cam kết một cách nghĩ mới, tiếp cận mới về phương pháp cung cấp sản phẩm ra thị trường một cách liên tục thông qua các cải tiến (dù nhỏ) của sản phẩm.
Nâng cao chất lượng trên toàn bộ quá trình phát triển bằng cách không chỉ quan tâm đến chất lượng sản phẩm mà còn chất lượng trong quá trình phát triển, quá trình kiểm thử và quá trình triển khai sản phẩm end-to-end.
Tìm kiếm, đánh giá và thử nghiệm các công cụ hỗ trợ phương pháp làm việc tích hợp, một công cụ áp dụng quá trình làm việc liên tục, có khả năng tăng tốc quá trình phát triển, quá trình kiểm thử, quá trình triển khai và đảm bảo các việc này có thể được làm một cách đồng thời.
Đảm bảo rằng (vấn đề này là cần thiết) luồng làm việc cũng như dữ liệu của người dùng được thu thập và phân tích, bởi tất cả mọi người trong nhóm phát triển, để các chức năng mà ứng dụng cung cấp là dựa trên nhu cầu cần thiết nhất người sử dụng.
Giúp đỡ nhóm phát triển về quản lý và giảm thiểu rủi ro, ví dụ như kiểm thử trên sản phẩm ngay sau khi triển khai; chỉ triển khai những thay đổi/chức năng mới trên một vài hệ thống hoặc vài người dùng; tiến hành trên chế độ phân tích lỗi và đảm bảo có thể quay lại phiên bản trước trong trường hợp có lỗi.
Bạn có thể nói rằng “Những nhiệm vụ này là trách nhiệm của ai đó, không phải kỹ sư kiểm thử“. Theo truyền thống, bạn hoàn toàn đúng. Nhưng, một nền văn hóa đồng nhất và tích hợp mới, nơi mà mọi người hợp tác với nhau để phát triển và cung cấp các sản phẩm phần mềm nhanh hơn, tốt hơn và rẻ hơn đã làm lu mờ các vai trò trong nhóm phát triển.
REST đã được nhiều lập trình viên sử dụng để gửi dữ liệu qua HTTP, trong khi GraphQL thường được biết đến như một công nghệ thay thế của API REST.Trong bài viết này, tôi sẽ giải thích những điểm lợi cũng như hạn chế và sự khác biệt giữa REST và GraphQL. Điều này sẽ giúp bạn quyết định nên chọn gì cho dự án tiếp theo của mình.
REST là gì?
REST (Representational state transfer) là một phương thức tạo API được sử dụng để triển khai các dịch vụ web bằng cách sử dụng một tập hợp các hoạt động không trạng thái được xác định trước (bao gồm GET, POST, PUT, và DELETE).
Ý tưởng cốt lõi của REST là bạn sẽ truy xuất tài nguyên bằng cách đưa qua một yêu cầu tới URL của tài nguyên và nhận được phản hồi (thường là JSON, nhưng nó phụ thuộc vào API).
Lợi thế của REST
REST có khả năng mở rộng, vì nó tách biệt máy khách và máy chủ để bạn có thể mở rộng ứng dụng của mình một cách dễ dàng.
Tính linh hoạt là một lợi thế khác của việc sử dụng REST, vì nó có thể được thiết kế để xử lý các loại cuộc gọi khác nhau và trả về các định dạng dữ liệu khác nhau.
Hạn chế của REST
Over-fetching — Đây là khi endpoint API cung cấp nhiều thông tin hơn so với yêu cầu của khách hàng.
Under-fetching — Đây là khi endpoint API không cung cấp tất cả thông tin bắt buộc.Vì vậy, khách hàng phải thực hiện nhiều yêu cầu để có được mọi thứ mà ứng dụng cần.
GraphQL là gì?
GraphQL là một ngôn ngữ truy vấn dành cho API được tạo ra với mục đích nhắm tới những kiểu dữ liệu phức tạp, đa lớp với nhiều thành phần.GraphQL từ khi xuất hiện đã gần như thay thế hoàn toàn REST bởi tính hiệu quả, mạnh mẽ và linh hoạt hơn nhiều.
Lợi thế của GraphQL
Truy xuất dữ liệu chính xác và chỉ vậy thôi.Trong GraphQL, bạn sẽ nhận được những gì bạn request, đây là một điểm cộng quá tuyệt vời.
Chỉ cần thay đổi phía Client.Thông thường, khi có các thay đổi về yêu cầu dữ liệu, bạn chỉ cần sửa đổi truy vấn và không cần thay đổi nhiều.Cả client và server đều có thể làm việc độc lập, miễn là cả hai đều biết cấu trúc của dữ liệu.
Hạn chế của GraphQL
Có thể hơi phức tạp đối với các ứng dụng đơn giản, để thiết lập các loại truy vấn, v.v., vì nó có thể được thực hiện dễ dàng hơn bằng REST.
Nó sử dụng một endpoint duy nhất thay vì tuân theo HTTP lưu vào cache.Lưu vào cache ở mức độ mạng rất quan trọng vì nó có thể làm giảm lượng lưu lượng truy cập vào máy chủ.
Ví dụ đơn giản để so sánh cả hai
Giả sử chúng ta cần phải hiển thị danh sách bài đăng của tác giả và những người theo dõi họ.Trong trường hợp này, chúng ta phải hiển thị tác giả của bài đăng, bài đăng cũng như những người đang theo dõi người dùng đó.
Nếu sử dụng REST, chúng ta sẽ cần ít nhất 2 hoặc 3 request, như thế này:
/user/<id> để có được thông tin chi tiết về người dùng (tác giả) có thể là tên.
/user/<id>/posts để lấy danh sách các bài được đăng bởi người dùng đó.
/user/<id>/followers để lấy danh sách người đang theo dõi người dùng.
Nhưng trong tất cả những trường hợp này, chúng ta đang over-fetching dữ liệu.Ví dụ, trong request đầu tiên, chúng ta chỉ cần lấy tên, nhưng cái ta nhận được là tất cả các chi tiết về người dùng khi sử dụng cách này.
Và đây là lúc GraphQL cho thấy sức mạnh của nó.Chúng ta cần chỉ định truy vấn và nhận được đầu ra mong muốn.Chúng ta sẽ sử dụng một truy vấn như sau:
query {
User(id: '123') {
name
posts {
title
}
followers {
name
}
}
}
Với truy vấn như này, ta sẽ nhận được JSON response với các thuộc tính sau.Gọn gàng và đơn giản, đúng không anh em
GraphQL và REST
Tóm lại, đây là một vài điểm khác biệt nổi bật:
1.Data fetching
REST gây ra over-fetching hoặc under-fetching, trong khi đây không phải là vấn đề của GraphQL.Trong GraphQL, những điều gì bạn yêu cầu thì bạn nhận được đúng những điều đó.
2. Định nghĩa đối tượng (JSON response)
Với REST, bạn xác định đối tượng trong Backend. Còn với GraphQL, bạn xác định đối tượng trên Frontend.
3. Bộ nhớ đệm tự động
REST tự động lưu vào cache trong khi GraphQL không có hệ thống lưu cache tự động, nhưng có thể khắc phục bằng việc sử dụng các ứng dụng phía client như Apollo Client, Relay, v.v. sẽ mang lại khả năng lưu vào cache.
4. Xử lý lỗi
Xử lý lỗi trong REST đơn giản hơn nhiều so với GraphQL.Tuy nhiên, khi GraphQL sử dụng cùng các ứng dụng phía client như Apollo Client, Relay, … sẽ rất dễ dàng xử lý lỗi.
Kết bài
GraphQL chắc chắn có nhiều lợi thế hơn REST, nhưng nó không phải lúc nào cũng là cách tốt nhất.Như tôi đã nói trước đó, sự lựa chọn phụ thuộc vào ứng dụng của bạn, cho dù chọn REST hay GraphQL.
Tôi hy vọng bài này có thể giúp bạn đưa ra quyết định trong các dự án tương lai.Nếu bạn muốn chia sẻ kinh nghiệm của mình về GraphQL hoặc REST, hãy để chúng trong phần bình luận.Cảm ơn các bạn đã đọc!