Community support

Thank you @apiguy for creating such a beautiful library.

Thank you, everyone who contributed to the project since the fork:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$ git log 48b7b030f16506e6eea9e217f5aa004b2cf2472f.. --format="%aN <%aE>" --reverse | sort | uniq
Andrew Roberts <adroberts@...>
Chris McNabb <raizyr@...>
Eli Gundry <eligundry@...>
Freedom Dumlao <freedomdumlao@...>
Hayden Chudy <hjc1710@...>
Hoat Le <hoatle@...>
Matt Billenstein <matt@...>
Nick Phillips <nsphilli@...>
Niklas B <niklas@...>
Stephane Rufer <stephane.rufer@...>
blurrcat <blurrcat@...>
hieptq <hieptq8888@...>
slhawkins <slhawkins@...>

And thank you @hjc for your helpful feedbacks and accepting the committer invitation. I hope that we will have more and more committers like you to join the project.

Thank you to everyone who has been using the library for your everyday projects, creating issues and feedbacks to make the library better.

What’s new?

So what’s new with this release?

We have released Flask-Classful v0.6.11, v0.7.0, v0.7.1, v0.8.0, v0.9.0, v0.10.0, v0.11.0, v0.12.0, v0.13.0, v0.13.1 since the fork, but mostly for bug fixes and small improvements.

v0.14.0 introduces a lot of exciting changes that you’d love to use it right away. These are some of the most exciting changes:

• Type hints support for py3
• base_class introduced
• Add options passing to werkzeug.Routing.Rule from register function
• Enable using custom decorators in FlaskView
• Should allow specifying excluded methods from becoming routes
• Better representations
• Docker workflow along with teracy-dev for better dev setup

You should check out the changelog and the docs for more detailed information:

• Changelog: https://github.com/teracyhq/flask-classful/blob/develop/CHANGELOG.md#2017-10-05-hoat-le-hoatleteracycom

• Docs: http://flask-classful.teracy.org/

Lessons learned?

We released v0.14.0 without breaking changes notice and migration docs which hurt our users from upgrading. From now on, we will avoid introducing breaking changes but should add deprecated warnings before breaking things for the next version releases.

v0.14.1 is on its way to fix this problem by updating the changelog and docs.

So rest assured and enjoy the release :–).

What’s next?

We created a roadmap release for v0.15.0 and we’re waiting for the community feedbacks and ideas for it.

We will add more sample projects, some projects with integration with other popular libraries to create top-notch REST APIs. If you have such projects to be promoted, please let us know then.

Enjoy and happy hacking!

Tóm tắt nội dung toàn văn bài chia sẻ trong vòng 15’ như sau:

Chào các bạn, mình là Hoạt, hôm nay rất vinh dự được tới đây chia sẻ với các bạn về cơ hội nghề nghiệp với công nghệ container (cụ thể là Docker).

Mình đã trong nghề được hơn 8 năm, trải qua nhiều vai trò khác nhau: từ nhân viên rồi team leader, rồi làm freelancer, rồi khởi nghiệp và hiện tại đang là CEO của Teracy.

Xuyên suốt quá trình làm việc thì phần mềm tự do nguồn mở và triết lý của nó luôn luôn gắn với các hoạt động phát triển nghề và phát triển bản thân của mình. Công ty đầu tiên là công ty mã nguồn mở, làm freelancer cũng sử dụng và chia sẻ các dự án mã nguồn mở cá nhân, rồi tới công ty Teracy hiện tại thì càng đặc biệt chú trọng tới việc chia sẻ, hợp tác và phát triển các dự án mã nguồn mở – là định hướng ngay từ ban đầu khi thành lập công ty.

Tự do nguồn mở là tất yếu. Mình rất thích triết lý của tự do nguồn mở vì nó có những giá trị mà mình theo đuổi: tập hợp sức mạnh tập thể để cùng tự do chia sẻ, hợp tác và phát triển.

Theo ước tính thì có khoảng tới 90% các công ty có sử dụng mã nguồn mở. Có nhiều công ty trên thế giới tài trợ và trả lương cho nhân viên chỉ phát triển các dự án mã nguồn mở, đặc biệt là các công ty lớn như RedHat, Microsoft, Facebook, Docker, Gooogle, Apache…

Và Docker là một công ty mã nguồn mở, có công nghệ container (Docker) là dự án tự do nguồn mở.

Công nghệ nào sinh ra thì cũng để giải quyết các vấn đề đang tồn tại, giúp phát triển và triển khai các sản phẩm/ dịch vụ nhanh hơn để đưa ra thị trường đúng thời điểm.

Bài toán mà công nghệ container giải quyết chính là bài toán ảo hoá ở một tầm cao mới, mọi thứ đều dễ dàng và thuận tiện hơn rất nhiều so với công nghệ trước đó, có thể ví đây là cuộc cách mạng ảo hoá cũng không có gì là quá.

Tiền thân của Docker là dotCloud – cung cấp dịch vụ Platform as a Service (dịch vụ nền tảng).

Trong quá trình vận hành dotCloud thì họ thấy cơ hội kinh doanh với công nghệ ảo hoá và họ chuyển sang mô hình kinh doanh mã nguồn mở với công nghệ container và đặt tên là Docker (tên sản phẩm và cũng là tên công ty).

Docker được giới thiệu vào năm 2013 tại hội nghị PyCon và được đón nhận rất nồng nhiệt.

Đến năm 2015, là 1 trong 20 dự án được yêu thích nhất trên GitHub, khoảng 11000 người tham gia đóng góp xây dựng, trong đó có một số công ty đóng góp nhiều như: Docker, Cisco, Google, Huawei, IBM, Microsoft và Red Hat…

Hiện tại ở Việt Nam, Docker cũng được sử dụng khá rộng rãi ở nhiều công ty lớn, nhỏ.

Vậy Docker cho sinh viên cơ hội gì và cần làm gì để nắm bắt cơ hội đó?

Có 3 cơ hội mà ta có thể xét tới: lương, số lượng việc làm và cơ hội phát triển bản thân.

Về lương, theo khảo sát:

• Lương ở Mỹ: $5.8k-$10k/tháng

• Lương ở Việt Nam: $800-$4k/tháng, đây là con số khảo sát từ trong nhóm Docker Hà Nội và từ quan sát thực tế trên các trang tuyển dụng và các công ty khác.

Đây là thống kê lương với người đã có kinh nghiệm làm việc khá trở lên.

Về cơ hội việc làm: nhiều công ty trong nước cần tuyển nhiều vị trí DevOps để làm việc với Docker, có thể kể đến như: VCCorp, FPT, VNG, Eway, Vega, TOPICA, Arimo, DEHA Việt Nam, Teracy và nhiều công ty khác nữa mà mình chưa có số liệu cụ thể thống kê chi tiết.

Và cơ hội phát triển bản thân: được phát triển toàn diện khi được học và làm việc với nhiều công nghệ, stack khác nhau với vai trò DevOps: tham gia cả quá trình phát triển và vận hành, có cái nhìn toàn diện hơn về cách phát triển, quy trình phát triển phần mềm.

Để nắm bắt được cơ hội trên thì sinh viên cần làm gì?

Cơ hội lớn thì thách thức càng lớn.

Thách thức đầu tiên là nguồn nhân lực vừa thừa vừa thiếu. Số lượng sinh viên tốt nghiệp ngành CNTT đứng top 10 thế giới nhưng chất lượng đầu ra còn yếu, nhiều công ty gặp rất nhiều khó khăn để tuyển dụng được nhân lực chất lượng, có thể đảm nhiệm được công việc.

Thách thức nữa là vì số lượng lớn nên mức độ cạnh tranh gay gắt hơn ở những vị trí thực tập, nhân viên mới.

Và để làm việc được với công nghệ container thì đòi hỏi phải có kiến thức đủ rộng và đủ sâu để có thể hiểu và đảm nhiệm vai trò phát triển và vận hành cùng lúc được.

Vậy sinh viên cần làm gì để có thể nắm bắt cơ hội này?

• Ưu tiên xây dựng cái gốc, nền tảng vững để có thể tiến xa và bay cao nhất có thể.
• Học tập suốt đời để biết thế giới đang ở đâu, đi về đâu và mình đang ở đâu trên thế giới đó; ngừng học là tụt hậu.
• Bằng cấp không nói lên được điều gì, chỉ có kinh nghiệm và khả năng thực tế tạo ra sản phẩm mới có tiếng nói.
• Hãy đặt mục tiêu làm việc với người nước ngoài, các dự án, công ty nước ngoài: trước mắt là khả năng ngoại ngữ đặc biệt quan trọng, ít nhất là phải đọc viết thành thạo.
• Mới bắt đầu, đừng quá đặt nặng vấn đề lương, hãy quan tâm đầu tư hơn cho bản thân, nâng cao giá trị bản thân, có môi trường phát triển bản thân thật tốt, đó mới là cơ hội sinh viên nên nắm bắt. Không quan trọng là công ty to hay nhỏ hay khởi nghiệp, quan trọng đó phải là nơi bạn được sống hết mình, cống hiến hết mình và được phát triển, hoàn thiện bản thân.
• Hãy thử nghiệm thật nhiều và sẽ có nhiều thất bại, đó là điều bình thường, bạn được thất bại trong giai đoạn đầu để cố gắng liên tục cho sự thành công của giai đoạn sau, càng về sau càng không được thất bại, nhất là các thất bại đã được thử thách trước đó.
• Sinh viên nên tham gia vào các dự án mã nguồn mở để học hỏi và thể hiện bản thân, xây dựng thương hiệu, sau khi giá trị bản thân tốt, thương hiệu tốt thì các cơ hội nghề nghiệp tốt luôn tự động tìm đến bạn, bạn từ chối không hết, ví dụ như:
  • Sử dụng, sửa lỗi, phát triển, làm bất kì điều gì để đóng góp cho dự án.
  • Nắm bắt các quy trình dự án mã nguồn mở.
  • Nắm bắt các công nghệ, công cụ xoay quanh dự án mã nguồn mở.
  • Nắm bắt cách hoạt động, giao tiếp với dự án mã nguồn mở.
• Hãy bớt ảo tưởng, để đến được đích mong muốn thì phải trải qua nhiều gian khổ, không dành cho tay mơ:
  • Biết mình đang ở đâu trong thế giới này, thế giới đang ở đâu và sẽ đi về đâu.
  • Hãy nhớ lương bạn được trả tỉ lệ thuận với lợi ích, kết quả bạn đem lại.
  • Lương không được đo bằng thời gian, công sức bỏ ra để học tập, để bị stress vì điều đó chứng tỏ khả năng của bạn còn hạn chế.  + Lương càng cao thì áp lực càng lớn, hãy trao đổi thẳng thắn về những khó khăn của mình với công    ty để điều chỉnh cho hài hoà, đó là cách khôn ngoan đảm bảo lợi ích cho cả 2 bên.
• Chuyên nghiệp ngay từ hôm nay đi:
  • Chuyên nghiệp là khả năng làm việc hết tâm, hết sức và biết giá trị của mình đem lại cho công ty, tổ chức để cân bằng lợi ích giữa 2 bên.
  • Chuyên nghiệp là biết nhìn xa trông rộng thay vì chỉ chăm chăm cái lợi trước mắt.  + Chuyên nghiệp là đừng răm rắp nghe lời chỉ đạo từ cấp trên, phải biết chủ động, tư duy và phản biện để có kết quả tốt nhất có thể.
  • Chuyên nghiệp là làm những việc nhỏ nhất với sự cẩn thận và tận tâm nhất.
  • Chuyên nghiệp là hãy đảm bảo hoàn thành công việc với kết quả tốt nhất, vượt ngoài mong đợi của lãnh đạo, khách hàng.
  • Đó là những biểu hiện của sự chuyên nghiệp. Khi ứng tuyển vào các công ty mà bạn có ghi muốn làm    việc ở môi trường chuyên nghiệp thì đây chính là những đặc điểm của sự chuyên nghiệp đó mà bạn cần chuyên nghiệp ngay từ bây giờ.

Cơ hội rất lớn, thách thức cực nhiều và những hành động cụ thể rất cần. Mà để đến đích có nhiều con đường, con đường nào là tốt nhất, ít đau thương nhất? Chỉ có những con người đã trải qua đau thương mới giúp trả lời câu hỏi này. Vậy tìm những người này ở đâu để có thể giúp các bạn sinh viên?

Đó là nhóm Docker Hà Nội, ở nơi đây có các anh chị làm ở nhiều công ty khác nhau đầy kinh nghiệm sẽ giúp các bạn đi trên con đường ít đau thương nhất để tới đích. Các anh chị đầy nhiệt huyết muốn dìu dắt các em sinh viên để cùng phát triển, xây dựng cộng đồng lớn mạnh hơn.

Đó là cơ hội nghề nghiệp trước mắt mà các bạn sinh viên nào quan tâm thì hãy nắm bắt lấy, đừng để mất cơ hội.

Hãy tham gia và góp ý cho nhóm Docker Hà Nội ngày càng tốt hơn, cộng đồng lớn mạnh hơn, giúp đỡ nhau phát triển hơn.

Tóm lại các bạn sinh viên cần nhớ:

• Phần mềm tự do nguồn mở là tất yếu, trong đó có công nghệ container.
• Nhiều cty lớn nhỏ ở Việt Nam và trên thế giới đã ứng dụng triển khai nhiều dự án trên công nghệ container (Docker).
• Sinh viên cần biết những cơ hội, thách thức và hành động cụ thể để nắm bắt cơ hội, hãy bớt ảo tưởng và chuyên nghiệp ngay từ hôm nay.
• Để đi tới đích với con đường tốt nhất, ít đau thương nhất thì hãy tham gia Docker Hà Nội.

Hy vọng những chia sẻ vừa rồi có ích cho các bạn, có thể giúp các bạn định hướng nghề nghiệp tốt hơn, nắm bắt cơ hội tốt hơn.

Although running Docker inside Docker (DinD) or Docker outside of Docker (DooD) is generally not recommended, there are some legitimate use cases, such as development of Docker itself or for local CI testing. And in this blog post, I’m going to show you how to use DinD or DooD for local CI testing as it’s a very typical use case for local DevOps.

The differences between DinD and DooD?

DinD is the opposite of DooD.

DinD includes a whole Docker installation inside of it.

DooD uses its underlying host’s Docker installation by bind-mounting the Docker socket.

Obviously, DooD should be faster because we can leverage its caching mechanism, and DinD should be cleaner. DinD should support parallel running but DooD does not, or at least, not very reliable with my observation. If you want to conduct the clean testing, use DinD. If you want to conduct the faster testing, use DooD.

DooD is simpler to use than DinD.

And if you want to test with different versions of docker, docker-compose, use DinD and DooD.

Local CI testing with DinD

You can use https://hub.docker.com/r/library/docker/ for local testing, however, it’s alpine image which is not very suitable for local CI testing since it is not the default travis-ci environment. We should use Ubuntu for executing CI scripts on all the CI systems (gitlab, drone, etc.) because we can port the CI scripts easily between these CI systems.

That is the reason why we build teracy/ubuntu Docker images to be used with DinD, you can check out the project here: https://github.com/teracyhq/docker-files/tree/master/ubuntu and the built Docker images here: https://hub.docker.com/r/teracy/ubuntu/tags/

We also have docker-compose installed to the teracy/ubuntu Docker images for faster testing with it.

Let’s see how it works:

The commands from the above video:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

$ docker run --privileged --name df-docker -d docker:17.06.0-dind # start DinD container

$ docker run --rm -it --link df-docker:docker docker:17.06.0 sh # run docker image (Alpine)

# docker version

# docker-compose --version # no docker-compose

$ docker run --rm -it ubuntu bash # run Ubuntu image within the Docker Alpine container

# uname -a
# exit
# uname -a
# exit


$ docker run --rm -it --link df-docker:docker teracy/ubuntu:16.04-dind-17.06.0-ce bash # run Ubuntu image

# docker version
# docker-compose version

$ docker run --rm -it alpine sh # run Alpine image with the Docker Ubuntu container

# uname -a
# exit
# uname -a
# exit

Local CI testing with DooD

Let’s see how it works:

The commands from the above video:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

$ docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock docker sh # start DooD container

# docker version
# docker-compose --version # no docker-compose

$ docker run --rm -it ubuntu bash # run Ubuntu image within the Docker Alpine container
# cat /etc/lsb-release
# exit
# cat /etc/alpine-release
# exit

$ docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock teracy/ubuntu:16.04-dind-17.06.0-ce bash # start DooD container

# docker version
# docker-compose version

# docker run --rm -it alpine sh # run Alpine image with the Docker Ubuntu container
# cat /etc/alpine-release
# exit
# cat /etc/lsb-release 
# exit

