7zip vs zip vs plain text

Nén file lớn khi commit để tiết kiện HDD space và bandwidth.

Với text file, như kết quả dưới đây:

zip: Giảm 100 lần size
7zip: Giảm khoảng 700 lần size

clamav

 Gửi anh T,

Với Linux desktop: Không cần phí mua chương trình diệt virus vì
Linux miễn nhiễm với hầu hết[1] mã độc của Windows

Với clamav, một virus scanning engine mã mở sẽ không tốn một
đồng triển khai[2].

Nếu tích hợp Clamav với Spyware Terminator (Real-time shield)
sẽ có một giải pháp quét virus miễn phí.

Về virus database và engine: clamav chạy đủ nhanh và malware
database được cập nhật bởi cộng đồng *hằng ngày*

Công ty em dùng clamav cả năm nay và chưa có vấn đề gì xảy ra cả :)

[1] Đề tài này hơi bị dài nên em chỉ xin nói ngắn gọn là "hầu hết"
[2] http://www.clamav.net/lang/en/ clamav không có chức năng
     quét on-access real-time, nhưng tích hợp được với hầu hết
     các chương trình phổ dụng như ThunderBird


2011/3/29 Nguyễn Hữu Thành 

    Báo Việt Cộng: Chi 8 tỷ đồng để diệt virus cho 2.000 trường học
    Ngày 29/3, Công ty bảo mật Nam Trường Sơn (NTS Security) thông báo 
    sẽ tặng phần mềm bảo mật Kaspersky doanh nghiệp (KOSS) cho 2.000 trường học 
    tại Việt Nam.
    Phần mềm bản quyền này có thời hạn 6 tháng, được cài đặt cho 10 
    máy tính nối mạng Internet cho một trường học cấp 1, cấp 2 và cấp 3. 
    Mỗi gói sản phẩm nói trên có giá trị 4 triệu đồng. Tổng chương trình 
   lên tới 8 tỷ đồng.

VTV1 phong van

VTV1 phỏng vấn mình về

- Cách mà OpenOffice/LibreOffice và bản tiếng Việt được phát triển
  + Các vấn đề trong quá trình phát triển bản OpenOffice/LibreOffice Việt hóa
- OpenOffice rẽ nhánh sang LibreOffice
- Khuyến cáo người dùng sử dụng LibreOffice thay vì OpenOffice

Tiếp theo

- Quay phim công ty, lấy hình nhân viên đang họp
- Lấy hình Linux, OpenOffice

dong gop ung ho dong dat

Cầu mong nước Nhật sớm vượt qua sóng gió này.

Dinh nghia mot so test case

Trong "category" ở phía dưới các test case, người tạo cần phân biệt

N (normal)　正常
E (abnormal = error) 以上
L (limit) 境界
I (interface)　インタフェース

Mặc dù khách hàng không quá quan trọng hóa việc phân loại này, 
nhưng có thể tham khảo nguyên tắc sau
để phân loại TC chính xác hơn

1. Interface
Giao diện giữa các hàm số, các chức năng.
Hiện trong dự án chưa phát hiện ra trường hợp này

2. Limit:
Các trường hợp tới hạn. Ví dụ biến x có thể lấy giá trị nguyên từ 0 đến 500
thì 0 và 500 là các trường hợp tới hạn.

3. Error, Abnormal:
Xảy ra xự số hay expection. Ví dụ: Không truy cập được DB, nhập chuỗi, số sai format, vượt giới hạn
Tham khảo: http://en.wikipedia.org/wiki/Exception_handling#Exception_handling_based_on_Design_by_Contract

4. Normal:
Các trường hợp thông thường (còn lại)

Hoc tieng Nhat

ペケ： dấu nhân × -> Đại diện cho ký tự bất kỳ
http://ja.wikipedia.org/wiki/%E3%83%9A%E3%82%B1
Nếu viết ペケペケに関する -> vấn đề nào đó

ビカピカ có phải tiếng Nhật hay không?

