Interesting Commics

I Can't Stop Thinking!

http://www.scottmccloud.com/comics/icst/index.html

ICST #1: Intro to ICST and "The HTML Blues."
31 Panels, 205K (5.6 feet long at 72 ppi)

ICST #2: "The 99.9% Solution" - Diversity Online.
28 Panels, 177K (7.4 ft.)

ICST #3: "10 Suggestions for First-Time WebComics Artists"
40 Panels, 238K (9.2 ft.)

ICST #4: "Follow that Trail!"
31 Panels, 412K (11.3 ft.)

ICST #5: "Coins of the Realm" Part One.
49 Panels, 505K (13.3 ft.)

ICST #6: "Coins of the Realm" Part Two.
64 Panels, 677K (14.0 ft.)

Bảng trắc nghiệm tình cảm phụ nữ

Những chiếc ô khác màu nhau tượng trưng cho những tính cách khác nhau. Vì thế, bạn hỏi cô gái: "Đang đi trên đường, nếu trời mưa, em sẽ mua ô màu gì?" Có tám lựa chọn cho cô gái: 1. màu đỏ; 2. màu cam; 3. màu vàng; 4. xanh lá cây; 5. xanh da trời; 6. đỏ tía; 7. màu trắng; 8. màu đen. Căn cứ theo đáp án tùy chọn, ta có thể biết loại hình tính cách của cô gái. Đó là 1. núi lửa; 2. nắng chiếu; 3. yêu kiều; 4. tự nhiên; 5. trí tuệ; 6. cao quý; 7. băng tuyết; 8. đêm tối.

 

Loại hình núi lửa:

Cô gái giống như đóa hồng rực rỡ, trái tim dào dạt yêu đương. Cô ta nhiệt tình, hào phóng, sống cuộc đời đầy náo nhiệt, đầy kích thích. Cô ta khiến bạn hào hứng, muốn cùng cô ta tới chân trời góc bể. Cô ta rất dễ xúc động, tiêu tiền như rác và cũng khát tiền như nước để thỏa mãn thói phù phiếm. Cô ta có thể khiến cuộc sống của bạn đầy màu sắc nhưng bạn cũng phải có đủ sức lực và tiền tài. Cách tốt nhất để chinh phục cô ta là: Đưa cô ta vào rừng săn, hai người sẽ lần theo dấu vết loài ác thú, thậm chí đánh nhau với ác thú rồi bắt nó. Khi bạn và cô ta nâng cốc rượu thắng lợi, bạn thể thốt tiếng lòng với cô ta: "Hãy để anh như mặt trời quay quanh em, chiếu ánh sáng tự do rực rỡ! "

Loại hình nắng chiếu:

Cô gái thích màu cam, đó là màu nắng, không kích thích mắt như màu đỏ, tràn đầy tình yêu thương hiền hòa. Cô ta chung thủy, tận tình chăm sóc gia đình, sống chung với cô ta sẽ có cảm giác ấm áp như sưởi nắng. Không nóng bỏng như cô gái chọn màu đỏ, tình cảm của cô ẩn chứa bên trong và chỉ bộc lộ với người mình yêu thương. Bản tính tiết kiệm, có hơi kỹ tính, nhưng trong gia đình cô ta là người khéo léo. Trên khuôn mặt cô luôn tươi thắm nụ cười. Muốn chinh phục cô ta, bạn phải học cách tiết kiệm và chăm lo cho gia đình giống cô ta. Khi tặng cô ta đóa hồng, bạn hãy nói: "Vì sắc đẹp của em, anh nguyện làm giọt sương trên những cánh hoa. "

Loại hình yêu kiều:

Cô gái thích màu vàng, đó là màu của cảm tính, nó giống như mầm cỏ đầu tiên nhú lên trong mùa xuân. Cô ta có thân hình khả ái, nụ cười rạng rỡ và tính cách nghịch ngợm. Lúc bạn ngủ, cô ta có thể nhẹ nhàng ngoáy mũi bạn; lúc bạn cáu giận, nụ cười không có gì đáng yêu hơn của cô ta sẽ khiến cơn giận của bạn tiêu tan. Tình cảm của cô yếu ớt, tính ỷ lại cao, cô ta rất cần một người che chở. Muốn chinh phục cô ta, gặp khi cô ta thất vọng hay phải chịu biến cố, hãy thương hoa tiếc ngọc mà ôm cô ta vào lòng, để cho cô khóc bên ngực bạn.

Loại hình tự nhiên:

Xanh lá cây là màu xanh của tự nhiên, nó khiến người ta thư thái, dễ chịu. Cũng như vậy, cô gái thích màu xanh lá cây là người bình tĩnh, lý trí. Nếu bạn gặp vấn đề khó giải quyết, cô ta có thể cho những ý kiến xác đáng. Cô ta giống như một khu vườn trí tuệ, mọi người đều muốn tới đó cho thông thoáng đầu óc. Có lúc ánh mắt lạnh lùng lý trí của cô ta khiến người ta phải lúng túng, người không hiểu cô ta thì ngại ngùng bởi sự thanh cao, cô độc của cô. Thực ra cô là người có tâm hồn, thích tri thức và một chút lập dị. Nếu muốn kết bạn, bạn phải chứng tỏ trí tuệ và sự điềm tĩnh. Nếu muốn chinh phục, bạn đừng ngại mời cô ta đi trượt băng, bơi lội để thay đổi không khí, giảm bớt mệt mỏi của đầu óc. Trong khi trượt băng, bạn có thể cũng ngã với cô ta, tay nắm tay từ đó cho tới lúc thành hôn.

Loại hình trí tuệ:

Cô gái thích ô màu xanh da trời rất hiểu lòng người, tính cách ngoài hòa nhã, trong cương quyết, mong tìm được một người giống mình nhưng thông minh hơn, người có thể kể cho cô ta những tin tức li kỳ mới nhất. Lúc qua đường, cô ta đặt bàn tay mềm mại vào lòng bàn tay bạn trai, khiến bạn trai tự hào mình là người che trở. Bên trong vẻ ngoài mềm yếu đó của cô ta là lòng tự tin, kiên nhẫn. Gặp cơn sóng gió, cô ta quyết không nép sau lưng bạn mà cùng kề vai chèo chống. Tuy nhiên, cô không dung thứ bạn bè hay người thân phản bội. Muốn chinh phục cô ta, bạn phải chứng tỏ sự thủy chung của mình.

Loại hình cao quý:

Cô gái thích màu đỏ tía có sự thâm u của mắt mèo và sự biến ảo của loại hồ li. Cô ta thường xuất hiện với những thương gia lừng danh trong những đêm vũ hội ồn ào. Cô ta theo đuổi cuộc sống sang trọng, hy vọng tìm được người chồng là nhà kinh doanh để cùng cô ta trọn đời lãng mạn. Nếu muốn yêu cô ta, bạn không những phải có nhiều tiền mà còn cần phong độ. Đêm sinh nhật cô ta, bạn có thể tổ chức tại một quán bar sang trọng nhất, bày tiệc thật xa hoa. Khi bạn và cô ta vừa kết thúc bài khiêu vũ thanh tao, trong tiếng vỗ tay của bạn bè, bạn có thể quỳ trước mặt cô ta, đọc mấy câu thơ cổ điển ưu nhã, xưng tụng cô ta như nữ thần.

Loại hình băng tuyết:

Màu trắng khiến người ta nghĩ tới sự thuần khiết và mĩ lệ. Cô gái thích màu trắng là người có đôi mắt trong trẻo, lý tưởng lãng mạn và trái tim không nhuốm bụi trần. Cô ta trong trắng như băng tuyết, cũng mong manh như tuyết băng, cũng có lúc nhỏ nhen, chợt hờn dỗi, có lẽ do cuộc sống của cô đã vương chút màu sắc khác, nhưng hiện giờ vẫn là màu trắng. Muốn chiếm trái tim cô gái, bạn không những cần nhẫn nại mà còn cần kiểm soát từng hành động, lời nói của mình. Lần thứ nhất hôn cô ta, bạn có thể làm cô ta chán ghét nhưng nếu bạn bày tỏ sự hối hạn, bạn vẫn còn cơ hội tiếp tục hôn cô ta. Tình yêu của bạn và cô ta sẽ phảng phất như câu chuyện cổ tích.

Loại hình đêm tối:

Màu đen là màu cực đoan. Một số cô gái thích mặc áo đen thường la cà trong các bar, miệng nhả khói, mắt xa xăm như sao sớm. Trong mắt của nhiều chàng trai, những cô gái mặc áo đen có gì bí hiểm như bóng đêm. Tuy nhiên, cô gái chọn ô đen thường không hòa hợp với bố, cô ta mong muốn có một người đàn ông bao dung che trở mình trọn đời. Cô ta có chút ưu uất, chút mẫn cảm, một khi có được cô ta, bạn sẽ như được thưởng thức men nồng của rượu thơm.

(Trích từ Tam @ Quốc)

Brook's law

Adding manpower to a late software project makes it later." by Fred Brooks, author of "The Mythical Man-Month."

 

The extra human communications required to add another member to a programming team is considerably more than anyone ever expects. It of course depends on the experience and sophistication of the programmers involved and the quality of the documentation, which is often sparse.

 

When a new person joins a running team he will initially be of little value because he doesn’t know the system nor the team. Indeed he can slow things down because he drains time from other people as they teach him about these things. The more people you add, the bigger this slow down effect is. Add enough people and the project can come to a big crunching halt. This is the origin for Brook’s Law ("adding people to a late project just makes it later").

Bùi Giáng - Nhà thơ cuối cùng của thế kỷ 20

Bùi Giáng xuất hiện trong nền thơ ca VN như một hiện tượng kỳ lạ và độc đáo. Từ thuở sinh tiền cho đến khi ông nằm xuống, người ta đã nói, đã viết về ông quá
nhiều.
“Mòn con mắt sầu đưa từ cổ độ
Bụi thu mờ ai phủi với hai tay”

"Em về mấy thế kỷ sau
Ngó trăng cón thấy nguyên màu ấy không?
Ta đi gửi lại đôi dòng
Lá rơi có dội lại trong sương mù."
(Mưa nguồn)

"Bây giờ riêng đối diện tôi
Còn hai con mắt khóc người một con".

“Em nhớ hay không hồn hoa dại cỏ
Những ngậm ngùi đầu núi canh khuya
Vàng cao gót nai đầu buông hãi sợ
Gió cây rung trút lá mộng tan lìa"...


(lượm lặt trên mạng…)

Một số links trên mạng:
. http://vnthuquan.net/truyen/truyen.aspx?tid=2qtqv3m3237n2n0n0nvn31n343tq83a3q3m3237nvn
. http://vnthuquan.net/truyen/truyen.aspx?tid=2qtqv3m3237ntn0n0nqn31n343tq83a3q3m3237nvn
. http://zdfree.free.fr/diendan/HAbuigiang/bz1.html
. http://www.evan.com.vn/News/phe-binh/phe-binh/2005/10/3B9ACF70/
. http://www.evan.com.vn/News/doi-song-van-nghe/chuyen-lang-van/2006/03/3B9ACC8E/
. http://www.evan.com.vn/News/Tin-tuc/trong-nuoc/2006/09/3B9AD2B3/

Tạo sitemap cho một Website