Volume mounting

Volume mounting is a bit tricky, you must understand the underlying mechanism of its to get it work. Basically, you need to make sure the mounting path from the running containers must be the same as the DinD containers or DooD containers.

Let’s see how volume mounting works with DinD:

The commands from the above video:

1
2
3
4
5
6
7
8
9

# volume mount with DinD

$ pwd
$ ls
$ docker run --privileged --name df-docker -d -v $(pwd):$(pwd) -w $(pwd) docker:17.06.0-dind # start DinD container
$ docker run --rm -it --link df-docker:docker -v $(pwd):$(pwd) -w $(pwd) teracy/ubuntu:16.04-dind-17.06.0-ce bash
# ls
# docker run --rm -it -v $(pwd):/opt/app -w /opt/app ubuntu bash
# ls

Let’s see how volume mounting works with DooD:

The commands from the above video:

1
2
3
4
5
6
7

# volume mount with DooD
$ pwd
$ ls
$ docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock -v $(pwd):/$(pwd) -w $(pwd) teracy/ubuntu:16.04-dind-17.06.0-ce bash # start DooD container
# ls
# docker run --rm -it -v $(pwd):/opt/app -w /opt/app ubuntu bash
# ls

Local CI Testing with a real project

Let’s see how we can conduct a local CI testing with the https://github.com/teracyhq/docker-files project.

Let’s dive into the .travis.yml file https://github.com/teracyhq/docker-files/blob/master/.travis.yml to test the following scripts:

1
2
3
4
5
6
7
8
9
10
11
12

before_install:
# install the latest docker and docker-compose versions
- sudo apt-get remove docker docker-engine
- sudo curl -sSL https://get.docker.com/ | sh
- sudo rm /usr/local/bin/docker-compose
# the latest docker-compose version
- export DOCKER_COMPOSE_VERSION=$(curl -s https://api.github.com/repos/docker/compose/releases/latest | grep 'tag_name' | cut -d\" -f4)
- curl -L https://github.com/docker/compose/releases/download/${DOCKER_COMPOSE_VERSION}/docker-compose-`uname -s`-`uname -m` > docker-compose
- chmod +x docker-compose
- sudo mv docker-compose /usr/local/bin
- docker version
- docker-compose version

Let’s see how to do local CI testing in action:

This is just the very first step for basic testing.

Later, we should convert this .travis.yml file into a build.sh one to execute, this is the right way for local CI testing travis-ci and other similar CI systems.

To do that, please follow https://github.com/teracyhq/docker-files/issues/42 and I’ll update this section more when it’s ready.

Too many virtualization layers?

At Teracy, the teracy-dev VM is virtualized on a host machine (and the host machine could be virtualized from another virtualized machine and so on).

Within the teracy-dev VM, we use DinD. And within a Docker container, we can use Docker to run other Docker containers and so on.

Yeah, welcome to the world of “Inception”, let’s figure out where you are now :–)?

Happy hacking!

References

• http://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/
• https://hub.docker.com/r/library/docker/
• https://github.com/axltxl/docker-jenkins-dood
• https://sreeninet.wordpress.com/2016/12/23/docker-in-docker-and-play-with-docker/

What’s new?

This milestone release helps us to manage the installation of these packages: kubectl, helm, and gcloud automatically.

These are the client packages which are used to communicate and to work with the Google Cloud Platform, Google Container Engine or any other Kubenertes servers.

You can install, remove any valid versions of those packages onto Ubuntu or CentOS platforms and more supported platforms will come.

What’s next?

This cookbook is designed to provide utilities for us to work with Kubernetes stack, so the next milestone will introduce kubernetes resource to set up and install Kubernetes server which should work the same as Minukube with better developer productivity enhancement. This will allow our developers to have a quick local deployment test with k8s on their workstations.

By using this, we can save a lot of server cost, reduce testing time and speed up delivery time of application deployment.

Developers will understand Kubernetes more deeply when they can do whatever they want with it. It’s very safe! They can destroy and set up a new deployment anytime they want without causing any harm to their co-workers.

You should check out how it should be used with teracy-dev at https://github.com/acme101/dev-setup/blob/develop/chef/main-cookbooks/acme/recipes/k8s.rb

I hope that this free cookbook could make your lives easier when working with Kubernetes: https://supermarket.chef.io/cookbooks/kubernetes-stack

Happy hacking!

v0.5.0-c1

As you’ve known, the RC-1 version means “all minor bugs are fixed, the software works stably, and the code will be released unless there is a last minute bug found after test campaigns.”. However, to meet some requests from our clients and community, we added some features to this release.

Changes

This major release includes some bugs fixed, document improvement and new features:

• Support the project base configuration. From now, you can add a list of vagrant configuration to your JSON file and extend the configuration from that.
• Update the document for the getting started with windows environment, nodejs debugging.
• Add many tools to help your development process.
• Add the ability to extend and uniquely extend the array list in the JSON configuration file.
• Introduce ACME101 as the sample project which shows the best practices of using teracy-dev.

There are more that you should explore yourselves when using teracy-dev for a while.

What’s next?

Along with the project base configuration we also introduce ACME101 which has many development stacks to use with teracy-dev. Hopefully, it will be useful for you and we’re welcome any contribution, suggestion for ACME101. We’re also adding more documents and guide for the project.

We’ll take all the feedbacks from v0.5.0 usage to continue making teracy-dev better and greater.

Don’t hesitate to use teracy-dev v0.5.0-c1 for your everyday projects from today by getting started with http://dev.teracy.org/docs/getting_started.html

If you have any feedbacks or problems, you’re welcome to create issues for the project at https://github.com/teracyhq/dev/issues

Enjoy and happy hacking!

Một điều dễ nhận thấy đó là, sự tốt đẹp sẽ đến khi sản phẩm của bạn gắn liền và mô phỏng đời sống thực. Đó là cảm xúc, hành vi, động cơ, và phần thưởng trong cuộc sống thực.

Và với sự phát triển nhanh chóng của cái gọi là FOMO (chứng sợ bị lãng quên), chúng ta sẽ ngạc nhiên khi thấy sản phẩm tiến bộ hơn ra sao khi kèm cả FOMO.

Khi được sử dụng đúng cách, FOMO trong sản phẩm của bạn có thể giúp nâng cao khả năng xác nhận xã hội, tăng giao lưu và gắn kết. Hãy xem xét một số ví dụ

Ô trò chuyện trên Facebook

Bạn có thể đã từng muốn giấu nhẹm đi ô Facebook chat để khỏi phải nhìn thấy nó 76 lần mỗi ngày khi bạn mở Facebook ra. Facebook quyết định chế độ “tắt” cuộc trò chuyện được thiết lập bằng cách làm mờ khu vực trò chuyện và bao phủ toàn bộ bằng một lớp FOMO trong, giúp bạn bật ô trò chuyện trong trường hợp cần thiết.

Đây là điều tôi nhận thấy ở góc dưới cùng bên phải màn hình mỗi khi tôi sử dụng Facebook.

Hầu hết mọi người đều sẽ tin rằng đây là tất cả những người đang sử dụng trực tuyến và sẵn sàng trò chuyện. Tuy nhiên, thực tế không phải vậy. Thay vào đó, danh sách này chỉ bao gồm những người bạn tương tác gần đây. Đó là cách hay khi bạn có thể theo dõi những người dường như có mối quan hệ gần gũi thay vì hỗn độn một nhóm ngẫu nhiên.

FOMO: Hãy xem – giờ thì chỉ những người bạn thân nhất sẽ hiển thị trên Facebook chat.

WillCall

Bạn chỉ có thể phát hiện ra rằng mình đã lỡ mất buổi hòa nhạc khi bạn bè bàn tán về nó vào ngày hôm sau. Gần đây, điều đó đã thay đổi, buổi hòa nhạc sẽ được cập nhật khi nó được tải lên Tweeter hoặc Instragram.

Và bây giờ, với WillCall, bạn thậm chí sẽ cập nhật được cả phần đầu buổi hòa nhạc. Nếu ai đó trong mạng của bạn mua vé trên WillCall, bạn sẽ nhận được một quảng cáo như sau:

FOMO: Thực ra bạn sẽ không cần mua vé cho chương trình mà bạn của mình sẽ đi xem tối nay? Thay vào đó, chỉ cần ngồi nhà thư giãn và lắng nghe qua Radio.

Danh sách chờ (Simple, Mailbox, Tempo)

Xếp hàng chờ ứng dụng là một trải nghiệm mới mẻ.

Trong những tháng gần đây, có vẻ như việc ra mắt sản phẩm còn hơn là một cái nhìn thoáng qua về sản phẩm. Nếu bạn không sớm truy cập, bạn sẽ bị đưa vào danh sách chờ.

Một số công ty ứng phó với những khách hàng khó tính bằng thủ thuật cho rằng danh sách chờ sẽ giúp tạo quy mô và chất lượng tốt hơn. Điều này chỉ đúng một nửa – khi nhiều khả năng các nhà tiếp thị và hacker đứng sau để đẩy lượng danh sách chờ. 3 tuần sau khi ứng dụng ra mắt, Mailbox đã có hơn 1 triệu người nằm trong danh sách chờ, trong khi Tempo có khoảng 700.000 người.

Hầu hết các ứng dụng danh sách chờ hứa hẹn truy cập nhanh hơn nếu bạn mời bạn bè hoặc chia sẻ dịch vụ của họ bằng mạng của bạn. Những lời hứa này có vẻ là giả mạo, nhưng chúng lại nuôi dưỡng các bộ máy phát triển và mang lại sự ấn tượng về quy trình đối với những người đang theo dõi.

FOMO: Hàng trăm ngàn người khác giống như bạn đã nằm trong danh sách, tốt hơn hết, hãy nhanh chân đăng ký một vị trí ngay bây giờ trước khi bạn đứng chờ sau hàng triệu người nữa.

Trên thực tế, rất nhiều thành công đến từ một sản phẩm tối ưu được dựa trên phân tích tâm lý thực tế của đối tượng hướng đến. Hãy chú trọng đến cảm xúc của con người, và bạn đang trên con đường xây dựng một sản phẩm tuyệt vời.

FOMO là một chủ đề – nhưng có hàng chục, thậm chí còn hàng trăm chủ đề để cân nhắc. Cách tuyệt vời để nhớ và thử thách bản thân là với Mental Notes, một bộ 50+ thẻ “mô tả sự hiểu biết sâu sắc về hành vi của con người và đề xuất cách áp dụng nó vào việc thiết kế các trang Web, ứng dụng Web và các ứng dụng phần mềm.”

Nguồn dịch: Building FOMO into your product

teracy-dev is developed with the goal to keep it as minimal and extensible as possible. The extension feature is so powerful that you can customize the VM in anyway you want. For example, in this blog post, I’ll show you how to extend it to work with Kubernetes.

About Kubernetes

We’re leveraging Docker for all of our development workflow for our clients, internal and open source projects. teracy-dev is provisioned with Docker by default out of the box so that we can start working with Docker right away.

However, Docker alone is not enough to work with container technology stack. The production deployment is different from the local Docker environment. There are many options for container production deployment, however, we choose Kubernetes as the first class as it’s currently the big giant and the future of container orchestration that we believe in.

Working with Kubernetes requires kubectl client to be available, and if you’re starting to use GKE (Google Container Engine), gcloud (google cloud sdk) client should be available, too.

So let’s find a way to extend teracy-dev to install kubectl and gcloud.

Extending teracy-dev

You can extend teracy-dev’s VM by your own choice of operating system and automate the provisioning process by your own choice of configuration software. “The only limit is your imagination” :–).

To extend teracy-dev, we can use any kind of provisioners that are supported by vagrant (as teracy-dev is built on top of vagrant), you can see more info here: https://www.vagrantup.com/docs/provisioning/

We choose Chef as it’s our default provisioner that we have more years of usage experience. We intend to use Ansible for some future projects, too.

Installing ChefDK

We’re going to use Acme 101 project which is used to show the best practices from teracy-dev applied for organizations.

To work with Chef cookbooks, we need to install ChefDK. Fortunately, there is already an available cookbook for us to use to install ChefDK automatically on our VM: https://supermarket.chef.io/cookbooks/chef-dk

Usually, we have dev-setup directory to extend teracy-dev (acme-dev in this case). The initial dev-setup content should be like this: https://github.com/acme101/kubernetes-dev-setup/tree/0-initial

To install ChefDK, we must install the chef-dk cookbook and use it as follows:

• Add depends 'chef-dk' to dev-setup/chef/main-cookbooks/acme/metadata.rb

• Install vendor cookbooks with the following commands within the VM:

1
2
3

$ ws
$ cd dev-setup/chef
$ docker-compose up

• Sync back the changes from the VM to the host machine:

1

$ vagrant rsync-back

The updated content should be like this: https://github.com/acme101/kubernetes-dev-setup/tree/1-dependency

Now, to install chef-dk, just add the following Ruby code to default.rb recipe, it’s never so easy:

1
2
3
4

chef_dk 'my_chef_dk' do
  global_shell_init true
  action :install
end

Make sure you have berks-cookbooks paths that vagrant can look up. The configuration step should be like this: https://github.com/acme101/kubernetes-dev-setup/tree/2-configuration

• After that, $ vagrant reload --provision and voila, you should have ChefDk installed.

1
2
3
4
5
6
7
8

$ vagrant ssh
$ chef --version
Chef Development Kit Version: 1.4.3
chef-client version: 12.19.36
delivery version: master (41b94ffb5efd33723cf72a89bf4d273c8151c9dc)
berks version: 5.6.4
kitchen version: 1.16.0
inspec version: 1.25.1

That’s how we use Chef cookbooks to manage the VM’s software automatically. We can do the same with all other types of Chef cookbooks shared and opensourced from the public Chef Supermarket: https://supermarket.chef.io/ You can use all the public shared cookbooks to do almost anything you want for your VM.

However, sometimes, there is not available cookbook that we want, then it’s time we should build new cookbooks from scratch.

Creating new Chef cookbooks

From the steps above, we have ChefDK available to work with Chef cookbooks. To learn how to use it, you can follow: https://github.com/chef/chef-dk

I already created the initial kubernetes-stack-cookbook that we can work with. You need to clone the repo into the workspace directory:

1
2

$ cd ~/acme-dev/workspace
$ git clone git@github.com:teracyhq-incubator/kubernetes-stack-cookbook.git

You can test the cookbook within the VM ($ vagrant ssh) with rspec, kitchen easily:

1
2
3

$ ws
$ cd kubernetes-stack-cookbook/
$ rspec

you should see the following similar content:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

kubernetes-stack::default
  When all attributes are default, on ubuntu 16.04
    converges successfully

kubernetes-stack-test::gcloud_install_default
  When all attributes are default, on ubuntu 16.04
    converges successfully
    install gcloud

kubernetes-stack-test::kubectl_install_default
  When all attributes are default, on ubuntu 16.04
    converges successfully
    install kubectl

Finished in 1.35 seconds (files took 1.78 seconds to load)
5 examples, 0 failures


ChefSpec Coverage report generated...

  Total Resources:   7
  Touched Resources: 2
  Touch Coverage:    28.57%

Untouched Resources:

  gcloud[install default gcloud]     kubernetes-stack-test/recipes/gcloud_install_default.rb:1
  execute[import google-cloud-sdk public key]   kubernetes-stack/resources/gcloud.rb:13
  apt_repository[google-cloud-sdk]   kubernetes-stack/resources/gcloud.rb:17
  bash[clean up the mismatched kubectl version]   kubernetes-stack/resources/kubectl.rb:20
  remote_file[/usr/local/bin/kubectl]   kubernetes-stack/resources/kubectl.rb:33

and to test with kitchen:

1
2
3
4

$ ws
$ cd kubernetes-stack-cookbook/
$ export KITCHEN_LOCAL_YAML=.kitchen.dokken.yml
$ kitchen test

then you should see the following similar content:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

...
Starting Chef Client, version 13.2.7
[2017-06-14T17:53:24+00:00] WARN: Plugin Network: unable to detect ipaddress
resolving cookbooks for run list: ["kubernetes-stack-test::gcloud_install_default"]
Synchronizing Cookbooks:
  - kubernetes-stack-test (0.1.0)
  - kubernetes-stack (0.1.0)
