Sử dụng v-model trên component lồng nhau

Cách viết dùng v-model để tự đồng bộ giá trị khi lồng các component

Bạn có component nhận vào prop, muốn sử dụng v-model để nó tự cập nhập giá trị khi có thay đổi

// Address.vue
<template>
    <div>
        <input name="street" v-model="street">
        <input name="city" v-model="city">
        <input name="state" v-model="state">
        <input name="zip" v-model="zip">
    </div>
</template>
<script>
    export default {
        props: ['street', 'city', 'state', 'zip']
    }
</script>

Bạn truyền nó vào như thế này, với hy vọng mọi thứ chạy ngon lành

// Form.vue
<template>
    <form>
        <input name="name" v-model="name">
        <input name="email" v-model="email">
        <mailing-address
            :street="address.street"
            :city="address.city"
            :state="address.state"
            :zip="address.zip"
        />
    </form>
</template>
<script>
    import MailingAddress from './Address.vue';
    export default {
        components: { MailingAddress },
        data() {
            return {
                address: {
                    street: '',
                    city: '',
                    state: '',
                    zip: ''
                }
            }
        }
    }
</script>

Nhưng không 😭 nó sẽ thông báo trong console, “Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-renders. “

Về nguyên tắc, chúng ta ko được thay đổi giá trị của prop, nếu không lúc re-render nó sẽ ko còn đúng nữa

Để nó chạy ngon lành, chúng ta không dùng prop. Khi sử dụng v-model nó làm cho chúng ta 2 việc, bind giá trị vào biến value, gắn handle cho sự kiện v-on:input. Túm lại chúng ta ko cần dùng prop làm gì cả, chỉ việc dùng lùng value bên trong component

// Address.vue
<template>
    <div>
        <input name="street" v-model="value.street">
        <input name="city" v-model="value.city">
        <input name="state" v-model="value.state">
        <input name="zip" v-model="value.zip">
    </div>
</template>
<script>
    export default {
        props: {
            value: {
                type: Object,
                required: true
            }
        },
        watch: {
            value() {
                this.$emit('input', this.value);
            }
        }
    }
</script>

Khi sử dụng

<mailing-address v-model="address" />

Nếu nó thêm một cấp nữa thì sao? Ví dụ bên trong Address.vue chúng ta nhét thêm một component cháu nội của Form nữa

// Address.vue
<template>
    <div>
        ...
        <state v-model="value.state" />
</div>
</template>
<script>
    import State from "./State";
    export default {
        components: { State },
        props: {
            value: {
                type: Object,
                required: true
            }
        },
        watch: {
            value() {
                this.$emit('input', this.value);
            }
        }
    }
</script>

State component

<template>
    <select v-model="value">
        <option v-for="(state, abbreviation) in states"
                :value="abbreviation"
                v-html="state"
        ></option>
    </select>
</template>
<script type="text/babel">
    export default {
        props: {
            value: {
                type: String,
                required: true
            }
        },
        data() {
            return {
                states: {
                    NY: 'New York',
                    WI: 'Wisconsin'
                    // + rest of the states
                }
            }
        }
    }
</script>

Nó sẽ tiếp tục chửi bới chúng ta, vì chúng ta đi thay đổi prop nữa rồi, chúng ta cần đưa nó về computed

// State.vue
<template>
    <select v-model="localState">
        <option v-for="(state, abbreviation) in states"
                :value="abbreviation"
                v-html="state"
        ></option>
    </select>
</template>
<script type="text/babel">
    export default {
        props: {
            value: {
                type: String,
                required: true
            }
        },
        data() {
            return {
                states: {
                    NY: 'New York',
                    WI: 'Wisconsin'
                    // + rest of the states
                }
            }
        },
        computed: {
            localState: {
                get() {return this.value},
                set(localState) { this.$emit('input', localState)}
            }
        }
    }
</script>

Cách này giống như chúng ta dùng controlled component trong React

TopDev via Vuilaptrinh

CEO TopDev ra mắt công nghệ AI/Computer Vision trợ giúp kết nối doanh nghiệp với người mất việc vì Covid

