Lập trình viên Google đã tiết kiệm 90% lương như thế nào?

Bài viết được sự cho phép của smartjob.vn

Trong bài viết này, Smartjob sẽ chia sẻ cho các bạn một câu chuyên khá hi hữu về chàng trai hiện đang là lập trình viên của gã khổng lồ Google khi anh ấy bằng một cách thần kỳ đã bảo toàn được tới 90% lương của mình. Quả là một câu chuyện đáng học hỏi cho những ai muốn tiết kiệm thật nhiều cho tương lai của mình.

10 nguyên tắc lập trình nền tảng mà lập trình viên nào cũng cần biết

Thuật toán là gì? 11 thuật toán hàng đầu dành cho lập trình viên

Chàng trai đó tên là Brandon, 24 tuổi, trở thành kỹ sư phần mềm của Google từ tháng 5/2015. Anh ấy đã có ý tưởng sống trong một chiếc xe tải để thắt chặt chi tiêu của mình khi bắt đầu thực tập tại Google giữa năm 2014. Vào thời điểm đó, Brandon cùng 3 người bạn của anh đã thuê một căn hộ 2 giường ngủ với mức giá rẻ nhất San Francisco (khoảng 65USD/đêm tương đương 2000 USD/tháng).

Chiếc xe của Brandon tại khuôn viên Google

Sau kì thực tập, Brandon đã thuyết phục hoàn toàn được các sếp trong Google và trở thành kỹ sư phần mềm tại đây. Ngay sau đó, anh đã chi khoảng 10.000USD để mua chiếc xe tải cũ sản xuất năm 2006, nhãn hiệu Ford cỡ nhỏ. Chiếc xe này đã chạy được hơn 252.000km nhưng vẫn còn rất tốt đối với Brandon. Thực chất số tiền 10.000USD là số tiền thưởng mà Google đã dành cho Brandon khi anh ký hợp đồng với hãng này.

Chiếc xe tải của Brandon rộng gần 12m2, không quá lớn nhưng đủ để anh đặt 1 chiếc giường, 1 tủ quần áo, 1 giá treo đồ và 1 lồng thú cưng :D. Theo lời anh, trước đó dù được ở trong một căn hộ nhưng anh hoàn toàn không thoải mái và không có cảm giác như ở nhà. Với Brandon đó chẳng khác gì ném tiền qua cửa sổ. Brandon chia sẻ thêm: “Thật khó để biện mình cho hành động ném tiền qua cửa sổ như thế. Về cơ bản, tôi đang lãng phí tiền bạc. Số tiền ấy chẳng để góp vốn cho cái gì hay xây dựng tương lai vì thế tôi không đành lòng tiếp tục thuê căn hộ.”

Tính lương gross sang net chuẩn, trải nghiệm ngay!

Tại San Francisco, số tiền mà chàng trai này phải bỏ ra cho việc mua bảo hiểm xe tải là 121USD/tháng. Bên cạnh đó, hóa đơn tiền điện thoại anh dùng sẽ do Google chi trả. Để tiết kiệm hơn, anh cũng ăn 3 bữa và tắm giặt ngay tại văn phòng. Và đặc biệt, anh không mua thêm bất cứ vật dụng nào liên quan đến điện. Anh chia sẻ: “Tôi không sở hữu bất cứ vật gì dùng đến điện. Chiếc xe tải của tôi có sẵn đèn. Tôi có một chiếc đèn pin để sử dụng vào ban đêm. Ngoài ra, tôi chỉ có một cục pin nhỏ để dự phòng, vài ngày mới sạc một lần trên công ty. Tôi dùng cục pin này để sạc tai nghe và điện thoại di động. Còn laptop của tôi có thể chạy qua đêm sau mỗi lần sạc đầy tại văn phòng.”

Brandon đặt ra mục tiêu là tiết kiệm 90% thu nhập sau khi đã trừ các khoản thuế. Anh sẽ dùng số tiền đó để trả nợ đã vay từ thời còn sinh viên và đầu tư cho các kế hoạch của riêng mình. Anh cũng tiết lộ rằng anh đã vay số tiền 22.434USD để trang trải cho việc học đại học và với việc tiết kiệm triệt để trong vòng 4 tháng, anh đã trả được 16.449USD và theo như các tính toàn của anh, tất cả số tiền anh đã vay sẽ được hoàn trả trong vòng 6 tháng tới. Trong 10 đến 20 năm nữa, anh sẽ có trong tay hàng trăm ngàn USD với chính sách thắt chặt chi tiêu như hiện nay.

Chia sẻ thêm về cuộc sống của Brandon: anh luôn là người có mặt sớm nhất công ty bởi mỗi sáng sớm anh chỉ tốn vài bước chân đi bộ từ oto đến nơi làm việc trong khi đồng nghiệp của anh phải chờ hàng giờ trên tàu điện hoặc chết đứng trong đám kẹt xe. Anh nghĩ anh vẫn còn trẻ và lựa chọn cuộc sống như vậy tuy có hơi kì cục nhưng cũng chẳng ảnh hưởng đến ai.

Nhận xét của Smartjob:

Brandon là một chàng trai thực sự giỏi dù có hơi “dị”. Từ khi học đại học cho đến khi thi tuyển và làm việc tại Google anh hoàn toàn biết cách “quản trị cuộc đời” mình. Việc vay tiền, đi học, học thật giỏi, thi vào Google tất cả đã nằm trong tính toán của anh. Với cuộc sống đắt đỏ tại San Francisco, với khoản nợ khá lớn như thế, tiết kiệm là cách tốt nhất giúp anh rút ngắn thời gian để thực hiện những ước mơ của mình. Các bạn có thể cười chê chàng trai này, cho rằng anh ấy mặt dày, hà tiện,… nhưng theo Smartjob, Brandon là người đáng để học hỏi. Ngay cả Google cũng tôn trọng cách sống của anh thì chúng ta chẳng có lý do gì để cười nhạo một người như thế. Mỗi ước mơ khi đã thành hiện thực đều có những sự đánh đổi và Brandon đã lựa chọn cách đánh đổi như thế.

Phạm Bình (Theo Business Insider)

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

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

Truy cập ngay việc làm IT đãi ngộ tốt trên TopDev

Database migration sử dụng Liquibase với Spring MVC

Bài viết được sự cho phép của tác giả Nguyễn Hữu Khanh

Trong bài viết trước, mình đã giới thiệu với các bạn về Liquibase, một thư viện giúp chúng ta hiện thực việc database migration cho một ứng dụng Java bất kỳ. Trong bài viết này, mình sẽ hướng dẫn các bạn hiện thực database migration sử dụng Liquibase với Spring MVC các bạn nhé!

Chạy database migration khi deploy, nên hay không?

Migrate từ hệ thống monolithic sang microservice - part 2

Đầu tiên, mình sẽ tạo mới một Spring MVC project sử dụng Spring Tool Suite 3 để làm ví dụ.

Kết quả:

Mình sẽ sử dụng Maven Jetty Plugin để chạy project này.

<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.4.40.v20210413</version>
<configuration>
<webApp>
<contextPath>/springmvc-liquibase</contextPath>
</webApp>
</configuration>
</plugin>

Kết quả khi mình chạy project này sẽ như sau:

Để làm việc với Liquibase, các bạn cần khai báo dependency của nó:

<dependency>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-core</artifactId>
<version>4.3.4</version>
</dependency>

Để làm việc với database trong Spring, chúng ta cần thêm spring-orm dependency:

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<version>${org.springframework-version}</version>
</dependency>

Mình sẽ sử dụng PostgreSQL database trong ví dụ này:

<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>42.2.20</version>
</dependency>

Mặc định, Liquibase đã hỗ trợ việc integrate với Spring framework. Bằng cách khai báo bean của class SpringLiquibase trong Spring container, khi chạy ứng dụng có sử dụng Spring framwork lên, Liquibase sẽ tự động thực hiện việc database migration cho chúng ta các bạn nhé!

Các bạn có thể cấu hình bean của class SpringLiquibase trong Spring container sử dụng XML configuration (trong tập tin /src/main/webapp/WEB-INF/spring/root-context.xml) như sau:

<bean id="springLiquibase" class="liquibase.integration.spring.SpringLiquibase">
<property name="dataSource" ref="dataSource" />
<property name="changeLog" value="classpath:db-changelog.xml" />
</bean>

Nhiệm vụ của chúng ta là chỉ cần cấu hình bean cho phần dataSource và changeLog mà thôi!

Mình sẽ cấu hình dataSource cho database PostgreSQL trong Spring container (trong tập tin /src/main/webapp/WEB-INF/spring/root-context.xml) như sau:

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="org.postgresql.Driver" />
<property name="url" value="jdbc:postgresql://localhost:5432/liquibase_example" />
<property name="username" value="khanh" />
<property name="password" value="1" />
</bean>

Việc cấu hình dataSource mình sẽ không đề cập chi tiết ở đây. Các bạn có thể đọc thêm bài viết này https://huongdanjava.com/vi/jpa-va-spring-framework.html các bạn nhé!

Từ value của changeLog trong cấu hình của SpringLiquibase ở trên, các bạn có thể hiểu là mình cần tạo tập tin changelog của Liquibase db-changelog.xml trong thư mục src/main/resources.

Mình sẽ định nghĩa nội dung tập tin changelog để thêm bảng clazz như sau:

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.0.xsd">

<changeSet id="1" author="khanh">
<createTable tableName="clazz">
<column name="id" type="BIGINT" autoIncrement="true">
<constraints primaryKey="true" nullable="false" />
</column>
<column name="name" type="VARCHAR(50)" />
</createTable>
</changeSet>
</databaseChangeLog>

Bây giờ, chạy lại ứng dụng, kiểm tra database, các bạn sẽ thấy kết quả như sau:

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

Việc làm mvc

Việc làm database

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

React Router Cheatsheet và mọi thứ bạn cần biết (Phần 2)

Tác giả: Reed Barger

Thành phần liên kết

Giả sử với NavBar, chúng tôi muốn tạo một số liên kết để có thể di chuyển xung quanh ứng dụng của mình dễ dàng hơn thay vì phải thay đổi URL theo cách thủ công trong trình duyệt.

Chúng ta có thể làm như vậy với một thành phần đặc biệt khác từ React Router DOM là Link component. Nó chấp nhận prop to, chỉ định nơi muốn liên kết điều hướng người dùng đến. Trong trường hợp này có thể có một liên kết về:

import { BrowserRouter as Router, Switch, Route, Link } from "react-router-dom";

export default function App() {
  return (
    <Router>
      <Navbar />
      <Switch>
        <Route path="/" component={Home} />
        <Route path="/about" component={About} />
      </Switch>
    </Router>
  );
}

function Navbar() {
  return (
    <nav>
      <Link to="/">Home</Link>
      <Link to="/about">About</Link>
    </nav>
  )
}

Thành phần liên kết cho phép cung cấp một số inline styles giống như bất kỳ thành phần React tiêu chuẩn nào. Nó cũng cung cấp một prop component hữu ích, vì vậy chúng tôi có thể đặt liên kết của mình làm thành phần tùy chỉnh riêng để tạo kiểu dễ dàng hơn.

Tìm việc làm React lương cao up to 2000USD

NavLink Component

Ngoài ra, React Router DOM cũng cung cấp NavLink Component rất hữu ích trong trường hợp muốn áp dụng một số kiểu đặc biệt.

Nếu bạn đang ở trên đường dẫn mà liên kết trỏ đến, điều này cho phép tạo một số kiểu liên kết hoạt động để cho người dùng biết, bằng cách xem liên kết đang ở trang nào.

Ví dụ, nếu người dùng đang ở trên trang chủ, chúng tôi có thể cho họ biết càng nhiều bằng cách sử dụng phần mềm activeStyle hỗ trợ để làm cho liên kết được in đậm và có màu đỏ khi họ ở trên trang chủ:

import {
  BrowserRouter as Router,
  Switch,
  Route,
  NavLink
} from "react-router-dom";

export default function App() {
  return (
    <Router>
      <Navbar />
      <Switch>
        <Route path="/" component={Home} />
        <Route path="/about" component={About} />
      </Switch>
    </Router>
  );
}

function Navbar() {
  return (
    <nav>
      <NavLink
        activeStyle={{
          fontWeight: "bold",
          color: "red"
        }}
        to="/"
      >
        Home
      </NavLink>
      <NavLink activeClassName="active" to="/about">
        About
      </NavLink>
    </nav>
  );
}

Ngoài ra còn có prop activeClassName có thể được thiết lập nếu bạn không muốn bao gồm các inline styles hoặc muốn nhiều kiểu có thể tái sử dụng hơn để thực hiện cùng một chức năng activeStyle.

Bỏ túi cheatsheet dành cho Python newbie

React Props Cheatsheet: 10 Patterns mà bạn nên biết (Phần 1)

Thành phần chuyển hướng

Một thành phần rất hữu ích khác mà React Router DOM cung cấp là thành phần chuyển hướng. Điều này có vẻ lạ khi có một thành phần thực hiện chức năng chuyển hướng người dùng khi nó được hiển thị, nhưng lại rất hữu ích.

Bất cứ khi nào bạn sử dụng một cái gì đó như một private route và có điều kiện trong đó người dùng không được xác thực, bạn có thể chuyển hướng họ trở lại trang đăng nhập.

Dưới đây là một ví dụ về việc triển khai các thành phần về private route đảm bảo rằng người dùng được xác thực trước khi nó hiển thị cho họ một route cụ thể đã được khai báo với thành phần này.

Ngược lại, nếu chúng không được xác thực, chúng sẽ được chuyển hướng đến một public route (có thể là một route để đăng nhập) khi thành phần chuyển hướng được hiển thị:

import {
  BrowserRouter as Router,
  Switch,
  Route,
  Redirect
} from "react-router-dom";

export default function App() {
  return (
    <Router>
      <Switch>
        <Route exact path="/" component={Home} />
        <PrivateRoute path="/hidden" component={Hidden} />
      </Switch>
    </Router>
  );
}

function PrivateRoute({ component: Component, ...rest }) {
  // useAuth is some custom hook to get the current user's auth state
  const isAuth = useAuth();

  return (
    <Route
      {...rest}
      render={(props) =>
        isAuth ? <Component {...props} /> : <Redirect to="/" />
      }
    />
  );
}

function Home() {
  return <>home</>;
}

function Hidden() {
  return <>hidden</>;
}

useHistory Hook

Trên tất cả các thành phần đầy chất lượng này, có một số hook rất hữu ích mà React Router DOM cung cấp thêm cho chúng ta.

Chúng chủ yếu hữu ích bằng cách cung cấp thông tin bổ sung mà bạn có thể sử dụng trong các thành phần của mình. Chúng có thể được gọi là các React hook bình thường mà chúng ta có thể sử dụng các giá trị của chúng một cách chính xác theo ý muốn.

Bỏ túi Cheatsheet React cho năm 2023 (kèm ví dụ thực tế)

Có lẽ một trong những hook hữu dụng nhất chính là useHistory hook. Có thể sử dụng nó ở đầu bất kỳ thành phần nào được khai báo trong thành phần bộ định tuyến của chúng tôi và lấy lại các dữ liệu history, bao gồm thông tin như vị trí được liên kết với thành phần chẳng hạn.

Điều này cho chúng ta biết tất cả về vị trí hiện tại của người dùng, chẳng hạn như tên đường dẫn mà họ đang truy cập, cũng như bất kỳ tham số truy vấn nào có thể được thêm vào URL của chúng tôi. Tất cả dữ liệu vị trí đều có thể truy cập được từ history.location:

import { useHistory } from "react-router-dom";


function About() {
  const history = useHistory();
    
  console.log(history.location.pathname); // '/about'

  return (
    <>
     <h1>The about page is on: {history.location.pathname}</h1>
    </>
  );
}

Ngoài ra, các thông tin lịch sử trực tiếp bao gồm các phương pháp hữu ích cho phép hướng người dùng theo chương trình đến các trang khác nhau trong ứng dụng của bạn.

Điều này rất hữu ích, ví dụ, để chuyển hướng người dùng sau khi đăng nhập hoặc trong bất kỳ tình huống nào mà cần phải đưa người dùng từ trang này sang trang khác.

Chúng tôi có thể đẩy người dùng từ trang này sang trang khác bằng cách sử dụng history.push. Khi sử dụng phương pháp đẩy, bạn chỉ cần cung cấp đường dẫn mà chúng tôi muốn đưa người dùng của mình đến bằng cách sử dụng phương pháp này. Nó thêm trang mới này vào stack về lịch sử:

import { useHistory } from "react-router-dom";


function About() {
  const history = useHistory();
    
  console.log(history.location.pathname); // '/about'

  return (
    <>
     <h1>The about page is on: {history.location.pathname}</h1>
     <button onClick={() => history.push('/')}>Go to home page</button>
    </>
  );
}

Cũng có thể chuyển hướng người dùng bằng history.replace, giá trị này cũng chấp nhận giá trị đường dẫn, nhưng xóa mọi thứ trong lịch sử, sau khi điều hướng được thực hiện. Điều này rất hữu ích cho những trường hợp không cần quay lại lịch sử, chẳng hạn như sau khi người dùng đã đăng xuất.

useLocation Hook

Các useLocation hook bao gồm tất cả các thông tin tương tự mà useHistory hook làm.

Điều quan trọng cần lưu ý là nếu bạn cần cả dữ liệu vị trí và sử dụng lịch sử để điều hướng người dùng của mình theo chương trình, hãy đảm bảo sử dụng History. Tuy nhiên, nếu bạn chỉ muốn dữ liệu vị trí, tất cả những gì bạn cần làm là sử dụng useLocation hoặc lấy lại tất cả dữ liệu vị trí trên một đối tượng giống với dữ liệu được cung cấp trên history. location:

import { useLocation } from "react-router-dom";


function About() {
  const location = useLocation();
    
  console.log(location.pathname); // '/about'

  return (
    <>
     <h1>The about page is on: {location.pathname}</h1>
    </>
  );
}

useParams Hook + Dynamic Routes

Một điều mà chúng tôi không đề cập đến khi nói đến các routes là chúng tôi có thể tạo ra các dynamic routes một cách tự nhiên. Điều này có nghĩa là các tuyến không cố định và được xác định, nhưng có thể là bất kỳ số ký tự nào.

Các dynamic routes rất hữu ích trong các tình huống mà chúng tôi có, chẳng hạn như một bài đăng trên blog với một slug duy nhất. Làm cách nào để đảm bảo rằng chúng tôi hiển thị dữ liệu và các thành phần một cách thích hợp, vì slug bài đăng trên blog của chúng tôi có thể hoàn toàn khác?

Để khai báo một tham số route trên một route nhất định, nó phải được đặt trước bằng dấu hai chấm :. Nếu muốn tạo một dynamic route, “/ blog /: postSlug”, cho một thành phần bài đăng trên blog, nó có thể giống như sau:

import React from "react";
import { BrowserRouter as Router, Switch, Route } from "react-router-dom";

export default function App() {
  return (
    <Router>
      <Switch>
        <Route exact path="/" component={Home} />
        <Route path="/blog/:postSlug" component={BlogPost} />
      </Switch>
    </Router>
  );
}

function Home() {
  return <>home</>;
}

function BlogPost() {
  return <>blog post</>;
}

Nhưng trong thành phần BlogPost, làm cách nào để nhận được dữ liệu slug của bài đăng đó? Chúng ta có thể truy cập bất kỳ thông số tuyến nào của một tuyến đã khai báo với thành phần liên kết của nó bằng cách sử dụng useParams hook.

useParams sẽ trả về một đối tượng sẽ chứa các thuộc tính phù hợp với các tham số tuyến của chúng ta (trong trường hợp này là postSlug). Chúng ta có thể sử dụng cấu trúc đối tượng để truy cập ngay lập tức và khai báo dưới dạng một biến với tên postSlug:

import React from "react";
import { BrowserRouter as Router, Switch, Route, useParams } from "react-router-dom";

export default function App() {
  return (
    <Router>
      <Switch>
        <Route exact path="/" component={Home} />
        <Route path="/blog/:postSlug" component={BlogPost} />
      </Switch>
    </Router>
  );
}