Nhận được một vài câu hỏi của một vài bạn về việc tạo sitemap cho một website bất kỳ, tôi xin trả lời vắn tắt như sau (về chi tiết, các bạn nên tham khảo tại Google sitemaps homepage: https://www.google.com/webmasters/sitemaps).

Về cơ bản, ta có thể tạo sitemap cho website theo hai cách:

-          Cách 1: Sử dụng sitemap generator: https://www.google.com/webmasters/sitemaps/docs/
en/sitemap-generator.html

-          Cách 2: Tự viết bằng tay dựa theo Sitemap protocol được định nghĩa tại: https://www.google.com/webmasters/sitemaps/docs/
en/protocol.html

 

Với cách 1, ta dùng công cụ của Google được viết bằng Pyphon script, do đo bạn phải có khả năng chạy được Pyphon trên Web server. Đồng thời, nếu nội dung website thay đổi thường xuyên, bạn cần phải có cơ chế định thời (hoặc làm bằng tay định kỳ) để tạo ra file sitemap với nội dung mới nhất.

Thay vì sử dụng generator của Google bạn cũng có thể sử dụng các third-party tools khác tham khảo tại: http://code.google.com/sm_thirdparty.html (tại đây có liệt kê một số online tool sử dụng khá đơn giản)

Cách 2, chỉ thích hợp cho website với thông tin tĩnh (và tất nhiên chỉ khi bạn không thể sử dụng cách 1). Tốt hơn hết là bạn nên tìm một file sitemap của một website nào đó và sửa lại phù hợp với webste của mình, hay sử dụng các online tools để sinh ra kết quả sau đó kết hợp lại thành file sitemap cho website của mình. Chú ý rằng với sitemap được tạo bằng tay, bạn nên validate trước khi submit (xem https://www.google.com/webmasters/sitemaps/docs/
en/protocol.html#sitemapValidation)

First article on PC-World VN

My post “Làm thể nào để Google đánh chỉ mục cho blog của bạn” has printed in PC World VietNam, series A 10/2006. Here is the online link: http://www.pcworld.com.vn/pcworld/magazine_a.asp?
t=mzdetail&atcl_id=5f5e5d5f5f565d

However, this is not my interesting one. Hope that next time, write something more valuable.

Patterns are signs of weakness in programming languages

“Patterns are signs of weakness in programming languages”

 

This is a conclusion of Mark Dominus on his blog, an interesting and thought-provoking post (very worth reading).  Anyway, I don’t agree with his idea. Though we can create a very complicated programming language, there will always be something left and these things are likely to be patterns.  

Tùy cơ ứng biến

Một hôm ra triều, quốc vương A-cơ-ba hỏi Pi-ơ-ba: “Tại sao trên lòng bàn tay ta không mọc lông?”

Pi-ơ-ba để cười nhạo quốc vương bèn trả lời: “Vì ngài thường dùng hai tay bố thí cho người nghèo và học giả bà la môn, do cọ xát mà lòng bàn tay không mọc lông”.

Nghe lời đáp ca ngợi mình, A-cơ-ba trong bụng thấy vui. Nhưng ông ta lập tức hiểu ra đó là cười nhạo mình, có điều ông ta không nói ra, và ông ta quyết tìm cách làm nhục Pi-ơ-ba. Khi đã nghĩ xong mưu kế, ông ta hỏi Pi-ơ-ba:

“Lòng bàn tay ngươi sao không mọc lông?”

Pi-ơ-ba nói: “Vẫn thường nhận của bố thí, như vậy, cọ xát mà không mọc lông.”

Quốc vương lại hỏi: “Tại sao người trong cung ta, lòng bàn tay ai cũng không mọc lông?”

Pi-ơ-ba nói: “Đáp án thật rõ ràng, khi ngài bố thí cho tôi hoặc những người khác thì những con bọ đáng thương trong cung ngưỡng mộ mà cứ xoa tay, kết quả của việc xoa tay là lòng bàn tay họ cũng không mọc lông.”

 

Pi-ơ-ba  đứng trước đòn tấn công liên tục được sắp đặt công phu của quốc vương đã có thể đưa ra đối sách ứng biến nhanh chóng, kín kẽ, chứng tỏ một khả năng tùy cơ ứng biến khác thường.

 

Behind Closed Doors - Secrets of Great Management

Don’t waste your time reading this book: Behind Closed Doors - Secrets of Great Management. Reading these following notes and the Appendix is good enough. To me, it’s not an interesting book in management. “Peopleware” or “The One Minute Manager” are the better.

 

1. Week One: Learning about the People

+ Great management is about leading and developing people and managing tasks.
+ You need to learn three things when you enter a new organization or job:
    • Who the people are—their strengths and interests—and what they are working on
    • The stated mission of the group and how the group provides value
    • How your group fits into the larger organization
--> one-on-one meeting, used open-ended questions
+ Walking Around and Listening (MBWAL) A half hour to walk around the department, even though had a “getting to know you” pizza lunch scheduled
+ Don’t offer help if you can’t deliver it
+ Multitasking: Wasting Mental Cycles
    • Working on two tasks (not projects or teams) can improve productivity because when a person is stuck on one task, they can switch to the other.
    • Productivity may increase when a person has two related tasks, but it plummets as the number of projects increases.
+ Gather Data about Current Work: Understand all the work that they do: project work, ad hoc work, periodic work, ongoing work, and management work

2. Week Two: Bringing Order to the Chaos

+ Redirect people to more important, focus on the funded work.
+ Create the Project Portfolio: Match the Work to the Goals
+ Categorize all the projects
+ Management isn’t for everyone:
    • If you find it’s not for you, or it’s not for you yet, it’s okay to step back into a technical role.
    • The best managers practice management and practice technical leadership, moving between both types of jobs before they decide to focus on one or the other.
+ Stepping Back from Management:
    • Do I want to control more of the technical decisions?
    • Am I more interested in fixing technical problems than people problems?
If you answer "yes" to both questions
+ If you think management might be for you, ask yourself:
    • Do I like working with people?
    • Do I like coaching and mentoring people?
    • Am I willing to learn how to provide feedback and have difficult conversations with people when I need to?
+ Matching the Roles with the People
+ Poor performance might be the result of insufficient skills. But it might be something else:
    • Performance also depends on the environment
    • Quality of management.
+ Hire the best:
    • Analyze the job
    • Source candidates  
    • Winnow the candidates  
    • Develop behavior description questions: Behavior description questions such as “Tell me about a time when. . . ” help candidates explain how  they’ve worked in the past rather than how they wish they work
    • Phone screen before in-person interviewing
    • Develop an audition
    • Interview candidates with an interview team
    • Involve as many people as possible when selecting new team members and team leaders
    • Listen to the interview team’s assessment
+ Plan to Integrate New Team Members
    • Create and use a checklist for new hires.
    • Spend time setting the context on the first day
    • Assign a buddy
    • Expect to re-form teams.
+ Big Visible Charts (BVCs): People know what to do and do it when managers use techniques that help people see the status of the work, planned, in progress, and completed.
+ Managing the Project Portfolio
    • Prioritize the work
    • Staff the most important work
    • Assign people to one project at a time
    • Plan to replan

3. Week Three: Build the team

+ How Is a Group Different from a Team?
It’s great to be a team, but not every workgroup needs to function as a team. The difference is in six characteristics.[5]
Teams:
    • are usually small—they have five to ten members.
    • are committed to a common purpose or goal.
    • have an agreed-upon approach to the work.
    • have complementary skills.
    • have interrelated or interdependent interim goals.
    • make commitments about tasks to each other.
+ Here’s the agenda for our first meeting:
    • Rumors, Gossip, News (5 minutes)
    • Issues of the day (the problem we’ll be working on this week)
    • Set our goals as a management team (50 minutes)
    • Action items from previous weeks (we won’t have any this first time)
+ Failure to Give Feedback: Costs More than Money
    Managers who fail to give feedback lose trust and productivity. When managers fail to give feedback, problems fester and resentment builds.
    • Loss of trust: Surprising a team member with a long list of performance complaints at a performance review isn’t helpful.
    • Loss of productivity: Most people want to do a good job.
    • Simmering resentment: People who work closely together know who is doing a good job and which team members are skating by.   
+ Provide Timely Feedback:
    People need information to know what they’re doing well and what they are doing that just isn’t working. Your feedback will help them tune their work
    • Provide feedback as close to the event as possible
    • Deliver feedback in private
    • Describe the behavior or result
    • Evaluations are different from feedback
    • Listen to what the other person has to say
    • Keep notes of feedback conversations
+ When Feedback Doesn’t Correct the Situation
    • Start with a verbal warning
    • Deliver a written warning
    • Implement a get-well plan: A get-well plan is a short period (four to five weeks) where the employee must show evidence that he is meeting acceptable standards.
    • Don’t underestimate the impact of poor performance

4. Week Four:  Managing Day by Day

+ Career Development: both the manager and the staffer are responsible
    • The manager initiates the career development in one-on-ones periodically. We recommend quarterly.
    • Both people verify the career development goals are still valid.
    • Both people monitor progress against goals.
    • The manager looks for opportunities to advance the team member’s career.
+ Create Individual Goals for Each Person
    Goals don’t have to address the entire year. In fact, it’s more effective to have a series of short-term goals
+ Coaching for Success
    • Coaching is a kind of helping: Coaching helps the other person see more options and choose from them.
    • Generate options: generate at least three reasonable options for solving any problem. Rather than offer options on a silver plate, collaboratively generate and discuss options with the employee.
    • Walk through implications
    • Develop an action plan: Options without actions don’t happen.
    • Follow up on progress during one-on-ones
    • Coaching goes only so far: When you find yourself coaching someone about the same issues over and over, decide whether the person
has the ability to learn from your coaching. The failure may be due to your coaching or the other person’s abilities. You may be missing an underlying issue. It’s also possible that the person is in the wrong job.
    -> If you believe someone needs coaching to be successful, and he or she isn’t interested, don’t coach. Move into corrective feedback and possibly a get-well plan.
+ Rule of Three: is a guideline for making better decisions
    • One alternative is a trap. There’s only one solution, and if it doesn’t work, you’re out of luck and out of options.
    • Two alternatives is a dilemma. Two alternatives is false choice: there’s only this or that.
    • Three alternatives provide a real choice. With three alternatives you can make a real choice
    Nothing is more dangerous than an idea if it's the only one you have. (Emil-Auguste Chartier, Propos sur la religion, 1938)
+ Learning to Influence
    • Emphasize mutual benefit: participate in your urgent project will benefit them, not just you
    • Appeal to greater goals: Enlist support by emphasizing the greater good.
    • Horse trade: Maybe you are in a position to help another manager with an issue she is facing. You may have machines, lab time, skills, or some other resource that she needs. Offer a straight-up trade.
    • Reciprocate: Next time around, you may be the one who has resources to help someone else.

5. Week Five:  Discovering Lurking Problems

+ Sustainable Pace
    • They’re burnt-out people: They’re on a short fuse, and they make stupid mistakes. Sometimes their decisions are not just suspect, they appear downright wrong.
    • Working at a sustainable pace of 40 hours a week isn’t molly-coddling. It’s a smart business decision, and it’s your
job to make it happen.
+ Solving Problems as a Management Team
    • Engage group creativity
    • Describe the problem
    • Collect data
    • Write it down
    • Brainstorm possible solutions
    • Document the decision
    • Look for areas where you can act: Even when a full solution involves areas outside your control, don’t rely on others to start working on the issue
    • Develop an action plan: People don’t implement solutions that don’t have action plans.

6. Week Six:   Building Capability
+ You have an obligation to provide feedback—it’s information your employees need to be successful in their jobs.
Coaching is a choice; sometimes yours, and sometimes the employee’s.
+ You always have the option not to coach. You can choose to give your team member feedback (information about the past), without providing advice on options for future behavior.
+ Once you have four people or more in your group, you can’t perform technical work and still be a great manager.
+ Learning to Delegate
    • Managers need to focus on managerial work.
    • Decide what you can delegate: decide which tasks are strategic and which are tactical, tactical work is ripe for delegation.
    • Understand who has the skills to do the work.
    • Consider delegating an investment
    • Consider the specific results you want: Communicate the task parameters including time and quality to the person to whom you’re delegating. + Focus on the results rather than methods. How-to direction is micromanagement.
    • Decide how the two of you will monitor progress. Establish periodic checks on progress.
+ Notice and Appreciate Changes and Contributions
    • Notice people doing something right: Look for opportunities to comment on what people are doing well.
    • Appreciate, don’t thank.
    • Choose your venue: When you appreciate someone, decide whether you will appreciate privately or publicly.
+ How Many People Can You Manage?
    • We strongly recommend managers avoid technical work that’s on the critical path—it’s a nowin situation.
+ Building Self-awareness:
    • Managers need to be aware of their own emotional state and how their words and behavior affect other people.
    • It’s perfectly normal to become frustrated or upset with issues at work. It’s not okay to yell, scream, swear, rant, rave, or threaten (despite some high-profile examples of this behavior).
    • Even facial expressions can have unintended consequences.
    • We don’t advocate keeping a poker face at all times. People expect managers to have emotions. But let the messenger
know you’re upset about the news, not at them.
-> When managers are self-aware, they can respond to events rather than react in emotional outbursts.
+ Manage Yourself
    • Physical displays, especially around subordinates, scare people: people not to bring you any news, especially bad news.
    • Awareness is the first step
    • Notice triggers
    • Choose your response
    • Manage your emotions: People who cannot or will not manage themselves should not manage other people.[
    • Obtain feedback about how you appear to others.  
+ Develop the People in Your Group Every Week
Great managers help each person develop his or her career. Supporting people to build their careers, lets them know you care about them, not just what they produce.
    • Understand what people want. Ask people about their career goals in one-on-ones. Not everyone wants to progress up the hierarchical ladder.
    • Create an action plan and follow it
    • Look for opportunities to practice new skills
    • Don’t hold people back: Sometimes career development means helping someone find a new position. Holding someone back to make your job easier backfires in the long term.
    • Create a transition plan.
    • Separate career development from evaluation: Career development benefits the individual and the organization. But it shouldn’t be part of an individual’s yearly evaluation or rating.
    • Career development is different from remedial development.

7. Week Seven:  Dealing with Corporate Realities without Rolling Over

+ Digging Yourself into a Hole
Sometimes we make our own problems. We don’t want to ruffle the bosses’ feathers, and we shrink from saying “no” directly. When you hear yourself saying these words, you know you are digging yourself a hole that will be hard to climb out of:
    • We’ll try.
    • We should be able to do that.
    • Let’s hope for the best.
    • We’ll just do. . . .
    • We’ll have to make. . . .
    • We’ll multitask.
    • We’ll find resources somewhere.
--> I will work with my team to see what we can achieve. DO NOT promise anything before talking with your team
+ Manage Your Boss, Stand Up for Your Team
    • Understand the other person’s context: don’t blame the other person (in this case, a senior manager) for wanting what they want.
    • Avoid premature decisions: be firm, stating that you can’t commit until you discuss what is possible with your team.
+ Leading Your Team Through A Change In Priorities
    • Replace rumors with facts
    • Set your team’s expectations about how you will respond to the change
    • Replan with your team

Notes:
+ Make goals SMART: Specific, Measurable, Attainable, Relevant, and Time-bound.
    • Here’s an example of a goal that isn’t SMART: “Improve product quality.” 
    • Here’s a SMART version of that goal: “Decrease the total number of released defects in the next release by 10%.” 

Một vài ứng dụng AJAX ấn tượng

Zoho Office Suite & Productivity Tools:  http://www.zoho.com/

Writely: http://www.writely.com/

Google Tools (map, mail, spreadsheets, translate, etc...):  http://maps.google.com/

Windows Live™ Spaces: http://spaces.live.com/  

Flickr: http://www.flickr.com

Netvibes (personalized pages): http://www.netvibes.com/

Webnote: http://www.aypwip.org/webnote/

…

Quality vs. Schedule

Hẳn ai làm trong ngành phần mềm đều biết đến áp lực về thời gian và chất lượng: chất lượng sản phẩm phải tốt nhất, nhưng thời gian hoàn thành thì luôn bị rút ngắn.

Mỗi lần nhắc đến vấn đề này, tôi lại nhớ đến một nhận định của cô bạn làm trong ngành phần mềm khá lâu rồi: 

            “Thời gian và chất lượng sản phẩm chẳng khác gì tiền và giỏ hàng đi chợ của một cô dâu mới về nhà chồng”.

 

Làm thế nào để vừa lòng nhà chồng khi số tiền đi chợ thì ít nhưng bữa cơm nhất định phải tươm tất. Tất nhiên là chẳng có cách nào khác ngoài việc bỏ thêm tiền riêng của cô ấy vào tiền đi chợ. Tôi lấy làm ngạc nhiên khi nghe cô ta so sánh như vậy: tôi luôn nghĩ rằng cái vấn đề “mẹ chồng nàng dâu” ấy đã “đi vào dĩ vãng” từ lâu lắm rồi chứ. Vì không đồng ý, tôi đã làm một cuộc khảo sát nhỏ với tất cả những bạn bè quen biết (và tất nhiên cả những người quen của người quen nữa…). Và tôi đã đúng: Các nàng dâu bây giờ không hề chịu áp lực về tiền bạc và chất lượng bữa ăn. Họ hoàn toàn tự quyết định việc chi tiêu cho bữa ăn như thế nào là hợp lý nhất.

Khi phát hiện ra phán đoán ban đầu của mình là đúng, thay vì thích thú tôi lại cảm thấy phiền não vì lại xuất hiện một câu hỏi khác: Tại sao cái quan điểm cổ hủ ấy đã bị xã hội đào thải rồi, nay lại sống dậy và len lỏi vào trong tư tưởng của hầu hết các nhà quản lý dự án hiện nay?

Cách tốt nhất để khiến người khác làm việc hiệu quả là luôn đặt họ dưới áp lực về thời gian hoàn thành công việc. 

Chính cái tư tưởng này đặt một áp lực lớn lên các lập trình viên. Để có được chất lượng sản phẩm như mong đợi, họ buộc phải tăng thời gian làm việc: đó là những lúc làm việc overtime, cuối tuần hay đem cả công việc về nhà làm…

 

Vậy, hệ lụy của nó là gì?

-          Chất lượng sản phẩm không đạt được như mong đợi, vì rằng người bị đặt dưới áp lực thời gian không hề làm việc tốt hơn, họ chỉ làm việc nhanh hơn.

-          Niềm yêu thích và sự thỏa mãn đối với công việc giảm đi dần, và kết quả là sự ra đi của người nhân viên đó.

 

Trong một buổi ăn tối cùng bạn bè thuở còn học đại học, sau một lát truyện phím chúng tôi lại qua ra bàn chuyện công việc. Tôi mang nhận định này ra thảo luận. Cũng may trong buổi tối đó không chỉ có dân IT, thành phần khá đa dạng: hai người là quản lý dự án, ba lập trình viên và một vài người làm kinh doanh.

-          “Hừm, nếu không có áp lực thời gian thì làm sao quản lý được những tay lười biếng chứ. Tao đã  từng quản lý những nhân viên mà lúc nào cũng trễ nải dù công việc là khó hay dễ“, một tay quản lý dự án phản đối.

-          Và hắn lập tức có ủng hộ, “Deadline của dự án là thứ mà không thể không đạt được, do đó đôi khi cần phải tạo cả những áp lực thời gian giả tạo lên nhân viên của mình. Nghệ thuật quản lý là gì? Đó là kicking ass”, tay quản lý dự án còn lại nói.

 

Lập tức, có nhiều ý kiến phản đối:

-           “Áp lực thời gian ư, nó hoàn toàn không tốt. Tôi đã từng phải viết ra những đoạn mã vội vàng để kịp thời gian, và tất nhiên chúng tiềm tàng những lỗi. Còn overtime ư, nó chẳng giúp ích được bao nhiêu cả”, “Những đoạn mã viết dưới áp lực về thời gian không thể là đoạn mã tốt”, hắn kết luận.

-          “Rõ ràng như vậy! Không những thế, khi viết tiếp các thiết kế hay những đoạn mã tồi, tôi mất đi hoàn toàn cảm giác thú vị trong công việc”.

 

Sau một hồi chăm chú lắng nghe, với các luận cứ của cả hai bên, một trong những người làm kinh doanh mới lên tiếng nhằm dung hòa hai quan điểm trái ngược trên (có lẽ là hắn muốn đổi đề tài nhàm chán này):

-          “Quyết định có đặt áp lực thời gian lên một công việc cũng giống như việc bạn quyết định có phạt con trẻ khi chúng nghịch ngợm vậy. Nếu lúc nào cũng áp dụng, chắc chắn sẽ bị phản tác dụng”.

 

Tôi thật sự bị lạc vào mê hồn trận của những quan điểm trái ngược nhau, nhưng có lẽ đây là một nhận định đúng.  Nếu không thì sao người ta lại cho rằng quản lý là một nghệ thuật, chứ không phải là một ngành khoa học.

 

-          “Này! Thế các dự án phần mềm lúc nào cũng phải có deadline cố định sao? Các lập trình viên không thể tham gia vào việc quyết định thời hạn ra release của sản phẩm à?”, một cô bạn học kinh tế hỏi.

Một câu hỏi thật hay và gợi ta nhiều suy nghĩ. Sau này, tôi được biết một số công ty ở Nhật (Hitachi software, Fujitsu) đã thành công khi cho phép nhóm phát triển dự án từ chối việc ra release sản phẩm khi nhóm này cho rằng sản phẩm chưa đạt được chất lượng mong muốn.

 

Vậy, ta thử tìm hiểu xem nếu dự án không có áp lực về thời gian thì có được những lợi điểm gì?

 

Thời gian hoàn thành dự án:

Trước tiên, chúng ta hãy khảo sát bảng số liệu dưới đây. Jeffẻy-Lawrence đã khảo sát productivity của 24 dự án phần mềm dưới các áp lực thời gian khác nhau:

 

Productivity by Estimation Approach

(Full Result)

EFFORT ESTIMATE           AVERAGE               NUMBER OF

PREPARED BY                 PRODUCTIVITY        PROJECTS

-----------------------------------------------------------------------------------------------

Programmer alone                      8.0                                19

Supervisor alone                        6.6                                23

Programmer & supervisor            7.8                                16

Systems analyst                        9.5                                21

(No estimate)                             12.0                              24

(bảng số liệu này được lấy từ Peopleware - Productive Projects and Teams)

 

Kết quả khảo sát cho ta thấy rằng dự án không có bất kì một áp lực nào về thời gian lại có productivity cao nhất.

Hỡi các nhà quản lý dự án, định luật Parkinson không đúng với các lập trình viên làm việc trí óc đâu!

 

Nhóm phát triển dự án:

Khi không chịu áp lực về thời gian, họ mạnh dạn áp dụng những kỹ thuật mới, dám loại bỏ đi những thiết kế tồi. Và kết quả của nó là những bài học, những kinh nghiệm quý báu mà chẳng có sách vở nào giúp bạn được. Kiến thức và kinh nghiệm làm việc của cả nhóm tăng lên sau mỗi dự án, không những thế niềm yêu thích và cảm giác thú vị trong công việc cũng tăng theo.

Ngược lại, chuyện gì sẽ xảy ra trong mộ môi trường luôn có áp lực về thời gian. Nhân viên của bạn rất sợ mắc lỗi, họ luôn hướng mọi giải pháp theo những gì mà họ đã làm hoặc ít nhất là đã biết. Chẳng có một ý tưởng mới, táo bạo gì trong công việc. Một môi trường như vậy sẽ làm thui chột tài năng và giết chết đi mọi cảm hứng.

Tôi có người bạn gặp phải một vấn đề nan giải: nhân viên của anh ấy cứ lần lượt rời khỏi nhóm mặc dù anh ta đã có chính sách đãi ngộ thích đáng. Sau thời gian tìm hiểu, anh ta nhận ra rằng nguyên nhân chính là vì tính chất công việc luôn đặt dưới áp lực thời gian, làm cho các nhân viên đó không dám áp dụng những cái mới, và dần dần họ không còn cảm giác thú vị với dự án nữa, việc ra đi là một sự tất yếu. Và hẳn ai đã làm quản lý đều biết rằng để tìm và đào tạo được một nhân viên mới không hề đơn giản tí nào.

 

Hỡi các nhà quản lý dự án, hãy sáng suốt lên!

 Nếu không thì bạn thắng trong những trận đánh nhỏ, nhưng lại thất bại trong cả cuộc chiến.

 

Chất lượng sản phẩm:

Tôi vẫn còn nhớ cái cảm giác lần đầu tiên học lập trình, cái cảm giác vui sướng khi hoàn thành một chương trình; hay một niềm tự hào khi tìm ra được một thiết kế hay, một đoạn mã đơn giản hơn khi ngồi refactoring các đoạn mã. Cái cảm giác ấy hiện nay vẫn còn, và tôi cũng tin chắc rằng không chỉ có mình tôi có cảm giác đó. Đấy là sự thú vị của nghề lập trình.

Vì vậy, tôi hoàn toàn đồng ý với nhận đinh sau:

Một developer luôn gắn lòng tự trọng bản thân vào chất lượng sản phẩm họ sáng tạo ra.

Vì thế mà trong quá trình phát triển, các developer luôn định hình ra các tiêu chí về chất lượng sản phẩm riêng của họ, các tiêu chí này luôn cao hơn so với quan niệm của nhà quản lý cũng như sự chấp nhận của thị trường.

Trong khi đó các nhà quản lý lại không như vậy, dưới áp lực cần phải bàn giao sản phẩm đúng hạn, họ chỉ xem chất lượng là một thuộc tính của sản phẩm, nó thay đổi tùy vào đòi hỏi của thị trường. Chất lượng sản phẩm chẳng khác gì một nồi canh, khi có nhiều người dùng thì đổ thêm nước vào. Đi làm dự án nhiều, hẳn bạn thường phải nghe những lời phàn nàn thế này:

-          “Tại sao cứ phải luôn cải tiến mã lệnh vậy?”

-          “Thiết kế như vậy là tốt rồi, chúng ta không có nhiều thời gian”.

-          “Vấn đề này không cần tốn nhiều thời gian như vậy”.

-          “Tôi không cần biết nó có rắc rối gì, các anh phải có được sản phẩm vào tháng tư”

-          …

Các nhận định này vô hình chung đã áp đặt một áp lực về thời gian lên nhóm phát triển sản phẩm, và tất nhiên họ buộc phải hi sinh chất lượng để lấy thời gian, cái mà không một lập trình viên nào cảm thấy hài lòng cả.

Các nhà quản lý dự án, xin chú ý:

Tiêu chí chất lượng sản phẩm mà các developers đưa ra luôn cao hơn mong muốn của bạn.

Hãy cho họ một cơ hội quyết định chúng.

 

Ai là người ước lượng thời gian hoàn thành sản phẩm?

Không tạo áp lực thời gian hoàn toàn không có nghĩ là để dự án “trôi nổi” vô định, kết thúc khi nào nó kết thúc. Mọi công việc đều phải được ước lượng thời gian hoàn thành, và không ai ước lượng tốt hơn chính bản thân những người thực hiện nó.

-          “Hừm! Nhân viên của tao luôn ước lượng lớn hơn thời gian cần thiết nhiều”. Tôi nhận ngay một lời phản đối khi đưa ra nhận định trên.

Nhưng lần này tôi nghĩ hắn đúng, rõ ràng ước lượng là công việc đòi hỏi có nhiều kinh nghiệm.

Hãy để việc ước lượng cho nhóm phát triển sản phẩm dưới sự tư vấn của một nhân viên nhiều kinh nghiệm

Hẳn ai cũng từng nghe Modern Talking hát: “You can win if you want. If you want it you will win”. Thật vậy, mọi người đều nỗ lực khi bản thân họ muốn vậy. Developer cũng không ngoại lệ, họ sẽ có khuynh hướng làm việc tốt hơn để đạt được thời gian do chính mình ước lượng.

 

Lời kết

Hãy tưởng tượng một ngày nọ bạn tỉnh giấc và thấy mình đang đi trên dây, tay cầm sào giữ thăng bằng: đi nhanh quá thì ngã mà đi chậm quá cũng không xong, đứng lại thì càng không được. Hẳn là lúc đó bạn đang quản lý dự án đấy, rồi chuyện gì xảy ra đây nếu bạn lại thêm chứng bệnh sợ độ cao…

Làm thể nào để Google đánh chỉ mục cho blog của bạn

Trong những năm gần đây, một dạng trao đổi thông tin mới ra đời và phát triển với tốc độ rất nhanh, đó là blog (hay weblog). Blog thoạt đầu được phát triển như một dạng nhật ký trực tuyến với những suy nghĩ cá nhân được đưa lên web. Hiện nay, ứng dụng blog trở nên phong phú hơn, và dễ thấy nhất là việc dùng blog làm một kênh thông tin trong nội bộ cũng như bên ngoài công ty.

Một trong các dịch vụ blog miễn phí khá nổi tiếng là dịch vụ Blogger của Google (www.blogger.com), nó cho phép bạn tạo và duy trì các blog trên máy chủ Blogger. Trong bài viết này tôi xin không trình bày cách tạo một blog trên Blogger vì nó chỉ thông qua một vài thao tác đơn giản và có khá nhiều bài viết đã trình bày. Thay vào đó, bài viết sẽ hướng dẫn bạn cách đưa blog vào google sitemap, để Google có thể đánh chỉ mục blog của bạn, nhằm gia tăng cơ hội cho blog của bạn xuất hiện dưới kết quả tìm kiếm của Google.

Trước hết chúng ta hãy tìm hiểu qua về Google Sitemaps: Google Sitemaps hiện đang ở bản beta, được Google phát triển với mục đích cung cấp một cách thức đơn giản cho người dùng có thể mô tả web site của họ. Thông qua việc cung cấp cho Google sitemap của site (cấu trúc site, các trang web quan trọng cũng như mức độ thay đổi của chúng…), bạn đã hướng dẫn cho các "spiders" của Google cách đọc thông tin và đánh chỉ mục cho web site của bạn.

Dưới đây là hướng dẫn chi tiết cách đưa blog vào google sitemap:

Bước # 1: Đăng nhập vào Google Sitemaps (http://www.google.com/webmasters/sitemaps/siteoverview) thông qua tài khoản Google của bạn

Ngay ở đầu trang bạn sẽ thấy ô nhập liệu để nhập site cần đánh chỉ mục. Hãy nhập vào đó địa chỉ URL của blog của bạn (ví dụ: http://khanhle.blogspot.com/)

Sau đó nhấn nút “OK”. Blog của bạn sẽ được thêm vào tài khoản như hình dưới:

Bước # 2: Xác thực quyền của bạn trên blog vừa nhập.

Kích vào siêu liên kết “Verify”, bạn sẽ chuyển đến trang có hình dưới:

Google cung cấp hai phương pháp xác thực. Tuy nhiên ta chọn phương pháp thứ hai “Add META tag”, vì đây là phương pháp duy nhất mà Google Blogger hỗ trợ.

Sau khi chọn, trang web sẽ sinh ra mã META tag, ta sẽ chép đoạn mã này vào phần template của blog.

Bước # 3: Dán META tag vào template của blog

Đăng nhập vào www.blogger.com . Vào blog của bạn, di chuyển đến tab “Template”.
Chèn đoạn mã META tag vào như ví dụ dưới:

Lưu lại thay đổi bằng cách kích vào nút “Save Template”

Kích vào nút “Republish Index only”. Sau đó đợi vài giây cho đến khi blog của bạn được published hoàn toàn.

Bước # 4: Trở về lại Google sitemap để kết thúc quá trình xác thực.

Trở về lại Google sitemap, ta có: “I’ve added the META tag in the home page of http://khanhle.blogspot.com/”.

Nhấn vào nút “Verify” để kết thúc quá trình xác thực

Bước # 5: Đến bước này blog của bạn đã được đưa vào Google sitemap. Tuy nhiên, bạn cần phải cung cấp cho Google URL sitemap của blog của bạn. Ta sẽ dùng site feed (ATOM xml) của blog làm site map.

Trở về hình ở bước một và nhấn vào siêu liên kết “Add a Sitemap”, bạn có được:

Chọn “Add General Web sitemap”

Cung cấp địa chỉ URL của blog của bạn, đó là địa chỉ của file atom.xml. Ví dụ http://khanhle.blogspot.com/atom.xml (*):

Nhấn vào nút “Add Web Sitemap”.

Bạn sẽ nhận được thông điệp xác nhận của Google:

“You have added a Sitemap to http://khanhle.blogspot.com/. Reports may take several hours to update. Thank you for your patience!”

Chúc mừng! Bạn đã kết thúc quá trình đưa blog vào Google sitemap. Bây giời thì bạn chỉ còn phải đợi Google đánh chỉ mục cho blog của bạn.

(*) Chú ý: Nếu bạn chưa kích hoạt chức năng “Site Feed” của blog của bạn, thì bạn phải thực hiện trước khi thực hiện bước này. Dưới đây là hướng dẫn:

Đăng nhập vào www.blogger.com . Vào blog của bạn, di chuyển đến tab “Setting” > “Site Feed”. Và thực hiện như hình dưới:

Bước # 6: Kiểm tra kết quả đánh chỉ mục của Google

Sau khoảng vài giờ hoặc một ngày, bạn hãy kiểm tra tài khoản trên Google sitemap xem blog của bạn đã được Google đánh chỉ mục chưa. Nếu Google đã kiểm tra blog của bạn, bạn sẽ có kết quả tương tự hình dưới:

Tùy thuộc vào lượng tin, nội dung cũng như số lượng người truy cập vào blog của bạn mà cơ hội blog URL có thể xuất hiện dưới kết quả tìm kiếm của Google. Tuy nhiên, nếu từ khóa là tên của bạn hoặc các từ riêng biệt chỉ xuất hiện trên blog của bạn thì khả năng blog của bạn nằm trong 10 kết suất đầu tiên của Google là gần như chắc chắn.

Ví dụ sau đây kết quả của sử dụng tìm kiếm thông qua Google với từ khóa “le canh khanh”:

Nếu blog của bạn khá nổi tiếng với nhiều người vào xem và bình luận thì cơ hội cơ hội cho nó xuất hiện dưới nhiều từ khóa khác nhau là hoàn toàn có thể, còn không thì thông qua tên bạn bè bạn cũng dễ dàng tìm ra blog của bạn.

Refactoring or "if it works, don't fix it"?

Once upon a time, a consultant made a visit to a development project. The consultant looked at some of the code that had been written; there was a class hierarchy at the center of the system. As he wandered through the hierarchy, the consultant saw that it was rather messy. The higherlevel classes made certain assumptions about how the classes would work, assumptions that were embodied in inherited code. That code didn't suit all the subclasses, however, and was overridden quite heavily. If the superclass had been modified a little, then much less overriding would have been necessary. In other places some of the intention of the superclass had not been properly understood, and behavior present in the superclass was duplicated. In yet other places  several subclasses did the same thing with code that could clearly be moved up the hierarchy.

The consultant recommended to the project management that the code be looked at and cleaned up, but the project management didn't seem enthusiastic. The code seemed to work and there were considerable schedule pressures. The managers said they would get around to it at some later point.

The consultant had also shown the programmers who had worked on the hierarchy what was going on. The programmers were keen and saw the problem. They knew that it wasn't really their fault; sometimes a new pair of eyes are needed to spot the problem. So the programmers spent a day or two cleaning up the hierarchy. When they were finished, the programmers had removed half the code in the hierarchy without reducing its functionality. They were pleased with the result and found that it became quicker and easier both to add new classes to the hierarchy and to use the classes in the rest of the system.

The project management was not pleased. Schedules were tight and there was a lot of work to do. These two programmers had spent two days doing work that had done nothing to add the many features the system had to deliver in a few months time. The old code had worked just fine. So the design was a bit more "pure" a bit more "clean." The project had to ship code that worked, not code that would please an academic. The consultant suggested that this cleaning up be done on other central parts of the system. Such an activity might halt the project for a week or two. All this activity was devoted to making the code look better, not to making it do anything that it didn't already do.

How do you feel about this story? Do you think the consultant was right to suggest further clean up? Or do you follow that old engineering adage, "if it works, don't fix it"?

I must admit to some bias here. I was that consultant. Six months later the project failed, in large part because the code was too complex to debug or to tune to acceptable performance.

The consultant Kent Beck was brought in to restart the project, an exercise that involved rewriting almost the whole system from scratch. He did several things differently, but one of the most important was to insist on continuous cleaning up of the code using refactoring. The success of this project, and role refactoring played in this success, is what inspired me to write this book, so that I could pass on the knowledge that Kent and others have learned in using refactoring to improve the quality of software.

 

(trích từ  Refactoring: Improving the Design of Existing Code)