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.

Xac dinh do uu tien cua cong viec

Xác định độ ưu tiên công việc

Xác định độ ưu tiên công việc, liệt kê theo thứ tự giảm dần của độ ưu tiên

Những việc cần làm ngay, có deadline tính bằng vài giờ hoặc dưới 24 tiếng (1 ngày)

Những việc liên quan tới nhóm khác, người khác ngoài dự án mình đang tham gia

Những việc liên quan tới người khác trong nhóm của mình

Những việc của bản thân có deadline nhỏ hơn tính bằng đơn vị ngày (2+ ngày)

Công việc nội bộ không ảnh hưởng nhiều tới tiến độ dự án: training, phổ biến quy định, 
nghiệp vụ, review kết quả

Tieng Nhat business

Sửa Tiếng Nhật

Sửa thành thể viết tắt:

○○○の成果物を１月１４日に送付した。
○○○様からのレビュー結果を待っている。

○○○の成果物を１月１４日に送付済み。
○○○様からのレビュー結果待ち。

レビュー結果に従い、バッチのＵＴ結果を修正している
レビュー結果に従い、バッチのＵＴ結果を修正中


早速にファイルを送付して頂き、ありがとうございました。
⇒早速、ファイルの送付をありがとうございます。　(Không nên dùng ました trong trường hợp này)

何か不明点があれば、また連絡いたします。
⇒もしご不明な点がありましたら、お知らせください # Hay dùng, lịch sự hơn ご連絡下さい
⇒もしご不明な点がありましたら、ご一報下さい # Điệu hơn
⇒もしご不明な点がありましたら、ご連絡下さい # Trung lập, hay dùng nhất

ありましたら chứ không phải là あれば。

Google:
不明点があれば
不明点がありましたら

Haipad M1001

http://www.haipad.net/ProductShow.asp?ID=5 http://www.hiapk.com/index.php

Tao search thử rồi, cái HaiPad mà tao mua là cái này

http://www.haipad.net/ProductShow.asp?ID=5
http://www.tudou.com/programs/view/w59txS1H3gc/

Không rõ trang này
http://www.shanzhaiben.com/
có liên quan gì đến haipad?

đồ của bọn này dùng tạm được, nhưng bọn nó làm ẩu quá:
kể cả phần cứng lẫn phần mềm. Nếu muốn cải tiến thì phải
order chúng nó customize thêm phần cứng và cả phần mềm
(phần mềm thì tự mình làm được chút ít)

Hỗ trợ tiếng Anh, tiếng Nhật, Việt thiếu.
Tài liệu cũng hơi lởm khởm (search toàn ra tiếng Trung không đọc được)

À, nếu sang Thẩm Quyến từ VN thì đi thế nào tiện nhất?
Có cần VISA không? Nếu An có việc sang đấy thì rủ tôi đi cùng nhá.

On Fri, Dec 17, 2010 at 9:33 AM, Darren Cook <@dcook.org> wrote:
>
> >>  They aren't too tech-savvy so I though something
> >> wireless that connects to an online web album and can be controlled
> >> from a browser would be good.
> >
> > I would recommend a Google Android tablet combined with Flickr Droid.
>
> Is that a practical suggestion? Can you suggest a specific model, that
> is available to buy now? An android tablet is so much more than a photo
> frame, so if the price is competitive that would explain why no-one is
> bothering to make photo frames (at least, with wireless) any more!

This is what I am playing with:

# This is not a knockoff.
# This toy is for geeks but I think its slide show function will work
pretty well once properly configurated.

http://shop.apadjp.com/products/detail.php?product_id=12

The latest Android version is 2.3 but I think 2.1 works fine.
Because the OP only needs a slide show that can be connected to Internet,
most apad works well with Flickr Droid as I recommended in the previous post.

The price is 2 man - 2.5 man depends on the model, but I am sure you can get
a bargain if you go to あきばお(？) at weekend.

So far, Wi-Fi works well for me, 256 MB of RAM seems to be enough for me
for surfing web, viewing PDF files with Acrobat Reader (for Android)
and slide show.
However, for the PNG and JPG file with resolution 1000x800 needs 1-2 seconds to
be rendered and shown on the screen (too slow compared to iPad?, yes,
compare their CPU and RAM)

One thing I am not happy with is, battery. It seems to be optimized
for decoding mp3 and working offline.
However if you go online (communication needed), the battery will run
out in less than 2 hours).

HTH.

タッチ！うごく うたえほん

