Bài viết mới nhất


Chào các bạn!

Khi bắt đầu với lập trình Android, chúng ta đều được học rằng KHÔNG THỂ truyền tham chiếu của một đối tượng (object references) tới các Activity hoặc fragment. Để đối mặt với vấn đề khó khăn này chúng ta phải "gói" chúng vào một Intent/Bundle.

Truyền những tham số có kiểu nguyên thủy (primitive data types) như là string, integer, float,... qua Intents thì khá dễ dàng trong Android. Tất cả những gì bạn cần làm là "put" dữ liệu với một key duy nhất làm từ khóa vào Intent và gửi nó đến một Activity bất kỳ.

Nhìn vào API, ta nhận ra rằng có hai cách để truyền Java object qua Intent: một là implements Java class đó từ Percelable interface, hai là implements từ Serializable interface. Là một lập trình viên Java/C# chúng ta chắc hẳn đã biết rõ cơ chế hoạt động của Serializable, vậy tại sao ta lại phải bận tâm với Parcelable?

Để trả lời câu hỏi đó, hay tiếp cận rõ hơn để xem tại sao như vậy nhé!




SERIALIZABLE - BẬC THẦY CỦA SỰ ĐƠN GIẢN

Serializable là một interface chuẩn của Java. Vẻ đẹp của Serializable là việc bạn đơn giản chỉ cần đánh dấu một class Serializable bằng cách implements interface đó lên nó và các class con của nó, sau đó máy ảo Java (Java Virtual Machine) sẽ tự động serialize class theo từng trường hợp khác nhau. Đây là một marker interface, nghĩa là không cần phải cài đặt lại bất cứ method nào của khi implements.


Vấn đề xảy ra với hướng tiếp cận này là Java Reflection được sử dụng, và nó làm tiến trình của phần mềm bị chậm đi. Cơ chế này thường hay tạo rất nhiều đối tượng tạm (temporary object) và khi đó cơ chế dọn rác Garbage Collection của Java sẽ hoạt động và tốn tài nguyên máy tính.


PARCELABLE - ÔNG VUA TỐC ĐỘ

Parcelable là một interface riêng của Android, nơi mà bạn phải tự cài đặt các hàm serialization một cách thủ công mà không được sự hỗ trợ từ JVM. Parcelable được tạo ra cải tiến từ Serializable, nó hiệu quả hơn và khắc phục được một số vấn đề tồn tại ở Java Serializable, đó là lý do tại sao đa phần lập trình viên Android ưu tiên sử dụng Parcelable hơn là Serializable.


Theo những gì mình đọc trên StackOverflow, hay theo các google engineers thì đoạn code trên sẽ chắc chắn thực thi nhanh hơn. Một trong các lý do đó là chúng ta đã cài đặt tường minh các hàm thể hiện quá trình serialization thay vì sử dụng Java Reflection. Khi tối ưu hóa như vậy thì cơ chế dọn rác GC của Java sẽ làm việc ít hơn làm chương trình "nhanh" hơn.

Tuy nhiên, rõ ràng cái gì cũng có cái giá của nó. Với hướng tiếp cận này chúng ta sẽ sinh ra một "đống" code khá phức tạp và làm cho những class này rất khó đọc và fix bug, bảo trì.


KẾT QUẢ KIỂM TRA TỐC ĐỘ

Dĩ nhiên, chúng ta đều muốn biết Parcelable nhanh hơn tới mức nào!

Phương pháp:
- Mô phỏng quá trình truyền object vào activity
- Chạy quá trình đó trong vòng lặp 1000 lần
- Chạy trung bình 10 lần khác nhau để tính dung lượng bộ nhớ, cpu chiếm dụng,..
- Các object được test là HCMUSDeveloper IceTeaVietDeveloper ở trên.
- Test trong nhiều thiết bị android (LG Nexus 4 - Android 4.2.2, Samsung Nexus 10 - Android 4.2.2, HTC Desire Z - Android 2.3.3)

Kết quả:

Thời gian thực thi của bộ test (hình ảnh và dữ liệu theo developerphil.com)

Nexus 10
Serializable: 1.0004ms, Parcelable: 0.0850ms - 10.16x improvement.


Nexus 4
Serializable: 1.8539ms - Parcelable: 0.1824ms - 11.80x improvement.


Desire Z
Serializable: 5.1224ms - Parcelable: 0.2938ms - 17.36x improvement.



TỔNG KẾT

Trong ví dụ trên, Android Parcelable tỏ ra nhanh hơn nhiều so với kỹ thuật Java Serializable. Một trong những lý do chính là do Parcelable hoàn toàn tùy chỉnh code, cho phép lập trình viên convert dữ liệu cần thiết thành Parcel trong khi Serialazation convert đối tượng thành một data stream sử dụng Java Reflection API.

Nếu bạn muốn trở thành một lập trình viên giỏi, hãy bỏ thời gian để cài đặt Parcelable bởi vì nó có thể thực thi nhanh hơn từ 4 - 10 lần và sử dụng ít tài nguyên hơn, khiến GC hoạt động ít hơn.

Tuy nhiên trong nhiều trường hợp, sự "chậm chạp" của Serializable không đáng nhắc tới. Hãy thoải mái sử dụng nó đối với những class nhỏ, nhưng hãy nhớ là nó luôn "ngốn tài nguyên" nên hãy giảm thiểu đến mức đáng kể khi cần những đoạn code đẹp - dễ đọc và bảo trì. Còn nếu bạn đang muốn truyền một List với hàng nghìn object, thì sự "chậm chạp" đó sẽ lên tới con số nhiều giây. Và khi đó chuyển động giao diện cũng như hiệu năng của ứng dụng sẽ trở nên khá tồi tệ và đó cũng là lúc bạn cần dùng đến vị cứu tinh dành riêng cho lập trình viên Android - Parcelable.

________________________________________________________________________