Covid-19 là nguyên nhân chính gây ra tình trạng sa thải hàng loạt do thu hẹp quy mô, giải thể, cắt giảm nhân sự của rất nhiều doanh nghiệp. Tại Mỹ, chỉ riêng 1 tháng kể từ lúc bùng phát dịch, đã có đến hơn 400 startup công khai cắt giảm đến hơn 50 nghìn việc làm. Con số này mới chỉ là bề nổi rất nhỏ và chỉ tính riêng các startup công nghệ tại Silicon Valley (Nguồn: https://layoffs.fyi)

Tại Việt Nam, theo một khảo sát gần đây nhất của TopDev một trong những đơn vị tuyển dụng IT uy tín nhất hiện nay, cho biết có đến 34% doanh nghiệp đang phải thu hẹp quy mô, cắt giảm chi phí và nhân sự để tồn tại trước nguy cơ kéo dài cho đến khi tìm ra vaccine.

Đã có rất nhiều giải pháp hỗ trợ người mất việc, phổ biến nhất là công khai danh sách các nhân sự bị mất việc để các doanh nghiệp khác có thể tiếp nhận tuyển dụng lại, tuy nhiên việc này dẫn đến lộ các thông tin cá nhân như số điện thoại hoặc email, đây là miếng mồi ngon cho các loại tội phạm mạng khác khai thác.

Bên cạnh đó, việc này cũng không giúp ích gì nhiều cho người mất việc lẫn doanh nghiệp vì không đủ thông về học vấn, kỹ năng, kinh nghiệm…điều mà ứng viên thường thể hiện trong CV tìm việc, khiến cho doanh nghiệp rất khó để chọn đúng người để tuyển dụng lại.

Với một cách tiếp cận rất khác, sử dụng AI để ẩn tự động các thông tin liên hệ trong CV, bảo mật thông tin cá nhân, trong khi vẫn không làm mất đi tính thẩm mỹ và các thông tin chi tiết khác lột tả chính xác về ứng viên, kết hợp với nền tảng kết nối tự động giúp doanh nghiệp đánh giá cũng như tìm đúng người họ cần.

Khi truy cập vào covid.topdev.vn, doanh nghiệp sẽ tiếp cận danh sách rất nhiều ứng viên đang tìm việc mới đi kèm với CV của từng người, chỉ vài thao tác gõ từ khóa tìm kiếm hoặc sử dụng bộ lọc sẽ cho ra kết quả những nhân sự phù hợp với nhu cầu.

Nền tảng công nghệ AI quét và che thông tin cá nhân trong file PDF được chính CEO Nguyễn Hữu Bình phát triển từ một hobby project (dự án nghiên cứu từ sở thích cá nhân) mà ông đã theo đuổi 3 năm, cho khả năng nhận dạng chính xác dù CV được tạo ra từ bất kỳ công cụ hoặc dịch vụ nào.

Để hiểu hơn về đặc thù của nền tảng, “cha đẻ” của hệ thống Covid.topdev cho biết: “Tôi đã sử dụng nhiều tiến bộ mới nhất của công nghệ nhận dạng để có thể hoạt động chính xác với muôn hình vạn trạng cách design CV của người tìm việc vì để đảm bảo được thiết kế gốc và xác định vị trí thông tin là điều hết sức phức tạp; việc sử dụng công nghệ mới giúp họ thể hiện tốt nhất những gì mình có, lại đảm bảo an toàn thông tin riêng tư trong quá trình tìm việc mới”.

Giải pháp ra đời với kim chỉ nam trợ giúp người mất việc tìm việc mới nhanh nhất có thể, ứng viên được đảm bảo những tiêu chuẩn về nội dung, hình thức, tính bảo mật thông tin cá nhân, mở ra khả năng tìm được việc mới nhanh gấp nhiều lần so với trước đây, hiện đây là một hệ thống công khai CV trong điều kiện bảo mật tân tiến nhất trong giới công nghệ tuyển dụng ở Việt Nam và thế giới

Nếu như đã chuẩn bị sẵn CV cho mình, thì bạn không cần phải làm gì nhiều nữa – chỉ cần đăng tải trực tiếp hoặc URL bộ Resume/ CV của mình tại Hệ thống.

Ngay sau khi đăng tải, hệ thống tích hợp công nghệ AI – Computer vision sẽ tiến hành đọc quét dữ liệu của hồ sơ và ẩn đi các thông tin cá nhân của bạn – tất cả các thông tin cá nhân nhạy cảm bao gồm hình chụp thẻ, thông tin email, số điện thoại, các đường link mạng xã hội,… sẽ được ẩn đi ngay khi upload CV. Kể từ đó, bạn có thể rải chiếc CV của mình ở khắp nơi như các group trên Facebook, Linkedin hay các forum tập trung nhiều nhà tuyển dụng mà không bị lộ thông tin cá nhân, trong khi nhà tuyển dụng vẫn có thể liên hệ khi cần và sau khi được sự đồng ý của bạn.

Đây là phần điểm sáng và tiến tiến nhất của nền tảng Covid.topdev. Hệ thống Covid.topdev giúp đảm bảo với người tìm việc:

Cam kết bảo mật thông tin: Qua Covid.topdev, hệ thống sẽ bảo vệ bạn bằng cách che các thông tin nhạy cảm (gương mặt, thông tin email – số điện thoại…), chỉ cho phép nhà tuyển dụng download bản gốc khi có sự đồng ý của bạn.

Hiện nay trên thị trường không thiếu các hệ thống cho đăng tải CV đơn giản, và các nhà tuyển dụng sau khi có thông tin các CV tiềm năng sẽ liên hệ ngay đến ứng viên. Tuy nhiên mô hình cũ này làm cho người tìm việc ở thế “bị động” – họ dễ rơi vào tình trạng spam offer từ nhiều nhà tuyển dụng mà chưa có thông tin trước.

Một khi hồ sơ của bạn được cho là tiềm năng, nhà tuyển dụng sẽ tiến hành gửi JD (Job description) về email của bạn thông qua hệ thống của nền tảng. Bạn sẽ có thể preview JD và lựa chọn các bên mà mình cảm thấy phù hợp và tiếp tục các khâu tiếp theo: Liên hệ với nhà tuyển dụng bằng CV đầy đủ và phỏng vấn.

Giữ nguyên format của CV: Sẽ không ít các bạn lo lắng về việc khi hệ thống xử lý và quét các thông tin trên CV và ảnh hưởng đến format bạn đã thiết kế và apply cho CV của mình. Hệ thống Covid.topdev cải tiến đảm bảo giữ nguyên format và trạng thái CV của bạn sau khi đã upload lên hệ thống, dù bạn đã thiết kế CV bằng các loại công cụ hay dịch vụ khác nhau

Chỉ các thông tin cá nhân liên quan được phát hiện sẽ được che đi và tất cả các thông tin còn lại sẽ “yên vị”, đảm bảo công sức làm đẹp đơn ứng tuyển và gây ấn tượng với các nhà tuyển dụng.

Spread CV hiệu quả hơn: Đơn cử phía TopDev cũng là một đơn vị chuyên trang tin Tuyển dụng hot nhất hiện nay tại Việt Nam. Với số lượng khách hàng doanh nghiệp “khủng” nhất nhì tại thị trường, hệ thống hoàn toàn có thể giúp mang hồ sơ của bạn (sau khi đã được xử lý thông tin) nhanh chóng tiếp cận các nhà tuyển dụng hơn trong vị trí mong muốn của mình.

Trường hợp bạn chưa có CV trong tay, thì cũng không phải lo lắng. Hệ thống TopDev đã đồng thời tích hợp với bộ công cụ tạo CV online cho phép bạn chỉ cần input các thông tin và chọn các template CV mới nhất có sẵn của hệ thống được update thường xuyên. Ngay sau khi hoàn thiện CV, bạn sẽ có thể thao tác đăng tải lên nền tảng Covid.topdev và đợi thông tin từ phía nhà tuyển dụng.

Các nhà tuyển dụng từ các tổ chức/doanh nghiệp khi tìm kiếm ứng viên, họ muốn có một danh sách được sắp xếp theo trình tự logic, rõ ràng và có thao tác dễ dàng sử dụng.

Trong đó, mỗi thông tin về ứng viên cần được cập nhập đầy đủ, chính xác về trình độ chuyên môn, kinh nghiệm để họ có thể khoanh vùng, chọn lọc và liên hệ ứng viên phù hợp nếu đáp ứng đủ những tiêu chí mà vị trí nhân sự họ đang tuyển dụng. Và tất nhiên, giải pháp tạo CV của TopDev hoàn toàn thực hiện tốt vai trò này.

Sau khi truy cập vào https://covid.topdev.vn/

Bước 1: Chọn vào ô Search (Box 1) và gõ vị trí/ skill cần tìm

Bước 2: Chọn mục Filter (Box 2) và chọn điều kiện lọc kèm (Vd: Location, Date ứng tuyển,…)

Bước 3: Gõ điều kiện vị trí tương ứng cần tìm

Sau khi nhận yêu cầu, hệ thống sẽ cho hiển thị list các CV ứng viên tương ứng với yêu cầu của nhà tuyển dụng. Nhân sự có thể nhấn preview xem CV của các bạn mà không có thông tin liên hệ trước. Nếu như cảm thấy CV đạt yêu cầu, nhân sự sẽ Mời ứng tuyển CV đó bằng cách gửi JD vị trí về email của bạn qua hệ thống.

Các resume – CV trên nền tảng của TopDev chắc chắn sẽ không làm nhân sự thất vọng vì sự chỉn chu, chuyên nghiệp và được hợp thức hoá theo mô hình đa dạng tùy ngành nghề, tránh lối mòn chỉ đơn thuần trình bày như một đơn khai báo thông tin theo các form chưa có sự thống nhất về quy cách.

Chính bằng tính năng tuyệt vời của mình cũng góp phần tạo ra nhiều cơ hội hơn để hồ sơ các ứng viên có thể tiếp cận đến với nhiều nhà tuyển dụng. Đây cũng là điểm đặc biệt tạo nên lợi thế của giải pháp từ TopDev; vừa giúp người giúp việc tiếp cận nhà tuyển dụng nhanh chóng hơn, mà chính các nhà tuyển dụng cũng có được một nền tảng mới dễ dàng tìm kiếm ứng viên chuyên nghiệp và tiềm năng.

Đây là một dự án được xem là một bước đi khá liều lĩnh. Qua đó ông Nguyễn Hữu Bình cũng chia sẻ: “Vì hỗ trợ hoàn toàn miễn phí nên tiềm ẩn rủi ro ảnh hưởng đến doanh thu của công ty, nhưng trước tình hình 34% doanh nghiệp đang phải cắt giảm chi phí, quy mô hoạt động và sa thải nhân sự, với mong muốn hỗ trợ xã hội và cộng đồng, tôi nhận được sự ủng hộ của hội đồng quản trị cũng như sự động viên của đội ngũ dưới quyền khi triển khai dự án này.”

Giải pháp bảo mật CV từ đội ngũ TopDev nói chung và sáng kiến từ ông Nguyễn Hữu Bình, CEO của TopDev cùng các cộng sự của mình nói riêng nhằm hướng đến việc cung cấp cho các ứng viên đang thất nghiệp có cơ hội trải nghiệm và truyền tải CV online của mình trên một nền tảng công nghệ được đảm bảo về tính an toàn, xác thực. TopDev hy vọng giải pháp ra đời sẽ tạo ra một sự cộng hưởng lớn, mang lại những giá trị thiết thực nhất cho người dùng.

Tạo một animation cho component trong React

Sử dụng React, styled-components, react-flip-toolkit để tạo animation giống như mên trên trang chủ của Stripe

Phân tích

Trước tiên phân tích cái animation này ra thành nhiều phần để dể hình dung. Có thể xem dạng slow motion trên Codepen để xem nhé.

container dropdown màu trắng sẽ thay đổi kích thước và vị trí
background màu xám ở phía dưới của dropdown transition độ cao
Khi di chuyển chuột khỏi dropdown, fade out nội dung trước đó đi và chuyển vị trí nó sang element mới, sau đó đưa nội dung mới lên.

Tìm việc React lương cao trong tháng up to 25M

Một vài lưu ý khi làm animation với React, cứ để browser quản lý layout. Thay vì sử dụng các dropdown khác nhau, chúng ta dùng 1 dropdown và thay đổi vị trí của nó, dùng Flip technique để giả lập như có 3 dropdown khác nhau.

Dựng component thô chưa có animate

Để bắt đầu ta dựng một component navbar sử dụng styled-component

Ở đây thì chưa thêm phần gray background ở dưới dropdown, cái này nó sẽ nằm absolute

Animate với Flip technique

Chúng ta sẽ sử dụng react-flip-toolkit để thay đổi kích thước và vị trí dropdown.

<Flipper flipKey={currentIndex}>
  <Navbar>
    {navbar.Config.map((n, index) => {
      // render navbar items
    })}
  </Navbar>
</Flipper>

Ở DropdownContainer component, đưa các element sẽ animate vào bên trong Flipped component, nhớ giá trị flipId phải khác nhau

<DropdownRoot>
  <Flipped flipId='dropdown-caret'>
    <Caret />
  </Flipped>
  <Flipped flipId='dropdown'>
    <DropdownBackground>
      {children}
    </DropdownBackground>
  </Flipped>
</DropdownRoot>

Làm 2 cái animate trên <Caret/> và <DropdownBackground/> riêng biệt, để thuộc tính overflow: hidden set trên <DropdownBackground /> không ảnh hưởng tới <Caret/>

Giờ có 1 vấn đề nhỏ là nội dung bên trong dropdown lúc xuất hiện bị stretch một cách kỳ cục, lý do là thuộc tính transforms: scale nó áp luôn trên children. Xử lý cái này bằng cách đưa nội dung này vào trong <Flipped/> kèm giá trị cho props inverseFlipId, lúc này children sẽ không bị effect từ thằng cha nữa, đồng thời xác định luôn là ko muốn áp thằng scale

<DropdownRoot>
  <Flipped flipId="dropdown-caret">
    <Caret />
  </Flipped>
  <Flipped flipId="dropdown">
    <DropdownBackground>
      <Flipped inverseFlipId="dropdown" scale>
        {children}
      </Flipped>
    </DropdownBackground>
  </Flipped>
</DropdownRoot>

Chăm chút

Cũng gần được rồi, chúng ta cần để ý thêm vào những chi tiết nhỏ nhất để animate nhìn cool hơn

Styled-components hỗ trợ rất tốt việc thay đổi keyframe animation. Chúng ta sẽ sử dụng tính năng này để làm animation lúc enter và cross-fade nội dung dropdown khi thay đổi ví trí chuột.

const getFadeContainerKeyFrame = ({ animatingOut, direction }) => {
  if (!direction) return;
  return keyframes`
    from {
      transform: translateX(${
        animatingOut ? 0 : direction === 'left' ? 20 : -20
      }px);
    }
    to {
      transform: translateX(${
        !animatingOut ? 0 : direction === 'left' ? -20 : 20
      }px);
      opacity: ${animatingOut ? 0 : 1};
    }
  `;
};

const FadeContainer = styled.div`
  animation-name: ${getFadeContainerKeyFrame};
  animation-duration: ${props => props.duration * 0.5}ms;
  animation-fill-mode: forwards;
  position: ${props => (props.animatingOut ? "absolute" : "relative")};
  opacity: ${props => (props.direction && !props.animatingOut ? 0 : 1)};
  animation-timing-function: linear;
  top: 0;
  left: 0;
`

Khi user đưa chuột lên menu mới, chúng ta ko chỉ đưa vào dropdown hiện tại mà con dropdown trước đó như children cho DropdownContainer, cùng với những thông tin về hướng di chuột của user. Sau đó DropdonwContainer sẽ wrap hết tất cả children của nó trong một component mới, FadeContents, thằng này sẽ sử dụng keyframe animation code ở trên để thêm animation tương ứng

Background animation

Cuối cùng chúng ta thêm gray background

const updateAltBackground = ({
  altBackground,
  prevDropdown,
  currentDropdown
}) => {
  const prevHeight = getFirstDropdownSectionHeight(prevDropdown)
  const currentHeight = getFirstDropdownSectionHeight(currentDropdown)
  
  // we'll use this function when we want a change 
  // to happen immediately, without CSS transitions
  const immediateSetTranslateY = (el, translateY) => {
    el.style.transform = `translateY(${translateY}px)`
    el.style.transition = "transform 0s"
    requestAnimationFrame(() => (el.style.transitionDuration = ""))
  }

  if (prevHeight) {
    // transition the grey ("alt") background from its previous height
    // to its current height
    immediateSetTranslateY(altBackground, prevHeight)
    requestAnimationFrame(() => {
      altBackground.style.transform = `translateY(${currentHeight}px)`
    })
  } else {
    // immediately set the background to the appropriate height
    // since we don't have a stored value
    immediateSetTranslateY(altBackground, currentHeight)
  }
}

Source: https://github.com/aholachek/react-stripe-menu

TopDev via Vuilaptrinh

Xem thêm các vị trí tuyển nhân viên it tại đây

Sử dụng CSS content như thế nào cho đúng

Thuộc tính content trong CSS thường được sử dụng cùng với 2 ghost element là after và before, những giá trị nào có thể đưa vào cho thuộc tính content này

<div 
  data-done="&#x2705;"
  class="email">
    chriscoyier@gmail.com
</div>

.email::before {
  /* Chèn trước thẻ div giá trị của data-done + Email: */
  content: attr(data-done) " Email: "; 
}

Không phải giá trị nào đưa vào content này cũng hợp lệ

/* Được */
::after {
  content: "1";
}

/* Không được */
::after {
  content: 1;
}

Không thể tính toán gì đâu, nó chỉ là string thôi

<div data-price="4" data-sale-modifier="0.9">Coffee</div>

/* Méo chạy */
div::after {
  content: " $" 
    calc(attr(data-price) * attr(data-sale-modifier));
}
/* Nope */
::after {
  content: calc(2 + 2);
}

Muốn nối chuỗi ư?

/* Không chạy đâu, không phải javascript hay php */
::after {
  content: "1" . "2" . "3";
  content: "1" + "2" + "3";

  /* Dùng bình thường thế này thôi */
  content: "1" "2" "3";
  content: "1 2 3";
}

Đường dẫn hình thì được, mà không cho thay đổi kích thước hình ¯_(ツ)_/

p:before {
  content: url(image.jpg);
}

TopDev via Vuilaptrinh

4 cách thúc đẩy sự phát triển nhân viên tại công ty

Phát triển nhân viên có ý nghĩa quan trọng vì nó là sự cam kết về việc tạo môi trường hỗ trợ nhân viên cho họ nhìn thấy được những tiến bộ chuyên nghiệp của mình trong từng giai đoạn. Đồng thời, phát triển nhân viên là một sáng kiến dài hạn và có những ảnh hưởng sâu sắc đến hiệu suất công việc, niềm tin với tổ chức và cả sự đồng hành. Cùng TopDev theo dõi bốn cách sau đây và bạn có thể bắt đầu cải thiện sự phát triển nhân viên tại công ty của mình.

1. Có chiến lược đào tạo rõ ràng & chuyên nghiệp

Để có thể dẫn dắt các nhân viên của bạn đạt đến sự thành công thì việc đầu tiên chính là cung cấp cho họ tất cả các công cụ và tài nguyên họ cần, nhằm thực hiện tốt công việc của mình. Điều này bao gồm đào tạo chuyên nghiệp.

Hãy xây dựng một nền tảng kiến thức với các thông tin quan trọng được minh chứng bởi số liệu thực tế để nhân viên có thể nắm được kiến thức nền (background knowledge) một cách tốt nhất.

Ngoài ra, khi sự phát triển công nghệ đang thay đổi nhiều lĩnh vực trong cuộc sống, nhân viên của bạn cần tiếp cận nhiều kiến thức hơn thay vì những nguồn thông tin vẫn chưa được cập nhật và đổi mới toàn diện. Cũng chính từ đó mà các công ty đã áp dụng nhiều mô hình giải pháp đào tạo khác nhau cho nhân viên của mình.

Ví dụ như giải pháp học trực tuyến về các nguồn dữ liệu khoa học thông tin như Udemy , LinkedIn Learning và CodeAcademy,.. Đây là những nguồn đáng tin cậy không những cung cấp cho nhân viên các kiến thức với sự linh động về thời gian mà còn tạo ra cơ hội cho nhân viên tự khai thác và vận dụng kiến thức vào quy trình thực hiện công việc của mình. Nếu chỉ xét riêng về khía cạnh trong ngành Nhân sự, thì trong một nghiên cứu trong bài Báo cáo về thế hệ Nhân sự tiếp theo của 15Five, có đến 75% các nhân viên tiềm năng đã bày tỏ nguyện vọng của mình về việc được đào tạo thêm các kỹ năng về quản lý và lãnh đạo. Điều này cho thấy mong muốn được học hỏi ở họ là rất lớn.

2. Phát triển người quản lý thành cố vấn chuyên môn cho các nhân viên

Là một người lãnh đạo, dường như việc bạn kiểm soát sự nỗ lực, ghi nhận sự thay đổi và phát triển của nhân viên mình là vô cùng khó khăn. Và người quản lý chính là người sẽ giúp bạn theo dõi, đánh giá đúng tình hình về mức độ phát triển của từng nhân viên trên lộ trình thăng tiến riêng của từng người. Vì thế, để cải thiện sự phát triển của nhân viên, điều đầu tiên bạn nên làm là phát triển kỹ năng của người quản lý thành một huấn luyện viên thật sự hiệu quả để họ có thể thúc đẩy kinh nghiệm và tạo động lực cho các nhân viên của mình.

Công việc của một cố vấn chuyên môn chính là đồng hành và báo cáo về những cố gắng của nhân viên; điểm mạnh nào cần phát huy – điểm yếu nào cần khắc phục. Ngoài ra, người quản lý cần nắm được những mong muốn của nhân viên như: điều gì làm họ thích thú với công việc, điều gì làm họ kiệt sức,… để kịp đưa ra những giải pháp điều chỉnh và phát triển cho phù hợp. Và để dễ dàng nắm bắt và huấn luyện các nhân viên, người quản lý hãy bắt đầu bằng cách hỏi một số câu hỏi đơn giản như sau:

– Có bất kỳ trở ngại nào bạn đang gặp phải, và tôi có thể giúp gì không?

– Thời điểm trong ngày của bạn mà bạn thấy tràn đầy năng lượng nhất?

– Bạn muốn học thêm điều gì có thể giúp bạn thực hiện tốt vai trò của mình?

Hãy cho phép người quản lý tự định hướng những cuộc trao đổi để nhân viên có thể tự bày tỏ suy nghĩ về các thành tích. Từ đó, các nhà quản lý có thể hỗ trợ họ phát huy tối đa tiềm năng của mình để gặt hái được những mục tiêu xa hơn.

3. Nhấn mạnh các kỹ năng mềm

Những kỹ năng mềm thường bị lãng quên trong mô hình tự động hóa hoạt động của các công ty như hiện nay. Thế nhưng, ít ai biết được rằng kỹ năng mềm thật sự là một phần không thể thiếu trong công tác lập kế hoạch phát triển năng lực cho các nhân viên.

“Các kỹ năng của tương lai không phải đơn thuần là kỹ thuật, mà chúng là hành vi. Những kỹ năng mềm gọi là “mềm” nhưng bản chất thật sự chúng không “mềm” – ngược lại, chúng rất phức tạp, là những thứ mất nhiều năm để con người có thể học hỏi, thay đổi, thích ứng với phạm vị hoạt động của chúng. Chúng tôi gọi chúng là kỹ năng của sức mạnh. Và nhớ rằng trong xu thế cạnh tranh hiện nay, hãy nắm bắt một số kỹ năng mà nhiều CEO yêu cầu: sáng tạo – tư duy đổi mới, linh hoạt – nhanh nhẹn và khả năng thích ứng với mọi môi trường.”

Chia sẻ của Josh Bersin, một tác giả nổi tiếng với những tác phẩm chuyên nói về các vấn đề xoay quanh việc phát triển con người, khả năng lãnh đạo và công nghệ nhân sự.

Các tổ chức/doanh nghiệp suy cho cùng cũng chỉ là một tập hợp gồm những con người làm việc cùng nhau dựa trên một sự thống nhất về mục tiêu, phương thức hoạt động, cách tổ chức và vận hành,… Tuy nhiên, họ quên mất sợi dây liên kết những con người lại và tạo ra hiệu suất công việc lại là những kỹ năng mềm. Các kỹ năng là chìa khóa quan trọng giúp thắt chặt các mối quan hệ đồng thời tăng cường khả năng kiểm soát và mức độ hoạt động của các công việc.

4. Đầu tư vào phát triển cá nhân

Nhân viên của bạn khó có thể phát triển được bản thân nếu cứ tập trung quá nhiều vào việc cống hiến cho tổ chức. Họ cũng chỉ là con người với bao gồm toàn bộ các trải nghiệm về thể chất, trí tuệ và cảm xúc. Vì thế để cải thiện và phát triển năng lực của họ, bạn cần tạo không gian để họ đầu tư vào việc phát triển cá nhân trước khi hướng đến mục tiêu phát triển toàn diện và chuyên nghiệp.

Bí mật giúp tạo động lực và tăng năng suất cho nhân viên!

Cân bằng cảm xúc

Điều này không quá khó khăn. Bạn có thể đặt các câu hỏi như:

Bạn cảm thấy thế nào về công việc của mình gần đây?
Bạn đang vật lộn với bất cứ điều gì?

Việc liên tiếp đặt ra các câu hỏi nhằm đáp ứng các nhu cầu cơ bản về ghi nhận, lắng nghe và phản hồi, tạo ra sự tương tác giữa nhân viên với nhà quản lý/người lãnh đạo. Một người quản lý biết cách khai thác và hỗ trợ, người có kỹ năng lắng nghe, đồng cảm và luôn hiện diện trước những thách thức của nhân viên sẽ là điểm tựa vững chắc giúp nhân viên tìm thấy sự cân bằng khi họ chìm trong một không gian cảm xúc khó khăn.

Đầu tư phát triển về mindset

Sách và các buổi hội thảo, những khóa học không nhất thiết phải là về lĩnh vực chuyên môn mà nó có thể là những nguồn bổ trợ về các kỹ năng khác, kiến thức liên ngành. Sức mạnh của việc cung cấp giáo dục không chỉ giúp nhân viên hoàn thiện lành mạnh.

Bên cạnh đó, khi nhân viên của bạn đạt được thành tích xuất sắc, người quản lý/nhà lãnh đạo có thể tạo cơ hội tiếp cận hoặc tài trợ cho các nhân viên tham gia các khóa học, những hoạt động ngoại khóa, giao lưu phù hợp với mục tiêu và sở thích cá nhân của họ.

Khi nhân viên được cung cấp các công cụ để làm tốt công việc của họ, được đào tạo để thăng tiến trong sự nghiệp, họ sẽ cảm thấy được hỗ trợ và hạnh phúc hơn. Việc quan tâm đến sự cải thiện và phát triển của nhân viên sẽ giúp họ đồng hành lâu dài với tổ chức đồng thời tạo động lực để họ hoàn thành tốt nhiệm vụ và đóng góp vào sự phát triển chung của công ty.

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

Xem thêm Top Việc làm Developer trên TopDev

Test Automation — Con đường không dễ dàng với bất kỳ ai

Tác giả: Uyen Tran

Trong những người tôi từng trò chuyện, có hai người bạn sở hữu những điểm chung rất tình cờ. Đó là Max và Ellie — cùng từ Mỹ trở về Việt Nam làm việc tại startup, cùng trở thành Test Automation Engineer dù đây không phải lựa chọn ban đầu.

Từ lâu, các vị trí Tester thuộc team Quality Assurance (QA) vốn không phải lựa chọn được ưu tiên của nhiều người so với vị trí Developer/Software Engineer. Vậy con đường “tình cờ” trở thành Test Automation Engineer của Max và Ellie đã diễn ra như thế nào? Quá trình training, công việc của họ là gì và những cơ hội phát triển cho vị trí này ra sao?

Hãy cùng nhóm báo lá cải của Got It “hỏi xoáy đáp xoay” hai nhân vật đặc biệt hôm nay để tìm hiểu ngọn ngành câu chuyện này nhé!

Uyên Trần: Các bạn từng có khởi đầu thế nào trước khi trở thành Test Automation Engineer tại Got It?

Max: Trước đây, mình từng làm Software Engineer cho một công ty nghiên cứu y học tại Mỹ, song cũng có một số cơ hội được trải nghiệm làm Test Automation. Tuy vậy, mình nhận thấy đây là một lĩnh vực phát triển ổn định, nên muốn lựa chọn một startup làm sản phẩm để học hỏi nhiều hơn. Ban đầu, mình tìm thấy Got It và chỉ có ý định apply làm Software Engineer như trước đây, không ngờ lại được offer chuyển sang một title mới toanh: Test Automation Engineer. Vì muốn thử sức xem mình có thể “lên skill” đến đâu trong ngành Test Automation, mình đồng ý ngay với lời đề nghị này.

Ellie: Khác Max, mình vốn theo học ngành kiểm toán ở Mỹ từ đầu. Đến năm ba, mình mới quyết định đăng ký thêm ngành Computer Information System trong trường vì nhận thấy IT là ngành phát triển mạnh mẽ. Ngày tốt nghiệp, cầm trên tay một tấm bằng với hai chuyên ngành, dù chẳng phải dân chính gốc nhưng mình vẫn liều mạng apply làm engineer ở Got It. Cuối cùng, mình được Got It gợi ý trở thành Test Automation Engineer để phù hợp với background học tập hiện tại. Lúc đấy mình chỉ nghĩ rằng: “Tội gì mà không thử nhỉ?”

Uyên Trần: Không ai trong số hai bạn có kinh nghiệm làm tester từ đầu, vậy Max và Ellie có gặp khó khăn gì trong quá trình training không?

Max: Vì đã có sẵn một chút nền tảng về Test Automation, mình không mất quá nhiều thời gian để học về kỹ thuật. Tuy vậy, trong nửa khoảng thời gian đầu training, mình cần nghiên cứu kỹ lưỡng về sản phẩm và quy trình của team Quality Assurance (QA). Về mặt sản phẩm, tester cần hiểu rõ flow trọng yếu của sản phẩm (hay business impact flow) ở cấp độ của cả người dùng lẫn người kiểm thử. Về quy trình, mình cần nắm chắc các công cụ chuyên biệt team sử dụng như Trello, Jira, Testrail và học thêm cả về SQL nữa! Sản phẩm và quy trình ở Got It khá phức tạp nên mình luôn phải tìm hiểu thật cẩn thận. Tester mà bỏ sót hay hiểu lầm chỗ nào thì nguy lắm!

Ellie: Trong khoảng 7 tuần training, mình cần chú trọng hơn cả về mặt kỹ thuật vì vốn không học sẵn chuyên ngành như Max. Khoảng 3 tuần cuối, mình tìm hiểu các concepts, framework về Test Automation. Phần lớn thời gian, mình học các khóa online về Python và Selenium (ngôn ngữ lập trình và framework Got It sử dụng trong Test Automation) dưới sự hướng dẫn của mentor Quý Lê (người từng được lên sóng trên blog đó).

Chỉ nhớ hồi đó các vấn đề mentor giao cho mình giải quyết cực “khoai”, nhất là việc viết test script cho một số tính năng và các bài tập liên quan đến OOP (Object-oriented programming) — một model mọi engineers ở Got It phải thuộc “nằm lòng”. Cũng may là có daily standup, mình được mentor đưa feedback và giải đáp câu hỏi thường xuyên nên cuối cùng cũng vượt “cửa ải” training thành công *cười*.

Uyên Trần: Bạn có thể mô tả cụ thể những công việc một Test Automation Engineer sẽ làm ở Got It không?

Ellie: Công việc của chúng mình có thể được mô tả với quy trình như sau. Khi đã hiểu rõ các requirements từ Product Manager, Test Automation Engineer sẽ bắt đầu viết các test cases. Chúng mình cần nghiên cứu kỹ tài liệu của developers về cách họ triển khai các tính năng, từ đó lên phương án thiết kế việc tự động hóa kiểm thử cho phù hợp. Sau đó, tester sẽ chuẩn bị các tài liệu, sắp xếp meeting để các thành viên cùng review việc triển khai (implement) test và ước tính thời gian hoàn thành.

Tiếp đến là phần việc đòi hỏi kỹ thuật phức tạp nhất: Viết code và xây dựng môi trường cho Test Automation. Giờ thì mọi thứ đã sẵn sàng, chạy test và phát hiện ra các bugs thôi! Cuối cùng, không thể quên việc kiểm thử hồi quy và flow trọng yếu của sản phẩm (Run regression and business impact flow).

Uyên Trần: Từ developer trở thành tester, Max có thấy công việc của mình phần nào nhàn hơn như suy nghĩ của nhiều người không?

Max: Là người đã trải nghiệm ở cả hai vị trí, mình thấy không thể đem hai công việc này lên bàn cân so sánh với nhau. Mình nhận thấy rằng một Test Automation Engineer vẫn phải biết xử lý các vấn đề kỹ thuật phức tạp. Ở Got It, team phải biết phân tích và quyết định hình thức kiểm thử (thủ công hay tự động) từ giai đoạn đầu, nếu chọn tự động sẽ dùng Python để triển khai (implement) test. Cùng với đó, tester cũng phải nắm chắc từng tính năng sản phẩm và cách thức hoạt động của hệ thống Back-end, Front-end để tìm ra các bugs mắt thường không thể tìm thấy.

Bên cạnh vấn đề kỹ thuật, team QA còn cần giao tiếp tốt với các thành viên khác trong team. Một bên là Product Manager (PM) để làm rõ các requirements và ticket; một bên là Software Engineers để đảm bảo các features tạo ra vừa đúng yêu cầu, vừa giúp giảm mức độ phức tạp của việc test.

Kỷ niệm “sấp” nhất với mình có lẽ chính là công việc đầu tiên sau khi hoàn thành training. Lúc này, team cần hoàn thành hệ thống Onboarding Experts cho sản phẩm ExcelChat và PowerpointChat — một bước quan trọng giúp thu hút và tuyển dụng các experts. Cùng với PM và team dev, team QA cũng làm việc cấp tốc chỉ trong vòng 2 tuần. Khi ấy, mình đã cảm nhận rõ hơn bao giờ hết tính chất của một startup — một guồng quay khác biệt hoàn toàn so với những gì mình làm trước đây.

Uyên Trần: Sau gần một năm làm trong team QA, với các bạn, đâu là đặc điểm nổi bật nhất một Test Automation Engineer cần có?

Ellie: Ngay từ những ngày onboarding đầu tiên, mình đã được mentors nhắc lại nhiều lần về đặc điểm khiến cho mọi QA Engineers ở Got It hoàn thành tốt công việc: “Be proactive to ask questions” (Hãy chủ động đặt câu hỏi), và mình vẫn thấy điều đó đúng cho đến bây giờ. Một tester phải luôn biết chủ động đặt câu hỏi, về những gì mình chưa hiểu, về cách vận hành của thế giới xung quanh. Từ đó, bản thân sẽ trở nên nhạy bén hơn với các vấn đề, nhanh chóng phát hiện ra các bugs đang tồn tại.

Nhưng không phải cứ đặt câu hỏi bừa, mà phải biết đặt những câu hỏi cần thiết và đúng lúc. Để làm được điều đó, bản thân mình đã luyện tập và cải thiện khả năng research. Trước khi đặt câu hỏi, mình tự nghiên cứu trước vấn đề bằng những resources hiện có, hình dung tổng quan vấn đề và chỉ tìm đến sự giúp đỡ với những khía cạnh thực sự phức tạp.

Max: Ngoài ra, mình thấy khả năng ước tính (estimation) và quản lý công việc cũng rất cần thiết với một tester. Từ giai đoạn đầu, tester đã cần ước tính các deadline quan trọng cho việc test, từ đó mới có thể tổ chức, thiết kế và viết test cases một cách hợp lý nhất. Thực chất thì khả năng ước tính cũng được rèn luyện trong chính cách mỗi người quản lý công việc cá nhân hàng ngày rồi. Làm ở startup, mình học cách tự set các deadlines cho bản thân, phân chia khối lượng công việc phù hợp và bám chắc theo các kế hoạch để hoàn thành. Nếu không, bản thân sẽ dễ trở nên quá tải và bỏ lỡ việc cần làm.

Uyên Trần: Cùng là du học sinh trở về Việt Nam, lại làm trong ngành kiểm thử vốn tồn tại một số định kiến, các bạn nghĩ sao về cơ hội phát triển cho mình?

Ellie: Thực tế, sau khi làm Test Automation Engineer một thời gian, mình nhận ra đây là vị trí giúp một người có thể phát triển theo cả mảng technical (kỹ thuật) lẫn management (quản lý). Với những kỹ năng và kiến thức có được, mình có thể lựa chọn trở thành kỹ sư phần mềm, nhưng cũng có thể tiếp tục làm Test Lead hay thậm chí chuyển hướng trở thành Product Manager/Technical Product Manager. Có thể nói rằng, vị trí này mở cho mình cánh cửa đến với nhiều cơ hội đa dạng trong tương lai.

Max: Giống như Ellie nói, mình cũng thấy những gì học được từ Test Automation nói riêng và QA nói chung có thể được áp dụng ở rất nhiều công việc khác nhau. Làm Test Automation Engineer, mình thấy chuyển hướng sang làm cả Business Intelligence Analyst cũng là điều hoàn toàn có thể xảy ra đấy! Vậy nên, nếu bạn nào còn đang e ngại về nghề tester, hãy thử một lần cởi mở và cơ hội này và thử sức với nó xem sao nhé.

Uyên Trần: Với những chia sẻ từ hai bạn, hy vọng các bạn đọc sẽ phần nào hiểu được chặng đường của một Test Automation Engineer. Chắc hẳn con đường phía trước sẽ còn nhiều thử thách, chúc các bạn sẽ tiếp tục vượt qua những khó khăn ấy và đạt được những thành công nhất định trong sự nghiệp làm tester của mình nhé!

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

Functional programing nên và không nên

Bài viết được sự cho phép của tác giả Lưu Bình An

Luôn trả về giá trị

Luôn trả về giá trị, kể cả nhưng hàm chỉ tạo side-effect, ngoài ra giá trị trả về còn nên cố định luôn một kiểu, không nên lúc kiểu này lúc kiểu khác, giữ giá trị thô, đừng lưu giá trị đã định dạng (như format tiền tệ, ngày tháng), dùng tham số, đừng hard-code

❌ Không ngon

let result = 1;
for (let i = 2; i <= 5; i++) {
  result *= i;
}

console.log("Fact of 5: ", result);

✅ Chuẩn cơm mẹ nấu

const fact = (n) => (n === 0 ? 1 : n * fact(n - 1));

console.log("Fact of 5: ", fact(5));

Module hóa

Tách bạch một module chỉ làm một việc, và làm thật tốt việc đó

Xem thêm tuyển dụng javascript lương cao

Hợp thể ko kế thừa (composition vs. inheritance)

Kế thừa KHÔNG phải là cách chúng ta xử lý dữ liệu, behavior trong functional programing

Ghi nhớ khi cần thiết

Với pure function, việc ghi nhớ (memoize) kết quả được xem là an toàn vì cùng input-cùng output.

Ví dụ dùng hàm memize của thư viện Ramda

const fact = memoize((n) => (0 === n ? 1 : n * fact(n - 1)));

fact(5); // Calculates fact for 5, 4, 3 ...
fact(5); // Instantaneous
fact(3); // Instantaneous

Không thay đổi giá trị gốc

❌ Không ngon

var approved = [];

for (var i = 0; i < approved.length; i++) {
  if (users[i].score >= 7) {
    approved.push(approved);
  }
}

✅ Chuẩn cơm mẹ nấu

const approved = filter((user) => user.score >= 7, users);

Không dùng vòng lặp `for`

Mặc dù vòng lặp for nhanh nhất trong các vòng lặp, tuy nhiên nghiêm cấm sử dụng để tránh gây ra một side-effect không cố ý.

❌ Không ngon

const even = [];
for (let i = 0; i <= 300; i++) {
  if (i % 2 === 0) {
    even.push(i);
  }
}

console.log(even); // [0, 2, 4, 6, 8 ...]

✅ Chuẩn cơm mẹ nấu

import { filter, range } from "ramda";

const even = filter((n) => n % 2 === 0);

console.log(even(range(0, 300))); // [0, 2, 4, 6, 8 ...]

Không dùng `switch...case`

❌ Không ngon

const person = { name: "Wesley" };
let result;

switch (person.name) {
  case "Dayana":
    result = person.name + " is cool!";
    break;
  case "Wesley":
    result = person.name + " likes farting";
    break;
  default:
    result = "Who is " + person.name + "?";
}

console.log(result); // Wesley likes farting

✅ Chuẩn cơm mẹ nấu

import { T, cond, propEq } from "ramda";

const getDescription = cond([
  [propEq("name", "Dayana"), ({ name }) => `${name} is cool!`],
  [propEq("name", "Wesley"), ({ name }) => `${name} likes farting`],
  [T, ({ name }) => `Who is ${name}?`]
]);

console.log(getDescription({ name: "Wesley" })); // Wesley likes farting

Try…catch

❌ Không ngon

try {
  undefined.property;
} catch (err) {
  console.log(err);
}

✅ Chuẩn cơm mẹ nấu

import { tryCatch } from "ramda";
import { Either } from "ramda-fantasy";

const computation = tryCatch(
  () => undefined.property,
  Either.Right,
  Either.Left
);

console.log(computation()); // Left<TypeError>

Undefined và null

Không có giá trị (undefined, null) dẫn đến chuyện phải verify khá nhiều thứ và điều kiện nối điều kiện. Sử dụng Maybe

❌ Không ngon

const safeDiv = (a, b) => {
  if (b === 0) {
    return undefined;
  }

  return a / b;
};

console.log(safeDiv(20, 0) + 10); // Ops

✅ Chuẩn cơm mẹ nấu

import { Maybe } from "ramda-fantasy";

const safeDiv = (a, b) => (0 === b ? Maybe.Nothing : Maybe.Just(a / b));

safeDiv(20, 0).chain((result) => {
  console.log(result + 10); // Never falls here
});

Class

Nói chung, sử dụng class chúng ép buộc phải tạo ra effect và thao tác trực tiếp đến đối tượng gốc.

❌ Không ngon

class Person {
  setName(name) {
    this.name = name;
  }
  getName() {
    return this.name;
  }
}

let person = new Person();
person.setName("Cassandra");

✅ Chuẩn cơm mẹ nấu

import { lensProp, prop, set } from "ramda";

const setName = set(lensProp("name"));
const getName = prop("name");

const person = setName("Cassandra", {});

Đặt tên function

Có một động từ mô tả cái nó sẽ làm
Mô tả được bên trong nó làm cái gì (tất nhiên là ngắn gọn nhất có thể)
Nếu có cùng concept, sử dụng một từ chung
Chỉ làm một việc duy nhất
Không mô tả nó làm như thế nào
Nếu gặp khó khăn trong việc đặt tên function, có thể bạn đã không đúng khi gom quá nhiều xử lý vào nó (ôm đồm xử lý)

Bài viết gốc tại Vuilaptrinh

Xem thêm các việc làm ngành it công ty lớn tại đây

Mental model trong React

Nếu lập trình đủ lâu, bạn sẽ ít nhiều nghe đến khái niệm mental model, và nếu bạn đã và đang viết React, bạn càng thấy thuật ngữ này xuất hiện rất nhiều. Đây là một khái niệm không chỉ trong hữu dụng trong React, mà nó còn là chìa khóa để bạn tự tin khi làm việc với những thư viện như React.

Mental model là gì

Một chữ rất khó tìm được một từ tiếng việt gói gọn để mô tả nó. Một cách dài dòng thì nó là cách mà chúng ta hình dung một vấn đề trong đầu, một bước mapping một hệ thống ở bên ngoài vào trong đầu trong ta, hình dung nó cách vận hành.

Một ví dụ điển hình của mental model là internet: một hệ thống phức tạp gồm nhiều phần kết nối lại với nhau, nhưng hãy nghĩ đến cái mà bạn hình dung về nó. Tôi sẽ nghĩ nó là một hệ thống các máy tính kết nối lẫn nhau thông qua rất nhiều server, một vài điều hướng viên giúp định hướng đường đi của thông tin.

Nó không phải là một hệ thống mô tả đầy đủ chi tiết về internet, nhưng ít nhất với cái hình dung này, tôi có thể xử lý nhiều thứ liên quan, thí dụ như nếu tôi cần mạng thì tôi cần có máy tính thiết bị đầu cuối và nối vào một đường truyền của nhà mạng.

Tìm việc it react hấp dẫn cho bạn

Tại sao quan trọng?

Nếu chúng ta hình dung được mọi thứ sẽ vận hành ra làm sao, nếu gặp một vấn đề, chúng ta có thể làm việc với nó trơn tru hơn.

Hình dung cách React vận hành như thế nào

React giúp chúng ta xây dựng nhưng hệ thống UI phức tạp, với tùm lum thứ tương tác qua lại với nhau dễ dàng hơn trước đây rất nhiều. Nó cũng định hướng chúng ta viết code theo một cách rất cụ thể, giống như nó thể thơ “lục bát”, khi bạn viết thì phải tuân thủ những nguyên tắc nhất định.

Ý tưởng chính của React: đóng gói những logic và UI giống nhau của ứng dụng thành một khối, React đảm bảo phần đóng gói này luôn cập nhập.

Tất cả đều là function

React component: là một function
Một component chứa một component khác: một function gọi đến một function khác
Prop: tham số của một function

Khi viết bằng JSX, bạn có thể tưởng nhầm component, prop là gì đó cao siêu. Nếu bỏ hết những gì của JSX đi, React là những function gọi qua gọi lại.

Component: một function trả về JSX

React sử dụng JSX – Javascript XML – một cách viết nhét HTML vào trong javascript.

Hãy bỏ qua class component và chỉ tập trung vào functional component đang trở nên phổ biến hơn. Một function component sẽ hoạt động y như một javascript function thông thường. React component luôn trả về JSX -> sau đó sẽ được thực thi và trả về kết quả cuối cùng là HTML

const Li = (props) => <li {...props}>{props.children}</li>;

export const RickRoll = () => (
  <div>
    <div className="wrapper">
      <ul>
        <Li color={"red"}>Never give you up</Li>
      </ul>
    </div>
  </div>
);

Sẽ được đưa về Javascript như sau

const Li = (props) => React.createElement("li", props, props.children);

export const RickRoll = () =>
  React.createElement(
    "div",
    null,
    React.createElement(
      "div",
      {
        className: "wrapper"
      },
      React.createElement(
        "ul",
        null,
        React.createElement(
          Li,
          {
            color: "red"
          },
          "Never give you up"
        )
      )
    )
  );

Trong React, cũng như trong HTML và đời sống, con thì chỉ có một mẹ, không đứa con nào của thể do 2 người mẹ sinh ra, mỗi component cũng chỉ có một mẹ, component mẹ thì có thể có nhiều con.

Prop: tham số của function

Prop (properties) chẳng qua là một cách gọi khác cho tham số truyền vào trong function, còn về mọi thứ còn lại nó hoàn toàn giống nhau, React có nhét thêm một số tham số của riêng nó như children.

Hình dung về một function

Bạn có thể hình dung function/component như những chiếc hộp, thằng này bọc thằng kia

Những chiếc hộp này tương tác với nhau như thế nào?

Bạn có thể hình dung trong đời sống thực ông bà có câu nói tài sản của cha/mẹ là của con, tài sản của con là của con, Javascript người ta đặt tên cho kiểu kế thừa đó gọi là closure.

Đây là cách mà các function cha-con tương tác với nhau, bạn sử dụng function, bạn đã sử dụng closure.

Nghĩa là trong React, là cha mẹ chúng ta có thể truyền prop xuống cho con, nhưng tài sản của con thì chúng ta không đụng vào được

const Parent = () => {
  const [count, setCount] = useState(0);

  return (
    <div>
      The count is {count}
      <div>
        <ChildButtons onClick={setCount} count={count} />
      </div>
    </div>
  );
};

const ChildButtons = (props) => (
  <div>
    <button onClick={() => props.onClick(props.count + 1)}>
      Increase count
    </button>
    <button onClick={() => props.onClick(props.count - 1)}>
      Decrease count
    </button>
  </div>
);

Hình dung cách React render

Render có thể xem là phần gây khó dễ nhất của React để mà hình dung. Có những thứ nhìn vào code chúng ta sẽ không thấy được cơ chế khi render chuyện gì xảy ra và không xảy ra.

Tưởng tượng nó như một cái hộp có thể tái chế, lần render đầu tiền là lúc sản xuất ra chiếc hộp này, các lần re-render tiếp theo, hay tái chế, phần lớn mọi thứ sẽ được đập đi làm lại, nhưng những phần như state sẽ được tái sử dụng

const Thumbnail = (props) => (
  <div>
    {props.withIcon && <AmazingIcon />}
    <img src={props.imgUrl} alt={props.alt} />
  </div>
);

Việc của React phải làm với state là đảm bảo nó consistent giữa các lần render.

Khi một chiếc hộp được tái chế, toàn bộ các hộp con bên trong cũng được tái chế – re-render bởi các state và prop lúc này đã thay đổi.

Hy vọng qua bài viết kiểu này các bạn đã có thể làm việc với React Component một cách nhẹ nhàng không cay cú.

TopDev via Vuilaptrinh

7 sự thật mình bỏ lỡ khi còn là lập trình viên junior

Đã 10 năm kể từ khi mình chính thức trở thành 1 lập trình viên. Rất khó để nhớ về khoảng thời gian mà mình còn chưa biết HTML là gì. Đa số tụi nhỏ thường chọn múa ballet hay chơi loại nhạc cụ nào đó, riêng mình lại chọn đắm chìm trong những dòng code.

Nhớ lại lúc mình mới bắt đầu được nhận thù lao thường xuyên chỉ để gõ những ‘ký hiệu lạ lẫm’ vào Terminal, mình cũng muốn chia sẻ 1 chút về những thay đổi về cách suy nghĩ của bản thân trong nhiều năm qua với vai trò là 1 lập trình viên.

Với các bạn junior: Có thể bạn sẽ tìm thấy thứ gì đó để rút kinh nghiệm, cũng có thể tìm thấy cảm hứng để tiếp tục con đường developer. Hoặc có thể bạn sẽ thấy bài đăng này rất đáng khích lệ vì bạn đã vượt xa level của mình rồi.

Với các senior: Có thể bạn sẽ thấy điểm tương đồng, hay bắt gặp vài tình huống dở khóc dở cười mà chính bạn cũng từng gặp khi còn là junior.

Sau đây là 9 điều mình đúc kết được từ khi còn là junior.

Mình là 1 lập trình viên senior

Mình ứng tuyển cho công việc đầu tiên lúc mới 19 tuổi. Vị trí mình ứng tuyển là ‘Quản trị web sinh viên – Student Webmaster’. Vốn là 1 công việc khá xịn sò, bởi vì bạn sẽ vừa là sinh viên và còn là quản trị viên cùng 1 lúc. Giờ thì mọi người đều muốn được gọi là ‘kỹ sư’ vì nghe có vẻ hào nhoáng hơn, nhưng nếu bạn hỏi mình thì từ ‘quản trị viên’ sẽ chính xác hơn. Anyway, công việc của mình là viết PHP và MySQL, duy trì website Drupal cũng như dựng các bộ tool nội bộ.

Vì đã code tại nhà được vài năm, mình khá chắc khoảng thời gian đó cũng được xem như là ‘số năm kinh nghiệm’. Nên khi được hỏi về số năm kinh nghiệm về PHP, mình tự tin trả lời rằng: “3 – 4 năm!”

Mình cũng nghĩ là bản thân biết khá nhiều về SQL bởi vì mình có thể làm được outer joins. Và theo Google, 3-4 năm kinh nghiệm có nghĩa là mình nên đi kiếm tiền được rồi.

Nói qua về công việc hiện tại, mình được tuyển sau 5 năm học hỏi ở trường cũng như qua kinh nghiệm chuyên ngành (vốn mình từng nghĩ kinh nghiệm nào cũng giống nhau như cả thôi). Và ở thời điểm đó, mình cơ bản không bao giờ review code. Mình deploy ssh-ing vào 1 server và chạy ‘git pull’. Mình còn chưa phải open 1 Pull Request. Mình đã học được nhiều thứ tuyệt vời với 2 công việc đầu tiên, nhưng chưa bao giờ có cơ hội để làm cùng với các dev khác trong cùng 1 codebase. Tuy vậy, mình đã thử ứng tuyển cho vị trí ‘senior frontend engineer’, và đã được nhận việc.

Và thế là, mình đã trở thành 1 lập trình viên senior ở độ tuổi 24.

Rõ ràng là nhà tuyển dụng sẽ không để mình đảm nhiệm “chức danh” này nếu mình không thực sự là 1 senior. Và thế là mình trở thành lập trình viên trẻ tuổi nhất tại văn phòng làm việc.

Liệu tôi có làm Junior Developer "mãn kiếp"?

Những điều mà mình đã học được

Không phải tất cả các kinh nghiệm đều giống như nhau. Kinh nghiệm coding từ nhỏ, làm việc thời sinh viên, làm về nghiên cứu CS, và làm việc tại 1 startup đang phát triển đều là những dạng kinh nghiệm đáng giá. Nhưng chúng không hề giống nhau. Giai đoạn đầu trong sự nghiệp, bạn có thể học được gấp 10 lần (ở 1 team hỗ trợ lẫn nhau trong 1 năm) hơn là chỉ viết code 1 mình (hay với feedback) trong 5 năm trời. Nếu code của bạn chưa từng được các lập trình viên khác review, thì bạn sẽ không học được nhanh hết sức có thể – đó là 1 yếu tố khá quan trọng.

Đó là lý do các cố vấn viên – mentor rất là quan trọng, và có 1 team làm việc cùng cũng đáng giá hơn nhiều so với việc kiếm được vài đồng trong ví. Đừng chấp nhận vị trí junior ở nơi mà bạn sẽ phải làm việc 1 mình! Và đừng chấp nhận vai trò đầu tiên của bạn (hay thực sự mà nói là cho bất cứ vai trò nào) chỉ dựa vào tiền nong. Làm việc cùng team mới chính là nơi có giá trị thực sự.

Mình cũng học được rằng chức danh nghề nghiệp cũng không chứng tỏ được gì cả. Giống như việc là CTO của 1 team 5 người sẽ khác biệt với 1 team có 50 người hay 1 team có 500 người. Công việc và kỹ năng yêu cầu cũng hoàn toàn khác biệt, dù tước danh thì giống hệt nhau. Cho nên dù mình có 1 công việc với chức danh ‘senior’ thực sự không làm mình hoàn toàn trở thành 1 kỹ sư senior. Hơn thế nữa, các chức danh phân cấp cũng thường dễ bị thiếu sót, và khó để so sánh giữa các công ty. Mình học được điều quan trọng là đừng nên quá quan trọng các chức danh, mà chỉ nên dùng chúng như 1 dạng công nhận bên ngoài xã hội.

Việc làm junior IT lương cao trên TopDev

Mọi người đều tự test

Trong nửa đầu sự nghiệp, mình làm về nghiên cứu. Nói rõ hơn là mình làm ở 1 dự án gây quỹ cộng đồng trong khoảng 3 năm rưỡi, và sau đó là tại 1 trường đại học ở NLP được 1 năm rưỡi. Phải nói rằng việc lập trình cho nghiên cứu khác hoàn toàn với việc lập trình trong ngành công nghiệp (thương mại).

Phần lớn công việc mình sẽ không phải phát triển ứng dụng, mà sẽ làm việc với các thuật toán hay phân tích bộ dữ liệu. Còn nếu đang dựng ứng dụng thì khả năng cao là được gây quỹ từ cộng đồng – đồng nghĩa với việc app hoàn toàn free và dự án là open-source. Và khi 1 thứ gì đó miễn phí, có nghĩa rằng bạn không phải chịu trách nhiệm để làm cho chúng hoàn hảo nhất.

Vì nó miễn phí mà. Bạn cũng không chịu trách nhiệm kiếm tiền từ app đó hay tạo ra sản phẩm, nhưng đó là 1 câu chuyện hoàn toàn khác khi làm lập trình viên trong học viện.

Sau đó mình rời khỏi học viện với khá nhiều kỳ vọng.

Kỳ vọng về công việc sẽ được triển khai như thế nào. Sẽ có automation, Pull request và code review .Nghe rất gì và này nọ. Ngoài ra còn là những dòng code đỉnh nhất, thêm nữa mình còn tin rằng mọi người trong ngành công nghiệp lập trình đều phải test.

Trái với mong đợi, ngày đầu tiên đi làm của mình ở 1 startup và không hề có test tiếc gì. Chẳng có test cho frontend và cũng không có test cho backend.

Nada. Zip. Null. Undefined. NaN test.

Không những không có test, mà dường như không ai có vấn đề gì với việc thiếu vị trí tester! Với 1 chút ngây thơ, mình cho rằng lý do không test vì mọi người không biết viết test cho AngularJS. Nếu mình dạy cho họ cách làm, mọi thứ sẽ ổn và chúng ta sẽ bắt đầu có test. Sai lầm! Nhiều năm sau đó, công ty mình thậm chí cân nhắc việc thêm test tự động vào code, và nó cũng không đơn giản như mình nghĩ.

Nhưng không phải là vì mọi người không biết cách viết test. Họ cũng hầu như không bao giờ cảm nhận được nỗi khó chịu khi thiếu bước test ấy.

Những gì cuối cùng mình học được

Có khá nhiều công ty và startup có rất ít hoặc không hề có test. Khi chật vật để tìm thị trường sản phẩm phù hợp, hay chiến đấu để tồn tại, rất nhiều công ty bỏ qua việc test sớm. Ngay cả các công ty nhìn rất hào nhoáng, tài trợ cho các hội nghị hay code open-source – nên thành ra là nhiều nơi vẫn còn lượng Monolith lớn.

Thật sự không có công ty nào có tech setup hoàn hảo. Mỗi công ty đều có nhiều vấn đề riêng, mỗi công ty đều có technical debt của họ. Câu hỏi là họ đang làm gì với nó. Chúng ta không nên ảo tưởng khi ứng tuyển rằng luôn có việc gì đó cần phải hoàn thành – nếu không họ sẽ không thuê mình.

Quá ngoan cố về các chủ đề mà bạn thiếu kinh nghiệm ngoài đời thực là khá kiêu ngạo. Mình tình cờ trở thành 1 người ‘biết tuốt’, khăng khăng phải có test nhưng hầu như không có bất kỳ kinh nghiệm nào về những gì có quy mô thực sự giống như vậy. Đừng như mình. Dù có nguyên tắc là tốt , nhưng bạn cũng phải cởi mở tiếp thu những kinh nghiệm và quan điểm của người khác.

Trở thành Junior Dev ở tuổi 30

Chúng ta đã bị bỏ lại khá xa so với những người khác (aka tech fomo)

Đây khá liên quan tới chủ đề về unit testing. Trong khi công ty mình không có nhiều unit test, mình chắc là tất cả các công ty khác thì có.

Hướng dẫn viết unit test trong React

Mình đã đọc rất nhiều bài blog. Mình đã xem nhiều nhiều cuộc hội đàm trên Youtube. Mình xem ‘StackOverflow’ hầu như suốt cả ngày. Dường như là mọi người đã và đang viết các ứng dụng siêu tinh vi và chất lượng cao với hiệu suất tuyệt vời và animation hào nhoáng, trong mình vẫn ở đây chắp vá nhiều thứ lại với nhau chỉ để làm nó chạy kịp thời trước deadline.

Mình cơ bản thần tượng tất cả các công ty khác mà mình đọc được, và cảm thấy thất vọng về công ty của mình và dự án bị bỏ lại đằng sau.

Tuyển dụng junior IT TPHCM mới nhất

Những điều cuối cùng mình học được

Nhiều cuộc hội thảo thường bao gồm bằng chứng của các khái niệm hơn là kịch bản ngoài đời thực. Chỉ bởi vì bạn thấy 1 cuộc hội thảo nói về 1 công nghệ đặc thù, không có nghĩa rằng công ty đó đang sử cụng công nghệ như vậy trong công việc hàng ngày của họ, hay là tất cả code của họ đều hoàn hảo. Những người tham dự hội thảo thường là để giới thiệu các ứng dụng đồ chơi hơn là các trường hợp nghiên cứu thực tế, khá quan trọng để phân biệt 2 loại này.

Đối mặt với legacy code (code không có test) là hoàn toàn bình thường. Nhưng sau khi dành nhiều thời gian cho các cuộc hội thảo và nói chuyện với những người làm việc ở những công ty công nghệ hàng đầu, mình cảm thấy nó trở nên rõ ràng hơn là chúng ta đều ở trên cùng 1 con thuyền. Công ty nào mà KHÔNG CÓ lượng monolith PHP hay Ruby khổng lồ mà họ đang cố thuần hóa chứ ? (hay buộc phải thuần hóa ở 1 vài thời điểm). Legacy code là chuyện bình thường, và học cách để đối phó với nó thường sẽ dạy cho bạn nhiều thứ hơn là chỉ dựng các ứng dụng từ scratch, vì bạn sẽ được tiếp xúc với các khái niệm mà bạn chưa hiểu.

Chất lượng code là điều quan trọng nhất.

Từng có ngày, nhận 1 review code từ mình có thể là việc khá tàn nhẫn.

Mình khá kỹ tính trong việc code. Cách mình code khá tương đồng với style guide Airbnb JavaScript. Những thứ như indentation (thụt đầu dòng), format (định dạng), đặt tên, … Nếu ai đó “vượt qua” review code mà không nhận ít nhất 1 comment từ mình thì đó thật sự là “tâm linh tương thông” giao thoa với việc ‘trúng xổ số“, thật sự.

Thử tưởng tượng việc có hơn 50 comment trong PR của bạn với biết bao dấu ‘;’ bị thiếu sót… mình khá tinh mắt nên là mình muốn có những dấu ‘;’ chất lượng đó.

(May thay, mình đã không còn tinh mắt nữa sau khi nhìn chằm chằm vào máy vi tính từ năm này sang năm khác, nên là tha cho các bạn đấy! – Đùa tí thôi.)

Điều cuối cùng mình học được

Đủ tốt là đủ rồi. Khi quá chăm chút cho việc code cần “tốt” như thế nào sẽ gây ra việc suy giảm hiệu suất. Không cần phải sạch hoàn hảo để có thể hoàn thành công việc và cũng không hẳn là 1 thảm họa để duy trì. Đôi khi, code 1 cách lặp đi lặp lại nhiều hơn 1 chút hay dài dòng hơn 1 chút sẽ làm người khác dễ hiểu hơn. Và khái niệm ‘code tốt’ cũng không giống như ‘code nhìn giống như mình viết’.

Kiến trúc code quan trọng hơn sự chi li. Đoạn code có thể từ từ cải thiện, nhưng các vấn đề lớn thường xuất hiện về phần cấu trúc. Đáng lẽ mình nên tập trung nhiều hơn về cấu trúc của ứng dụng hơn là chăm chút từng li từng tí khi mới bắt tay vào code.

Chất lượng code khá quan trọng, và mình không nói ngoa đâu. Nhưng thực sự là chất lượng code không giống như những gì mình từng nghĩ, vốn mĩnh cho là những thứ như linting hay formatting hay bất cứ style gì được quảng bá trên các bài viết trên blog gần đây mà mình đã đọc.

Mọi thứ phải được tư liệu hóa – document.

Ở công ty đầu tiên, cũng là lần đầu tiên mình làm việc với nhiều code của người khác viết như vậy. Trước đó mình chưa từng phải tiếp nhận 1 codebase có sẵn và hình dung xem cái khỉ gì đang diễn ra như vậy. Có lần mình đã viết lại tất cả code thay vì cố gắng tìm ra cách hoạt động của nó.

Dù sao thì, nó cũng không giúp được gì vì đó là code AngularJS được viết bởi lập trình viên Ruby, hay vì mình chỉ là 1 lập trình viên junior vốn không biết mình là 1 junior.

Vậy cách mình lo liệu sự thật rằng 300 line code lạ lẫm làm cho mình như bị ngập ngụa trong nó?

JSDOC. Ở KHẮP MỌI NƠI.

Mình bắt đầu bình luận mọi thứ để làm mọi thứ hợp lý hơn.
Chú thích cho mỗi function mà mình có thể nắm được.

Mình đã học được tất cả các syntax JSDoc hào nhoáng của Angular đó. Code của mình lúc nào cũng dài gấp đôi bởi vì có khá nhiều document và comment.

Điều mình cuối cùng học được

Document cũng nhiều khi là xạo thôi. Khá dễ dàng để nghĩ rằng document là 1 giải pháp giải quyết tất cả. ‘Chúng tôi cần doc!’ Trong khi mình chưa đưa ra kết luận rằng chỉ vì doc là công việc khó nhằn, không có nghĩa là nó không đáng để làm 1 chút nào, mình học được rằng bạn phải “doc” lại đúng thứ theo đúng cách. Quá nhiều doc cho những thứ không cần thiết thường dẫn tới sự cứng nhắc, vốn có thể gây nhầm lẫn tới người đang cố fix 1 vấn đề nào đó.

Ưu tiên automation hơn “doc” nếu được. Các test hay automation thường đi chung với nhau. Cho nên thay vào đó, mình cố tập trung về việc viết test, để các lập trình viên làm việc với code của mình có thể nhìn được các function của project với code đang hoạt động.

Technical debt khá là tệ

Có khoảng thời gian, mình nghĩ rằng bất cứ code ‘lộn xộn’ đều là technical debt. Technical debt là 1 cụm từ khá hài hước bởi vì nếu bạn hỏi mọi người để cho bạn 1 thí dụ để chỉ ra nó là cái gì, thì sẽ có rất nhiều câu trả lời khác nhau.

Cho nên với tư cách là 1 người đã xem bất kỳ code ‘không đúng trật tự’ nào là technical debt, mình ngay lập tức cố để loại bỏ nó với cái rùng mình cùng cực.

Từng có 1 lần, mình thực sự dành nguyên cuối tuần để fix thủ công tận 800 linting error.

Mình biết mình đã quá rảnh rang (Dĩ nhiên đó là khi auto-fixing được ra đời)

Điều mình cuối cùng học được

Code không theo trật tự hay lộn xộn và technical debt hoàn toàn khác nhau. Chỉ bởi vì 1 thứ gì đó không ‘đẹp đẽ’ cho lắm không có nghĩa nó là technical debt. Technical debt thực sự sẽ làm bạn chậm lại theo nhiều cách, hay làm 1 số dạng thay đổi phức tạp hoặc dễ bị error. Nếu code chỉ hơi lộn xộn 1 chút, thì đơn giản là nó hơi thiếu trật tự chút thôi, và làm gọn nó có thể hơi tốn thời gian chút.

Có vài technical debt là chuyện bình thường. Đôi khi chúng ta đi đường tắt bởi vì chúng ta cần chút thời gian, và vì vậy chúng ta từ bỏ ‘tốc độ’ của mình trong tương lai. Có nhiều phần code thực sự dính ‘technical debt’ cũng ổn thôi, miễn là bạn nhận ra được bạn sẽ phải cần để trả phần nợ đó lại sau. Nếu bạn nghĩ codebase của mình không có technical debt nào, có nhiều cơ hội là bạn đang đánh bóng quá mức thay vì tự nhìn nhận lại. Và mình cũng từng bị như thế rồi!

Có thâm niên = giỏi lập trình

Vì đã bắt đầu code từ khi còn nhỏ, mình khá thành thạo trong việc thực hiện các vòng lặp (hơn 15 năm kinh nghiệm). Đối với mình lập trình cũng gần như việc mình thở vậy. Khi 1 giải pháp đã rõ ràng, mình có thể chỉ cần gõ theo và code sẽ đi theo sau. Cũng giống như viết bài blog hay email. Mình có thể code ra giải pháp nhanh hơn bất kỳ ai, và thường đảm nhận các dự án phức tạp hơn cho bản thân.

Trong 1 thời gian dài, mình nghĩ rằng đó là ý nghĩa của việc trở thành 1 lập trình viên senior.

Sao lại không chứ? Chức danh công việc của mình là ‘lập trình viên senior’, chứ không phải ‘người giao tiếp senior’ hay ‘quản lý dự án senior’. Nên mình nghĩ là mình không cần phải thêm nhiều kỹ năng khác cho việc lập trình để thành 1 lập trình viên senior thực sự.

Điều mình cuối cùng học được

Kỹ sư senior phải phát triển nhiều kỹ năng bên cạnh việc lập trình. Số lượng kỹ năng mà mình phải phát triển trong thời gian đó là vô số kể, so với những gì mình thực sự nắm được. Trải dài từ giao tiếp và quản lý phụ thuộc tới chia sẻ bối cảnh, quản lý dự án, ước tính và công tác thành công với các đồng nghiệp không phải là lập trình viên. Những kỹ năng này ít có thể xác định số lượng hơn và cần nhiều thử nghiệm và sai sót để hoàn thiện.

Không phải ai cũng trở thành ‘senior’ trong sự nghiệp của họ. Thâm niên trong nghề là kết quả của nhiều năm tích lũy kinh nghiệm. Và chưa hết, nhiều năm kinh nghiệm là chuyện cần thiết, nhưng chưa đủ điều kiện cho việc có thâm niên. Nó cũng phải là dạng kinh nghiệm phù hợp nơi bạn tiếp thu được những bài học phù hợp và áp dụng thành công những bài học đó trong tương lai. Đôi khi những bài học lớn hơn có thể mất cả năm hay nhiều hơn để tiếp nhận đầy đủ – đó là lý do tại sao nhiều năm kinh nghiệm vẫn khá quan trọng, ngay cả khi bạn là đã là 1 coder giỏi.

Chúng ta vẫn còn là 1 junior trong vài lĩnh vực khác. Không quan trọng là bạn có bao nhiêu năm kinh nghiệm, vẫn có nhiều lĩnh vực khác mà bạn không biết nhiều về nó.
Thừa nhận những gì bạn không biết là bước đầu tiên để lấp những khoảng trống đó và nhận sự giúp đỡ từ những người có nhiều kinh nghiệm.

Lời kết

Bài học số 1 mà bạn đã học được khi trở thành 1 lập trình viên junior là gì? Hay bài học hàng đầu mà bạn đang phải đối mặt, hãy chia sẻ nó với mình nữa nhé!

Topdev via Freecodecamp

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

“Thiếu hiểu biết về Công nghệ ở thế kỷ 21 coi như là mù chữ” – Nhân Nguyễn, CEO tại KALAPA

Từng gắn bó cùng Google hơn 5 năm với vị trí Software Engineer và thử sức tại các startup khác nhau về lĩnh vực Công nghệ, Nhân Nguyễn dừng chân tại Việt Nam và lập nghiệp với Kalapa với tư tưởng rất mới mẻ: cả công ty đều suy nghĩ sẽ hiệu quả hơn một người lãnh đạo – mô hình bottom up. Cùng trò chuyện với anh để hiểu hơn vì sao ở thế kỷ 21, nếu thiếu kiến thức về Toán, Tiếng Anh và Công nghệ thông tin thì bạn sẽ gần như là “mù chữ”.

Đôi nét về khách mời Nhân Nguyễn

Em được biết xuất thân của anh là một kỹ sư công nghệ, nhưng anh lại đầu tư khá nhiều vào các start-up, vậy lý do nào khiến anh làm như vậy?

Thật ra bất kỳ ai cũng có thể tìm hiểu và đầu tư chứ không gì những người làm kinh doanh. Background của mình là kỹ sư thì mình cũng có thể tích trữ và lên chiến lược đầu tư vào những gì có lợi nhuận, đơn giản là vậy.

Còn bây giờ mình sẽ giải thích lý do tại sao đầu tư start-up. Mình có đọc quyển sách đó là “Mass Flourishing” của Dr Phelps ở Đại học Columbia, ông có đến Google chia sẻ lý do những nước như Do Thái vì sao họ lại phát triển về công nghệ và kinh tế, bởi vì họ đầu tư vào start-up. Một quỹ của start-up của Silicon Valley là quỹ Sequoia từ Apple và Google thì nó tạo ra tổng giá trị trên thị trường là khoảng 20% của market cap của NASDAQ, nghĩa là tổng vốn hóa của NASDAQ là cỡ 20%, từ một quỹ của VC tức là họ tạo ra những công ty khủng. Đấy là lý do vì sao mình tập trung vào đầu tư start-up.

Liên quan đến start-up em có nghe nói, thành công thì mỗi người có công thức của riêng mình, nhưng thất bại thì lại có chung một công thức. Theo anh những case nào anh đã gặp phải trong quá trình đầu tư và bài học rút ra là gì?

Theo mình thì mỗi người cũng sẽ gặp thất bại “on their own ways” vậy, chứ cũng không có công thức chung đâu về thất bại đâu. Mình chọn founder khá kĩ vì founder là người đồng hành, thường mình không có vấn đề gì về tư cách đạo đức và khả năng, tư cách đạo đức của bạn ý là số một thì mình vẫn muốn chơi với bạn đó sau khi bạn fail, đa số những người mình đầu tư, công ty không thành công, cũng kha khá founder rồi đó, thì mình vẫn muốn chơi với founder đó, chứ không phải họ thất bại thì mình nghỉ chơi, dù sao họ cũng cố gắng hết sức.

Vấn đề ở con người đại đa số người Việt mình nghĩ là, người đấy thất bại nghĩa là người đấy không tốt, là hoàn toàn sai. Thì mình vẫn muốn chơi với người như vậy, những người chưa thành công, cái chưa thành công chưa phải là vấn đề quan trọng, bởi vì họ chưa thành công ở kèo này công ty này thì họ vẫn có thể thành lập công ty khác, khả năng của họ cao hơn hẳn. Đấy là cái thứ nhất.

Cái thứ hai, thường business model không hiệu quả. Ví dụ bỏ ra 2$ nhưng chỉ thu lại được 1$ thôi, thì mô hình này giống với WeWork, doanh thu khoảng 1 tỷ đô, nhưng chi phí cỡ 1,8 tỷ đô thôi, thường những cái model như thế khó mà khả năng thành công được, với WeWork bạn founder mà thành công thì bạn thành tỷ phú luôn rồi, chỉ có nhà đầu tư là chưa thôi.

Với vai trò là kỹ sư công nghệ chắc anh cũng từng làm việc với nhiều developer tại Việt Nam, vậy anh có nhận xét thế nào về developer Việt Nam và điều gì cần cải thiện thêm?

Developer Việt Nam rất là thực tế. Ngày xưa mình cứ nghĩ mô hình của Silicon Valley là đúng. Ví dụ như ở Google thì không có tester, người nào viết code thì người đó phải test, đó là nhiệm vụ của họ. Không phải một ông làm ra code dở rồi để ông khác dọn vệ sinh, thì đấy là không ổn, đó là tư duy của Google. Bên Microsoft thì không làm như vậy, Microsoft ở Seattle họ developer họ có tester riêng. Việt Nam mình thấy đi theo mô hình giống Microsoft hơn, bạn làm developer và bạn làm tester riêng. Ngày xưa khi mình làm ở Google thì mình thấy cái này không đúng, với cách tư duy riêng của mình thì mình thấy hiệu quả hơn hẳn vì ông thì đá bóng, ông thì thổi còi, ông đá bóng là ông developer, nhiệm vụ của ổng là tạo ra sản phẩm, mà sản phẩm của ông ý thì bug, ông ý mà tự chấm thì không công bằng chút nào, vì thế mà cần tester. Ở Kalapa, người đá bóng thì không được thổi còi, thế nên bây giờ mình bắt đầu tuyển tester rồi.

Hiện tại anh là một CEO của công ty công nghệ thì triết lý quản trị của anh như thế nào để giúp công ty tồn tại và phát triển ngày một mạnh hơn?

Mình cũng chẳng có triết lý gì đâu, cứ làm rồi sẽ thấy thôi. Mong muốn của mình là để các bạn trẻ được cọ xát với các bài toán, là cơ hội để các bạn lớn lên. Và mình hoàn toàn tin rằng lãnh đạo thường là những người không biết gì, thế nên toàn bộ công ty phải nghĩ, chứ mỗi lãnh đạo nghĩ thì không ổn. Mình nghĩ mình có tư tưởng này, có thể nguồn gốc xuất phát từ Google. Thực ra cả Google và Walmart họ đều có strong believe đó là bottom up, tức là nhân viên đều phải suy nghĩ cho cả công ty và có tính ownership, nghĩa là nếu mình là chủ của công ty thì mình sẽ action như thế nào, làm như thế nào. Chứ còn quản lý và quản trị nghĩa là từ top down, từ trên sẽ quản toàn bộ nhân viên ở dưới, như vậy thì không ổn lắm vì mình phải đi “soi” từng ông, rất là khó. Còn mô hình kia thì tất cả mọi người đều là chủ của công ty thì mình sẽ ứng xử như thế nào. Đấy là cách mình mong muốn công ty Kalapa hướng đến. Ví dụ như mình không thể hằng ngày đến xem nhân viên của mình có tắt điện hay chưa và đó cũng không phải là việc của mình, nhưng nếu mọi nghĩ mình là chủ của công ty này thì tất nhiên mình phải tắt điện thôi, những công ty còn rủ nhau tắt điện thì chưa phải là chủ đâu. Mình đôi lúc vẫn bị mắng là người cuối cùng làm việc ở công ty mà quên không tắt điện.

Trải nghiệm việc làm tại những doanh nghiệp lớn

Anh thường hay giới thiệu developer Việt Nam sang làm việc tại Google, như vậy thuật toán đang ngày một quan trọng và là cơ hội để làm việc tại các tập đoàn công nghệ lớn trên thế giới?

Ngày xưa năm 1945, Việt Nam có 90% không biết đọc, và trong thế kỷ 21, nếu như không biết lập trình, không biết tiếng Anh và không biết toán, 3 công cụ xuất hiện ở tất cả industry, tất cả các ngành. Banking cũng cần tiếng Anh, banking cũng cần toán, banking cũng cần công nghệ thông tin; bất động sản cũng cần tiếng Anh, bất động sản cũng cần toán, bất động sản cũng cần công nghệ thông tin. Nếu em không biết toán, không biết tiếng Anh, không biết công nghệ thông tin nghĩa là em mù chữ trong thế kỳ 21.

Tại sao anh quyết định rời Google chuyển sang làm việc tại Walmart mặc dù tại Google anh đạt được thành công nhất định, có phải anh thích điều gì đó trong ngành bán lẻ

Sau khi mình làm việc tại Google 5 năm rưỡi, đúng ra là mình thực tập tại Google và ra làm start-up được 1 năm thì Facebook mua lại, nhưng mà mình thấy ngưỡng mộ Google. Trong team của mình có 2 bạn, 1 bạn là HCV Toán quốc tế, 1 bạn là giải nhất Topcoder cho khối đại học và 1 bạn là giải nhất cho khối open, nghĩa là tất cả mọi người đều có thể thi được. Mình rất ngưỡng mộ những bạn đó, lúc mình làm ở Google mình chơi với những bạn như thế, cả team đấy gần chục người thì mình rất ngưỡng mộ. Và mình tự bảo vào Google là để mình học, sau 5 năm thì mình không học thêm được điều gì nữa, lúc đấy mình có một người bạn dạy cho mình default option, nghĩa là khi mình không làm thay đổi gì cả nhưng mình vẫn tiếp tục con đường đấy, lúc đó rất khó để mình quyết định có nên nghỉ việc hay không, bởi vì bình thường mình vẫn đi làm hằng ngày. Còn nếu theo một góc nhìn khác, giả sử mình đi xin việc lại, và mình biết Google như thế này và biết khả năng học của mình ở Google như thế này thì mình có xin vào đây không, và rất dễ mình sẽ trả lời là mình không xin vào Google nữa vì mình không học được gì thêm, cá nhân mình thấy khả năng học thêm là ít rồi nên mình rất dễ ra quyết định mình xin nghỉ.

Nhắc đến Google thì chắc có nhiều bạn đặt mục tiêu trong tương lai mong muốn làm việc tại Google. Với kinh nghiệm đã từng làm việc tại Google thì anh có thể chia sẻ lời khuyên hay một vài tips đến cho các bạn được không?

Mình rất mong muốn tạo cơ hội cho các bạn trẻ, nên mình có tạo một group Intern Candidate meet Referral, mình tạo group này trên facebook bởi vì ở Trung Quốc và Ấn Độ, họ có nhiều group để giới thiệu nhau vào công ty lớn, người đi trước support cho người đi sau thế nên cộng đồng của họ rất là mạnh, họ sẽ giúp đỡ lẫn nhau, Trung Quốc họ cũng giới thiệu lẫn nhau để vào Google hay Facebook. Ngày xưa khi mình học ở Canada, khi vào Google mình đã nhận offer của IBM rồi, thế nhưng bạn dạy đội tuyển trường UBC giới thiệu mình vào Google nên mình cancel việc thực tập tại IBM. Các bài toán ở IBM cho ngành tài chính cũng rất thú vị nhưng mình thấy Google xịn hơn nên mình nghỉ, mình sang làm cho Google. Theo chính sách của Google, những bạn giới thiệu người đã từng thực tập tại Google rồi thì không được tiền, bình thường khi một người giới thiệu một người vào làm fulltime thì sẽ được 4000$, nên mình bảo là mình không nhận việc tại Google nếu bạn nào không được 4000$, thế là 4000$ đấy chia cho 3 bạn. Ngày xưa mình chỉ giới thiệu vào làm thực tập thôi và mình không giới thiệu ai vào làm fulltime vì mình không cần 4000$ đó, giới thiệu thực tập thì không được tiền nhưng mất công phải trình bày lý do tại sao quen người này, người này có tố chất gì có tốt hay không để vào làm. Nhiều hôm mình điền form giới thiệu đến 2 – 3 giờ sáng. Và năm mình ở Google mình giới thiệu được 75 bạn, 15 bạn được vào Google, tỷ lệ 25%, tỷ lệ này là siêu cao so với mặt bằng chung, thời điểm 2008, 5000 hồ sơ nộp online hằng ngày, tỷ lệ được là 3/10000, 0.03, còn mình là 20%, gấp khoảng 600 lần.

Anh có thể chia sẻ thêm về 2 void complex project và contact switching scotley được không?

Mình được bạn giới thiệu vào Google, bạn đó là founder của Google Codejam, 1 kênh mà Google tuyển những người giỏi, giao cho nhiệm vụ là quản 30 bạn volunteer, các bạn tự tổ chức ra 1 cuộc thị thôi để xin kinh phí, tổ chức cuộc thi như sân chơi cho các bạn. Thì Google Codejam là về organ competition mà, và mình được quản 4 cuộc thi online thì mình sẽ chia việc cho từng bạn 1 và mình tạo ra cái Google worksheet để quản 20 bạn như thế, và các bạn làm việc fulltime, tuy mình là thực tập nhưng mình làm việc với cả Thomas Checka với Peter, nhũng người mà mình chỉ nhìn qua TV mà mình rất ngưỡng mộ hồi mình đi học nên mình rất hào hứng về cái việc tham gia cái đội ấy. Năm cuối cùng trước khi mình nghỉ Google thì các bạn lại mời mình tham gia để làm cùng với cả Google Codejam về phần tổ chức. Mình cũng có tham gia như khi làm việc fulltime rồi thì có rất nhiều pressure về KPI OKR nên là để làm được 2 project là 10 perfect time và Google Codejam và cái main project của mình thì rất là khó khi làm 2 cái cùng lúc.

Thế nên cái bài học của mình là 1 nghề cho chín còn hơn 90 nghề và có 1 vài bạn sinh viên gần đây hỏi mình là: “Nếu mà em ra trường, thì em có nên xin vào 1 công ty lớn như FPT rồi ở nhà em lại làm startup riêng của em” thì mình bảo là không nên làm như thế, mình đã suffer chuyện ấy rồi, cái việc chính của mình mà mình không tập trung 100% vào thì mình sẽ không đi đến đâu cả bởi vì người ta tập trung 120% mà người ta còn không đi đến đâu mà mình lại làm 2 việc cùng lúc thì khả năng fail của em là 100%, chứ không phải 99,999 mà là 100% luôn. Thế nên là các bạn trẻ thì nên đi ra làm công ty lớn để học cái process, cái nguyên tắc và sau đó có ý tưởng, có đam mê thì hãy đi ra làm khởi nghiệp. Nếu các bạn chân trong chân ngoài, vẫn đi làm nhà nước, vẫn đi làm FPT rồi em vẫn làm 1 cái startup của riêng em thì mình không khuyến khích việc đấy.

Theo em được biết anh là người đã giúp Google giải quyết các bài toán phân loại quảng cáo thì anh có thể nói rõ hơn các vấn đề của Google lúc đó và giải pháp của anh là gì không?

Team của mình thì làm chất lượng quảng cáo, nguyên tắc và nguyên lý của nó cũng rất đơn giản thôi, quảng cáo dở hơi, người dùng không thích không click vào thì không cho lên luôn, còn những quảng cáo người dùng người ta đến họ thích và click vào, có thể người ta mua hàng hay gì đấy thì nghĩa là nó chất lượng tốt nên nguyên lý nó chỉ là như vậy thôi. Cách làm thì mình sẽ dùng Machine Learning để tính và click xem vào đấy để xem cái quảng cáo này có tốt hay không.

Ở Google thường thì có hàng ngàn dự án, nhưng số dự án thành công chỉ có từ 2-3. Anh có thể chia sẻ một số dự án rất là tiềm năng để có thể triển khai nhưng đã thất bại hay không?

Dự án to nhất mà mình là leader ở Google thì nó ảnh hưởng khoản chừng 5% doanh thu, thời đấy nguồn doanh thu là 29 tỷ thì 5% là 1,5 tỷ, dự án ấy tên là Near Exact Match, thí dụ em đánh sai chính tả cái tên Hilary hay là Obama chẳng hạn thì Google nó sẽ correct, tức là nó sẽ đưa ra kết quả tìm kiếm của đúng tên bà Hillary hay Obama thôi, chữ Hillary có 1 chữ ‘l’ hay 2 chữ ‘l’. Bên search họ đã làm như thế rồi và bên quảng cáo thì chưa làm, bên quảng cáo khi em search từ gì thì em phải edit đúng từ đấy mới ra, nó gọi là misspelling. Trước lúc mà mình làm dự án này thì mình làm cái analysis và kiểu nó là báo cáo, nếu mình làm cái này thì mình sẽ kiếm thêm bao nhiêu tiền cho Google, và nó dưới hình thức gọi là 1% traffic của Google sẽ được chạy cái hệ thống mới và bọn mình không thu tiền và đưa quảng cáo của nhà quảng cáo lên nhưng không thu tiền advertiser, và 1% traffic mình tính rất là ok, khi mình đưa cái này lên thì cái impact nó là bao nhiêu %, tức là trước khi làm dự án thì mình phải tính là cái dự án này nó ra bao nhiêu tiền, thì ý tưởng thì bên search đã làm rồi bọn mình chỉ là copy thôi và trước khi làm doanh thu bọn mình tính cho Google là 1 tỷ USD, thế nên dự án đó được viết vào cái OKR của công ty năm ấy.

Việc triển khai A/B testing, chạy song song 50-50 cho hệ thống mới và cũ để đo lường hiệu quả về doanh thu cho một hệ thống khổng lồ như Google có gặp khó khăn gì không anh?

Nó rất là đơn giản thôi, tức là em có 10 cái em muốn thử, thí dụ như 1 cái em thay đổi giao diện chẳng hạn, 1 cái em thay đổi thuật toán, 1 cái em thay đổi là cái database nó sẽ ảnh hưởng độ nhanh chậm của hệ thống, 3 cái đấy là 3 cái layer khác nhau, 1 cái là UI, 1 cái là thuật toán, 1 cái là server – tức là nhanh chậm, độ ổn định của server. Thì 3 cái đấy là 3 cái layer khác nhau, rất là rõ, và người ta sẽ thử nghiệm với 1 người dùng bất kỳ thì có thể người ta dùng UI cũ hay UI mới, thì họ cứ tung cái đồng xu lên: mặt người là ông cũ, không phải mặt người là ông mới, với lại hệ thuật toán thì lại tung 1 đồng xu nữa, và các ông khách hàng, mỗi ông sẻ có cái trải nghiệm khác nhau với hệ thống UI cũ và UI mới, thuật toán cũ và thuật toán mới và server cũ và server mới, thì họ có hàng tỉ những experiment như thế và cứ mỗi 1 experiment, mỗi cái thay đổi ấy chia ra là cũ và mới, 50-50, tung đồng xu mà và nếu mà cái assumption rằng tôi không biết những cái khác, tôi chỉ biết là trong cái phần ảnh hưởng đến doanh thu của tôi thì nó như thế nào, nếu nó tốt tôi sẽ release, nếu không tốt thì tôi dẹp.

Khởi nghiệp tại Việt Nam và những bài toán

Vì sao anh quyết định rời Silicon Valley để về Việt Nam khởi nghiệp Kalapa và có phải anh đã nhận ra được cái vấn đề gì đó ở thị trường Việt Nam và giải pháp nào của Kalapa là anh tự tin nhất để giải quyết được những cái vấn đề này?

Thì có 2 nhóm các anh ở VN qua và 1 anh thì ở Sing qua, thì Silicon Valley nó mang 1 thông điệp là cơ hội không ở Mỹ mà nằm ở Đông Nam Á, anh Peng ở Singapore làm ở quỹ Beverly Hills Venture thì anh đó bảo Đông Nam Á sẽ cần khoảng 1000 tỷ đô cho vay bởi vì khu vực đang phát triển nên họ cần vốn và cơ hội rất là nhiều và những người mà đã thành công ở Trung Quốc thì thường là những người đi học ở nước ngoài về và 1 anh nữa là anh Lê Hồng Minh team VNG, thì sang và bảo có rất nhiều cơ hội ở Việt Nam, và ở Đông Nam Á, thì ở Mỹ rất khó khăn, mình về Việt Nam nhìn đâu cũng có cơ hội, và quyết định để mình về Kalapa thì ở Mỹ khi mình vay mua nhà, thì lãi suất chỉ từ 3-4% và vay mua nhà ở VN là 10% 1 năm, thì không hiểu làm sao mà các bạn có thể mua nhà được, vì 1 tỷ 1 năm trả 100 triệu, thì chia ra 1 tháng phải mất 8tr rồi, thì mình nghĩ là quá đắt và tại sao lại đắt như thế, thì khi mình thấy cơ hội lại cao thì mình lại để công nghệ giải quyết bài toán đấy.

Quá trình eKYC được diễn ra như thế nào? Giữa KYC truyền thống thông qua gặp trực tiếp và eKYC có những khó khăn hay thuận lợi nào? Đặc biệt ở bài toán Anti Fraud?

Trong luật của Ngân hàng theo mình hiểu, thì chưa được phép làm được phép làm eKYC và bắt buộc khi mà khách hàng vay 1 khoản vay thì phải ra gặp gỡ nhau để tránh việc là fraud là gian lận tài chính hay tín dụng, chắc do sợ là cho vay online thì sẽ rất nhiều gian lận, có thể là ăn trộm hoặc mua thẻ căn cước công dân của 1 ông này xong rồi lắp mặt của mình vào, xong rồi vay. Thì cái này là chiêu rất cơ bản của đội làm gian lận tín dụng, bởi vì là gian lận nhiều quá thôi, vay 1 triệu mà đến khoảng 50% không trả nợ thì lãi suất phải đẩy lên thôi, không có cách nào khác cả, và eKYC thì nó có tiềm năng gì? thì chi của 1 bạn đi gặp bạn vay thì đã mất khoảng tầm ít nhất là 100 nghìn, và có 1 đội chỉ chuyên đi thu hồ sơ, chụp ảnh cho vay các kiểu là mất khoảng 150K, 120K, đó là cách truyền thống KYC.

Còn eKYC thì họ làm hoàn toàn online, ảnh chứng minh đây, có matching với mặt hay không và những cách công nghệ mới là họ dùng video, tức là họ phải làm theo cái instruction và làm theo cái ‘quay trái – phải, trên – xuống’ thì cái video là không fake được nhé, và cái thứ 2 là matching chứng minh thư, thì công nghệ làm được hết rồi, đấy là eKYC thì họ sẽ giúp được 2 thứ là nhanh và giảm chi phí, giảm thời gian vay và có thể phục vụ được trên toàn cả nước, còn nếu mà bây giờ mà ngân hàng mà không có 1 cái chi nhánh nào ở huyện đấy là chịu, thì nó giải bài toán về financial inclusion, tức là ai cũng có thể có nhu cầu vay, tức là họ vay mua 1 con lợn chẳng hạn, mà họ không có tiền vay thì chịu, không sinh ra được doanh thu cho người nông dân.

Rất cảm ơn phần chia sẻ của anh Nhân về những kinh nghiệm tại các tập đoàn công nghệ, Hy vọng qua bài viết này các bạn đọc giả sẽ hiểu hơn về mô hình bottom-up, về quy trình tuyển dụng hay tích lũy cho mình các lời khuyên nếu muốn thử sức với start-up của riêng mình. Và TopDev cũng mong rằng với kinh nghiệm từ các công ty công nghệ và nền tảng vững chắc, anh Nhân sẽ đồng hành và phát triển Kalapa ngày một lớn mạnh.

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

Xem thêm các việc làm it lương cao tại TopDev

Biện hộ: Vì sao các Developer không test phần mềm của họ?

Từ xa xưa tôi đã ghét việc testing, nó không quan trọng với tôi, tôi không thấy lý do gì để làm việc này, kiểu như phí tiền và thời gian vậy.

Trong suốt sự nghiệp trước đây, tôi chưa bao giờ nói về cách nào, tại sao hoặc có nên test software của mình. Tôi đưa ra rất nhiều biện hộ cho việc không muốn học hỏi vụ này. Tôi nói với nhiều developer về điều này, những người cũng không ngừng biện hộ như tôi.

Trong suốt thời gian làm việc với những người khác trước đây, tôi đã trải qua rất nhiều quan điểm trái ngược khác nhau về software testing. Sau đây là vài lý do phổ biến nhất mà các developer đưa ra để không phải test software.

Code của tôi chạy hoàn hảo. Sao tôi phải test?

Tôi chưa bao giờ gặp một lập trình viên nào hoàn hảo cả, và cũng không nghĩ tồn tại một người như thế.

Lấy ví dụ ở các công ty công nghệ lớn trên thế giới như Facebook, Google, Rockstar, Sony…Họ thuê những developer thông minh nhất trên thế giới, nhưng các developer đó vẫn viết ra những mã không bảo mật.

Câu trả lời của tôi đối với những người cho rằng code của họ hoàn hảo: Sao bạn biết code của bạn là hoàn hảo? Bạn đã test nó chưa? Bạn có thể test nó liền và nói cho tôi biết là nó đã chạy hoàn hảo?

Tham khảo thêm các việc làm tester lương cao cho bạn tại đây

Nhưng mà, tôi không biết test cái gì bây giờ?!

Test tất cả mọi thứ! Ngoại trừ code của bên thứ ba vì họ đã tự test rồi!

Tôi xin trích dẫn một câu trả lời từ StackExchange bởi vì nó hợp lý.

1. Test mọi trường hợp phổ biến nhất có thể. Nó sẽ cho bạn thấy khi nào code của bạn lỗi khi thực hiện vài thay đổi(Quan điểm của tôi đây là lợi ích lớn nhất của automated unit testing )

2. Test những trường hợp nổi cộm có dính đến những đoạn code phức tạp mà bạn nghĩ rằng có thể xảy ra lỗi

3. Khi bạn tìm thấy một lỗi, hãy viết test case lại trước khi fix nó.(Để sau này dùng automation testing hoặc tester dùng)

4. Đưa những trường hợp nổi cộm này vào các code ít quan trọng hơn để khi nào đó có ai đó có thời gian xử lý nó

Thật khó để biết bắt đầu từ đâu khi bạn vẫn còn mới trong thế giới software testing. Có nhiều thể loại software testing. Tôi luôn đề xuất các beginner bắt đầu với Unit Testing, Integration Testing và Regression Testing.

Có rất nhiều phương pháp kiểm thử phần mềm. Một số developer sẽ không bao giờ cần phải làm việc này nếu họ đang làm việc trong một nhóm, nhưng ít nhất bạn cũng nên biết sự khác nhau giữa chúng:

Acceptance testing
Alpha testing
Beta testing
Black box testing
Comparison testing
Compatibility testing
End-to-end testing
Functional testing
Incremental integration testing
Install/uninstall testing
Integration testing
Load testing
Performance testing
Recovery testing
Regression testing
Sanity testing
Security testing
Stress testing
System testing
Unit testing
Usability testing
White box testing

Nếu bạn muốn biết thêm về tất cả các thể loại khác nhau của kiểm thử phần mềm, bạn nên đọc this article.

Điều quan trọng là kiểm thử là cần thiết chứ không phải là tùy chọn

Testing vừa khó khăn vừa khó hiểu

Mọi thứ đều sẽ khó khăn nếu bạn không biết cách thực hiện. Sẽ tốn thời gian, thực hành, kinh nghiệm và kiên nhẫn. Hãy thư giãn, thả lỏng và tìm niềm vui khi học. Hãy mong đợi một thất bại và nhầm lẫn lúc ban đầu, đừng mong thành công ngay. Bạn cũng chỉ là con người thôi!

Một khi bạn đã học và cảm thấy thoải mái với việc test, bạn sẽ thấy nó rất đơn giản

Lấy một cuốn sách, đọc nó, trao đổi với các developer khác trên IRC/Slack/Discord v.v…

Testing khiến kéo dài thời gian phát triển 🙁

Đây là lý do biện hộ rất sai làm và phổ biến

Bất kỳ ai mới vào nghề testing ban đầu sẽ cố gắng, rồi sau đó, cảm thấy không thoải mái. Bạn là con người, việc này rất bình thường.

Trong giai đoạn đầu sẽ rất tốn thời gian nhưng hãy tiếp tục gắn lấy nó, cuối cùng nó sẽ ăn vào máu của bạn thôi. Thủ thuật ở đây là hảy xem nó như là một phần của quy trình phát triển phần mềm, vì vậy sẽ trở thành thói quen.

Viết các test case sẽ tiết kiệm khá nhiều thời gian và tránh nhức đầu về sau. Lặp lại việc testing bằng cách click vào cái nút và xác nhận mọi thứ chạy đúng như mong đợi khiến bạn cảm thấy tự tin khi giao nó cho khách hàng.

Bạn sẽ có cảm giác mãn nguyện khi code vượt qua hết các giai đoạn test. Việc bảo trì các đoạn code có khả năng test được luôn luôn dễ, sướng hơn là làm việc với những hệ thống không lặp lại việc test.

Tìm hiểu thêm các vị trí tuyển dụng tester HOT nhất tại Topdev

Tuyển tập “cheatsheet” bộ câu hỏi cho anh em developer trước buổi phỏng vấn

Bạn đang lo lắng khi lần đầu phỏng vấn? Bạn cảm thấy thiếu tự tin về kinh nghiệm khi apply vào các công ty IT? Đừng hoang mang vì hôm nay, TopDev sẽ bật mí với các bạn những câu hỏi phỏng vấn từ các các nhà tuyển dụng IT. Bài viết là những chia sẻ thông qua các trải nghiệm tuyển dụng thực tế của đội ngũ TopDev, hy vọng sẽ có ích cho các bạn.

Thách thức bài test đầu vào – Liệu bạn đã sẵn sàng?

Nghe thì đã sợ, đó là cảm giác ám ảnh suốt một khoảng thời gian dài đúng không nào? Tuy nhiên, bạn đừng lo, bài test đầu vào của một công ty IT nhằm đánh giá tổng quát những kiến thức cơ bản của bạn về vị trí ứng tuyển. Vì thế, bạn nên thoải mái, giữ một tinh thần tốt để sẵn sàng hoàn thành bài thi bất cứ lúc nào nhé.

Cụ thể trong thách thức đầu tiên, bạn cần thể hiện mình có những am hiểu cơ bản về chuyên môn lập trình, tư duy logic và khả năng về ngoại ngữ. Trong đó, bài thi về chuyên môn lập trình bao gồm bộ câu hỏi trắc nghiệm nhằm giúp bạn hệ thống lại các kiến thức xoay quanh nền tảng lập trình (Java core), web (HTML, CSS, JS), database. Chung quy lại, việc kiểm tra năng lực của bạn sẽ đi từ việc khai thác kiến thức Front-end đến Back-end và Database.

Quan trọng nhất – Vòng phỏng vấn trực tiếp

Đây có thể nói là vòng quan trọng nhất bởi bạn sẽ được phỏng vấn trực tiếp bởi đội ngũ chuyên môn đến từ các Team Leader tại công ty. Thông thường, các bạn sẽ được hỏi các kiến thức từ cơ bản đến nâng cao. Sau đây, TopDev sẽ đưa ra danh sách các câu hỏi được phân loại tương ứng từng loại kiến thức chuyên môn. Đây là sườn những vấn đề và câu hỏi thường được nhà tuyển dụng hỏi để đánh giá năng lực và tiềm năng phát triển của ứng viên.

1. Câu hỏi cá nhân:

Giới thiệu bản thân: Bạn có thể nói sơ về số năm kinh nghiệm, sở thích về công nghệ, vị trí và dự định muốn làm (Dành cho khoảng này 2-3 phút thôi nhé)
Hãy nói về 1 project bạn đã làm? Bạn làm vai trò gì?: Người phỏng vấn sẽ hỏi khá sâu về cấu trúc project, những việc đã bạn làm, kể cả những khó khăn bạn gặp phải và kèm theo cách xử lý và vượt qua nó. Chính quá trình xử lý vấn đề họ sẽ đánh giá được nhiều điều từ bạn qua câu hỏi này.

2. Câu hỏi về chuyên môn:

Bộ câu hỏi tổng hợp được chia nhỏ theo nhiều skill, hãy chuẩn bị kỹ lưỡng trước càng sâu các skill trong chuyên môn và những gì bạn đã đề trong CV. Bạn sẽ được hỏi đầy đủ từ backend, đến frontend và cả một số các framework liên quan. Ngoài lý thuyết, bạn có thể còn được hỏi cách giải quyết 1 vấn đề cụ thể nào đấy, hãy chuẩn bị kỹ lưỡng nhé!

Bộ cheatsheet bạn có thể tham khảo:

Kiến thức Java nền tảng

- Thế nào là lập trình đối tượng? Cho biết các tính chất đặc thù của lập trình hướng đối tượng?
- Sự khác nhau giữa While và doWhile?
- Cách tổ chức hoạt động của các Collection Framework như List , Map, Set, Queue, Stack,..?
- Phân biệt ArrayList , Linkedlist và Vector?
- Sự khác nhau giữa ArrayList – Array, Linkedlist – Arraylist, Set – List, Override – Overload?
- Khái niệm về Generic? Cho ví dụ và lý do sử dụng?
- Sự khác nhau giữa Abstract class và Interface?
- Khái niệm tham trị và tham chiếu?
- Ngoại lệ (Exception là gì)? Phân biệt Check và Uncheck exception?
- Thuật toán tìm kiếm nhị phân và thuật toán sắp xếp?

Tham khảo ngay: Top các việc làm Java lương cao tại Topdev

Một số câu hỏi về Git cần biết

- Git fork là gì? Sự khác nhau giữa git fork, branch và clone?
- Sự khác nhau giữa pull request và branch?
- Làm thế nào để revert previous commit trong git?
- Giải thích những ưu điểm of Forking Workflow?
- Sự khác nhau giữa HEAD, working tree và index?
- Trình bày quy trình làm việc của Gitflow Workflow?
- Khi nào nên sử dụng git stash?
- Làm thế nào để loại bỏ một tập tin từ git mà không cần loại bỏ nó khỏi file system của bạn?
- Khi nào nên sử dụng git rebase thay vì git merge?

Những câu hỏi phỏng vấn về GIT cần nhớ ngay

Kiến thức về Framework (ví dụ như học Spring Framework của Java)

- Mô hình MVC là gì? Mô tả luồng đi của một ứng dụng MVC?
- Các khái niệm về Dependency Injection, JPA, ORM mapping, Webservice?
- Giải thích các annotation @Controller , @Service , @Repository , @Autowire?
- Chức năng hoạt động của Maven?
- Sự khác nhau của Session và Cookie?
- Làm thế nào để bảo mật trong lập trình?

Kiến thức về Database

- Khái niệm Database? Các quan hệ trong database? Các loại Join trong database?
- Các khái niệm về Composite key, Transaction, Unique?
- Khoá chính – khóa ngoại là gì?
- Giải thích các Rule chuẩn hóa dữ liệu?
- Sự khác nhau Truncate, Delete , Drop?
- Sự khác nhau Having và Where?

Tham khảo các vị trí tuyển dụng Database hấp dẫn nhất trong tháng

Một số câu hỏi “mẹo” về Front-end

- HTML, CSS, Bootstrap dùng để làm gì ?
- Phân biệt Class và Id? Phân biệt
- Phân biệt các thuộc tính Position: Absolute, Fixed, Relative, Fixed, Static
- Khai báo <!DOCTYPE> trong HTML có tác dụng gì?
- Phân biệt Class vs ID như thế nào trong CSS?
- Phân biệt toán tử “==” và “===” trong Javascript?
- “this” trong Javascript dùng để làm gì?
- Đánh lừa bằng cách đặt tên function trùng với một function có sẵn của thư viện

Tìm việc làm cho lập trình viên Front end hấp dẫn nhất 2022

3. Câu hỏi đánh giá về khả năng tiếp thu kiến thức

Câu hỏi này như một thách thức thêm để đánh giá mức độ cập nhật các xu hướng công nghệ mới của từng ứng viên.

Qua câu hỏi này, nhà tuyển dụng IT không đưa ra sự kết luận cuối nào cho kết quả tuyển dụng ứng viên, chỉ là xác lập thêm tiêu chí ứng viên đó có khả năng tự tìm hiểu về lĩnh vực mình theo đuổi hay không. Đó là điểm cộng lớn cho các ứng viên.

Lúc này sẽ có thêm một số câu hỏi cá nhân để không khí bớt căng thẳng: Bạn có sở thích gì? Bạn có điểm yếu điểm mạnh gì?,… Cứ trả lời thành thật! Bạn sẽ không chỉ được đánh giá qua kỹ năng technical, mà còn đánh giá qua thái độ làm việc, thái độ trả lời câu hỏi. Có nhiều câu hỏi bạn không biết, nhưng nếu cố gắng trả lời, thể hiện thái độ muốn học hỏi bạn vẫn sẽ được đánh giá cao nhé.

* Cuối buổi phỏng vấn: Bạn sẽ được hỏi rằng “Có câu hỏi gì không?” Đừng ngại mà hỏi các câu hỏi như: Môi trường làm việc ra sao, có yêu cầu OT hay không? Chính sách review tăng lương tăng thưởng thế nào? Công ty có tổ chức seminar hay chính sách gì để giúp nhân viên phát triển không?. Những câu hỏi này sẽ thể hiện bạn có tinh thần làm việc nghiêm túc, biết suy nghĩ đến tương lai.

Lời kết

Những câu hỏi trên là những câu hỏi thông dụng nhất được tập hợp lại và chia sẻ thông qua các trải nghiệm tuyển chọn cá nhân. TopDev mong rằng, các bạn sẽ trang bị cho mình năng lực chuyên môn, các kỹ năng cần thiết và quan trọng là một thái độ tốt. Hãy nhớ rằng, sau buổi phỏng vấn, nhớ gửi một email cảm ơn cho người đã phỏng vấn mình. Đây là một điều nho nhỏ, hiệu quả lại lơn lớn mà các bạn thường “quên” không làm.

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

Xem thêm IT Developer Job trên TopDev

Preload, prefetch và các thuộc tính khác trên link

Cùng tìm hiểu các attribute sử dụng trên thẻ link để cải thiện hiệu năng

<link rel="prefetch" href="/style.css" as="style" />
<link rel="preload" href="/style.css" as="style" />

<link rel="preconnect" href="https://example.com" />
<link rel="dns-prefetch" href="https://example.com" />

<link rel="prerender" href="https://example.com" />

preload

<link rel="preload" /> sẽ báo với trình duyệt download và cache một resource (như script hoặc stylesheet) nhanh nhất có thể. Nếu chúng ta cần resource đó ngay sau khi trang đang load.

Một khi trình duyệt đã download xong resource này, trình duyệt sẽ không làm gì hết, file script đó sẽ ko được thực thi, file stylesheet sẽ ko được áp dụng. Nó cache lại ở đó, khi có một thằng nào khác cần tới nó, nó sẽ được cung cấp ngay lập tức.

Cú pháp

<link rel="preload" href="/style.css" as="style" />

Các giá trị có thể cung cấp cho as

style
script
font
fetch

Chúng ta cần phải cung cấp giá trị as để trình duyệt biết thứ tự ưu tiên download về cho đúng.

Ví dụ, sử dụng custom font, nếu sử dụng font face chúng ta đặt việc load file này trong css

<link rel="stylesheet" href="index.css" />

/* index.css */
@font-face {
  src: url('comic-sans.woff2') format('woff2');
}

Theo mặc định file comic-sans.woff2 chỉ được download khi file index.css đã được load và áp dụng. Chúng ta có thể cưỡng ép load file font này về trước

<link rel="preload" href="comic-sans.woff2" as="font" />

prefetch

<link rel="prefetch" /> yêu cầu trình duyệt download và cache lại resource ngầm bên dưới, nó sẽ có độ ưu tiên thấp, không tranh giành thứ tự ưu tiên với các resource quan trọng hơn. Thí dụ như bạn cần resource đó ở các trang sau nữa, bạn có thể load trước để sẵn ở trang hiện tại.

Cú pháp

<link rel="prefetch" href="/style.css" as="style" />

Ví dụ, user di chuyển từ home page sang trang product page, đa phần luồng đi của user sẽ là như thế, trừ trường hợp học bookmark lại trang đó, hoặc nhấp vào một link được share. Chúng ta có thể sử dụng <link rel="prefetch" /> để tải trước các file css, js sẽ dùng trên trang product.

preconnect

<link rel="preconnect" /> được dùng để tăng tốc độ load ban đầu bằng việc báo với trình duyệt, chúng ta sẽ load một resource từ domain nào đó không sớm thì muộn. Thí dụ chúng ta load font từ Google, CDN, JSON từ API server.

Thực hư tăng tốc được bao nhiêu thì cũng chưa rõ, nhưng đây là cách chúng ta báo với trình duyệt

<link rel="preconnect" href="https://api.my-app.com" />

dns-prefetch

<link rel="dns-prefetch" /> công dụng cũng tương tự như preconnect, nó sẽ setup sẵn các config cần thiết trên trình duyệt khi cần thực hiện một DNS resolution

<link rel="dns-prefetch" href="https://api.my-app.com" />

prerender

<link rel="prerender" /> yêu cầu trình duyệt load 1 url và render nó trong một tab ẩn, khi user click vào đường link đến url đó, trang web sẽ được hiển thị ngay và luôn.

Tuy nhiên là thuộc tính này tính đến thời điểm hiện tại rất ít trình duyệt hỗ trợ

<link rel="prerender" href="https://my-app.com/pricing" />

TopDev via Vuilaptrinh

Javascript prototype chuyên sâu

Bài này chỉ phù hợp với các bạn đã có kiến thức trung bình khá javascript trở lên, mình không chỉ đơn giản giải thích cách xài mà còn sâu hơn, bạn sẽ nắm rất rất rõ prototype trong javascript thực chất là gì

Object trong javascript rất là vi diệu. Nó là nền tảng của rất nhiều thứ hay ho trong javascript.

Object là một cặp giá trị key/value. Cách đơn giản nhất tạo một object là obj = {}, thêm các property và phương thức sử dụng dấu chấm

let animal = {}
animal.name = 'Leo'
animal.energy = 10

animal.eat = function (amount) {
  console.log(`${this.name} is eating.`)
  this.energy += amount
}

animal.sleep = function (length) {
  console.log(`${this.name} is sleeping.`)
  this.energy += length
}

animal.play = function (length) {
  console.log(`${this.name} is playing.`)
  this.energy -= length
}

Quá đơn giản. Giờ chúng ta muốn có thêm một animal khác, chúng ta đưa toàn bộ logic này vào bên trong 1 function, cách này gọi là Functional Instantiation hay constructor function

function Animal (name, energy) {
  let animal = {}
  animal.name = name
  animal.energy = energy

  animal.eat = function (amount) {
    console.log(`${this.name} is eating.`)
    this.energy += amount
  }

  animal.sleep = function (length) {
    console.log(`${this.name} is sleeping.`)
    this.energy += length
  }

  animal.play = function (length) {
    console.log(`${this.name} is playing.`)
    this.energy -= length
  }

  return animal
}

const leo = Animal('Leo', 7)
const snoop = Animal('Snoop', 10)

Khi chúng ta muốn tạo một instance mới của Animal, tất cả những gì chúng ta cần làm là gọi lại hàm Animal.

Cách làm này có một điểm hạn chế, các phương thức eat, sleep, play là hoàn toàn giống nhau cho các instance, đồng thời khi tạo một instance mới chúng ta cũng đã vô tình lãng phí bộ nhớ bằng việc khai báo thêm những object mà đôi khi không cần thiết.

Tuyển dụng lập trình Javascript lương cao

Chúng ta sẽ tách các phương thức này ra. Từ ngữ chuyên môn cho vấn đề này là Functional Instantiation với các phương thức dùng chung.

const animalMethods = {
  eat(amount) {
    console.log(`${this.name} is eating.`)
    this.energy += amount
  },
  sleep(length) {
    console.log(`${this.name} is sleeping.`)
    this.energy += length
  },
  play(length) {
    console.log(`${this.name} is playing.`)
    this.energy -= length
  }
}

function Animal (name, energy) {
  let animal = {}
  animal.name = name
  animal.energy = energy
  animal.eat = animalMethods.eat
  animal.sleep = animalMethods.sleep
  animal.play = animalMethods.play

  return animal
}

Các phương thức dùng chung giờ đây nằm ở từng object và refer đến object bên trong của Animal.

Object.create

Nâng cấp thêm chút nữa bằng Object.create. Object.create cho phép bạn tạo một object, nếu không tìm thấy nó sẽ đưa về một object khác để xem có thể tìm thấy property đó không.

const parent = {
  name: 'Stacey',
  age: 35,
  heritage: 'Irish'
}

const child = Object.create(parent)
child.name = 'Ryan'
child.age = 7

console.log(child.name) // Ryan
console.log(child.age) // 7
console.log(child.heritage) // Irish

Trong ví dụ trên, bởi vì children được tạo bởi Object.create(parent), khi nó không tìm thấy property trong children, javascript tự nó biết tìm đến parent object. Trong ví dụ này, child không có property là heritage, mà parent có, nên nó sẽ lấy của parent là Irish

Giờ làm sao chúng ta đơn giản hoá code của Animal? Thay vì thêm tất cả các phương thức dùng chung vào Animal từng thằng một, có thể dùng Object.create để truyền object animalMethods

const animalMethods = {
  eat(amount) {
    console.log(`${this.name} is eating.`)
    this.energy += amount
  },
  sleep(length) {
    console.log(`${this.name} is sleeping.`)
    this.energy += length
  },
  play(length) {
    console.log(`${this.name} is playing.`)
    this.energy -= length
  }
}

function Animal (name, energy) {
  let animal = Object.create(animalMethods)
  animal.name = name
  animal.energy = energy

  return animal
}

const leo = Animal('Leo', 7)
const snoop = Animal('Snoop', 10)

leo.eat(10)
snoop.play(5)

Bây giờ khi gọi leo.eat, javascript sẽ tìm phương thức eat trên object leo. Nếu fail, nó đưa đến animalMethods trong đó có hàm eat

Làm như vậy có thể bị xem là hơi tricky khi quản lý một object độc lập cho các phương thức dùng chung.

Javascript chúng ta có prototype đảm nhiệm việc này mà bạn không cần viết thêm gì cả.

Tất cả function trong Javascript có một property là prototype, nó reference đến một object.

Holy grab? Không tin có thể test

function doThing () {}
console.log(doThing.prototype) // {}

Thay vì viết Object.create(animalMethods), chúng ta cứ dùng luôn object có sẵn là prototype

function Animal (name, energy) {
  let animal = Object.create(Animal.prototype)
  animal.name = name
  animal.energy = energy

  return animal
}

Animal.prototype.eat = function (amount) {
  console.log(`${this.name} is eating.`)
  this.energy += amount
}

Animal.prototype.sleep = function (length) {
  console.log(`${this.name} is sleeping.`)
  this.energy += length
}

Animal.prototype.play = function (length) {
  console.log(`${this.name} is playing.`)
  this.energy -= length
}

const leo = Animal('Leo', 7)
const snoop = Animal('Snoop', 10)

leo.eat(10)
snoop.play(5)

Hy vọng là bạn có giây phút ERECA khi đọc tới đây, như mình đã có. prototype chỉ là một property mà tất cả function trong javascript đều có.

Sâu hơn xa hơn

Tới thời điểm này, chúng ta đã biết

Tạo một function constructor
Thêm phương thức cho function constructor bằng prototype
Sử dụng Object.create để khi fail trỏ đến prototype

Cái này là quá căn bản với các ngôn ngữ lập trình khác, không lẽ javascript lại tệ đến vậy sao, không có một cách chính thống để làm? Có chứ, sử dụng new

Tại sao chúng ta phải đi cả ngàn dặm tới bước này, sao mình không nói toạc luôn ngay từ đầu? Với cách này bạn sẽ nắm rất sâu, hiểu rất rõ new sẽ làm gì bên dưới

Xem lại constructor Animal, 2 phần quan trọng nhất là tạo object và return nó.

function Animal (name, energy) {
  let animal = Object.create(Animal.prototype)
  animal.name = name
  animal.energy = energy

  return animal
}

new thì có gì hót – khi gọi một function sử dụng new, 2 dòng code này sẽ được chạy luôn cho mình và object được tạo ra gọi là this

Cách viết dùng new

function Animal (name, energy) {
  // const this = Object.create(Animal.prototype)

  this.name = name
  this.energy = energy

  // return this
}

Animal.prototype.eat = function (amount) {
  console.log(`${this.name} is eating.`)
  this.energy += amount
}

Animal.prototype.sleep = function (length) {
  console.log(`${this.name} is sleeping.`)
  this.energy += length
}

Animal.prototype.play = function (length) {
  console.log(`${this.name} is playing.`)
  this.energy -= length
}

const leo = new Animal('Leo', 7)
const snoop = new Animal('Snoop', 10)

Không dùng new, lỗi

function Animal (name, energy) {
  this.name = name
  this.energy = energy
}

const leo = Animal('Leo', 7)
console.log(leo) // undefined

WTF? Cả đống này chỉ là để làm cái class trong các ngôn ngữ khác thôi ư?

Đúng. Trước thời ES6, javascript không có vụ class này, chúng ta dùng như vậy đấy.

Vậy nếu bạn đang đọc bài này, thì bạn đã qua thời ES6, ES7, chúng ta có cách chính thống để làm. Bên dưới ES6 thì nó cũng làm i chang như vậy thôi, chẳng qua là bạn được viết bằng cách có “gu” hơn, chứ bên dưới nó vẫn implement như thế.

class Animal {
constructor(name, energy) {
this.name = name
this.energy = energy
}
eat(amount) {
console.log(`${this.name} is eating.`)
this.energy += amount
}
sleep(length) {
console.log(`${this.name} is sleeping.`)
this.energy += length
}
play(length) {
console.log(`${this.name} is playing.`)
this.energy -= length
}
} const leo = new Animal('Leo', 7) const snoop = new Animal('Snoop', 10)

Một số phương thức với prototype nên biết

Lấy tất cả prototype của function

Object.getPrototypeOf()

function Animal (name, energy) {
  this.name = name
  this.energy = energy
}

Animal.prototype.eat = function (amount) {
  console.log(`${this.name} is eating.`)
  this.energy += amount
}

Animal.prototype.sleep = function (length) {
  console.log(`${this.name} is sleeping.`)
  this.energy += length
}

Animal.prototype.play = function (length) {
  console.log(`${this.name} is playing.`)
  this.energy -= length
}

const leo = new Animal('Leo', 7)
const prototype = Object.getPrototypeOf(leo)

console.log(prototype)
// {constructor: ƒ, eat: ƒ, sleep: ƒ, play: ƒ}

prototype === Animal.prototype // true

Có 2 điểm quan trọng trong đoạn code trên

1 là chỗ constructor cũng được liệt kê ra như một hàm, như vậy bất kỳ instance nào cũng có thể gọi đến constructor bằng instance.constructor
2 là nếu so sánh Object.getPrototypeOf(leo) === Animal.prototype là đúng.

Xác định một property có tồn tại trong prototype không

.hasOwnProperty()

const leo = new Animal('Leo', 7)

for(let key in leo) {
  if (leo.hasOwnProperty(key)) {
    console.log(`Key: ${key}. Value: ${leo[key]}`)
  }
}

kiểm tra một object có phải là một instance của Class

object instanceof Class

function Animal (name, energy) {
  this.name = name
  this.energy = energy
}

function User () {}

const leo = new Animal('Leo', 7)

leo instanceof Animal // true
leo instanceof User // false

Lưu ý về arrow function

Do arrow function không có this bên trong nó, không thể dùng nó như một constructor function

const Animal = () => {}

const leo = new Animal() // Error: Animal is not a constructor

Đồng thời arrow function cũng sẽ không có prototype

const Animal = () => {}

console.log(Animal.prototype) // undefined

A Beginner’s Guide to JavaScript’s Prototype

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

Tham khảo thêm các vị trí tuyển IT đa ngành tại đây

Sync extensions của VSCode

Khi sử dụng VSCode chắc ai cũng cài thêm một mớ extensions, lỡ ngày nào cài lại máy, hay sử dụng máy công ty, máy tính ở nhà muốn VSCode sync mấy cái extention hay sử dụng

Cần có

Tài khoản Github, danh sách extension sẽ được lưu lên gist
Cài thêm extention tên là Settings Sync – tác giả Shan Khan.

Tạo access token trên Github

Đăng nhập vào tài khoản Github, vào trang Settings / Developer settings / Personal access tokens / Generate New Token

Nhập tên và cấp quyền tạo gist cho token này

Sau khi tạo xong, nhớ lưu lại token này ở đâu đó

Upload những thiết đặt, extensions đã cài cho VSCode

Dùng phím tắt Shift + Alt + U hoặc search từ command Palette, search từ sync

Nó sẽ yêu cầu nhập giá trị token vừa mới tạo

Sau khi upload thành công, nó sẽ trả về gist id, nhớ copy và lưu lại giá trị gist Id này để sử dụng trên máy khác.

Download các thiết từ gist về

Dùng phím tắt Shift + Alt + D, hoặc gọi từ command palette

Nó sẽ yêu cầu nhập lại token và gist id đã tạo, điền vào, xong!

TopDev via Vuilaptrinh

Redux vận hành như thế nào

Actions, reducers, action creators, middleware, pure functions, immutability,… những ngoại ngữ làm rối bất kỳ ai nếu chưa biết redux

Nếu chưa biết tại sao lại sinh ra thằng Redux này, có thể xem ở tuts trước của mình.

Chỉ sử dụng State của React

Component sẽ build

import React from 'react';

class Counter extends React.Component {
  state = { count: 0 }

  increment = () => {
    this.setState({
      count: this.state.count + 1
    });
  }

  decrement = () => {
    this.setState({
      count: this.state.count - 1
    });
  }

  render() {
    return (
      <div>
        <h2>Counter</h2>
        <div>
          <button onClick={this.decrement}>-</button>
          <span>{this.state.count}</span>
          <button onClick={this.increment}>+</button>
        </div>
      </div>
    )
  }
}

export default Counter;

Giải thích ngắn gọn cho dễ theo dõi

Giá trị count được lưu trong state của component Counter
Khi user click ‘+’, hàm increment sẽ tăng giá trị count lên
Khi state bị thay đổi, React sẽ render lại Counter và những component bên trong của nó, giá trị mới sẽ hiển thị

Thêm Redux

Như đã đề cập trong tuts trước, Redux lưu state lại trong 1 cái store, tranh lẫn lộn, store là nơi lưu state, và state dữ liệu.

Cài redux và react-redux package

npm install redux react-redux --save

Tại sao phải 2 cái package?, cái redux chỉ cho ta cái store, để lấy được cái state ra, sử dụng hàm connect trong react-redux, vì redux không phải chỉ làm việc chung được với React thôi không, nó có thể chơi với Vue, Angular không chừng.

Bỏ state đi

import React from 'react';

class Counter extends React.Component {
  increment = () => {
  }

  decrement = () => {
  }

  render() {
    return (
      <div>
        <h2>Counter</h2>
        <div>
          <button onClick={this.decrement}>-</button>
          <span>{this.props.count}</span>
          <button onClick={this.increment}>+</button>
        </div>
      </div>
    )
  }
}

export default Counter;

connect nó với store thôi

import { connect } from 'react-redux';
// ...
// Viết thêm hàm này
function mapStateToProps(state) {
  return {
    count: state.count
  };
}

// Thay cái
// export default Counter;

// bằng
export default connect(mapStateToProps)(Counter);

Ok vậy là xong phần connect component với các state ở trong store, chúng ta cần khai báo Store!

Bọc toàn bộ cái App bên trong component Provider của react-redux để tất cả component bên trong App có thể sử dụng hàm connect để gọi đến store

import { Provider } from 'react-redux';

...

const App = () => (
  <Provider>
    <Counter/>
  </Provider>
);

Chưa xong, chúng ta phải setup cái store để đưa vào cho Provider

import { createStore } from 'redux';

const store = createStore();

const App = () => (
  <Provider store={store}>
    <Counter/>
  </Provider>
);

Vẫn chưa đủ, thật sự Redux không được thông minh như chúng ta tưởng tượng, lúc đầu mình đã nghĩ rằng khi create store như vậy nó sẽ cho mình những giá trị default bên trong store. Nhưng không chúng ta phải làm tay tất cả. Chúng ta phải cung cấp cho nó 1 hàm gọi là reducer, cái hàm reducer này phải return về một giá trị cho state, luôn phải return state nhé. Bên trong reducer ta sẽ xào nấu state theo yêu cầu, nó sẽ nhận state hiện tại và trả về state mới.

const initialState = {
  count: 0
};

function reducer(state = initialState, action) {
  return state;
}

const store = createStore(reducer);

const App = () => (
  <Provider store={store}>
    <Counter/>
  </Provider>
);

Action

Action là gì, nó đóng vai trò như thế nào và nó đến từ đâu? Làm thế nào mà ta đổi giá trị counter?

action là 1 JS object nó sẽ cho biết bạn đang muốn order món nào, như tờ giấy ghi order trong nhà hàng ấy mà, nó sẽ chưa thông tin ‘món’ bạn order, đầu bếp reducer sẽ dựa vào đó mà xào nấu ra ‘món’ bạn order

function reducer(state = initialState, action) {
  switch(action.type) {
    case 'INCREMENT':
      return {
        count: state.count + 1
      };
    case 'DECREMENT':
      return {
        count: state.count - 1
      };
    default:
      return state;
  }
}

Reducer sẽ căn cứ vào action.type để thực hiện thay đổi và trả về state mới, nên nhớ chúng ta phải LUÔN LUÔN trả về state trong reducer, nếu có hay không có thay đổi cũng phải trả về state

Không bao giờ được phép thay đổi State trực tiếp

State là một immutable object, tuyệt đối KHÔNG thay đổi state như sau

function brokenReducer(state = initialState, action) {
  switch(action.type) {
    case 'INCREMENT':
      // BẬY: đừng thay giá trị bằng kiểu này
      state.count++;
      return state;

    case 'DECREMENT':
      // BẬY: đừng thay giá trị bằng kiểu này
      state.count--;
      return state;

    default:
      return state;
  }
}

Làm như vậy cũng cấm tuyệt đối nhé:

state.foo = 7
state.items.push(newItem)
delete state.something

Action từ đâu mà có

Action không tự sinh ra, nó được dispatch ra từ hàm dispatch. Hàm dispatch thì đặc biệt là nó không được import, mình có thể gọi store.dispatch(someAction), nhưng cái store này thì nó năm ở trong 1 file thôi, Vậy hàm dispatch này làm sao có đây?

Thật ra lúc chúng ta gọi connect thì hàm connect cũng đã map cái hàm dispatch vào trong props của component luôn.

import React from 'react';
import { connect } from 'react-redux';

class Counter extends React.Component {
  increment = () => {
    this.props.dispatch({ type: 'INCREMENT' });
  }

  decrement = () => {
    this.props.dispatch({ type: 'DECREMENT' });
  }

  render() {
    return (
      <div>
        <h2>Counter</h2>
        <div>
          <button onClick={this.decrement}>-</button>
          <span>{this.props.count}</span>
          <button onClick={this.increment}>+</button>
        </div>
      </div>
    )
  }
}

function mapStateToProps(state) {
  return {
    count: state.count
  };
}

export default connect(mapStateToProps)(Counter);

TopDev via Vuilaptrinh

Sinh viên IT cần trang bị gì khi tìm việc

Sau những năm mòn mông trên ghế nhà trường, chắc hẳn ai cũng có mong muốn có được công việc ổn định, lo được cuộc sống hiện tại và tương lai. Nhưng đường đời không hề bằng phẳng, ra trường bạn mang một nhiệt huyết muốn cống hiến muốn làm đúng chuyên ngành để phát triển bản thân nhưng rồi tình trạng chung lại xuất hiện, gửi CV nhiều nơi nhưng không có nơi nào gọi.

Bạn không biết vì sao, bạn không biết bạn thiếu gì thì hãy đoc bài viết này góp phần hỗ trợ các bạn sinh viên IT cách nhìn nhận lại cái mình còn thiếu và cần trang bị những gì khi tìm kiếm công việc.

Kiến thức

Đây là điều tiên quyết bạn cần có khi tìm kiếm công việc. Kiến thức sẽ là yếu tố để nhà tuyển dụng nhìn nhận những yếu tố bên ngoài của bạn để xem xét bạn phù hợp không. Ví dụ bạn là lập trình PHP nhưng công ty bạn mong muốn làm thì lại tuyển Java thì bạn đã vào thế yếu rồi. Nhưng nếu như bạn chưa tích lũy đủ thì cũng đừng quá băn khoăn, bạn vẫn có cơ hội update kiến thức dần dần, miễn là trong chính bản thân bạn có động lực thúc đẩy bạn làm điều đó.

Tham khảo: Các vị trí tuyển dụng IT parttime hấp dẫn tại Topdev

Ngoại ngữ

Ngoại ngữ là một trong những yếu tố cần thiết đối với ngành IT ngoài kỹ năng chuyên môn. Hầu hết các tài liệu nghiên cứu về ngành IT đều bằng tiếng Anh, vì công nghệ nước ngoài đi trước chúng ta, công nghệ tại Việt Nam mới kế thừa và phát triển sau này nên tài liệu mang tiếng Việt khá ít mà thường biên dịch từ tài liệu nước ngoài. Nhưng việc biên dịch cũng có hạn chế vì người ta sẽ dịch dựa trên góc nhìn và độ hiểu của người dịch, có thể vô tình câu từ gây khó hiểu. Nên việc hiểu biết về tiếng Anh sẽ giúp bạn vừa hiểu tường tận kiến thức chuyên môn, vừa cải thiện khả năng tiếng Anh

Tiếng Anh dành cho lập trình viên

5 trang web, nguồn học thuật toán chất lượng để bạn luyện "lên cơ"

Hồ sơ xin việc – CV

Bạn đầu tư cho bản thân nhưng đó là những thứ vô hình, khó nhìn thấy, nhà tuyển dụng sẽ rất khó để biết bạn có gì trong mình nên hồ sơ xin việc là công cụ giúp bạn hữu hình hoá những cái bạn đang có, những cái bạn muốn show ra để thấy bạn là người phù hợp.

Tuỳ nơi mà có quy định riêng về hồ sơ xin việc khác nhau, nhưng cơ bản có những yếu tố sau đây: sơ yếu lý lịch, đơn xin việc, CV, giấy khám sức khỏe, bằng cấp – chứng chỉ.

Nhưng có lẽ điều bạn băn khoăn là không biết viết gì trong CV để phù hợp?

Hiện tại trên mạng có rất nhiều template CV sẵn, tha hồ bạn lựa chọn, nhưng template chỉ là yếu tố phụ thôi, quan trọng là nội dung của CV.

“Để thu hút nhà tuyển dụng thì ứng viên nên nhấn mạnh giá trị mình đem đến cho công ty, cũng như chứng minh được bản thân có khả năng giải quyết vấn đề tốt qua những kinh nghiệm làm việc. Còn technology thì không thực sự cần thiết vì mỗi công ty sẽ có technology riêng của họ”).