ピカピカ 　

　光り輝くさま。 　

　ピヒ・カ→ピ・カ（語尾の「ヒ」が脱落）、
  PIHI-KA(pihi=begin to grow;ka=take fire,burn)、
  火が勢いよく燃えて光る→光り輝くさま

Có, và rất gần tiếng Maori (đượng coi là ngôn ngữ anh em với tiếng Nhật)

http://www.iris.dti.ne.jp/~muken/kokugo01.htm#142%E3%83%94%E3%82%AB%E3%83%94%E3%82%AB

Tu Han-Nhat-Han-Viet

Kính gửi anh Thông và các anh chị,

Từ Hán (cổ), ảnh hưởng liên tục và có khúc xạ với ngôn ngữ của quốc gia bản địa
sinh ra từ Hán-Việt, Hán-Nhật, Hán-Hàn. Đây là đề tài rất thú vị.

Về mặt ngữ âm, cả 4 loại trên còn khá nhiều điểm tương tự, nhưng sau sau hàng ngàn
năm ảnh hưởng sự giống nhau cũng không nhiều.

Về mặt ngữ nghĩa, từ Hán Việt hiện tại giống nhiều từ Hán cổ từ thời Tiền Hán.
Vào khoảng đầu thế kỷ 20, có xảy ra sự hấp thụ từ Hán lần thứ hai (ví dụ: Mễ Tây Cơ)
nhưng ảnh hưởng này hiện tai không còn nhiều.

Với Nhật Bản, ảnh hưởng sâu đậm nhất của tiếng Hán xảy ra vào khoảng thế kỷ thứ 6-7,
khi Phật Giáo du nhập vào Nhật Bản.

Do đó, về mặt ngữ nghĩa,
các từ Hán Nhật khá giống tiếng Hán đời Đường. Người Nhật đọc thơ đường rất dễ dàng
và họ cảm thấy gần với những từ Hán Nhật hiện đại.

Về mặt ngữ nghĩa, theo tôi, do tiếng Nhật khá nghèo (chỉ có 50 âm) nên cách phát âm các
từ Hán Nhật bị thay đổi rất nhiều.

Ví dụ: 代表: ta pi-ẻo (Trung Quốc), đai hi-ô (Nhật) và đại-biểu (Việt)

Khoa kỹ du nhập vào Nhật Bản dưới thời Minh Trị (thế kỷ 19) và những từ này lại được người
Trung Quốc du nhập ngược trở lại Trung Quốc và sau đó người Việt du nhập lại một lần từ Trung Quốc.

Ví dụ: 関数 : can sư (Nhật), quan-su (Trung Quốc), hàm-số (Việt)

Hiện tượng đồng âm dị nghĩa:
- Do sử dụng từ Hán cũ-mới qua các thời kỳ
- Do cách ghép (tự sáng tạo) riêng của từng quốc gia (Nhật, Trung, Việt)

Điều may mắn và đặc thù với nước Nhật là họ chỉ ảnh hưởng mạnh một lần vào đời Đường,
sau đó tự phát triển. Một trong những lý do là Nhật Bản là quốc đảo, sự di chuyển và giao thao
văn hóa/ngôn ngữ nhiều phần bị ảnh hưởng.

Những từ mượn như アイスクリーム (ice scream) tồn tại rất rất nhiều trong tiếng Nhật, các từ này
du nhập từ (chủ yếu là) Đức, (sau đó là) Pháp, Ý trong thời kỳ Minh Trị.
Những từ tiếng Anh được du nhập từ Mỹ vào Nhật rất mạnh sau thế chiến thứ hai.

Hiện tại, các từ chuyên môn trong nghành công nghệ thông tin chủ yếu mượn nguyên xi từ tiếng
Anh và phiên âm theo âm cứng tiếng Nhật. Ví dụ

Protocol: プロトコル (pừ rô tô cô lự)
Internet: インタネット (in ta nét tộ)

Mong các anh chị tham khảo

Comment

