Bài viết được sự cho phép của tác giả Trần Hữu Cương
1. Hệ điều hành Android là gì?
Android là một hệ điều hành di dộng phổ biến nhất. Nó được chạy trên các thiết bị di động như smart phone, tablet… (điện thoại thông minh, máy tính bảng, đồng hồ thông minh)
Android là một mã nguồn mở, phát triển trên nền tảng Linux.
Hiện tại, Android được sở hữu và phát triển bởi Google.
Android gồm 5 phần chính sau được chứa trong 4 lớp:
Nhân Linux: Đây là nhân nền tảng mà hệ điều hành Android dựa vào nó để phát triển.
Thư viện: Chứa tất cả các mã cái mà cung cấp cấp những tính năng chính của hệ điều hành Android.
Android runtime: Là tầng cùng với lớp thư viện Android runtime cung cấp một tập các thư viện cốt lỗi để cho phép các lập trình viên phát triển viết ứng dụng bằng việc sử dụng ngôn ngữ lập trình Java.
Android framework: Là phần thể hiện các khả năng khác nhau của Android(kết nối, thông báo, truy xuất dữ liệu) cho nhà phát triển ứng dụng.
Application: Tầng ứng dụng là tầng bạn có thể tìm thấy chuyển các thiết bị Android như Contact, trình duyệt…
Trong các bài viết trước mình đã giới thiệu với các bạn cách kết nối đến RabbitMQ sử dụng Java thông qua giao thức AMQP. Trong bài này, tôi sẽ giới thiệu với các bạn cách kết nối RabbitMQ sử dụng Javascript thông qua WebSocket.
Web STOMP plugin giúp chúng ta có thể sử dụng Javascript để kết nối đến RabbitMQ sử dụng giao thức STOMP thông qua WebSocket connection.
RabbitMQ Web STOMP sử dụng giao thức STOMP, được cung cấp bởi RabbitMQ STOMP plugin và expose (hiển thị) nó bằng WebSocket.
Để enable RabbitMQ Web STOMP plugin, sử dụng lênh sau:
rabbitmq-plugins enable rabbitmq_web_stomp
Sau khi enable, chúng ta có thể access một web socket endpoint tại context path: /ws
Chẳng hạn: http://127.0.0.1:15674/ws
Sử dụng Web STOMP Plugin
Trong ví dụ bên dưới, tôi sẽ tạo một ứng dụng Echo server, đơn giản cho phép user gửi một Message lên RabbitMQ server và subscribe để nhận Message từ RabbitMQ Server.
Giao diện chúng ta sẽ tạo như sau:
Box bên trái: hiển thị thông tin Message nhận được từ RabbitMQ server.
Box bên phải: hiển thị thông tin log message giao tiếp giữa client và RabbitMQ server thông qua websocket.
Một input cho phép user gửi message lên RabbitMQ server.
Tiếp theo, chúng ta sẽ tạo file javascript để kết nối đến RabbitMQ server, gửi và nhận message:
printLogDebug : hiển thị thông tin log message giao tiếp giữa client và RabbitMQ server thông qua websocket. Thông tin log sẽ được hiển thị ở box bên phải.
printReceivedMessage : hiển thị thông tin Message nhận được từ RabbitMQ server. Thông tin log sẽ được hiển thị ở box bên trái.
send : thực hiện gửi message lên RabbitMQ server.
subscribe: đăng ký nhận message từ RabbitMQ server.
bindSubmittingForm : bind sự kiện submit form (khi user nhấn enter), để lấy thông tin user đã nhập trong input và gửi Message lên RabbitMQ server.
onConnectCallback : phương thức này được gọi lại sau khi đã tạo Stomp Client thành công. Nó thực hiện bind sự kiện submit form, subscribe nhận message từ RabbitMQ server.
onErrorCallback : phương thức này được gọi lại khi tạo Stomp Client thất bại.
start : chạy ứng dụng, bao gồm tạo client, enable debug, tạo connection và đăng ký các callback.
Các bạn lưu ý rằng, Destination được định nghĩa trong STOMP có một chút khác biệt so với Java sử dụng AMQP. Đặc tả STOMP không quy định loại destination nào mà broker phải hỗ trợ, thay vào đó nó được xác định dựa vào giá trị của destination header trong SEND và MESSAGE. RabbitMQ STOMP hỗ trợ một số loại destination sau:
/exchange : SEND các khóa định tuyến tùy ý và SUBSCRIBE cho các pattern kết tùy ý.
/queue : SEND và SUBSCRIBE tới các hàng đợi được quản lý bởi STOMP gateway.
/amq/queue : SEND và SUBSCRIBE tới các hàng đợi được tạo bên ngoài STOMP gateway.
/topic : SEND và SUBSCRIBE tới transient và durable topic.
/temp-queue/ : tạo hàng đợi tạm thời (chỉ trong reply-to header).
Bây giờ các bạn có thể chạy thử file index.html ở trên và kiểm tra kết quả.
Mở admin UI và xem thông tin Exchange, Queue được tạo:
Trên đây là một số hướng dẫn cơ bản về cách kết nối RabbitMQ server sử dụng Javascript thông qua WebSocket. Các bạn có thể tham khảo thêm cách Authentication user, cấu hình security, thay đổi host, port, … ở các liên kết bên dưới.
Bài viết được sự cho phép của tác giả Trần Hữu Cương
Trong bài trước, mình thực hiện build 1 maven project với source lấy từ github thành 1 file .jar sau đó chạy file jar đó bằng tay.
Thực tế thì khi deploy ứng dụng, sau khi build được file .jar (hoặc là file .war, .ear) thì người ta sẽ chạy file .jar đó giống như 1 service để chạy ngầm và quản lý. Hoặc với những file .war thì người ta sẽ cấu hình để sau khi build, upload file đó lên tomcat để chạy. Còn gần nhất là đang thịnh hành sử dụng docker để deploy thì người ta sẽ tạo 1 container, copy file .jar, .war vào container đó và chạy.
Trong bài này mình sẽ hướng dẫn chạy file .jar tự động sau khi build giống như 1 service trên Ubuntu.
Bài viết tập trung vào thiết kế hệ thống (Design System) cho việc lưu trữ file. Đảm bảo tính scalable cho system và sử dụng Distributed Concepts (Hệ thống phân tán).
Bắt đầu ngay thôi nào!
1. Tiếp cận với Distributed File System
Hiện nay, hẳn không lập trình viên nào còn lạ lẫm với Google Drive, Dropbox. Đây là những hệ thống quản lý file ở quy mô lớn, scalable cho hàng tỷ người dùng, hàng triệu triệu request mỗi giây.
Việc một lượng lớn người sử dụng đặt yếu tố mở rộng (Scalable) lên hàng đầu. À nhân tiện thì bài viết này cũng có sử dụng một số phần nội dung về Google File System (GFS). Anh em có thể tham khảo thêm về GFS ở phần tham khảo của bài viết.
Để đảm bảo tính ổn định của hệ thống, như dữ liệu đã public về design thông qua GFS, ta có thể biết các hệ thống này đang thiết kế theo hướng phân tán (Distributed File System).
Nói sơ về Google File System thì nó là design cách quản lý cơ sở dữ liệu của Google. Trong GFS:
Khi thiết kế về Google File System được chia sẻ, ta biết rõ rằng Google hỗ trợ lưu file với kích thước vô cùng lớn. Các file có thể có kích thước vào khoảng TeraByte, MegaByte.
Tất nhiên nội dung các file sẽ được chia sẻ ra thành nhiều phần và lưu trữ ở nhiều Chunk khác nhau. Không bao giờ một file có kích thước quá lớn được lưu trữ vào duy nhất một machine.
Mỗi file sẽ được phân tách thành các phần có kích thước 64MB. (Số lượng chunk có kích thước 64MB tùy thuộc vào kích thước file)
Tuy nhiên nếu một phần file chỉ ở một chunk vẫn xảy ra rủi ro về file. Nếu một chunk gặp vấn đề và down, các phần để tập hợp một file có thể không đủ. Dẫn tới file bị broken.
Để giải quyết vấn đề này, mỗi part of file sẽ lưu trữ ở 3 chunk khác nhau. Nếu một chunk down, vẫn có cách để lấy file đó ở các chunk khác. Việc lưu trữ ở nhiều chunk nhỏ đảm bảo cho sự phân tán (Distributed) trong Distributed File System.
Dễ dàng scaling khi có nhiều file hoặc nội dung file lớn.
Phần nội dung số 1 sẽ lưu ở 3 chunk khách nhau là Server 1, Server 2 và Server 3.
3. Chunk Location Table System
Trường hợp file được chia thành các phần nhỏ. Mỗi lúc cần truy xuất file ở một node, ta sẽ sử dụng Location Table System.
Bảng này cho biết part đó đang nằm ở đâu?. Chunk nào?
Trường hợp ở trên File được chia thành 8 phần. Các chunk id đại diện cho từng phần (tất nhiên là duy nhất Unique). Vị trí của các chunk nằm trên replica nào sẽ được ghi vào table này. Table này có thể lưu trữ vào RAM ở Master.
Trên đây là cái nhìn tổng quan nhất về Distributed File System và Google File System. Cách thức lưu trữ file lớn và những gì lưu trữ ở chunk. Tiếp theo, ở phần hai sẽ bàn về How System Work?, bổ sung một số thiết kế detail.
Anh em có thể tiếp tục đón đọc phần 2 chuỗi bài viết này ở đây.
Bài viết được sự cho phép của tác giả Trần Thị Thu Hà
Hôm nay là ngày thứ 7, cuối tuần, tôi mới có thời gian thoải mái đắm chìm trong một vài bài nhạc Trịnh du dương,ngọt ngào cùng nhấm nháp thứ chất lỏng đen sì , chát đắng sặc mùi hóa chất mà người ta vẫn hay kháo nhau bằng cái tên rất mĩ miều “cafe” .Chết lảm nhảm rồi!!!
Đây là một bài chia sẻ. Chuẩn đấy! Mặc dù nó được tôi viết (chính xác là đánh máy), nhưng nó chỉ là một bài chia sẻ . Chắc chắn không phải là một giáo án hay đại loại thế, đừng nhầm! Giáo án thuộc một phạm trù gì đó dành cho nhà giáo đáng kính , hay các expert cao quý .Còn tôi, đơn thuần là một anh chàng đang trong tuổi ăn , tuổi học loay hoay tập code kể lại mấy hoạt động testing với cái gọi là parsing HTML. Thế nên, xin nhắc lại lần nữa: Đây, là một bài chia sẻ :)) .Ấy lại lảm nhảm rồi
Thực ra thì cái nào cũng quan trọng với bài này, khi bạn click vào link này thì chắc là bạn có lướt qua một trong những khái niệm trên rồi nhỉ .Nếu không thì các bạn vào từng cái để tìm hiểu đã nhé
Thôi , có vẻ hơi lan man . Chúng ta vào phần chính, à mà quên. nhược điểm của việc bóc tách theo dạng này là rất tốn băng thông nhé vì phải download cả file html, và app rất dễ tèo (app phụ thuộc hoàn toàn vào web theo một cách hoàn toàn bị động)
Thôi zô nào
Cấu trúc của project :
1 Interfaces
2 IHTMLParser
3 IAsyncCallback
Tiếp theo là thư viện sử dụng , các bạn nhớ add đầy đủ nhé
Chúng ta sẽ xử lý Networking thông qua thư viện volley.Nói về volley thì các bạn cũng biết ưu điểm của nó là gì rồi,Các bạn vào đây tìm hiểu thêm
Màn khởi động thế là ổn rồi :).Chúng ta đến với class đầu tiên
BaseApplication
ở đây tôi sử dụng Singleton Pattern mục đích là đảm bảo tại mỗi thời điểm nó được gọi thì chỉ có mỗi nó được tạo ra
public class BaseApplication extends Application {
private static BaseApplication sInstance;
private RequestQueue mRequestQueue;
public synchronized static BaseApplication getInstance() {
return sInstance;
}
public RequestQueue getRequestQueue() {
return mRequestQueue;
}
@Override
public void onCreate() {
super.onCreate();
sInstance = this;
mRequestQueue = Volley.newRequestQueue(this);
}
}
Tiếp theo là 2 Interface IHTMLParser và IAsyncCallback
ở class này chúng ta thao tác trực tiếp với Jsoup .Các bạn chú ý hàm này
doc.getElementsByTag("title");
Nó sẽ trả về một chuỗi có tag name là “tittle”,ngoài ra các bạn có thể thay đổi các hàm khác để test
Tiếp theo thì tôi đưa text vừa get về được vào array và add url vào cho phần tử đó
for (Element anchor : anchors) {
post = new Smartjop();
post.setURL(anchor.attr("href"));
post.setText(anchor.text());
response.getPosts().add(post);
}
Toàn bộ class SmartjobParser
package vn.com.vdc.myapplication.parsers;
import org.jsoup.Jsoup;
import org.jsoup.nodes.Document;
import org.jsoup.nodes.Element;
import org.jsoup.select.Elements;
import java.util.ArrayList;
import vn.com.vdc.myapplication.entities.Smartjop;
import vn.com.vdc.myapplication.webrequesthandler.IHTMLParser;
public class SmartjobParser implements IHTMLParser {
@Override
public BaseObject parseHTML(String htmlToParse) {
BlogResponse response = new BlogResponse();
try {
Document doc = Jsoup.parse(htmlToParse);
response.setPosts(new ArrayList());
Smartjop post;
Elements anchors = doc.getElementsByTag("title");
for (Element anchor : anchors) {
post = new Smartjop();
post.setURL(anchor.attr("href"));
post.setText(anchor.text());
response.getPosts().add(post);
}
} catch (Exception exception) {
exception.printStackTrace();
}
return response;
}
}
Cuối cùng là MainActivity
ở đây tôi sử dụng listview để show dữ liệu .Các bạn chưa rõ về listview ,adapter có thể vào đây ,một bài viết khá đầy đủ của một dev nữ rất xinh gái :)) để tham khảo nhé
Tôi sử dụng url để parsing “http://bigidol.vn/su-kien/57f74bd1a56da1e02756a9f2.html”
Mẫu báo cáo tháng HR cần là những báo cáo được quan tâm nhằm đánh giá xác lập cơ sở; đánh giá tình hình phát triển của công tác nhân sự suốt một tháng vừa qua. Sẽ là một thiếu sót lớn nếu bạn lỡ bỏ qua những mẫu báo cáo tháng HR này.
Ngoài ra, nội dung chính báo cáo HR còn có ý nghĩa quan trọng trong việc đánh giá chất lượng; tác động lớn đến chiến lược tiếp theo của toàn quy trình. Tính ổn định; mức độ hiệu quả đều được thể hiện rõ qua mẫu report HR. Đây cũng là cơ sở quan trọng để phòng nhân sự tối ưu hóa quy trình làm việc; nhận ra những sai sót, các vấn đề còn tồn động để tìm ra giải pháp khắc phục kịp thời.
Cùng TopDev điểm qua 4 loại báo cáo quan trọng trong công tác quản trị nhân sự; mà bắt buộc bất kỳ HR nào cũng sẽ cần nắm bắt.
Báo cáo nhân sự liên đến sự chuyển biến nhân sự
Mẫu report HR này có mục đích chính là theo dõi những biến đổi trong quá trình tiếp nhận, tổ chức; hoặc có liên quan tới số lượng nhân sự của công ty.
mẫu báo cáo tháng hr
ăn cứ theo các tiêu chí gồm: thâm niên, thời gian, vị trí,.. Thông qua đó biết được sự tăng giảm của nhân viên.
Cụ thể mẫu báo cáo tháng HR gồm có:
Báo cáo biến động theo thâm niên
Liệu bạn có biết được tỷ lệ thay đổi, biến động; và có sự xác định rõ giữa các nhóm nhân viên hay không? Tất cả sẽ được biểu hiện rõ qua mẫu báo cáo tháng HR này. Thông qua mẫu report HR này, ban quản trị nhân sự có thể tìm ra các nguyên nhân căn bản nhất một cách chính xác. Từ đó, làm cơ sở quan trọng để thiết lập ra những giải pháp phù hợp nhất với tình hình hiện tại.
Mẫu report HR này được dùng để chia các nhóm thâm niên (nhóm < 01 tháng, 03 tháng, 06 tháng, 12 tháng, 24 tháng, nhỏ hơn hoặc lớn hơn 36 tháng).
Mẫu report HR biến động theo thời gian
Nội dung chính báo cào HR này xoay quanh việc nhận định; đánh giá từ tổng quan đến chi tiết quá trình. Ban quản trị nhân sự có thể nhìn ra được khoảng thời gian nào là thời điểm các nhân viên có sự dịch chuyển về công việc nhiều nhất. Đây được gọi là thời điểm nhảy việc. Và dựa trên những số liệu thực tế, thời gian này tập trung phân bổ chủ yếu rõ rệt nhất là vào khoảng tháng 1 và tháng 2 dương lịch.
Theo các báo cáo nhân sự từ các tập đoàn lớn thì đây cũng chính là thời gian mà các công ty có nhiều sự biến động mạnh mẽ nhất về sự thay đổi nhân sự (sau khi nhận lương thưởng Tết xong).
Lúc này, phòng Nhân sự sẽ ngồi lại với nhau để tìm ra các yếu tố quyết định nghỉ việc của từng người. Đồng thời, chuẩn bị nguồn ứng viên cần để thay thế vị trí đó. Mẫu báo cáo tháng HR này thông thường sẽ được chia theo tỷ lệ tháng/năm.
Tính biến động từ báo cáo này cũng được thể hiện rất rõ thông qua thực tế. Khi dễ dàng thấy được từ tháng 01 đến tháng 08, tỉ lệ biến động nghỉ việc tăng dần. Chính số liệu và khoảng thời gian cụ thể, các công ty sẽ bắt đầu đánh giá; tìm ra nguồn cơn tạo ra sự thay đổi này. Đồng thời, lên kế hoạch cho những thay đổi có thể diễn ra trong giai đoạn mới.
Báo cáo dựa theo biến động vị trí công việc
Đây là loại báo cáo tháng HR cung cấp cái nhìn tổng quan & khách quan theo tỷ lệ biến động lớn. Công việc chủ yếu của trưởng bộ phận các phòng ban là cần tập trung tìm ra nguyên nhân; cùng các giải pháp nhằm cải tiến hiệu suất. Nội dung chính báo cáo HR này thường chia thành các nhóm tương ứng với những vị trí chức vụ giống nhau.
Mẫu báo cáo tháng HR nhân sự thể hiện tính tổng quan việc tuân thủ thời gian làm việc; chấp hành quy định đối với từng bộ phận; cũng như toàn công ty vận hành theo cơ cấu trực tuyến chức năng. Từ cái nhìn chung ấy, HR sẽ có cơ sở phân tích; đồng thời chỉ ra tất cả các vấn đề vi phạm quy trình một cách có dẫn chứng (thông qua sự biến động về số liệu); và công tác quản lý của công ty.
Ý thức của mỗi nhân viên cũng được xem là yếu tố quan trọng. Vì nó có thể dẫn đến nhiều thay đổi trong công tác và quy trình tuyển dụng nhân sự.
Mẫu report HR cho thấy mức độ hiệu quả quá trình sử dụng lao động
Đây là mẫu báo cáo tháng HR tiêu chuẩn nhất. Và nó được đánh giá là một trong những báo cáo quan trọng. Mẫu report này giúp ban lãnh đạo nhận thấy được hiệu suất của sự tác động đến hoạt động kinh doanh. Đồng thời giải đáp được cơ cấu vị trí chức vụ, lương, trình độ nhân viên xem có tương thích với khả năng thực sự; trình độ và tiềm năng phát triển của họ hay không.
Đặc điểm về nội dung chính báo cáo HR:
– Xét dựa trên phương diện mục tiêu; tính đặc thù tương thích với từng loại hình kinh doanh để tạo ra báo cáo cụ thể.
– Theo phân tích, so sánh từ chính bộ phận hoặc doanh nghiệp theo thời gian, ngày tháng, quý, năm.
– Mẫu báo cáo tháng HR này thường dùng để so sánh hiệu suất giữa bộ phận, đơn vị này với các bộ phận hoặc là đơn vị khác.
Điều cần lưu ý khi xây dựng mẫu báo cáo tháng HR này thường căn cứ theo các chỉ tiêu:
Số lượng sản phẩm/ định biên nhân sự
Số lượng sản phẩm / tổng chi phí tiền lương
Việc tối ưu hiệu quả mà mẫu report HR mang lại rất quan trọng. Các bộ phận cần được chia sẻ kết quả của quá trình sản xuất kinh doanh trong từng đơn vị một cách cụ thể. Khi có những thông tin xác thực; các số liệu thực tế về quy trình phát triển doanh nghiệp, việc thiết lập báo cáo và sự phân tích, đánh giá sẽ có cơ sở và đạt được hiệu quả cao hơn.
Mẫu report HR tuyển dụng
Khi nhắc tới các loại báo cáo quan trọng của nhân sự không thể không nhắc tới báo cáo hiệu quả tuyển dụng. Trong loại báo cáo này thì nhân sự cần phải nêu rõ được hiệu quả tuyển dụng; so sánh chuẩn xác được những kênh đem tới nguồn ứng viên thích hợp với doanh nghiệp.
mẫu báo cáo tháng hr
Báo cáo hiệu quả tuyển dụng gồm 2 loại: Công tác tuyển dụng và bảng đánh giá hiệu quả với từng nguồn tuyển dụng.
Lời kết
Mẫu báo cáo tháng HR đóng một vai trò quan trọng đối với định hướng phát triển lâu dài cho tổ chức/doanh nghiệp. 4 loại mẫu report HR vừa kể trên có tính thông dụng cao. Nó là các mẫu báo cáo mà ai trong lĩnh vực HR nhân sự cũng cần phải nắm. Mong rằng, bài viết đã cung cấp cho mọi người những thông tin bổ ích về các loại báo cao tháng HR. Từ đó, lựa chọn và sử dụng cho phù hợp; cũng như thiết lập một cách toàn diện quá trình báo cáo HR một cách tốt nhất.
Hôm nay mình nghe bài nói chuyện giữa anh Kyle Simpson (tác giả You Don’t Know JS) và Jeff từ Software Engineering Daily[1] Nếu các bạn đang hỏi là: Ơ, tự nhiên lòi đâu ra cái vụ nghe podcast nữa? Thì podcast là một phong trào mới nổi trong cộng đồng developer, và tính cả thời gian đi làm lẫn đi về của mình thì một ngày tốn tầm 3, 4 tiếng lái xe, nên nghe podcast/audio book để tận dụng thời gian “chết” là một giải pháp vừa hiển nhiên vừa chỉ có lợi.thì thấy một ý kiến khá là đáng quan tâm của anh Kyle về cách phân biệt giữa library và framework, note lại kẻo quên.
Đầu tiên, anh Kyle đưa ra một ví dụ về việc lái xe: Giả sử bạn lái xe, và muốn đi từ điểm A tới điểm B, mà bạn không biết đường.
Cách đơn giản nhất, đó là mở ngăn kéo lấy ra một tấm bản đồ, nhìn vô đó để tìm đường đi, tấm bản đồ bằng giấy, và bạn phải tự tìm đường bằng cách hình dung ra con đường. Tấm bản đồ là một công cụ giúp bạn tìm đường đi, nhưng tự thân nó không đưa ra bất kì ý kiến hay chỉ dẫn nào cho bạn.
Ở một cấp độ khác cao hơn, chúng ta có các thể loại thiết bị kết nối GPS, đưa ra các gợi ý và hướng dẫn để chúng ta đi từ điểm này đến điểm khác, như Google Maps trên điện thoại. Tuy nhiên, nếu Google Maps biểu bạn rẽ trái, mà bạn lại quẹo phải, thì cũng không sao. Bạn luôn luôn có sự lựa chọn là nghe theo hoặc không nghe theo các ý kiến chỉ dẫn đó.
Cấp độ cao hơn nữa, đó là xe tự lái, bạn ngồi lên xe, ra lệnh cho nó chạy từ chỗ này đến chỗ kia, và nó sẽ tự tìm đường để đưa bạn đến nơi cần đến, có nghĩa là bạn đi theo nó, và bạn không có sự lựa chọn nào khác Chỉ là đại khái thôi, thực ra xe tự lái thì bạn vẫn có thể can thiệp được vào việc nó lái, và đó là luật.ngoài việc nằm im và hưởng thụ ngồi yên cho nó lái.
■ Đọc tới đây hẳn các bạn cũng đã hình dung ra được thế nào là framework và library rồi đúng không? đọc tiếp đi.
Ở trên là 3 cấp độ đại diện cho 3 cách phân loại: library, framework và platform, lần lượt dựa trên mức độ opinionated của chúng.
Library là các loại công cụ chỉ đơn thuần là công cụ, không đưa ra bất kỳ ý kiến hay chỉ dẫn nào để bạn phải làm theo, bạn có thể tùy ý sử dụng và tùy biến nó theo cách của bạn. jQuery, underscore, lodash là các ví dụ về library, chúng chỉ cung cấp cho chúng ta các công cụ cần thiết để tùy ý lựa chọn và sử dụng chứ ta không cần phải theo một quy tắc gì.
Framework là các công cụ opinionated, nó đưa ra các quy tắc và hướng dẫn để chúng ta phải tuân theo, tuy nhiên nếu không theo thì cũng chả chết ai. Angular là một framework, vì nó bắt bạn code theo quy tắc của nó (từ cách đặt tên, cho tới cách tổ chức cấu trúc dự án, service, module, cách viết directives…). React thì nằm đâu đó giữa framework và library vì nó không bắt buộc chúng ta phải tuân theo một quy cách nào, mỗi người có một cách sử dụng React riêng, nhưng vẫn phải tuân theo một số quy tắc mà nó đưa ra (ví dụ các lifecycle handler của một component, và bạn có thể tùy ý setState hoặc xài Redux,…).
Platform là các công cụ cực kì opinionated, Cũng có người định nghĩa platform theo nghĩa rộng hơn, là bao gồm cả hệ điều hành, phần cứng, nơi mà các ứng dụng, framework chạy. Tuy nhiên cách định nghĩa này có vẻ không liên quan đến platform trong bài viết.bạn phải tuân theo hoàn toàn mọi quy tắc mà nó đưa ra, làm khác đi thì không được. Ví dụ WordPress nằm ở giữa khoản framework và platform, một bộ theme phải có các thành phần này kia, phải có function.php (phải ko ta, lâu rồi không code PHP), .NET Framework là một platform. PhoneGap là một platform.
Tôi đã học được những gì từ dự án đầu tiên của mình?
Tác giả: Jessica Wilkins
Sau bốn tháng dài viết code, nghiên cứu, tìm hiểu mọi thứ và tự hỏi liệu bao giờ nó hoàn thành, cuối cùng tôi đã được triển khai trang web đầu tiên của mình. Đó không phải là một con đường dễ dàng, nhưng kết quả cuối cùng rất xứng đáng. Bên cạnh đó, tôi cũng rút ra được nhiều kinh nghiệm lập trình hữu ích cho mình.
Kỹ năng lập trình sẽ được cải thiện sau nhiều dự án
1. Tôi có thể làm được điều đó không?
Vào tháng 6 năm 2020, căng thẳng chủng tộc ở mức cao chưa từng thấy vì những sự kiện xung quanh cái chết của George Floyd. Kết quả là, điều này đã tạo ra một cuộc trò chuyện về sự thiếu đa dạng và đại diện của các nhóm thiểu số trong tất cả các ngành.
Tôi đã có rất nhiều bạn bè liên hệ với tôi và hỏi thông tin về các nhà soạn nhạc da đen trong quá khứ và hiện tại với hy vọng âm nhạc của họ được biểu diễn thường xuyên hơn. Để đáp lại điều này, tôi quyết định bắt đầu chuỗi video Youtube Black Excellence giới thiệu những nhà soạn nhạc da đen thành công.
Bộ truyện đã thành công vang dội và một ý tưởng mới đã ra đời. Điều gì sẽ xảy ra nếu có một trang web tên là Black Excellence Music Project? Nó có thể là một trang web giáo dục với hồ sơ, trò chơi, âm nhạc và rất nhiều thứ khác. Nhưng có một vấn đề lớn hơn: ai trên thế giới sẽ tạo ra thứ này?
Tôi chỉ mới bắt đầu hành trình viết code được vài tuần, chưa có nhiều kinh nghiệm lập trình và tôi không nghĩ mình đủ khả năng để xây dựng một thứ như thế này. Vì vậy, tôi quyết định đặt nó vào ổ ghi phía sau và tiếp tục với việc học của mình.
2. Bây giờ hoặc không bao giờ
Vài tháng sau, tôi bắt đầu suy nghĩ nhiều hơn về dự án. Tôi đã nghĩ về các trò chơi có thể có, các nhà soạn nhạc nổi bật và các tính năng thú vị khác. Nhưng tôi vẫn còn do dự khi bắt đầu vì tôi cảm thấy mình chưa sẵn sàng. Tôi chỉ biết HTML, CSS và một chút JavaScript. Nhưng tôi nhận ra một điều rằng: bây giờ hoặc không bao giờ.
Vậy nên, mặc dù sợ hãi và do dự, tôi quyết định sẽ bắt đầu.
Lần đầu tiên tôi mở tài khoản GitHub của mình vào tháng 6 năm 2020, khi tôi quyết định học cách viết code. Tôi đã không thực sự làm bất cứ điều gì với nó trong vài tháng trước khi bắt đầu dự án này. Cảm giác mơ hồ của tôi về GitHub là bạn có thể lưu code của mình và mọi người có thể nhìn vào nó. Vì vậy, tôi quyết định đã đến lúc thực sự tìm hiểu về GitHub và bắt đầu làm việc với dòng lệnh.
Sau khi xem một vài hướng dẫn, tôi đã tạo thành công repo đầu tiên của mình và đẩy lên GitHub. Tôi rất vui vì mình đã có thể làm được gì đó, nhưng bây giờ tôi phải tiếp tục như thế nào? Tôi sẽ làm cái gì tiếp theo?
Tôi đã có tất cả những ý tưởng này nhưng hoàn toàn không biết bắt đầu từ đâu. Tôi có bắt đầu với trò chơi xây dựng không? Tôi có xây dựng mô hình thiết kế không? Mọi thứ nhanh chóng bắt đầu trở nên choáng ngợp và tôi không biết phải làm gì tiếp theo. Vì vậy, tôi quyết định chỉ bắt đầu với một trang HTML đơn giản.
Tôi cố gắng tạo một số trang HTML cho hồ sơ nhà soạn nhạc và lo lắng về việc tạo kiểu cho chúng sau này. Cách tiếp cận này làm tôi thấy yên tâm hơn và dẫn đến một khởi đầu rất hiệu quả cho dự án.
Tôi muốn chọn một bảng màu phù hợp với chủ đề. Tôi muốn một thứ gì đó êm dịu nhưng có tiềm ẩn sức mạnh đằng sau nó. Sau một số nghiên cứu, tôi quyết định chọn màu tím. Màu tím thường được xem là đại diện cho sự sang trọng và trí tuệ.
Tôi nghĩ đây sẽ là sự lựa chọn hoàn hảo cho những nhà soạn nhạc da đen đã có những đóng góp đáng kể cho nghệ thuật.
Để hoàn thành việc build một trang web cần sự phối hợp của rất nhiều yếu tố
6. Có những cách nào để tôi sáng tạo game?
Đến lúc này, tôi đã có một vài trang HTML và một số style cơ bản. Và đã đến lúc bắt đầu viết code cho một số trò chơi. Tôi nghĩ sẽ rất tuyệt nếu có một vài trò chơi mà cả trẻ em và người lớn đều thích. Lần đầu tiên tôi bắt đầu với việc vạch ra cách các trò chơi sẽ hoạt động. Sau đó, tôi bắt đầu giải quyết từng chức năng một. Tôi đã nghiên cứu rất nhiều và mắc rất nhiều sai lầm nhưng cuối cùng tôi cũng bắt được chúng.
// this is for the tour and local gig functionsfunctionperformanceOutcomes(){shuffle(gigResponses);if(randomMsg ==='You were late to the gig and not allowed to perform.'|| randomMsg ==='You were mugged outside after the gig and they took all of your money.'){
message.innerHTML = randomMsg;
money +=0;
earnings.innerHTML =`Total earnings: $ ${money}`;}else{
message.innerHTML = randomMsg;
money +=5;
earnings.innerHTML =`Total earnings: $ ${money}`;}}
7. Sắp xếp thông tin như thế nào?
Sẽ có rất nhiều phần chuyển đến trang web vì vậy tôi cần phải thông minh trong việc quản lý tất cả các tệp này. Tôi luôn ý thức về việc chọn các tên tệp và thư mục mô tả cần ngắn gọn để có thể dễ dàng tìm thấy chúng.
Tôi cũng gặp phải vấn đề có nhiều bảng định kiểu. Vì tôi đang sử dụng lại rất nhiều kiểu giống nhau, nên sẽ hợp lý hơn khi chỉ có một biểu định kiểu chính và liên kết nó với tất cả các trang HTML.
Vào cuối tháng 1 năm 2021, trang web cuối cùng đã sẵn sàng onboard. Tôi quyết định liên hệ với Nicholas Carrigan, người kiểm duyệt và nhà phát triển freeCodeCamp. Anh ấy có một dịch vụ cho các phiên đánh giá code trên trang web của anh ấy và tôi muốn anh ấy check code của mình. Buổi đánh giá rất có giá trị và tôi đã học được rất nhiều về cách làm cho trang web trở nên tốt hơn nữa.
9. Nhưng sự thật khi xuất bản trang web thì…
Không có thanh điều hướng. Không có chân trang. Không có CSS.
Tại sao điều này lại xảy ra?
Mọi thứ đều ổn khi tôi thử nghiệm nó tại địa phương. Sau nhiều giờ mày mò và nghiên cứu, cuối cùng tôi đã tìm đến sự giúp đỡ. Tôi đã nhắn tin cho Nicholas và giải thích vấn đề. Anh ấy check code và giải thích rằng có vấn đề với đường dẫn tệp của tôi và chỉ cho tôi cách khắc phục. Tôi cảm thấy nhẹ nhõm khi biết giải pháp cho vấn đề của mình và có thể thực hiện tất cả các thay đổi cần thiết.
Tôi đã học được rất nhiều điều khi xây dựng dự án này và chắc chắn có một phần thăng trầm. Nhưng cuối cùng, tôi rất hạnh phúc với kết quả mình đã đạt được. Nhất là với những kinh nghiệm lập trình tôi đúc kết được.
Những kinh nghiệm lập trình đó là gì?
Nếu bạn có ý tưởng cho một dự án, chỉ cần bắt đầu. Đừng đợi cho đến khi bạn sẵn sàng. Xây dựng nó theo cách tốt nhất mà bạn biết cách và triển khai nó. Nó là hoàn toàn tốt nó không phải là hoàn hảo hoặc đánh bóng. Chỉ cần tiếp tục xây dựng và học hỏi.
Bài viết được sự cho phép của tác giả Trần Khôi Nguyên Hoàng
Chắc chắn trong đời của các bạn thì đã một lần trốn học đi chơi Net. Và mình cũng thế, mình cũng có một tuổi thơ ăn dầm nằm dề ở quán các quán net cỏ ngày xưa. …
Chính vì thế, mình sẽ mượn hình ảnh của quán Net để nói một cách tổng quát các khái niệm của Amazon Web Services (AWS), giúp các bạn có một cái nhìn tổng quát hơn về AWS.
Quán Net Amazon
Tưởng tượng rằng công ty A muốn mở một chuỗi các cửa hàng kinh doanh quán Net với cấu hình khủng. Vì công ty A giàu vcl nên công ty A muốn mở chuỗi cửa hàng Net trên toàn bộ thế giới. Cứ một quốc gia sẽ có một quán Net ở mỗi thành phố lớn ở quốc gia đó.
Quán Net của ông ty A thì to vcl, mỗi quán lại có vài nghìn máy cấu hình khủng, đủ cho các Skys cày view cho sếp hay là đua rank LOL.
Cũng như bao quán Net khác, quán Net của công ty A cũng đánh số lên mỗi máy: Máy 1, Máy 2, Máy 3, để nhân viên dễ dàng quản lý và khách hàng cũng dễ dàng tìm được máy mà mình thích hơn.
Tuy nhiên, quán Net này lại không có nhân viên kỹ thuật, chính vì thế, khách hàng tới chơi Net phải tự chuẩn bị sẵn bộ cài Window (hoặc bất cứ hệ điều hành nào) để cài lên máy, sau đó thì mới làm gì thì làm.
Trước khi đi vào quán Net thì khách hàng phải đi qua bộ phận bảo vệ của quán, để dảm bảo là các bạn không mang hung khí vào quán hay giúp các bạn trẻ né những pha gank thần thánh đến từ phụ huynh.
Vậy thì nó liên quan gì đến AWS?
Thật ra thì nó có liên quan cả đấy. Nếu như các bạn thay:
Công ty A = Amazon
Quán Net = Amazon Web Services
Mỗi quốc gia = Region
Mỗi thành phố = Availability Zones
Máy tính = EC2
USB chứa hệ điều hành = AMI
Máy số 1 = Elasctic IP
Bảo vệ = ASG
Thì các bạn đã nắm được sơ sơ cách hoạt động và các khái niệm cơ bản của AWS rồi đấy
Quay lại với AWS
Thông qua ví dụ ở trên thì mình sẽ nói rõ hơn về các khái niệm cơ bản nhất của AWS nhé.
Region
Region của AWS ở đây thì nó giống hệt như các quốc gia ở ví dụ về quán Net của mình ở trên. Amazon sẽ đặt máy chủ của họ ở rất nhiều quốc gia và khu vưc khác nhau trên toàn thế giới. Ở thời điểm hiện tại thì sẽ có tổng cộng là 22 quốc gia mà Amazon chọn mặt gửi vàng để đặt máy chủ.
Điều này có nghĩa là khi mua dịch vụ của AWS thì nên chọn khu vực nào đó phù hợp với nhu cầu của mình. Ví dụ ở Việt Nam thì nên chọn khu vực là Singapore vì máy chủ ở đây gần với Đông Lào nhất, nên tốc độ sẽ nhanh hơn nhiều.
Availability Zones (AZ)
Cũng như ở trên, cứ một một quốc gia thì Amazon sẽ tiếp tục đặt máy chủ của mình ở mỗi khu vực khác nhau. Ví dụ như ở Amazon chọn Singapore làm chỗ đặt máy chủ thì Amazon sẽ đặt vài cái server khác nhau ở mỗi một chỗ khác nhau để đảm bảo an toàn. Lỡ khủng bố nó bắn bể server ở một chỗ thì còn vài chỗ khác backup. Mỗi một cái máy chủ sẽ gọi là một Availability Zones (AZ).
EC2
Ở một một cái máy chủ, thì Amazon cho phép mình thuê các Instance trên các máy chủ đó. Nó giống hệt như mình thuê một cái máy tính như ví dụ ở trên của mình. Không khác gì cả. Cái máy tính mình thuê này có tên là EC2, là một máy tính ảo mà Amazon cho mình.
Vì là máy tính nên mỗi cái máy tính sẽ có cấu hình khác nhau, tùy vào nhu cầu lựa chọn của mình. Các bạn cứ lên thẳng trang chủ của AWS mà xem cấu hình của từng con rồi chọn con nào phù hợp với nhu cầu của mình.
Thường thì nếu là nhu cầu học hành thì dùng con t2.micro là ok rồi. Con này nó cho xài free luôn.
Amazon Machine Image (AMI)
Sau khi có máy tính rồi, thì việc tiếp theo là phải cài đặt hệ điều hành cho nó. Cái này thì anh em cài Win dạo chắc biết hết. Kiểu gì cũng phải tải bộ cài về rồi dùng USB tạo boot rồi đem đi cài Win dạo được chứ.
Giống y vậy, thì bộ cài ở đây gọi là AMI. Amazon cho mình chọn là mình muốn cài cái gì luôn, tùy vào nhu cầu thì chọn cái để cài thôi. Ví dụ như mình có thể cài Windows, Ubuntu, Redhat, hay Fedora. Cái gì cũng được. Lúc mình thuê EC2 là nó cho mình chọn cả. Mình cũng có thể build riêng hệ điều hành của mình rồi cài lên cũng được nốt.
Amazon có cung cấp một AMI mà mình nghĩ là hay xài nhất là Amazon Linux. Đó về cơ bản là một hệ điều hành Linux với một số tool được Amazon cài sẵng. Mình dùng thằng này để học. Mấy thằng khác thì mình không có nhiều kinh nghiệp lắm.
Elasctic IP
Khi vào một quán Net thì mỗi một máy có một địa chỉ nhất định. Ví dụ như máy 1, máy 2, máy 2. Thì tương tự, khi bạn thuê một cái EC2 thì Amazon sẽ cung cấp cho bạn một cái địa chỉ, gọi là IPv4.
Tuy nhiên, cái địa chỉ này nó sẽ thay đổi mỗi lần bạn tắt EC2 hay khởi động lại EC2. Chính vì thế, Amazon cung cấp cho bạn một cái địa chỉ cố định và không bao giờ thay đổi, gọi là Elasctic IP. Cơ mà cái này phải tốn tiền để có được, nên thường thì các trang Web vừa và nhỏ không cần dùng thằng này làm gì cả. Thường thì người ta sẽ dùng DNS để trỏ qua IPv4 một cách tự động mà không cần dùng đến Elasctic IP.
Amazon Security Group (ASG)
Amazon Security Group giống hệt như bảo vệ của quán Net vậy. Bảo vệ sẽ kiểm soát toàn bộ các khách hàng đi ra đi vào quán Net. Cũng như Amazon Security Group sẽ kiểm soát toàn bộ các kết nối đi vào và đi ra instance. Mặc định, khi các bạn tạo một instance thì một ASG được tạo và block tất cả các kết nối ngoài vào và chấp nhận các kết nối từ trong đi ra.
Ví dụ như khi mình tạo một Instance và trong SG mình cấu hình chỉ cho port 22 (SSH) đi từ ngoài vào, thì chỉ có các kết nối bằng port 22 mới có thể đi vào EC2, còn lại sẽ bị block sạch.
Kết luận
Trên đây là các khái niệm cực kỳ cơ bản và đơn giản AWS. Mình không đi sâu vào tính năng của mỗi phần (Mình chưa học kỹ) nhưng cũng đủ để cho các bạn hình dung sơ sơ được AWS nó tròn méo ra sao. Phần sau mình sẽ nói tiếp đến các khái niệm khác như Load Balancer hay Auto Scaling Group nhé.
Bài viết được sự cho phép của tác giả Trần Hữu Cương
I. Scene trong Swift
Scene là các màn hình do View Controller quản lý và làm việc hiển thị giao diện người dùng.Vì vậy khi bạn tạo Scene cũng chính là bạn tạo đối tượng View Controller vào trong Storyboard.
+Cách tạo Scene:
-Các bạn tìm kiếm View Controller trong ô tìm kiếm và kéo vào Storyboard vừa tạo.
Và đây chúng ta đã có một Scene
-Tiếp theo tạo class kế thừa từ UIViewController để quản lý màn hình vừa tạo.
Để Xcode hiểu class vừa tạo là file quản lý màn hình thì chúng ta phải khai báo ở đây.
Để màn hình nào đó chạy đầu tiên thì bạn cần cài đặt trong Storyboard.
Các bạn hãy click vào checkbox Is initial View Controller.
Tìm việc làm code swift lương cao không cần kinh nghiệm cho bạn tại đây
II. Segue trong Swift
1. Segue là gì?
Segue có tác dụng là chuyển tiếp giữa các màn hình với nhau,giống intent trong Android.
+Có 4 loại Segue là
-Show :Hiển thị view controller mới nhưng sẽ đưa view controller cũ vào stack để có thể điều hướng quay trở lại khi chúng click vào back.
-Present Modally:Hiển thị view controller mới nằm đề lên view controller cũ khi view controller mới đóng thì view controller cũ vẫn được hiển thị trên màn hình.
-Present as Popover:Hiển thị view controller trong popover.
-Custom:Cho phép bạn tự tạo các thao tác chuyển tiếp theo ý mình.
Ví dụ:
-Sử dụng storyboard
giờ các bạn hãy tạo 2 màn hình như sau gồm 2 button :
Và các bạn nhớ phải tạo View controler để quản lý từng màn hình.
Để tạo segue các bạn hãy click vào button “Go to scene 2” rồi chuột phải và kéo sang màn hình thứ 2 .
Và đây là kết quả các bạn sau khi tạo
Khi tạo thành công nó sẽ có mũi tên liên kết của Segue giữa các màn hình với nhau.
2. Cách truyền dữ liệu sử dụng Segue
Tại màn hình 2 các bạn khai báo biến để bên màn hình gọi truyền dữ liệu vào.
Tại màn hình 1 overite lại phương thức prepare
override func prepare(for segue: UIStoryboardSegue, sender: Any?){ let data = segue.destination as! ViewController2 data.strDataFromView1=“Hello"}
Tại màn hình 2 các bạn chỉ việc set text cho button ,với data đã truyền từ màn hình 1 qua.
class ViewController2: UIViewController { var strDataFromView1:String?@IBOutlet weak var btn_back_to_scene: UIButton! override func viewDidLoad(){super.viewDidLoad() btn_back_to_scene.setTitle(strDataFromView1, for: .normal)}}
3. Cách quay lại màn hình trước sử dụng Segue
Sử dụng tính năng “unwind” , cho phép cài đặt một phương thức trong ViewController của scene để thực hiện hành động quay lại khi sử dụng segue kết nối các scene với nhau.
Chúng ta khai báo hàm unwind trong View controller 1
@IBAction func unwindTonameMain(_ unwindSegue: UIStoryboardSegue){ let sourceViewController = unwindSegue.source}
Tại màn 2 các bạn chỉ cần kéo view button muốn click quay lại vào nút Exit và chọn “unwindToMain”
Tiếp nối bài viết về thủ thuật lập trình phần trước thì tôi sẽ hướng dẫn thêm cho các bạn về một thủ thuật nho nhỏ của sublime text, thủ thuật này cũng rất là hữu dụng khi các bạn xử lý các dữ liệu của mình. Nào chúng ta cùng bắt đầu tìm hiểu nhé.
Giờ tôi muốn lấy ra tất cả các thông tin email ở trong đống JSON này trong vòng một nốt nhạc thì tôi phải làm như thế nào. Các bạn yên tâm vì bây giờ đã có Sublime text để giúp cho các bạn làm việc này một cách nhanh chóng. Cách làm như sau nhé.
1. Bôi đen ký tự [“email”: ]
2. Nhấn tổ hợp phím Ctrl + F
3. Nhấn tổ hợp phím ALT + Enter để chọn toàn bộ những ký tự [“email”:]
4. Nhấn phím > (3 lần) để di chuyển con trỏ sang phải 3 lần.
5. Nhấn giữ phím Ctrl + Shift và nhấn nút > (Nhấn tới khi nào chọn hết được email thì dừng lại.
6. Nhấn Ctrl + C để copy email và Ctrl + V để dán kết quả ta được như sau.
Hy vọng thủ thuật này sẽ giúp ích cho bạn được một phần nào đó để làm việc hiệu quả và đạt hiệu suất cao trong công việc.
Nếu thấy hay thì hãy nhớ like page và share các bài viết giúp tôi nhé.
Cám ơn các bạn đã quan tâm theo dõi.
Khi bắt đầu học / tìm hiểu môn ngôn ngữ hay framework, technology mới thì code được tất nhiên là tốt, nhưng hiểu về concept lại là điều quan trọng nhất, chính vì lí do đó Kieblog giới thiệu thêm bài viết về Vuejs Concept.
Học Vuejs tất nhiên nhanh, nhưng không nên vì quá nhanh mà quên mất những concept quan trọng nhất của Vuejs.
Thật ra mục này tương tự như câu hỏi “Computed và Methods khác gì nhau?”.
Đầu tiên, computed tất nhiên không có tham số (đối số) – argument. Thường được sử dụng để xử lý data từ những properties của component hiện tại hoặc chuyển từ component khác tới
Computed properties actually work like getters, they are usually using to compose new data from existing properties and they don’t accept arguments. Computed properties know if the values used in the function changed so they don’t need to run every time to check
Bản chất thì computed gần giống như getters thường sử dụng xử lý dữ liệu từ các props sẵn có, computed không chấp nhận đối số. Computed biết nếu giá trị trong function đã thay đổi thì sẽ thực hiện lại. Vì vậy không cần phải gọi method trong computed nhiều lần để kiểm tra
Còn về methods thì sao. Method là function, cứ nhớ là vậy.
Methods are static functions and they are useful for DOM event handling, logic parts. And you can pass arguments to methods. Methods don’t know if the values used in the function changed so they need to run every time to check.
Method là những function tĩnh, thường được sử dụng để xử lý các sự kiện trên DOM, các tính toán logic. Có thể pass các tham số cho method. Cái bất lợi là method không trigger tham số change khi nào. Bất cứ khi nào muốn update tính toán cho tham số đều phải gọi function.
Hiểu để sử dụng Computed và Methods lúc nào cho đúng cũng là hiểu được Vuejs concept.
2. Lifecycle hooks
Cái thứ hai không thể không nắm rõ là Lifecycle hooks. Đây là nội dung bắt buộc phải nắm rõ vì hiểu được Lifecycle mới biết một component thực sự hoạt động như thế nào?. Trải qua những bước gì để có một component hoàn chỉnh cho ta thấy?
Lifecycle đôi khi cũng được đánh giá là Vuejs concept quan trọng nhất cần phải biết.
Ví dụ như created. Step này component chưa render trên DOM, ta có thể thoải mái chuẩn bị data, gọi API, …
Sau khi đã đầy đủ dữ liệu thì thực hiện tính toán và render trên DOM để có một component hoàn chỉnh.
Kế đến là mounted
The mounted hook calls after the template have created and inserted in the DOM, and now you have access to the vm.$el property. But also you should remember that mounted does not guarantee that all child components have also been mounted
Mounted hook thì được gọi sau khi template đã tạo và thêm vào DOM thành công. Lúc này ta có thể truy cập tới thuộc tính vm.$el. Tuy nhiên cần nhớ là mounted không đảm rằng tất cả các component con đã mount ra thành công. Mỗi component có thời gian xử lý và tính toán khác nhau, để phán định các component con thì cần vào mounted trong component con đó.
3. Vue to re-render component như thế nào?
Làm việc với Vuejs tất nhiên không thể tránh khỏi việc rerender lại một component. Dữ liệu update, thao tác người dùng thay đổi, …. Có vô vàn thứ ta cần thực hiện, thông qua rerender component.
Tuy nhiên, render lại component cũng có concept để bám theo. Cách này hay cách kia đều được cân nhắc kĩ lưỡng lợi và hại. Bài viết này sẽ phân tích 2 cách rerender là sử dụng “v-if” với nextTick và “key”.
Giá trị của isComponentsVisible khởi tạo là true, vì vậy compoent some-component sẽ được rendered
Khi ta gọi hàm forceRerender lại set giá trị cho isComponentsVisible là false
Lúc này dừng render component some-component vì kiểm tra thấy v-if bằng false
Lúc này next tick set lại isComponentsVisible là true
Lúc này giá trị của v-if là true, ta lại render lại compoent some-component thêm một lần nữa.
First, we got to wait until the next tick or we won’t see any changes. In Vue, a tick is a single DOM update cycle. Vue will collect all updates made in the same tick, and at the end of a tick, it will update what is rendered into the DOM based on these updates. If we don’t wait until the next tick, our updates isComponentsVisiblewill just cancel themselves out, and nothing will update.
Đầu tiên ta cần chờ next tick hoặc không thấy cái gì thay đổi. Trong Vue, tick là một DOM cycle độc lập hoàn toàn. Vue sẽ lấy tất cả các nội dung update trong tick, cập nhật và render lại component ở trên DOM. Lúc này ta cần chờ đợi next tick, cập nhật của isComponentsVisiblewill nếu không có gì thay đổi thì component sẽ không được update.
Đó là cách hơi chuối, rối rắm và loằng ngoằng cho mỗi cái mục đích “rerender lại component”. Có cách khác hay hơn để forceRerender một component.
Với cách viết này thì mỗi khi function forceRerender() được gọi, giá trị của key componentKey sẽ thay đổi. Vuejs sẽ biết điều này và “xóa component cũ, thực hiện tạo component mới”.
Nên nhớ là re-render không thực hiện trên component cũ. Vuejs thực chất xóa component cũ và tạo lại một cái mới.
Đây cũng là Vuejs concept cần nhớ khi muốn thực hiện rerender lại component.
4. Đừng viết JavaScript expressions khó quá
Khó ở đây không phải viết sao cho tốt, cho dễ refactor. Khó ở đây đang được hiểu là đừng viết những logic quá rắc rối ở template. Hãy thực hiện chúng ở function.
Thử tưởng tượng một component có 30 dòng ở template, nhưng có tới 5 cái v-if, v-for và v-else thì quả thật là tai họa. Đọc để hiểu cũng đã là cả một vấn đề, nói gì tới đọc hiểu rồi còn sửa code. Thảm họa.
Chỉ cần khoảng 3,4 điều kiện như thế này lồng nhau. Đọc source thôi cũng nhức cmn cả đầu. Thay vì sử dụng quá nhiều expressions, ta có thể handle ở method. Viết lại như sau sẽ dễ dàng hơn:
Bài viết được sự cho phép của tác giả Nguyễn Trương Trung Tín
Mình xin viết tiếp bài post hôm trước về những lần đi phỏng vấn của mình, nó có thể cho bạn 1 chút kinh nghiệm khi chưa đi phỏng vấn lần nào. Còn khi bạn đã phóng vẫn vài lần và kinh nghiệm đầy mình rồi thì có thể đọc chơi xem “lần đầu” của mọi người có cảm giác giống nhau hết hay không. Mình có phỏng vấn 3 lần thì mình xin kể lại và cuối cùng là phần rút ra kinh nghiệm nhé.
Lần 1 – phỏng vấn làm nhân viên chính thức (lúc này mình vừa học xong năm 3):
Không cần nói các bạn cũng biết thì lần đầu lúc nào cũng là lần khó khăn nhất. Một là vì lúc này bạn chưa có kinh nghiệm làm việc ở đâu cả nên rất dể chết trong những câu kiến thức. Lí do khác là vì bạn chưa bao giờ phải moi móc kiến thức mình ra để nói chuyện trực tiếp với người khác lâu đến vậy, trừ khi bạn có đi dạy thêm cho những bạn cùng lứa. Vì vậy, nên lần này sẽ là lần dễ đánh gục bạn nhất. Nhưng không sao cả, Thomas Edison vẫn vĩ đại khi ông có khoảng 10.000 thất bại nên 1 lần của bạn cũng không là cái đinh gì cả. Mình cũng thất bại trong lần này nhé.
Ở lần phóng vấn này mình cũng không chuẩn bị gì nhiều cả vì cũng không có gì chuẩn bị. Nhưng trước hôm phỏng vấn mình có hơi căng thẳng và không ngủ được do mình chỉ nộp CV thử thôi nhưng không ngờ họ lại gọi mình, vì mình mới học xong năm ba và công việc này lại cần người ra trường hoắc 1, 2 năm kinh nghiệm. Do lần đầu nên mình bị stress dữ lắm, trước phỏng vấn mấy ngày cứ lo lắng suốt thôi. Khi vào phòng phỏng vấn, mình mô tả lại xíu là phòng khoảng 10m2, có 2 thánh đang ngồi sẵn đặt CV của bạn trước mặt. lần lượt 2 người đứng dậy bắt tay mình lúc này run không nói được gì luôn, cứng hết cả người. Ngồi xuống lấy lại tí bình tĩnh. Thì câu hỏi đầu tiên của những cuộc phỏng vấn sẽ là giới thiệu bản thân bạn.
Do run quá mình không nói được gì nhiều, hình như họ cũng không đánh giá cao phần này lắm. Rồi họ hỏi vài ba câu đại loại làm quen như hỏi về phần học tập của mình, cấp 3 học trường này hả, chuyên gì… Cuối cùng thì họ sẽ vào vấn đề chính là kiến thức. Ban đầu họ sẽ nhìn CV bạn mà hỏi những thứ bạn ghi chép trong đó. Họ hỏi rất kĩ càng đến khi nào bạn không biết nữa thì thôi. Phần này thì mình ok vì chuẩn bị khá tốt. Nếu bạn có trả lời sai gì họ có thể góp ý cho bạn ngay tại đó để biết mình sai luôn nhé. Tiếp đến sẽ là phần kiến thức họ cần cho công việc, ví dụ như bạn xin vào làm team ứng dụng nghe nhạc. Thì lúc này họ sẽ hỏi những thứ như tạo service để chạy nhạc làm sao, lấy nhạc như thế nào…. Còn 1 phân nữa không thể thiếu là họ sẽ hỏi bạn về OOP và data structure. Những phần này chú ý là bạn nên tìm hiểu kĩ nhá, mình ỷ y không hỏi nên phần này mình hơi ú ớ xíu. Xong xuôi tất cả thì họ sẽ trao đổi những thứ liên quan đến công ty họ, xem bạn có thật sự quan tâm không, bạn đã tìm hiểu gì về họ chưa. Xong thì về và đợi họ gọi báo kết quả, và kết quả của mình là không được gọi…
Lần 2 – phỏng vấn thực tập (vừa sau pv lần 1 vài tuần):
Sau đó ít tuần thì họ có gọi và bảo mình phỏng vấn thực tập. Mình cũng ok và đi thử vận may xem sao. Do cách lần pv trước ko xa nên kiến thức mình không lo lắm, còn về tâm lý thì lần này mình có vẻ đỡ stress hơn vì dù sao mình cũng đã có ít kinh nghiệm với lại tính chất quan trọng lần này cũng không lớn lắm nên cứ vậy mà đi phỏng vấn thôi. Nhưng đời không như là mơ bước vào chổ phỏng vấn thì thấy cả 6 7 người đứng đấy đợi phỏng vấn, quen cũng có mà là cũng có. Mà mình lại là người vào đầu tiên nữa chứ.
Lúc này bao nhiêu tự tin của mình bay hết rồi. Tay chân thì cứng đơ đứng đó, đợi “bị” kêu vào để pv. Lại giống hệt như lần đầu phỏng vấn là phòng nhỏ, 2 người ngồi sẵn đấy (lúc sau có thêm 1 người nữa, sau này vào làm mới biết là sếp to). Mình thì lại tim đập nhanh, miệng thì khô, đầu óc thì ngưng hoạt động, y hệt như lần trước vậy. Nhưng ít ra lần này mình rút kinh nghiệm được 1 tí, chủ động bắt tay, rồi ngồi xuống, rót 1 miếng nước uống lấy lại bình tĩnh và bắt đầu pv. Thì về cách phỏng vấn chẳng khác gì lắm so với lần 1, có điều lần này mấy sếp hỏi hơi kĩ hơn.
Đặc biệt là lúc sếp to xuống hỏi toàn những cái khó bên phần OOP với data structure, phần này thì mình hơi yếu và không kịp ôn nên khi pv xong tự nói luôn là thôi rồi, lần này tạch là cái chắc. Nhưng vì định luật bắt cầu nên lần trước nghĩ đậu thì lại rớt suy ra lần này nghĩ rớt thì lại đậu. Khoảng tuần sau mình được gọi đi pv lần 2. Và cũng biết luôn nguyên nhân mình không pass nhân viên chính thức. Lí do là mình không thể làm fulltime được, nên họ sẽ cho mình vào thực tập để tích lũy kinh nghiệm. Thì lần pv sau này cũng không có gì để kể, như cuộc nói chuyện hỏi thăm làm quen giữa cty và mình, sau đó deal lương và kí hợp đồng thôi.
Lần 3 – phỏng vấn xin học bổng (sau lần 2 khoảng 5 tháng):
Lần phỏng vấn này thì mình đã khá tự tin bà bình tĩnh để bắt đầu rồi. Và do lần này là pv xin học bổng nên cũng không liên quan tới kiến thức lắm (mình đã test kiến thức với họ trước đó rồi). Thường thì họ sẽ hỏi về định hướng tương lai của mình trước, cả gần lẫn xa luôn. Bạn cứ nói thoải mái, không có chuyện gì cả. Nhưng tốt nhất là nên có dự định gì liên quan tới cty họ thì tốt nhất nhé. Sau đó thì họ hỏi xem bạn biết gì về công ty hay chưa, biết thì kể họ nghe. Để xem bạn có quan tâm họ không ấy mà. Về phần pv này mình thấy hơi chán với lại không liên quan gì đến kiến thức cả nên mình pass qua luôn nhé.
Kinh nghiệm bản thân rút ra được:
Sau 3 lần pv thì mình có tích lũy được 1 số kinh nghiệm về việc chuẩn bị trước và trong lúc phỏng vấn để chia sẽ cho các bạn như sau:
Trước khi phỏng vấn:
Theo mình thấy thường thì khoảng thời gian này bạn sẽ có khoảng 1 tuần để chuẩn bị. Vậy các bạn nên chuẩn bị những gì? Kiến thức là thứ chắc chắn sẽ là quan trọng nhất. Bạn nên xem lại tất cả những thứ bạn đã ghi trong CV về công việc đó. Càng kĩ càng tốt. Và đặc biệt xem luôn phần OOP, data structure,… Vì những cái đó hình như là việc nào cũng vần đến cả. Và cuối cùng nên tìm hiểu thêm 1 ít thông tin của công ty bạn sắp vào pv nữa nhé. Ok lúc này nếu kiến thức bạn đã vững rồi thì giờ đến tinh thần. Thứ ảnh hưởng không kém đến chất lượng của màn trình diễn của bạn sắp tới. Chắc luôn là nếu lần đầu thì cả tuần trước khi pv bạn sẽ có 1 số hôm cảm thấy hơi căng thẳng, không làm được gì, lo tới lo lui,… Khi các bạn cảm thấy cảm giác đó thì mình khuyên là đừng cố nhồi nhét thêm kiến thức gì vào lúc đó cả, thư giản đi nhé, có thể xem 1 bộ phim, đá 1 trận banh, hoặc nghe vài list nhạc, những việc đó chỉ mất từ 1->2 tiếng thôi. Không nhiều nhưng đủ cứu cả ngày làm việc của bạn hôm đó đấy. Cứ thư giản đến lúc bạn cảm thấy ok rồi thì hay work tiếp. Nếu bạn đang căng thẳng mà work tiếp sẽ rất dễ gây ra stress và ảnh hưởng rất lâu đến suy nghĩ và đầu óc của bạn. Và nếu kéo dài đến trước lúc bạn phỏng vấn thì sẽ rất khó cho bạn. Trước lúc phỏng vấn thì chỉ có 2 việc đó thôi là kiến thức và tinh thần, bạn chuẩn bị được tốt 2 việc thì quá ok
Khi đến công ti phỏng vấn:
Việc đầu tiên mình lưu ý là khi đến công ty phỏng vấn không nên uống quá nhiều nước nha, và đặc biệt là không được uống nước có chất kích thích như redbull chẳng hạn. Nó sẽ làm đầu óc bạn căng ra đấy. Nên ăn 1 ít trái cây trước khi đi thì tốt hơn.
Còn vấn đề khác là trang phục, nên nhớ phỏng vấn việc gì thì chọn trang phục cho nó hợp với công việc đó xíu nha. Phỏng vấn làm software developer mà mặc sơ mi, đóng thùng, mang cà vạt thì nó hơi không hợp mắt tí nào. Còn 1 lưu ý là nếu bạn phỏng vấn làm mobile thì nếu đang xài cục gạch thì đừng đem ra trước mặt người phỏng vấn nhé. Vì mình nghĩ đơn giản là thợ chụp ảnh không thể được người khác thuê khi trong tay chỉ có máy ảnh dỏm được, thì với dân làm mobile mình cũng nghĩ thế.
Cuối cùng đến lúc vào phòng pv thì trước khi vào nên uống 1 ngụm nước để cổ họng không bị khô nhé. Để gây ấn tượng tốt với nhà tuyển dụng thì bạn nên chủ động tươi cười, đưa tay ra bắt tay vói họ và lúc nào cũng giữ trạng thái tươi cười nhé. Một điều cực kì quan trọng mình muốn nói là các bạn đừng nghĩ họ giỏi hơn mình, cứ nghĩ là mình đang nói chuyện với bạn như trong lớp vậy thôi, bạn nó hỏi bài chổ nào thì mình chỉ cho nó hết khả năng. Nếu bạn kiểm soát cuộc pv như là 1 cuộc nói chuyện bình thường giữa những developer với nhau thì bạn đã thành công trong việc giữ bình tĩnh rồi đấy. Cuối cùng là với những câu hỏi bạn không biết thì đừng trả lời bừa nhé, tuyệt đối không được trả lời bừa, mà hãy nói là: “vấn đề này em vẫn chưa được tìm hiểu, nhưng nếu có thời gian em sẽ tìm hiểu nó sau ạ”.
Nói vậy sẽ tạo thiện cảm cho người tuyển dụng hơn.
Thực lòng mà nói, khi cả thế giới thậm chí đã ngưng nói về OOCSS, BEM hay các CSS methodologies khác, thì mình vẫn còn stick với kiểu viết CSS truyền thống, đó là cách viết “trải lòng”, theo đúng nghĩa đen của nó:
Cho đến một ngày, khi mình quyết định là mình đã chịu hết nổi khi phải nghe @kcjpop và @bần_harris@bần_harris là thanh niên không chịu cho xin địa chỉ Github để link vô đây, đây là thanh niên làm cho mình mỗi sáng thức dậy lại cảm thấy khủng hoảng vì trình độ lớp trẻ ngày một cao siêu…nói mãi về những tachyons hay tailwind, cụ thể hơn là Atomic CSS, những thứ từ vựng mình không biết và không hiểu mẹ gì. Mình quyết định lại một lần nữa, nhảy lên con tàu của những kẻ hipster.
Atomic CSS hiểu nôm na là một cách viết CSS mà chúng ta… không cần viết một dòng CSS nào cả. Thay vì viết code CSS, chúng ta sẽ sử dụng các class có sẵn mà một Atomic CSS Framework cung cấp. Trong các framework này, mỗi class có nhiệm vụ định nghĩa một thuộc tính duy nhất (vậy nên mới gọi là atomic).
atomic /əˈtämik/: adjective, relating to an atom or atoms / of or forming a single irreducible unit or component in a larger system. tiếng Việt: nguyên tử
Ưu điểm lớn nhất của Atomic CSS có lẽ là giúp tránh được các vấn đề với CSS specificity (mức độ ưu tiên của các thuộc tính), gây ra do cách viết kế thừa class.
Tức là, thay vì muốn có một cái nút phẳng bo góc tròn, thay vì:
Nhìn qua thì có vẻ hơi rối và hoang đường, thứ nhất, ai lại đi viết một đống class dài lê thê thế kia? thứ hai, ấn tượng của mình là: Ba cái bọn bốc phét! Không viết CSS thì chắc chỉ làm được vài ba cái style đơn giản, còn mấy cái cần customize nhiều thì thách cha nó làm cũng không được!
Đây cũng là quan điểm của khá nhiều người, mình biết được vì sau đó vài ngày thì trên Hacker News cũng xuất hiện một thread thảo luận về một bài viết về Atomic CSS của Julia Evans.
Tuy nhiên, sau vài hôm thử nghiệm, mình làm được vài cái demo nho nhỏ với Tailwind CSS, cũng cảm thấy thoải mái hơn khi sử dụng. Đầu tiên là prototype một cái giao diện blog minimal:
Xét về khả năng customize và sự tự do khi thiết kế giao diện, Tailwind tỏ ra là không thua bất cứ ai, thậm chí nó còn hỗ trợ responsive và các thuộc tính CSS như hover nữa.
Sẵn tiện đã hype, thì hype cho tới, mình cũng quất luôn một cái demo khác và lần này ôm thêm cả React Hooks. Là prototype một cái mail client UI.
Đến demo thứ hai này thì mình buộc phải xuống tay viết một vài dòng custom CSS để làm hiệu ứng background nằm chéo màn hình, mấy cái trò này hiển nhiên Atomic CSS chưa thể hỗ trợ được.
Khi sử dụng với React thì coi bộ Atomic CSS khá tiện, giúp cho việc prototype nhanh chóng mà không cần phải switch qua lại để vừa viết code JS và viết CSS, cũng không cần phải viết CSS style trong JS nữa.
Nhìn chung thì đây cũng là một phương pháp viết CSS rất đáng quan tâm, tuy nhiên để đưa ra thêm nhận xét thì mình còn phải sử dụng nó nhiều nữa. Còn từ giờ cho đến lúc đó, bài này đành phải kết cụt lủn như thế này vậy
Chào mọi người, sau bao nhiêu năm đi làm tôi đã đúc kết được một số kinh nghiệm quý báu, cũng xin chia sẻ lại với mọi người, chủ yếu là giành cho những bạn sinh viên và những bạn mới ra trường. Tôi sẽ chia sẻ về cách mình đến mới máy tính, đến với lập trình và những kinh nghiệm khi đi làm, những dự án thực tế, bài học rút ra để các bạn không gặp phải, những kỹ thuật, hack, cheat để làm dự án nhanh hơn.
Series bài viết này tôi sẽ không hướng dẫn về thủ thuật máy tính hay thủ thuật lập trình. Mà muốn tâm sự về nghề nghiệp, về con đường mình đã chọn, chia sẻ những kinh nghiêm khi đi học và đi làm để những bạn mới tiếp cận về lập trình sẽ không mắc lại những sai lầm của tôi.
Tôi là một lập trình viên, không phải nhà văn hay một người viết lách, cách hành văn của tôi sẽ không hay nhưng tôi sẽ cải thiện dần để ngày một hay hơn. Và câu chuyện của tôi là…
Biết đến máy tính từ năm học lớp 6, ngày đó thực sự tôi chưa biết máy tính là gì, tôi không nhớ chính xác cái năm đó là năm bao nhiêu, tôi chỉ nhớ đó là một kỳ nghỉ hè và cũng không hiểu lý do gì đã thôi thúc tôi đăng ký học một khóa học máy tính.
Trường THPT của tôi là một ngôi trường ở quê, một nơi chưa cập nhật công nghệ thông tin như các thành phố lớn khác, lúc đó có mở một khóa tin học và tôi đã đăng ký tham gia học.
Lần đầu tiên tôi biết tới máy tính lúc đó chỉ biết nó là một loại máy móc nào đó giống như những loại máy khác, không biết nó làm gì và ứng dụng như thế nào vào cuộc sống mà chỉ biết học để thỏa mãn trí tò mò.
Tôi được học về phần mềm soạn thảo văn bản MS Word 2003, cách đánh máy, cách chia bố cục văn bản, vẽ hình, chèn hình, định dạng văn bản. Mỗi người được giáo viên phát cho một đĩa mềm với dung lượng là 1.44Mb để lưu những bài học thực hành mà mình đã làm được.
Trong lớp học chỉ có một mình tôi là lớp 6, tôi học chung với những anh chị lớp 8, 9. Sau một vài ngày học thì chúng tôi phát hiện trong máy tính có một game tên là TienSu. Mà chúng tôi hay gọi là tiền sử, game nói về một người tiền sử cầm một cái cây giống như gậy đánh bóng chày, đi qua những nơi nào có khủng long thì cầm cái chày đó mà giã.
Thế là một kỳ nghỉ hè lại trôi qua và tôi chuẩn bị vào lớp 7, tôi đã lãng quên đi những kiến thức của Word mà đã học được, trong tâm trí tôi không còn đọng lại những thông tin gì cả.
Từ sau năm lớp 8 trở đi, những quán net mọc lên như nấm, người người chơi game, nhà nhà chơi game và tôi cũng không ngoại lệ, thời điểm đó tôi biết tới game half life. Ngoài half life thì tôi không chơi một game nào khác, tôi được một cái hay là chơi game thì không bị nghiền, một phần vì lý do là không có tiền nhiều để chơi liên tục, một phần là do đại lão gia nhà tôi rất nghiêm khắc, biết được tôi đi chơi game mà không học là mông nở hoa liền.
Đã bao nhiêu mùa lúa trổ bông mà tôi cũng chưa được sờ…À nhầm tôi đã sắp lên lớp 11, mốc này rất quan trọng trong cuộc đời của tôi là bước ngoặt mà tôi đã đến với con đường lập trình. Năm đó tôi đi học thêm môn hóa của cô H. Thì tình cờ người yêu của cô về trường của tôi dạy (À quên nói là trường cấp 2 của tôi được nâng cấp lên thành trường cấp 2 -3). Người yêu của cô cũng tên là H. Thầy H vừa dạy tin học vừa dạy toán, có thể dạy cả lý, nói chung là giỏi vô cùng. Nếu như thầy mà không về thì tôi giờ cũng không ngồi đây mà kể chuyện cho các bạn đọc, có lẽ hiện tại tôi đang đi ăn xin ở một nơi nào đó.
Trước khi nhập học thì tôi vẫn đi học thêm hóa và được làm quen với thầy, biết được thầy dạy môn tin học. Lúc đó tôi cũng không biết rằng tin học 11 thì mình sẽ học cái gì, thì mình liền hỏi thầy. Thầy nói rằng tụi mình sẽ học lập trình Pacal. Mình nghe thấy lâp trình thì thấy rất hứng thú, liền về nhà xin bố mẹ mua máy tính.
Nhà tôi cũng không phải khá giả gì, về cũng xin được bố mẹ 6tr đi mua máy tính, thêm cái bàn để máy tính nữa là 6tr6. Ôi mẹ ơi, máy tính gì mắc vãi, lúc đó mua được cái máy Pentium 4, ram 512Mb, USB 1Gb. Tôi sẽ không kể lại những chuyện vọc máy ra sao, cho nhớt vào máy thế nào mà tôi sẽ kể về lần đầu tiên tiếp cận về Pascal.
Sau khi mua máy về thì được thầy cho chép phần mềm Turbo pascal, đem về nhà mở máy tính và mở sách giáo khoa ra và gõ, mặc dù không hiểu gì và cũng không chạy được nhưng tôi vẫn gõ và gõ. Lúc này tôi biết là sẽ theo con đường lập trình này rồi.
Trong lớp thì có 2 đứa học Pascal tốt nhất vì nhà 2 đứa đều có máy tính, năm lớp 11 thì tôi đã quyết định chọn ngành công nghệ thông tin và thằng bạn tôi cũng vậy. Tuy nhiên sang năm lớp 12, khi đăng ký ngành để đi thi thì có mỗi tôi nộp vào ngành công nghệ thông tin còn thằng bạn thì lại nộp quản trị kinh doanh, đến giờ cũng không biết lý do vì sao nó lại chọn ngành đó, có thể do lúc đó ngành này quá hot chăng.
Và cái gì đến cũng sẽ đến tôi đậu vào ngành công nghệ thông tin của một trường không quá hot và với số điểm không được cao. Thằng bạn cũng đậu quản trị kinh doanh.
Đến đây thì đã hết phần 1, mời các bạn đón đọc phần 2 nhé, phần 2 sẽ kể về những ngày tháng sinh viên học công nghệ thông tin của tôi.
Các bạn nhớ like fanpage để theo dõi những bài viết mới nhất nhé.
Dù bạn đã đạt đến trình Senior hay chỉ là một Junior mới bước chân vào con đường lập trình thì việc gặp bugs khi coding là điều thường xuyên và gần như không thể tránh khỏi. Sự khác biệt là một lập trình viên giỏi sẽ biết cách cải thiện kỹ năng debug của mình, giúp việc đối mặt với bugs trở nên “bớt đáng sợ” hơn.
Debug là một trong những kỹ năng quan trọng của lập trình viên
Làm thế nào để đối phó với bugs?
Có ba cách chính hiện đang được nhiều người biết đến:
Prebugging: giảm thiểu các lỗi trước khi chúng được tạo ra.
Debugging: xác định, khắc phục và loại bỏ lỗi khi tìm thấy chúng.
Post-debugging: có lỗi không mong muốn hoặc không xác định.
Chúng ta hãy xem xét từng vấn đề để hiểu rõ hơn về chúng.
1. Prebugging là gì?
Nếu chúng ta hay gặp lỗi ở một chương trình thông qua việc lập trình, điều đó có nghĩa là chúng ta cần tự hướng dẫn mình để giảm số lượng lỗi mà chúng ta gặp phải. Tôi gọi quá trình hướng dẫn bản thân này là “Prebugging”. Đây là một kỹ năng debug khá cơ bản.
Tôi đã tìm kiếm rất nhiều và có thể thấy một khái niệm khái quát nhất về Prebugging, đây là quá trình xác định và loại bỏ các lỗi khỏi phần cứng hoặc phần mềm của máy tính.
1.1. Lỗi cú pháp
Mỗi ngôn ngữ lập trình đều có các quy tắc riêng và các dev có trách nhiệm tuân theo các quy tắc đó. Ngôn ngữ lập trình nghiêm ngặt về các quy tắc và sẽ đưa ra lỗi bất cứ khi nào các quy tắc đó bị vi phạm.
Ví dụ, hãy tưởng tượng rằng bạn bỏ qua dấu ngoặc đơn của một hàm hoặc phương thức như sau: function {}
Bug sẽ lập tức xuất hiện.
Việc làm quen với thông báo lỗi của một lỗi cú pháp và cách khắc phục nó sẽ giúp bạn có lợi hơn trong khi gỡ lỗi. Cá nhân tôi nhận thấy rằng hầu hết các lỗi liên quan đến cú pháp luôn đề cập đến một số từ khóa giúp bạn tìm ra phần code nào đang có bug.
let school = {
name: "Harvard",
location: "Heaven On Earth", admit: function() { return "weeew! You are admitted" }
}
console.log(school.names); // undefined
Lỗi “Không xác định” được trả về cho chúng ta biết liệu đối tượng hoặc thuộc tính đang truy cập có khả dụng hay không. Chúng tôi có thể tìm ra vấn đề ở đâu nếu chúng tôi chú ý đến thông báo lỗi.
1.2. Lỗi logic
Các lỗi logic rất khó xử lý vì chúng luôn có vẻ như không có lỗi – nhưng bạn vẫn không nhận được kết quả như mong đợi.
Ví dụ: một cách đơn giản để xác nhận loại lỗi này là kiểm tra mã bên dưới trong bảng điều khiển của trình duyệt
prompt("enter number") + 3;
Bạn có thể mong đợi một số như một đầu ra, nhưng nó sẽ trả về một chuỗi. Tóm lại, bạn sẽ không nhận được kết quả như mong đợi. Do đó việc lên kế hoạch trước khi code và hiểu những điều cơ bản về ngôn ngữ lập trình đang sử dụng có thể giúp bạn đối phó với các lỗi logic – miễn là bạn hiểu các yêu cầu chương trình đưa ra cho bạn.
Chương trình của bạn có thể không biên dịch vì bạn có thể đã vi phạm một số quy tắc mà trình biên dịch mong muốn bạn tuân theo.
Ví dụ: viết một chuỗi mà không có dấu ngoặc kép thông thường, như trong const name = Ayobami, sẽ dẫn đến lỗi biên dịch vì một chuỗi phải được trích dẫn. Vì vậy, code sẽ không biên dịch.
Điều này tương tự như lỗi cú pháp, và càng viết nhiều code, bạn càng xử lý tốt hơn các lỗi biên dịch. Bạn có thể làm việc hiệu quả hơn và giảm những lỗi này bằng cách biên dịch hoặc kiểm tra code của mình thường xuyên.
Đôi khi, chương trình của bạn có thể vượt quá giới hạn bộ nhớ hoặc sử dụng hết tài nguyên có sẵn. Điều đó có thể khiến ứng dụng của bạn ngừng hoạt động hoặc hoạt động sai. Đoạn code dưới đây là một ví dụ trong thế giới thực về đoạn mã dẫn đến lỗi resources.
functionfactorial(num){var result =1;for(var i = num; i >0; i--){
result = num *factorial(num-1);}return result;}factorial(5);factorial(10);factorial(20);factorial(0);
Hàm factorial() bị treo hoặc làm chậm trình duyệt vì không gian ngăn xếp, tức là bộ nhớ mà trình duyệt phân bổ cho chuỗi lệnh gọi hàm, đã được sử dụng hết. Trong trường hợp này, lỗi là lỗi resources vì nó xảy ra do sử dụng hết bộ nhớ được cấp phát.
1.5. Lỗi giao diện
Đôi khi chúng tôi thiết kế các API chương trình để sử dụng theo những cách nhất định nhưng người dùng sử dụng các chương trình theo cách khác nhau và gây ra lỗi. Những lỗi như vậy được gọi là lỗi giao diện.
Ví dụ, giả sử rằng phương thức go(string) mong đợi một chuỗi nhưng thay vào đó chúng ta gọi nó bằng một số. Điều đó sẽ dẫn đến lỗi nếu người tạo ra chương trình không mong đợi và quản lý cách chương trình sẽ phản hồi trong trường hợp như vậy.
Hầu hết mọi thứ trong phần mềm đều tuân theo các tiêu chuẩn. Nếu các tiêu chuẩn đã xác định của bạn không được tuân thủ, bạn cần cung cấp cho người dùng của mình thông báo lỗi hoặc hướng dẫn để giúp họ tìm ra họ đang sử dụng ứng dụng sai. Việc ghi lại các API của bạn có thể giúp ích rất nhiều trong trường hợp này.
2. Debugging là gì?
2.1. Cách tìm lỗi
Tìm lỗi bắt đầu bằng việc hiểu các thông báo lỗi mà bạn thấy. Không cần phải nói rằng một thông báo lỗi là một con trỏ dẫn đến một lỗi. Nếu bạn hiểu thông báo lỗi, bạn có thể theo dõi chính xác vị trí của lỗi.
2.2. Tìm nguyên nhân của việc xảy ra lỗi?
Sau khi tìm thấy một lỗi, bạn cần phải tìm ra lý do tại sao code lại hoạt động theo cách mà nó thực hiện. Làm điều này giúp bạn xây dựng một hệ thống hiệu quả. Thay vì nhiều devs chỉ search Google và sử dụng câu trả lời họ nhận được trực tiếp từ StackOverflow.
Điều đó tốt trong một số trường hợp nhất định, nhưng tốt hơn là bạn nên hiểu nguyên nhân của lỗi và giải pháp cho vấn đề là gì. Hiểu nguyên nhân gây ra lỗi là một bước quan trọng trên con đường sửa chữa hoặc loại bỏ lỗi.
Sau khi tìm và hiểu được nguyên nhân gây ra lỗi, chúng ta phải sửa lỗi đó. Một khi bạn hiểu lỗi là gì, bạn sẽ đơn giản tìm ra giải pháp mà không cần căng thẳng. Tuy nhiên, có những lúc sự hiểu biết của chúng ta không mang lại giải pháp nào cho dù chúng ta có cố gắng đến đâu. Thay vì mất thời gian, bạn có thể thông báo lỗi trên Google hoặc bất cứ điều gì bạn cảm thấy phù hợp.
Bạn cũng có thể hỏi một người khác vì những người khác có xu hướng nhìn mọi thứ theo cách khác. Họ trung lập và sự trung lập đó thực sự giúp sửa một số lỗi.
Có nhiều cách khác nhau để khắc phục lỗi
3. Post-debugging là gì?
“Post-debugging” là dự đoán các lỗi không mong muốn trong các chương trình bạn đã viết. Nó đề cập đến tất cả các cơ chế bạn có thể sử dụng để đảm bảo rằng các lỗi không xác định được dễ dàng theo dõi hoặc quản lý trước khi chúng gây hại cho hệ thống hoặc công ty.
Bạn nên có một hệ thống theo dõi lỗi trong quá trình sản xuất để bạn có thể dễ dàng phát hiện ra các lỗi khi chúng xuất hiện sau khi đưa ứng dụng của bạn vào phiên bản sản xuất. Có rất nhiều công cụ theo dõi lỗi trên mạng. Nhưng đây là một số web mà bạn có thể kiểm tra:
www.sentry.io
www.honeybadger.io
www.pypi.org
www.airbrake.io
www.logrocket.com
Có rất nhiều công cụ theo dõi lỗi trên mạng, bạn sẽ phải nghiên cứu để tìm ra thứ tốt nhất cho mình.
Kết luận
Kỹ năng debug là một kỹ năng quan trọng mà tất cả các nhà phát triển phần mềm phải trau dồi. Nó là cốt lõi của việc viết code, và nếu bạn làm tốt, nó có thể giúp bạn trở thành một lập trình viên giỏi hơn. Tìm hiểu thêm nhiều cách debug chắc chắn là một trong những giải pháp quan trọng nhất dành cho bạn.
Đây là phương pháp giúp bạn tạo nhiều storyboard bằng cách tách bớt các màn hình từ một storyboard đã có thành storyboard mới.
Giờ các bạn tạo 2 màn hình như các bài trước mình đã hướng dẫn.
Bây giờ màn 2 vẫn thuộc Storyboard cũ,giờ chúng ta muốn tạo storyboard mới quản lý màn 2 chúng ta hãy click vào màn 2 bên storyboard và chọn Vào menu Editor ➜ Refactor to Storyboard
Và đây là kết quả sau khi chúng ta tách thành công
2.Tự tạo liên kết
Đối với cách này, chúng ta sẽ tự tạo một Storyboard mới ngay từ đầu, sau đó liên kết với Storyboard đã có. Chúng ta sẽ sử dụng luôn ví dự ở cách 1
1.Kéo thả đối tượng Storyboard Reference vào Interface Builder. Storyboard Reference là đối tượng giúp bạn tạo liên kết với một Storyboard nào đó. Bạn sẽ liên kết Button “go to screen 2” với Storyboard Reference
2.Các bạn hãy tạo 1 view controller mới
Đặt luôn id cho màn hình 2 để bên Storyboard references ánh xạ.
3.Các bạn hãy vào storyboard đầu tiên và click vào storyboard refernces
Để đặt class view controllers quản trị và references ID.
Giờ các bạn hãy build và xem kết quả .
Hy vọng bài hôm nay sẽ giúp các bạn hiểu rõ các sử dụng nhiều storyboard.
Bài viết được sự cho phép của tác giả Trần Khôi Nguyên Hoàng
Chú ý
exports và module.exports chứ không phải là export nhé các bạn. Nhiều bạn hay viết thiếu chữ “s” lắm ấy. Trong Javascript thì có cái từ khóa export nhưng trong NodeJS thì chưa đâu.
Trước khi một đoạn code trong module được thực thi thì NodeJS sẽ wrap code lại như sau:
(function(exports, require, module, __filename, __dirname){// Module code actually lives in here });
JavaScript
module.exports và exports khác nhau như thế nào?
Trước hết thì module.exports và exports trỏ tới cùng một Object, là một Object rỗng.
Tuy nhiên, chỉ có một thằng module.exports là cái thật sự được export khi mình require nó thôi. Còn thằng exports thì không phải. Nó chỉ là một reference tới thằng module.exports thôi.
Ở đây có thể thấy hai thằng này chỉ thay đổi cái properties của cái Object ban đầu (là Object rỗng ban đầu). Nên ở đây, hai thằng này vẫn là cùng một Object.
Muốn trở thành Vuejs Master tất nhiên không thể suốt ngày dựa dẫm vào các “Top 3 Vuejs Library”, “Top 5 Vuejs Library”. Một Senior Vuejs Engineer luôn có những component riêng được viết từng dòng code. Lượng sao trên github tất nhiên chẳng bao giờ tồi.
Tuy nhiên, nói đi cũng phải nói lại. Biết Library chưa chắc đã là không tốt. Một số dự án khi đã bị dí “tới đít”, sử dụng Library là điều không thể tránh khỏi. Do viết byhand một component bao giờ cũng tốn thời gian. Tuy nhiên, dùng là một chuyện, biết để dùng lại là chuyện khác.
Bài viết dưới đây Kieblog giới thiệu Top 3 Vuejs Library thường hay sử dụng nhất. Dùng khá là ok nên mới giới thiệu nha!
Bắt đầu ngay thôi nào!
1. User Ratings
Đứng thứ nhất trong Top 3 Vuejs Library là User Ratings.
Hầu hết web hay application hiện nay thường sử dụng rating rất nhiều. Rating cho user, rating cho dịch vụ, rating cho communication, bla bla. Viết một component Rating thực chất không khó.
Component Rating cần cho phép lựa chọn số lượng sao report. Tuy nhiên cần chú ý tới responsive trên mobile sao cho người dùng dễ dàng lựa chọn. Tránh spam, ngoài ra còn phải chú ý tới customize khi người dùng muốn thay đổi màu sắc, độ dài, …
Thực ra thì các Vue Framework hiện tại đã làm khá tốt và đều đã hỗ trợ Rating component. Đơn cử như Vuetify.
Về custom thì một số Vue Framework đã làm khá tốt. Custom đầy đủ.
Tuy nhiên, về khả năng custom nhanh chóng vượt ngoài design form của các framework tất nhiên không thể không kể tới vue-rate-it. Một
The options make it easy to v-model user selection ratings to wherever you want to use them, and you can set the rating to be changeable or read-only with a single prop.
Với vue-rate-it, các lưa chọn trở nên dễ dàng khi người dùng sử dụng v-model ở bất cứ đâu. Two way binding là đây chứ đâu.Việc tùy chọn rating readonly khi người dùng đã rate cũng chỉ cần thông qua môt prop duy nhất.
Đứng thứ hai trong Top 3 Vuejs Library là Date Picker.
Date cũng là component thường xuyên sử dụng khi phát triển Web/App với Vuejs. Date chọn ngày giao hàng, date search sản phẩm theo ngày, date chọn ngày publish, … Vô vàn thứ liên quan tới Date
Ứng cử viên Library mình muốn nhắc tới là vue2-datepicker. Component này có một số điểm mạnh:
Dễ dàng custom UI
Hỗ trợ i18n cho nhiều loại ngôn ngữ
Hỗ trợ nhiều loại date format cho từng quốc gia/ khu vực.
Lựa chọn được Date Rangle, …
Sử dụng vue2-datepicker vô cùng đơn giản.
import DatePicker from 'vue2-datepicker';
// styles
import 'vue2-datepicker/index.css';
Notification tất nhiên có nhiều loại, nhiều kiểu. Viết được Component Notification không khó. Tuy nhiên cần lưu ý, trigger và các vấn đề khác về thời gian hiển thị. Event back của Notification Component cũng là một vấn đề cần lưu tâm.
4. Tham khảo
Ngoài Top 3 Vuejs Library được Kieblog liệt kê ở phía trên, còn nhiều Library hấp dẫn khác không nên bỏ qua. Tất cả được liệt kê dưới đây:
