Bài viết được sự cho phép của tác giả Trần Duy Thanh
Với sự thay đổi như vũ bão của công cụ lập trình Android Studio, năm 2020 Tui tranh thủ viết bổ sung thêm một số tính năng hữu ích trong phiên bản mới này.
Bài đầu tiên trong chuỗi các hướng dẫn là Cách cài đặt và sử dụng Android Studio phiên bản năm 2020
Nói chung 1 đứa con nhà nghèo và 1 đứa con nhà giàu, 2 đứa này tính cánh và năng lực giống nhau thì đứa con nhà giàu sẽ học tốt hơn vì nó có điều kiện hơn.
Học là sự đầu tư có lãi trong tương lai, ráng đầu tư để có công cụ hỗ trợ chúng ta lập trình tốt hơn.
Bước trước tiên, ta cần tải Android Studio phiên bản mới nhất tại đây:
Nhấn vào “DOWNLOAD ANDROID STUDIO”, ở trên thấy là 3.6.2 (và không quan trọng, bao nhiêu kệ nó):
Màn hình trên hiện ra, check vào “I have read and agree with the above terms and conditions”
Sau đó bấm “DOWNLOAD ANDROID STUDIO FOR WINDOWS”. Máy bạn là MAC , LINUX thì cũng tương tự.
Bấm save để tải về, tùy tốc độ mà lâu hay mau, đợi chỗ này nó tải cho xong.
Sau khi tải xong thì bắt đầu cài đặt.
Trước khi cài đặt thì nên tạo 1 thư mục Android trong ổ C, ví dụ:
Khi cài đặt sẽ có 2 thành phần mà ta nên cài vào bên trong thư mục Android, đó là:
android-studio->công cụ lập trình
sdk->các thư viện để hỗ trợ lập trình
Bây giờ double click vào file cài mới tải ở trên về để cài đặt:
Nhấn Next để tiếp tục:
Để mặc định như trên rồi tiếp tục nhấn Next:
Ở màn hình trên lưu ý cài vào thư mục C:\Android\android-studio
Sau đó nhấn Next để tiếp tục:
Sau đó nhấn “Install” để bắt đầu cài đặt
Ngồi chờ xíu cho nó cài đặt, khi cài đặt xong sẽ có thông báo như dưới đây:
Nếu như trước đó đã làm làm Android thì dĩ nhiên có SDK sẵn và phần mềm không yêu cầu gì thêm cả, nếu chưa bao giờ cài thì sẽ tiếp tục được yêu cầu cài SDK:
Chương trình sẽ báo Missing SDK, ta tiếp tục nhấn Next
Lưu ý Android SDK Location ta chọn đúng nơi mà ta đã tạo thư mục trước đó: C:\Android\sdk
Sau đó nhấn Next để tiếp tục. Màn hình Verify Settings sẽ xuất hiện như dưới đây:
Nhấn FINISH để cài, màn hình Downloading Components sẽ hiển thị như dưới đây, chờ:
Bài viết được sự cho phép của tác giả Trần Anh Tuấn
Gần đây mình thấy có một bạn hỏi về việc làm sao để hiển thị được ngôn ngữ như tiếng Nhật, Hàn từ trên xuống dưới chứ không phải mặc định là theo tiếng latin như tiếng Anh chạy từ trái sang phải như chúng ta hay làm. Thì mình tìm thấy một thuộc tính là writing-mode để làm việc đó. Và điều thú vị là nó không chỉ áp dụng cho những ngôn ngữ như tiếng Nhật mà khi làm với ngôn ngữ khác như tiếng Anh thì chúng ta có thể tạo đoạn chữ đứng thẳng một cách dễ dàng hoặc làm được nhiều thứ hay ho khác. Cùng tìm hiểu thêm dưới đây nhé.
Giá trị mặc định của thuộc tính này là horizontal-tb, tức là nó sẽ hoạt động với những ngôn ngữ như tiếng Anh, tiếng Pháp…. như bình thường chúng ta hay thấy trên trang web. Và writing-mode có một giá trị khác rất là thú vị mà chúng ta sẽ cùng nhau khám phá tiếp theo đây đó chính là vertical-lr (trong đó lr nghĩa là Left to right) với các ví dụ sau.
Ví dụ số 1
Với giao diện như trên thì chúng ta có một section-title nằm xoay 90 độ và nằm phía trên bên trái. Nếu các bạn muốn làm ra như vậy thì các bạn cần phải làm từng bước phân tích như sau:
Đầu tiên là các bạn cần CSS cho lớp bao ngoài ví dụ ở đây là wrapper với thuộc tính position: relative.
Sau đó các bạn sẽ dùng position: absolute cho section-title.
Sau đó các bạn đổi trục xoay của nó bằng việc dùng thuộc tính transform-origin: left top vì nó nằm ở trên cùng bên trái.
Tiếp đến để nó xoay 90 độ thì các bạn dùng transform: rotate(90deg).
Cuối cùng các bạn cần thêm padding-left cho wrapper để nội dung của cái grid bên phải không tràn qua chỗ section-title.
Chúng ta có HTML và CSS cho giao diện ở trên như sau:
<section class=“wrapper”>
<h2 class=“section-title”>Our Works</h2>
<div class=“grid”>
<div class=“grid__item”></div>
<div class=“grid__item”></div>
<div class=“grid__item”></div>
<div class=“grid__item”></div>
</div>
</section>
.wrapper {
position:relative;
padding-left:70px;
padding-top:30px;
margin:0auto;
max-width:500px;
}
.section-title {
// 4 dòng đầu
position:absolute;
left:0;
transform-origin:lefttop;
transform:rotate(90deg);
//
font-size:20px;
font-weight:bold;
font-family:“Arial”;
}
.grid__item {
-webkit-box-flex:0;
flex:0048%;
height:150px;
background:#e1e1e1;
padding:1.35em;
box-sizing:border-box;
margin-bottom:1em;
}
Các bạn thấy đó việc để làm cái section-title nằm dọc thôi mà phải CSS tận 4 dòng. Tiếp theo đây thì chúng ta sẽ khám phá xem là writing-mode sẽ làm nó như thế nào đây.
.wrapper {
display:flex;
}
.section-title {
writing-mode:vertical-lr;// thay bằng dòng này
}
.grid{
display:flex;
flex:1;
flex-wrap:wrap;
-webkit-box-pack:justify;
justify-content:space-between;
}
Chỗ section-title thay vì dùng 4 dòng CSS thì giờ đấy với tinh chỉnh CSS một chút kết hợp với writing-mode thì chỉ còn một dòng mà thôi. Quá tuyệt phải không nào. Các bạn có thể lấy code để chạy thử nhé.
Ví dụ số 2
Với thiết kế này, thì các bạn cũng dễ dàng thấy là các social widget được sắp xếp nằm hàng dọc phía bên trái của nội dung. Nhìn vào thì chắc là nhiều bạn cũng code ra được mà không nhất thiết phải dùng tới writing-mode, nhưng điều thú vị ở đây là khi các bạn sử dụng social widget, các bạn đôi khi sẽ muốn nó hiển thị chiều dọc ở phía trên, ở giữa hay thậm chí là ở dưới hoặc ở giữa.
Thì như trên hình các bạn thấy rằng cái social widget này nó nằm chiều dọc được canh trên top của thằng cha chứa nó với giá trị text-align: left thì để thay đổi vị trí của nó chúng ta sẽ đổi giá trị của text-align. Ví dụ:
.social-widget {
writing-mode:vertical-lr;
text-align:right;
}
Hoặc là canh giữa với đoạn code này. Các bạn có thể nhấn vào đây để xem demo online nhé, và đừng quên F12 để check code và sửa lại text-align cho social-widget thay đổi vị trí đúng không nhé.
.social-widget {
writing-mode:vertical-lr;
text-align:center;
}
Trình duyệt hỗ trợ
Thật sự là may mắn vì thuộc tính này đa số các trình duyệt đều hỗ trợ, với global là 96.08% tại caniuse. Vì thế các bạn có thể sử dụng nó trong các trình duyệt hiện đại rồi, nhưng hãy cẩn thận khi làm việc với những trình duyệt như IE từ 6-11 nhé.
Bài viết được sự cho phép của BBT Tạp chí Lập trình
Trong những ngày đầu của web động, việc viết một ứng dụng web khác rất nhiều so với ngày nay. Các nhà phát triển sau đó chịu trách nhiệm viết mã cho không chỉ logic duy nhất của các ứng dụng đó, mà còn viết lại từng thành phần rất phổ biến trên các trang web khác – xác thực người dùng, xác thực đầu vào, truy cập cơ sở dữ liệu, tạo khuôn mẫu,…
Ngày nay, các lập trình viên có rất nhiều framework và hàng ngàn thành phần và thư viện có thể truy cập dễ dàng. Nhưng khi bạn học một framework mới, thì 3 framework mới hơn (và có ý nghĩa tốt hơn) đã xuất hiện với ý định thay thế nó.
Có nhiều lý do để chọn sử dụng một framework nào đó. Vậy tại sao phải sử dụng framework? Cụ thể hơn, tại sao nên sử dụng Laravel?
Thật dễ hiểu vì sao lại có lợi khi sử dụng các thành phần hoặc packages riêng lẻ có sẵn cho các nhà phát triển PHP.
Với các packages, người khác chịu trách nhiệm phát triển và duy trì một đoạn mã bị cô lập, có công việc được xác định rõ và theo lý thuyết thì người đó hiểu sâu hơn về thành phần này hơn bạn.
Các framework như Laravel – và Symfony, Silex, Lumen và Slim – đóng gói một bộ sưu tập các packages của bên thứ ba cùng với framework “tùy chỉnh” như các tệp cấu hình, service providers, cấu trúc thư mục được quy định… Vì vậy, lợi ích của việc sử dụng một framework nói chung là “ai đó” đã đưa ra quyết định không chỉ về các packages riêng lẻ cho bạn, mà còn về cách các packages đó phù hợp với nhau.
“Tôi có thể xây dựng nó”
Hãy nói rằng bạn bắt đầu một ứng dụng web mới mà không dùng framework. Bạn bắt đầu từ đâu? Chà, có lẽ nên định tuyến các yêu cầu HTTP, vì vậy bây giờ bạn cần đánh giá tất cả các thư viện phản hồi yêu cầu HTTP có sẵn và chọn một. Ồ, và bạn có thể cần phải thiết lập một số dạng tệp cấu hình v.v.. Nó nên sử dụng cú pháp nào? Nó nên đi đâu? Còn bộ điều khiển thì sao? Nó nằm ở đâu, và nó được tải lên như thế nào? Và rất nhiều thiết lập khác.
Hơn nữa, điều gì sẽ xảy ra nếu bạn dành thời gian để trả lời tất cả những câu hỏi đó và tạo thành công ứng dụng của bạn – điều gì tác động đến nhà phát triển tiếp theo? Thế còn khi bạn có 4 ứng dụng tùy chỉnh như vậy, hoặc nhiều hơn, và bạn phải nhớ nơi các bộ điều khiển nằm trong đó, hoặc cú pháp định tuyến là gì?
Như vậy việc tự xây dựng từ đầu vô cùng khó khăn và phức tạp, giải quyết quá nhiều vấn đề liên quan.
Tính nhất quán và linh hoạt
Các framework giải quyết vấn đề này bằng cách cung cấp một câu trả lời được xem xét cẩn thận cho từng câu hỏi. Chúng ta nên sử dụng thành phần nào ở đây? và đảm bảo rằng các thành phần cụ thể được chọn làm việc tốt với nhau. Ngoài ra, các framework cung cấp các quy ước làm giảm số lượng mã nguồn mà nhà phát triển mới cho dự án phải hiểu – ví dụ, nếu bạn hiểu cách định tuyến hoạt động trong một dự án Laravel, bạn hiểu cách nó hoạt động trong tất cả các dự án khác được xây dựng trên Laravel.
Các framework không chỉ cung cấp cho bạn một nền tảng vững chắc mà còn cho bạn tự do tùy chỉnh nội dung. Và điều này, Laravel làm rất tốt, đó là một trong các lý do làm cho Laravel trở nên đặc biệt.
Một phần quan trọng để có thể trả lời câu hỏi “Tại sao lại sử dụng Laravel?” là hiểu về lịch sử của Laravel – và hiểu những gì xảy ra trước nó. Trước khi Laravel trở nên nổi tiếng, đã có một loạt các PHP framework khác và những sự thay đổi trong PHP và các công cụ phát triển web khác.
Ruby on Rails
David Heinemeier Hansson đã phát hành phiên bản đầu tiên của Ruby on Rails vào năm 2004, và thật khó để tìm thấy một framework để phát triển ứng dụng web kể từ đó, điều đó đã bị ảnh hưởng bởi Rails theo một cách nào đó.
Rails phổ biến MVC, API API RESTful, quy ước về cấu hình, ActiveRecord và nhiều công cụ và quy ước khác có ảnh hưởng sâu sắc đến cách các nhà phát triển web tiếp cận ứng dụng của họ – đặc biệt là liên quan đến phát triển ứng dụng nhanh chóng.
Dòng chảy của các PHP Framework
Rõ ràng với hầu hết các nhà phát triển rằng Rails và các framework web tương tự, là làn sóng của tương lai và các framework PHP, bao gồm cả các framework được thừa nhận, các framework bắt đầu phát triển cũng như các framework đang bật lên nhanh chóng.
CakePHP là sản phẩm đầu tiên vào năm 2005 và ngay sau đó là Symfony, CodeIgniter, Zend Framework và Kohana (một ngã ba CodeIgniter). Yii đến vào năm 2008, và Aura và Slim vào năm 2010. 2011 đã mang ra FuelPHP và Laravel, cả hai đều không phải là nhánh của CodeIgniter, mà thay vào đó được đề xuất như là lựa chọn thay thế.
Một số framework có nhiều Rails-y hơn, tập trung vào các trình ánh xạ quan hệ đối tượng cơ sở dữ liệu (ORM), cấu trúc MVC và các công cụ khác nhắm đến mục tiêu phát triển nhanh. Những framework khác, như Symfony và Zend, tập trung nhiều hơn vào các mẫu thiết kế doanh nghiệp và thương mại điện tử
Cái tốt và cái chưa tốt của CodeIgniter
CakePHP và CodeIgniter là hai framework PHP ban đầu cởi mở nhất về mức độ cảm hứng của họ được rút ra từ Rails. CodeIgniter nhanh chóng nổi tiếng và đến năm 2010 được cho là phổ biến nhất trong các framework PHP.
CodeIgniter đơn giản, dễ sử dụng và tự hào về tài liệu tuyệt vời và một cộng đồng mạnh mẽ. Nhưng việc sử dụng công nghệ hiện đại và các mẫu của nó phát triển chậm, và khi thế giới framework phát triển và công cụ PHP phát triển, CodeIgniter bắt đầu tụt hậu về cả tiến bộ công nghệ và các tính năng vượt trội. Không giống như nhiều framework khác, CodeIgniter được quản lý bởi một công ty và họ chậm bắt kịp với các tính năng mới hơn của PHP 5.3 như namespaces và chuyển sang GitHub và sau đó là Composer. Đó là vào năm 2010, Taylor Otwell, người tạo ra Laravel, đã không hài lòng với CodeIgniter và anh ấy đã bắt đầu viết ra framework của riêng mình.
Laravel 1, 2 và 3
Bản beta đầu tiên của Laravel 1 đã được phát hành vào tháng 6 năm 2011 và nó được viết hoàn toàn từ đầu. Nó có tính năng ORM tùy chỉnh (Eloquent); định tuyến dựa trên routing (lấy cảm hứng từ Ruby Sinatra); một hệ thống mô-đun để mở rộng; và trợ giúp cho các biểu mẫu form, xác nhận, xác thực người dùng, và nhiều hơn nữa.
Sự phát triển sớm của Laravel trở lên nhanh chóng, và lần lượt Laravel 2 và 3 được phát hành vào tháng 11 năm 2011 và tháng 2 năm 2012. Họ đã giới thiệu controllers, unit testing, command- line tool, IoC, mối quan hệ Eloquent (Eloquent relationships) và migrations.
Laravel 4
Với Laravel 4, Taylor viết lại toàn bộ từ đầu. Đến thời điểm này, Composer, trình quản lý package phổ biến hiện nay của PHP, đã có dấu hiệu trở thành một tiêu chuẩn công nghiệp và Taylor thấy giá trị của việc viết lại Laravel như một bộ sưu tập các component, được phân phối và kết hợp với nhau bởi Composer.
Taylor đã phát triển một bộ các thành phần với tên mã Illuminate và vào tháng 5 năm 2013, đã phát hành Laravel 4 với cấu trúc hoàn toàn mới. Thay vì gói phần lớn mã của nó dưới dạng tải xuống, giờ đây, Laravel đã lấy phần lớn các thành phần từ Symfony (một framework khác phát hành các thành phần của nó để người khác sử dụng) và các thành phần Illuminate thông qua Composer .
Laravel 4 cũng giới thiệu hàng đợi-queues, email, tạo dữ liệu mẫu-seeding.
Laravel 5
Laravel 4.3 đã được lên kế hoạch phát hành vào tháng 11 năm 2014, nhưng khi sự phát triển tiến triển, rõ ràng tầm quan trọng của những thay đổi của nó là một bản phát hành chính, và Laravel 5 đã được phát hành vào tháng 2 năm 2015.
Laravel 5 có cấu trúc thư mục được tân trang lại, loại bỏ biểu mẫu và trình trợ giúp HTML, giới thiệu giao diện interfaces, một loạt các chế độ xem mới, Socialite để xác thực phương tiện truyền thông xã hội, Elixir để biên dịch tài sản, Scheduler biểu để đơn giản hóa cron, dotenv để quản lý môi trường đơn giản, form request và REPL hoàn toàn mới.
Laravel có gì đặc biệt?
Vậy điều gì làm nên sự khác biệt của Laravel? Tại sao nó đáng để sử dụng hơn một framework PHP khác? Hãy tìm hiểu những gì làm cho Laravel trở lên đặc biệt.
Triết lý của Laravel
Bạn chỉ cần đọc qua các tài liệu marketing của Laravel và READMEs để bắt đầu thấy các giá trị của nó. Taylor sử dụng những từ liên quan đến ánh sáng như là “Illuminate” và “Spark”. Và sau đó là: “Nghệ nhân-Artisan”, “Thanh lịch-Elegant.” Ngoài ra, đây là: Hơi thở của không khí trong lành. “Khởi đầu mới-Fresh start” Và cuối cùng là: Rapid Rapid. Tốc độ Warp.
Hai giá trị được truyền đạt mạnh mẽ nhất của Laravel là tăng tốc độ của nhà phát triển và hạnh phúc của nhà phát triển. Taylor đã mô tả ngôn ngữ của Nghệ nhân là cố ý tương phản với các giá trị thực dụng hơn. Bạn có thể thấy nguồn gốc của kiểu suy nghĩ này trong câu hỏi năm 2011 của anh ấy trên StackExchange, trong đó anh ấy đã nói – “đôi khi tôi dành thời gian (giờ) lố bịch để làm cho mã trông khá đẹp – chỉ vì một trải nghiệm tốt hơn khi tìm kiếm tại chính mã ấy” Và anh ấy thường nói về giá trị của việc giúp các nhà phát triển dễ dàng và nhanh chóng hơn để đưa ý tưởng của họ thành hiện thực, thoát khỏi những rào cản không cần thiết để tạo ra những sản phẩm tuyệt vời.
Mục tiêu của Laravel là cung cấp mã và các tính năng rõ ràng, đơn giản và đẹp mắt, giúp các nhà phát triển nhanh chóng tìm hiểu, bắt đầu và phát triển và viết mã đơn giản, rõ ràng
Các khái niệm được viết rõ ràng trên các tài liệu của Laravel.Trong đó có viết “Happy developers make the best code” – tạm dịch: “các nhà phát triển hạnh phúc khi viết mã tốt nhất”. Tất nhiên, bất kỳ công cụ hoặc framework nào cũng sẽ nói rằng nó muốn các nhà phát triển được hạnh phúc. Nhưng việc có được hạnh phúc của nhà phát triển là mối quan tâm chính, thay vì thứ yếu, đã có tác động rất lớn đến phong cách và tiến trình ra quyết định của Laravel. Khi các framework khác có thể nhắm mục tiêu về độ tinh khiết của kiến trúc làm mục tiêu chính của chúng hoặc tương thích với các mục tiêu và giá trị của các nhóm phát triển doanh nghiệp, thì trọng tâm chính của Laravel là phục vụ nhà phát triển cá nhân.
Làm thế nào Laravel đạt được hạnh phúc của nhà phát triển
Việc nói rằng bạn muốn làm cho các nhà phát triển hạnh phúc là một điều. Làm điều này là một việc khác, và nó đòi hỏi bạn phải đặt câu hỏi điều gì trong một framework có khả năng làm cho các nhà phát triển không hài lòng và điều gì có khả năng làm cho họ hài lòng nhất. Có một vài cách mà Laravel cố gắng để làm cho các nhà phát triển có cuộc sống dễ dàng hơn.
Đầu tiên, Laravel là một framework phát triển ứng dụng nhanh chóng. Điều đó có nghĩa là nó tập trung vào việc học tập dễ dàng và giảm thiểu các bước giữa bắt đầu một ứng dụng mới đến khi phát hành. Tất cả các tác vụ phổ biến nhất trong việc xây dựng các ứng dụng web, từ tương tác cơ sở dữ liệu, xác thực đến hàng đợi, đến email, bộ nhớ đệm, được thực hiện đơn giản hơn bởi các thành phần mà Laravel cung cấp.
Chưa hết, Laravel cung cấp toàn bộ hệ sinh thái các công cụ để xây dựng và khởi chạy các ứng dụng một cách dễ dàng. Bạn có Homestead và Valet để phát triển trên môi trường local, Forge cho quản lý máy chủ và Envoyer để triển khai nâng cao. Và có một bộ gói bổ trợ: Cashier cho thanh toán và đăng ký, Echo cho WebSockets, Scout cho tìm kiếm, Passport để xác thực API, Socialite để đăng nhập bằng mạng xã hội và Spark để khởi động SaaS của bạn. Laravel đang cố gắng loại bỏ công việc lặp đi lặp lại khỏi các công việc của nhà phát triển để họ có thể làm một cái gì đó độc đáo.
Tiếp theo, Laravel tập trung vào”convention over configuration”, – nghĩa là nếu bạn sẵn sàng sử dụng cấu hình mặc định của Laravel, bạn sẽ phải làm việc ít hơn nhiều so với các framework khác yêu cầu bạn phải khai báo tất cả các cài đặt của mình ngay cả khi bạn sử dụng cấu hình mặc định. Các dự án được xây dựng trên Laravel mất ít thời gian hơn so với các dự án được xây dựng trên hầu hết các framework PHP khác.
Laravel cũng tập trung vào sự đơn giản. Nó có thể sử dụng cơ chế “dependency injection” và “Mocking” và kho lưu trữ dữ liệu và phân chia trách nhiệm truy vấn và tất cả các loại mẫu kiến trúc phức tạp khác với Laravel, nếu bạn muốn.
Cộng đồng Laravel
Một trong những yếu tố nổi bật của Laravel, đóng góp cho sự phát triển và thành công của nó, là cộng đồng giảng dạy, hỗ trợ của Laravel. Từ các video hướng dẫn về Laracasts của Jeffrey Way đến Laravel News đến các kênh Slack và IRC, từ bạn bè Twitter đến các blogger đến các hội nghị của Laracon, Laravel có một cộng đồng lớn và sôi động, những người đã có mặt từ ngày đầu tiên và những người sống một mình ngày một
Taylor đã hiểu từ những ngày đầu của Laravel rằng một dự án nguồn mở thành công cần có hai điều: tài liệu tốt và một cộng đồng lớn. Và hai điều đó bây giờ là đặc điểm nổi bật của Laravel.
Tại sao lại là Laravel?
Vậy – tại sao bạn nên sử dụng Laravel?
Bởi vì Laravel giúp bạn đưa ý tưởng của mình thành hiện thực mà không bị lãng phí mã, sử dụng các tiêu chuẩn mã hóa hiện đại, được bao quanh bởi một cộng đồng lớn, với một hệ thống các công cụ hỗ trợ vô cùng mạnh mẽ.
Và bởi vì bạn, nhà phát triển thân yêu, bạn xứng đáng được hạnh phúc.
Cậu tệ quá! Tốt nghiệp loại giỏi, lại xuất thân từ trường danh tiếng, cậu thể hiện chỉ được như thế thôi sao? Cậu không phải là nhân viên tốt. Chúng tôi cần nhiều hơn thế!
Đó là những câu nói mà nhiều ứng viên đã chia sẻ với TopDev. Thực tế ấy cho thấy một sinh viên giỏi chưa hẳn đã làm việc tốt. Lãnh đạo là người có chuyên môn, và chắc chắn sự phê bình hay góp ý của họ đều có cơ sở? Vậy bạn lẽ làm gì? Không lẽ bạn sẽ xù lông để tự bảo vệ mình: Ai cũng bảo tôi học giỏi, từ ba mẹ đến thầy cô, bạn bè, các người dựa vào gì để chê tôi? Việc phản bác như vậy sẽ không khiến bạn trở thành một nhân viên tốt hơn.
Hãy bình tĩnh! Và thật tỉnh táo để loại bỏ ngay suy nghĩ “Các sinh viên ưu tú thì nhất định là một nhân viên giỏi”. Nhiều yếu tố khác nhau giữa cả hai môi trường doanh nghiệp và giảng đường đã tạo ra sự chi phối lớn đến tiêu chi đánh giá chất lượng một sinh viên/nhân viên. Do vậy, việc áp đặt chung một quy chuẩn đánh giá là thiếu nhất quán.
Cùng TopDev phân tích rõ hơn về vấn đề này thông qua bài viết sau.
Hệ tiêu chuẩn đánh giá không đồng nhất
Ở Đại học, tiêu chuẩn đánh giá về năng lực là thái độ, kết quả học tập. Ngược lại, môi trường doanh nghiệp lại đề cao về thái độ và sự thể hiện thông qua những kết quả thực tế.
Nếu ở chốn giảng đường, bạn đáp ứng được những chỉ dẫn, điểm của bạn sẽ tốt. Và hiển nhiên, bạn thuộc top những sinh viên nổi trội. Thế nhưng, trong một tổ chức, cấp trên chỉ đánh giá bạn dựa vào những kết quả đạt được.
Hơn thế nữa, tiêu chuẩn về năng lực trong công ty còn chịu tác động bởi các hệ giá trị về tính trách nhiệm: đi đúng giờ, hoàn thành deadline,… Trường hợp bạn đạt hiệu suất sẽ được xem xét là một nhân viên tốt. Ngược lại, việc khiển trách hoặc sa thải sẽ dành cho những cá nhân không thể hoàn thành tốt nhiệm vụ được giao.
Nhiều sinh viên mới ra trường do thiếu trải nghiệm, họ bị chật vật với mọi thứ. Dù họ đã cố gắng nhưng vẫn luôn bị phê bình. Dường như lời phát ngôn: “Tôi đã cố gắng rồi” không còn hữu hiệu trong hoàn cảnh công sở nữa. Thay vào đó, giá trị của bạn chỉ được công nhận khi bạn thực hiện được phát ngôn: “Tôi đã hoàn thành”.
Cách nhìn nhận về năng lực có sự khác biệt
Học tập trên giảng đường, IQ được xem là hệ giá trị phản ánh tài năng. Thế nhưng, khi đi làm EQ mới là hệ giá trị được các công ty quan tâm nhất.
Chẳng hạn, các sinh viên khối ngành khoa học xã hội cần tận dụng năng lực trí nhớ. Sinh viên khối ngành khoa học tự nhiên tận dụng năng lực suy luận – tính toán.
Thế nhưng, các doanh nghiệp lại cần mỗi nhân viên phát huy tối đa các kỹ năng: thiết lập mối quan hệ – networking, kỹ năng giao tiếp, kỹ năng đàm phán,… Đó lại là những năng lực về EQ.
Chúng ta không thể phủ nhận những thành tích xuất sắc mà một sinh viên giỏi đạt được. Đó là những nỗ lực thật sự của họ. Thế nhưng, để trở thành một nhân viên tốt với đầy đủ những tố chất thì họ chưa đạt được. Nhiều sinh viên có kết quả học tập chưa tốt nhưng họ lại thành công. Họ tinh tế và có cách ứng xử chuyên nghiệp. Đồng thời, biết phát huy thế mạnh EQ để chứng tỏ năng lực của mình. Đó là lý do tại sao họ lại nhận được nhiều sự hậu thuẫn từ đồng nghiệp, bạn bè.
Sự khác biệt trong quy luật về Điểm giá trị năng lực
Điểm số học tập càng cao thì điểm giá trị năng lực càng lớn. Đó cũng chính là thước đo đánh giá duy nhất tại môi trường Đai học. Ngoài ra, tiêu chí phụ sẽ được phát huy nếu cá nhân sinh viên có tham gia vào các họat động xã hội, công trình nghiên cứu. Lúc ấy, điểm giá trị năng lực của bạn có thể được gia tăng lên.
Khác với quy luật trên, thước đo đánh giá ở công ty rất đa dạng. Tùy vào từng vị trí khác nhau đều có sự linh hoạt thể hiện các năng lực tương ứng.
Ví dụ như cùng là công ty về công nghệ, ở phòng ban Dev, cần những bạn có kỹ năng lập trình tốt. Trong khi đó ở phòng ban Social lại đòi hỏi những bạn có kỹ năng về sáng tạo. Chính sự khác biệt ấy dẫn đến yêu cầu thể hiện và phát triển các năng lực cũng khác nhau. Điểm giá trị năng lực trong công ty hướng đến những nhân viên phù hợp nhất, không phải tìm kiếm những nhân viên ưu tú nhất.
Dù bạn giỏi hay chưa giỏi theo quy chuẩn về thành tích, bạn cũng cần quan tâm đến cái gọi là sự phù hợp với môi trường công ty. Hãy thật sự hiểu được công ty cần gì. Bạn có gì để đáp ứng được những nhu cầu mà họ đang tìm kiếm. Lúc ấy, bạn mới thật sự là một cử nhân/ứng viên giỏi đúng nghĩa.
Lời kết
Không cần biết bạn giỏi thế nào, khi bắt đầu trở thành một nhân viên tốt, hãy tôn trọng các quy tắc. Hãy tìm hiểu để thích nghi nhanh chóng với môi trường mới. Quan tâm đến việc học hỏi và phát huy tốt các kỹ năng, bạn sẽ tiến bộ nhanh thôi. Đối với các công ty, nên tăng cường công tác đào tạo kỹ năng cho nhân viên thay vì chỉ dựa vào sự phán đoán đơn thuần – thành tích học tập. Hãy lưu tâm: sự cân bằng luôn quan trọng.
Bài viết được sự cho phép của tác giả Nguyễn Trương Trung Tín
(Lời mở đầu, thích thì đọc không thích thì cho qua) Vậy là cũng ngót nghét 4 tháng từ lúc bỏ vị trí làm native của Android chuyển sang làm giao diện và tính năng người dùng. Trong 4 tháng đó thì hết 3 tháng giành ra để chạy tính năng, chỉ mới 1 tháng gần đây mới giành lại thời gian để nghiên cứu “lại” kiến thức Android. Sau khi kinh qua từ core, tầng native tới tầng UI của Android thì hầu như đã có cái nhìn tổng quan về lập trình Android nói riêng và lập trình di động nói chung. Vì vậy, mình dự định viết vài bài blog để tổng hợp kinh nghiệm, kiến thức và các bài học mình rút ra được trong qua trình làm việc. Xem như vừa ôn bài vừa chia sẽ kiến thức, còn viết được vài bài hay không thì còn tùy vào mức độ “siêng” level max của mình nữa :v.
Thì sau 4 tháng chuyển từ native sang làm UI mình chỉ muốn rút gọn bài viết này trong 1 câu duy nhất là “PLEASE! LET THE UI COME FIRST”, còn câu chuyện tại sao mình nói câu đó và làm thế nào để let it come first thì mình sẽ viết tiếp theo sau đây hoặc trong các bài kế tiếp
Sự khác biệt giữa mobile và computer (pc và laptop) – mình chỉ so sánh với Android vì nó khá phổ biến trên thế giới và đa dạng về cấu hình hơn.
– TỐC ĐỘ XỬ LÝ: Về tốc độ xử lý thì ai dùng qua computer và mobile đều sẽ dễ dàng khẳng định được là tốc độ của mobile mặc dù đã rất phát triển nhưng so với tốc độ xử lý của máy tính thì vẫn còn xa. Nhưng để nói có sách mách có chứng thì sau một hồi tìm hiểu các thông số CPU của một số máy mạnh nhất hiện nay thì:
+ Android: Đa số máy thuộc dạng trâu bò hiện này thì CPU đã đạt được ngưỡng 2.7GHz và lõi tứ http://news.zing.vn/10-de-Android-cau-hinh-manh-nhat-hien-nay-post482280.html .
+ Computer: Về phần máy tính thì sau khi tìm hiểu 1 số bài viết thì mình biết được CPU của máy laptop hiện nay đã có thế lên đến 3,4GHz và lõi 8 lõi 12 chứ không còn là lõi tứ nữa. Bên cạnh đó máy máy tính còn có thể được trang bị card màn hình cấu hình “khủng” để giúp cho việc xử lý đồ họa được mượt mà hơn.
– BỘ NHỚ RAM: RAM là 1 phần không thể thiếu nếu đem ra so sánh performance giữa 2 thiết bị nào đó.
+ Android: Mình vẫn chưa được thấy máy Android nào trang bị RAM lên đến 8GB, hoặc nếu có thì cũng thuộc dạng hàng hiếm hiện nay, đa số các máy Android tầm trung chỉ vào khoảng 2-3GB RAM là cùng, trong đó hệ điều hành thường chiếm tới vài trăm MB RAM.
+ Computer: Laptop hoặc PC hiện nay theo mình biết thì đã trang bị được tối đa lên đên 16GB và có vài máy đã được 32GB RAM, 1 số lượng bộ nhớ tuyệt vời để chạy được hàng tá ứng dụng.
– DUNG LƯỢNG LƯU TRỮ: Với nhu cầu kĩ thuật số ngày càng phát triển về lượng và cả về chất như hiện nay thì 1 tấm hình có dung lượng vài chục MB hoặc 1 2 game có dung lượng lên tới vài GB là chuyện hết sức bình thường.
+ Android: Với các máy hiện nay thì đa số chỉ hộ trợ bộ nhớ trong khoảng 64GB và nếu có hổ trợ thẻ nhớ ngoài nữa thì mình nghĩ cũng chỉ lên đến tầm 128GB nữa là cùng.
+ Computer: Laptop hiện nay thì ổ cứng 256GB là đã thuộc dạng vứt đi được rồi. Một số máy hiện nay đã trang bị ổ cứng 1TB, ngoài ra còn chưa kể đến việc có thể lắp song song ổ SSD vào để tăng tốc độ truy xuất của bộ nhớ.
– PIN: Đa số người dùng computer sẽ ít lo về vấn đề PIN trong khi đó việc dùng mobile sẽ bi ảnh hưởng rất nhiều đến dung lượng PIN của thiết bị.
– TỐC ĐỘ MẠNG: Với thời đại internet như hiện nay thì tốc độ mạng là vấn đề không thể không đề cập tới.
+ Android: Đa số người dùng di động sẽ sử dụng mạng di động 3G làm phương tiện truy cập internet chính vì vậy về chi phí sẽ tốn rất nhiều và tốc độ thì không thể so sánh với mạng cap quang được.
+ Computer: Người dùng computer đa số sẽ sử dụng wifi hoặc mạng cáp, vì vậy việc dùng thả ga mạng để download và sẽ không lo đến chi phí sẽ là điều hiển nhiên
Đương nhiên sẽ có rất nhiều khía cạnh còn phải so sánh, nhưng việc so sánh trên chủ yếu mình muốn nói là mobile còn rất hạn chế so với computer nên việc để làm được 1 ứng dụng tốt thì còn phải quan tâm trên mức “làm được” đối với 1 số vấn đề. Và như mình nói ở trên là “LET THE UI COME FIRST!”
Giao diện người dùng.
Hãy tưởng tượng việc bạn bật 1 ứng dụng xem hình gái xinh lên. Có 1 danh sách các hot girl được show ra, và khi bạn scroll xuống list hình giật tung chảo thì bạn có còn hứng thú với việc sử dụng app đó nữa hay không? hay là tìm 1 ứng dụng khác?? Hoặc vào 1 ứng dụng tìm quán ăn mà bạn phải đợi màn hình loading (thậm chí là không hiện gì) đến cả buổi thì bạn có nản và tắt nó đi trước khi dùng hay không? Việc người dùng tương tác với ứng dụng họ sẽ thấy giao diện và tương tác với nó đầu tiên, không cần biết tính năng bạn làm bá tới đâu, bao nhiêu công sức bạn bỏ ra để “make up” cho giao diện đẹp lung linh, nhưng khi người dùng tương tác vào cảm thấy không hài lòng thì việc ứng dụng bạn bị uninstall ngay sau đó là rất dễ xảy ra. Vì vậy giữa việc bạn làm được và làm tốt sẽ rất khác nhau.
Nói thì dễ làm mới khó, mình có nghiên cứu khá nhiều tài liệu và tự tìm hiểu cũng như hỏi han các “thánh” khác thì rút ra 1 số kinh nghiệm về việc optimize layout (nhưng chưa có cơ hội áp dụng hết), mình sẽ chia sẽ ở những bài sau nếu có cơ hội. Một số kỹ thuật cho các bạn muốn tìm hiểu là: lazy load, optimize view hierachy, thread, cache, reuse view by using view holder,…
Đừng làm tốn tài nguyên người dùng 1 cách không đáng.
Như đã nói ở phần so sánh trước, Người dùng mobile đa phần sẽ dùng 3G để làm phương tiện truy cập internet. Vì vậy, dung lượng 3G là 1 điều hết sức đáng lưu ý. Đem so sánh 1 số ứng dụng OTT hiện nay như Zalo, Skype, Viber,.. thì bạn sẽ thích dùng cái nào hơn, đương nhiên là ứng dụng nào có dung lượng cuộc gọi thấp nhất và chất lượng ok nhất. Nói ngắn gọn lại là tốn ít tiền 3G nhưng gọi vẫn ok. Hoặc việc bạn phải tải đi tải lại 1 bài nhặc hoặc hình ảnh nào đó mà bạn “ĐÔ tải trước đó rồi thì thật sự rất phí dung lượng 3G khi bạn sử dụng những app đó. Vì vậy việc chú ý tài nguyên từ bộ nhớ máy, RAM, dung lượng 3G,… rất đáng để chú ý khi bạn bắt đầu lập trình 1 ứng dụng di động.
Không nên làm người dùng khó hiểu và cảm thấy phức tạp khi dùng app.
Việc người dùng có sử dụng ứng dụng của bạn hay không còn tùy thuộc rất nhiều vào độ “đơn giản” của app bạn. Khi có 2 ứng dụng 1 ứng dụng bắt bạn phải điền đầy đủ thông tin và 1 ứng dụng chỉ cần click vào nút đăng nhập bằng facebook thì bạn sẽ chọn sử dụng ứng dụng nào? Đương nhiên là ứng dụng cho đăng nhập bằng facebook, vì nó khá đơn giản và dễ sử dụng. Ngoài ra những thao tác cơ bản nhưng số bước thực hiện quá nhiều cũng rất dễ làm cho user phát nản. Giả dụ khi bạn cần mua 1 món hàng online qua app. Thì bạn có muốn phải làm 3 4 bước thủ tục, qua 3 4 bước màn hình. Hay là chỉ cần click mua 1 phát là có hàng liền? Đơn cử cho việc này là sự xuất hiện của Dialog, giúp người dùng không phải chuyển màn hình nhiều và làm cho app có cảm giác là nhỏ và tiện dụng hơn.
Nên đặt ví trí của mình là một người dùng app
Bạn sẽ cảm thấy khó chịu, bức bối cực kì khi bạn làm được điều này. Vì đi đâu trong app bạn bạn cũng sẽ thấy chưa hài lòng, và muốn nó tốt hơn, nhanh hơn và “rẻ” hơn. Hoặc nếu bạn không làm được thì bạn cứ nghĩ, sau này công ty “kế tiếp” của bạn sẽ nhìn vào sản phẩm bạn đang làm và đánh giá. Họ sẽ có cái nhìn cực kì khách quan, vì thế nếu bạn không biết tự đặt lại vị trí của mình thì tương lai bạn cũng có thể gặp khó khăn.
Bài viết là 1 số kinh nghiệm ít ỏi mình rút ra được, mọi người có góp ý hay đóng góp thêm thì mail về cho mình nha. Email: ntttin132@Gmail.com!
Học lập trình tới khi nào có thể làm freelancer? Tôi thấy trên các group về lập trình thì thấy khá nhiều bạn post bài viết về mong muốn học lập trình xong để đi làm freelancer và coi đó là nghề tay trái của mình. Nên nay tôi sẽ viết bài này để nói về học lập trình khi nào thì có thể làm freelancer.
Đầu tiên thì chúng ta cần phải biết freelancer là gì? freelancer là những người làm công việc tự do, không bó buộc vào một công ty nào cả. Freelancer thì có hai dạng, một là làm freelancer toàn thời gian, hai là freelancer chỉ làm buổi tối và cuối tuần. Còn ngày thường thì vẫn đến công ty làm bình thường.
2. Học lập trình khi nào có thể làm freelancer?
Câu trả lời nay rất đơn giản, khi bạn có kiến thức thì bạn có thể làm freelancer. Nếu bạn lại hỏi tôi kiến thức như thế nào là đủ thì tôi xin trả lời là kiến thức thì không bao giờ là đủ cả. Tôi xin ví dụ bạn đang và đã học hết một khóa lập trình ở một trung tâm hay một khóa học online nào đó, trong một ngày đẹp trời bạn vô tình lướt facebook và thấy một người nào đó post bài thuê làm bài tập hay đồ án. Bạn đọc yêu cầu và cảm thấy mình làm được và nhận cái công việc đó, hay bất kể công việc gì liên quan đến lập trình như fix bug, làm đồ án, bài tập…Lúc này bạn cũng đã dấn thân vào con đường freelancer rồi đó.
Tuy nhiên đó là những công việc chỉ giúp bạn kiếm được vài đồng lẻ mà thôi, làm sao bạn có thể trang trải cuộc sống trong khi giá cả đang leo thang từng ngày. Để trở thành một freelancer thực thụ, người mà có thể kiếm được nhiều hơn những số tiền lẻ kia thì cần rất nhiều kỹ năng về lập trình, phân tích dự án, giải quyết vấn đề… Mà những kỹ năng này thì không có trường lớp nào dạy bạn cả, chỉ có đi làm thực tế ở những công ty khoảng 2-3 năm là kinh nghiệm bạn sẽ phát triển dần dần lên. Lúc này bạn sẽ tự tin nhận những dự án khó, tiền nhiều để làm. Nếu bạn đang đi một mình thì không bao giờ mà học lập trình để làm freelancer mà không phải trải qua một vài năm rèn dũa ở các công ty về lập trình cả. Còn nếu bạn có người dẫn dắt để làm freelancer thì có thể bạn sẽ không cần rèn dũa bởi công ty mà lúc này người rèn dũa bạn chính là người dẫn dắt bạn.
3. Những khó khăn khi làm freelancer?
* Khó khăn về tìm kiếm dự án
Để làm được freelancer thì bạn phải có dự án để làm, mà dự án ở đâu ra. Bạn phải có được nguồn cung cấp từ bạn bè, người thân.. hoặc phải tự đi kiếm dự án về làm.
* Khó khăn về kỹ thuật
Một ngày nọ bạn nhận làm một project, tuy nhiên đang làm đến một task khó nào đó thì bạn bí, làm hoài hai ba ngày không ra, deadline sắp tới gần, bạn cảm thấy chán nản, bạn muốn bùng dự án. Lúc này kỹ năng của bạn không đáp ứng được độ khó của dự án, bạn cứ nghĩ là bạn làm được rồi nhận đại, nhưng khi vào làm thì tá hỏa lên vì không giải quyết được những vấn đề trong đó.
* Khó khăn khi nhận dự án
Khi nhận một dự án thì bạn phải cân nhắc về độ lớn của dự án, nếu đang làm freelancer độc cô cầu bại thì bạn không thể nhận dự án quá lớn được vì một mình thì khó có thể ôm một dự án lớn. Khi mà kỹ thuật của bạn không đủ thì dự án rất dễ bị fail. Lúc này bạn phải có một team để làm, cùng nhau giải quyết những vấn đề đang gặp phải.
4. Lợi ích khi làm freelancer?
Khi làm freelancer thì lợi ích về tiền bạc thì cũng không hề nhỏ, những người làm freelancer toàn thời gian nếu dự án có đều thì số tiền của họ kiếm được là gấp rưỡi hoặc gấp đôi nếu đi làm ở công ty. Còn những người làm freelancer ít thời gian thì cũng có thể kiếm được tiền trang trải cho cuộc sống của mình.
Ngoài lợi ích về tiền bạc thì bạn cũng tăng được kỹ thuật lập trình của mình lên, nhờ những lần tôi làm freelancer có nhiều yêu cầu khác nhau nên tôi cũng biết thêm khá nhiều những cái mới lạ và hay ho.
Nhắc đến thiệt hại khi làm freelancer thì tôi vẫn đang cay, đó là việc bị khách hàng xù tiền. Vấn đề xù tiền khi giao hàng xong thì những người làm freelancer có lẽ ai cũng đã từng bị, lần đầu làm để tạo uy tín nên tôi đã không yêu cầu thanh toán trước 50% mà giao hàng họ test ổn thì sẽ yêu cầu thanh toán. Tuy nhiên sau khi giao hàng thì không liên lạc được nữa và mất trắng số tiền mà mình cực khổ làm cho họ. Thế nên nếu ai muốn theo nghiệp freelancer thì khi làm dự án nên cân nhắc số tiền đặt cọc để không mắc phải sai lầm giống như tôi nhé.
Bài viết được sự cho phép của tác giả Huỳnh Quán Cẩm
Chuyện là vài hôm trước, tui có fix được một lỗi tồn tại khá lâu của Nabo liên quan đến Elixir compiler. Bản fix thì chỉ vài dòng thôi, cơ mà nguồn cơn sâu xa thì hơi dài dòng. Giải thích trong PR không hết. Hơn nữa, từ lâu tui cũng đã muốn viết bài về chủ đề compiler của Elixir vì thấy nó cũng khá hay ho. Nhân cơ hội này, xin được chia sẻ cùng các bác.
Để tiện theo dõi, tui tạm chia Elixir Compiler ra làm 2 phần: Compiler và Parallel Compiler. Compiler chịu trách nhiệm compile một file ra Erlang binaries (BEAM byte code). Parallel Compiler cho phép compile nhiều file song song, nhằm tăng tốc quá trình compile.
Bài viết hơi khô khan, vui lòng tự tra dầu nhớt trước khi đọc!
Compiler
DQ;ĐĐ (Dài quá; đếu đọc)
Elixir compiler biên dịch một đoạn mã nguồn Elixir thành BEAM byte code.
DĐ;ĐĐ (Dài đó; đọc đi)
Mục tiêu của Elixir compiler là sinh ra BEAM byte code. Sau đó, byte code được sử dụng tùy theo mục đích biên dịch: mix compile, IEx, v.v.
Về bản chất, Elixir compiler là một chương trình Erlang. Khi cần biên dịch một file, đầu tiên nó sẽ bật máy ảo Erlang lên và bootstrap các module cần thiết (Kernel, code server).
Tương tự như các trình biên dịch khác, Elixir compiler cũng tokenize và parse source code thành abstract syntax tree (AST, cây cú pháp trừu tượng), thường gọi là quoted form trong Elixir. Mọi language construct trong Elixir đều được biểu diễn bằng quoted form.
AST của Elixir là một tuple gồm 3 phần tử: toán tử, metadata, và các tham số của toán tử đó. Ví dụ AST của câu lệnh a + b * c là:
Quoted form là building block của ngôn ngữ Elixir. Nó là code dưới dạng data, thao tác với nó cho phép ta dùng code để viết code. Elixir cung cấp interface quote, unquote và Macro để làm việc với quoted form. Để biết chi tiết hơn bạn có thể đọc qua bài Elixir—Ngôn ngữ được biết bằng macros.
Sau đó, từng bước một, compiler sẽ biên dịch AST thành BEAM byte code. Đây là một quá trình dài bao gồm nhiều bước:
expand—triển khai quoted form và thực hiện kiểm tra tính đúng đắn của quoted form.
translate: dịch từ expanded form sang Erlang Abstract Format, còn gọi là Erlang parse tree.
compile: biên dịch từ Erlang Abstract Format sang Core Erlang, cuối cùng là BEAM bytecode.
Thật ra thì trong các bước này chia ra nhiều bước và nhánh nhỏ khác, mà trong khuôn khổ bài viết này không thể trình bày hết. Xin được khất lại sang một bài khác.
Compiler ghi BEAM bytecode vào code path, cụ thể là /ebin, kết thúc quá trình biên dịch.
Một số câu hỏi thường được đặt ra
Nếu code Elixir được biên dịch ra Erlang, vậy nó có chậm hơn Erlang không?
Không và không hẳn. Code Elixir được biên dịch ra BEAM byte code (không phải Erlang). Code Erlang cũng vậy, tuy các bước có khác, nhưng output vẫn là BEAM byte code. Erlang không phải là ngôn ngữ bậc cao hơn Elixir.
Một số trường hợp Elixir sẽ chậm hơn đôi chút, ví dụ khi bạn làm việc với Enum. Đôi lúc code Elixir sẽ nhanh hơn, khi bạn sử dụng binary thay vì char list như Erlang. Cơ mà sự khác biệt chỉ là rất rất rất nhỏ, không thật sự đáng kể.
Vì sao compiler phải bỏ BEAM byte code vào trong ebin?
Erlang VM trong interactive mode có cơ chế autoload module vào code server ở lần đầu tiên bạn gọi module, từ ebin. Cơ chế autoloading chính là yếu tố làm nên sự thú vị của Elixir parallel compiler mà tui sẽ trình bày tiếp theo.
Elixir Parallel Compiler
Trước khi đi vào parallel compiler, hãy cùng tui kinh qua 2 thứ: Code Server và :error_handler.
Code Server là nơi chứa code của Erlang VM. Trước khi một module được thực thi, code của nó cần phải được nạp vào code server. (Ờ ha, không nạp code sao chạy ha.)
Module :code trong Erlang Kernel cung cấp một số interface để bạn thao tác với code server. Ví dụ :code.load_binary(Foo, "", beam) sẽ nạp module Foo với beam là byte code; trong khi :code.purge hoặc :code.delete giúp bạn xóa code ra khỏi code server.
iex> defmodule Foo do
...> deffoo(), do:true
...> end
{:module, Foo,
<<70, 79, 82, ...>>, {:foo, 0}}
iex> Foo.foo()
true
iex> :code.delete(Foo)
true
iex> Foo.foo()
** (UndefinedFunctionError) function Foo.foo/0 is undefined (moduleFooisnotavailable)
Foo.foo()
Elixir compiler chạy trên Erlang VM interactive mode. Compile-time của chúng ta chính là run-time của compiler ( Mr. Obvious!). Compiler của Elixir vừa biên dịch code, vừa thực thi code.
Đọc tới đây, một độc giả tinh ý phán xét: Quào, khúc này bối rối quá Quần Cam ơi. Vừa biên dịch code vừa chạy code là sao? Chẳng phải ông vừa chém là compiler phải dịch ra byte code, nạp nó vào code server thì mới thực thi được sao. Mâu thuẫn, mâu thuẫn! Trả lại tiền 2 tô sủi cảo đi.
Ở đây, ta muốn tính @heavy_computation ở compile time để tăng tốc hàm foo(), thay vì cứ phải tính đi tính lại ở run time. Cho nên khi biên dịch tới khúc đó, compiler cần phải thực thi code.
Để cho gọn code, đôi khi ta muốn bỏ tách phần code @heavy_computation vào một module khác cho code đẹp. Thế là code viết lại thành:
Tuy nhiên, việc này sẽ làm nảy sinh ra một vấn đề: compiler cần đảm bảo rằng HeavyComputation được biên dịch trước Foo. Hay nói cách khác, Foo có compile-time dependency vào HeavyComputation.
Để đảm bảo điều đó, cách giải quyết thông thường là sinh ra một cái dependency graph. Rồi dựa vào graph này để biết thứ tự biên dịch của các file. Cơ mà sẽ không có thuật toán liên quan đến dependency graph ở bài viết này đâu .
Đó là vì Elixir … không làm như thế mà chọn một lối đi riêng, dựa vào cơ chế :error_handler trong interactive mode. Nó tự tìm dependency on-the-fly (không biết dịch on-the-fly sao cho gọn).
Trong interactive mode, nếu module không tồn tại, Erlang VM sẽ kích hoạt callback trong :error_handler. :error_handler sẽ thử nạp module đang thiếu lên. Nếu load được, nó chạy tiếp như không có gì xảy ra. Nếu không load được, nó sẽ chửi vào mặt chúng ta.
Ngoài ra, Erlang cho phép chúng ta tự định nghĩa cách xử lý các lỗi liên quan tới module loading. Bạn có thể tạo một module implement các callback cần thiết của :error_handler, sau đó thay đổi biến cờ :error_handler. Bạn nào code Ruby có thể tưởng tượng nó hao hao method_missing (mặc dù không phải vậy).
Bạn có thể thử chơi với :error_handler trên IEx hoặc production tùy theo nồng độ liều trong máu bạn cao hay không:
iex(1)> defmoduleFooHandlerdo
...(1)> defundefined_function(mod, fun, args) do
...(1)> IO.puts("Could not find " <> inspect({mod, fun, args}))
...(1)> :error_handler.undefined_function(mod, fun, args)
...(1)> end
...(1)> end
iex(2)> :erlang.process_flag(:error_handler, FooHandler)
:error_handler
iex(3)> ABC.foo()
Could not find {ABC, :foo, []}
Could not find {Exception, :blame...}
Could not find {ErlangError, :normalize ...}
** (UndefinedFunctionError) function ABC.foo/0 is undefined (module ABC is not available)
ABC.foo()
Vậy error handler liên quan gì đến điều mà ta đang nói tới? Ở ví dụ đó, ngẫu nhiên 2 trường hợp có khả năng xảy ra:
HeavyComputation được biên dịch trước, trường hợp này thì không có gì đáng bàn.
Foo được biên dịch trước. Biên tới khúc gọi hàm thì nó phát hiện HeavyComputation không tồn tại (nhờ error handler). Nó sẽ tạm dừng lại, spawn ra một process khác để biên dịch module đang thiếu. Sau khi biên dịch HeavyComputation xong, Foo sẽ tiếp tục được biên dịch.
Về cơ bản thì cách này chạy được. Cơ mà spawn process vô tội vạ thì hay bị dính họa vào thân. Hơn nữa còn dễ xảy ra deadlock. Giả sử Foo và HeavyComputation có compile-time dependency lên lẫn nhau, HeavyComputation sẽ tiếp tục đẻ ra Foo, Foo lại đẻ ra HeavyComputation. Tốc độ lây lan nhanh như con virus Vũ Hán.
Process ở đây có thể hiểu nôm na là lightweight thread (mặc dù không hẳn vậy) trong Erlang VM. Ta có thể spawn hàng triệu process như thế. Bạn đọc có thể xem bài Elixir/Erlang, Actors model và Concurrency nếu muốn hiểu thêm.
Vì thế, ta cần phải có một con coordinator đứng ra làm nhiệm vụ điều tiết, với một số yêu cầu sau:
Các file source code không được sắp xếp theo một thứ tự nào cả.
Khi bạn có dependency graph kiểu A -> B, B -> C, C -> A, bạn có một cái cyclic deadlock. Coordinator phải detect được deadlock.
Coordinator sẽ spawn ra compiler process cho từng file, cho phép biên dịch nhiều file song song.
Tuy nhiên, khả năng xử lý song song của bạn bằng với số lượng online scheduler mà bạn có (nôm na là CPU cores). Có spawn hàng triệu task thì máy tính của bạn cũng không làm được hơn thế. Thậm chí nó còn làm giảm hiệu năng bởi vì scheduler phải tốn thêm công điều tiết.
Thuật toán xử lý của coordinator không phức tạp chút nào, có thể tóm gọn lại như sau:
Coordinator spawn ra một compiler process riêng cho mỗi file, duy trì số lượng process theo ý muốn bằng cách giữ một biến counter.
Mỗi con compiler này sẽ biên dịch file của nó. Nếu trong compile-time dependency Y trong file X chưa tồn tại, X sẽ dừng lại, nói cho coordinator biết nó đang đợi module Y, rồi khoanh tay đứng yên không làm gì cả.
Coordinator ghi nhận X -> Y (X đợi Y) vào trong waiting list của mình, rồi tiếp tục đẻ ra compiler process cho file tiếp theo trong danh sách.
Khi Y được biên dịch xong, coordinator sẽ báo cho X để X tiếp tục biên dịch.
Ví dụ
Tui hy vọng tới khúc này bạn đã hiểu. Nếu chưa thì bạn thể theo dõi ví dụ sau:
Cho một gia đình Quần Cam. Quần Cam phụ thuộc vào Cha và Mẹ, Cha và Mẹ phụ thuộc vào Cha và Mẹ của họ.
Bắt đầu với CODE server rỗng (chưa có module nào được load/compile). QUEUE chứa danh sách file cần biên dịch với thứ tự ngẫu nhiên. Coordinator duy trì mức 2 task song song.
CODE []
QUẦN CAM
/ \
CHA MẸ
/ \ / \
CHA CHA MẸ CHA CHA MẸ MẸ MẸ
QUEUE [CHA CHA, CHA, QUẦN CAM, MẸ, MẸ MẸ, MẸ CHA, CHA MẸ]
WAITING []
2 file đầu tiên là CHA CHA và CHA được đưa vào biên dịch.
Nói một cách ngắn gọn nhất, để bạn dễ nhớ thì hãy nhớ đến tên đầy đủ của từng thằng để hình dung công dụng của nó
npm viết tắt cho Node Package Manager
npx viết tắt cho Node Package eXecute
Một thằng dùng để quản lý package, thằng còn lại để thực thi package.
NPM là gì?
NPM là bộ quản lý package (như bộ giao thông vận tải, bộ giáo dục đào tạo) chính thức của Node.js, khi bạn cài Node.js là bạn được tặng kèm không thu giá một bộ command-line (câu lệnh để bạn gõ cọc cọc trong terminal) cũng tên là npm
Nó là một kho lưu trữ trực tuyến để xuất bản các dự án Node.js mã nguồn mở. NPM còn là một công cụ CLI hỗ trợ bạn cài đặt các gói đó và quản lý các phiên bản và phần phụ thuộc của chúng. Có hàng trăm nghìn thư viện và ứng dụng Node.js trên npm và nhiều thư viện khác được thêm vào mỗi ngày.
npm tự nó không chạy package. Nếu bạn muốn chạy package sử dụng npm, bạn phải chỉ định gói đó trong package.jsontệp của mình .
Khi các tệp thực thi được cài đặt thông qua các gói npm, npm sẽ tạo liên kết đến chúng:
cài đặt cục bộ có liên kết được tạo tại ./node_modules/.bin/thư mục
cài đặt toàn cầu có các liên kết được tạo từ bin/thư mục chung (ví dụ: /usr/local/bintrên Linux hoặc tại %AppData%/npmtrên Windows)
Để thực thi một gói với npm, bạn phải nhập đường dẫn cục bộ, như sau:
$ ./node_modules/.bin/your-package
hoặc bạn có thể chạy một gói được cài đặt cục bộ bằng cách thêm nó vào package.jsontệp của bạn trong phần tập lệnh, như sau:
NPX, được trình làng từ Node.js 5.2.0 (nghĩa là hiện tại bạn sẽ luôn có npx song song với npm, vì cái thời 5.2.0 là nó là thời mình còn cởi truồng tắm mưa rồi) được dùng để thực thi bất kỳ package nào có trên trang https://www.npmjs.com/ mà không cần cài đặt nó trước đó, bạn chỉ chạy nó thôi (tức nhiên nếu nó chạy được)
npx cũng là một công cụ CLI có mục đích là giúp dễ dàng cài đặt và quản lý các phần phụ thuộc được lưu trữ trong sổ đăng ký npm.
Giờ đây, rất dễ dàng để chạy bất kỳ loại tệp thực thi nào dựa trên Node.js mà bạn thường cài đặt qua npm.
Bạn có thể chạy lệnh sau để xem nó đã được cài đặt cho phiên bản npm hiện tại của bạn chưa:
$ which npx
Nếu không, bạn có thể cài đặt nó như sau:
$ npminstall -g npx
Sau khi chắc chắn rằng bạn đã cài đặt nó, hãy cùng xem một vài trường hợp sử dụng khiến npx trở nên cực kỳ hữu ích.
Chạy một gói được cài đặt cục bộ một cách dễ dàng
Nếu bạn muốn thực thi một gói được cài đặt cục bộ, tất cả những gì bạn cần làm là nhập:
$ npx your-package
npx sẽ kiểm tra xem có <command>hoặc <package>tồn tại trong $PATHhoặc trong tệp nhị phân dự án cục bộ hay không và nếu có thì nó sẽ thực thi.
Thực thi các gói chưa được cài đặt trước đó
Một ưu điểm lớn khác là khả năng thực thi một gói chưa được cài đặt trước đó.
Hãy kiểm tra điều này bằng cách chạy:
$ npx cowsay wow
Điều này thật tuyệt vời vì đôi khi bạn chỉ muốn sử dụng một số công cụ CLI nhưng bạn không muốn cài đặt chúng trên toàn cầu chỉ để kiểm tra chúng.
Điều này có nghĩa là bạn có thể tiết kiệm một số dung lượng ổ đĩa và chỉ chạy chúng khi bạn cần. Điều này cũng có nghĩa là các biến toàn cục của bạn sẽ ít bị ô nhiễm hơn.
Chạy mã trực tiếp từ GitHub
Bạn có thể sử dụng npx để chạy bất kỳ lưu trữ và kho lưu trữ GitHub nào. Hãy tập trung vào việc thực thi ý chính GitHub vì việc tạo một ý chính dễ dàng hơn.
Tập lệnh cơ bản nhất bao gồm tệp JS chính và a package.json. Sau khi bạn đã thiết lập các tệp, tất cả những gì bạn phải làm là chạy npx với liên kết đến ý chính như thể hiện trong hình trên
Ví dụ cho dễ hiểu nhé, trên tài liệu của create-react-app người ta sẽ hướng dẫn bạn chạy lệnh
npx create-react-app my-app
Bạn không cần cài create-react-app (bản thân nó là một package Node.js), mà chỉ thực thi nó để init source code
Để trở thành lập trình viên thì chúng ta phải học code và những môn bổ trợ. Để trở thành lập trình viên giỏi thì ta cần phải biết nhiều thứ khác nhau, debug cũng là một thứ mà một lập trình viên giỏi nhất định phải thành thạo.
Trước khi khi học ở trường đại học thì tôi không biết về nó nên khi đi làm thì tôi gặp rất nhiều khó khăn, vì vậy tôi viết bài này chia sẻ về debug, hy vọng sẽ giúp các bạn nhiều hơn về con đường lập trình.
Debug là một công cụ gỡ lỗi mà một ngôn ngữ lập trình nào cũng phải có, nói đến debug thì mọi người sẽ nghĩ đến chương trình bị lỗi thì sẽ sử dụng công cụ này để tìm lỗi, tuy nhiên đó chỉ là một phần đúng mà thôi. Ngoài chức năng gỡ lỗi của nó thì nó còn cho chúng ta biết những thứ khác, những thứ đó là gì thì chúng ta cùng tìm hiểu các ví dụ thực tế nhé.
2. Debug trong ngôn ngữ javascript
Để hiểu về debug thì bạn cần biết được bốn thứ quan trọng đó là: breakpoint, step over, step into, watch.
2.1 Breakpoint là gì?
Breakpoints đó là điểm dừng, bất kể bạn làm việc trên javascript hay bất kỳ một ngôn ngữ nào khác cũng đều có breakpoints, khi bạn debug thì cần đặt một điểm dừng ở trong source code, nơi mà bạn đang nghi ngờ chỗ đó phát sinh bug.
Quan sát hình bên trên, vùng khoanh màu đỏ (dòng 8) thì tôi có đặt một breakpoints, khi chương trình của tôi chạy tới dòng 8 thì tự động chương trình sẽ dừng lại và không chạy tiếp cho đến khi tôi tác động.
2.2 Step over là gì?
Step over là di chuyển xuống một dòng, sau vị trí đặt breakpoints
Quan sát hình bên trên thì ta thấy vị trí ban đầu đã di chuyển xuống dòng 9, còn breakpoints của dòng 8 đã đặt trước đó thì vẫn sẽ giữ nguyên như cũ để cho lần chạy tiếp theo.
2.3 Step into là gì?
Step into là di chuyển vị trí debug vào trong function con, bạn hãy nhìn hình bên trên sẽ thấy function getLocalStorage(). Step into sẽ di chuyển debug vào hàm này.
2.4 Watch là gì?
Watch là nơi mà hiển thị các thông tin của biến, giá trị trả về của function, để chúng ta xem và phán đoán bug, đồng thời có thể đưa ra được cách giải quyết cái bug của mình.
Quan sát hình bên trên thì tôi có thể xem được các dữ liệu của biến key truyền vào function getLocalStorage(key) là gì. Và kết quả trả về của getLocalStorage là gì.
2.5 Cách debug trong javascript
Để debug javascript thì tôi sẽ dùng công cụ developer tool của google chrome. Để mở công cụ này lên thì nhấn F12 thôi, khá là đơn giản, khi đó giao diện của bạn sẽ như thế này.
Khi mở lên thì chọn tab Source, nơi đây sẽ chứa những file html, js, css, image dự án của bạn.
2.5.1 Đặt một breakpoints
Để đặt một điểm dừng cho debug thì tôi sẽ nhấn chuột trái vào vùng khoanh màu đỏ.
2.5.2 Step over
Để di chuyển sang dòng tiếp theo thì nhấn F10, hoặc nút được khoanh màu đỏ hình ở bên dưới.
2.5.3 Step into
Để di chuyển vào trong hàm con của getLocalStorage thì nhấn F11, hoặc phấn vào nút được khoanh màu đỏ ở hình bên dưới.
2.5.4 Watch
Để xem dữ liệu của các kiến hay giá trị trả về thì bôi đen giá trị muốn xem và nhấn chuột phải tại giá trị đó và chọn “Add selected text to watches”.
Nhấn F8 để nhảy đến vị trí đặt breakpoints kế tiếp, nếu không có vị trí đặt breakpoints kế tiếp thì chương trình sẽ tiếp tục chạy.
Trên đây là những cái cơ bản nhất của debug, có thể các bạn xem xong phần này nhưng vẫn sẽ thắc mắc vì chưa hình dung được khi vào dự án thực tế thì bug sẽ như thế nào, cách giải quyết ra sao. Nếu bạn thắc mắc như vậy thì đó là điều hiển nhiên, vì bài này tôi viết chỉ ở mức cơ bản, tiếp cận về debug mà thôi, ở bài viết sau tôi sẽ viết những bài nâng cao hơn, tôi sẽ tự đặt ra những ví dụ thực tế về những cái mà tôi đã gặp phải và cách giải quyết chúng. Lúc đó bạn sẽ hiểu rõ thêm về sức mạnh của debug là gì.
Để thành công trong sự nghiệp, bạn cần nắm được những yếu tố cốt lõi mà nhà tuyển dụng muốn khai thác ở một ứng viên. Vậy bạn đã từng nghe về Tư duy cầu tiến (Growth Mindset) chưa? Đó được xem là bí quyết giúp bạn chinh phục những nhà tuyển dụng khó nhằn nhất. Cùng TopDev tìm hiểu về tư duy cầu tiến trong bài viết sau.
Tư duy cầu tiến là gì?
Tư duy cầu tiến – Growth Mindsetđược mô tả trên nền tảng về niềm tin của một cá nhân khi họ đủ nhận thức bản thân có thể học hỏi và cải thiện năng lực.
Sự tự nhận thức ấy được phản ánh qua những biểu hiện về sự nỗ lực và cách họ vượt qua những thất bại. Hoặc bao quát hơn, tư duy cầu tiến được bộc lộ thông qua thái độ của mỗi người. Tức là cách bạn đối đầu với thách thức ở những mức độ như thế nào.
Khác với những người có lối tư duy bảo thủ, người có tư duy cầu tiến luôn tiếp nhận những thất bại. Trong họ tràn đầy tinh thần học hỏi. Họ chấp nhận những sai lầm để nhận ra các bài học giá trị. Họ xem đó là từng nấc thang cao hơn, từng cơ hội lớn hơn để bản thân chinh phục và thử sức.
Đó là lý do tại sao họ luôn tự trau dồi, phát triển bản thân một cách nhanh chóng. Đơn giản, họ đón nhận thất bại bằng một niềm vui tích cực. Đồng thời, tự nhận ra những điểm yếu và sẵn sàng trải nghiệm cái mới.
Ghi điểm với nhà tuyển dụng với cách thiết lập tư duy cầu tiến hiệu quả
Ngoài chuyên môn, bạn cần thể hiện cho nhà tuyển dụng thấy tố chất về tư duy cầu tiến. Thái độ chính là tiêu chí quyết định đến sự thành công của bạn.
“I can do it!” – Từ suy nghĩ đến hành động tích cực
Mọi hành động của bạn đều có quá trình. Tất nhiên, nó sẽ chi phối mạnh mẽ khi bạn nhận thức, suy nghĩ, thể hiện năng lượng trí tuệ cảm xúc về một vấn đề nào đó. Vì thế, nếu trở nên vô vọng trước những thách thức, đó là một điều đáng tiếc.
Đừng đánh mất đi cơ hội. Hãy giữ cho mình một tư duy cầu tiến. Cụ thể là thái độ thích nghi, lắng nghe và chấp nhận đối mặt với các thử thách. Hãy bình tĩnh, ngẫm lại những gì đã diễn ra để nhận ta đâu là lỗ hỏng. Từ đó, bạn biết được những giải pháp nào sẽ phù hợp và mang lại hiệu quả cao nhất.
Bạn có biết rằng Walt Disney đã từng bị đuổi khỏi tòa soạn the Kansas City Star với lý do thiếu sáng tạo về mặt ý tưởng”. Do vậy, hãy luôn tâm niệm: “I can do it!”. – Tôi có thể làm được. Suy nghĩ ấy tạo ra một động lớn thúc đẩy bạn tiếp tục cố gắng. Thế nhưng, nếu bạn cứ duy trì những suy nghĩ bảo thủ, bạn sẽ mãi chậm chân tại chỗ, không thể có những bước tiến xa hơn.
Những người cầu tiến họ không ngại thử thách. Chắc chắn, sẽ khó tránh khỏi những nỗi sợ khác nhau phát sinh từ công việc. Lượng công việc quá lớn tạo ra áp lực đối với họ. Và để không cảm thấy mất kiểm soát trong việc giải quyết công việc thì bạn nên lập kế hoạch thực hiện mục tiêu.
Mỗi mục tiêu đề ra phải tương ứng với các đầu nhiệm vụ. Chúng cần được phân chia hợp lý theo trình tự logic. Từ đó, bạn dễ dàng xử lý công việc đồng thời đảm bảo việc thực hiện đang đi đúng quỹ đạo; tránh làm phát sinh những rủi ro.
Khi đạt hiệu quả, bạn sẽ có động lực để cố gắng hoàn thành các nhiệm vụ tiếp theo. Kế hoạch nên được cập nhật theo ngày, tháng, quý để tiện cho việc theo dõi, đánh giá cả quá trình.
Trở thành một phiên bản tốt hơn mỗi ngày
Đây là điều quan trọng bạn cần lưu tâm để rèn luyện tư duy cầu tiến.
Những cá nhân Growth Mindset họ thường đặt ra chỉ tiêu bản thân phải tiến bộ hơn mỗi ngày. Dù chỉ là 1 hay 2% nhưng mọi sự thay đổi đều có giá trị. Họ nhận ra nhiều sự khác biệt nhỏ được nảy sinh từ những cố gắng.
Nỗ lực đôi khi không phải cái bạn muốn là có được. Có những người họ phải trải qua những khó khăn; có quá trình tự nhìn nhận để tạo động lực cho bản thân cố gắng. Thế nhưng, nếu muốn rèn luyện tư duy cầu tiến, bạn cần chủ động trong việc thực hiện các nỗ lực. Dù cho bạn nghĩ rằng bạn đang đạt được giới hạn của sự hoàn hảo, bạn vẫn phải cố gắng. Hãy là một phiên bản tốt hơn mỗi ngày; không ngừng học hỏi và nâng cao những trải nghiệm!
Đúc kết những kinh nghiệm từ thực tế
Để rèn luyện tư duy cầu tiến, bạn phải góp nhặt nững kinh nghiệm từ những lần thất bại.Thất bại không đồng nghĩa với sự thua cuộc.
Bạn có thể học hỏi và trưởng thành, tiến bộ lên rất nhiều nếu ghi nhận những phản hồi. Và quá trình ngẫm lại những điểm thiếu sót của bản thân để quyết tâm thay đổi. Mỗi kinh nghiệm đều có giá trị riêng của nó. Và như đã nói từ trước, thái độ chính là sự phản ánh chân thật nhất của tư duy cầu tiến.
Với một thái độ tốt, bạn tự đánh giá lại bản thân đồng thời tiếp tục nỗ lực trau dồi. Ngược lại, với một thái độ không tích cực, thiếu sự cầu thị trong công việc, bạn nhất định sẽ không có một bước tiến lớn nào trong sự nghiệp phát triển của bản thân.
Nhà tuyển dụng họ đánh giá rất cao những ứng viên có thể chia sẻ về các trải nhiệm của bản thân. Không phải ai cũng có thể tự đánh giá và mô tả và chia sẻ những trải nghiệm ấy với người khác. Nếu bạn làm được điều đó, bạn là người sở hữu tư duy cầu tiến rồi, hãy cứ phát huy nhé!
Lời kết
Nếu xét về mặt phát triển cá nhân, Tư duy cầu tiến – Growth Mindest giúp kích thích lối tri nhận, phát triển tối đa năng lực trong tiềm năng giới hạn của bạn hoặc hơn thế. Hãy rèn luyện cho bản thân mình một tư duy cầu tiến. Nhớ rằng cầu tiến không có nghĩa là bất chấp mọi thỉ đoạn để đạt được mục đích. Một người thật sự hiểu về tư duy cầu tiến sẽ không bao giờ để mình lạc vào những phạm vị tiêu cực có thể diễn ra.
Bài viết được sự cho phép của tác giả Vũ Công Tấn Tài
Ngày phép – theo định nghĩa thì nó là những ngày có trong lịch làm việc của công ty mà bạn được phép được nghỉ ở nhà, và điều quan trọng là bạn vẫn sẽ được công ty trả lương cho những ngày đó. Theo luật lao động chính thức ở Việt Nam thì mỗi năm số ngày phép tối thiểu mà bạn có sẽ là 12 ngày.
Tuy vậy, do ngành IT là một ngành có sự cạnh tranh nhân sự rất cao, vậy nên các công ty thường đưa ra những chính sách tốt hơn, trong đó cho phép nhân viên được nghỉ 14, thậm chí tới 18 hoặc 20 ngày / năm. Yếu tố này – bên cạnh những khía cạnh khác như lương hoặc môi trường làm việc – là một trong những thứ rất đáng cân nhắc khi bạn lựa chọn nơi làm việc. Dẫu vậy, không nhiều người để ý tới hoặc đánh giá đúng chế độ phúc lợi này khi thỏa thuận với công ty. Để mình nói cho bạn biết một vài lợi ích mà ngày phép mang lại cho bạn nhé.
Một năm có 365 ngày, thời tiết thay đổi qua 4 mùa xuân – hạ – thu – đông (hoặc 2 mùa mưa / nắng), hơn nữa việc tiếp xúc với nhiều khói bụi và không khí ô nhiễm như hiện nay, dù bạn có là người khỏe mạnh, chăm chỉ tập thể dục đi chăng nữa cũng không thể đảm bảo bạn sẽ luôn khỏe mạnh quanh năm. Những ngày nghỉ cho phép bạn được nghỉ ngơi nếu chẳng may có bị bệnh, để sớm hồi phục sức khỏe. Bạn đừng nghĩ điều này là tầm thường, hãy hỏi những người làm trong các ngành dịch vụ (ví dụ: quán ăn, vận tải, …), những người mà họ phải làm việc quanh năm bất kể ngày lễ để đảm bảo dịch vụ được thông suốt, đôi khi mắc bệnh nặng cũng phải ráng sức mà làm việc, khi đó bạn sẽ thấy những ngày phép có ích biết chừng nào.
Hay đơn giản là lấy lại năng lượng và sự thoải mái tinh thần
Ngày phép, theo đúng ý nghĩa ban đầu của nó là những ngày mà người lao động được nghỉ ngơi sau quá trình làm việc căng thẳng và mệt mỏi. Bên cạnh những lần bị bệnh, đôi khi bạn cũng sẽ cảm thấy căng thẳng hoặc mệt mỏi khi phải chạy theo những deadline, những lần làm việc thêm giờ cho kịp phát hành sản phẩm, hoặc đơn giản là bạn cảm thấy buồn vì một lí do nào đó (chuyện gia đình, chuyện người yêu), …
Mỗi khi gặp phải tình huống như vậy, đôi khi dành thời gian để tĩnh tâm hoặc nghỉ ngơi là tất cả những gì bạn cần / muốn làm. Nếu bạn có nhiều ngày phép, bạn sẽ có nhiều thời gian để nạp lại năng lượng hơn, và quan trọng là không sợ mất thu nhập cho những lần như thế.
Bạn có thể dành thời gian cho gia đình
Có nhiều người hay than thở rằng: xa quê hương để vào thành phố làm, một năm ngoài dịp lễ tết thì chẳng có mấy dịp để về quê thăm bố mẹ, thăm gia đình. Thật ra thì cũng không hẳn như thế, nếu bạn có nhiều ngày phép, bạn chỉ cần sắp xếp công việc ổn thỏa và lên kế hoạch trước để cho nhóm và công ty biết, rồi xin nghỉ phép để về quê thôi. Ai xa nhà chắc hiểu cảm giác này, người thân của mình mà một năm gặp được có dăm ba ngày tết thì đâu có đủ phải không nào?
Ngoài ra, bạn cũng có thể dành thời gian của những ngày nghỉ phép cho bọn trẻ (nếu bạn có con), hoặc đi du lịch đâu đó với người yêu để hâm nóng tình cảm. Các bạn nhỏ được nghỉ hè vài tháng, chẳng lẽ bố mẹ lại không dành được cho chúng vài ngày để đi du lịch ở đâu đó hay sao? Ai mà chẳng muốn những người con hoặc những người thân yêu của mình sẽ có nhiều kỉ niệm đáng nhớ với mình cơ chứ.
Những khoảng thời gian cho bên gia đình là vô giá.
Khám phá những điều mới mẻ
Có một anh bạn ngày xưa học chung với mình, là một người nhiệt tình trong công việc, chăm chỉ học hỏi nhiều công nghệ mới, và cũng là một người ưa thích phưu lưu khám phá. Anh bạn đó đã tận dụng những ngày được nghỉ phép để đi du lịch rất nhiều nơi, khám phá nhiều vùng đất mới với nhiều văn hóa khác nhau. Anh bạn đó cũng từng đi phượt xuyên Việt, và dự định còn đi phượt xuyên nhiều quốc gia nữa. Mình vẫn còn nhớ một câu ảnh nói với mình: tuổi trẻ chẳng lẽ chỉ toàn những ngày ngồi trong văn phòng thôi sao, như vậy thì nhạt nhẽo quá!
Có nhiều ngày phép, tức là bạn được đi chơi và khám phá nhiều hơn, trong lúc bạn đi thì bạn vẫn nhận được tiền lương của mình. Thật tuyệt phải không nào!!!
Tìm hiểu những công nghệ mới
Bạn làm việc trong lĩnh vực công nghệ, giờ lại giành những ngày nghỉ phép để tìm hiểu công nghệ nữa thì có hợp lí không nhỉ? Mới nghe qua thì có vẻ hơi vô lí, nhưng bạn nên biết là, môi trường công việc đôi khi không hoàn toàn sử dụng những công nghệ mà bạn thích. Bạn muốn tìm hiểu React, nhưng công ty lại chỉ dùng kiểu HTML với Bootstrap thông thường, bạn muốn học hỏi thêm về cách sử dụng CircleCI trong các dự án CI/CD, nhưng ở công ty bạn ít có cơ hội được tìm hiểu nó… Đôi khi trong công việc, bạn phải làm những thứ công ty cần, chứ không phải những thứ mà bạn thích.
Bạn thấy đấy, đôi khi môi trường công việc không cho cho bạn nhiều cơ hội để làm việc với những công nghệ mới, bạn có thể dùng ngày phép của mình để có thể tìm hiểu những điều mà thứ mới mẻ mà mình cảm thấy thích thú. Là một lập trình viên, bạn luôn phải ý thức được việc thường xuyên trao dồi kiến thức và kĩ năng mới. Tìm hiểu những thứ mới không chỉ giúp bạn nâng cao khả năng, mà còn mở ra cho bạn nhiều cơ hội việc làm hấp dẫn hơn nữa đó.
Luôn ý thức việc phát triển kĩ năng của bản thân
Làm một điều gì đó bản thân
Đôi khi, bạn nảy ra một ý tưởng gì đó thật thú vị trong đầu, bạn muốn thử nghiệm làm kinh doanh hay tạo ra một phần mềm thú vị nào đó cho riêng mình, bạn sẽ dành thời gian nào để thực hiện điều đó? Câu trả lời rất có thể là sử dụng những ngày nghỉ phép mà bạn có.
Nếu bạn không có thời gian để hiện thực hóa những ý tưởng của mình, thì tất cả chúng sẽ mãi mãi chỉ là những ý tưởng mà thôi. Đôi khi bạn quá bận rộn với công việc, đôi khi bạn e sợ việc nghỉ một vài ngày để thử nghiệm ý tưởng của mình sẽ không có tiền lương để sinh sống, … tất cả những điều đó đôi khi làm bạn chùn bước. Nếu bạn có nhiều ngày phép, hãy thử tận dụng nó coi sao, rất nhiều sản phẩm đột phá trên thế giới được sinh ra từ những khoảng thời gian như thế này đó.
Kết lại
Như đã trình bày ở trên, ngày nghỉ phép có thể mang lại rất nhiều lợi ích cho bạn, những lợi ích đó không chỉ ảnh hưởng tới cuộc sống và sự nghiệp của riêng bạn, mà còn có tác động lên những người xung quanh bạn nữa. Nếu được, hãy chọn lựa hoặc yêu cầu công ty cấp cho bạn nhiều ngày phép hơn, đó thực sự là một trong những lợi ích lớn mà một công ty có thể mang đến cho bạn, và đừng quên là hãy sử dụng nó một cách hợp lí nữa nhé.
Bài viết được sự cho phép của tác giả Nguyễn Trương Trung Tín
Bắt đầu với chủ đề custom layout để đẩy nhanh tốc độ vẽ màn hình của ứng dụng. Mình dự định chia chủ đề này ra làm 2-3 bài viết, với bài đầu tiên là bàn lại về kiến thức View của android cũng như view hierarchy, còn 1-2 bài sau để viết về phần optimize layout và custom view. Qua đó giúp cho các bạn tiện theo dõi về chủ đề này hơn. Vì vậy, toàn bộ bài này mình sẽ viết về kiến thức View cũng như View Hierarchy, làm sao android có thẻ vẽ lên giao diện người dùng được, vẽ như thế nào,… Nên nếu có kiến thức tốt về view và view hierarchy thì bạn có thể BỎ QUA BÀI NÀY.
Tạm định nghĩa là 1 class dùng để thế hiện các thành phần giao diện lên màn hình của thiết bị, mỗi view sẽ chiếm 1 ô hình chữ nhật trên màn hình, view chịu trách nhiệm đo kích thước, tìm vị trí, vẽ chính nó lên màn hình thiết bị nếu có lệnh gọi từ người dùng và nhận các sự kiện từ người dùng. View dùng để tạo các thành phần tương tác được với người dùng (Button, TextView, EditText,..) – Widgets. Ngoài ra ViewGroup là 1 lớp con của view dùng để đóng vai trò là các container chứa các view khác, thường thì viewgroup sẽ không hiển thị lên màn hình (RelativeLayout, LinearLayout,…) – Layouts.
IDs
Để có thể thao tác, chỉnh sữa, cài đặt cho 1 view nào đó thì developer sẽ truy cập tới view đó thông qua ID, vì vậy mỗi ID trong 1 layout sẽ phải là duy nhất, không được trùng với ID của các view khác. NẾU CÁC VIEW ĐÓ CÙNG NẰM TRONG 1 LAYOUT.
Vì hình dạng của 1 view là hình chữ nhật, nên sẽ có 2 cặp giá trị biểu diễn vị trí đặt trên màn hình của 1 view. 1 cặp biểu diễn vị trí đặt gồm 2 giá trị left (bên trái) và top (bên trên) và cặp còn lại thể hiện kích thước của 1 view gồm width (chiều rộng) và height (chiều cao). Từ 2 cặp giá trị này chúng ta sẽ biết được ví trí mà view chiếm trên 1 màn hình.
CẦN CHÚ Ý: cặp tọa độ left và top sẽ được tính theo vị trí của view cha của chính view đó, chứ không phải tính từ góc trái trên của màn hình thiết bị. Chúng ta có thể lấy các giá trị này ra thông qua các hàm getLeft(), getTop(), getWidth() và getHeight(). Ví dụ nếu getLeft() trả về là 50 thì view này sẽ được đặc cách mép trái của VIEW CHA 1 đoạn 50 pixels.
Kích thước:
Về kích thước của 1 view, sẽ có 2 cặp giá trị để biểu diễn chiều rộng và chiều cao của View. 1 cặp là Measuared Width và Measured Height, cặp còn lại mà Witdh và Height.
+ Measured Width và Measured Height: cặp giá trị này thể hiện chiều rộng và chiều cao mà view muốn được chiếm trên view cha của mình, cặp giá trị này dùng để đo lường kích thước thật của View sau khi được vẽ lên. Có thể lấy cặp giá trị này qua hàm getMeasuredWidth() và getMeasuredHeight().
+ Width và Height: cặp giá trị còn lại thể hiện độ dài và độ rộng thật sự của View trên màn hình sau khi được vẽ lên. Cặp giá trị này có thể khác giá trị với cặp measured width và measured height. Có thể lấy cặp giá trị này qua hàm getWidth() và getHeight().
View Hierarchy – cây giao diện?
Android sẽ tổ chức giao diện màn hình dưới dạng cây. Thường thì các layout sẽ là các nốt cha và các widget sẽ là các nốt con. Vả thông thường các lá sẽ là phần được thể hiện lên giao diện người dùng. Với cách tổ chức như vậy thì việc giao diện có cây quá sâu thì lúc duyệt sẽ rất tốn thời gian.
Làm sao để view có thể được vẽ lên màn hình?
Để vẽ được 1 view lên màn hình thì android sẽ thực hiện 2 bước layout và draw. Đầu tiên View phải biết được vị trí và kích thước thật sự của nó trên màn hình để được vẽ, đây gọi là bước layout. Sau đó view sẽ được vẽ lên màn hình của thiết bị – bước draw.
Layout:
Để thực hiện được việc layout này android cần làm 2 việc, có thể tạm gọi là: đo (measure) và đặt (layout).
+ Đo (Measure): Bước này sẽ tính được kích thước thật sự của 1 view trên màn hình thiết bị bằng cách gọi hàm measure(int,int). Và được duyệt theo cây giao diện từ cao xuống thấp. Sau khi xong bước measure, mỗi view của cây sẽ biết được kích thước thật sự của mình.
+ Đặt (Layout): Việc này sẽ diễn ra sau khi hàm layout(int, int, int, int) được gọi, cũng bằng cách duyệt cây giao diện từ cao xuống thấp và sử dụng các kích thước đã được đo trong bước measure ở trên để đặt các view vào các vị trí cụ thể trên màn hình.
Để yêu cầu lại bước Layout này chúng ta có thể gọi hàm requestLayout() để android tính toán lại kích thước và vị trí của các view trên màn hình
Draw:
Sau khi đã có kích thước và vị trí của từng view trong cây, android sẽ tiến hành duyệt cây để xem view nào cần vẽ lại và tiến hành vẽ. Việc vẽ phải được vẽ theo thứ tự từ cha xuống con. Nếu 1 view bạn có set background cho nó thì background sẽ được vẽ trước và view vẽ sau, với các view ngang hàng thì view nào được đặt trước thì vẽ trước.
Để gọi lại 1 view vẽ lại chính nó thì có thể gọi hàm invalidate().
Tạm kết thúc phần 1 về View và cách 1 view được vẽ lên màn hình. Bài tiếp theo mình sẽ đi đến optimize layout.
Làm thế nào để lưu trữ source code sau mỗi lần update dự án? GitHub đã ra đời để giải quyết vấn đề này! GitHub là một trong những resource phổ biến hiện nay để lưu trữ, chia sẻ mã nguồn và làm việc cùng nhau trên các dự án. Nếu bạn thấy GitHub thú vị và muốn tìm hiểu thêm, hãy đọc hết bài chia sẻ về GitHub này của TopDev. Chúng tôi sẽ giải thích GitHub là gì, các tính năng nổi bật, nó được sử dụng để làm gì và cách bắt đầu sử dụng GitHub.
Github là gì?
GitHub là một mạng xã hội đặc biệt dành cho lập trình viên, là một hệ thống quản lý dự án, lưu trữ source code, theo dõi và cộng tác trong các dự án phần mềm.
Các lập trình viên có thể clone lại mã nguồn từ một repository và Github chính là một dịch vụ máy chủ repository công cộng, mỗi người có thể tạo tài khoản trên đó để tạo ra các kho chứa của riêng mình để có thể làm việc.
Ngoài ra, GitHub là một dịch vụ nổi tiếng cung cấp kho lưu trữ mã nguồn Git cho các dự án phần mềm. Github có đầy đủ những tính năng của Git, ngoài ra nó còn bổ sung những tính năng về social để các developer tương tác với nhau.
GitHub có 2 phiên bản: miễn phí và trả phí. Với phiên bản có phí thường được các doanh nghiệp sử dụng để tăng khả năng quản lý team cũng như phân quyền bảo mật dự án.
Còn lại thì phần lớn chúng ta đều sử dụng Github với tài khoản miễn phí để lưu trữ source code.
Github cung cấp các tính năng social networking như feeds, followers, và network graph để các developer học hỏi kinh nghiệm của nhau thông qua lịch sử commit.
Nếu một comment để mô tả và giải thích một đoạn code. Thì với Github, commit message chính là phần mô tả hành động mà bạn thực hiện trên source code.
Github trở thành một yếu tố có sức ảnh hưởng lớn trong cộng động nguồn mở. Cùng với Linkedin, Github được coi là một sự thay thế cho CV của bạn. Các nhà tuyển dụng cũng rất hay tham khảo Github profile để hiểu về năng lực coding của ứng viên.
Giờ đây, kỹ năng sử dụng git và Github từ chỗ ưu thích sang bắt buộc phải có đối với các ứng viên đi xin việc.
Với GitHub các lập trình viên có thể tạo tài khoản, tải lên các tệp và quản lý các dự án lập trình.
Tuy nhiên, sức mạnh thực sự của GitHub nằm ở khả năng cộng tác giữa các người dùng, đặc biệt là các nhóm phát triển làm việc cùng nhau trên các dự án mã nguồn mở hoặc các dự án doanh nghiệp.
Hầu hết các dự án phát triển phần mềm đều được xây dựng bởi một nhóm lập trình viên. Những thành viên trong nhóm này có thể làm việc tại một cùng công ty hoặc từ xa, đồng bộ hoặc không đồng bộ. Điều này tạo ra nhiều thách thức cho việc hợp tác phát triển phần mềm, nhưng GitHub giúp quá trình này trở nên dễ dàng hơn nhờ vào một số tính năng.
GitHub tập trung mã nguồn và tài liệu trong một nơi duy nhất
GitHub cho phép tất cả mã nguồn và tài liệu dự án được lưu trữ tập trung trong các “repository” (kho lưu trữ). Điều này đảm bảo rằng bất kỳ ai muốn đóng góp vào dự án đều có quyền truy cập vào những tài nguyên cần thiết, giảm thiểu các vấn đề về truy cập thông tin. Mỗi repository thường đi kèm với các hướng dẫn cụ thể, giúp người tham gia hiểu được mục tiêu và quy tắc của dự án.
Quản lý xung đột mã
Lập trình không chỉ đơn giản là viết mã; nó còn đòi hỏi sự sáng tạo và linh hoạt. Ví dụ, hai lập trình viên có thể đang làm việc trên các phần mã khác nhau, nhưng chúng cần phải hoạt động hài hòa với nhau. Đôi khi, một phần mã có thể khiến phần mã khác bị lỗi, hoặc có thể có tác động không mong muốn lên cách mà phần khác hoạt động. GitHub giải quyết vấn đề này bằng cách hiển thị rõ ràng những thay đổi từ hai lập trình viên trước khi họ đẩy (push) mã lên “branch” (nhánh chính) của dự án. Điều này giúp phát hiện và khắc phục các lỗi tiềm ẩn trước khi chúng ảnh hưởng đến toàn bộ dự án.
GitHub giúp theo dõi và khôi phục phiên bản mã nguồn
Một trong những tính năng quan trọng nhất của GitHub là khả năng quản lý phiên bản. Điều này cho phép bạn theo dõi mọi thay đổi trong dự án và quay lại các phiên bản trước đó nếu cần. GitHub dựa trên công nghệ Git, một hệ thống kiểm soát phiên bản (version control system), giúp lưu lại các thay đổi qua từng “commit” (lần lưu mã). Bạn có thể quay lại phiên bản trước đó nếu phát hiện lỗi, hoặc theo dõi ai đã thay đổi những gì và khi nào.
Mạng xã hội cho developers
Bên cạnh đó, GitHub được coi là một mạng xã hội dành cho lập trình viên lớn nhất và dễ dùng nhất với các tính năng cốt lõi như:
Wiki, issue, thống kê, đổi tên project, project được đặt vào namespace là user.
Watch project: theo dõi hoạt động của project của người khác. Xem quá trình người ta phát triển phầm mềm thế nào, project phát triển ra sao.
Follow user: theo dõi hoạt động của người khác.
Có 2 cách tiếp cận GitHub: Tạo project của riêng mình Contribute cho project có sẵn: fork project có sẵn của người khác, sửa đổi, sau đó đề nghị họ cập nhật sửa đổi của mình (tạo pull request).
Git và GitHub – sự khác biệt
GitHub được xây dựng trên công nghệ Git, nhưng hai khái niệm này không hoàn toàn giống nhau. Git là một hệ thống quản lý phiên bản mã nguồn mở, giúp theo dõi các thay đổi trong mã nguồn, và bạn có thể sử dụng Git mà không cần GitHub. GitHub là một nền tảng dựa trên Git, cung cấp giao diện web dễ sử dụng và nhiều tính năng bổ trợ như quản lý cộng tác, lưu trữ mã nguồn từ xa, và theo dõi lỗi. GitHub mở rộng khả năng của Git bằng cách hỗ trợ làm việc theo nhóm và cộng tác từ xa một cách hiệu quả
Một vài khái niệm của Git bạn cần nắm
git: là prefix của các lệnh được sử dụng dưới CLI
branch: được hiểu như là nhánh, thể hiện sự phân chia các version khi 2 version đó có sự sai khác nhất định và 2 version đều có sự khác nhau.
commit: là một điểm trên cây công việc (Work Tree ) hay gọi là cây phát triển công việc
clone: được gọi là nhân bản, hay thực hiện nhân bản. Sử dụng để clone các project, repository trên các hệ thống chạy trên cơ sở là git, ví dụ như: bitbucket, github, gitlab, cor(1 sản phẩm mã nguồn mở cho phép người dùng tự tạo git server cho riêng mình trên vps, server),… Việc clone này sẽ sao chép repository tại commit mình mong muốn, dùng để tiếp tục phát triển. Thao tác này sẽ tải toàn bộ mã nguồn, dữ liệu về máy tính của bạn.
folk: Folk là thao tác thực hiện sao chép repository của chủ sở hữu khác về git account của mình. sử dụng và đối xử như 1 repository do mình tạo ra.
repository: Kho quản lý dữ liệu, là nơi lưu trữ các dữ liệu, mã nguồn của project.
tag: sử dụng để đánh dấu một commit khi bạn có quá nhiều commit tới mức không thể kiểm soát được.
remote: sử dụng để điều khiển các nhánh từ một repository trên git server, đối xử với các nhánh trên remote tương tự như đối xử với các nhánh trên local
diff: So sánh sự sai khác giữa phiên bản hiện tại với phiên bản muốn so sánh, nó sẽ thể hiện các sự khác nhau
.gitignore: file mặc định của git sử dụng để loại bỏ (ignore) các thư mục, file mà mình không muốn push lên git server
Lịch sử của GitHub
GitHub được viết bằng Ruby on Rails và Erlang do Tom Preston-Werner, Chris Wanstrath, và PJ Hyett phát triển trang web được đưa ra và chạy chính thức vào tháng 4 năm 2008.
Tính đến thời điểm tháng 3 năm 2018 Github đang là dịch vụ máy chủ lưu trữ các mã nguồn lập trình lớn nhất thế giới. Với hơn 25 triệu người dùng và hơn 80 triệu mã nguồn dự án, Github đã trở thành một phần không thể thiêu đối với cộng đồng phát triển mã nguồn mở và cộng đồng lập trình viên trên toàn thế giới.
Lợi ích của Github đối với lập trình viên
Quản lý source code dễ dàng
Khi bạn tạo một repo, toàn bộ source code của repo đó được lưu trên GitHub. Tại đây, bạn có thể coi lại quá trình mình đã làm việc thông qua các comment sau mỗi lần commit. Và cái hay ở đây, là nhiều người có thể cùng làm một repo.
Lợi ích đầu tiên, chính là bạn biết được ai đã commit và commit cái gì. Tiếp theo, source của bạn có thể phát triển theo nhiều nhánh. Nguyên tắc làm việc với các nhánh như thế này: Bạn có thể rẽ nhiều nhánh để phát triển project. Nhưng cuối cùng, bạn phải merge lại vào nhánh MASTER để ra được project hoàn chỉnh.
Khi có nhiều member cùng thực hiện một dự án thì khá là phức tạp để theo dõi revisons – ai thay đổi cái gì, lúc nào và mấy cái files đó được stored ở đâu. Đừng lo vì GitHub đã tính đến chuyện này giúp bạn, bằng cách luôn lưu lại những thay đổi bạn đã push lên repository. Cũng tương tự với Microsoft Word hay Google Drive, bạn có một lịch sử phiên bản để phòng trường hợp các phiên bản trước đó bị mất hay không được lưu.
Markdown
Markdown là một cách định dạng text trên web. Bạn có thể chỉnh sửa cách hiển thị của document, format từ như định dạng in đậm hay in nghiêng, thêm hình và tạo list những thứ bạn có thể làm với Markdown. Hầu hết, Markdown chỉ là đoạn text đơn thuần với những ký tự đặc biệt chèn vào, như # hay *. Trong GitHub thì bạn có thể sử dụng Mardown ở những nơi: Git, Comments tại Issues và Pull Requests, các file có đuôi .md hay .markdown extension.
Chẳng thể phủ nhận những lời hay ý đẹp bạn viết trong CV là cần thiết. Nhưng Source code luôn là minh chứng tốt nhất để thể hiện bạn là developer thực thụ. Có thể nói, 1 phần GitHub “nho nhỏ” trong CV có thể đánh bóng vị trí của bạn, nổi bật hơn những ứng cử viên khác. Đối với nhà tuyển dụng, GitHub cũng giống như một chiếc máy liar-detech – phân biệt real developer với những kẻ “faker”.
Hãy đầu tư cho mình một tài khoản Github thật ấn tượng và đưa đường dẫn vào trong CV, chẳng nhà tuyển dụng nào lại dại dột mà bỏ qua bạn đâu.
Có rất nhiều công ty lớn trên thế giới xem đây là một yêu cầu trong quy trình tuyển dụng của họ. Nếu bạn có nhiều đóng góp cho cộng đồng hoặc có nhiều sản phẩm trên Github, sẽ là một lợi thế rất lớn so với các ứng viên khác. Vì bằng cách đăng tải các project của mình lên đây, bạn đã tạo cho mình một profile cá nhân vô cùng đáng tin cậy.
Vì khi nhìn vào đó, nhà tuyển dụng sẽ biết được ngay thế mạnh của bạn là gì, và khả năng coding của bạn thế nào.
Github giúp cải thiện kỹ năng code, thậm chí là tracking bug
Có hàng ngàn hàng vạn cách để học, học trên Github sẽ là một ý kiến không tồi trong thời đại này. Với hàng vạn open source projects, hàng trăm ngàn contributors, hàng tỉ commit mỗi ngày thì chỉ bằng việc xem. So sánh, học tập từ những thay đổi đó đã đem lại cho bạn hàng tá điều hay để cải thiện kỹ năng code của bản thân mình.
“Bug tracking” là một tính năng được GitHub tích hợp vào để đơn giản hóa quá trình “tìm và diệt bọ”. Để hiểu được quy trình thì những gì bạn cần làm là mở dashboard của từng project lên và filter các thông tin. Sau đó, các câu hỏi sẽ được hệ thống, sắp xếp theo mức độ phổ biến, thời gian update hay tương tại. Phần mềm này cũng có giao diện khá mượt nên luôn được xếp hạng cao trong cộng đồng IT dev.
Github là một kho tài nguyên tuyệt vời
Với chức năng Explore, bạn có thể theo dõi, tìm kiếm những open source projects theo đúng technology pattern mà bạn ưa thích. Github hỗ trợ code search không kể nó ở dưới dạng một project riêng biệt hay là website. Ngoài ra, nền tảng này cũng có SEO khá tốt nên người dùng có thể tìm kiếm bất kỳ code string nào được chia sẻ public.
Github Action
Trên server của Github có những workflow scripts chạy tự động. Dev có thể dùng chúng để phản hồi các events trên repositories hoặc thực hiện vài action. Ví dụ như tôi có viết một cái tiện ích nho nhỏ, Autotagger – GitHub Marketplace, sẽ tự động tạo git tafs khi mà số phiên bản của package.json thay đổi. Nhìn thì đây chỉ là hành động nhỏ nhưng sẽ có tác động rất lớn khi phải truy tìm code ngược về bản phát hành, và bớt đi một cơn “nhức đầu” cho các project maintainers đó chứ.
Github Package Registry
Cái package registry này cho phép lập trình viên duy trì distribution registries của họ, bao gồm npm, docker, maven, nuget và Ruby gems.
Đừng ngần ngại mà không tạo ngay cho mình một tài khoản Github. Tạo những project của riêng mình và chia sẻ với mọi người, hoặc bạn có thể thoải mái fork một project của một open source nào đó. Tạo pull request hoặc issues nếu như tìm được lỗi, cần support.
Mở rộng mối quan hệ
Gặp gỡ những dev mới: Vài ngàn developer toàn cầu đang tham gia mạng lưới rộng lớn của GitHub để chia sẻ kinh nghiệm của họ cũng như những ý tưởng rất đỉnh.
Chia sẻ kinh nghiệm bản thân: Git cho phép user share code, text fragments hay bất kỳ thông tin nào với các dev khác. Do đó bạn có thể dùng nó để trao đổi text, hay gists work như git repositories, từ đó tách ra và update các phiên bản đó.
Bắt đầu sử dụng GitHub
Dưới đây là các bước cơ bản để bắt đầu sử dụng GitHub:
Bước 1: Tạo tài khoản GitHub Truy cập GitHub và đăng ký tài khoản miễn phí.
Bước 2: Tạo một kho lưu trữ (Repository) mới Kho lưu trữ là nơi bạn lưu trữ mã nguồn và các tệp liên quan đến dự án của mình. Để tạo kho lưu trữ mới:
Nhấp vào biểu tượng dấu cộng (+) ở góc trên bên phải và chọn “New repository”.
Điền thông tin cần thiết như tên, mô tả và thiết lập quyền riêng tư (công khai hoặc riêng tư).
Bước 3: Bạn cần cài đặt Git trên máy tính để có thể tương tác với GitHub từ dòng lệnh. Tải Git từ Git downloads và cài đặt
Bước 4: Kết nối Git với GitHub Mở terminal hoặc command prompt và cấu hình Git với thông tin tài khoản GitHub của bạn:
Bước 9: Sử dụng GitHub Desktop (Tùy chọn) Nếu bạn không thích làm việc với dòng lệnh, GitHub Desktop là một ứng dụng giao diện người dùng dễ sử dụng. Tải và cài đặt GitHub Desktop từ GitHub Desktop.
Bước 10: Tạo và quản lý các nhánh (Branches) Nhánh giúp bạn làm việc trên các tính năng hoặc bản sửa lỗi mới mà không ảnh hưởng đến mã nguồn chính. Để tạo một nhánh mới:
git checkout -b feature-branch
Bước 11: Push các thay đổi lên GitHub Sau khi hoàn thành các thay đổi, push lên kho lưu trữ GitHub:
git push origin feature-branch
Qua bài viết của TopDev, hi vọng đã giúp bạn hiểu hơn về GitHub và các tính năng cũng như cách sử dụng GitHub. Chúc bạn có một khởi đầu suôn sẻ với GitHub!
Bài viết được sự cho phép của tác giả Trần Duy Thanh
Kotlin cho Android là một plug-in giúp ta tăng tốc lập trình Android. Vì sự bất tiện của việc truy suất các control trên giao diện nên plug-in Kotlin ra đời. Cộng đồng Kotlin rất mới mẻ, tính tới 12h:00 khuya ngày 19/03/2017 thì có khoảng 600 ngàn lập trình viên và cộng đồng này ngày càng tăng chóng mặt. Và các công ty hiện nay cũng bắt đầu tuyển dụng lập trình viên Android với Kotlin.
Kotlin là một ngôn ngữ lập trình, Tui sẽ có những bài học riêng về ngôn ngữ này để áp dụng cho lập trình Android với Kotlin để tăng tốc lập trình. Tuy nhiên trong bài học này Tui chỉ hướng dẫn cách nhanh nhất để đưa plug-in tuyệt vời này vào ứng dụng Android.
Những ai lập trình android thường chán ngán với hàm findViewById để truy suất tới các control trên giao diện, hoặc là phải sử dụng Data Binding để mapping model-view. Kotlin giúp ta cách dễ nhất để có thể tương tác trực tiếp tới các Id của các Control trên giao diện (tương tự như C# mà ta lập trình trong Visual Studio)
cuối cùng build.gradle trong Project level ta có như sau:
Tiếp tục vào build.gradle trong Module level:
Ta bổ sung thêm:
apply plugin: 'kotlin-android-extensions'
Cuối cùng ta có build.gradle trong Module level:
Sau cùng bấm vào nút Sync Now:
Bước cuối cùng ta sẽ chuyển MainActivity (coding java) thành MainActivity (coding kotlin ) bằng cách vào menu Code/ chọn Convert Java file to Kotlin File:
Sau khi bấm Convert Java File to Kotlin File, ta chờ chút xíu để chương trình chuyển đổi java class thành kotlin class:
Kết quả sau khi chuyển đổi:
Bây giờ ta có thể dễ dàng tương tác trực tiếp các control trên giao diện theo ngôn ngữ lập trình Kotlin như sau:
Bạn quan sát đấy, nó truy suất vô cùng dễ dàng, ngắn gọn (dĩ nhiên bạn phải biết lập trình bằng ngôn ngữ Kotlin cho android, Tui sẽ sắp xếp giảng khóa học này cho các bạn sau). Kết quả thực hiện:
Giờ muốn thêm một màn hình Activity với Kotlin hay là tạo Class Kotlin thì ta chọn Kotlin Activity hoặc Kotlin File/ Class , Android Studio sẽ tự động chuyển Activity qua dạng kotlink luôn, và phần mở rộng của Kotlin là .tk nhé:
Bài viết được sự cho phép của tác giả Nguyễn Hữu Khanh
Serialization là một khái niệm giúp chúng ta có thể chuyển đổi trạng thái của một Java object thành một định dạng nào đó để Java object này có thể được lưu trữ ở đâu đó và sau đó, nó sẽ được sử dụng bởi một tiến trình khác.
Thông thường, khi sử dụng Serialization, Java object của chúng ta sẽ được chuyển đổi qua byte streams và chúng ta có thể lưu byte stream này trong bộ nhớ, trên ổ đĩa, truyền qua mạng đến một server nào đó hoặc cũng có thể lưu chúng vào database.
Và khi một tiến trình khác sử dụng một Java object đã được Serialization, nó sẽ chuyển đổi định dạng đã Serialization về trạng thái của Java object ban đầu. Nhờ vậy, tiến trình đó có thể sử dụng lại Java object của chúng ta.
Để cho một object có thể sử dụng Serialization được, chúng ta phải cho object của chúng ta hiện thực một interface với tên gọi là java.io.Serializable. Interface này không có bất kỳ một phương thức nào cần hiện thực cả các bạn ạ!
Để các bạn có thể hiểu rõ hơn, mình sẽ làm một ví dụ để minh chứng những điều mình vừa nói nhé!
Ví dụ ở đây, mình có một đối tượng là Student:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
packagecom.huongdanjava.javaexample;
publicclassStudent{
privateStringname;
privateintage;
publicStringgetName(){
returnname;
}
publicvoidsetName(Stringname){
this.name=name;
}
publicintgetAge(){
returnage;
}
publicvoidsetAge(intage){
this.age=age;
}
}
Vì mình muốn sử dụng Serialization nên mình sẽ hiện thực interface Serializable cho đối tượng Student như sau:
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
packagecom.huongdanjava.javaexample;
importjava.io.Serializable;
publicclassStudentimplementsSerializable{
privatestaticfinallongserialVersionUID=1L;
privateStringname;
privateintage;
publicStringgetName(){
returnname;
}
publicvoidsetName(Stringname){
this.name=name;
}
publicintgetAge(){
returnage;
}
publicvoidsetAge(intage){
this.age=age;
}
}
Như các bạn thấy, mình đã thêm một biến tên là serialVersionUID trong object Student của mình. Mục đích của biến này là để chắc chắn trước và sau khi chuyển đổi, lớp Student của chúng ta là một đấy các bạn.
OK, bây giờ chúng ta sẽ viết code để chuyển đổi đối tượng Student và lưu byte streams của nó vào một tập tin nào đó xem thử nhé!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
packagecom.huongdanjava.javaexample;
importjava.io.FileOutputStream;
importjava.io.IOException;
importjava.io.ObjectOutputStream;
publicclassSerializationExample{
publicstaticvoidmain(String[]args){
// Create Student object
Student student=newStudent();
student.setName(“Khanh”);
student.setAge(30);
// Use FileOutputStream to save the Student object into a file
Một lập trình viên 30 tuổi sẽ có những suy nghĩ gì về tương lai? Những định hướng nào sẽ là sự lựa chọn phù hợp? Đó là những tâm sự chung của nhiều anh em lập trình chạm ngưỡng 30. Dựa vào tình hình thực tế, TopDev sẽ phân tích những lối đi riêng mà dân lập trình lựa chọn. Đó là chặng đường kế tiếp họ sẽ trải qua trên hành trình nghề nghiệp của mình.
Sau 30, có lẽ bạn sẽ nhận ra nhiều điều. Hết hứng thú với việc học và trải nghiệm lập trình? Lập trình dường như trở thành một công việc để nuôi sống bản thân? Vậy sự hứng thú trong nghề nghiệp liệu có tồn tại? Có phải là do sự xáo trộn hay những áp lực còn bủa vây chăng?
Trải qua nhiều biến thăng trầm giai đoạn 20 – 30 tuổi, đây là lúc phù hợp nhất để dân lập trình có một định hướng rõ ràng và lâu dài. Tất nhiên, song hành cùng đó, niềm vui công việc rất quan trọng.
Nhiều anh em lập trình họ chọn cách tiếp tục code để phát triển khả năng, nâng cao năng lực của bản thân. Họ chọn đó là công việc mà họ sẽ tiếp tục trải nghiệm. Một người bạn của tôi đã ngoài 40, anh ấy giờ đây xem việc code là một người bạn hằng ngày. Lúc này có lẽ động lực về niềm vui thể hiện rõ và những áp lực không còn quá lớn.
Lối rẽ từ sự am hiểu chuyên môn lập trình – Hướng đi phổ biến định hình một chuyên gia
Đã đến lúc có một chuyển mình mới cho sự nghiệp. Đó có thể là sự liều lĩnh. Nhưng, sự dấn thân của thời tuổi trẻ đã cho họ lối tư duy, nhận thức sâu sắc; giúp họ đủ khả năng tạo ra những điều mới mẻ hơn. Dựa vào những am hiểu về chuyên môn, họ lựa chọn một phân nhánh nhỏ và tập trung khai thác về nó.
Chẳng hạn khi ở ngưỡng 30, bạn lựa chọn trải nghiệm F&B. Với hơn 20 năm kinh nghiệm, bạn có đầy đủ những hiểu biết để đối mặt với sự lựa chọn mới. Không quá khó để bạn thuần thục những công việc; tiếp cận, đào sâu khía cạnh công việc này. Từ lập trình, phần mềm tích điểm cung ứng cho chuỗi hệ thống; việc lắp đặt, xử lý cấu hình,…bạn đều nắm rất rõ.
Hoặc bạn quyết định sẽ chuyển hướng sang fullstack. Những vấn đề về thống kê biểu đồ; phân tích tính hiệu quả, phán đoán, đưa ra các quyết định mua – bán là chuyện nhỏ đối với bạn.
Điều quan trọng là bạn cần phát huy hết khả năng và áp dụng nó vào đúng mục đích phát triển tiếp theo của mình.
Hãy nhớ, thời gian sau 30 tuổi là lúc bạn sống với những hướng đi mới. Bạn tìm tòi, nghiên cứu, theo dõi sự thay đổi và tạo ra những cái mới xoay quanh lối rẽ về chuyên môn. Đó không còn là một công việc đơn thuần nữa. Vì giờ đây, bạn đang thực hiện công việc của một chuyên gia công nghệ thực thụ.
Xây dựng thương hiệu lập trình riêng – Khẳng định dấu ấn bản thân
Như đã chia sẻ từ trước, anh em lập trình họ đủ sức dẫn đầu về xu thế. Tuy nhiên, một số lại lựa chọn một định hướng khác hơn. Đó là tập trung vào việc tạo nên thương hiệu riêng nhằm khẳng định dấu ấn bản thân mình. Họ quyết định sáng lập ra các công ty, doanh nghiệp – những đứa con tinh thần mà họ ấp ủ, dành nhiều tâm huyết. Nhiều người nghĩ rằng, liệu họ lập công ty vào thời điểm này có quá trễ?
Họ đều là những chiến binh với đầy đủ tố chất, bản lĩnh. Vấn đề chỉ là ở thời gian. Bạn cần hiểu để mở một công ty đòi hòi sự am hiểu về tất cả mọi thứ. Từ cơ cấu vận hành, am hiểu nhiều lĩnh vực khác nhau; marketing, sales, tư vấn doanh nghiệp, xây dựng các hệ thống, theo dõi và hướng dẫn, lãnh đạo đội ngũ, quản lý các chu trình,… họ đều phải nắm bắt và đảm đương tốt.
Ngoài ra, nếu so về trình độ hiện tại, họ đủ sức đưa ra những lời khuyên phát triển về mặt hệ thống; tầm nhìn chiến lược, cách tổ chức vận hành cho một doanh nghiệp. Họ còn giỏi trong việc kết nối những nhân tố xuất sắc. Điều này góp phần tạo ra một doanh nghiệp với tổng thể toàn diện. Sứ mệnh và sự phát triển chung của tổ chức có thực hiện được hay không là do chính họ cùng những người cộng sự của mình.
Đào tạo và dẫn dắt – Truyền lửa đam mê công nghệ
Nếu không chọn code chuyên nghiệp; thực hiện nghiên cứu như một chuyên gia đầu ngành; theo đuổi mục tiêu phát triển doanh nghiệp, anh em lập trình sau 30 tuổi hoàn toàn có thể lựa chọn con đường này. Đó là đào tạo lĩnh vực giáo dục công nghệ.
Tiếp tục học lên cao và trở về chốn giảng đường là lựa chọn của nhiều anh em. Bạn có thể đào tạo, dẫn dắt các bạn sinh viên, những người đang có niềm yêu đến gần hơn với công nghệ. Hoặc các khóa học online – trực tuyến cũng là sự lựa chọn hoàn hảo.
Ngoài ra, bạn có tham gia cộng tác làm diễn giả, khách mời – cố vấn chuyên môn cho các chương trình công nghệ có quy mô lớn, được tổ chức thường niện như Vietnam Mobile Day, Vietnam Web Summit,…
Nhiệm vụ của bạn là truyền tải cho họ các kiến thức nền tảng từ cơ bản đến nâng cao. Chia sẻ với họ về khó khăn, áp lực tồn tại khi họ chấp nhận theo đuổi ngành học này. Tất nhiên, với tư cách là từng trải, bạn sẽ có những lời khuyên chân thành và phù hợp nhất. Đồng thời, cũng tạo ra động lực thúc đẩy đam mê , nhiệt huyết trong chính họ.
Về phía những người trẻ đang muốn dấn thân vào con đường lập trình, hãy chọn lựa thật thông minh. Cụ thể, một người thầy với bề dày sự trải nghiệm sẽ cho bạn những kiến thức chuyên sâu nhất. Hãy lựa chọn những ngôn ngữ lập trình thuộc lớp “đàn anh” như Java, PHP,… để học. Bạn cần hiểu và tiếp cận với các nguồn tư liệu chuyên sâu ngay từ những nền tảng cơ bản nhất.
Lời kết
Mỗi sự lựa chọn đều có giá trị riêng của nó. Ở ngưỡng 30, mọi anh em lập trình đã có cho mình nhiều trải nghiệm khác nhau. Đây cũng là khoảng thời gian đẹp nhất để bắt đầu chuyển mình thực hiện những mục tiêu mới. TopDev hi vọng những phân tích từ bài viết đã cho anh em lập cũng như những ai yêu thích ngành lập trình nói riêng có những hình dung chân thật về bức tranh cuộc sống ngành lập trình ở tuổi 30. Mong rằng mọi người sẽ tìm được cho mình một hướng đi đúng đắn và ngày càng thăng tiến hơn trong sự nghiệp.
Để trở thành một lập trình viên thì không quá khó, nhưng để trở thành một lập trình viên giỏi thì không phải dễ. Lập trình viên giỏi thì sẽ cần nhiều kỹ năng và hơn hết kỹ năng không thể thiếu đó là “search google”. Với lượng kiến thức khổng lồ về lập trình thì không ai có thể nhớ hết được mọi thứ, còn những người mà nhớ được thì họ không phải là người nên tôi không để cập đến ở đây. Vì vậy kỹ năng về tìm kiếm thông tin rất cần thiết nên bài viết này tôi sẽ dựa vào những kiến thức của tôi sẽ bày vẽ cho các bạn những cách tôi thường dùng, tôi không tự nhận mình là một lập trình viên giỏi nên tôi không dám dạy bảo gì cả mà chỉ chia sẻ về nó mà thôi.
1. Vì sao kỹ năng search google lại quan trọng?
Khi code gặp một vấn đề nào đó hoặc bạn quên một cú pháp nào đó thì việc search google đúng từ khóa giúp bạn tìm kiếm nhanh chóng thông tin, tiết kiệm được nhiều thời gian để làm những việc khác. Trường hợp nếu bạn tìm không đúng sẽ dẫn đến việc bạn tiêu tốn hết nhiều thời gian và dẫn đến trễ deadline, khi đi làm việc tuân thủ deadline rất là quan trọng.
2. Nguyên nhân newbie thường không biết cách “search google”
Trên các group IT tôi hay thấy những câu hỏi mà search google một chút là sẽ ra ngay (đứng trên là một người có kinh nghiệm như tôi). Tuy nhiên những người mới lập trình hoặc những bạn mới đi làm thường sẽ không biết cách search google vì các bạn không đủ kiến thức để hiểu vấn đề của mình là gì và nếu search ra đúng chỗ nhưng cũng không biết nó là cái gì, áp dụng vào ra sao.
VD1 : Vào một ngày đẹp trời tôi đang code javascript xử lý một array và tôi muốn xóa một phần tử trong array theo vị trí index trong mảng, nhưng tôi đã quên mất cách làm. Tôi liền mở google và gõ “javascript delete element in array” và google search được hàng ngàn kết quả. Tôi liền nhấn vào link đầu tiên và tìm ra được kết quả mong muốn.
Đọc ví dụ bên trên thấy dễ vler phải không, đúng là rất dễ nhưng chỉ khi mình tìm được từ khóa, tôi sẽ chỉ cho các bạn biết làm sao tôi tìm được từ khóa này. Đầu tiên tôi đang muốn làm gì? Hiện tại tôi đang muốn “xóa phần tử trong một mảng của javascript”. Tôi sẽ cho bạn một cú pháp các bước search như sau.
1. Cú pháp: Tên ngôn ngữ + nội dung
2. Khi đó tôi sẽ có từ khóa như sau : javascript + xóa phần tử trong một mảng.
3. Tiếp theo sẽ đem nội dung lên google dịch ta được : javascript delete element in array. Và đem từ khóa này đi search thôi
VD2 : Tôi đang code java về việc đảo ngược các phần tử trong một list có sẵn. Tôi lên google dịch vào gõ “đảo ngược list” tôi được một chuỗi là “reverse the list” gắn với từ khóa “java” nữa tôi được một chuỗi ” java reverse the list”. Quá dễ phải không nào.
Túm cái váy lại là khi search google thì các bạn nên search theo tiếng anh vì cộng đồng lập trình trên thế giới đều sử dụng tiếng anh là chủ yếu, nếu bạn search theo tiếng việt nhiều khi sẽ không ra kết quả. Và hôm nay tôi cũng xin chúc ai đọc bài viết này năm mới gặp nhiều may mắn. Xin chân thành cám ơn đã quan tâm theo dõi, nếu thấy hay hãy like fanpage ở bên cạnh và share nhé
Trên wiki: DRY là nguyên tắc bạn đừng viết lặp lại một đoạn code
Bạn: Ok, những phần code bị trùng mình sẽ chuyển thành abstraction
Giải pháp trông có vẻ hiển nhiên đúng, nhưng không, abstraction của bạn thường là sai.
Đây là lý do tại sao:
Bạn thì code bị duplicate
Bạn đưa đoạn duplicate ra thành một abstract (method, class)
Bạn thay thể toàn bộ phần duplicate bằng abstraction mới
Bạn nghĩ code đã hoàn hảo
Thời gian trôi đi
PM đưa thêm các yêu cầu mới.
Bạn bắt đầu hiện thực các yêu cầu mới
Với yêu cầu mới này, bạn phải chỉnh sửa vài đoạn trong abstraction, if...else các kiểu, đổi parameter, abstraction của chúng ta có thể đưa ra những action khác nhau theo những điều kiện khác nhau
Giờ abstraction của trọng sẽ cho ra những kết quả khác nhau trên những case khác nhau
Yêu cầu mới lại đến, thêm parameter tiếp, thêm câu điều kiện tiếp
Và giờ đây đoạn code của bạn không còn dễ maintain, nói thẳng ra là một đống hầm bà lằng khó nuốt
Chúc mừng, bạn đã bị over engineer và gây ra một abstract quá đỗi phức tạp
Vậy thì sao? Hãy thử WET (Write everything twice)
WET
Như cách chơi chữ đã thể hiện, nó là trường phái đối nghịch hoàn toàn với DRY, khi bắt đầu viết code, bạn sẽ không thể nào lường trước được mọi yêu cầu, mọi tính năng. Vì thế đừng vội vàng áp dụng abstraction
Bạn hãy nhớ
Cái giả phải trả cho duplicate vẫn rẻ hơn nhiều cho một abstract viết sai
Ví dụ bạn viết một ứng dụng, bạn dựng ra một component tên Button để sử dụng nhiều nơi, nghe rất hợp lý. Một yêu cầu mới xuất hiện, ở trang landing page họ muốn có một nút bấm rất fancy và không giống với tất cả những nút bấm trước đây.
Ok, thay đổi cũng nhỏ thôi, chỉ cần thêm tí điều kiện if..else, 90% phần code là của Button và 10% code là của FancyButton
Sự thật đáng buồn là sẽ có rất nhiều những thay đổi như thế xuất hiện và khả năng rất cao là bạn không đủ kinh nghiệm để có hiện thực những abstraction đủ dễ hiểu, dễ maintain.
Lời khuyên? Copy copy code đó ra, đừng ngần ngại
Bạn thấy quan điểm của mình bậy quá bậy!, bạn có thể tham khảo thêm quan điểm của Dan Abramov
Bài viết được sự cho phép của BBT Tạp chí Lập trình
Test coverage là một chỉ số quan trọng trong kiểm thử phần mềm về chất lượng và hiệu quả. Bài viết này chúng ta sẽ tìm hiểu khái niệm test coverage, kỹ thuật, số liệu và cách cải thiện nó.
Thế giới đã chứng kiến một số sự kiện thảm khốc do các lỗi phổ biến trong phần mềm. Một sự kiện như vậy, mà cá nhân tôi nhớ lại, là việc khai trương Heathrow Terminal 5, Vương quốc Anh vào năm 2008.
Các kỹ sư đã khá tự tin về hoạt động của hệ thống xử lý hành lý của khách hàng do đã trải qua quá trình kiểm thử nghiêm ngặt . Tuy vậy hệ thống xử lý hành lý không thể đối phó khi đối mặt với một số tình huống thực tế; dẫn đến việc tắt hoàn toàn hệ thống. Trong 10 ngày sau đó, khoảng 42.000 hành lý không thể đi cùng chủ sở hữu và hơn 500 chuyến bay đã bị hủy.
Tất cả điều này là do các kỹ sư không thực hiện được phạm vi thử nghiệm của các tình huống có thể xảy ra trong thực tế.
Trong bài viết này, chúng ta sẽ thảo luận về tất cả các khía cạnh của test coverage – phạm vi kiểm thử, và cách nó ảnh hưởng trực tiếp đến việc sản xuất, cho dù đó là phát triển phần mềm tùy chỉnh hoặc kiểm thử phần mềm.
Test coverage được định nghĩa là một kỹ thuật xác định xem các trường hợp thử nghiệm có thực sự bao trùm mã ứng dụng hay không và bao nhiêu mã được thực hiện khi chạy các trường hợp thử nghiệm đó.
Nếu có 10 yêu cầu và 100 thử nghiệm được tạo và nếu 90 thử nghiệm được thực hiện thì phạm vi thử nghiệm là 90%. Bây giờ, dựa trên số liệu này, người kiểm tra có thể tạo các trường hợp kiểm tra bổ sung cho các kiểm tra còn lại. Dưới đây là một số lợi thế của test coverage.
Bạn có thể xác định các lỗ hổng trong yêu cầu, trường hợp kiểm tra và lỗi ở cấp độ sớm và cấp mã.
Bạn có thể ngăn ngừa rò rỉ lỗi không mong muốn bằng cách sử dụng phân tích test coverage.
Test coverage cũng giúp kiểm tra hồi quy, ưu tiên trường hợp kiểm thử, tăng cường bộ kiểm thử và tối thiểu hóa bộ kiểm thử.
Statement Coverage đảm bảo rằng tất cả các dòng lệnh trong mã nguồn đã được kiểm tra ít nhất một lần. Nó cung cấp các chi tiết của cả hai khối mã được thực thi và thất bại trong tổng số các khối mã.
Hãy để hiểu nó với ví dụ về sơ đồ sau. Trong ví dụ đã cho, đường dẫn 1A-2C-3D-E-4G-5H này bao gồm tất cả các câu lệnh và do đó nó chỉ yêu cầu trên một trường hợp thử nghiệm để đáp ứng tất cả các yêu cầu. Một trường hợp thử nghiệm có nghĩa là một Statement Coverage.
Trong mã nguồn phức tạp, một đường dẫn không đủ để bao gồm tất cả các câu lệnh. Trong trường hợp đó, bạn cần viết nhiều trường hợp kiểm tra để bao quát tất cả các câu lệnh.
Ưu điểm:
Nó có thể được áp dụng trực tiếp vào mã đối tượng và không yêu cầu xử lý mã nguồn.
Nó xác minh những gì mã nguồn viết được dự kiến sẽ thực thi và không thực thi
Nhược điểm:
Nó chỉ bao gồm các điều kiện “true” của mã nguồn.
Statement Coverage hoàn toàn không quan tâm với các toán tử logic (|| và &&)
Decision/Branch coverage
Các nhà phát triển không thể viết mã trong một chế độ liên tục, tại bất kỳ điểm nào họ cần phân nhánh mã để đáp ứng các yêu cầu chức năng. Sự phân nhánh trong mã thực sự là một bước nhảy từ điểm quyết định này sang điểm khác. Branch coverage kiểm tra mọi đường dẫn có thể hoặc chi nhánh trong mã được kiểm thử.
Branch coverage có thể được tính bằng cách tìm số đường dẫn tối thiểu để đảm bảo rằng tất cả các cạnh đã được che phủ. Trong ví dụ đã cho, không có đường dẫn duy nhất đảm bảo vùng phủ sóng của tất cả các cạnh cùng một lúc.
Ví dụ: nếu bạn đi theo đường dẫn 1A-2C-3D-E-4G-5H này bao gồm số cạnh tối đa (A, C, D, E, G và H), bạn vẫn sẽ bỏ lỡ hai cạnh B và F. Bạn cần đi theo một đường dẫn khác 1A-2B-E-4F để che hai cạnh còn lại. Bằng cách kết hợp hai con đường trên, bạn có thể đảm bảo đi qua tất cả các con đường. Đối với ví dụ này, phạm vi kiểm thử chi nhánh của chúng tôi là 2 vì chúng tôi đang theo hai đường dẫn và nó yêu cầu hai trường hợp thử nghiệm để đáp ứng các yêu cầu.
Ưu điểm:
Nó bao gồm cả các điều kiện đúng và sai không có khả năng được gọi trong statement coverage.
Nó đảm bảo tất cả các nhánh được kiểm thử.
Nhược điểm:
Nó bỏ qua các nhánh trong các biểu thức Boolean xảy ra do các toán tử ngắn mạch.
Path Coverage
Path Coverage là một phương pháp kiểm tra cấu trúc liên quan đến việc sử dụng mã nguồn của chương trình để tìm mọi đường dẫn thực thi có thể.
Path Coverage đảm bảo phạm vi của tất cả các đường dẫn từ đầu đến cuối. Trong ví dụ này, có bốn đường dẫn có thể kiểm thử:
1A-2B-E-4F
1A-2B-E-4G-5H
1A-2C-3D-E-4G-5H
1A-2C-3D-E-4F
Ưu điểm:
Nó giúp giảm các test thừa.
Cung cấp phạm vi kiểm tra cao vì nó bao gồm tất cả các câu lệnh và các nhánh trong mã.
Nhược điểm:
Đánh giá mỗi đường dẫn là một thách thức cũng như tốn thời gian vì một số đường dẫn theo cấp số nhân của số nhánh. Ví dụ, một hàm chứa 10 câu lệnh if có 1024 đường dẫn để kiểm tra.
Đôi khi nhiều đường dẫn không thể thực hiện do mối quan hệ của dữ liệu.
Condition Coverage
Condition Coverage sẽ kiểm tra phạm vi điều kiện nếu cả hai kết quả (có nghĩa là “true” hay “fail”) của mọi điều kiện đã được thực hiện. Kết quả của điểm quyết định chỉ liên quan để kiểm tra các điều kiện. Nó đòi hỏi hai trường hợp thử nghiệm cho mỗi điều kiện cho hai kết quả.
Số liệu Test Coverage là gì?
Số liệu test coverage đo lường nỗ lực kiểm thử và giúp trả lời câu hỏi “Bao nhiêu phần của ứng dụng đã được kiểm thử? Số liệu test coverage có thể được chia thành ba phần: số liệu cấp mã, số liệu kiểm tra tính năng và số liệu cấp độ ứng dụng.
Có nhiều công thức khác nhau để tính toán các kết quả này và tạo báo cáo mức độ bao phủ kiểm thử.
Số liệu cấp mã
Tỷ lệ phần trăm testcase được thực hiện
Nó cũng được gọi là các bài kiểm thử được thực hiện được tính bằng tỷ lệ phần trăm của các testcase được thực hiện / thực hiện trong tổng số các testcase.
Ưu điểm là bạn có được cái nhìn tổng quan về tiến trình kiểm thử bằng cách đếm số lần testcase đã pass và fail.
Nhược điểm là việc đếm các testcase pass không liên quan đến chất lượng của các testcase đó. Ví dụ, một số testcase có thể pass vì nó kiểm tra điều kiện đơn giản hoặc một số lỗi trong mã của testcase đó dẫn đến testcase đó không hoạt động đúng theo yêu cầu.
Số liệu kiểm tra tính năng
Độ bao phủ yêu cầu
Độ bao phủ yêu cầu được sử dụng để xác định các trường hợp kiểm thử bao gồm các yêu cầu phần mềm được xử lý tốt như thế nào. Đối với điều đó, bạn chỉ cần chia số lượng yêu cầu được bao phủ trên tổng số yêu cầu trong phạm vi cho một sprint, phát hành hoặc dự án.
Các trường hợp kiểm thử theo yêu cầu
Số liệu này được sử dụng để xem những tính năng nào đang được kiểm thử và số lượng kiểm thử phù hợp với yêu cầu. Hầu hết các yêu cầu chứa nhiều trường hợp kiểm thử. Điều rất quan trọng là phải biết trường hợp kiểm thử nào bị lỗi đối với một yêu cầu cụ thể để viết lại các trường hợp kiểm thử cho các yêu cầu cụ thể khác.
Số liệu này rất quan trọng đối với các bên liên quan vì nó cho thấy tiến trình phát triển ứng dụng / phần mềm.
Số liệu cấp ứng dụng
Mật độ khiếm khuyết
Mật độ khiếm khuyết là thước đo tổng số khiếm khuyết đã biết chia cho kích thước của thực thể phần mềm được đo.
Nó được sử dụng để xác định các khu vực cần tự động hóa. Nếu mật độ khiếm khuyết cao cho các chức năng cụ thể hơn nó yêu cầu kiểm tra lại. Để giảm các nỗ lực kiểm tra lại, các trường hợp kiểm tra các lỗi đã biết có thể được tự động hóa.
Điều quan trọng là phải xem xét mức độ ưu tiên của khiếm khuyết (thấp hoặc cao) trong khi đánh giá các khiếm khuyết.
Ví dụ, nhiều khiếm khuyết ưu tiên thấp có thể vượt qua vì các tiêu chí chấp nhận đã được thỏa mãn. Mặt khác, chỉ có một khuyết điểm ưu tiên cao có thể ngăn cản các tiêu chí chấp nhận được thỏa mãn.
Các yêu cầu bên ngoài Test Coverage
Sau khi tính toán phạm vi yêu cầu, bạn sẽ tìm thấy một số yêu cầu không được bao phủ. Bây giờ, điều quan trọng là phải biết về từng yêu cầu chưa được đề cập và giai đoạn yêu cầu là gì.
Số liệu này giúp kiểm tra các kỹ sư và nhà phát triển để xác định và loại bỏ các yêu cầu chưa được khám phá khỏi tổng số yêu cầu trước khi họ gửi chúng đến giai đoạn sản xuất.
Làm thế nào để cải thiện Test Coverage?
Xóa mã “chết”
Test coverage có thể hiểu là tỷ lệ số dòng mã được bao phủ trên tổng số mã trong ứng dụng (cover_code / total_code). Bạn có thể tăng phạm vi test coverage bằng cách giảm mẫu số là tổng mã. Điều này có thể được thực hiện bằng cách xóa mã chết hoặc những đoạn mã thừa. Thông thường, mã “chết” có thể được tìm thấy trong lịch sử phát triển chương trình khi các tính năng đã được thay đổi. Bằng cách này, bạn có thể tăng tổng tỷ lệ bao phủ mã của mình mà không cần viết bất kỳ testcase bổ sung nào.
Mã “chết” có thể được tìm thấy dễ dàng bằng cách kiểm tra thủ công hoặc sử dụng các công cụ tự động hóa. Trước khi loại bỏ mã “chết”, bạn cần thực hiện kiểm tra chức năng và đảm bảo nó thực hiện chính xác theo yêu cầu. Bạn cũng có thể sử dụng các công cụ phân tích để xác định mã “chết” không sử dụng trong mã nguồn.
Xoá các đoạn mã trùng lặp
Xóa mã trùng lặp có thể cải thiện tỷ lệ test coverage theo cách tương tự như xóa mã “chết”.
Kết luận
Các nhà phát triển ngày nay có hệ thống hơn và các tổ chức tìm kiếm các biện pháp kiểm tra tính đầy đủ và hiệu quả để hiển thị các tiêu chí hoàn thành kiểm thử. Trong đó, test coverage được coi là đặc biệt có giá trị. Dựa vào tỉ lệ test coverage giúp chúng ta giảm thiểu rủi ro tối đa trong phát triển phần mềm.