– Anh Hiếu Phạm – Senior Software Engineer tại Rockset

Để hết tất cả những project bạn từng tham gia vào trong CV, điều đó cũng được thôi nhưng quan trọng với mỗi project bạn học được gì. Nhà tuyển dụng khi nhìn vào những project bạn làm sẽ nghĩ bạn có kinh nghiệm và kỹ năng, và đó là điểm cộng so với những ứng viên khác. Nhưng điều quan trọng hơn là nhà tuyển dụng cần biết bạn học được điều gì với mỗi project.

Có những bạn sinh viên tham gia project thì nhiều nhưng cuối cùng lại là “cái đầu rỗng”, đến khi hẹn ứng viên phỏng vấn mới phát hiện ra. Thế nên để tránh làm mất thời gian của nhau thì bạn nên ghi tóm tắt những điều mình làm và học được sau mỗi project, mô tả khái quát về dự án đó làm gì, công nghệ như thế nào, bạn thực hiện công việc chính gì trong project đó.

Viết thư xin việc đúng cách

Chủ động trong mọi tình huống

Khi gần ra trường hay trước học kỳ đi thực tập, các bạn nên dành ra một chút thời gian, chủ động đi tìm việc. Với sự phát triển của Internet hiện nay thì không quá khó khi tìm kiếm, chỉ cần search keyword một cách tối ưu sẽ giúp bạn tìm kiếm hiệu quả hơn, hoặc các bạn có thể lên các trang confession để hỏi các anh chị đi trước.

