Mặt trái của Frameworks


Từ Framework đã quá thông dụng. Nhờ nó mà số dòng code của chúng ta giảm đi thấy rỏ. Và các ứng dụng ngày nay, còn có thêm một yêu cầu về frameworks dùng. Tuy nhiên, có một điều mà hầu như ai cũng biết: mặt trái của nó.



Tôi đã dùng JSF ngay từ khi bắt đầu đến với Java WEB. Một components base framework, giúp ta tối ưu hoá việc sử dụng MVC trong web. Tôi đã hầu như không gặp bất kỳ một trở ngại nào trong các ứng dụng thuộc loại cổ điển (các bài quản lý như: thư viện, sinh viên, nhân viên, thư viện, ...).

Nhưng khi dùng Ajax thì thật sự nó là một gánh nặng. Muốn làm một component Ajax cho JSF quả là rất khó khăn - dĩ nhiên là không phải không làm được. Bạn cần có một kiến thức rỏ ràng về vòng đời các thành phần, biết cách vượt qua một số giai đoạn, và một thành phần không thể không biết là PhaseListener.

Có một số hãng phát triển cho mình một số Ajax for JSF frameworks như IceSoft với icefaces, Jboss với Richfaces, và Oracle với Netadvantage. Tuy nhiên, việc dùng frameworks nào cần có một bước phân tích tỉ mỉ về tất cả các vấn đề cần phải dùng frameworks. Đó là chưa kể đến vấn đề về lỗi kỹ thuật của nó, và thường thì ta phải chờ fix, đó là một ảnh hưởng rất lớn đến dự án.

Ở tầng business thì ta không thể phủ nhận những tính năng của Spring. Tuy nhiên, mặt tối của nó đã dẫn đến một bài viết về một cuộc phỏng vấn điển hình mà Giovani Salvador nhắc đến trong bài Java Architectural Knowledge for Job Interviews. Are we prepared? Nó cũng làm tôi nhớ đến vấn đề mà Robert Nocera đưa ra là gọi Stored Procedures từ JDBCTemplate của Spring.

Và cuối cùng: “Một giải pháp hoàn hảo là giải pháp không dùng Frameworks”.

Đọc tiếp >>

Cao Trong Hien

,

IT và vấn đề Phân biệt giới


Người ta cũng nói vui với nhau rằng: làm việc quá giờ trong IT là một nền “văn hoá”. Nhưng cá nhân tôi nghĩ rằng đó là kết quả của sự lớn lên của hệ thống IT, lớn lên của nhiệm vụ được mong đợi và tính cạnh tranh khốc liệt trong ngành. Nó cũng là một thực tế đáng buồn trong IT, và khi thay đổi “nền văn hoá” sẽ không làm thay đổi được nó.


Có những cách làm hay


Trường đại học Carnegie Mellon thiết lập một mẫu giáo dục để thu hút nhiều người phụ nữ hơn. Chẳng hạn, dùng môn kỹ năng lập trình là điều kiện để sắp lớp. Bù lại, họ tạo ra những lớp lập trình tăng tốc cho newbies, để bằng với những sinh viên với đã có kinh nghiệm trước. Chương trình được coi là một thành công và một kiểu mẫu cho những trường đại học khác.

Nhưng có thiết thực?


Chương trình Carnegie cũng có cùng lỗi về sự giữ thăng bằng giới với những sáng kiến: Nó tìm kiếm thúc đẩy tỷ lệ phụ nữ bằng việc tập trung vào phụ nữ, mà không biết rằng trong sâu thẳm họ không quan tâm đến IT như những người sẽ là đối thủ trong trường học và trong công việc. Những người ít hứng thú hơn này có khả năng thất bại hay rời bỏ công việc khi đối diện với thử thách so với những người hứng thú và luôn thúc đẩy bản thân vươn lên, bất chấp giới.

