Grammar 2.8

Đã có Grammar2.8 rùi tải về thôi ^^

http://sites.google.com/site/grammar1997/tai-grammar

Get link Youtube & flv2mp3

Lâu quá ko post bài hôm nay giới thiệu với mọi người địa chỉ để get link youtube mà mình thường dùng :

http://feelingtea.com/

và phần mềm convert định dạng flv sang mp3

http://www.smallvideosoft.com/flv-to-mp3/

Chúc vui ^^

Thiết kế lưới

Tìm hiểu và áp dụng thư xem

http://www.thegridsystem.org/

Văn hóa trích dẫn

TTCT – Khi dạo blog, bạn không thích điều gì? Bạn không thích những blog dùng kiểu chữ “teen” rối mắt? Hay bạn không thích những blog dùng thứ tiếng Việt “online” lạ lẫm?

Còn tôi, tôi hết sức khó chịu khi vào những blog đăng lại bài viết/bài báo/ thơ/nhạc… của người khác mà không ghi nguồn trích dẫn! Thậm chí những ai để cái cụm “sưu tầm” không, tôi cũng thấy phản cảm. Thời đại Google, chỉ cần gõ một câu trong tác phẩm là có thể biết được tên tác giả. Thao tác rất đơn giản. Nếu bạn đã là một blogger, một người dùng Internet thường xuyên thì bạn không thể nói thao tác ấy là quá sức của mình được!

Mà không chỉ trên blog, khi cầm trong tay tập san kỷ niệm ngày thành lập của một trường đại học nổi tiếng, tôi cũng cảm thấy hơi xấu hổ giùm cho một số tác giả có bài đăng trong đó. Dù rất đáng khen là dân kỹ thuật nhưng thuộc thơ văn khá nhiều. Tuy nhiên, đã là dân kỹ thuật, dân làm khoa học (ít nhất cũng đã viết xong luận văn tốt nghiệp rồi) thì họ phải hiểu hơn ai hết nguyên tắc ghi nguồn trích dẫn.

Lần đầu nộp báo cáo ở Pháp, việc đầu tiên tôi bị thầy chỉnh sửa chính là cách ghi trích dẫn. Ghi chú tài liệu trích dẫn phải được đặt ngay sau ý mà mình trích dẫn. Tài liệu trích dẫn phải ghi đầy đủ tên tác giả, nhà xuất bản, tạp chí, năm phát hành… Điều đấy không chỉ thể hiện thái độ trân trọng với sáng tạo của người khác, mà còn tạo điều kiện dễ dàng cho công tác tra cứu sau này.

Khi viết một báo cáo như vậy, chỉ cần một ý nhỏ tham khảo từ người khác đưa vào hỗ trợ cho ý chính (trong một đoạn nhỏ của cái tác phẩm lớn của bạn) là bạn đã có nghĩa vụ phải biết ơn tác giả của ý nhỏ đó rồi. Đằng này, có bạn lấy nguyên một khổ thơ, một câu danh ngôn… mà chẳng thèm ghi tên ai, cứ như đó là sáng tác của mình thì đấy không còn là biểu hiện của sự vô tình, đấy là biểu hiện của cái mà dân gian hay gọi là… “cầm nhầm”!

Đáng buồn thay, việc “tiết kiệm mực” không ghi nguồn trích dẫn chẳng phải là một hiện tượng, mà là một thực trạng. Điển hình, đọc tập san mà tôi đề cập ở trên sẽ thấy đầy rẫy “thơ chùa”, đọc cứ tưởng… ca dao (mà thật ra dùng ca dao cũng phải ghi thêm chữ “ca dao” ở trong ngoặc đơn)!

Quay lại thế giới blog, việc “giả đò làm ngơ” khi xài “hàng lượm” nhiều khỏi phải nói! Thỉnh thoảng thấy có vài blog ghi blast kèm theo tên tác giả, mừng quá, nhìn kỹ lại mới thấy đó là blog của những người hay có bài bị chôm nhất: blog của nhà thơ Đỗ Trung Quân, blog của nhà văn Nguyễn Quang Lập… Có lẽ hơn ai hết, họ hiểu nỗi đau bị “cầm nhầm” là như thế nào, nên dù chỉ mượn cái tứ nhỏ nhoi họ vẫn lịch sự ghi nguồn trích dẫn!

Không khó gì khi dùng Google để tìm tên tác giả. Càng quá dễ để viết một cái tên vào trong một dấu ngoặc ở cuối blast/entry của bạn. Cho nên đừng để dễ dàng đánh mất sự trân trọng với lao động của người khác, cũng như lòng tự trọng của chính bản thân bạn!
LÊ PHAN

www.tuoitre.com.vn

Trưởng dự án phần mềm: Bản lĩnh – Trách nhiệm!

Trong một dự án phát triển phần mềm (PM) nói riêng, trưởng dự án (Project Manager) là người chịu trách nhiệm cao nhất về kết quả dự án.

Project Manager là tinh thần của dự án

Bất kỳ một dự án lớn nhỏ nào cũng cần một người đứng ra chịu trách nhiệm tổ chức, triển khai và thực hiện… Người giữ vai trò này được gọi là người quản lý dự án hay giám đốc dự án (Project Manager). Vì vậy, Project Manager cần phải am hiểu dự án và thật sự bản lĩnh để đảm bảo tiến độ triển khai và giải quyết những vấn đề nảy sinh để dự án đạt hiệu quả, hoàn thành đúng với quy trình và ngân sách dự kiến.

Nếu Project Manager ít kinh nghiệm, chưa hiểu quy trình, chưa được đào tạo bài bản về nghiệp vụ và nhiều lúc làm theo cảm tính thì chất lượng dự án không được như ý muốn và có thể sẽ đi đến thất bại…

Quy trình sản xuất PM cũng không khác biệt so với việc sản xuất một sản phẩm cụ thể. Để có một sản phẩm PM tốt, ngoài các kỹ năng làm việc, các nhân sự trong từng vị trí của dự án phải hiểu rõ cụ thể công việc mà mình thực hiện, trách nhiệm và thời gian hoàn thành khối lượng công việc đó. Vai trò của từng vị trí trong dự án PM rất quan trọng, công việc có lúc cần phải xử lý tuần tự, nhưng đa phần là xử lý song song đồng loạt các vấn đề. Đây chỉ là những công việc rời rạc, nhiệm vụ cụ thể mà mỗi cá nhân cần phải thực hiện. Project Manager là người điều phối, gắn kết các bộ phận rời rạc này lại, đồng thời giải quyết mâu thuẫn nội bộ phát sinh để đưa ra giải pháp khả thi nhất. Làm thế nào để nhân viên (NV) chấp nhận thực hiện? Thuyết phục và làm cho khách hàng tin tưởng vào sự tư vấn, quy trình và công nghệ dự án có thể đáp ứng cho họ…

Tùy thuộc vào yêu cầu, độ phức tạp của dự án, Project Manager cùng với các cộng sự lên kế hoạch cụ thể cho từng giai đoạn: Phân chia số lượng công việc, dựa vào sự hiểu biết về công nghệ, khả năng của từng nhân sự trong dự án để có thể ước lượng chính xác thời gian hoàn thành cũng như chi phí cho từng dự án.

Ông Nguyễn Minh Quang, Project Manager có hơn 5 năm kinh nghiệm thuộc trung tâm Phần Mềm HPT, cho biết, Project Manager được xem là thủ lĩnh tinh thần của dự án. Mọi công việc không phải tự mình quyết đoán thiếu khoa học, thiếu thực tiễn. Khi gặp vấn đề phức tạp, nan giải cần phải thống nhất ý kiến trong toàn đội dự án, cùng nhau tìm hiểu cách khắc phục và lựa chọn giải pháp tối ưu nhất cho khách hàng… Đối với những đơn vị, doanh nghiệp (DN) triển khai là đối tác của các nhà cung cấp giải pháp như Microsoft, Oracle… thì việc hỗ trợ công nghệ, công cụ mới không có gì khó khăn nhưng cần phải phát huy nội lực sẵn có từ bên trong.

Áp lực và niềm vui

Ông Nguyễn Minh Quang

Công việc nào cũng có những đặc thù và áp lực riêng của nó. Do yêu cầu của PM thay đổi (điều này rất thường xảy ra), dự án có thể thêm hoặc giảm bớt nhân sự. Khi tăng nhân sự, Project Manager có thể yêu cầu tuyển nhân sự từ các dự án khác trong DN hoặc kéo dài thời gian dự án hay vận động NV làm thêm giờ để đảm bảo hoàn thành đúng tiến độ dự án.

Theo nhận xét của ông Quang, Project Manager hoàn toàn là nghề không dễ dàng! Vừa làm việc theo nguyên tắc đúng với kế hoạch đề ra, tinh thần kỷ luật cao để đảm bảo tiến độ và chất lượng dự án thì người làm Project Manager cũng cần mềm dẻo, uyển chuyển và linh động. “Quản lý máy móc có thể dễ dàng nhưng để kết hợp quản lý con người gắn với công nghệ, biến những bài toán thực tế, gắn liền với nghiệp vụ kinh doanh của khách hàng, cần nhất kiến thức để thuyết phục khách hàng gần như là một nghệ thuật trong lĩnh vực CNTT”.

Ông Quang cho biết thêm, đã từng trải qua nhiều vị trí khác nhau nên hiểu được phần nào tâm tư nguyện vọng của các thành viên, quan tâm sát sao công việc của NV và mỗi khi dự án kết thúc (chuyển giao sản phẩm cho khách hàng) toàn đội dự án có thể tổ chức liên hoan hoặc dã ngoại nhằm gắn kết mọi người, tổng kết và chia sẻ kinh nghiệm kiến thức từ dự án thực hiện. Điều này thật sự cần thiết trong ngành làm dự án PM!

Công việc thường làm của một Project Manager 1. Hoạch định kế hoạch: Bố trí nhân sự và thời gian hợp lý; Thu thập và quản lý yêu cầu; Quản lý rủi ro (rủi ro từ phía khách hàng, nhân sự trong dự án, rủi ro công nghệ…); Xây dựng quy trình; Tài liệu dự án và các bộ mã nguồn liên quan (nếu có); Dự kiến hướng phát triển của sản phẩm… 2. Tổ chức thực hiện: Làm việc với nhóm chuyên gia phân tích thiết kế hệ thống; Theo dõi và cập nhật rủi ro; Kiểm soát quy trình; Quản lý sự thay đổi yêu cầu; Quan hệ nhà thầu phụ; Cập nhật công nghệ mới; Giao ban và đôn đốc NV cùng thực hiện 3. Kiểm tra giám sát: Kế hoạch và tổ chức hoạt động kiểm tra, giám sát các nhóm, tiến độ thực hiện công việc; Báo cáo và đề xuất lãnh đạo… 4. Công tác khác: Tham gia tổ chức thực hiện các chương trình đào tạo nội bộ cho NV; Tư vấn cho khách hàng khả năng phát triển của dự án một cách tích cực, chủ động…

Project Manager trưởng thành qua từng dự án

Ông Nguyễn Thành Châu

Ông Nguyễn Thành Châu, chuyên viên tư vấn và đào tạo cao cấp tập đoàn ECCI Group (Philippines) cho biết, nhu cầu cho các vị trí quản lý dự án PM là rất lớn. Các công ty, DN thực hiện triển khai PM, ngay cả các công ty ứng dụng CNTT cũng cần vị trí Project Manager để thực hiện các dự án phát triển PM dùng riêng cho ngành nghề đặc thù của DN. Trong giai đoạn khó khăn hiện nay, nhu cầu Project Manager có thể giảm. Thay vào đó, các DN PM sử dụng nhân sự hiện có đã qua đào tạo để kiêm nhiệm nhằm giảm chi phí triển khai.

Hầu hết, Project Manager trong các DN PM Việt Nam từ chuyên viên phát triển PM trưởng thành qua những dự án, rồi đến vị trí trưởng nhóm (Team Leader). Từ team leader có thể kiêm nhiệm, tập sự và học kinh nghiệm thực tế từ quản lý những dự án nhỏ, sau đó sẽ đảm đương vị trí Project Manager thật sự.