function Home() {
  return <>home</>;
}

function BlogPost() {
  const [post, setPost] = React.useState(null);
  const { postSlug } = useParams();

  React.useEffect(() => {
    fetch(`https://jsonplaceholder.typicode.com/posts/${postSlug}`)
      .then((res) => res.json())
      .then((data) => setPost(data));
  }, [postSlug]);

  if (!post) return null;

  return (
    <>
      <h1>{post.title}</h1>
      <p>{post.description}</p>
    </>
  );
}

useRouteMatch Hook

Nếu muốn biết liệu thành phần đã cho có nằm trên một trang nhất định hay không, chúng ta có thể sử dụng useRouteMatch hook.

Ví dụ: trong bài đăng trên blog, để xem liệu trang chúng tôi đang truy cập có khớp với tuyến đường “/ blog /: postSlug” hay không, chúng tôi có thể lấy lại giá trị boolean sẽ cho chúng tôi biết liệu tuyến đường mà chúng tôi đang truy cập có khớp với mà chúng tôi đã chỉ định:

import { useRouteMatch } from "react-router-dom";

function BlogPost() {
  const isBlogPostRoute = useRouteMatch("/blog/:postSlug");
 
  // display, hide content, or do something else
}

Phỏng dịch theo bài viết gốc tại freecodecamp.org

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

Xem thêm tuyển dụng it hấp dẫn trên TopDev

Lập trình IOS: Triển khai MVVM cho prject swift (phần 1)

Bài viết được sự cho phép của tác giả Lê Xuân Quỳnh

Hôm nay chúng ta sẽ làm 1 ứng dụng nho nhỏ, hiển thị danh sách các loại động vật, như hình ảnh:

Đầu tiên là tải source code của tôi tại đây:

https://github.com/codetoanbug/MVVMSample

Tôi hướng dẫn các bạn tải code về bằng git 1 xíu nhé. Là git command line nha các bạn.

Rx-MVVM(1): Cấu trúc project – lib manager

Rx-MVVM(2): Cấu trúc project – quản lý thư viện sử dụng trong dự án

Đầu tiên là bạn mở terminal và gõ:

git clone https://github.com/codetoanbug/MVVMSample.git

Sau đó bạn cd vào thư mục code MVVMSample. Mẹo là gõ cd MV, nhấn nút tab trên bàn phím nó cũng ra lệnh như sau:

cd MVVMSample

Tiếp theo gõ để show toàn bộ branch:

git branch -a

Bạn sẽ thấy branch master, bai1… Mỗi branch sẽ chứa code của 1 bài. Ở đây ta chỉ quan tâm code bài 1 nên bạn cần chuyển qua code của bài 1 bằng cách gõ như sau:

git checkout bai1

Như vậy là bạn đã có code của bài hôm nay rồi đấy. Đơn giản đúng không?

Để triển khai mô hình MVVM, chúng ta cần nắm qua mô hình này xem nó hoạt động như thế nào.

Hãy tiếp cận 1 cách đơn giản nhất nhé. Mặc định khi bạn tạo 1 project thì Xcode nó tự render các file theo tiêu chuẩn MVC của họ. M là Model, V là View, còn C là Controller. Tuy nhiên, ở đây chúng ta sẽ hay xử lý logic để lấy dữ liệu cho view và hiển thị view chung vào ViewController.

Nếu tiếp cận cách đơn thuần như thế, thì cái table của bạn muốn có dữ liệu thì bạn phải tạo được data cho nó ở trong ViewController luôn. Rồi ngày qua ngày, cái table view này nó thêm nhiều tính năng mới. Ví dụ như khi chạm vào từng cell trên table thì phải kiểm tra xem cell đó là con gì, mở màn hình detail tương ứng. Hoặc trong cái view controller của bạn sếp yêu cầu phải lấy data từ trên server về thay vì tạo data set cứng trong nó. Bạn phải xử lý khi có data thì hiển thị như nào, khi không có data thì hiển thị như nào. Rồi một ngày đẹp trời nữa sếp bạn yêu cầu tao muốn hiển thị nhiều loại cell khác nhau, mỗi loại cell 1 loại data khác nhau… Code cứ dài càng dài, và càng khó chỉnh sửa sau này.

Vấn đề của MVC ở đây là xử lý hết logic trong View, thì code nhiều. Mà nhiều thì khó đọc, cáu, chửi thề, và cuối cùng là đấm sếp rồi nghỉ việc

Có rất nhiều developer đã căng thẳng như thế, tóc bạc đi nhiều sau nhiều năm code MVC thuần. Rồi họ bắt đầu bực bội và muốn thay đổi điều gì đó để cho công việc đơn giản hơn. Họ nghĩ ngay “tại sao không đưa các xử lý logic về data sang 1 file khác, còn view chỉ đơn thuần là find data vào thôi?” Và rồi họ quyết định làm điều đó. Ra ban công làm khói, ngắm hàng xóm và tiếp tục đọc nhé.

Thành phần mới này họ đặt tên là View Model – nghĩa là nó giao thông qua lại giữa view và model. Cái tên rất sát nghĩa đúng không?

Thôi nói lan man. Ở đây tôi sẽ trình bày cách triển khai từng phần 1 cho dễ hiểu nha.

Đầu tiên bạn tạo mới 1 project bằng Xcode, đặt tên nó là gì cũng được. Vào file Main.storyboard và kéo thả 1 cái tableview, 1 cái title như hình:

Bước tiếp theo bạn tạo mới 1 file AnimalViewController kế thừa từ UIViewController, chọn nó quản lý cái file giao diện bạn vừa làm. Tiến hành kéo thả các liên kết từ view vào UIViewController này.

Giả sử tôi kéo thả tableview và được code như sau:

 @IBOutlet weak var tableView: UITableView!

Chưa xong, đã có tableview rồi thì phải tạo cell cho nó. Vậy bạn hãy tạo 1 cái lớp MyTableViewCell kế thừa từ UITableViewCell. Và lại kéo thả! Việc nhẹ lương cao nhỉ

Hình nó như này:

Nhớ auto layout cho nó nhé. Không biết auto layout thì tôi đấm luôn. Chú ý cái khoanh đỏ tôi lười nên hay lấy cái identifier này trùng với tên class cell. Để cho dễ nhớ và copy cho tiện. Mục đích của nó là sau tái sử dụng.

Code như sau:

@IBOutlet weak var titleLabel: UILabel!
@IBOutlet weak var animalImageView: UIImageView!

Rồi, và bây giờ để code clean thì bạn tạo cho tôi 1 cái hàm ở AnimalViewController có nội dung như sau:

/// Init table view
    private func initTableView() {
        tableView.register(UINib(nibName: "MyTableViewCell", bundle: nil), forCellReuseIdentifier: "MyTableViewCell")
        tableView.delegate = self
        tableView.dataSource = self
    }

Rất basic, ở đây nó có ý nghĩa là table đăng ký cell để tí dùng. Kế thừa các hàm delegate và datasource. Những công việc mà newbie nào cũng cần biết nhỉ. Sau đó ném cái hàm vào trong hàm viewDidLoad nhé. Vẫn chưa thấy view model đâu. Bây giờ là chuyên mục chính này.

Đầu tiên là bạn phải tạo cái model để chứa dữ liệu animal của tôi, bao gồm 1 cái tên và 1 cái hình. Tôi tạo code bằng 1 cái struct như sau:


struct Animal {
    let name: String
    let image: String
}

Struct vì nó là giá trị, không có dùng class à nha. Class để giành cho View model.

Rồi, bây giờ ta sẽ nghĩ ngay đến việc là cần 1 cái view model để xử lý các công việc sau:

Tạo datasource cho tableview, chắc chắn phải ném nó vào hàm init của view model
Tạo các hàm trả về cho delegate và datasource của tableview.

Cụ thể bạn tạo file AnimalViewModel và code như sau:

class AnimalViewModel {
    private var animals: [Animal]

    init() {
        animals = []

        // Create data source
        animals.append(Animal(name: "Alligator", image: "Alligator"))
        animals.append(Animal(name: "Anteater", image: "Anteater"))
        animals.append(Animal(name: "Armadillo", image: "Armadillo"))
    }

    func numberOfRowsInSection(section: Int) -> Int {
        return animals.count
    }

    func cellForRowAt(indexPath: IndexPath) -> Animal {
        return animals[indexPath.row]
    }
}

Code thì dài dòng, nhưng để đơn giản thì tôi tạo data ở local, bài sau tôi sẽ hướng dẫn lấy data từ đâu đó trên mạng nha. Các công việc như sau:

Hàm init sẽ tạo datasource cho tableview
Hàm numberOfRowsInSection tôi đặt giống hàm của table datasource, mục đích trả số row trên 1 section
Hàm cellForRowAt cũng vậy, mục đích là để bind data cho cell nhá

Và quay lại file AnimalViewController, bạn viết thêm cho tôi dòng này:

var animalViewModel: AnimalViewModel!

Khi tạo xong view model rồi, thì bạn phải ném nó vào view controller. Sau đó, lại để cho code clean, bạn tạo 1 hàm xử lý view model cho nó. Code như sau:

private func bindViewModel() {
        animalViewModel = AnimalViewModel()
    }

Ở trên chỉ độc 1 dòng code là tạo view model. Tuy nhiên các dự án thực tế nó có nhiều setting khác, như các closure của view model. Nhưng khoan quan tâm, tôi sẽ trình bày ở các bài sau nhé.

Và bây giờ là cần xử lý cho table view, bạn viết đoạn code sau:

extension AnimalViewController: UITableViewDataSource, UITableViewDelegate {
    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return animalViewModel.numberOfRowsInSection(section: section)
    }

    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(withIdentifier: "MyTableViewCell") as! MyTableViewCell
        cell.bindData(animal: animalViewModel.cellForRowAt(indexPath: indexPath))
        return cell
    }

    func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
        return 80
    }
}

Đoạn code trên khá sạch sẽ, view controller sẽ lấy data thông qua view model, và bạn méo cần quan tâm trong đó có gì, chỉ cần view model mày trả data cho tao là được. Do vậy, view controller đã không phải xử lý các logic xử lý model nữa. Khỏe hẳn ra, cứ như là lấy vợ về có người nấu cơm cho ăn ấy.

Tuy nhiên, ở ví dụ này tôi có 1 loạt bức ảnh màu trắng, bạn có thể xem trong mục Assets như hình:

Do vậy để cho ứng dụng màu mè thì tôi viết thêm các extension tạo màu từ ảnh trắng này. Các bạn vào file Extensions để xem.

Trong UIImageView+Extensions tôi có code:

extension UIImageView {
  func setImageColor(color: UIColor) {
    let templateImage = self.image?.withRenderingMode(.alwaysTemplate)
    self.image = templateImage
    self.tintColor = color
  }
}

Đoạn này là tạo màu cho ảnh.

Trong UIColor+Extensions, là tạo màu random cho ảnh nó khác màu nhau nhá:

extension UIColor {
    static func random() -> UIColor {
        return UIColor(
           red:   .random(),
           green: .random(),
           blue:  .random(),
           alpha: 1.0
        )
    }
}

Ok, vậy là cơ bản đã xong rồi đó. Trong bài tiếp theo tôi sẽ làm thêm về phần request lên server nhé.

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

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

Xem thêm Việc làm ios hấp dẫn trên TopDev

Tuyển dụng swift lương cao cho bạn

5 Ngộ nhận về nghề BrSE

Bài viết được sự cho phép của tác giả Nguyễn Văn Trọng

Dạo này có nhiều bạn hay hỏi han mình về 1 số kinh nghiệm trong nghề, hầu hết đều là các bạn trẻ đang học đại học hoặc ra trường 1 vài năm nhưng chưa xác định hướng đi rõ ràng. Khi nói chuyện thì mình phát hiện ra là còn nhiều ngộ nhận về nghề này nên mình mạo muội kể ra 5 điểm cho anh chị em tham khảo. Thiệt sự còn nhiều điều các bạn trẻ chưa hình dung hết trong con đường phía trước nhưng mà mình cực kỳ vui khi biết nhiều thanh niên thanh nữ đang rất máu lửa dấn thân vào nghề “code dạo cầu vinh”, và mình cảm nhận được sự cố gắng của các bạn từng ngày, ham học ham làm chứ không ham chơi như mình hồi xưa

Kinh Nghiệm Phỏng Vấn BrSE

Những kỹ năng cần có của 1 BrSE

1. BrSE Chỉ Làm Việc Communication (Làm Cầu Nối Liên Lạc)

Thực tế kết nối thông tin chỉ là 1 phần trong chuỗi công việc hàng ngày mà BrSE phải đảm nhận. Ngoài việc truyền đạt yêu cầu khách hàng cho team offshore/onsite cũng còn rất nhiều task thú vị khác như đi xin lỗi … giỡn chứ cũng ngồi mày mò code với tìm hiểu công nghệ, support kỹ thuật…

2. BrSE Không Cần Giỏi Công Nghệ

Có nhiều bạn thắc mắc rằng “code không cứng có làm được BrSE không ? “, giờ mình hỏi lại “không cao to đẹp trai, không dẻo miệng có cưa được gấu không ? “, thực tế các bạn thấy mấy cu cậu xấu hoắc mà gấu xinh như tiên thường có 1 thế mạnh đặc biệt khác như có oto hay SH chẳng hạn :D. Câu trả lời là vẫn OK nhưng phải có cái yếu tố khác cực mạnh để bù vào, như tiếng nhật lưu loát chẳng hạn. Nếu đem so sánh BrSE vs FA về 3 khía cạnh thì nó sẽ tương đương như sau :

Đẹp trai, cao to = code cứng
Dẻo mỏ = kỹ năng mềm tốt
Đô la thần chưởng = JP thần chưởng

Vậy nên nếu muốn cưa đổ gái ngon thì phải làm gì các bạn biết rồi. Tương tự như vậy, không cần giỏi code cũng làm được Br nhưng mà đối tượng khách hàng sẽ bị thu hẹp lại, chỉ tán được khách hàng dễ, chứ gặp khách to vs khó tính cũng mệt. May mắn cho anh em là “cao to đẹp trai” do bẩm sinh – khó cải thiện còn code cứng dễ ợt, làm nhiều học nhiều đọc nhiều tự khắc lên thôi.

3. Cứ Qua Nhật Onsite Là Thành BrSE

Cái này không hề đúng nhé, đó chỉ đơn thuần là SE thôi. Ở đây mình không có ý so sánh BrSE vs SE cái nào cao hơn, vì có những SE làm trong dự án khủng khách hàng to, được giao các task khó mà ngay cả những chuyên gia Nhật không dám nhận, ở Nhật hiện tại có rất nhiều SE khủng như vậy, có điều họ không muốn lên tiếng thôi 1 mặt họ quá bận, 1 mặt khác là những tập đoàn lớn sercurity rất chặt nên các anh không được phép chia sẻ thông tin.

4. Không Có Tiếng Nhật Thì Sẽ Không Được Đi Nhật

Cái này cũng không đúng luôn nhé, Có những team mấy chục người nhưng chỉ cần 1 vài người cầu nối còn lại các anh em khác chỉ việc rung đùi ngồi vọc code vs tìm hiểu công nghệ mới thôi. Lý do là đặc thù dự án ưu tiên kỹ năng lập trình chứ không cần các yếu tố khác vì đã có BrSE lead lo hết rồi. Hoặc cũng có 1 số công ty Nhật nhưng mà Global, toàn dùng tiếng anh trong mail – tài liệu – họp … nên 1 số BrSE chỉ cần tiếng Anh lưu loát là có thể sang làm Bridge hoặc SE được. Đợt trước có mấy anh bạn JP bẻ đôi không biết, tình cờ thấy Rakuten tuyển SE chỉ cần tiếng anh, apply thử. Kết quả là giờ mang cả gia đình qua Nhật định cư luôn rồi, lương cực khủng, công việc toàn liên quan công nghệ sở trường nên tha hồ vùng vẫy. Các bạn muốn đi Nhật nhưng ghét tiếng Nhật có thể chọn khe cửa hẹp này để lách sang.

5. BrSE Là Việc Dành Cho Con Trai

Lại bậy nữa, tuy tỉ lệ ít hơn nam nhưng BrSE nữ không hiếm, đôi khi còn lợi thế hơn trong việc thuyết phục khách hàng (mỹ nhân kế). Mình đã từng gặp nhiều chị em trong nghề này, đa số đều là những người thành công, có người code cứng – có người không nhưng tựu chung lại là hầu hết đều giỏi JP và giỏi kỹ năng mềm. Còn gì tuyệt hơn khi những bống hồng IT làm việc tại Nhật, du ngoạn trên những con đường phủ đầy hoa anh đào trong tà áo dài thướt tha !

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

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

Xem thêm Việc làm Brse Developer hấp dẫn trên TopDev

Sử dụng Lombok để rút gọn code trong Java

Bài viết được sự cho phép của Tạp chí Lập trình

Giới thiệu

Lombok là một thư viện Java giúp sinh các mã getter & setter tự động. Bên cạnh đó còn hỗ trợ sinh các hàm khởi tạo (constructor) với tham số, hoặc không có tham số.

Nếu là lập trình viên Java, chắc hẳn ai cũng biết getter/setter, constructor. Với những lớp mô tả dữ liệu (Entity class), chúng ta thường lặp lại các thao tác tạo mã getter/setter và constructor một cách nhàm chán. Lombok giúp mã ngắn gọn hơn trong những trường hợp này.

Tuyển dụng lập trình viên Java lương cao

Hãy xem ví dụ sau!

Giả sử, chúng ta xây dựng chương trình quản lý danh sách việc cần làm (Todo List). Lớp mô tả dữ liệu Todo sẽ có 2 thuộc tính: title, complete.

public class Todo {

    private String title;
    private boolean complete;
    public Todo() { }

    public Todo(String title, boolean complete) {
        this.title = title;
        this.complete = complete;
    }
    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }
    public boolean isComplete() {
        return complete;
    }

    public void setComplete(boolean complete) {
        this.complete = complete;
    }
}

Nếu sử dụng Lombok, đoạn mã trên có thể được viết lại như sau:

@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
public class Todo {
    private String title;
    private boolean complete;
}

Ở trên sử dụng 4 anotation:
– @Setter để thay thế các phương thức: setTitle, setComplete
– @Getter để thay thế các phương thức: getTitle, isComplete
– @NoAgrsConstructor thay thế phương thức khởi tạo không có tham số Todo()
– @AllArgsConstructor thay thế phương thức khởi tạo có tham số Todo(…)

Nếu muốn gọn hơn nữa, chúng ta có thể viết như sau:

Ở trên sử dụng 4 anotation:
– @Setter để thay thế các phương thức: setTitle, setComplete
– @Getter để thay thế các phương thức: getTitle, isComplete
– @NoAgrsConstructor thay thế phương thức khởi tạo không có tham số Todo()
– @AllArgsConstructor thay thế phương thức khởi tạo có tham số Todo(…)

Nếu muốn gọn hơn nữa, chúng ta có thể viết như sau:

Nếu xây dựng một chương trình có nhều đối tượng dữ liệu cần mô tả thì việc áp dụng Lombok sẽ giảm đi một khối lượng lớn mã đáng kể, tiết kiệm nhiều thời gian và nâng cao hiệu suất công việc. Quả thật hữu ích phải không các bạn?

Nếu muốn tìm hiểu thêm những tính năng khác của Lombok, bạn có thể truy cập link sau: https://projectlombok.org/features/all

Tiếp theo, chúng ta sẽ tìm hiểu cách cài đặt Lombok vào dự án Java.

Các bước cài đặt

Nếu sử dụng Gradle, các bạn có thể thực hiện qua các bước sau:

Bước 1: Bổ sungbuild.gradle

Nếu xây dựng một chương trình có nhều đối tượng dữ liệu cần mô tả thì việc áp dụng Lombok sẽ giảm đi một khối lượng lớn mã đáng kể, tiết kiệm nhiều thời gian và nâng cao hiệu suất công việc. Quả thật hữu ích phải không các bạn?

Nếu muốn tìm hiểu thêm những tính năng khác của Lombok, bạn có thể truy cập link sau: https://projectlombok.org/features/all