Trên là những chia sẻ của mình về hai hướng tiếp cận cho việc truyền object ref. Cảm ơn các bạn đã theo dõi, chúc các bạn học tốt và hãy để lại bình luận bên dưới nhé! 
Bonus cho các bạn 1 tấm hình từ slide của anh Huynh Q. Thao về những tip trong Android Perfomance, đó cũng là lý do và động lực để mình viết bài này :D



Bất cứ nơi đâu chúng ta đến, ta đều bị vây quanh bởi những thiết kế tồi tệ - từ chỗ ngồi của máy bay làm biến dạng tư thế ngồi của chúng ta đến một chiếc xe máy với thiết kế khiếm nhã. Những cảnh quan đã từng là màu xanh của sự sống và bây giờ một màu xám xịt đang dần phủ lên. Môi trường xung quanh của chúng ta chứa đầy những cơ hội bị bỏ lỡ để đem đến sự hài lòng, phấn khích và niềm vui cho cuộc sống con người!

Chỗ ngồi máy bay làm biến dạng tư thế ngồi

Những đồ vật với thiết kế tồi tệ làm chúng ta chậm lại, và làm phiền lòng mọi người - giống như tòa nhà xấu xí của ông hàng xóm làm bạn nhăn nhó mỗi khi nhìn thấy nó, hay cái remote TV với quá nhiều nút bấm, hay chỉ là một phần mềm không thể hoạt động đúng như chức năng của nó.
Những thứ như vậy đa phần là hậu quả của sự hiểu lầm, tham lam, không đồng cảm, thiếu tập trung. Những thiết kế tồi tệ đặc biệt làm phiền lòng con người khi ảnh hưởng rất nhiều tới hành tinh xanh này. Nói có hơi quá, nhưng đôi khi nó có vẻ như đang lấp đầy thế giới này bằng rác rưởi linh tinh.



Cùng với sự trưởng thành của nền công nghiệp thông tin, chúng ta đã chứng kiến sự quan tâm và đầu tư nhiều hơn cho việc thiết kế. Nhiều công ty hiện giữ vững quan điểm cho rằng thiết kế có thể trở thành lợi thế trong việc cạnh tranh với các đối thủ khác. Những hiểu biết của con người về ý nghĩa của "thiết kế" ngày càng trở nên sâu sắc qua từng năm tháng, vượt qua cả thẩm mỹ để đến với những kỹ năng giải quyết vấn đề. Trong những thập kỷ gần đây, trong ngành công nghiệp phần mềm chúng ta cho rằng một sản phẩm là "thiết kế toàn diện" khi sản phầm đó được cho rằng hữu dụng, dễ dùng và hấp dẫn khách hàng. Chúng ta có thể làm tốt hơn vậy - chúng ta cần làm tốt hơn vậy!

Tôi đang muốn ám chỉ điều gì? Trước khi chúng ta đi sâu vào vấn đề, hay để tôi cung cấp cho bạn một vài bối cảnh bằng cách quay trở lại và review những cấp độ khác nhau mà thiết kế có thể được hiểu.


Thiết kế = Hình mẫu

Hầu hết mọi người đều cho rằng thiết kế thì thường liên quan đến thẩm mỹ. Những nguyên tắc phổ quát của cái đẹp, như là Tỉ lệ vàng (Golden Ratio), quy tắc 1/3 (Rule of Thirds) hay là những quy tắc của sự tương đối, căn chỉnh liên kết, tương phản và sự lặp lại thông báo cho tiềm thức của chúng ta rằng vật đó có đẹp hay không. Ở mức độ hiểu biết này đối với thiết kế, chúng ta sẽ nghĩ rằng thiết kế là vẻ ngoài của đồ vật, ví dụ như chiếc xe hơi trông có vẻ chạy nhanh, có vẻ đắt hay có vẻ rất cứng cáp,...




Thiết kế = Chức năng

Tuy nhiên thiết kế không phải chỉ là vật thế đó trông như thế nào mà còn là nó hoạt động như thế nào. Chúng ta xem một vật thể là "thiết kế toàn diện" không chỉ khi nó đẹp mà còn khi nó dễ sử dụng. Thiết kế tốt sẽ giúp cuộc sống chúng ta dễ dàng hơn. tiết kiệm thời gian hơn, và giúp ta không cần phải suy nghĩ nhiều, từ đó giảm thiểu stress trong cuộc sống và giữ gìn ý chí và thiện chí đối với những người xung quanh. Trong trường hợp này, thiết kế  giống như là một cái tủ lạnh - khi nó hoạt động thì mảy may chẳng ai chú ý, nhưng khi nó ngừng hoạt động thì mọi thứ trở nên tệ hại cả lên!

Ở bài tiếp theo mình sẽ đưa đến một khía cạnh hoàn toàn khác của thiết kế, các bạn hay đón xem nhé!
Bài viết dựa trên "Design and the self" của blogger Irene Au


Chào các bạn!

Hôm nay nhân dịp chuẩn bị ôn thi Mạng máy tính, mình xin chia sẻ một số thứ cơ bản về Private và Public IP.


Một địa chỉ IP (Internet Protocol) dùng để nhận biết mỗi máy tính, thiết bị trong mạng. Khi máy tính giao tiếp với nhau trên Internet hoặc trong mạng LAN cục bộ, thông tin được gửi thông qua địa chỉ IP của các thiết bị. Bạn phải cần một địa chỉ IP nếu bạn đang host một server cho phần mềm vừa làm - các máy trạm (client) cần biết địa chỉ IP đó nếu muốn kết nói đến server để sử dụng phần mềm.

Địa chỉ IP thường được chi làm 2 loại: Public và Private. Nếu bạn đang tự hỏi không biết giữa chúng khác nhau như thế nào, thì xin mời đọc tiếp phần tiếp theo.


PUBLIC IP