Theo ông Châu, các trường đào tạo CNTT chuyên ngành PM, hệ thống thông tin ở Việt Nam đều có giảng dạy môn quản lý dự án PM nhưng chỉ mang tính lý thuyết, giới thiệu quy trình phát triển PM… Chỉ tính riêng ngành PM ở Hoa Kỳ thì có 3 chuyên ngành chính: kỹ sư khoa học máy tính (Computer Science), hệ thống thông tin (IS – Information System), kỹ sư PM (Software Engineering). Trong đó, chuyên ngành kỹ sư khoa học máy tính gần giống như chương trình đào tạo CNTT ở Việt Nam. Ngoài ra, tùy theo từng dự án, khả năng của mỗi người và chính sách của từng công ty, một NV phát triển PM trở thành người quản lý dự án thời gian trung bình có thể từ 4 đến 5 năm. Cá biệt những công ty không có nhân sự cho vị trí Project Manager thì sẽ có ít nhất 1 NV kiêm nhiệm và đây cũng là cơ hội cho NV đó học hỏi cách quản lý của Project Manager. So với thị trường Mỹ, một Project Manager cần từ 8 đến 10 năm để phấn đấu: một kỹ sư PM mới ra trường sẽ đảm nhận vị trí NV kiểm thử PM (Tester) trong 2 năm, sau đó là NV hỗ trợ PM và phải mất thêm 2 năm để trở thành NV phát triển PM. Vị trí này cần thêm 4 năm để trở thành trưởng nhóm PM (Team Leader) và thêm 2 năm nữa để đạt vị trí Project Manager.

Các chương trình đào tạo bổ sung kiến thức cho Project Manager 1. TUV Rheinland Việt Nam kết hợp với ECCI tổ chức khóa học quản lý dự án CNTT trong 3 ngày từ 8/4/2009 đến 10/4/2008, học phí (bao gồm tài liệu): 4.650.000 đồng. 2. Liên hiệp 5 trường ĐH và trung tâm đào tạo CNTT Việt Nam (viết tắt là SEG Vietnam, bao gồm ĐH dân lập Duy Tân – Đà Nẵng, ĐH dân lập Văn Lang – TP.HCM, ĐH Cần Thơ – Cần Thơ, công ty cổ phần Công Nghệ Viễn Thông Kỹ Thuật Số (DTT-HanoiCTT), trung tâm Đào Tạo CNTT TP.HCM) cùng với ĐH Carnegie Mellon (Hoa Kỳ, CMU) triển khai chương trình đào tạo: quản trị dự án PM; kiểm thử và đảm bảo chất lượng PM; kỹ năng lập trình…

(Theo PCWorld VietNam)

CV là gì ?

Một sơ yếu lý lịch, còn có tên thông dụng trong ngôn ngữ phương Tây là résumé, curriculum vitae hay CV, là một văn bản tóm tắt hay liệt kê các kinh nghiệm làm việc và quá trình giáo dục của một cá nhân, thường là một phần quan trọng trong hồ sơ xin việc làm. Tờ sơ yếu lý lịch thường được xem xét đầu tiên bởi nhà tuyển dụng khi nhận hồ sơ của một người xin việc; nó đóng vai trò cung cấp thông tin quan trọng cho người thuê nhân công và nên được chuẩn bị cẩn thận bởi ứng viên.

* Đặc điểm chung:

Một sơ yếu lý lịch nói chung là ngắn gọn (một hoặc hai trang), chỉ chứa các kinh nghiệm làm việc trực tiếp liên quan đến công việc ứng thí. Một số sơ yếu lý lịch dùng các từ khóa mà người thuê nhân công có thể đang tìm, có xu hướng tô đẹp thêm cho ứng viên, chứa các từ ngữ thể hiện nhiệt huyết.

Thông thường, các sự kiện được liệt kê theo thứ tự thời gian; ngược hoặc xuôi. Tuy nhiên, có sơ yếu lý lịch sắp xếp kinh nghiệm làm việc theo các chủ đề, ví dụ như cho sinh viên chưa có bề dày làm việc, nhưng muốn nhấn mạnh các nhóm kỹ năng thu được qua các khóa học và đợt thực tập.

Ngày nay, các sơ yếu lý lịch hay có thêm mục kể về các khả năng làm việc với máy tính (ví dụ như soạn thảo văn bản) do máy tính đang được ứng dụng ngày càng rộng rãi trong mọi lĩnh vực.

*Việt Nam:

Ở Việt Nam hiện nay, nhiều khi các nhà tuyển dụng yêu cầu các sơ yếu lý lịch phải được đóng dấu chứng nhận và ký của Ủy ban Nhân dân phường, Ủy ban Nhân dân xã, hay một cơ quan có uy tín. Đôi khi các Ủy ban Nhân dân chỉ chứng nhận khi sơ yếu lý lịch được điền theo đúng một khuôn mẫu in sẵn. Mẫu in sẵn có thể có mục về lịch sử gia đình.

*Mỹ:

Từ “curriculum vitae” ở Mỹ mang ý nghĩa của một bản tự giới thiệu bản thân, có thể dài hơn vài trang; ngoài chứa thông tin về kinh nghiệm làm việc, quá trình giáo dục, các bài xuất bản, các giải thưởng đạt được,… nó còn có thể chứa thêm ví dụ về các công trình đã làm bởi ứng viên. CV kiểu này hay được các nhà tuyển dụng về nghiên cứu khoa học hay y khoa yêu cầu.

Từ résumé có ý nghĩa gần với sơ yếu lý lịch hơn, thường chỉ ngắn gọn một đến hai trang, thích hợp với tuyển dụng kinh doanh thông thường. Từ résumé thường bị thay thế bằng một hình thái đơn giản hơn của nó (chủ yếu là bởi các người Mỹ không phát âm được tiếng Pháp) như resumé hay ngay cả resume.

CV ở Mỹ còn có một số đặc điểm sau:

- Không khuyến khích kèm ảnh chụp cá nhân trong CV, trừ ngành nghệ thuật biểu diễn.

- Các CV cho vị trí nghiên cứu khoa học hay liệt kê các sự kiện cũ nhất trước.

- Các ngành khác liệt kê sự kiện mới nhất trước.

- Trước thập niên 1990, dòng đầu tiên hay ghi mục đích ứng cử. Ngày nay công thức này đã lỗi thời.

*Anh:

Tại Anh, từ “curriculum vitae” hay “CV” là các từ tiêu chuẩn được sử dụng, thay cho từ “résumé” của Mỹ.

*Đức:

Tại các nước nói tiếng Đức, một CV bao giờ cũng phải kèm theo hình ảnh chân dung của người đứng đơn.

*Pháp:

Thông thường, các CV ở Pháp phải luôn được kèm theo lettre de motivation (tạm dịch là đơn xin), trong đó nói thêm về cá nhân (nhiệt huyết, các điểm mạnh và những gì người xin việc có thể mang đến), các yêu cầu và các mong đợi, và tất nhiên đề nghị được gặp gỡ và chào hỏi theo công thức.