Installing Cookbook Gems:
Compiling Cookbooks...
Converging 1 resources
Recipe: kubernetes-stack-test::gcloud_install_default
  * gcloud[install default gcloud] action install
    * execute[import google-cloud-sdk public key] action run
      - execute curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
    * apt_repository[google-cloud-sdk] action add
      * execute[apt-cache gencaches] action nothing (skipped due to action :nothing)
      * apt_update[google-cloud-sdk] action nothing (skipped due to action :nothing)
      * file[/etc/apt/sources.list.d/google-cloud-sdk.list] action create
        - create new file /etc/apt/sources.list.d/google-cloud-sdk.list
        - update content in file /etc/apt/sources.list.d/google-cloud-sdk.list from none to 24ee22
        --- /etc/apt/sources.list.d/google-cloud-sdk.list 2017-06-14 17:53:25.296105380 +0000
        +++ /etc/apt/sources.list.d/.chef-google-cloud-sdk20170614-20-7wqkmu.list 2017-06-14 17:53:25.296105380 +0000
        @@ -1 +1,2 @@
        +deb      "http://packages.cloud.google.com/apt" cloud-sdk-xenial main
        - change mode from '' to '0644'
        - change owner from '' to 'root'
        - change group from '' to 'root'
      * execute[apt-cache gencaches] action run
        - execute apt-cache gencaches
      * apt_update[google-cloud-sdk] action update
        - force update new lists of packages
        * directory[/var/lib/apt/periodic] action create (up to date)
        * directory[/etc/apt/apt.conf.d] action create (up to date)
        * file[/etc/apt/apt.conf.d/15update-stamp] action create_if_missing
          - create new file /etc/apt/apt.conf.d/15update-stamp
          - update content in file /etc/apt/apt.conf.d/15update-stamp from none to 174cdb
          --- /etc/apt/apt.conf.d/15update-stamp  2017-06-14 17:53:26.136525380 +0000
          +++ /etc/apt/apt.conf.d/.chef-15update-stamp20170614-20-1r28edv 2017-06-14 17:53:26.136525380 +0000
          @@ -1 +1,2 @@
          +APT::Update::Post-Invoke-Success {"touch /var/lib/apt/periodic/update-success-stamp 2>/dev/null || true";};
        * execute[apt-get -q update] action run
          - execute apt-get -q update
      
    
    * apt_package[google-cloud-sdk] action install

      - install version 159.0.0-0 of package google-cloud-sdk
  

Running handlers:
Running handlers complete
Chef Client finished, 9/13 resources updated in 55 seconds
       Finished converging <smoke-gcloud-ubuntu-1604> (1m0.97s).
-----> Setting up <smoke-gcloud-ubuntu-1604>...
       Finished setting up <smoke-gcloud-ubuntu-1604> (0m0.00s).
-----> Verifying <smoke-gcloud-ubuntu-1604>...
       Loaded tests from test/smoke/gcloud 

Profile: tests from test/smoke/gcloud
Version: (not specified)
Target:  docker://16562c9afb7c00447169330fc584b442617a810f6b776d2eb6b78ce87d5d652f


  Command which
     ✔  gcloud exit_status should eq 0
     ✔  gcloud stdout should match "/usr/bin/gcloud"

Test Summary: 2 successful, 0 failures, 0 skipped
       Finished verifying <smoke-gcloud-ubuntu-1604> (0m0.64s).
-----> Destroying <smoke-gcloud-ubuntu-1604>...
       Deleting kitchen sandbox at /home/vagrant/.dokken/kitchen_sandbox/1000b8c847-smoke-gcloud-ubuntu-1604
       Deleting verifier sandbox at /home/vagrant/.dokken/verifier_sandbox/1000b8c847-smoke-gcloud-ubuntu-1604
       Finished destroying <smoke-gcloud-ubuntu-1604> (0m10.67s).
       Finished testing <smoke-gcloud-ubuntu-1604> (1m55.61s).
-----> Kitchen is finished. (4m12.76s)

That’s how we develop and test the cookbook on local dev.

You can see the cookbook here at https://github.com/teracyhq-incubator/kubernetes-stack-cookbook

It’s currently a very simple cookbook to support the installation of kubectl and gcloud. In the future, it will do more than that and support more platforms than current Ubuntu only.

Installing kubectl and gcloud

The kubernetes-stack-cookbook is not available on the Chef Supermarket (yet), so to use it, we need to install it from the github repo.

To install kubectl, add this to the default.rb recipe:

1

kubectl 'install the latest kubectl'

To install gcloud, add this to the default.rb recipe:

1

gcloud 'install the latest gcloud'

The configuration step should be like this: https://github.com/acme101/kubernetes-dev-setup/tree/3-kubectl-gcloud-installation

After that, $ vagrant reload --provision and voila (again), you should have both of the packages installed.

1
2
3

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.4", GitCommit:"d6f433224538d4f9ca2f7ae19b252e6fcb66a3ae", GitTreeState:"clean", BuildDate:"2017-05-19T18:44:27Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
The connection to the server localhost:8080 was refused - did you specify the right host or port?

1
2
3
4
5
6
7
8

vagrant@acme:~$ gcloud --version
Google Cloud SDK 159.0.0
alpha 2017.06.09
beta 2017.06.09
bq 2.0.24
core 2017.06.09
gcloud 
gsutil 4.26

Setting up Kubernetes local deployment

I’ve shown you how to extend teracy-dev to install new software packages. It is very simple, just follow the steps I described above to apply for all other projects.

kubectl and gcloud are used to work with Google Container Engine (GKE), however, we want to install Kubernetes to test on local dev, too. So I will have another blog post to cover this more complex setup: how to create a Kubernetes cluster to work on local dev so that we can test all your production Docker images on your local dev the same way it is deployed on the production system.

Summary

Now you should know how to extend teracy-dev with Chef cookbooks, this is a very common task to do. And other newcomer devs can just use your dev-setup without learning anything new, just follow the instructions and learn more to master later.

There are still some areas of configuration for teracy-dev that needs improvement and it will be available on teracy-dev v0.5.0, so stay tuned for our next very exciting upcoming releases.

I hope that this blog post can help you follow the current best practices to extend teracy-dev for your own need more easily. If you have any problem with it, let me know by dropping your comments.

Happy hacking!

Cốt lõi của trải nghiệm người dùng không phải là bộ các tính năng, mà thực ra nó là công việc mà người sử dụng muốn sản phẩm làm cho họ. Ví dụ như cốt lõi trải nghiệm người dùng của Uber là cho phép gọi xe taxi dễ dàng bất cứ lúc nào. Bộ đếm giờ, hiển thì chính xác khi nào thì xe sẽ tới, nó là một tính năng phù hợp để mở rộng trải nghiệm này. Tuy nhiên sản phẩm Uber vẫn chạy dù có tính năng này hay không, nhưng tính năng đếm giờ này sẽ không thể chạy nếu không có sản phẩm. Có mối quan hệ 1 chiều giữa tính năng và sản phẩm đó là tính năng không thể chạy nếu thiếu sản phẩm. Đó là lý do tại sao người thiết kế nên tư duy theo hướng sản phẩm trước.

“Nên tư duy hướng sản phẩm, chứ không phải hướng tính năng”

Khám phá mục đích của sản phẩm là gì

Mỗi Sản phẩm đều có một trải nghiệm người dùng cốt lõi, cơ bản đó là lý do để sản phẩm tồn tại. Nó đáp ứng nhu cầu hoặc xử lý vấn đề nào đó của con người. Do đó, nó trở nên ý nghĩa và cung cấp một giá trị nào đó. Nếu vấn đề không tồn tại hoặc giải pháp đưa ra không phù hợp, sản phẩm sẽ trở nên vô nghĩa và mọi người sẽ không ai dùng nó; rồi cuối cùng cũng sẽ dẫn đến sản phẩm thất bại. Giải pháp sai có thể được sửa, nhưng vấn đề mà không tồn tại thì không thể điều chỉnh được. Vậy làm thế nào để có thể chắc chắn tìm được vấn đề đó? Chúng ta không thể chắc chắn 100%, nhưng chúng ta có thể tối thiểu hóa các rủi ro thật nhiều bằng cách quan sát và nói chuyện với mọi người. Từ đó, khám phá vấn đề và xây dựng giải pháp mà người sử dụng muốn.

„Đó không phải là việc của khách hàng để biết mình muốn gì” — Steve Jobs

Ví dụ, (Clay Christensen) đã từng cố gắng cải thiện doanh số bán sữa lắc, anh ta cố làm cho sữa ngọt hơn, cung cấp nhiều hương vị và làm cái ly to hơn một tí. Nhưng không mang lại kết quả, cho đến khi anh ta bắt đầu quan sát người ta mua hàng của mình. Và tìm ra rằng khi người ta mua sữa lắc thì thực ra là họ muốn trên đường đi làm bớt nhàm chán hơn. Lợi ích lớn nhất sữa lắc mang lại là nó đặc và để được lâu hơn và cảm giác no hơn các loại sữa khác. Đây chính là vấn đề, người sửa dụng không biết như vậy. Cuối cùng thì anh bán sữa lắc này đã đưa ra giải pháp làm cho sữa đặc hơn và từ đó tăng trưởng doanh số cho mình.

„Hãy theo đuổi một vấn đề, chứ đừng theo đuổi một giải pháp cụ thể nào đó” — Laura Javier

Tư duy hướng sản phẩm và xây dựng tính năng đúng cho đúng người dùng

Tư Duy Hướng Sản Phẩm giúp xây dựng các tính năng thành công. Bằng việc xác định các vấn đề mà sản phẩm đang có, nó trả lời câu hỏi rằng “tại sao chúng ta xây dựng sản phẩm này?”. Xác định đối tượng khách hàng “ai bị vấn đề này?” và xác định giải pháp “chúng ta sẽ làm cái này như thế nào?” sẽ đủ đễ dẫn lối và tạo ra một tính năng mới. Sắp đặt một mục tiêu sẽ giúp đo lường thành quả của tính năng này.

Bộ Vấn đề và Giải pháp

Sản phẩm sẽ ý nghĩa hơn khi mà được cung cấp đúng giải pháp. Giải pháp này mô tả cách vấn đề sẽ được giải quyết như thế nào. Do đó, Bộ Vấn đề và Giải pháp định nghĩa trải nghiệm người dùng cốt lõi của sản phẩm. Các tính năng cụ thể sẽ chỉ trợ giúp và mở rộng trải nghiệm cốt lõi, nhưng sẽ không thể thay thế nó. Thiết kế tương tác (Interaction Design) và thiết kế trực quan (Visual Design) có thể làm sản phẩm đẹp, dễ sử dụng và làm sản phẩm nổi bật hơn so với các sản phẩm khác nhưng sẽ không làm sản phẩm có ý nghĩa hơn. Đây là lý do tại sao bộ vấn đề và giải pháp là tối quan trọng đối với sự thành công của sản phẩm.

Định nghĩa sản phẩm

Khi tư duy hướng sản phẩm, trước tiên người thiết kế UX cần trả lời được những câu hỏi sau:

• Chúng ta đang giải quyết vấn đề gì? (Vấn đề người dùng)

• Cho ai? (Đối tượng tham gia)

• Tại sao? (Tầm nhìn)

• Làm như thế nào? (Chiến lược)

• Chúng ta muốn đạt được những gì? (Mục tiêu)

Chỉ đến khi nào trả lời được tất cả các câu hỏi này thì mới tới lúc chúng ta nghĩ đến việc chính xác là chúng ta đang làm gì (Tính năng).

Sức mạnh của Tư Duy Hướng Sản Phẩm

Tư Duy Hướng Sản Phẩm mang lại nhiều lợi thế cho người thiết kế trong việc xây dựng tính năng phù hợp cho đúng đối tượng người dùng. Nó giúp hiểu được trải nghiệm người dùng một cách tổng quan; Không chỉ là Thiết kế tương tác và Thiết kế trực quan của các tính năng. Nó đảm bảo rằng các nhà thiết kế giải quyết các vấn đề thực sự của người sử dụng và theo đó làm giảm nguy cơ xây dựng một cái gì đó không ai muốn. Nó cho phép đưa ra các quyết định đúng đắn khi xây dựng các tính năng.

“Xây dựng tính năng thì dễ, xây dựng tính năng đúng cho đúng người dùng mới khó”

Tư Duy Hướng Sản Phẩm cho phép nhà thiết kế UX hỏi được những câu hỏi đúng, để xây dựng những tính năng đúng và để giao tiếp với những bên liên quan hiệu quả hơn. Nó cho phép người thiết kế nói “không” và cho phép ta do dự trước khi thêm tính năng mới nào. Bất cứ khi nào một tính năng mới được yêu cầu hoặc là ai đó có ý tưởng nào đó cho sản phẩm, người thiết kế sẽ có thể hỏi những câu hỏi phù hợp, trước khi phác thảo bản vẽ hoặc xây dựng giao diện bắt mắt:

• “Cái này có khớp với sản phẩm?”

• “Nó sẽ phục vụ cho vấn đề người dùng chứ?”

• “Người ta muốn hay cần nó? Hãy thăm dò trước!”

Việc này sẽ giúp sản phẩm mềm mỏng và hiệu quả.

Kết luận

Tư Duy Hướng Sản Phẩm đảm bảo cho người thiết kế xây dựng tính năng phù hợp với người dùng phù hợp và xử lý những vấn đề thực tế của mọi người. Nó tăng cường khả năng ra quyết định đúng và là nền tảng của thành công trong xây dựng sản phẩm mà người dùng muốn. Tư Duy Hướng Sản Phẩm đặt ra một mối quan hệ hiệu quả giữa việc quản lý sản phẩm và thiết kế giao diện người dùng và do đó dẫn tới sản phẩm sẽ mạnh mẽ hơn. Đó là lý do tại sao Tư Duy Hướng Sản Phẩm sẽ là thế hệ tiếp theo trong thiết kế trải nghiệm người dùng.

Nguồn: Why Product Thinking is the next big thing in UX Design

Không có gì là bí mật cả. Sự hài lòng của nhân viên mang lại tất cả những yếu tố thành công trong kinh doanh. Một nhân viên nhảy việc có thể khiến công việc làm ăn bị thiệt hại khoảng 20% lương chi trả cho họ, chi phí kinh doanh của bạn xoay quanh 20% tiền lương của anh ta hoặc cô ấy – và đó chỉ là một phần của tác động. Năng suất lao động, văn hoá công ty và danh tiếng thương hiệu có thể bị ảnh hưởng chỉ vì sự ra đi của một thành viên.

Hãy là người trung thực. Tuy nhiên, thật sự mà nói không phải luôn luôn có sự giao tiếp cởi mở giữa giám đốc điều hành và nhân viên. Ngay cả khi điều này tồn tại, nhân viên thường e ngại bộc lộ những điều họ mong muốn, nhu cầu và phản hồi của họ sẽ khiến họ có vẻ là những người đang phàn nàn, do đó dẫn đến những hậu quả tiêu cực.

Nếu một lực lượng lao động sáng tạo, năng suất và đầy nhiệt huyết nằm trong danh sách ưu tiên của bạn trong năm 2017, thì hãy cân nhắc một số điều mà nhân viên của bạn có thể mong muốn nhưng họ sẽ chẳng hề nói cho bạn biết.

1. Cập nhật công nghệ ở nơi làm việc

Nếu công nghệ không tồn tại, không hoạt động đúng hoặc không giúp nhân viên của bạn làm việc, năng suất sẽ bị ảnh hưởng. Ngoài các công nghệ phổ biến ở nơi làm việc, có rất nhiều ứng dụng di động, các công cụ tương tác, các công cụ đa phương tiện và nhiều phần mềm, máy móc khác rất đáng được đầu tư để nâng cao năng suất, hiệu quả và sự tham gia tích cực của nhân viên.

2. Cắt giảm quản lý vi mô

Quản lý vi mô làm suy yếu khả năng tư duy của lực lượng lao động. Nó cũng sẽ khiến đội ngũ quản lý bị dàn trải, và nhân viên bị mất quyền tự chủ. Đây không phải là môi trường dành cho sự đổi mới phát triển, và có thể khiến cho những nhân viên tài năng rcủa bạn rời khỏi công ty.

3. Linh hoạt hơn

Tính di động là một trong những món quà tuyệt vời nhất mà công nghệ mang đến cho lực lượng lao động ngày nay. Hơn 60 phần trăm người lao động báo cáo rằng nhờ tính năng này, họ có thể chọn lựa làm bán thời gian ngoài văn phòng. Theo một báo cáo của Forbes, nói chung những người lao động này nói cũng cảm thấy hạnh phúc hơn, bởi vì họ “tận hưởng sự tự do và tính linh hoạt.”

40% lao động còn lại thì sao? – Đừng quá ngạc nhiên nếu họ bỏ việc để nhảy sang một công ty khác hỗ trợ họ có được sự cân bằng lớn hơn giữa cuộc sống và công việc.

4. Một tương lai nghề nghiệp rõ ràng