Public IP là địa chỉ được ISP (nhà cung cấp dịch vụ Internet) cấp và có thế được "nhìn thấy" và truy cập từ Internet. Giống như địa chỉ nhà dùng để nhận thư tín, bưu phẩm vậy. Mỗi public IP chỉ tồn tại độc nhất trên mạng Internet cho cả toàn cầu, vì đó không thể tồn tại hai thiết bị (server, máy tính, router,...) có cùng địa chỉ public IP.
Có thể tìm public IP của mình bằng cách search Google

Đa phần người dùng phổ thông không có quyền kiểm soát địa chỉ public IP của mình, quyền đó thuộc về ISP.

Một public IP có thể là tĩnh (static) hoặc động (dynamic) tùy theo loại dịch vụ của người dùng. Một địa chỉ public IP tĩnh không thay đổi và thường được dùng cho hosting các trang web, hoặc dịch vụ trên Internet. Mặt khác, địa chỉ động được chọn từ một "hồ chứa" các địa chỉ có sẵn và thay đổi mỗi lần người dùng kết nối đến Internet.
Đa số ISPs hiện nay cung cấp địa chỉ IP động cho người dùng!

Ví dụ: Các web server, email server, hay các server game bất kì đa số đều được kết nối trực tiếp từ Internet thông qua địa chỉ public IP. Hoặc ở các mạng gia đình, ký túc xá,... thì router giữ public IP để kết nối trực tiếp đến Internet. Các máy tính, smartphones,... và các thiết bị "đằng sau" của router chỉ sử dụng các địa chỉ private IP để kết nối đến router. Router bây giờ hoạt động như một người trung gian, forward lưu lượng dữ liệu đến các địa chỉ IP cục bộ theo yêu cầu, và đảm bảo dữ liệu gửi/nhận đến các địa chỉ chính xác!
Router - "bộ não" của các mạng gia đình thường gặp

PRIVATE IP

Private IP là các địa chỉ được cấp phát bởi InterNIC cho phép các công ty, tổ chức có thể tạo cho họ một mạng cục bộ riêng. Có ba dãy IP ở class A, class Bclass C được IANA (Tổ chức cấp phát số hiệu trên Internet) dành riêng để đánh địa chỉ private IP.
Các dãy địa chỉ được cung cấp để làm private IP

Private IP dùng để phân biệt các máy tính và thiết bị trong một mạng "riêng" bao gồm mạn
g gia đình, trường học, hoặc các tổ chức, công ty, bussiness LANs trong các sân bay, khách sạn,... Và nhờ đó các thiết bị trong mạng có thể giao tiếp được với nhau.


Một ví dụ khác, một mạng X bao gồm 10 máy tính, mỗi máy được gán địa chỉ IP từ 192.168.1.1 đến 192.168.1.10. Không như public IP, quản trị mạng cục bộ có thể tự do gán IP theo ý thích (nhưng phải thuộc dãy private IP ở trên và theo đúng class đang sử dụng)

Khi một máy tính kết nối đến router và được gán một địa chỉ private IP, các thiết bị cục bộ trong mạng "nhìn thấy" máy tính này qua private IP. Tuy nhiên với private IP thiết bị sẽ không thể kết nối trực tiếp đến Internet được, tương tự các thiết bị "bên ngoài" của mạng cũng không thể kết nối trực tiếp đến thiết bị giữ private IP, mà tất cả phải thông qua router. 
Vì vậy với ví dụ mạng gia đình ở trên, thì ở góc nhìn từ bên ngoài, mọi thiết bị trong mạng gia đình, ký túc xá,.. đều đang giao tiếp với Internet thông qua một địa chỉ IP duy nhất - địa chỉ public IP của router!