子育て中のママ＆パパ必見！！　ママたちがこどものために作ったアプリ
「うごく絵本」＋「うた」＋「手遊び」＋「カラオケ」＝それが！ 
「タッチ！うごく うたえほん」。人気の童謡を中心に10曲収録で盛りだくさん！
お子様を飽きさせない仕掛けや音がいっぱいです！




http://itunes.apple.com/jp/app/id408859672?mt=8#
http://app.joysound.com/sumahomama/

Khả năng

1. Chiều lòng khách hàng
2. Hỗ trợ tới mức kỹ thuật tới nhân viên cấp duới khi cần thiết
3. Khả năng ngôn ngữ Anh/Việt/Nhật (duy nhất), khả năng trình bày
4. Quản lý nguồn thông tin bằng các công cụ cần thiết
5. Gây ảnh hưởng gián tiếp
6. Chat có nội dung và không có nội dung
7. Chịu dựng áp lực công việc (kể cả mắng chửi :D)
8. Thay thế 4 người (2 quản lý trung gian và 2 phiên dịch viên) :)

flv to mp4 (iPhone) conversion

Under cygwin or a typical bash shell

ffmpeg version SVN-r20888

for file in *flv; do ffmpeg -i "$file" -s 320x180 "$file.mp4"; done

Lập trình không lỗi

"Lập trình không lỗi" là việc gần như không thể làm.
Ngay cả những công ty lớn và những lập trình viên siêu việt cũng gặp lỗi
vì họ không thể vượt qua quy luật:

"Mọi chương trình đều có ít nhất một lỗi".

Hệ quả: Nếu fix được "lỗi cuối cùng", sẽ xuất hiện "lỗi cuối cùng" tiếp theo.

Tips để lập trình ít lỗi hơn:

1. Architect it beautifully
-> Thiết kết dễ hiểu, đơn giản.
Nếu làm việc trên một hệ thống có sẵn, cần hiểu kỹ cấu trúc của hệ thống này.

2. Look at every single line of code and ask yourself "how could this go wrong?"
-> Kiểm lại lại từng dòng code.
Nói cách khác: Tự review code của chính mình.
# Trên thực tế, không phải mọi team đều có thời gian để review chéo code.

3. Keep careful track of your screwups in 2 and build systems to avoid them
Quản lý môi trường: Một version cũ, ngay trước đó, và version hiện tại.
Kết hợp sử dụng software configuration management software (như subversion)
để quản lý mã nguồn: Hôm qua code chạy được, nhưng không nay thì không? Vậy nguyên nhân ở đâu?

cf. http://inamidst.com/topic/bugfree

Luật Parkinson

Đây là luật Parkinson, đơn giản như một nghịch lý nhưng rất đúng.
Cần áp dụng triệt để khi giao việc:

Work expands so as to fill the time available for its completion.
-> Người giao việc có thể cắt ngắn deadline tới mức không thể ngắn hơn.

Data expands to fill the space available for storage.
-> Ổ cứng chứa toàn dữ liệu thừa có thể xóa được.

The demand upon a resource tends to expand to match the supply of the resource.
-> Tiền bao nhiêu cũng đủ, dù là "ít" hay "nhiều".

Tuyển người qua hành vi

Đây là một vài tip khi phỏng vấn, các bạn tham khảo: Trong tuyển dụng nhân sự, phương pháp phỏng vấn dựa trên khoa học về hành vi đã chứng tỏ được tính ưu việt hơn hẳn so với phỏng vấn truyền thống.

Văn Hóa

Phương pháp này có tên đầy đủ theo tiếng Anh là Behavioral Event Interview (BEI), là tiến trình phỏng vấn theo một cấu trúc nhằm giúp dự đoán chính xác hơn tiềm năng của ứng viên cho sự thành công trong công việc sau này. BEI có nguồn gốc từ nghiên cứu của Hải quân và Không quân Mỹ vào thập niên 1940. Theo đó, khi khảo sát về tính hiệu quả trong chiến đấu của lực lượng trong ngành, các chuyên gia đã đưa ra kết luận rằng chính hành vi, chứ không phải kiến thức về kỹ thuật, đã tạo nên sự khác biệt của từng cá nhân.

Tại hội thảo “Phát huy sức mạnh nguồn nhân lực để hội nhập WTO”, do Trung tâm Huấn luyện Thành công và Hạnh phúc, TPHCM tổ chức, bà Kee May Lee với hơn 15 năm kinh nghiệm trong lĩnh vực phát triển con người đã chia sẻ phương pháp phỏng vấn dựa trên khoa học về hành vi. Theo bà Lee, BEI là một quá trình phỏng vấn theo hệ thống, nhằm giúp nhà tuyển dụng có được những thông tin thiết thực và khách quan về ứng viên. Nói cách khác, BEI sẽ “dò tìm” sự tương thích cao nhất giữa ứng viên và công việc tuyển dụng. Vì thế, khi áp dụng phỏng vấn BEI doanh nghiệp sẽ giảm bớt thời gian đào tạo nhân sự, đồng thời hạn chế tối đa mức độ bỏ việc đột xuất của nhân viên.