Nhân viên của bạn muốn biết có những cơ hội gì phía trước và cũng muốn biết rằng tổ chức của bạn có nhận ra họ là đối tượng phù hợp cho tương lai của tổ chức. Không có một tầm nhìn rõ ràng, không có động lực thúc đẩy, thì nhân viên sẽ cảm thấy không được thoả mãn và không được đánh giá cao.

5. Cơ hội giáo dục liên tục

87% những người trẻ tuổi cho rằng sự phát triển rất quan trọng trong công việc, đó là nhân tố hàng đầu để duy trì nhân viên. Nếu bạn muốn nuôi dưỡng một lực lượng lao động đầy tham vọng, bạn phải cung cấp cho họ cơ hội để tiếp tục học tập, trau dồi kỹ năng và phát triển như các chuyên gia.

6. Môi trường làm việc lý tưởng

Khoảng 30 phần trăm cuộc sống con người được sử dụng để làm việc. Theo báo cáo của Medical News Today, việc ngồi quá lâu trong một khoảng thời gian dài mỗi ngày gây ảnh hưởng tiêu cực đến sức khoẻ của chúng ta. Bằng cách đầu tư vào các vật dụng như ghế ngồi, bàn làm việc và bàn phím, bạn có thể tạo môi trường lành mạnh hơn cho nhân viên của mình, cho phép họ làm việc ít hơn và hiệu quả hơn. Một không gian làm việc thoải mái hơn cũng sẽ cải thiện sự tích cực của nhân viên và năng suất tổng thể.

7. Các quy trình hợp lý và hiệu quả

Một yếu tố khác giết chết sự hài lòng công việc là các quy trình bất hợp lý. Nếu nhân viên buộc phải tuân thủ quy trình làm việc và các giao thức mà họ biết là không hiệu quả và tổ chức không có động thái cải tiến nào, họ sẽ bắt đầu tìm kiếm một ông chủ có tầm nhìn chiến lược rộng lớn hơn.

Các mẹo nhỏ: Công nghệ quản lý tài sản, không gian và nơi làm việc sẽ giúp các nhà lãnh đạo xác định được những tắc nghẽn bất hợp lý trong quy trình làm việc và điều chỉnh kế hoạch chung để sắp xếp các quy trình và hỗ trợ tốt hơn các yêu cầu về nguồn lực.

8. Công nhận và đánh giá

Nhân viên luôn muốn được các nhà quản lý và lãnh đạo điều hành quan tâm, lắng nghe. Họ muốn được công nhận khi họ hoàn thành tốt công việc, nhận được các phản hồi mang tính đóng góp, xây dựng nếu họ làm chưa tốt và thường xuyên đánh giá hiệu suất công việc để họ biết trình độ của họ đang ở đâu.

9. Các nội dung bao hàm

Khoa học đứng đằng sau lý do tại sao phương tiện truyền thông xã hội lại phổ biến trong cộng đồng như thế, đó là nơi và là phương tiện để con người chúng ta truyền tải các mong muốn vốn có của chính mình. Sự bình đẳng giữa các văn phòng làm việc biểu hiện nền văn hóa công ty vững chắc, là điểm tựa tuyệt đối để nhân viên tin tưởng gắn bó một chặng đường dài. Hãy xác định mục đích và giá trị của thương hiệu, chỉ định các đại sứ văn hoá, đầu tư vào việc cư xử và đối đãi với nhân viên của bạn và xây dựng các sự kiện để tăng cường mối quan hệ giữa các văn phòng.

10. Sự đền bù công bằng

Chúng tôi để “mong muốn” này vào cuối danh sách vì đáng ngạc nhiên là đây không phải mục được ưu tiên nhất trong danh sách các mong muốn của nhân viên, nhưng nó vẫn đặt ra những vấn đề mà tổ chức cần lưu ý đến. Nhân viên của bạn biết giá trị của họ, và các nền tảng trực tuyến như Glassdoor và PayScale thấu hiểu điều đó. Sự đền bù cạnh tranh sẽ giữ cho nhân viên của bạn trung thành và luôn có động lực trong công việc.

Chỉ vì nhân viên của bạn đã không đề cập đến các mong muốn trên, điều đó không có nghĩa là chúng không nằm trong những mục lưu tâm hàng đầu. Nhưng hãy đảm bảo rằng bạn đang nỗ lực hết mình để đáp ứng đầy đủ 10 mong muốn và nhu cầu đó, bạn sẽ có được một lực lượng lao động năng suất hơn, cảm thấy hài lòng hơn và hạnh phúc hơn.

Nguồn dịch: 10 Things Employees Want From Leaders (But Won’t Tell Them)

Thời gian là tài nguyên không thể làm mới lại được, do đó nó là một trong những thứ quý giá nhất mà chúng ta có được.

Là một chủ doanh nghiệp, có lẽ bạn đang phải đảm nhiệm nhiều trọng trách để mọi việc được hoàn thành tốt. Chúng sẽ làm bạn rất dễ bị xao lãng, mất tập trung và lãng phí thời gian quí giá vào những việc không quan trọng. Dưới đây là 10 mẹo rất hữu ích giúp bạn quản lý được thời gian của mình.

1. Cho mình thời hạn cực ngắn… và tuân thủ theo nó.

Hãy nhớ cụm từ then chốt này của Sheryl Sandberg (COO của Facebook): Làm xong còn tốt hơn là hoàn hảo. Nếu bạn là một người cầu toàn, thì chắc chắn rằng bạn sẽ nhận được kết quả công việc theo cách của bạn. Bạn sẽ không làm qua loa (đó không phải tính cách của bạn?), bạn sẽ làm cho ra kết quả. Hãy cho mình thời hạn ngắn hơn bình thường và tuân thủ theo nó.

2. Ghi các việc chính cần làm vào thời khóa biểu.

Đừng đợi đến khi có thời gian mới hoàn thành những việc quan trọng. Nếu như thời gian biểu của bạn còn khoảng trống, cũng giống như với nước vậy, những việc không quan trọng sẽ tự động bị xen vào đó (xem phần 7).

3. Không làm nhiều việc cùng một lúc.

Tất cả các nghiên cứu đã chỉ ra rằng làm nhiều việc cùng một lúc (multi-tasking) là không hiệu quả (Hãy tin tôi đi – bạn có lẽ không có thời gian để tìm hiểu đâu). Bạn sẽ làm hiêụ quả và năng suất hơn nếu bạn chỉ tập trung duy nhất một việc vào một thời điểm.

4. Ủy nhiệm tất cả những việc ngoài khả năng của bạn cho người khác có khả năng hơn.

Tập trung thời gian và năng lượng của bạn vào những việc có lợi ích hơn. Nếu bạn không biết làm thế nào để ủy nhiệm việc cho người khác, hãy đọc Ủy nhiệm những gì và như thế nào rồi hiện thực nó và làm những việc quan trọng khác.

5. Có một đội ngũ hiệu suất cao và trao quyền cho người làm việc tốt nhất.

Quản lí vi mô thì thường không thoải mái cho cả bạn và những người khác có liên quan. Đừng làm vậy. Hãy thuê những người mà thông minh hơn, giỏi hơn, nhanh hơn và nhiều kinh nghiệm hơn bạn và bạn sẽ thấy hài lòng.

6. Chia thời khóa biểu ra nhiều phần hoặc theo ngày.

Thứ hai là ngày tôi quản trị và xây dựng nghiệp vụ – nó giúp tôi biết được tôi cần phải tập trung ở đâu và việc gì là quan trọng nhất cần phải làm vào hôm đó. Những việc này đều đã được phân bổ trong công việc và trong tuần làm việc của tôi. Bạn có thể dễ dàng “phân khúc” thời khóa như tôi vậy.

7. Để những việc tốn thời gian vào cuối ngày.

Những việc tốn thời gian (mà vẫn cần phải làm) như: mạng xã hội, email, etc.. nên để vào cuối ngày. Làm như thế sẽ giúp bạn không bị lãng phí thời gian quý giá và năng suất của mình vào những thứ không có lợi ích, không quan trọng hoặc không nằm trong khả năng của mình.

8. Nếu gặp khó khăn vào việc gì đó mà không có tiến triển gì, hãy bỏ qua hoặc tìm sự giúp đỡ.

Đừng tự đâm đầu vào tường. Có lẽ bạn chỉ cần ngồi một mình thư giãn thôi và/hoặc thay đổi cách giải quyết vấn đề.

9. Hãy tìm một người huấn luyện hoặc cố vấn để dẫn dắt mình.

Một người huấn luyện hoặc cố vấn tốt sẽ luôn giữ cho bạn có tinh thần trách nhiệm, hỗ trợ bạn khi cần thiết và giúp bạn thấy được những lúc bạn đang tự huỷ hoại chính bản thân mình như thế nào. Chúng ta ai cũng cần sự giúp đỡ, không ai trong chúng ta có thể tự thân đạt được 100% mục đích của mình. Hãy tìm người mà bạn tin tưởng, người mà sẽ dẫn dắt VÀ thúc đẩy khi bạn cần.

10. Thiết lập thói quen hằng ngày tùy vào cơ địa của bạn.

Hãy tự chăm sóc bản thân mình thật tốt, cả thể xác lẫn tinh thần. Nếu không, bạn sẽ không làm gì tốt được.

Dịch từ: 10 Time-Management Tips for Busy Executives

Trong khi các nhân viên làm việc tại chỗ có thể chỉ cần tận dụng 5 phút giải lao cạnh máy nước lạnh để nói chuyện hoặc tán gẫu với nhau, thì việc định hình và duy trì văn hoá làm việc từ xa đòi hỏi nhiều nỗ lực hơn. Tạo dựng sự tương tác dễ dàng giữa các nhân viên là nhiệm vụ bạn cần làm, nhưng bằng cách nào?

Nhìn lại Process Street, nơi chúng tôi điều hành một con tàu từ xa, ở đó chúng tôi lựa chọn một hoặc hai điều để tạo dựng một nền văn hoá từ xa bền vững. Điều hay nhất của những nền văn hoá này là chúng có thể tự duy trì – chỉ cần thiết lập chúng và bổ sung tiểu tiết theo yêu cầu. Để xây dựng nền văn hoá này các đội ngũ làm việc từ xa chỉ cần đạt được một hoặc hai nhân tố then chốt, nhưng ở đây tôi sẽ chia sẻ 4 điều được coi là cốt lõi của sự thành công.

Vì vậy, nếu bạn lần đầu thuê các nhân viên làm việc từ xa, cảm thấy lo lắng vì thiếu sự tương tác và khoảng cách giữa nhân viên và công ty, hãy tĩnh tâm và thật thoải mái. Chúng tôi đã thấu hiểu hoàn cảnh của bạn.

Làm việc từ xa là linh hoạt; bạn cũng nên như vậy

PHOTO: DAMIAN ZALESKI

Các nhân viên làm việc từ xa được hưởng lợi từ sự linh hoạt; việc áp dụng một khung giờ làm việc mệnh lệnh đối với họ sẽ là một thảm hoạ. Thay vì điều đó, bạn hãy khuyến khích nhân viên tự đưa ra khoảng thời gian trong ngày giúp họ có thể làm việc năng suất nhất.

Ví dụ, một số người làm việc như những con cú đêm, và hiệu quả tốt nhất là làm việc vào buổi sáng và tối. Hãy để cho những người này được phép làm việc 4 tiếng buổi sáng và 4 tiếng buổi tối để họ cống hiến năng suất nhất, thay vì ép họ phải làm việc theo giờ hành chính. Buffer là ví dụ điển hình khi họ đưa ra chính sách rằng nhân viên có thể làm việc vào giờ nào họ cảm thấy thoải mái nhất.

Điều này không chỉ khiến nhân viên thấy vui vẻ với công việc mà còn giúp họ hoàn thành công việc tốt hơn và tạo môi trường nuôi dưỡng nền văn hoá làm việc từ xa.

Giao tiếp tập trung

Nền văn hoá từ xa sẽ không thể được nuôi dưỡng – đơn phương tồn tại – nếu quá trình giao tiếp diễn ra dàn trải bằng các tài khoản email và 5 ứng dụng khác nhau. Nếu các nhân viên trong đội không biết người khác đang nói về điều gì, hoặc không thể bình luận do đã xoá đi một chuỗi dài email, thì toàn bộ dự án có thể sẽ đổ bể.

Tuy nhiên, nếu bạn khiến giao tiếp tập trung bằng cách đảm bảo mọi thứ chuyển tiếp chỉ trong 1 hoặc 2 ứng dụng, thì gần như các thành viên trong đội đều nắm rõ tình hình. Đây là bí quyết đối với các đội làm việc từ xa với các múi giờ khác nhau, bởi vì chúng sẽ gần như xoá đi vấn đề nảy sinh do giao tiếp chậm trễ giữa châu Mỹ và châu Âu – không bỏ sót bất kỳ điều gì (thậm chí những mảng lớn tin nhắn tới nhân viên offline) bởi vì mọi người đều biết cần phải làm thế nào để nắm được tình hình.

Đây cũng chính là phương thức để chiến đấu với nguy cơ thực tế đó là sự cô lập, mà tất cả các nhân viên (các đội) làm việc từ xa đều phải đối mặt; nền văn hoá làm việc từ xa sẽ tiếp tục được nuôi dưỡng khi tránh được việc tự bị phá huỷ. Tại sao không áp dụng khi Sandwich Video đã có một video để chứng minh cho điều này?

Thêm gia vị cho văn hoá

Văn hoá sẽ tự tồn tại nếu những người trong cuộc cảm thấy có điều gì đó đáng duy trì. Nếu quy trình xây dựng văn hoá công ty chỉ là “giao tiếp, đảm bảo mọi người thấy được các tin nhắn có liên quan tới họ”, thì nó giống như nói với ai đó chỉ quan tâm tới điều giản đơn. Nó không có tác dụng, vì thế bạn cần làm nhiều thứ hơn chứ không đơn thuần là đảm bảo việc chỉ cho mọi người cách giao tiếp với nhau.

Bạn cần phải bổ sung sức sống cho văn hoá công ty, và cách tốt nhất là lôi cuốn được sự tham gia của toàn thể công ty, thu hút cá tính của họ chứ không chỉ là thảo luận công việc. Tạo dựng sự cạnh tranh hữu nghị trên cơ sở lợi ích chung hoặc lên lịch cho các sự kiện chung sẽ giúp tạo sự gắn kết giữa các nhân viên và trao đổi câu chuyện hài hước ngoài giờ làm.

Ví dụ, tại Process Street, hiện chúng tôi đang tiến hành hai cuộc thi, và tương lai sẽ thực hiện thêm. Chúng tôi là những người khác thường (geeky) không hề ngại ngùng, nên việc tổ chức cuộc thi Heartstone cho toàn thể công ty sẽ phù hợp với văn hoá của chúng tôi; một trò chơi bài tập thể trong đó bạn sẽ đấu với những người chơi khác. Để đảm bảo cuộc thi không bị gian lận bởi chủ nghĩa kinh nghiệm, chúng tôi cũng giới hạn việc lựa chọn quân bài đối với cỗ bài sẵn có khi chúng tôi có cả những người chơi mới và lâu năm trong đội của mình.

Nếu đội của bạn không giống kiểu thích trò chơi, bạn có thể tạo ra cuộc thi về các chủ đề khác. Chúng tôi cũng thực hiện cuộc thi giả tưởng để xem ai có thể tìm ra bộ phim hay nhất và tồi nhất. Mỗi tuần, các ứng viên sẽ post một phim lên kênh Slack chung, để sau đó chúng tôi cùng xem và đánh giá chất lượng, chúng tôi đã đánh dấu lưu ý một số như The Beast Must Die, Shivers và (gần đây nhất) là piranha Sharks. Mặc dù đó không phải là những phim hay nhất đáng xem, nhưng hoạt động này giúp chúng tôi xích lại gần nhau là một đội và là điều chúng tôi có thể thảo luận và gắn kết ngoài công việc.

Khơi mào

Sự hoà nhập là thứ mà bạn vừa phải bỏ công sức xây đắp, và (sau đó) vừa là thứ mà gần như bạn có thể để văn hoá xây đắp cho mình. Hãy đảm bảo quy trình tạo sự hoà nhập cho nhân viên là bền vững bằng cách giới nhiệu nhân viên mới với các thành viên khác trong đội và khuyến khích đội ngũ cũ cởi mở. Đừng khiến cho những cuộc trò chuyện bị ép buộc, mà hãy xây dựng nền tảng then chốt nhằm đảm bảo cho những nhân viên làm việc từ xa vừa biết phải liên hệ với ai khi gặp vấn đề vừa cảm thấy thoải mái khi làm điều đó.

