心

just a stuff

how long is it from the last day I have written something in English :-?
it is quite hard for me to write in English now :-( and i get more troubles in speaking :-(
sometimes, I lost my way, which way should I go, but now it seems i have just one way to choose :-(
but even when I found out my way, I also do not run on it as fast as I can :-(
Someone plz boost me up T_T

たしかなこと

作詞：小田和正 作曲：小田和正

雨上がりの空を見ていた　通り過ぎてゆく人の中で
哀しみは絶えないから　小さな幸せに　気づかないんだろ

時を越えて君を愛せるか　ほんとうに君を守れるか
空を見て考えてた　君のために　今何ができるか

忘れないで　どんな時も　きっとそばにいるから
そのために僕らは　この場所で
同じ風に吹かれて　同じ時を生きてるんだ

自分のこと大切にして　誰かのこと　そっと想うみたいに
切ないとき　ひとりでいないで　遠く　遠く離れていかないで

疑うより信じていたい　たとえ心の傷は消えなくても
なくしたもの探しにいこう　いつか　いつの日か見つかるはず

いちばん大切なことは　特別なことではなく
ありふれた日々の中で　君を
今の気持ちのまゝで　見つめていること

君にまだ　言葉にして　伝えてないことがあるんだ
それは　ずっと出会った日から　君を愛しているということ

君は空を見てるか　風の音を聞いてるか
もう二度とこゝへは戻れない
でもそれを哀しいと　決して思わないで

いちばん大切なことは　特別なことではなく
ありふれた日々の中で　君を
今の気持ちのまゝで　見つめていること

忘れないで　どんな時も　きっとそばにいるから
そのために僕らは　この場所で
同じ風に吹かれて　同じ時を生きてるんだ

どんな時も　きっとそばにいるから

Bé Bình khóc nhè

Bài này hát sao hết :-s

Top 10 Things That Annoy Programmers

10. Comments that explain the “how” but not the “why”

Introductory-level programming courses teach students to comment early and comment often. The idea is that it’s better to have too many comments than to have too few. Unfortunately, many programmers seem to take this as a personal challenge to comment every single line of code. This is why you will often see something like this code snippit taken from Jeff Atwood’s post on Coding Without Comments:

view sourceprint?

1	r = n / 2; // Set r to n divided by 2

2

3	// Loop while r - (n/r) is greater than t

4	while ( abs( r - (n/r) ) > t ) {

5	r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)

6

}

Do you have any idea what this code does? Me neither. The problem is that while there are plenty of comments describing what the code is doing, there are none describing why it’s doing it.
Now, consider the same code with a different commenting methodology:

view sourceprint?

1	// square root of n with Newton-Raphson approximation

2	r = n / 2;

3

4	while ( abs( r - (n/r) ) > t ) {

5	r = 0.5 * ( r + (n/r) );

6

}

Much better! We still might not understand exactly what’s going on here, but at least we have a starting point.
Comments are supposed to help the reader understand the code, not the syntax. It’s a fair assumption that the reader has a basic understanding of how a for loop works; there’s no need to add comments such as “// iterate over a list of customers”. What the reader is not going to be familiar with is why your code works and why you chose to write it the way you did.

9. Interruptions

Very few programmers can go from 0 to code at the drop of a hat. In general, we tend to be more akin to locomotives than ferraris; it may take us awhile to get started, but once we hit our stride we can get an impressive amount of work done. Unfortunately, it’s very hard to get into a programming zone when your train of thought is constantly being derailed by clients, managers, and fellow programmers.
There is simply too much information we need to keep in mind while we’re working on a task to be able to drop the task, handle another issue, then pick up the task without missing a beat. Interruptions kill our train of thought and getting it back is often a time-consuming, frustrating, and worst of all, error-prone process.

8. Scope creep

From Wikipedia:

Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project’s scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided.

Scope creep turns relatively simple requests into horribly complex and time consuming monsters. It only takes a few innocent keystrokes by the requirements guy for scope creep to happen:

• Version 1: Show a map of the location
• Version 2: Show a 3D map of the location
• Version 3: Show a 3D map of the location that the user can fly through

Argh! What used to be a 30 minute task just turned into a massively complex system that could take hundreds of man hours. Even worse, most of the time scope creep happens during development, which requires rewriting, refactoring, and sometimes throwing out code that was developed just days prior.

7. Management that doesn’t understand programming

Ok, so maybe there are some perks.

Management is not an easy job. People suck; we’re fickle and fragile and we’re all out for #1. Keeping a large group of us content and cohesive is a mountain of a task. However, that doesn’t mean that managers should be able to get away without having some basic understanding of what their subordinates are doing. When management cannot grasp the basic concepts of our jobs, we end up with scope creep, unrealistic deadlines, and general frustration on both sides of the table. This is a pretty common complaint amongst programmers and the source of a lot of angst (as well as one hilarious cartoon).

6. Documenting our applications

Let me preface this by saying that yes, I know that there are a lot of documentation-generating applications out there, but in my experience those are usually only good for generating API documentation for other programmers to read. If you are working with an application that normal everyday people are using, you’re going to have to write some documentation that the average layman can understand (e.g. how your application works, troubleshooting guides, etc.).
It’s not hard to see that this is something programmers dread doing. Take a quick look at all the open-source projects out there. What’s the one thing that all of them are constantly asking for help with? Documentation.
I think I can safely speak on behalf of all programmers everywhere when I say, “can’t someone else do it?“.

5. Applications without documentation

I never said that we weren’t hypocrites. Programmers are constantly asked to incorporate 3rd party libraries and applications into their work. In order to do that, we need documentation. Unfortunately, as mentioned in item 6, programmers hate writing documentation. No, the irony is not lost on us.
There is nothing more frustrating than trying to utilize a 3rd party library while having absolutely no fricken idea what half the functions in the API do. What’s the difference between poorlyNamedFunctionA() and poorlyButSimilarlyNamedFunctionB()? Do I need to perform a null check before accessing PropertyX? I guess I’ll just have to find out through trial and error! Ugh.

4. Hardware

Any programmer who has ever been called upon to debug a strange crash on the database server or why the RAID drives aren’t working properly knows that hardware problems are a pain. There seems to be a common misconception that since programmers work with computers, we must know how to fix them. Granted, this may be true for some programmers, but I reckon the vast majority of us don’t know or really care about what’s going on after the code gets translated into assembly. We just want the stuff to work like it’s supposed to so we can focus on higher level tasks.

3. Vagueness

“The website is broken”. “Feature X isn’t working properly”. Vague requests are a pain to deal with. It’s always surprising to me how exasperated non-programmers tend to get when they are asked to reproduce a problem for a programmer. They don’t seem to understand that “it’s broken, fix it!” is not enough information for us to work off of.
Software is (for the most part) deterministic. We like it that way. Humor us by letting us figure out which step of the process is broken instead of asking us to simply “fix it”.

2. Other programmers

Programmers don’t always get along with other programmers. Shocking, but true. This could easily be its own top 10 list, so I’m just going to list some of the common traits programmers have that annoy their fellow programmers and save going into detail for a separate post:

• Being grumpy to the point of being hostile.
• Failing to understand that there is a time to debate system architecture and a time to get things done.
• Inability to communicate effectively and confusing terminology.
• Failure to pull ones own weight.
• Being apathetic towards the code base and project

And last, but not least, the number 1 thing that annoys programmers…

1. Their own code, 6 months later

Don’t sneeze, I think I see a bug.

Ever look back at some of your old code and grimace in pain? How stupid you were! How could you, who know so much now, have written that? Burn it! Burn it with fire!
Well, good news. You’re not alone.
The truth is, the programming world is one that is constantly changing. What we regard as a best practice today can be obsolete tomorrow. It’s simply not possible to write perfect code because the standards upon which our code is judged is evolving every day. It’s tough to cope with the fact that your work, as beautiful as it may be now, is probably going to be ridiculed later. It’s frustrating because no matter how much research we do into the latest and greatest tools, designs, frameworks, and best practices, there’s always the sense that what we’re truly after is slightly out of reach. For me, this is the most annoying thing about being a programmer. The fragility of what we do is necessary to facilitate improvement, but I can’t help feeling like I’m one of those sand-painting monks.

Source: http://www.kevinwilliampang.com/

Truyền đạt, truyền lửa, truyền thành công!

Hẳn chúng ta vẫn nhớ đến bài phát biểu của Steve Jobs - Giám đốc điều hành của tập đoàn máy tính Apple Computer ở lễ trao bằng tốt nghiệp của trường ĐH danh tiếng Stanford (Mỹ) vào tháng 6/2005. Không hô hào khẩu hiệu, chẳng kể lể thành tích, nhưng bài diễn thuyết của ông đã gây chấn động lớn ở buổi lễ và trên mạng Internet toàn cầu sau đó.
Không bàn tới nội dung của bài phát biểu vốn dĩ quá đột phá và xuất sắc, ở đây, người viết muốn nhấn mạnh đến một khía cạnh góp phần giúp bài diễn thuyết của Steve thành công rực rỡ: đấy là phương cách truyền đạt hoàn hảo của ông với phong cách và sự chuẩn bị nội dung không thể chê vào đâu được.
Bạn không phải là Steve Jobs, tuy nhiên nếu bạn là một nhà quản lý giỏi, hẳn bạn cũng đã và đang trang bị cho mình một phong cách truyền đạt rất riêng cho bản thân để hỗ trợ cho công việc, bởi kỹ năng giao tiếp và truyền đạt luôn nằm ở phần đầu trong danh sách các kỹ năng bắt buộc của người quản lý. Bên cạnh phương pháp riêng của mình, bạn có thể tham khảo những bí quyết sau.
Chuẩn bị thông tin thật kỹ
Dù là một bài diễn văn quan trọng, một email giao việc hay chỉ là một đôi câu nói hướng dẫn, thì điều kiện đầu tiên của thông tin vẫn là phải đầy đủ, có bố cục chặt chẽ, có dàn ý rõ ràng. Bạn nên nghĩ kỹ về những điều mình sẽ nói/viết, có mở đầu, diễn giải và kết thúc không, đã đủ các ý cần nêu chưa, các ý ấy đã rõ ràng dễ hiểu chưa, có nguyên nhân, mục đích gì… Một thông tin được chuẩn bị tốt sẽ là khởi đầu của thành công, và ngược lại, việc chuẩn bị thông tin kém sẽ đem lại sự trắc trở cho công việc, bắt nguồn từ việc nhân viên không hiểu gì về đều bạn muốn truyền đạt, hoặc là hiểu sai ý, kiểu như ông nói gà mà bà nghe thành vịt. Chúng ta có thể hoàn toàn kiểm soát được từ mà mình viết hoặc nói ra, chỉ cần chúng ta thực sự chú ý.
Chỉ một thông điệp chính
Một lần truyền đạt tốt nhất chỉ nên chứa một thông điệp chính. Bởi trí nhớ và tốc độ tiếp nhận thông tin của con người có giới hạn, truyền đạt quá nhiều thông điệp hoặc đưa quá nhiều thông tin không cần thiết sẽ khiến nhân viên cảm thấy rối rắm, chẳng biết đâu mà lần, chẳng biết phải thực hiện việc gì. Bên cạnh đó, thông tin nên ngắn gọn, không vòng vo quanh quẩn (nhất là trong các bài nói) mà nên đi thẳng vào chủ đề chính sau một câu mở đầu.
Nhấn mạnh và lặp lại
Đề cập đến "dàn ý" ngay từ đầu là phương pháp rất phổ biến và hiệu quả để cho người nghe có thể hình dung và nhớ được nội dung của thông tin. Phương pháp lặp ở cuối cùng để nhấn mạnh ý chính và gây ấn tượng cũng đóng vai trò rất quan trọng. Các bạn cứ để ý phần mềm Word có công cụ Bold (B - tô đậm), Italic (I - in nghiêng) và Underline (U – gạch dưới). Trong phần truyền đạt của mình dù là nói hay viết, bạn hãy tận dụng các chức năng này để nhấn mạnh các ý chính, tuy nhiên hãy nhớ đừng lạm dụng quá mức khiến người nghe/ đọc cảm thấy rối rắm.
Lắng nghe và thảo luận
Một nhà quản lý biết cách truyền đạt tốt luôn tìm hiểu xem nhân viên đã nắm rõ vấn đề chưa, đặt những câu hỏi cho nhân viên, khuyến khích nhân viên thảo luận, hỏi lại mình, tranh luận cùng mình. Bên cạnh đó, việc lắng nghe ý kiến của nhân viên sẽ giúp nhà quản lý bổ sung thông tin, có được ý tưởng mới, hoàn thiện kế hoạch, nhìn nhận vấn đề một cách sâu rộng hơn.
Thái độ truyền đạt
Thái độ truyền đạt là một yếu tố cực kỳ quan trọng, quyết định phần truyền đạt của bạn có thành công hay không. Thái độ ấy ẩn chứa trong cách dùng ngôn từ, trong biểu cảm của giọng nói và trong ngôn ngữ cơ thể. Nếu bạn dùng từ ngữ quá cao ngạo, đầy mệnh lệnh, giọng nói của bạn lạnh lùng, thái độ của bạn quá thô lỗ thì hẳn nhân viên của bạn ngoài việc “run như cầy sấy” hoặc đầy bất mãn, sẽ chẳng còn tâm tư đâu tiếp nhận thông tin của bạn. Một gương mặt thân thiện, không cần phải cười nhiều nhưng toát ra vẻ gấn gũi, ngôn ngữ cơ thể đúng mực, không quá thân mật nhưng cũng không xa cách, ngôn từ chừng mực, đơn giản, rõ ràng dễ hiểu sẽ giúp cho việc truyền đạt của bạn trở nên dễ dàng và hiệu quả.
Ngoài ra, người quản lý nên điều chỉnh cách nói/viết của mình cho phù hợp với nhân viên tùy theo trình độ, tuổi tác, văn hóa... Với người già không nên nói qua nhanh, với thanh niên thì đừng nên nói quá chậm hoặc tác phong chậm chạp sẽ gây hiệu ứng không tốt khi giao tiếp với nhau.
Ở những công ty nhỏ và vừa, do số lượng nhân viên ít đặc thù văn hóa công ty cởi mở gần gũi hơn, nên khoảng cách giữa nhà quản lý và nhân viên có thể thu hẹp, tựa như anh em, bạn bè, vì vậy, việc truyền đạt cũng có thể bớt theo khuôn khổ mà linh động hơn. Tuy nhiên trên cơ bản vẫn nên thực hiện theo các bước đã nêu (có đơn giản hóa đi), giữa sếp và nhân viên cũng nên có một khoảng cách nhất định, không thể đi quá giới hạn, kiểu như sếp và nhân viên bằng tuổi xưng hô “mày tao”...
Truyền đạt là truyền lửa
Trên tất cả, mục đích của việc truyền đạt thông tin là để thực hiện công việc trôi chảy, kinh doanh thuận lợi, công ty thành công. Để đạt được điều đó, mỗi nhân viên trong công ty phải hiểu được sứ mạng của công ty cũng như sứ mạng của bản thân. Nhiệm vụ của một nhà quản lý là truyền đạt để nhân viên nắm rõ và cố gắng hết sức thực hiện sứ mạng đó, vì bản thân họ (thu nhập, thăng tiến) và vì công ty. Chính vì thế, một khi người quản lý đốt lên được ngọn lửa đam mê công việc cho chính bản thân mình, tìm được lý tưởng sống và làm việc của mình, thì ngọn lửa đó sẽ lan tỏa đến nhân viên một cách tự nhiên và bền vững, thắp lên trong lòng nhân viên những khát vọng, ước mơ cống hiến và đột phá, thay đổi, vươn lên. Như bức thư gửi nhân viên nổi tiếng của Bill Gates, như bài diễn thuyết thế kỷ của Steve Jobs đã làm được.

Nguồn Vietnam Works

Rùa Con

Tình yêu tuyệt vời

Blogger - "Read more" function

Blogger is now support the "Read more" function, so that you can publish your article shortly.

Anh

Bay giua ngan ha

....

A stuff

Daddy: tết sắp đến rồi mà chả thấy ko khí gì, ngày nào cũng có thể ăn uống hoành tráng, chả việc j phải đợi đến tết.

Mammy: Yep, có ko khí đi nữa thì đến 30 thì bắt đầu chán rồi :-(

Son: [no comment]

Tại sao có những ng mong chờ tết thế, lại có những ng đến tết lại chán :-(

Tết là ngày để ăn nhậu hoành tráng mà hem bị cằn nhằng ??? là ngày chơi bời xả láng ???

Hay là ngày để đoàn tụ gia đình, để đi đó đi đây thăm hỏi người thân, để nghỉ ngơi, chuẩn bị 1 năm mới nhiều dự định mới ???

Thèm lắm cảm giác xa nhà, mong chờ tết đến để về với gia đình, nhớ lắm cảm giác đc bố mẹ chở đi chúc tết (nhiều lúc chả biết là ai :"> ), thèm đc 1 ngày thảnh thơi ^.^

Tiệc tùng, ồn ào, chén bát chất đống, bài bạc ... -> "điệp khúc mùa xuân" lại 1 năm nữa :-)

Viết bằng Eng có lẽ đỡ hơn :">

Happy new year 2010

Be happy :-)