Home Blog Page 204

Những con số biết nói trong ngành di động

Công nghệ di động – thuật ngữ không còn xa lạ trong cộng đồng người dùng điện thoại thông minh (Smartphone) hiện nay. Số liệu từ Nielsen Việt Nam cho biết tỷ lệ người dùng smartphone so với người dùng điện thoại phổ thông (feature phone) trong năm 2017 là 84%; tăng 6% so với năm 2016 (78%) và ước tính sẽ tăng 20% trong năm tiếp theo. Đây là một dấu hiệu tích cực cho toàn ngành vì smartphone không chỉ là vật bất ly thân của những người bận rộn mà còn dần trở thành những chiếc laptop “cầm tay” hỗ trợ mọi nhu cầu ngày càng ngày càng cao của người dùng.

Công nghệ di động, từng bước nâng tầm như thế nào?

Nền công nghệ 4.0 cho thấy thiết bị di động nhỏ bé nhưng sức ảnh hưởng không hề nhỏ, những năm gần đây sự dung nhập của công nghệ vào ngành di động càng khiến cả hai ngành trở nên nổi trội hơn. Công nghệ di động không chỉ dừng lại ở các ứng dụng mà còn trở thành nguồn lực phát triển mạnh mẽ của nhiều ngành nghề khác nhau. Có thể thấy như:

  • “Việt Nam đang tham gia “cuộc chơi” thương mại điện tử với phong độ tốt, nắm bắt hầu hết các xu thế của khu vực”, iPrice đánh giá. Từ khi thương mại điện tử Việt Nam chào đón Alibaba thông qua ứng dụng thanh toán AliPay, ứng dụng di động mua sắm trực tuyến Shopee, Lazada,… tạo nên dấu hiệu phát triển tích cực về thị trường thương mại điện tử Việt Nam như người dùng bắt đầu có thói quen mua sắm trực tuyến qua thiết bị di động nhiều hơn.
  • Kéo theo đó là sự chuẩn bị chu đáo từ các doanh nghiệp không muốn mình bị chôn vùi trong “cơn lốc” công nghệ vì hiện nay có đến 72% lượng truy cập website thương mại điện tử đến từ di động. VECOM còn cho biết trong số các doanh nghiệp có website phiên bản di động hoặc ứng dụng bán hàng, có tới 41% doanh nghiệp đã cho phép người mua thực hiện toàn bộ quá trình mua sắm trên thiết bị di động, 29% có triển khai chương trình khuyến mại dành riêng cho khách hàng sử dụng thiết bị di động để mua sản phẩm và 49% doanh  nghiệp có nhận đơn đặt hàng qua ứng dụng bán hàng trên thiết bị di động.
  • Không dừng lại ở đó, công nghệ di động còn trở thành bệ phóng mạnh mẽ cho các ngành nghề khác như: Fintech – được xem là cơ hội nhiều hơn là thách thức, đặc biệt theo Pwc Việt Nam, tỷ lệ hợp tác với các doanh nghiệp cung cấp dịch vụ thanh toán trực tuyến đã tăng lên mức 42% (cao hơn mức 35% năm ngoái).; Digital marketing – năm 2017, theo Adsota ngân sách quảng cáo cho nền tảng di động đạt tới 78.7 triệu dollar Mỹ, tương đương 36.6% tổng chi tiêu quảng cáo trực tuyến tại Việt Nam; …

Những dữ liệu trên cho thấy rõ được sự phát triển chóng mặt của toàn thị trường mobile tech tại Việt Nam. Cùng thời điểm đấy, cộng đồng công nghệ cũng đã sôi sục trở trở lại với sự kiện VIETNAM MOBILE DAY sắp diễn ra tại 2 thành phố lớn nhất TP.HCM 28/08 và Hà Nội 30/08. Được diễn ra lần thứ 8, sự kiện được giới chuyên môn đánh giá là một diễn đàn rất hữu ích giúp kết nối tất cả các doanh nghiệp lớn nhỏ trên cả nước. Năm 2017 vừa qua, Vietnam Mobile Day đã quy tụ được hơn 200 doanh nghiệp quốc tế và Việt Nam, thu hút hơn 8000 nguồi tham dự  chuỗi sự kiện của mình.

Sự kiện quy tụ nhiều chuyên gia công nghệ đứng đầu ngành.

Cập nhật những xu hướng công nghệ mới nhất trong năm

Để hệ sinh thái công nghệ phát triển một cách bền vững, những sự kiện mang tính chất kết nối mạng lưới các chuyên gia công nghệ, doanh nghiệp, lập trình viên càng trở nên thiết yếu, Vietnam Mobile Day được xem là chuỗi sự kiện nổi bật nhất toàn ngành mobile mang sứ mệnh cao cả này.

Ông Nguyễn Ngọc Dũng, Phó chủ tịch Hiệp hội VECOM từng nhấn mạnh: “Các doanh nghiệp muốn thành công cần theo sát những xu hướng thương mại di động mới nhất để giữ vững lợi thế cạnh tranh trong kinh doanh. Nếu website của doanh nghiệp có sự tương thích đối với thiết bị di động, doanh nghiệp sẽ bảo đảm được khả năng hiện diện trước nhiều khách hàng hơn và khả năng cạnh tranh trên thị trường của doanh nghiệp cũng được nâng cao”

Đến với VIETNAM MOBILE DAY, cộng đồng công nghệ sẽ được cập nhật hơn 100 chuyên đề mới nhất trong ngành Mobile hiện nay chia thành 5 nhóm chủ đề chính: Future of Fintech; Blockchain; Mobile App and Game – Red ocean strategy; AI world domination; The future of Marketing. Sự kiện mang lại một sân chơi hấp dẫn, phong phú, thu hút hơn 10.000 người tham dự; với hơn 200 doanh nghiệp lớn nhỏ hoạt động trong ngành công nghệ thông tin và hơn 100 đơn vị truyền thông trên khắp cả nước tham gia, chắc chắn đây sẽ là một bữa tiệc thịnh soạn dành cho cộng đồng lập trình, doanh nghiệp và khởi nghiệp quan tâm đến lĩnh vực công nghệ.

THÔNG TIN CHI TIẾT VỀ SỰ KIỆN
Website: http://mobileday.vnFanpage chính thức: https://www.facebook.com/mobiledayevent/Hãy nhanh tay đăng kí những chiếc vé EARLY BIRD đầu tiền. Số lượng có hạn! Nhập ngay mã VMDEARLYBIRD khi đăng kí tại: https://meetup.vn/e/JaK để được giảm ngay 100.000 VNĐ cho mỗi vé hạng Standard.

Về các hạng mục hợp tác tại sự kiện:
Mr. Khiêm Phạm
Mobile:  0902 951 296
Email: khiem.pham@applancer.net

Tổng quát về sự kiện:
BTC
Điện thoại: 84-28 62645022 | 84-28 62733496 | 84-28 62733497
Email: event@applancer.net

 

Vietnam Mobile Day đã chính thức quay trở lại!!

Những số liệu, chiến lược và công nghệ nóng nhất ngành sẽ được đem đến tại kỳ Vietnam Mobile Day lần thứ 8 lần này

Với hơn 9 ngàn lượt người tham dự hàng năm, Vietnam Mobile Day được biết đến như ngày hội thường niên lớn nhất trong toàn ngành công nghệ. Sự kiện được giới chuyên môn đánh giá là một diễn đàn cung cấp đầu đủ những kiến thức mới nhất, chuyên sâu nhất từ các diễn giả là chuyên gia được chọn lọc mời từ các công ty Internet tiên phong, đối tượng tham dự đa dạng từ các Developer, Marketer đến các Designer và doanh nhân.

Đừng bỏ lỡ cơ hội tham gia và giao lưu với những Decision Maker của ngành công nghệ. Nắm bắt những thông tin và xu hướng mới chính là chiếc chìa thành công cho bất kỳ ai hoạt động trong lĩnh vực này.

Những kiến thức bạn sẽ được cập nhật “tận răng” trong lần VIETNAM MOBILE DAY 2018:

👉What is the future of Fintech?

👉Blockchain: Bubble or Revolution.

👉Mobile App and Game: All about the red ocean strategy.

👉AI world domination? Real or fiction?

👉The future of Marketing.

Và còn rất nhiều những điều thú vị nữa đang chờ đón các bạn. Hãy truy cập và theo dõi tại website hoặc fanpage của Vietnam Mobile Day để cập nhật những thông tin mới nhất nhé!

💥THÔNG TIN CHI TIẾT

Website: http://mobileday.vn/

Event Page: https://www.facebook.com/mobiledayevent/

💥HOTLINE/ LIÊN HỆ HỢP TÁC:

– event@applancer.net (Event team) | 028 6273 3497 – 028 6681 3236

– khiem.pham@applancer.net (Mr. Khiêm) | 0902 951 296

 

Imatis – làn gió công nghệ mới trong dịch vụ chăm sóc sức khỏe y tế

Internet of thing (IoT) có rất nhiều ứng dụng trong lĩnh vực chăm sóc sức khỏe, từ giám sát từ xa đến cảm biến thông minh cùng khả năng tích hợp vào các thiết bị y tế. Nó không chỉ có khả năng giúp cho bệnh nhân an toàn và khỏe mạnh mà còn được dùng để nâng cao chất lượng dịch vụ. Có thể nói đây là một hệ thống tiên tiến vốn được xem là chuẩn mực cho các bệnh viện ở nước ngoài.

Với mong muốn đem đến cơ hội chăm sóc ý tế đáp ứng tốt hơn nhu cầu của người dùng Việt Nam và nhận thức được nhu cầu chăm sóc sức khỏe chất lượng cao tại thị trường Việt Nam. Imatis, một trong những công ty chuyên phát triển dịch vụ phần mềm về chăm sóc sức khỏe hàng đầu thế giới, và đang có kế hoạch triển khai dự án ở thị trường Việt Nam. Hôm nay, TopDev có cơ hội được gặp gỡ và trò chuyện cùng đội ngũ chuyên gia của Imatis để hiểu rõ hơn về E-health và tiềm năng của E- health tại thị trường Việt Nam

Việt Nam – thị trường E-health đầy tiềm năng và thử thách

Theo ông Morten Andresen, CEO của Imatis –  công ty chuyên phát triển phần mềm về chăm sóc sức khỏe. Trong đó, hãng tập trung về mảng logistic, quản lí thiết bị cơ sở cũng như là thiết lập đường dây kết nối thông tin dành riêng cho bệnh viên. Với sự tích hợp của machine learning, người bệnh sẽ được hỗ trợ dịch vụ chăm sóc sức khỏe vô cùng tiện lợi.

Imatis hiện đã có mặt tại hơn 30% bệnh viện tại Na Uy. Ngoài ra, Imatis cũng phát triển ra các thị trường như Thụy Điển và Đan Mạch nói riêng cũng như khu vực Bắc Âu nói chung. Không dừng lại đó, công ty hiện đang lên kế hoạch mở rộng chi nhánh tại Việt Nam và các nước trong khu vực Châu Á. Vì vậy, Imatis quyết định hợp tác với OutsourceIt-Facilitated Work Hub, một công ty công nghệ chuyên về cung cấp dịch vụ phần mềm với chi nhánh tại Việt Nam.

Đây là một dự án có rất nhiều ứng dụng khác nhau với mục tiêu nhằm tối ưu hóa quá trình chăm sóc sức khỏe cũng như là bảo đảm quỹ thời gian của bác sĩ được sử dụng hiệu quả. Bên cạnh đó, nhóm phát triển phần mềm tại Việt Nam trực thuộc OutsourceIt-Facilitated Work Hub cũng sẽ chịu trách nhiệm cho những ứng dụng nhỏ đó. Tùy vào yêu cầu của từng bệnh viện mà Imatis sẽ phát triển cũng như chỉnh sửa ứng dụng cho phù hợp.

Ông Morten cũng chia sẻ thêm, Imatis muốn tập trung vào việc phát triển một đội ngũ phát triển phần mềm ngay tại thị trường nội địa cũng như xây dựng nền móng tại Việt Nam. Ngoài ra, công ty cũng lên kế hoạch để cải thiện dịch vụ hỗ trợ cho khách hàng. Bởi khách hàng của Imatis có ở khắp mọi nơi trên thế giới nên dịch vụ xuyên suốt 24/7 là điều bắt buộc.

Một đội ngũ developer tuyệt vời sẽ quyết định tất cả

Đòi hỏi một nguồn nhân lực giỏi ngay tại thì trường nội địa, Imatis cũng rất quan tâm tới quá trình tuyển dụng các developer cũng như chính sách đối đãi phù hợp.

Theo anh Phan Thành Thái, Technical lead của Imatis, với một môi trường làm việc năng động, xuyên quốc gia đây là cơ hội lớn, đồng thời cũng là thách thức không nhỏ đối với các bạn developer.

Để có thể thực sự tỏa sáng ở môi trường làm việc đa văn hóa như ở Imatis các developer sẽ cần phải có khả năng giao tiếp bằng tiếng Anh cũng như có một thái độ làm việc chuyên nghiệp, ham học hỏi. Mặt khác, môi trường văn hóa làm việc là tự quản lí công việc nên quá trình giao tiếp thường diễn ra trực tiếp và mang tính tự giác giữa đôi bên. Do đó, thái độ làm việc đóng vai trò rất quan trọng. Developer sẽ phải tự giác trao đổi để có thể học cách tiếp cận và giải quyết một vấn đề.

Anh cũng cho rằng có 2 khó khăn lớn là khác biệt trong văn hóa cũng như giao tiếp. Các developer Việt Nam khá là rút rè và nhút nhát trong việc đưa ra ý kiến riêng của chính mình, đặc biệt là trong giao tiếp với người nước ngoài. Ngoài ra, kĩ năng giải thích vấn đề cũng là một thách thức cho cả 2 phía khi mà trình độ tiếng Anh của developer Việt Nam vẫn chưa thật sự đồng đều cũng như thuần thục.

Chia sẻ thêm về kinh nghiệm cho những developer newbies muốn nhanh chóng gia nhập được môi trường làm việc đa quốc gia thì đam mê, nhiệt huyết, “cày” hăng say vẫn là chưa đủ. Bởi suy cho cùng hiệu quả công việc mới là yếu tố quyết định chính. Do đó, ngoài kiến thức cơ bản học tại nhà trường thì các bạn developer cũng sẽ rất cần những kĩ năng mềm như cách sắp xếp công việc để bảo đảm chất lượng sản phẩm. Đồng thời, developer sẽ phải cân bằng được giữa làm việc và thư giãn, cũng như có khả năng giao tiếp nhóm để có thể học hỏi từ các anh chị đi trước.

Ngoài ra, khả năng sử dụng tiếng Anh là một trong những yếu tố quan trọng nhất. Với 4 kĩ năng bao gồm đọc, nói, viết và nghe đều phải ở mức khá trở lên. Tất nhiên là bạn có thể nói tiếng Việt thoải mái với các developer Việt Nam khác nhưng mọi thứ liên quan tới công việc cũng như giao tiếp với team Na Uy đều sẽ dùng tiếng Anh.

Thay Lời Kết

Với sự phát triển vũ bão của công nghệ cũng như internet đã mang tới sự đột phá cho nhân loại. Nó không chỉ là về máy tính, laptop, tablet hay smartphone. Các máy giặt, máy hút bụi, ổ khóa cửa, đồ chơi và thậm chí lò nướng bánh mì hiện nay đã trở nên “thông minh” hơn. Tương lai mà chúng ta vẫn hay nghe trong những câu chuyện khoa học viễn tưởng đang dần dần trở thành hiện thực, và người tiêu dùng đang chờ đợi một làn gió mới. Chính vì vậy mà tất cả các lĩnh vực, không riêng gì mảng công nghệ, đều phải tự nâng cấp dịch vụ của mình trong thời đại “IoT” này. Tin rằng không chỉ có Imatis mà vẫn còn rất nhiều công ty công nghệ khác đang cố gắng thay đổi thế giới bằng chính những sản phẩm đầy tiềm năng của họ.

TopDev

Unit testing các component Vue.js bằng các tool Vue testing và Jest (P3): Test các Style and cấu trúc của các Vue.js Component trong Jest

Phần 1: Viết Vue.js Component Unit Test với Jest

Phần 2: Test Vue.js Components deep render trong Jest

vue-test-utils đem đến cho chúng ta một bộ tính năng để xác định các Vue.js component.

Đến hiện tại, các test chúng ta thực hiện đều qua Jest Snapshots. Nó rất tốt, nhưng đôi khi chúng ta cần xác định cái gì đó cụ thể hơn.

Mặc dù bạn có thể access vào một ví dụ của Vue qua cmp.vm, bạn vẫn có một bộ tính năng tùy ý sử dụng để làm nó nhanh hơn. Hãy xem xem chúng ta có thể làm gì.

Wrapper object

Wrapper là một object chính trong vue-test-utils. Đây là một type trả về của các function mount, shallow, find và findAll. Bạn có tham khảo dây đủ API và typing tại đây.

find và findAll

Chúng đều nhận Selector như một argument, vừa là một CSS selector, vừa là một Vue Component.

Chúng ta có thể làm một số việc như thế này:

  let cmp = mount(MessageList)
  expect(cmp.find('.message').element).toBeInstanceOf(HTMLElement)

  // Or even call it multiple times
  let el = cmp.find('.message').find('span').element

  // Although for the previous example, we could do it in one
  let el = cmp.find('.message span').element

Xác thực Structure và Style

Hãy thực hiện thêm test trong MessageList.test.js:

it('is a MessageList component', () => {
  expect(cmp.is(MessageList)).toBe(true)

  // Or with CSS selector
  expect(cmp.is('ul')).toBe(true)
})

it('contains a Message component', () => {
  expect(cmp.contains(Message)).toBe(true)

  // Or with CSS selector
  expect(cmp.contains('.message')).toBe(true)
})

Ở đây chúng ta dùng is để xác thực loại component, và dùng contains để check xem có xuất hiện sub-component hay không. Tương tự như find chúng nhận một Selector, bất kể là CSS Selector hay Component.

Chúng ta có các utils để xác nhận (assert) Vue instance:

it('Both MessageList and Message are vue instances', () => {
  expect(cmp.isVueInstance()).toBe(true)
  expect(cmp.find(Message).isVueInstance()).toBe(true)
})

Bây giờ chúng ta sẽ xác nhận Structure một cách chi tiết:

it('Message element exists', () => {
  expect(cmp.find('.message').exists()).toBe(true)
})