Khi nền văn hoá công ty được thiết lập bền vững, nó sẽ thực sự góp phần lớn cho quy trình tạo sự hoà nhập nhân viên, bởi vì các cuộc thi, sự kiện và tinh thần của đội sẽ gắn kết mọi nhân viên mới vào văn hoá công ty một cách tự nhiên. Bạn sẽ vẫn cần phải giới thiệu họ với đội của mình nhưng với nền văn hoá giao tiếp, các cuộc thi và sự phối hợp sẽ giúp những người mới hoà nhập với công ty vì mục đích chung.

Bạn đã có được bí quyết để xây dựng văn hoá có thể tự tồn tại trong công ty, thậm chí khi đội ngũ nhân viên làm việc từ xa. Mặc dù cần một quy trình để thiết lập một nền văn hoá hiệu quả, nhưng kết quả mang lại là điều hiển nhiên. Làm cho nhân viên của bạn trung thành, năng suất hơn và trên hết là hạnh phúc với công việc họ đang làm, bất kể là làm việc từ xa hay không, bạn sẽ thấy rằng bất kể nền văn hoá bạn xây dựng điên rồ cỡ nào, nó cũng sẽ đem lại hiệu quả tích cực.

Dịch từ: HOW TO CREATE A SELF-SUSTAINING REMOTE CULTURE

Setting up a CI/CD (continuous integration/continuous delivery) system for Docker applications to be deployed on staging and production environment with scalability and high availability is not hard. It took a while to get it done properly, and today I will show you how to set up that system properly with a Next.js application as an example. You can apply the same process for all other kinds of Docker applications. So let’s get started.

Prerequisites

Newcomers to Docker ecosystem can enjoy this tutorial.

Experienced ones to Docker ecosystem can review this for your approach and suggest what we can do for a better approach.

If you know these systems below, that’s great and easier to follow this tutorial:

• Docker
• gitlab-ci, travis-ci as CI/CD system
• Heroku as a PaaS (Platform as a Service)
• Kubernetes (Production-Grade Container Scheduling and Management)
• Helm (The Kubernetes Package Manager)

Getting Started

First, you need to have Docker installed on your system. To make it easier for all platforms (Linux, macOS, Windows), we’re going to use teracy-dev for local dev environment.

To know why teracy-dev, see the blog Teracy-dev – the Only Truly Universal Productive Development Platform With Docker on macOS, Linux and Windows.

You’re not required to use teracy-dev, however, using it should help you follow this tutorial more easily.

We’re going to use https://github.com/acme101/nextjs-hello-world as an example project.

acme101 is a sample github organization which has all the best practices from teracy-dev applied for organizations, follow it and you can’t get lost.

nextjs-hello-world is the simplest seed code for Next.js applications with Docker workflow, CI/CD system:

• CI/CD with gitlab-ci: https://gitlab.com/acme101/nextjs-hello-world/pipelines

• CI/CD with travis-ci: https://travis-ci.org/acme101/nextjs-hello-world/builds

• Auto deployment to Heroku: https://acme-nextjs-staging.herokuapp.com/

• Auto deployment to GKE (Kubernetes) with terapp.com (A record domain): https://acme-nextjs-staging.terapp.com/

To set up the project on local development:

• Follow: https://github.com/acme101/dev-setup/blob/master/README.md

• Check out the repo into the acme-dev/workspace directory

That’s it, you’re ready to work on the local dev environment.

Local Dev Environment

Our development philosophy is this: everything can and should be done on local development with consistent behaviors between all developers and production deployments.

And Docker helps us with that to create a consistent build-time and run-time environment for all.

Usually, there are 3 modes on local dev for our workflow:

• Dev Mode: developers work on this for new changes, this usually contains development dependencies.

• Prod Mode: developers need to make sure that production Docker image should work on local dev. This production Docker image, which is different from the one from dev mode, will contain only the production dependencies, and the runtime environment only.

  If developers can only make it work on dev mode, prod mode can break. If prod mode breaks, developers can check and fix it on local dev. This is really conveninent and time saving.

• Prod Review Mode: we should review the work from others and this mode help us for faster reviewing process. Basically, everyone’s work branch will have the corresponding production Docker image that we can review it right away on our local dev environment. We don’t have to checkout the codes to start reviewing.

  This is helpful for us to set up CI/CD system for reviewing process later: when a pull request is sent, the CI/CD system should deploy it right away for QA to validate, for example.

The following is the more details about how to use these modes:

Dev Mode

To run dev mode on the current source code.

1
2
3
4

$ vagrant ssh
$ ws
$ cd nextjs-hello-world
$ docker-compose up -d dev && docker-compose logs -f dev

Open dev.nextjs.acme.dev (http + https modes) to check it out.

Prod Mode

To run prod mode on the current source code.

1
2
3

$ docker-compose run --rm dev yarn run build && \
  docker-compose -f docker-compose.yml -f docker-compose.prod.yml build prod && \
  docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d prod

We usually scale at least 2 or more containers, so please scale it on local dev too to make sure scaling should work:

1

$ docker-compose -f docker-compose.yml -f docker-compose.prod.yml scale prod=2

Open nextjs.acme.dev (http + https modes) to check it out.

Don’t forget to remove the container after checking out for cleaning up:

1
2

$ docker-compose -f docker-compose.yml -f docker-compose.prod.yml stop prod && \
  docker-compose -f docker-compose.yml -f docker-compose.prod.yml rm -f prod

Prod Review Mode

To review prod mode from different built Docker image.

For example, I need to review the hoatle/nextjs-hello-world:features-1-something Docker image from @hoatle.

1
2
3

$ export DOCKER_IMAGE_REVIEW=hoatle/nextjs-hello-world:features-1-something && \
docker-compose -f docker-compose.yml -f docker-compose.review.yml pull review && \
docker-compose -f docker-compose.yml -f docker-compose.review.yml up -d review

We usually scale at least 2 or more containers, so please scale it on local dev too to make sure scaling should work:

1

$ docker-compose -f docker-compose.yml -f docker-compose.review.yml scale review=2

Open review.nextjs.acme.dev (http + https modes) to check it out.

Don’t forget to remove the containers after checking out for cleaning up:

1
2

$ docker-compose -f docker-compose.yml -f docker-compose.review.yml stop review && \
  docker-compose -f docker-compose.yml -f docker-compose.review.yml rm -f review

That’s how we, developers, usually work on local development. And to streamline the work, we need to deploy the applications on production system.

The docker-compose commands above are rather long, maybe you can create bash files to run more easily, for example, $ dev.sh start, $ dev.sh stop, $ prod.sh build, $ prod.sh start, $ prod.sh stop, $ review.sh start <image_for_review> and $ review.sh stop.

Production System

We build Docker images for deploying so we can leverage any system that accept Docker image.

In this tutorial, we use Heroku and Kubernetes, but you can choose whatever system that Docker is supported.

Heroku is very easy to be used, just push the Docker image and it should work.

Kubernetes (K8s) and Helm is easy to work with, it’s mature and it gives us more control over everything. I recommend using Kubernetes for production system to automate it all.

Heroku Deployment

You can follow https://devcenter.heroku.com/articles/container-registry-and-runtime to deploy your Docker image to Heroku.

K8s Deployment

You can use Google Container Engine (GKE) to deploy K8s applications. Using Helm as the K8s package manager is more easier and convenient.

I created the Helm chart for this application here: https://github.com/acme101/nextjs-hello-world/tree/develop/helm-charts/nextjs-hello-world

We can install it right away:

1

$ helm install halm-charts/nextjs-hello-world

CI/CD Systems

To automate all the development integration and production deployment, we use CI/CD systems. You can use any CI/CD systems available. In this sample project, I set up for gitlab-ci and travis-ci, they share the same steps and these steps can be applied to any other CI/CD systems.

A typical CI/CD system will need to:

• check for new changes

  • code style
  • security
  • all kinds of tests

• when checks passes, build the production Docker image and push to the Docker registry

• take the production Docker image and deploy it to the production systems

• everyone enjoys the new changes!

The CI/CD system should work on any forked repo, too.

And to get it work, we need to provide the some environment variables settings. To know more about some of these variables, please follow:

• How to deploy on Heroku: https://github.com/acme101/dev-setup/blob/master/docs/how-to-deploy-on-heroku.md

• How to deploy on GCP: https://github.com/acme101/dev-setup/blob/master/docs/how-to-deploy-on-gcp.md

Sum up

In this tutorial, I’ve introduced the development philosophy and workflow that we apply for all our projects at Teracy and our clients’ projects. I hope that it could be helpful to others to boost your productivity with software development.

Happy developing!

Cách đây chỉ vài năm, tôi đã từng là một người nóng vội. Bất cứ khi nào dù ai nói điều gì thì tôi cũng sẽ nghĩ cách phủ định ý kiến của họ. Tôi sẽ không nề hà phản bác ngay nếu như có ý kiến nào đó không phù hợp với thế giới quan của tôi.

Điều này có nghĩa là quan điểm của tôi phải là nhất trong mọi tình huống. Tuy nhiên, khi đưa ra những ý kiến này, tôi đã không thực sự suy nghĩ chín chắn về vấn đề. Bạn càng phản ứng nhanh, thì bạn càng ít suy nghĩ. Không phải luôn luôn, nhưng thường là vậy.

Thật dễ khi nói về các phản xạ tự nhiên như thể chúng là thói quen của người khác, và chỉ có người khác mắc phải mà không hề liên quan đến bạn. Bạn cũng có những phản xạ tự nhiên này. Và nếu những người hàng xóm của bạn không hề miễn nhiễm với thói quen này thì bạn cũng vậy.

Vần đề này cũng xảy ra với tôi vào năm 2007. Trong khi tôi được mời phát biểu tại hội nghị của tổ chức Sáng Kiến Kinh doanh tại Providence, RI. và Richard Saul Wurman cũng vậy. Sau bài thuyết trình của tôi thì đến lượt Richard, anh ta bước lên giới thiệu về bản thân và dành lời khen ngợi cho bài thuyết trình của tôi. Đó thật là một cử chỉ hào phóng, mà đáng ra anh ta không cần thiết phải làm như thế.

Và tôi đã làm gì? Tôi đã phản kháng ngay bài thuyết trình của anh ta. Trong khi anh ta đang hào hứng và say mê đưa ra các luận điểm của mình trên sân khấu, tôi đã liệt kê danh sách hàng loạt những ý kiến tôi không đồng quan điểm. Và khi được mời đối thoại trực tiếp với anh ấy, tôi đã nhanh chóng phản biện lại các ý kiến của anh ấy. Có lẽ lúc đó, tôi trông thật tệ khi bới móc sai sót của người khác.

Và rồi phản ứng của anh ấy đã làm thay đổi cuộc đời tôi. Anh ấy chỉ nói một câu đơn giản: “Này ông, hãy dành ra 5 phú để suy nghĩ”. Tôi hỏi lại ý anh ấy là gì? Anh ấy trả lời rằng đưa ra những quan điểm trái chiều, đưa ra những phản biện đều rất tốt, và thật tuyệt vời khi mọi người có những quan điểm và niềm tin mạnh mẽ, nhưng hãy dành thời gian để suy nghĩ lại về những luận điểm của tôi trước khi bạn chắc chắn rằng bạn muốn tranh cãi về những luận điểm đó. Hãy dành “Năm phút” để “suy nghĩ” chứ không phải phản ứng lại. Anh ấy hoàn toàn đúng. Tôi đã tham gia vào cuộc thảo luận chỉ để nhằm chứng minh một điều gì đó và tôi không thể học hỏi gì từ cuộc tranh luận này.

Đây là một khoảnh khắc đáng nhớ trong cuộc đời tôi.

Richard đã dành 30 năm sự nghiệp của mình để suy ngẫm về những vấn đề này. Còn tôi thì chỉ biết đến nó có vài phút. Vào giờ phút đó, ông ấy có thể đã sai và tôi có thể đã đúng, nhưng tốt hơn hết là nên suy nghĩ sâu sắc về một điều gì đó trước khi bạn chắc chắn rằng bạn đã đúng.

Cũng có sự khác biệt giữa việc đặt câu hỏi và việc phản bác vấn đề. Phản bác có nghĩa là bạn biết chắc rằng mình đúng. Đặt câu hỏi có ý nghĩa là bạn muốn biết. Bạn muốn học hỏi nhiều hơn.

Học nghĩ trước khi phản ứng nhanh là việc cần theo đuổi suốt đời. Điều này thật sự khó khăn. Đôi khi tôi vẫn nóng vội trong những trường hợp không cần thiết. Nhưng tôi cũng đã cố gắng khắc phục và tận hưởng tất cả những lợi ích mà nó mang lại, tôi trở nên điềm đạm hơn.

Nếu bạn không chắc chắn lý do tại sao điều này là quan trọng, hãy suy nghĩ trích dẫn này từ Jonathan Ive về việc coi trọng các ý tưởng của Steve Jobs:

“Và cũng như Steve đã yêu thích những ý tưởng và yêu thích công việc, ông xem quá trình sáng tạo ý tưởng là một điều rất quý hiếm và đáng trân trọng. Bạn thấy đấy, tôi nghĩ ông ấy hiểu rõ hơn bất kì ai rằng cuối cùng thì những ý tưởng luôn có sức mạnh mặc dù ban đầu chúng chỉ là những suy nghĩ mỏng mảnh, không trọn vẹn, dễ dàng bị bỏ qua, và đi vào bế tắc.”

Thật sự, những ý tưởng rất mong manh. Những ý tưởng này thường bắt đầu từ những suy nghĩ thoáng qua, không có chủ đích, không được đào sâu hay nhào nặn, vì vậy chúng ta dễ dàng phớt lờ hoặc bỏ lỡ chúng.

Có hai thứ trên thế giới này không cần kĩ năng:

• Tiêu tiền của người khác

• Bỏ qua một ý tưởng.

Việc bỏ qua một ý tưởng rất dễ dàng vì nó không liên quan đến bất kỳ công việc nào. Bạn có thể dễ dàng giễu cợt nó. Bạn cũng có thể bỏ qua nó. Nhưng điều khó là làm sao bạn có thể bảo vệ nó, suy nghĩ về nó, khám phá, thổi hồn vào nó và dấn thân vào thử thách. Xuất phát điểm của một ý tưởng tuyệt vời có thể bị che giấu dưới dáng vẻ của một ý tưởng sai lầm.

Vì vậy, lần tới khi nghe một điều gì đó, hoặc ai đó nói về một ý tưởng hay đưa ra hoặc gợi ý một ý tưởng nào đó, bạn hãy dành ra năm phút để suy ngẫm. Hãy dành thời gian suy nghĩ về điều đó trước khi phản bác, trước khi nói rằng nó quá khó khăn hoặc như vậy là quá tốn công sức để thực hiện. Có thể những lý do biện minh là đúng, nhưng có thể có một sự thật khác đằng sau: Nó rất đáng giá.

Dịch từ: Give it five minutes

Cuộc sống năm 2016 thật là tuyệt vời. Dù ở nhà hay ra ngoài thì các bạn vẫn luôn luôn được kết nối internet.

Chỉ với chiếc điện thoại thông minh là bạn đã có cả thế giới trong tầm tay rồi. Dường như điều đó thật tuyệt vời phải không? Nhưng thực tế lại không đúng như vậy.

Hầu hết mọi người đang không sử dụng công nghệ mà bị công nghệ sử dụng.

Các ứng dụng, trò chơi, video, các bài báo, quảng cáo hay các chương trình TV đều được thiết kế để thu hút sự chú ý của bạn. Do đó bạn đã lãng phí không biết bao nhiêu thời gian mỗi tuần mà không hề hay biết. Bạn tập trung vào tất cả mọi nơi nhưng sự tập trung đó lại không dừng đúng nơi.

Bạn có nghĩ vì sao Netflix bắt đầu mỗi tập phim trong 3, 2, 1 giây không? Khi điều đó xảy ra, bạn nghĩ: “Mặc kệ, xem thêm cái này đã.”

Điều này cũng tương tự với YouTube. Bạn có nghĩ vì sao những gợi ý của nó lại tốt như thế không? Bạn bị đắm chìm vào trong những ràng buộc đó và điều này cũng áp dụng cho tất cả các nội dung. Sẽ luôn luôn có một video, 1 tập phim, bài báo, trò chơi tiếp theo lôi cuốn bạn.

Lạ kỳ rằng, hầu như những người mà đọc những thể loại báo kiểu này đều biết rằng mất tập trung là rất tệ. Và trong những năm gần đây, có một số lượng lớn các bài báo và các sách nghiên cứu đã nói về ảnh hưởng xấu của việc xao lãng.

Đặc biệt, nghiên cứu của Gloria Mark và các đồng tác giả đã chỉ ra rằng xao lãng có mối liên quan với mức độ căng thẳng hơn, sự thất vọng cao hơn, áp lực thời gian và nỗ lực.

