Thư trả lời kết quả phỏng vấn được xem được đánh giá là khá quan trọng đối với các ứng viên. Vì thực tế, bất kỳ ứng viên nào cũng đều mong muốn nhận được phản hồi về kết quả phỏng vấn; dù có trúng tuyển hay không?
Nếu là một doanh nghiệp có công tác chuyên nghiệp trong tuyển dụng, thì việc gửi email hay gọi điện phản hồi kết quả phỏng vấn là điều nên hiển nhiên cần thực hiện. Đây cũng thể hiện doanh nghiệp có một quy trình chặt chẽ; đảm bảo tính lịch sự và để lại ấn tượng đẹp trong lòng nhiều ứng viên. Cùng TopDev tìm hiểu xem đâu là cách thức viết thư trả lời phỏng vấn hiệu quả và chuẩn nhất!
Từ chối ứng viên một cách lịch sự – Cần hay không?
Tất nhiên là có! Và đó cũng là điều mà nhiều doanh nghiệp cần phải quan tâm. Việc tìm ra cách thức để từ chối ứng viên một cách lịch sử cũng trở nên quan trọng hơn.
Và sẽ tùy thuộc vào cách xử lý của mỗi công ty cũng như phòng nhân sự; các giải pháp cụ thể dễ dàng nhất sẽ được diễn ra. Có nhiều cách thức từ chối được thông báo đến ứng viên. Đó có thể là bằng văn bản, bằng email hay bằng liên hệ qua điện thoại thông báo trực tiếp đến từng người,… Tuy vậy, cách chuyển tải nội dung thông báo kết quả qua văn bản. Cụ thể là thư trả lời kết quả phỏng vấn được xem là ưa chuộng nhất.
Có nên cần hay không?
Cùng tham khảo các mẫu trả lời ứng viên dưới đây khi ứng viên của bạn chưa may mắn trúng tuyển nhé!
Mẫu thư trả lời kết quả phỏng vấn cho ứng viên không trúng tuyển
Mẫu email trả lời lịch sự
THÔNG BÁO
V/v …………………………
Kính gửi: ………………………………………………………………………………………………..
Trước hết Công ty xin trân trọng cảm ơn Anh/Chị đã tham gia vào chương trình tuyển dụng của công ty chúng tôi.
Sau khi kiểm tra kiến thức chuyên môn, kỹ năng và phỏng vấn, Công ty xin thông báo: Anh/Chị không trúng tuyển vào vị trí: ………………………………………………………………..
Trường hợp Anh/Chị muốn nhận lại hồ sơ, xin vui lòng liên hệ Anh/Chị ………………………..
Phòng Nhân sự. Nếu Anh/Chị không lấy lại hồ sơ, chúng tôi sẽ chuyển hồ sơ Anh/Chị vào hồ sơ lưu (ứng viên tiềm năng).
Trân trọng kính chào!
TP. NHÂN SỰ
(Ký và ghi rõ họ tên)
Mẫu thư trả lời kết quả chuẩn
THƯ CẢM ƠN
V/v …………………………
Kính gửi:
Lời đầu tiên thay mặt Tập thể công ty xin trân trọng cảm ơn Anh/Chị đã tham gia vào chương trình tuyển dụng của công ty chúng tôi.
Sau khi kiểm tra kiến thức chuyên môn, kỹ năng và phỏng vấn, Công ty xin thông báo: Anh/Chị không trúng tuyển vào vị trí:
Ban tuyển dụng đánh giá cao thời gian bạn dành để ứng tuyển. Chúc bạn may mắn trong quá trình tìm việc và mong rằng có thể hợp tác với bạn ở những vị trí việc làm khác trong tương lai.
Trân trọng kính chào!
NHÂN SỰ
(Ký và ghi rõ họ tên)
Lưu ý về cách viết thư trả lời kết quả sau phỏng vấn ứng viên
Số lượng ứng viên cho một vị trí rất nhiều. Do vậy, sức cạnh tranh là vô cùng lớn. Và việc lưu ý về cách thức viết thư trả lời kết quả của buổi phỏng vấn cũng có thể giúp bạn tối ưu hóa vấn đề thời gian. Đồng thời, vẫn đảm bảo tính chuyên nghiệp, tính lịch sự,… Hãy lưu tâm đến những vấn đề sau đây:
Về thông tin cá nhân của ứng viên
Dù đó là thư từ chối ứng viên; hay thư báo kết quả ứng viên thì cũng cần đảm bảo những thông tin cá nhân cho ứng viên. Điều này minh chứng cho sự chuyên nghiệp của tổ/doanh nghiệp đó.
Lời cảm ơn rất quan trọng!
thư trả lời kết quả phỏng vấn
Một lời cảm ơn chân thành là điều mà mọi ứng viên đều mong muốn nhận được từ doanh nghiệp. Đừng quên dành lời cảm ơn đến ứng viên bởi họ đã quan tâm đến công ty cũng như vị trí mà họ ứng tuyển; dành thời gian của mình để nộp hồ sơ cũng như tham gia cuộc phỏng vấn. Đây thể hiện sự trân trọng lớn với những cố gắng mà họ đã bỏ ra.
Thư phản hồi ứng viên sau phỏng vấn cần được trình bày một cách rõ ràng; rành mạch về lý do. Không nên viết quá dài dòng và lan man. Hãy tập trung vào những yếu tố mang tính xây dựng; khuyến khích tạo động lực thay vì chỉ chia sẻ về việc ứng viên thiếu những gì và không phù hợp ở đâu.
Mời ứng tuyển lại
Đây thật sự là một điểm sáng cho thư trả lời kết quả sau phỏng vấn. Vì nếu công ty thấy ứng viên chưa phù hợp với vị trí hiện tại, hãy lưu hồ sơ của họ. Có thể sẽ có những vị trí phù hợp hơn. Việc thông báo ấy cũng tạo động lực; khích lệ tinh thần của họ một cách tốt hơn.
Lời kết
Thư trả lời kết quả phỏng vấn là một lá thư quan trọng đối với ứng viên. Và quả thật, ai trong số họ cũng quan tâm đến nó. Đó cũng là cơ sở để họ biết được tình trạng kết quả phỏng vấn của mình thế nào.
Mong rằng, với bài viết này, TopDev đã chia sẻ với các bạn các mẫu thư trả lời phỏng vấn cơ bản; cùng những lưu ý giúp thư trả lời kết quả của bạn trở nên chỉn chu; chuyên nghiệp hơn.
Tuyển Dụng Nhân Tài IT Cùng TopDev Đăng ký nhận ưu đãi & tư vấn về các giải pháp Tuyển dụng IT & Xây dựng Thương hiệu tuyển dụng ngay!
Hotline: 028.6273.3496 – Email: contact@topdev.vn
Dịch vụ: https://topdev.vn/page/products
Tự hào là nhà phân phối chính thức các thiết bị tin học tại thị trường Việt Nam, ADVN Computer đang dần chiếm ưu thế trong mối quan hệ hợp tác với các thương hiệu công nghệ hàng đầu. Với sự phát triển mạnh mẽ trong lĩnh vực outsource, ADVN Computer luôn tìm kiếm nhân tài công nghệ và sẵn sàng trao tay những cơ hội tuyệt vời.
ADVN Computer và sự tín nhiệm bởi các doanh nghiệp hàng đầu về công nghệ
Ruby on Rails Developer
Vươn lên từ sự thành công của công ty mẹ – AceCom tại Singapore, ADVN Software hình thành năm 2014 với nền tảng ban đầu là nhà phân phối Công nghệ thông tin. Đến nay, ADVN Computer đã trở thành một trong những Công ty phần mềm cung cấp ứng dụng Website, Mobile App, Quảng cáo Google… được ưa chuộng nhất tại thị trường Việt Nam.
Từ năm 2016, ADVN Computer trở thành nhà phân phối chính thức các thiết bị tin học mang thương hiệu tầm cỡ thế giới tại Việt Nam, khẳng định vị thế của mình bởi sự tín nhiệm từ các thương hiệu công nghệ hàng đầu như MSI, Sony, Hitachi, InFocus, Prolink…
Với mục tiêu tập trung phát triển các dự án outsource, thương mại điện tử và quảng cáo chất lượng, công ty luôn nỗ lực tìm tòi, áp dụng công nghệ hiện đại, đồng thời từ đó đáp ứng tối đa và tối ưu các yêu cầu từ khách hàng.
Hoạt động với phương châm “Chuyên nghiệp, sáng tạo, chất lượng” và sự tin cậy từ các Nhà sản xuất, ADVN Computer được chỉ định là Trung Tâm Bảo Hành Ủy Quyền Chính Thức tại Việt Nam cho tất cả các thương hiệu nhằm đảm bảo quyền lợi tuyệt đối về chất lượng, giá cả, kỹ thuật, chế độ hậu mãi (Motorola).
Và để đạt được thành tựu to lớn đó, ADVN Computer luôn ghi nhận tài năng và công sức của đội ngũ “chiến binh” công nghệ – những “phần tử” tài năng luôn cố gắng hết sức mình cho sự phát triển của công ty.
Con đường sự nghiệp rộng mở dành cho Ruby on Rails Developer khi gia nhập ADVN Computer
Ruby on Rails Developer
Ở thời điểm hiện tại, Team Dev nhà ADVN Computer đang tìm kiếm “nhân tố” tài năng cho vị trí Ruby on Rails Developer, với nhiệm vụ hỗ trợ công ty phát triển trang web, trang thương mại điện tử và ứng dụng di động, đáp ứng các nhu cầu từ phía khách hàng.
Và nếu bạn đã nhen nhóm dự định lựa chọn ADVN Computer làm “điểm đến” để phát triển sự nghiệp, đừng ngại gửi CV ứng tuyển ngay hôm nay. ADVN Computer sẵn sàng mang đến cho bạn điều kiện tốt nhất về không gian làm việc, đi kèm với mức lương thưởng và đãi ngộ xứng đáng:
Mức lương hấp dẫn $1,000 – $1,500;
Review lương hàng năm, nâng cao chất lượng sống;
Được đảm bảo mọi quyền lợi các chế độ (ngày phép năm, gói bảo hiểm) đầy đủ theo luật Việt Nam;
Được thử sức mình với các dự án đầy tính thử thách, cải thiện và trau dồi kỹ năng làm việc theo nhóm;
Cơ hội phát triển mạnh mẽ với sự hướng dẫn tận tình, giúp đỡ từ “đàn anh” trong công ty;
Được làm việc trong môi trường quốc tế chuyên nghiệp, thân thiện với đầy đủ tiện nghi và không gian tuyệt vời cho bạn thỏa sức đam mê;
Cùng nhiều hoạt động tập thể, team building, sự kiện thú vị khác.
Review source code không phải là “nhiệm vụ” giới hạn cho bất kì vị trí nào. Dù là dev hay senior dev, tech lead đều “rất rất cần” tự review source code của chính mình.
Bài viết này xin chia sẻ chút kinh nghiệm nhỏ nhoi khi review source cho người khác. Viết sao cho tốt. Trình bày vấn đề sao cho rõ ràng. Đặt câu hỏi sao cho thông minh?. Tất cả sẽ có ngay sau đây.
Hiểu định nghĩa là quan trọng. Nhiều khi lên mặt review dạy đời là không đúng.
Code Review, or Peer Code Review, is the act of consciously and systematically convening with one’s fellow programmers to check each other’s code for mistakes, and has been repeatedly shown to accelerate and streamline the process of software development like few other practices can.
Code Review, hoặc Peer Code review, là hành động kêu gọi có “ý thức”, có “hệ thống” với các lập trình viên đồng nghiệp để kiểm tra code của nhau có đúng hay không. Việc này đã nhiều lần được chứng minh là đẩy nhanh và hợp lý hóa tiến trình phát triển phần mềm như một số cách khác có thể làm được
Đấy, bản thân review source code là đi tìm lỗi trong các đoạn code. Chỉ ra các điểm sai, các điểm chưa hợp lý hoặc có thể cải thiện cho code.
Đã bảo rồi!. Review Source Code có dễ bao giờ đâu
Tuy nhiên, không phải bất cứ điểm nào bất hợp lý cũng raise lên. Tùy thuộc dự án, người review mà cần “không khéo” khi post các thread review hoặc bày tỏ quan điểm.
2. Chỉ thị hoặc yêu cầu trực tiếp
Chỉ thị hoặc các yêu cầu trực tiếp trong Review Source Code thường được sử dụng khi nội dung review đã “sai” rõ ràng. Cần được xử lý ngay lập tức.
Một số vấn đề đơn cử có thể được nêu ra như sau:
Vi phạm Coding Convention
Code sai dẫn tới sai bussiness
Vi phạm hoặc có khả năng xảy ra vấn đề trong tương lai
Không handle hết tất cả các case
Trường hợp này, các vấn đề được nêu lên trực tiếp. Yêu cầu người viết code phải sửa vấn đề. Tất nhiên, tùy thuộc độ nghiêm trọng và phạm vi ảnh hưởng có thể bàn bạc cách thức đối ứng.
Việc sử dụng yêu cầu trực tiếp là cần thiết để biết vấn đề nào đã gặp và không nên để tiếp diễn ở lần sau. Tuy nhiên hạn chế sử dụng khi vấn đề không chắc chắn. Lúc này ta nên sử dụng Các câu hỏi mở.
3. Các câu hỏi mở
Các câu hỏi mở thường được sử dụng khi:
Vấn đề được raise lên cần được bàn luận kĩ hơn để có lựa chọn tối ưu thay thế hoặc không thay thế cách hiện tại.
Giải pháp suy nghĩ trong đầu có thể không chính xác. Cần tham khảo.
Gợi ý cho người được review tìm hiểu thêm về một vấn đề nào đó.
Các câu hỏi mở giúp tìm hiểu thêm để giải quyết vấn đề. Hiểu hơn về source mà mình viết ra.
Việc sử dụng các câu hỏi mở vừa “khêu gợi”. Lộn, “kích thích” tìm hiểu vấn đề được bàn luận trong code. Vừa giúp “hạ nhiệt” các vấn đề được review, đảm bảo không khí review source code không trở nên quá nóng bỏng.
4. Thông tin cần thiết
Review source code đôi khi cần thông tin đi kèm. Những thông tin này thường được gọi là rule. Việc chấp hành các “luật lệ” này đảm bảo việc review diễn ra suôn sẻ. Luôn có đáp án chính xác cho từng review.
Một số rule có thể được kể ra như sau.
Review code cho biết chính xác dòng code, method nào, variable nào vi phạm hoặc cần xem xét.
Taglib cho từng review (bussiness sẽ cần fix gấp, convention đôi khi không cần quá gấp hoặc áp dụng sau,…)
Checkmark hoặc comment cho biết review đã được fixed, không đối ứng hoặc bất cứ thông tin gì thêm.
Rule đôi khi vô cùng hữu ích, giúp quá trình review source trở nên “dễ thở” hơn
Luật lệ tất nhiên có thể khác nhau tùy thuộc yêu cầu từng dự án. Một số dự án mình đã tham gia sẽ trả MR (Merge Request) về cho dev khi có vấn đề cần fix hoặc cần consider. Khi đã fix xong sẽ trả lại cho reviewer để check và merge.
Việc này có thể tiến hành linh hoạt tùy “tình hình, tiến độ” project, số lượng member, … Tuy nhiên nên lựa chọn cách dễ dàng nhất mà vẫn đảm bảo yêu cầu của việc review code.
OpenSSH là một chương trình mã nguồn mở (Open Source) được sử dụng để mã hoá (encrypt) các giao dịch giữa các host với nhau bằng cách sử dụng Secure Shell (SSH). Nó là một sự thay thế an toàn cho những chương trình được sử dụng để kết nối như: Telnet, rlogin, rsh…Bởi nó luôn luôn mã hoá (encrypt) tất cả các giao dịch, ẩn đi, che dấu username và password được sử dụng cho những phiên đăng nhập từ xa. Sau khi phiên đăng nhập được thực hiện, nó sẽ tiếp tục mã hoá (encrypt) tất cả những dữ liệu giao dịch giữa 2 host.
Dự án OpenSSH được phát triển dựa trên nền tảng của dự án Open BSD (một OS thuộc họ Unix). Nó được thiết kế để sử dụng những thuật toán mã hoá mạnh để nâng cao tính an toàn và ngăn chặn sự phá hoại của các hacker. Mặc dù được xây dựng và phát triển bởi nền tảng OpenBSD, nó cũng có khả năng tương thích và có thể hoạt động trên hầu hết các OS thuộc dòng họ Unix: Linux, HP-UX, AIX, Irix, SCO, MacOS X, Cygwin, Digital Unix/Tru64/OSF, SNI/Reliant Unix, NeXT, Solaris…
OpenSSH không phải là một chương trình. Nó là một bộ các chương trình kết nối an toàn:
– OpenSSH Client (ssh): Chương trình được sử dụng cho các đăng nhập từ xa. Với sự an toàn và mã hoá (encrypt) trong mỗi phiên đăng nhập ở mức độ cao. Nó là sự thay thế an toàn cho: rlogin và telnet đã tỏ ra lỗi thời và kém an toàn.
– Secure Copy Program (scp): Được sử dụng cho việc copy file từ xa, copy các file từ các host khác nhau trên Internet. Nó hỗ trợ username và password.
– Secure File Transfer Program (sftp): Được sử dụng để phục các yêu cầu FTP một cách an toàn.
– OpenSSH Deadmon (shhd): Đặt OpenSSH chạy ở chế độ daemon trên các hệ thống Unix.
…………….
Trên đây là những Tools chính không thể thiếu trong bộ OpenSSH. Ngoài ra còn rất nhiều Tools, Plugin, Addin nữa…
Để lấy OpenSSH bạn lên Homepage chính của nó:http://www.openssh.org
Download một version phù hợp với hệ thống của mình. Tôi dùng Linux nên tôi sẽ download gói *.rpm. Sau đó sử dụng lệnh
root@domain.com#: rpm -Uvh *.rpm
Nếu bạn sử dụng các hệ thống khác thì việc cài đặt nó cũng tương tự. Bạn download gói phù hợp với hệ thống của mình. Nó có thể là *.tar, *.tar.gz, *.gz…etc. Bung nén nó vào một thư mục.
root@domain.com #: ./configure
root@domain.com #: make
root@domain.com #: make install
Tiếp đó theo làm theo các chỉ dẫn của script. Công việc cài đặt không mấy khó khăn. Chúng ta hãy dành thời gian và công sức cho công việc cấu hình.
CÁC TÍNH NỔI BẬT CỦA OPEN SSH
Open SSH cung cấp khá nhiều tính năng để giúp cho việc truyền thông giữa 2 host trở lên an toàn. Dưới đây là một số tính nổi bật:
1) Khả năng mã hoá mạnh bởi việc sử dụng chuẩn mã hoá 3 DES và Blowfish: Cả 2 chuẩn mã hoá trên đều đuợc cung cấp miễn phí và sử dụng rộng rãi ở nhiều nước trên thế giới. 3DES cung cấp khả năng mã hoá chứng thực thời gian. Blowfish cung cấp khả năng mã hoá nhanh hơn. Cũng như những chuẩn mã hoá khác cả 2 chuẩn nêu trên đều cung cấp khả năng mã hoá các dữ liệu trước khi nó được đưa vào đường truyền một cách an toàn. 2)Khả năng chứng thực mạnh bởi việc sử dụng các cơ chế Public Key, OPTs (One Time Password), Kerberos: Có tác dụng bảo vệ chống lại tính dễ tổn thương trong quá trình chứng thực bởi việc khai thác và sử dụng các kỹ thuật như: IP Spoof, DNS Spoof, Fake Router…Có 4 phương pháp chứng thực được Open SSH sử dụng :
– Chỉ chứng thực Public Key
– Sự chứng thực host bởi việc sử dụng Public Key kết hợp với .rhost – Sự chứng thực dựa trên OPTs kết hợp với s/key
– Sự chứng thực dựa trên cơ chế Kerberos 3) Mã hoá giao thức X11 cho việc sử dụng X Window: Mã hoá dữ liệu trong quá trình sử dụng X Window giữa 2 host. Được sử dụng để chống lại những cuộc tấn công từ xa nhằm vào xterm như Snooping, Hjacking… 4) Mã hoá cho quá trình chuyển đổi cổng (Port Forwarding): Cho phép quá trình chuyển đổi các port TCP/IP tới một hệ thống khác thông qua một kênh được mã hoá. Nó được sử dụng cho những giao thức Internet chuẩn không cung cấp khả năng mã hoá dữ liệu trên đường truyền như: SMTP, POP, FTP, Telnet… 5) Đại diện chuyển tiếp cho những đăng nhập vào các mạng đơn: Một Key chứng thực của người dùng có thể và thường được lưu giữ trên PC của họ, nó có thể trở thành một trạm đại diện chứng thực. Khi người sử dụng hệ thống truy cập từ một hệ thống mạng khác. Kết nối của họ sẽ được chuyển tới cho trạm đại diện chứng thực này. Nó có tác dụng cho phép người sử dụng truy cập đến hệ thống của bạn một cách an toàn từ bất kỳ hệ thống nào. 6)Nén dữ liệu: Cung cấp khả năng nén dữ liệu một cách an toàn. Nó rất có ý nghĩa trên những hệ thống mạng không được nhanh. 7) Chứng thực chung cho Kerberos và Andrew File System bằng cách sử dụng Ticket: Những người sử dụng Kerberos và AFS sẽ được cung cấp một password chung để sử dụng và truy cập 2 dịch vụ trên trong một thời gian nhất định.
Bài viết được sự cho phép của tác giả Nguyễn Việt Hưng
Học và hành thường ở rất xa nhau. Ta có thể học đủ loại khái niệm, đủ loại cú pháp, viết các thuật toán để luyện ngôn ngữ, nhưng rồi lại mãi luẩn quẩn ở đó, không thoát ra được, không bay lên nổi. Viết 1 vòng for, 2 câu if bằng Python, JavaScript, Golang hay Elixir cũng không hơn nhau gì cả, chỉ thay đổi chút cú pháp thôi.
Thế nên cách “tốt nhất” để học 1 ngôn ngữ lập trình, không phải là học đủ các khái niệm, best practice, viết code chuẩn đẹp tuyệt đối, mà là việc hoàn thành một sản phẩm từ đầu đến tận X Y Z. Đưa ra sản phẩm cuối cùng, có thể là trang web chạy với domain hẳn hoi, có thể là chương trình đóng thành package, thành file cài đặt, hay game có giao diện đầy đủ.
Package manager giúp cài đặt các thư viện có sẵn là công cụ giúp ta đến đích nhanh nhất. Python có pip, JavaScript có NPM, Elixir có mix, Rust có cargo … thì CHICKEN Scheme có chicken-install, câu lệnh có sẵn khi cài CHICKEN Scheme.
Ta thu được list các phần tử có chứa số, string “[0-9]” là regular expression biểu diễn một số hệ 10.
Đọc tài liệu của module/function
grep ở trên làm gì? CHICKEN Scheme có chương trình chicken-doc để tra tài liêu, tương tự python có pydoc. Để có chicken-doc, cần cài extension với lệnh: sudo chicken-install chicken-doc.
$ chicken-doc grep
path: (regex grep)
-- procedure: (grep REGEX LIST [ACCESSOR])
Returns all items of `LIST` that match the regular expression `REGEX`. This procedure could be defined as follows:
(define (grep regex lst)(filter (lambda (x)(string-search regex x)) lst))`ACCESSOR` is an optional accessor-procedure applied to each element before doing the match. It should take a single argument
and return a string that will then be used in the regular expression matching. `ACCESSOR` defaults to the identity function.
$ chicken-doc -i scheme # đầy đủ doc về R5RS
...
$ chicken-doc -c scheme # danh sách các procedure trong R5RS
...
$ chicken-doc data-structures
path: (data-structures)== Unit data-structures
This unit contains a collection of procedures related to data structures. This unit is used by default, unless the
program is compiled with the `-explicit-use` option.
...
$ chicken-doc when # tìm từ khóa when, thấy 2 kết quả
Found 2 matches:
(spock when)(when X1 BODY ...)(chicken special-forms when)(when TEST EXP1 EXP2 ...)
$ chicken-doc chicken special-forms when # xem kết quả thứ 2
-- syntax: (when TEST EXP1 EXP2 ...)
Equivalent to:
(if TEST (begin EXP1 EXP2 ...))
Pydoc đi kèm với Python có khả năng tương tự:
$ pydoc len
Help on built-in function len in module builtins:
len(obj, /)
Return the number of items in a container.
Liệt kê các extension có trên “mạng”
$ chicken-install -list
2d-primitives
3viewer
9ML-toolkit
9p
AD
F-operator
R
abnf
accents-substitute
...
Tại thời điểm viết bài, có 781 egg trong kho – hơi ít.
Phần chú thích trong lập trình C là phần bị bỏ qua khi thực hiện compile. Chỉ có ý nghĩa về mặt text hiển thị giúp lập trình viên hiểu hơn về đoạn code.
Phần chú thích nằm sau dấu gạch chéo // (trường hợp comment trong 1 dòng) hoặc nằm trong /* */ (trường hợp comment nằm trên nhiều dòng)
Ví dụ:
/* * in ra màn hình dòng chữ * Hello World! */printf("Hello World \n");// khai báo tuổi bằng 10int age = 10;
Định danh (identifier)
Định danh trong C là một cái tên dùng để xác định một biến, một hàm (tên biến, tên hàm).
Định danh có thể bao gồm các ký tự a-z, A-Z, 0-9 hoặc dấu gạch dưới _. Tuy nhiên định danh không được bắt đầu bằng 0-9.
Đặc biệt, định danh không được trùng với các từ khóa của ngôn ngữ C.
Ví dụ một số định danh hợp lệ: name, _age, address1, firstName
5 tips thúc đẩy sự sáng tạo trong quá trình coding
Tác giả: Andrej Kovacevic
Khó khăn trong lúc lập trình là một trong những vấn đề mà bất kì lập trình viên nào cũng có thể gặp phải. Với một số lập trình viên, việc mỗi ngày đều phải tiếp xúc với dấu chấm phẩy, dấu ngoặc và dấu ngoặc đơn (ai mà không lãng phí hàng giờ để tìm kiếm một trong những thứ mà họ đặt sai vị trí hoặc bỏ sót), gần như đã trở thành một sự “ám ảnh”.
Đối phó với việc bí ý tưởng như thế nào?
Nhưng hiện nay, vấn đề lập trình phổ biến nhất mà các lập trình viên trải qua chính là mắc kẹt trong các ý tưởng, không thể cho ra những đoạn code và đạt kết quả mà mình mong muốn. Nhờ những kinh nghiệm làm việc của bản thân, tôi sẽ chia sẻ với bạn về việc làm thế nào để khắc phục tình trạng này.
1. Bắt đầu các dự án trên giấy trước
Hầu như bất cứ khi nào tôi gặp rắc rối khi làm việc trong một dự án, những khó khăn trong lập trình phát sinh tôi đều có thể truy tìm nguyên nhân cụ thể của nó. Bằng cách nào? Đó là tôi đã cố gắng xây dựng các dự án bằng cách xoay quanh tổng thể những việc cần phải làm.
Khi bạn làm điều này, bạn sẽ nhận ra sự to lớn và đa dạng của dự án mã hóa mà bạn phải làm việc. Thêm vào đó, bắt đầu viết code mà không có ý tưởng cụ thể về thứ mình cần làm là gì, kết quả sau cùng chắc chắn sẽ không tốt, thậm chí là một sự thất bại đáng sợ.
Thay vào đó, hãy phác thảo những nét sơ bộ về dự án sắp phải làm việc trên giấy trước. Đó là điều mà các lập trình viên thế hệ trước thường làm theo thói quen, nhưng các lập trình viên trẻ tuổi hiện tại có xu hướng bỏ qua. Tất cả những gì bạn phải làm là viết ra mục đích hoạt động của chương trình, sau đó là danh sách các chức năng con mà bạn nghĩ sẽ làm cho mọi thứ hoạt động tốt hơn.
Hành động tưởng chừng đơn giản này giúp bạn dễ dàng chia nhỏ dự án thành các phần hợp lý hơn. Ngoài ra, đây cũng là cơ hội phát hiện trước các vấn đề có thể làm bạn chậm lại trong quá trình làm việc sau này.
2. Hoạt động trong SandBox
Đôi khi cách tốt nhất để vượt qua việc bí ý tưởng trong lúc lập trình là xây dựng một thứ gì đó – bất cứ thứ gì – miễn là nó hoạt động được. Vì vậy, nếu tôi gặp phải một nội dung khó khăn mà cảm giác khiến tôi như chẳng thế tiến thêm được kết quả gì, tôi sẽ chuyển sang SandBox và cố gắng xây dựng một thứ gì đó thú vị hơn với nền tảng này.
Bởi vì tôi thường làm việc và xử lý giao diện người dùng web, các trang web tôi thường truy cập sẽ là CodeSandbox và CodePen, nhưng chắc chắn sẽ có nhiều website khác có thể phù hợp với nhu cầu của bạn hơn một chút.
Ví dụ: Replit sẽ cho phép người dùng viết code trực tiếp bằng hơn 50 ngôn ngữ và thậm chí có thể chuyển sang cộng đồng tích hợp của họ để yêu cầu trợ giúp nếu bạn gặp khó khăn về vấn đề nào đó.
Một điều góp phần vào việc xây dựng ý tưởng lập trình của cá nhân tôi là không có danh sách các nhiệm vụ đơn giản, có thể hoàn thành ngay, mà tôi có thể chuyển sang khi muốn tiếp tục đạt được tiến độ trong một dự án.
Nói cách khác, khi bạn đang làm việc với một thứ gì đó đặc biệt khó khăn trong lập trình, bạn sẽ muốn dành thật nhiều thời gian để suy nghĩ và hoàn thành nó. Dù dành ra quá nhiều thời gian nhưng có thể kết quả sẽ chẳng thể đi đến đâu. Để tránh phải điều đó, bạn nên duy trì một danh sách những task còn tồn đọng trong suốt quá trình chạy dự án. Tôi sử dụng một công cụ tương tự như một Scrum product backlog (ngay cả khi tôi không làm việc với một nhóm) để lưu trữ thông tin.
Ghi chú vào đó những thứ như tái cấu trúc mã và thay đổi giao diện,… Những vấn đề đơn giản sẽ có độ ưu tiên thấp nhất và cứ thế triển khai với vấn đề khó khăn hơn. Sau đó, khi gặp trục trặc, bạn có thể giải quyết những việc đơn giản đó như một phương tiện để tiếp tục tiến lên với dự án của mình.
Đôi khi, hoàn thành ngay cả một nhiệm vụ đơn giản nhất cũng đủ giúp bạn trở lại đúng hướng và tạo ra những code tốt một lần nữa nhờ cảm giác tin tưởng vào bản thân hơn.
4. Nghỉ ngơi đúng cách và có chiến lược
Nếu bạn dành một chút thời gian để tra cứu ý tưởng lập trình trên công cụ tìm kiếm yêu thích của mình, mỗi bài viết bạn thấy sẽ đều khuyên bạn nên nghỉ ngơi để thoát khỏi những áp lực và thử thách lập trình khó khăn. Tuy nhiên, điều quan trọng là bạn phải biết cách để thư giãn một cách hợp lí. Việc nghỉ ngơi thiếu logic có thể là một con dao hai lưỡi. Nếu không cẩn thận, những khoảng thời gian nghỉ của bạn sẽ bị lãng phí cho những thứ khác, chẳng hạn như sẽ chìm đắm vào chiếc điện thoại hay game đang chơi dở. Lúc này thì những khó khăn trong lập trình sẽ như quả cầu tuyết – càng lăn càng lớn.
Tôi đã nhận ra điều này khi lần đầu tiên tìm kiếm các mẹo vượt qua khó khăn khi lập trình. Lúc đầu, tôi khá có trách nhiệm với những khoảng thời gian nghỉ ngơi của mình – chỉ cần đi bộ năm phút hoặc đến máy pha cà phê khi tôi muốn đầu óc tỉnh táo, rồi sau đó tôi sẽ quay lại với công việc.
Nhưng ngay sau đó, tôi nhận ra mình đang tìm kiếm lý do để không bị phân tâm vào bất cứ điều gì tôi đang mắc kẹt. Chẳng hạn như việc tôi dành nửa ngày lùng sục trên internet để tìm một chiếc card màn hình PCIe có giá cả hợp lý mà không cần phải đưa vào danh sách chờ.
Nghỉ giải lao là một cách hợp lý để thử và vượt qua việc bí ý tưởng, nhưng đương nhiên, đó là chỉ khi bạn sử dụng chúng một cách đúng đắn. Cuối cùng tôi nhận thấy rằng việc sử dụng thời gian có hạn, không sử dụng máy tính hoạt động tốt như là bước cuối cùng trong quá trình thiết lập lại có chủ ý cho não của tôi.
Hiện tại, khi tôi gặp khó khăn, thời gian nghỉ ngơi của tôi sẽ như thế này:
Dành 15 phút để giải quyết vấn đề
Dành 5 phút để xem xét mọi thứ từ đầu
Dành thêm 15 phút để giải quyết vấn đề
Đi bộ ít nhất 10 phút để làm điều gì đó không liên quan đến mã hóa
Bắt đầu lại từ đầu
Hầu như mọi lúc, tôi sẽ tìm thấy câu trả lời mà tôi đang tìm kiếm sau khi nghỉ ngơi khoảng 10 phút như thế này. Đó là lý do tại sao phải có một khoảng thời gian ngắn sau đó ngay lập tức quay trở lại với nó. Lâu hơn nữa có thể khiến bạn bị phân tâm và thậm chí quên mất mình đã dừng lại ở đâu và cần làm gì tiếp theo.
Và nếu may mắn, bạn sẽ không phải lặp lại quá trình trên thường xuyên. Bằng cách đó, bạn có thể tập trung và tránh lãng phí quá nhiều thời gian cho những công việc không hiệu quả. Tuy nhiên, hãy cẩn thận, không được bỏ qua hoàn toàn các giờ giải lao. Bạn nên cân nhắc thời gian giãn cách công việc để thư giãn, nó không chỉ tốt cho việc phát huy ý tưởng mới mà còn cần thiết vì sức khỏe của bạn.
5. Luôn luôn để lại những ghi chú cần thiết
Khi nói đến sự khó khăn trong việc phát triển các ý tưởng phần mềm, câu nói “phòng bệnh hơn chữa bệnh” chắc chắn không thể đúng hơn. Đó là lý do tại sao tôi xây dựng thói quen kiểm soát thời gian và cách thức tôi tạm dừng công việc của mình khi đang thực hiện một dự án mã hóa.
Tôi làm điều này bởi vì tôi thấy rằng việc bị gián đoạn và không hoàn thành được bất cứ việc gì đang làm giữa chừng không gây ra vấn đề gì, ngoài việc đau đầu để tìm lại vị trí công việc ở nơi mà tôi đã dừng lại.
Thay vào đó, nếu tôi cần ngừng làm việc, tôi sẽ để lại những ghi chú cụ thể và chi tiết cho biết tôi cần làm gì tiếp theo. Ngay cả khi tôi đang vội, tôi vẫn để lại vài dòng note để dễ dàng hơn khi bắt nhịp công việc của mình lúc quay lại.
Nó giúp tôi giảm được những rắc rối liên quan đến việc quay trở lại “chế độ lập trình” vì tôi không phải suy nghĩ quá nhiều để bắt đầu tại nơi tôi đã dừng lại. Cả hai vấn đề đều có thể làm bạn chậm lại và khiến bạn gặp nhiều trở ngại trong việc lập trình.
Tiếp tục với chuỗi bài viết về Behaviral Pattern (Pattern hành vi), hôm nay là Mediator Design Pattern. Pattern này cũng khá là dễ nhớ nếu hiểu về concepts. Ngoài ra, nó cũng có đôi điểm tương đồng và đôi khi hay bị nhầm lẫn với Observer Pattern.
Mediator Design Pattern is a behavioral design pattern that lets you reduce chaotic dependencies between objects. The pattern restricts direct communications between the objects and forces them to collaborate only via a mediator object.
Mediator Design Pattern là dạng pattern hành vi, cho phép giảm bớt sự phụ thuộc hỗn loạn giữa các đối tượng. Mẫu này cũng tắt tất cả các giao tiếp giữa object, bắt buộc tất cả các object khi muốn comunication đều phải thông qua đối tượng mediator.
Vì kiểm soát cách thức giao tiếp (communication) giữa các object nên thuộc về behavioral (hành vi). Để dễ nhớ hơn, ta có thể xem Mediator như cảnh sách giao thông thực hiện điều tiết ở ngã tư.
Tuy nhiên điều tiết không chỉ đơn thuần là bấm đèn xanh đỏ, tất cả giao thông qua lại ngã tư đều chịu sự điều khiển của anh cảnh sát này.
2. Bài toán thực tế
Phi công và tất cả các phương tiện bay trên trời đều cần được điều khiển. Trong thực tế được biết tới với tên (Đài kiểm soát không lưu).
Để tránh xảy ra va chạm, rõ ràng tất cả cá phương tiện bay (máy bay, trực thăng, thủy phi cơ,…) đều phải điện tới Đài kiểm soát không lưu. Với trách nhiệm chính của đài không lưu:
Phân luồng bay, đảm bảo không xảy ra va chạm
Điều tiết đường băng cho máy bay hạ cánh
Bắt tay thiết kế hệ thống này, ta có thể nghĩ tới ngay Mediator Design Pattern. Đài kiểm soát không lưu lúc này trở thành Mediator.
Quay trở lại với bài toán trong nghề của anh em mình. Giả sử như đang có một cái task khá khoai tạo một dialog với nhiệm vụ edit. Trên dialog có nhiều Button, Checkbox, TextField, Tabs. Một số form trên dialog còn tương tác với element ở form khác. Lúc này, chỉ mỗi cái checkbox thôi cũng có vô vàn relations tới các element khác.
Nếu hệ thống phức tạp và có nhiều elements trên màn hình. Lúc này, class implement cho Checkbox, Button thực tất không thể tái sử dụng, không thể sử dụng ở form hay màn hình khác.
3. Giải quyết vấn đề
Rồi, Mediator Design Pattern giải quyết vấn đề nêu trên như thế nào?
Mediator lúc này đúng nghĩa là cảnh sát, quyền uy tối thượng. Mediator sẽ loại bỏ hết tất cả các communication giữa các component. Trường hợp ta muốn component A độc lập với các component khác, mediator sẽ xóa tất cả các liên kết tới A.
Sau khi đã xóa, Mediator Object đóng vai trò như người trung gian, tất cả giao tiếp đều phải thông qua Mediator Object.
Các element trên UI lúc này phải giao tiếp gián tiếp với nhau thông qua Mediator Object, không được communication trực tiếp nữa. Về cấu trúc, Mediator Design Pattern bao gồm những thành phần như sau:
Components là các class bao gồm một số logic xử lí business. Tất cả các component đều sẽ reference tới Mediator Interface, khai báo kiểu của mediator interface. Do implement interface nên có thể tái sử dụng component trong chương trình khác bằng cách link tới Mediator mới.
Mediator Interface khai báo những method phục vụ giao tiếp với components, thường bao gồm một method (notification method).
ConcreteMediator đóng gói tất cả các relation giữa các component lại với nhau. Giữ tham chiếu tới tất cả component, đôi khi còn quản lý vòng đời của component
Với thiết kế này, Component không bao giờ liên lạc trực tiếp với component khác. Nếu muốn, Component A có thể gửi notify tới Mediator. Lúc Mediator nhận được thông báo, nó sẽ định dạng được thằng component nào đang gọi.
Components should store a reference to the mediator object. The connection is usually established in the component’s constructor, where a mediator object is passed as anargument.
Components nên lưu trữ tham chiếu tới mediator object. Kết nối này thường được thiết lập trong component constructor, mediator object lúc này được truyền tới như là tham số
Khi tất cả action đã đăng kí ở Mediator. Một action được gọi ở Component sẽ giao tiếp thông qua Mediator. Ví dụ dưới đây là action deleteNote().
Java
import javax.swing.*;
import java.awt.event.ActionEvent;
/**
* EN: Concrete components don't talk with each other. They have only one
* communication channel–sending requests to the mediator.
*
*/
public class DeleteButton extends JButton implements Component {
private Mediator mediator;
public DeleteButton() {
super("Del");
}
@Override
public void setMediator(Mediator mediator) {
this.mediator = mediator;
}
@Override
protected void fireActionPerformed(ActionEvent actionEvent) {
mediator.deleteNote();
}
@Override
public String getName() {
return "DelButton";
}
}
4. Tổng kết
Đầu tiên, nói về ưu điểm:
Mediator đáp ứng được Single Responsibility Principle, communication giữa các component được tổng hợp về một nơi, dễ dàng để quản lý hoặc maintainance sau này. Thứ hai nữa là Open/Closed Principle, trường hợp cần mở rộng, có thể dễ dàng tạo ra mediator mới (không cần phải thay đổi trong component).
The primary goal of Mediator is to eliminate mutual dependencies among a set of system components. Instead, these components become dependent on a single mediator object. The goal of Observer is to establish dynamic one-way connections between objects, where some objects act as subordinates of others.
Mục đích chính cuẩ Mediator là loại bỏ sự phụ thuộc lẫn nhau giữa các components trong hệ thống. Thay vào đó, các component trở nên đọc lập với nhau, giao tiếp thông qua mediator object. Còn mục tiêu của Observers là thiết lập kết nối một chiều giữa objects. Objects này có thể làm ông nội của các objects khác.
Tuy nhiên, nếu implement Mediator theo chiều hướng subscribe và unsubscribe. Các component đăng kí và hủy đăng kí thông qua Mediator object, lúc này, đọc vào chưa chắc là nhận ra được cái khác giữa 2 cha nội này.
A/B testing và những tiêu chí chính để đánh giá sự thành công của ASO
ASO hay còn gọi là App Store Optimization – là một hoạt động giúp tối ưu hóa việc hiển thị ứng dụng trên app store. Theo báo cáo của Branch trong Mobile Growth Handbook 2020, 65% users tải app thông qua việc tìm kiếm trên app store, vì vậy nên ASO trở thành một trong những yếu tố quan trọng hàng đầu khi thực hiện Mobile Marketing. App càng được nhiều người nhìn thấy thì việc tìm kiếm cũng trở nên thuận tiện hơn và họ dễ dàng tải app về sử dụng.
ASO ảnh hưởng thế nào đến sự tăng trưởng của ứng dụng?
Trước tiên, ASO đòi hỏi phải tăng khả năng được nhìn thấy của ứng dụng trên Appstore. Cơ hội nhìn thấy càng nhiều thì app sẽ càng được cài đặt nhiều hơn. Càng nhiều user cài đặt thì cơ hội kiếm tiền của công ty sẽ càng cao hơn. Chưa kể khi làm tốt phần ASO thì giá trị và chi phí để tìm một user mới sẽ giảm đi, từ đó lợi nhuận sẽ còn tăng lên cao hơn. Đó là cách ASO ảnh hưởng một cách tích cực đến sự tăng trưởng ứng dụng.
Các tiêu chí đánh giá sự thành công của ASO
Hiện tại đang có khá nhiều cách để đánh giá vấn đề này, tuy nhiên có 2 yếu tố mấu chốt mà bạn không thể bỏ qua đó là Impression và Conversion.
Vậy Impression của app đến từ đâu? Có 4 cách chính để tăng impression cho app: feature, app ranking, keyword ranking và advertising. Trong khi đó Conversion được đánh giá bằng việc install với ASO. Có 2 điểm cần chú ý với conversion là CTR (click to rate) or TTR (tap to rate), đây là tỉ lệ user nhìn thấy được ứng dụng và click vào. Tỉ lệ thứ 2 cần quan tâm là conversion rate, sau khi click vào thì bao nhiêu % user quyết định install app.
Vậy tại sao 2 yếu tố này quan trọng trong việc đánh giá sự thành công của ASO?
Vì nếu tìm mọi cách để tăng impression bao gồm việc chạy ads, dùng các thủ thuật để tăng ranking cho keyword, cho app, trong khi đó chất lượng không thật sự tốt, traffic không cao vì users không thật sự mong muốn tải ứng dụng, sẽ dẫn đến việc dù đổ vào rất nhiều impression nhưng Conversion Rate thấp nên không có thêm được nhiều user.
Đó là lý do vì sao impression và conversion rate là 2 metrics phải luôn song hành với nhau. Làm tốt cả 2 yếu tố này chính là bạn đang làm tốt chiến lược ASO của mình.
Vậy những yếu tố nào ảnh hưởng đến Impression?
App feature: Đây có lẽ là mối quan tâm hàng đầu của rất nhiều dev, đó là mong app mình build được feature bởi các editor từ Apple hoặc Google Play. Khi feature sẽ có được rất nhiều lợi ích.
Thứ nhất, app sẽ được promote không tốn tiền trên app store, thậm chí là được nhìn thấy ở những vị trí đắt giá nhất app store. Nhờ thế sẽ có được impression miễn phí rất lớn. Tuy nhiên không phải lúc nào impression cũng mang lại kết quả tốt đẹp. Đôi khi đó không phải là user đang thật sự muốn tìm kiếm ứng dụng mà tải về. Có rất nhiều user tải app về chỉ vì tò mò, không có mục đích sử dụng nên không thể trở thành loyal user mà rất nhanh sẽ uninstall app.
Hoặc thậm chí impression đổ về rất nhiều nhưng lượng cài đặt lại không bao nhiêu. Do đó khi đánh giá bất cứ ASO nào cũng cần dựa trên 2 tiêu chí là impression và conversion.
App ranking: Vị trí ranking của app trên các category hay top charts càng cao thì càng được users tìm thấy dễ dàng hơn.
Keyword ranking: Đây được xem là yếu tố then chốt quyết định performance tốt nhất trong ASO. Vì keyword là những từ mà user có chủ đích tìm kiếm để tải app nên nếu app ở thứ hạng cao thì vừa được tìm thấy, vừa được tải bởi các user có quality tốt. Điều đó giúp cơ hội họ ở lại nhiều hơn và sử dụng app lâu hơn, trở thành 1 loyal user.
Ở Vulcan Labs, một keyword sẽ được xác định dựa trên 3 yếu tố: Thứ nhất là search volume xem keyword đó có nhiều người tìm hay không, có nhiều ứng dụng đang sử dụng keyword này hay không và keyword này có liên quan gì đến ứng dụng của mình hay không. Vì nếu không đảm bảo 3 yếu tố này mà sử dụng nó trong meta data như app name, subtitle,… sẽ dẫn đến hiện tượng có impression nhưng không có conversion. Keyword có search volume cao chưa chắc đã có sự liên quan đến app bạn đang build.
Theo báo cáo Share of Voice by Keyword Ranking của Apple, nếu keyword đạt rank số 1 thì có thể chiếm đến 60% share voice, vị trí thứ 2 khoảng 20%, vị trí thứ 3 và thứ 4 khoảng 10%. Nếu nằm ngoài top 5 thì đôi khi sẽ không có bất cứ % nào trong share of voice cho impression và organic install. Đây là kết quả với iOS store.
Còn đối với Google Play, theo mình được biết nếu nằm ngoài top 10 thì gần như không tìm được impression share nào cho keyword.
Advertising: Thông thường tiêu chí này không được nhắc đến nhiều trong ASO vì nhiều người quan niệm rằng làm ASO là miễn phí, là thứ mình tự làm nên không đặt advertising vào một trong những yếu tố ảnh hưởng đến ASO. Tuy nhiên đây lại là một tiêu chí quan trọng ảnh hưởng đến hoạt động ASO của bạn. Vì chạy ads sẽ mang về nhiều traffic hơn cho store. Khi có nhiều traffic hơn, nhiều install hơn thì dĩ nhiên cũng sẽ có được ranking tốt hơn trong kết quả tìm kiếm, nên vô hình chung nó còn giúp tăng organic install.
A/B testing cho ASO
A/B testing là gì?
Đó là phương thức đánh giá từ hai hoặc nhiều lựa chọn để so sánh xem lựa chọn nào sẽ mang lại kết quả tốt hơn. Khi áp dụng hình thức A/B testing cho ASO chính là đang test những giá trị khác nhau của các thành phần trên product page để tăng đồng thời 2 yếu tố lượt hiển thị và tỉ lệ chuyển đổi cho ứng dụng.
AB testing là phương thức đánh giá
A/B testing cho ASO với các ứng dụng trên Google Play Store
Google Play Store cung cấp phương thức testing miễn phí là Google Play Store Listing Experiment. Ở đây có thể test rất nhiều các thành phần như app name, icon, screenshot, description, có thể tùy biến testing một cách dễ dàng. Mỗi lần chỉ test 1 tiêu chí để nhận diện được trị nào đang ảnh hưởng đến conversion rate.
Bên cạnh đó, bạn nên tạo ra nhiều tổ hợp để test càng nhiều càng tốt, khi đó kết quả cũng được tối ưu nhất. Không có câu trả lời chính xác cho việc cần phải test bao lâu và mẫu số bao nhiêu cho từng loại ứng dụng. Nhưng nếu testing trong khoảng 1 tuần và thấy rằng sự khác biệt giữa 2 options không nhiều nghĩa là bạn đang cần một mẫu số lớn hơn.
A/B testing cho ASO với các ứng dụng trên iOS
Với iOS, hiện tại không có cách test miễn phí cho A/B testing. Mọi người có thể sử dụng dịch vụ A/B testing của Splitmetric cho iOS app. Dịch vụ này tạo ra những product pages giống hoàn toàn với pages mà chúng ta đang có trên Apple Store và dùng tiêu chí quyết định kết quả tốt nhất là conversion rate.
Cách thứ 2 là Apple Search Ads Creative Set Test: Để hiện hình thức này, khi submit version mới để test sẽ cần upload cả 2 version lên store. Sau đó, những creative cần test đã available, các bạn vào Apple Search Ads platform để tạo 1 campaign mới và set options mình mong muốn ở Asset Selection. Khi đó việc chạy quảng cáo sẽ được thay phiên giữa option default và option cần test. Chúng ta có thể xem report để xem option nào có nhiều impression và conversion rate hơn.
Có một lời khuyên ở Splitmetric mình cảm thấy khá hợp lí đó là các bạn sẽ phải làm gì nếu sự chênh lệch conversion rate giữa 2 options không quá cao? Theo Splitmetric, tất cả những chênh lệch nào dưới 1% thì không thể xem là thắng thế tuyệt đối của một option. Sự khác biệt conversion rate từ 1 – 2% rất dễ dẫn đến việc khi test trên một mẫu số nhỏ thì option đó thắng thế nhưng khi lên đến một mẫu số lớn, được apply cho all users thì gặp hiện tượng performance negative ngược lại, không mang lại sự tăng trưởng như mong muốn. Do đó kết quả testing nào cho sự khác biệt lớn hơn 2% sẽ đáng tin tưởng hơn.
Testing Flow
Để bắt đầu A/B testing thì bạn không thể nào bỏ qua bước đầu tiên là research – nghiên cứu. Thứ nhất nghiên cứu và đối thủ, thị trường và các hình thức chạy hiệu quả nhất đã có. Sau đó cần xem lại dữ liệu người dùng của ứng dụng để nghiên cứu hành vi người dùng trước đi đặt ra giả thuyết để tiến hành thiết kế lựa chọn cho A/B testing
Đối với dụng Camera translator, sau khi nghiên cứu thấy cần cải thiện ASO cho khu vực Nhật Bản, Vulcan Labs đã bắt đầu khảo sát ứng dụng ở Japan Store nằm ở top chart hoặc top category và tìm ra điểm khác biệt về thị hiếu của người dùng ở thị trường này. Người Nhật như có khuynh hướng tải các ứng dụng có screenshot có hơi thẩm mỹ cao hơn là chỉ thể hiện tính năng app một cách trực quan sinh động. Kết hợp với tìm hiểu trong dữ liệu về hành vi người dùng của ứng dụng Camera Translator ở Nhật, team nhận thấy sử dụng chính trong ứng dụng của Nhật thường được dịch sang tiếng Trung hoặc tiếng Hàn.
Với các lý do đó, Vulcan Labs đưa ra các giải pháp:
Thiết kế lại screenshot ở một layout khác, chỉ sử dụng một màu nền, hướng đến phương châm đơn giản vẫn là đẹp nhất.
Có các hình ảnh demo bằng tiếng Trung to hơn trong screenshot.
Mong muốn của team về kết quả test:
Layout sẽ đóng vai trò quan trọng như thế nào đối với screenshot ở thị trường Nhật Bản.
Dùng background nhiều màu hay một màu sẽ thu hút hơn.
Kết quả cuối cùng là version cải tiến dùng background thiết kế nghệ thuật hơn và có hình m hoạ tiếng Trung đạt kết quả tốt hơn khi tăng trưởng hơn 2.3% conversion rate và 22.5% organic install cho ứng dụng Camera translator tại thị trường Nhật Bản.
Đại dịch Covid-19 và những thách thức tác động đến ASO trong năm 2020
Báo cáo của Branch 2020 cho thấy có sự thay đổi trong hành vi của người tiêu dùng. Trước đây, việc tải ứng dụng đa phần đến từ việc user nhìn thấy quảng cáo và cảm thấy hứng thú nhiều hơn việc họ tự tìm kiếm một ứng dụng và chủ động tải.
Đến giai đoạn dịch Covid-19, việc tìm kiếm ứng dụng trở thành nhu cầu thiết yếu hơn. Đa số người dùng sẽ lên app store và chủ động tìm kiếm những ứng dụng phù hợp với nhu cầu của mình như để giải trí, cập nhật tin tức hoặc để giao tiếp với bên ngoài.
Vậy sự dịch chuyển này tác động như thế nào đến ASO?
Traffic đến từ việc users search keyword sẽ tác động đến keyword ranking nên khi keyword có traffic search volume rất lớn sẽ trở thành mục tiêu mà nhiều competitor hướng đến và trở thành một “trận chiến”.
Trước đây việc chạy ads có thể hỗ trợ một phần cho ASO thì hiện giờ vai trò của ads trong hỗ trợ tăng thêm impression trở nên nhỏ hơn. Vì vậy việc tối ưu hoá tất cả các yếu tố có trên product page để khiến người dùng tải app trở thành yếu tố quan trọng hơn nữa trong việc thực hiện thành công ASO. Lúc này, vai trò của ASO sẽ ngày càng nhiều hơn và đóng góp mạnh mẽ hơn cho sự thành công trong việc tìm kiếm users mới cũng như sự tăng trưởng cho ứng dụng.
Bài viết được trích dẫn từ phần trình bày của Ms Châu Lê tại sự kiện Vietnam Mobile Day 2020 LIVE do TopDev tổ chức
Sau một vài buổi trao đổi với các bạn làm quen với GIT mình tổng hợp một số quan điểm và những điều cần lưu ý khi dùng GIT mà các bạn này hay thắc mắc. Bài này chỉ thích hợp cho mấy bạn đã nắm qua git cơ bản rồi mà chưa có đụng chạm các vấn đề thực tiễn nhiều nhé!
Tôi đang chưa hiểu rõ sự khác biệt giữa git merge và git rebase là gì?
Tại sao tôi lại dùng git rebase mà không phải merge trong dự án này?
git rebase nó hay bị nhiều conflict hơn git merge?
git merge dễ tra log hơn git rebase đúng không vì rebase sửa log lại hết rồi 😐 ?
Lý do áp dụng rebase trong dự án là cho mọi thứ đều dễ dàng xem, điều tra log khi xem qua transport plan trong git. Chính vì thế việc áp dụng rebase cho từng brach riêng biệt là cách để cac developer có tư duy logic tốt log một cách có hệ thống những commit thực sự quan trọng và cần thiết để tra cứu sau này hạn chế commit spam ngoài ý muốn.
Việc conflict trong git là điều không thể tránh khỏi khi merge hay rebase branch khác mà làm chung trên 1 file mình chưa thấy dẫn chứng nào là rebase conflict nhiều hơn merge.
Trước khi commit mới thì mình phải pull code mới về, mà nếu gặp conflict thì phải xử lý, nếu xử lý ko khéo thì mất code của mình làm, vậy phải làm sao đây?
Nếu chỉ backup 1 lần cho 1 commit thì cực quá vì pull nhiều branch thì sao?
Mình đang làm branch hiện tại chưa muốn commit, mà phải qua branch khác fix bug dùm member vậy thì phải làm sao?
Nhìn chung mọi câu hỏi đều xoay quanh việc bạn muốn backup code mà chưa thể commit được! Có 1 câu thần chú mà mình hay dùng đó là git stash nó cho phép bạn backup mọi lúc, không giới hạn số lần backtup và bạn dễ dàng tra cứu lại những gì bạn backup nữa.
Bài viết được sự cho phép của tác giả Nguyễn Việt Hưng
Khi trở thành một trong những ngôn ngữ lập trình phổ biến nhất thế giới, Python không chỉ được dùng trong làm web, data science, hay sysadmin tool mà nó còn đá sang cả một lĩnh vực vốn giới hạn về tài nguyên: nhúng.
Bình thường khi bật Python lên để in ra màn hình dòng “hello, world” ta đã dùng tới 8MB bộ nhớ. Vậy nên việc dùng Python cho lập trình nhúng thường nghe có vẻ không phù hợp.
MicroPython ra đời, là một bản thu gọn của Python, tối ưu chạy trên các vi xử lý cũng như các môi trường giới hạn về tài nguyên. Bài này khám phá việc chạy MicroPython trên một thiết bị tí hon có tên WEMOS D1 mini.
WEMOS D1 mini
Là 1 bảng mạch điện có khả năng thu phát sóng wifi (wifi board) có kích thước nhỏ hơn ngón chân cái của người lớn, thiết bị này có giá 2 USD.
Bảng mạch này sử dụng vi điều khiển (microcontroller) ESP-8266, với xung nhịp 80MHz/160MHz, 96KB RAM và 4 MB Flash.
Microcontroller
A microcontroller is a small computer on a single integrated circuit. In modern terminology, it is similar to, but less sophisticated than, a system on a chip or SoC; an SoC may include a microcontroller as one of its components. A microcontroller contains one or more CPUs along with memory and programmable input/output peripherals.
Một vi điều khiển là một máy tính nhỏ, trên một mạch điện tử (P/S: SoC là khái niệm tương tự, nhưng phức tạp hơn). Nó có một hoặc nhiều CPU, memory và chỗ để thực hiện vào ra dữ liệu.
Hãy nhìn vào chiếc máy bàn hay laptop bạn đang dùng, nó có 1 cục CPU to bằng lòng bàn tay, vài thanh RAM dài như bàn tay, các cổng vào ra đều to bằng ngón tay. Mỗi cục CPU đều từ 2-3 GHz (so với 80MHz), ổ cứng vài trăm GB (so với 4MB), 1-16 GB RAM (so với 96KB RAM). Ta sẽ thấy microcontroller nhỏ bé và “yếu ớt” đến chừng nào.
MicroPython
Phiên bản Python dành riêng cho các thiết bị tí hon này nhỏ tới mức chỉ cần 256kB không gian chứa code, và 16kB RAM.
Cài đặt MicroPython lên WEMOS D1 Mini trên Ubuntu 16.04
(Windows hay OSX cần cài driver, hãy lên trang chủ của WEMOS để tải và xem hướng dẫn).
Cắm thiết bị vào máy tính sử dụng dây micro USB (dây sạc điện thoại android), sẽ thấy nháy đèn trên thiết bị, gõ lệnh dmesg để xem Linux kernel báo nhận thiết bị:
$ dmesg
...
[992.253009] usb 2-1: new full-speed USB device number 5 using xhci_hcd
[992.402181] usb 2-1: New USB device found, idVendor=1a86, idProduct=7523[992.402185] usb 2-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0[992.402187] usb 2-1: Product: USB2.0-Serial
[992.402757] ch341 2-1:1.0: ch341-uart converter detected
[992.403119] usb 2-1: ch341-uart converter now attached to ttyUSB0
$ file /dev/ttyUSB0
/dev/ttyUSB0: character special (188/0)
Ta có thấy xuất hiện 1 file mới gọi là /dev/ttyUSB0, đây chính là thiết bị vừa kết nối.
$ sudo /home/hvn/py36/bin/esptool.py --port /dev/ttyUSB0 --baud 460800 write_flash --flash_size=detect -fm dio 0 ~/esp8266-20180511-v1.9.4.bin
esptool.py v2.5.1
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: b4:e6:2d:3b:22:1b
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0240
Compressed 604872 bytes to 394893...
Wrote 604872 bytes (394893 compressed) at 0x00000000 in 9.0 seconds (effective 536.4 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
Sau khi cài đặt xong, bấm nút “reset” trên thiết bị để khởi động lại, ngay sau đó bật WIFI của laptop hay điện thoại lên ta sẽ thấy một mạng WIFI có tên MicroPython-xxxxxx, có thể kết nối vào WIFI này với password micropythoN. Ở đây ta không cần làm việc này. Tiếp tục cài đặt để kết nối với thiết bị qua cổng COM:
Cài picocom:
$ sudo apt install -y picocom
$ sudo picocom /dev/ttyUSB0 --baud 115200
picocom v1.7
port is : /dev/ttyUSB0
flowcontrol : none
baudrate is : 115200
parity is : none
databits are : 8
escape is : C-a
localecho is : no
noinit is : no
noreset is : no
nolock is : no
send_cmd is : sz -vv
receive_cmd is : rz -vv
imap is :
omap is :
emap is : crcrlf,delbs,
Terminal ready
>>> 2**1000
10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069376
Sau khi kết nối, ta lập tức sử dụng Python interpreter như bình thường.
Python interpreter đóng vai trò như 1 hệ điều hành ở đây, mỗi lần reset thiết bị, nó sẽ lại bật lại Python interpreter. Mọi tương tác với thiết bị (đọc/ghi file) đều thực hiện qua code python.
Hai file này được chạy mỗi lần thiết bị khởi động.
Xem nội dung file boot.py:
>>>f=open('boot.py')>>>print(f.read())# This file is executed on every boot (including wake-boot from deepsleep)#import esp#esp.osdebug(None)importgc#import webrepl#webrepl.start()gc.collect()
File main.py chứa code của người dùng muốn chạy mỗi lần bật thiết bị. Ví dụ ta muốn hiển thị dòng hello PyMi:
...
ets_task(40100130, 3, 3fff83ec, 4)
Hello Pymi.vn
MicroPython v1.9.4-8-ga9a3caad0 on 2018-05-11; ESP module with ESP8266
Type "help()" for more information.
>>>
Baud /ˈbɔːd/ ở câu lệnh trên là một độ đo “symbol rate” (symbol per second), để quyết định tốc độ giao tiếp qua một kênh thông tin.
Kết luận
Với MicroPython trên thiết bị, ta đã có thể thực hiện điều khiển các chân Pin hay gửi HTTP request như code Python bình thường. Giờ thì giới hạn chỉ còn là trí tưởng tượng của bạn.
Bài viết được sự cho phép của tác giả Lê Xuân Quỳnh
Có thể bạn đã sử dụng nhiều library trong dự án IOS của mình. Vậy thường thì bạn có tạo lớp để quản lý cho dễ không? Thực tế mình cũng ít khi làm việc này, chỉ trừ mấy thư viện lớn như request server thôi. Hôm nay chúng ta sẽ học được 1 cách quản lý thư viện mà theo mình đánh giá là ổn, khá logic, clear và đáng học hỏi. Nào cũng ta cùng bắt đầu nhé!
Phần Readme đã mô tả rất rõ cách cài đặt, các bạn đọc và tạo thử 1 project để cài nhé. Mình nghĩ dùng pod để cài là đơn giản nhất.
Chức năng:
Cung cấp event tracking model tốt hơn
Dữ liệu thống kê realtime – thống kê của GA thường mất hàng giờ
Với GA bạn phải tạo ra các funnel trước khi thu thập dữ liệu, còn với Mixpanel bạn có thể xây dựng funnel bất cứ lúc nào.
retention analytics – Cho phép đo lường lượng người dùng mới, sử dụng lại app. Nó cũng cho phép bạn xác định tần suất người dùng sử dụng app, GA không có tính năng này.
Customer support: GA không cung cấp hỗ trợ người dùng chất lượng cao nếu bạn gặp lỗi và không hiểu báo cáo.
Cải thiện độ chính xác dữ liệu
Mobile A/B testing: Mixpanel cung cấp mobile a/b testing, dễ dàng cho người phát triển hoặc không biết kỹ thuật. GA không có chức năng này.
Dữ liệu của bạn được private. Không như GA, Mixpanel không bao giờ sử dụng dữ liệu của bạn cho mục đích quảng cáo.
Scripting: Tự động hóa/tương tác với Excel từ môi trường Python, sử dụng cú pháp gần với VBA mà vẫn “Pythonic”.
Macros: Viết các script python thay thế cho VBA macros, giúp code dễ đọc hơn. Sau khi viết script python xong, chỉ cần gọi 1 hàm trong VBA là script chạy.
UDFs: Viết hàm người dùng tự định nghĩa bằng ngôn ngữ Python và sử dụng được hàm đó trong excel (Windows only).
REST API: cung cấp REST API cho Excel workbook.
Cài đặt:
pipinstallxlwings
Sử dụng:
Một số thao tác cơ bản:
importxlwingsasxw# mở workbook mớinew_wb=xw.Book()# hoặcopening_wb=xw.Book('name_of_opening_workbook')# hoặcopen_new_workbook=xw.Book('full/relaive_path_to_xls')# Lấy các sheets có trong file excel xw.sheets# Làm việc với dữ liệu trong 1 sheetsht=xw.sheets[0]print(sht.range('A1').value)sht.range('A1').value='xxx'# tự động tìm bảng# https://docs.xlwings.org/en/stable/datastructures.html#range-expandingsht.range('A1').expand()# ...
Xử lý trường hợp cụ thể: Trong video này, xlwings được dùng để tự động tạo các named range cho hàng loạt file có cấu trúc tương tự. Mục đích là để làm bước tiếp theo: link giá trị từ nhiều file vào 1 file tổng hợp, dựa vào named range trong từng file chi tiết. Tham khảo script.
Trong script này còn sử dụng Excel VBA API: WorkBook.Names.Add (tra cứu toàn bộ ở đây, được cung cấp qua xw_object.api). Tức là những gì không được cung cấp sẵn cú pháp Pythonic, ta sẽ sử dụng VBA API.
Hạn chế: range expand chỉ ứng dụng được cho vùng dữ liệu liên tục. Với “bảng” có các dòng/cột trống (để “format” cho đẹp) thì sẽ bị ngắt tại chỗ có dòng/cột trống. Vì vậy, thường sẽ phải chọn 1 range khá lớn/1 magic number để lấy được toàn bộ vùng dữ liệu cần xử lý.
Mọi việc phải xử lý trong video demo sẽ đơn giản hơn nếu có 1 file excel mẫu ban đầu, được định nghĩa sẵn các named range, sau đó mới duplicate ra để điền dữ liệu vào. Tuy nhiên, thực tế không như thế, ta phải xử lý lỗi một cách nhanh nhất, cũng giống như khi tập chép phạt: "Anh xin lỗi\n" * 100
Trên thanh Menu bên trái chọn Manage Jenkins > Global Tool Configuration
Cuộn màn hình xuống dưới sẽ thấy phần Add JDK, Click vào nút Add JDK
Cách 1: Cấu hình JDK cho Jenkins bằng cách download từ trang của oracle
Chọn vào ô check box Install automatically
Với cách này, Jenkins sẽ tự động download bản JDK trên trang oracle về máy và cài đặt. Tất cả sẽ thực hiện tự động, bạn không cần phải cấu hình gì cả.
Tuy nhiên với cách này bạn cần phải có 1 tài khoản oracle, và thêm account oracle đó vào jenkins
Thêm tài khoản oracle vào Jenkins
Chọn version JDK muốn cài đặt (ở đây mình dùng JDK 1.8). Đặt tên cho bản JDK (nên đặt giống tên version JDK để dễ nhớ)
Tick vào ô I agree to the Java SE Development Kit License Agreement
Click nút Save, hệ thống sẽ tự động download Java về máy (Quá trình này chạy ngầm, nên sau khi add JDK bạn có thể chưa build được project Java do nó chưa cài đặt xong)
Cách 2: Cài đặt JDK cho Jenkins bằng Java ở local
Với cách này, yêu cầu máy bạn đã cài đặt Java và cấu hình JAVA_HOME
Để kiểm tra biến JAVA_HOME, mở cửa sổ terminal (Ctrl + Alt + T) và gõ echo $JAVA_HOME
Ví dụ, máy mình đang cài Java ở folder /opt/java/jdk1.8.0_261
Cấu hình JDK cho Jenkins bằng Java trên local bằng cách bỏ chọn ô checkbox Install automatically
Trường JAVA_HOME nhập và đường dẫn JAVA_HOME mà bạn cấu hình trên máy.
Nhập tên cho bản JDK và click Save
Với cách này, Jenkins không cần cài đặt gì cả nên sau khi save bạn có thể build, chạy các project Java được luôn.
TinyURL là hệ thống rút gọn link được sử dụng phổ biến trên toàn thế giới. Link dài, link rắc rối, link không muốn người khác nhìn vào là biết?. Tất cả đều được xử lí với TinyURL
Một hệ thống như vậy thông thường sẽ xử lí một lượng lớn request phân giải Short URL thành Original URL. Việc phân giải đòi hỏi chính xác, nhanh chóng.
Hôm sau Kieblog sẽ giới thiệu chuỗi bài viết thiết kế hệ thống như TinyURL, bao gồm 2 phần.
Phần 1: Tổng quan hệ thống, đưa ra giải pháp thiết kế
Phần 2: Thiết kế chi tiết, giải quyết các vấn đề thực tế
Bắt đầu ngay thôi nào!
1. Về TinyURL System
Bản thân Tiny URL là hệ thống rút gọn link. Trường hợp link quá dài, loằng ngoằng không hồi kết, để rút gọn link cho dễ thao tác và sử dụng ta có thể sử dụng Tiny URL.
Về mặt bản chất, Tiny URL thực chất là hệ thống implementing a distributed key-value store. Hiện thực hệ thống phân tán, lưu trữ theo cơ chế key-value.
Key ở đây được hiểu là short url đã rút gọn. Value là original url trước khi rút gọn.
Thông qua function makeTinyURL, ta có thể lấy được URL lưu trữ trong hệ cơ sở dữ liệu phân tán (Distributed System).
Key -> Value
The user can now share tinyurl.com/ksfskfh. Whenever someone visits that URL, our system will look up the Distributed Database and redirect them to the actual URL.
Về cơ bản, sau khi đã rút gọn, user có thể chia sẻ short URL. Bất cứ ai khi đi tới short URL, hệ thống sẽ tìm kiếm trong Hệ cơ sở dữ liệu phân tán và chuyển hướng người dùng tới URL chính xác.
2. Bắt tay vào thiết kế hệ thống
Do việc lấy original URL được thực hiện ở phía Server, tất nhiên ta sẽ cần một App Server để xử lý. Về phía Database, ta sẽ sử dụng Sharing Distributed, do lượng người sử dụng và số lượng URL shorted rất lớn.
Trung bình có thể tới vài triệu URL được rút gọn trong vòng một ngày. Việc lưu trữ ở phía DB đòi hỏi áp dụng thiết kế Sharding, lưu trữ phân tán.
Chi tiết thêm về Dynamic Sharding anh em có thể tham khảo thêm ở bài viết này
Chi tiết hệ thống có thể được thiết kế như hình vẽ sau đây
Load Balancer giúp cân bằng tải, handle một lượng lớn request extract URL hàng ngày. Lượng request yêu cầu extract URL có thể lên tới hàng trăm ngàn request mỗi giây
App Server thực hiện Original URL (URL gốc) từ Database thông qua tìm kiếm key-value ở Database.
Distributed Database là hệ thống cơ sở dữ liệu phân tán, scale theo chiều ngang giúp mở rộng hệ thống, đáp ứng perfomance khi lượng request lớn.
3. Bài toán mà hệ thống cần giải quyết
Đi sâu hơn vào chi tiết, hệ thống như Tiny URL đặt ra nhiều câu hỏi cho người thiết kế hệ thống.
Cụ thể, bản thân người kĩ sử sẽ cần xem xét
1. What method do we use to generate the shortened URL?
Method nào sẽ sử dụng để tạo các URL ngắn. Chuỗi phía sau URL sẽ được tạo ra như thế nào để đảm bảo tính duy nhất (unique). Dễ dàng cho việc tìm kiếm?.
2. How long should the shortened URL be?
URL được làm ngắn sẽ trông như thế nào?. Tất nhiên, đã là rút gọn link thì sau khi rút gọn phải ngắn hơn, chứ mà sau khi rút gọn còn dài hơn cả trước khi rút gọn thì hệ thống FAIL. LOL
3. What happens if the same URL is shortened twice? Do we re-use the old TinyURL or create a new one?
Trường hợp URL đã được rút ngắn, chuyện gì xảy ra khi rút thêm lần nữa?. Ngắn hơn?. Có nên sử dụng cái TinyURL đã thiết kế, hay tạo ra cái mới?.
Tất cả các câu hỏi này cần bản thân người kĩ sư tìm ra câu trả lời. Một phán đoán sai hay giải pháp không tốt có thể ảnh hưởng tới toàn bộ hệ thống. Chính vì vậy, các vấn đề kĩ thuật cần được giải quyết triệt để.
Bài viết được sự cho phép của tác giả Lê Xuân Quỳnh
Dựa theo tác giả: Marin Todorov.
Loạt bài đăng này giới thiệu cho bạn cách viết ứng dụng IOS sử dụng Reactive bằng ngôn ngữ Swift. Vậy chính xác RxSwift = Reactive + swift là gì?
Nó là thư viện để xử lý các sự kiện không đồng bộ (theo thời gian thực) nhờ việc tạo ra các observable quan sát và các toán tử (operators) chức năng xử lý tham số hóa nhờ schedulers – lập lịch.
Nói nôm na, ví dụ người yêu bạn thấy trời nắng thì liền dùng ô, thấy mưa thì chạy vào nhà. Sự kiện mưa nắng là ngẫu nhiên, nhưng việc xử lý chính xác dùng ô hay chạy vào nhà gọi là schedulers. Các observable chính xác là mắt nhìn của người yêu bạn. Trong lập trình reactive nó cũng tương tự như vậy.
Đọc cũng phức tạp, vì nó còn mới. Nhưng chúng ta hãy đi từ từ từng khái niệm một nhé.
Mục tiêu của loạt bài chủ đề này: Học cách sử dụng các hàm của RxSwift – hay còn gọi là APIs của nó, và áp dụng được nó vào ứng dụng IOS của bạn. Chúng ta sẽ học những API cơ bản, và sau đó nâng dần lên trung cấp và nâng cao. Hãy giành thời gian thực hành theo các ví dụ và vì Reactive là 1 khái niệm rất rộng cho nên khó có thể viết hết về nó được. Nhưng chúng tôi hi vọng qua loạt bài này sẽ cung cấp cho các bạn các kiến thức căn bản đủ để bạn tiếp tục theo đuổi nó và nâng dần trình độ của mình lên. Chúng ta sẽ không lo nó lỗi thời, vì hiện tại Apple đã cung cấp Combine, 1 framework chính chủ cũng áp dụng y hệt cách hoạt động của RxSwift, chúng ta có thể dễ dàng di chuyển qua nó. Thông qua Rx, chúng ta có thể đọc code bằng các ngôn ngữ khác viết cho android hay web.
Tuy nhiên chúng ta vẫn chưa biết Rx là gì phải không? Vậy hãy bắt đầu bằng 1 định nghĩa đơn giản dễ hiểu sau:
Về bản chất, RxSwift đơn giản hóa việc phát triển các chương trình không đồng bộ bằng việc cho phép ứng dụng của bạn phản ứng các thay đổi của dữ liệu mới theo cách riêng biệt, tuần tự.
Là một nhà phát triển ứng dụng IOS, điều này là dễ hiểu hơn nhiều so với khái niệm ở trên, ngay cả khi mơ hồ thì bạn cũng hiểu là Rx giúp bạn viết mã cho các chương trình bất đồng bộ. Và mọi việc hỗ trợ cho việc viết code bất đồng bộ dễ hiểu, trong sáng(clean) đều được hoan nghênh. Vì vậy chúng ta còn chần chừ gì mà không đọc tiếp bài 2 ở đây.
Bài viết được sự cho phép của tác giả Nguyễn Việt Hưng
Đơn giản, nhanh, chậm, xinh, cao, thấp, giỏi, xịn… đều là những khái niệm mang tính chất tương đối. Có cái hơn khi so sánh ở góc độ này, nhưng lại kém khi so sánh ở góc độ khác. Trong ngành lập trình, mọi thứ đều là sự đánh đổi (trade off), không có giải pháp nào thỏa mãn tất cả mọi nhu cầu (silver bullet) – hoặc có nhưng chưa ai tìm ra.
Không cần bàn cãi, ai cũng đồng ý code Python dễ đọc, viết hơn C, hay… đơn giản hơn. Nhưng cái đơn giản đó, là đơn giản với con người, với lập trình viên, còn với máy tính thì hoàn toàn ngược lại.
Ta sẽ thử nghiệm chương trình đơn giản nhất trái đất: hello world viết bằng C và Python rồi so sánh dùng strace – một công cụ debug “cao cấp” thường dùng bởi các SysAdmin.
strace
$ whatis strace
strace (1) - trace system calls and signals
Bài viết thực hiện trên Ubuntu 18.04, cc – C compiler có lẽ là có sẵn. Hoặc nếu không có, hãy cài bằng sudo apt-get install -y build-essential strace
Compile rồi chạy – yeah, cực đơn giản, không cần gì khác cả, cũng không cần làm việc đơn giản này trở thành rắc rôi.
$ cc hello.c -o hello # compile, sinh ra file hello
$ ./hello # chạy file hello
Hello world!
Giờ chạy với strace để xem chương trình siêu đơn giản này gọi những system call nào, -C sẽ hiển thị bảng thống kê, -S calls sẽ sắp xếp thống kê này theo cột calls, giảm dần.
Chương trình Python đơn giản này thực hiện tới 703 syscall, 52 fail.
Kết luận
27 với 703 thì cái nào “hơn”?
27 nhỏ hơn 703, còn 703 thì lớn hơn 27. Lập trình C cũng rất đơn giản, đúng không!
Vậy nên khi lập trình, luôn nhớ rằng mọi thứ đều là tương đôi, đều phải đánh đổi. Mấy em gái đã xinh mà code Python lại giỏi, chỉ có 2 khả năng xảy ra:
Bài viết được sự cho phép của tác giả Trần Hữu Cương
Các ưu nhược điểm của Swift so với Objective C
1. Swift và Objective C
Swift và Objective-C là hai ngôn ngữ trong lập trình iOS.
Objective-C ra đời trước Swift và đã có lịch sử phát triển với rất nhiều ứng dụng.
Về sau Swift được phát triển để thay thế Objective-C. Swift cũng đi kèm với công cụ lập trình trực quan. Do đó, làm tới đâu thấy tới đó luôn, sẽ giúp ích nhiều cho các lập trình viên, đỡ tốn công debug.
Tuy nhiên Swift vẫn chưa thể thay thế ngay được Objective C.
Nếu bạn đã lập trình với cả C và Python thì bạn sẽ thấy Objective C giống C còn Swift giống Python. Swift lược bỏ đi khá nhiều những cú pháp phức tạp và rắc rối.
Swift dễ đọc và dễ học hơn so với Objective-C (cú pháp hoàn toàn mới, ngắn gọn hơn rất nhiều)
Các file trong Swift thống nhất neenvieecj bảo trì code đơn giản hơn.
Compiler của Swift tốt hơn Objective C
Swift không sử dụng con trỏ giúp cho code an toàn hơn, và giúp lập trình viên lược bỏ phần khái niệm khó nhằn về con trỏ.
Swift quản lý bộ nhớ tốt hơn
Swift là mã nguồn mở: Lập trình viên có thể xem được mã nguồn, chỉnh sửa, vá lỗi.
3. Nhược điểm của Swift so với Objective C
Nhiều API không làm việc với Swift
Nhiều qui tắc khi khởi tạo, lựa chọn kiểu optional
Một lượng lớn các project, phần mềm trước đó đều viết bằng Objective C do đó Objective C.
Tóm tại, tuy tồn tại một số nhược điểm nhưng Swift vượt trội hoàn toàn so với Objective C. Trường hợp các dự án cũ, nhỏ thì bạn hoàn toàn có thể kết hợp cả 2 ngôn ngữ này.
Nhắc tới thiết kế hệ thống (System Design), ngoài thiết kế hệ thống tốt, đáp ứng khả năng Scale, chuẩn business, ta cũng cần cân nhắc thêm về tính bảo mật của hệ thống (Security Considerations)
Qua bài viết dưới đây, Kieblog mong muốn chia sẻ thêm chút ít kinh nghiệm thực tế khi thiết kế hệ thống Web. Một số vấn đề về Security cần quan tâm.
Bắt đầu ngay thôi nào!
1. Access and Authentication
Access và Authentication là 2 phần không thể bỏ qua khi nói về Security Considerations cho Designing Web Applications. Hầu hết các cuộc tấn công Web hiện nay, nguyên nhân chủ yếu không phải là các cuộc tấn công lớn hoặc sử dụng công nghệ cao. Nguyên nhân chính là do hệ thống bảo mật yếu kém. Trong đó nổi bật nhất là Authentication.
Các vụ tấn công lớn đã được biết tới của Target Corp hay Yahoo đều xuất phát từ email. Đối tượng tấn công vào một node trong chuỗi cung ứng. Dẫn tới mật khẩu quản trị bị đánh cắp dẫn tới mất thông tin.
Việc bổ sung bước thứ hai giúp giảm thiếu rủi ro bị đánh cắp dữ liệu, giao các quyền truy cập thông tin không được phép vào tay hacker.
Trước tới nay, nhắc tới API, ta có thể nghĩ tới tới ngay SOAP Web Services. Tuy nhiên với GraphQL, có nhiều cách để take care hoặc đảm bảo API Access Secutiry.
2. SSL – Http và Https
Về SSL, HTTPS và HTTP hẳn anh em cũng đã có hiểu biết nhiều. Hiện tại, Https đã là yếu tố bắt buộc của hầu hết các Website.
Nhắc lại một chút về định nghĩa.
SSL stands for Secure Sockets Layer and, in short, it’s the standard technology for keeping an internet connection secure and safeguarding any sensitive data that is being sent between two systems, preventing criminals from reading and modifying any information transferred, including potential personal details.
SSL là Secure Socket Layer, nó là công nghệ tiêu chuẩn để giữ an toàn cho các kết nối, bảo về dữ liệu an toàn khi được gửi đia giữa hai hệ thống, ngăn tội phạm đọc trộm hoặc chỉnh sửa bất kì thông tin nào khi đã được gửi đi, bao gồm thông tin chi tiết.
HTTPS (SSL or Secure Sockets Layer). Anh em nào chưa biết có thể tham khảo thêm ở đây
3. SQL Injection
Khi nói về Secutiry cho hệ thống Web (Security Considerations), không thể không nhắc tới SQL Injection. Đây là cách tấn công phổ biến và để lại hậu quả tại hại. Về cơ bản:
SQL injection is a code injection technique that might destroy your database. Is one of the most common web hacking techniques. Is the placement of malicious code in SQL statements, via web page input.
SQL Injection là kiểu tấn công phá hủy hệ cơ sở dữ liệu bằng cách thực hiện command ngay trên chính DB hệ thống, là kiểu tấn công cơ bản và được sử dụng nhiều. Thông qua input và Web, thực hiện các câu lệnh SQL nhằm ăn cắp hoặc phá hủy thông tin.
Về phương án xử lý hoặc phòng ngừa với SQL Injection cũng khá đơn giản. Hầu hết các ORM Framework hiện nay (Hibernate, JPA, MyBatis) đều đã hỗ trợ để ngăn chặn cuộc tấn công bằng SQL Injection
Java EE – use PreparedStatement() with bind variables
.NET – use parameterized queries like SqlCommand() or OleDbCommand() with bind variables
PHP – use PDO with strongly typed parameterized queries (using bindParam())
Hibernate – use createQuery() with bind variables (called named parameters in Hibernate)
Gần giống như SQL Injection, Command Inject cũng tìm cách thực hiện hoặc run được command ở phía services của web.
Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application
Mục tiêu của tấn công Comman injection là thực hiện tùy ý các lệnh trên hệ điều hành thông qua một ứng dụng dễ bị tấn công.
Trên góc nhìn cá nhân, cả SQL Injection và Command Injection đều nguy hiểm. Tuy nhiên Command Injection mang tới hậu quả khủng khiếp hơn, nếu một Server hoặc Services bị down, dù chỉ 5,10 phút cũng có thể gây ảnh hưởng rất lớn tới cá nhân, doanh nghiệp.
Về giải pháp thì có thể cân nhắc trong quá trình phát triển web:
Do not allow any user input to commands your application is executing – Không cho phép bất cứ input nào từ user command trên applicaton được thực thi.
Only use secure APIs for executing commands, such as execFile() – Chỉ sử dụng API đã secure để thực thi commands, như execFile().
When using execFile(), make sure the user has no control over the program name – Khi sử dụng execFile(), đảm bảo rằng user không kiểm soát tên chương trình.
Top 10 command injection attacks. Nguồn ảnh/Source: snyk.io
Input check cũng là một yếu tố cần quan tâm khi nhắc tới Security Considerations. Input checks cũng gần giống với Access. Tuy nhiên input ở phía người dùng có vô vàn biến thể khác nhau (theo cách khó ngờ nhất).
Make sure to validate input fields on both the server and client side
Phải chắc chắn rằng ta luôn validate input field ở cả 2 phía server và client
Input field cũng có thể sử dụng blacklisting, chỉ cho phép những field whitelist validate, còn lại ignore tất cả.