BEI có gì khác so với phỏng vấn truyền thống? Bà Lee giải thích, phỏng vấn truyền thống thường đưa ra những câu hỏi dựa trên “cảm nhận” hoặc “giả định” đối với ứng viên. Chẳng hạn: “Bạn có cho rằng mình có lợi thế về kỹ năng phục vụ khách hàng?”; “Bạn sẽ làm gì nếu gặp phải một khách hàng khó tính?”… Trong khi đó, BEI sẽ hướng đến những câu hỏi cụ thể hơn: “Hãy kể cho tôi nghe một trường hợp khi bạn gặp phải một khách hàng khó tính”; “Lúc đó bạn đã xử lý tình huống như thế nào?”; “Kết quả ra sao?”… Do vậy, phỏng vấn BEI đòi hỏi nhà tuyển dụng phải chuẩn bị kỹ trước, trong và sau khi phỏng vấn. Trước cuộc phỏng vấn, nhà tuyển dụng sẽ chuẩn bị bảng mô tả công việc (trách nhiệm phải thực hiện và tiêu chuẩn để đánh giá công việc); đọc bản lý lịch tóm tắt (resume) của ứng viên; lập bảng câu hỏi phỏng vấn và bảng đánh giá phỏng vấn. Khi tiến hành phỏng vấn, nhà tuyển dụng phải chia sẻ với ứng viên về các bước tiến hành phỏng vấn; đặt những câu hỏi về hành vi trong quá trình làm việc trước đây của ứng viên; sử dụng quy tắc “10 giây” (nhằm tránh buộc ứng viên phải trả lời ngay câu hỏi, hoặc để ứng viên suy nghĩ quá lâu); ghi chú những thông tin thiết thực từ ứng viên.

Cụ thể, nhà tuyển dụng nên thông báo cho ứng viên về thời lượng cuộc phỏng vấn; cho họ biết những câu hỏi cụ thể sẽ được nêu và khuyên họ đừng vội trả lời vì thông tin của họ sẽ được ghi lại; cuối buổi phỏng vấn họ có thể đặt câu hỏi với nhà tuyển dụng… Nhà tuyển dụng cần làm cho ứng viên thấy thoải mái và thư giãn bằng cách đặt câu hỏi với thái độ tôn trọng và chờ họ trả lời; kiên nhẫn lặp lại câu hỏi hoặc diễn đạt cho rõ nghĩa hơn; lắng nghe chăm chú và ghi chép những gì ứng viên nói. Sau khi phỏng vấn xong, nhà tuyển dụng cần xem lại những ghi chép của mình đã được hệ thống chưa, và phải hoàn tất ngay bảng đánh giá phỏng vấn. Bà Lee cho biết nhiều nhà tuyển dụng đã không làm điều này, vì thế thông tin về các ứng viên có thể bị lẫn lộn nếu tiến hành phỏng vấn nhiều người.

Làm sao đặt câu hỏi về hành vi trong quá khứ của một người? Theo bà Lee, nhà tuyển dụng nên phối hợp giữa các dạng câu hỏi mở, thăm dò và câu hỏi đóng. Câu hỏi mở nhằm lấy thông tin về tình huống xảy ra, việc xử lý và kết quả đạt được nên thường nhẹ nhàng như gợi mở những tâm sự: “Kể cho tôi nghe về sự kiện đó…”, “Bạn có thể chia sẻ với tôi về tình huống…”. Câu hỏi thăm dò nhằm đột phá vào các câu trả lời chung chung của ứng viên nên thường dưới dạng 4W+1H (Cái gì? Ở đâu? Khi nào? Ai? Như thế nào?). Tuy nhiên, nhà tuyển dụng nên tránh câu hỏi “Tại sao?” - vì dễ khiến ứng viên nảy sinh cảm giác đề phòng, đối phó, từ đó thông tin cung cấp sẽ không trung thực. Câu hỏi đóng nhằm xác nhận, làm rõ vấn đề nên thường ngắn gọn: “Thật vậy chứ?”.

Trên thực tế, bước vào cuộc phỏng vấn hầu như ứng viên nào cũng cảm thấy bối rối, lo lắng hoặc thậm chí căng thẳng. Lý do là vì họ muốn tạo ấn tượng tốt với nhà tuyển dụng để được thâu nhận. Nhưng chính những bất ổn tâm lý này đã khiến họ không thể suy nghĩ thấu đáo mọi vấn đề, từ đó câu trả lời ít nhiều bị sai lệch.

Trong phỏng vấn BEI, vấn đề khuyến khích ứng viên đưa ra các thông tin vừa chính xác vừa có tính sự kiện rất được quan tâm. Và các nhà tuyển dụng đã được khuyên hãy tạo không khí thoải mái cho ứng viên; hãy tỏ ra tôn trọng, hỗ trợ và động viên tinh thần của họ. Nhưng nhà tuyển dụng nên làm thế nào để tỏ thái độ tôn trọng và hỗ trợ ứng viên? Bà Lee cho biết trong vòng luân chuyển các dạng câu hỏi mở, thăm dò và đóng của phỏng vấn BEI, nhà tuyển dụng nên xen kẽ bằng những câu hỏi dạng trấn an, diễn đạt cho rõ nghĩa hoặc lặp lại ý vừa nêu. Chẳng hạn như trong câu trấn an nhằm khuyến khích ứng viên cố nhớ lại một sự kiện trong quá trình làm việc trước đây, nhà tuyển dụng có thể nói: “Tôi biết rất khó nhớ lại những chuyện đã qua, nhưng bạn đừng quá căng thẳng, chúng ta còn thời gian…”.

Bên lề cuộc hội thảo trên, một số doanh nghiệp nước ngoài đã chia sẻ những kinh nghiệm thực tế trong việc áp dụng phương pháp phỏng vấn BEI. Theo họ, tuy BEI đã có những câu hỏi sát sườn với công việc thực tế của ứng viên nhưng vẫn có những người giỏi “bịa chuyện”, có thể nêu ra những tình huống rất thật được cóp nhặt từ đâu đó. Vì thế, phỏng vấn BEI nên được kết hợp với việc thực hành tình huống thật, chẳng hạn tuyển tiếp tân thì đề nghị ứng viên thực hành tình huống nghe điện thoại; tuyển bán hàng thì không gì “thật” hơn buộc ứng viên vào vai nhân viên công ty trong một tình huống được sắp đặt sẵn… Ngoài ra, câu hỏi thăm dò trong phỏng vấn BEI chỉ nên có từ hai đến ba câu cho từng ứng viên và nhà tuyển dụng phải ghi chép thật chính xác lời ứng viên nói. Dấu hiệu cho thấy buổi phỏng vấn thành công là ứng viên… nói nhiều hơn nhà tuyển dụng, theo một tỷ lệ là 80% (cho ứng viên) và 20% (đối với nhà tuyển dụng).

Theo KINH TẾ SÀI GÒN

Software Outsourcing Hidden Cost

Xét cho cùng, outsourcing sang Việt Nam không hiệu quả nếu không biết cách làm. http://spreadsheets.google.com/pub?key=0AgOqPQzRjQPOdDA4R0NNUTgxSnNzV1Zmd0JRYUt1c2c&hl=ja&single=true&gid=0&output=html

Điểm quan trọng khi phân tích yêu cầu dự án (mức business)

Điểm quan trọng khi phân tích yêu cầu dự án (mức business)

* Mô tả yêu cầu câu việc thật ngắn gọn.
* Phát biểu các mục tiêu quan trọng của dự án.
* Mô tả môi trường mà hệ thống sẽ chạy.
* Các thông tin "hậu trường" và các tài liệu liên quan quan trọng.
* Thông tin về các ràng buộc thiết kế chính.

Ngoài ra,

1. Đừng nghĩ mình hiểu đúng khách hàng muốn gì. Phải hỏi.
2. Đưa người dùng tham gia dự án từ đầu.
3. Bản ghi nhớ, đồng ý giữa các bên về phạm vi dự án.
4. Đảm bảo rằng các yêu cầu dự án cụ thể, thực tế (thực thi được) và đo đếm được.
5. Rõ ràng, không có điểm nghi vấn.
6. Tạo tài liệu yêu cầu dự án rõ rằng, ngắn ngọn và chia sẻ với khách hàng.
7. Xác nhận sự hiểu của mình về dự án với khách hàng.
8. Tránh đề cập tới công nghệ hay giải pháp cho tới khi yêu cầu được làm rõ.
9. Bản ghi nhớ: Được sự đồng ý của các bên liên quan ngay từ khi dự án bắt đầu.
10. Tạo bản prototype để khách hàng có thể hiểu rõ hơn yêu cầu