Làm việc tập trung là rất khó. Chúng ta luôn bị phân tâm.

Và đó không phải là lỗi của bạn. Hầu hết các công nghệ đều tác động vào bản năng căn bản và khoá bạn lại, biến bạn thành người tiêu dùng.

Vì vậy, đừng nghĩ về việc chống đối lại internet hay công nghệ. Tôi cá là bạn cũng đã từng thử làm như thế trong quá khứ. “Tôi sẽ không bao giờ lướt web vô thức hàng giờ liền nữa”. Đúng thế!

Điều gì sẽ mang lại hiệu quả đây? Gần đây, tôi đã viết về việc làm thế nào để đánh bại sự trì hoãn bằng cách tạo ra 1 hệ thống. Một trong những phần quan trọng nhất của hệ thống đó là:

HÃY NGẮT KẾT NỐI INTERNET

Và chỉ có duy nhất 1 lý do để làm điều đó: cái gì nhiều quá cũng không tốt, kể cả nhiều thứ tốt cũng thế.

• Luyện tập quá nhiều? Cơ thể sẽ bị quá tải.

• Yêu quá nhiều? Bạn sẽ làm người khác ngột ngạt.

• Làm việc quá nhiều? Bạn sẽ bị kiệt sức.

• Ăn quá nhiều? Bạn sẽ bị béo phì.

• Quá nhiều nước? Bạn sẽ bị chết đuối.

Vậy tại sao bạn phải sử dụng internet quá nhiều như thế? Tôi đã tự hỏi chính mình điều này cách đây 2 năm. Tôi đã không có câu trả lời. Vì tôi đã nghĩ, tôi làm mọi thứ trong tầm kiểm duyệt của mình, tại sao lại không có internet?

Tôi sớm phát hiện ra rằng không hề có sự kiểm duyệt với việc sử dụng internet. Nó giống như một bữa tiệc tự chọn vậy. Bạn đã no, nhưng bạn vẫn tiếp tục ăn. Và sau khi bạn đã nhồi nhét bản thân mình, bạn lại cảm thấy hối tiếc vì đã làm thế.

Và điều này tương tự như việc sử dụng internet. Nó quá hấp dẫn, thoả mãn sự tò mò của bạn và có ở mọi nơi. Do vậy mà bạn đi khắp nơi cùng với nó, YouTube, Whatsapp, Facebook, Snapchat…

Tôi đang cố loại bỏ mọi thứ làm mình xao lãng. Tuy nhiên, tôi cũng không muốn sống như một kẻ ẩn dật, vì vậy tôi phải tìm ra một nền tảng hợp lý có hiệu quả.

Tôi đã tìm thấy rằng một tinh chỉnh đơn giản trong thái độ của tôi đối với internet đã làm được thủ thuật đó.

Tôi chuyển từ “Luôn luôn kết nối” thành “Luôn luôn ngắt kết nối”.

Thực tế, nó hoạt động như thế này:

• Trên điện thoại của mình, wifi và dữ liệu di động thường xuyên bị tắt. Tôi chỉ bật khi nào mình cần.

• Trên máy tính, tôi sử dụng 1 ứng dụng gọi là SelfControl (chỉ dành cho máy Mac) trong suốt thời gian tôi làm việc (nếu bạn dùng Windows thì hãy thử FocusMe). Ứng dụng này chặn các trang web làm bạn bị phân tán. Ưu điểm là những ứng dụng mà tôi cần như Evernote, DayOne, Office365 vẫn kết nối vì thế tôi có thể lưu trữ công việc của mình trên các dịch vụ đám mây.

“Luôn luôn kết nối” không phải là điều tốt cho sự tập trung và năng suất của bạn

Nó giống như đến phòng tập hoặc ăn tối, hay có một buổi tối lãng mạn với nửa kia của bạn. Bạn không làm những điều này trong 24 giờ một ngày. Bạn chỉ làm khoảng 30 phút, một giờ hoặc một vài giờ. Làm những việc này quá nhiều đơn giản là không mang lại hiệu quả.

Việc ngắt kết nối internet đã mang lại những điều kì diệu cho tôi. Tôi không cảm thấy cần phải cấp bách kiểm tra điện thoại, email hay các tin tức 500 lần mỗi ngày như trước kia nữa.

Và sau một thời gian, bạn cảm thấy bạn không bị bỏ lỡ bất cứ điều gì cả. Điều đó mang lại cảm giác bình tĩnh cho cuộc sống của bạn.

Tôi cũng nhận được nhiều hơn cho mỗi ngày của mình; tôi đạt được nhiều điều hơn trước kia, cảm thấy ít bị phân tâm hơn, và có nhiều thời gian cho những điều làm tôi hạnh phúc hơn.

Vào cuối ngày, internet chỉ là một công cụ. Tuy nhiên, một số người trong chúng ta lại nghĩ nó là mọi thứ. Nhưng tôi khá tự tin rằng, nhiều năm tới tôi sẽ không cần nhìn lại và hối tiếc vì đã không dành đủ thời gian cho internet.

Bạn có thể tưởng tượng được không? Bạn đang hấp hối trên giường bệnh và bạn nói với gia đình mình rằng: “Tôi rất vui vì đã được xem quá nhiều FAIL Complilation trên YouTube”.

Chắc chắn là bạn sẽ không nhìn lại thời gian đó. Có thể bạn sẽ nhớ lại thời gian bạn ở bên gia đình và bạn bè của bạn, hay những kỷ niệm khi bạn đi du lịch, hay sự vui thích trong công việc của mình.

Vì vậy hãy ngắt kết nối internet đi. Nó không mang lại cho bạn điều gì ngoài sự xao lãng.

Và sau khi đọc bài viết này, bạn hãy ngắt kết nối internet đi nhé.

Bạn sẽ có một số triệu chứng cai nghiện giống như cầm điện thoại lên khoảng 100 lần, hoặc ấn nút F trên bàn phím để mở Facebook mọi lúc. Nhưng tôi hứa với bạn điều này: Ngắt kết nối sẽ giúp bạn làm được nhiều hơn và đó chính là cuộc sống mà bạn hướng tới.

Dịch từ: Why Disconnecting From The Internet Improves Your Focus

About six months ago we published How to Develop Angular 2 Applications Easily With Docker and Angular-cli which received a lot of Angular community feedbacks and questions.

Six months has passed and we’d like to share more best practices to develop Angular applications with Docker after working on it for a while.

Received Feedbacks

We received some outstanding feedbacks and questions about:

• Problems when running Docker images after pulling the built Docker images.
• How to build prod Docker image and run it.
• How to get npm packages into the node_modules to work within your IDE, editor.

And in this blog post, we’re going to solve all of them and even with more best practices.

angular-boilerplate

Setting up Angular projects with Docker to get it work properly is not easy. Luckily, we’ve done all the heavy lifting for you with the angular-boilerplate project.

angular-boilerplate was created as a seed project that can be used to generate any new Angular projects having Docker and CI/CD system support.

To generate a new Angular project, you can check out the README.md file to follow.

angular-hello-world

In this section, I’ll introduce you the best way to set up a development environment and you can apply it for all your projects, not just Angular projects. After some first required steps to set up acme-dev, after $ vagrant up, you can start coding immediately, you don’t have to learn the set up steps at first, but defer it later.

Suppose that we’re in Acme organization and we need to work on the angular-hello-world project.

Let’s follow the README file here: https://github.com/acme101/angular-hello-world

It tells us to follow https://github.com/acme101/dev-setup/blob/master/README.md

By setting up acme-dev, we can use it for all types of projects with different stacks with the same set up workflow, it means that we can save a lot of time and effort to add more and more projects.

Re-using and scaling boots productivity and cost savings.

Best practices

By looking into the angular-boilerplate or angular-hello-world, you can see the following best practices:

• We should build the production Docker image for production deployment.

• We should work on dev mode on local dev.

• We should work on prod mode on local dev.

• We should review others’ work on local dev.

• We should use alias domains instead of fixed ports to avoid conflicts.

• We should generate node_modules to work on the npm packages safely within your IDE.

• We should use yarn instead npm as the node package manager.

• We should test both dev and prod modes on local dev.

• We should test both http and https modes on local dev.

All the instruction should be updated in the README file, please follow there to apply for your project: https://github.com/acme101/angular-hello-world/blob/develop/README.md

Summary

All the heavy lifting and best practices are documented into the corresponding projects, that’s how we should do so that everyone can follow easily and we can support each other with ease, too.

Hopefully, this will help you a lot with your Angular projects and any other projects that you can apply similarly.

Happy hacking and don’t forget to let us know your feedbacks and questions by leaving your comments!

Việc quản lý thời gian có thể là rất khó khăn. Những điều khẩn cấp và quan trọng trong cuộc sống của bạn thường rất khác nhau.

Điều này đặc biệt đúng với vấn đề sức khỏe của bạn, khi mà những vấn đề quan trọng hầu như không được xem là khẩn cấp mặc dù cuối cùng cuộc sống của bạn vẫn còn mất cân bằng.

• Không, đi tập gym hôm nay chưa cấp bách, nhưng nó lại quan trọng cho sức khỏe lâu dài của bạn.

• Không, bạn sẽ không chết vì bị stress hôm nay, nhưng nếu bạn không tìm cách vượt qua nó sớm thì bạn cũng có thể sẽ bị chết vì stress thôi.

• Không, ăn những thực phẩm sạch chưa qua công nghệ chế biến là không cần thiết để bạn có thể sống sót ngay bây giờ, nhưng sẽ giúp bạn làm giảm nguy cơ bị ung thư và bệnh tật.

Còn có điều gì mà chúng ta có thể làm nữa nhỉ? Tất cả chúng ta có 24 giờ trong 1 ngày, chúng ta thực sự phải sử dụng thời gian của chúng ta như thế nào để đạt hiệu quả hơn?

Và điều quan trọng nhất, chúng ta có thể quản lý thời gian của chúng ta như thế nào để sống vui vẻ hơn, khỏe mạnh hơn, làm những việc mà chúng ta biết là quan trọng và vẫn tiếp tục xử lý những trách nhiệm cấp bách?

Tôi đang tìm câu trả lời đó giống như bạn vậy, nhưng theo kinh nghiệm của tôi có 3 mẹo quản lý thời gian thực sự hiệu quả trong cuộc sống thực và sẽ giúp bạn cải thiện được sức khỏe và năng suất.

1. Bằng mọi giá hãy loại bỏ “công việc nửa vời”

Trong thời đại này, chúng ta luôn dễ bị phân tâm giữa việc đang làm và các yếu tố xã hội tác động. Chúng ta vẫn thường thực hiện nhu cầu về email, tin nhắn và danh sách việc phải làm trong khi đang có công việc cần hoàn thành. Và, rất hiếm khi chúng ta toàn tâm với công việc.

Việc phân tán thời gian và sức lực như vậy tôi gọi đó là công việc nửa vời. Sau đây là một số ví dụ:

• Bạn bắt đầu viết báo cáo, nhưng đột nhiên dừng lại kiểm tra điện thoại mà chẳng có lý do gì, hoặc bật facebook, twitter.

• Bạn đang thử nghiệm một chương trình luyện tập mới. Hai ngày sau, bạn đọc một chương trình mới khác và thử nghiệm. Bạn không thấy nhiều tiến triển, và vì vậy bạn lại tiếp tục tìm kiếm bài tập khác tốt hơn.

• Bạn để tâm trí của mình hướng vào hộp thư đến của email trong khi đang nói chuyện với một ai đó.

Bất kể bạn rơi vào cái bẫy của “công việc nửa vời” như thế nào và ở đâu, tất cả đều chung một kết quả: Bạn sẽ không thể toàn tâm vào công việc đang làm. Công việc nửa vời chính là lý do tại sao bạn có thể làm được nhiều hơn vào ngày hạn chót so với thời điểm hai tuần trước đó (khi bị liên tục xao nhãng).

Giống như hầu hết mọi người, tôi luôn gặp phải vấn đề này và cách tốt nhất để tôi giải quyết nó là dành thời gian tập trung vào một việc và xoá bỏ các tác động khác.

Tôi chọn một bài tập và tập trung vào đó (ví dụ: hôm nay chỉ tập trung luyện ngồi thôi. Các nội dung khác là thừa).

Tôi bỏ ra một vài giờ đồng hồ (thậm chí cả ngày) để tập trung cho một dự án quan trọng. Tôi để điện thoại ở một phòng khác, đóng email, facebook, twitter.

Việc loại bỏ hoàn toàn các mối bận tâm là cách duy nhất tôi biết để tập trung sâu vào công việc, tránh những phân mảnh có thể khiến bạn làm việc nửa vời.

Bạn có thể đạt thêm bao nhiêu hiệu quả nữa nếu như bạn thực sự tập trung vào làm việc theo cách cần phải làm và loại bỏ những công việc nửa vời?

2. Ưu tiên trước hết cho các công việc quan trọng nhất

Rối loạn và mất kiểm soát có xu hướng tăng dần theo thời gian. Đồng thời, các quyết định, lựa chọn được đưa ra trong ngày sẽ làm xói mòn trí lực của bạn. Dường như, bạn sẽ khó đưa ra được một quyết định tốt vào cuối ngày hơn so với khi mới bắt đầu công việc.

Tôi nhận thấy điều này đúng với các bài tập của tôi. Khi bài tập càng phát triển, tôi càng tốn ít trí lực để hoàn thành các khoa mục và các bài tập khó.

Vì những lý do đó, tôi luôn cố gắng đảm bảo rằng cái gì quan trọng cần làm, tôi sẽ làm trước. Nếu tôi có một bài báo quan trọng cần hoàn thành, tôi sẽ uống một cốc nước và bắt đầu viết ngay khi vừa thức dậy. Nếu có một bài tập khó cần thực hiện, tôi sẽ làm vào đầu buổi tập.

Nếu bạn luôn ưu tiên làm những việc quan trọng trước, bạn sẽ không bao giờ có ngày nào mà chưa thực hiện công việc quan trọng. Tuân thủ theo nguyên tắc này, bạn sẽ luôn kết thúc với một ngày làm việc hiệu quả, thậm chí khi mọi thứ nằm ngoài kế hoạch. Như vậy, lời khuyên hữu ích cho bạn là hãy ưu tiên làm những công việc quan trọng nhất.

3. Giảm tầm mức, nhưng luôn theo lịch

Trước đây tôi đã từng viết về tầm quan trọng của việc bám lịch thay vì bám hạn định. Đôi khi hạn định cũng có ý nghĩa riêng, nhưng tôi cho rằng khi làm một việc quan trọng trong thời gian dài, việc bám lịch sẽ có hiệu quả hơn nhiều.

Tuy nhiên, đối với bài tập ngày qua ngày, bám lịch nói dễ hơn làm. Khi hỏi bất kỳ ai đã lên kế hoạch luyện tập mỗi ngày thứ 2, thứ 4 và thứ 6, họ sẽ nói cho chúng ta biết về mức độ khó khăn của việc bám lịch như thế nào.

Để đối phó với những điều bận tâm phát sinh và vượt qua trở ngại dễ bị tác động, tôi đã thực hiện một sự thay đổi nhỏ về cách tiếp cận lịch của mình. Mục tiêu của tôi là xây dựng lịch trước, thay vì tầm mức, trái với thông lệ.

Ví dụ, giả sử hôm nay bạn dậy và dự kiến buổi chiều sẽ chạy 3 dặm. Tuy nhiên trong ngày hôm đó lịch trình của bạn bị xáo trộn và thời gian bắt đầu khó mà thực hiện được. Bây giờ bạn chỉ có 20 phút để chạy thôi.

Lúc này bạn có 2 lựa chọn:

Lựa chọn đầu tiên là nói “tôi không đủ thời gian để tập hôm nay” và bỏ khoảng thời gian đó vào việc khác. Đó là cách trước đây tôi thường thực hiện.

Lựa chọn thứ hai là, giảm tầm mức, nhưng vẫn theo lịch. Thay vì chạy 3 dặm, bạn chỉ chạy 1 dặm hoặc làm 5 lượt chạy nhanh. Nhưng bạn vẫn theo lịch và luyện tập. Tôi thấy rằng sử dụng phương pháp tiếp cận này mang lại thành công về lâu dài hơn lựa chọn đầu tiên.

Hàng ngày, tác động của việc thực hiện 5 lượt chạy nhanh không lớn, đặc biệt khi bạn đã lên kế hoạch chạy 3 dặm. Nhưng tác động luỹ kế của việc bám lịch sẽ rất lớn. Bất kể hoàn cảnh nào, mức độ bài tập ra sao, bạn đều biết rằng sẽ phải thực hiện bài tập của ngày hôm nay. Đó là cách mà mục tiêu nhỏ bé của ngày hôm nay có thể trở thành thói quen trong cả cuộc đời.