管理があまい→納期に対しての意識
やるかはモチベーションに左右される→いつでも全力でやるべき
わからなくてもわかると言っているふり→わからなければそう言ってOK
自慢する→ベトナム人の国民性か？日本人は謙遜なので

Tara-and-Reba

Em cứ dùng たら đi, không sợ sai đâu.

Ít nhất là khi dùng với ご連絡ください。
thì anh luôn viết.

エラーが発生したら、ご連絡ください。

Người Nhật họ dùng như thế mà.
Ngôn ngữ nó là thế, dùng quen, giống người Nhật, sai giống ngườiNhật,
chứ hỏi vì sao "đúng, sai"...thì bản thân người Nhật cũng không biết.

Google
エラーが発生したら: 12.4 triệu hit
エラーが発生すれば: 487K hit
-> Rõ ràng người Nhật hay dùng したら hơn

# Tuy vẫn đúng nhưng không dùng れば、

Picture - Image (Japanese)

Tiếng Nhật đôi lúc khó hiểu thế này: -> 画像 のイメージ
画像のイメージでは、jsの実装に問題ないと思います。

Dich-dich-dich

Định dịch mấy cái này

Redmine - Quản lý dự án
www.amazon.co.jp search "Redmineによるタスクマネジメント実践技法 [大型本]" ISBN-10: 4798121622

Subversion - Quản lý thay đổi
svnbook.red-bean.com/en/1.5/svn-book.pdf

POSS - Phát triển phần mềm mã mở
http://producingoss.com/

Tieng Nhat

AのBとC: 理解仕方は2通りがあって

1. (AのB) 及び C
2. (AのB）及び（AのC)

→ Cần confirm lại để tránh hiểu lầm.

Doi dieu ve chuan va lam chuan

Chào chú Việt và các anh chị

Vâng, việc bỏ dấu vẫn bỏ ngỏ.
Tạm thời các dự án mã mở chọn bỏ dấu kiểu cũ làm chuẩn (de facto)

Thứ tự từ điển: Cũng chưa có chuẩn; đang được bỏ ngỏ.
Cháu đề xuất (và lập trình viên sẽ cũng làm như thế, vì họ lười):
So sánh thứ tự HEX code.

Đây là hai vấn đề khác nhau nhưng có điểm chung:
Hình như ở Tây có đi top-down từ chuẩn tới cụ thể,
còn ở ta thì "muốn thế nào cũng được".

Unicode (encoding) chỉ là encoding; thứ tự từ điển ra sao là
do ta định nghĩ (có thể theo thứ tự so sánh HEX code)

Cháu nghe kể vui rằng để mua một cái ghế trong một bộ nào đó,
thủ tục mất 1 tháng.

Đấy là chưa nói đến thủ tục liên bộ (Văn hóa, Thể thao, Du lịch
và Thông tin Truyền thông) để tạo ra một chuẩn IT về ngôn ngữ
chắc không khả thi chút nào.

Độc tài:
Ở Libi độc tài có lẽ là do dân trí thấp.

Dân chủ:
500 nghị viên quốc hội Bắc Triều Tiên biểu quyết dân chủ
nhưng kết quả có thể vẫn mờ vì... dân trí thấp.

Kỹ trị:
Khó quá vì chuyên gia khó vào quốc hội quá.

Vô vi nhi trị:
Quay lại vấn đề chính, cháu thấy cứ để cộng đồng tự quyết định
chuẩn có lẽ sự cân bằng sẽ công minh nhất (bởi "bàn tay vô hình").

Nguyễn Vũ Hưng

Vào 06:33 Ngày 01 tháng 3 năm 2011,  đã viết:

    Chào các chị các anh,

      Hôm trước diễn đàn ta có bàn tới việc hài dấu và IT. Tôi nghĩ việc này trong khi các nhà ngôn
    ngữ cãi nhau chưa xong, cánh IT ta đành chịu khó thay đổi một dòng lệnh vậy.

      Tuy nhiên, khi tra từ điển thấy vấn đề không đơn giản như thế. Hài dấu sẽ ảnh hưởng tới trật tự
    từ điển. Mà đã gọi là "điển" không đơn thuần là việc cãi cọ "ý tôi ý anh".

      Từ điển Thiều Chửu tách ra để phụ âm Nh sau Ng sau N. Như vậy Nụ, Nó đứng trước Ngu và đứng
    trước Nhà. Như vậy quy tắc tra từ theo ký tự từ trái qua phải sửa lại khá phức tạp. Sửa thuật
    toán không thành vấn đề lắm. Nhưng mấy bữa nữa các bác ngôn ngữ lại ra một phát kiến mới thì
    các ứng dụng CNTT lại lủng củng.

      Vấn đề Unicode dựng sẵn hay tổ hợp có lẽ cũng liên quan tới vấn đề trật tự từ điển. Anh chị nào
    có hứng thú cao đàm nhã luận xin bàn thêm ở Diễn đàn thế giới chữ cho đỡ lạc đề ở đây. Tôi vừa
    mới mở một thread về topic này
    http://thegioichu.com/Forum/tabid/58/forumid/10/postid/833/scope/posts/Default.aspx#833

    Aiviet

Notes on Bug tracking system, project management system

(2011/03/02 16:11), HongThanh Dao wrote:
> 2011/3/2 Truong Anh. Tuan 
>
>
>     Để làm bug tracking, nhất là cho các FOSS projects, cứ BugZilla mà chơi,
>     có gì mà phải nghĩ ngợi, lưa chọn ;)
>
>     Kind regards,
>     Tuan
>
>
> Không hẳn: Nếu người dùng không chuyên, thậm chí đến email còn hầu như chưa dùng bao giờ thì bugzilla quá phức tạp!
Bugzilla: Phần mềm quản lý lỗi (rất ngon)

Redmine: Phần mềm quản lý dự án cộng cộng nhiều chức năng khác,
Trong đó có chức năng quản lý lỗi (cài mặc định) có thể tùy biến rất tốt,
làm cho Redmine không khác gì Bugzilla.

LP G-500 rooted with z4root

#To: Arky

Hello,

How are you doing?

Just bought LG Optimus P-500 today and
z4root did the job perfectly :)

I will have to find time playing with it.

Dich tieng Nhat

チェックエラーとなった場合、メッセージ出力する。

Có thể dịch là

Trường hợp có lỗi, (thì) hiển thị thông báo.
Nếu có lỗi, (thì) hiển thị thông báo.

Review Tieng Nhat

本日の議事録を送付いたします。

特に、「３．他の連絡事項」は問題 ないか、ご確認をお願いします

本日（１月１４日）の打ち合わせ内容を議事録にて纏めました。

指摘事項などがあれば、ご連絡願います。

「議事録」　thì bao giờ cũng là cái matome của meeting ->
Vì vậy, viết 打ち合わせ　và 纏めました　ở đây là thừa.

ご連絡お願いします => thiếu を
Nguời Nhật hay nói: ご連絡 をください

指摘事項　→ ご指摘　nhưng nói chung chỉ cần viết ご確認をお願いします là đủ.

Hoc tieng Nhat

スケジュールを引く: Tạo schedule Vì schedule, dạng gant chart, giống đường thẳng nên họ nói giống như 線を引く ただし: (trong đó, tuy nhiên), dùng để bổ sung cho vế trước しかし：Nối 2 vế ngược nhau

Noi luc cong ty

Question: Công ty có nêu đầu tư thời gian, tiền bạc để đào tạo nhân viên hay không?

Tôi nghĩ  những người muốn học tiếng Nhật:

* Có tinh thần có gắng và tiến thủ
* Muốn gắn bó lâu dài với Nhật.

Gạt chuyện giữ người sang một bên (họ không làm cho công ty chúng ta thì cũng làm ở đâu đó)
mình nên khuyến khích những người này bằng cách:

* Đào tạo họ (cả tiếng Nhật và kỹ thuật)
* Hỗ trợ khoảng 30% tiền ăn trưa cho những người học tiếng Nhật.

Về ngắn hạn thì công ty phải bỏ phí, nhưng về lâu dài, công ty sẽ có đội key và BSE mạnh.

Trao doi ve BSE

Xem hình dưới

Theo slide đã tham khảo

Level 1 SE < BSE < Level 2 SE < Level 3 SE < Level 4 SE

Anh nghĩ điều này cần giải thích thêm

1.  Level SE là đủ trình độ để trở thành BSE
2. Tuy nhiên, Level 2, 3, 4 SE làm BSE thì càng tốt.

Anh đồng ý

BSE = SE + communication skills + alpha

Nếu mổ xẻ alpha ra thì có lẽ nó đều là common sense.

Communication skills có thể đào tạo được.

Vậy với BSE ngành IT, nếu có là SE+, thì cần kỹ thuật gì?
Anh nghĩ những kỹ thuật này được liệt kê trong IPA skill sheet ở trên.
BSE cần có nhiều kỹ năng, càng nhiều càng tốt, đặc biệt ở cột
IT architecturre, Project management, IT specialist, Software development
do đặc trưng của IT outsourcing là: Chỉ outsouce 3 công đoạn:
detail design, coding và testing.

Nếu outsouce các công đoạn khác cần nhiều skill hơn
Nếu involve với khách hàng nhiều hơn: cần nhiều skill hơn.

Hy vọng em Hương có thể hạn chế lại những kỹ năng cần thiết hơn.

Chia sẻ kinh nghiệm nhé :) Thanks

> Từ: ThuHuong Nguyen 
> Ngày: 09:29 Ngày 25 tháng 2 năm 2011
> Chủ đề: Re: Nhờ anh Hưng trả lời giúp!
> Đến: Nguyen Vu Hung 
>
> Vâng, thế cho nên em mới phải làm cái nghiên cứu 3-4 năm nay đấy ạ:D
Hóa ra là thế
> Vì nghiên cứu của Tàu thì vẫn là case Tàu, không xuất phát từ thực tiễn và context của VN.
Anh có đề cập qua trong email trước


Thực ra anh cũng  quan tâm đến vấn đề này
để đưa ra phương hướng đào tạo BSE.

Em còn case nào khác của Tàu không? -> gửi nhé.

BSE của VN và TQ khác nhau thế nào?
Theo anh nghĩ đầu tiên và cuối cùng vẫn là vấn đề ngôn ngư

- BSE của TQ làm 100% tiếng Nhật OK (VN BSE thì không thể)
- Phát sinh công (công đoạn dịch)
- Việc dịch chèn vào tất cả các công đoạn
- Mất 2 lần (gấp đôi) công review
- Trao đổi bị hạn chế (email, và đặc biệt là voice chat, meetings)
-  Hiểu nhầm, hiểu thiếu...

>
> Hiện nay em thu thập được rất nhiều data thú vị từ case FSoft. Nhưng tất cả 
đang là 1 đống hỗn độn. Em đang cố gắng matome lại, khi nào xong em sẽ share với anh.

>
> Em thực sự thấy nghề này rất hay và có hứng thú tìm hiểu về nó.
> Với lại em nghĩ, mô hình tương lai, chắc chắn các công ty outsource VN sẽ cần những
người như bọn em, có nghiệp vụ và chuyên tâm hăn vào việc nghiên cứu, để tìm hiểu và 
đưa ra solution. Chứ bản thân các công ty, ví dụ FSoft cũgn ko ai có yoyu để tìm 
hiểu nghiên cứu, khái quát lại các vấn đề.
Tương lai mở công ty tư vấn đây Hương nhỉ?

Các công ty VN làm gì có R&D đâu, họ cứ hùng hục làm zangyou cho xong việc
mà không hề nghĩ đến chuyện làm sao cho smart hơn.

