Tips for being a better programmer

1. Read, Read, Read
Read a lot, read stuff booksblogs whatever. Subscribe to blogs so that you will learn something new everyday.

Read other peoples code, I mean read good code, for me I read some parts of the Spring MVC and Spring Security modules code to better understand how it works and I sometimes amazed at how clean the separation of the different modules are. Reading bad code, cause you will never want to do the things that guy did.

Read about the history of programming, it’s quite a shame that most programmers don’t really know much about its history. You can watchDouglas Crockford’s video to get an idea of where all these came from.

2. Try Try Try
But its not enough to read, you must try! If you are a OO try try functional programming, if you are a functional guy, try OO. Try web programming if you mainly do desktop apps.

Don’t try with something trival! Like printing HELLO WORLD. Try and solve a problem.

See a problem? Suitable for writing a small project? Go ahead and try it! I always try to keep in mind a few such problems so that I always have something to do if I have some free time. And by trying it in a context of a problem you can see what value the new tool/framework/language can bring to you. You need to develope your toolbox so that everything you see will not be a nail.

Interested in Google maps ? Write something with Google map!

3. Be Clean

Write clean code, leave the code a little bit cleaner than when you came. Uncle bob’s Clean Code, is a great book about how to write better code, read about theSOLID principles while you are at it.

4. No “I” in team
We work in teams, very few of us that are doing this for a living work solo. Learn to be a people person, I remember during my high school days, an image consultant came by to teach us how about color and clothes and etiquette and she emphasize the importance of people liking you, because if people like you they will be willing to teach you even if you are not very good. Dale Carnegie has a nice book on the topic, How to win friends and influence people.

Many a careers are sometimes determined by not how good you are technically but how you are as a person.

5. Be through (or at least try to be)
What can be more frustrating then someone coming up to you and say “Hey the webservice didn’t work”, and when you probe further you found out that he didn’t know what exception caused it because he didn’t bother to check the logs. He just comes up to you and expect a magical answer.

Well try to be through in solving a problem, at least your lead or your manager will appreciate that you have at least tried to find out the cause.

6. Know your users domain
Know the domain be it accounting, customer service, military, will aid in you communicating with your users. It makes talking with them so much the easier.

Posted by Stephen

pregmatch

/is:

-i ko phân biệt chữ hoa hay chữ thường
-s là space

preg_match(“/^[A-Za-z0-9]{32,32}$/”, $_COOKIE[‘inform’]);

-Hai dấu / ở đầu và cuối chỉ là hai dấu phân cách
-Dấu ^ : Có nghĩa là kiểm tra coi cái chuỗi đó có nằm ở đầu chuỗi hay ko
Ex : ^ea sẽ tương kết với eat nhưng sẽ không tương kết với deaf
-Dấu $ ở cuối có nghĩa là kiểm tra coi có phải là cuối chuỗi hay ko
Ex : tương tự ea$ sẽ tương kết với tea chứ ko tương kết leaf
-Dãy [A-Za-z0-9]{32,32} : Tương kết các chuỗi là số hay chữ (hoa và thường) và có tối thiểu là 32 kí tự , tối đa 32 kí tự
Ex Nó sẽ tương kết
thefamerinthedell…(32 kí tự)
Chứ ko tương kết
the fammer in the dell
Hay
the_fammer_in_the_dell

ex:

$myString = “hoang.anh”;
var_dump(preg_match(‘/^A-Z.+$/i’, $myString));

ex:

$mail= “hoang.anh@gmail.comjklj.”;
var_dump(preg_match(“/^(a-zA-Z0-9)(a-zA-Z0-9._-)*@(a-zA-Z0-9)\.(a-zA-Z0-9)$/” , $mail));

author: ppdat

Sub version (SVN) Tofu scale

Một số khái niệm căn bản về svn:
Repository: Là nơi lưu trữ phiên bản mới nhất của file, cùng các phiên bản trước đó, và nó thường được đặt tại server
Version : Là là một phương pháp đặt tên, hay số duy nhất mỗi trạng cho trạng thái  của cây repository tại một thời điểm. Với version đặt tên bằng số, các số này được săp xếp theo thứ tự tăng dần. Phiên bản mới hơn sẽ có số lớn hơn.
Changeset: Changeset là một tập hợp những thay đổi với một tên là duy nhất, Những thay đổi có thể là những đoạn được edit trong một file nội dung, những thay đổi trong một cấu trúc cây… Changeset không lưu lại toàn bộ file khi bạn edit , nó chỉ lưu lại những điểm thay đổi , nó là một patch với một tên riêng biệt mà bạn có thể truy cập tới.
Project Layout: Nơi tập trung code của một project, chỉ chứa các file liên quan đến project không chứa những project con.
Repository Layout: Cấu trúc các thư mục để lưu các version của project, hay thư mục lưu tài liêu liên quan tới project , cho phép ta có thể check project theo từng giai đoạn.
Example:
  • Repository Layout
  • /branches
      • dev
        • 1.1.10/code   <= Project Layout
        • 1.1.11/code   —
      • releases
  • /tags
  • /trunk