Hãy hoàn thành những thứ của ngày hôm nay, thậm chí tầm mức của nó nhỏ hơn dự kiến.

Những mẹo quản lý thời gian thực sự hiệu quả

Có hàng nghìn ứng dụng quản lý thời gian và các thiết bị giúp tăng hiệu suất công việc. Lịch, lời nhắc và danh sách công việc cần làm là những thứ bạn sẽ tìm thấy nhiều hơn so với điều bạn biết là phải làm gì với chúng. Nhưng theo kinh nghiệm của tôi, các cách quản lý thời gian hiệu quả và thực tế ở trên thật đơn giản.

Để có một cuộc sống khoẻ mạnh và năng suất, tôi cố gắng tập trung vào 3 điều:

• Loại bỏ công việc nửa vời, tập trung sâu.

• Ưu tiên trước hết cho những việc quan trọng nhất.

• Bám theo lịch và hình thành thói quen, cho dù tầm mức thực hiện có ra sao.

Còn bạn, bạn đã làm gì để quản lý thời gian tốt hơn và tăng hiệu suất công việc ở nơi làm việc, ở nhà hay phòng gym?

Lược dịch từ: 3 Time Management Tips That Actually Work

“Khách hàng không quan tâm đến giải pháp của bạn, họ quan tâm đến vấn đề của họ.” – Dave McClure

1. Ưu tiên tính hữu ích trước, tính sử dụng sau: Dụng cụ lột vỏ chuối có phải là một sản phẩm hữu ích không? Sản phẩm & dịch vụ phải có tính hữu ích trước khi được đưa vào sử dụng. Sản phẩm cần có giá trị tiện ích rõ ràng khi đáp ứng nhu cầu về thể chất hoặc tâm lí của con người.

Tại sao sản phẩm của bạn hữu ích?

2. Trọng tâm: Có điểm gì chung giữa Instagram, Dropbox, Basecamp, và Airbnb? Tất cả các ứng dụng đều có nhiệm vụ riêng và thực hiện tốt chức năng!

Khổng Tử có câu “Nếu đuổi theo hai con thỏ, bạn sẽ chẳng bắt được con nào.”

Mỗi sản phẩm có một điểm mạnh riêng và phải xác định được trọng điểm để làm cho sản phẩm có sức hút. Những công ty khởi nghiệp thường có xu hướng thêm quá nhiều tính năng, khiến cho sản phẩm không có điểm nhấn, không những không hữu ích mà còn không khả dụng, thế thì làm sao có thể thu hút được người mua.

Nhiệm vụ quan trọng mà bạn cam kết thực hiện đối với người dùng sản phẩm của bạn là gì?

3. Sản phẩm có mức giá tối thiểu: Người ta thường nói vế các sản phẩm có tính khả dụng tối thiếu, tuy nhiên chất lượng của chúng thường rất kém. Không phải vì các sản phẩm này do những người không đủ năng lực thực hiện mà bởi vì các sản phẩm này được phát hành sớm, không xuất phát từ quan điểm của người mua hay người sử dụng. Không phải vì các sản phẩm này không hữu dụng, mà bởi vì các sản phẩm này có những chức năng mà người dùng thực sự không dùng tới.

Vì vậy, hãy bỏ những sản phẩm có tính khả thi cực tiểu đi và bắt đầu với một sản phẩm chỉ cần khách hàng sẵn sàng trả tiền mua. Bắt đầu với một sản phẩm chỉ cần người sử dụng yêu thích!

Lý do lớn khiến khách hàng sẽ trả tiền để sử dụng sản phẩm của bạn là gì? Điều gì thực sự làm nên linh hồn sản phẩm của bạn?

4. Trải nghiệm người dùng không chỉ là giao diện người dùng: Nếu bạn cho rằng giao diện trông bắt mắt sẽ là một trải nghiệm người dùng tuyệt vời, thì bạn đã nhầm.

Trải nghiệm người dùng (UX) thực chất tập trung vào tính hữu ích, tính khả dụng, và có ý nghĩa với người sử dụng trong khi giao diện người dùng và thiết kế hình ảnh đảm bảo rằng sản phẩm cuối cùng có “vẻ ngoài” bắt mắt.

Sản phẩm của bạn thiên về tính hữu ích, tính khả dụng và có ý nghĩa hay thiên về hình thức bắt mắt?

5. Trải nghiệm người dùng là tất cả thuộc về người dùng: Trải nghiệm người dùng tập trung vào tính hữu ích, tính khả dụng, và có ý nghĩa đối với người dùng. Vì vậy, nếu bạn không thấu hiểu người dùng, bạn không thể làm thiết kế sản phẩm có ý nghĩa.

Không bao giờ là quá muộn để tìm kiếm những nhu cầu thật sự của người sử dụng, hãy đi và quan sát những gì người dùng làm trong ngày hoặc đề nghị cho bạn xem những gì họ làm. Bạn sẽ biết nhiều hơn về cách làm thế nào để thiết kế sản phẩm của bạn một cách hoàn toàn khác biệt. Hãy nhớ rằng, người dùng chắc chắn không phải là bà, là bố, là bạn gái, hay đồng nghiệp của bạn!

Liệu bạn đã tiếp xúc với ít nhất 10 người dùng thực tế và có tiềm năng chưa?

6. Sử dụng công cụ đồng cảm Empathy: Nhiều CEO khởi nghiệp tin rằng Axure và Photoshop là những công cụ trải nghiệm người dùng hữu ích nhất. Điều thú vị là, tất cả nhà khởi nghiệp đều lưu tâm về giao diện người dùng chứ không phải trải nghiệm người dùng!

Đã khi nào bạn nghe về một công cụ tuyệt vời có tên Empathy chưa? Empathy được các chuyên gia sáng tạo hàng đầu trên toàn thế giới sử dụng để thiết kế các sản phẩm tuyệt vời.

Vâng, tôi đang nói về sự đồng cảm của con người đơn thuần. Đồng cảm là khả năng nhận ra những trải nghiệm cảm xúc của người khác – người dùng. Bạn đồng cảm khi bạn cảm được những điều mà người khác đang cảm nhận, đó là những biểu cảm, hi vọng, khát khao và nỗi đau của họ.

Nếu cô lập trong cách làm, bạn sẽ chỉ tạo ra những sản phẩm mà không ai muốn sử dụng. Khi bạn đồng cảm với người dùng, bạn sẽ làm ra các sản phẩm tuyệt vời.

Bạn có thể kể 5 câu chuyện người dùng tuyệt vời vể sản phẩm của bạn?

7. Định hình concept trên giấy: Khi concept được xây dựng bằng một công cụ điểm ảnh chính xác hoàn hảo, phản hồi về nó từ người dùng chỉ là màu sắc, phông chữ và bố cục, chứ chẳng bao giờ đề cập tới concept.

Tuy nhiên, khi concept được phác hoạ trên giấy hoặc bảng trắng, người dùng sẽ phản hồi về lợi ích và tính hữu dụng của sản phẩm, đó là điều bạn thực sự cần! Nguyên mẫu được phác thảo trên giấy nhanh chóng, dễ dàng, liên hồi, và chi phí bằng 0. Thêm vào đó, bạn nhận được thông tin phản hồi về các khái niệm sản phẩm.

Khi đã định hình xong ý tưởng sản phẩm, sẽ là lúc bạn cần sử dụng đến các công cụ prototyping ban đầu để tạo ra các wireframes chi tiết.

8. Thiết kế liên hồi: Người làm marketing sử dụng các phép mô phỏng thị trường và phần mềm để kiểm thử. Người thiết kế cũng cần phải tiến hành kiểm thử để phát hiện vấn đề và hiệu chỉnh. Trong nghề thiết kế, việc kiểm thử được thực hiện với những người dùng thực ở các giai đoạn khác nhau của nguyên mẫu.

Các nhà thiết kế giỏi nhất thế giới luôn tuân thủ theo chu trình khép kín là thiết kế > kiểm thử người dùng > thiết kế. Nếu bạn không kiểm thử với người sử dụng thực, bạn sẽ không biết thiết kế có sai sót gì.

Kiểm thử sớm và kiểm thử thường xuyên sẽ cho bạn sự tự tin để xây dựng một sản phẩm thực sự hữu ích và khả dụng. Hãy từ bỏ thiết kế sơ khai nếu chúng không hiệu quả, đừng ngần ngại thiết kế lại. Liên hồi, liên hồi và liên hồi.

9. Khảo sát vô ích: Thật dễ khi hỏi người dùng với những câu hỏi “Bạn thích gì?”, “Điểm tốt và xấu của sản phẩm này là gì?”, hoặc “tôi có thể cải thiện sản phẩm bằng cách nào?”

Tất cả các câu hỏi trên sẽ cung cấp cho bạn ý kiến ​​của người sử dụng – rất cảm tính, không hề tốt đối với một sản phẩm mới. Vì vậy, hỏi ý kiến khách hàng là điều bạn KHÔNG BAO GIỜ phải làm!

Nếu khảo sát là những ý kiến ​​cảm tính, hãy ném kết quả đó vào thùng rác, đó là vị trí của chúng! Thứ bạn cần là tìm hiểu hành vi người dùng.

“Thật sự rất khó để thiết kế sản phẩm bởi các nhóm tập trung. Hầu hết người ta không biết mình muốn gì cho đến khi bạn cho họ thấy sản phẩm.” – Steve Jobs

10. Làm thế nào để kiểm thử với người dùng: Để hiểu hành vi người dùng, nó khá là đơn giản. Thực hiện theo 7 bước đơn giản này, và bạn sẽ hiểu rõ hành vi của người sử dụng trong bất cứ thời điểm nào:

1. Tạo một danh sách từ 3-5 nhiệm vụ quan trọng mà người dùng sẽ làm thường xuyên khi sử dụng sản phẩm của bạn. Các nhiệm vụ đó đại loại như tạo một hóa đơn, gửi lại hóa đơn, kiểm tra xem một hóa đơn đã được thanh toán chưa, và gửi lời nhắc nhở khi chậm thanh toán.

2. Mời người dùng thực tới văn phòng của bạn, mỗi lần một người, và làm cho họ thật thoải mái.

3. Cho người dùng thấy màn hình đầu tiên và yêu cầu họ hoàn thành nhiệm vụ 1. Khuyến khích họ luôn nói với bạn những gì họ đang làm.

4. Chờ đợi và quan sát kỹ người dùng làm việc, không trả lời câu hỏi liên quan đến cách sử dụng của sản phẩm. Sau khi hoàn thành, có thể thành công hoặc gặp khó khăn, hãy đưa cho người dùng nhiệm vụ 2.

5. Sau mỗi nhiệm vụ, đặt câu hỏi về lý do tại sao người dùng thực hiện theo cách đó, không hỏi về lí do thích hay không thích.

6. Cuối cùng, tặng một món quà nhỏ cho người sử dụng, có thể là một tách cà phê và một ít bánh quy.

7. Đừng lo lắng về việc phân tích, tâm trí của bạn được kết nối với một số ý tưởng để giải quyết vấn đề!

Bây giờ bạn đã thuộc nhóm người hiểu được mặt tốt của kiểm thử tính khả dụng (UT), hứa với tôi là bạn sẽ làm điều này thường xuyên với sản phẩm của bạn.

Bạn có thể sử dụng WebEx cho người dùng từ xa. Và bạn không cần đến nguyên mẫu thật, bạn có thể sử dụng nguyên mẫu trên giấy dễ dàng chỉ cần tiếp tục đẩy màn hình tiếp theo trên màn hình hiện tại.

11. Phân tích kết hợp với kiểm thử tính khả dụng: Phân tích là một cách tuyệt vời để biết người dùng đến từ đâu, những gì người dùng đã làm, và nơi mà người dùng rời đi. Phân tích là một điểm khởi đầu để xác định khả năng sử dụng.

Tuy nhiên, phân tích sẽ không cần thiết khi bạn muốn hiểu lý do cho hành vi của người sử dụng: tại sao người dùng đến, tại sao người dùng làm những việc họ đang làm, và tại sao người dùng lại không làm việc gì đó. Kiểm thử tính khả dụng là một công cụ tốt để hiểu được lý do của hành vi người dùng, bây giờ bạn đã trở nên chuyên nghiệp!

12. Tôi phụ thuộc vào phản hồi người dùng: Người dùng gọi điện thoại hoặc gửi email khi họ gặp vấn đề không thể giải quyết thấu đáo. Hầu hết người dùng không bận tâm đến việc gửi phản hồi, họ chỉ từ bỏ sản phẩm của bạn. Bạn sẽ không bao giờ có thể tìm thấy hiệu quả sử dụng lớn hoặc giải pháp thay thế nhiệm vụ với phản hồi người dùng.

Kiểm thử tính khả dụng giúp bạn gần gũi hơn với người sử dụng và hiểu các vấn đề thực tế rất sớm. Bạn sẽ giải quyết được một lượng lớn các vấn đề trước khi phát hành sản phẩm, giúp bạn tránh được rất nhiều vấn đề đau đầu sau này.

13. Phác hoạ cấu trúc khung sườn (Wireframes) bằng Keynote hoặc Powerpoint: Tôi đã thực hiện nguyên mẫu trên giấy và tôi đã thử nghiệm chúng – người dùng yêu thích sản phẩm của tôi, bây giờ liệu tôi có thể sử dụng các công cụ tạo mẫu UX?

Bạn có thể sử dụng, đây là thời điểm để sử dụng tất cả các công cụ tạo mẫu tốt nhất. Vấn đề quan trọng trong giai đoạn này là thông tin phản hồi từ các bên liên quan – khách hàng, người sử dụng, chuyên gia… Vì vậy, chọn một công cụ sẽ giúp thu thập phản hồi rất tốt.

Các công cụ cung cấp cho bạn giá trị tối đa trong giai đoạn này là Keynote (trên Mac) hoặc PowerPoint. Bạn có thể chi tiết hoá thiết kế của bạn rất tốt bằng cả hai công cụ. Điểm tốt nhất là bạn có thể gửi đến nhiều người cùng lúc để xem xét một cách dễ dàng, và bất cứ ai trong nhóm của bạn cũng có thể cùng xem xét.

14. 5 câu hỏi giao diện người dùng cần hỏi: Tuân thủ các nguyên tắc thiết kế và luôn theo sát thiết kế trực quan tốt nhất.

Đừng quên hỏi 5 câu hỏi sau đây trong mỗi màn hình tương tác với người dùng để có được một sản phẩm thực sự hữu dụng:

1. Người dùng đang cần thông tin gì để hoàn thành nhiệm vụ/ nhiệm vụ phụ / lĩnh vực này?

2. Cần làm gì để có thể cung cấp các thông tin còn thiếu?

3. Các bước tiếp theo khả dĩ nhất mà người dùng sẽ thực hiện là gì?

4. Chúng ta có thể giúp đỡ / hướng dẫn người dùng thực hiện bước dự tính tiếp theo bằng cách nào?

5. Người dùng đang ở đâu và sẽ được gì sau khi hoàn thành nhiệm vụ này?

Dịch từ: UX 101 for startups

We are very excited about an upcoming event with the topic “Productive development environment with teracy-dev” presented by Hoat Le, Co-founder, and CEO of Teracy. The event will be held on Thursday, February 23 at 6:30 PM – 9:30 PM at Toong Hoang Dao Thuy (25T2 Hoang Dao Thuy, Ha Noi). This is the first event in the series of OpenTour’s activities.

OpenTour is started from the idea of ​​collaboration, and help each other of three open source communities in Vietnam, including OpenCPS, Vietnam OpenStack, and Docker Hanoi. OpenTour is a series of activities and events aiming at building Vietnamese FOSS ecosystem, building a network of FOSS experts to promote the use, application and development of FOSS in Vietnam, especially for ​​ICT enterprises and training institutions, on the base of absorbing ideas and activity patterns of the FOSS community in the world, and through shared activities and promoting.

Agenda:

• Introduce about OpenTour

• teracy-dev: the only truly universal productive development platform with Docker on macOS, Linux, and Windows for developers.

  • Introduce about teracy-dev

  • The existing problems that many developers are struggling:

    • The problems when there was no Docker yet

    • The problems when there was no teracy-dev yet

    • The approaches and solutions for these problems with teracy-dev

    • The 4-year story of teracy-dev

    • The Docker workflow with teracy-dev

  • teracy-dev demo with the real projects

  • Questions and Answers

Join us! To have more details and register to join the event, please see the details at https://www.facebook.com/events/979555312146106/. It’s our honor to have your presence at this event. See you there!