>
> Hiện tại, theo em để tuyền BSE, đối với case VN, anh nên đưa ra những chuẩn thấp 
thấp thôi, ví dụ tốt nghiệp khối kỹ thuật, tiếng Nhật 3kyu, quan trọng nhất là phải có tinh thần học hỏi.

Dân Vn mình kém hơn bọn TQ và bọn Nhật :).

VN mới chỉ có khoảng hơn 10-15 năm làm gia công cho Nhật,
trong đó khoảng 5-7 năm gia công phần mềm.

Kinh nghiệm rất ít so với Trung Quốc (từ năm 79-86), chưa đủ tích lũy
biến chuyển từ know-how thành chất lượng.


> Thế thôi, còn đâu về anh đào tạo còn hơn. Ví dụ anh đưa ra các level, ranking,
> - level 1 tệ nhất là như em vừa nói 3kyu + f (soft skills)
Mức này không dùng làm BSE được, phải phối hợp

1. Lập trình viên + comter
2. Kỹ sư (cấp 1) + comter
3. Kỹ sư (cấp 2,3,...) + comter

Hầu hết các công ty sử dụng loại 3; trong trường hợp này, họ cần kỹ sư rất khá

Các kỹ sư này, nếu em để ý, họ đều xuất thân từ các trường chuyên cấp III, học đại học
có ranking vào bậc nhất ở Việt Nam.


> - level 2, 2kyu + g (f+1)
> - level 3 : 1 kyu+j....
>
> để có chuẩn tuyển và để BSE trong cty phấn đấu lên bậc.
> (Các case của em cho thấy dân xã hội mà tuyển làm BSE sẽ rất rất hạn chế trong cv sau này)
trong khi đó, dân xã hội (là các trường đại học có ranking thấp hơn, đầu vào kém) nên
họ không khá nhanh được.

Dân xã hội có hạn chế nữa là tư duy kỹ thuật, điều này thực tế cho thấy khó có thể đào tạo
lại ở độ tuổi 22+.

Em có biết Fujitsu case tuyển dân ngoại ngữ (đã tốt nghiệp ở VN) đào tạo ở Việt Nam và Nhật không nhỉ?
Case này theo anh biết thất bại gần như 100% (nhưng phải kể tới nguyên nhân suy thoái kinh tế)

Đại học FPT đang lấp chỗ trống bằng cách đào tạo cả tiếng Nhật + kỹ thuật + kỹ năng mềm từ trong trường

Đại học Hà Nội cũng có lớp kỹ sư tiếng Nhật.

Trao đổi thêm nhé! Anh rất muốn được nghe ý kiến từ chuyên gia như Hương!

Redmine Bulk Time Entry plugin to record work time

https://github.com/edavis10/redmine-bulk_time_entry_plugin
Cho phép nhập nhiều timelog cùng một lúc trong một trang.
Có thể import timelog từ csv file.

Dịch 場合

チェックエラーとなった場合、メッセージ出力する。 Có thể dịch là Trường hợp có lỗi, (thì) hiển thị thông báo. Nếu có lỗi, (thì) hiển thị thông báo.

Redmine Tips - Do your Issue Statuses help or hurt your workflow?

The statuses depend on the development processes that we are working on.
And I imitate the following statuses (specified for the  cases of bug tracking)
cf. https://bugs.freedesktop.org/page.cgi?id=fields.html#status

Statuses for other development processes are as simple as you wrote;
The default statuses on Redmine/ProjectChilly are fine to me.

IMO, I think we should mention statuses + trackers + roles as a combination
when speaking to development processes.

By the way, please recommend me a good book on Redmine.


(2011/02/17 0:30), Eric Davis wrote:
Do your Issue Statuses help or hurt your workflow?
 