Tiếp theo, chúng ta sẽ tìm hiểu cách cài đặt Lombok vào dự án Java.

10 Java Web Framework tốt nhất

10 lý do cho thấy tại sao bạn nên theo học ngôn ngữ lập trình Java

Các bước cài đặt

Nếu sử dụng Gradle, các bạn có thể thực hiện qua các bước sau:

Bước 1: Bổ sungbuild.gradle

compileOnly         'org.projectlombok:lombok:1.18.10'
annotationProcessor 'org.projectlombok:lombok:1.18.10'
testCompileOnly         'org.projectlombok:lombok:1.18.10'
testAnnotationProcessor 'org.projectlombok:lombok:1.18.10'

Bước 2: Cấu hình IDE để có thể xử lý annotation trong Lombok.

Với IntelliJ IDEA, có thể thiết lập bằng cách vào “Settings > Build > Compiler > Annotation Processors”, chọn “Default”, tick chọn “Enable annotaion processing”.

“Enable annotaion processing” trong IntelliJ IDEA

Tham khảo cách cài đặt cho các IDE khác ở link này: https://projectlombok.org/setup/overview

Qua nội dung trên, chúng ta đã biết được tác dụng của Lombok và cách cài đặt để sử dụng. Nếu có góp ý hoặc bổ sung, bạn có thể bình luận trực tiếp trên bài viết này.

Author: Đặng Huy Hòa

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

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

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Database migration sử dụng Liquibase

Bài viết được sự cho phép của tác giả Nguyễn Hữu Khanh

Database migration hay chúng ta còn có thể gọi là version control cho database, là một công việc quản lý thông tin, cấu trúc database theo kiểu versioning. Lấy ví dụ như bạn đang phát triển một ứng dụng quản lý sinh viên có sử dụng database, release đầu tiên của ứng dụng này các bạn cần 2 table để quản lý thông tin là student và clazz, lần release thứ 2 thì chúng ta cần chỉnh sửa thông tin table student hoặc clazz, hoặc có thể là thêm mới table subject để quản lý môn học, … Cho mỗi lần release chúng ta sẽ có một version liên quan đến database structure cho ứng dụng của mình. Để hiện thực nhu cầu này, chúng ta có nhiều cách khác nhau trong Java như sử dụng Flyway hoặc Liquibase, … Trong bài viết này, mình sẽ giới thiệu với các bạn về Liquibase để hiện thực database migration các bạn nhé!

Xem thêm Tuyển dụng database hấp dẫn trên TopDev

Đầu tiên, mình sẽ tạo mới một Maven project để làm ví dụ:

Mình sẽ sử dụng Java 11 cho project này:

<properties>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
</properties>

Để làm việc với Liquibase, các bạn cần khai báo dependency của nó:

<dependency>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-core</artifactId>
<version>4.3.3</version>
</dependency>

Mình cũng sẽ sử dụng PostgreSQL database để làm ví dụ cho bài viết này:

<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>42.2.20</version>
</dependency>

Khi làm việc với Liquibase, các bạn cần nắm 3 khái niệm cơ bản của nó là changelog, changeset và changetype.

Một changelog có thể sẽ chứa nhiều changeset và một changeset có thể chứa nhiều changetype. Nói nôm na cho các bạn hiểu thì changelog là một tập tin này định nghĩa tất cả các version của database structure theo cách của Liquibase để nó có thể execute việc thay đổi database theo version cho chúng ta được. Các bạn có thể định nghĩa tập tin changelog này theo nhiều định dạng khác nhau bao gồm SQL, XML, JSON, YAML, …

Nếu các bạn định nghĩa bằng XML thì nội dung của tập tin changelog sẽ có nội dung cơ bản như sau:

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.3.xsd">

<!-- Define changeset -->

</databaseChangeLog>

Bên trong tag <databaseChangeLog> đại diện cho changelog, chúng ta sẽ định nghĩa các changeset. Các bạn có thể hiểu mỗi changeset là một version của database structure của ứng dụng. Có 2 thuộc tính bắt buộc cho mỗi changeset mà các bạn phải khai báo là id và author.

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.3.xsd">

<!-- Define changeset -->
<changeSet id="1" author="khanh">
<comment>A sample change set 1</comment>
</changeSet>

<changeSet id="2" author="khanh">
<comment>A sample change set 2</comment>
</changeSet>
</databaseChangeLog>

Mỗi changeset sẽ hỗ trợ cho các bạn rất nhiều changetype. Nói nôm na changetype là đại diện cho các câu lệnh SQL để các bạn thực hiện việc thêm, mới, xoá, sửa database structure. Cho changeLog với XML format, các bạn có thể thấy các changetype như sau:

Ví dụ bây giờ mình cần tạo mới table name student với thông tin về tên và tuổi của sinh viên thì mình sẽ định nghĩa changeset với changetype như sau:

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.3.xsd">

<changeSet id="1" author="khanh">
<createTable tableName="student">
<column name="id" type="BIGINT" autoIncrement="true">
<constraints primaryKey="true" nullable="false" />
</column>
<column name="name" type="VARCHAR(200)" />
<column name="age" type="BIGINT" />
</createTable>
</changeSet>
</databaseChangeLog>

Bây giờ, mình sẽ viết code để xem Liquibase hoạt động như thế nào các bạn nhé!

Mình sẽ lưu nội dung changelog ở trên vào tập tin db-changelog.xml trong thư mục src/main/resources của project:

Mình sẽ tạo mới main class để làm ví dụ:

package com.huongdanjava.liquibase;

public class Application {

public static void main(String[] args) {

}

}

Để làm việc với Liquibase, các bạn cần sử dụng đối tượng của class Liquibase. Chúng ta sẽ cần truyền cho đối tượng này connection tới database và đường dẫn tới tập tin cấu hình của changelog. Có 3 constructor trong class Liquibase cho phép chúng ta truyền các thông tin này.

Mình sử dụng một trong 3 constructor này như sau:

package com.huongdanjava.liquibase;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import liquibase.Liquibase;
import liquibase.database.Database;
import liquibase.database.DatabaseFactory;
import liquibase.database.jvm.JdbcConnection;
import liquibase.exception.LiquibaseException;
import liquibase.resource.ClassLoaderResourceAccessor;

public class Application {

public static void main(String[] args) throws SQLException, LiquibaseException {
Connection c = DriverManager.getConnection("jdbc:postgresql://localhost:5432/liquibase_example",
"postgres", "123456");

Database database = DatabaseFactory.getInstance()
.findCorrectDatabaseImplementation(new JdbcConnection(c));

Liquibase liquibase = new Liquibase("classpath:db-changelog.xml", new ClassLoaderResourceAccessor(), database);
}

}

Tham số thứ 2 trong constructor của Liquibase trong ví dụ trên chỉ định cách mà Liquibase sẽ đọc tập tin cấu hình changelog. Nó implement interface ResourceAccessor của Liquibase đó các bạn!

Các bạn sử dụng cách nào cũng được tùy theo project của mình nhé.

Sau khi đã có đối tượng Liquibase thì các bạn có thể gọi method update() với một tham số mang ý nghĩa Context mà chúng ta đang chạy database migration. Các bạn có thể để empty hoặc null cũng được nếu muốn. Mình sẽ để empty:

package com.huongdanjava.liquibase;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import liquibase.Liquibase;
import liquibase.database.Database;
import liquibase.database.DatabaseFactory;
import liquibase.database.jvm.JdbcConnection;
import liquibase.exception.LiquibaseException;
import liquibase.resource.ClassLoaderResourceAccessor;

public class Application {

public static void main(String[] args) throws SQLException, LiquibaseException {
Connection c = DriverManager.getConnection("jdbc:postgresql://localhost:5432/liquibase_example",
"postgres", "123456");

Database database = DatabaseFactory.getInstance()
.findCorrectDatabaseImplementation(new JdbcConnection(c));

Liquibase liquibase = new Liquibase("classpath:db-changelog.xml", new ClassLoaderResourceAccessor(), database);

liquibase.update("");
}

}

OK, giờ thì chạy ứng dụng thôi các bạn.

Để kiểm tra kết quả, các bạn hãy vào database của mình. Các bạn sẽ thấy Liquibase tạo ra 3 bảng trong ví dụ trên của mình:

Ngoài bảng student với cấu trúc database mà chúng ta đã định nghĩa trong changeset:

như các bạn thấy, chúng ta còn có thêm 2 bảng là databasechangelog và databasechangeloglock.

Mục đích của bảng databasechangelog là keep track lại tất cả các changeset mà Liquibase đã chạy. Nếu các bạn query table này, các bạn sẽ thấy kết quả như sau:

Thứ tự execute cho mỗi changeset sẽ phụ thuộc vào việc các bạn định nghĩa changeset đó trước hay sau trong tập tin db-changelog.xml các bạn nhé! Id của mỗi changeset cùng với author và filename chỉ để cho Liquibase biết là nó đã execute changeset đó chưa dựa vào bảng databasechangelog này.

26 công cụ và kỹ thuật trong Big Data có thể bạn chưa biết

Cấu hình đồng bộ hai database mysql server MySQL Replication

Bảng databasechangeloglock chỉ để cho Liquibase make sure là chỉ có một tiến trình thực hiện việc database migration được thực hiện tại cùng một thời điểm thôi các bạn nhé!

Bây giờ, nếu mình thêm một changeset mới để thêm column address trong bảng student:

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.0.xsd">

<changeSet id="1" author="khanh">
<createTable tableName="student">
<column name="id" type="BIGINT" autoIncrement="true">
<constraints primaryKey="true" nullable="false" />
</column>
<column name="name" type="VARCHAR(200)" />
<column name="age" type="BIGINT" />
</createTable>
</changeSet>
<changeSet id="2" author="khanh">
<addColumn tableName="student">
<column name="address" type="VARCHAR(200)" />
</addColumn>
</changeSet>
</databaseChangeLog>

thì các bạn sẽ thấy kết quả như sau:

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

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

Sự khác biệt giữa ‘git merge’ và ‘git rebase’ là gì?

Bài viết được sự cho phép của tác giả Lê Chí Dũng

Trong bài này sẽ nói về sự khác biệt của rebase và merge để dễ hiểu vấn đề hãy xem ví dụ bên dưới.

Giả sử ban đầu đã có 3 commit A, B, C:

sau đó developer Dung tạo commit D, và developer Egg tạo commit E:

rõ ràng, cuộc xung đột này nên được giải quyết bằng cách nào đó. Đối với điều này, có 2 cách:

[Update] 43 kho lưu trữ Github JS phổ biến nhất 2024 - Bạn đã biết hết chưa?

5 tip về GitHub cho lập trình viên

MERGE :

Cả hai commit D và E vẫn còn ở đây, nhưng chúng tôi tạo ra phối commit M mà thay đổi thừa hưởng từ cả hai D và E. Tuy nhiên, điều này tạo ra hình dạng kim cương, mà nhiều người thấy rất khó hiểu. Nếu bạn có hàng chục commit D và E thì bạn có có hàng chục viên kim cương M lúc này bạn sẽ thấy log rối đến mức nào!?

REBASE :

Chúng tôi tạo ra commit R, mà nội dung thực tế file là giống hệt nhau của merge commit M ở trên. Tuy nhiên, chúng ta thoát khỏi commit E, giống như nó không bao giờ tồn tại (denoted bằng dấu chấm – vanishing dòng). Điều này sẽ làm cho commit của bạn nhìn dễ hiểu hơn.

Vì obliteration này, E sẽ có local để developer Ed và nên đã không bao giờ được đẩy đến bất kỳ các kho lưu trữ khác. Lợi thế của rebase là kim cương hình dạng tránh được, và lịch sử vẫn đẹp đường thẳng.

Sau đây là một so sánh log của rebase và merge 1 branch trong một mini project:

A) History dùng rebase nhìn clear và dễ dàng tracking do chính bạn tạo ra một cách hệ thống và logic!
B) History dùng merge nhìn khó hiểu và khi tracking bạn sẽ nói gì ngoài bullshit do chính bạn commit và merge vô tội vạ!
C) Transport plan của git, những chổ dùng rebase sẽ thằng hàng còn merge sẽ chỉa qua lại nhìn chung là ảnh hưởng các branch.

Kết Luận:

Chú ý vào rebase, mọi người sẽ thấy commit của rebase nằm phía trên commit mới nhất của master. Còn ở merge, mọi người sẽ thấy commit của master nằm phía trên commit mới nhất của merge, ngoài ra một commit Merge branch cũng được tạo ra.
Ban sử dụng git rebase nếu như bạn muốn các sự thay đổi thuộc về branch của bạn luôn luôn là mới nhất. Và bạn có thể log một cách có hệ thống dễ nhìn, dễ tracking sao này.
Bạn sử dụng git merge nếu bạn muốn sắp xếp các commit theo mặc định. Bạn không biết về những gì mình làm gì trên branch đó thì dùng merge cho đảm bảo việc tracking sao này có thể tốn nhiều thời gian lần mò.

Một số vấn đề cần lưu ý sau:

Git rebase thì nên dùng trên branch riêng, nó sẽ đẩy history commit của branch lên, history commit sẽ tách biệt hẳn với những commit từ branch khác, rất tiện cho quản lý các branch. Đặt biệt khi các bạn có các branch master / develop / hot-fix / features / release …
Cả rebase và merge sẽ conflict kinh khủng hơn nếu không update code thường xuyên chứ không phải chỉ có rebase như mọi người thường nói đâu nhé. Ví dụ: Nếu như master branch có time line hơn branch của bạn 1 tháng . Lúc đó hãy rebase hay merge branch của bạn và sẽ thấy conflict 2 cái có khác gì nhau!
Git merge là làm cho git commit list dài ra áp dụng cho branch riêng thì không phù hợp vì khó trace log vì nhiều commit dài thòn không phải do bạn tạo ra!?. Nhất là trong 1 dự án dài hơi, việc nhìn lại log của vài tháng trước có thể sẽ là vấn đề trong bầu trời đầy sao chổi với bạn.

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

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

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Các đặc điểm của một kỹ sư kiểm thử giỏi (Phần cuối)?

Bài viết được sự cho phép của vntesters.com

Ở phần 1 và phần 2, chúng ta đã điểm qua được phần lớn những đặc điểm của một kỹ sư kiểm thử giỏi. Bài viết đã nhận được nhiều phản hồi tích cực từ cộng đồng kỹ sư kiểm thử phần mềm Việt Nam và đó là động lực để mình hoàn tất loạt bài viết này. Trong phần cuối này, mình sẽ tiếp tục chia sẻ những đặc điểm để giúp chúng ta áp dụng những đặc điểm đã được đề cập trong phần 1 và phần 2 một cách hiệu quả nhất.

5 điều cần lưu ý trước khi bắt đầu kiểm thử di động

7 lãng phí trong kiểm thử phần mềm

13. Sự chuyên tâm

Một kỹ sư kiểm thử giỏi hiểu rằng việc tìm bug cũng như hiểu được bản chất của con bug đòi hỏi sự chuyên tâm nhất định. Một kỹ sư kiểm thử giỏi không bỏ sót một con bug nào tìm thấy dọc đường đi. Tuy nhiên họ sẽ không đào sâu tìm hiểu những con bug đó trước khi con bug chính được làm rõ.

Để không bị chệch hướng, bạn cần phải có một kế hoạch và bám sát vào nó. Trước khi tiến hành một lượt kiểm thử, hãy dành thời gian để lên kế hoạch trong đó xác định được bạn sẽ phân bổ thời gian kiểm thử như thế nào. Và khi tiến hành kế hoạch đó, hãy ghi nhận lại những điều thú vị bạn quan sát được trên đường đi nhưng vẫn chuyên tâm vào kế hoạch đã vạch ra. Khi bạn đã hoàn tất việc ghi nhận lại những vấn đề bạn gặp được trên đường đi, hãy quay lại và bắt đầu lần lượt tìm hiểu từng vấn đề đó. Khi tìm hiểu những vấn đề đó, tiếp tục lặp lại quá trình: ghi nhận những điều mới nhưng đừng xa rời mục tiêu.

Tác giả đã đưa ra lời khuyên nhưng những kỹ sư kiểm thử giỏi không áp dụng nó một cách cứng nhắc – nghĩa là chỉ ghi nhận và rồi đi tiếp. Đôi khi cũng có những điều quan trọng bạn gặp trên đường đi, hãy tập trung đào sâu tìm hiểu nó ngay lập tức thay vì chỉ ghi nhận lại.

[TH]:Trong quá trình nghiên cứu một con bug hay một vấn đề nào đó, chúng ta rất dễ bị “chèo kéo”, “mời gọi” của những vấn đề mới phát sinh và làm chúng ta lạc lối. Một sự lạc lối rất đáng yêu. Tôi lạc lối vì tôi có nhu cầu đào sâu tìm hiểu vấn đề, tôi chấp nhận “đào sâu để tìm vàng”, tôi sợ rằng nếu không đào sâu tôi sẽ bỏ sót những vấn đề tưởng chừng như nhỏ nhưng có thể gây ảnh hưởng nghiêm trọng đến khách hàng. Tuy nhiên hãy biết cân bằng và luôn tự hỏi “có đáng để làm công việc này không?”

14. Nhờ giúp đỡ

Những kỹ sư kiểm thử giỏi luôn sẵn sàng đối mặt với thử thách, “đập đầu vào tường” (khuyến cáo không nên hiểu và làm theo nghĩa đen) để phá vỡ nó từ từ. Vấn đề là có một số bức tường dày hơn một số khác. Những kỹ sư kiểm thử giỏi luôn biết khi nào cần sự giúp đỡ từ ai và vào khi nào.

Điều này đòi hỏi sự cân bằng. Bạn muốn tự mình tìm hiểu vấn đề nhưng cũng không muốn lãng phí thời gian vô ích. Hãy nói chuyện với quản lí của bạn để định ra đâu là giới hạn thời gian cho việc bạn tự nghiên cứu. Hết thời gian đó, bạn sẽ nhờ giúp đỡ.

Mặc dù bạn biết rằng bạn cần giúp đỡ nhưng cũng khó để có thể thừa nhận là bạn cần sự giúp đỡ. Để làm được việc này, bạn cần nhận thức được rằng việc nhờ giúp đỡ sẽ không làm giảm đi chất lượng của công việc cũng như việc kiểm thử của bạn. Mọi người sẽ hiểu được rằng nhờ giúp đỡ là một việc đúng đắn và nên làm và sẽ càng tôn trọng bạn hơn nếu bạn thực lòng muốn làm điều đó. Một kỹ sư kiểm thử giỏi hiểu rằng chẳng việc gì phải hổ thẹn khi nhờ ai đó giúp đỡ. Nếu bạn không thường xuyên nhờ ai đó giúp đỡ, có khi đó lại là vấn đề.

15. Nói cùng ngôn ngữ với kỹ sư lập trình

Điều này cũng tương tự như bạn ghé thăm một đất nước nào đó. Bạn được khuyến khích làm quen với ngôn ngữ cũng như phong tục tập quán của nước đó để ít nhất bạn thể bắt taxi về khách sạn hay hỏi thăm đường. Tương tự, kỹ sư kiểm thử phải tập làm quen với ngôn ngữ và thói quen của kỹ sư lập trình.

Nếu kỹ sư lập trình trong nhóm sử dụng UML, bạn phải tìm hiểu nó ít nhất là ở mức căn bản để không khiến cho họ phì cười khi bạn vẽ một biểu đồ UML. Hãy học cách viết một đoạn code ít nhất là ở mức của một sinh viên năm nhất. Hãy trò chuyện với kỹ sư lập trình để có cái nhìn tổng quát về những thành phần của ứng dụng. Điều quan trọng nhất là bạn có thể tự tin đặt câu hỏi để không cảm thấy ngớ ngẩn cũng như học cách để học.

Nếu bạn làm tốt khâu này, thì một ngày nào đó kỹ sư lập trình sẽ đến và nói với bạn rằng “Bạn tìm được bug. Bạn chỉ ra được bug chính xác là do đâu. Nếu bạn có thể sửa được bug nữa thì chẳng còn gì cho chúng tôi làm nữa”.