Câu hỏi đặt ra: Với tất cả những công cụ lập trình miễn phí hiện nay, thông tin và những ý tưởng đang có, người nào làm nó trước 18 tuổi mà không cần học lập trình?
Câu trả lời: Đó là người có niềm đam mê đặc biệt đến lập trình.
Có hàng triệu câu hỏi được đặt ra chỉ để hiểu ngành IT và sự không cân bằng giới, bí quyết để học thành công IT, so sánh giữa teens có đam mê trong lập trình với teens không có niềm đam mê như vậy.
Tôi Thật sự không biết rằng tại sao nhiều những cậu bé hơn những cô gái chọn học IT, chọn và ở lại với IT để bắt đầu sự nghiệp - và Tôi thú nhận rằng Tôi không có giải pháp hay đề xuất gì. Nhưng Tôi chắc chắn rằng khuôn mẫu hóa, giới tính và những nhân tố khác luôn phải tồn tại. Tôi cũng tin điều đó gây sức ép cho những cô gái- hay những chàng trai cho rằng điều đó quan trọng- khi bước vào sự nghiệp mà không có sự giúp đỡ của bất cứ ai. Qua những suy nghĩ không đúng- như kiểu mẫu và rập khuôn- và chẳng giúp gì được. Điều cần thiết là họ cần có một tình yêu với thiết bị, những hệ thống và thao tác giải quyết vấn đề phức tạp, hay họ chẳng hề nghĩ đến việc chọn theo IT.

Trong khi trong mọi lĩnh vực, đúng là chúng tôi cần hỗ trợ để loại bỏ sự phân biệt giới, tiền lương và các chế độ không công bằng. Nhưng không phải là áp đặt cho những cô gái và đẩy họ vào trong một sự nghiệp mà họ không hứng thú.

Kết luận


Có quá nhiều phụ nữ trong IT phải không? Tất nhiên không phải। Nhưng Tôi thật sự lo ngại rằng có thể quá nhiều phụ nữ vào IT bởi sự “dỗ dành” để trong một sự nghiệp mà không hề có một niềm đam mê hay yêu thích, chỉ vì lý do “cân bằng giới”.

Tham khảo từ: http://itmanagement.earthweb.com/career/article.php/3645346

Đọc tiếp >>

Cao Trong Hien

,

Có nhiều nữ trong ngành IT?


Theo hãng nghiêng cứu Gartner, tỉ lệ phần trăm nữ làm việc trong ngành IT là thấp và có xu hướng giảm, từ 42 % trong năm 1996 xuống cỏn 32.4% trong năm 2004 trên toàn thế giới. Trong môt số quốc gia, trong đó có Mỹ, con số là dưới 30 %.

Nhưng những điều đó chỉ là một phần nhỏ của câu chuyện: thường có rất ít nữ chọn theo ngành IT so với nam trong các trường đại học. Và trong số đó, phần lớn khi ra trường làm việc lại chọn một chuyên ngành khác. Trong khi hàng năm, số lượng nữ chọn ngành IT nhiều hơn nam đi ra khỏi ngành. Về vị trí quản lý trong ngành IT, phụ nữ rất ít. Các vị trí cao hơn nữa thì càng hiếm.
Lý do của sự mất cân bằng trên có thể do một số lý do sau như: hầu hết không ủng hộ nữ theo ngành IT, thiếu người kiểu mẫu, tính chất của ngành IT là quá “nam tính,” và có sự phân biệt giới trong làm việc.
Hàng triệu Đô La được dùng cho các tổ chức xã hội và trường đại học để hiểu đâu là lý do của sự mất cân bằng trong ngành IT, nhưng kết quả bước đầu của chương trình này là thất bại nhiều hơn thành công.

Thiếu người kiểu mẩu


Rebecca George, người điều hành diễn đàn phụ nữ IT, than thở việc thiếu những người đi đầu, và dẫn chứng: "Nếu bạn hỏi trong một lớp của những học sinh ở lứa tuổi khoảng 11 rằng họ biết bao nhiêu người lập trình viên(LTV) nữ, thì sẽ không có một cánh tay nào dơ tay cả. Nếu là trường hợp của bác sĩ, luật sư, giáo viên thì có rất nhiểu."
Lý do này thật ra là không hợp lý. Vì phần lớn trẻ em không biết cả những LTV nam. Bác sĩ và giáo viên, là những người mà trẻ em hay tiếp xúc, và thường để lại ấn tượng cho các em. Quan trọng hơn, người ta thường chọn IT không phải vì họ muốn như ai đó, mà họ yêu hệ thống máy tính, mạng và giải quyết những vấn đề rắc rối liên quan.
Một điều tệ nhất là những người kiểu mẩu truyền cảm hứng cho ai đó chọn ngành IT và muốn được giống như họ. IT là nghề có tính cạnh tranh cao, và đầy những thử thách. Một người luôn muốn theo ngành IT vì họ muốn trở thành một ai đó, hơn là yêu thích công việc, thì chắc chắn sẽ thất bại.