*Ngoại lệ:

Các nghệ sĩ có thể viết CV khá dài và có thể theo các định dạng sáng tạo không theo khuôn mẫu, và thêm thông tin về các biểu diễn hay trưng bày cá nhân hoặc theo nhóm.

(Bách khoa toàn thư mở Wikipedia)

ORM and Code generation for persistent layer – which one is better?

Object Relation Mapping là kĩ thuật ánh xạ từ mô hình hướng đối tượng xuống cơ sở dữ liệu quan hệ.
Code generation for persistent layer là kĩ thuật sinh code từ các bảng cơ sở dữ liệu quan hệ dưới database ra tầng persistent để giao tiếp với hệ quản trị cơ sở dữ liệu. Trong bài viết này tôi không đề cập đến khái niệm code generation chung chung – mà muốn đề cập đến những framework gen code cụ thể cho persistent layer hiện nay như Net Tier.
Đã có rất nhiều người hỏi tôi rằng ORM (Object Relation Mapping) và Code generation for persistent layer – cái nào tốt hơn? Và khi nào thì dùng ORM, khi nào ta nên sử dụng các tool gen code cho persistent layer .
Thực tình mà nói – tôi không dám khuyên bạn sử dụng công cụ nào – nếu tôi không biết dự án bạn đang làm là gì? và nguồn lực bạn đang có ra sao?
Tôi đã đánh hơn 5 dự án sử dụng Hibernate (kể cả NHibernate của .NET), 1 dự án sử dụng iBatis của Java. Với những nền tảng đó – tôi tương đối hiểu sâu về những kĩ thuật và cách thức tương tác với các ORM framework.
Dự án đầu đời mà tôi bắt tay làm – tôi sử dụng MyGeneration (một công cụ gen code) để sinh ra persistent layer cho .NET. Tôi cũng nghiên cứu khá kĩ về các tool gen code đang sử dụng phổ biến trong cộng đồng open source (.NET cũng như Java). Với những kinh nghiệm đó, tôi muốn chia sẻ với các bạn những gì tôi đã từng trải qua. Hy vọng có thể đóng góp được những điều bổ ích và thú vị cho các bạn.
Những ưu điểm và nhược điểm của ORM
Trước tiên ta tạm xét những ưu điểm nổi trội của các framework ORM hiện nay:
Độc lập hệ quản trị cơ sở dữ liệu. Điều này hẳn ai cũng biết – hầu hết các framework ORM luôn được thiết kế để độc lập với các hệ quản trị cơ sở dữ liệu quan hệ. Chỉ cần thay đổi driver tương tác là bạn có thể giao tiếp với một database khác mà không phải thay đổi bất kì dòng code nào.
Cung cấp các API đơn giản – dễ dùng. Lập trình viên không cần phải nhớ mình nên select, update bao nhiêu field cho lọai đối tượng nào, chỉ cần sử dụng thành thạo các hàm Save, Load, Query, Update + một ngôn ngữ query ORM (nếu như framework ORM hỗ trợ – ví dụ ngôn ngữ HQL của Hibernate).
Giúp cho bản thiết kế của bạn gần gũi hơn với lập trình viên – vì đi theo tư duy OOP khi thiết kế entity cho persistent layer. Lập trình viên chỉ cần nắm được sơ đồ thiết kế lớp là đã có thể implement dễ dàng.
Bảng thiết kế sẽ linh động – chi phí trả giá cho việc sửa code khi thay đổi model ít hơn so với sử dụng các tool gencode để sinh ra persistent layer.
Vậy nhược điểm của các ORM là gì?
Nếu thiết kế không đúng cách bạn sẽ trả giá rất lớn về performance.
Các ORM thường gen ra sql để insert, update, query phía bên dưới – nên đôi khi bạn khó can thiệp sâu để optimize performance. Thông thường các ORM framework vẫn hỗ trợ ta gọi câu sql trực tiếp xuống database trong những tình huống cần thiết
Bạn sẽ phải đối đầu với rất nhiều tình huống nan giải mà bất kì ai làm việc với ORM cũng phải gặp qua: cách thức quản lý session truy xuất của ORM – nếu bạn làm việc với Web project, lazy loading, tình huống load tòan bộ database lên nếu không thiết kế đúng cách, …
Để nắm bắt được cách thiết kế tối ưu cho ORM và có thể control được một ORM framework đòi hỏi phải có một thời gian làm việc lâu dài – không phải chỉ trong một sớm một chiều mà đạt được. Vì vậy bạn khó tìm được nguồn nhân sự nắm vững về ORM cho dự án (ở Việt Nam).
Đôi khi bạn sẽ thấy cấu trúc bảng quan hệ bên dưới database rất khó quản lý – nếu như bạn lạm dụng việc kế thừa quá nhiều trong thiết kế class cho ORM.
Những ưu điểm và nhược điểm của việc sử dụng các tool gencode cho Persistent layer
Để dễ đọc tôi tạm viết tắt cụm từ “việc sử dụng các tool gencode cho Persistent layer” thành PLCG – Persistent Layer Code Generation.
Ưu điểm:
Code được sinh ra một cách tường minh – bạn có thể dễ dàng thay đổi và optimize tùy thích.
Ít gặp vấn đề về performance.
Dễ dàng tìm được nguồn nhân sự phục vụ dự án. Chỉ cần người có thể nắm vững các kĩ năng truy vấn database – và người có kinh nghiệm sử dụng code generation tool (cách sử dụng code generation tool cũng rất đơn giản).
Nếu bạn là một người phụ trách việc quản lý dữ liệu trên database – bạn sẽ thấy cấu trúc bảng quan hệ bên dưới “thân thiện hơn và dễ quản lý hơn”.
Nhược điểm:
Khi bạn đối đầu với những cấu trúc phức tạp về model, những quan hệ business rule chằng chịt thì những tool gen code không đủ sức đáp ứng nhu cầu của bạn nữa. Khi đó bạn phụ thuộc rất nhiều vào cấu trúc bảng phức tạp dưới database – khả năng sử dụng tool gen code sẽ ít đi, mà thay vào đó bạn phải viết những hàm xử lý tách biệt nhiều hơn.
Khi cấu trúc của model thay đổi – nếu như bạn đã có sửa đổi code trong các class ở persistent layer, bạn gần như không thể gen code lại mà buộc phải sửa đổi trong các hàm đã gen ra. Điều gì xảy ra – nếu như việc thay đổi không chỉ là thêm/bớt field mà thay đổi cả mối quan hệ phụ thuộc giữa các bảng => Kết quả tất yếu là chi phí sửa đổi code sẽ cao hơn so với sử dụng các framework ORM.
Sau khi phân tích một số ưu khuyết điểm của 2 xu hướng trên, ắt hẳn bạn sẽ hỏi tôi: “vậy khi nào thì dùng cái nào?”… Dưới đây là câu trả lời của tôi.
Uống thuốc đúng liều và đúng cách
Khi nào thì sử dụng ORM
Chỉ sử dụng ORM cho dự án của bạn nếu bạn có người từng có kinh nghiệm về một framework ORM trên 2 năm. (điều kiện tiên quyết)
Nên sử dụng ORM nếu cấu trúc của các đối tượng nghiệp vụ phức tạp – thường xuyên thay đổi.
Sử dụng ORM nếu bạn có thể đánh đổi chi phí phát triển với chi phí upgrade hardware để optimize performance trong tình huống xấu nhất.
Khi nào thì sử dụng PLCG
Khi cấu trúc các đối tượng nghiệp vụ của bạn đơn giản. Phần lớn là ánh xạ 1-1 với các class nghiệp vụ và ít thay đổi.
Nếu bạn không có người expert về ORM để làm dự án (sure – )
Bạn cần tốc độ tối ưu cho ứng dụng nhưng không muốn tốn chi phí cho việc upgrade hardware.
Nếu bạn host một dự án web (ASP.NET) bằng share hosting service thì nên test cẩn thận việc gọi qua lại giữa các dll của ORM và các hàm của ứng dụng Web. (thường bị chặn security level). Nếu không thể gọi được các DLL của ORM tại host đó thì nên chuyển qua host khác hoặc viết lại Persistent layer sử dụng các tool gen code