Vậy chủ động tìm kiếm điều gì về công ty, nơi bạn muốn làm việc? Bạn nên tìm hiểu về văn hóa, chế độ đãi ngộ, tầm nhìn phát triển của công ty. Bạn so sánh các điều đó với career path của bạn, nếu phù hợp thì đó là nơi dành cho bạn. Ngoài ra, khi bạn tìm hiểu những thông tin trên từ trước, đó sẽ là điểm cộng khi bạn đi phỏng vấn.

Tất cả những thủ thuật Google Search mà bạn cần biết

Lượng sức mình, không nên quá ảo tưởng

Nhiều lúc chắc bạn tự hỏi sao gửi CV nhiều nơi mà không thấy công ty nào gọi hẹn lịch. Có nhiều nguyên nhân dẫn đến trường hợp này, một trong số đó là bạn lựa chọn công ty ứng tuyển chưa phù hợp với năng lực, nhà tuyển dụng họ thường xem xét tuyển người phù hợp hơn là người giỏi.

Bạn thử hình dung, nếu một người giỏi vào công ty nhưng tinh thần làm việc trì trệ, nghĩ mình giỏi và xem thường đồng nghiệp thì tuyển vào rất lãng phí. “Một cây làm chẳng nên non, ba cây chụm lại nên hòn núi cao”, trong công việc “đơn phương độc mã” thì công việc không hiệu quả được, nếu tuyển người như trên thì teamwork cũng rất khó. Ông bà ta có câu “biết mình biết ta, trăm trận trăm thắng” là vậy, hiểu bản thân mình, hiểu nhà tuyển dụng chắc chắn bạn sẽ thu hút được mọi nhà tuyển dụng hướng đến bạn.