it('Message is not empty', () => {
  expect(cmp.find(Message).isEmpty()).toBe(false)
})

it('Message has a class attribute set to "message"', () => {
  // For asserting "class", the `hasClass` method is easier
  expect(cmp.find(Message).hasAttribute('class', 'message')).toBe(true)
})

exists, isEmpty và hasAttribute rất thích hợp cho phần này.

Sau đó, chúng ta dùng hasClass và hasStyle để xác nhận Styling. Update component Message.vue với một style, vì hasStyle chỉ nhận style inline:

<li style="margin-top: 10px" class="message">{{message}}</li>

Test như sau:

it('Message component has the .message class', () => {
  expect(cmp.find(Message).hasClass('message')).toBe(true)
})

it('Message component has style padding-top: 10', () => {
  expect(cmp.find(Message).hasStyle('padding-top', '10')).toBe(true)
})

Phương thức get

Như đã nói, chúng ta có các util rất hữu ích để assert các component Vue. Hầu hết dùng form hasX, nhưng có một getX có thể đem đến trải nghiệm test tuyệt vời hơn về tính linh hoạt và dễ debug. Vì thế bạn có thể rewrite như ví dụ dưới đây:

// `has` form
expect(cmp.find(Message).hasAttribute('class', 'message')).toBe(true)

// `get` form
expect(cmp.find(Message).getAttribute('class')).toBe('message')

Kết luận

Có rất nhiều util giúp cho việc test Vue component đơn giản hơn nhiều. Bạn có thể tìm đầy đủ trong các file typing ở đây.

Code ví dụ trên trong repo này.

TopDev via alexjoverm.github.io

Microservices là gì? Speed up Microservices 1: Tác dụng phụ và một số chiến lược cơ bản

Chào mọi người, nếu như các bạn cũng biết thì dự án Teamcrop của mình xây dựng và chạy hoàn toàn trên kiến trúc Microservices và sau hơn 2 năm triển khai thì có một số vấn đề liên quan đến kiến trúc này, thiết nghĩ cần chia sẻ thêm với mọi người để mọi người thấy được rằng Microservices không phải là chìa khóa vạn năng như vẫn hay nghe quảng cáo, dụ dỗ. Mọi kiến trúc đều có đánh đổi và Microservices cũng vậy.

Mình sẽ viết một loạt bài (5, 6 bài gì đó) về việc tăng tốc cho kiến trúc Microservices mà đã rút tỉa được trong quá trình triển khai dự án Teamcrop, bởi tốc độ luôn là yếu tố hàng đầu khi xây dựng các ứng dụng web, và với kiến trúc mới này thì tăng tốc là một kỹ thuật cần xem xét khi triển khai.

Microservices là gì?

Microservices là các dịch vụ nhỏ, tách biệt đại diện cho 1 phần nhỏ tương ứng trong business domain của bạn. Với kiến trúc Monolithic, bạn sẽ có 1 server lớn chịu trách nhiệm giải quyết tất cả các requests. Việc này sẽ gây khó khăn rất nhiều trên phương diện scale.  Microservices có thể cân bằng traffic theo nhu cầu của doanh nghiệp. Nếu đang nhận được 1 lượng lớn thanh toán, bạn có thể scale up thiết bị thanh toán và giữ các dịch vụ khác ở mức sử dụng 1 lượng nhỏ hơn các services.

Microservice VS Monolithic

Mô tả kiến trúc Microservices

Trong kiến trúc Microservices, các service (dự án) tồn tại độc lập nhau về xử lý (process), lưu trữ (database) và request (client/server model). Hình minh họa bên dưới là minh họa 1 thành phần trong kiến trúc microservices (lưu ý là nó không liên quan đến phần bài toán đề cập bên dưới).

Ví dụ bạn xây dựng một hệ thống bán hàng dựa trên Microservices (như Teamcrop chẳng hạn) thì giả sử một đơn hàng được mô tả với các thông tin sau “Hôm nay có nhân viên A tạo một đơn hàng B tại cửa hàng C và xuất từ kho D” thì bạn cần tối thiểu 4 service (project) với database độc lập:

  • Employee service (sử dụng table tc_employee)
  • Store service (sử dụng table tc_store)
  • Inventory service (sử dụng table tc_warehouse)
  • Order service (sử dụng table tc_order). Trong đó table tc_order chỉ chứa khóa ngoại – tức ID của Nhân viên, ID của cửa hàng, ID của nhà kho theo đúng tinh thần thiết kế chuẩn hóa database.

Bởi vì theo kiến trúc Microservices nên hệ thống bạn sẽ chạy 4 dịch vụ khác nhau như trên và chạy ở tối thiểu 4 instance (container, server) khác nhau.

Lợi ích của Microservices

Nếu đọc đến đây thì bạn sẽ thấy được việc tách ra như thế sẽ làm cho mô hình Microservices phát huy thế mạnh như đã quảng cáo là:

  • Source code tinh gọn: bởi vì hệ thống cấu thành từ những dự án nhỏ, mỗi dự án sẽ đơn giản và tập trung vào 1 hoặc 1 vài nghiệp vụ chính nên code base và độ phức tạp cũng không cao. Giúp mang lại tính gọn nhẹ, dễ bảo trì và mở rộng.
  • Bảo mật source code: vì nhân viên nào làm việc ở dự án nào thì chỉ truy cập được source code của dự án đó.
  • Tồn tại độc lập: vì đây là 4 dự án khác nhau và có thể có cách deploy riêng, và một service nào đó chết thì service khác vẫn hoạt động bình thường.
  • Scale độc lập: tùy theo nhu cầu sử dụng của hệ thống mà có thể scale riêng service đó, ví dụ như service đơn hàng sử dụng thường xuyên nên có thể chạy 2, 3 server (container) để tăng performance.

Tác dụng phụ của Microservices

Các điểm bên trên đúng là các ưu điểm của microservices, tuy nhiên, hãy nghĩ đến ngữ cảnh ở trên. Nếu ở website bạn hiện 1 table view với thông tin sau:

Invoice ID Nhân viên Cửa hàng Kho xuất
123456 Võ Duy Tuấn Cropcom Kho HCM

thì bạn sẽ làm như thế nào và tối ưu nhất? Có thể trong đầu các bạn đã nghĩ đến JOIN, nhưng xin thưa, đây không phải là ứng dụng Monolithic, mà đây là microservice và 4 database table này ở 4 database server khác nhau nên không có chuyện JOIN gì cả, và ở table đơn hàng (tc_order) bạn chỉ có EmployeeID, StoreID và WarehouseID.

Chào mừng đến với tác dụng phụ của Microservices.

Một số chiến lược cơ bản

Để giải quyết bài toán hiển thị ở trên, bạn chỉ có thể tiếp cận theo hướng lấy dữ liệu trực tiếp từ service liên quan. Từ EmployeeID, gọi sang service Employee, từ StoreID thì gọi sang service Store…để lấy các thông tin cần hiển thị. Việc này sẽ dẫn đến giao tiếp liên service (inter-service communication).

Trong kiến trúc Microservices, càng hạn chế gọi liên service càng tốt vì các service sinh ra để phục vụ bên ngoài chứ không phải để phục vụ liên service, dẫn đến performance hệ thống sẽ bị giảm, vì nếu thiết kế không tốt, các service bị die hầu như do các service gọi lẫn nhau gây quá tải chứ từ client chưa chắc quá tải :).

Ngoài ra, gọi liên service sẽ có overhead vì vẫn có giao thức kết nối đi kèm (như HTTPS, Protobuf..) nên phải hạn chế. Do đó, cách dễ dàng tiếp cận nhất là sử dụng cache để không phải request nhiều đến các service mà chỉ cần mò vào cache. Có thể sử dụng Redis hoặc memcache cho tính năng này. Nhiệm vụ còn lại của bạn chỉ là làm sao clear cache một cách hiệu quả mà thôi.

Như vậy, với 1 đơn hàng, bạn sẽ cần thêm 3 request đến cache để fetch thêm thông tin (employee, store và warehouse) trước khi trả về client để hiển thị đầy đủ thông tin.

Tham khảo thêm: Việc làm Microservices lương cao tại Topdev

Teamcrop đã làm thế nào?

Ở trên là cách mình đề xuất và mọi người cũng nghĩ ra dễ dàng vì nó khá cơ bản cho các ứng dụng web hiện đại. Tuy nhiên, dự án Teamcrop không theo cách này và theo 1 cách “phức tạp” hơn nhiều và tất nhiên nó sẽ nhanh hơn cách ở trên.

Trong bài tiếp theo, mình sẽ chia sẻ chi tiết cách Teamcrop đã giải quyết bài toán này như thế nào, tận dụng web socket, service worker của trình duyệt để tăng tốc tối đa cho việc hiển thị dạng này.

Hy vọng bạn sẽ thích các thông tin này và sẽ tiếp tục theo dõi loạt bài chia sẻ kỹ thuật tăng tốc cho kiến trúc Microservices.

P.S: Teamcrop.com là hệ thống ERP dành cho chuỗi bản lẻ và luôn tìm kiếm lập trình viên PHP, nếu bạn biết PHP, yêu thích xây dựng các dự án web lớn, phức tạp trên những kiến trúc mới như Microservices, công nghệ mới như Docker thì đừng ngần ngại liên hệ với Tuấn (qua email tuanmaster2012@gmail.com) để tham gia cùng mình xây dựng những sản phẩm thú vị.

Có thể bạn quan tâm:

  Giao tiếp hiệu quả giữa các Microservice
  Hướng dẫn vượt khó Microservices vô cùng giá trị dành cho bạn!
  Xác thực và phân quyền trong Microservices

Nguồn: Bloghoctap

Devops đang rất quý, nhiều công ty hàng đầu cần tuyển Devops lương lên đến $3000

Unit testing các component Vue.js bằng các tool Vue testing và Jest (P2): Test Vue.js Components deep render trong Jest

Hãy cùng xem cách tham khảo cách sử dụng các vue-test-utils để test một cây component đã được render.

Trong Phần 1 chúng ta đã hiểu được cách sử dụng Shadow Rendering để test một component riêng biệt và tránh việc các component bị sub-free từ việc render.

Nhưng trong một số trường hợp, chúng ta lại muốn test một component đại diện cho cả 1 group, hoặc các phần tử như trong Atomic Design.

Bổ sung một Message Component

Đối với hai component Message và MessageList, bên cạnh việc viết các unit test cho chúng, thì chúng ta còn có thể test cả hai cái như một unit nữa.

Đầu tiên chúng ta tạo components/Message.vue:

<template>
    <li class="message">{{message}}</li>
</template>

<script>
  export default {
    props: ['message']
  }
</script>

Và update components/MessageList.vue để sử dụng nó:

<template>
    <ul>
        <Message :message="message" v-for="message in messages"/>
    </ul>
</template>

<script>
import Message from './Message'

export default {
  props: ['messages'],
  components: {
    Message
  }
}
</script>

Test MessageList bằng Message Component

Để test MessageList bằng Deep Rendering, chúng ta chỉ cần sử dụng mount chứ không cầnshallow trong test/MessageList.test.js đã tạo trước:

import { mount } from 'vue-test-utils'
import MessageList from '../src/components/MessageList'

describe('MessageList.test.js', () => {
  let cmp

  beforeEach(() => {
    cmp = mount(MessageList, {
      // Beaware that props is overriden using `propsData`
      propsData: {
        messages: ['Cat']
      }
    })
  })

  it('has received ["Cat"] as the message property', () => {
    expect(cmp.vm.messages).toEqual(['Cat'])
  })

  it('has the expected html structure', () => {
    expect(cmp.element).toMatchSnapshot()
  })
})

Không liên quan nhưng mà, bạn đã bao giờ nghĩ về beforeEach? Đây là một phương pháp “sạch” để tạo một component “sạch” trước mỗi test, một điều rất quan trọng trong unit testing, vì các test không nên phụ thuộc lẫn nhau,

Cả mount và shallow đều sử dụng API hệt như nhau, khác nhau nằm ở chỗ render. Tôi sẽ từ từ show cho bạn API này trong suốt cả series.

Nếu bạn cho chạy npm t bạn sẽ thấy ngay test thất bại vì Snapshot không khớp với MessageList.test.js. Để thực hiện lại, hãy chạy cùng với option -u:

npm t -- -u

Sau đó nếu mở và kiểm tra test/__snapshots__/MessageList.test.js.snap, bạn sẽ thấy có class="message", đồng nghĩa rằng component đã được render.

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`MessageList.test.js has the expected html structure 1`] = `
<ul>
  <li
    class="message"
  >
    Cat
  </li>
</ul>
`;

Luôn nhớ rằng phải tránh deep render khi có dấu hiệu sẽ xuất hiện các effect phụ, vì một khi các children component xuất hiện thì created và mount sẽ bị kích hoạt, và có thể sẽ kèm theo các HTTP call hoặc các hiệu ứng khác mà chả ai muốn đụng tới. Nếu bạn muốn thử, thêm component Message.vue vào console.log trong hook đã tạo:

export default {
  props: ['message'],
  created() {
    console.log('CREATED!')
  }
}

Sau đó nếu chạy lại các test bằng npm t, bạn sẽ thấy dòng text "CREATED!" trong output cuối cùng. Vì vậy hãy cẩn thận.

Phần 3: Test các Style and cấu trúc của các Vue.js Components trong Jest

TopDev via alexjoverm.github.io

Unit testing các component Vue.js bằng các tool Vue testing và Jest (P1): Viết Vue.js Component Unit Test với Jest

Hãy cùng nhau học cách viết unit test bằng các tool unit test chính chủ từ VueJS và framework Jest.

vue-test-utils, một thư viện VueJS testing chính thức dựa trên avoriaz, vừa mới ra lò. Nó cung cấp tất cả các tool cần thiết giúp viết unit test trong ứng dụng VueJS một cách dễ dàng. Bên cạnh đó, Jest là một testing framework được xây dựng bởi Facebook, giúp testing nhanh vượt trội với nhiều features tuyệt vời như:

  • Hầu như không có config mặc định
  • Interactive Mode rất “cool”
  • Chạy test song song
  • Các spy, stub và mock mới ra mắt
  • Built trên code coverage
  • Snapshot testing
  • Các tiện ích module mocking

Tất nhiên bạn có thể viết test mà không dùng tool này và chỉ cần dùng karma + mocha + chai + sinon + …, nhưng rồi bạn sẽ thấy nó dễ dàng như thế nào.

Set up một project mẫu vue-test 

Hãy bắt đầu bằng một project mới dùng vue-cli :

npm install -g vue-cli
vue init webpack vue-test
cd vue-test

Và chúng ta cần phải install một vài phụ tùng khác:

# Install dependencies
npm i -D jest jest-vue-preprocessor babel-jest

Cần phải cài jest-vue-preprocessor để jest đọc được cái file .vue, và cần babel-jest để hợp nhất với Babel.

Cài vue-test-utils:

npm i -D vue-test-utils

Thêm cấu hình Jest vào package.json:

...
"jest": {
  "moduleNameMapper": {
    "^vue$": "vue/dist/vue.common.js"
  },
  "moduleFileExtensions": [
    "js",
    "vue"
  ],
  "transform": {
    "^.+\\.js$": "<rootDir>/node_modules/babel-jest",
    ".*\\.(vue)$": "<rootDir>/node_modules/jest-vue-preprocessor"
  }
}
...

moduleFileExtensions sẽ chỉ cho Jest extension nào để tìm, và transform sẽ chỉ preprocessor nào để dùng cho các file extension.

Cuối cùng, thêm test script vào package.json:

{
  "scripts": {
    "test": "jest",
    ...
  },
  ...
}

Testing một Component

Ở đây tôi sẽ dùng các Single File Component, và tôi vẫn chưa check xem nó có hoạt động không nếu tách chúng ra các file html, css hoặc js riêng, vì thế cứ xem như là bạn cũng làm luộn việc này.

Đầu tiên tạo một MessageList.vue component trong src/components:

<template>
    <ul>
        <li v-for="message in messages">
            {{ message }}
        </li>
    </ul>
</template>

<script>
export default {
  name: 'list',
  props: ['messages']
}
</script>

Và update App.vue để dùng nó như sau:

<template>
  <div id="app">
    <MessageList :messages="messages"/>
  </div>
</template>

<script>
import MessageList from './components/MessageList'

export default {
  name: 'app',
  data: () => ({ messages: ['Hey John', 'Howdy Paco'] }),
  components: {
    MessageList
  }
}
</script>

Chúng ta đã có một vài component để test. Hãy tạo một folder test  trong project root, và một App.test.js:

import Vue from 'vue'
import App from '../src/App'

describe('App.test.js', () => {
  let cmp, vm

  beforeEach(() => {
    cmp = Vue.extend(App) // Create a copy of the original component
    vm = new cmp({
      data: { // Replace data value with this fake data
        messages: ['Cat']
      }
    }).$mount() // Instances and mounts the component
  })

  it('equals messages to ["Cat"]', () => {
    expect(vm.messages).toEqual(['Cat'])
  })
})

Bây giờ nếu ta chạy npm test (hoặc npm t cho nhanh), test sẽ chạy và pass. Vì chúng ta vẫn còn điều chỉnh test, nên chạy nó trên watch mode:

npm t -- --watch

Vấn đề của các nested component (component chồng component)

Bài test này quá đơn giản. Hãy check cả output ban đầu và output dự kiến. Chúng ta có thể sử dụng feature Snapshots của Jest, có thể cho ra snapshot của output và đối chiếu nó với những lần run tới. Add thêm sau it trước trong App.test.js:

it('has the expected html structure', () => {
  expect(vm.$el).toMatchSnapshot()
})

Nó sẽ tạo ra một file test/__snapshots__/App.test.js.snap. Mở và xem kĩ:

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`App.test.js has the expected html structure 1`] = `
<div
  id="app"
>
  <ul>
    <li>
      Cat
    </li>
  </ul>
</div>
`;

Để ý kĩ bạn sẽ thấy, có một vấn đề rất lớn ở đây: component MessageList  cũng đã bị render. Các unit test phải được test theo mỗi unit riêng lẻ, nghĩa là trong App.test.js chúng ta muốn test component App và không quan tâm đến những thứ khác.

Nó có thể bắt nguồn từ nhiều lý do. Tưởng tượng xem, các component con đó (trong trường hợp này là MessageList) sẽ gây ra nhiều side effect trên created hook, ví dụ như gọi fetch, một Vuex action hoặc các thay đổi state? Chắc chắn chúng ta không hề muốn nó xảy ra.