Bước chân vào thế giới lập trình

Thế là bạn nghĩ rằng lập trình là một thế giới vô cùng thú vị, và bạn muốn tham gia vào thế giới ấy?

Trước khi bạn bắt đầu, điều duy nhất mà tôi muốn khuyên là: nếu bạn thực sự yêu thích lập trình thì đó rõ ràng đó là công việc tốt nhất mà bạn có thể có được. Ngược lại, nếu bạn chỉ cảm thấy thích, hay không quan tâm lắm đến lập trình, thì đó rõ ràng là công việc tồi tệ nhất của bạn. Bởi vì bạn đang gia nhập vào một thế giới mà sự cạnh tranh luôn là nỗi ám ảnh không thể tránh khỏi. Phát triển phần mềm gần như là một cuộc đua tranh. Trong đó, cuộc sống của bạn là một con đường và bạn phải chạy càng nhanh càng tốt, không cần biết dưới chân có gì, cho đến khi gặp đồng bằng hoặc là đụng phải vách đá cheo leo. Nếu bạn sẩy chân, mọi thứ kết thúc, và đó hoàn toàn là lỗi của bạn. Nghe có vẻ hơi ghê gớm đúng không? Nhưng đừng để những điều đó làm bạn nản lòng. Tôi chỉ không muốn vẽ nên một viễn cảnh tươi đẹp, nơi có những cánh đồng xanh ngút ngàn và những đám mây lững lờ trôi trên nền trời xanh thẳm. Thực tế là có thể chỉ vài phút sau đó trời sẽ mưa và bạn thì chẳng mang theo dù. Thế nhưng, chính những điều không chắc chắn, những thách thức và áp lực sẽ làm cho cuộc sống trở nên đầy hứng thú.

Bạn vẫn còn đọc đến đây ư? Rất tốt, thế có nghĩa là bạn hoàn toàn nghiêm túc về điều này. Bây giờ điều tôi sẽ nói với bạn là một bản phác thảo về những gì đang chờ đợi bạn trong thế giới lập trình, chúng ta sẽ nói một ít về kỹ thuật và cả những niềm vui của thế giới ấy.

Bạn cần gì để trở thành một lập trình viên? Tôi không nghĩ rằng có một vài yêu cầu khó khăn nào đó khiến bạn không thể trở thành lập trình viên, tôi chỉ đơn giản nghĩ rằng bất cứ ai có một ít (hay rất nhiều) mong muốn đều có thể trở thành lập trình viên. Vấn đề chỉ là bạn dành ra bao nhiêu thời gian. Điều đó có nghĩa là tôi nghĩ có nhiều quan niệm sai

lầm về những kỹ năng cần có để trở thành lập trình viên. Trước tiên, bạn không cần phải thật xuất sắc trong môn Toán, bạn chỉ cần có khả năng hiểu được những điều cơ bản. Dĩ nhiên là có những ngoại lệ, nếu bạn có hứng thú trong lĩnh vực đồ họa hay lập trình game thì một kiến thức Toán vững vàng sẽ giúp bạn rất nhiều. Một quan niệm sai lầm khác là bạn cần phải là thiên tài logic. Nói chung, điều đó không phải là bắt buộc, dĩ nhiên tư duy logic càng tốt thì càng dễ dàng hơn khi tiếp cận thế giới lập trình. Vậy thì kỹ năng nào là cần thiết? Bị thúc đẩy bởi những thách thức là yếu tố quan trọng nhất. Đơn giản là vì bạn đang tham gia vào một trò chơi trong đó thách thức xuất hiện trong mọi ngõ ngách. Một điều quan trọng khác là phải không ngừng theo đuổi mục tiêu, nhưng vẫn phải luôn uyển chuyển để không đuổi theo một cách mù quáng những mục tiêu xa vời.