Thời điểm mới ra trường đa số các bạn đều muốn lương cao, đãi ngộ tốt, đòi hỏi rất nhiều từ nhà tuyển dụng để xứng đáng với 4 năm đại học, nhưng cũng vì thế mà bạn gặp khó khăn trong quá trình tìm việc. Đừng nên đòi hỏi mà thay vào đó, bạn hãy lựa chọn những công việc training on job, cũng sẽ là cơ hội cho bạn tích lũy kinh nghiệm và nâng cao năng lực trước khi cập bến tại một công ty to lớn hơn, nơi mà bạn ao ước.

Học và cả thiện kiến thức lập trình từ các dự án cá nhân (Pet Project)

Chuẩn bị thật kỹ trước buổi phỏng vấn

Có người thì lo lắng quá trước khi đi phỏng vấn, có bạn thì lại không, nhưng lời khuyên mình dành cho các bạn là nên chuẩn bị kỹ trước cho buổi phỏng vấn. Vậy chuẩn bị gì, mong là một số lời khuyên bên dưới giúp ích cho bạn.

Ôn lại kiến thức mà phía nhà tuyển dụng yêu cầu, chúng được đề cập trong mô tả công việc. Bạn có thể tham khảo các câu hỏi mẫu, phổ biến mà tuyển dụng hay dùng, điều này sẽ giúp bạn cảm thấy tự tin hơn, tránh bị lúng túng.
Chuẩn bị kỹ càng mọi hồ sơ cần thiết.
Tập thử trước gương hoặc soạn sẵn ra những câu hỏi, tự trả lời trước gương, chỉnh sửa tác phong, điều này giúp bạn tạo nên sự tự tin và cách nói chuyện thật tốt.