May thay, đã có Shallow Rendering!

Shallow Rendering là gì?

Shallow Rendering là một kĩ thuật đảm bảo rằng component của bạn được render mà không có component con đi kèm. Nó có lợi ích sau:

  • Chỉ test component bạn muốn test (vậy mới gọi là Unit Test)
  • Tránh các side effect của các component con, như thực hiện các HTTP call, calling store actions,…

Testing Component bằng vue-test-utils

vue-test-utils cung cấp cho chúng ta Shallow Rendering trong số các features. Chúng ta có thể viết lại test trước như sau:

import { shallow } from 'vue-test-utils'
import App from '../src/App'

describe('App.test.js', () => {
  let cmp

  beforeEach(() => {
    cmp = shallow(App, { // Create a shallow instance of the component
      data: {
        messages: ['Cat']
      }
    })
  })

  it('equals messages to ["Cat"]', () => {
    // Within cmp.vm, we can access all Vue instance methods
    expect(cmp.vm.messages).toEqual(['Cat'])
  })

  it('has the expected html structure', () => {
    expect(cmp.element).toMatchSnapshot()
  })
})

Sau đó nếu như bạn vẫn đang chạy Jest trong watching mode, bạn sẽ thấy nó vẫn qua bài test, nhưng Snapshot thì không tương thích. Nhấn u để generate lại lần nữa. Hãy mở và check lại:

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`App.test.js has the expected html structure 1`] = `
<div
  id="app"
>
  <!--  -->
</div>
`;

Bạn thấy không? Không có component con nào được render và App component được test hoàn toàn tách biệt khỏi bộ component. Ngoài ra, nếu bạn có bất kỳ created hay các hook nào đó trong các component con, chúng cũng không được call nhé.

Nếu bạn tò mò về Shallow render được implement như thế nào, check source code và ta thấy rằng căn bản đó là components key, method render và các lifecycle hook.

Tương tự như vậy, bạn có thể áp dụng MessageList.test.js test như sau:

import { shallow } from 'vue-test-utils'
import MessageList from '../src/components/MessageList'

describe('MessageList.test.js', () => {
  let cmp

  beforeEach(() => {
    cmp = shallow(MessageList, {
      // Beaware that props is overriden using `propsData`
      propsData: {
        messages: ['Cat']
      }
    })
  })

  it('has received ["Cat"] as the message property', () => {
    expect(cmp.vm.messages).toEqual(['Cat'])
  })

  it('has the expected html structure', () => {
    expect(cmp.element).toMatchSnapshot()
  })
})

Xem đầy đủ tại Github.

Phần 2 : Unit testing các component Vue.js bằng các tool Vue testing và Jest (P2): Test Vue.js Components deep render trong Jest

 

TopDev via Alex Jover Blog

Lập trình Concurrent cùng Semaphore

Giờ đây chuyện viết được một app iOS đã trở nên khá đơn giản, tuy nhiên, để tạo được một app chuẩn mực sẽ đòi hỏi nhiều nỗ lực hơn trong nhiều khía cạnh từ tối ưu hóa thuật toán đến các thao tác liên quan đến system. Quy tắc chung cho hầu hết mọi trường hợp đó là tránh để các job nặng nhọc, tốn thời gian gần main thread nhưng phải đảm bảo rằng các call trong UIKit hoặc những cái liên quan đến UI diễn ra trong main thread. Điều này làm cho app phản ứng nhanh hơn và không quá chậm chạp trong khi sử dụng, để mang đến trải nghiệm người dùng tốt hơn.

Việc phân chia job với các thread tương ứng thực chất chính là lập trình concurrent, một topic gây nhức nhối bấy lâu. Nhờ có các ngôn ngữ lập trình, libraries và các framework cao cấp hỗ trợ mà nó đã phần nào trở nên “dễ thở” hơn và ít lỗi prone cần xử lý hơn. Tùy theo mức độ phức tạp của app mà ta sử dụng các phương pháp xử lý vấn đề khác nhau, và một trong số đó chính là sử dụng semaphore để đồng bộ hóa các job bất đồng bộ hoặc tái sắp xếp chúng trong thread. Mọi thứ sẽ được trình bày kĩ hơn trong bài viết dưới đây.

Semaphore là gì?

Nếu để ý bạn sẽ thấy các phiên bản của semaphore xuất hiện ở rất nhiều nơi trong cuộc sống của chúng ta. Ví dụ trong cuộc thi cờ vua, bạn sẽ thấy cả hai thí sinh đều nhấn một đồng hồ đếm chung trước lượt đi của mỗi người. Chỉ có một bàn cờ và mỗi lượt chỉ được một người đi. Một ví dụ khác nữa đó là các quầy thu ngân trong siêu thị. Thông thường thì số lượng quầy thu là có hạn. Nếu có quầy trống, bạn sẽ tới check ở quầy đó ngay. Tuy nhiên, hầu như lúc nào các quầy cũng full và dòng người đứng đợi thanh toán thì dài dằng dẳng. Cả hai ví dụ có một điểm chung đó là chúng đều có nguồn chia sẻ giới hạn, lần lượt là bàn cờ và các quầy thu ngân.

Về semaphore, nó là một cơ chế giúp quản lý các nguồn chia sẻ và đảm bảo access không bị tắc nghẽn. Nguồn này có thể là cái gì đó cụ thể như một variable hoặc trừu tượng như một job pool. Có hai loại semaphore, binary semaphore và counting semaphore. Loại đầu tiện được dùng làm lock vì nó chỉ có 2 giá trị là 0 và 1 đại diện cho tình trạng lock hay unlock, còn loại thứ hai thì thực hiện đếm resource để cho biết mức độ sẵn sàng của resource.

Trong Grand Central Dispatch (GCD), semaphore là một ví dụ của DispatchSemaphore. API của nó rất nhỏ gồm một initializer init(value:) và 2 method chính signal() và wait().

Lưu ý: Các call đến signal() phải cân bằng với các call đến wait(), nếu không sẽ xuất hiện ngoại lệ EXC_BAD_INSTRUCTION.

Param value trong init(value:) ghi rõ value ban đầu của semaphore, chúng ta sẽ bàn về nó sau. Về nguyên tắc sử dụng semaphore thì rất đơn giản, wait() sẽ trả về toàn bộ nếu value của semaphore sau khi giảm tải lớn hơn hoặc bằng 0, nếu không nó sẽ đợi có tín hiệu. Để ra hiệu, đương nhiên sẽ dùng đến signal() để tăng value đó lên, từ đó caller đang đợi lệnh wait() có thể tiếp tục hoạt động. Để hiểu rõ hơn hãy xem phác thảo dưới đây.

Semaphore

Sau khi đã biết cách sử dụng DispatchSemaphore, chúng ta sẽ áp dụng nó vào các use case khác nhau.

Use case 1

Trong trường hợp này, chúng ta sẽ đồng bộ hóa 2 job bất đồng bộ trong một concurrent queue. Bên cạnh đó, chúng ta cũng nên kiểm tra param value trong initializer với value bằng 0.

Context: Ta có một concurrent queue chứa 2 job bất đồng bộ, Download Image và Download Frame. Chúng ta cần thực hiện cả 2 download một lúc – vừa image vừa frame, rồi kết hợp chúng vào 1 cái, giả sử như Download Frame. 

let queue = DispatchQueue(label: "queue", attributes: .concurrent)
let semaphore = DispatchSemaphore(value: 0)

// Download Image job.
queue.async {
    Thread.sleep(forTimeInterval: 0.5)
    print("Downloaded image.")
    let signal = semaphore.signal()
    print("Signal:", signal)
}

// Download Frame job.
queue.async {
    Thread.sleep(forTimeInterval: 0.9)
    print("Downloaded frame.")
    // Await Download Image job to complete.
    semaphore.wait()
    print("Combine image and frame.")
}

// Downloaded frame.
// Downloaded image.
// Combine image and frame.
// Signal: 1

Ta đã tạo một semaphore có value ban đầu bằng 0 tức là dù cho có call wait() đầu tiên nào thì nó cũng phải đợi cho đến khi có call signal(). Nó rất có ích khi bạn muốn dùng semaphore như một lock hoặc một flag đồng bộ vì bạn không biết hoặc không có nhiều resouces. Quay lại phần code trên, Thread.sleep(forTimeInterval:) chỉ đang mô phỏng quá trình download tiêu tốn cả mớ thời gian để hoàn thành. Dù cho job Download Frame sẽ xong trước, nó vẫn phải đợi cho job Downloaf Image hoàn thành trước khi đến bước tiếp theo.

semaphore.wait() sẽ giảm value của semaphore, từ 0 xuống -1, và bắt đầu đợi. Ngược lại, khi semaphore.signal() được gọi, nó sẽ tăng value của semaphore về lại 0 và ra hiệu cho job Download Frame để tiếp tục vận hành.

Điều thú vị ở đây đó là nếu ta đảo Thread.sleep(forTimeInterval:) giữa 2 job để job Download Image xong trước, thì mọi thứ vẫn chạy bình thường trừ một điểm khác biệt nhỏ.

// Downloaded image.
// Signal: 0
// Downloaded frame.
// Combine image and frame.

Bạn đã phát hiện ra chưa? Đó chính là value của signal. Trong tình huống trước, value của nó là 1, còn bây giờ là 0. Có nghĩa là gì? Thứ tự call của signal() and wait() không còn qaun trọng nữa nếu như bạn cân bằng nó. Nếu call wait() hiện trước call signal() và có cái đang đợi tín hiệu, thì signal() sẽ trả về một value khác 0. Ngược lại, nó trả về value 0 đồng nghĩa rằng không có job nào phải đợi để hoạt động, và call wait() tương ứng sẽ return ngay lập tức.

Bản phác họa này sẽ giúp bạn dễ hiểu hơn.

Use case 1

Use case 2

Trong một vài trường hợp, chúng ta cần giới hạn số lượng concurrent job. Ví dụ, chúng ta cần download một mớ images nhưng chỉ muốn tải một lúc 2 cái. Việc này là hoàn toàn có thể bằng API cấp cao hơn OperationQueue. Duối đay là cách sử dụng semaphore như một resource pool.

Context: Chúng ta có một concurrent queue. Ta gắn khá nhiều job Download Image vào queue này và chỉ tối đa 2 job chạy cùng lúc.

let queue = DispatchQueue(label: "queue", attributes: .concurrent)
let semaphore = DispatchSemaphore(value: 2)

for i in 0 ..< 10 {
    queue.async {
        semaphore.wait()
        print("Downloading image", i)
        let timeInterval: TimeInterval = 0.5 + (arc4random_uniform(2) == 0 ? 1.0 : -1.0) * 1.0 / Double(arc4random_uniform(10) + 1)
        Thread.sleep(forTimeInterval: timeInterval)
        print("Downloaded image", i)
        semaphore.signal()
    }
}

// Downloading image 0
// Downloading image 1
// Downloaded image 0
// Downloading image 2
// Downloaded image 2
// Downloading image 3
// Downloaded image 1
// Downloading image 4
// Downloaded image 4
// Downloading image 5
// Downloaded image 3
// Downloading image 6
// Downloaded image 5
// Downloading image 7
// Downloaded image 6
// Downloading image 8
// Downloaded image 7
// Downloading image 9
// Downloaded image 9
// Downloaded image 8

Ở đây, tôi đã random timeInterval để mô phỏng thời gian download. Nhìn vào log bạn sẽ thấy ban đầu chỉ có image 0 và 1 được downlaod cùng lúc. Khi image 0 đã hoàn thành, image 2 tiếp nối, và số lượng concurrent download vẫn là 2 cái. Nó sẽ như vậy cho đến khi tất cả các images được down về.

Use case 2

Kết luận

Semaphore là một tool vừa đơn giản lại vừa giúp ích cho việc xử lý các vấn đề về concurrency. Nó cùng với các APIs khác trong GCD, và các API cấp cao hơn như OperationQueue sẽ còn giúp bạn xử lý được nhiều vấn đề phức tạp hơn thế nữa.

TopDev via Vinh Nguyen’s Blog

Câu chuyện khởi nghiệp từ giảng đường đại học đến “ông lớn công nghệ” ngành kim hoàn Việt

Được thành lập từ tháng 4/2009, là một trong những đơn vị tiên phong trong việc áp dụng công nghệ thông tin vào lĩnh vực vàng bạc, đá quý, những nỗ lực của công ty Phần Mềm Vàng đã thực sự mang lại những chuyển biến tích cực cho ngành kinh doanh này và được đông đảo người dùng tin tưởng và công nhận, thể hiện qua các giải thưởng mà công ty đã nhận được như Giải thưởng Danh hiệu Sao Khuê 2015, Giải thưởng “Thương hiệu đẳng cấp, uy tín năm 2014“ hay giấy khen của Sở Công Thương TP.HCM vì tham gia tích cực các hoạt động năm 2016, 2017.

Mới đây nhất, Phần Mềm Vàng đã thành công trong việc “mobile hóa”, cung cấp ứng dụng  quản lý dành riêng cho các doanh nghiệp vàng bạc đá quý đầu tiên tại Việt Nam có mặt trên Android và iOS. Nhưng ít ai ngờ, đằng sau những thành công đó là một câu chuyện khởi nghiệp đầy thú vị.

Hôm nay, TopDev có may mắn được trò chuyện cùng anh Đinh Xuân Ánh – Phó Giám đốc công ty Phần Mềm Vàng, và lắng nghe những câu chuyện thú vị đó.

1.Khởi nghiệp từ giảng đường đại học

Ít ai có thể ngờ rằng, cách đây hơn 10 năm trước tại trường Đại Học Bách Khoa, một thành viên ban giám đốc lúc bấy giờ còn là sinh viên khoa Điện tử – Viễn thông đã tự mày mò tìm hiểu và cùng bạn bè phát triển phần mềm quản lý kinh doanh vàng bạc. Ý tưởng xuất phát từ chính nhu cầu thực tế của gia đình mình, giúp bố mẹ giảm bớt gánh nặng trong việc quản lý công việc kinh doanh. Viết cho gia đình sử dụng, tưởng dễ mà khó vì phải thuyết phục, động viên, có lúc phải… năn nỉ, lúc thì “đấu tranh quyết liệt”. Và rồi, phần mềm sau đó đã đi vào hoạt động ổn định, việc quản lý hàng hóa, tiền bạc… nay đã trở nên đơn giản. Càng làm lại càng cảm thấy hứng thú, cảm thấy đam mê và nhận thấy tiềm năng của ngành này là rất lớn. Chính vì vậy, tháng 4/2009 Công Ty TNHH TM & DV Tin Học Phần Mềm Vàng được ra đời với định hướng cung cấp giải pháp quản lý toàn diện dành riêng cho các doanh nghiệp vàng bạc đá quý. Sau 9 năm hoạt động, Phần Mềm Vàng đã có hơn 3000 khách hàng trên toàn quốc với các giải pháp quản lý đa dạng đáp ứng các qui mô và hình thức kinh doanh: từ các gói phần mềm cơ bản như in tem nhãn nữ trang, quản lý cầm đồ đến các phần mềm quản lý mua bán vàng bạc, kim cương hay phần mềm quản lý bán sỉ (chành vàng) đến cả phần mềm quản lý chuỗi cửa hàng vàng, phần mềm quản lý xưởng chế tác nữ trang, ứng dụng quản lý mua bán vàng trên máy tính bảng…. Cùng với việc phát triển sản phẩm, Phần Mềm Vàng còn chú trọng đến dịch vụ khách hàng với đội ngũ nhân viên kỹ thuật được huấn luyện nghiệp vụ, làm việc trách nhiệm, nhiệt tình, ngay cả cuối tuần hay lễ tết vẫn vào ca trực hỗ trợ khách hàng.

2. Vườn ươm tài năng cho các lập trình viên trẻ

Với xuất phát điểm là những người khởi nghiệp từ giảng đường đại học, ban lãnh đạo công ty Phần Mềm Vàng luôn mong muốn tạo cơ hội cho các lập trình viên mới ra trường có cơ hội học hỏi, cọ xát thực tế từ chính công việc hàng ngày!

Chính vì vậy công ty luôn rộng cửa chào đón những lập trình viên trẻ tuổi, nhiệt tình và tràn đầy tâm huyết. Anh cũng không quên nhắn nhủ các bạn sinh viên hãy chủ động giới thiệu các dự án từng tham gia trong quá trình học tại trường hay đi thực tập… trong hồ sơ xin việc để giúp nhà tuyển dụng có thêm thông tin về ứng viên vì sinh viên mới ra trường chưa có nhiều kinh nghiệm đi làm thực tế!

Anh Ánh tự hào chia sẽ thêm: “Chúng tôi không chọn bằng cấp, trường lớp mà chú trọng đến năng lực riêng của ứng viên để quyết định tuyển dụng. Qua 9 năm, chúng tôi đã có nhiều thế hệ nhân viên trưởng thành từ mái nhà Phần Mềm Vàng và trong số đó, có không ít nhân viên lập trình của chúng tôi ngày nào nay giữ chức vụ quản lý tại nhiều công ty phần mềm lớn”.

Giải bóng đá ngành kim hoàn – sân chơi thể thao do Phần Mềm Vàng khởi xướng và tổ chức đã có 3 mùa giải thành công

Bên cạnh việc tạo điều kiện tối đa cho các lập trình viên nâng cao kĩ năng chuyên môn thông qua các buổi training nội bộ, hỗ trợ chi phí cho các khoá học ở trung tâm ngoài hay khuyến khích nhân viên tham gia các buổi hội thảo, sự kiện chuyên ngành. Công ty cũng rất chú trọng đến việc nâng cao đời sống xã hội của các lập trình viên thông qua các hoạt động ngoại khóa:

  • Các hoạt động thể thao như tổ chức Giải Bóng đá Ngành Kim Hoàn
  • Tạo nhiều cơ hội cho những bạn lập trình viên thích ca hát thể hiện tài năng trong các sự kiện thường niên của công ty, hay đầu tư tham gia Hội thi Tiếng hát ngành Kim hoàn…
  • Các developers thích diễn xuất hay nấu ăn có thể thoải mái trổ tài trong các kì teambuilding và dã ngoại thường niên,…

Câu nói của một nhân viên làm việc lâu năm của công ty: “Ở Phần Mềm Vàng, chữ TÌNH lớn hơn chữ TIỀN” đã chứng minh cho tất cả