[TH] Vâng. Tác giả rất hài hước. Dĩ nhiên, chúng ta luôn biết rằng sẽ không ai có thể giỏi tất cả các khâu được và trên hết chúng ta hiểu được sức mạnh của tinh thần làm việc nhóm. Tuy nhiên việc đó cũng không thể ngăn cản chúng ta tự hoàn thiện bản thân và bổ sung thêm những kỹ năng mới. Bạn chuyên kiểm thử thủ công thì việc tìm hiểu và học một ngôn ngữ lập trình, một công cụ kiểm thử tự động, hay học cách viết các câu truy vấn cơ sơ dữ liệu v.v là không bao giờ thừa. Tương tự, nếu bạn là một kỹ sư kiểm thử tự động thì việc tìm hiểu thêm về những kỹ thuật kiểm thử thủ công, cách thức quản lý bug, trường hợp kiểm thử cũng đều sẽ rất hữu ích.

16. Đầu tư

Một kỹ sư kiểm thử giỏi biết được rằng cách duy nhất để họ tiếp tục là một kỹ sư kiểm thử giỏi là không bao giờ ngừng học hỏi. Nếu bạn được công ty hỗ trợ cho việc học là rất tốt, nếu không thì hãy tự trang bị bổ sung kiến thức cho chính mình.

Để tìm thời gian cho việc đào tạo, hãy đánh giá lại tất cả những công việc bạn đang làm và hãy cân nhắc xem việc nào không quan trọng và có thể bỏ đi. Ban lãnh đạo công ty thường cân nhắc việc được và mất khi hỗ trợ việc đào tạo cho nhân viên. Do đó, để có được sự chấp thuận của họ, việc bạn cần làm là chứng minh việc hỗ trợ đào tạo cho nhân viên sẽ được nhiều hơn mất.

Có nhiều cách khác nhau để đào tạo. Chẳng hạn để luyện tập kỹ năng trình bày, bạn có thể xây dựng một buổi trình bày về một kỹ thuật lập trình/kỹ thuật kiểm thử hữu ích cho đồng nghiệp. Kết quả cuối cùng là cả bạn và đồng nghiệp đều có được kỹ năng hoặc kiến thức mình còn thiếu. Đầu tư vào chính bản thân là cách tốt nhất để cải thiện những đặc điểm đề cập trong bài viết này.

[TH] Hãy không ngừng học hỏi và đầu tư cho việc nâng cao kiến thức chuyên ngành. Tùy nhu cầu và định hướng phát triển nghề nghiệp, các bạn sẽ chọn cách đầu tư theo cách riêng mình…nhưng hãy đảm bảo rằng các bạn có đầu tư.

17. Nhìn thấy bug

Một kỹ sư kiểm thử giỏi biết rằng một ứng dụng dường như không có bug là một ứng dụng có thể có đầy bug mà mình vẫn chưa tìm ra được. Một kỹ sư kiểm thử giỏi luôn tâm niệm rằng mỗi con bug mà khách hàng tìm được là một dấu hiệu cho thấy họ đã để sót rất rất nhiều bug.

Chuyện này sẽ trở nên tự nhiên hơn khi chúng ta hiểu rằng một ứng dụng tưởng chừng như đơn giản nhưng lại không đơn giản như mình nghĩ và rằng không có ứng dụng nào có thể chạy đúng hết tất cả các trường hợp được.

Hãy nhìn vào những khu vực mà ứng dụng hay bị lỗi. Hãy tìm hiểu xem người dùng cuối sử dụng sản phẩm như thế nào vì người dùng thỉnh thoảng có những thói quen sử dụng sản phẩm mà bạn không thể ngờ tới. Cho dù bạn có tìm được bug hay không thì bug vẫn còn đâu đó nhưng những người kỹ sư kiểm thử giỏi luôn muốn tìm được chúng.

[TH] Nếu bạn không tìm thấy bug thì hãy thử những gợi ý sau đây: bạn đã xem qua tài liệu mới của ứng dụng chưa (thiết kế, đặc tả, help, hướng dẫn sử dụng, v.v), xem lại những email cũ xem còn vấn đề nào chưa thảo luận xong và bị “bỏ quên” không, lật lại cuốn sổ tay xem có thông tin gì thú vị mà bạn đã ghi chú không, xem lại những con bug và những thảo luận của chúng trên hệ thống quản lý bug… Sau khi lục lọi tìm tòi đủ thứ, bạn có thể tìm được bug nhưng cũng có thể không. Tuy nhiên, điều quan trọng là bạn sẽ hiểu thêm về hiện trạng của sản phẩm cũng như sẽ đưa ra được những câu hỏi hay vấn đề thú vị để đem ra thảo luận với khách hàng, với kỹ sư lập trình, với giám đốc sản phẩm, giám đốc dự án.

18-19-20. Trung thực – Chính trực – Dũng cảm

Đây là 3 đặc điểm nền tảng cho những đặc điểm khác. Như Jerry Weinberg đã từng nói “Nếu như không có sự chính trực và lòng dũng cảm để bảo vệ nó thì bạn sẽ bị cán dẹp trên đại lộ của sự phát triển và mỗi ngày trôi qua bạn sẽ ngày càng dẹp lại …dẹp lại..”. Sự trung thực, chính trực và lòng dũng cảm là nền móng của một kỹ sư kiểm thử giỏi.

Nếu bạn không trung thực về tình trạng hiện tại của ứng dụng thì hoặc là ứng dụng sẽ không bao giờ được đưa ra thị trường (nếu như bạn cố tình phóng đại về tình trạng tệ hại của ứng dụng) hoặc là bạn sẽ bỏ sót một “rừng bug” cho khách hàng (nếu như bạn cố tình nói giảm về tình trạng tệ hại). Sự chính trực có mối quan hệ mật thiết với danh tiếng của bạn; cải thiện điều này sẽ cải thiện điều kia. Cuối cùng, bạn sẽ thể hiện lòng dũng cảm dễ dàng hơn nếu như bạn thật lòng tin rằng là bạn đã làm đúng. Những đặc điểm khác sẽ giúp bạn có thêm lòng dũng cảm để đứng lên tranh đấu khi cần thiết. Sự trung thực, chính trực và lòng dũng cảm là chất xúc tác giúp bạn đạt được những đặc điểm khác nhanh chóng hơn.

[TH] Một trong những nhiệm vụ quan trọng của một người kỹ sư kiểm thử là cung cấp thông tin một cách chính xác và kịp thời đến cho khách hàng. Nếu thông tin cung cấp bị sai lệch thì công việc kiểm thử coi như là vô ích. Nếu bạn thấy thời gian kiểm thử cho sản phẩm quá ít hãy cho khách hàng biết. Nếu bạn cảm thấy không tự tin khi đưa sản phẩm ra thị trường, hãy chia sẻ với khách hàng. Nếu bạn thấy bạn không hoàn tất việc được giao, hãy thông báo khách hàng. Nếu bạn cảm thấy không khỏe và không thể làm công việc với kết quả tốt nhất, hãy chia sẻ với khách hàng…Hãy luôn trung thực với những việc mà bạn tin rằng sẽ ảnh hưởng đến chất lượng công việc, sản phẩm và dự án.

Lời kết

Mình vừa đi qua những đặc điểm cuối cùng trong loạt bài về 20 đặc điểm của một kỹ sư kiểm thử giỏi. Bạn sẽ phì cười khi nghĩ rằng làm gì có ai có đủ 20 đặc điểm đó và rằng tất cả chỉ là “sách vở” thì bạn biết rằng ít nhất có một người chia sẻ quan điểm với bạn…người đó là mình. Tuy nhiên, đối với mình việc có đủ 20 đặc điểm đó (hoặc đặc điểm khác hoặc nhiều hơn hoặc ít hơn) không quan trọng bằng việc luôn tìm kiếm những đặc điểm của riêng mình để trở thành một kỹ sử kiểm thử giỏi và luôn cố gắng đạt được nó.

Ngoài ra, nếu ai đó đã đọc đến phần thứ 3 này (dĩ nhiên là cả phần 1 và phần 2 nữa) thì mình tin là bạn đó rất có thể là một kỹ sư kiểm thử giỏi vì bạn đó đã chứng tỏ được sự kiên nhẫn – một trong những đặc điểm làm nên một kỹ sư kiểm thử giỏi – theo nhận định của mình.

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

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

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Để hoạt động review test case hiệu quả hơn

Bài viết được sự cho phép của tác giả To Thi Van Anh

Tranh thủ mấy ngày Tết, mặc dù tình hình ăn uống, đi chơi cứ phải gọi là tưng bừng nhưng cũng không thể lơ là việc học tập được. Hehe. Thế nên là theo như kế hoạch mình sẽ tung ra một ‘hit’ mới rất không liên quan đến ngày Tết, nhưng mà lại vô cùng liên quan đến công việc mà mình đã làm được gần hai tuần trước khi nghỉ tết và dự là sau Tết còn làm nhiều nhiều và dài dài.

Tuyển dụng tester các công ty

Nghe đã thấy hoang mang, và tóm lại thì nó là gì, không lan man nữa đó chính là hoạt động review test case như tiêu đề bài viết đã gợi ý đó!

Tất cả chúng ta (trong lĩnh vực phần mềm mềm nói riêng) đều biết được sự cần thiết của các test case, một trong những yếu tố đánh giá hiệu quả của hoạt động kiểm thử. Các test case đóng một vai trò quan trọng trong quá trình đảm bảo chất lượng đầu ra của sản phẩm phần mềm, do đó việc cần phải đảm bảo tính hiệu quả, sự chính xác và tối ưu của các test case cũng là một việc cần được ưu tiên. Và hoạt động reivew ở đây chính là để đảm bảo các yếu tố đó!

Test case sau khi được viết ra xong, đúng quy trình thì sẽ được chính người viết đó tự kiểm tra lại một lượt (self-review) trước khi chuyển cho một thành viên khác trong nhóm kiểm thử, kiểm tra chéo những test case đó (peer-review), sau khi hoàn tất công đoạn này thì test case mới được đưa vào giai đoạn thực thi.

04 Điều Cần Chú Ý Cho Người Mới Làm Automation Test

Automation skills cho tester già mà lười

Nắm bắt được tư tưởng và ứng dụng được một số yếu tố dưới đây mình nghĩ là nó sẽ giúp ích được kha khá cho hoạt động self-review và peer-review của chúng ta được tốt hơn đấy (vì mình cũng đang áp dụng rồi mà, ah thì tất nhiên là cũng có chọn lọc cho phù hợp với hoàn cảnh thực tế dự án của mình nhé! kaka), các bạn cùng tham khảo nha!

– Giá trị sử dụng

Việc đầu tiên cần kiểm tra đó là giá trị sử dụng của test case đó, với yêu cầu đó thì test case này có cần thiết không? Test case này đã có được cover bởi một test case nào khác hay chưa? Trong đó ta cần phải xác định được những giá trị mà test case mang lại, việc xác định này sẽ dựa theo mô tả hay chức năng của hệ thống mà test case này được viết ra cho nó.

– Mục tiêu của test case

Đọc lướt qua mô tả, nội dung test case để xác định xem là bạn có hiểu được mục đích của test case này là gì hay không? Lưu ý là mỗi một test case chỉ để kiểm tra một vấn đề cụ thể nào đó thôi nhé. Nếu trong một test case mà nó có nhiều hơn một mục đích cần kiểm tra khi thực thi thì lúc này ta cần phải xem xét tách nhỏ case đó ra.

– Điều kiện trước

Ở đây ta sẽ xác định xem là cái test case này có yêu cầu ta phải chuẩn bị, thực hiện một số setup đặc biệt nào đó trước khi thực thi test case hay không. Thứ tự thực hiện các yêu cầu ấy, và việc review là phải xem xem trong test case đã có lưu ý rõ ràng và đầy đủ những yêu cầu đó hay chưa?

– Các bước thực hiện

Các bước thực hiện được đưa ra trong test case có dễ dàng làm theo khi thực thi test case không? Với một người mới liệu có thể nắm được mục đích và làm theo được thông qua các bước này hay không? Nếu không, thì có thể là người viết chỉ đang suy đoán các bước là như vậy, lúc này cần thì phải chỉnh sửa hoặc là phải thêm một số bước cụ thể hơn để có thể dễ dàng làm theo được.

– Inputs

Các test case cần cung cấp rõ ràng và cụ thể những giá trị đầu vào nào cần cho test case đó. Ta cũng cần phải lưu ý rằng, với những giá trị cụ thể đó ta cũng sẽ có những kết quả cụ thể tương ứng. Và những giá trị này có thể là nguyên nhân mà test case sẽ trả về các kết quả khác nhau sau mỗi lần thực thi.

– Ngôn ngữ

Yếu tố quan trọng nữa là việc sử dụng từ ngữ cần phải đơn giản và rõ ràng. Từ đó, không phải chú thích hay giải thích gì khi mà test case được đưa vào thực thi – tuy nhiên có thể sẽ có những ngoại lệ (cái này thì không tính nhé :v). Rồi liên quan đến việc diễn đạt, ngữ pháp, hay chính tả… (Lỗi dễ mắc khi mà chúng ta viết test case bằng tiếng Anh, hehe)

– Kết quả mong muốn

Một test case kiểu mẫu cần phải mô tả một cách rõ ràng kết quả mong muốn hay phản hồi của hệ thống khi thực thi test case đó. Từ đây, việc đánh giá test case đó pass hay fail có thể xác định một cách dễ dàng và công bằng.

– Clean-up

Thao tác này đối với một số test case đặc thù, trong khi thực hiện những bước làm thay đổi trạng thái hay cài đặt của hệ thống, nó có thể làm cho các bước sau đó và test case chạy không chuẩn xác nữa. Do đó, với những trường hợp này thì ta cần phải có thêm một bước để khôi phục lại những thay đổi đó.

– Sự phụ thuộc

Ta sẽ xác định test case này có phụ thuộc vào các test case khác hay không? Những test case đó có yêu cầu cần được thực thi trước hoặc sau test case này hay không? Nếu có thì cần phải lưu ý rõ ràng trong các test case đó. Lý tưởng ở đây là mỗi test case cần phải độc lập với các test case khác. Nhưng trong trường hợp không thể tránh được thì điều cần làm đó là phải note lại một cách vô cùng cẩn thận và rõ ràng các thông tin đó nhé.

– Tài liệu

Test case cần có thông tin đầy đủ về tác giả – người viết ra test case đó, độ ưu tiên của test case (nếu có), requirement của test case, những thông tin này sẽ hữu ích trong trường hợp mà cần thêm thông tin hoặc kiểm tra độ bao phủ của test case.

Về cơ bản là chúng ta sẽ nên tập trung chủ yếu vào các yếu tố trên, ngoài ra tùy theo đặc thù của hệ thống, nền tảng ta sẽ cần xem xét thêm những yếu tố khác nữa nhé, như là các thiết bị test nào cần được chuẩn bị, môi trường test là gì… Ta cũng sẽ cần kiểm tra thêm những cái đó có được mô tả đầy đủ và chính xác đối với từng case cụ thể hay chưa.

Hi vọng rằng, với những gợi ý từ bài viết sẽ mang lại những lợi ích nào đó cho tất cả những bạn nào đã đọc bài viết này.

Bài viết gốc được đăng tải tại vananhtooo.wordpress.com

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

Xem thêm Việc làm it job hấp dẫn trên TopDev

WiFi 6 là gì? Ưu điểm nổi bật của WiFi 6 so với thế hệ trước

Bài viết được sự cho phép của blogchiasekienthuc.com

Wi-Fi 6 (hay còn gọi là WiFi thế hệ thứ 6) là một khái niệm đã quá quen thuộc với những người yêu thích công nghệ rồi. Vậy bạn đã hiểu gì về Wi-Fi 6 rồi?

Nếu như bạn đang tìm kiếm một bài viết giải thích ngắn gọn và dễ hiểu nhất về Wi-Fi 6 thì mời các bạn tham khảo bài viết bên dưới đây.

Dùng MicroPython với wifi board ESP-8266

Các ưu nhược điểm của Swift so với Objective C

Trong bài viết này mình sẽ tổng hợp lại những nét đặc trưng và những ưu điểm nổi bật của Wi-Fi 6, để các bạn có cái nhìn tổng quát nhất.

I. Lịch sử phát triển WiFi?

Okay, trước tiên thì mình sẽ nói qua một chút về lịch sử ra đời các phiên bản Wi-Fi trước đã:

WiFi thế hệ 1: Được phát triển vào năm 1997 với chuẩn 802.11
WiFi thế hệ 2: Được ra đời 2 năm sau đó, tức là vào năm 1999 với chuẩn 802.11b
WiFi thế hệ thứ 3: Được ra đời vào năm 2003 với chuẩn 802.11 a/g (chuẩn a và chuẩn g ra đời).
WiFi thế hệ thứ 4: Được ra đời vào năm 2007 với chuẩn 802.11n (chuẩn n ra đời).

WiFi 4 được sinh ra để giải quyết vấn đề về tốc độ (HT – Hight Throughput hay còn gọi là tốc độ cao). Chuẩn n này có thể đạt tốc độ tối đa là 600 Mbps

WiFi thế hệ thứ 5: Được ra đời vào năm 2012 với chuẩn 802.11ac (chuẩn ac ra đời). Và tiếp tục, vào năm 2015 một phiên bản cải tiến của chuẩn ac ra đời ( 802.11ac Wave 2).

Vâng, và chuẩn ac được ra đời cũng là để cải tiến tốc độ (VHT – Very Hight Throughput hay còn gọi là tố độ rất cao). Và chuẩn ac này có thể đạt tốc độ tối đa là 6Gbps

WiFi thế hệ thứ 6: Đây là chuẩn Wi-Fi mới nhất hiện nay (chuẩn 802.11ax). Tốc độ của WiFi 6 lên đến 10 Gbps, và nó có thể đạt được 12 Gbps với điều kiện ở trong phạm vi ngắn và với tần số sóng không dây cao nhất.

Có thể nói, với người dùng phổ thông thì ít ai mà có thể sử dụng được tối đa của tốc độ WiFi 5, vậy thì WiFi 6 được phát triển ra là với mục đích gì?

Vâng, chuẩn ax được phát triển ngoài mục đích là để nâng cao tốc độ hơn nữa thì nó còn để giải quyết vấn đề về sô lượng user (người dùng) và giảm độ nhiễm, chồng chéo sóng. Nói một cách ngắn gọn thì WiFi 6 được phát triển với mục đích mang lại HIỆU QUẢ CAO TRONG VIỆC TRUYỀN DỮ LIỆU (HE – Hight Efficiency)

=> Như vậy thì các bạn có thể thấy, sự khác nhau trong việc đặt tên cho các thế hệ Wi-Fi là ở phần tên phía sau, như là b, a/g, n, ac, ax…

Nhưng sẽ thật khó nhớ khi chúng ta cứ phải gọi chuẩn ac hay ax.. đúng không. Mà để đơn giản hóa vấn đề, thì những cái tên như Wi-Fi 5, Wi-Fi 6 nên được sử dụng.

II. Những ưu điểm nổi bật của WiFi 6?

#1. Hoạt động trên cả 2 băng tần 2.4GHz và 5GHz

Như các bạn đã biết, Router băng tần kép hiện nay thường hoạt động trên phổ tần là 2.4GHz và 5GHz, và các phổ này phân bổ theo bộ kênh với độ rộng 20MHz.

Wi-Fi 6 ra đời hoạt động trên cả 2 băng tần 2.4GHz và 5GHz. Ngoài ra thì nó cũng tương thích hoàn toàn với các thiết bị chỉ hỗ trợ một băng tần 2.4GHz

Điều này là vô cùng cần thiết, bởi vì đa số các thiết bị hiện nay đều chạy trên băng tần 2.4 GHz. Nói tóm lại là Wi-Fi 6 có khả năng tương thích tốt với các thiết bị cũ.

#2. Sử dụng OFDMA

Nếu như Wi-Fi 3, 4 hay là Wi-Fi 5 sử dụng OFDM thì Wi-Fi 6 lại sử dụng OFDMA.