Trong quá trình phỏng vấn

Dù chuẩn bị kỹ càng cỡ nào thì khi đi phỏng vấn cũng không biết chuyện gì xảy ra để lường trước được, nhưng bạn cần lưu ý những điểm sau đây:

Bình tĩnh trong quá trình phỏng vấn, mất bình tĩnh sẽ ảnh hưởng đến kết quả phỏng vấn.
Trang phục lịch sự, nói chuyện âm lượng vừa đủ nghe, khi bước vào phỏng vấn nên cúi đầu nhẹ và chào, sẽ giúp bạn bước đầu ghi điểm trong mắt nhà tuyển dụng và cũng khiến bạn cảm thấy thoải mái, không bị quá áp lực với bầu không khí căng thẳng lúc đó.
Khi trả lời phỏng vấn, nếu không biết thì hãy thành thật. Nhà tuyển dụng sẽ biết bạn nói xạo ngay thông qua một số câu hỏi vì đó là nghề của họ. Không nên nói thẳng thừng là “Em không biết!” mà nên trả lời khéo léo, ví dụ như “vấn đề này em chưa có cơ hội tìm hiểu qua, em sẽ tìm hiểu trong thời gian tới’.
Hãy luôn thể hiện mình là một người có tinh thần học hỏi, không ngại khó, không ngại khổ; cố gắng thể hiện năng lượng và tinh thần làm việc nhóm.
Hãy nói lên mong muốn của bạn, mong muốn được có cơ hội thử sức làm viêc tại công ty, bên cạnh đó thể hiện đam mê và trách nhiệm với công việc.
Bạn cũng có thể tham khảo các bài phỏng vấn mẫu để rút ra bài học cho bản thân và áp dụng khi đi phỏng vấn.