Còn trường học thì sao? Trường học là nơi tuyệt vời để học mọi thứ ngoại trừ công nghệ. Đừng cho là tôi sai, tôi không nói rằng tôi nghĩ trường học là không quan trọng. Ngược lại, tôi nghĩ trường học là rất quan trọng, nhưng không phải để học lập trình. Những gì bạn nên tập trung thật sự ở trường là học cách để làm việc với những người khác trong một đề án. Cũng như học cách những người xung quanh giải quyết vấn đề và cách thức giải quyết của họ khác cách của bạn ở chỗ nào. Trường học thường bắt bạn phải làm những thứ có thể bạn không thích. Chẳng hạn, tôi nhớ lúc tôi học môn “Thiết kế trình biên dịch”, tôi tự nhủ: “Thật là mất thời gian một cách vô ích, tôi chẳng bao giờ cần phải thiết kế trình biên dịch làm gì”. Nhưng, điều tôi đã học được là làm thế nào để giải quyết những vấn đề hoàn toàn khác nhau, và kiến thức này giúp tôi làm được nhiều việc khác. Một trong những thuận lợi bạn có được từ trường học là bạn có thể gặp gỡ bạn bè có cùng chí hướng và có thể sau này trở thành đồng nghiệp của bạn. Ngành công nghiệp phần mềm ở nhiều khía cạnh rất giống với ngành công nghiệp điện ảnh, khi có ai đó bị lôi cuốn vào một đề án đầy tham vọng, họ thường mời bạn bè cùng hợp tác. Nếu bạn không biết họ từ trước, bạn sẽ không thể mời (hay thuê), và trong nhiều trường hợp, trường học chính là nơi bạn có thể tìm được những người có cùng sở thích. Một khía cạnh khác không thể bỏ qua là trường học không chỉ dạy về kỹ thuật mà còn dạy về lịch sử, về tâm lý,… Và trong khi những thứ ấy có vẻ không liên quan trực tiếp đến lập trình, bạn có thể sẽ rất ngạc nhiên nếu biết rằng đó cũng là một trong những nguồn cảm hứng mà tôi từng có.

Tôi nên bắt đầu từ đâu? Trước tiên, tôi khuyên là bạn nên cân nhắc cẩn thận trước khi có một quyết định quan trọng. Như tôi đã nói, thế giới lập trình có thể rất lý thú, nhưng cũng đầy gian nan. Do đó, đừng bao giờ nhảy bổ vào mà không suy nghĩ kỹ. Việc đầu tiên cần làm dĩ nhiên là tìm mua một cuốn sách dạy lập trình. Nhưng có quá nhiều sách và quá nhiều ngôn ngữ. Tôi khuyên bạn nên chọn một trong các ngôn ngữ sau: C, C++, Visual Basic, Pascal (Delphi) hay Java. Khoan hãy nghĩ đến những ngôn ngữ khác, bởi vì chúng hoặc là quá phức tạp cho người mới bắt đầu hoặc là quá đơn giản để có thể đưa bạn vào thế giới lập trình. Nhưng dù thế nào thì bạn cũng nên chọn một ngôn ngữ vào thời điểm này. Những ngôn ngữ này rất giống nhau, và vô cùng mạnh mẽ. Hầu như mọi ứng dụng thương mại đều có thể được viết bởi một trong những ngôn ngữ trên. Phương pháp của tôi là chọn 2 quyển sách cho mỗi ngôn ngữ đã nêu ở trên. Đọc sơ qua trước, và chú ý các ví dụ, mã nguồn trong đó. Sau khi đã đọc sơ qua tất cả các quyển sách đã chọn, hãy chọn quyển sách gây cho bạn nhiều hứng thú nhất. Và ngôn ngữ mà quyển sách đó đề cập chính là ngôn ngữ bạn nên học đầu tiên. Bây giờ hãy chọn thêm vài quyển sách về ngôn ngữ đó, mỗi quyển, bạn hãy đọc một phần chương đầu tiên, bạn có cảm thấy quan tâm đến nó không? Nếu không, hãy bỏ quyển sách ấy và chọn một quyển khác; nếu có, hãy lật đến giữa quyển sách và một phần chương mà bạn bắt gặp, vẫn cảm thấy quan tâm đến quyển sách ấy đúng không? Tốt, đó là quyển sách có thể bạn sẽ chọn. Đừng cố hiểu nó viết cái gì, chỉ cần tìm hiểu xem nó có mang đến cho bạn sự quan tâm về ngôn ngữ đó hay không. Tiếp tục phương pháp này cho đến khi không còn quyển sách nào cả, bạn có thể tìm được quyển sách gây cho bạn nhiều hứng thú nhất để học ngôn ngữ đó.

Những công cụ cần thiết Hãy nhìn thẳng vào vấn đề, chọn đúng công cụ sẽ làm cho công việc trở nên dễ dàng hơn. Điều này càng chính xác hơn trong lĩnh vực phát triển phần mềm. Có thể Microsoft đã tạo ra môi trường phát triển tốt nhất, Microsoft Developers Studio. Do đó, nếu bạn dùng C/C++, Visual Basic,… thì có lẽ đây sẽ là thứ bạn cần. Tuy nhiên, vẫn có nhiều công cụ thay thế miễn phí khác cho những ngôn ngữ này. Bạn có thể kiểm tra thử nếu thích.

Một công cụ khác cũng rất quan trọng, đó là trình soạn thảo mã lệnh (code editor). devStudio có một trình soạn thảo mã lệnh tích hợp sẵn, và đó là một trong những lý do khiến nhiều người dùng nó. Cá nhân tôi không thích bị ràng buộc bởi một môi trường phát triển nào. Do đó, tôi thích dùng công cụ soạn thảo MultiEdit Tôi đã sử dụng nó trong nhiều năm. Và tôi rất tự hào khuyên những ai muốn tìm một công cụ thay thế cho DevStudio hãy dùng nó. Hãy là người lạc quan Tôi từng nghe người ta nói rằng kẻ lạc quan nhất trên thế giới chính là nhà phát triển phần mềm. Trong suy nghĩ của họ, không có phần mềm nào là không thể viết được. Một ví dụ nhỏ, bạn hãy vào thử một site download phần mềm nào đó mà xem. Có hàng trăm hàng ngàn phần mềm bao gồm mọi lĩnh vực. Làm thế nào mà người ta có thể sáng tạo ra từng ấy phần mềm. Chúng nhiều và tốt đến nỗi bạn không thể nghĩ ra nên sáng tạo thêm phần mềm nào. Thế nhưng từng ngày từng giờ, các nhà phát triển phần mềm luôn sáng tạo và cho ra nhiều phần mềm mới hơn nữa, những phần mềm mà đã có thời người ta cho là không thể tạo ra được. Dù sao thì lạc quan mấy cũng phải có giới hạn. Mấu chốt của vấn đề là họ không nhìn mọi thứ một cách tổng thể, mà ở từng phần cụ thể. Ở một chừng mực nào đó, có thể xem đấy là đặc trưng của ngành thiết kế phần mềm, chia dự án ra thành những phần nhỏ và giải quyết từng phần. Nếu bạn không phân phối thời gian hợp lý, bạn sẽ không thể nào hoàn thành công việc. Khi bạn bắt đầu viết chương trình “thực sự” đầu tiên (nghĩa là chương trình có thể thực hiện được một công việc nào đó cần thiết cho mọi người, không phải cho riêng bạn), phải chắc chắn rằng bạn dành đủ thời gian để vạch ra kế hoạch về những việc bạn định làm, thứ tự thực hiện, và kết quả cuối cùng là gì. Nếu bạn làm điều này, bạn sẽ thấy mọi thứ trở nên dễ dàng hơn và có thể hoàn thành nhanh hơn là bạn nghĩ. Hãy làm việc theo nhóm! Nếu bạn dự định trở thành một lập trình viên đơn độc, hãy suy nghĩ lại. 99,9% các dự án đòi hỏi phải làm việc theo nhóm. Và do đó, bạn cần phải có kinh nghiệm làm việc theo nhóm, phối hợp với những người khác trong một dự án. Một khi bạn đã hoàn thành những dự án nhỏ của riêng mình, đó là lúc bắt đầu tìm cách tham dự vào một dự án có nhiều người tham gia. Đó có thể là một game, một bản demo, hay bất cứ thứ gì. Chỉ cần đó là dự án làm bạn quan tâm. Có nhiều các để tìm dự án, bạn có thể gia nhập vào những dự án đã có, tìm kiếm những nhóm vừa mới thành lập và xin gia nhập, hay thậm chí tự lập một dự án và mời người khác cùng cộng tác. Điều quan trọng nhất là bạn phải học cách làm việc cùng với những người khác để thực hiện mục tiêu chung.