v0.5.0-b1

This is the beta 1 release of v0.5.0, what does it mean? By following the semantic versioning guide, it means:

features completed, only minor bugs are expected. Avoid refactoring here, just fix bugs

This v0.5.0-b1 release is tested with all our projects and our clients’ projects, so we can guarantee that the release has a very high quality and stability that you can use it for everyday projects.

We’re still lacking lots of documentation guides for users to explore and leverage all the supported features more easily.

Changes

This major release includes lots of features and improvements:

• high performance on Windows, especially file syncing
• Docker workflow out of the box, can use any versions of docker, docker-compose
• support all type of provisioners configurations
• use public_network by default
• config override the object within array
• Vagrantfile-ext support
• use rsync as the default sync mechanism (with the support from vagrant-gatling-rsync and vagrant-rsync-back plugins)
• reverse proxy support with /etc/hosts update for auto domain management
• auto vagrant plugins installation support

There are more that you should explore yourselves when using teracy-dev for a while.

What’s next?

We’re working hard to add more documentations and guides. We’ll fix bugs if any.

After v0.5.0 final is release, we’ll take on the next major release v0.6.0 that follow our teracy-dev’s vision:

teracy-dev is the best universal development tool for everyone.

We’ll take all the feedback from v0.5.0 usage to continue making teracy-dev better and greater.

Don’t hesitate to use teracy-dev v0.5.0-b1 for your everyday projects from today by getting started with http://dev.teracy.org/docs/getting_started.html

If you have any feedbacks or problems, you’re welcome to create issues for the project at https://github.com/teracyhq/dev/issues

Enjoy and happy hacking!

01. Tính hữu dụng là nhiệm vụ

Nếu sản phẩm của bạn không hữu dụng, nếu con người không tìm được cách sử dụng sản phẩm đó, như vậy thiết kế của sản phẩm đã thất bại. Sản phẩm của bạn phải giúp con người tạo ra những điều có giá trị trong cuộc sống của họ. Giá trị này thông qua việc sử dụng có thể trở nên thiết thực (Đồng hồ Timex của tôi có thể báo thời gian), có thể là giá trị xã hội (Đồng hồ Rolex của tôi gây ấn tượng với bạn bè tôi), hoặc giá trị về cảm xúc (đồng hồ của tôi là món quà từ vợ/chồng của tôi). Vòng đời sử dụng của sản phẩm bao gồm khả năng biết về tính hữu dụng của sản phẩm, một trải nghiệm tốt khi lần đầu tiên sử dụng sản phẩm, khả năng sử dụng sản phẩm và thành công theo thời gian.

02. Trải nghiệm chính là sản phẩm

Khi bạn có sản phẩm thì sẽ có trải nghiệm của người sử dụng sản phẩm đó. Thật dễ dàng để thấy được sự khác biệt từ xa, nhưng đối với người sử dụng sản phẩm của bạn, các sản phẩm luôn giống nhau. Mọi tương tác đều là vấn đề và trở thành môt phần trải nghiệm sản phẩm. iPod nguyên bản chính là một ví dụ kinh điển: trải nghiệm của iPod bao gồm mọi thứ từ việc cầm iPod lên và cảm nhận trọng lượng của thiết bị cho đến việc tìm kiếm nhạc với nút điều khiển hình tròn, đến việc đồng bộ với máy tính của bạn và việc mua nhạc từ cửa hàng iTunes. Tất cả những tương tác này cùng nhau tạo nên toàn bộ trải nghiệm sản phẩm và cuối cùng đó là những gì mà khách hàng đã mua.

03. Giải quyết các vấn đề còn tồn tại

Khi chúng ta nỗ lực tạo ra những sản phẩm thay đổi thế giới, chúng ta thường tạo ra một vài thứ mà trên thế giới chưa bao giờ nhìn thấy. Nhưng việc đổi mới sản phẩm không phải là về sản phẩm mới sẽ giải quyết vấn đề mới. Đổi mới sản phẩm là sản phẩm mới sẽ giải quyết các vấn đề đang tồn tại tốt hơn các sản phẩm hiện nay đang làm. Lấy Google Search, Netflix và Facebook làm ví dụ. Những dịch vụ phổ biến này đơn giản là giải quyết các vấn đề đang tồn tại tốt hơn so với chúng trước đây.

04. Tìm kiếm sự đầu tư

Các tính năng của sản phẩm tốt nhất là các tính năng sẽ được sử dụng. Cách thức tốt nhất để dự đoán liệu một tính năng sẽ được sử dụng đó là đã có người đầu tư vào lĩnh vực đó. Đã có ai đầu tư tiền bạc, thời gian, hay công sức để giải quyết vấn đề này chưa? Đây là các chỉ số cho thấy vấn đề đáng được giải quyết. Nếu mọi người nói họ có một vấn đề nhưng lại không đầu tư để giải quyết vấn đề đó. Như vậy, vấn đề đó không thực sự nằm trong top danh sách ưu tiên của họ. Vì vậy hãy tìm kiếm đầu tư hiện tại trước khi bổ sung một sản phẩm hoặc tính năng mới.

05. Các tính năng mẫu của công cụ thực

Một cách để bạn có thể chắc chắn có người đang đầu tư vào vấn đề đó là tìm kiếm công cụ để sử dụng. Các công cụ là đối tượng của thế giới thực mà con người sử dụng để hoàn thành một công việc. Hãy suy nghĩ đến những ghi chú được dính xung quanh màn hình máy tính. Các công cụ thường xuyên bị va đập, giống như việc đặt băng dính trong lên Iphone để bảo vệ màn hình hoặc một bảng tính Excel giúp tổ chức thông tin. Khi bạn trải qua một công cụ và coi công cụ đó như vàng và đề nghị chủ sở hữu công cụ đó nói cho bạn biết tất cả thông tin về công cụ đó, công cụ đó trực tiếp chuyển thành các tính năng hữu ích.

06. Làm cho phù hợp và hoàn thành vấn đề

Chúng ta xây dựng được niềm tin với người dùng khi một vấn đề nào đó có vẻ đúng, khi các giao diện đã được đánh bóng tới độ chính xác từng pixel, khi việc viết quảng cáo là hoàn toàn rõ ràng, khi các thương hiệu trở nên chuyên nghiệp. Thông điệp ngầm là “những người dùng này thực sự quan tâm đến việc họ sẽ làm gì…chỉ cần chú ý chi tiết thôi”. Khi đó họ sẽ mang thêm cơ hội thành công cho sản phẩm của chúng ta.

07. Chất lượng của phát hành tạo lên kỳ vọng

Việc phát hành thiết lập nên kỳ vọng. Điều này trở thành phổ biến để phát hành sản phẩm một cách nhanh nhất có thể và sau đó lặp lại dựa trên những phản hồi từ người dùng. Điều này rất đáng khen ngợi; Không có sự thay thế cho việc sử dụng thực tế. Nhưng dù bạn phát hành cái gì đi nữa, cũng cần đảm bảo rằng đó là sự nỗ lực hết mình của bạn. Nếu tất cả những phát hành của bạn mới hoàn thành được 80% dù đó là cái mà mọi người mong đợi. Mỗi lần như vậy, kỳ vọng của họ cũng sẽ giảm dần mỗi lần phát hành vì niềm tin của họ suy yếu dần. Tuy nhiên nếu mỗi sản phẩm trong số các sản phẩm phát hành của bạn, bất kể là sản phẩm đó nhỏ như thế nào nhưng có chất lượng cao nhất, nhưng những người sử dụng sản phẩm của bạn sẽ biết rằng sản phẩm đó rất đáng để họ bỏ thời gian để chú ý. Thậm chí, họ còn rất háo hức mong chờ sản phẩm đó.

08. Phát hành sản phẩm càng nhỏ thì sản phẩm càng tốt

Hiện tại, thật dễ dàng để xây dựng các tính năng. Công cụ phát triển đã bổ sung thêm các tính năng nhanh hơn so với trước đây. Tuy nhiên, phạm vi tính năng luôn luôn là vấn đề cũ. Mọi tính năng mà bạn bổ sung là bất đồng trong giao diện và là một gánh nặng bổ sung. Tuy nhiên, nếu sản phẩm của bạn thực sự được tập trung và không cố gắng thực hiện nhiều hơn và bạn sẽ nói không đối với nhiều tính năng hơn là bạn nói có.

09. 10% cuối cùng của sản phẩm là khó làm nhất

Sự khác nhau giữa một sản phẩm tốt và lý tưởng là ở 10% cuối cùng. Mọi người đều có 90% giống nhau… các tính năng cốt lõi giống nhau, giá và cốt truyện tương tự nhau. Nhưng 10% cuối cùng là sự khác biệt thực sự. Đây là phần để phân biệt bạn với những đối thủ cạnh tranh của bạn. Đó là máu, mồ hôi và nước mắt để làm chi tiết sản phẩm. Và điều này có thể lấy đi 50% thời gian của bạn. Tuy nhiên, thời gian không phải là cái mà bạn sẽ đo đếm. Bạn sẽ đo đếm sự khác biệt giữa tốt và lý tưởng.

10. Biết rõ đối thủ cạnh tranh của bạn là ai

Email và Excel là 2 đối thủ phần mềm lớn nhất của nhau từ trước đến giờ: mọi người sử dụng hai phần mềm này để làm mọi thứ. Chúng tôi chưa nghĩ về việc coi hai phần mềm này là đối thủ cạnh tranh vì chúng không cạnh tranh trực tiếp để thay thế. Thật dễ dàng để làm theo các phân tích đặc điểm của sản phẩm tạo ra trong mỗi ngành công nghiệp. Nhưng các đặc điểm này hiếm khi bao quát đầy đủ lĩnh vực cạnh tranh. Do đó tìm kiếm các đối thủ cạnh tranh gián tiếp thường nguy hiểm như việc tìm các đối thủ cạnh tranh trực tiếp. Ví dụ, điện thoại có máy ảnh là một đối thủ cạnh tranh gián tiếp nhưng là đối thủ “chết người” với máy ảnh kỹ thuật số và máy quay video cầm tay. Bạn cần phải biết ai là đối thủ cạnh tranh trực tiếp và gián tiếp của bạn để tạo ra sự đổi mới thực sự của sản phẩm.

11. Sử dụng thực tế và mong muốn

Thường xuyên có sự khác nhau giữa việc bạn muốn mọi người sử dụng sản phẩm của bạn để làm gì và thực tế nó được sử dụng để làm gì. Đừng lầm lẫn giữa hai việc này. Hãy trung thực về cách mọi người sử dụng sản phẩm của bạn. Trong một vài trường hợp, sản phẩm sẽ không phải là cái bạn dự định làm. Đây là điều đáng lưu ý. Mặt khác, người sử dụng sản phẩm không đúng cách vì họ không học sử dụng đúng cách và cần đến sự trợ giúp. Kịch bản tệ nhất là khi mọi người đang sử dụng một sản phẩm không đúng cách mà lại không có sự trợ giúp của bạn – một nhà thiết kế hiểu biết.

12. Giá trị cá nhân đi trước giá trị xã hội

Thật dễ dàng để mong chờ giá trị xã hội của phần mềm. Ooh, nếu chúng ta xây dựng đúng giá trị thì khi đó mọi người sẽ chia sẻ với bạn bè của họ! Tuy nhiên mọi người hiếm khi sử dụng phần mềm chỉ đơn thuần vì nó mang tính xã hội. Họ sử dụng phần mềm vì phần mềm đó trước hết cung cấp một vài giá trị cá nhân mà họ có thể sử dụng chúng mà không cần sự tham gia của người khác. (Điều này có thể bao gồm những giá trị khác nhưng hành động chia sẻ thường chỉ đứng ở vị trí thứ hai).

13. Người sử dụng không phải là nhà thiết kế sản phẩm

Người sử dụng luôn có những ý kiến bất tận về sản phẩm của bạn, nhưng họ không phải là nhà thiết kế. Bạn mới là người thiết kế. “Khi mọi người nói với bạn cái gì sai hoặc không hoạt động với họ, hầu như họ luôn luôn đúng. Khi họ nói với bạn một cách chính xác những gì họ nghĩ là sai và làm thế nào để giải quyết chúng, họ hầu như luôn luôn sai.” Câu trích dẫn này của Neil Gaiman là đúng về những người rất có ý thức nhận biết một vấn đề tồn tại nhưng không biết cách giải quyết vấn đề đó (nếu họ biết cách giải quyết vấn đề, họ đã không có vấn đề gì!) Vì vậy, đừng vội bỏ qua vấn đề một cách nhanh chóng, hãy chắc chắn rằng bạn đã đào sâu hơn để hiểu vấn đề một cách cơ bản, điều này có vẻ như không liên quan. Một nhà thiết kế mù quáng đi theo ý tưởng của những người sử dụng sẽ nhanh chóng mất đi khả năng tự báo cáo một cách chính xác. Đừng khó chịu với người dùng về vấn đề này. Đây là bản chất của người sử dụng.

14. Hành vi mà bạn đã nhìn thấy là hành vi để bạn thiết kế

Bất kể bạn lên kế hoạch như thế nào, mọi người thường cư xử theo các cách thức không thể dự kiến trước. Đừng bỏ qua hành vi, chấp nhận hành vi mà bạn nhìn thấy là hành vi để bạn thiết kế dù điều đó là cố ý hay không. Nếu có một vài thứ mà bạn không thể lên kế hoạch, việc đương nhiên mà bạn cần làm là tập trung hơn vào những tương tác cốt lõi, làm cho các tương tác càng chặt chẽ càng tốt để tập trung vào các nỗ lực của người sử dụng.

15. Sản phẩm lý tưởng được tập trung vào một vấn đề duy nhất

Thông thường mọi người thường sáng tạo sản phẩm với hy vọng hấp dẫn tất cả mọi người. Nhưng sản phẩm tốt nhất là sản phẩm hấp dẫn theo cách đặc biệt cho những người đang cố gắng làm một điều gì đó đặc biệt… họ là chuyên gia trong một vấn đề cụ thể. Đó là trực giác ngược lại để tập trung vào thị trường nhỏ nhưng hành trình đến thị trường lớn sẽ bắt đầu từ đây.

16. Sản phẩm đột phá giống như đồ chơi

Các sản phẩm đột phá thường bắt đầu trông giống như một món đồ chơi. Các sản phẩm không có vẻ nhiều, nhưng cái mà các sản phẩm có là một ngưỡng nhiều hữu dụng hơn theo cách nào đó so với những sản phẩm hiện tại. Có thể các sản phẩm rẻ hơn, dễ sử dụng hơn hoặc có tính chất cộng tác hơn. Điều này có vẻ không có sự đánh bóng hay sự trưởng thành hoặc cơ sở khách hàng lớn hơn và vì vậy sản phẩm xuất hiện giống một món đồ chơi. Và khía cạnh khiêm tốn này chính xác là lý do tại sao thường quá muộn khi người thiết kế nhận ra rằng sản phẩm này được mọi người quan tâm.

17. Việc định vị sản phẩm là rất quan trọng

Cách mọi người nghĩ về sản phẩm của bạn là vô cùng quan trọng để họ chấp nhận và sử dụng sản phẩm. Cách mà bạn định vị sản phẩm của mình, cách mà bạn nói về sản phẩm, mô tả sản phẩm, so sánh sản phẩm đó với các sản phẩm khác, cho mọi người một khuôn khổ để hiểu về sản phẩm và làm thế nào có thể sử dụng chúng. Bạn có thể định vị sản phẩm như là một mục sản phẩm mới hoặc như một sự cải tiến trong các hạng mục hiện có. Điều này thường tạo cảm giác định vị sản phẩm dựa trên hạng mục hiện có… mọi người thường tìm hiểu bằng cách so sánh với các sản phẩm khác mà họ đã biết.

18. Sản phẩm phù hợp với thị trường là khi mọi người bán hàng hộ bạn

Sản phẩm phù hợp với thị trường (Product market fit) là một thuật ngữ vui, nhưng ở đây chính là cách thức cụ thể để nghĩ về sản phẩm. Khi mọi người hiểu và sử dụng sản phẩm của bạn đủ để họ công nhận giá trị của nó đã là một thắng lợi lớn. Nhưng khi họ bắt đầu chia sẻ các trải nghiệm tích cực của họ với những người khác, khi bạn có thể tái tạo trải nghiệm đó với người sử dụng mới đã được nghe những trải nghiệm từ những người dùng hiện tại, như vậy bạn đã có được sản phẩm phù hợp với thị trường. Và khi điều này xảy ra thì một số điều kì diệu cũng xảy ra. Điều bất ngờ đó là khách hàng của bạn sẽ trở thành người bán hàng cho bạn.

Dịch từ: Principles of Product Design