Để cho phép truy cập trực tiếp đến thiết bị cục bộ bằng private IP, bạn phải cần sự hỗ trợ của NAT (Network Address Translationhoặc kết nối trực tiếp thiết bị đến Internet mà không thông qua bất kỳ router nào!

Bạn có thể tìm thấy địa chỉ private IP của mình bằng cách mở Command Prompt và gõ ipconfig. Vì hầu hết mạng hiện nay vẫn đang sử dụng IPv4 nên con số xuất hiện ở dòng "IPv4 Address" chính là private IP của bạn. Với mạng gia đình, hầu hết sẽ là 192.168.1.1 hoặc 192.168.1.2.
Private IP class A của nhà mạng ký túc xá

NHỮNG HIỂU LẦM THƯỜNG GẶP VỀ PRIVATE IP


Nhiều người cho rằng private IP là địa chỉ được dùng cho các hành động lén lút trên Internet, và do đó nó không thể bị phát hiện. Nhưng điều đó KHÔNG ĐÚNG!

Không như nhiều người nghĩ, địa chỉ private IP không giống như số điện thoại riêng tư, nó chỉ là một địa chỉ thuộc về một mạng "riêng tư". Trong thực tế không một địa chỉ public IP nào mà không thể bị "trace" - theo dõi, bởi vì chính giao thức TCP/IP này được thiết kế nhằm mục đích công khai và minh bạch!



Chúng ta thường được nghe qua sự thành công trong sự nghiệp của các doanh nhân là nhớ vào chấp nhận mạo hiểm, rủi ro để nhận phần thưởng. "Chúng tôi dám dũng cảm nắm bắt cơ hội và làm liều thôi" - đó là những phát ngôn của họ khi họ đã thực sự thành công, tuy nhiên sự thật thì điều đó khá hiếm xảy ra, thậm chí chỉ xuất hiện trong những câu chuyện ngụ ngôn!
Liệu mạo hiểm để thành công có hoàn toàn đúng

Tôi từng đọc đâu đó trên Internet, rằng có một người bạn trên là Bryan chấp nhận từ bỏ công việc Technical writer  (viết tài liệu kỹ thuật, hỗ trợ khách hàng,...) cho một tập đoàn nằm trong danh sách Fortune 500 để tìm một việc gì đó thực sự mới mẻ.

Trong ngày làm việc cuối cùng của Bryan, mọi người trong văn phòng bộc lộ nhiều thái độ khác nhau: từ ghen tị đến bất ngờ. Họ không thể tin rằng anh lại có thể rời công ty như vậy, rằng anh ta vừa có một bước nhảy thực sự lớn trong sự nghiệp. Nhưng thực tế Bryan đã lên kế hoạch cho thời khắc ấy từ 10 năm trước.
Đã đến lúc phải nghỉ việc và chuyển sang một công việc mới?
________________________

Đến đây tôi tự ngẫm rằng, tôi dù đang học công nghệ phần mềm, nhưng lại ấp ủ niềm đam mê khởi nghiệp. Liệu rằng sau này khi có một công việc làm ổn định trong một công ty có sức hút đủ lớn, với mức thu nhập chấp nhận được, bạn có sẵn lòng nghỉ việc để làm một điều gì đó mới mẽ như Bryan?

Bởi vì đơn giản nếu thất bại tôi có thể mất gần như hoàn toàn những gì mà công sức bản thân đã gây dựng trong bao năm qua. Tuy nhiên nếu thành công thì sẽ như một câu chuyện cổ tích! Tôi nên làm gì?
______________________

Ai từng đọc qua một số quyển sách kinh doanh, nghe những câu chuyện về những người tự thân lập nghiệp, hoặc ghé thăm những người bạn cũ thành đạt thời Đại học, bạn luôn nghe đi nghe lại cụm từ "Tôi dám dũng cảm nắm bắt cơ hội và làm liều thôi".
Cụm từ này được nhắc đi nhắc lại khi nói về những thành công lớn. Nó như là một câu chuyện về rủi ro và phần thưởng mà chúng ta hay nghe từ miệng của những doanh nhân giàu có, các diễn viên điện ảnh nổi tiếng hay những nghệ sĩ trứ danh... Nhưng, nó đều là những lời nói dối!


THÀNH CÔNG THƯỜNG ĐẾN RẤT MUỘN

Jeff Goins - một nhà văn, doanh nhân nổi tiếng - từng được phỏng vấn rằng, làm cách nào anh ta có thể trở thành một nhà văn toàn thời gian. Mọi người muốn biết lý do lớn nhất mà anh theo đuổi công việc này là gì?

"Không, không có, không có gì là lớn lao cả, chỉ là sự cộng hưởng của những thành công nhỏ qua thời gian..." 
Anh ta không có khoảnh khác giống như Jerry Maguire - một nhân vật trong bộ phim điện ảnh cùng tên đã quyết định từ bỏ mọi thứ khi đang ở đỉnh cao sự nghiệp để có thể sống và hành động theo đúng với cảm nhận của mình - tuy nhiên khi bắt đầu có một cái nhìn chân thành về sự thành công, anh ta nhận ra rằng chúng ta cần có những chiến lược chậm và chắc.
Để thành công cần luyện tập ngày qua ngày

Năm 1975, Bill Gates thành lập Microsoft. Nhưng mãi đến 6 năm sau ông mới ký được hợp đồng đầu tiên với IBM. Sau đó cần đến 5 năm nữa công ty mới IPO (phát hành cổ phiều lần đầu ra công chúng), giúp Gates trở thành triệu phú và được mọi người tung hô là một vĩ nhân với "thành công chỉ qua một đêm". 

Với Steve Jobs, thậm chí nó còn mất nhiều thời gian hơn. Ông cùng với Steve Wozniak thành lập Apple Computer năm 1976, nhưng không có gì nổi bất đến 1984, với sự ra đời của Macintosh. Sau đó ông bị đuổi khỏi công ty và sau khi trở lại thì sự nghiệp của ông mới thành công như hôm nay.

Một câu chuyện nổi tiếng khác trong giới công nghệ, nhà đồng sáng lập GoogleLarry PageSergey Brin cũng gặt hái thành công khá chậm. Họ mở công ty năm 1996, và đến 8 năm sau công cụ tìm kiếm của họ mới đánh bại tất cả các đối thủ khác thời đấy và giúp Google hoàn thành thương vụ IPO với mức vốn hóa thị trường lên tới 23 tỉ USD.

Cả 3 ví dụ trên đều phù hợp với thuyết "luyện tập thận trọng" của K. Anders Ericsson và thuyết "quy tắc 10 000 giờ" của Malcoml Gladwell sau đó trở nên phổ biến. Trong nghiên cứu của ông, Ericsson cho rằng để một người nào đó trở thành chuyên gia trong một lĩnh vực, họ cần ít nhất 10 000 giờ luyện tập. Nói cách khác, trước khi bỏ việc hoặc chuyển sang một ngành nghề mới, hãy dành thời gian luyện tập, xây dựng kĩ năng cần thiết để làm việc đó một cách tốt nhất.
Trước khi nghỉ việc, dành thời gian xây dựng những kỹ năng cần thiết để làm tốt công việc mới


SAI LẦM TỪ NHỮNG CƠ HỘI LỚN

Trong bối cảnh hiện nay, chưa bao giờ sự gia tăng không ngừng của những startup lại lớn như thế này. Kinh doanh trực tuyến càng trở nên dễ dàng - chúng ta vẫn luôn bị ám ảnh bởi những tư tưởng "chấp nhận rủi ro", "dám làm liều"...

Tại sao? Bởi vì tất cả mọi người xung quanh đều có suy nghĩ rằng để thành công trong sự nghiệp chắc hẳn chúng ta phải dám đánh một ván cược lớn để hưởng thành quả to lớn. 

________________________

Thực ra tư tưởng khởi nghiệp đang dần ăn sâu vào từng con người, ngay từ thời sinh viên đã liên tục có những buổi hội thảo, chuyên đề về startup, dạy cách để đạt thành công trong sự nghiệp. Hàng trăm, hàng nghìn quyển sách "dạy đời" truyền cảm hứng rằng con người trong cuộc sống phải chấp nhận rủi ro, chấp nhận mạo hiểm để gặt hái được thành công. Ngay cả lang thang trên Internet cũng không khó để bắt gặp những bài viết kiểu như vậy!.
Tư tưởng đó luôn ám ảnh tôi và cả những người rất giỏi tôi từng biết.

Mọi khi có dịp tụ tập từ quán nước vỉa hè đến các quan coffee sang trọng chúng tôi đều nói hoặc nghe người khác nói về con đường tương lai. Ai cũng muốn thành công sớm, có cho mình một công ty riêng, một sự nghiệp ổn định. Mà không ai nghĩ rằng làm sao để có được nó, liệu "dám mạo hiểm, nắm bắt cơ hội, chấp nhận rủi ro" đã đủ chưa? Hãy phải trải qua "10 000 giờ" luyện tập gian khổ?
________________________

Vâng, thực tế mọi chuyện không diễn ra dễ dàng như vậy!


Chắc hẳn các bạn còn nhớ câu chuyện Thỏ và Rùa này chứ!

Dr. Robert Maurer, tác giả của "One Small Step Can Change Your Life", cho rằng chúng ta thích ý tưởng về một "bước nhảy lớn", ngay cả khi nó có thể gây hại. Nhưng nó không phải là cách mà những sự đổi mới trên thế giới xảy ra. Một lý do là bộ não của chúng ta được phản xạ để từ chối những thay đổi lớn. Đây là cách ông ta giải thích nó trong một bài phỏng vấn:

Bộ não phản ứng với những thách thức lớn bằng cách kích hoạt các amygdala, trung tâm sợ hãi trong não. Nếu thách thức được coi là quá lớn, nếu đó là người sợ thất bại, nỗi sợ hãi trở nên to lớn và người đó sẽ bỏ cuộc.

Maurer thậm chỉ còn đưa thêm dẫn chứng về "kaizen", một thuật ngữ Nhật Bản được ghep từ chữ "kai" - thay đổi và "ken" - tốt hơn. Tức là một quá trình "thay đổi để hoàn thiện", hay "cải tiến liên tục". Thay vì cố gắng để giảm cân, hãy ra ngoài luyện tập 1 phút mỗi ngày, rồi 2 phút, 3 phút,... Theo thời gian, những thứ nhỏ nhặt lại trở nên lớn lao và bền vững.

Nhà triết học nổi tiếng Aristotle từng nói "Chúng ta là những gì chúng ta thường xuyên làm. Vì vậy sự hoàn hảo không phải là hành động mà là thói quen". Nếu làm một điều gì đó đủ lâu, bất kể điều gì dần dần cũng trở thành thói quen.

THAY VÌ MẠO HIỂM, CHẤP NHẬN RỦI RO ĐỂ THỰC HIỆN "BƯỚC NHẢY VỌT"

Vậy làm sao để áp dụng những lời khuyên của Maurer vào thực tế?

Đầu tiên, hãy bắt đầu từ những việc nhỏ, thật nhỏ. Nhiều người cho rằng để có được thành công, họ phải làm nó thật to lớn. Nhưng nó không thực sự đúng. Mỗi ngày, mọi người theo đuổi ước mơ của họ và đều mắc sai lầm. Họ đặt mục tiêu "trên cung trăng" mà không chuẩn bị những bước đầu cơ bản nhất. Và kết quả là họ thất bại.

Thứ hai, xây dựng thói quen của bạn theo thời gian.  Mọi thứ đều phải trải qua thực hành. Và càng làm nhiều, mọi việc càng trở nên dễ dàng hơn. Thói quen làm mọi thứ trở nên dễ dàng hơn, và làm mỗi người chúng ta tốt hơn.

Thỏi quen giúp mọi thứ trở nên dễ dàng hơn và giúp mỗi người chúng ta trở nên hoàn thiện hơn.

Cuối cùng, hãy luôn nhớ rằng bạn xây dựng kĩ năng và cũng chính bạn trau dồi cho những kĩ năng đó. Và sau cùng, những gì bạn nhận được không phải là những bước nhảy vọt bấp bênh, mà là một cây cầu vững chắc mà bạn đã chậm rãi, thận trọng xây nó theo thời gian. Điều này sẽ không trở thành một câu chuyện tốt để làm phim cho Hollywood, nhưng nó là cách tốt nhất để thành công tồn tại lâu dài!

____________________________

Thực sự tôi không nghĩ ý kiến bỏ việc và mạo hiểm để Startup là tồi, bởi vì sau này dường như tôi cũng sẽ làm vậy. Tuy nhiên trước đó bạn phải đảm bảo có một quá trình luyện tập dài để có những kỹ năng đáp ứng cho công việc.

Dù bạn là ai, dù bạn có giỏi hay không, dù cho mọi người xung quanh đang gặt hái nhiều thành công to lớn, có nhiều "bước nhảy vọt", trong lúc chúng ta luôn thất bại, xin đừng nản lòng. Hãy cố gắng tìm cho mình những thứ mình thích, luyện tập và trau dồi kỹ năng để làm việc đó. Rồi khi đạt đến một trình độ nhất định, bạn chắc chắn sẽ thành công. Và cho dù có xui xẻo thất bại thêm nhiều lần nữa thì cũng là vì những thứ bạn yêu thích. Nó rất xứng đáng mà, phải không?

Tôi cũng từng có một quá khứ thành công, và cũng đầy thất bại. Vì quá khứ huy hoàng thời phổ thông làm tôi trở nên tự kiêu, tự mãn. Đôi lúc tôi cũng thử mạo hiểm bỏ học tập ở trường, nắm bắt cơ hội để đi làm từ thời sinh viên năm 2, tuy nhiên vấp phải đầy khó khăn và đôi lúc tôi thực sự gục ngã. Tuy nhiên kết quả nhân được là kinh nghiệm sống, và quan trọng là rút ra quyết định dừng lại để trau dồi, học tập thêm kỹ năng và cố gắng đạt thành công một cách chậm rãi, bền vững. 

Trong suốt quá trình học hỏi và mạo hiểm của mình tôi không bỏ ra quá nhiều thời gian để hối hận, ngay cả khi thất bại. Bởi vì chẳng có thuốc chữa hối hận, mà lãng phí thời gian dành cho nó cũng chẳng giúp ích gì cho bản thân tôi cả. Cuộc sống có thể sẽ khó khăn và khắc nghiệt với bạn, nếu cảm thấy thiều định hướng, hãy thử bắt đầu với những gì bạn thích làm và làm khá về nó. Bằng cách đó, khi tưởng chừng như mọi cánh cửa đã đóng, thì biết đâu đấy sẽ có một cánh cửa mở ra với bạn, giống như tôi vậy!
____________________________


Hãy cứ ước mơ, hãy cứ dại khờ. Luyện tập ngày qua ngày rồi thành công sẽ đến với bạn

Bài viết tham khảo từ những quan điểm cá nhân của Jeff Goins - một doanh nhân và nhà văn nổi tiếng.



Chào các bạn,
Khi chúng ta nói đến lập trình máy tính (computer programming), ta không chỉ đề cập riêng việc viết code bằng các ngôn ngữ lập trình như Java, C#, C++, Python,... mà còn là cả một quá trình phát triển phần mềm. Chỉ đơn thuần học cách viết mã nguồn bằng ngôn ngữ lập trình là KHÔNG ĐỦ để trở thành một người phát triển phần mềm (software developer) tài giỏi. Bạn cần phải nắm rõ cách thiết kế một chương trình theo phương pháp lập trình hướng đối tượng (object-oriented programming). Khi đó bạn sẽ không chỉ đơn thuần là một coder lúc nào cũng chỉ biết ôm máy tính để lập trình, mà sẽ trở thành một developer hiểu sâu và rộng kiến thức trong nhiều lĩnh vực.
Kỹ nghệ phần mềm - Xu hướng của đa số sinh viên CNTT hiện nay


VỊ TRÍ BẮT ĐẦU TRONG NGÀNH CÔNG NGHỆ PHẦN MỀM

Vậy thì coder, programmer, developer và engineer là gì? Và nó khác nhau chỗ nào?

Về cơ bản, coder (thợ code) chỉ viết các mã lệnh logic với ngôn ngữ lập trình trong phạm vi yêu cầu mà anh ấy không cần biết nhiều về logic của chương trình. Họ được cung cấp định nghĩa về các bussiness logic và flowchart hoặc dễ hiểu hơn là các vấn đề được mô tả bằng ngôn ngữ tự nhiên, mã giả,... và nhiệm vụ của họ là chuyển nó sang mã nguồn lập trình.
Còn Programmer thì cũng tương tự như coder, tuy nhiên anh này là người đề ra giải pháp giải quyết các vấn đề, cung cấp bussiness logic cho coder. 
Tôi đang trên đường trở thành một Engineer, còn bạn thì sao?
Developer là người không chỉ code mà còn tham gia vào tất cả các quá trình của SDLC (Software development life cycle). Nếu dự án có vấn đề mà bạn chưa định hình được nó và hướng giải quyết thì các developer sẽ giúp bạn phân tích vấn đề, và tìm cách giải quyết nó. Vậy developer là người vừa lập trình, vừa định hướng phát triển sản phẩm
Engineer là một thuật ngữ được sử dụng ở mức cao cấp nhất. Anh này hoạt động ở cả phần lập trình, phân tích thiết kế (bussiness level) và bảo trì. Là những developer giỏi, có khả năng phân tích và giải quyết các vấn đề phức tạp. Những anh này thường sẽ được trả lương xấp xỉ với quản lý dự án (Project Manager), tuy nhiên thiên về hướng phát triển kỹ thuật hơn.

Ở bài này mình chỉ nói sơ về các vị trí bắt đầu khi bước vào ngành CNPM, bởi vì kiến thức thực tế còn quá giới hạn nên các vị trí khác đành chờ phần sau vậy :D




QUY TRÌNH PHÁT TRIỂN PHẦN MỀM


Chúng ta xây một ngôi nhà với các giai đoạn được xác định rõ ràng (làm móng, xây nền, dựng cột, xây tường,...), và áp dụng các nguyên tắc kỹ thuật vào tất cả các giai đoạn đó. Làm phần mềm cũng vậy, bạn xây dựng một chương trình qua các công đoạn và áp dụng các phương pháp, qui tắc phát triển phần mềm vào từng công đoạn. Trình tự các công đoạn đó từ giai đoạn ý tưởng (conception) đến vận hành (operation) được gọi là qui trình phát triển phần mềm (Software Development Life Cycle)

Có 5 giai đoạn chính trong qui trình phát triển phần mềm: Phân tích (Analysis), Thiết kế (Design), Cài đặt mã nguồn (Coding), Kiểm thử (Testing) và Vận hành (Operation). Phần mềm ra đời dựa trên yêu cầu của người dùng.


PHÂN TÍCH


Ví dụ: một người muốn có một danh bạ online. Trong giai đoạn phân tích, chúng ta thực hiện nghiên cứu tính khả thi, chúng ta phân tích các vấn đề và xác định xem liệu giải pháp có thực sự khả thi. Và nếu giải pháp đó khả thi, thì kết quả của giai đoạn này sẽ là bảng "Đặc tả yêu cầu"  - requirement specification - để mô tả các chức năng của chương trình. Các tính năng này phải được phát biểu theo những cách có thể kiểm chứng được. Một trong những tính năng của danh bạ online là có khả năng tìm kiếm một người dựa trên first name của họ. Chúng ta có thể kiểm tra tính năng đó bằng cách chạy trực tiếp chương trình và tìm kiếm, và kiểm tra xem chương trình có hoạt đông đúng và cụ thể khi tên của một người có trong danh bạ, và người không có trong danh bạ được gõ vào khung tìm kiếm. Những việc làm đó thuộc pha Kiểm thử, thứ mà mình sẽ nói tới nó sau.


THIẾT KẾ

Trong giai đoạn thiết kế, chúng ta sẽ chuyển bảng đặc tả yêu cầu thành bảng "Thiết kế chi tiết" - detailed design của chương trình. 
Trong giai đoạn này chúng ta sẽ thiết kế các giao diện người dùng của chương trình (User Interface) -  bao gồm các bước: Lập danh sách các màn hình (view, form,...) dựa vào Use Case, vẽ sơ đồ mối quan hệ giữa các màn hình, Thiết kế các đối tượng trên mỗi màn hình (Sắp xếp vị trí các button, textbox,...) theo các qui tắc về thiết kế giao diện, cuối cùng đặc tả, giải tích cách hoạt động của các đối tượng trên từng màn hình đó.
Với một chương trình thiết kế hướng đối tượng (object-oriented design), kết quả của pha này không thể thiếu Danh sách các lớp (class) được dùng để đáp ứng yêu cầu. Chúng ta sẽ thiết kế các lớp đối tượng, dựa vào những yêu cầu cần thiết, các kiến thức về kế thừa, đa hình để thiết kế các lớp đối tượng, và mô hình hóa chung bằng các sơ đồ (ví dụ UML - Unified Modeling Language). Ví dụ: với chương trình danh bạ online ở trên thì chúng ta có thể cần các class như Person, Phone, Group,...
Thiết kế phần mềm - giai đoạn không thể thiếu trong qui trình phần mềm
Ngoài ra ở một số chương trình đặc thù, ta còn cần thiết kế các tầng dữ liệu cho chương trình. Dữ liệu ở đây có thể là hệ thông tập tin đơn giản, đến các hệ  cơ sở dữ liệu phức tạp. Sau đó vẽ sơ đồ mô hình hóa, đặc tả dữ liệu.
Cuối cùng không thể thiếu là thiết kế xử lý cho chương trình. Chi tiết hóa các kịch bản usecase, các luồng logic trong chương trình. Và sử dụng sơ đồ tuần tự để mô tả.


CÀI ĐẶT MÃ NGUỒN

Trong giai đoạn cài đặt mã nguồn, chúng ta triển khai các thiết kế thành một chương trình thực tế bằng các ngôn ngữ lập trình như Java, C#, Python, hay các hàm API,... Chúng ta đã có một bảng thiết kế cấu trúc hoàn chỉnh, thì việc triển khai thành mã nguồn không thực sự quá khó khăn.
Nhiều người hay lầm tưởng làm phần mềm chỉ là ngồi viết code!


KIỂM THỬ

Khi quá trình triển khai mã nguồn hoàn chỉnh, chúng ta sẽ đến với giai đoạn kiểm thử. Trong giai đoạn này chúng ta sẽ chạy chương trình với nhiều bộ dữ liệu để kiểm chứng là chương trình chạy đúng theo đặc tả yêu cầu. Hai loại kiểm thử dành cho các chương trình hướng đối tượng là: kiểm thử đơn vị (unit testing) và kiểm thử tích hợp (integration testing). 
Giai đoạn dễ gây "mâu thuẫn" giữa các thành viên trong team nhất!
Kiểm thử đơn vị thường do lập trình viên thực hiện, kiểm nghiệm từng class riêng biệt, từng hàm trong mã nguồn trong môi trường cô lập. Còn đối với kiểm thử tích hợp chúng ta kiểm tra các class có làm việc đúng khi ghép lại với nhau hay không, và quá trình test diễn ra ngay sau unit testing. Hành động "bất hủ" dùng để phát hiện và loại bỏ lỗi của quá trình  thiết kế và cài đặt gọi là "debugging". Nếu tìm được lỗi, chúng ta phải quay về pha trước đó để sửa chữa và hoàn thiện chương trình.

Bonus cho các bạn 1 câu nói bất hủ của Dijkstra :
"Program testing can be used to show the presence of bugs, but never to show their absence!"

VẬN HÀNH

Cuối cùng sau khi quá trình kiểm thử kết thúc thành công, chúng ta đi vào pha vận hành, khi đó chương trình sẽ được đưa vào sử dụng thực tế. Thứ quan trọng nhất và mất nhiều thời gian nhất trong pha này là bảo trì phần mềm (software maintenace). Ngay cả sau khi phần mềm được đưa vào sử dụng, chúng ta hầu như luôn phải sửa đổi nó. Bởi vì khách hàng có thể yêu cầu thêm tính năng, hoặc các lỗi mới được tìm thấy. 
Thống kê cho thấy, xấp xỉ 70% phí của phần mềm thuộc về công đoạn bảo trì. Vậy nên khi phát một phần mềm chúng ta phải nhắm vào phần mềm dễ bảo dưỡng, bỏ thời gian và công sức ra để phân tích thiết kế và lập trình cẩn thận. Ngay cả nó có mất thời gian, và chi phí giai đoạn đầu, nhưng trong qua trình hoạt động lâu dài, các phần mềm có sự chuẩn bị thiết kế chu đáo sẽ ít tốn kém hơn. Đây là một điểm rất quan trọng mà các bạn nào muốn trở thành một nhà phát triển phần mềm giỏi cần phải lưu ý!

--------------------------------------------------------------------------------------------
Giai đoạn thiết kế luôn là giai đoạn quan trọng nhất trong qui trình phần mềm!

Chào và chúc các bạn học tốt!



Chào các bạn!

Nhiều bạn thắc mắc muốn thao tác với ảnh bằng C# Winform thì làm như thế nào, hôm nay mình sẽ hướng dẫn các bạn cách kết hợp hai control cơ bản là PictureBox OpenFileDialog để làm một chương trình "Picture Viewer" trong C#
Đầu tiên các bạn tìm hiểu sơ lược về hai control này nhé.




PICTURE BOX TRONG C#

PictureBox là một control khá hữu dụng của C# .NET. Nó cung cấp một vùng hình chữ nhật để chèn ảnh bất kỳ và kích cỡ có thể tùy chỉnh bằng nhiều cách khác nhau.
Picturebox hỗ trợ nhiều định dạng ảnh: BMP, GIF, JPEG, EXIF, PNG và TIFF, ICO... (các định dạng được GDI+ hỗ trợ)
PictureBox có thể lấy ảnh từ ổ cứng của bạn hoặc từ Internet

Đầu tiên mình sẽ hướng dẫn các bạn chèn ảnh từ ổ cứng:
Mình sẽ dùng ảnh PNG trong ví dụ bên dưới, các định dạng khác cũng làm tương tự.

Tại sao chúng ta lại phải thiết lập thuộc tính Width và Height? Vì ảnh của chúng ta và kích cỡ của PictureBox có thể khác nhau rất nhiều, nếu như không thiết lập thì ảnh có thể sẽ bị crop. Ngược lại muốn crop ảnh theo kích cỡ mong muốn thì cứ thiết lập thuộc tính Width, Height của PictureBox

Picturebox cũng có các thuộc tính tương tự như các control cơ bản khác, tuy nhiên có một số thuộc tính mới cần nói như SizeMode.
Thay vì thiết lập thuộc tính Width và Height của PictureBox, hoặc hình ảnh. Chúng ta có thể thiết lập nhanh bằng một số tùy chọn .NET cung cấp sẵn:

Chúng ta còn các SizeMode khác như (Normal, Zoom: căng ảnh nhưng duy trì tỉ lệ aspect ratioAutoSize: tự thiết lập size của pictureBox bằng với size của ảnh, CenterImage: Center ảnh vào trung tâm PictureBox, StretchImage: căng ảnh lên theo 2 chiều cho vừa với khung pictureBox)

Tiếp theo là chèn ảnh từ Internet. Ví dụ trên mình đã dùng thuộc tính ImageLocation để chèn ảnh bằng địa chỉ của nó. Vậy thì địa chỉ hình ảnh trên Internet thì sao nhỉ?
Chúng ta thử gán nhanh cho thuộc tính ImageLocation trong cửa sổ properties với giá trị: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiT3aZFMZ3jDv1pa1cvkSNUPHLgJnOeC_MuXY0FPpQU2I24_Hd1tbFX7-vt_qDp1ANqMRJAFtxX0oMVvxiVFYFKf4-t9nZYaro26Nb6jzWi_3M50jTrBE5x4vPqAXTXWmuSPnnPuuXegBg/s1600/cooltext125983511023412.png. Sau đó chạy thử chương trình lên và kết quả sẽ là:


Về phần sự kiện của PictureBox thì chúng ta cũng có các sự kiện cơ bản như các control khác (Click, Mouse Hover,...). Vậy là xong phần PictureBox, chúng ta cùng sang control thứ hai cần thiết để hoàn thành chương trình này.


OPEN FILE DIALOG TRONG C#

OpenFileDialog (OFD) cho phép người dùng browse một thư mục hoặc tệp tin. Là control thường thấy trong rất nhiều ứng dụng. Nhất là các gói cài đặt thường cho bạn chọn thư mục để cài.

Để cài đặt một OFD các bạn kéo nó ra từ thanh Toolbox, nhóm Dialogs.
Thường thì chúng ta sẽ thiết lập các thuộc tính cho OFD ở ngay trong khung Properties. OFD cũng có thuộc tính Name, Title, Tag,.. như các control khác. Tuy nhiên một số thuộc tính mới như:
- FileName: Tên mặc định của File. Nếu các bạn gõ vào đây "fileName1" thì khi mở hộp thoại "fileName1" sẽ đặt mặc định trong ô FileName. Vậy nên các bạn nên xóa và để trống thuộc tính này
- Filter: Bộ lọc file. Thông thường ta chỉ cần một số loại file nhất định, nhưng nếu thư mục có quá nhiều file khác nhau thì việc tìm kiếm sẽ mất nhiều thời gian. Nên chúng ta có thể thiết lập thuộc tính Filter để lọc ra các loại file mong muốn.
Ví dụ: ofd.Filter = "Windows Bitmaps|*.bmp|JPEG Files|*.jpg"
Cứ theo định dạng mô tả | *.đuôi tệp tin. Giữa những loại tệp tin với nhau cũng là một dấu gạch đứng |.
- CheckFileExist, CheckPathExist: Các bạn để mặc định là true để OFD kiểm tra file và đường dẫn có hợp lệ, tồn tại không.
- InitialDirectory: Thư mục mặc định mà khi OFD được show ra sẽ nằm ở đó.
- MultiSelect: Nếu các bạn muốn chọn nhiều file một lúc thì cho bằng true.
- ...

Để mở hộp thoại OFD, chúng ta cần một button và thiết lập cho nó sự kiện Click để chạy code show OFD.

DIALOG RESULT

DialogResult là một biến kiểu Enum, dùng để nhận giá trị trả về của var.ShowDialog(). Để kiểm tra xem người dùng vừa click nút nào, dự định làm gì.
DialogResult chứa các giá trị như: OK, Cancle, Ignore, Try, Yes, No,...

Vậy thì tiếp theo làm sao để ta lấy được hình ảnh từ OFD? Chung ta sẽ lấy đường dẫn của ảnh vừa chọn bằng thuộc tính FileName của OFD.

 Image img = Image.FromFile(openFileDialog1.FileName); 

Vậy là chúng ta đã học xong được tất cả các chức năng chính của PictureBox và OpenFileDialog rồi. Giờ chỉ còn kết hợp nó để làm chương trình xem ảnh thôi :D

Mình sẽ cung cấp code mẫu ở đây luôn. Ai có gì không hiểu thì bình luận hoặc pm trực tiếp mình qua facebook/email nhé

Chúc các bạn học tốt! Chào và hẹn gặp lại


Contact Form

Name

Email *

Message *

Powered by Blogger.
Javascript DisablePlease Enable Javascript To See All Widget