Vậy OFDM khác gì so với OFDMA? Vâng, với OFDM khi bạn cấu hình các kênh như 20MHz, 40 MHz… thì lúc này OFDM sẽ sử dụng toàn bộ 20MHz, 40 MHz… đó cho 1 user, user này xong thì sẽ đến lượt các user khác.

Còn với OFDMA thì khác hoàn toàn, với 20MHz, 40 MHz… đó thì nó sẽ chia sẻ ra cho nhiều người cùng một lúc trên băng thông 20MHz, 40 MHz… đó.

Các bạn có thể hình dung đơn giản là OFDM được ví như là con đường chỉ có 1 làn đường, còn OFDMA là một con đường nhiều làn vậy.

Giải thích theo góc độ kỹ thuật thì:

Wi-Fi 6 sẽ thực hiện phân bổ các kênh 20 MHz này ra thành 256 kênh nhỏ hơn (một con số lớn hơn rất nhiều so với 64 kênh trước kia).

=> Điều này không chỉ giúp cho Wi-Fi 6 gia tăng về mặt số lượng kênh đơn thuần, mà còn sửa đổi các kết nối dữ liệu trong những kênh được tăng thêm.

Từ đó mà Wi-Fi 6 có thể chạy được nhiều luồng cùng một lúc hơn, và nó hoạt động tốt hơn, ổn định hơn khi có nhiều người truy cập.

__

Ngoài ra, ở trong phiên bản trước (tức là Wi-Fi thế hệ 5) thì chỉ có 256 Quadrature Amplitude Modulation (QAM), nhưng trên Wi-Fi 6 thì đã được nâng cấp lên tới 1024 QAM.

=> Điều này giúp cho Wi-Fi 6 có thể phát sóng 8 luồng cùng một lúc, hiểu đơn giản thì nó có thể xử lý lưu lượng truy cập của 8 người cùng lúc, ở cùng một tốc độ mà không hề bị giảm => giải quyết được vấn đề nghẽn mạng.

#3. Resource Unit

Nó sẽ thực hiện chia nhỏ tài nguyên băng thông ra thành những Resource Unit, và nó sẽ phân phát các Resource Unit này cho các user ở phía bên dưới chia sẻ nhau => Cho phép nhiều thiết bị có thể truyền/nhận dữ liệu cùng lúc.

#4. BSS Color

Nó sẽ đánh dấu các gói tin WiFi, mục đích là để nhận biết những gói tin nào cùng một SSID, cùng một hãng WiFi thì nó sẽ được đánh dấu cùng một màu. Còn ngược lại, nếu khác SSID thì nó sẽ đánh dấu khác màu.

=> Như vậy thì nếu chẳng may có 2 Access Point có đặt cạnh nhau, và phát cùng một kênh đi chăng nữa thì nó cũng sẽ không bị nhiễu sóng.

#5. Target Wake Time (TWT)

Một tính năng giúp giảm xung đột & Tiết kiệm năng lượng hơn. Vâng, tiết kiệm điện là tiết kiệm cho các thiết bị kết nối với mạng Wi-Fi 6 nhé các bạn, ví dụ như smartphone, máy tính….

III. Một số thuật ngữ mà bạn có thể gặp khi dùng Wi-Fi 6

Bên dưới là một số thuật ngữ mà có thể bạn sẽ gặp khi tìm mua một bộ phát WiFi 6 nào đó, mình sẽ tiếp tục update tại đây nên nếu quan tâm bạn có thể bookmark lại bài viết này để theo dõi nhé.

#1. WiFi Mesh là gì?

Vâng, các bạn có thể hiểu đơn giản WiFi Mesh là một hệ thống bao gồm nhiều thiết bị (Mesh) kết nối không dây lại với nhau, để phủ sóng Wi-Fi trong một không không gian rộng lớn, như là: chung cư, quán xá, văn phòng, hoặc biệt thự, căn nhà nhiều tầng….

Bạn không cần phải chạy dây mạng lằng ngoằng tới các thiết bị như những modem truyền thống nữa, và điều này thì đương nhiên là sẽ mang lại tính thẩm mỹ cao hơn cho căn nhà.

WiFi mesh giúp cho toàn bộ các thiết bị sử dụng chung một tên WiFi duy nhất, mà từ đó người dùng cũng không cần phải trực chờ đổi sang mạng Wi-Fi khác khi di chuyển giữa các tầng.

Qua đó thì cũng giúp cho các thiết bị thông minh (smart) trong gia đình như: camera, robot hút bụi … dễ dàng kết nối và cài đặt hơn.

Nhưng bạn đừng nghĩ WiFi Mesh là một bộ kích sóng nhé, bởi bộ kích sóng chỉ đơn giản là giúp tăng cường độ tín hiệu của Router chính, còn WiFi Mesh sẽ tạo ra một mạng WiFi hoàn toàn độc lập.

#2. AIoT là gì?

AIoT là sự kết hợp của AI (Trí Tuệ Nhân Tạo) và IoT (Internet of Things – Vạn vật kết nối) nhằm mục đích trao quyền cho cho các thiết bị được kết nối với trí thông minh của riêng chúng.

Vâng, điều này cho phép chúng học hành vi của con người và hành động theo hành vi và sở thích của người dùng mà không cần tương tác, nhắc nhở hoặc lập trình từ con người .

IV. Lời Kết

Okay, như vậy là mình đã giúp bạn hiểu rõ hơn về Wi-Fi 6 rồi nhé, về cơ bản thì bạn chỉ cần hiểu như vậy là đủ.

Và tất nhiên, ngoài những lý thuyết bên trên ra, nếu bạn còn biết thêm những kiến thức hay ho khác về Wi-Fi 6 thì đừng quên chia sẻ lại cho anh em bằng cách để lại comment phía bên dưới bài viết này nhé!

Kiên Nguyễn – Bài viết gốc tại blogchiasekienthuc.com

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

Xem thêm tuyển dụng it mới ra trường hấp dẫn trên TopDev

TOP 7 phiên bản phân phối của Linux phổ biến nhất hiện nay

Bài viết được sự cho phép của blogchiasekienthuc.com

Chào các bạn, với những người dùng phổ thông thì có lẽ Windows hay MacOS là những hệ điều hành phổ biến nhất mà họ biết đến, mình nói đúng chứ.

Và đối với những người dùng phổ thông thì ít ai biết đến hệ điều hành Linux cũng như các phiên bản phân phối của nó.

10 điều bạn có thể làm với Linux mà bạn không thể làm với Windows

5 lý do lập trình viên nên sử dụng hệ điều hành Linux

Nhưng có lẽ bạn chưa biết, hệ điều hành “Linux nói chung” hiện cũng đã chiếm một tỷ lệ khá lớn rồi. Phần đa những người sử dụng điều hành này là các lập trình viên, những người yêu thích mã nguồn mở và những người làm việc với hệ thống.

Và ở trong bài viết này, mình sẽ cùng các bạn điểm tên những phiên bản phân phối phổ biến nhất của Linux, mà nếu bạn yêu thích Linux thì có thể trải nghiệm thử nhé.

I. Nhân Linux là gì?

Trước khi tìm hiểu về các phiên bản phân phối của Linux, chúng ta cần phải nắm được một khái niệm đó là “nhân linux – Kernel” trước đã.

Đây là thành phần quan trọng nhất của hệ điều hành Linux nói chung và các phiên bản phân phối nói riêng.

Chức năng của nó là cho phép hệ thống giao tiếp, quản lý và điều khiển các bộ phận phần cứng của máy tính.

II. Các phiên bản phân phối của Linux

Hiện có hàng trăm phiên bản phân phối khác nhau của Linux. Các bạn có thể xem chi tiết tại đây: https://distrowatch.com/

Nhưng trong số đó, chỉ có một vài cái tên nối tiếng và phổ biến như: Ubuntu, Debian, Fedora, Kali, Red Hat, PopOS!…

Việc có quá nhiều phiên bản như vậy phần nào cũng khiến cho người dùng (đặc biệt là với những bạn đang tìm hiểu) thấy rất khó trong việc lựa chọn phiên bản phù hợp.

Chính vì vậy mà tùy mục đích, tùy cấu hình máy tính mà các bạn có thể chọn ra cho mình một phiên bản phù hợp để cài đặt thì sẽ đem lại hiệu quả cao nhất.

Okay ! Bây giờ thì mình sẽ cùng các bạn điểm mặt một vài những phiên bản phổ biến nhé.

#1. Red Hat Enterprise Linux

Được phát triển bởi Red Hat và mục tiêu là hướng tới thị trường thương mại. Red Hat Enterprise Linux được phát hành cho các phiên bản máy chủ x86, x86-64, Itanium, PowerPC và IBM System z.

Red Hat Enterprise Linux có hai phiên bản là RHEL và RHELAP.

RHEL(Red Hat Enterprise Linux) là phiên bản hỗ trợ 2 CPU.
RHELAS(Red Hat Linux Advanced Server) là phiên hỗ trợ CPU không giới hạn

Red Hat Enterprise Linux chủ yếu được sử dụng bởi các tổ chức có yêu cầu tính bảo mật cao (các cơ quan, tổ chức nhà nước chẳng hạn).

Trình quản lý gói RPM được sử dụng trên Red Hat và các bản phân phối dựa trên nó (Red Hat Package Management).

#2. CentOS

CentOS là viết tắt của Community Enterprise Operating System và là một bản phân phối miễn phí của Red Hat Enterprise Linux (RHEL).

Trên thực tế thì có rất nhiều doanh nghiệp sử dụng CentOS là hệ điều hành cho các Server, đơn giản vì nó là một bản phân phối của RHEL nên đảm bảo về mức độ bảo mật.

Hai nữa là CentOS lại miễn phí, vậy nên các doanh nghiệp sẽ tiết kiệm được một khoản tiền khá lớn khi không phải trả tiền mua và duy trì dịch vụ.

Các bạn có thể tham khảo về CentOS tại địa chỉ sau: https://www.centos.org/

#3. Fedora

Trước đây Fedora được gọi là Fedora Core và cũng là một bản phân phối Linux dựa trên RPM Package Manager. Fedora được cộng đồng Fedora Project phát triển và được bảo trợ bởi Red Hat.

Do được tài trợ bởi Red Hat, Fedora được dùng để kiểm tra các tính năng mới của Red Hat phát triển trước khi tính năng đó được thương mại hóa với RHEL.

Các bạn có thể tham khảo về Fedora tại địa chỉ sau: http://fedoraproject.org/

#4. Debian Linux

Debian Linux là phiên bản phân phối miễn phí của Linux, nó được phát triển bởi cộng đồng các lập trình viên và người dùng (phát triển dựa trên những phản hồi từ người dùng).

Do Debian miễn phí nên mọi người có thể tham khảo Souce Code của dự án và sử dụng nó với các mục đích hợp pháp.

Với hơn 23000 ứng dụng và công cụ cài đặt có sẵn thông qua dpkg thì chúng ta sẽ có rất nhiều lựa chọn khi cài đặt phần mềm, công cụ trên Debian.

Các bạn có thể tham khảo về Fedora tại địa chỉ sau: https://www.debian.org/

#5. Ubuntu

Ubuntu có lẽ là cái tên quen thuộc trong giới lập trình viên, nhiều người còn ví von “Ubuntu giống như Windows của Linux” – kiểu nó phổ biến như cách Windows phổ biến với người dùng vậy.

Ubuntu cũng miễn phí giống như Debian với khoảng 6 tháng sẽ được cập nhật một lần. Hiện nay, phiên bản mới nhất của Ubuntu là 20.04 LTS (Long-term Support).

Ngoài ra thì Ubuntu cũng có hỗ trợ các phiên bản thương mại dành cho các tổ chức. Ubuntu được sử dụng với với nhiều mục đích khác nhau gồm cả desktop, server, IoT và Cloud..

Ubuntu được đánh giá là một phân phối Linux dễ sử dụng, hiệu năng tương đối tốt và mang lại trải nghiệm tốt cho người dùng.

Các bạn có thể tham khảo về Ubuntu tại địa chỉ sau: https://www.ubuntu.com/

#6. Pop!_OS

Là một bản phân phối Linux miễn phí và mã nguồn mở dựa trên Ubuntu, nó cũng có một màn hình GNOME tùy chỉnh.

Bản phân phối này được phát triển bởi nhà sản xuất máy tính Linux System76 của Mỹ.

System76 không xây dựng hệ điều hành Pop!_OS từ đầu, đây thực chất là một bản distro Linux.

Một cách để phân phối Kernel Linux và tất cả các phần mềm miễn phí cần thiết để mang đến trải nghiệm máy tính hoàn chỉnh cho người dùng.

Pop!_OS được đánh giá tối ưu hơn Ubuntu cho các lập trình viên.

Các bạn có thể tham khảo thêm về Pop!_OS tại địa chỉ sau: https://pop.system76.com/

#7. Gentoo

Gentoo Linux là một bản phân phối Linux được đặt tên theo loài chim cánh cụt Gentoo.

Gentoo chủ yếu được thiết kế cho các thiết bị xách tay với mục tiêu dễ bảo dưỡng, linh hoạt và có khả năng tùy biến theo máy tính của người sử dụng.

Một ưu điểm của Gentoo đó là hệ thống quản lý gói của Gentoo được xây dựng như một plug-in rất linh hoạt, dễ bảo trì và độ tương thích phần cứng là gần như không giới hạn.

III. Lời Kết

Okay, vậy là trong bài viết này mình đã cùng các bạn tìm hiểu về các phiên bản phân phối phổ biến của Linux rồi ha.

Trên thực tế thì việc lựa chọn dựa trên nhiều yêu cầu khác nhau như mình đã trình bày bên trên. Nhưng nếu bạn mới bắt đầu tiếp xúc với Linux thì mình nghĩ Ubuntu là một lựa chọn tốt, vì nó phổ biến và bạn sẽ dễ dàng tìm được hướng dẫn khi cần.

NOTE: Trong các Distro trên, nếu dùng ở môi trường Desktop thì các bạn nên chọn Ubuntu, còn nếu dùng làm Server có thể chọn CentOS, Ubuntu Server.

Nguyễn Đức Cảnh – Bài viết gốc tại blogchiasekienthuc.com

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

Xem thêm tìm việc làm ngành it hấp dẫn trên TopDev

Các đặc điểm của một kỹ sư kiểm thử giỏi (Phần 2)?

Bài viết được sự cho phép của vntesters.com

Ở phần 1 mình đã giới thiệu đến các bạn một số đặc điểm cơ bản của một kỹ sư kiểm thử giỏi như “sự cân bằng”, “sự tò mò”, “sự thực hành thường xuyên”, “luôn phấn khích khi tìm được bug”, “niềm đam mê đối với khách hàng”. Ở phần 2, mình sẽ giới thiệu tiếp những đặc điểm mà với những đặc điểm này sẽ bổ trợ cho những đặc điểm ở phần 1.

10 bước để bắt đầu áp dụng kiểm thử tự động vào dự án

5 điều cần lưu ý trước khi bắt đầu kiểm thử di động

7. Nhìn tổng thể

Những kỹ sư kiểm thử giỏi thường bắt đầu công việc kiểm thử bằng việc nghĩ ra những phần nào có thể kiểm thử được trên sản phẩm của mình. Những kỹ sư kiểm thử này bắt đầu bằng việc phân tích kiến trúc, thiết kế, hay những tính năng của sản phẩm tuy nhiên họ cũng nhận thức được rằng đó chỉ là một trong nhiều yếu tố có thể ảnh hưởng đến chất lượng sản phẩm.

Nên nhớ rằng người dùng thật của sản phẩm không có ý định kiểm thử sản phẩm mà chỉ muốn sử dụng chúng cho nên hãy sáng tạo khi kiểm thử. Do đó nếu có trường hợp kiểm thử nào mà bạn kiểm thử ít hơn những trường hợp khác thì đôi khi vẫn có thể chấp nhận được. Việc có cái nhìn tổng thể sẽ giúp kỹ sư kiểm thử có thể cân bằng được những điều này.

8. Sắp xếp thứ tự ưu tiên

Khả năng nhìn tổng thể sẽ giúp cho kỹ sư kiểm thử sắp xếp được thứ tự ưu tiên trong công việc. Một kỹ sư kiểm thử giỏi luôn biết phải kiểm thử cái nào trước cái nào sau và phạm vi kiểm thử như thế nào để những phần kiểm thử mà có khả năng tìm được bug nhiều nhất và ảnh hưởng đến khách hàng nhiều nhất sẽ được thực thi trước.

Cũng theo ý tác giả, để làm được việc này một cách hiệu quả thì cần phải nắm được khách hàng của mình là ai. Khách hàng của khách hàng cũng là khách hàng. Đội hỗ trợ sản phẩm cũng là khách hàng. Các bên liên quan đến sản phẩm đều sẽ bị ảnh hưởng bởi những con bug bạn tìm được hoặc không tìm được.

Theo sát phần thiết kế của sản phẩm ngay từ đầu hay trao đổi với kỹ sư lập trình sẽ giúp bạn biết được mình cần phải tập trung kiểm thử phần nào và độ ưu tiên ra sao. Tuy nhiên, hãy tin vào bản năng của một kỹ sư kiểm thử. Nếu bản năng nói với bạn rằng chỗ này hoặc chỗ kia cần phải kiểm thử, hãy nên lắng nghe nó.

[TH]: Đó là lí do vì sao các bộ trường hợp kiểm thử hay bug thường có 2 thông tin quan trọng là “độ ưu tiên” (Priority) và “độ nghiêm trọng” (severity). Trong nhiều trường hợp vì một lí do nào đó bạn không thể thực thi hết tất cả các bộ kiểm thử thì khi đó việc xác định độ ưu tiên sẽ giúp bạn chọn được những phần kiểm thử quan trọng nhất để thực thi để rủi ro ảnh hưởng đến sản phẩm thấp nhất.

9. Khả năng quan sát

Những kỹ sư kiểm thử giỏi luôn để mắt quan sát những điều bất thường trên đường kiểm thử của mình. Những điều bất thường này có khi chỉ là những lỗi lập trình đơn giản, có khi là cả một “ổ” bug, có khi đó là một con bug nào đó mà trước giờ nhiều người vẫn chưa mô phỏng lại được. Hãy ghi nhận lại tất cả những gì bất thường quan sát được.

Để quan sát được những điều bất thường thì trước tiên kỹ sư kiểm thử phải biết được như thế nào là bình thường. Để làm được vậy người kỹ sư kiểm thử phải nắm được sản phẩm của mình từ trong ra ngoài. Bên cạnh đó phải luyện tập thường xuyên kỹ năng quan sát. Để tâm vào chi tiết và phát hiện những điều có vẻ hơi bất bình thường một chút. Tuy nhiên, đừng quá sa đà nếu không bạn sẽ bỏ qua những con bug lộ ngay trước mặt.

[TH]: Lời khuyên của mình là hãy luôn có một cuốn sổ tay bên mình hay bất cứ thứ gì có thể ghi chú được khi thực thi các trường hợp kiểm thử hay kiểm thử kiểu khám phá (mình chọn Onenote ) Mục đích là để ghi chú tất cả những gì mình quan sát được, nghi ngờ là bug hoặc đơn giản chỉ là những điều mình thắc mắc và sẽ quay lại tìm hiểu và kiểm chứng sau mà không làm chệch mục tiêu mình đang kiểm thử.

10. Sự chính xác

Khi những kỹ sư kiểm thử giỏi tìm được bug, họ thường dành thời gian để làm giảm thiểu số bước cần thiết để mô phỏng con bug đến mức tối thiểu. Họ cũng thường kiểm thử thêm xung quanh con bug để hiểu thêm về con bug. Những kỹ sư kiểm thử giỏi khi báo cáo một con bug luôn chỉ rõ ra chỗ nào là ngầm định, chỗ nào là họ thực tế quan sát được.