Issue Statuses are used in Redmine to create a workflow for issues. In an optimized
setup, the issues will move through the different statuses as they are worked on. 
The Issue Statuses I use for Little Stream Software have been optimized to be as 
simple as possible for single person business but also communicate where the issue 
is at to my clients.
 

    * Proposed - Someone has an idea for some work but isn't sure about it yet.
    * New/Approved - Both my client and I like the idea and agree on the budgets.
    * In Progress - I'm actively working on the issue.
    * Resolved - I've finished the issue and am waiting for client to sign off 
      on it. (i.e. ready to be tested).
    * Closed - My client agrees the work is complete.

 
I also use two issue statuses for when exceptions occur:
 

    * Declined - one of us decides the issue isn't needed but we want to document 
       the conversation (instead of deleting the issue).
    * Feedback - someone has a question about the issue that prevents us from 
       working on it

 
This same workflow works for my Open Source plugins but in that case I act as the 
client and project manager.
 
What issue statuses do you use? What have you found helpful?

The changing quality assurance paradigm

The changing quality assurance paradigm All of the factors discussed in the previous section point to the need to end status quo quality assurance approaches and break down the barriers between all of the internal organizations that are instrumental to creating quality products. Leaving testing and quality assurance as an afterthought today is a ticking financial bomb.

Cach dung 各位

関係各位: OK
各位： Không nên dùng độc lập mà viết ○○各位, 
   ví dụ xxxチーム各位、SSS株式会社各位、 従業員各位 
   nên dùng trong trường hợp ngang hàng
関係者各位: Người Nhật dùng phổ biến, tuy nhiên, 
   về mặt ngôn ngữ là không hợp lý vì có cả 者 và 位　
   (đồng nghĩa: đều có nghĩa là người)
各位 = 皆さん (nhẹ nhàng, informal hơn)
関係者各位様： tuy nhiên, về mặt ngôn ngữ là không hợp lý 
   vì có cả 者 = 位 = 様 cùng nghĩa
各位殿,関係者各位殿: Tương tự trên, có 違和感


Google:
関係各位: 4 triệu hit -> có vẻ phổ biến hơn
関係者各位: 1 triệu hit
関係者各位様: 382K hit, trong đó rất nhiều hit không match hoàn toàn.

Học tiếng Nhật: Sai cái sai giống y chang người Nhật (có lẽ nên như thế)

Is Ctr+P a good shortcut?

Thời kỳ chưa có chuột, nếu bố trí shortcut kiểu Ctrl+P (thông thường: In)
thì phối hợp ngón út cả hai tay. Khá tiện.

Đến thời kỳ có chuột, thông thường một tay phải dùng chuột
nên em nghĩ nếu muốn ấn Ctrl-P thì

1. Bỏ tay phải (nếu thuận tay phải) khỏi chuột, move tay phải đến phím P
   tay trái nhấn Ctrl

2. Move tay trái sang phía phải (dãy jkl;), dùng hai ngón tay trên bài tay trái nhấn Ctrl và P
   # Tay phải giữ nguyên chuột.

Cách nào cũng dở nhỉ?
Hay là nên thay phím P bằng một phím nào đó phía bên trái (asdf) để dễ bấm bằng
một bàn tay (trái) hơn?

Gartner Top Predictions for 2011: IT’s Growing

Đây là các dự đóan của Gartmer về IT năm 2011

1. Đến năm 2011, hạ tầng cơ sở của một nước G20 sẽ bị phá loại bởi các thế lực online
2. Đến năm 2011, thu nhập hàng năm từ IT được xác định bằng thu nhập hàng năm của các CIO mới nhất trên toàn thế giới năm 2000
3. Tới năm 2015, các doanh nghiệp thông minh về thông tin sẽ tăng chi tiêu về IT trên đầu người tới 60%
4. Tới nắm 2015, các công cụ và sự tự động hóa sẽ làm mất đi 25% lực lượng lao động về IT


7. Tới năm 2015, 20% số các công ty phi IT trong top 500 sẽ là các nhà cung cấp dịch vụ đám mây
8. Tới năm 2014, 90% số tổ chức sẽ hỗ trợ thiết bị tập hợp chương trình trên các thiết bị cá nhân
9. Tới năm 2013, 80% business sẽ có lực lượng lao động sử dụng tablet
10. TỚi năm 2015, 10% số "người dùng" online sẽ không phải là con người