3. Nhìn lại những chặng đường đã qua

Để có được những thành công như ngày hôm nay, Phần Mềm Vàng cũng trãi qua không ít những thăng trầm những ngày đầu lập nghiệp.

Anh Ánh nhớ lại những ngày đầu thành lập công ty cũng gặp vô số những khó khăn, bài toán nan giải nhất cần giải quyết là ” thay đổi tư duy người dùng” . Vì đa số các doanh nghiệp kinh doanh vàng đều không có nhiều kiến thức về công nghệ thông tin, chính vì thế yêu cầu về phần mềm phải đơn giản, tiện dụng được ưu tiên hàng đầu! Thêm nữa, đặc thù và tập quán kinh doanh của mỗi vùng miền lại khác nhau! “Bài toán khó đặt ra cho chúng tôi là phải đáp ứng các nghiệp vụ phức tạp bằng các giao diện thân thiện, thao tác đơn giản”, anh chia sẻ. Để giải bài toán này, nhóm phát triển đã phải tham khảo và nghiên cứu nhiều loại công nghệ khác nhau để chọn ra giải pháp có thể tối ưu hoá cả quản lý nghiệp vụ và trải nghiệm người dùng. Lựa chọn công nghệ phù hợp với đối tượng khách hàng, thân thiện với trải nghiệm người dùng có thể nâng cấp và bảo trì dễ dàng – một điều tưởng dễ nhưng không dễ trong ngành đặc biệt này là những điều mà anh Ánh cũng những các đồng nghiệp của mình luôn trăn trở, và tìm giải pháp tối ưu hóa ứng dụng của mình để ngày càng làm hài lòng những khách hàng khó tính nhất.

Anh Ánh cho biết thêm một trong những dự án đầy thử thách với công ty chính là phần mềm quản lý xưởng chế tác vàng. Gọi là thử thách vì qui mô xưởng không chỉ khác biệt (từ 5 – 10 thợ đến xưởng hàng trăm thợ) mà chính là cách quản lý mỗi nơi mỗi khác! Hơn thế nữa, quản lý sản xuất vốn là một phân hệ chiếm tỉ trọng lớn trong các hệ thống ERP có chi phí không hề thấp. Hơn nữa, nếu chỉ dừng lại ở việc quản lý xuất – nhập thì chưa phải là phần mềm!

4. Vẫn còn đó những trăn trở với ngành vàng

Anh Ánh cho biết theo số liệu thống kê, Việt Nam có hơn 12.000 doanh nghiệp lớn nhỏ kinh doanh vàng bạc đá quý. Trong đó, chiếm phần lớn là các doanh nghiệp kinh doanh theo qui mô gia đình, buôn bán tại địa phương và số lượng doanh nghiệp đầu tư xây dựng thương hiệu, kinh doanh theo mô hình chuỗi cửa hàng còn rất khiêm tốn.

Mặt khác, sự đổ bộ của các nhãn hiệu trang sức cao cấp nổi tiếng trên thế giới là một thách thức không hề nhỏ đối với các doanh nghiệp nội địa. Tại các trung tâm thương mại lớn – nơi tụ họp nhiều khách hàng tiềm năng của ngành này, khoảng cách định vị thương hiệu của các doanh nghiệp Việt Nam so với các thương hiệu nước ngoài càng được chứng minh rõ hơn. Ngoài ra, trong khi các tập đoàn nữ trang quốc tế thường nhắm đến phân khúc cao cấp và có đầu tư kĩ lưỡng vào các kênh phân phối, các doanh nghiệp Việt chỉ có các cửa hàng nhỏ lẻ với quy mô rất hạn chế vì “không có thương hiệu”, hay thậm chí nhiều chủ cửa hàng đã hài lòng với quy mô hiện có và không có ý định mở rộng kinh doanh dù không thiếu nguồn vốn!

Là ngành kinh doanh truyền thống “cha truyền con nối”, các hộ gia đình kinh doanh mặt hàng này thường trung thành với phương thức kinh doanh đã có từ bao đời, tập trung vào duy trì quy mô vừa và nhỏ, thiếu kế hoạch dài hạn mở rộng quy mô kinh doanh. Mặt khác, các chủ doanh nghiệp vàng bạc Việt khá bảo thủ trong việc thay đổi nghiệp vụ quản lý và tập quán kinh doanh vì họ cho rằng truyền thống kinh doanh thành đạt qua nhiều đời là bằng chứng thực tế và đáng tin tưởng nhất.

Từ kinh nghiệm thực tế, anh Ánh cho biết đối với các chủ doanh nghiệp, phần mềm là sản phẩm công nghệ hữu hình nhưng lại vô hình! Hữu hình tức là tuy đã cài đặt vào máy tính, có giao diện, có “mặt mũi” hẳn hoi nhưng lại vô hình vì khách hàng chưa thể hình dung những lợi ích mang lại như thế nào! Do đó, khó khăn ở đây nằm ở việc truyền thông tính hiệu quả và thực tế của các sản phẩm công nghệ.

 

GOLD SOFTWARE CO.,LTD

Website: https://www.phanmemvang.com.vn/

Fanpage: https://www.facebook.com/phanmemvang.com.vn/

TopDev

Làm thế nào để sử dụng SVG như một Placeholder, và các phương pháp Image Loading khác

Tác giả: José M. Pérez

Tôi rất quan tâm đến việc tối ưu hóa chất lượng image và làm sao cho ảnh load nhanh hơn trên web. Một trong những area thú vị nhất là placeholder: khi image chưa load xong thì nên hiển thị cái gì.

Trong những ngày qua tôi có tìm được một số kỹ thuật loading sử dụng SVG, và tôi sẽ kể chi tiết hơn trong bài viết này.

Trong bài này chúng ta sẽ nói về các chủ đề:

  • Sơ lược về các loại placeholder.
  • Các placeholder sử dụng SVG (các edges, shapes và silhouettes)
  • Auto hóa process.

Sơ lược về các dạng placeholder khác nhau 

Khi thực hiện kĩ thuật lazy-load cần phải nghĩ xem cần render cái nào như một placeholder, vì nó có ảnh hưởng lớn đến sản phẩm mà user tiếp nhận. Tôi đã từng đưa ra nhiều options sau:

Có rất nhiều phương pháp để bỏ vào vùng image trước khi nó load.

  • Để trống vùng: Trong xu hướng thiết kế responsive design hiện nay, việc này giúp tránh việc content bị nhảy lung tung. Các thay đổi của layout không chỉ không tốt từ khía cạnh trải nghiệm người dùng, mà còn đối với chất lượng (performance). Browser buộc phải tính toán lại layout mỗi lần nó fetch độ phân giải của hình ảnh, để trống chỗ đó.
  • Placeholder: Hãy tưởng tượng rằng chúng ta đang hiển thị ảnh profile của một user. Chúng ta muốn hiển thị một silhouette ở background. Nó sẽ hiện ra khi hình ảnh đã được load, và khi request bị fail hoặc khi user chưa chọn ảnh profile nào. Những hình ảnh này thường là ảnh vector, và nhờ có size nhỏ nên chúng rất dễ để chèn.
  • Solid Colour (Màu cố định): Chọn một màu từ hình ảnh và dùng nó như màu background của placeholder. Nó có thể là màu trội nhất, sáng nhất,… Mục đích của nó là nó dựa trên màu của ảnh bạn load lên để làm cho sự chuyển tiếp từ không có ảnh đến ảnh đã được load trông mượt mà hơn.
  • Ảnh mờ: Còn được gọi là kĩ thuật blur-up. Bạn render version nhỏ của ảnh rồi chuyển tiếp đến version đầy đủ của nó. Cả pixel và kB của ảnh đầu tiên đều rất nhỏ. Để loại bỏ các artifacts, ảnh sẽ được phóng to ra và làm mờ đi.

Hóa ra là còn rất nhiều dạng khác và rất nhiều người tài năng khác đang phát triển các phương pháp tạo placeholder khác.

Một trong số đó sử dụng màu gradient thay vì màu solid. Màu gradient cho ra bản preview ảnh final chính xác hơn, với dung lượng rất thấp (tăng phần payload).

Một phương pháp khác đó là sử dụng các image dựa trên SVG, đang thu hút nhiều sự chú ý sau các thử nghiệm gần đây.

Các Placeholder dùng SVG

Chúng ta đều biết SVG rất thích hợp cho ảnh vector. Đa số chúng ta đều muốn load ảnh bitmap, vì thế câu hỏi ở đây là làm sao để vector hóa hình ảnh. Một vài option gồm có sử dụng edges, shapes và silhouettes.

Edges

Mục tiêu ban đầu của tôi đó là phác thảo ra các vùng, vector hóa hình ảnh, nhưng tôi không biết phải làm sao. Và rồi nhận ra rằng sử dụng edges cũng có thể hiệu quả và tôi đã quyết định animate nó tạo ra hiệu ứng “drawing”.

Shapes

SVG có thể được dùng để vẽ area từ ảnh thay vì edges/ borders. Từ đó, chúng ta sẽ vector hóa một ảnh bitmap để tạo placeholder.

Trước đây tôi đã cố làm gì đó tương tự với những hình tam giác.

Code trên đây là một ví dụ về placeholder sử dụng SVG bao gồm 245 hình triangles. Gốc gác của chúng dựa trên Delaunay triangulation sử dụng polyserver của Possan. Đúng như mong đợi, size của file sẽ càng lớn khi SVG sử dụng càng nhiều triangles.

Primitive và SQIP, kĩ thuật LQIP dựa trên SVG

Tobias Baldauf đang hoàn thiện một kĩ thuật Image Placeholder Chất lượng thấp gọi là SQIP. Trước khi bàn sâu về SQIP tôi sẽ cho bạn một bản sơ lược về Primitive, một thư viện dựa trên SQIP.

Primitive rất tuyệt vời và tôi vô cùng ủng hộ việc bạn thử nó. Nó chuyển ảnh bitmap thành một SVG gồm nhiều shape chồng lên nhau. Size của nó nhỏ nên rất thích hợp cho việc chèn thẳng vào page. Đỡ đi một vòng và ta có được một placeholder ngay trong payload HTML ban đầu.

Code cho SVG với 10 shapes là rất nhỏ, khoảng 1030 bytes, có thể giảm xuống 640 bytes khi pass output qua SVGO.

<svg xmlns=”http://www.w3.org/2000/svg" width=”1024" height=”1024"><path fill=”#817c70" d=”M0 0h1024v1024H0z”/><g fill-opacity=”.502"><path fill=”#03020f” d=”M178 994l580 92L402–62"/><path fill=”#f2e2ba” d=”M638 894L614 6l472 440"/><path fill=”#fff8be” d=”M-62 854h300L138–62"/><path fill=”#76c2d9" d=”M410–62L154 530–62 38"/><path fill=”#62b4cf” d=”M1086–2L498–30l484 508"/><path fill=”#010412" d=”M430–2l196 52–76 356"/><path fill=”#eb7d3f” d=”M598 594l488–32–308 520"/><path fill=”#080a18" d=”M198 418l32 304 116–448"/><path fill=”#3f201d” d=”M1086 1062l-344–52 248–148"/><path fill=”#ebd29f” d=”M630 658l-60–372 516 320"/></g></svg>

Những hình ảnh được tạo bằng 100 shapes thì lớn hơn, nặng khoảng 5kB sau khi qua SVGO (trước đó là 8kB). Mức độ chi tiết của chúng cao hơn với payload vẫn nhỏ. Quyết định về số lượng triangles cần dùng sẽ phụ thuộc nhiều vào dạng hình ảnh (ví dụ contrast, lượng màu, complexity) và mức độ chi tiết.

Ta có thể tạo một script tương tự như cpeg-dssim mà kéo lượng shapes được dùng cho đến khi chạm đến ngưỡng tương đồng về cấu trúc ( hoặc một lượng shapes tối đa trong trường hợp xấu nhất).

Những kết quả SVG này cũng tốt khi sử dụng như hình background. Nhờ có size được khống chế và nền tảng dựa trên vector mà chúng rất phù hợp cho hero image và các background lớn mà không hiện các artifact.

SQIP

Theo chính lời của Tobias:

SQIP như một nỗ lực tìm sự cân bằng giữa 2 cực: nó tận dụng Primitive để tạo ra một SVG bao gồm nhiều shapes đơn giản xấp xỉ với features chính hiển thị trong hình, tối ưu hóa SVG bằng SVGO và thêm vào đó một Gaussian Blur filter. Nó giúp cho ra một SVG placeholder nặng chỉ khoảng 800 – 1000 bytes, nhìn mượt hơn trên screen.

Kết quả cho ra thì tương tự như việc sử dụng placeholder image nhỏ trong phương pháp blur-up (như Medium và các sites khác đã làm). Sự khác nhau đó là thay vì sử dụng ảnh bitmap, ví dụ JPG hay WebP, thì placeholder là SVG.

Nếu chúng ta chạy SQIP trên ảnh gốc nó sẽ như thế này:

Cái SVG output là khoảng 900 bytes, và trong đoạn code chúng ta có thể thấy filter feGaussianBlur được áp dụng với nhóm shapes:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 2000 2000"><filter id="b"><feGaussianBlur stdDeviation="12" /></filter><path fill="#817c70" d="M0 0h2000v2000H0z"/><g filter="url(#b)" transform="translate(4 4) scale(7.8125)" fill-opacity=".5"><ellipse fill="#000210" rx="1" ry="1" transform="matrix(50.41098 -3.7951 11.14787 148.07886 107 194.6)"/><ellipse fill="#eee3bb" rx="1" ry="1" transform="matrix(-56.38179 17.684 -24.48514 -78.06584 205 110.1)"/><ellipse fill="#fff4bd" rx="1" ry="1" transform="matrix(35.40604 -5.49219 14.85017 95.73337 16.4 123.6)"/><ellipse fill="#79c7db" cx="21" cy="39" rx="65" ry="65"/><ellipse fill="#0c1320" cx="117" cy="38" rx="34" ry="47"/><ellipse fill="#5cb0cd" rx="1" ry="1" transform="matrix(-39.46201 77.24476 -54.56092 -27.87353 219.2 7.9)"/><path fill="#e57339" d="M271 159l-123–16 43 128z"/><ellipse fill="#47332f" cx="214" cy="237" rx="242" ry="19"/></g></svg>

SQIP cũng có thể cho ra một tag ảnh với các content SVG Base 64:

<img width="640" height="640" src="example.jpg” alt="Add descriptive alt text" style="background-size: cover; background-image: url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAw…<stripped base 64>…PjwvZz48L3N2Zz4=);">

Silhouettes

Chúng ta vừa điểm qua cách dùng SVG cho edges và các primitive shapes. Mikael Ainalem đã chia sẻ một codepen vài ngày trước chỉ cách sử dụng silhouette 2 màu như một placeholder. Kết quả cho ra rất đẹp:

Các SVG trong trường hợp này được vẽ tay, nhưng phương pháp này nhanh chóng sản sinh ra các tool giúp tự động hóa quá trình.

  • Gatsby, một static site generator sử dụng React để hỗ trợ các SVG cần theo dõi này. Nó sử dụng một JS PORT của potrace để vector hóa images.

Summary

Chúng ta đã thấy rất nhiều tool và kĩ thuật tạo SVG từ image và dùng chúng như các placeholder. Chúng ta có thể kiểm soát được mức độ detail (và cả size), nó rất dễ nén và dễ thao tác trên CSS và JS.

Tham khảo thêm các vị trí tuyển dụng it không cần kinh nghiệm tại Topdev

Bài viết gốc được đăng tải tại medium.freecodecamp

6 điều tôi vỡ lẻ khi tự học code (P2)

Nguồn ảnh: REUTERS/Kacper Pempel

Phần 1: 6 điều tôi vỡ lẻ khi tự học code (P1)

  1. Mặc kệ người ta nói! Cứ thử những cái mới!

Tôi đã dùng đủ mọi cách, từ vùi đầu vào sách, cho tới thử các khoá học online. Không cái nào giúp được tôi cả. Thậm chí tôi cũng đã thử tham gia một số diễn đàn nhưng nó càng làm mọi thứ trở nên “tùm lum tà la” hơn . Cuối cùng, tôi cũng tìm ra được một số khóa học bằng video vừa ý và mọi thứ bắt đầu trở nên dễ dàng hơn.

Bạn cứ thử hết tất cả đi, xem videos, đọc sách, mua các khóa học trực tuyến, tham gia diễn đàn, không bổ chiều ngang cũng bổ chiều dọc. Nếu mà đâm đầu vào đọc sách không, chắc tôi cũng “Tạch” từ lâu rồi, thật!. Hồi xưa tôi không ưa video, nhưng xài thử mới thấy sự lợi hại. Nó giúp bạn chủ động thời gian một cách kinh khủng.

Cách học tốt nhất tôi đã tìm ra là chú ý vào bản chất của ngôn ngữ, hơn là những thứ lằng nhằng râu ria khác, có thể thử học 7-8 ngôn ngữ cùng một lúc. Nghe có vẻ hơi căng, nhưng đối với bản thân mình, tôi thấy nó lại phát huy hiệu quả một cách bất ngờ. Hiện nay, tôi đã nắm chắc được 5 ngôn ngữ, mấy cái ngôn ngữ còn lại dành để giải trí những lúc rảnh (ahihi). Như bạn biết, tôi là người cả thèm chóng chán, tôi hay bỏ giữa chừng lắm, tôi thường thay đổi khẩu vị cho đỡ ngán, như chuyện chuyển đổi từ việc xây dựng SQL database đến việc tìm hiểu các về pointers trong C, đến học về Git. Thử đi, nó giúp mở rộng tư duy kinh luôn ấy.

Những cái trên có thể phù hợp với tôi, nhưng chưa chắc nó hợp với bạn. Quan trọng là phải thử cả.

  1. Chọn cái mà bạn cảm thấy mình làm “ngon” nhất.

Tôi thích vọc các text editor mới. Cá nhân tôi đã thử qua một số Linux Distro phổ biến trước khi quyết định “an phận” các công cụ hiện tại. Đừng nghe người ta nói gì cả, cứ thử hết đi. Tôi cực thích những thứ là lạ so với những gì bà con hay dùng (ví dụ tôi yêu php) nhưng tôi cũng theo cộng đồng ở một số cái, vì nhiều khi nó dùng ngon thật. (Như việc dùng Linux đã thay đổi toàn bộ quy trình làm việc của tôi, nó khiến mọi thứ trở nên tốt hơn rất nhiều)