Không hợp thời


Để thu hút nữ chọn IT, theo George, "bạn cần bắt đầu với trẻ em 11-tuổi và thuyết phục chúng rằng ngành IT thế giới là rất “thời thượng”, và chúng hoàn toàn có thể là một phần của nó."
Một người chọn công việc IT làm một niềm đam mê, không phải vì tác phong của một người đang làm nó. Có nhiều hình ảnh về nghề nghiệp có sự thu hút đặc biệt như: diễn viên, người mẫu, nhà bình luận công nghệ – nhưng IT không phải là chúng.
Đừng nên nói với một cô gái rằng IT là một nghề “mốt” và “hợp thời”, mà chúng ta cần thuyết phục chúng rằng: mốt và thời trang là trống rỗng và không có gì “hay ho”, và rằng nghề IT rất thú vị và đầy thử thách. Bọn trẻ sẽ bác bỏ lý do này và chuyển sang cống hiến cho ngành IT.

Phân biết giới tính trong làm việc


Sylvia Ann Hewlett, một nhà kinh tế học tại trung tâm Work-Life Policy tại New York và người sáng lập và giám đốc trung tâm Work-Life Policy, thực hiện một cuộc nghiêng cứu tại Harvard Business Review. Cho thấy rằng trong 41% "technical staff" (bao gồm IT, khoa học và một số ngành kỹ thuật) có nữ, có hơn một nửa rời phòng ở tuổi 40. Và kết luận đây là một lý do chính dẫn đến kết luận về sự phân biệt giới và “tăng ca" là bình thường đối với bất kỳ ai trong ngành.
Trong nhiều ngành nghể truyền thống (bác sĩ, luật sư, kế toán, kinh doanh, tiếp thị, vv.) ta thấy sự gia tằng số phụ nữ, điều này đã làm cho giới tính ngày càng cân bằng, đánh đổ phân biệt giới.
Phụ nữ có thể tồn tại và vượt qua rào cảng giới trong cả ngành IT và tất cả các ngành khác bởi vì họ luôn khao khát được làm việc. Và họ hoàn toàn có khả năng đối diện và đánh đổ sự phân biệt giới để làm việc. Vì vậy sự sụt giảm của nữ trong ngành IT không thể giải thích bằng lý do phân biệt giới.

* Vậy đâu là giải pháp cho vấn đề trên? Hãy cùng tôi tìm hiểu trong bài viết sau.

Đọc tiếp >>

Cao Trong Hien

,

Dojo JSON-RPC + Java


Dojo hỗ trợ JSON-RPC, là tính năng mở rộng của JSON dùng để triệu gọi phương thức từ xa. JSON-RPC có thể dùng như một phương tiện cho các ứng dụng cần giao tiếp với servers. Ví dụ sau sẽ chỉ ra cách tương tác với Java trên server và gọi một phương thức Java từ JavaScript dùng Dojo RPC services. Nó cũng cho thấy việc sử dụng JSON-RPC dễ dàng hơn khi dùng Java.

Đầu tiên, ta tạo một servlet và viết phương thức POST sẽ đọc nội dung của request:


public class JsonRPC extends HttpServlet {
protected void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
String content = streamToString(req.getInputStream());

Ta dùng json.org’s Java library để phân tích và lấy ra các thuộc tính từ JSON object. Một JSON-RPC object gồm có 3 thuộc tính được định nghĩa để gọi: method, params, và id. Như sau:


JSONObject rpcObject = new JSONObject(content);
String methodName = rpcObject.getString("method");
String id = rpcObject.getString("id");
JSONArray paramsArray = rpcObject.getJSONArray("params");
Object[] params = new Object[paramsArray.length()];
for (int i = 0 ; i < paramsArray.length(); i++) {
params[i] = paramsArray.get(i);
}

Ta có thể dùng những thuộc tính này để chạy một phương thức trên một object. Nếu ta đã có tạo sẵn một object dùng như một target cho RPC, ta có thể gọi phương thức và thi hành nó:

for (Method method : target.getClass().getMethods()) {
// we could use getMethod(methodName, paramTypes) here but
// we would need to create a list of parameters types
if (method.getName().equals(methodName)) {
Object result = method.invoke(target, params);
...

Sau khi trả kết quả lại cho client. Response object cũng có 3 thuộc tính: id, result, và error. Ta sẽ dùng JSON library để dựng lại object này:

response.put("id",id); // id from the request
response.put("result",result); // result of the invocation
response.put("error",JSONObject.NULL); // no error
// send the response to the client
resp.getOutputStream().print(response.toString());

Đó là tất cả những gì cần để xây dựng class để gọi JSON-RPC. Cũng có thể dùng try/catch để kiểm soát lỗi:

try {
...
Object result = method.invoke(target, params);
...
} catch (Throwable e) {
response.put("id",id); // id from the request
response.put("result",JSONObject.NULL);
response.put("error",e.getMessage());
}

Tôi sẽ tạo một class rất đơn giản để gọi JSON-RPC:

public class Echo {
public String sayHi(String from) {
return "Hi " + from;
}
}

Và hiện thực:

target = new Echo();

Tiếp theo là khai báo một servlet trong file web.xml:

<servlet>
<servlet-name>JsonRpc</servlet-name>
<servlet-class>com.sitepen.JsonRPC</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>JsonRpc</servlet-name>
<url-pattern>/jsonrpc/</url-pattern>
</servlet-mapping>


Gọi phương thức với Dojo



Trên client side, chúng ta có thể dùng simple method description (SMD) object để khai báo JSON-RPC và Dojo sẽ tạo phương thức thích hợp.

dojo.require("dojox.rpc.Service");
dojo.require("dojox.rpc.JsonRPC");

echoService = new dojox.rpc.Service({
envelope:"JSON-RPC-1.0",
transport:"POST",
target:"/jsonrpc/echo",
services:{
sayHi:{
parameters:[{type:"string"}] // this is optional
}
}
});

Giờ thì echo đã có phương thức sayHi thi hành tương ứng với phương thức trên Echo class. Chúng ta có thể gọi sayHi chỉ với một phương thức trên JavaScript. Tham số sẽ bao gồm trong JSON-RPC và dùng để gọi phương thức trên server. Ví dụ:

var deferred = echoService.sayHi("Kris");

Thi hành sayHi với đối số “Kris”. Giá trị trả về là Deferred object, và bạn có thể dùng bình thường, hay dùng callback:

deferred.addCallback(function(result) {
alert(result); // executed when the RPC is finished
});

Khi RPC response được trả về, callback function sẽ trả kết quả trên alert. Và “Hi Kris” hiện ra.

Multiple Target Objects


Chúng ta đã thực hiện xong phần triệu gọi RPC cho một object. Ta cũng có thể thực hiện cho nhiều objects. Một trong những điều kiện để có thể dùng multiple objects là tạo nhiều URL paths cho các target objects:

static Map rpcTargets = new HashMap();
public static void registerRpcTarget(String path, Object target) {
rpcTargets.put(path,target);
}

Sau đó là tìm đến target objects bằng URL path:

String targetPath = req.getPathInfo();
Object target = rpcTargets.get(targetPath);

Thêm một target objects là vần đề đơn giản nhất. Cho echo object, ta có thể khai báo như sau:

registerRpcTarget("/echo",new Echo());

Còn nếu bạn đã tạo một object mới, khai báo theo cấu trúc:

registerRpcTarget("/myObject",new MyClass());

Và thêm vào client side một service object khác từ SMD:

myObject = new dojox.rpc.Service({
envelope:"JSON-RPC-1.0",
transport:"POST",
target:"/jsonrpc/myObject",
services:{
foo:{
parameters:[{type:"string"}] // this is optional
}
}
});

Bạn có thể download đầy đủ source tại đây. Chúc thành công!

Đọc tiếp >>

Cao Trong Hien

, ,