Tham khảo: december_15_top_predictions_for_2011_dplummer.pdf

Vi sao nhan vien nghi viec

Theo một điều tra của một công ty cỡ lớn ở Nhật,
dưới đây là lý do vì sao nhân viên nghỉ việc

Nói chung không phải vì việc khó, mà chính vì cấp trên.
Nguyên nhân chính là

1. Cấp trên không chịu nghe ý kiến tư vấn của cấp dưới
2. Bị ép làm thêm "miễn phí"
3. Cách lãnh đạo không thuyết phục
4. Ép một cách chủ quan, không đủ thuyết phục.
5. Không hề quan tâm đến một số nhân viên


ホットライン窓口では「会社は好きだけど辞めたい。」という訴えに接することがあります。
仕事が厳しいから辞めたいのではありません。それどころか、仕事自体は楽しいというのです。
ではなぜ？それは、職場の環境です。上司への不満に堪えきれなくなっているのです。
 
具体的には、
上司が「部下の意見を聞く耳を持たない。」
「サービス残業を強要する。」
「納得できない指導をする。」
「根性論だけを押しつける。」
「一部の部下をことさら無視する。」などです。
このような不満で有為な人物を失うのは、組織としてみればとても大きな損失です。
 
人は、仕事が厳しくてもやりがいがあれば、満足感を感じるものです。
自分の成長を感じるときは、人はストレスを感じないといいます。
これまでの上司で、一番の人を思い出してください。
きっと「厳しくはあっても親身な指導で自分を成長させてくれた人」を思い起こすのではないでしょうか。
 
あなたは上司として、部下が気持ちよく働 くことができ、
また、成長できる環境を作るよう意識して いますよね。
疲労感や閉塞感を与えるのではなく、達成 感を与えるマネージャーであってください。

hien tai quoc gia chi nguyen khi

賢才国家之元気 (Hiền tài quốc gia chi nguyên khí), 
là câu của của tiến sĩ Thân Nhân Trung, người Việt Yên, Bắc Giang, lưu trong
大宝三年壬戊科進士題名碑記 năm 1484
(Đại Bảo tam niên Nhâm Tuất khoa tiến sĩ đề danh bi kí),
được coi là 一言興邦 (Nhất ngôn hưng bang), ảnh hưởng nhiều tới Lê Hiến Tông.

A letter to a CEO

Con người là yếu tố quan trọng nhất của một công ty. 
Đây là câu được viết trong Quốc Tử Giám: Hiền tài quốc gia chi nguyên khí
(賢才国家之元気)

Thâm niêm cũng quan trọng, nhưng năng lực là yếu tố quan trọng hơn.

適材適所. Dùng đúng người đúng chỗ.

Sự đổi mới và sáng tạo bị giết chết trong một môi trường thiếu dân chủ.

Quản lý nhân sự có trình độ đại học khác với quản lý công nhân xuất thân từ nông dân. 
Lập trình viên có tinh thần tự chủ. Những người không có khả năng này cần ra đi.

Mô hình tập đoàn/công ty con thích hợp nếu nhân sự tăng tới 80-100 người.
Tổ chức công ty theo mô hình này sẽ dễ dàng quản lý và mở rộng hơn.
Tin tưởng và giao quyền quyết định cho cấp dưới.

Chất lượng là vấn đề sống còn để cạnh tranh với các đối thủ outsourcing khác 
ở Việt Nam và Trung Quốc.

Công khai, minh mạch, tuyên bố rõ định hướng chủ trương của công ty (chính là chủ trương của CEO) để tạo sự hiểu nhất quán trong toàn tổ chức.

Chia sẻ. Thiếu tài chính: đi vay.

Xác định và tập trung vào core business.

Vượt qua chính mình, nỗ lực tự tiến bộ, chứ không phải vượt qua đối thủ cạnh tranh.