Những thứ nên đọc! Đọc sách là nguyên tắc cơ bản… Và điều này càng chính xác trong ngành phát triển phần mềm. Nếu bạn là người không thích đọc sách, có lẽ bạn nên chọn một công việc khác. Bởi vì đọc sách chính là chìa khóa để củng cố và hiện thực hóa những tiềm năng của bạn. Bạn có thể tự hỏi vì sao tôi có thể viết nhiều phần mềm trong thời gian ngắn như thế? Có 3 lý do chính: kinh nghiệm, những đồng nghiệp tài năng mà tôi luôn hài lòng khi được làm việc chung và cuối cùng là những quyển sách tôi đã đọc. Tôi không thể giúp bạn có được kinh nghiệm và những bạn đồng nghiệp giỏi, nhưng tôi có thể giới thiệu cho bạn những quyển sách hay:

Code Complete:
Đây là quyển sách cần thiết cho mọi nhà phát triển phần mềm, bất kể họ đang dùng ngôn ngữ lập trình nào. Nó bao gồm nhiều bài thực hành và nhiều kỹ thuật liên quan đến phong cách viết mã.
ISBN: 1-55615-484-4

Rapid Development:
Quyển sách này hướng đến việc lập kế hoạch cho một dự án, tập trung vào những lỗi tiềm ẩn có thể mắc phải,… Đây là quyển sách cho bạn biết thế giới thực sự của ngành phát triển phần mềm.
ISBN: 1-55615-900-5

Dynamics of Software Development:
Quyển sách này có một hướng tiếp cận khác, tập trung vào việc làm việc theo nhóm và động lực của việc lập trình. Đây là điều thỉnh thoảng bị xem nhẹ, và hậu quả có thể được thấy trong nhiều dự án bị thất bại.
ISBN: 1-55615-823-8

The Mythical Man-Month
Đây thực sự là một quyển sách nên đọc. Dù rằng nó đã được viết cách đây hơn 20 năm, thế nhưng vẫn có nhiều điều có thể áp dụng.
ISBN: 0-201-83595-9

Programming Windows
Nếu bạn có ý định lập trình trên Windows (bằng C hay C++), bạn cần phải mua quyển sách này. Theo tôi đây là quyển sách dạy lập trình Windows tốt nhất.
ISBN: 1-57231-995-X

The Art of Ware
Tôi là một người hâm mộ cuồng nhiệt Tôn Tử, do đó tôi rất thích thú khi đọc quyển sách này. Đây là một quyển sách có phong cách viết rất lôi cuốn, với những bài học trong binh pháp Tôn Tử được vận dụng vào ngành phát triển phần mềm.
ISBN: 1-55851-396-5

NgoHung

Phương pháp học tập ở bậc đại học

Tôi nhận được những chia sẽ này trong một bài nói chuyện về phương pháp học tập ở bậc ĐH, tôi xinh chia sẽ mọi người.
1. Tự học

® Ghi chép: ở lớp, ở thư viện, ở các seminars, ở viện bảo tàng, khi đi tham quan… và tập quan sát và ghi nhận thông tin

® Tìm tài liệu: qua sách báo, trên internet; trong thư viện của trường; ở nhà… à tập nhận biết và chọn lọc thông tin

® Đọc tài liệu: đọc ý chính, đọc nhanh và nắm bắt ngay nội dung, gạch dưới những ý chính trong tài liệu à tập phân loại thông tin

® Tóm tắt tài liệu/thông tin: chỉ ghi những ý cần thiết, tránh dài dòng à tập diễn đạt ngắn gọn và xúc tích

2. Học tập theo nhóm

® Lập lịch họp nhóm

® Phân công giữa các thành viên

® Ghi chép và trao đổi thông tin

® Tranh luận và bảo vệ ý kiến

® Tham khảo chuyên gia hoặc giảng viên

3. Thực tập

® Nhận giấy giới thiệu và liên hệ nơi thực tập

® Tuân thủ nội quy thực tập/làm việc tại đơn vị

® Quan sát, học hỏi kinh nghiệm và nêu thắc mắc, không ngại khó

® Viết báo cáo

(Sưu tầm)

Muốn làm CNTT – phải có đam mê và định hướng cụ thể

Giám đốc Cty CMC Nguyễn Trung Chính đã khẳng định như vậy trước hàng nghìn sinh viên trong buổi giao lưu với chủ đề “Làm thế nào để gia nhập các công ty CNTT hàng đầu Việt Nam” diễn ra hôm 24-10, tại Đại Học Bách Khoa Hà Nội. Đây là một phần của chương trình trong ngày hội mang tên “Hướng đi mới trong đời sống và học đường”, do báo Tuổi Trẻ cùng Hãng máy tính Intel tổ chức.