Có nhiều cách để làm tốt khâu này. Hãy nhìn vấn đề với con mắt của kỹ sư lập trình để hiểu được bản chất của nó. Hãy giả định rằng người đang đọc bản báo cáo bug có thể là người không có hoặc ít kiến thức về vấn đề đang được đề cập. Mục đích là để làm sao ngay cả CEO cũng có thể đọc, hiểu được bản báo cáo bug và đưa ra quyết định dựa trên báo cáo đó. Trong báo cáo bug, hãy chỉ rõ hành vi bạn mong muốn là gì và tại sao cái bạn quan sát là không hợp lí. Hãy giải thích con bug này sẽ làm ảnh hưởng như thế nào đến khách hàng.

[TH]: Hãy làm tất cả những gì có thể mà bạn nghĩ là cần thiết để giúp người đọc hiểu được bản chất của con bug đó. Các bước mô phỏng, ảnh chụp màn hình, video, log file, trích dẫn tài liệu đặc tả, thiết kế, v.v tất cả đều hữu dụng khi bạn báo cáo bug.

11. Suy nghĩ độc lập

Mặc dù việc con bug làm ảnh hưởng đến khách hàng như thế nào đã được để cập đầy đủ trong báo cáo bug nhưng kỹ sư kiểm thử giỏi đôi khi cũng phải đối diện với tình huống là phải yêu cầu để sửa bug đó gấp. Những kỹ sư kiểm thử giỏi luôn sẵn sàng trở nên cứng đầu và “xù lông” khi cần thiết.

Tuy nhiên, trước khi “xù lông” thì hãy đánh giá lại một lần nữa liệu vấn đề có phải là do bạn đã không cung cấp đủ thông tin cần thiết về mức độ ảnh hưởng của con bug hay là bạn đã không đặt độ ưu tiên đủ cao cho con bug. Một kỹ sư kiểm thử giỏi luôn cân nhắc tất cả những điều này cùng với việc đặt khách hàng lên trên hết trước khi đưa ra quyết định của mình.

Nên nhớ rằng bạn không cần phải thô lỗ hay bất cần khi nêu lên quan điểm của mình. Hãy tìm đồng minh để “chống lưng” cho vấn đề của bạn. Hãy nhẹ nhàng chỉ ra lí do tại sao con bug cần được sửa và thuyết phục rằng sản phẩm sẽ không thể được đưa ra thị trường với con bug đó được.

Uy tín của bạn đóng vai trò quan trọng ở đây. Nếu bạn báo động giả nhiều lần, sẽ chẳng ai còn tin bạn. Do đó hãy suy nghĩ và nghiên cứu vấn đề một cách thấu đáo và hãy chắc chắn rằng bạn có đủ thông tin để tự tin.

Hãy luôn nhớ rằng kỹ sư kiểm thử không phải là người quyết định sau cùng một con bug có được sửa hay không. Do đó khi tranh luận, hãy lịch sự nhưng đồng thời cũng phải tỏ ra cứng rắn.

12. Nhu cương đúng lúc

Những kỹ sư kiểm thử giỏi luôn sẵn sàng đứng lên tranh luận khi cần thiết nhưng họ cũng biết khi nào nên dừng lại. Kỹ sư kiểm thử giỏi luôn cảm nhận được nỗi đau khi để vuột mất một vấn đề quan trọng nào đó. Họ cũng biết được không thể và không đáng để sửa tất cả các con bug. Họ cũng biết được rằng một số con bug sẽ được đưa ra thị trường cùng với sản phẩm để những con bug khác được sửa.

Hãy luôn nhớ rằng việc cung cấp thông tin là cốt lõi trong kiểm thử phần mềm. Vai trò của kỹ sư kiểm thử không phải là ra quyết định mà là cung cấp thông tin một cách đầy đủ để ban lãnh đạo có thể ra quyết định khi nào sửa bug, khi nào đưa sản phẩm ra thị trường và khi nào không.

[TH]: Hãy nhu cương đúng lúc!!

Hết phần 2 .

Trong phần cuối, mình sẽ giới thiệu đến các bạn những đặc điểm sẽ giúp các bạn áp dụng những đặc điểm trên một cách tối ưu nhất.

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

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

Xem thêm Việc làm Developer hấp dẫn trên TopDev

UAT và SIT

Bài viết được sự cho phép của To Thi Van Anh

Đầu năm chính là thời điểm mà thị trường nhân lực, tuyển dụng hoạt động vô cùng sôi nổi, có thể nói là sôi nổi nhất trong năm, vì chúng ta mới nghỉ Tết xong lại còn có một cục thưởng Tết nữa mà! Nhưng điều đó thì liên quan gì đến việc kia nhỉ?! Tưởng ko liên quan nhưng mà lại khá là liên quan đó, hehe.

1001 lý do mỗi doanh nghiệp cần có một website riêng cho mình

Bí kíp tạo website nhờ vào GitHub và Cloudflare

Khi mà bạn vừa nhận được cục kia, gọi là thưởng cho thành tích mà bạn đã đạt được trong năm vừa qua, có người thì hài lòng với con số mà có nhiều số 0 đằng sau 1 con số ‘vừa đủ’ nào đó, có người thì không hài lòng, cảm thấy “bất công”, chẳng xứng với công sức mình đã đóng góp, cống hiến.

Với những người cảm thấy hài lòng hoặc tạm hài lòng với con số đó thì họ lại muốn được nhiều hơn trong năm tới, người chưa hài lòng muốn tìm một nơi có con số kia khiến người ta có thể chấp nhận được hơn, cũng có những người không quan trọng các con số đó quá thì họ lại muốn tìm một môi trường làm việc thách thức hơn, hay nhàn nhã hơn, hoặc thoải mái hơn, phù hợp hơn về nhiều mặt, rồi hay vì những ức chế với mấy vị sếp, phải cố lấy thưởng xong rồi đi… và còn muôn vàn lý do khác nữa cho những người nhảy việc.

Và ở công ty hiện tại bên mình thời gian gần đây cũng không thể nào tránh khỏi cái thời điểm nhạy cảm này, khi mà đùng một cái bao nhiêu người báo nghỉ, liên hoan chia tay cứ rần rần như cái việc liên hoan gặp mặt cuối năm ấy! Hòa chung không khí nhộn nhịp ấy mình cũng lướt qua thị trường tuyển dụng xem tình hình ra sao. Mình quan tâm nhiều hơn đến các vị trí kiểm thử, và tìm hiểu luôn bên thị trường Thái (cơ bản cũng không khác VN nhưng mà mình muốn kiếm cơ hội đi Thái luôn ấy mà! ) hehe

Các tiêu chí về mặt chuyên môn, thì cũng đều yêu cầu người ứng tuyển có kinh nghiệm (mới tốt nghiệp hoặc là ít kinh nghiệm cũng có nhé), nắm chắc các kiến thức cơ bản về kiểm thử, tạo mới, và thực thi test case cho hệ thống, có kiến thức về cơ sở dữ liệu, kiến thức về lập trình ngoài ra cũng rất đánh giá cao các ứng viên năng động và thái độ tích cực trong công việc.

Liên quan đến chủ đề chính của bài viết này, trong nhiều các yêu cầu của các công ty mình đã xem qua thì đều dành luôn một dòng yêu cầu các ứng viên phải có đó chính là kiến thức về UAT và SIT. Thấy cũng hay hay nên mình tổng hợp lại kiến thức về hai cái này để chúng ta cùng ôn lạị nhé!

Bạn nào mà ôn ISTQB rồi thì chắc là nắm được cái này rồi, có thể đọc tiếp để xem mình có nhầm chỗ nào không rồi góp ý cho mình với nha!

UAT là gì?

UAT: là viết tắt của User Acceptance Test

UAT và SIT là hai mực độ kiểm thử phần mềm khác nhau.

UAT được thực hiện ở giai đoạn cuối cùng trong chu trình kiểm thử trước khi đưa sản phẩm ra thị trường, đưa đến tay người dùng. Việc này để đảm bảo là các chức năng của sản phẩm phần mềm xây dựng đáp ứng được các yêu cầu và nghiệp vụ mà hai bên (là bên cung cấp phần mềm và khách hàng) đã thống nhất với nhau trước đó.

Các loại UAT

UAT có hai loại chính là Alpha testing và Beta testing

Alpha testing: được thực hiện trong môi trường của developer, và thường do một team độc lập với team design nhưng vẫn trong cùng công ty nhé! Có thể là một nhóm các test engineer, hoặc các SQA.
Beta testing: hay còn được biết đến với tên gọi khác là field testing, được thực hiện 1 hoặc nhiều lần trên môi trường với các điều kiện thực tế mà nó sẽ được sử dụng chính thức và do chính các khách hàng là người sử dụng phần mềm. Beta test chỉ được thực hiện sau khi Alpha test đã hoàn thành. Ta vẫn thường nghe đến các bản beta của các loại game đó!

SIT là gì?

SIT: là viết tắt của System Integration Test

SIT được thực hiện để xác nhận rằng các chức năng đã được test độc lập khi kết hợp với nhau có thể hoạt động và đáp ứng yêu cầu chức năng. Các chức năng có thể hoạt động tốt khi chúng được test độc lập, nhưng khi tích hợp với các chức năng khác thì có thể xảy ra một số vấn đề khiến nó không hoạt động đúng yêu cầu. SIT được thực hiện để kiểm tra tính đúng đắn và sự toàn vẹn dữ liệu giữa các chức năng phụ thuộc nhau.

So sánh nho nhỏ giữa UAT vs. SIT

	SIT	UAT
Khái niệm	Kiểm thử giao tiếp giữa các module khi tích hợp với nhau	Kiểm thử để đảm bảo đáp ứng đúng yêu cầu của người dung
Mục đích	Mục đích là kiểm tra việc giao tiếp các module hệ thống với nhau	Kiểm tra dưới góc nhìn của người dung thực tế
Người thực hiện	Được thực hiện bởi dev và test	Được thực hiện bởi khách hàng, người dùng cuối
Cách thức thực hiện	Thực hiện theo quy trình, luồng xử lý dữ liệu và nghiệp vụ	Thực hiện ngẫu nhiên, có thể không theo một quy trình cụ thể bắt buộc nào.

Chi tiết về từng loại như sự cần thiết, lợi ích, áp dụng và triển khai trong dự án thực tế như thế nào các bạn có thể tìm hiểu thêm trên nhiều trang chia sẻ về testing nhé. Ở đây mình chỉ điểm một vài ý chính để chúng ta có thể hiểu và nhớ được khi mà nhắc đến mấy khái niệm này thôi. Hehe.

Chúc các bạn một tuần mới vui vẻ!

Bài viết gốc được đăng tải tại vananhtooo.wordpress.com

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

Xem thêm Việc làm Developer hấp dẫn trên TopDev

3 cách undo hoặc loại bỏ commit cơ bản: Reset, Revert và –amend

Undo hoặc xóa commit sai bằng Git revert, reset và --amend

Bài viết được sự cho phép của tác giả Lê Chí Dũng

Khi bạn vừa thêm một commit vào git tree, và chợt nhận ra commit vừa rồi bị sai, không hoàn chỉnh hoặc có vấn đề, bạn sẽ muốn “undo” commit hoặc loại bỏ nó. Ở đây mình sẽ giới thiệu 3 cách undo commit hoặc loại bỏ commit cơ bản: RESET, REVERT VÀ –amend

git reset là một lệnh mạnh mẽ trong Git cho phép bạn quay lại trạng thái trước đó của project. Git reset được sử dụng để di chuyển HEAD (con trỏ chỉ đến commit hiện tại) đưa nhánh hiện tại về một commit cụ thể trong lịch sử.

Nhảy HEAD về vị trí trước, khi commit sai bằng git reset như sau:

git reset --hard HEAD^

HEAD^ có ý nghĩa giống với HEAD~ hay @^, nghĩa là quay về trước 1 commit
Muốn quay về trước n commit, VD 5 commit thì có thể thay bằng HEAD~5.

git reset --hard|soft HEAD~2 -> Quay về trước 2 commit so với HEAD.

--hard có nghĩa là bỏ commit đi và bỏ cả những thay đổi chưa được commit trong working space. Khi này môi trường sẽ hoàn toàn “sạch sẽ” như thời điểm trước khi commit.
--soft có nghĩa là bỏ commit đi nhưng giữ nguyên những thay đổi chưa được commit trong working space. --soft hữu dụng khi bạn muốn giữ lại những thay đổi chưa commit cho lần commit tiếp theo.

git revert là một lệnh Git được sử dụng để tạo ra một commit mới nhằm đảo ngược thay đổi của commit trước đó. Không giống như git reset, git revert không thay đổi lịch sử Git. Nó tạo ra một commit mới có tác dụng ngược lại so với commit mà bạn muốn loại bỏ, giúp giữ nguyên lịch sử commit một cách rõ ràng và an toàn hơn.

Giả sử commit cũ có hash là (commit_hash) thì câu lệnh sẽ là:

git revert (commit_hash)

git commit --amend là một lệnh hữu ích trong Git giúp bạn sửa đổi commit gần đây nhất. Thay vì tạo một commit mới, --amend cho phép bạn ghi đè lên commit cuối cùng đã thực hiện.

git commit --amend

Lúc này git sẽ cho phép bạn viết lại commit message. Cách này hay dùng khi muốn sửa commit message. Nếu bạn chỉ muốn add thêm file mà không muốn sửa commit message thi có thể dùng option --no-edit

# Đây là commit sai / thiếu git add home.php
git commit -m 'Add home'

# Nhận ra là add thiếu 1 file home.css và muốn thêm vào commit bên trên
git add home.css
git commit --amend --no-edit

3 cách bên trên đây có những trường hợp sử dụng cụ thể khác nhau

Muốn bỏ hoàn toàn một commit sai, dùng git reset
Muốn undo commit và để lại lịch sử, dùng git revert
Muốn thêm những thay đổi nhỏ không đáng kể và tránh bị lắt nhắt, dùng git commit --amend

Nguồn tham khảo: lcdung.top

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

Xem thêm Việc làm Developer hấp dẫn trên TopDev

React Router Cheatsheet và mọi thứ bạn cần biết (Phần 1)

react router cheasheet — React Router Cheatsheet và mọi thứ bạn cần biết (Phần 1)

Tác giả: Reed Barger

Nếu bạn đang xây dựng các ứng dụng React cho web, bạn sẽ cần sử dụng một router chuyên dụng để hiển thị các trang và điều hướng người dùng của bạn xung quanh chúng.

Đó là lý do tại sao hôm nay chúng ta sẽ xem xét bộ React applications – React Router.

Cài đặt React Router

Bước đầu tiên để sử dụng React Router là cài đặt package thích hợp. Về mặt kỹ thuật, chúng là ba gói khác nhau: React Router, React Router DOM và React Router Native.

Sự khác biệt chính giữa chúng nằm ở cách sử dụng. React Router DOM dành cho các ứng dụng web và React Router Native dành cho các ứng dụng di động được tạo bằng React Native.

Điều đầu tiên bạn cần làm là cài đặt React Router DOM bằng cách sử dụng npm:

npm install react-router-dom

Setup React Router cơ bản

Sau khi được cài đặt, có thể đưa thành phần đầu tiên vào để sử dụng bộ định tuyến React được gọi là BrowserRouter.

Lưu ý rằng có nhiều loại router react-router-dom cung cấp ngoài BrowserRouter nhưng ở đây sẽ không đi sâu vào phân tích. Nếu chúng ta muốn cung cấp các tuyến trong toàn bộ ứng dụng của mình, nó cần được bao bọc xung quanh toàn bộ cây thành phần của chúng ta. Đó là lý do tại sao bạn thường sẽ thấy nó được bao bọc xung quanh hoặc bên trong thành phần ứng dụng chính:

import { BrowserRouter as Router } from 'react-router-dom';

export default function App() {
  return (
    <Router>
      {/* routes go here, as children */}
    </Router>
  );
}

Đây là chức năng chính của BrowserRouter: để có thể khai báo các tuyến đường riêng lẻ trong ứng dụng.

Tuyển dụng React lương cao không yêu cầu KN

Route Component

Bắt đầu bằng khai báo các router trong Router component là các tuyến con. Bạn có thể khai báo bao nhiêu routes tùy thích và cần cung cấp ít nhất hai props cho mỗi route path và component (hoặc render):

import { BrowserRouter as Router, Route } from 'react-router-dom';

export default function App() {
  return (
    <Router>
      <Route path="/about" component={About} />
    </Router>
  );
}

function About() {
  return <>about</>   
}

Prop path hỗ trợ chỉ định đường dẫn của ứng dụng mà một route nhất định được đặt.

Các props render hoặc component được sử dụng để hiển thị một thành phần cụ thể cho đường dẫn của chúng ta.

Các props component chỉ có thể nhận tham chiếu đến một thành phần nhất định, trong khi render thường được sử dụng nhiều hơn để áp dụng một số logic có điều kiện để hiển thị một thành phần này hay thành phần khác. Để kết xuất, bạn có thể sử dụng tham chiếu đến một thành phần hoặc sử dụng một hàm:

import { BrowserRouter as Router, Route } from "react-router-dom";

export default function App() {
  return (
    <Router>
      <Route path="/" render={() => <Home />} />
      <Route path="/about" component={About} />
    </Router>
  );
}

function Home() {
  return <>home</>;
}

function About() {
  return <>about</>;
}

Cần lưu ý rằng bạn có thể bỏ prop render hoặc component hoàn toàn và sử dụng component mà bạn muốn liên kết với một route nhất định khi là route con:

import { BrowserRouter as Router, Route } from "react-router-dom";

export default function App() {
  return (
    <Router>
      <Route path="/about">
        <About />
      </Route>
    </Router>
  );
}

Cuối cùng, nếu muốn một thành phần (chẳng hạn như thanh điều hướng) hiển thị trên mọi trang, hãy đặt nó nằm trong trình duyệt của router, nhưng ở trên (hoặc bên dưới) các routes đã khai báo:

import { BrowserRouter as Router, Route } from "react-router-dom";

export default function App() {
  return (
    <Router>
      <Navbar />
      <Route path="/" component={Home} />
      <Route path="/about" component={About} />
    </Router>
  );
}

function Navbar() {
  // visible on every page
  return <>navbar</>
}

function Home() {
  return <>home</>;
}

function About() {
  return <>about</>;
}

Bỏ túi cheatsheet dành cho Python newbie

Tất tần tật các Frontend cheatsheets tốt nhất

Chuyển đổi thành phần

Khi bắt đầu thêm multiple routes, bạn sẽ nhận thấy một số vấn đề. Giả sử chúng ta có một route cho trang chủ và trang giới thiệu. Mặc dù chỉ định hai đường dẫn khác nhau, ‘/’ và ‘/ about’, khi truy cập trang giới thiệu, bạn vẫn sẽ thấy cả thành phần home và about.

Có thể khắc phục sự cố này bằng phần mềm hỗ trợ chính xác, trên route chính để đảm bảo rằng router của chúng tôi khớp chính xác với đường dẫn ‘/’ thay vì ‘/ about’:

import { BrowserRouter as Router, Switch, Route } from "react-router-dom";

export default function App() {
  return (
    <Router>
      <Navbar />
      <Switch>
        <Route exact path="/" component={Home} />
        <Route path="/about" component={About} />
      </Switch>
    </Router>
  );
}

Khi nói đến chuyển đổi giữa các routes khác nhau mà router sẽ hiển thị, trên thực tế, có một thành phần chuyên dụng mà bạn nên sử dụng nếu bạn có nhiều routes trong router của mình và đó là việc chuyển đổi thành phần.

Thành phần chuyển đổi nên được bao gồm trong router và có thể đặt tất cả các routes bên trong nó:

import { BrowserRouter as Router, Switch, Route } from "react-router-dom";

export default function App() {
  return (
    <Router>
      <Navbar />
      <Switch>
        <Route exact path="/" component={Home} />
        <Route path="/about" component={About} />
      </Switch>
    </Router>
  );
}

Switch sẽ xem xét tất cả các child routes và hiển thị cái đầu tiên có đường dẫn khớp với URL hiện tại. Thành phần này là những gì bạn muốn sử dụng trong hầu hết các trường hợp cho hầu hết các ứng dụng, vì sẽ có nhiều routes và nhiều plate pages trong ứng dụng của mình nhưng chỉ muốn hiển thị một trang tại một thời điểm.