Đừng bao giờ dành cả tuổi thanh xuân vì một thứ chỉ vì một lời khen trên một diễn đàn hoặc blog công nghệ nào đó.

  1. Tri thức làm ta khiêm tốn, ngu si làm ta kiêu ngạo.

Khiêm tốn là yếu tố quyết định thành công, dù ở bất cứ nơi đâu. Vì tính chất công việc, tôi thường không có quá nhiều cơ hội làm việc với các developers khác, và hầu hết các khách hàng của tôi đều không biết hoặc không quan tâm đến code. Tôi luôn tâm niệm rằng khiêm tốn là chiếc cầu để tôi có thể làm việc tốt với các developers khác. Chắc bạn đã quá hiểu chuyện làm việc với các lập trình viên không phải là dễ nuốt, vì họ thường không có nhiều kỹ năng giao tiếp lắm. Kết quả là…nhiều khi dự án kết thúc mà 2 bên đều không happy, kiểu “bằng mặt mà không bằng lòng”.

Khi có cơ hội làm việc với một team đỉnh, ai cũng tập trung cao độ cũng như tôn trọng ý kiến của nhau, bạn sẽ thấy được sức bật khủng khiếp của team đó như thế nào. Hãy nhớ rằng con cá chắc chắn sẽ không bao giờ biết leo cây, hãy nhìn vào thế mạnh của người đồng đội của mình và tận dụng nó tối đa. Dù trở thành một team player hay leader, thì việc mở lòng để thật sự hiểu nhau khi làm việc chính là chiếc chìa khoá cho sự thành công.

Tôi luôn giữ cho mình một tâm thế cầu thị, mở lòng cho những cái mới. Bạn nên tự thôi thúc chính mình bằng những câu hỏi kiểu như “làm sao cho code đơn giản hơn, chạy ngon hơn”. Nhiều khi những cái đơn giản thì lại cần rất nhiều thời gian để thấu hiểu và chiêm nghiệm.

Tôi hi vọng bài viết này phần nào có thể giúp các bạn có những cái nhìn khác trong lập trình. Lập trình tuy khó, nhưng khi chinh phục được nó thì sẽ cảm thấy rất “yo-most!”.

Cảm xúc lập trình có đủ cả, nó cho phép bạn sáng tạo, giải quyết vấn đề, v.v. Từ trước đến nay chỉ có lập trình mới khiến tôi lăng xả làm việc thâu đêm. Chỉ có vậy thôi! Hãy tiếp tục code thật nhiều nhé.

100++ cơ hội lập trình Mobile ấn tượng bạn không thể bỏ qua

4 lỗi mọi người thường mắc phải khi viết CV

Cạnh tranh cho một vị trí hấp dẫn trong các công ty ngày càng trở nên khốc liệt hơn đặc biệt trong thời đại này, sẽ rất khó để làm nổi bật bản thân nhưng một CV hoàn hảo sẽ giúp bạn làm điều đó. Nếu không biết làm cách nào để cải thiện CV của mình, hãy đọc qua một số lỗi mà chúng ta thường mắc phải để tránh sau này.

Lỗi cú pháp và chính tả

Đây là một lỗi khá thường gặp. Đã bao nhiêu lần bạn bị phàn nàn về lỗi chính tả trong CV của mình? Thường thì đây là điều đầu tiên các nhà tuyển dụng chú ý đến khi xem CV của bạn. Nhưng đôi khi, họ thậm chí không để ý đến các lỗi này.

Chỉ có một cách duy nhất để tránh mắc phải lỗi này là hãy đọc thật kĩ và kiểm tra thật nhiều lần. Nếu bạn không chắc chắn về ngữ pháp, hãy nhờ bạn bè, đồng nghiệp hoặc ngay cả một nhà tuyển dụng mà bạn quen biết. Họ sẽ giúp bạn sửa những lỗi này.

Những cơ hội việc làm cực hot dành riêng cho Fresher

Dùng một CV cho nhiều vị trí

Bạn có chỉnh sửa CV áp dụng cho mỗi vị trí? Nếu không, hãy làm điều đó từ bây giờ.

Nhiều người thường chỉ dùng một CV cho rất nhiều công việc. Mọi người thường cảm thấy nên xin tuyển nhiều nơi để tăng cơ hội nhận được lời mời phỏng vấn, nhưng điều này chỉ làm giảm cơ hội của chính bạn mà thôi.

Hầu hết các nhà tuyển dụng sử dụng tool để giúp họ tìm kiếm CV bằng các từ khoá nhất định. Nếu bạn đang sử dụng CV mẫu, có thể sẽ không có các từ khóa mà họ tìm kiếm trong CV của bạn.

Dùng một CV cho nhiều vị trí giúp bạn tiết kiệm thời gian, nhưng người tuyển dụng có thể sẽ không hài lòng vì liệu họ có thực sự muốn thuê ai đó mà thậm chí không dành thời gian để chỉnh sửa CV cho họ?

Thiết kế xấu

Khi bạn phải cạnh tranh với CV của các ứng viên khác, một CV với thiết kế bắt mắt sẽ tạo ấn tượng với các nhà tuyển dụng. Hãy dừng ngay việc tạo CV bằng một trang Word nhàm chán, một thiết kế thú vị sẽ làm cho CV của bạn hấp dẫn hơn!

Thế nhưng thiết kế có thể là một con dao hai lưỡi. CV sẽ trở nên quá nhiều hoặc lộn xộn vì bạn không phải dân thiết kế.

Một trang word đơn giản cũng có thể mắc lỗi thiết kế, vì vậy đừng nghĩ rằng sẽ an toàn nếu bạn dính vào một tài liệu Word cơ bản.

Dùng mẫu CV hoặc gửi CV của bạn tới người khác để xem xét trước khi “apply” vào các công ty.

Thiếu các “động từ mạnh”

Bạn có nhớ giáo viên dạy tiếng Anh ở trường trung học nói về tầm quan trọng của động từ mạnh không? Người đọc sẽ chú ý nhiều hơn nếu thấy những động từ mạnh trong CV của bạn.

Các điểm được chú ý với các công ty trong CV của bạn là những “achivement” mà bạn đã có. Do đó hãy sử dụng động từ mạnh để mô tả những gì bạn đã làm trong sự nghiệp của mình. Thay vì nói  “chịu trách nhiệm design cho một ứng dụng di động”, hãy nói rằng bạn đã thiết kế nó.

Điều này cũng giúp bạn tránh đưa ra những thông tin mơ hồ. Xác định chính xác những gì bạn đã làm.

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

Nếu bạn thấy bất kỳ vấn đề nào trong số những vấn đề này với CV của bạn, đừng lo lắng. Bạn có thể sửa chúng trước khi bạn bắt đầu nộp đơn xin việc và sẽ thành công thôi!

TopDev via Inteqna

  Bí mật giúp bạn thành công khi phỏng vấn (P1)

6 điều tôi vỡ lẻ khi tự học code (P1)

Nguồn ảnh: REUTERS/Kacper Pempel

Tôi được khuyến khích và muốn chia sẻ kinh nghiệm của mình để bản thân vui hơn, vì vậy tôi viết bài này để các bạn đến sau hiểu được nhiều hơn con đường mình đi. Hãy lưu ý rằng chuyên ngành của tôi là phát triển web, vì vậy stack của tôi phản ánh điều đó.

1. Hãy sẵn sàng vứt bỏ tất cả mọi thứ, kể cả những thứ tốt nhất, giải pháp hợp lí mới giải quyết mọi vấn đề.

Điều này đúng với mọi khía cạnh từ code đến các ngôn ngữ lập trình đến ý tưởng. Lập trình thay đổi rất nhanh và có rất nhiều cách hay để tiếp cận các vấn đề, nhưng cần nhớ rằng tìm ra giải pháp mới là lý do của lập trình. Mục đích chính là giải quyết vấn đề thành công chứ không phải về quá trình tìm ra cách giải quyết. Bạn chắc hẳn sẽ rất tức giận hoặc có những hành động bồng bột khi gặp tình huống sau: Bạn dành 2 ngày để viết code hoặc xây dựng một page, bỗng nhiên có người bước ngang qua và chỉ ra một giải pháp nhanh hơn / tốt hơn?!

Nếu bạn tập trung vào giải pháp tốt nhất, nó sẽ giúp bạn giải quyết code dễ dàng hơn. Gần đây, tôi đã dành 2 ngày xử lý một số flexbox cho một dự án và đối tác kinh doanh của tôi ( họ không phải là dân tech) đã quyết định rằng không có tính năng đó sẽ tốt hơn cho chiến lược phát triển của họ. Trực giác của tôi mách bảo rằng tôi sẽ phát điên lên và không muốn thay đổi code cho dù có chuyện gì xảy ra, nhưng sau khi hít thở sâu vài lần và nghĩ thật thông, tôi nhận ra đối tác của tôi đã nói đúng.

Hơn nữa, nếu tôi trung thực, khách hàng của tôi có thể tiết kiệm được một khoảng thời gian quan tâm đến số giờ tôi đã làm việc để tạo ra widget x hoặc code của y đẹp đến mức nào. Họ chỉ muốn sản phẩm của họ tốt nhất có thể.

2. Ngôn ngữ lập trình bạn đang học không quan trọng bằng ý kiến của mọi người

Tôi chưa bao giờ là fanboy của một công nghệ cụ thể nào, tôi yêu thích Windows 10, và tôi có một máy tính xách tay khác chạy Kubuntu mà tôi rất thích. Tôi cũng thích sử dụng MacBook của vợ tôi.
Tôi đã tiếp cận nhiều ngôn ngữ lập trình cùng một cách. Tôi đã quyết định học vài ngôn ngữ lập trình để phục vụ cho việc kinh doanh của tôi (HTML / CSS / JS * Tôi biết html và css không hẳn là ngôn ngữ lập trình.) và sau đó tôi chọn một vài thứ tôi muốn học, (SQL, Python, Perl, Java), rồi tôi học thêm C vì tôi muốn bổ sung vào trình độ compsci thấp của mình với một ngôn ngữ cơ bản hơn.

Sau khi học xong, tôi đã học được rằng mọi thứ mình học đều có giá trị về lâu về dài. Nếu bạn không có nhu cầu cấp bách học một ngôn ngữ cụ thể nào, hãy thử nhiều thứ cùng lúc và tìm ra ngôn ngữ phù hợp nhất. Hãy tìm hiểu về ngôn ngữ bạn sử dụng nhiều nhất, và quyết tâm học nó bất kể mọi người nói gì. Nếu bạn đam mê ngôn ngữ assembly, nó sẽ giúp bạn đi rất xa trong mảng này.

3. Lập trình thực sự khó như mọi người nói

Khi tôi mới bắt đầu, tôi thực sự nghĩ rằng tôi là một thiên tài có thể hiểu mọi thứ trong vài giờ học. C và CSS đã khiến tôi tỉnh mộng. Tôi đã dành rất nhiều thời gian để hiểu các khái niệm trong CSS khiến tôi có chút thất vọng về bản thân, vì thế tôi đã thay đổi phương châm thành ” Dành đủ thời gian, stack overflow, ghi chép lại để tìm hiểu sâu hơn.”

Nếu bạn hiểu rằng lập trình là khó để theo đuổi, và khi đó bạn sẽ tiếp cận nó với tâm thế sẽ rất khác, bạn sẽ cố gắng hơn, khi gặp khó bạn sẽ coi đó là điều đương nhiên và ít nản lòng hơn, thậm chí xác suất bỏ cuộc giữa chừng cũng thấp hơn. Thay vì thất vọng khi gặp bug hoặc trang bị sập, tôi đã hiểu ra nó là một phần của quá trình và khiến tôi đỡ đau đớn hơn. Đó là sự thật sau một sự kiện không thể tìm ra một dấu chấm phẩy sau hơn 4 tiếng tìm kiếm vào lúc 3 giờ sáng.

Phần 2: 6 điều tôi vỡ lẻ khi tự học code (P2)

Tech Startup Việt – đường ra biển lớn

Từ năm 2016, bối cảnh của cộng đồng Tech startup Việt đã có những bước tiến lớn khi liên tục đón nhận các tin vui như kế hoạch cấp vốn đầu tư trị giá 10 triệu USD từ quỹ đầu tư danh giá 500 Startups, sự xuất hiện của gần 40 quỹ đầu tư nước ngoài với giá trị vốn trên dưới 50 triệu USD, hay hàng loạt các thương vụ đầu tư đình đám vào các startup hoạt động ở nhiều mảng khác nhau như Tiki, Foody, Giao hàng nhanh, …

Tuy nhiên, theo ông Lê Thanh Tâm, Giám đốc Điều hành của Tập đoàn IDG Đông Nam Á chia sẻ, trên 60% công ty khởi nghiệp thất bại, trong đó 70% thất bại ngay trong năm đầu tiên, 90% trong năm thứ hai, và năm thứ ba gặp nhiều khó khăn.

Vậy, cơ hội nào dành cho các Tech startup Việt tiến ra biển lớn? Hãy cùng Techtalk trò chuyện với anh Uy Trần – Managing Director của UpStar Labs tìm hiểu ưu – nhược điểm của các công ty khởi nghiệp Việt và chiến lược chinh phục thị trường thế giới.

1. Thực trạng của cộng đồng Tech startup Việt

Theo anh Uy, các công ty khởi nghiệp công nghệ ở Việt Nam đang có nhiều thuận lợi lớn cần được tận dụng.

Tuy Việt Nam vẫn còn đi sau các nước phát triển khác, nhưng điều này lại là cơ hội cho các startup công nghệ trong nước khi có thể tận dụng nhiều ý tưởng, sản phẩm đã định hình và các bài học kinh doanh trong chiến lược phát triển ở thị trường nước ngoài. Ví dụ như lĩnh vực thương mại điện tử đã có những ông lớn như Amazon, Alibaba,… hay lĩnh vực dịch vụ có Airbnb, Uber,… mà ta có thể học hỏi.

Bên cạnh đó, người dùng Việt khá cởi mở, tiếp nhận công nghệ nhanh chóng, đi cùng với sự phát triển của cơ sở hạ tầng có khả năng cung cấp dịch vụ chất lượng quốc tế với giá thành thấp, giúp các công ty khởi nghiệp tiếp cận được khách hàng và thị trường mục tiêu nhanh chóng và dễ dàng hơn.

Nhóm khách hàng mục tiêu mà các công ty startup công nghệ có thể khai thác đa số tập trung tại thành phố Hồ Chí Minh và Hà Nội, giúp giảm chi phí marketing và tiếp cận khách hàng. Hơn thế nữa, từ năm 2014, nhà nước có nhiều chính sách khuyến khích khởi nghiệp, thành lập nhiều hiệp hội hỗ trợ startup, là một thuận lợi lớn.

Về năng lực kỹ thuật, các startup công nghệ Việt gần như bắt kịp với tốc độ phát triển của thế giới. Nhìn chung, ngoại trừ các công nghệ có tính chất rất đặc thù, khả năng của lập trình viên Việt Nam vẫn đứng trong Top 20 của thế giới.

Tuy nhiên, đi cùng với đó cộng đồng khởi nghiệp Việt còn phải đối mặt với vô số những khó khăn.

Mặc dù tinh thần và văn hóa khởi nghiệp đã được cổ vũ mạnh mẽ ở Việt Nam trong thời gian gần đây, tuy nhiên, các founder trong nước đa số còn thiếu các kiến thức, kỹ năng để quản lý doanh nghiệp do không được đào tạo bài bản, cũng như thiếu cơ hội tiếp cận với những mô hình khởi nghiệp thành công trên thế giới.

Mặt khác, tư duy vận hành của founder Việt cũng là một thử thách không nhỏ. Đa phần các công ty khởi nghiệp công nghệ Việt khi thành lập chỉ mới chú trọng vào các công việc thường ngày như phát triển phần mềm, lập trình… Tuy nhiên, dù có ý tưởng kinh doanh tốt nhưng khách hàng, thị trường mục tiêu không rõ ràng, kỹ năng lãnh đạo và quy trình quản lý không hiệu quả cũng sẽ khiến công ty khó thành công.

Ngoài ra, với tốc độ phát triển công nghệ như hiện nay, các công ty phải luôn trau dồi, cập nhật kiến thức nhanh chóng và kịp thời để đáp ứng được nhu cầu của khách hàng cũng như tăng tính cạnh tranh của mình trên thị trường khi quyết định cho ra một tính năng mới cho sản phẩm.

Hơn thế nữa, cách sử dụng tiền đầu tư hiệu quả hợp lý cũng là một vấn đề cần được lưu tâm. Một số trường hợp sau khi thành công trong việc gọi vốn lại điều chỉnh chiến lược sản phẩm hay đầu tư trái ngành thay vì tập trung cho định hướng phát triển ban đầu, dẫn đến tình trạng “chết yểu” vì hết vốn chỉ sau một đến hai năm.

2. Những hành trang quan trọng trước khi ra “biển lớn”

Từ những điểm xuất phát thuận lợi và khó khăn ấy, để chinh phục thị trường nước ngoài, các startup công nghệ Việt cần chuẩn bị một chiến lược rõ ràng, phù hợp với môi trường quốc tế, từ văn hóa, ngôn ngữ, đến cách tiếp cận người dùng, chiến lược marketing và đặc biệt là vấn đề bản quyền cũng như pháp lý. Theo anh Uy, sản phẩm nội địa có thể sẽ gặp nhiều khó khăn và thời gian để triển khai ra thị trường quốc tế dù đạt được nhiều thành công trong nước.

Yếu tố đầu tiên các startup Việt cần chú ý chính là công nghệ. Thường các công nghệ được chọn áp dụng ở Việt Nam dựa trên yếu tố nguồn nhân lực giá rẻ sẵn có. Tuy nhiên, để có thể phát triển nhanh chóng và tạo được tiếng vang ở thị trường quốc tế, công nghệ được lựa chọn nên mới nhất và được chấp nhận rộng rãi.

Bên cạnh nền tảng công nghệ, chiến lược marketing cũng cần được xem xét, chuẩn bị và lên kế hoạch một cách kỹ lưỡng. Kỹ thuật phần mềm có thể sửa đổi được nếu có đủ nhân sự, nhưng phương thức làm marketing rất khó điều chỉnh trong khoảng thời gian ngắn. Cụ thể hơn, cách tiếp cận người dùng ở Việt Nam khác nhiều so với quốc tế, đặc biệt là kênh nội dung.