Đúng 8 giờ sáng 24-10, tiền sảnh nhà C1 ĐH Bách Khoa chật kín sinh viên từ rất nhiều trường học ở Hà Nội về tìm hiều công nghệ mới, tranh tài trong các cuộc thi soạn nhạc, thuyết trình về tương lai CNTT và giao lưu với các chuyên gia CNTT hàng đầu…

Mặc dù Ban Tổ chức đã bố trí rất nhiều máy tính nối mạng và báo phát nhưng dường như vẫn không đủ để áp ứng nhu cầu của các bạn tham dự.

Các sinh viên đã liên tiếp đặt câu hỏi sau những phần giới thiệu công nghệ, thuyết trình hỏi đáp của Intel, Microsoft như: tại sao phải thi chứng chỉ Microsoft, làm thế nào để kết nối mạng không dây…Đặc biệt, phần giao lưu “Làm thế nào để gia nhập các công ty CNTT hàng đầu Việt Nam” đã thu hút rất nhiều bạn trẻ.

Không khí trở nên sôi nổi hẳn lên khi Giám đốc FPT Software Nguyễn Thành Nam và Giám đốc điều hành CMC Nguyễn Trung Chính trả lời nhiều câu hỏi thiết thực của sinh viên về các hình thức đào tạo và điều kiện tuyển dụng, bí quyết dùng người và cách làm thế nào để trở thành người quản lý giỏi.

Chia sẻ về những băn khoăn với các bạn trẻ đang còn ngồi trên ghế nhà trường về cách trở thành người tài giỏi về CNTT, ông Nguyễn Trung Chính đưa ra lời gợi ý: “Trước hết cần phải có niềm đam mê, có định hướng cụ thể để biết mình muốn gì, cần gì và có quyết tâm thực hiện nó. Ví dụ bạn muốn làm quản trị mạng, thì bạn nên tìm hiểu mình phải bắt đầu từ đâu, cần phải luyện gì, thi những chứng chỉ gì để sau này ra trường có thể thể hiện khả năng của mình trước nhà tuyển dụng”.

Ông Chính cũng khuyên rằng “các bạn trẻ đừng ngần ngại thử sức mình vào những vị trí khó, và nên coi việc tiếp xúc với các doanh nghiệp là hoạt động cần thiết và bổ ích để phát triển khả năng mình”.

Nói về tiêu chuẩn khi tuyển dụng nhân viên, ông Chính cho biết: “Nhiều bạn trẻ không đạt điểm cao trong quá trình đi học, nhưng mạnh dạn, tự tin thể hiện được khả năng của mình qua các đề tài, kinh nghiệm đều được đánh giá cao”.

Không chỉ có những câu hỏi liên quan đến vấn đề tìm việc, cách tuyển dụng của các doanh nghiệp, nhiều sinh viên còn đặt ra nhiều câu hỏi rất hắc búa đối với Giám đốc FPT Software Nguyễn Thành Nam.

Chẳng hạn như làm cách nào từ một lập trình viên có thể trở thành người quản lý giỏi. Cách dùng người thành công của doanh nghiệp… Mặc dù không giải đáp hết thắc mắc của các em, nhưng hầu hết các chuyên gia đều đã đưa ra được rất nhiều kinh nghiệm bổ ích giúp các em có thể chuẩn bị tốt hơn cho tương lai.

“Chính từ buổi giao lưu này chúng em có thêm kinh nghiệm và định hướng cho tương lai. Em coi đây là cơ hội tốt để học hỏi và khám phá bản thân mình”, Trung – một nam sinh viên – bộc bạch.

(TuoiTre)

Tôi muốn trích đăng lại tin ngắn trên từ báo TuoiTre khi thấy bài viết có một tựa đề khá thú vị và bổ ích cho nhiều người cũng như chính bản thân tôi. Từ đó mình cũng có điều kiện nhìn nhận lại vấn đề như cuộc sống, công việc cũng như đam mê và định hướng.

Những cột mốc trong cuộc sống mỗi người:

1. Tuổi thơ dữ dội: Tùy theo mỗi người mà tuổi thơ dữ dội của chúng yta có thể là từ Đại học chữ to (Mẫu giáo) cho đến Đại học chữ nhỏ (khoảng cuối cấp 1, hoặc cấp 2). Lứa tuổi chỉ bết học mà chơi và chơi mà học. Tuổi này là tuổi tinh nghịch hồn nhiên, nhí nhảnh.

2. Tuổi mộng mơ: Tuổi này rơi trọng tâm vào lứa tuổi cấp 3 – PTTH. Lứa tuổi mộng mơ và những hoài bão của mình.

3. Giai đoạn học tập & phát triển công việc: Khởi đầu là một anh chàng sinh viên, cũng có thể là một anh chang học việc. Gia đoạn vùa học vừa làm và rồi trau dồi kiến thức và kinh nghiệm để phát triển nghề nghiệp của mình.

4. Lứa tuổi với những định hướng gia đình: Tùy theo vùng (nông thôn / thành thị), tùy theo trình độ học vấn mà gia đoạn này có thể đi cùng với giai đoạn (3) hay là đi sau nó vài năm.

5. Về đích trong công việc, chăm lo mái ấm gia đình …. đến về già: ……

Với bài viết này, tôi chỉ muốn tấp trung vào định hướng nghề nghiệp, những nhân tố ảnh hưởng đến nó, tức là ở giai đoạn thứ 3, lứa tuổi của các bạn trẻ như tôi và các bạn trẻ đang định hình cho công việc, hướng đi của chính mình.

Muốn làm CNTT – phải có đam mê và định hướng cụ thể

Chỉ CNTT thôi ư, không những CNTT mà bất cứ ngành nghề nào thì khi làm việc cũng cần phải có đam mê và định hứng cụ thể. Có được những yếu tố đó nó giúp cho chúng ta biết minh đang đứng tại vị trí nào và tương lai mai này rồi sẽ ra sao. Tôi nghe được câu này: “Chẳng biết ngày sau có ra sao, dù có ra sao cũng chẳng sao“, triết lý đấy nhưng tôi không đồng ý với ý kiến đó. Chủ nghĩa bình quân làm con người ta nhụt chí, không định hướng cho bản thân mình.

Nguồn : http://blog.360.yahoo.com/blog-XckJEY8_fKl68a_VSVflbIEYqQ–?cq=1&l=41&u=45&mx=229&lmt=5