Nếu vì lý do nào đó bạn muốn nhiều trang được hiển thị cùng một lúc, bạn có thể cân nhắc không sử dụng thành phần chuyển đổi.

Xem thêm Bỏ túi cheatsheet dành cho Python newbie

404 route

Nếu chúng ta cố gắng đi đến một route không tồn tại trong ứng dụng thì sẽ thấy gì? Bạn sẽ không nhìn thấy bất cứ điều gì nếu không có một route tương ứng với điều đó. Làm thế nào để tạo một catch-all route?

Nếu người dùng cố gắng truy cập một trang không có route xác định, bạn cũng có thể tạo một route và sau đó đặt đường dẫn thành dấu hoa thị *:

import { BrowserRouter as Router, Switch, Route } from "react-router-dom";

export default function App() {
  return (
    <Router>
      <Navbar />
      <Switch>
        <Route path="/" component={Home} />
        <Route path="/about" component={About} />
        <Route path="*" component={NotFound} />
      </Switch>
    </Router>
  );
}

function NotFound() {
  return <>You have landed on a page that doesn't exist</>;
}

Điều này sẽ phù hợp với bất kỳ nỗ lực nào để truy cập một trang không tồn tại và có thể kết nối nó với một thành phần không tìm thấy để cho người dùng biết rằng họ đã “đến một trang không tồn tại”.

Phỏng dịch theo bài viết gốc tại freecodecamp.org

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

Xem thêm tuyển dụng IT hấp dẫn trên TopDev

TestNG tổng hợp qua các câu hỏi khi đi phỏng vấn

Bài viết được sự cho phép của tác giả To Thi Van Anh

Tại vì là đã có rất nhiều các bài viết nói rất kỹ về TestNG này rồi, nếu muốn tìm hiểu thì mọi người chỉ cần tìm kiếm trên Google với những từ khóa liên quan đến TestNG, thì có hàng trăm nghìn kết quả được tìm ra chỉ trong vài giây luôn, và thế là các bạn đã có thể thoải mái đọc hiểu về bạn này.

Chính vì thế mà mình không nói lại nữa, mà sẽ ôn tập theo hình thức là đưa ra các câu hỏi mà khi phỏng vấn có thể là bạn sẽ gặp phải. Hehe, chỉ là dễ gặp thôi nha, quan trọng ở đây vẫn là lượng kiến thức hữu ích cho các bạn để có thể nắm được và vận dụng thành thạo trong các project của mình!

A/B testing và những tiêu chí chính để đánh giá sự thành công của ASO

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

Hi vọng sẽ giúp ích được cho các bạn.

#1. Ý nghĩa của file <testNG.xml> là gì? Hay sử dụng file <testNG.xml> này có tác dụng gì?

Trong dự án Selenium TestNG, ta sử dụng file <testNG.xml> để cấu hình các bộ test đã hoàn thành vào trong một file cụ thể. File này giúp cho chúng ta gom nhóm các bộ test case và các tham số của bộ đó một cách dễ dàng trong file đó. Đồng thời cũng cung cấp khả năng tạo các tập hợp con cho các test hoặc tách thời gian gian chạy các test theo cấu hình.

Một số công việc ta có thể nhóm trong file .xml này như:

Có thể cấu hình bộ test bao gồm nhiều test case cụ thể nào đó để chạy từ một nơi duy nhất. Như cho phép bộ test này chỉ run test trên FireFox, hoặc chỉ trên IE thôi.
Có thể bao gồm hoặc không bao gồm các test method được thực thi việc test ứng dụng
Có thể chỉ định cụ thể một nhóm nào sẽ được chạy hoặc không
Có thể sử dụng các tham số cho các test, như việc set tham số để chọn trình duyệt sẽ sử dụng này, linh động trong việc kết nối cơ sở dữ liệu…
Bạn cũng có thể cấu hình để chạy test song song cho ứng dụng, ví dụ như cấu hình để chạy bộ test nào đó chạy cùng một lúc trên các trình duyệt là FireFox, Chrome và IE chẳng hạn.
Ngoài ra có thể định nghĩa các listener cho các test. Hiểu về listener các bạn tham khảo ở đây nhé! http://testng.org/doc/documentation-main.html#testng-listeners.

#2. Bạn sử dụng tham số trong file .xml và trong các test case như thế nào?

Chúng ta có thể định nghĩa các tham số trong file .xml theo cú pháp dưới đây:

<parameter name="browser" value="FireFox" />

Ví dụ:

<suite name="My suite">
      <parameter name="first-name"  value="Cedric"/>
      <test name="Simple example">
 <-- ... -->

Bên cạnh đó, ta cũng sẽ sử dụng các parameter theo cú pháp dưới đây trong test case:
Ở đây, thuộc tính name định nghĩa tên của tham số, thuộc tính value là giá trị của thuộc tính đó.

@Parameters ({"browser"})

Ví dụ:

@Parameters({ "first-name" })
@Test
public void testSingleString(String firstName) {
     System.out.println("Invoked testString " + firstName);
     assert "Cedric".equals(firstName);
}

#3. Trong trường hợp một test case có nhiều method @Test, nhưng khi thực thi test case thì lại không muốn run một method test nào đó, bạn có thể làm gì để giải quyết vấn đề này?

Ở đây chúng ta chỉ cần thêm tên method mà ta không muốn chạy vào trong tag exclude trong file <testNG.xml> theo cú pháp hướng dẫn dưới đây nhé:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
<suite name="Test Exclusion Suite">
   <test name="Exclusion Test" >
      <classes>
          <class name="Your Test Class Name">
              <methods>
                   <exclude name="Tên test method mà bạn muốn Exclude"/>
              </methods>
          <class>
       </classes> 
   </test>
</suite>

#4. Sắp xếp thứ tự các thẻ dưới đây theo cấp cha-con trong file <testNg.xml>:

<test>
 <suite>
 <class>
 </methods>
 </classes>

Trong file <testNg.xml> ta có:

Tag cha trong file testNg.xml là tag <suite>

Trong tag <suite> có thể bao gồm một hoặc nhiều tag <test>

Trong tag <test> có thể bao gồm tag <classes>

Tag <classes> có thể bao gồm một hoặc nhiều tag <class>

Tag <class> chứa các tag <method> – nơi mà chúng ta định nghĩa các test method có thể được thực thi hoặc là không.

Do đó, thứ tự các thẻ theo cấp cha-con được sắp xếp như sau:

<suite>
  <test>
    </classes>
      <class>
        </methods>

#5. Bạn set thứ tự ưu tiên của các @Test method như thế nào? Nó có ý nghĩa gì?

Trong số các test case cho ứng dụng web mà chúng ta có, ta có thể thực hiện gắn độ ưu tiên thực hiện cho các test case ấy bằng cách thêm tham số vào trong anotation @Test theo cú pháp sau:

@Test(priority=0)

Bằng cách sử dụng việc này ta có thể dễ dàng điều khiển thứ tự thực thi các test case theo ý muốn, hoặc theo yêu cầu nhất định nào đó. Cụ thể với những test case được gắn trọng số priority = 0 thì sẽ được ưu tiên chạy trước những test case có trọng số bằng 1, rồi 2…

#6. Kể tên ít nhất 5 assertion của testNG mà chúng ta có thể sử dụng trong Selenium webdriver

Có nhiều loại assertion khác nhau trong testNG, dưới đây là một số loại assert mà mình đã dùng như:

assertEquals
assertNotEquals
assertTrue
assertFalse
assertNull
assertNotNull

#7. Bạn hãy đưa ra một số cách khác nhau để run TestNG?

Chúng ta có thể run TestNG bằng một số cách sau:

Thực hiện run trực tiếp từ Eclipse IDE
Thực hiện run thông qua IntelliJ’s IDEA IDE
Thực hiện run với ant build tool
Hoặc run từ command line

#8. Để disable một test trong testNG bạn làm cách nào?

Để disable một test case, ta có thể thêm tham số enable vào trong annotation @Test theo cú pháp dưới đây:

@Test(enabled = false)

#9. Parametric testing trong TestNG là gì?

Parametric testing cho phép chúng ta chạy lại cùng một test case nhưng với các giá trị test data khác nhau. Ví dụ với trường hợp đăng nhập, ta có thể đăng nhập với nhiều dữ liệu test có cặp username và pass word khác nhau. TestNG cho phép chúng ta có thể truyền các tham số vào trong các test method bằng hai cách dưới đây:

Sử dụng trong file TestNG.xml
Với Data providers.

#10. Các cách để xuất báo cáo trong TestNG là gì?

TestNg cung cấp hai cách giúp chúng ta có thể xuất báo cáo, đó là:

Sử dụng Listeners: một class listenter sẽ thực thi một interface là org.testng./TestListener. Trong khi run test, TestNg sẽ gửi thông tin tới các class đó mỗi khi các test case đó ở các trạng thái như: est begins, finishes, skips, passes hoặc fails.
Sử dụng Reporters: đối với một class reporting, nó cũng sẽ thực thi cái interface là org.testng/Reporter. Khi mà tất cả các test suite chạy xong, những class này sẽ được gọi đến, lúc này tất cả các thông tin của các đối tượng trong toàn bộ quá trình thực hiện test sẽ được gửi đến class này.

#11. Liệt kê những ưu điểm của TestNG so với Junit?

Dưới đây là một số ưu điểm của TetsNG so với Junit:

TestNG có các anotation logic hơn và dễ hiểu hơn
TestNG class không yêu cầu bắt buộc khai báo @BeforeClass và @AfterClass.
Trong Selenium TestNG không có các ràng buộc về method name
TestNG hỗ trợ thêm một số annotations:
- @Before/AfterSuite,
- @Before/AfterTest, and
- @Before/AfterGroup.
Trong Selenium TestNG project, thì bạn không cần phải extend class nào
Trong TesNG, bạn có thể thực hiện chạy song song các test case
TestNG hỗ trợ bạn gom nhóm các test case, điều mà Junit không làm được.
Từ các nhóm, TestNG cho phép bạn chạy các test case nằm trong các nhóm ấy.
TestNG cho phép bạn xác định các test case phụ thuộc.

Nói chung là kiến thức thì rộng lớn lắm, bọn mình cần phải làm nhiều thì mới gặp đến những trường hợp mà bình thường chả bao giờ đả động đến luôn. Mấy câu hỏi này thực ra là cũng chẳng có gì là khó, và nó cũng còn nhiều lắm hehe. Nếu các bạn quan tâm thì phần sau mình sẽ cố gắng chọn lọc và đưa vào những câu hỏi nâng cao hơn.

Không khí tết tràn ngập khắp nơi rồi, mình cũng a dua theo dân tình đi làm mẻ mứt dừa để tết ngồi gặm cho mỏi răng đây!

Bài viết gốc được đăng tải tại vananhtooo.wordpress.com

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

Xem thêm Việc làm ngành IT hấp dẫn trên TopDev

Lập trình viên nên HỌC NHIỀU HƠN một ngôn ngữ lập trình?

Bài viết được sự cho phép của blogchiasekienthuc.com

Chào anh em, có lẽ việc học một ngôn ngữ lập trình nào đó là bắt buộc nếu như anh em có ý định làm về IT nói chung, hay làm về lập trình nói riêng.

Thực ra nếu dùng từ “bắt buộc” là không đúng, vì thực tế có nhiều hướng đi trong ngành IT không yêu cầu anh em phải nắm rõ một ngôn ngữ lập trình nào đó.

Nhưng cũng giống như việc ăn cơm, nếu như anh em biết một ngôn ngữ lập trình thì nó cũng giống như kiểu anh em có một đôi đũa trong tay vậy, và mọi việc sẽ trở nên dễ dàng hơn rất nhiều.

10 lý do cho thấy tại sao bạn nên theo học ngôn ngữ lập trình Java

4 ngôn ngữ phát triển game indie phổ biến

Nhưng liệu lập trình viên có nên học nhiều hơn một ngôn ngữ lập trình hay không?

Đã có rất nhiều ý kiến trái chiều xoay quanh vấn đề này, vậy nên trong bài viết ngày hôm nay mình sẽ đưa ra 5 lý do để các bạn nên học nhiều hơn một ngôn ngữ lập trình.

Do là ý kiến chủ quan của mình nên có thể đúng với người này, không đúng với người khác mong anh em góp ý nha.

#1. Rèn luyện khả năng tiếp cận công nghệ mới

Anh em làm về IT thì biết rồi đấy, công nghệ mới thay đổi liên tục từng giây. Nhiều khi chưa kịp làm chủ công nghệ này thì đã có công nghệ khác tốt hơn và tối ưu hơn rồi.

Tất nhiên, việc chạy theo công nghệ không phải lúc nào cũng tốt, nhưng ngược lại, cứ khư khư mãi một công nghệ cũ cũng là không nên.

Mà công nghệ mới thường được phát triển dựa trên các ngôn ngữ lập trình khác nhau, nó được cập nhật hàng tuần chứ không muốn nói là hàng ngày.

Mình lấy ví dụ bạn rất giỏi về Java, nhưng lại không biết gì về NodeJS thì các công nghệ mới được phát triển từ NodeJS bạn sẽ tiếp cận khó khăn hơn, vì bạn chưa có nền tảng về NodeJS.

Tất nhiên là nếu nắm được phương pháp và cách tiếp cận thì cũng không mất quá nhiều thời gian, nhưng trong nhiều trường hợp gấp rút (dự án đang rất cần) thì một chút thời gian đó thôi cũng có thể quyết định doanh thu của dự án.

Chính vì vậy, việc học một ngôn ngữ lập trình (ở mức cơ bản, nắm được cú pháp, biết cách dùng) đôi khi sẽ giúp bạn làm chủ công nghệ được nhanh hơn.

#2. Có thêm “vũ khí”

Hồi sinh viên chúng ta thường nghe thầy cô bảo “Ngôn ngữ lập trình chỉ là công cụ thôi, cái quan trọng là tư duy thuật toán”.

Thì đúng là như vậy, ngôn ngữ lập trình chỉ là công cụ ! Nhưng nếu bạn đã đi làm rồi thì bạn sẽ phải bổ sung câu trên như sau:

“Ngôn ngữ lập trình chỉ là công cụ thôi, cái quan trọng là tư duy thuật toán. Nhưng nếu biết dùng và dùng đúng công cụ thì bài toán đôi khi lại đơn giản hơn rất nhiều”

Thực tế là như vậy anh em à, việc anh em triển khai một thuật toán hồi đi học trong một dự án thực tế thì gần như là rất hiếm. Chủ yếu là sử dụng các phương thức, các hàm có sẵn hoặc thay đổi chúng sao cho phù hợp với bài toán.

Có nhiều bài toán nếu dùng Java có khi cả ngày không ra, nhưng ngược lại khi dùng Python thì lại cho kết quả rất nhanh hoặc ngược lại.

Nhưng để đạt được đến trình độ mà bài toán nào thì sử dụng ngôn ngữ nào là hiệu quả nhất sẽ đòi hỏi anh em phải hiểu về ngôn ngữ và có kinh nghiệm làm việc với nó, chứ không phải đơn thuần học qua qua là làm được ngay.

#3. Dễ dàng thích nghi với thay đổi hơn

Như mình đã trình bày bên trên, việc học nhiều hơn một ngôn ngữ lập trình sẽ giúp bạn tiếp cận công nghệ mới dễ dàng hơn.

Và thực tế trong quá trình đi làm thì có thể các bạn sẽ phải làm nhiều dự án khác nhau, mỗi dự án sử dụng một công nghệ khác nhau.

Nếu chỉ khư khư một công nghệ nào đó thì mình đảm bảo là các bạn sẽ rất khó để “mở tư duy”, để tiếp cận với các công nghệ khác.

Trong khi khả năng thích nghi gần như là một kỹ năng bắt buộc phải có của một lập trình viên hiện nay, vì không phải công ty nào cũng có đủ nguồn lực để đáp ứng kịp thời theo dự án.

Lập trình viên buộc phải tiếp cận và thích nghi nhanh với công nghệ mới để cho kịp dự án. Đây là sự thật mà anh em chấp nhận khi đi làm, và tất nhiên nếu bạn có nền tảng về các ngôn ngữ lập trình khác nhau thì việc thích nghi sẽ dễ dàng thôi.

#4. Thêm nhiều cơ hội việc làm

Quay lại với câu chuyện cơ hội nghề nghiệp thì thầy cô đại học thường nói: “Người ta chỉ thuê người giỏi về một thứ gì đó, chứ chẳng bao giờ đi thuê một đứa mà cái gì cũng biết một chút để chẳng biết dùng vào đâu.”

Mình phải công nhận là đúng, vì thực tế mình đi làm và đi thực tập gặp nhiều ông bảo cái gì cũng biết nhưng thực tế thì chẳng làm được gì !

Nhưng điều này có đúng với tất cả mọi người không? Theo mình thì là không, vì đôi khi biết nhiều (hiểu về những gì mình biết) có khi còn có nhiều cơ hội việc làm hơn.

Nhất là trong thị trường lao động như hiện này, các bạn sinh viên mới ra trường (những bạn giỏi xuất sắc mình không nói) còn những bạn cũng bình thường mà nếu lười tìm tòi, học hỏi cái mới thì “chết” là chắc. Chết là chết đói ấy

#5. Nâng cao trình độ

Chắc đọc đến đây thì nhiều anh em sẽ nghĩ tại sao mình không để lý do này lên đầu tiên. Rõ ràng đây mới là một lý do quan trong nhất mà !

Nhưng thực tế thì không hẳn là như vậy, không hẳn việc học nhiều ngôn ngữ lập trình là sẽ nâng cao trình độ đâu anh em à.

Nếu bạn không có nền tảng tốt về một ngôn ngữ lập trình nào đó, mà cứ học theo kiểu mỗi thứ biết một ít, mỗi ngôn ngữ lập trình học một ít… thì anh em có học 10 ngôn ngữ hay 20 ngôn ngữ thì cũng thế cả thôi.

Chính việc học và tìm hiểu về nhiều ngôn ngữ lập trình đôi khi nó “ngốn” mất thời gian để anh em chuyên sâu vào một công nghệ nào đó.

Nói vậy thì có vẻ học nhiều hơn một ngôn ngữ lập trình là sai vì nó không giúp anh em nâng cao trình độ?

Không, chắc chắn là không phải là như vậy, quan trọng là anh em học thế nào thôi. Nếu biết trau dồi chuyên môn lại vừa học thêm công nghệ, ngôn ngữ mới thì đảm bảo trình độ của anh em sẽ lên rất nhanh.

Quan trọng vẫn là phương pháp thôi: Phương pháp mà mình gợi ý cho anh em là hãy tập trung học thật chuyên sâu vào một ngôn ngữ, sau đó mở rộng thêm các ngôn ngữ khác ở mức độ cơ bản !

#6. Lời kết

Vâng, đó là một vài những quan điểm cá nhân của mình về việc liệu có nên học nhiều hơn một ngôn ngữ lập trình lập trình hay không?

Đặc biệt là những anh em đã đi làm được 1 – 2 năm rồi thì mình nghĩ là anh em nên học thêm một vài ngôn ngữ lập trình khác, ngoài cái mà anh em đang dùng.

Hi vọng là bạn sẽ thích bài viết này. Xin chào và hẹn gặp lại anh em trong các bài viết tiếp theo nha !

CTV: Nguyễn Đức Cảnh – Bài viết gốc tại blogchiasekienthuc.com

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

Truy cập ngay việc làm IT đãi ngộ tốt trên TopDev

Các đặc điểm của một kỹ sư kiểm thử giỏi (Phần 1)?

Bài viết được sự cho phép của vntesters.com

Đâu là những đặc điểm của một kỹ sư kiểm thử giỏi? Mình muốn giỏi thì phải làm sao? Đó cũng chính là băn khoăn của mình cách đây vài năm (và bây giờ vẫn vậy). Và trong một lần tình cờ mình đọc được một bài viết khá đầy đủ và sâu sắc đã giải đáp được phần lớn câu hỏi ở trên và hôm nay mới có dịp chia sẻ bài viết này với cộng đồng kỹ sư kiểm thử phần mềm Việt Nam.