Ví dụ: Facebook fanpage là kênh xã hội phổ biến nhất ở nước ta. Tuy nhiên, người Mỹ lại thích sử dụng Twitter hơn Facebook.

Một điểm cần chú ý khác là việc giao tiếp nội dung. Cụ thể, những thông tin khi được phiên dịch thường không được chính xác hay thậm chí sai chính tả sẽ ảnh hưởng nhiều đến khả năng tiếp thu và cảm xúc của người dùng. Vì thế, khi có định hướng chiến lược phát triển ra nước ngoài, founder nên tuyển dụng những bạn có kinh nghiệm phát triển sản phẩm cho thị trường quốc tế, những người đã làm việc tại nước ngoài để giúp tư vấn về văn hóa và cách tiếp cận người dùng địa phương nhằm nâng cao chất lượng sản phẩm.

Pháp lý là thử thách cuối cùng mà các Tech startup Việt cần chuẩn bị. Quan trọng nhất là việc xây dựng mối quan hệ lâu dài với các tổ chức chuyên về sở hữu trí tuệ và tham khảo từ họ cách hoạt động ở nước ngoài trước khi triển khai để tránh những vấn đề không đáng có.

3. UpStar Labs – Bệ phóng dành cho các Tech Startup Việt

Với mong muốn hỗ trợ, chia sẻ kinh nghiệm và hợp tác nâng tầm các sản phẩm công nghệ Việt có khả năng cạnh tranh trên thị trường quốc tế, vườn ươm UpStar Labs được thành lập vào tháng 6/2017.

UpStar Labs không phải là một quỹ đầu tư, mà là vườn ươm (Incubator), nên không chỉ tập trung đầu tư vốn vào một công ty. Vườn ươm hỗ trợ các startup từ giai đoạn phát triển ý tưởng đến khi có Minimum Feasible Product, hoặc Minimum Lovable Product – giai đoạn người dùng có thể thấy được giá trị hoặc cảm thấy sản phẩm đó sẽ đem lại giá trị cho họ nếu chưa dùng được. UpStar Labs khác biệt các mô hình vườn ươm hiện nay bởi:

  • Đầu tư tập trung. Thay vì đầu tư vào nhiều mảng khác nhau, UpStar Labs chỉ tập trung vào sản phẩm phần mềm, đặc biệt ưu tiên mở rộng ra thị trường quốc tế thay vì chỉ gói gọn ở nước nhà hay khu vực Đông Nam Á.
  • Đầu tư vào những công nghệ tiên phong. Cụ thể hơn, hiện nay, công ty đang tập trung triển khai các sản phẩm được xây dựng với công nghệ Blockchain và AI.
  • Không chỉ là đầu tư, UpStar Labs mong muốn được lâu dài cùng các startup. Vườn ươm sẽ đồng hành với các dự án từ lúc còn sơ khai và cùng nhau hợp tác phát triển lâu dài nên mỗi năm, chỉ từ 2 – 3 dự án được chọn để triển khai nhằm đảm bảo sự thành công cho các dự án. Ngoài ra, UpStar Labs sẽ không làm những dự án quá nhỏ hay quá lớn. Các đơn vị tài chính tương tự thường tập trung vào phân khúc từ $15.000 đến $30.000, nhưng UpStar Labs sẽ đầu tư từ $50.000 đến $100.000 cho vòng đầu tiên kèm theo sự hợp tác chặt chẽ xuyên suốt quá trình phát triển sản phẩm.
  • Đội ngũ nhân lực sẵn sàng. Sự giúp đỡ từ bộ máy hơn 800 nhân viên của KMS Technology với nhiều kinh nghiệm cùng cơ sở hạ tầng tốt sẽ là một đòn bẩy thuận lợi cho các startup công nghệ.

Anh có thông điệp gì muốn gửi đến các tech startup Việt hiện nay không?

==============

Thông tin chi tiết về UpStar Labs

UpStar Labs là vườn ươm ý tưởng khởi nghiệp, thành viên KMS Technology. Mục tiêu của UpStar Labs là đầu tư, chia sẻ kinh nghiệm và hợp tác với những cá nhân và tổ chức có ý tưởng với mong muốn xây dựng những sản phẩm công nghệ cao có khả năng cạnh tranh trên thị trường quốc tế với niềm tin trong tương lai Việt Nam sẽ có những Google, Uber, Facebook.

Website: https://www.UpStarlabs.com/

Việc làm tại KMS Technology & UpStar Labs: https://www.facebook.com/kmscareers/

TopDev via Techtalk

[Update] 7 lĩnh vực công nghệ lương cực cao trong năm 2024

các phần mềm dành cho dân it
Các Phần Mềm Dành Cho Dân IT Mà Mọi Lập Trình Viên Nên Biết

Bắt đầu năm 2024, sự vượt bậc của công nghệ cũng đã đem đến cho các lập trình viên rất nhiều cơ hội, mở ra một năm mới với nhiều điều thú vị. TopDev xin tổng hợp lại những công việc đang được săn đón nhiều nhất hiện nay để gửi đến các Dev.

Xem ngay những công việc tuyệt vời nhất trên hệ thống TopDev

1- Chuyên gia về Front-end

Front-end Developer sử dụng HTML, CSS và JavaScript, còn những thiết kế ứng dụng web là do người thiết kế web làm. Các code mà front-end developer viết chạy bên trong trình duyệt của người dùng (trái ngược với back-end developer mà các mã chạy trên backend servers).

Có thể nghĩ đơn giản thế này, Back end developer giống như những kiến trúc sư thiết kế và tạo ra các hệ thống làm cho 1 thành phố hoạt động (điện, nước và hệ thống cống rãnh, v.v), trong khi đó, frontend developer là người bố trí, thực hiện các con đường và đảm bảo rằng tất cả mọi thứ trong hệ thống đều được kết nối đúng cách với nhau để người dùng có thể sử dụng một cách trơn tru.

Tham khảo thêm các vị trí tuyển dụng front end mới nhất cho bạn

Cần kỹ năng gì để trở thành chuyên gia về Front-end?

Các kỹ năng phát triển Front-end bao gồm thiết kế giao diện người dùng (UI) và trải nghiệm người dùng (UX), CSS, JavaScript, HTML.

Mức lương dành cho vị trí này: lên đến $2,500

2 – Hiệp sỹ Python – Bước đệm cho những công nghệ đỉnh cao

Python có thể là bước đệm mở đầu cho những ai yêu thích thế giới lập trình muốn tìm tòi và học hỏi. Ở các bảng xếp hạng lớn, Python luôn nằm trong top 10 ngôn ngữ lập trình phổ biến nhất.

Chắc không cần phải nói nhiều, Python chính là nền tảng cho rất nhiều sản phẩm cực kỳ nổi tiếng: Google, Quora, Instagram, BitTorrent, Reddit, hay Dropbox, v.v… Biết được Python là một lợi thế lớn trong ngành lập trình.

Cần kỹ năng gì để trở thành Python Developer?

  • HTML, CSS và Javascript: 3 ngôn ngữ bắt buộc để làm web dù bạn có thích hay không. Khi nắm chắc cơ bản được 3 dạng này bạn có thể học Python Web
  • Các Framework để lập trình Python web: Flask và Django là 2 cái phổ biến nhất hiện nay mà bạn nên theo học.
  • Đây là một ngôn ngữ mũi nhọn cho việc xây dựng các hệ thống Machine Learning, có thể nhắc đến các thư viện như: Tensorflow, numpy, pandas hay scikit-learn.

Mức lương dành cho vị trí này: lên đến $2,500

3 – Anh hùng PHP – Ngôn ngữ lập trình phổ biến nhất hiện nay

Với cú pháp đơn giản, tốc độ nhanh và nhỏ gọn, PHP được xem là ngôn ngữ lập trình dễ học và thời gian tiếp cận cũng ngắn hơn so với nhiều ngôn ngữ lập trình khác, do đó số lượng các vi trí việc làm PHP Developer ngày nay đang chiếm tỷ lệ khá lớn, thậm chí có thể gọi là lớn nhất.

Lợi thế của PHP là có rất nhiều CMS, framework mã nguồn mở như WordPress, Laravel nên có thể đáp ứng hầu hết các website thông thường từ blog cá nhân cho đến website giới thiệu công ty hay bán hàng.v.v…

Cần kỹ năng gì để trở thành PHP Developer?

  • Javascript, Jquery: Đây là những thành phần quan trọng trong trang web.
  • PHP/MySQL: Nói đến lập trình web thì PHP và MySQL thường gắn liền với nhau. MySQL để lưu trữ dữ liệu còn PHP sẽ thực hiện lấy, lưu dữ liệu.
  • Các Framework của PHP: Codeigniter, Yii, Laravel, Zend, Cakephp, Phalcon,…Tuy nhiên, khi mới bắt đầu thì bạn nên học Codeigniter trước vì đây là framework dễ tiếp cận và có hướng dẫn sử dụng rất kỹ càng.

Mức lương dành cho vị trí này: lên đến $2,500

4 – Project Manager – PM (Quản trị dự án)

Một trong những nghề có lương cao nhất trong ngành IT không thể nào không nhắc đến vị trí Project Manager – PM (Quản trị dự án), những người giữ vị trí chủ chốt trong quá trình thực thi dự án. Một PM vừa phải là người quản lý những vấn đề tổng thể, vừa phải là người tham gia vào tất cả công việc trong dự án.

Các công việc đảm nhiệm chính của PM thường là: làm dự toán, lập đội dự án, lên kế hoạch và quy trình làm sản phẩm theo yêu cầu khách hàng, sắp xếp quy trình trong team giữa các Developer, Tester và các vị trí liên quan, quản lý tiến độ và chất lượng, làm việc với khách hàng đê báo cáo tiến độ, quản lý chiến lược…

Cần kỹ năng gì để trở thành PM chuyên nghiệp?

  • Kỹ năng quản lý dự án
  • Kỹ năng lập kế hoạch
  • Kỹ năng quản lý thời gian
  • Kỹ năng giao tiếp
  • Kỹ năng về ngoại ngữ
  • Kỹ năng giải quyết vấn đề

Mức lương dành cho vị trí project manager này (hoặc liên quan): Upto 4,000 USD

5 – Kỹ sư về Machine Learning (AI)

Machine Learning là một phương pháp phân tích dữ liệu mà sẽ tự động hóa việc xây dựng mô hình phân tích. Thông qua việc dùng các thuật toán lặp để học từ dữ liệu, Machine Learning cho phép máy tính tìm thấy những thông tin giá trị ẩn sâu mà không được lập trình một cách rõ ràng nơi để tìm.

AI (Trí tuệ nhân tạo – Artificial Intelligence) là một ngành khoa học được sinh ra với mục đích làm cho máy tính có được trí thông minh. Nói một cách ngắn gọn hơn là AI thể hiện một mục tiêu của con người, và Machine Learning là một phương tiện được kỳ vọng sẽ giúp con người đạt được mục tiêu đó. Trên thực tế thì Machine Learning đã mang nhân loại đi rất xa trên quãng đường chinh phục AI và dự sẽ tiếp tục gây nên cơn sốt công nghệ trên toàn thế giới trong tương lai.

Cần kỹ năng gì để trở thành Kỹ sư Machine Learning (AI):

  • Feature Engineering: Đây là một kỹ năng quan trọng bởi nó ảnh hưởng đến độ chính xác chung cũng như đến tốc độ huấn luyện của mô hình dự đoán (thu thập chính xác dữ liệu, điều chỉnh các feature, chọn lọc các feature phù hợp với mô hình hiện tại, thêm các feature mới vào dữ liệu, xử lý và thay đổi.v.v….)
  • Model tuning: để hiểu biết thấu đáo về các thuật toán Machine Learning thì đây là một kỹ năng cần thiết, việc hiểu các thông số (parameter) của mô hình và tinh chỉnh các thông số này ra sao sẽ làm thay đổi đáng kể độ chính xác của mô hình dự đoán.
  • Model Ensemble: là mô hình dựa trên các kĩ thuật Machine Learning khác nhau, lấy mẫu (sampling) dữ liệu và đưa ra kết quả dự đoán dựa vào sự kết hợp của nhiều mô hình gộp lại.
  • Cài đặt machine learning trên các platform khác nhau: bạn có thể bắt đầu cài đặt trên bất kì nền tảng nào mà bạn cảm thấy quen thuộc. Các thư viện tương thích đa nền tảng như R, Python, Java, Spark, … hiện đã có nhiều cài đặt về machine learning.
  • Visualization: Visualization cho dữ liệu và mô hình cơ bản là một lĩnh vực quan trọng. Công cụ này cung cấp cái nhìn toàn diện về cách dữ liệu được tổ chức cũng như hiểu được làm thế nào mà mô hình của chúng ta có thể thực hiện được.

Mức lương cho vị trí này: lên đến $2,200

6 – Phù thuỷ Java

Java là một ngôn ngữ lập trình mạnh mẽ, có tính chất hướng đối tượng, và thường được sử dụng trong các hệ thống có tính độc lập cao. Yếu tố cơ bản để phân biệt Java so với các ngôn ngữ lập trình khác chính là theo khẩu hiệu: “viết một lần, chạy mọi nơi”.

Như tên gọi của nó cho thấy, lập trình hướng đối tượng (OOP) sử dụng các đối tượng được định nghĩa đầy đủ – và các mối quan hệ giữa các đối tượng với nhau – để thực hiện các tác vụ khác nhau. Do nền tảng mô-đun tự nhiên của nó, OOP thường làm cho nó dễ dàng hơn, nhanh hơn và rẻ hơn trong phát triển và quản lý phần mềm.

Cần kỹ năng gì để trở thành Java Developer:

  • MVC Frameworks – Frameworks J2EE mã nguồn mở như Struts, Webwork, Spring MVC, Tapestry, các kiến thức về Web Services.
  • Web/Application server như Tomcat, Glassfish, WebLogic, WebSphere, Jetty etc.
  • Hiểu biết về môi trường Unix – Hầu hết các server Java đặt trên môi trường Unix nên hiểu biết về Unix là một lợi thế lớn

Mức lương dành cho vị trí này: lên tới $2,200

7 – Anh hùng thầm lặng, Back-end Developer

Nếu Front-end Developer là người tạo nên vẻ ngoài hoàn mỹ cho ngôi nhà thì Back-end Developer chính là người vận hành mọi thứ ở phía sau, là xương sống để tạo nên một website tuyệt vời. 

Các hoạt động xử lý và vận hành website đều do Back-end Developer đảm nhiệm, họ sẽ là người điều chỉnh mọi logic nghiệp vụ phức tạp ở phía sau, bảo đảm cho hệ thống hoạt động trơn tru từ data của user cho đến các thuật toán phân tích.

Cần kỹ năng gì để trở thành Back-end Developer?

  • Ngôn ngữ server-side để viết back-end: C#, Java, Python, Ruby, …. bao gồm các web framework đi kèm như: ASP.NET MVC, Spring, Django, Rails … Bạn có thể chọn một trong ngôn ngữ trên để học.
  • Database SQL: MS SQL Server, MySQL, …Một số database NoSQL đang khá thịnh hành như Neo4j, MongoDB mà bạn có thể học hỏi. Hoặc biết  cách viết Web Service, cách đăng nhập và phân quyền.
  • Kiến thức về một số CMS: WordPress, Joomla, Umbraco, ….

Mức lương dành cho vị trí này: lên tới $2,000

Bí mật giúp bạn thành công khi phỏng vấn (P2)

  Bí mật giúp bạn thành công khi phỏng vấn (P1)

Glassdoor: Theo chị, việc ứng viên không trả lời được câu hỏi trong buổi phỏng vấn có ảnh hưởng đến kết quả hay không? Nếu ứng viên không biết câu trả lời, cách phản hồi tốt nhất là gì?

Những cơ hội làm Machine Learning với mức lương cực cao

McDowell: Hoàn toàn bình thường! Tôi cho rằng việc bạn không biết trả lời một câu hỏi là chuyện rất bình thường. Tôi khuyên bạn nên dành một chút thời gian suy nghĩ và đảm bảo rằng hiểu rõ tất cả các chi tiết của vấn đề một cách chính xác. Sau đó sử dụng bảng ghi chép lại các chi tiết và đưa ra các ví dụ để tìm ra cách giải quyết của vấn đề. Hãy tưởng tượng bạn hỏi những người không biết gì về code các câu hỏi chuyên sâu về mảng này, chắc chắn họ sẽ không biết câu trả lời – nhưng nếu bạn nói với họ rằng hãy đọc tài liệu và tìm thử đi, thì tỷ lệ cao là họ sẽ làm được. Vì vậy, hãy xem xét kĩ các thông tin trong câu hỏi để tìm ra đáp án hợp lí nhất. Khi bạn đã có một số hướng giải quyết, ngay cả khi chúng không phải là cách tốt nhất, hãy nghĩ về những trường hợp tệ nhất và cách tối ưu hóa chúng. Nếu hướng giải quyết của bạn không thành công, hãy suy nghĩ lại thật kĩ để xác định lí do thất bại.

Khi đã tìm ra giải pháp, đừng vội vàng code liền tay. Bạn có biết rằng, một trong những điều làm con người chậm lại là tính hấp tấp – họ có một ý tưởng cơ bản về cách giải quyết, ngay lập tức họ lao đầu vào viết code cho nó. Lấy một ví dụ tương tự, hãy tưởng tượng bạn muốn lái xe đến một nơi cách đây hai dặm. Bạn mường tượng sơ sơ được đường đi đến đó, nhưng bạn có nên khởi hành ngay lúc đó? Hoàn toàn có thể, nhưng bạn có thể sẽ quẹo sai đường, đi sai hướng rất nhiều lần. Thay vào đó, 3 phút tìm hiểu hướng đi trước khi di chuyển sẽ giúp bạn hoàn thành chuyến đi dễ hơn rất nhiều.

Glassdoor: Các ứng viên cần chuẩn bị gì cho buổi phỏng vấn không thuần về data structure hay các câu hỏi thuật toán chuyên sâu?

McDowell: Developers cũng nên có khả năng trình bày background của mình. Không cần lâu – chỉ cần 30 giây đến một phút thôi đã là quá đủ. Mục đích là để nhà tuyển dụng có cái nhìn tổng quan về kinh nghiệm của bạn.