Bỏ túi những kinh nghiệm đi thực tập hay dành cho lập trình viên!

Lời nhắn nhủ

Bài viết dựa trên góc nhìn của bản thân, nếu còn thiếu sót mong các bạn thông cảm và góp ý với mình nhé! Hi vọng trong tương lai, bài viết sẽ góp phần giúp các bạn tự tin tiếp bước trên con đường lập nghiệp.

Ngoài ra với các bạn sinh viên đang tham khảo vị trí tuyển dụng từ các công ty ngành cntt. Tham khảo ngay các việc làm it như fresher business analyst, fresher net, fresher nodejs,….. apply ngay!

Các nguyên tắc 5W1H – 5W2H – 5W1H2C5M

Bạn luôn trong trạng thái không biết sẽ làm gì và bắt đầu từ đâu trong công việc? Các công việc cứ chồng chéo lên nhau và bạn không biết phải làm việc nào trước. Và nhiều vấn đề khác liên quan đến lập kế hoạch trong học tập, làm việc hoặc kinh doanh. Bài viết này là dành cho bạn, TopDev sẽ giúp bạn tìm hiểu các phương pháp giúp xác định rõ nội dung công việc một cách hiệu quả. Đó là 3 nguyên tắc 5W1H, 5W2H và 5W1H2C5M.

Nguyên tắc 5W1H

5W gồm WHO, WHAT, WHEN, WHERE, WHY và 1H là HOW.

Mỗi từ trong 5W1H đại diện cho một câu hỏi căn bản:

What (Cái gì): Điều gì đã xảy ra? Vấn đề là gì?
Why (Tại sao): Tại sao điều này xảy ra? Nguyên nhân là gì?
Who (Ai): Ai là người liên quan hoặc chịu trách nhiệm?
Where (Ở đâu): Điều này xảy ra ở đâu? Bối cảnh nào?
When (Khi nào): Thời gian xảy ra sự việc là khi nào?
How (Như thế nào): Điều này diễn ra như thế nào? Quá trình ra sao?

Why – Mục tiêu và công việc nào cần thực hiện

Why giúp bạn đặt ra những thắc mắc đầu tiên trước khi tiếp tục các giai đoạn kế tiếp. Đây cũng được xem là rào cản và cũng là thách thức mà bạn cần vượt qua.

Hãy trả lời các câu hỏi sau đây để tự nhận định rằng mình có mục tiêu rõ ràng hay chưa:

Tại sao bạn phải làm công việc này?
Nó có ý nghĩa như thế nào đối với bộ phận, tổ chức của bạn?
Nếu không thực hiện, nó có dẫn đến những ảnh hưởng nào hay không?

Nhiều người gặp khó khăn và đã thất bại trong khi trải nghiệm Why. Điều này dễ hiểu vì bản thân họ chưa biết họ muốn điều gì. Vì thế, các bạn hãy thật sự tập trung để xác định mục tiêu, yêu cầu công việc một cách cụ thể. Điều này có ý nghĩa lớn vì nó sẽ là kim chỉ nam giúp bạn luôn hướng về mục tiêu ban đầu đồng thời việc đánh giá kết quả đạt được sẽ chính xác hơn.

What – Xác định nội dung công việc cụ thể là gì?

Sau khi đã vạch rõ mục tiêu, yêu cầu công việc, bước tiếp theo là bạn sẽ lên những nội dung hoạt động cụ thể hơn.

Chằng hạn, khi xác định được mục tiêu là cần đạt được 300 CV trong vòng 1 tuần, bạn sẽ chia nhỏ ra những đầu công việc ứng với từng nhiệm vụ. Đó có thể là thông tin về vị trí ứng tuyển, tìm kiếm khai thác và khoanh vùng những ứng viên tiềm năng, lập hồ sơ liên hệ và trao đổi với các đối tác để có nguồn dữ liệu về các ứng viên đủ tiêu chí,…Và một điều quan trọng là đừng quên bám sát vào mục tiêu đề ra, tránh đi lạc hướng so với những dự định ban đầu.

Where, When, Who – Địa điểm, thời gian, nguồn lực nhân sự

Các câu hỏi thuộc nhóm 3W (Where, When, Who) giúp xác định bối cảnh, thời gian và đối tượng liên quan đến một vấn đề cụ thể. Dưới đây là mô tả chi tiết và ví dụ cho từng câu hỏi Where, When, và Who.

Where (ở đâu?)

Câu hỏi “Where?” được sử dụng để xác định địa điểm hoặc bối cảnh nơi một sự kiện, hành động, hoặc vấn đề xảy ra. Nó giúp làm rõ vị trí địa lý hoặc bối cảnh cụ thể liên quan đến tình huống đang được xem xét.

Ví dụ các câu hỏi:

Sự kiện này diễn ra ở đâu?
Nơi làm việc của bạn ở đâu?
Cuộc họp được tổ chức ở phòng nào?
Dự án này sẽ được triển khai ở địa phương nào?
Tài liệu này được lưu trữ ở đâu?

When (khi nào?)

Câu hỏi “When?” được sử dụng để xác định thời gian hoặc mốc thời gian mà một sự kiện hoặc hành động xảy ra. Việc trả lời câu hỏi này giúp làm rõ khung thời gian liên quan đến sự kiện hoặc hành động đó.

Ví dụ các câu hỏi:

Khi nào cuộc họp bắt đầu?
Dự án này sẽ hoàn thành vào thời gian nào?
Bạn đã gặp khách hàng lần đầu tiên khi nào?
Khi nào bạn bắt đầu công việc này?
Sản phẩm sẽ được ra mắt vào khi nào?

Who (ai?)

Câu hỏi “Who?” được sử dụng để xác định người hoặc nhóm người có liên quan đến một sự kiện, hành động, hoặc tình huống cụ thể. Nó giúp làm rõ danh tính của các cá nhân hoặc tổ chức liên quan.

Ví dụ các câu hỏi:

Ai là người chịu trách nhiệm cho dự án này?
Ai sẽ tham gia cuộc họp ngày mai?
Bạn đã làm việc với ai trong dự án này?
Khách hàng chính của chúng ta là ai?
Ai là người phát biểu trong buổi lễ?

How – Cách thức để thực hiện nhiệm vụ

Ở bước này, hiểu đơn giản là người lập kế hoạch cần chỉ ra được những cách thức thực hiện công việc.

Cụ thể, cần thông tin cho những cộng sự về các nguồn tài liệu có liên quan, thiết bị nào cần được trang bị nhằm phục vụ tốt quá trình thực hiện công việc, cách vận hành các thiết bị, máy móc hoặc đề ra những tiêu chuẩn đánh giá về chất lượng công việc.

Nguyên tắc 5W2H

Nguyên tắc 5W2H, gần giống với 5W1H chỉ khác là có thêm 1H nữa là How much/How many – Chi phí là bao nhiêu? Số lượng là bao nhiêu? Mức độ ảnh hưởng ra sao?

5W2H đi sâu hơn vào chi tiết bằng cách bổ sung phân tích về khía cạnh định lượng, như chi phí, số lượng, mức độ giúp bạn có cái nhìn chi tiết hơn, đặc biệt là trong việc lập kế hoạch và quản lý dự án. Ví dụ các câu hỏi như Chi phí cho dự án này là bao nhiêu? Lợi nhuận dự kiến là bao nhiêu? Bao nhiêu thời gian sẽ cần để hoàn thành nhiệm vụ này?

Phương pháp 5W1H2C5M

Nhìn vào các chữ cái viết tắt, chúng ta dễ dàng nhận thấy 5W1H2C5M là cải tiến từ 5W1H với phần bổ sung là 2C và 5M. Cùng xem các chữ cái này có ý nghĩa gì nhé!\

2C – Control, Check

Trong phương pháp 5W1H2C5M, 2C đại diện cho hai yếu tố quan trọng: Control (Kiểm soát) và Check (Kiểm tra). Cả hai yếu tố này đều liên quan đến việc đảm bảo rằng một dự án hoặc quy trình được thực hiện theo đúng kế hoạch, đạt được các tiêu chuẩn chất lượng, và đáp ứng các yêu cầu đã đề ra.

Control – Kiểm soát hoạt động

Bất kỳ một công việc nào khi thực hiện cũng cần phải được tiến hành kiểm soát và đo lường. Chính vì vậy, để việc theo dõi và đo lường phạm vi hoạt động hiệu quả, bạn cần đề cập đến một số yếu tố sau:

Đơn vị đo lường cho công việc này là gì?
Những thông số khoa học nào phản ánh đầy đủ khả năng và phạm vi hoạt động của công việc?
Vấn đề nào/Điều gì cần kiểm soát và theo dõi xuyên suốt?

Check – Kiểm tra, đánh giá quá trình và hiệu suất

Đây là một bước khá quan trọng và cần được tuân thủ theo nguyên tắc Pareto: Cơ chế của nguyên tắc này là chỉ kiểm tra 20% mức độ hiệu quả ban đầu của quá trình thực hiện nhiệm vụ. Trong khi đó, 80% sẽ tập trung vào những sai sót phát sinh.

Để công đoạn kiểm tra và đánh giá quá trình đạt được hiệu quả như mong muốn, người quản lý cần xác định những nội dung như sau:

Những bước nào cần tiến hành kiểm tra, theo dõi
Tần suất kiểm tra là bao lâu? (dựa vào tính quan trọng của từng giai đoạn thực hiện)
Những điểm nào là trọng yếu trong quá trình đánh giá

5M – Xác định nguồn lực thực hiện nhiệm vụ

5M là viết tắt của Man, Money, Material, Machine, Method, đây là năm yếu tố chính ảnh hưởng đến sản xuất và quản lý, thường được sử dụng trong phân tích và cải tiến quy trình.

Man – Nguồn nhân lực: Người giữ trách nhiệm thực hiện công việc có đủ mức độ phù hợp với công việc thông qua các tiêu chí về: trình độ, kỹ năng, kinh nghiệm, phẩm chất,…
Money – Ngân sách: Nguồn quỹ thực hiện những công việc này là bao nhiêu? Và kỳ hạn giải ngân sẽ được tiến hành trong bao lâu?
Material – Hệ thống cung ứng phục vụ kế hoạch nhân sự: Tiêu chuẩn để trở thành nhà cung ứng cho việc là gì?
Machine – Máy móc/công nghệ kỹ thuật: Mức độ tương đồng giữa các thiết bị công nghệ kỹ thuật có phù hợp với nhu cầu thực hiện nhiệm vụ không? Những phương pháp về công nghệ nào cần được áp dụng để thực hiện công việc?…
Method – Phương pháp làm việc: Cách vận hành hoạt động nhân sự như thế nào?

Nguyên tắc 5W – H – 2C – 5M được thể hiện dưới nhiều hình thức khác nhau và trên thực tế khi áp dụng, với kinh nghiệm vốn có của mình, nhà quản lý sẽ linh hoạt sao cho nguyên tắc này đảm bảo được tính hiệu quả nhất cho tổ chức của mình.

3 phương pháp 5W1H – 5W2H – 5W1H2C5M là công cụ mạnh mẽ giúp bạn phân tích, lập kế hoạch, và quản lý các dự án hoặc quy trình một cách hiệu quả. Hi vọng qua bài viết của TopDev đã giúp bạn biết cách áp dụng các nguyên tắc phù hợp với bản thân.

Xem thêm Top Việc làm Developer trên TopDev

React Authentication với Amazon Cognito – Phần 1

Implement authentication 2 factor sử dụng React, React Router, Amazon Cognito

Trong demo chúng ta sẽ sử dụng

Create React App
Glamor
React Router
Amazon Cognito để authentication
AWS amplify để tương tác với AWS Services

Tuyển dụng React ngành IT

Setup

Khởi tạo project và các thư viện sẽ sử dụng

create-react-app react-auth
cd react-auth

npm i react-router-dom glamor --save

Cài AWSMobile CLI

npm i -g awsmobile-cli

Khởi tạo config AWS IAM

awsmobile configure
awsmobile init

Nó sẽ tạo project Mobile Hub và file aws-exports.js trong thư mục src. Tiếp theo, thêm user-signin và deploy các config mới

awsmobile user-signin enable
awsmobile push

awsmobile user-signin enable sẽ bật Amazon Congito trong project với các thiết đặt mặc định, bao gồm 2 factor authentication với SMS (sẽ thêm TOTP sau). Nếu muôn can thiệp các thiệt đặt, vào trực tiếp Amazon Cognito để chỉnh

Màn hình đăng ký

Để tương tác với Amazon Cognito, chúng ta sẽ sử các hàm trong class Auth từ thư viện aws-amplify:

signUp – tạo user mới

signUp(username: string, password: string, attributes?: object)

confirmSignUp – để xác nhận đăng ký thành công

confirmSignUp(username: string, authenticationCode: string)

signIn – đăng nhập

signIn(username: string, password: string)

confirmSignIn – xác nhận đăng nhập

confirmSignIn(user: object, authenticationCode: string)

Trong file root của project, thường là index.js

// một số import khác
// 
import config from './aws-exports'
import Amplify from 'aws-amplify'

Amplify.configure(config)

ReactDOM.render(<App />, document.getElementById('root'))
registerServiceWorker();

Screen SignUp.js

import React from 'react'
import { css } from 'glamor'

class SignUp extends React.Component {
  state = {
    username: '',
    password: '',
    email: '',
    phone_number: '',
    authCode: ''
  }
  render() {
    return (
      <div {...css(styles.container)}>
        <h2>SignUp</h2>
      </div>
    )
  }
}
const styles = {
  container: {
    display: 'flex',
    flexDirection: 'column',
    alignItems: 'center'
  }
}

Flow sẽ như thế này, sau khi user cung cấp các thông tin trong form signup, chúng ta gọi đến phương thức signUp, user sẽ nhận được một mã code để verify quá SMS, user điền mã code này vào form verify, chúng ta verify cái mã code này bằng phương thức ‘confirmSignUp’

import React from 'react'
import { css } from 'glamor'

class SignUp extends React.Component {
  state = {
    username: '',
    password: '',
    email: '',
    phone_number: '',
    authCode: ''
  }
  onChange = (key, value) => {
    this.setState({ [key]: value })
  }
  render() {
    return (
      <div {...css(styles.container)}>
        <h2>Sign Up</h2>
        <input
          {...css(styles.input)}
          placeholder='Username'
          onChange={evt => this.onChange('username', evt.target.value)}
        />
        <input
          {...css(styles.input)}
          placeholder='Password'
          type='password'
          onChange={evt => this.onChange('password', evt.target.value)}
        />
        <input
          {...css(styles.input)}
          placeholder='Email'
          onChange={evt => this.onChange('email', evt.target.value)}
        />
        <input
          {...css(styles.input)}
          placeholder='Phone Number'
          onChange={evt => this.onChange('phone_number', evt.target.value)}
        />
        <div {...css(styles.button)}>
          <span>Sign Up</span>
        </div>
        
        <input
          {...css(styles.input)}
          placeholder='Authentication Code'
          onChange={evt => this.onChange('authCode', evt.target.value)}
        />
        <div {...css(styles.button)}>
          <span>Confirm Sign Up</span>
        </div>
        
      </div>
    )
  }
}

let styles = {
  container: {
    display: 'flex',
    flexDirection: 'column',
    alignItems: 'center'
  },
  button: {
    width: '170px',
    padding: '10px 0px',
    backgroundColor: '#ddd',
    cursor: 'pointer',
    borderRadius: '3px',
    ':hover': {
      backgroundColor: '#ededed'
    }
  },
  input: {
    height: 40,
    marginBottom: '10px',
    border: 'none',
    outline: 'none',
    borderBottom: '2px solid #4CAF50',
    fontSize: '16px',
    '::placeholder': {
      color: 'rgba(0, 0, 0, .3)'
    }
  }
}

export default SignUp

Xong cái UI, giờ ta sử dụng 2 phương thức class Auth

// previous imports omitted

  import { Auth } from 'aws-amplify'

  // previously shown code omitted
  signUp = () => {
    const { username, password, email, phone_number } = this.state
    Auth.signUp({
      username,
      password,
      attributes: {
        email,
        phone_number
      }
    })
    .then(() => console.log('successful sign up!'))
    .catch(err => console.log('error signing up: ', err))
  }
  confirmSignUp = () => {
    Auth.confirmSignUp(this.state.username, this.state.authCode)
    .then(console.log('successful confirm sign up!'))
    .catch(err => console.log('error confirming signing up: ', err))
  }
  render() {
    // 
    // here we need to update the buttons to attach class methods to onClick event
    <div {...css(styles.button)} onClick={this.signUp}>
      <span>Sign Up</span>
    </div>

    <input
      {...css(styles.input)}
      placeholder='Authentication Code'
      onChange={evt => this.onChange('authCode', evt.target.value)}
    />
    <div {...css(styles.button)} onClick={this.confirmSignUp}>
      <span>Confirm Sign Up</span>
    </div>
  }

Cuối cùng import và sử dụng component trong App.js

import React, { Component } from 'react';
import logo from './logo.svg';
import './App.css';

import SignUp from './SignUp'

class App extends Component {
  render() {
    return (
      <div className="App">
        <header className="App-header">
          <img src={logo} className="App-logo" alt="logo" />
          <h1 className="App-title">Welcome to React</h1>
        </header>
        <SignUp />
      </div>
    );
  }
}

export default App;

Các thông tin của user sẽ được lại trong ‘Manage your User Pools’, vào Amazon Coginito dashboard, chọn ứng dụng đã setup, chọn mục ‘Users and Settings’

Sign in thì cũng tương tự như signup, chúng ta sử dụng Auth.signIn(username, password), trả về object nếu thành công, sau đó nó sẽ gửi SMS tới user với code xác nhận lần nữa, verify bằng confirmSignIn

signIn() {
  Auth.signIn(this.state.username, this.state.password)
    .then(user => this.setState({ user }))
    .catch(err => console.log('error signing in! :', err))
}
confirmSignIn() {
  Auth.confirmSignIn(this.state.user, this.state.authCode)
    .then(userData => {
      console.log('userdata: ', userData)
    })
    .catch(err => console.log('error confirming sign in!: ', err))
}

User data nằm trong cục dữ liệu trả về sau khi gọi hàm confirmSignIn

Có rất nhiều cách để lấy thông tin user đang đăng nhập, có thể dùng Auth.currentAuthenticatedUser() là dễ nhất, toàn bộ API có thể tham khảo ở đây

Kết thúc phần 1 ở đây, phần 2 tiếp tục với Routing và TOTP để có thể làm Google Authenticator.

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

Xem thêm các vị trí công việc ngành it tại Topdev.vn

8 câu điều kiện khi render trong React

Tutorial này sẽ cover những câu điều kiện dùng để render component phổ biến nhất

If/Else

Dễ nhất và căn bản nhất

render() {
    if (this.state.mode === 'view') {
        return (
            <div />
        )
    } else {
        return (
            <div />
        )
    }
}

Ko render với `null`

Nếu không muốn render một component, trong hàm return trả về giá trị null, lưu ý khi return null nhưng hàm render vẫn được gọi.

render() {
    if (this.state.mode === 'view') {
        return <h1 />;
    } else {
        return (
            null
        )
    }
}

Đặt biến cho element

Giờ nếu không muốn thêm câu else

render() {
    let input;
    
    if (this.state.mode !== 'view') {
      input = <h1/>;
    }
      
    return input;
}

Câu điều kiện rút gọn

Thay gì if/else, có thể dùng câu điều kiện rút gọn để render luôn

điều kiện ? nếu true : nếu false

Sử dụng với ví dụ trên

render() {
    return(
        <div>
            {this.state.mode === 'view' ? <h1> : null}
        </div>
    )
}

Gọn gàng sạch sẽ hơn, tuy nhiên cũng đừng lạm dụng quá, có anh bạn làm chung với mình, lạm dụng cách này quá lố, đến nổi mỗi lần đọc code của anh ấy là cơn ác mộng, mặc dù không sai, nhưng thằng nào code sau mở lên đọc tội nó lắm.

return (
  <div>
    { condition1
      ? <Component1 />
      : ( condition2
        ? <Component2 />
        : ( condition3
          ? <Component3 />
          : <Component 4 />
        )
      )
    }
  </div>
);

Short-circuit operator (&&)

Trong trường hợp trên, rõ ràng việc trả về null cũng hơi dư thừa, có thể sử dụng ngắn-hơn-cả-ngắn với cú pháp &&. Cũng như câu điều kiện rút gọn, tuy nhiên nó sẽ chỉ render nếu true, con false nó sẽ không làm gì cả

render() {
    return(
        <div>
            {this.state.mode === 'view' && <h1>}
        </div>
    )
}

Immediately-invoked function expressions (IIFE)

IIFE như tên gọi nó đã nói lên tất cả, hàm sẽ thực thi ngay khi nó được định nghĩa.

Bình thường

function myFunction() { 
    // ...
}
myFunction();

Để biến nó thành IIFE, convert nó qua thành một expression

(function myFunction(/* tham số*/){
    // ...
}( /* tham số*/ ));

// viêt như vầy cũng được nha
(function myFunction(/* tham số*/){
    // ...
})( /* tham số*/ );

// hoặc bỏ luôn tên
(function(/* tham số*/){
    // ...
})( /* tham số*/ );

// hoặc dùng luôn arrow function cho máu
((/* tham số*/) => {
    // ...
})( /* tham số*/ );

Giờ thì dùng IIFE với component

render() {
    return(
        <div>
            {
              (() => {
                const handler = view 
                    ? this.handleEdit 
                    : this.handleSave;
                const label = view ? 'Edit' : 'Save';
              
                return (
                  <button onClick={handler}>
                    {label}
                  </button>
                );
              })()
            }  
        </div>
    )
}

Subcomponents

Nếu thấy dùng IFEE có vẻ hơi khó chịu, chúng ta đang làm React, tất cả hãy đưa về component, tách phần logic của component và phần render cái view ra luôn là đều được khuyến cáo, declarative vs. imperative programing

Vậy nên chuyển các điều kiện này sang một sub component để render dựa trên props luôn là ý hay.

render(
    const view = this.state.mode === 'view';

    return(
        <div>
            {
              view
                ? <EditComponent handleEdit={this.handleEdit}  />
                : (
                  <SaveComponent 
                   handleChange={this.handleChange}
                   handleSave={this.handleSave}
                   text={this.state.inputText}
                 />
                )
            } 
        </div>
    )
)

Hoặc trong React-Router-4 mỗi route là một If component với cách thức vận hành như sao

<If
    condition={ view }
    then={ editComponent }
    else={ editComponent }
/>

// Component Route trong React-Router
<Route path='/' component={Home} />

Higher-Order Component (HOC)

Sử dụng HOC để truyền xuống một prop dựa trên kiểm tra logic

function higherOrderComponent(Component) {
  return function EnhancedComponent(props) {
    if (condition) {
      return <AnotherComponent { ...props } />;
    }

    return <AnotherComponent { ...props } />;
  };
}

Tham khảo thêm việc làm React lương cao tại đây

TopDev via Vuilaptrinh

Phân tích

Dựng component thô chưa có animate

Animate với Flip technique

Chăm chút

Background animation

1. Có chiến lược đào tạo rõ ràng & chuyên nghiệp

2. Phát triển người quản lý thành cố vấn chuyên môn cho các nhân viên

3. Nhấn mạnh các kỹ năng mềm

4. Đầu tư vào phát triển cá nhân

Cân bằng cảm xúc

Đầu tư phát triển về mindset

Luôn trả về giá trị

Module hóa

Hợp thể ko kế thừa (composition vs. inheritance)

Ghi nhớ khi cần thiết

Không thay đổi giá trị gốc

Không dùng vòng lặp for

Không dùng switch...case

Try…catch

Undefined và null

Class

Đặt tên function

Mental model là gì

Hình dung cách React vận hành như thế nào

Tất cả đều là function

Component: một function trả về JSX

Prop: tham số của function

Hình dung về một function

Hình dung cách React render

Mình là 1 lập trình viên senior

Những điều mà mình đã học được

Mọi người đều tự test

Chúng ta đã bị bỏ lại khá xa so với những người khác (aka tech fomo)

Những điều cuối cùng mình học được

Chất lượng code là điều quan trọng nhất.

Mọi thứ phải được tư liệu hóa – document.

Technical debt khá là tệ

Có thâm niên = giỏi lập trình

Lời kết

Đôi nét về khách mời Nhân Nguyễn

Trải nghiệm việc làm tại những doanh nghiệp lớn

Khởi nghiệp tại Việt Nam và những bài toán

Code của tôi chạy hoàn hảo. Sao tôi phải test?

Nhưng mà, tôi không biết test cái gì bây giờ?!

Testing vừa khó khăn vừa khó hiểu

Testing khiến kéo dài thời gian phát triển 🙁

Thách thức bài test đầu vào – Liệu bạn đã sẵn sàng?

Quan trọng nhất – Vòng phỏng vấn trực tiếp

1. Câu hỏi cá nhân:

2. Câu hỏi về chuyên môn:

Kiến thức Java nền tảng

Một số câu hỏi về Git cần biết

Kiến thức về Framework (ví dụ như học Spring Framework của Java)

Kiến thức về Database

Một số câu hỏi “mẹo” về Front-end

3. Câu hỏi đánh giá về khả năng tiếp thu kiến thức

Lời kết

preload

prefetch

preconnect

dns-prefetch

prerender

Object.create

Sâu hơn xa hơn

Một số phương thức với prototype nên biết

Lấy tất cả prototype của function

Xác định một property có tồn tại trong prototype không

kiểm tra một object có phải là một instance của Class

Lưu ý về arrow function

Tạo access token trên Github

Upload những thiết đặt, extensions đã cài cho VSCode

Download các thiết từ gist về

Chỉ sử dụng State của React

Thêm Redux

Action

Không bao giờ được phép thay đổi State trực tiếp

Action từ đâu mà có

Kiến thức

Ngoại ngữ

Hồ sơ xin việc – CV

Không dùng vòng lặp `for`

Không dùng `switch...case`

Ko render với `null`