19 tips cho các kỹ sư phần mềm hữu ích trong 2024

10 bước để bắt đầu áp dụng kiểm thử tự động vào dự án

“The hallmarks of great tester” được viết bởi Michael J Hunter – một người có hơn 20 năm kinh nghiệm làm lập trình và kiểm thử ở Microsoft. Michael J Hunter chia sẻ về những đặc điểm của một kỹ sư kiểm thử giỏi và cách ứng dụng chúng trong công việc. Vâng, rất thực tiễn. Tất cả chúng ta đều muốn học một cái gì đó mà có thể ứng dụng ngay được.

Mình sẽ lần lượt giới thiệu với các bạn 20 đặc điểm làm nên một kỹ sư kiểm thử giỏi. Sao? Bạn nói dài quá hả? Mình đồng ý. Tuy nhiên, trong 20 đặc điểm đó chúng ta sẽ bắt gặp đâu đó hình ảnh của mình trong đó và cả những điều mà chúng ta có thể chưa biết hoặc đã biết nhưng làm chưa tốt và chỉ riêng điều đó thôi cũng đáng để chúng ta đọc 20 đặc điểm này.

OK. Bắt đầu thôi.

1. Cân bằng

Những kỹ sư kiểm thử giỏi luôn nhận biết được tầm quan trọng của việc cân bằng trong tất cả các công việc mình làm cũng như luôn biết cách cân bằng sao cho hợp lý trong những tình huống mà họ gặp phải.

Thật khó để định nghĩa thế nào là “hợp lý” tuy nhiên bạn phải biết cân bằng giữa ham muốn đào sâu tìm hiểu vấn đề với yêu cầu phải ra quyết định cũng như nhu cầu hoàn thành công việc.

[TH] Thực vậy, mình thấy khả năng cân bằng trong công việc là rất quan trọng. Mình đã gặp nhiều bạn kỹ sư kiểm thử nhiều khi do quá tập trung việc nghiên cứu tài liệu, sửa lỗi scripts hay tìm bug mà quên deadline của task, quên kiểm tra email, quên một cuộc họp, quên thư giãn, v.v. Cân bằng tốt sẽ giúp mình cảm thấy thoải mái và làm công việc bền vững hơn.

2. Sự tò mò

Sự tò mò là lí do tại sao những kỹ sư kiểm thử giỏi luôn hỏi, tại sao lại như thế này mà không phải thế kia. Họ biết rằng việc hiểu cách một chương trình/ứng dụng chạy sẽ giúp họ hiểu được cách nó tương tác với những chương trình/ứng dụng khác và đó là cách giúp họ tìm ra bug. Một kỹ sư kiểm thử giỏi không những thể hiện sự tò mò trong phạm vi công việc của mình mà còn trong tất cả các mặt khác của cuộc sống như cách bộ phận marketing hoạt động như thế nào hay như chiếc cần cẩu được vận hành như thế nào, v.v

Tuy nhiên nếu bạn vốn không phải tuýp người tò mò thì bạn vẫn có thể thể hiện sự tò mò bằng cách đặt câu hỏi càng nhiều càng tốt trong những vấn đề bạn gặp phải. Một lưu ý là sự tò mò tuy không xấu nhưng cách bạn tò mò có thể làm phiền người khác. Cho nên lời khuyên là bạn phải cho người khác thấy rằng bạn chỉ muốn tìm hiểu tính hợp lý của vấn đề chứ không chỉ đơn thuần là đặt câu hỏi cho mỗi quyết định của họ.

[TH] Trong quá trình làm việc, mình nhận thấy có nhiều bạn luôn ngại hỏi? Nguyên do thì đa dạng nhưng đa phần là vì các bạn đó nghĩ hỏi là dở, hỏi là làm phiền người khác, v.v và các bạn đó một số thì chọn giải pháp “im lặng là vàng”, một số thì giả định vấn đề, một số khác âm thầm tự tìm hiểu. Những cách đó có thể cũng có thể mang lại kết quả nhất định tuy nhiên đó không phải là lựa chọn thường xuyên của những kỹ sư kiểm thử giỏi.

3. Thực hành thường xuyên

Một kỹ sư kiểm thử giỏi luôn kiểm thử toàn bộ sản phẩm chứ không chỉ dừng lại ở tính năng của sản phẩm. Một kỹ sư kiểm thử giỏi còn kiểm thử luôn cả những sản phẩm khác. Một kỹ sư kiểm thử giỏi kiểm thử luôn sách, tủ lạnh, bóng đèn, cửa v.v kiểm thử tất cả mọi thứ trong cuộc sống mà kích thích trí tò mò của họ.

Thực ra thì cơ hội để thực hành công việc kiểm thử không hề hiếm. Bạn có thể kiểm thử máy bán hàng tự động, cửa tự động, lò vi sóng hay bất cứ thứ gì. Hãy thử hình dung ra những tình huống mà những thứ đó có thể hoạt động sai và rồi thử xem bạn có thể khiến nó hoạt động sai không. Kiểm thử mọi thứ mà bạn có thể nghĩ ra nhưng đừng sa đà quá.

[TH]: Lời khuyên này nghe có vẻ ngớ ngẩng nhưng đó là một trong những cách hiệu quả và tiết kiệm nhất để luyện cho bạn khả năng “nhạy” với bug. Tin mình đi, sau một thời gian luyện tập, khả năng tìm bug của bạn trong công việc sẽ cải thiện đáng kể đồng thời cũng đừng ngạc nhiên khi ngày càng có nhiều người khen bạn “hâm”
* Lưu ý nhỏ: Không nên luyện tập kiểm thử trên những sản phẩm có độ nguy hiểm cao như…thang máy chẳng hạn.

4. Lắc léo

Một kỹ sư kiểm thử giỏi luôn hình dung ra nhiều cách lắc léo khác nhau để tấn công sản phẩm thay vì chỉ dựa vào checklist hay những hướng dẫn có sẵn. Một kỹ sư kiểm thử giỏi sẽ luôn tìm được những con bug để khiến cho lập trình viên phải đặt câu hỏi “Ai lại đi làm trò vớ vẩn đó” và khi đó họ sẽ trả lời rằng là vì họ có thể làm được, hacker cũng sẽ làm được và người dùng cuối cũng có thể làm.

Nếu bạn không có tính lắc léo bẩm sinh hoặc đã lắc léo rồi nhưng cảm thấy chưa đủ thì đây là cách để bạn luyện: Hãy nghĩ về những thứ có thể khiến cho sản phẩm chạy sai. Bạn có thể bắt từ đầu tài liệu đặc tả nhưng đừng chỉ dừng lại ở đó. Hãy thử với những cách tiếp cận khác nhau (chẳng hạn như HICCUPP), những kỹ thuật khác nhau lên sản phẩm và tập trung vào điểm giao nhau giữa những chức năng. Đó là những nơi mà một kỹ sư kiểm thử giỏi thường dành thời gian vào. Hãy tinh nghịch một chút nhưng phải luôn nắm được những tính năng yêu cầu của sản phẩm. Bug nào cũng là bug nhưng những con bug quan trọng nhất là những con bug có thể gây ảnh hưởng đến người dùng.

5. Luôn phấn khích khi tìm được bug

Kỹ sư Kiểm thử giỏi luôn nhìn bug bằng con mắt đáng yêu. Kỹ sư kiểm thử giỏi luôn thường xuyên tìm gặp lập trình viên để “khoe” những con bug tuyệt đỉnh mà mình vừa mới tìm được trong code của họ. Những kỹ sư kiểm thử giỏi hào hứng “chém gió” về những con bug của mình với những kỹ sư kiểm thử khác và sẵn lòng lắng nghe những kỹ sư kiểm thử khác “chém gió”. Và khi đi làm về nhà, cả nhà đều có thể biết được hôm đó kỹ sư kiểm thử nhà mình có tìm được con bug nào xịn không.

Để làm tốt việc đó, bạn phải học cách luôn vui vẻ và sẵn lòng tìm bug và bị tìm bug. Khi bạn tìm được bug trong code của người lập trình viên hay trong tài liệu đặc tả sếp viết hãy luôn nhớ lại cảm giác khi mình bị người khác tìm được bug. Hãy luôn ghi nhớ mục tiêu của kỹ sư kiểm thử giỏi là giúp đồng nghiệp cảm thấy tốt hơn bằng cách tìm ra những lỗi mà họ đã phạm phải chứ không phải là xát muối vào nỗi đau của họ.

Hãy luôn luôn ghi nhớ:
– Tìm được bug: tuyệt.
– Khiến cho lập trình viên đau đầu với con bug đó: càng tuyệt.
– Giữ mối quan hệ tốt với lập trình viên: vô giá.

[TH] Phần nhiều thì kỹ sư kiểm thử đều (rất) phấn khích khi tìm được bug, tuy nhiên cũng có một số ít lại tỏ ra thờ ơ với những con bug mình tìm được ?!?

6. Niềm đam mê đối với khách hàng

Tác giả chia sẻ một trong những cách có được niềm đam mê đối với khách hàng/người dùng là hãy “thấu hiểu nỗi đau của họ”. Hãy đánh giá về những ảnh hưởng của con bug mà bạn tìm lên khách hàng/người dùng của bạn. Hãy tìm hiểu xem khách hàng/người dùng của bạn chia sẻ những tâm tư nguyện vọng gì trên các diễn đàn, blog hoặc bạn cũng có thể gặp trực tiếp họ để tìm hiểu xem những vấn đề khó khăn mà họ đang gặp phải. Nếu có thể hãy thử sử dụng chính sản phẩm mình đang kiểm thử để đánh giá sản phẩm. Điều cốt lõi là “thấu hiểu nỗi đau của khách hàng”

[TH] Đây là một ý rất hay mà mình rất tâm đắc – Niềm đam mê đối với khách hàng, thấu hiểu khách hàng. Đã bao nhiêu lần kỹ sư kiểm thử mừng ra mặt khi sản phẩm không được đưa ra thị trường đúng hẹn do một số bug quan trọng chưa kịp fix. Kỹ sư kiểm thử cảm thấy tự hào, cảm thấy “vip” nhưng cũng nên hiểu rằng việc chậm trễ trên là không ai muốn và việc đó cũng gây tổn hại cho khách hàng (tài chính, danh tiếng) và cũng có thể cả kỹ sư kiểm thử nữa. Trễ deadline, khách hàng đòi tăng ca, trễ deadline, khách hàng mất khách hàng của họ, sản phẩm thất bại, đóng dự án v.v. Hãy luôn tỏ ra chuyên nghiệp vì bạn sẽ không biết khi nào thì những thứ dường như chẳng liên quan gì đến mình sẽ gây ảnh hưởng đến chính mình.

Mình vừa giới thiệu xong phần đầu tiên (trong 3 phần) về những đặc điểm của một người kỹ sư kiểm thử giỏi. Trong phần 2 của bài viết, mình sẽ giới thiệu đến các bạn cách mà một kỹ sư kiểm thử giỏi ứng dụng những điểm trên vào công việc.

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

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

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Git stash là gì? 8 lệnh git stash hữu ích và cách dùng

Tổng hợp cách dùng lệnh git stash hiệu quả

Git Stash là một khái niệm và công cụ dùng để quản lý các chuỗi thay đổi (stack of changes) trong Git, thường được sử dụng trong các dự án phần mềm phức tạp. Nó giúp phát triển và duyệt qua các thay đổi theo cách có tổ chức hơn, đặc biệt là khi làm việc với nhiều nhánh và nhiều yêu cầu pull (pull requests). Dưới đây là một số thông tin chi tiết về Git Stack.

Khái niệm Git stash

Git Stash là gì?

Git Stash giúp bạn tạo ra và quản lý một loạt các thay đổi (commits) liên quan đến nhau một cách dễ dàng. Thay vì chỉ có một chuỗi commit thẳng đứng, bạn có thể có nhiều nhánh nhỏ chứa các thay đổi liên quan. Điều này giúp bạn sắp xếp và hệ thống được các thay đổi theo thứ tự logic, dễ dàng duyệt qua và xem lại từng thay đổi một cách tuần tự.

Trong working directory, để bạn có thể chuyển đổi sang một nhánh khác hoặc thực hiện các công việc khác mà không mất đi những thay đổi chưa hoàn thành. Sau khi hoàn thành công việc khác, bạn có thể áp dụng lại các thay đổi đã lưu trữ một cách dễ dàng.

Cách thức hoạt động của Git Stash

Lưu trữ các thay đổi: Khi bạn chạy lệnh git stash, Git sẽ lưu lại tất cả các thay đổi trong working directory và index (staging area) vào một khu vực lưu trữ tạm thời gọi là stash stack. Working directory và index của bạn sẽ trở về trạng thái của commit cuối cùng.
Quản lý các thay đổi: Bạn có thể lưu nhiều mục stash khác nhau, mỗi mục được lưu trong một stack. Các mục này có thể được áp dụng lại, xóa hoặc quản lý theo nhu cầu của bạn.
Áp dụng lại các thay đổi: Khi bạn cần áp dụng lại các thay đổi đã lưu trữ, bạn có thể sử dụng các lệnh như git stash apply hoặc git stash pop.

>> Xem thêm: Tổng hợp kiến thức về Git cho người mới bắt đầu

Các lệnh cơ bản của Git Stash

Git stash

git stash là lệnh cơ bản nhất khi sử dụng Git stash, nó giúp lưu trữ các thay đổi hiện tại trong working directory và index vào stash.

Git stash được sử dụng khi muốn lưu lại các thay đổi chưa commit, thường rất hữu dụng khi bạn muốn đổi sang 1 branch khác mà lại đang làm dở ở branch hiện tại.

Muốn lưu toàn bộ nội dung công việc đang làm dở, bạn có thể sử dụng git stash như sau

$ git stash save # or just "git stash"

Khi này branch đã trở nên “sạch sẽ” và git status sẽ cho thấy bạn có thể chuyển sang branch tuỳ thích. Bạn có thể git stash bao nhiêu lần tuỳ thích và mỗi lần đó git sẽ lưu toàn bộ lần thay đổi đó như 1 phần tử trong 1 stack.

10 Vấn đề về Git thường gặp và Giải pháp

12 điều cực "cool" mà bạn có thể làm với Github

Sau khi đã git stash 1 hoặc vài lần, bạn có thể xem lại danh sách các lần lưu thay đổi bằng câu lệnh

$ git stash list
stash@{0}: WIP on : 
stash@{1}: WIP on : 
stash@{2}: WIP on :

Nếu muốn xem cả nội dung của từng thay đổi thì thêm option -p

$ git stash list -p

$ git stash show stash@{1}

Khi muốn apply lại thay đổi từ stash lần 1 bạn có thể

$ git stash apply stash@{1}

Git stash apply

Lệnh này sẽ chiếm phần trên cùng trong stack và apply nó vào repo. Trong trường hợp này là stash@{0}

Nếu bạn muốn áp dụng một số stash khác, bạn có thể chỉ định stash id.

Đây là một ví dụ:

git stash apply stash@{1}

Git stash pop

Lệnh này rất giống với stash apply nhưng nó xóa stash từ stack sau khi nó được áp dụng.

Câu lệnh:

# Giả sử bạn đã lưu trữ các thay đổi
git stash

# Bây giờ bạn muốn áp dụng các thay đổi đó và xóa stash khỏi danh sách
git stash pop

Nếu bạn muốn một stash cụ thể để “pop”, bạn có thể chỉ định stash id.

git stash pop stash@{1}

Git stash show

Lệnh này chỉ ra bản tóm tắt của các stash diff. Lệnh trên chỉ xem xét về stash mới nhất.

Câu lệnh:

# Giả sử bạn đã stash một số thay đổi
git stash

# Bạn có thể xem các thay đổi trong stash gần nhất
git stash show

# Bạn cũng có thể chỉ định stash id để có được tóm tắt diff.
git stash show stash@{0}

Nếu bạn muốn xem full diff, bạn có thể sử dụng

git stash show -p

Git stash branch <name>

Lệnh này tạo ra một nhánh mới với một stash hiện thời, và sau đó xóa các stash mới nhất (như stash pop).

Nếu bạn cần một stash cụ thể bạn có thể chỉ định stash id.

git stash branch <name> stash@{1}

Điều này thật sự hữu ích khi bạn gặp rắc rối sau khi đã áp dụng stash vào phiên bản mới nhất của chi nhánh.

Git stash clear

Lệnh này xóa tất cả các stash được tạo ra trong repo này và có thể không thể revert.

# Xóa tất cả các stash đã lưu trữ
git stash clear

Git stash drop

Lệnh này sẽ xoá stash mới nhất khỏi stack, nhưng hãy dùng nó cẩn thận, có thể sẽ khó để revert.

Bạn cũng có thể chỉ định stash id.

git stash drop stash@{1}

Sau khi tìm hiểu toàn bộ nội dung về Git Stash, ta có thể thấy Git Stash giúp bạn duy trì một luồng làm việc có tổ chức, dễ theo dõi và kiểm soát, đặc biệt hữu ích trong các dự án lớn và phức tạp.

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

Thành phần liên kết

NavLink Component

Thành phần chuyển hướng

useHistory Hook

useLocation Hook

useParams Hook + Dynamic Routes

useRouteMatch Hook

1. BrSE Chỉ Làm Việc Communication (Làm Cầu Nối Liên Lạc)

2. BrSE Không Cần Giỏi Công Nghệ

3. Cứ Qua Nhật Onsite Là Thành BrSE

4. Không Có Tiếng Nhật Thì Sẽ Không Được Đi Nhật

5. BrSE Là Việc Dành Cho Con Trai

Giới thiệu

Hãy xem ví dụ sau!

Các bước cài đặt

Các bước cài đặt

Sau đây là một so sánh log của rebase và merge 1 branch trong một mini project:

Kết Luận:

13. Sự chuyên tâm

14. Nhờ giúp đỡ

15. Nói cùng ngôn ngữ với kỹ sư lập trình

16. Đầu tư

17. Nhìn thấy bug

18-19-20. Trung thực – Chính trực – Dũng cảm

Lời kết

– Giá trị sử dụng

– Mục tiêu của test case

– Điều kiện trước

– Các bước thực hiện

– Inputs

– Ngôn ngữ

– Kết quả mong muốn

– Clean-up

– Sự phụ thuộc

– Tài liệu

I. Lịch sử phát triển WiFi?

II. Những ưu điểm nổi bật của WiFi 6?

#1. Hoạt động trên cả 2 băng tần 2.4GHz và 5GHz

#2. Sử dụng OFDMA

#3. Resource Unit

#4. BSS Color

#5. Target Wake Time (TWT)

III. Một số thuật ngữ mà bạn có thể gặp khi dùng Wi-Fi 6

#1. WiFi Mesh là gì?

#2. AIoT là gì?

IV. Lời Kết

I. Nhân Linux là gì?

II. Các phiên bản phân phối của Linux

#1. Red Hat Enterprise Linux

#2. CentOS

#3. Fedora

#4. Debian Linux

#5. Ubuntu

#6. Pop!_OS

#7. Gentoo

III. Lời Kết

7. Nhìn tổng thể

8. Sắp xếp thứ tự ưu tiên

9. Khả năng quan sát

10. Sự chính xác

11. Suy nghĩ độc lập

12. Nhu cương đúng lúc

UAT là gì?

Các loại UAT

SIT là gì?

So sánh nho nhỏ giữa UAT vs. SIT

Git Reset

Git Revert

–amend

Kết luận

Cài đặt React Router

Setup React Router cơ bản

Route Component

Chuyển đổi thành phần

404 route

#1. Ý nghĩa của file <testNG.xml> là gì? Hay sử dụng file <testNG.xml> này có tác dụng gì?

#2. Bạn sử dụng tham số trong file .xml và trong các test case như thế nào?

#3. Trong trường hợp một test case có nhiều method @Test, nhưng khi thực thi test case thì lại không muốn run một method test nào đó, bạn có thể làm gì để giải quyết vấn đề này?

#4. Sắp xếp thứ tự các thẻ dưới đây theo cấp cha-con trong file <testNg.xml>:

#5. Bạn set thứ tự ưu tiên của các @Test method như thế nào? Nó có ý nghĩa gì?