Ơn trời, cải tiến của Java 13 Switch và Text Blocks đây rồi!
1. Ấp ủ từ lâu
Ở Java 13, sự có mặt của JEP 354: Switch Expressions là sự kế thừa từ Java 12 Switch Expressions. Bản Java 12 đã bổ sung từ khóa yield (như bên Python). Mục đích của từ khóa yeild là return giá trị trong biểu thức Switch.
Đối với chuyện cộng chuỗi string bằng plus (+) thì quá đỗi ám ảnh anh em coder Java rồi. Mà hầu như chẳng còn xài nữa. Giờ có viết cũng cố đổi qua String Builder hay Buffer gì đó, chú ý sao cho performance không ảnh hưởng.
Tất nhiên, Java không như Javascript, cải tiến hay release feature mới liên tục, mỗi tuần vài shot. Nhưng mỗi thay đổi trong Java đều được chú ý, vì ít khi thay đổi.
Cùng xem xem có gì thay đổi khi Oracle release bản Java 13 nha. Đã là lập trình viên thì chắc chắn đụng tới Switch case hằng ngày. Tại sao?
Viết switch case trông code clean hơn hẳn.
Nhìn rõ ràng, dễ handle các case.
Trường hợp 6,7 cái trở lên thì ăn đứt if, else
// Kiểu viết thông thường
private String swithCaseNormal(int chanom) {
String result = "Kieblog";
switch (chanom){
case 1:
result = "Old switch";
break;
case 2:
result = "New switch";
break;
default:
yield -1;
break;
};
return result;
}
Ở Java 13 đã chuyển qua sử dụng yeild như thế này:
// Ở Java 13, không còn break, thay vào đó là yeild
private String swithCaseNormal(String mode) {
String result = "Kieblog";
switch (mode) {
case 1:
yield "Old switch";
case 2:
yield "New switch";
default:
yield -1;
};
return result;
}
Tuy nhiên, nếu viết kiểu arrow mũi tên thì Java 13 vẫn support như thường
// Nếu lỡ viết kiểu arrow như Java 12 thì Java 13 vẫn support như thường
private String swithCaseNormal(String mode) {
String result = "Kieblog";
switch (mode) {
case 1 -> "Old switch";
case 2 -> "New switch";
default -> -1;
};
return result;
}
Bỏ đi breaks để sử dụng arrow và yeild cũng có một số cái lợi như sau:
Đỡ mất công break cho từng case
Tránh bug khi quên break sẽ nhảy xuống case khác
Ngắn source, đơn giản, dễ hiểu, viết lẹ nữa chứ
3. Text Blocks
Thật lòng mà nói, ngoài Java 13 Switch, Text Blocks như là vị cứu tinh cho mấy cái dự án JDBC cũ cũ. Cũng đỡ tạo ác cảm, khẩu nghiệp cho lập trình viên.
Cứ có gì cần công chuyện, append bằng String Builder, String Buffer thì mệt vãi đ**. Mà cộng chuỗi bằng “+” thì củ chuối không thể chịu được.
// Một số dự án maintain SQL cũ còn viêt SQL Statement theo kiểu này
class KieBlog {
public void kieblogMain() {
String txt =
" Kie\n" +
" Blog\n" +
" Content\n" +
" Is\n" +
" Good\n";
}
}
Một số dự án render hoặc trả message lỗi bằng HTML tĩnh viết kiểu String cũng như được giải thoát
// Cách viết đơn giản, đỡ đâu đầu, chỉ cần """ rồi viết
class KieBlog {
public void kieblogMain() {
String txt = """
Kie
Blog
Content
Is
Good
""";
}
}
Sử dụng “”” cũng bỏ luôn nỗi ám ảnh dài lâu về tab hay space. Không format code cũng không được, mà format cho đẹp thì mất công, mất sức. Ba dấu phẩy thật sự lợi hại, tiết kiệm thời gian.
Trong phần 2, Smartjob sẽ tiếp tục cùng các bạn tìm hiểu những loại bàn phím được lập trình viênyêu thích nhất được tác giả Phil Johnson của IT World tổng hợp. Mình tin rằng trong phần này các bạn sẽ được nhìn thấy những kiểu dáng rất quen thuộc trong khoảng chục năm trở lại đây. Nếu bạn thích chúng, đừng ngại ngần bỏ công sức ra sưu tầm bởi sau này tìm lại được những mẫu thiết kế như thế chẳng hề dễ dàng gì.
Mọi người đã nói gì về nó? Không đắt đỏ, không cầu kỳ, trọng lượng nhẹ, nhỏ gọn với 104 phím và nút bấm. Những phím quan trọng vẫn được đặt ở các vị trí quen thuộc, không có marco hay phím media. Các phím có phản ứng với xúc giác nhưng vẫn rất yên tĩnh khi làm việc.
Nhận xét:
“Được làm việc với nó là một niềm vui lớn của tôi. Khi gõ phím, tôi có cảm giác mọi thứ đều thuộc về mình. Nó thực sự là chiếc bàn phím thuộc về tôi chứ không đơn thuần chỉ là một miếng nhựa lớn.” Tanerax
“Còn gì tuyệt vời hơn L100. Bạn có thể mua nó với chi phí cực rẻ. Đó là một sản phẩm hoàn hảo với tôi.” Polemon
“ Đây là bàn phím tốt nhất tôi đã từng sử dụng. Tôi nghĩ đây là loại bàn phím mà mỗi lập trình viên nên có.” Vedarthk
“Dell là bàn phím tuyệt vời.” Robert Harvey
Deck – 2005
Các phím của Deck được thiết kế theo kiểu phím cơ Cherry, là một loại backlit keyboard (bàn phím có đèn LED với các màu sắc khác nhau), có thể sáng cục bộ hoặc mờ đi tùy cách lập trình viên sử dụng. Loại bàn phím này có hai cỡ lớn và nhỏ (gồm 82 phím) như những phiên bản trước. Ưu điểm nổi bật của bàn phím Deck là rất bền với thời gian.
Nhận xét:
“Tôi thích mọi loại bàn phím của Deck. Chúng trông thực sự mát mẻ với gam màu lạnh và khiến tôi rất thoải mái khi gõ phím.” Spong
“Đây là bàn phím duy nhất trong loại của nó theo kiểu backlit. Nó hoàn toàn phù hợp với chiếc cặp của bạn.” Jeff Atwood
“The Deck được xây dựng dựa trên thực trạng lạm dụng bàn phím của game thủ vì vậy chúng rất bền. Đó là loại backlit nên bạn có thể thấy rõ những gì mình đang hack ngay cả khi tắt đèn vào lúc 2 giờ đêm.” Ken Jenni ngs
“ Nó thực sự rất tuyệt – Được thiết kế kiên cố và có màu xanh. Bàn phím đó sẽ mang lại cho bạn nhiều hơn những gì bạn có thể tưởng tượng.” John McC
Nhận xét của Smartjob: Nếu bạn thường xuyên phải code đêm, code rất nhiều thì đây là lựa chọn không thể bỏ qua. Nó sẽ giảm thiểu tối đa những tác hại mà bàn phím thông thường gây ra. Ngoài ra, gam màu đen kết hợp ánh sáng xanh sẽ làm cho quá trình làm việc của bạn có được hiệu quả cao khi phải ngồi lâu bên máy tính.
Das
Đây thực sự là loại bàn phím cho người lập dị – Nó được thiết kế tương tự bất cứ bàn phím thông thường nào khác chỉ có điều trên các phím không có bất cứ chữ cái, con số hay kí hiệu nào. Các phím trống tưởng có thể làm khó cho nhiều người tuy nhiên với một số lập trình viên nó thực sự đem lại cảm hứng lớn khi đánh máy. Tốc độ và sự chính xác sẽ được gia tăng đồng thời phím cơ Cherry MX sẽ mang đến cảm giác thỏa mãn khi gõ. Âm thanh của phím, không cần nhìn mà vẫn biết mình đang gõ gì – Đó là hai điểm khác biệt của Das.
Nhận xét
“Chúng thực sự khiến bạn gõ nhanh hơn. Bạn có thể gõ trong khi đang nói chuyện với mọi người.” Tom Morgan
“Người khác sẽ không thể đụng vào bàn phím của bạn nếu bạn chơi kiểu này =)).” Ackthpt
“Phải mất một khoảng thời gian để làm quen nhưng sau đó bạn có thể gõ phím mà không cần nhìn.” Luke Girvin
“Bàn phím này cho thực sự đem lại cho bạn nhiều sức mạnh. Bạn làm việc lâu bao nhiêu kết quả của bạn sẽ tốt bây nhiêu.” Jakobud
“Gõ kiểu này còn tốt hơn quan hệ tình dục.” Jeremy Cantrell
Microsoft Natural Ergonomic 4000 – 2005
Bàn phím Ergonomic tự nhiên hơn đối với rất nhiều người. Hai miếng đệm dựa luôn tạo ra sự thoải mái và giảm bớt việc bị đau cổ tay.
Nhận xét:
“ Cổ tay và bàn tay của tôi cảm giác thoải mái đến lạ kì. Những miếng da tạo cho bàn tay tôi cảm giác thoải mái hơn nhiều so với bàn phím chỉ toàn nhựa.” Paul Nathan
“Nó rất phù hợp với những người có bàn tay lớn.” JBRWilkinson
“Bàn phím tốt nhất mà tôi từng sử dụng. Mua một chiếc như vậy là quá đủ cho home(tôi là người sử dụng Linux)” David Rabinowitz
“Tuyệt vời, rất thoải mái. Mọi người sẽ tránh xa chiếc máy tính của tôi khi không thể sử dụng cái bàn phím kì lạ đó.” HappyCat
Microsoft Comfort Curve – 2005
Nó nhiều công thái học hơn bất cứ loại bàn phím nào – không quá lớn, không quá đắt tiền như bàn phím Natural Ergonomic của Microsoft. Một vài trong số chúng được thiết kế với các phím thấp.
Nhận xét:
“Đó là sự kết hợp tuyệt vời giữa bàn phím cơ bản và Ergonomic ” Carlos
“Đường cong tạo ra sự khác biệt. Ngoài ra mặt trên của bàn phím rất phẳng nên tôi có thể đánh phím từ mọi góc độ mà vẫn cảm thấy thoải mái. Các phím cũng rất dễ bấm.” EpsilonVector
“Các phím thấp thực sự rất hữu ích. Chúng được uốn cực kỳ chính xác và khi gõ cảm giác rất yên tĩnh.” Nlawalker
“Đẹp, bàn phím cứng, giá cả tuyệt vời… Nói chung nó rất tiện lợi vời những người đánh máy lâu năm.” Rob
Bàn phím nhôm không dây của Apple (Apple Aluminum)
Đây là loại bàn phím rất quen thuộc với các fan của Apple. Apple Animinum được thiết kế khá mỏng, bao bọc bởi vỏ nhôm và cách bố trí khá giống MacBook. Nhiều lập trình viên rất thích sự nhỏ gọn của nó (không có vùng phím số) và cơ chế ngăn cản caps-lock.
Nhận xét:
“Các phím ngăn cách nhau bởi bề mặt nhôm và điều đó giúp ích rất nhiều trong việc phòng ngừa lỗi fat-finger. Tôi khuyến khích các bạn nên dùng nó bất kể bạn đang dùng hệ điều hành nào.” Haploid
“Nhỏ gọn và xinh đẹp :D.” Randolf RF
“Đây là loại bàn phím yêu thích của tôi.” Dongsheng Cai
Như vậy là 12 loại bàn phím “bá” nhất đã được chúng ta khám phá. Đó là 12 kiểu dáng cơ bản nhất mang lại cảm hứng cho những mẫu thiết kế đương đại. Một lập trình viên thông minh không chỉ là người biết gõ code, fix lỗi hay hùng hục chạy theo các dự án. Các bạn hãy chọn cho mình loại bàn phím phù hợp nhất để có được thêm niềm cảm hứng và đam mê với công việc lập trình. Biết tận hưởng luôn tốt hơn là chỉ chăm chăm vào công việc. Chúng tôi sẽ tiếp tục đồng hành cùng các bạn trong suốt quãng đời của một lập trình viên và sẽ mang lại những kiến thức bổ ích nhất, biến lập trình trở thành một công việc thú vị chứ không chỉ là làm việc với những đoạn code khô khan, nhàm chán.
Theo Phil Johnson – Bài viết gốc được đăng tải tại smartjob.vn
Bài viết này sẽ giới thiệu tiếp phần còn lại của những kinh nghiệm tự học lập trình mà bạn có thể học hỏi để tự phát triển bản thân trong chặng đường trở thành developer của mình.
Kinh nghiệm tự học lập trình: Xây dựng không gian làm việc phù hợp
Tạo dựng cho bản thân một môi trường làm việc riêng biệt và khiến bản thân cảm thấy thoải mái có lẽ là điều duy nhất khiến tôi cảm thấy mình đã có quyết định đúng, cũng như muốn chia sẻ lại với bạn về kinh nghiệm tự học lập trình.
Cá nhân tôi không cảm thấy mình phù hợp với những môi trường quá yên tĩnh hay một không gian khép kín. Vậy nên tôi thường lựa chọn cho mình một vài quán cà phê gần nhà hoặc thư viện để học. Tôi thích âm nhạc vì vậy kể cả là khi đang tập trung để nghiên cứu tôi vẫn đảm bảo lượng âm thanh vừa đủ lớn để khiến tôi tập trung và không quan tâm đến những thứ diễn ra xung quanh.
Rõ ràng với môi trường làm việc phù hợp này tôi đã tăng hiệu suất học tập và nghiên cứu của mình lên đáng kể. Trong khi đây là một phần rất quan trọng thì vẫn có khá nhiều người bỏ qua nó.
Tập trung là một phần cơ bản nhưng có vai trò tiên quyết trong việc giúp bạn thu thập thông tin và tăng cường khả năng ghi nhớ. Khi bạn cố gắng tập trung để tăng cường khả năng ghi nhớ, sức mạnh của việc tiếp thu kiến thức sẽ được liên kết trực tiếp với cường độ tập trung. Khả năng tập trung kém đồng nghĩa với việc bạn sẽ học chậm hơn và mất nhiều thời gian hơn.
Hãy tìm cho mình một môi trường làm việc không khiến bạn bị phân tâm và cho phép khả năng tập trung có thể kéo dài lâu nhất có thể. Dưới đây là một số cách bạn có thể áp dụng để tạo cho mình một môi trường học tập và làm việc tập trung nhất:
Tìm một vị trí mà mọi người ít để tâm và không thể làm phiền bạn.
Cho điện thoại về chế độ im lặng hoặc để chế độ máy bay.
Sử dụng một số loại trình chặn trang web được hẹn giờ cho các trang web truyền thông xã hội và tin tức.
Đeo tai nghe và nghe các bản nhạc có thể tăng cường sự tập trung khi làm việc (tốt hơn hết nên là một danh sách dài các bài hát để tránh khiến bạn phải mất thời gian để chuyển bài).
Nên có một cuốn sổ bên cạnh để ghi chú lại bất kì thông tin mới nào hoặc một ý tưởng nào vừa nảy ra.
Chính bạn sẽ là người biết được đâu là môi trường làm việc tốt nhất với mình. Hãy cố gắng đưa ra những quyết định đúng đắn và tạo cho mình một không gian làm việc giúp tối ưu sự tập trung của bản thân nhé.
Bước ra thế giới bên ngoài và gặp gỡ nhiều người hơn
Công việc lập trình đến với tôi một cách rất ngẫu nhiên. Sau khi chuyển đến nơi ở mới tại Omaha, Nebraska, tôi đã dành khoảng một năm cho việc tự học lập trình. Vì dành quá nhiều thời gian và sự chuyên tâm cho việc học nên tôi không quen biết thêm được nhiều người mới tại đây.
Tôi quyết định tìm kiếm trên Meetup.com những người có cùng sự quan tâm đến việc lập trình android giống mình. Trong buổi giao lưu giữa các nhà phát triển android tôi đã cảm thấy hơi lo lắng và sợ hãi khi nhận thấy mọi người có nhiều kinh nghiệm hơn hẳn tôi và tôi hoàn toàn không đủ tự tin về khả năng lập trình của mình.
Tuy nhiên, may mắn là tôi đã không từ bỏ và tham gia các buổi Meetup này một cách thường xuyên hơn. Và không lâu sau tôi đã gặp một chuyên gia đang tìm kiếm một nhà phát triển trong lĩnh vực Android. Sau một lúc nói chuyện, tôi đã được hẹn đến để tham gia buổi phỏng vấn vào cuối tuần.
Trước khi đến buổi phỏng vấn, tôi đã rất tự tin rằng mình có thể làm tốt. Nhưng, sau khi buổi phỏng vấn diễn ra thì tôi cảm thấy khó khăn hơn hẳn. Người phỏng vấn nói về các dự án mà tôi sẽ phải tham gia và mọi thứ cứ thế lướt qua trong đầu tôi mà thôi. Dù tôi đã cố gắng tiếp tục tham gia nhưng dường như nó nằm ngoài khả năng của tôi. Sau buổi phỏng vấn tôi dành thời gian để thư giãn và suy nghĩ nhiều hơn về các thông tin mà công ty chia sẻ. Kết quả tôi nhận được là họ yêu cầu tôi tham gia vào công ty với vai trò là một thực tập sinh. Tôi thật sự rất bất ngờ với kết quả này.
Nhờ sự cố gắng và nỗ lực không ngừng mà sau khoảng thời gian thực tập, tôi đã được cân nhắc lên làm việc với tư cách một nhân viên chính thức về phát triển phần mềm. Khi bạn tự học, mọi người sẽ không thể nào biết hay tìm kiếm bạn. Bạn sẽ cần phải tự đi tìm kiếm cơ hội cho chính mình. Một sinh viên sau khi tốt nghiệp đại học có thể tận dụng lợi thế mạng lưới công việc do trường cung cấp để tìm việc. Nhưng với những nhà lập trình tự học, đây là một thứ xa xỉ.
Hãy cố gắng tự bước ra ngoài và xây dựng mạng lưới quan hệ cho bản thân để gia tăng cơ hội tìm kiếm những công việc tốt hơn. Bạn có thể xây dựng thông tin cá nhân trên các cổng trực tuyến để nhà tuyển dụng nhìn thấy bạn. Tuy nhiên, tìm việc thông qua những người quen cũng là một cách khá hay ho để bạn có thể tìm thấy những cơ hội việc là tốt nhất.
Các trang web như Meetup.com sẽ là một nơi tuyệt vời để tìm kiếm các hội nhóm dành riêng cho cá nhân và hoạt động theo nhóm. Ngay cả trong thời điểm dịch xảy ra, các buổi họp mặt nhóm online vẫn được tổ chức, cung cấp cho bạn nhiều thông tin có lợi và bổ ích.
Ngoài ra còn có các kênh khác như Slack hoặc Discord cũng là những nền tảng khá phổ biến được nhiều lập trình viên sử dụng để kết nối và mở rộng quan hệ. Khi gặp nhau, hãy thân thiện và chia sẻ về kinh nghiệm bạn với đối phương, đảm bảo để họ có thể biết được mục đích của bạn là đi tìm việc.
Hãy cân nhắc bất cứ cơ hội nào xuất hiện trong cuộc đời mình, vì biết đâu chính cơ hội đó, quyết định đó sẽ là thay đổi con đường sự nghiệp của bạn. Rõ ràng công việc thực tập mà tôi đã nhận trước đó có vẻ không thật sự phù hợp với tôi, nhưng tôi vẫn chấp nhận. Nhờ sự chăm chỉ và tận tâm mà tôi đã có thể lấn sân sang lĩnh vực lập trình một cách nghiêm túc và có cơ hội trở thành một nhân viên fulltime. Quan trọng là bạn cần biết vạch ra những hướng đi ngắn hạn và dài hạn phù hợp cho bản thân.
Điều quan trọng nhất mà tôi muốn chia sẻ là bạn có thể từ những lỗi lầm của mình là để bạn có thể rút ra được bài học cho cá nhân. Hạn chế tối đa những lỗi sai có thể biết trước chắc chắn sẽ giúp ích nhiều hơn cho công việc tương lai của bạn cũng như rút ngắn lộ trình của một công việc thành công. Hi vọng những kinh nghiệm tự học lập trình được chia sẻ sẽ giúp bạn cải thiện mọi thứ tốt hơn.
Bài viết được sự cho phép của tác giả Lê Xuân Quỳnh
Hello mọi người! Trong bài hôm nay chúng ta sẽ phát triển ứng dụng lên một tầm cao mới. Đó là có thể sử dụng ứng dụng offline được. Không cần mạng internet, chúng ta vẫn có thể truy cập dữ liệu đã tải trước đó. Như các bạn thấy, một số ứng dụng tiêu biểu cho việc này là facebook. Khi bạn tắt mạng đi, thì nó vẫn có thể đăng bài, tải các bài trên feed đã lưu trước đó. Trông cũng khá ổn, nó tăng tính trải nghiệm người dùng hơn, chuyên nghiệp hơn đúng không nào?
Vậy thì, hôm nay chúng ta làm điều đó, bằng 1 framework cho database, khá chuyên nghiệp đó là Realm. Vậy realm là gì? Có thể bằng vài câu thì không nói hết được các tiện ích mà framework này mang lại. Tuy nhiên, bạn có thể hiểu nôm na là realm giúp bạn lưu trữ giữ liệu, lôi ra khi cần. Bạn có thể thêm sửa xóa, có thể làm mọi thứ với dữ liệu bạn đã lưu. Rất tiện ích. Để hiểu hơn hãy đọc cẩn thận tài liệu của realm cho ios ở đây:
Trong bài trước, chúng ta đã thêm loading cho phần tìm kiếm để nó chuyên nghiệp hơn. Vẫn còn vài bug nhỏ, nhưng các bạn tự fix xem nhé. Trong bài lần này, tôi sẽ thêm realm vào để lưu trữ toàn bộ kết quả mà bạn đã search vào bộ nhớ. Sau đó mỗi lần search, nếu như nó tìm thấy kết quả đã có trong bộ nhớ, nó sẽ tiến hành lấy kết quả đó và hiển thị vào table, thay vì request lên network.
Đầu tiên như những bài trước, bạn phải tải code tại đây:
Và chuyển qua branch bai4 các bạn nhé. Cách chuyển thì xem lại bài đầu tiên nha.
Rồi bây giờ cùng bắt đầu làm quen và sử dụng realm bằng 1 cách chuyên nghiệp nào.
Xây dựng realm manager
Lớp RealmManager
Hãy xem xét lớp RealmManager mà tôi đã tạo. Source code hơi dài, nhưng đừng lo lắng, tôi sẽ phân tích từ từ từng dòng 1.
Ý tưởng của lớp này như sau:
Tôi muốn tạo 1 lớp quản lý database có đầy đủ tính năng thêm(save), sửa(update), xóa(delete).
Tôi muốn lưu trữ các model kế thừa từ Codable. Bằng việc này tôi có thể lưu thẳng kết quả trả về của API từ server vào realm.
Mỗi model phải có 1 khóa chính để update. Việc save có nghĩa là update 1 model vào realm. Nếu như nó chưa tồn tại thì thêm mới. Nếu nó đã có thì cập nhật vào model đã có sẵn.
OK, khi có realm manager này, các bạn sẽ dễ dàng làm những việc mà mục tiêu của đề bài đã yêu cầu.
Hãy cùng xem code từng dòng nhé:
Đầu tiên để chơi với realm, bạn cần phải cài đặt realm vào Podfile nhé:
Việc cài đặt rất đơn giản, bằng việc bạn mở Podfile ở project rồi thêm dòng 8 vào. Sau đó vào command line và cd vào thư mục source code, gõ: pod install là xong!
Khi cài xong rồi, bạn tạo 1 file có tên là RealmManager.swift, sau đó thêm dòng này vào trên cùng:
import Realm
import RealmSwift
2 dòng trên để các bạn có thể sử dụng realm.
/// Version realm database
enum RealmVersion: UInt64 {
case version1 = 0
}
Dòng trên tôi dùng để update database cho realm. Mỗi khi tôi sửa lại model thì cần migration, liên quan đến cập nhật dữ liệu với model mới. Cái này bạn sẽ quan tâm sau, bài này tôi không nói.
Tôi muốn update database theo khóa chính nên bạn cần có 1 cái RealmRepresentable bắt buộc phải có 1 khóa chính, tôi đặt tên là uid mà mọi object Codable muốn sử dụng realm đều phải có, tôi dùng protocol để làm việc đó. RealmRepresentable giúp bạn luôn phải có khóa chính cho model, đảm bảo model luôn luôn cập nhật được. RealmRepresentable này kế thừa từ Object – một class của realm dùng để xử lý database giống như model. Nếu bạn đã làm qua với sqlite, thì bạn sẽ thấy ưu điểm của realm ở đây, là bạn có thể thao tác với realm như thao tác với model vậy. Không phải select, delete… những câu lệnh khó nhằn của sql.
Protocol các hàm cơ bản của realm service
RealmServiceProtocol là protocol chứa các hàm có thể có của 1 manager. Nhìn tên hàm bạn cũng có thể đoán được ý nghĩa của nó đúng không:
associatedtype Entity: Định nghĩa 1 kiểu trừu tượng, protocol generic placeholder. Nói cách khác nó áp dụng kiểu cụ thể tại thời điểm compile. Nó làm cho code clear hơn nha. Entity chính là model chúng ta cần lưu, cụ thể là class của model codable kế thừa từ Object của realm.
queryAll: Hàm này trả về toàn bộ mảng [Entity]
func query(with predicate: NSPredicate, sortDescriptors: [NSSortDescriptor]) -> [Entity]: Hàm này dùng để truy vấn với điều kiện nào đó và sắp xếp theo yêu cầu nào đó.
func save(entity: Entity) -> Bool: lưu 1 entity vào database.
Ô kê la, vậy là bạn đã hiểu chúng ta sẽ làm gì rồi đúng hông? tất nhiên protocol thì là define thui, còn bây giờ mới tới màn coding thật sự nè. Nào hãy vào lớp RealmManager để xem nhé
Class RealmManager định nghĩa hơi khác 1 chút so với những gì bạn hay làm. Ở đây ta có toán tử <T: RealmRepresentable>, nghĩa là mọi lớp kế thừa lại lớp này đều phải có tính chất của RealmRepresentable, hay nói cách khác nó phải có khóa chính:
var uid: String { get }
RealmManager kế thừa RealmServiceProtocol, nghĩa là mọi hàm chúng ta vừa nói ở trên đều phải định nghĩa cho nó.
typealias Entity = T: Ở đây chúng ta định nghĩa kiểu của Entity là T, là RealmRepresentable, tức là các class có tính chất của RealmRepresentable
Realm.Configuration: Cấu hình tham số cho Realm.
var realm: Realm?: đối tượng realm mà chúng ta sẽ sử dụng để xử lý các tác vụ với database.
Hàm init khởi tạo configuration, trong này chứa việc xử lý việc thay đổi model của realm. Bạn có thể xem thêm ở đây để hiểu thêm.
68->71, nếu không khởi tạo được realm thì trả về rỗng
Nếu không thì lấy mảng Entity và trả về
Hàm lưu Entity
Nếu như không khởi tạo được realm thì trả về false
Nếu không tiến hành lưu entity vào database theo dạng update, nghĩa là nếu chưa có thì thêm mới vào, còn nếu đã tồn tại thì cập nhật. Sau đó refresh lại realm database.
Giả sử quá trình lưu thất bại, tiến hành in lỗi. Ở đây các bạn có thể để lệnh print trong cặp #if DEBUG
Tương tự hàm save 1 chuỗi “func save(entities: [Entity]) -> Bool” cũng như trên, chỉ khác là lưu 1 mảng vào.
Hàm xóa 1 Entity
Tiến hành tìm kiếm entity có khóa chính uid, nếu tìm được thì tiến hành xóa và trả về true. Nếu không trả về false.
Trường hợp xóa lỗi cũng hiển thị lỗi và trả về false.
Tương tự hàm “func delete(entities: [Entity]) -> Bool” dùng để xóa 1 mảng entities.
Hàm xóa toàn bộ Entity
Tiến hành xóa toàn bộ entities trong database và trả về true. Nếu không xóa được báo lỗi và trả về false.
Ở đây các bạn để ý mình viết hàm có phần comment ở trên hàm. Nếu bạn muốn nó sinh tự động có thể đặt con trỏ chuột vào tên hàm và bấm tổ hợp “Option + Command + /”, khi các bạn bấm vào dấu ? bên phải Xcode thì nó ra hướng dẫn của hàm, rất tiện lợi cho việc sinh documents sau này.
Hướng dẫn chuẩn format của Apple
Vậy là chúng ta đã hoàn thành cơ bản lớp RealmManager, base cơ bản để xử lý database trong realm.
Bài đã hơi dài, nên chúng ta sẽ tạm thời dừng ở đây. Trong bài tiếp theo mình sẽ hướng dẫn viết lớp RealmGithubService kế thừa từ RealmManager để xử lý data trả về từ API nhé.
Bàn phím là công cụ không thể thiếu với mỗi lập trình viên. Họ dùng chúng hằng ngày, tiếp xúc với chúng nhiều hơn bất cứ thứ gì khác. Với mỗi người sẽ có những loại bàn phím ưa chuộng riêng tùy theo sở thích, phong cách làm việc của họ. Sau đây là 12 loại bàn phím được rất nhiều lập trình viên muốn sở hữu bởi các style và tính năng riêng biệt mà chúng mang lại. Các bạn sẽ được chiêm ngưỡng những kiểu dáng điển hình nhất của từng thời đại, đã làm nên tên tuổi của các nhà sản xuất và đã gắn bó với giới lập trình trong một khoảng thời gian dài.
Đươc thiết kế với sự chủ đạo là tính đàn hồi, đem lại cảm giác rất thỏa mãn cho người dùng. Các lập trình viênđã từng rất ưa chuộng model này và rất thích thú với âm thanh của bàn phím. Chúng ta có thể bố trí bàn phím này ở nhiều góc khác nhau trên bàn làm việc bởi sự cơ động của nắp chụp phím. Một đặc điểm khác là độ bền của model này gần như là số 1. Đó là lý do nó đã gắn bó với nhiều lập trình viên trong suốt một khoảng thời gian dài.
Nhận xét:
“Bạn thích nó bởi phản ứng của từng phím mang lại cảm giác chắc chắn và sẽ cực kỳ thoải mái khi làm việc khi được nghe âm bàn phím kết hợp với tiếng nháy chuột.” Daniel C.Silvertein
“Nó được thiết kế như một chiếc xe tăng vậy. Tôi có thể gó phím cả ngày mà chẳng hề có dấu hiệu mỏi tay hay những bất cập từ bàn phím nhỏ.” Shog9
“Lợi ích tốt nhất mà nó mang lại là giảm bớt lỗi chính tả. Rất dễ dàng để gõ phím và tôi đã mắc ít sai lầm hơn.” AppDevGuy
“Model M mang lại cho bạn cảm giác tốt nhất khi gõ phím.” Falcon
Northgate OmniKey (1993)
Rất nặng, chắc chắn và rất bền. Nó dễ dàng cấu hình lại và khi lập trình nó cung cấp cảm giác thỏa mãn về xúc giác. Các lập trình viên thường so sánh nó với M. IBM
Nhận xét:
“Từng phím được xây dựng rất kiên cố với một công tắc cho phép bạn điều chỉnh mọi thứ, giống như bàn phím Drovak với loại phím đính được sử dụng từ những ngày xa xưa.” James Wan
“Mọi thứ được bố trí tuyệt vời, đó là một nền tảng vững chắc. Các phím có sức chịu đựng lớn. Bạn có thể dễ dàng ghi nhớ vị trí các phím và lắp ghép lại nó nên việc tháo gỡ, làm sách thực sự rất đơn giản.” Anonymous
“Nó nặng khoảng 6 pounds và cảm giác như được xây từ một khối thép. Đặc điểm chính là độ sắc nét, nó cho tôi cảm giác như được đánh máy trên chiếc IBM Selectric II nơi mà có một nam châm điện hay một cái gì đó ném phịch fontball (1 loại font chữ) vào con lăn với mỗi phím tắt. Rất nhanh chóng, tích cực. Tôi nhớ như in điều đó.” Jeff Paulsen
Datahand (1992)
Nó rất tiện dụng, cho phép các vị trí tay tùy chỉnh. Mỗi tay bạn có thể tiếp cận đến 5 phím chính và sử dụng tích hợp chuột.
Nhận xét:
“… nó không khó để tìm hiểu, là một loại keyboard tương tự như QUERTY. Khi tôi bắt đầu bị RSI, nó đã giúp tôi rất nhiều.” Spellboot
“Nó rất đáng để bạn trả tiền. Lý do chính tôi sử dụng nó là bởi bàn phím này có tích hợp chuột nên tôi có thể ngồi cả ngày bên máy tính mà chỉ phải di chuyển tay một chút.” User93422
“Những chiếc Datahand dành cho những người muốn code tất cả trong một ngày mà không hoàn thành công việc với ngón tay chảy máu hoặc bị RSI vào buổi tối.” Jan Goyvaerts
Note: RSI – Repetitive strain injury, một căn bệnh có triệu chứng là sưng ngón tay, cứng khớp,…do gõ bàn phím và đẩy chuột nhiều trong ngày.
Happy Hacking (1996)
Nhỏ gọn, dễ dàng bấm phím và các vị trí quan trọng được tối ưu cho người sử dụng Unix chẳng hạn như việc kiểm soát các chữ in hoa.
Nhận xét:
“… có các phím điều khiển ở vị trí đó có thể tránh được tình trạng gọi là Emacs Pinky” Simon Howard
“Tôi có vài chiếc trong số model này và tôi thấy chúng giúp tôi giảm bớt gánh nặng của cổ tay nhờ việc có thể dễ dàng di chuyển ở không gian xung quanh”
Type Matrix (1997)
Có các phím dọc thẳng thay vì so le, giúp giảm thiểu cử động tay và căng thẳng lặp đi lặp lại cũng như việc phím Enter và Space gần vị trí của ngón trỏ thay vì ngón cái. Kích thước nhỏ cũng làm giảm chuyển động cần thiết khi bạn muốn dùng tới chuột.
Nhận xét:
“ Các nút nằm ở vị trí kẻ ô thay vì nằm chéo nhau khiến tôi dễ dàng hơn trong việc gõ phím.” Maudite
“Enter và BackSpace nằm gần vị trí ngón trỏ của tay giúp bạn dễ dàng hơn trong việc giữ vị trí, giảm bớt các chuyển động của tay.” Kris
“Tất cả mọi người đều nghĩ tôi đã bị điên khi sử dụng nó. Nhưng thực sự rất tuyệt vời khi được trải nghiệm bàn phím này.” Jason Baker
Kinesis Advantage (2002)
Cách bố trí tiện lợi đúng như cái tên của nó; các phím không chữ được đặt ở phía trung tâm giúp giảm thiểu các tổn thương có thể gặp phải. Phím của nó có thể được sắp xếp lại và dễ dàng chuyển đổi thành kiểu QWERTY hay Drovak.
Nhận xét:
“Loại Kinesis làm cong các ngón tay của bạn. Khi dùng chúng, cổ tay của bạn như có được đệm lót và thực tế ngón tay cái được sử dụng rất tự nhiên chứ không phải vật đẩy cho nút Space nên sẽ giúp phân bổ công việc dễ dàng cho giữa các ngón tay.” Heptadecagram
“Tôi đã đổi chỗ Backspace và Delete Alt và việc gõ bàn phím đã trở nên đơn giản hơn bao giờ hết.” Kevin Cline
“Cổ tay của tôi gần như không phải làm việc và điều này làm công việc của tôi thoải mái hơn rất nhiều. Tôi thực sự rất thích nó.” Dean J
Bài viết được sự cho phép của tác giả Edward Thien Hoang
Là dạng kiến trúc rất phổ biến ngày nay, chắc chắn ai cũng đã từng nghe qua về kiến trúc 3 lớp, MVC, MVVM,… Tất cả đều có chung một mục đích là tổ chức, phân rã mã nguồn theo nhiều chức năng và nhiệm vụ khác nhau trong hệ thống.
Trong các hệ thống hướng đối tượng, UI, Database và các dạng mã khác thường được viết trực tiếp vào trong logic nghiệp vụ. Và theo chiều ngược lại, mã nghiệp vụ lâu lâu lại được nhúng vào trong UI, DB code. Không có sự phân cấp rõ ràng dẫn đến sự phức tạp trong tổ chức, quá nhiều phụ thuộc lẫn nhau giữa các mã nguồn. Sở dĩ điều này diễn ra là vì lập trình nó rất dễ và nhanh.. nhưng chỉ là lúc mới bắt đầu. Khi các đoạn mã liên quan đến nghiệp vụ được dàn trải ở khắp nơi, điều này sẽ trở nên rất phức tạp và rất khó để đọc hiểu được nghiệp vụ. Thay đổi trên giao diện người dùng cũng có thể làm thay đổi business logic. Để thay đổi business logic, chúng ta phải đi ngược lên các mã UI, cơ sở dữ liệu hoặc các phần tử của chương trình khác để xem những chỗ cần phải thay đổi theo. Điều này không cần nói cũng đủ hiểu nó gây ra khó khăn như thế nào.
In an object-oriented program, UI, database, and other support code often gets written directly into the business objects. Additional business logic is embedded in the behaviour of UI widgets and database scripts. This happens because it is the easiest way to make things work, in the short run.
When the domain-related code is diffused through such a large amount of other code, it becomes extremely difficult to see and to reason about. Superficial changes to the UI can actually change business logic. To change a business rule may require meticulous tracing of UI code, database code, or other program elements. Implementing coherent, model-driven objects becomes impractical. Automated testing is awkward. With all the technologies and logic involved in each activity, a program must be kept very simple or it becomes impossible to understand.
Không biết và không phụ thuộc vào các lớp bên trên sử dụng nó;
Trong kiến trúc phân lớp, các layer có thể được design theo hướng nghiêm ngặt, một layer chỉ có hiểu biết và sử dụng layer ngay bên dưới nó, hoặc theo hướng linh hoạt hơn, nghĩa là một layer có thể sử dụng tất cả các layer ở dưới nó. Cả Martin Fowler và tôi đều tán đồng cách thứ 2 để tạo nên sự linh hoạt, tránh phải tạo ra các proxy method (hoặc thậm chí là proxy class) trong các layer trung gian chỉ để truyền tải thông điệp từ lớp bên trên nó xuống lớp phía dưới nó. Việc sử dụng các layer trung gian như vậy được coi là 1 anti-pattern với tên gọi Lasagna Architecture.
Đôi khi các layer được thiết kế sao cho domain layer hoàn toàn không muốn presentation layer biết đến data source layer. Tuy nhiên, và thường xuyên, presentation layer nên truy cập trực tiếp đến data source layer. Mặc dù điều này không tinh khiết, nhưng nó có xu hướng hoạt động tốt hơn trong thực tế.
Sometimes the layers are arranged so that the domain layer completely hides the data source from the presentation. More often, however, the presentation accesses the data store directly. While this is less pure, it tends to work better in practice.
Chúng ta chỉ cần hiểu những lớp bên dưới lớp chúng ta đang làm;
Mỗi lớp có thể được thay thế bởi một thể hiện tương đương (equivalent implementation), không ảnh hưởng đến các lớp khác;
Một lớp có thể được sử dụng bởi một số lớp cấp cao khác nhau.
NHỮNG BẤT LỢI LÀ:
Lớp không thể đóng gói (encapsulate) tất cả mọi thứ (một field được thêm vào UI, rất có thể cũng cần phải được thêm vào DB);
Các lớp bổ sung (extra) có thể gây ảnh hưởng đến hiệu suất, đặc biệt nếu ở các tier khác nhau.
Cùng điểm qua sự tiến hóa của kiến trúc phân lớp qua các thời kỳ
NHỮNG NĂM 60 VÀ 70
Những application lúc đó (hầu như) hoàn toàn khác với ngày nay. Chẳng có GUI (cái chỉ mới xuất hiện vào những năm đầu thập nên 90), tất cả application được sử dụng thông qua CLI (Command-line interface) dưới dạng cửa sổ console với nhiệ vụ đơn giản là nhận input (bàn phím) từ người dùng và xuất ngược trở ra màn hình. Cũng chẳng có khái niệm Client-Server, tất cả được đóng gói thành một bản cài đặt trên từng máy trạm.
Vì ứng dụng lúc đó quá đơn giản nên chẳng ai buồn nghĩ tới chuyện phân tách layer/tier này nọ làm gì. Ta có thể gọi các ứng dụng lúc đó với kiến trúc 1 layer, 1 tier, chúng không thể mở rộng (scalable), ví dụ, nếu chúng ta muốn cập nhật phiên bản mới, thì chỉ có cách là cài đặt chúng trên từng máy trạm (client)
GIAI ĐOẠN NHỮNG NĂM 80 VÀ 90
Giai đoạn này đã bắt đầu xuất hiện các ứng dụng dành cho doanh nghiệp (enterprise) với lượng người sử dụng dùng máy tính cá nhân (desktop computer) để truy cập vào ứng dụng thông qua network.
CÓ 3 LAYERS ĐƯỢC CHIA RA:
User Interface (Presentation): là những chương trình chạy trên desktop / CLI hoặc các web page. Các chương trình client lúc này thường là các rich client (nơi luồng công việc và kiểm tra input đầu vào đặt ở client)
Business Logic (Domain): là nơi đặt các logic về nghiệp vụ chính của hệ thống, layer này sẽ tiếp nhận các request từ phía Client, xử lý và lưu trữ data thông qua Data source layer.
Data source: nhiệm vụ chính của layer này là thực thi các tác vụ lưu trữ dữ liệu và liên lạc với các applications khác (được request từ business logic layer).
Đây chính là mô hình 3 lớp (3-layers) kinh điển chúng ta đã từng biết khi còn là sinh viên. Tuy nhiên xét về mặt các lớp vật lý (tier) thì ứng dụng thường được tổ chức ở mức 2 tier hay còn gọi là Client-Server. Client side sẽ chứa Presentation layer, Server side sẽ chứa Business logic layer and Data source layer.
Kiến trúc này có thể giải quyết các vấn đề về mở rộng, tuy nhiên vẫn còn hạn chế. Các ứng dụng dạng rich-client khi được cài đặt ở một số lượng lớn máy trạm thì việc update, mở rộng sẽ gặp nhiều khó khăn.
VÀO GIỮA NHỮNG NĂM 90
Đây là giai đoạn thế giới công nghệ có những chuyển biến mạnh mẽ. từ những năm 95 đến 2005, thế giới bắt đầu dịch chuyển lên “mây”. Số lượng người dùng tăng lên, độ phức tạp về ứng dụng tăng lên, vấn đề về cơ sở hạ tầng cũng ngày càng phức tạp. Từ đó dẫn đến việc cải tiến các mô hình kiến trúc sao cho phù hợp với nhu cầu, kiến trúc phân lớp vào thời điểm này được biến đổi như sau:
Web browser: làm nhiệm vụ render và gửi / nhận request tới server.
Application server: chứa presentation layer, the application layer, the domain layer, và the persistence layer.
Database server: được tối ưu cho mục đích lưu trữ dữ liệu
Đây là một architecture pattern 3 lớp vật lý (3-tier) hay n-tier. Tất cả logic điều được move lên phía server, do đó giải quyết triệt để vấn đề về mở rộng, client bây giờ chỉ làm nhiệm vụ render mà không cần biết các thay đổi từ server ra sao.
NHỮNG NĂM 2000 TỚI NAY
Domain Driven Design là từ khóa rất hot trong giới kỹ nghệ lập trình. Eric Evan là người khởi xướng thuật ngữ này vào năm 2003 với cuốn sách nhan đề: Domain-Driven Design: Tackling Complexity in the Heart of Software. Cuốn sách chứa đựng rất nhiều khái niệm ảnh hưởng sâu rộng đến cách chúng ta định hình nên các bản thiết kế hiện nay.
User Interface
Chịu trách nhiệm trong việc render và truyền tải thông điệp từ client tới server. Client ở đây có thể là người dùng hoặc những application khác, gần giống với khái niệm Boundary object trong bài viết về EBI Architecture của Ivar Jacobson, chúng ta sẽ làm rõ thêm khái niệm này.
Application Layer
Gọi là Facede Layer cũng được. Điều khiển luồng công việc (use-case) bằng cách thực thi và kết hợp (Orchestrates) các Domain object. Nó không chứa business logic. Nó liên quan đến khái niệm Interactors trong EBI Architecture, ngoại trừ 1 điều là các interactors là bất kỳ object nào không phải là UI hoặc Entity.
Có 1 từ rất hay đó là Orchestration, nó được dùng trong SOA/ESB như là một điều phối viên. Ví dụ, Application Layer nhận 1 request từ Presentation, nó phải gọi xuống Domain Layer để thực hiện công việc đó, nhưng không đơn giản là 1 lời gọi đơn giản xuống Domain Layer, mà nó cần phải biết gọi Domain object nào, bao nhiêu Domain object để có thể thực hiện xong công việc, và trả về dữ liệu cho Presentation. Cho nên mình gọi nó là Application Services và Domain Services Layer.
Domain Layer
Layer này chứa các logic liên quan đến nghiệp vụ của ứng dụng, các Entities, Events, và bất cứ object nào handle logic nghiệp vụ. Rõ ràng, nó giống như Entiy trong EBI Architecture; là trái tim của cả hệ thống.
Infrastructure
Các common technical facilities dùng chung cho cả hệ thống, ví dụ như logging, persistance, messaging…
ANTI-PATTERN: LASAGNA ARCHITECTURE
Là tên gọi cho anti-pattern trong kiến trúc phân lớp, khi:
Chúng ta quyết định đề ra các chính sách nghiêm ngặt về việc liên lạc giữa các layer (một layer chỉ có thể liên lạc với layer ở dưới ngay nó). Trong trường hợp như vậy, rất có thể ta phải tạo ra rất nhiều proxy method, proxy class trong các layer trung gian cốt chỉ để by-pass việc communication này, gây tốn công và khó chịu khi làm việc. Vì vậy, hãy giảm bớt sự nghiêm ngặt để có thể trực tiếp đi thẳng tới các layer phía dưới nó mà không cần qua trung gian.
Một thay đổi nhỏ cũng có thể gây ảnh hưởng đến cả hệ thống. Ví dụ việc refactor lại 1 layer nào đó có thể gây ra hậu quả to lớn so với lợi ích nhận lại.
Tạo quá nhiều layer dẫn đến việc phức tạp cho cả hệ thống.
Có quá nhiều tier sẽ dẫn đến sự phức tạp và giảm performance trong hệ thống.
Chúng ta tổ chức, đóng gói layer theo chức năng kỹ thuật (functional) của nó, ví dụ như UI, Domain, DB,.. mà không chia theo chức năng nghiệp vụ (component) như Product, Payment, Checkout, làm mất đi khả năng module hóa và đóng gói (encapsulation) theo domain concept.
KẾT LUẬN
Layered Architecture là một cách chia để trị mối quan tâm, đóng gói và tách riêng, bằng cách nhóm các đơn vị mã bằng vai trò chức năng của chúng trong ứng dụng.
Tuy nhiên, như hầu hết mọi thứ trong cuộc sống, quá nhiều sẽ phản tác dụng! Vì vậy, quy tắc của ngón tay cái (rule-of-thumb) là: Chỉ sử dụng các lớp chúng ta cần, các lớp chúng ta cần, và không có gì nhiều hơn nữa! Chúng ta không được đuổi theo đuổi một chén thánh kiến trúc, cái không hề tồn tại. Những gì tồn tại là một nhu cầu, và sự phù hợp tốt nhất có thể cho nhu cầu đó. Đó là một phần của Lean, tiện thể.
Hơn nữa, điều quan trọng cần lưu ý là phương pháp tiếp cận top/down này đã lỗi thời. Không còn là những gì chúng ta nên làm trong phát triển phần mềm hiện đại, có những cách nghĩ mới và tốt hơn về một lớp ứng dụng. Tôi sẽ nói về sau đó trong bài viết sau.
Đây là bài viết trong loạt bài viết về “Tổng quan về sự phát triển của kiến trúc phần mềm“. Đây là loạt bài viết chủ yếu giới thiệu về một số mô hình kiến trúc phần mềm hay nói đúng hơn là sự phát triển của chúng qua từng giai đoạn, qua đó giúp chúng ta có cái nhìn tổng quát, up-to-date và là roadmap để bắt đầu hành trình chinh phục (đào sâu) thế giới của những bản thiết kế với vai trò là những kỹ sư và kiến trúc sư phần mềm đam mê với nghề.
Bài viết được sự cho phép của tác giả Nguyễn Văn Trọng
Câu hỏi đặt ra : học công nghệ đó để làm gì (nghe quen quen kiểu “làm từ thiện để làm gì”). Nếu học vì đam mê, yêu thích nó thì mình không bàn tới. Phạm vi bài viết này chỉ giới thiệu xu hướng công nghệ đang hot với BrSE ở thời điểm hiện tại và vài năm tới (ở Nhật), tức là dù không mê hay thậm chí …ghét cay ghét đắng cũng nên học. Mình sắp xếp theo 3 mảng : Maintain, Migartion, Development.
Hiện tại các hệ thống quản lý nội bộ công ty – quản lý khách hàng thuộc các domain như y tế, giáo dục, ngân hàng … đang lạc hậu trầm trọng về mặt tính năng, tính tương thích nhưng để làm mới là việc quá rủi ro vì hệ thống quá lớn đã được vận hành hàng thập kỷ. Khách hàng Nhật có tính chắc ăn trong mọi việc nên thường họ chọn cách làm maintain hệ thống cũ, tức là làm mới giao diện người dùng, thêm 1 vài tính năng mới…
Có nhiều ngôn ngữ nhưng 3 loại phổ biến nhất mà BrSE theo mảng maintain cần nắm.
Java
Khỏi cần nói nhiều vì Java quá phổ biến.
Cobol
Ngôn ngữ cũ ríc này hiện nay vẫn chưa tắt thở vì 1 lợi thế quá lớn về mặt performan. Và các hệ thống to đùng hầu hết tầng bên dưới đều dùng anh này.
VB
Một trong những ngôn ngữ lập trình hướng đối tượng ra đời sớm nhất, và được ứng dụng rộng rãi trong nhiều hệ thống quản lý nội bộ công ty. Và 1 điều mình cũng khá ngạc nhiên là đến bây giờ vẫn rất nhiều bác khách hàng thích VB, lý do có thể là do quen dùng.
Migration
Mảng này thường trải rất rộng. 1 hệ thống thường ứng dụng nhiều ngôn ngữ ở các tầng khác nhau vì mỗi loại có ưu nhược riêng. Ở tầng giao diện ASP, JSP, PHP khá phổ biến, còn tầng dưới (xử lý nghiệp vụ) thì Java, C#, VB. Về database thì có 3 ông lớn : DB2 (IBM), SQL, Oracle.
Các chuỗi Migration thường gặp
Java : từ các version cũ như 3,4 lên Java 7/8
ASP : từ ASP qua ASP.net, hoặc từ ASP.net version 2/3.5 lên ASP.net ver 4.5
VB (lại là VB) : từ VB4/VB6 lên VB.net hoặc từ VB.net ver thấp lên cao
Database : DB2 hoặc Oracle qua SQL, hoặc Oracle/SQL từ ver thấp lên cao. Thời điểm hiện tại thì Oracle 11 vs SQL 2012 là 2 bản database ổn định và được chọn làm đích upgrade.
Migration lên Cloud : đang cực kỳ HOT. Azure hoặc AWS là 2 dịch vụ mà bạn cần phải nắm vững nếu muốn nhảy vào mảng này. Mình nhắc lại thêm 1 lần nữa : nó rất rất hot – còn hơn cả Ngọc Trinh
Development
Phát triển mới hiện tại đang nhắm vào 3 mảng lớn : Web, Mobile và Embedded (lập trình nhúng). Thường đối với các dòng dự án phát triển mới thì BrSE sẽ tham gia từ design, vậy nên kỹ năng viết – trình bày tài liệu bằng tiếng nhật hay làm prototype (excel/html) quan trọng không kém ngôn ngữ – cộng nghệ.
Làm develop sướng hơn so với maintain và migration. Maintain là công việc khá nhàm chán (quan điểm cá nhân), còn migration thì khá là căng thẳng – vì nó trải rộng làm BrSE phải xì khói ra đào sâu từng chi tiết nhỏ khác biệt giữa các ngôn ngữ -cũng như giữa các version trong cùng thể loại, cộng thêm luôn dính phải anh Maintain :(.
Các ngôn ngữ phổ biến :
Mảng WEB
JavaScript: không chạy đâu được với anh này mặc dù anh hơi sida (nói theo cách toidicodedao). Đi kèm với nó là JQuery, Note.js, Angular.js, KnockOut. Các bạn nên chọn 1 Framework để học và làm tốt nó.
JSP
PHP
HTML 5
Ruby-on-rails : bên cạnh những ngôn ngữ truyền thống thì anh này hiện tại đang thấy khá hot, các nhà tuyển dụng săn mấy ông BrSE Ruby rất kinh, tức là thấy mặt cái tóm qua JP luôn – khỏi nói nhiều
Mảng Mobile
Android
IOS
Mảng này mình không rành nhiều nhưng có 1 điều chắc chắn là : không nên theo Window Phone.
Mảng Nhúng
C/C++
CAD, CAM
Có 1 điều thú vị là các dự án chuyên về ô tô, chip, smart tivi thì có nhu cầu rất lớn những bạn học điện tử viễn thông hay cơ điện tử.
Tổng Kết
Những liệt kê ở trên có thể không đầy đủ vì kiến thức còn hạn hẹp, nhưng mình nghĩ khá sát so với thực tế dựa theo kinh nghiệm 6 năm làm dự án với các bác Nhật. Ngoài ra có 1 điều đặc biệt quan trọng là mọi ngôn ngữ có thể học được rất nhanh nếu như nắm được cốt lõi. Ví dụ chỉ cần ngon JQuery thì mất thêm vài tuần là dùng được Angular.js.
Vậy nên nếu đang làm dự án với ngôn ngữ – công nghệ nào thì tốt nhất là cứ tập trung tối đa vào nó, lên lé vồ master thì dù nó không hot cũng thuộc hàng độc, cơ hội từ từ sẽ đến – trời đất không phụ người chăm chỉ
Bài viết được sự cho phép của tác giả To Thi Van Anh
Bài cuối cùng trong chuỗi mind map “lười biếng” này của mình xin được chia sẻ với các bạn những tổng hợp cơ bản nhất về Selenium IDE, cái add-on ai cũng nghĩ là dễ này. Lưu ý nho nhỏ cho các bạn là từ FireFox 55 trở đi thì Selenium IDE không được hỗ trên đó nữa. Muốn dùng thì các bạn phải sử dụng FF phiên bản thấp hơn nhé! Chi tiết có thể đọc thêm ở đây nha.
Updated 28.5.2018: Selenium IDE – tiện ích mở rộng dành cho trình duyệt Firefox hiện giờ đã update và thay đổi hình hiển thị của icon, và lưu ý là phiên bản của trình duyệt cần sẽ phải từ Firefox 56 trở lên chứ không phải Firefox 55 nữa nha.
Nhưng mà dù sao thì mình vẫn tổng hợp lại bài này coi như là một phần kiến thức đã học được, biết đâu là sẽ dùng nó vào một ngày nào đó hoặc là có vào dĩ vãng thì cũng có chút kỉ niệm về nhau hehe!
Hi vọng là các bạn sẽ thích bài này và một lần nữa mình vẫn mong nhận được những ý kiến đóng góp từ các bạn để các bài viết của mình được hoàn thiện hơn!
Bài viết được sự cho phép của blogchiasekienthuc.com
Chào anh em, đối với dân lập trình nói riêng và dân IT nói chung thì việc học và tiếp thu kiến thức mới mỗi ngày là một việc vô cùng quan trọng.
Mình có một bài viết chia sẻ về việc: lập trình viên có nên học nhiều hơn một ngôn ngữ lập trình không? Nếu bạn nào muốn đọc thì có thể tham khảo tại đây nhé:
Vậy một câu hỏi đặt ra lúc này là, nếu học nhiều thứ cùng một lúc thì phải học làm sao cho hiệu quả? Học như thế nào để có được kết quả tốt nhất?
Mình tin đây là câu hỏi mà mọi người đều trăn trở, một câu hỏi mà ai cũng muốn biết được câu trả lời chính xác nhất ᵔᴥᵔ Vâng, thực ra mỗi người sẽ có một cách học khác nhau.
Và ở trong bài viết này, mình sẽ chia sẻ với bạn một số phương pháp mà mình thấy mọi người và bản thân mình đã áp dụng, nó mang lại hiệu quả khá cao đối với cá nhân mình.
Cụ thể thì mình sẽ nói về cách tiếp cận và cách học một ngôn ngữ lập trình mới sao cho hiệu quả nha.
#1. Định hình loại ngôn ngữ lập trình
Đây là một bước tuy đơn giản nhưng nhiều anh em bỏ qua mà cứ thế lao đầu vào học cú pháp của ngôn ngữ luôn.
Vậy thế nào là định hình loại ngôn ngữ lập trình? Thực ra, ngôn ngữ lập trình được chia thành nhiều loại với nhiều mục đích và bản chất khác nhau.
Mình giả sử như bạn đang là một lập trình viên front-end (làm về giao diện) – như vậy bạn phải biết về JavaScript và cách dụng một Framework của nó (VueJS, ReactJS, Angular…)
Còn nếu bạn muốn học thêm về Back-end thì bạn chọn Java để học. Thực tế thì JavaScript và Java chả liên quan gì với nhau cả. Vậy nên việc bạn áp dụng cách học JavaScript cho Java sẽ không bao giờ đem lại hiệu quả cao được.
Vì vậy mà, trước khi học một ngôn ngữ lập trình mới thì bạn nên xác định ngôn ngữ đó thuộc loại nào (ngôn ngữ biên dịch hay thông dịch, bậc cao hay bậc thấp, có hướng đối tượng hay không…)
#2. Nắm được cú pháp cơ bản
Phần đa ngôn ngữ lập trình có cú pháp khác nhau và đây cũng là một trong những điểm quyết định ngôn ngữ lập trình có dễ học hay không.
Mình lấy ví dụ, nếu các bạn đem so sánh cú pháp của Python và Java thì chắc chắn 90% các bạn sẽ chọn học Python, đơn giản là vì cú pháp của Python tương đối dễ hiểu và dễ học cho người mới.
Nhưng xét cho cùng, dù là ngôn ngữ lập trình nào thì về cơ bản nó cũng sẽ có biến, có hàm, có các câu lệnh điều kiện và các cấu trúc dữ liệu.
Thứ bạn cần học đầu tiên đó chính là, nắm được cách mà ngôn ngữ lập trình triển khai các khái niệm cơ bản đó.
Nếu bạn đã có nền tảng vơi một ngôn ngữ lập trình nào đó trước rồi thì việc học và nắm được các khái niệm này sẽ không mất quá nhiều thời gian đâu.
Nhưng bạn đừng chỉ học theo kiểu biết cách viết, mà bạn phải học làm sao để biết cách dùng và áp dụng vào các ví dụ thực tế (để làm được điều này thì các bạn hãy thực hiện giải các bài toán cơ bản nhé).
#3. Làm một vài project với những gì học được
Sau khi đã nắm được hòm hòm về cú pháp rồi thì đã đến lúc các bạn nên làm ra một ứng dụng hay một chương trình nào đó từ những gì mà các bạn học được.
Câu hỏi ở đây là: tại sao không học sâu hơn nữa, vì nắm được cú pháp thì đã làm được gì đâu? Mình tin chắc nhiều bạn sẽ có thắc mắc như vậy, nhưng mình cũng đặt ngược lại cho các bạn một câu hỏi là học sâu nữa thì bạn định học đến bao giờ?
Học phải đi đôi với thực hành, hơn nữa khi làm ra được cái gì đó (có kết quả) thì bạn sẽ có động lực để học tiếp, vì nó giống như là một thành quả cho sự cố gắng của bạn vậy.
Quay lại với câu hỏi là làm sao để làm được một project với những gì mà các bạn có trong tay, khi mà chỉ là cú pháp của ngôn ngữ?
Thì đơn giản thôi, bạn có thể xem các video hướng dẫn trên mạng, đọc một bài tutorials nào đó mà người ta hướng dẫn chi tiết rồi làm theo, hoặc đơn giản là làm theo cách của các bạn.
Chắc chắn sẽ có chỗ các bạn chưa hiểu đâu, mình cá là như vậy! Nhưng đừng vội dừng lại, hãy cứ làm cho đến khi các bạn ra sản phẩm nhé.
#4. Ngồi xem lại các Project vừa làm
Nếu các bạn chỉ dừng lại ở bước làm theo như ở bên trên thì coi như các bạn chỉ dừng lại ở việc học thuộc cú pháp và làm theo người ta mà thôi.
Và nếu là như thế thì bạn sẽ không bao giờ có thể tiến bộ được bởi vì các bạn chưa biết cách biến code đó thành code của các bạn.
Chính vì vậy, sau khi làm xong các project rồi thì các bạn hãy ngồi lại và review chúng xem mình đã học được gì, tại sao người ta lại code như thế, mình có thể code hay hơn không, hoặc làm sao để thay đổi đi cho khác?
Đây giống như là bước để các bạn tổng hợp lại kiến thức vậy, vì bản chất, nếu cứ học chay mà không làm cái gì đó thì các bạn sẽ không thể biết được kiến thức mà bạn học được áp dụng vào đâu và áp dụng như thế nào.
Mình nhắc lại lần nữa, đây là một bước cực kỳ quan trọng nha, các bạn hãy cố gắng ngồi xem lại những gì minh đã làm chứ đừng vội nhảy qua làm project khác luôn.
#5. Chịu khó đọc docs để hiểu sâu hơn, rộng hơn
Sau khi xem lại những gì mà bạn đã làm thì mình đảm bảo với các bạn là bạn vẫn chưa hiểu hết 100% đâu ᵔᴥᵔ, mà muốn hiểu tường tận hơn buộc các bạn phải đọc tài liệu về em nó.
Bản chất của các bài hướng dẫn hay các video hướng dẫn là họ hướng đến việc các bạn làm theo và làm ra một cái gì đó có thể giống hoặc khác một chút so với người ta.
Kể cả khi bạn có ngồi xem lại thì đó vẫn là ý tưởng của người ta chứ không phải là ý tưởng hay kiến thức của bạn.
Vì vậy, bước đọc tài liệu (là các tài liệu chi tiết của ngôn ngữ lập trình đó, thường là documments do chính đội ngũ phát triển viết) là bước RẤT QUAN TRỌNG nếu bạn muốn trả lời cho câu hỏi: tại sao người ta lại code như vậy trong mục #4.
Có thể đọc tài liệu sẽ hơi chán một xíu do phần đa tài liệu không phải là hướng dẫn mà thiên về giải thích, nên đôi khi hơi dài và nhiều chữ.
Nhưng các bạn hãy cứ kiên trì đọc và mình tin chắc nếu đọc và hiểu thì các bạn sẽ ngỡ ra rất nhiều điều đó.
#6. Phát triển hoặc tối ưu các Project đã làm
Sau khi làm theo và hiểu được người ta làm như thế nào rồi thì đã đến lúc các bạn nên tự làm một project nào đó.
Về mặt ý tưởng, tốt nhất vẫn nên là ý tưởng của riêng các bạn. Nhưng nếu bạn không có ý tưởng gì thì các bạn có thể tham khảo trên mạng.
Sau khi có ý tưởng rồi thì dựa vào những gì đã học được, bạn hãy cố gắng tự làm từ đầu đến cuối project đó (tất nhiên cũng có những chỗ phải xem lại nhưng hãy cố gắng đừng copy – paste nhé). Có như thế bạn mới hiểu sâu và nhớ lâu hơn.
Tất nhiên đây là giai đoạn khó nhất, mình đã từng trải qua rồi nên mình hiểu rất rõ, bạn buộc phải tự mình tư duy, tự mình mày mò tìm kiếm cách giải quyết khi có vấn đề.
Nhưng nếu làm tốt bước này thì có thể nói là bạn đã thành công trong việc học một ngôn ngữ lập trình mới.
#7. Lời kết
Đó là một quy trình 6 bước giúp bạn học một ngôn ngữ lập trình mới được hiệu quả hơn.
Mình xin nhắc lại lần nữa là mỗi người sẽ có một phương pháp học tập khác nhau và mình chỉ đang chia sẻ những gì mà mình và nhiều người khác từng làm và nó đem lại hiệu quả.
Các bạn có thể áp dụng một cách linh hoạt nếu cảm thấy 6 bước trên phù hợp với cách học của các bạn. Xin chào và hẹn gặp lại các bạn trong các bài viết tiếp theo nha !
À quên, bạn đang sử dụng phương pháp nào để tiếp cận với các ngôn ngữ lập trình mới? Rất hi vọng bạn sẽ chia sẻ cho anh em cùng biết cách học tập của bạn, để anh em cùng học hỏi và trao đổi thêm. Thank you !
Bài viết được sự cho phép của tác giả Lê Xuân Quỳnh
Hello guys! Lại là mình đây
Trong bài trước, chúng ta đã học cách viết 1 lớp network layer rất chuyên nghiệp để call API, clear và simple. Hôm nay chúng ta sẽ tinh chỉnh cho app chuyên nghiệp hơn.
OKey, vậy chúng ta hãy cùng bắt đầu nhé. Đầu tiên như các bài trước bạn hãy checkout source code tại đây:
https://github.com/codetoanbug/MVVMSample.git
Vui lòng đọc cách chuyển sang branch bai3 dựa vào các bài trước để xem code nhé.
Hãy cùng bắt đầu nhé
Thêm phần loading cho search
Như các bạn thấy, thì các mục search trên các ứng dụng như facebook, google, họ thường hay thêm indicator hiển thị loading để người dùng chờ đợi. Vì thế mà ứng dụng của chúng ta cũng nên có cái này để tăng trải nghiệm người dùng. Chứ mà không có thì ai biết ứng dụng có đang working hay không.
Phần loading sẽ show khi người dùng bắt đầu search, và sẽ ẩn đi khi đã kết thúc tác vụ search. Vì thế chúng ta sẽ sửa lại giao diện như sau:
Thêm indicator
Trong hình trên, chúng ta sẽ thêm 1 indicator ở dưới ô search và trên ô table. Tôi đưa indicator và tableview vào 1 stack view vì khi indicator show/hide, thì tableview sẽ tự động full màn hình.
topIndicator: Show lên khi người dùng nhập text để search
bottomIndicator: Show lên khi người dùng scroll xuống dưới cùng để load thêm dữ liệu
OK, vậy bây giờ xử lý logic nó như thế nào?
2. Xử lý logic search
Khi chúng ta gõ text, thường sẽ đợi khoảng 0.5s khi gõ xong rồi mới gọi API, để giảm tải số lần call API tới server, và đỡ người dùng bấm nút search rồi mới search nha.
Khi có kết quả trả về, indicator cần ẩn đi.
Khi người dùng cuộn table, bàn phím cần ẩn đi
Kiểu bàn phím là search
Okey vậy chúng ta sẽ làm lần lượt từng yêu cầu trên.
Đầu tiên khi bạn muốn search sau 1 khoảng thời gian thì bạn cần có 1 timer để đếm. Đủ time sẽ search, đủ yêu thương thì sẽ về chung 1 nhà
Cài đặt timer cho việc search
Đoạn code trên check mỗi khi user gõ phím, thì timer được tạo ra. Đúng 0.5s sau khi user gõ ký tự cuối cùng, thì hàm performSearch sẽ chạy nha. Ở đây bạn capture để tránh trường hợp đang gõ, user thoát ra màn khác thì leak memory nha. Hàm shouldChangeCharactersIn có mục đích là lắng nghe sự kiện user gõ bàm phím, và hàm này thuộc UITextFieldDelegate, cho nên muốn xài nó bạn cần gán delegate cho textfield:
// Add delegate for textfield
searchTextField.delegate = self
Okey, vậy là đã xong mục timer.
Xử lý search:
Khi hàm performSearch gọi chúng ta sẽ làm những công việc sau:
Cần loại bỏ các dấu cách thừa ở đầu hay cuối nếu user cố tình nhập
Nếu text gọi lên giống với lần trước thì bỏ qua vì kết quả giống nhau mà
Nếu như user xóa trắng ô search thì clear kết quả đã search trước đó nếu có
Nếu mọi thứ ok thì show top indicator lên và bắt đầu search.
Cập nhật currentLanguage để so sánh cho lần tiếp theo
Khá đơn giản nhỉ
Tiếp theo chúng ta cài đặt search và search more trong view model nha:
Cài đặt search trong view model
Như quan điểm MVVM, thì mọi logic phức tạp sẽ move hết vào view model. Như vậy view hay view controller sẽ đỡ gánh nặng nha.
3. Sửa API theo document
Ở dòng 40, tôi có biến incompleteResults. Biến này có mục đích là xác định kết quả search có còn không. Nếu còn thì nó trả về false, còn nếu đã hết kết quả để search thì true. Mục đích của nó là xác định cho client xem mày có nên gọi request search lên nữa hay không nha.
Cùng xem và sửa API search trên trang github develop:
Hum trước thì cái API chưa có page, nên hum nay mình update page vào nè. dịch ra ở trên là page là số trang kết quả mà bạn muốn lấy. Người ta chia page với mục đích là load more đó bạn. Ví dụ server nó có 1000 kết quả, thì nó không thể trả 1 phát 1 nghìn lun, mà phải tách nhiều page. Giả sử 1 page có 100 kết quả thì có 10 page ha, mục đích làm việc trả kết quả nhanh, người dùng đỡ đợi nè. Vì thế khi bạn muốn load more, thì bạn phải tăng số page này lên. Đến bao giờ incompleteResults = true -> không có kết quả nữa thì thui hông call nữa nè. Đơn giản phải không nào
OK con dê, vì thế nên ta tiến hành thêm 1 biến page vào API ha.
Quay lại hàm search ở view model. Mình có 2 params truyền vào là:
language: String, loadMore: Bool = false
language là ngôn ngữ người dùng muốn tìm. Còn loadMore là để handle riêng cho trường hợp user muốn load more khi scroll table xuống bottom nà. Mặc định nó là false(nghĩa là search new).
Dòng 44->47 mình check nếu không phải load more thì cần sửa page về 0, đồng thời xóa trắng data cũ đi.
Dòng 56->60 mình xử lý để show cái bottomIndicator. Khi có kết quả trả về load more, thì cần ẩn cái bottomIndicator đi nhé.
Nếu search success, thì tiến hành append data mới vô githubSearchItem. Sau đó reload table nha.
Nếu thất bại thì báo lỗi
Vậy là xong phần search rồi. Tuy nhiên làm sao để biết lúc nào thì search more?
Khi người dùng cuộn xuống bottom, thì hàm trên sẽ được gọi. Do vậy mình check ở đây:
Nếu như cell đó là cell cuối cùng thì tiến hành tăng page lên 1, và hiển thị bottomIndicator lên, đồng thời gọi API để lấy thêm data vào.
Vậy là đã xong toàn bộ logic seach nè.
Tiếp tục quay ra GithubViewController để cài đặt các callback từ view model sang cho nó.
Cài đặt callback cho view controller
Dòng 46->49, khi needReloadTableView thì cần reload table và ẩn top indicator view đi.
Dòng 52->56, tương tự báo lỗi và ẩn indicator.
Dòng 58->65, xử lý cho bottomIndicator khi ẩn và hiện
Tiếp theo, chúng ta cần xử lý những logic be bé cho ứng dụng chạy đúng với trải nghiệm người dùng:
Dòng 128->130, khi người dùng bấm nút clear trên ô search, thì cần xóa data của table đi
Dòng 133->135, khi người dùng cuộn thì ẩn bàm phím đi.
Rồi vậy là đã xong đó. Mình cũng làm những logic cơ bản nhất của search. Nếu bạn muốn sử dụng indicator chuyên nghiệp hơn thì đây là 1 library mà mình hay dùng:
pod 'NVActivityIndicatorView', '~> 4.0' # https://github.com/ninjaprox/NVActivityIndicatorView
Chúc các bạn sẽ học được nhiều điều hay từ bài viết này
Mang tiếng là FE Developer, chính chiến khắp nơi, nào là Vuejs, ReactJs, Angular, nhưng đôi khi lại quên mất những điều đặc biệt ở Javascript ES6. Chà, tắc trách quá!
Hãy cùng Kieblog điểm qua một số điều thú vị đôi khi ta quên mất là chỉ có ở ES6. Cùng bắt đầu nha!
ES6 được xem như bước ngoặt lớn trong quá trình phát triển của ECMA Script
1. Default parameter
Rõ ràng mà nói, từ xưa tới nay vẫn luôn dùng || để set giá trị default cho argument trong trường hợp không được truyền vào
var kieblog = function (author, article, url) {
var author = author || 'Kien nguyen'
var article = article || 'Javascript ES6'
var url = url || 'https://kieblog.vn'
...
}
Tuy nhiên, ở Javascript ES6, ta có thể set giá trị default của argument ngay khi khai báo function. Đơn giản như sau:
Trước đây, khi muốn concat string các giá trị lấy theo chuỗi, ta sử dụng +. Tuy nhiên, với một hai cái thì không sao, tới chừng 5,6 cái thì thật sự là hoa cả mắt. Không ổn không ổn.
// Chỉ 2 cái thì okie, không sao hết
// Mặc dù nhìn hơi củ chuối, nhưng vẫn chấp nhận được!
var aboutme = 'My name is ' + first + ' ' + last + '.'
May mắn thay, ở Javascript ES6 ta có thể sử dụng syntax ${NAME} để bind các value vào String. Easy for ence như sau:
// Bind một phát,nhìn vừa gọn vừa chuyên nghiệp
var name = `My name is ${first} ${last}.`
Nhắc tới Javascript ES6 mà bỏ qua Arrow function thì thật sự là thiếu sót to lớn rồi. Dùng hằng ngày, viết hằng ngày thì tất nhiên phải nhớ có mặt ở ES6. Phải không nào?
// Với ES5, trước đây phải viến function(event)
var _this = this
$('.btn').click(function(event){
_this.doButtonThing()
})
Qua ES6, chỉ với Arrow function, đơn giản chỉ cần viết
// Với ES5, trước đây phải viến function(event)
var _this = this
$('.btn').click(function(event){
_this.doButtonThing()
})
Hiện tại, đơn giản chỉ cần nhớ. Tuy nhiên dùng arrow function thì không bind this trong đó, nên phải cẩn thận khi dùng this trong function có arrow
Ở ES5, var có scope ở cả function, thành ra đôi khi có mấy cái bug bi hài nếu dùng chung variable name. Mặc dù đã khai báo var các kiểu con đà điều, nhưng giá trị vẫn không đổi
// Với ES6
function theFunnyThingWithES5(es5) {
var es5Value = 99
if (es5) {
var es5Value = 100
}
{ // Cứ có block thì var sai
var es5Value = 101
{
var es5Value = 999
}
}
return es5Value
}
// Console ở đây log ra là 999 -> funny thing
console.log(theFunnyThingWithES5(true))
Quay trở lại Javascript ES6, thay đôi lớn nằm ở việc let có scope ở function, còn var thì giới hạn lại ở trong block
function theFunnyThingWithES6(es6) {
var es6Value = 99
if (es6) {
let es6Value = 100 // first es6Value is still 99
}
{ // more crazy blocks!
let es6Value = 101 // first es6Value is still 99
{
let es6Value = 999 // first es6Value is still 99
}
}
return es6Value
}
Bài viết được sự cho phép của tác giả Nguyễn Văn Trọng
Nguyên Do
Bài viết này hơi tự sự 1 chút. Chuyện kể về 1 anh chàng cu đơ lõm bõm chút tiếng Nhật cách đây 4 năm. Rồi tình cờ công việc rơi vào đầu anh và thế là anh trở thành 1 kỹ sư cầu nối bất đắc dĩ. Chỉ ngắn gọn vậy thôi. Rồi cũng tình cờ, sau mấy năm làm cái công việc mà có khi chả khác gì “dâu trăm họ” anh thấy mình chững lại, muốn bứt phá lên 1 mức cao hơn mà ở trên đó anh nghĩ là có nhiều cái mới, cái hay. Đời không như mơ, anh nói chuyện với bạn bè rồi đến các senpai, ai cũng loay hoay với vòng quay cơm áo gạo tiền bon chen cuộc sống, chả hơi đâu lại để ý đến chuyện chia sẻ kinh nghiệm này nọ. Không bỏ cuộc, anh tìm đọc hàng tá blog đủ mọi thể loại ngôn ngữ từ trên mạng rồi anh phát hiện ra 1 sự thật đau lòng : chả có 1 ai chia sẻ về nghiệp “kỹ sư cầu nối”. Thế đó, cái blog này ra đời 1 cách không tình cờ.
Có những lúc tự hỏi, phải chăng BrSE không phải là 1 cái nghề như bao thứ khác ? mà nó chỉ là bước đệm để cho anh em kỹ sư đạp lên đó mà dấn thân. Nghĩ nhiều vô ích, cho dù là gì đi chăng nữa thì đã – đang và sẽ có những con người tài năng đi qua đoạn đường này. Chi bằng ở trên đó, anh vẽ ra những biển chỉ dẫn – chỗ này nguy hiểm tránh xa – chỗ kia có thú dữ – chỗ nọ có nàng tiên cá … để cho khách bộ hành không dẫm lên những cái bãi lầy mà anh từng đạp ko biết bao lần. Và đôi khi lữ khách có thể tìm ra kho báu hay chỉ đơn giản là viên sỏi óng ánh mang trong mình tinh hoa của tạo hoá thông qua những chỉ dẫn mơ hồ mà anh dựng lên.
1 cánh én không thể làm nên mùa xuân, điều đó anh biết. Nhưng 1 đốm lửa vẩn có thể thiêu rụi cả 1 khu rừng. Nghĩ vậy nên anh càng tự tin hơn để cho ra những bài viết chả có 1 tí gì là văn hoa, lời lẽ thì khô khan, câu cú lủng củng, đôi khi còn nhiều chỗ phiến diện. Không phủ nhận, nhưng có 1 điều chắc chắn, trong những bài viết mà mỗi bạn chỉ đọc có 5p, anh đã dành ra 5h – có khi là 5 ngày để tổng hợp ý, tìm tài liệu và lục lọi trong ký ức những gì đi qua đã phủ bụi mờ của thời gian. Bạn có biết phương pháp chữa cháy rừng trong lúc nguy cấp là gì không ? không phải múc nước dưới sông lên dập lửa, càng không phải dùng bình cứu hoả – nguy cấp thì lấy đâu ra. Mà đó là ngăn sự lan rộng của ngọn lửa bằng cách vạch lá khô tạo vách ngăn. Ý ở đây là gì, nếu không có sự tiếp nối thì lửa không thể lan được, nó chỉ cháy âm ỷ trong phạm vi hẹp rồi lụi tàn. Thông tin cũng như ngọn lửa, mình thấy cái gì hay mà chỉ ôm – chỉ giữ khư khư thì rồi mình cũng lụi theo nó. Giữ chi vậy ? share ra cho anh em bạn bè đồng nghiệp còn biết chứ, đôi khi trong những cái mình đưa ra mà sai sót gì thì gặp cao nhân người ta còn chỉ giáo cho. Đó chính là suy nghĩ để anh làm động lực cho những bài viết tiếp theo.
Phương Pháp
Có nhiều cách để chia sẻ thông tin với độ lan toả cao như facebook hay twitter sao không chọn, anh chọn wordpress làm gì ? 1 góc nhỏ xíu trong này liệu ai biết để vào xem những cái hay ho của nghề ? đúng là độ lan toả thấp, nhưng đối tượng thì được chọn lọc 1 cách tuyệt vời. Không ai đi tìm hướng đi nghề nghiệp qua facebook cả, những bài viết chất lượng thì thường nằm ở những ngõ nhỏ phố nhỏ như này. Và những bạn tìm đến với anh, cùng gật đầu đồng cảm với ý kiến của anh, hoặc đôi khi là những cú bĩu môi chau mày theo kiểu “cha này viết linh tinh” – nhưng có lẽ không nhiều. Đó đều là những bạn trẻ có tâm với nghề, mong muốn con đường sự nghiệp của mình được tốt hơn.
Cái Tâm Và Tầm
Anh quen nhiều người, dẫu biết các anh – các bạn rất có tâm, nhưng lại ngại chia sẻ. Vì thực sự việc viết ra 1 cái gì đó công khai lên mạng thì đồng nghĩa với gạch đá, búa rìu. Đôi khi không cần phải lên đến mức chuyên gia mình mới có quyền chia sẻ. Ai cũng có cái quyền đó, vì mỗi người có 1 điểm nổi bật riêng mà cuộc đời này đã ban tặng. Có thể những cái bạn biết và nghĩ rằng ai cũng biết cả rồi, nhưng sự thực không phải vậy, trước đây anh cũng nghĩ thế. Đơn cử như vụ El nino – canh cua nấu với rau đay chẳng hạn. Từ khoá tìm kiếm trên google nhiều nhất đó là “El nino là ai” chứ không phải “El nino là gì”, rất nhiều người nghĩ El nino là tên 1 ai đó chứ không phải là 1 hiện tượng thời tiết. Vậy nên những cái anh viết ra có khi là kiến thức cũ mèm với nhiều người nhưng với 1 ai đó, nó lại là những thứ hay ho – mới mẻ. Không cần phải trở thành cá mập mới chia sẻ về đại dương, chỉ cần là cá trích – chú ấy có thể vẽ ra 1 khung cảnh dưới nước lung linh huyền ảo với vô số tầng sinh vật biển để tả lại cho nhưng đàn chym đang bay trên bầu trời. Chỉ cần tâm là đủ rồi.
Lời Đe Doạ
Sau khi đọc bài viết này, nếu có ý tưởng gì hay hãy viết Blog đi – không có gì hay ho cũng viết, dần dần sẽ hay. Bỏ những sts dài ngắn sướt mướt hay những giờ đắm chỳm vào mấy cái tin giật gân trên face liền. Những cái đó chả có ích gì, vì các mảnh thông tin chỉ tồn tại ở vỏ não 1 thời gian ngắn rồi cũng tiêu tan. Khi bắt tay vào viết 1 cái gì đó, lượng kiến thức sẽ hội tụ lại và khắc sâu vào trong các nếp nhăn, sau này chắc chắn sẽ có ích. Không cần ai đọc cũng được, coi việc viết như 1 sự luyện tập diễn đạt mà dân IT cực kỳ thiếu và yếu. Chỉ vì mục đích luyện tập và chia sẻ, đừng nghĩ gì cao xa, bắt tay vào làm ngay trước khi quá già. Hoặc nếu vì lười viết thì chí ít cũng comment bổ sung vào những bài viết để người khác xem và học hỏi, hoặc chỉ đơn giản là share nó ra cho ai cần.
Nay định bụng viết một bài “cao siêu sâu xa về git commit rebase”. Nhưng ngồi lướt face book lại thấy cái bài post hay quá. Nên lại viết về kinh nghiệm thực tế khi làm việc. Viết message commit như thế nào cho tốt?.
Thiết nghĩ theo cái nghề cũng là cái duyên cái nghiệp, không phải ai cũng ngồi trước máy tính làm việc 10-12 tiếng mà vẫn vui vẻ được. Cái nghề nó chọn mình, đeo bám lấy mình. Nhưng cứ “vững chí bền gan” – rèn luyện trau dồi thì nghề không phụ mình đâu!.
Lạc cmn đề, quay lại chủ đề chính “viết commit message sao cho tốt?“
1. Liên quan gì tới Senior?
Liên quan chứ, trở thành Senior không chỉ là “nắm rõ design pattern, hiểu tường tận về architecture“. Ngoài ra còn kĩ càng, chỉn chu trong những công việc nhỏ như viết nội dung commit, refactor các function nhỏ, hay viết manual document.
Một vài ví dụ. Blur là blur cái gì?, hot fix là fix khi nào?. Trước thì còn nóng sốt kịp release, nhưng giờ quay lại thì đâu thấy “gấp gáp” gì nữa. Vậy nội dung fix là gì?
Xin thưa là không phải nha, không phải code hoành tá tràng, giải thuật cao siêu hay component siêu to bự là muốn commit sao thì commit nha.
Vấn đề là feature này làm trong 2 tuần thì release, nên có viết content “ngáo ngơ” xíu thì cũng ok, nhìn vẫn nhớ. Còn nếu sau 2 tháng quay lại nhìn vào git history?.
Ơn chúa, “chỉ có chúa và con biết nội dung của nó là gì?. Mà đó còn là nội dung của bạn viết, chứ ông dev nào khác mà nhìn vào thì ôi thôi. Xác định là khỏi tra theo commit để mà tìm bug.
Ngoài ra, viết commit tốt còn giúp cho:
To speed up the reviewing process. (Tăng tốc quá trình review)
To help us write a good release note. (Viết release note tốt)
To help the future maintainers of Erlang/OTP (it could be you!), say five years into the future, to find out why a particular change was made to the code or why a specific feature was added. (Tìm lại những gì đã làm năm xưa một cách dễ dàng)
Để tránh những trường hợp đó. Ngoài có chuyên môn giỏi, khả năng code “thần sầu quỷ khóc”, cũng cần có tâm khi viết message content. How?, đây, tui chỉ cho
Rõ ràng phải nói là vậy, nhiều khi task dí tới đít, chạy còn không kịp, lấy đâu ra thời gian mà trau với chuốt nội dung commit. Biết là thế, nhưng mình vẫn khuyên là nên bỏ chút thời gian (khoảng 1,2 phút) để viết một nội dung có tâm.
Vậy nội dung có tâm là như thế nào? Có ngay đây!
git add .
git commit -m "fix bug"
git push
Nội dung commit không nên quá 50 kí tự (Limit the subject line to 50 characters). Đã là nội dung thì nên mô tả ngắn gọn, súc tích nhất có thể. Không nên viết quá dài dòng như tấu chương
Việc bỏ một chút thời gian để ghi rõ comment, commit message không những giúp rèn luyện tính cẩn thận tỉ mỉ. Từ những việc làm tưởng như nhỏ bé và đơn giản này cho ta cái nhìn khác biệt về hai người lập trình viên.
Chính vì vậy, hãy tập viết nội dung commit thật đàng hoàng ngay từ bây giờ nha. Có bị dí “chạy tụt quần” thì cũng bỏ ra 2 phút để viết được mà.
Bài viết được sự cho phép của tác giả Lê Xuân Quỳnh
Hello guys! Trong bài trước chúng ta đã hiển thị 1 danh sách động vật theo mô hình MVVM rất đơn giản.
Trong bài này, chúng ta sẽ nâng độ khó lên bằng cách request data từ server thật, cụ thể là server của github. Và bài này tôi sẽ viết 1 lớp layer cho network mà bạn có thể bưng vào project của bạn luôn.
Tuy nhiên tôi khuyên bạn chơi với terminal của MacBook cho nó pro nhé. Vì nếu bạn tải chay về bằng trình duyệt thì không thấy source code ở đâu đâu :v
Chơi với terminal đơn giản như sau:
Bạn gõ lệnh cd vào source code hôm trước bạn tải về:
cd TableviewSample
2. Tiếp theo là gõ fetch để lấy source code mới nhất của tôi về:
git fetch
3. Tiếp theo là bạn show toàn bộ branch trên repo của tôi bằng lệnh:
git branch -a
Ở đây bạn sẽ thấy các branch sau:
bai1
* bai2
master
Ví dụ bài này, tôi để hết source vào branch tên là bai2. Bạn chuyển sang source code bài 2 như sau:
git checkout bai2
Sau khi branch bai2 được bôi đậm chuyển màu nghĩa là bạn đã thành công rồi đó. Còn nếu nó báo không thấy thì chứng tỏ bạn làm sai, hãy làm lại!
Vẫn chưa chạy được source nhá. Muốn chạy thì phải cài pod cho nó. Nếu máy bạn chưa cài pod thì gõ lệnh sau:
sudo gem install cocoapods
Nhập mật khẩu và bấm enter nhé. Còn nếu bạn cài rồi thì bỏ qua lệnh trên và gõ tiếp lệnh:
pod install
Nếu bạn vào thư mục và thấy như sau nghĩa là đã thành công:
pod sẽ tạo file mới bôi xanh
Và bây giờ hãy mở file TableviewSample.xcworkspace lên và tiến hành ngâm cứu nào
Hãy chạy project lên và bạn sẽ thấy nó sẽ khác bài 1 với giao diện như sau:
Màn hình mới của app
Tôi đã tạo thêm 1 màn hình, có 2 nút bấm. Nút Local Animals List sẽ load lại ví dụ bài 1 hôm trước. Nút Remote repositories lists sẽ load ví dụ của bài hôm nay. Khi bạn bấm vào nút này nó sẽ show ra màn hình list như tôi đã trình bày ở đầu bài viết. OK, về cơ bản màn hình này tôi đã làm như sau:
Tôi tạo table view như bài 1
Tôi tạo 1 lớp network để call API
Tôi tạo 1 service để viết API lấy data về show
Tôi viết view model sử dụng service trên để lấy data về đổ vào view model
Tôi bắn hết data sang view để hiển thị lên
Khi bạn tách các công việc riêng biệt như này, thì view sẽ chả quan tâm bạn lấy data từ local hay từ server. Nó chỉ quan tâm là view model sẽ trả về cho nó mà thôi. Và nó cũng không có xử lý dữ liệu gì cả.
Đúng phong cách của MVVM rồi đó nha. Còn bây giờ chúng ta hãy tìm hiểu qua về network moya trước nha.
Moya là gì?
Đầu tiên, chúng ta cần hiểu qua 1 số kiến thức cơ bản về mạng internet và cách gọi API từ server. Các ứng dụng ta dùng hằng ngày như mạng xã hội thì đa số sẽ dùng cơ chế gọi tới các API và lấy kết quả trả về. Cơ chế đó có thể là Restful, GraphQL. Ở đây chúng ta sẽ nghiên cứu về Restful, còn thằng GraphQL thì tạm thời học bài khác ha, facebook nó cũng chơi với mấy kiểu GraphQL đó, viết API 1 lần, online realtime luôn, nhưng mà bây giờ chưa phải lúc ta học mấy cái này, để giành lần sau tôi viết bài khác về topic này.
Vậy Restful là gì? Nói nôm na nó là cơ chế gửi request lên, nhận 1 cái json trả về. Sau đó ứng dụng của chúng ta phải đọc được cái json này và chuyển thành model để sử dụng trong app của chúng ta. Có thể dùng get, post, put… Để hiểu nó hơn, bạn hãy vọc qua 1 tí về cái API mà chúng ta sắp sửa request nhé.
Đầu tiên bạn tải cho tôi cái ứng dụng Postman, trước khi code gì bên IOS, thì bạn sẽ có 1 cái API từ bọn backend gửi cho bạn(hoặc bạn làm nó), và chạy nó xem kết quả thế nào. Postman tải ở đây:
Bạn để ý thì mình dùng get để lấy dữ liệu. Ở đây là 1 API của github, dùng để request repositories với ngôn ngữ lập trình là swift. Trong nhiều trường hợp sau này với ứng dụng bạn làm, thì phương thức gửi lên là post. Post hay get thì tùy cách backend định nghĩa bạn nha. OK, vậy là chúng ta sẽ viết code để xử lý API này. Bạn vào đây để xem source code của Moya:
Trong phần readme của Moya, nó viết rất chi tiết bằng tiếng Anh cách mà nó hoạt động nha. Moya viết theo kiểu là tao cho mày các tham số đây để gọi 1 API, mày chỉ cần điền vào chỗ trống cho tao, việc còn lại tao làm. Mày điền phương thức là gì(get hay post..), đường dẫn, path, params mày gửi lên là gì, file để test ra sao.. Rồi việc còn lại tao lo cho mày hết. Đó là moya. Rất sexy phải không nào OK còn cụ thể nó như nào thì đọc tiếp nhé.
Và bây giờ là bắt đầu viết lớp layer network cực kỳ quan trọng sau đây.
Tạo lớp base để request network
Các bạn xem thư mục code base như sau:
Và cùng xem từng thành phần nhé. Nào bây giờ hãy ngắm mấy em mông to ngực bự hoặc làm 1 ít cà phê cho thư giãn đầu óc rồi tiếp tục nhé
Đầu tiên là file Configs như hình:
Code file config
Ở đây tôi dùng kỹ thuật tự động chuyển server test hay production nhờ flag đơn giản của Xcode. Các bạn để ý struct Network nằm trong struct Configs, nghĩa là nếu sau này bạn cần cố định các giá trị config cho nó thì có thể tạo thêm các struct khác như Color, Dimention… Ở đây bạn chú ý cho tôi đoạn macro #if DEBUG #else. Câu lệnh này nghĩa là nếu như các bạn đang chạy chế độ Debug(chế độ gỡ lỗi) trên Xcode, thì đường dẫn server sẽ là dòng nằm trên, còn nếu các bạn chạy chế độ Release(khi upload lên Appstore) thì dòng dưới. Nghĩa là trình biên dịch Xcode sẽ tự động thay đổi cái baseUrl cho bạn tùy thuộc vào bạn đang chạy debug hay đẩy app lên store nhé.
Tôi dùng 2 dòng giống nhau vì tôi lười, nhưng thực tế nếu làm các dự án thật, bạn sẽ được cung cấp 2 server dev và release, khi đó bạn phải biết cách config như tôi chỉ nhé. Việc nhẹ lương cao cho người lười. Nói thêm, chạy chế độ Debug thì mặc định Xcode nó chọn. Bạn có thể chỉnh về release như sau:
Chỉnh edit SchemeChỉnh lại thành Release
Vậy tại sao lại có 2 chế độ này? Các bạn mới sẽ thắc mắc, mình nói đơn giản là nếu chạy debug thì Xcode thêm nhiều đoạn code ẩn vào chương trình nhằm mục đích gỡ lỗi, nên chương trình nặng hơn. Còn khi các bạn fix hết bug rồi, thì khi upload lên không cần phải có mấy đoạn code ẩn đó, cho nên mới sinh ra chế độ release. Mặc định các IDE khác đều xử lý như vậy cả nhé. Như android studio, visual studio..
Đơn giản đúng không nào? OK tiếp theo chúng ta vào file BaseError như hình:
File BaseError
File này 1 enum để tôi xử lý lỗi trả về từ server. Server chúng ta sẽ gặp lỗi cơ bản:
Một là lỗi request sai. Ví dụ thằng backend bảo mày gửi get lên nhé, nhưng bạn cố tình post. Hoặc nó bảo bạn truyền 2 param lên để lấy(như username, password để đăng nhập) thì bạn cố tình truyền 1 cái lên, thì cũng được gọi là request sai. Hoặc như mất kết nối và bạn request thì cũng gọi là sai. Đại loại sai thì nhiều loại lắm, bạn cứ hiểu thế cho nó đơn giản.
Tiếp theo là đã request lên, server có trả về kết quả. Tuy nhiên khi dịch cái file json của server thì bằng 1 cách nào đó nó sai. Có thể là trả về rỗng, trả về null, trả về không có mà chúng ta lại cố tình decode nó.
Ở đây có bạn hỏi mình vậy json anh nói là cái gì vậy? Cái này bạn hiểu nôm na nó là 1 cái object gồm key và value tương ứng. Còn nếu muốn biết thêm chi tiết xin vui lòng đợi mình viết bài khác hoặc google nhé.
Trong cái postman bạn làm ở trên cái json cũng trả về và bạn có thể nhìn sâu vào nó và đọc từng key và value tương ứng nha.
Rồi, vì mình vừa mô tả ở trên nên mình đã tạo enum như mình nói. Nó gồm 2 case tương ứng. Mỗi case mình lại có 1 title để hiển thị lỗi, và 1 cái description mô tả chi tiết lỗi.
OK, đến đây nếu bạn mông lung không hiểu tôi đang nói gì thì có lẽ bạn lại phải nghỉ ngơi thư giãn 1 tí và xem lại, vì phần sau đây là quan trọng nhất. Phần NetworkProvider là trong tâm của bài này. Các bạn xem file NetworkProvider như sau:
Ở dòng 9 tôi bắt đầu sử dụng thư viện Moya để viết lại lớp provider này. Provider nghĩa là cung cấp nha, nghĩa là tôi muốn refactor moya 1 tí cho dễ dùng hơn(mặc dù nó cũng dễ dùng rồi). Dòng 11 tôi đổi tên 1 tí cho nó ngắn.
Dòng 14 đến 18, tôi lại dùng kỹ thuật debug như trên, tôi chỉ show các log của moya khi chạy debug. Nếu bạn thấy khó chịu khi nhiều dòng chữ in ra ở màn hình console của Xcode, thì bạn có thể bỏ false hết ở 1 chế độ.
Dòng 20 đến 25, tôi tạo 1 protocol nhằm mục đích:
Nếu như tôi chạy chế độ defaultNetworking(), nghĩa là tôi gọi API trực tiếp lên server và nhận kết quả trả về.
Nếu tôi chạy chế độ stubbingNetworking(), nghĩa là tôi gọi API từ app luôn, và trả kết quả thông qua 1 file json ở dưới app. Do vậy bạn sẽ không cần server khi chạy chế độ này. Nó hay dùng để test API hoặc là khi thằng server đang bận bế vợ hay bồ nó chưa kịp viết thì bạn vẫn ok viết API chạy dưới app mà không phụ thuộc nó, miễn là nó cho bạn 1 file json kết quả trả về.
Đoạn code trên là hàm tạo cho cái provider, rất nhiều tham số của Moya và tôi cũng không muốn giải thích chi tiết nó làm gì. Nhưng mà bạn cứ viết y hệt vậy sau có thời gian vào thư viện Moya xem nó giải thích. Có 1 biến online nhằm mục đích kiểm tra xem mạng mẽo có hoạt động tốt không. Nhưng thực tế trong project này tôi không có xử lý, bạn có thể tự code xem nhé.
Hàm request API:
Hàm request trên tôi chọn chế độ mutil target, vì theo kinh nghiệm code của tôi thì khi chọn Mutil target, bạn có nhiều API, mỗi API 1 cụm nào đó ví dụ như app bạn có các cụm: login gồm (login, logout), Home gồm feed, hot feature… Thì khi xử lý mutil target ở trong Moya, bạn sẽ tách được nhiều file API riêng biệt cho dễ viết code và unit test. Target ở đây bạn hiểu nó là cái server bạn sẽ gọi đến, nó sẽ gồm các thành phần sau:
Nếu bạn đọc được tiếng Anh thì nó dễ hiểu đúng không? còn không thì tôi dịch nôm na thế này. Muốn call API bạn cần:
Biết base URL nó là gì
Path là gì? ví dụ của chúng ta https://api.github.com/search/repositories thì base URL là https://api.github.com/ còn path là search/repositories
Method là get, post, put, download…
Sample data là cái mà tôi nói bạn không cần server, chỉ cần 1 file json ở dưới app là có thể viết unit test cho API của bạn. Moya làm sẵn cho bạn để bạn viết test hoặc chạy app dưới local nha
Task thì có thể là request dưới dạng param là json gửi lên, hoặc parameter, hoặc plain. Đây là quy tắc call server nên bạn cũng chỉ cần hiểu nôm na nếu như thằng server nó bảo bạn tao bảo mày gọi lên bằng post thì mày chọn kiểu jsonEncoding cho tao. Còn nếu mày gọi là get thì mày chọn parameterEncoding cho tao. Tôi tạo sẵn cho bạn ở đây:
Trong nhiều trường hợp nếu bạn chọn sai thì code của bạn sẽ trả về lỗi không gọi được(gửi get thay vì post, jsonEncoding thay vì parameterEncoding)… Rồi sau đó mất cả buổi chả hiểu mình sai chỗ nào. Chú ý cấu hình cho đúng nếu không đừng trách nước biển lại mặn
Quay lại với cái provider ở trên, Moya trả về 2 case, 1 case success và 1 case là failed. khi call api success, thì nghĩa là response.statusCode == 200, tôi tiến hành dịch cái json đó thành object codeable của tôi.
Đoạn code trên tôi try decode, mục đích là giả sử như bạn viết model để dịch cái response ra object của nó bị sai thì nó sẽ bắn ra lỗi nha(chỗ decode error), và return luôn.
Chú ý là tôi trả về completion hết vào main thread để đảm bảo rằng, UI của view khi có kết quả từ server sẽ xử lý trên main thread luôn nhé. Mặc định Apple chỉ cho phép xử lý UI trên main thread. Còn trường hợp case failed như sau:
Ở đây nghĩa là gọi API bị sai như tôi đã nói ở trên(mất mạng, gọi sai get, post, hay encode sai…) thì nó bắn vào đây. Tôi cũng completion thất bại như code. Tiếng anh completion nghĩa là hoàn thành, ở đây là hoàn thành việc gọi api nhé
Đoạn code từ dòng 86 bạn thấy cũng na ná đoạn code trên, chỉ khác nhau cái trả về thôi. Ở API request trên là trả về 1 object codeable. Còn request dưới này là trả về mảng. Tôi viết sẵn cho bạn nếu như bạn muốn xử lý mảng nha.
Đoạn code xử lý chạy server real hay là server fake nà
Như tôi nhắc 2 lần ở trên, đoạn này sẽ giúp bạn xử lý gọi API thật hay là gọi local nha. Cách dùng thì từ từ đọc tiếp nhá. Về cơ bản provider sẽ có những thứ quan trọng như vậy.
2. Tạo GithubAPI cho api của github
Rồi tiếp theo chúng ta sẽ viết GithubAPI cho github này. Sau này nếu có các cụm API khác như authen(bao gồm api Login và logout,…) thì bạn sẽ phải viết tách biệt ra 1 file khác nha.
Dòng 11 đến 13, các bạn xem lại Postman thì thấy rằng API gồm 3 tham số truyền lên:
Cho nên tôi lười tôi cũng đặt tên y hệt luôn như postman. Tên và param bạn nên đặt sát với API nhá. kiểu nó là string hết nha.
Tiếp theo từ dòng 15 trở đi, tôi bắt đầu mô tả cho API này.
Đầu tiên là base URL bằng việc lấy từ struct config đã trình bày.
– path thì là search/repositories(cũng đã trình bày ở trên).
Method là .get
sampleData là phần đọc file SearchRepositoriesResponse.json ở local như tôi đã trình bày. Bạn gọi dưới local thì nó sẽ lấy file này fake server trả về kết quả nha. File SearchRepositoriesResponse.json có nội dung y hệt cái response của backend nha bạn. Bạn có thể vào file đó mà xem.
Tiếp theo là headers, thường sẽ như dòng 59 nhé. Dòng 62 đến 70 sẽ là phần mô tả params truyền lên cho server:
Vậy là bạn đã hoàn thành viết API cho github nha.
3. Tạo service để gọi API github
Tiếp theo chúng ta phải viết 1 file service để gọi API. Các bạn vào file GithubSearchService:
File này đơn giản kế thừa từ BaseService. nó sẽ dùng provider của BaseService để gọi api của github. Bạn dùng MutilTarget để gọi, thì bạn sẽ tách được các cụm API riêng rẽ. Ví dụ trên là cụm GithubAPI, sau này có thể là AuthenAPI… Khi gọi request bạn cần truyền vào:
Target mà bạn muốn gọi. Ở đây là GithubAPI.searchRepositories
Kiểu model mà bạn muốn decode để trả về. Ở đây là GithubSearchResponse. Model này tôi tạo sau nhé.
Trong BaseService code như sau:
Ở đây tôi mặc định chế độ test là false. Nếu như bạn tạo service mà set isTest là true thì nó sẽ không bao giờ gọi lên server mà hoàn toàn lấy file json của bạn ở dưới local trả về kết quả. Nó phục vụ cho mục đích test API hay bạn không muốn đợi thằng backend viết xong API.
Rồi bây giờ sau khi xong file service thì bạn tiếp tục viết model. Nghe phức tạp nhỉ? viết code dài dòng vãi. Chắc các bạn mới sẽ phàn nàn với tôi như vậy. Nhưng khi mà bạn làm team lớn thì việc chia nhỏ sẽ như này sẽ hợp lý cho team work nè, và làm nhiều quen thì lại nghiện đó.
4. Tạo model để hứng dữ liệu từ server
Các bạn vào file SearchRepositoriesResponse.json, các bạn sẽ thấy rất nhiều key và value. Ở đây nếu bạn lười bạn có thể vào trang này để tạo model 1 cách nhanh chóng:
Các bạn chép cái json đó rồi parse vào nha. Đảm bảo nó ra 1 cái model luôn. Tuy nhiên vì tôi không cần tất cả data trong đó mà chỉ cần tên và đường dẫn để hiển thị cho nên tôi tạo đơn giản như sau(xem ở file GithubSearchResponse):
Model hứng dữ liệu từ server
Sau khi có model rồi thì các bạn tạo view model nhé!
5. Tạo view model để lấy dữ liệu từ service
Các bạn vào GithubViewModel để theo dõi code như sau:
Dòng 12 tôi dùng GithubSearchService. Thực tế dự án thật 1 view model có thể dùng nhiều services các bạn nhé.
Dòng 14 là biến closure để nhằm mục đích callback ra view, báo cho view reload lại table khi có kết quả từ server.
Dòng 15 tương tự nhưng báo lỗi và hiển thị lên màn hình.
Dòng 26 đến 42, tôi viết hàm gọi API từ view model, thông qua service. Có 2 trường hợp, nếu có kết quả tôi tiến hành lưu vào model nằm trong viewmodel và callback ra view để reload lại table. Nếu như thất bại tôi sẽ hiển thị lỗi. Rất clear đúng không nào
Rồi bây giờ thì đơn giản rồi, việc cuối cùng từ view gọi view model.
6. Sử dụng viewmodel trong view
Các bạn vào file GithubViewController, nhưng tập trung đoạn code trên cho tôi.
Dòng 30 là tạo viewmodel nha.
Dòng 31 tới 22 là call back khi có kết quả từ server, thì tôi reload lại table để hiển thị kết quả.
Dòng 35 đến 37 là khi server báo lỗi, tôi hiển thị lỗi lên view controller.
Vậy là các bạn đã hoàn thành quá trình viết 1 chương trình theo kiến trúc MVVM để gọi api thật. Ở ứng dụng này tôi cũng hay sử dụng thực tế trong các dự án công ty hay cá nhân. Còn thiếu 1 mục quan trọng là unit test cho nó nhưng thôi, vì bài dài quá rồi nên ta để sau nha. Nếu như bạn thấy bài viết hay thì chia sẻ hộ mình. Còn nếu sai sót chỗ nào vui lòng comment ở dưới bài nhé.
OK, tôi tổng kết lại các mục chính cho bạn nắm vững khi viết MVVM thực tế:
Tạo provider để call API
Tạo file mô tả API của API đó
Tạo services để call API
Tạo model để hứng dữ liệu từ server
Tạo view model để sử dụng services
Cuối cùng là dùng view model trong view để hiển thị kết quả
Hi vọng bài viết sẽ giúp các bạn mới làm quen dễ dàng hơn và chuyên nghiệp hơn trong việc viết code MVVM trong dự án của bạn.
Hiện nay, ngành công nghệ thông tin của Việt Nam đang phát triển mạnh mẽ hơn bất cứ khi nào hết và cũng bởi lẽ đó lập trình viên trở thành một nghề được rất nhiều bạn trẻ theo đuổi. Chúng ta đã chứng kiến sự thăng hoa của ngành ngân hàng trong thập kỷ trước để rồi liên tiếp những ngân hàng chìm đắm trong khủng hoảng. Liệu nghề lập trình có đi theo vết xe đổ ấy? Sự bùng nổ của ngành công nghệ thông tin khiến rất nhiều học sinh đổ xô vào các trường về công nghệ. Tuy nhiên không phải ai cũng có đam mê về lập trình, thương mại điện tử, về truyền thông để rồi lại tự hỏi sau này ra trường mình sẽ làm gì, đây có phải ngành nghề phù hợp với mình? Đó là bài toán muôn thuở của các nhà hoạch định khi học sinh, sinh viên không được định hướng kỹ càng, không được thử sức với các công việc thực tế và cuối cùng là không biết cuộc đời mình sẽ đi về đâu.
Trong bài viết này, chúng tôi sẽ chia sẻ những công việc mà một người lập trình hoàn toàn có thể làm sau khi ra trường. Bạn học lập trình không có nghĩa là sau này sẽ phải cắm đầu vào máy tính, code những dòng dài lê thê hay làm những công việc bạn không yêu thích. Hãy chuẩn bị cho mình một chút tư duy kinh tế, một cái nhìn bao quát nhất về xã hội, tôi tin bạn sẽ tìm ra hướng đi cho mình.
Trên thực tế, có những người thực sự đam mê với nghề lập trình. Họ rất thông minh, có tư duy tốt và một nhãn quan khủng khiếp. Đó dường như là tài năng thiên bẩm mà họ có được. Tuy nhiên, chúng ta lại khác: học hành chểnh mảng, không được định hướng, làm bài và thi cử một cách đối phó. Có những sinh viên chưa qua nổi năm nhất đã chán ngấy việc học đại học. Vậy đâu là giải pháp?
Một là bạn bỏ học, theo đuổi thứ mà bạn thực sự yêu thích. Điều này tôi không khuyến khích bởi các bạn sẽ phải chịu rất nhiều áp lực từ gia đình, áp lực từ chính bản thân. Nhưng nếu bạn đã chán ngấy lắm rồi, không có động lực để tiếp tục theo đuổi thì bạn nên dừng lại. Bên cạnh đó, bạn cần có cơ sở để bỏ học, hãy tìm ra những lý do cho riêng bản thân mình (bạn sẽ thi lại, bạn sẽ theo đuổi một nghề mới, bạn đã đủ quyết tâm,…).
Hai là bạn sẽ tiếp tục theo đuổi và nỗ lực hết mình để gắn bó với nghề lập trình. Nếu quyết định như thế, bạn cần:
Chăm chỉ: Bạn sẽ không thể trở thành người này người nọ nếu bạn không chăm chỉ. Bạn cần biết học chuyên sâu một ngôn ngữ; bạn cần biết thêm một vài ngôn ngữ khác, bạn cần rèn luyện những kỹ năng cơ bản nhất khi lập trình.
Kinh nghiệm: Đây là thứ rất quan trọng khi bắt đầu đi làm. Sẽ có rất nhiều khó khăn bởi công việc thực tế chẳng giống như những gì đã được học nhưng nếu bạn đủ thông minh, bạn sẽ lĩnh hội được rất nhiều. Hãy tạo ra giá trị mà chỉ mình bạn có chẳng hạn bạn code rất nhanh mà không dính nhiều lỗi; bạn giỏi trong việc tìm ra và xử lý bug; bạn có thể làm việc với người nước ngoài;… Đó là những lý do các doanh nghiệp muốn giữ bạn lại, muốn tăng lương cho bạn.
Bạn có thể làm gì?
Trở thành lập trình viên – Developer
Là người thiết kế, xây dựng và bảo trì các chương trình máy tính, các website, các ứng dụng trên điện thoại di động. Trong bài viếtLàm thế nào để trở thành lập trình viên, Smartjob đã đề cập đến những kỹ năng, phẩm chất cần thiết nhất để bạn có thể rèn luyện và chuẩn bị hành trang cho mình một cách sớm nhất, đúng hướng nhất. Ngoài ra, như đã đề cập ở trên, kinh nghiệm là thứ quan trọng bậc nhất mà lập trình viên cần có. Bạn sẽ chẳng thể làm gì nếu không có kinh nghiệm. Kinh nghiệm tạo ra giá trị cho bạn, giúp bạn sáng tạo ra những cái mới và khiến công việc của bạn bớt khó khăn đi rất nhiều. Đề có kinh nghiệm, hãy bắt tay vào code ngay từ khi còn ngồi trên ghế nhà trường. Lập trình là công việc mà càng sai ta càng nhận ra nhiều điều.
Trở thành một Tester
Công việc này có thể nói nôm na là bới bèo ra bọ, bới lông tìm vết. Sau khi lập trình viênđã code, Tester sẽ chạy thử, tìm mọi cách để mò ra những lỗi trong quá trình vận hành. Với nhiều người đây thực sự là công việc nhàm chán và nhức đầu. Nó phù hợp hơn với những bạn gái có tính tỉ mỉ, cẩn thận. Bạn cần đặt mình vào vị trí người dùng để trải nghiệm sản phẩm của nhóm và tìm ra những lỗi hay nhược điểm của sản phẩm.
Tester thường được mệnh danh là “bà già khó tính” bởi khi làm ở vị trí này bạn luôn bắt được những lỗi cơ bản, sai rồi mà cứ lặp lại khiến mình trở nên điên đầu. Đây là công việc không dành cho những người dễ bị stress – Cáu xong rồi thôi chứ không nên để sự nóng giận của mình làm ảnh hưởng đến cả nhóm. Tỉ mỉ, bình tĩnh và nóng nảy đúng lúc là những phẩm chất cần thiết nhất cho công việc này.
Được gọi là Designer, có nhiệm vụ tạo ra giao diện của một website hay một ứng dụng một cách hoàn chỉnh. Công việc này cũng liên quan khá mật thiết đến lập trình, seo,… Yêu cầu là bạn phải sử dụng thành thạo các chương trình thiết kế, tạo đồ họa như Photoshop, Al, Dreamweaver, Flash,… và rất nhiều phần mềm hỗ trợ khác. Càng thành thạo bao nhiêu, càng biết nhiều chương trình bao nhiêu thì việc làm của bạn càng hiệu quả bấy nhiêu.
Thường thì những doanh nghiệp nhỏ chỉ có một designer hoặc lập trình viênsẽ kiêm luôn design nên cường độ làm việc của bạn sẽ rất dày. Bạn sẽ phải “ôm” một vài dự án một lúc. Tuy nhiên công việc này không quá nặng đầu như lập trình viên hay tester. Chỉ cần đam mê và có đầu óc thiết kế, bạn sẽ hoàn thành tốt công việc.
Làm việc cho các công ty phần mềm, công ty tư vấn hay công ty ứng dụng công nghệ. Việc của bạn là thu thập, xử lý và tổng hợp dữ liệu sau đó sử dụng chúng để chuẩn bị cho các chương trình nghiên cứu, marketing hay các chương trình giới thiệu sản phẩm. Muốn làm được việc này, bạn không cần phải code giỏi mà nên tìm hiểu càng nhiều phần mềm càng tốt. Bên cạnh đó, tư duy là thứ rất quan trọng và bạn nên tìm hiểu kỹ trước khi phỏng vấn vào vị trí này. Cần có cái nhìn bao quát toàn bộ dự án chứ không chỉ có mớ code trong đầu.
Thường thì công việc này dành cho người lập trình đã có kinh nghiệm 2 đến 3 năm, biết phân tích, biết “chém gió” bởi bạn sẽ phải truyền đạt cho người khác ý tưởng và cách làm của mình; đôi khi còn phải thuyết phục được cấp trên hay đối tác. Đây là hướng đi hoàn toàn có triển vọng nếu bạn muốn làm lãnh đạo các dự án.
Nhân viên kinh doanh
Thoạt nghe có vẻ không hợp lý nhưng rất nhiều lập trình viên sau khi làm một thời gian đã phát hiện ra tài năng “chém gió” của mình và chuyển hướng sang công việc này. Chúng ta thường nghĩ đây là vị trí dành cho sinh viên kinh tế, marketing tuy nhiên thực tế không phải vậy. Rất nhiều người đã làm việc đúng ngành nghề của mình một thời gian để lấy kinh nghiệm sau đó dùng kiến thức của mình để thuyết phục khách hàng, làm việc với các đối tác nhằm phục vụ mục đích kinh doanh của công ty.
Nhân viên kinh doanh ở đây có thể là kinh doanh phần mềm, truyền thông cho các dịch vụ giá trị gia tăng, kinh doanh giải pháp, giới thiệu các dự án mới,… Thường thì vị trí này sẽ thoải mái hơn về thời gian nhưng cũng sẽ bị áp doanh số. Những kiến thức về marketing, quảng cáo thực sự hữu ích nếu bạn muốn “dấn thân” vào công việc này.
SEOer
SEO là từ viết tắt của Search Engine Optimization có nghĩa là tối ưu hóa công cụ tìm kiếm. Chúng ta có thể hiểu nôm na SEO là tổng hợp những phương pháp làm gia tăng lượng traffic của website với công cụ tìm kiếm chính là Google. Đây làm một nghề mới trong những năm trở lại đây và hiện đang được rất nhiều bạn trẻ theo đuổi.
Việc của bạn là sẽ phải làm sao cho các từ khóa được xuất hiện ở những vị trí top trên google, được nhiều người tìm kiếm, mang lại lượng truy cập cho website nhằm phục vụ những mục đích khác nhau (tuyển dụng, tin tức, kinh doanh,…). Những tố chất cần cho nghề SEO là kiên trì, tỉ mỉ và làm đúng phương pháp. Bạn cần được các chuyên gia hướng dẫn và tham gia một vài dự án trước khi có thể tự mình lập kế hoạch thực hiện dự án. Nếu thành thạo SEO, bạn hoàn toàn có thể tự mình kinh doanh, tự marketing cho các sản phẩm của mình.
Những công việc kể trên là những việc phổ biến nhất với dân IT ở Việt Nam hiện tại. Ngoài ra còn rất nhiều ngành nghề mới nếu bạn muốn làm việc tại các công ty liên doanh, các tập đoàn nước ngoài:
Kỹ sư phần mềm
Kỹ sư phần cứng
Kỹ sư blogchain
Kỹ sư thực tế ảo
Kiến trúc sư IoT
Kỹ sư cụm GPU
Chuyên gia an ninh mạng
…..
Cuối cùng, Smartjob cho bạn một lời khuyên là hãy học tốt một trong ba thứ tiếng Anh, Nhật, Hàn bởi chúng có thể mở ra những cơ hội mới mà chúng ta chẳng thể tưởng tượng nổi.
Các bạn xem qua ở phần trước đã có hướng dẫn cài đặt Node.js trước khi tới phần này.Hướng dẫn nhanh phần cài đặt Mongodb.
Hướng dẫn cài đặt Mongo db phiên bản mới nhất và tool Robomongo quản lý (nó giống các tool quản lý mysql như Naviacat )
Cách cài đặt riêng từng gói .Truy cập trang chủ, download bản cài đặt: https://www.mongodb.org/downloads#production
Lưu ý: Bạn nên sử dụng hệ điều hành 64 bit, không khuyến khích sử dụng hệ điều hành 32 bit
Gói cài đặt điển hình (như ảnh chụp màn hình) là mongodb-win32-x86_64-3.2.3-signed.msi có dung lượng 93 MB
Tiếp tục cài đặt và tới finish
Sau đó cài đặt biến môi trường như sau :
Bấm tổ hợp phím Windows + R để gọi tiện ích Run, gõ systempropertiesadvanced để vào chương trình thiết lập biến môi trường.
thêm text : ;C:\Program Files\MongoDB\Server\3.2\bin vào cuối bước 3
Mở CMD và gõ lệnh : mongod -version
Hiện lên màn hình sau nếu thành công
Sau đó tạo thư mục để chứa Data base như hình sau :
Nội dung file config.txt
##store data
dbpath=C:mongodb\data
##all output go here
logpath=C:\mongodb\log\mongo.log
Sau đó trỏ tới thư mục cài đặt mông trên ổ C: của mình đã cài đặt như đường link:
C:\Program Files\MongoDB\Server\3.2\bin
Và gõ lệnh sau :
mongod.exe --config C:mongodb\config.txt
Sau đó gõ lệnh sau để kiểm tra version : mongodb -version
Sau đó tới thư mục sau và gõ lệnh để chạy :mongod.exe –dbpath “C:\mongodb\data”
Chú ý : Từ lần sau khi muốn kết nối với Mongodb bằng Node.js hay PHP … bạn mở CMD và thự thi dòng lệnh trên
Các bạn tham khảo nội dung hướng dẫn dung Robomongo quản lý Mongodb: https://smartjob.vn/huong-dan-dung-robomongo-quan-ly-mongodb/
Tải source code tại đây:node_mongo
Tạo cấu trúc file thư mục như sau : folder : node_mongo file : conect_smartjob_mongo.js
Mở CMD và trỏ tới thư mục chứa file conect_smartjob_mongo.js gõ lệnh : npm install mongodb như hình dưới
Sau đó thì thư mục sẽ xuất hiện thêm folder:node_modules như hình vẽ
Nội dung file : conect_smartjob_mongo.js
//lets require/import the mongodb native drivers.
var mongodb = require('mongodb');
//We need to work with "MongoClient" interface in order to connect to a mongodb server.
var MongoClient = mongodb.MongoClient;
// Connection URL. This is where your mongodb server is running.
var url = 'mongodb://localhost:27017/test';
// Use connect method to connect to the Server
MongoClient.connect(url, function (err, db) {
if (err) {
console.log('Unable to connect to the mongoDB server. Error:', err);
}
else
{
//HURRAY!! We are connected.
console.log('Connection established to', url);
// Get the documents collection
var collection = db.collection('zips');
// Find some state
collection.find({'state': 'MA'}).toArray
(
function (err, result) {
if (err) {
console.log(err);
} else if (result.length) {
console.log(result);
//var result=result.length;
} else {
console.log('No document(s) found with defined "find" criteria!');
}
//Close connection
db.close();
}
);
}
});
Ở dòng 24 của file conect_smartjob_mongo.js như trên ta thấy điều kiện truyền vào lấy ra các bản ghi (theo cách nói của cơ sở dư liệu mysql ) ở đây là lấy ra các document có điều kiện là có state bằng ‘MA‘ và hiển thị lên cửa sổ lệnh cmd qua lệnh console.log sau đây là kết quả hiển thị được:
Ở cùng dòng đó ta có thể thay bằng các điều kiện khác để thực hiện truy vấn như:
– collection.find( ).toArray // lấy tất cả các kết quả trong collection
– collection.find({‘state’: ‘MA’,’pop’:9610}).toArray // thêm 1 điều kiện query nữa
– collection.find({‘address.zipcode’: 10075}).toArray // nếu có chứa các cặp field: value lồng trong cặp field:value
-collection.find({ pop:{$gt:9600} }).toArray // điều kiện lớn hơn với filed pop
-collection.find({ pop:{$lt:9600} }).toArray // nhỏ hơn
Làm tương tự và thực hiện lệnh thực thi file insert.js giống như ở trên : node insert.js file code insert.js như sau:
//lets require/import the mongodb native drivers.
var mongodb = require('mongodb');
//We need to work with "MongoClient" interface in order to connect to a mongodb server.
var MongoClient = mongodb.MongoClient;
// Connection URL. This is where your mongodb server is running.
var url = 'mongodb://localhost:27017/test';
// Use connect method to connect to the Server
MongoClient.connect(url, function (err, db) {
if (err) {
console.log('Unable to connect to the mongoDB server. Error:', err);
}
else
{
//HURRAY!! We are connected. :)
console.log('Connection established to', url);
// Get the documents collection
var collection = db.collection('zips');
//Create some document
var smartjob1 = {city: 'smartjob.vn', pop: 1242, state: 'MA', loc: [-72.936114, -72.936114]};
var smartjob2 = {city: 'mang tuyen dung hang dau viet nam', pop: 3442, state: 'MA', loc: [42.182949, 42.182949]};
// Insert some users
collection.insert([smartjob1, smartjob2], function (err, result) {
if (err) {
console.log(err);
} else {
console.log('Inserted %d documents into the "users" collection. The documents inserted with "_id" are:', result.length, result);
}
//Close connection
db.close();
});
}
});
Chú ý dòng 27 insert dữ liệu vào qua hai biến smartjob1,smartjob2.
và file update.js update thay đổi 1 thông số trong document
//lets require/import the mongodb native drivers.
var mongodb = require('mongodb');
//We need to work with "MongoClient" interface in order to connect to a mongodb server.
var MongoClient = mongodb.MongoClient;
// Connection URL. This is where your mongodb server is running.
var url = 'mongodb://localhost:27017/test';
// Use connect method to connect to the Server
MongoClient.connect(url, function (err, db) {
if (err) {
console.log('Unable to connect to the mongoDB server. Error:', err);
}
else
{
//HURRAY!! We are connected. :)
console.log('Connection established to', url);
// Get the documents collection
var collection = db.collection('zips');
collection.update({city: 'smartjob.vn'}, {$set: {city: 'smartjob.vn2'}}, function (err, numUpdated) {
if (err) {
console.log(err);
} else if (numUpdated) {
console.log('Updated Successfully %d document(s).', numUpdated);
} else {
console.log('No document found with defined "find" criteria!');
}
//Close connection
db.close();
});
}
});
Chú ý dòng 22 thay thế 1 document có thông số city = smartjob.vn và update city = smartjob.vn2
Xóa 1 document có trường (key) city= smartjob.vn2
var mongodb = require('mongodb');
var MongoClient = mongodb.MongoClient;
// Connection URL. This is where your mongodb server is running.
var url = 'mongodb://localhost:27017/test';
// Use connect method to connect to the Server
MongoClient.connect(url, function (err, db) {
if (err) {
console.log('Unable to connect to the mongoDB server. Error:', err);
}
else
{
console.log('Connection established to', url);
// Get the documents collection
var collection = db.collection('zips');
// start
collection.deleteOne({ city : 'smartjob.vn2' }, function(err, result) {
if (err) {
console.log(err);
} else {
console.log('xoa thanh cong');
}
//Close connection
db.close();
});
//end
}
});
Ở các bài tiếp theo mình cũng giới thiệu cách kết nối Mongodb bằng node.js theo ODM hướng đối tượng băng Mongose . Chúc các bạn thực hành thành công mọi thắc mắc các bạn có thể liên hệ qua Skype : nguyenanhdung90.
For fun tí thôi, nhưng mà thực tế khi bạn hiểu được tại sao lại leak như vậy rồi thì lần sau bạn sẽ không dễ bị leak thế nữa, đúng không nào? Trong bài này, chúng ta lại tự ngã vào 1 leak hoàn toàn mới: Đó là leak trong singleton. Ồ nghe nó có vẻ nguy hiểm nhỉ. Nhưng mình cá khi đọc xong cái bài này các bạn lại bảo “ôi tưởng thế nào, dễ vãi lằn ” OK con dê, vậy hãy bóp mông em đồng nghiệp 1 cái rồi vào việc luôn nào.
Tuy nhiên tôi khuyên bạn chơi với terminal của MacBook cho nó pro nhé. Vì nếu bạn tải chay về bằng trình duyệt thì không thấy source code ở đâu đâu :v
Chơi với terminal đơn giản như sau:
Bạn gõ lệnh cd vào source code hôm trước bạn tải về: cd LeakMemorySample
2. Tiếp theo là gõ fetch để lấy source code mới nhất của tôi về: git fetch
3. Tiếp theo là bạn show toàn bộ branch trên repo của tôi bằng lệnh: git branch -a
Ở đây bạn sẽ thấy các branch sau: bai1 * bai2 master
Ví dụ bài này, tôi để hết source vào branch tên là bai2. Bạn chuyển sang source code bài 2 như sau: git checkout bai2
Sau khi branch bai2 được bôi đậm chuyển màu nghĩa là bạn đã thành công rồi đó. Còn nếu nó báo không thấy thì chứng tỏ bạn làm sai, hãy làm lại!
Singleton là gì?
Trước khi tạo được leak cho nó thì chúng ta hãy hiểu Singleton là gì đã nha? Nó là 1 cái khái niệm gì đó bằng tiếng Anh. Nhưng nếu hiểu theo nghĩa thuần Việt singleton là kỹ thuật tạo class mà chỉ khởi tạo được duy nhất 1 lần. Nghĩa là gì? Cùng xem ví dụ sau:
class AlertViewHandleLogic {
}
Tôi tạo 1 class như trên và hoàn toàn không có gì trong đó cả. và bạn mở project lên, vào file SingletonLeakViewController:
thì thấy nó chạy bình thường như hình. Tiếp theo tôi biến class AlertViewHandleLogic thành singleton như sau:
Chuyển class thường thành class Singleton
Dòng 11: Tôi đưa hàm tạo init thành private, nghĩa là không cho phép các lớp khác khởi tạo nó nữa.
Dòng 12: Tôi tạo 1 biến static shared để gọi hàm tạo tại chính nó, ok nó chạy được.
Khi tạo như này, bạn build lại và vào xem ở file SingletonLeakViewController thì kết quả như sau:
Nó báo lỗi đỏ chót, dịch ra nghĩa là hàm init được bảo vệ private – do đó bạn không thể gọi hàm tạo được ở đây. OK vậy tôi sẽ gọi lớp này như nào?
Tôi gọi nó qua biến shared. Lúc này do shared là biến static nên nó chỉ khởi tạo đúng 1 lần và biến này tồn tại mãi mãi trong class AlertViewHandleLogic. Vậy là bạn đã tạo được 1 class Singleton thành công
Vậy trong thực tế, chúng ta có hay gặp singleton không? Ồ rất nhiều luôn bạn nhé. Ví dụ Apple có 1 đoạn code trong UIKit như sau:
Thì biến shared ở trên chính là singleton nha. Ở ví dụ trên, khi tôi muốn lấy rootViewController thì tôi thông qua biến shared của lớp UIApplication để truy cập. Vì mỗi ứng dụng IOS thì cần 1 biến để lưu rootViewController và duy nhất thôi, cho nên họ tạo singleton cho nó. Quy tắc đặt tên cho singleton thường là shared, hoặc là getInstance() như thời Objective-C bạn nhé. Vậy là bạn biết được tác dụng của Singleton như nào rồi ha. Hãy nhớ cho mình chúng ta chỉ tạo Singleton khi:
Quản lý 1 biến hay class duy nhất chạy xuyên suốt ứng dụng
Static sẽ không được giải phóng cho đến khi ứng dụng giải phóng
Do vậy, cũng không thể lạm dụng Singleton hay static được đúng không nào? Nếu bạn hiểu đơn giản thì swift hay các ngôn ngữ lập trình khác có 2 loại biến cơ bản là dynamic và static. Dynamic thì khởi tạo runtime, và giải phóng khi lớp chứa nó hủy. Còn static thì khởi tạo luôn khi class đó được gọi init, và tồn tại xuyên suốt ứng dụng. Tuy nhiên nhiều trường hợp bắt buộc vẫn phải dùng static dù muốn hay không.
Trong ví dụ chúng ta làm sau đây, tôi muốn chương trình sẽ sau 1 khoảng thời gian nào đó hiển thị 1 màn hình alert lên view controller, bất kỳ ở đâu nó cũng show lên được ha. Và việc xử lý show đó do class AlertViewHandleLogic xử lý. Nghe hấp dẫn nhỉ? Trong thực tế có những ví dụ như bạn muốn sau 1 khoảng thời gian ứng dụng tự lock màn hình cũng có thể áp dụng, vân vân mây mây ha.
OK đọc đến đây thì cũng mệt rồi, nên hãy đi hát 1 bài rồi ta lại tiếp tục nha
2. Tạo singleton quản lý show alert
Cùng theo dõi đoạn code sau:
Xử lý logic show popup nhờ timer
Dòng 12, 13 tôi có 1 biến timer để tính sau 1 khoảng thời gian sẽ show alert ra
Dòng 23 đến 27, tôi tạo hàm để cứ sau 1 khoảng 5s nó sẽ gọi vào biến closure needShowAlertView. Mục đích biến này là bắn ra callback cho view controller nào được gán sẽ thực hiện action này.
Vào SingletonLeakViewController và theo dõi đoạn code sau:
Dòng 15, tôi khởi tạo biến singleton của class AlertViewHandleLogic
Dòng 16 tôi gán closure needShowAlertView và hiển thị 1 dòng chữ need show here
Dòng 20 tôi gọi hàm resetShowAlertTimer để timer hoạt động
Sau khi build tôi nhận được kết quả sau:
Vậy là cứ đều đặn 5s nó sẽ bắn ra callback để chúng ta có thể viết logic show cái alert này ra.
Tuy nhiên, vì hàm alertViewHandleLogic.resetShowAlertTimer() gọi rườm rà nên tôi sẽ đưa nó vào hàm init của AlertViewHandleLogic để không phải gọi mỗi khi tạo callback needShowAlertView.
Tuy nhiên có 1 vấn đề nghiêm trọng như sau:
Biến closure needShowAlertView thuộc lớp AlertViewHandleLogic, là class Singleton. Do đó khi biến này được gán ở SingletonLeakViewController thì chỉ có view này show alert thôi. Giả sử tôi gán vào SecondViewController thì nó không còn hoạt động ở SingletonLeakViewController. Ồ trong khi tôi muốn là nó phải hoạt động ở tất cả các viewcontroller cơ mà
Khó rồi nha, vì singleton chỉ là 1 và duy nhất, cho nên chúng ta không thể áp dụng kỹ thuật callback bằng closure này được. Giải pháp là gì?
3. Thay thế closure callback bằng observers
quát dờ heo? Ông vừa chỉ tụi tôi cái singleton rồi định chỉ thêm cái observers? Có nhiều quá không vậy? Ồ nếu bạn vừa ngáp ngủ thì thôi tạm thời làm cốc trà đá, hút điếu thuốc, ngắm em bán nước mông cong 1 lúc rồi lên tiếp tục sau nha.
OK rồi bây giờ ta sẽ tiếp tục nghiên cứu observers là gì nè?
Observers dịch theo nghĩa thuần Việt nhất là 1 cái quan sát viên. Mỗi khi timer tới 5s, thì nó sẽ phải báo cho tất cả những thằng view controller dùng nó phải show alert lên. Tất nhiên là view controller đang ở chế độ hiển thị nha. Kỹ thuật này dùng thế nào?
Đơn giản là bạn tạo 1 cái protocol ở cái class AlertViewHandleLogic, sau đó bạn tạo thêm các hàm add và remove các protocol này để sử dụng hay xóa việc lắng nghe protocol ở các view. Protocol có nhiệm vụ báo cho các view controllers.
Nói thì hay lắm, code xem nào Theo dõi đoạn code sau:
Dòng 11 đến 14, Ở đây tôi tạo protocol AlertViewHandleLogicDelegate có nhiệm vụ là bắn hàm needShowAlertView để show alert. Một số quy tắc viết protocol nếu bạn chưa nắm vững có thể xem tại đây ha.
Dòng 18 tôi làm 1 biến observers kiểu AlertViewHandleLogicDelegate nhằm lưu trữ các observer(quan sát viên) của các view controller muốn listen nó.
Tiếp tục xem đoạn code:
Dòng 43 đến 46, tôi tạo hàm add observer. Tôi có check nếu nó chưa được add thì mới thêm, có rồi thì bỏ qua không thêm nữa.
Dòng 51 đến 54 tôi viết hàm remove observer. Vì không thêm lặp cho nên tôi chỉ check phần tử đầu tiên nếu là thằng cần remove thì xóa ra khỏi list thôi.
Trong hàm bạn sửa lại 1 xíu như sau:
Mục đích là chạy 1 vòng for rồi notification cho tất cả những thằng đã add observer nha. Tôi comment cái callback bằng closure.
OK vậy là bạn đã chuẩn bị để chơi với observer rồi nha. Bây giờ bạn vào SingletonLeakViewController và code như sau:
Dòng 21 tôi add observer cho SingletonLeakViewController. Khi add như này thì nó sẽ lắng nghe được sự kiện sau 5s sẽ show alert.
Dòng 26 đến 29, vì tôi add cho nên class SingletonLeakViewController phải extend các hàm từ protocol AlertViewHandleLogicDelegate. Tôi show print để biết nó hoạt động.
Ở các view controller khác bạn làm tương tự.
Và kết quả chạy như sau:
Good job. Vậy là nó đã hoạt động
Nhưng khoan đã, ông vừa bảo leak cái mẽ gì trong singleton rồi cơ mà, sao giờ lại lan man ra đây? Ồ bây giờ tôi mới chốt issue nè. Leak memory đã xảy ra rồi đó!
Bây giờ bạn thêm dòng code sau để check SingletonLeakViewController giải phóng khi bấm back ra không:
Và nó hoàn toàn không nhảy vào! OMG tôi đã làm gì sai mà leak vậy
Rồi quay lại vấn đề, việc ta add 1 observer vào SingletonLeakViewController như sau:
AlertViewHandleLogic.shared.addObserver(self)
Thì view controller này đã tham chiếu mạnh tới class AlertViewHandleLogic. Nghĩa là lớp SingletonLeakViewController chỉ bị giải phóng khi observer trong AlertViewHandleLogic được giải phóng. Tuy nhiên AlertViewHandleLogic làm sao mà giải phóng được khi nó có hàm remove ở đâu đâu. Có bạn bảo bạn ơi sao bạn không đưa hàm remove như này:
Rất tiếc là nó đã không giải phóng thì không nhảy vào deinit, mà không vào thì không chạy remove observer được. Câu chuyện trở thành bế tắc rồi
Giải pháp của tôi như sau:
Tôi trick khi nhấn nút back ở UIBarButtonItem thì sẽ gọi vào hàm viewWillDisappear, tôi sẽ xóa ở đó:
Kết quả như sau:
Vậy là SingletonLeakViewController đã call được vào deinit, nghĩa là nó được giải phóng
Tuy nhiên tôi thấy thật sự đây cũng chưa phải là giải pháp thông minh nhất, vì bạn sẽ phải biết trick tùy trường hợp mà giải phóng chứ không phải lúc nào cũng là như tôi làm ở trên.
OK vậy là bài này cũng khá dài rồi, nếu bạn có giải pháp nào hay hơn của tôi vui lòng hãy comment cho tôi biết ở dưới bài này nhé.
Cảm ơn vì đã theo dõi tới đây và hi vọng bạn sẽ học được thêm nhiều kiến thức hay ho, thực tế qua bài này. Thanks all!
Tuần trước đã có bài viết về nextTick() trong Vuejs, nhân đây muốn giới thiệu qua cho anh em luôn về Vuejs Render Process. Hiểu process của Vue mới nâng tầm lên được. Chứ cứ v-if, v-else, v-show hoài mà không biết nó render như thế nào thì toang.
Sẵn sàng chưa nào?. Xúc ngay và luôn cho nóng nha!
Trước khi tìm hiểu về Vuejs Render Process, bắt buộc phải có kiến thức về DOM (Document Object Model). Anh em nào chưa biết có thể tìm hiểu qua bài viết này. Trước đây khi có thay đổi phía FE, một node trên DOM tree thay đổi sẽ kéo theo phải render lại toàn bộ tree.
Việc thay đổi trên toàn bộ cây DOM thật sự tệ. Chính vì vậy, Virutal DOM ra đời.
Tóm tắt nhanh như tốc độ crush tỏ tình như sau:
Virtual DOM giúp tăng perfomance khi thực hiện thay đổi trên screen
Luôn có sự so sánh những gì thay đổi giữa VirtualDOM và DOM trước khi cập nhật.
Virtual DOM được sử dụng cho các dự án sử dụng Vuejs
Thực chất, khi run build Vuejs Application
2. Vuejs Render Process
Cả một quá trình dài trước khi Virtual DOM được sinh ra và phản ánh lên DOM thật. Quá trình này bao gồm 4 bước (nói rõ ra thì Vuejs Render Process) bao gồm 4 bước chính. Để hiểu rõ hơn về quá trình render, bắt buộc phải nhớ kĩ các step đó như sau:
4 bước render process của Vuejs nằm ở đây.
Nguồn / Source: Medium
2.1 defineProperty
Bắt đầu một process dài cập nhật lên DOM tree luôn là defineProperty. Ở step này, một khi dữ liệu được cập nhật và xác nhận là có thay đổi, method defineProperty sẽ được goi.
Về mặt bản chất, defineProperty có vai trò như người thông báo. Nó luôn lắng nghe cho mỗi lần data thay đổi, thông báo tới watcher sự thay đổi về data tại component.
Dữ liệu A thay đổi -> defineProperty gọi function setter -> thông báo cho watcher.
Rõ ràng mà nói, step đầu tiên trong Vuejs Render Process là defineProperty, việc xác định được data nào thay đổi báo cho watcher là bước đi vô cùng quan trọng
2.2 Watcher
Watcher được khởi tạo cho từng component trên Vue, ngay lúc application được khởi tạo. Nhiệm vụ chính của watcher là cập nhật DOM và Virtual DOM. Tuy nhiên, Watcher chỉ update cây DOM tạm thời (immediately) sau khi setter thông báo cho nó biết.
2.3 Queue
Khi thằng watcher nhận được thông báo thay đổi, nó tự đưa nó vào một hàng đợi (Queue). Nguyên nhân là có nhiều data thay đổi cùng lúc. Để xử lý được hết cần đẩy vào hàng đợi (để xử lý từ từ).
Nếu cả title và message trên component được update data cùng lúc (sau khi gọi API thành công). Vue Watcher sẽ đẩytừng thay đổi đó vào Queue (thứ tự order theo các điều kiện đặc biệt)
2.4 nextTick
Cuối cùng là nextTick API (bạn nào chưa biết có thể tham khảo bài viết này). nextTick giúp consumed and flushed (dịch tạm là chấp nhận và đẩy ra) cây DOM thật. Mỗi watcher sẽ được cập nhật lên DOM thật từ Virtual DOM. Đây cũng là cách là phương thức watch trong Vuejs hoạt động.
Việc cập nhật từ Virtual DOM lên DOM được thực hiện tự động bởi Vue qua method run(). Tuy nhiên, cũng có thể tự gọi function này khi muốn cập nhật DOM ngay lập tức.
3. Kết luận
Tóm lại, Vuejs Render Process chỉ tóm gọn lại trong bức hình dưới đây. Mỗi quá trình đều có một chức năng và nhiệm vụ khác nhau. Tuy nhiên, chỉ đơn giản nhớ rằng:
data thay đổi -> gọi defineProperty -> báo cho watcher cái gì đã thay đổi
watcher trên từng component được tạo -> nếu có nhiều watcher -> đẩy vào queue
Lần lượt từng Queue gọi nextTick() API -> cập nhật lên DOM
Qua bài viết này, mong rằng các vị huynh đài có cái nhìn khách quan và rõ ràng hơn về Vuejs Render Process. Để làm việc, code được với Vuejs thì không cần hiểu tới render process. Nhưng để trở thành master, được gọi là Senior thì cần nắm rõ kiến thức này.
Ngoài hiểu sâu để nhớ lâu, những thông tin bài viết cũng cấp còn giúp fix những bug quái lạ khi làm việc. Biết khi nào nên set data thay đổi, khi nào nên cập nhật Virtual DOM lên DOM.
Bài viết được sự cho phép của tác giả Nguyễn Văn Trọng
Sau 6 tháng trời bỏ bê thì nay mình quay lại viết lách một chút. Đợt rồi có xuất bản sách nhưng thiết nghĩ những gì viết trong đó đều ở mức rất cơ bản. Không biết thì không làm được nhưng cho dù biết hết cũng chưa chắc giỏi được. Bởi vậy mình sẽ quyết định viết tiếp cho tới khi nào anh em chán đọc thì dừng. Chắc không ai chán tại viết hay thế kia mà (muahaaa, tự an ủi).
Vào luôn chủ đề chính, nay mình tản mạn một chút về các tố chất cần thiết để có thể theo nghề này.
– Kiên trì
– Tập trung
– Thích nghi
Có rất nhiều yếu tố để tạo nên thành công trong sự nghiệp mỗi người. Mình không tự nhận bản thân đã làm được gì to tát nhưng nếu không có những tố chất trên thì rất khó để đi xa được cho tới ngày hôm nay. Bởi vì nó quá cần thiết nên muốn chia sẻ ngay cho anh em.
Nếu chọn đích đến là BrSE thực thụ thì cần có 3 kỹ năng chính : Code, JP và kỹ năng mềm. Cái này mình đã nói nhiều lần, vậy nên cho dù xuất phát điểm làm NonIT-JPN2 +, IT + NonJP, hoặc không có cái gì hết … thì cũng tới đích được, thời gian dài ngắn tuỳ điểm bắt đầu cũng như nỗ lực từng người. Cuối cùng người kiên trì nhất mới là người tới đích.
Ví dụ như việc học tiếng Nhật. Hồi sinh viên cũng chỉ tình cờ đi phỏng vấn 1 công ty Nhật về trường tuyển và pass, cũng không hiểu sao lại được chọn với tỉ lệ 40/1000 sinh viên, chắc tại đẹp trai. Sau đấy là một khoảng thời gian vật lộn với biết bao cám dỗ (game, nhậu, bóng đá …) để theo lớp tới cùng, và mình là một trong 9 người còn lại của lớp đấy trong khi mấy bạn khác bỏ hết. Sau đấy dù cố thế nào thì hợp đồng bị huỷ do khủng hoảng, vậy là hơn 6 tháng công sức đổ biển. Sau đấy ra trường đi làm, trong khi các bạn khác bỏ luôn thì mình vẫn miệt mài đi học thêm JP ở các lớp buổi tối, rồi tham gia khoá BrSE cho tới lúc có thể nghe nói đọc viết tốt và sang được JP. Nhưng sau đấy lại phải học thêm vì nghe khách nói chả hiểu mie gì, nói năng lắp ba lắp bắp nhưng trước đấy cứ nghĩ mình ngon rồi. Tiếp tục mài dùi cho tới bây giờ vẫn vậy.
Đó chính là tính kiên trì. Vậy nên nếu bạn nào đang bơ vơ lạc lõng thấy học mãi không vào thì cứ so đi, mình mất gần 10 năm học, các bạn đã bỏ ra bao lâu thời gian mà ngồi đấy than ? Không chỉ tiếng Nhật, code và kỹ năng mềm nó cũng vậy, cứ đi tiếp thì dù nhanh chậm thế nào cũng sẽ tới đích.
Tập Trung
Tập trung có thể hay bị nhầm với kiên trì. Thực sự không phải. Có những người rất kiên trì học, học JP không ổn học tiếng Anh, học không xong chuyển qua tiếng Hàn, và cứ kiên trì trong việc “HỌC NGOẠI NGỮ” nhưng quên mất rằng do thiếu sự tập trung nên chả đi tới đâu, có thể đi du lịch vòng quanh thế giới, tới đâu chào hỏi bằng thứ ngôn ngữ đó có vẻ rất siêu phàm nhưng chừng đó không đủ để làm việc – họp hành – đàm phán.
Huyền thoại võ thuật Lý Tiểu Long có một câu nói : “Tôi không sợ người luyện tập 10.000 cú đá chỉ một lần mà chỉ sợ người thực hành một cú đá 10.000 lần”. Và chính câu nói này đã giúp mình rất nhiều qua năm tháng.
Trong việc học code cũng thế, kiên trì học năm này qua năm khác, C# học 3 tháng chuyển qua Java, rồi vài tháng sau nhảy qua Python, chưa hết, khi thấy người ta thi nhau học trí tuệ nhân tạo, blockchain thì lại bỏ ngang cái đang học tiếp tục lao vào cái mới. Cứ thế đến cuối cùng cái gì cũng biết sơ sơ nhưng chả thạo, mà không thạo rất khó dùng. Có những kỹ sư chỉ biết mỗi 1 ngôn ngữ họ vẫn sống rất tốt, lương rất cao vì họ cực kỳ tập trung trau dồi cái mình mạnh nhất. Cắt nghĩa 1 chút để các bạn đỡ hiểu nhầm, vì có lần mình đã khuyên nên học để biết thật nhiều ngôn ngữ, nhưng nên nhớ phải có một thứ nổi bật nhất, giỏi nhất chứ không phải biết cho rộng nhưng không cái nào dùng được.
Lúc đi phỏng vấn thường các bài thi code người ta sẽ cho mình chọn một ngôn ngữ tự tin nhất để giải đề, dù ngôn ngữ nào cũng sẽ cho ra cùng 1 kết quả. Đó chính là lúc dùng sự tinh nhuệ. Còn trong trường hợp một dự án sử dụng nhiều loại ngôn ngữ khác nhau ví dụ : Front-End dùng html+css+Javascript+Angular+Node, Back-End dùng Java Spring Boot, Bath dùng C++(để chạy cho nhẹ trong đồng bộ dữ liệu). Đây chính là lúc cần sự hiểu rộng.
Tóm lại phải tập trung để mang lại cho mình một thứ giỏi nhất nhưng đừng quên tìm hiểu rộng ra để hình dung được mọi thứ xung quanh.
Xưa lúc còn làm công ty cũ, ktx có phòng dành cho 2 người. Vừa tiết kiệm tiền nhà cho công ty, vừa có bạn cũng vui. Mình có ở cùng ông anh hơn 3 tuổi. Cũng là kỹ sư, onsite như nhau nhưng thấy anh khó ăn khó uống, chỉ ăn được đồ Việt không ăn đồ Nhật nên 6 tháng công tác toàn nấu cho ăn, sau đó mình chuyển chỗ, anh ăn mỳ tôm 2 tháng chịu không nổi nên xin về nước. Còn mình thì cuộc sống nhẹ nhàng, thích ăn gì ăn thích ngủ đâu ngủ, có bữa còn ngủ ở ga tàu đợi 5h sáng tàu chạy mới về nhà ngủ tiếp :))) đàn hát bóng đá bóng chuyền bơi lội cái gì cũng tham gia hoà mình vào. Ngày đi làm, tối đứng bếp nấu ăn ngon không thua gì các mẹ các chị. Việc nhiều làm nhiều, việc ít thì dành thời gian đọc cái này cái kia, rồi luyện kỹ năng viết lách. Khách dễ thì mình vui, gặp khách khó chửi bới om sòm thì mình coi như gặp “thầy”, họ dạy mình để sau này gặp khách bớt khó hơn sẽ coi là dễ. Đi nhậu, khách uống bia mình bia, họ rượu mình rượu, ăn cá sống cũng ăn, ngay cả thịt gà sống người ta làm susi cũng ăn thử cho biết. Không có gì phải ngại.
Trong suốt 10 năm làm nghề đã từng rất nhiều lần chuyển dự án, chuyển team, bộ phận và kể cả chuyển việc. Mình khá quen với việc thoát ra khỏi vùng an toàn và tập thích nghi với cái mới. Phải tập vì ban đầu cái gì cũng khó khăn, và đều vượt qua cả. Như con tắc kè, nhảy vào chỗ nào lập tức đổi màu theo môi trường xung quanh để tránh bị ăn thịt. Bản thân mình cũng thế, tự biết chả giỏi giang gì nên mỗi lần tới đâu luôn cố tránh sự khác biệt nhất có thể, và không bao giờ làm mình nổi bật để người ta ghét. Nhập gia tuỳ tục, vào dự án thấy team OT thấy bà nội thì cũng xắn tay làm tới khuya cùng mọi người, cuối tuần người ta tụ tập hát hò thì cũng sắp xếp đi theo, vài buổi cũng được. Chứ đừng có kiểu chảnh chó bảo trước giờ làm 4-5 công ty, hàng chục dự án chưa phải OT lần nào, tụi bây làm gì làm, cứ kẻng đánh 6h chiều xách mông về. Vậy chỉ có làm việc với dế, trừ khi anh có thực tài làm được những việc không ai làm được thì mới được hưởng những đặc ân không ai có. Nên nhớ kỹ điều này.
Kết
Tính thích nghi nó cũng liên quan tới kiên trì, vì việc tập làm quen cái mới bao giờ cũng cần thời gian. Còn kiên trì thì bắt buộc phải tập trung thì mới có hiệu quả. 3 tố chất này bổ trợ cho nhau giúp bạn đi tới đích. Không phải ai ban đầu cũng hội tụ đủ, nhưng nếu có quyết tâm cùng với thời gian trau dồi sẽ tự khắc tiến bộ. Và chắc chắn đường xa mấy cũng tới nơi, quan trọng có chịu đi hay không, vấp ngã có tự đứng dậy hay dọc đường thấy tiên nữ tắm suối quên luôn mục đích ban đầu ?
Lâu rồi mới viết lại, thấy vẫn giữ phong độ như trước. Tay nghề không hề mai một, và đặc biệt là độ tự tin không hề suy giảm, biết dở nhưng vẫn tự khen hay kkk.
Firebase Security là phần đứng giữa data và user trong ứng dụng. Không phải ngẫu nhiên mà Google thêm nội dung này vào Firebase. Trước đây, muốn thực hiện bảo mật hoặc phân quyền cho database cần nhiều thời gian để thực hiện.
Đối với các ứng dụng lớn và phân quyền phức tạp, người ta còn viết ra cả một service riêng để check permission. Đã thiết kế vậy đòi hỏi phải thiết kế DB, nếu chưa biết có thể tham khảo các bài viết về antipattern khi thiết kế DB tại đây.
Nhưng với các ứng dụng nhỏ, không quá phức tạp thì sao?. Đấy, lúc đấy Firebase Security trở nên đơn giản, gọn nhẹ.
Nhờ vào tính flexible (linh động) và independent (độc lập), firebase database nói chung và Firebase Security càng ngày càng hot. Cùng Kieblog tìm hiểu ngay 3 điểm cần chú ý nha.
Trường hợp mà muốn test function hay feature thì có ngay mode test, mở toang cho anh em vào thử nha. Nghe hấp dẫn vcl, cùng tìm hiểu thôi
1.1 Hoạt động như thế nào?
Theo như lý thuyết từ trang chủ thì:
Firebase Security Rules work by matching a pattern against database paths, and then applying custom conditions to allow access to data at those paths.
Firebase Security Rules hoạt động bằng cách khớp các mẫu (matching a pattern) trên các đường dẫn database và áp dụng các điều kiện cho phép truy cập data hay không trên các đường dẫn này
À, vậy là tất cả các đường dẫn trên database đều có thể thiết lập các rules này. Rules thường được việt với if else, tuy nhiên cũng có thể viết các điều kiện phức tạp hơn (tùy thuộc yêu cầu của ứng dụng đang dùng).
service <<name>> {
// Match the resource path.
match <<path>> {
// Allow the request if the following conditions are true.
// Cho phép làm gì đó (read, write,...) nếu khớp điều kiện gì đó.
allow <<methods>> : if <<condition>>
}
}
2. Ba chức năng chính
2.1 Flexibility – linh hoạt
Linh hoạt ở đây không phải cho người khác dễ dàng thao tác mà là cho quản trị viên. Trường hợp muốn thay đổi rule gì đó trong security thì dễ dàng thêm thắt hay sửa đổi.
Write custom rules that make sense for your app’s structure and behavior. Rules use languages that allow you to leverage your own data to authorize access.
Viết các rules tùy biến phù hợp với cấu trúc và hành vi của ứng dụng. Rules còn được sử dụng từ các dữ liệu của chính bạn để quản lý việc truy cập.
Nói về độ flexible khi viết thì với đống Operator này là dư sức rồi nha
Tất nhiên Firebase Security viết ra không phải cho một loại ứng dụng. Chính vì vậy người dùng sẽ muốn thay đổi rule cho phù hợp với đặc thù ứng dụng của mình.
Cùng xem xét một số ví dụ sau đây nha:
// Trường hợp này lock toàn bộ document trên firestore
match /{document=**} {
allow read, write: if false;
}
// Chỉ các user đã authen mới được read, write
match /products/{productId} {
allow read: if request.auth != null;
}
2.2 Granularity – Chi tiết
Ở một số ứng dụng, việc phân chia user actions có thể chi tiết tới từng thao tác. User này có quyền được tạo data, trong khi user kia chỉ được xem.
Nhân thấy yêu cầu phân quyền chi tiết, Firebase Security chia read và write thành các thao tác chi tiết nhỏ.
In some situations, it’s useful to break down read and write into more granular operations. For example, your app may want to enforce different conditions on document creation than on document deletion. Or you may want to allow single document reads but deny large queries.
Trong một số tình huống, sẽ rất hữu ích nếu chia nhỏ read và write thành các thao tác nhỏ. Một số có thể chập nhận duy nhất một yêu cầu dọc dữ liêu, nhưng từ chối các truy vấn lớn hơn
service cloud.firestore {
match /databases/{database}/documents {
// Read chia thành get và list
match /cities/{city} {
// Applies to single document read requests
allow get: if <condition>;
// Applies to queries and collection read requests
allow list: if <condition>;
}
// Write thì chi tiết hơn, tạo, cập nhật và xóa
match /cities/{city} {
// Applies to writes to nonexistent documents
allow create: if <condition>;
// Applies to writes to existing documents
allow update: if <condition>;
// Applies to delete operations
allow delete: if <condition>;
}
}
}
Thay vì viết một service riêng rẽ kiểm tra các điều kiện để thực hiện phân quyền. Thằng Firebase Security chia nhỏ các thao tác đó ra. Phần thao tác truy cập database được phân quyền chi tiết theo các điều kiện if, dễ để kiểm soát
Việc phân quyền trong một file duy nhật với các condition còn dễ dàng cho việc maintainance sau này.
2.3 Independent security – Tính độc lập
Cái hay của Firebase Security là nó tách bạch phần phân quyền, bảo mật data riêng rẽ ra ngoài.
Mỗi database đều có một tab rules, cần gì cứ bay vào đó mà sửa thôi
Có thể một số ứng dụng phức tạp hoặc có các yêu cầu phân quyền đặc biệt không sử dụng. Nhưng đối với các ứng dụng đơn giản không có yêu cầu quá phức tạp về phân quyền có thể custom nhanh chóng phần này.
Because Rules are defined outside of your app (in the Firebase console or Firebase CLI), clients aren’t responsible for enforcing security, bugs don’t compromise data, and your data is always protected.
Bởi vì Rules được định nghĩa bên ngoài ứng dụng (trong Firebase console hoặc Firebase CLI), client không chịu trách nhiệm về vấn đề bảo mật, dữ liệu luôn được bảo vệ.
Tính độc lập của Firebase Security luôn được đánh giá cao. Dễ dàng custom và maintainance, đây là điểm cộng lớn cho Firebase. Một số đối thủ khác của Firebase đang cố gắng thực hiện tính năng tương tự.
Đây, introduction về Firebase security rules, vô cùng hữu ích
url: \(RLMRealmPathForFile(“default.realm”))”): Lệnh này sẽ hiển thị đường dẫn database của các bạn. Hãy tải cái này về để xem:
Thêm indicator và search more
Ồ nếu bạn vừa ngáp ngủ thì thôi tạm thời làm cốc trà đá, hút điếu thuốc, ngắm em bán nước mông cong 1 lúc rồi lên tiếp tục sau nha.
Theo dõi đoạn code sau:
Trường hợp mà muốn test function hay feature thì có ngay mode test, mở toang cho anh em vào thử nha. Nghe hấp dẫn vcl, cùng tìm hiểu thôi
Nói về độ flexible khi viết thì với đống Operator này là dư sức rồi nha
Mỗi database đều có một tab rules, cần gì cứ bay vào đó mà sửa thôi