Ngoài ra, các developers nên chuẩn bị để có thể trình bày từ 3 đến 5 dự án. Họ phải trình bày được tổng quan cách tổ chức của các dự án, và bạn có thể đề cập đến những ca khó nhất mà bạn đã trải qua. Vì vậy, khi tôi hỏi các developers về những thách thức trong một dự án, câu trả lời của họ sẽ đại loại kiểu ” tôi phải học bao nhiêu là thứ.” Với tư cách là một developer, tôi hiểu rằng làm việc với các công nghệ không quen thuộc là một thách thức. Nhưng nó là thử thách đối với để phân biệt một developer giỏi và tệ, nên điều này không gây ấn tượng với nhà tuyển dụng. Thay vào đó, câu trả lời hay nên nhắc đến các vấn đề kỹ thuật – một công cụ tối ưu hóa, một trình chữa bug, một thuật toán mới. Những điều này chứng minh bạn là một kĩ sư tuyệt vời.

Glassdoor: Bạn sẽ làm gì nếu gặp khó khăn trong buổi phỏng vấn đầu tiên?

McDowell: Bên cạnh Cracking the Coding Interview, tôi có một cuốn sách tên Cracking the Tech Career, dành cho những người nghĩ rằng ” Trời ơi, tôi là một lập trình viên của một công ty bảo hiểm nhưng tôi rất muốn làm việc cho Google, tôi làm điều đó như thế nào? ” Hoặc ” Tôi đang làm trong mảng marketing, tôi có thể chuyển sang làm việc tại một công ty công nghệ như thế nào?”. Một trong những điểm tôi đưa ra trong cuốn sách đó là, để tham gia một buổi phỏng vấn, bạn không chỉ muốn chứng minh rằng bạn là một developer giỏi, mà bạn còn là người có kiến ​​thức cơ bản để vượt qua các buổi phỏng vấn.

Bằng CS chắc chắn chứng minh được bạn là người có kiến ​​thức tốt. Nhưng nếu bạn không có bằng CS, tham gia các lớp data structure và các thuật toán trên Coursera sẽ giúp ích. Bạn cũng có thể lập trình ít cạnh tranh vì nó đòi hỏi phải lập trình rất cạnh tranh. Tôi cũng thấy những người cung cấp những liên kết về việc thực hiện các vấn đề của họ từ cuốn sách Cracking the Coding Interview.

Để chứng tỏ rằng bạn là một nhân viên giỏi, các dự án (open source, independent, hackathons – bất cứ điều gì!) có thể giúp ích rất nhiều. Bạn nên có ba hoặc bốn dự án lớn trong CV của bạn để chứng minh kỹ năng, niềm đam mê và sáng kiến ​​của bạn.

Đừng ràng buộc bản thân với bất kì ngôn ngữ lập trình nào (điều này xảy ra rất nhiều với boot camps). Bạn không phải là một developer .NET; bạn là một developer đang sử dụng .NET. Bạn có thể học một ngôn ngữ mới và kỹ năng của bạn chắc chắn sẽ nâng cao. Các công ty công nghệ quan tâm đến các kĩ năng cơ bản hơn là việc bạn giỏi một ngôn ngữ cụ thể. Trên thực tế, họ không xem trọng những developer chỉ sử dụng một loại ngôn ngữ, nên việc đa dạng hoá các kỹ năng rất quan trọng.

Glassdoor: Việc tuyển dụng đã thay đổi như thế nào từ khi chị viết cuốn sách cuối cùng? Theo chị, có xu hướng nào chuẩn bị biến mất không?

McDowell: Phiên bản mới nhất của cuốn sách cuối cùng của tôi đã xuất bản cách đây một năm rưỡi, và phiên bản cũ nhất đã được phát hành vào năm 2011. Nói thật, mặc dù mọi người đang nói về việc các buổi phỏng vấn đang thay đổi, thực sự nó không phải như vậy. Các kiểu câu hỏi về cơ bản không đổi trong 15 năm qua, nhưng có phần tập trung hơn về các hệ thống mở rộng và công nghệ web. Họ muốn biết rằng bạn có thể viết code tốt hay không, bạn có phải là người thông minh hay không, bạn có giỏi giải quyết vấn đề hay không, và bạn có thể làm việc tốt với đồng đội hay không. Cách đánh giá vẫn không thay đổi – chỉ có ngôn ngữ và công nghệ thay đổi.

Mặc dù tôi không nghĩ rằng quá trình phỏng vấn thay đổi ở các công ty hàng đầu, nó vẫn khá khác ở công ty kém phát triển hơn. Nhiều người nhận ra rằng: “Này, nhìn vào Google, Microsoft, Amazon, Uber, Lyft. Những công ty này đang xây dựng một công nghệ mới – họ biết họ đang làm gì. Hãy làm những gì họ làm. “

Glassdoor: Một số người cho rằng buổi phỏng vấn không thành công là do các yếu tố như thiên vị ngầm và thực tế là chúng thường không nắm bắt chính xác loại công việc bạn đang làm trên cơ sở hàng ngày. Chị có đồng ý không?

McDowell: Đó là một câu hỏi thú vị. Tôi không đồng ý rằng có sự thiên vị đối với những trường hơp thường thấy – nếu họ thấy một người phụ nữ hoặc dân tộc thiểu số, họ sẽ cho rằng những người ấy không phải là dân kĩ thuật. Tuy nhiên, tôi nghĩ rằng các buổi phỏng vấn về code ít thiên vị hơn, vì các tiêu chí đánh giá thường khách quan hơn. Thậm chí một nhà tuyển dụng ” công bằng ” ​​có thể nhận ra khả năng đưa ra giải pháp tối ưu của một ứng viên một cách nhanh chóng.

Tôi nghi ngờ các buổi phỏng vấn có tính chất ít khách quan hơn, ví dụ buổi phỏng vấn hành vi, có nhiều yếu tố thiên vị. Phụ nữ, ví dụ, thường không muốn khoe những thành tựu của họ, một phần là vì họ có thể bị phạt nếu làm như thế. Ngay cả khi họ làm như thế, nhà tuyển dụng vẫn có thể hỏi người đó đã làm việc như thế nào hay nhiệm vụ của họ thử thách đến mức nào.

Một số công ty đã thử nghiệm các phương pháp thay thế như phỏng vấn coding trực tiếp, hoặc các dự án làm tại nhà. Nhưng như thế các ứng viên vẫn gặp nhiều vấn đề. Thời gian một bà mẹ hai con có thể làm việc tại nhà là bao lâu?

Chúng ta nên chú ý đến sự thiên vị ngầm, nhưng cũng cần chú ý rằng cải cách có thể biến quá trình thiên vị thành một quá trình thiên vị hơn rất nhiều lần.

Quá trình phỏng vấn có thể có sai sót không? Chắc chắn có, trên thực tế có khá nhiều phản ánh chưa chính xác – những ứng viên thể hiện không tốt trong buổi phỏng vấn lại có thể là những developer tuyệt vời. Nhưng tôi sẽ nói điều này: Buổi phỏng vấn, khi được thực hiện hiệu quả, có thể tạo ra những kết quả và tài năng hàng đầu.

Tạo CV online ấn tượng với nhà tuyển dụng

Source: Glassdoor

5 thói quen xấu khiến developer bị sa thải

Có thể nói chuyện thành hay bại của một phần mềm bắt đầu từ việc ” Gãi đúng chỗ ngứa ” ” Ravi, thật tệ quá, bạn đang gặp vấn đề mỗi ngày đấy” Jim người quản lý của tôi nói

Tôi đã rất ngạc nhiên ,hay nói chính xác hơn là hoàn toàn bị sốc vì những lời nói đó.

” Jim à, tôi không chắc tại sao anh lại nghĩ như vậy” Tôi đáp trả bằng một giọng điệu mỉa mai

“Tôi là một developer tuyệt vời và là một nhân tài của team của chúng ta. Khách hàng hoàn toàn hài lòng với tôi và nếu nói không ngoa thì năng lực của tôi vượt xa những đồng nghiệp khác” . Tôi đã thực sự tức giận

200+ vị trí hot Android Developer không nên bỏ lỡ

” Chính suy nghĩ này là vấn đề của bạn, Ravi à. Nếu bạn không nhanh chóng khắc phục, bạn sẽ không bao giờ đạt đến được đỉnh cao của sự nghiệp” Jim nhìn thẳng vào mắt tôi và nói.

Quá nhiều cảm xúc diễn ra cùng một lúc: ngớ ngẩn, tức giận và bối rối, tất cả cùng một lúc, và nhận ra sự thô lỗ trong câu nói của anh ấy.

Tôi cố gắng kìm nén để tránh bộc phát và lắng nghe những lí do anh ta đưa ra:

” Code của tôi là tuyệt nhất “

Friedrich Nietzsche đã nói sau khi hoàn thành.

Bất kể tôi làm việc gì, tôi đều bị CÁI TÔI ám ảnh quá lớn

Người mà team thực sự cần là những người khiêm tốn, cầu tiến và thông minh: khiêm tốn đồng nghĩa với giảm bớt cái “tôi” cá nhân lại, quan tâm nhiều hơn đến “ta” chung. Cầu tiến nghĩa là họ có đạo đức nghề nghiệp, luôn cố gắng hoàn thành mọi thứ, và đóng góp bằng tất cả những gì họ có thể. Thông minh không có nghĩa là thông minh về mặt trí tuệ mà là nhạy bén trong xử lý tình huống.

Đừng chỉ trích code của người khác, một phần của nó có thể là của bạn. Thay vào đó, hãy cố gắng làm cho các đánh giá trở nên khách quan và chuyên nghiệp. Hãy khiêm tốn và cố gắng học hỏi từ mọi người xung quanh bạn.

Hãy luôn luôn nhớ, cái tôi là một trở ngại đối với công việc của bạn. Nếu bạn tin vào sự vĩ đại của bạn, nó sẽ là điểm chấm hết cho sự sáng tạo của bạn. Sự nghiệp cải thiện bản thân sẽ dừng lại khi bạn tin rằng không còn gì để học trên đời này.

” Tôi có thể sửa cái này trong tích tắc “

Angela Duckworth đã từng nói:

Không có con đường tắt nào dẫn đến thành công

Hãy tự cứu rỗi bản thân. Hãy tự cho phép mình tận hưởng cuộc sống này. Nếu bạn đang dành cả tuổi thanh xuân chỉ để làm những chuyện lặt vặt, bạn đã đi sai hướng rồi. Đi đường tắt không có nghĩa là sẽ đến đích nhanh hơn.

Đi đường tắt rất nhiều cám dỗ, mọi người đều đã từng làm điều đó. Thật ra có một số trường hợp cần phải làm điều đó, nhưng nhìn chung, nó rất nguy hiểm, rất rất nguy hiểm và nên tránh càng xa càng tốt. Một đường tắt sai lầm có thể giúp bạn tiết kiệm được vài giờ nhưng có thể sẽ phải đánh đổi bằng cả danh dự của chính bạn.

Hãy suy nghĩ kĩ lời khuyên của tôi. Tôi đã học được rằng việc đi đường tắt và sống buông thả không có nghĩa là bạn đang được sống trong tự do. 

” Tôi nhớ mọi thứ. Tôi không cần ghi chép gì cả “

Dick Brandon đã từng nói.

Việc ghi chép giống như tình dục; Khi làm tốt, nó sẽ rất tuyệt, và ngay cả khi làm tệ thì nó có vẫn còn hơn không

Việc ghi chép là ” chất bôi trơn ” của việc lập trình. Các nhà quản lý đều nghĩ rằng việc đó tốt với các lập trình viên những lập trình viên lại ghét nó!

Nhưng mọi người đều biết, những developers XUẤT SẮC đều làm cho thói quen hằng ngày trở nên thực tế hơn. 

Như trong bất cứ lĩnh vực nào, lập trình viên có thể chuyển đổi công việc, di chuyển từ phòng ban này sang phòng ban khác hoặc nghỉ hưu. Trong trường hợp xấu nhất, bệnh tật, thương tích hoặc tử vong có thể làm giảm số lượng thành viên trong nhóm – điều mà bạn không mong đợi. Code cũng vậy. Các developers có thể dễ dàng quên code của họ hoạt động như thế nào nếu họ không đụng vào nó trong vòng một năm hoặc nhiều hơn.

Trong bất kỳ trường hợp nào, việc truy cập vào các tài liệu thiết kế, thông số kỹ thuật API, hướng dẫn sử dụng và các nhận xét code cho thấy sự khác biệt giữa sản phẩm và deadline. 

Và thái độ này khiến họ trở nên quan trọng hơn với team. Đừng cố gắng trở thành người ” không thể thay thế ” trong team của bạn bằng việc không ghi chép. Tất cả những điều bạn nên làm là thể hiện hết trách nhiệm với team của bạn.

” Đó không phải do tôi ” 

Bruce Lee đã từng nói :

Mọi lỗi lầm đều được tha thứ, nếu người có lỗi đủ can đảm nhận sai

Câu nói trên đề cao một trong những đức tính quan trọng nhất của một developer VĨ ĐẠI thực sự.

Chúng ta luôn có những lý do … Trong những điều kiện bình thường, chúng ta sẽ không bao giờ phạm sai lầm, nhưng thật lòng, điều đó khó xảy ra.

Các developers tệ hay đổ lỗi cho khách hàng vì không sử dụng các sản phẩm đúng cách. Họ ít khi chịu trách nhiệm cho sản phẩm và các lỗi. Họ đảm bảo rằng mọi người đều biết chính xác người chịu trách nhiệm là ai khi có lỗi do người khác tạo ra.

Để tránh bị sao lãng và mất thời gian của mọi người trong quá trình này?

Giữ thái độ lành mạnh khi chúng ta còn có thể và nói những điều như: ” Tôi xin lỗi, bây giờ chúng ta cần làm điều này để khắc phục vấn đề này, đó là lỗi của tôi” sẽ giúp bạn gây dựng lại lòng tin, và sự tín nhiệm từ mọi người. Bạn càng sớm thừa nhận những sai lầm của bạn, bạn càng phải học và sửa sai nhiều hơn. Đơn giản như thế!!!

Hai từ ” Hoàn thành ” của bạn vẫn chưa đủ

Rick Lemons đã từng nói.

Đừng bắt người dùng cung cấp thông tin đã có trên hệ thống

Nếu lập trình là tình dục, sẽ có rất nhiều máy tính ” không thoả mãn “. Tôi nhận ra khá nhiều người đang nhầm lẫn về khái niệm ” Đã hoàn thành”

Hãy nhớ rằng ” Đã hoàn thành ” nghĩa là: Được thử nghiệm và được chấp nhận bởi người dùng theo yêu cầu của họ. Kết thúc theo suy nghĩ của bạn không có nghĩa là mọi thứ đã thật sự hoàn thành.

Một developer xuất sắc luôn mong muốn học hỏi những điều mới. Họ tìm tòi để hiểu cách các phần tử kết hợp với nhau và tình trạng của chúng. Họ đặt các câu hỏi về thiết kế và ý tưởng bên cạnh các tính năng để tìm kiếm giải pháp. Họ biết điều gì sẽ mang lại trải nghiệm tốt cho người dùng.

Mặt khác, một developer kém chỉ “tôn sùng” công nghệ họ yêu thích. Họ nghĩ rằng phương pháp hoặc quá trình của họ là ” lý tưởng” , và họ cho rằng trải nghiệm người dùng và các tình huống khác nhau không thể thay đổi quyết định đó. Họ đưa vào dự án các biến phụ thuộc không cần thiết để phù hợp với sở thích của họ. 

Các dự án thành công là những dự án được chấp nhận bởi người dùng và trở thành một phần trong cuộc sống của họ.

Kết luận  

Vậy có từ nào tổng hợp được tất cả các ý ở trên?

Câu trả lời là Thái Độ

Một thái độ tốt quan trọng hơn số năm kinh nghiệm.

Chỉ làm việc thôi chưa đủ, bạn phải có thái độ tốt trong công việc và thay vì có kỹ năng tốt, thái độ tốt vẫn quan trọng hơn nhiều. Nếu bạn chọn việc bạn thích là nghề nghiệp của bạn, nhìn chung bạn sẽ thích làm việc đó và công việc sẽ không bao giờ đơn điệu. Là một nhân viên, điều quan trọng là bạn phải thể hiện đúng thái độ tại nơi làm việc.

Như Zig Ziglar đã tổng kết.

” Thái độ, sẽ quyết định thành công của bạn. “

TopDev via 

  5 thói quen xấu khiến developer bị sa thải
: Những con số hấp dẫn về lương của Software Engineer”]

Source: Hackernoon

Bí mật giúp bạn thành công khi phỏng vấn (P1)

Nếu bạn đã từng tham gia phỏng vấn, hoặc tìm kiếm trên Google về vấn đề này, rất có thể bạn đã nghe nói về cuốn sách bán chạy Cracking the Coding Interview của tác giả Gayle Laakmann McDowell. Cuốn sách của McDowell đã nhanh chóng trở thành tác phẩm kinh điển cho những ai muốn làm việc cho những gã khổng lồ như Facebook, Amazon và Salesforce. Với sơ yếu lý lịch bao gồm các vị trí tại Google, Microsoft và Apple, cô ấy có đủ uy tín và kinh nghiệm để viết nên tuyệt phẩm đó.

300+ vị trí PHP đang chờ bạn tại TopDev

Gần đây, McDowell đã nói chuyện với Emily Moore của Glassdoor để chia sẻ một số mẹo hay để vượt qua các kỳ phỏng vấn cam go – hãy cùng xem để biết cách thể hiện tốt trong buổi phỏng vấn tại các công ty mà bạn luôn mơ ước.

Glassdoor: Giữa HackerRank, whiteboarding, paired programming v.v Hiện nay các kiểu phỏng vấn rất đa dạng. Theo chị ứng viên thực sự mong muốn điều gì nhất ở một buổi phỏng vấn ?

McDowell: Một buổi phỏng vấn điển hình bắt đầu với một hoặc hai cuộc phỏng vấn qua điện thoại (ít nhất một trong số đó là về kĩ thuật), tiếp theo sẽ có từ 4 đến 6 buổi phỏng vấn tại công ty. Trong những buổi phỏng vấn tại công ty, một trong những loại câu hỏi phổ biến là câu hỏi về hành vi. Những câu khác sẽ nghiêng về kĩ thuật, thường bao gồm coding / thuật toán, thiết kế hoặc các kiến ​​thức công nghệ chuyên sâu và kĩ năng.

Một buổi phỏng vấn bình thường diễn ra từ 45 đến 60 phút, và bắt đầu với một hoặc hai câu hỏi nhanh về hành vi. Mục đích là để có thêm thông tin về ứng viên và giúp họ thư giãn khi bắt đầu buổi phỏng vấn. Nếu nhà tuyển dụng bước vào và ngay lập tức đưa ra một câu hỏi liên quan đến kĩ thuật, điều này có thể gây ra cảm giác sợ hãi.

Ở những buổi phỏng vấn này, bạn sẽ phải thể hiện kỹ năng của mình qua tấm bảng trắng, chứ không phải trên máy tính xách tay mà bạn hay dùng. Tuy nhiên, một số công ty sẽ offer cho bạn máy tính nếu cần. Mục tiêu của dạng phỏng vấn này là đánh giá các kỹ năng giải quyết vấn đề của ứng viên và xem liệu họ có thể sắp xếp những suy nghĩ của họ thành những dòng code chính xác và có cấu trúc hợp lý hay không. Nhìn chung, nhà tuyển dụng sẽ bỏ qua các vấn đề cú pháp nhỏ (đặc biệt là trên bảng trắng), nhưng tôi vẫn khuyến khích các ứng viên đưa ra câu trả lời tốt nhất có thể. Bạn không cần thiết phải đạt đến mức độ hoàn hảo, nhưng nếu bạn quá cẩu thả hoặc hời hợt với các tiểu tiết, nó có thể ảnh hưởng đến quyết định của nhà tuyển dụng.

Một số công ty cũng sẽ đánh giá qua các buổi test trực tiếp, hoặc sử dụng các công cụ như HackerRank hoặc làm một dự án độc lập. Điều này thường xảy ra ngay trước hoặc sau khi phỏng vấn qua điện thoại, nhưng trong một số trường hợp, cũng có thể xảy ra ngay sau khi phỏng vấn tại công ty. Một số công ty sử dụng nó như cách để thu thập thêm thông tin khi nhà tuyển dụng không thu thập đủ thông tin để đánh giá ứng viên.

Glassdoor: Những nguyên tắc lập trình cơ bản nào mà chị cảm thấy ứng viên cần phải xem lại trước khi tham gia buổi phỏng vấn?

McDowell: Giả sử công ty sẽ đưa ra một số bài tập về code, nên việc có nền tảng về cấu trúc dữ liệu và các thuật toán thực sự rất quan trọng. Sau đây là những khái niệm cơ bản như binary search tree và breadth-first search. Chúng khá dễ học, nhưng lại có rất nhiều câu hỏi phỏng vấn kiến thức về những chủ đề này. Một ứng viên cũng nên biết cách viết code bằng một hoặc nhiều ngôn ngữ khác nhau. Sẽ không có vấn đề gì nếu bạn quên các parameter chính xác của phương pháp substring, nhưng bạn nên biết cách viết code hợp lý – cho các loops, các hàm, các lớp, v.v … mà không cần phải dựa vào việc tìm kiếm trên mạng.

Glassdoor: Vì cấu trúc dữ liệu và các thuật toán rất quan trọng, liệu bạn có thật sự cần một tấm bằng CS để có thể làm việc tại một công ty công nghệ hàng đầu hay không?

McDowell: Không hẳn. Với tấm bằng CS, một ứng viên có thể sẽ biết các cấu trúc dữ liệu cốt lõi và các thuật toán. Nhưng ứng viên chỉ cần vài tuần để học, vì vậy nó không thực sự đem lại cho ứng viên lợi thế lớn.

Bất lợi lớn nhất của các ứng viên không có bằng CS là sự thiếu tự tin.

Tôi đã thấy nhiều ứng viên không có tấm bằng lận lưng hoảng sợ ngay khi gặp câu hỏi liên quan đến “học tập”. Đó là điều mà tôi gọi là “nỗi sợ không đánh mà đau”. Khi tôi hỏi một câu hỏi liên quan đến trees hoặc đồ thị, mặc dù họ có kiến thức để giải quyết nó, họ vẫn từ bỏ ngay lập tức. Họ nghĩ mọi người có thứ gì đó “nhiều hơn” họ biết, và họ thậm chí không thử.

Tạo CV Online mới nhất cho bạn

Glassdoor: Theo chị, cách thực hành một buổi phỏng vấn tốt nhất sẽ như thế nào?

McDowell: Bạn có thể xem Cracking the Coding Interview như một tài liệu hữu ích cho mình. Nó có tất cả những kiến thức cần thiết và cung cấp nhiều ví dụ thực tiễn khác nhau mà bạn có thể thử qua. Nếu bạn không có bằng CS, nó sẽ giúp bạn tìm hiểu một số nguyên tắc cơ bản. HackerRank cũng có thể cung cấp cho bạn các bài tập thực hành.

Tự nghiên cứu rất quan trọng, nhưng hãy nhớ rằng đôi khi bạn tham gia phỏng vấn, họ sẽ không cung máy tính đâu – thay vào đó họ sẽ đưa một cái bảng trắng. Họ làm điều đó một phần là vì phương pháp này khuyến khích mọi người suy nghĩ và truyền đạt nhiều hơn, nhưng đòi hỏi bạn phải biết phải hướng giải quyết trước khi viết thành code. Bạn cần thực hành nhiều trong hoàn cảnh đó, do đó bạn có thể cần tìm một người bạn đồng hành và thực hành phỏng vấn với bạn ấy. Nó không chỉ giúp bạn có nhiều kinh nghiệm hơn trong vị trí ứng viên – nó cũng cho bạn kinh nghiệm như một nhà tuyển dụng. Có nhiều thứ ứng viên không thể hiểu cho tới khi họ có cơ hội trải nghiệm những điều đó.

Glassdoor: Việc luyện tập trước khi tham gia buổi phỏng vấn có ảnh hưởng xấu đến biểu hiện của ứng viên hay không? Mọi người có thường chú ý nhiều đến việc trình bày câu trả lời như nội dung của nó không?

McDowell: Khi luyện tập hợp lí, các câu hỏi bạn nhận được trong buổi phỏng vấn là những câu bạn chưa bao giờ nghe. Trên thực tế, mục đích của những câu hỏi này là đánh giá cách bạn giải quyết những vấn đề bạn chưa từng gặp. Nếu tôi yêu cầu bạn thiết kế một thành phố hoặc nghĩ một cách mới để làm việc gì đó, bạn không nhất thiết phải có một câu trả lời “sai”, nhưng có nhiều cách sai để làm điều đó. Như bạn biết, đôi khi bạn sẽ gặp các công ty tìm kiếm và hỏi các câu hỏi nổi tiếng của Google, điều đó sẽ dẫn đến việc chọn nhầm những ứng viên luyện tập quá kĩ. Nhưng nhìn chung đó là những công ty không biết họ đang làm gì. Những nhà tuyển dụng có thể phần nào đánh giá bạn thông qua cách bạn giao tiếp, nhưng thường họ sẽ ” dễ dãi ” ở điểm này – trừ khi có một điểm cấm kị như kiểu tự tin thái quá. Điều quan trọng nhất vẫn là khả năng giải quyết vấn đề hiệu quả với nền tảng vững chắc.

TopDev via

Source: Glassdoor

Cải thiện mối quan hệ giữa lập trình viên với sếp: dễ hay khó? (P2)

  Cải thiện mối quan hệ giữa lập trình viên với sếp: dễ hay khó? (P1)

Tôn trọng chuyên môn của nhau

Điều này khá rõ ràng và đơn giản.

Ở cấp quản lý, nếu bạn có thể tự tạo trang web hoặc hệ thống mà bạn đang yêu cầu các developers làm, hãy tự làm điều đó. Bạn không cần thiết phải yêu cầu developers làm việc đó thay cho bạn. Nó giống viêc yêu cầu một nhà thầu xây dựng cho bạn một ngôi nhà, và bạn là một dược sĩ, bạn đến gặp họ và yêu cầu họ xây dựng ngôi nhà theo cách của bạn. Các developers hoàn toàn không biết gì. Họ có kỹ năng và kinh nghiệm mà bạn có thể không có. Hãy tôn trọng nó và đặt niềm tin vào đó.

Là một developer, bạn cũng phải làm điều tương tự. Bạn cần phải thành thật về những hạn chế trong kinh nghiệm của bạn. Đừng để cái tôi quá lớn ảnh hưởng công việc của bạn. Đừng cố gắng thể hiện biết tất cả. Bạn có thể nói “Tôi không biết làm thế nào để giải quyết vấn đề này” hoặc câu gì đó gần giống như thế. Hơn nữa, nó rất có lợi cho bạn khi tìm hiểu sâu tình hình kinh doanh của công ty và hiểu nó. Ít nhất phải tốn một khoảng thời gian tương đối dài để bạn có thể hoàn thành tốt code của bạn.

Thử thách lẫn nhau
Vâng! Điều này là bình thường ! Bạn hoàn toàn có thể bàn luận về cách tiếp cận. Thậm chí cũng có thể tranh luận. Bạn hoàn toàn có thể giữ vững lập trường của bạn hoặc đưa ra phương án tốt hơn.

Khi bạn đang thử thách lẫn nhau với những phản hồi mang tính xây dựng, bạn sẽ không cảm thấy mình đang tranh cãi tiêu cực. Đó có thể là một quá trình đáng giá và cả hai phía đều học được rất nhiều thông qua đó.

Điều này xảy ra với tôi và một người bạn mà tôi thường làm việc chung. Anh ấy là chủ sở hữu của một sản phẩm và tôi là developer. Đôi khi chúng tôi tranh luận về một tính năng trải nghiệm người dùng hoặc một mục SEO. Tôi sẽ có một cách tiếp cận trong đầu tôi và anh ấy sẽ có một cách tiếp cận khác. Nó phụ thuộc vào việc cả hai chúng tôi cố gắng giành chiến thắng đối phương. Hãy thực sự nghĩ về bối cảnh đó.

Cố gắng thắng đối phương.

Điều đó không phải là ” Chứng minh rằng tôi thông minh hơn” hoặc những ý tương tự như thế.

Bạn muốn một số người theo phe của bạn và tìm ra được những lợi ích. Tất nhiên, điều này cũng có nghĩa là bạn cần phải luôn sẵn sàng thay đổi lập trường của mình.

Hãy giao tiếp giống như cuộc sống của bạn phụ thuộc vào điều đó

Đây cũng là một điều quan trọng cho các nhóm làm việc từ xa.

Tôi đã từng dẫn đầu một nhóm khoảng 12 người làm việc cùng một lúc. Một trong số họ ở Úc. Anh ấy thông báo tiến độ mỗi hai hoặc ba giờ. Y chang hoạt động của một cái đồng hồ. Ngay cả khi anh ấy chỉ muốn nói ” Không có cập nhật gì kể từ lần trước, chỉ bashing code ra”. Ban đầu, tôi đã rất khó chịu với số lượng tin nhắn tôi phải đọc.

Tôi nhanh chóng, rất nhanh, đã thay đổi suy nghĩ của mình về ý kiến đó khi có một thành viên trong nhóm không nói chuyện với tôi trong một ngày và sau đó, vào cuối ngày, trình bày với tôi những gì họ đã làm và đã đi quá sai với yêu cầu ban đầu của tôi. Tôi muốn được thông báo mỗi ba giờ một lần để xem những gì đang xảy ra, và sau đó đi 8 hoặc nhiều giờ hơn với bất cứ điều gì và đặc biệt quan tâm vào thời gian cuối.

Đối với các vị trí quản lý, điều này có thể được hiểu theo cách khác. Giao tiếp có thể được thể hiện dưới hình thức giải thích các yêu cầu hoặc tại sao lại đặt ra timeline đối với những công việc cụ thể. Đó là một góc nhìn khác khi nói về truyền thông từ nhà tuyển dụng, nhưng nó thật sự rất quan trọng. Bạn cần có khả năng giúp các developers hiểu yêu cầu của bạn để họ có thể đưa ra câu trả lời chính xác nhất.

Kết luận
Nhìn chung, đây chỉ là một vài điều tôi lượm lặt được từ kinh nghiệm trong quá khứ của tôi. Tôi hi vọng những điều này có thể giúp đỡ được những bạn đang gặp trường hợp tương tự.

Cảm ơn các bạn đã đọc bài viết của tôi và đừng ngần ngại liên hệ với tôi nếu bạn có bất cứ điều gì muốn nói hoặc hỏi, hoặc nếu bạn chỉ đơn giản muốn chụp chung một tấm.

[INFOGRAPHIC]: Những con số hấp dẫn về lương của Software Engineer

lương Software Engineer

Lương Software Engineer từ lâu đã trở thành một chủ đề rất được quan tâm. Nhiều người tin rằng, mức lương của nhà phát triển phổ thông rất cao. Nếu đó là sự thật, tại sao lại có đến 54,8% developers không hài lòng với tiền lương của họ?

Để giúp bạn hiểu rõ hơn về vấn đề tiền lương phức tạp này, chúng tôi đã thu thập dữ liệu từ Cục Thống kê Lao động, Stack Overflow, LinkedIn, Glassdoor, Jobvite, PayScale, Hannah Riley Bowles, Linda Babcock và nghiên cứu của Lei Lai, và InContext.

Cùng bắt đầu nào!

Infographic về lương Software Engineer

lương Software Engineer

Trong khi The Bureau of Labor Statistics cho rằng lương trung bình của một developer là 102.280 đô la mỗi năm, dữ liệu Glassdoor cho rằng mức lương trung bình của họ là 81.994 đô la một năm. Dữ liệu PayScale chỉ ra rằng một “lương Software Engineer kiếm được mức lương trung bình $ 69,083 một năm”. Sự khác biệt giữa các con số này có thể được giải thích bởi một số yếu tố. Trong khi một số yếu tố liên quan đến cá nhân (như trình độ chuyên môn của họ có thể được cải thiện dựa trên động lực và thái độ sẵn sàng học hỏi), những yếu tố khác được coi là yếu tố ngoại cảnh.

Chúng bao gồm, ví dụ, vị trí địa lý của công ty hoặc quy mô của nó ( mà nhà phát triển không thể hoặc ít kiểm soát). Thật thú vị, sự khác biệt về mức lương của các kỹ sư phần mềm ở các thành phố khá rõ ràng. Xem xét 6 địa điểm được trình bày trong infographic, sự khác biệt về mức lương giữa top một (San Francisco) và mức cuối (Minneapolis) đạt trên $28.000.

Tính lương chuẩn với công cụ tính lương gross – net tại TopDev

Các yếu tố ảnh hưởng đến mức lương của nhà phát triển

Như đã đề cập trong infographic, có nhiều yếu tố ảnh hưởng đến sự khác biệt về lương Software Engineer. Bao gồm:

  • Kinh nghiệm,
  • Kiến thức về ngôn ngữ và thư viện,
  • Tài năng hồ bơi kích thước,
  • Quy mô công ty,
  • Tập trung công nghiệp,
  • Địa điểm Triệu chứng.

LocaQuotient (LQ) là gì?

Theo Cục Phân tích Kinh tế, LQ là một số liệu thống kê ” đo lường mức độ chuyên môn trong một đơn vị địa lý lớn hơn (thường là quốc gia)”. Nó cho phép việc xác định những ngành làm cho khu vực được chỉ định trở nên độc đáo hơn.

Khi nói đến các software developers, Washington có location quotient cao nhất (2,83), tiếp theo là New Jersey (1,88), Colorado (1,83), Virginia (1,64) và Massachusetts và (1,59). LQ cho California bằng 1,43.

Sự khác biệt tiền lương Software Engineer theo giới tính

May mắn thay, khoảng cách về lương theo giới tính trong công nghệ nhỏ hơn so với các ngành khác. Tuy nhiên, vẫn còn nhiều thứ phải giải quyết. Theo số liệu của PayScale, ” khoảng cách về lương theo giới tính không thể kiểm soát đối với các cá nhân đóng góp cho ngành công nghệ là -18.8%”, so với 21.1% đối với những người không làm việc trong ngành công nghệ.

Đối với phụ nữ và nam giới trong những vị trí tương tự (được kiểm soát) ” khoảng cách về thu nhập của các cá nhân làm việc trong ngành công nghệ là -1,2%”, so với -3,2% ngoài ngành công nghệ. Khoảng cách giữa những người đàn ông và phụ nữ đang làm các công việc tương tự (được kiểm soát) thậm chí còn cao hơn đối với các công việc quản lý, giám đốc và giám đốc điều hành khi đạt đến -5,6% chi trung bình.

Có một số điều bạn có thể làm để tạo ra một công ty công nghệ thân thiện với phái nữ. Để đọc thêm, tôi khuyên bạn nên đọc bài đăng của chúng tôi: 10 bước để tuyển dụng nhiều phái nữ hơn trong công nghệ.

Làm thế nào để biến kiến thức thành hành động?

  5 thói quen xấu khiến developer bị sa thải

Vì lương bổng là trở ngại lớn thứ hai trong việc thu hút nhân tài, công ty cần phải linh hoạt hơn khi đàm phán về lương. Điều này đồng nghĩa với việc các ứng cử viên đã quen và dần tự tin hơn khi đàm phán về vấn đề này. Là một người tuyển dụng, bạn cần phải chuẩn bị chiến lược về cách bạn muốn giao tiếp trong quá trình phỏng vấn.

Hãy suy nghĩ về các yếu tố phi tiền tệ có thể mang lại cho bạn lợi thế tuyển dụng, như xây dựng thương hiệu mạnh của nhà tuyển dụng hoặc cung cấp các tùy chọn công việc từ xa, điều này rất quan trọng đối với 64% các nhà phát triển.

Xem qua các quảng cáo việc làm của bạn và tìm ra những sự thiên vị, bao gồm cả xu hướng giới tính khi trả lương. Mặc dù khoảng cách lương bổng theo giới tính trong công nghệ nhỏ hơn so với các ngành khác, bạn vẫn cần xem dữ liệu về mức lương của nhà phát triển và đánh giá liệu bạn có ” vô tình ” không công bằng trong việc trả lương cho các nhà phát triển nữ so với các nhà phát triển nam của cùng một công việc.

Trong khi sourcing, hãy tìm ra các nhà phát triển đã công khai bày tỏ sự sẵn sàng để luân chuyển.

Hãy nghĩ đến việc giới thiệu các gói hỗ trợ luân chuyển trong công ty của bạn để thu hút tài năng công nghệ hàng đầu từ các khu vực ít tập trung hơn.

Source: Devskiller

Có thể bạn muốn xem thêm:

Tham khảo thêm những công việc lập trình hot nhất thị trường tại đây

1...203204205...230Page 204 of 230