Branches: Branches là một nhánh code được copy ra từ một nguồn code (có thể là trunk hay một branch khác), và nó đươc development một cách độc lập với các thành phần khác.
Branches được tạo ra với các mục tiêu:
  • Development độc lập với các revision hiện tại, và nó sẽ xuất hiện trong release version
  • Làm việc độc lập trong thời gian dài.
  • Sử dụng source code từ các developers khác.
Tags: làm một “snapshot” của một project tại một thời điểm. Trong subversion, mỗi revision là một snapshot cùa một repository filesystem sau mỗi lần commit,
Sprint: làm một kỹ thuật quản lý thời gian trong planing projects, trong đó schedule được chia ra thành từng quãng thời gian riêng biệt, với mỗi quãng thời gian thì có một mục tiêu, deadline.
The version control pattern:
Mainline là gì ?
Một branch được gọi là một codeline, như trên hình vẽ release 2.3, 2.4 hay Project x là một codeline.
Cha của một codeline được gọi là baseline, release 2.4 là baseline của release 2.4.1.
– Mainline là một codeline không có base line, trunk là mainline, mỗi resposotory chỉ có một mainline và nó phải thỏa điều kiện
– Can release at any time: Tại mọi thời điểm khi muốn có một sản phẩm mới ta đều có thể release trực tiếp từ mainline.
Theo ví dụ trên: line màu xanh là trunk (mainline). Mỗi green ball thể hiện một lần checkin, khi hoàn thành 5 phần thì kết thúc được một Sprint.  Chúng ta có thể release từ trunk bất cứ lúc nào, khi gặp sự cố không thể finish #5 ta vẫn có thể release. 
– Want to release ASAP: Khi không muốn release #3, ta có thể kill branch, và release tới #2 như ở hình trên.
Tofu scale ?
Firm codeline“: là nhánh code ổn định, đã qua test, không thường xuyên thay đổi,  và là một nhánh release đã close.
Soft codeline“: là nhánh ít ổn định hơn, vừa thực hiện test, có thể bị thay đổi thường xuyên, và chưa đưa ra release
Qua ví dụ trên ta thấy, nếu Team B làm một nhánh code khác  merge trực tiếp từ Team A, điều này có thể sẽ dẫn tới nảy sinh rất nhiều lộn xộn trong code. thay vì làm điều đó , team A sau khi kết thúc team A sẽ đưa code của mình lên mainline, và team B sẽ down từ mainline xuống làm.
Mọi nhánh nằm trên mainline được gọi là release codeline. Release codeline firmer hơn mainline.
Mọi nhánh nằm dưới mainline được gọi là development codeline. development codeline softer hơn mainline.
Với ví dụ tại hình trên ta thấy:
  • Project x là một codeline được sinh ra từ mainline. Khi project hoàn thành, thì branch đó sẽ được đóng lại.
  • Team A đang làm việc trên một codeline được sinh ra từ mainline
  • Team A cũng đang song song thực hiện module Spike, module Spike này  có thể có lỗi vì vậy nếu thực hiện chung với branch A có thể gây cho Project A bi lỗi,  khiến team A không thể thực hiện song song được vì vậy tách ra thanh một branch Team A spike khác.
  • release 2.3 branch đã được close, RULES: Không để cho hai nhánh release cùng open, muốn release 2.4 phải close branch release 2.3
Với Tofu scale, ta dễ dàng thấy được rằng
  • Release 2.3 firmer hơn mainline.
  • Team A work softer hơn mainline
  • Team a spike softer hơn Team A work
Qua hình ảnh bên trên ta thấy rằng:
  • Bất kỳ khi nào có thay đổi trên realease codeline, những thay đổi này nên lập tức được merge down (Flow down ) to baseline, tất cả nên được merge xuống mainline
    • Example: khi một bug được fix tại R2.4.2. Nó nên được merge down to R2.4, và sau đó merge từ R2.4 xuống mainline.
  • Release codeline không bao giờ được nhận thay đổi từ baseline.
    • Example: Khi một new code được check tới mainline (từ nhánh dev copy up (flow up) lên), nó không nên được truyền tới R2.3, và R2.4
  • Mọi thay đổi trên baseline nên nhanh chóng được merge down xuống development codeline.
    • Example: Mọi thay đổi từ codeline nên được nhanh chóng merge down xuống Tearm A, Team B, khi Team A merge down xong thông báo với A spike, Merge down từ Team A xuống A spike.
  • Chỉ copy up từ development codeline  lên baseline khi chắc chắn nó đã stable points.
    • Example: Team B copy up to mainline khi đã hoàn thành và qua test.
    • A spike chỉ copy up lên Team A khi đã finished và tested.
Branch owner làm gì?
  • Mỗi một branch nên có một người là owner chịu trách nhiệm về branch đó
  • Quyết định xem có nên tách một codeline từ branch này hay không.
  • Thông báo tới tất cả các codeline khác sinh ra từ branch update khi baseline thay đổi
  • Mọi người làm việc trên codeline, phải biết baseline owner của mình để merge code khi baseline owner báo baseline thay đổi.
Khi nào tôi nên add new branch ?
  • Khi phát triển những new features, nên check code từ trunk, add a new branch và develop trên đó.
  • Khi finish một task, nhưng task này chưa được test, cần một nơi để có thể check code, nơi mọi người trong cùng team có thể làm việc với code.
Khi nào nên merge code từ baseline ?
  • Nên thường xuyên merge code từ baseline, càng sớm càng tốt, hàng ngày, tìm và giải quyết các conflict xảy ra lúc đó.
  • Khi baseline owner thông báo có thay đổi trên baseline.
Resolve conflicts trên branch kém ổn định nhất
  • Nếu bạn bị confict code , bạn nên resolve nó ngay lập tức, nếu code confict được check từ một nhánh khác, nên tìm branch owner của nhánh đó giúp resolve conflict.
Khi nào tôi nên Merge code với Trunk ?
  • Nên merge code thường xuyên với Trunk, khi bạn kết thúc một phần và đã test kỹ, nên merge nó với trunk, tránh để tới cuối cùng mới merge, điều này khiến bài toán merge trở nên bớt phúc tạp và mất thời gian hơn.
Release Branches
Sau khi kết thúc sprint 1 và released version 1.0.0, và đã thực hiện xong một số phần của sprint 2,qua quá trình test phát hiện một số bug của release 1.0.0. Tôi phải làm gì ?
  • Tạo một release branch gọi là release 1.0, từ nhánh release 1.0.0
  • Fixbug trên nhánh này
  • Merge từ nhánh release xuông trunk ngay khi fix xong, và release ban 1.0.1
Làm thế nào để release code lên Trunk ?
Hiện tại bạn đã finish code tại branch Team B , tested  tại development branch và muốn merge với Trunk.
  1. Lock nhánh release 2.3 mới nhất trên Release branch để không ai commit tại thời điểm này.
  2. Check out code từ trunk về local.
  3. Merge code từ nhánh release 2.3  newest trên release branches về trunk tại local, nếu có conflict edit ngay tại đó.
  4. Merge code từ trunk về nhánh dev Team B của minh trên local, và edit ngay conflict , commit code lên nhánh dev Team B
  5. Merge code từ dev branches Team B tmới commit rên server  về trunk trên local, edit conflict nếu có.
  6. Copy up từ Trunk local lên trunk server
  7. Add branches  release 2.4 trên nhánh release branches bằng cách check code trên trunk mới lên.

Trunk: tương ứng với mainline trong Mainline model. Có thể release phiên bản caravat mới bất kỳ lúc nào.
branches/dev : Development  Branches: nhánh phát triển chức năng mới, tách biệt
branches/release : Release Branches: Dùng để release, hay fixbug.
Tạo một brand mới như thế nào
  1. Chọn Tag/branch => Add Branch , hay dùng phím tắt Ctrl + B
  2. Trong màn hình Add Branch
    • Name: Tên của branch sắp tạo ra, phải tuân theo quy tắc
      • Nếu nằm trên nhánh Dev phải: dev/New Name Branch.
      • Nếu nằm trên nhánh Releases phải: releases/new name branch.
      • Có thể thấy các nhánh hiện có trong Repository bằng cánh nhấn vào button “…” => ra màn hình Tag Browser.
  3. Source: Tạo branch mới với source lấy từ đâu
    • Working Copy: Lấy code từ một thư mục nằm dưới local.
    • Repository Revision: Lấy code từ một nhánh khác( thông thường từ Trunk ) chép qua nhánh đang tạo.
  4. Check out code từ nhánh đang tạo về, và sử dụng để develop.
Quy tắc đặt tên version  m.m.b.b (major.minor.bugfix.builds) trong caravat
  • Major: Tăng khi có sự thay đổi lớn trong hệ thống, như core, hay khi có một tính năng lớn, quan trọng được add thêm vào hệ thống
  • Miner: thay đổi theo tháng, hay thêm các tinh năng mới, hay fix những bug lớn và quan trọng
  • Bugfix: khi fix xong một đợt bug
  • Builds: chỉ số bản build
Example: 1.12.2.1,
Project layout phải là nốt lá
Tất cả các project layout đều phải là nôt lá, không có project nào nằm trong nó và đều chung root là “code”. Điều này giảm tối đa chi phí của bài toán merge, SVN sẽ merge đúng hơn khi hai file nằm chung một root.
Khi có project a1 là child của project a, tạo branches thế nào là đúng?
Khi có một project a1 là con của project a, ta nên tạo branch ngang hàng project a1 với project a trong repository Layout
Example: ta sẽ tạo branches/dev/a1/codecùng cấp với branches/dev/a/code
References: