Welcome to Comedown's Blog Technology !
Loading...

My Monster Templates Collection - III

Người đăng: Unknown Thứ Ba, 21 tháng 7, 2009 Posted under -


Template Monster 24664

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 13.26 Mb

Code:

http://linkstofile.com/?7773751



Template Monster 24659

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 5.01 Mb

Code:
http://linkstofile.com/?6806068



Template Monster 24658

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 3.18 Mb

Code:
http://linkstofile.com/?2640523



Template Monster 24556

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 59.89 Mb

Code:
http://linkstofile.com/?6038346



Template Monster 24512

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 11.05 Mb

Code:
http://linkstofile.com/?8728699



Template Monster 24134

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 20.96 Mb

Code:
http://linkstofile.com/?9879885



Template Monster 24696

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 8.49 Mb

Code:
http://linkstofile.com/?4294391



Template Monster 24672

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 4.91 Mb

Code:
http://linkstofile.com/?659708



Template Monster 24669

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 25.59 Mb

Code:
http://linkstofile.com/?4066763



Template Monster 24449

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 8.90 Mb

Code:
http://linkstofile.com/?5945633


Comedown

Read more “My Monster Templates Collection - III”

My Monster Templates Collection - II

Người đăng: Unknown Posted under -


Template Monster 24051

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 34.55 Mb

Code:

http://linkstofile.com/?2079523



Template Monster 24487

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 8.33 Mb

Code:
http://linkstofile.com/?2890382



Template Monster 24451

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 7.72 Mb

Code:
http://linkstofile.com/?906998



Template Monster 24306

Sources: .FLA, .HTML, .SWF and fonts

Download: 5.81 Mb

Code:
http://linkstofile.com/?7670717



Template Monster 24246

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 12.20 Mb

Code:
http://linkstofile.com/?473392



Template Monster 23863

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 8.86 Mb

Code:
http://linkstofile.com/?7382587



Template Monster 24247

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 22.66 Mb

Code:
http://linkstofile.com/?3632580



Template Monster 24513

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 11.71 Mb

Code:
http://linkstofile.com/?9603417



Template Monster 24615

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 69.73 Mb

Code:
http://linkstofile.com/?8545912



Template Monster 24616

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 24.96 Mb

Code:
http://linkstofile.com/?9904974


Comedown

Read more “My Monster Templates Collection - II”

My Monster Templates Collection - I

Người đăng: Unknown Posted under -

Một số flash website template đẹp:


Template Monster 23950

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 23.38 Mb

Code:

http://linkstofile.com/?2367929



Template Monster 24016

Sources: .FLA, .HTML, .SWF

Download: 12.99 Mb

Code:
http://linkstofile.com/?4635344



Template Monster 24017

Sources: .FLA, .HTML, .SWF

Download: 10.57 Mb

Code:
http://linkstofile.com/?7205290



Template Monster 22865

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 22.28 Mb

Code:
http://linkstofile.com/?9346447



Template Monster 24483

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 6.31 Mb

Code:
http://linkstofile.com/?2183319



Template Monster 24514

Sources: .FLA, .HTML, .SWF and fonts

Download: 13.38 Mb

Code:
http://linkstofile.com/?4450485



Template Monster 24555

Sources: .FLA, .HTML, .SWF and fonts

Download: 12.69 Mb

Code:
http://linkstofile.com/?4083731



Template Monster 24557

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 21.53 Mb

Code:
http://linkstofile.com/?7764859



Template Monster 24508

Sources: .FLA, .XML, .HTML, .SWF and fonts

Download: 32.81 Mb

Code:
http://linkstofile.com/?4836148



Template Monster 24458

Sources: .FLA, .HTML, .SWF and fonts

Download: 11.24 Mb

Code:
http://linkstofile.com/?704492


Comedown

Read more “My Monster Templates Collection - I”

10 điều bạn phải chấp nhận nếu làm ngành IT

Người đăng: Unknown Chủ Nhật, 19 tháng 7, 2009 Posted under -

Thảm cảnh của dân IT là đây? - Ảnh minh họa: Internet


1. Ở những ngành khác thì nữ vừa nhiều vừa xinh đẹp, ngành IT thì ngược lại

Điều này ai đã và đang học CNTT ở các trường ĐH đều biết rồi. Không riêng gì trong ngành CNTT mà những ngành kỹ thuật, số lượng nữ giới cũng rất thấp. Tuy nhiên so với các ngành như cơ khí, điện tử thì tỉ lệ nữ giới học CNTT cũng còn khá cao. Nhưng khi học xong và đi làm, tỉ lệ nữ giới làm lập trình lại càng giảm, đa số các bạn ấy làm QC, DB, BA,… (*).

Ở nhóm tôi khoảng 20 người chỉ có mỗi 2 dev, 2 QC là nữ, còn lại toàn đực rựa. Tuy nhiên điều an ủi là trong công ty vẫn có nhiều chị em xinh lắm hỉ hỉ nhưng không làm ở bộ phận lập trình. Thiếu thốn này thường dẫn đến điều thứ hai.

2. Xác suất phải lập gia đình với người cùng ngành rất cao

Nghe có vẽ như hơi mâu thuẫn, đã ít nữ thì làm sao xác suất này cao được. Thế nhưng với những người làm IT thì kể từ lúc đi làm thường nhìn máy tính nhiều hơn giao tiếp với người thật nên sẽ ăn nói kém, giao tiếp kém, cơ hội gặp phụ nữ khác ngành cũng ít hơn người làm ở ngành khác nên trời kêu ai nấy dzạ.

Tuy nhiên chúng ta thường quen nửa cuộc đời của mình từ trong trường ĐH hoặc ở nơi làm việc nên điều này có thể cũng đúng với những người làm ở các ngành khác. Dù những người làm ở ngành IT chúng ta thường được cái thông minh, nhưng hai người thông minh thì sinh con ra chưa chắc thông minh nên đây cũng là một hiểm họa tiềm tàng. Hơn nữa, hai người cùng ngành IT giờ gặp nhau ngoài nói chuyện bug, code thì chán chết. Phải chi chàng kể chuyện bug, nàng hỏi bug là gì huh anh thì có thú vị ko nhẩy.

3. Bạn sẽ bị yếu đi

Điều này không có gì phải bàn cãi. Thứ nhất ngồi nhiều… thì bụng và mông sẽ to. Bụng càng to càng khó làm... nhiều thứ và tuổi thọ giảm. Ngồi nhiều còn có thể gây ra nhiều bệnh tế nhị khác. Ngoài hai bệnh đằng trước và đằng sau thì còn bệnh ở mắt do nhìn quá nhiều. Đa số người làm IT xung quanh ta đều bị cận thị. Gõ máy tính thường xuyên sẽ ảnh hưởng đến tim, rê chuột thường xuyên sẽ thoái hóa cổ tay. Ngoài ra cột sống sẽ bị chai hoặc mọc gai do tật ngồi nhiều hơn đứng của công việc này.

Ngoài ra, người làm IT thường có thói quen làm việc, sinh hoạt ban đêm. Cái giờ đáng lẽ những người ở những ngành khác làm cái việc mà ai cũng biết là việc gì thì người trong ngành IT lại gõ gõ, click click và thường gây ra bệnh đau bao tử. Tay chân ít hoạt động nên con người thường cảm thấy mỏi mệt, lười vận động, thậm chí cả lười tắm nên đừng thắc mắc tại sao một số SV ngành IT thường ở dơ. Nói chung làm cái nghề này nếu ko chịu sinh hoạt… điều độ thì đừng mong thọ.

4. Bạn sẽ thường xuyên bị làm phiền bởi người quen

Đây là một trong những điều tệ hại và khó chịu nhất bạn sẽ gặp phải. Những người quen của bạn: bạn bè, bà con, cô dì chú bác, bạn của ba của mẹ sẽ gọi điện nhờ bạn giúp khi họ không nghe nhạc được, máy khởi động chậm, không thấy webcam, không biết đưa hình lên blog.

Kiểu hỗ trợ kỹ thuật miễn phí này nên cẩn thận vì nó sẽ thường xuyên lặp đi lặp lại. Một số trường hợp bạn sẽ được trả công nhưng theo tôi, bạn chẳng cần số tiền chả đáng đổ xăng đó làm gì so với thời gian phải chạy đi chạy lại. Đa số người nhờ bạn giúp sẽ mong muốn được hỗ trợ miễn phí và tôi chắc chúng ta sẽ không vui gì về điều đó. Vì vậy hãy tập nói không khi có thể.

5. Bạn sẽ phải thường xuyên về trễ mà không được trả tiền

Đặc thù của ngành IT là công việc thường không thể tính chính xác bằng giờ. Có nghĩa là không phải cứ một lượng thời gian nào đó thì sẽ làm xong một công việc. Thường chúng ta sẽ phải ở lại thêm 1 giờ, 2 giờ để làm nốt công việc của mình nếu bạn là người có trách nhiệm. Nhưng dù có trách nhiệm hay không thì khi công việc chưa xong mà đã gần đến deadline thì bạn vẫn phải ở lại để hoàn thành những gì còn dở dang, tất nhiên không có xu nào cả.

6. Bạn sẽ thường xuyên bị stress

Khi làm việc với những project lớn nhiều người, công việc sẽ theo flow rõ ràng, bạn làm ngưòi khác test, manager dzí, và khi đến những ngày cuối cùng là lúc bạn làm việc nhiều nhất. Phải suy nghĩ nhiều, cơ thể mệt mỏi, thiếu ngủ cộng với căng thẳng khi làm việc sẽ khiến nhiều người bị stress.

Theo một số điều tra, thủ phạm gây stress nhiều nhất là email. Khi phải đọc khoảng 100 email một ngày thì người hiền lành cũng trở nên gắt gỏng. Bởi vậy những người làm IT thường hay khó chịu đột xuất.

7. Lương bạn sẽ tăng rất chậm

Ảnh minh họa: Internet

Làm IT lương khởi điểm sẽ khá cao so với một số ngành nhưng tốc độ tăng sẽ chậm và ít đột biến. Thường người làm IT sẽ giải quyết nhu cầu tăng lương bằng cách nhảy sang công ty khác. Cho nên những bạn sinh viên mới ra trường nên tìm một công ty có lương khởi điểm khá tốt, vì thông thường chu kỳ tăng lương sẽ là từng năm và khi lạm phát hai chữ số mà tăng lương dưới 15% + với trả lương bằng tiền Việt thì hơi bị đuối. Tốt nhất nên tìm hiểu những anh chị đi trước hoặc xác định mục tiêu của mình để tìm hướng đi khác vì làm lập trình chay khó làm giàu lắm.

8. Không phải lúc nào cũng được làm công việc ưa thích

Bạn từng nghĩ sẽ áp dụng những kỹ thuật tiên tiến nhất của các ngôn ngữ lập trình hiện đại, sẽ học hỏi những công nghệ mới nhất và làm việc với những chuyên gia đầy kinh nghiệm trong lĩnh vực CNTT nhưng thường không phải như vậy. Ở những công ty càng lớn càng có những project kỳ lạ kiểu như chuyển nguyên một chương trình từ VB6 sang C#, hoặc từ một ngôn ngữ rất cổ xưa sang C#.

Tuy đòi hỏi kiến thức lập trình trên hai ngôn ngữ, khả năng đọc hiểu code nhưng nói chung công việc như vậy khá nhàm chán và tôi nghĩ chẳng ai muốn theo đuổi lâu dài. Đối với những project lớn thì chi phí công nghệ mới là một trong những vấn đề quan tâm của khách hàng.

Bạn muốn sử dụng SQL 2005 nhưng khách hàng sẽ nói “No” khi họ đã có licence cho SQL 2000 và không muốn bỏ tiền mua thứ mới. Bạn muốn sử dụng ASP.NET để làm website cho khách hàng nhưng họ cho rằng PHP sẽ rẻ hơn vì không tốn nhiều licence cho máy chủ WINDOWS. Bạn muốn dùng ORM tool để tiết kiệm thời gian lập trình nhưng khách hàng nhất quyết bạn phải dùng Store Procedure và viết code gọi bằng C# vì làm vậy nhanh hơn 30 milisecond khi gọi 10.000 query. Nói chung khách hàng là thượng đế và chúng ta phải nghe theo.

9. Khi nhảy việc cũng không đơn giản, có khi phải bắt đầu lại từ đầu

Lương bạn hiện không cao trong khi lương tụi bạn đã gấp hai mình. Đề nghị sếp tăng lương thì sao, liệu sếp có chịu tăng cho mình gấp rưỡi không chứ đừng nói gấp hai. Tại sao không nhảy việc khi vừa có thể có lương cao hơn lại có thể học hỏi nhiều cái mới và làm quen nhiều con người mới.

Nhưng khi nhảy việc là lúc bạn phải chấp nhận làm lại từ đầu. Có thể bạn có nhiều kinh nghiệm từ công ty cũ nhưng sang môi trường mới sẽ không có đất để dụng võ. Và khi chưa biết gì hết thì bạn sẽ là một newbie (dân tay mơ) và chấp nhận làm lại từ con số không. Vì vậy, theo tôi, nếu tìm được công việc mới lương gấp rưỡi trở lên thì hãy nhảy, còn không ở lại cho lành và chờ thời cơ.

10. Rất khó để tự kinh doanh riêng về IT

Tỉ lệ thất bại cao của các công ty IT mới thành lập đã nói lên điều này. Nếu bạn làm IT khi muốn mở một công ty làm phần mềm thì rất khó. Một trong những khó khăn lớn nhất là sự cạnh tranh. Bạn sẽ khó kiếm được project từ những khách hàng lớn khi công ty của bạn chưa hề có tên tuổi hoặc không có công ty mẹ đỡ đầu. Nếu chấp nhận làm dự án nhỏ thì có vô khối công ty đã làm như vậy.

Những công ty may mắn sống sót nhờ vào dạng những project nhỏ này họ có thể thực hiện website trong một tuần nhờ tái sử dụng những cái đã có từ project cũ và chúng ta sẽ khó cạnh tranh mỗi khi kinh nghiệm tổ chức và kinh doanh là con số 0. Giỏi lập trình không có nghĩa là giỏi quản lý, và càng không có nghĩa là giỏi kinh doanh nên làm công ty về IT không hề đơn giản. Và khi không có project nào trong khi phải nuôi đội quân cỡ năm người, cộng với trả tiền điện, tiền mặt bằng trong ba tháng là bạn phải nghĩ đến chuyện giải tán.

Đó là 10 trong khá nhiều những khó khăn, thiệt thòi, gian khổ của ngành IT. Làm IT không đơn giản và không sướng chút nào, càng không dễ làm giàu. Thế nên những ai nghĩ làm IT sướng và lương cao thì nên xem lại và cân nhắc nếu như đang chọn nghề cho mình. Đây là những ý kiến chủ quan của tôi, có thể có nhiều ý kiến trái ngược và bổ sung khác nên rất mong được sự chia sẽ từ các bạn. Mọi comment khen ngợi, chửi bới đều hoan nghênh.


Sưu tầm

Read more “10 điều bạn phải chấp nhận nếu làm ngành IT”

Toyota Production System (TPS)

Người đăng: Unknown Thứ Tư, 15 tháng 7, 2009 Posted under -

Taiichi Ohno, nhà lãnh đạo tinh thần của TPS, cho rằng hao phí lớn nhất là hao phí về sản xuất thừa. Nếu bạn làm ra một thứ mà bạn không thể bán được, thì công sức bạn bỏ ra sẽ mất đi. Nếu bạn làm ra một thứ dùng nội bộ trong dây chuyền mà không sử dụng chúng ngay lập tức, thì giá trị thông tin của chúng sẽ bốc hơi. Và bạn cũng tốn chi phí lưu trữ chúng: chuyển chúng vào nhà kho; theo dõi kho; lau chùi rỉ sét khi đem ra dùng lại; và sẽ gặp rủi ro nếu bạn không bao giờ dùng đến chúng nữa; trong trường hợp đó, bạn lại tốn chi phí để đem hủy bỏ chúng.

Có vô vàn hao phí về sản xuất thừa trong phát triển phần mềm: bộ tài liệu yêu cầu đồ sộ nhanh chóng bị lỗi thời; các kiến trúc phức tạp không bao giờ được dùng; các đoạn mã hàng tháng trời không được tích hợp, kiểm thử và chạy trên môi trường thực; và các tài liệu không ai muốn đọc cho tới khi chúng không còn thích hợp hay mất tác dụng. Bởi vì tất cả những hoạt động này đều quan trọng với phát triển phần mềm, chúng ta cần sử dụng đầu ra của chúng ngay lập tức; để nhận được các phản hồi cần thiết nhằm loại trừ hao phí.

Lấy ví dụ về việc thu thập yêu cầu. Nó sẽ không được cải tiến bởi một tá các qui trình thu thập yêu cầu phức tạp. Nó sẽ được cải tiến bằng cách rút ngắn đoạn đường giữa “việc tạo ra các yêu cầu chi tiết” và “việc triển khai các phiên bản phần mềm”. Sử dụng ngay lập tức yêu cầu chi tiết ngầm ý rằng thu thập yêu cầu không phải là một giai đoạn mà kết quả là một thứ tài liệu tĩnh; thu thập yêu cầu là hoạt động diễn ra suốt quá trình phát triển, nó sản xuất ra các chi tiết vừa ngay khi chúng được cần đến.

Có rất nhiều mặt của TPS tương đồng với phát triển phần mềm; những ý tưởng hữu ích chẳng hạn như: huấn luyện chéo giữa các công nhân, tổ chức nhà máy thành nhiều ô, và lập các hợp đồng chia sẻ thành quả giữa khách hàng và nhà cung cấp. Nếu bạn có hứng thú, tôi khuyên bạn nên đọc quyển Toyota Production System của Ohno.


Sưu tầm

Read more “Toyota Production System (TPS)”

Default transaction scope trong MS SQL Store Procedure

Người đăng: Unknown Posted under -

Nếu không khai báo tường minh begin/end trans trong sql store procedure thì default transaction scope từ đâu đến đâu ?

Viết 1 storeproc in ra giá trị transaction count trong hai trường hợp, có khai báo và không khai báo begin tran

ALTER PROCEDURE TestTrans
AS

BEGIN tran
PRINT @@TRANCOUNT
COMMIT tran

EXEC TestTrans

Kết quả là nó in ra số 1 khi có khai báo và 0 khi không khai báo. Nguyên nhân do đâu ?

* M$ quan điểm một sql statement là một transaction, đây là đơn vị transaction nhỏ nhất được ms tự hiểu mà ko cần khai báo.

* Đối với trường hợp batch statement, buộc phải khai báo tường minh begin/end tran (oracle tự động set transaction khi execute một batch các statement).

* M$ cung cấp một option để setting ở mức server là SET IMPLICIT_TRANSACTIONS {On Off} (default là Off) cho phép tự động start một transaction khi execute một số statement và không đang ở trong một transaction khác.


Nguồn: :-Dzinh on tech

Read more “Default transaction scope trong MS SQL Store Procedure”

Object-Oriented Javascript

Người đăng: Unknown Posted under -

Không thể nào bỏ xuống được khi đọc. Cuốn sách này làm tôi thay đổi quan điểm của mình về Apress - một nhà sách được viết bởi mấy tác giả củ chuối của Ấn Độ, toàn là mấy cái dễ và ko có gì chuyên sâu cả.

Chương này tác giả đánh giá là chương quan trọng nhất trong cuốn sách, bàn về references, scope, closure, context.

Thuật ngữ object-oriented javascript có vẻ thừa thải vì javascript language toàn bộ là object, có cái nào khác object đâu. Nhưng tác giả muốn nhấn mạnh ở đây vì đa số cách sử dụng toàn là functionally, hiểu sai khái niệm và mơ hồ trong việc sử dụng object của hầu hết các developer.

References

Reference là 1 pointer trỏ đến location thật của object. Nếu 2 object có cùng 1 reference thì sửa cái này cái kia cũng bị thay đổi theo (cái này bình thường). Tuy nhiên, một số cái ta có thể ta không để ý:

* Javascript không có khái niệm reference đến 1 reference (Perl có), mà object khi reference sẽ reference đến một object thật sự. Do đó nếu object ban đầu trỏ đến một đối tượng khác thì các object kia reference đến nó sẽ không bị ảnh hưởng.

var items = new Array("one", "two", "three");
// itemsRef reference to item
var itemsRef = items;

// set items to equal a new object
items = new Array("four", "five");

alert(items != itemsRef);

* Chú ý một số tác vụ modify object có thể sinh ra một object mới (như concatenate string trong js)

var item = "test";
var itemRef = item;
item += "ing";
// do tác vụ cộng chuỗi làm cho object item trỏ đến một đối tượng khác, không còn là "test" nữa
alert(item != itemRef);

Scope

Scope được tính bên trong function, không phải bên trong block (vd while, if, for). Trong js, mỗi function được execute như là một method của một object.

Nếu ta khai báo biến và function khơi khơi, không chỉ định 1 scope nào hết thì nó thuộc về global scope, thật ra là thuộc về scope của object window. Xem ví dụ sau:

var foo = "test";

function test() {
var foo = "tele";
}

test();
alert(foo == "tele"); // return false;

do biến foo bên trong hàm test chỉ thuộc scope của hàm test nên nó không làm ảnh hưởng đến biến toàn cục foo bên ngoài.

Closures

Phần closure tác giả viết không hay như trong cuốn Asp.net Ajax in Action (chương 3 - javascript for ajax developers).

Closures là cách thức một inner function có thể tham khảo đến các biến trong một function cha, ngay cả khi function cha đó đã bị terminated. Xem ví dụ sau

function parent(arg) {
var parentVar = "I am a variable of parent";

function child() {
alert(arg + parentVar);
}

child();
}

parent("hello, "); // alert message hello, I am a variable of parent

Hàm child trong ví dụ trên gọi là nested function, được khai báo bên trong hàm cha. Ta thấy nó có thể truy xuất các biết định nghĩa bên ngoài function body của nó. Vấn đề này bình thường. Chuyện gì xảy ra nếu ta thay đổi như sau:


function parent2(arg) {
var parentVar = "I am a variable of parent";

function child() {
alert(arg + parentVar);
}

return child;
}

var theChild = parent2("yes, ");
theChild(); // alert message - yes, I am a variable of parent

Ta thấy rõ ràng sau khi hàm parent2 của nó được gọi và terminated, các variables của nó vẫn còn tồn tại và có thể được truy xuất bởi inner function. Đây gọi là closure.

Context

Là object vùng code mà object đang hoạt động bên trong. Biến this luôn reference đến object này (trong global context, biến this chỉ đến window object). Xem ví dụ sau:

var obj = {
yes: function() {
// this == obj
this.value = true;
},
no: function() {
this.val = false;
}
}

alert(obj.val == null); // ban đầu chưa gọi hàm nên biến val chưa tồn tại

obj.yes();
alert(obj.val == true);

// ta trỏ hàm no của object window vô hàm no của object obj
window.no = obj.no;
window.no(); // hàm no sẽ được execute trong context của window object

alert(obj.val == true); // do đó val của obj không bị thay đổi
alert(window.val == false); // hiển nhiên

Javascript cung cấp một cách set context vào trong function khi gọi hàm, thông qua hàm call. Ví dụ:

function changeColor(color) {
this.style.color = color;
}

var main = document.getElementById("main");
changeColor.call(main, "black"); // this bây giờ trỏ vô biến main

Object Creation

Phần này thấy đơn giản nhưng cũng có nhiều điều thú vị. Trong javascript, không có khái niệm class (nên không thể tạo object với một kiểu class nào đó), chỉ có object. Object này có thể tạo ra object kia và thừa kế từ các object khác (gọi là prototypal inheritance)

Để tạo một object có 1 kiểu nào đó, javascript cung cấp phương pháp khởi tạo function như là một object. Xem ví dụ sau:


function User(name) {
this.name = name;
}

var me = new User("my name"); // khởi tạo object của function đó qua toán tử new (constructor)
alert(me.name == "my name"); // name bây giờ trở thành property của object me, this pointer trỏ vào me
alert(me.constructor == User); // property constructor của me bây giờ chính là User

Ví dụ này chứng tỏ:

* Mỗi object đều có constructor property
* Constructor property trỏ vào function nào đã tạo ra nó.


Nguồn :-Dzinh on tech [Chapter 2 - Prof Javascript Techniques (Apress)]

Read more “Object-Oriented Javascript”

Javascript execution context

Người đăng: Unknown Posted under -

The Execution Context

Execution context là một khái niệm trừu tượng, được đặc tả bởi ECMSScript specification (ECMA 262 3rd edition). Nó có thể được xem như là các objects cùng với những properties (nhưng không phải là public properties).

Tất cả các javascript code được executed trong một execution context. Global code (code được execute inline, hoặc trong JS file, hoặc HTML page...) được execute trong global execution context và mỗi một lời gọi hàm sẽ có một conetxt object đi kèm với nó. Code được execute bằng hàm eval cũng có một execution context riêng, nhưng vì eval không thường được sử dụng bởi javascript programmer nên nó sẽ không được discuss ở đây. (các bạn có thể xem đặc tả của nó trong section 10.2 của ECMA 262)

Khi một javascript function được gọi, nó bước vào một execution context. Nếu một function khác được gọi (hoặc gọi lại chính nó theo cách gọi đệ quy) thì một execution context mới sẽ được tạo ra và lời gọi hàm sẽ enter vào context đó cho đến khi nó trả ra kết quả. Việc này dẫn đến javascript code hình thành nên một stack các execution context trong quá trình gọi.

Khi một execution context được tạo ra, một số việc sẽ xảy ra theo một thứ tự được định nghĩa trước. Đầu tiên, trong execution context của một function, một "Activation" object được tạo ra. Activation object này là một cơ chế đặc tả khác. Nó có thể được xem như là một object vì nó có các properties có thể truy xuất được. Nhưng nó không phải là một object bình thường vì nó không có prototype và không thể được reference trực tiếp bằng javascript code.

Bước tiếp theo của việc tạo ra execution context cho một lời gọi hàm là việc tạo ra argument object, là một object giống như array với các index là các số interger tương ứng với thứ tự của các parameter được truyền vào. Nó cũng có length và callee property. Một property của Activation object được tạo ra với tên là "arguments" và trỏ đến object này.

Bước tiếp theo execution context được gán vào một scope. Scope bao gồm một danh sách (hoặc một dây - chain) các objects. Mỗi function object có một property bên trong tên là [[scope]] và nó cũng chứa một danh sách các object. Scope gán cho execution context cho một function là một danh sách được tham khảo bởi [[scope]] property của function object đó với một chút thay đổi là Activation object sẽ được thêm vào đầu tiên của danh sách.

Quá trình khởi tạo các variables diễn ra bằng cách sử dụng một object gọi là "Variable" object (tham khảo ECMA 262 phần khởi tạo biến 10.1.3). Thật sự, Activation object và Variable object là một (!!!). Các properties được đặt tên cho Variable object được tạo ra cho mỗi parameters của function, và nếu các arguments của lời gọi hàm tương ứng với các các parameters này, giá trị của chúng sẽ được gán cho các properties của Variable object (các giá trị default sẽ là undefined). Các inner function được định nghĩa bên trong sẽ tạo ra các function objects và được gán thành các properties của Variable object với tên tương ứng là tên của các inner function. Bước cuối cùng trong quá trình khởi tạo biến là tạo ra các properties với tên tương ứng với các local variables được khai báo bên trong function.

Các properties được tạo trên Variable object tương ứng với các biến cục bộ được khai báo bên trong hàm ban đầu sẽ được gán giá trị là undefined, sau đó việc khởi tạo thật sự sẽ diễn ra trong quá trình evaluation của assignment expression bên trong thân hàm.

Sự kiện Activation object - cùng với property arguments của nó - và Variable object - cùng với các properties có tên tương ứng các local variables - cùng chỉ đến một object cho phép arguments được đối xử như là biến local của function.

Cuối cùng, nếu một giá trị được gán đang tham khảo đến một object mà sau đó các tác vụ truy xuất property có prefix là keyword this, thì nó sẽ dùng giá trị của object đó. Nếu không có từ khóa this hoặc giá trị được gán là null (tức là không nằm trong một object nào đó), nó sẽ refer đến global object.

Global execution context có một vài khác biệt nhỏ vì nó không có arguments nên nó không cần phải có một Activation object tham khảo đến nó. Global execution context thật sự cần một scope và scope chain của nó chỉ chứa một object, đó là global object. Trong quá trình duyệt để khởi tạo biến của global object, nó sẽ được dùng như một Variable object, do đó các biến toàn cục (hoặc các hàm top-level function) sẽ được tạo thành các properties với cùng tên, giống như mô tả ở trên.


Nguồn :-Dzinh on tech

Read more “Javascript execution context”

Command Pattern

Người đăng: Unknown Posted under -


Đang có nhu cầu refactoring đoạn code trong cty và muốn dùng Command Pattern nên đọc lại nó một chút. Ngoài cuốn sách của GoF kinh điển thì cuốn Head First - Design Patterns của nhà xuất bản O'reilly khá hay, nó lấy ví dụ trong cuộc sống và cách trình bày làm cho người đọc cảm thấy ít khô khan hơn.

Issue được đưa ra từ ví dụ sau: có một cái remote control có nhiều khe (slot), mỗi khe có thể được lập trình để điều khiển các thiết bị khác nhau. Có hai nút cho mỗi khe là On/Off, một nút Undo dùng chung cho tất cả các khe (xem hình)


Có nhiều thiết bị khác nhau, như quạt, đèn, TV, máy nước nóng (hottub)... Ta phải lập trình sau cho remote control có khả năng bật tắt trên các thiết bị đó, tùy vào ngữ cảnh user nạp thiết bị vào trong slot nào.

Ý nghĩ đầu tiên về cách lập trình:

if (slot1 == light) light.on();
else if (slot1 == hottub) hottub.on();
else....

--> chuối quá.

Có cách nào tách rời giữa remote control và các vendor class, nó không cần biết phải bật/tắt trên class nào, chỉ đơn giản là execute một command, không quan tâm bên trong command đó làm việc gì (bản thân command tự biết). Đây gọi là decouple requester của một action và object thực hiện action đó.

Command pattern thực hiện như sau:

* Tạo ra một command object encapsulate một request làm một action nào đó (giống như turn on a light) và trên một đối tượng nào đó (vd trên đối tượng bóng đèn).

* Store command object đó. Invoker khi có nhu cầu sẽ gọi execute trên command đó (giống như load các command trên mỗi button, khi user nhấn nút thì gọi command execute, không quan tâm đến nó làm cái gì)

Implementation

Tạo ra 1 interface chung Command

public interface Command {
public void execute();
}

public class LightOnCommand implements Command {
Light light;

public LightOnCommand(Light light) {
this.light = light;
}

public void execute() {
light.on();
}
}

public class TestRemoteControl {
public void Test() {
RemoteControl remoteControl = new RemoteControl(); // class remoteControl tu viet

Light light = new Light();

LightOnCommand lightCommand = new LightOnCommand(light);

remoteControl.setCommandOnSlot(1, lightCommand); // set lightCommand on slot 1

remoteControl.pressButton(1); // simulate press button 1
}
}

Trở lại đoạn code cần refactor, có khá nhiều use cases trong business flow, làm thế nào để code vừa áp dụng được pattern trên vừa thể hiện rõ business mà nó đang chạy nhất.


Review document ta thấy có 4 dạng business chính, wrapper lại thành 4 command chính là MoneyTransferCommand, MobileRechargeCommand...

Các command này thực hiện action trên 2, 3 đối tượng là YP, BP (banking Pichincha), Commerce (third party), ... (trong command pattern, đối tượng này gọi là Receiver)

Code được viết như sau:

public class MoneyTransferCommand : Command
{
YP yp;
BP bp;

// .......

public void Execute()
{
transActionStatus = yp.ValidateTransaction(incoming);

swith(transactionStatus)
{
case SUCCESS:
bp.MoneyTransfer();

break;

//......
}
}
}

CommandFactory thực hiện việc tạo ra các command từ incoming rồi bỏ vào trong queue. Các thread sẽ thực hiện command trong queue


Nguồn :-Dzinh on tech [Chapter 6 - Design Patterns (Head First)]

Read more “Command Pattern”

Code đẹp và code dễ đọc

Người đăng: Unknown Posted under - ,


Trong nhiều năm - thực sự nhiều thập kỷ qua - Tôi là một fan hâm mộ lớn của code đẹp. Tôi đọc gần như tất cả mọi thứ của Brian Kernighan, Jon Bentley, và P. J. Plauger. Niềm đam mê này là một cố gắng tạo lại sự hăm hở (rush) khi tôi đọc được đầu tiên dòng code:

*x++ = *y++

Trong ngôn ngữ lập trình. Tôi chưa bao giờ nhìn thấy bất cứ đoạn code nào cô đọng đẹp đến vậy. Nó đã được phát minh! Nhưng nhiều năm qua, tôi đọc rất nhiều các thuật toán thông minh, rất nhiều tối ưu hóa ấn tượng, rất nhiều thủ thuật nhỏ. Và tôi đã nhận ra càng ngày càng ít hơn những gì thu được (charge) trong những khám phá đó. Lý do là, khá thẳng thắn, là chúng gần như luôn luôn rơi vào một trong hai loại: một số cách thể hiện rất tao nhã trong một ngôn ngữ mới (Ruby được chuyển từ Java là một minh chứng) hoặc một kỹ thuật mà tôi không bao giờ có khả năng để sử dụng. Nói cách khác, tôi đang theo đuổi những món đồ chơi rẻ tiền. Theo thời gian, khiếu thẩm mỹ của tôi chuyển thành việc code một cách sáng sủa vì sự dễ chịu của nó.

Bây giờ, nếu tôi có thể chọn ra một đoạn code phức tạp, đọc nó lướt qua, và hiểu một cách chính xác những gì nó làm, thì tôi cảm thấy hăm hở trở lại. Tôi thường có cảm giác này khi đọc các đoạn code từ những lập trình viên giỏi, hoặc không hàng lâm. Nói một cách trung thực, khi miệt mài trong khoảnh khắc như vậy, tôi thường xuyên nhận thức rằng đoạn code của tôi không giống như họ. Thậm chí đoạn code hay nhất của tôi hoàn toàn không giống với họ một chút nào. Và tôi đã tự hỏi tôi có thể làm gì để cải thiện tính rõ ràng (clarity) trong đoạn code của tôi.

Cuốn sách mới của Kent Beck, Implementation Pattern là một cuốn sách tóm tắt ngắn về code rõ ràng. Tôi đã đọc nhiều về nó và tôi đã nhận ra rằng một số thói quen xấu của tôi đã làm phá hoại đi tính đọc được của đoạn code. Beck cơ bản chỉ nhìn vào các đoạn code có vấn đề và tư vấn những lời khuyên khôn ngoan.

Điều này có nghĩa là vài lời khuyên là thích hợp nhất cho người mới bắt đầu, trong khi chúng chỉ đủ là các lời gợi ý tế nhị để giữ sự chú ý của một người kỳ cựu, người quan tâm đến sự rõ ràng.
Ví dụ, một trong những thói quen xấu là tôi thường code mà không không cần suy nghĩ nhiều về sự pha trộn của các mức độ trừu tượng hóa trong cùng một method. Vì vậy, ví dụ (sử dụng ví dụ của Beck):

void process() {
input();
count++;
output();
}

Dòng code thứ hai rõ ràng ở một mức độ trừu tượng khác với hai cái kia, và làm cho đoạn code khó đọc một cách nhanh chóng. Beck đề nghị giải pháp sau đây, mà tôi đồng ý là rõ ràng hơn.

void process() {
input();
tally();
output();
}

Có nhiều thói quen xấu khác của tôi mà cuốn sách này đã soi sáng. Và trong nửa tá thay đổi sẽ mang đến cho phong cách của tôi, tôi nghĩ rằng tôi đã thu được nhiều lợi ích hơn so với trong tất cả các bài luận tôi đã đọc về chủ đề beautiful code.

Tuy nhiên trước khi kết thúc, tôi nên đưa ra hai lời cảnh báo: Tài liệu cho người mới bắt đầu đến trung cấp đang tràn lan, vì vậy bạn sẽ cần phải lươm lặt trên phần lớn đống chữ nghĩa đó để rút trích ra các thông tin có giá trị. (Tuy nhiên, khía cạnh này tạo món quà cho các lập trình viên junior ở vị trí của bạn.) Điểm thứ hai là cuốn sách này thiếu chỉnh sửa tốt. Một cuốn sách về clarity code thì nên trong sáng; cuốn này thì không. (Xem xét việc sử dụng các từ ‘mẫu từ,' nó rất dể gây hiểu lầm cao. Và không phải tất các mẫu từ đều như vậy.) Nhưng những vấn đề này có thể chấp nhận được.


Nguồn :-Dzinh on tech [Beautiful code vs Readable Code]

Read more “Code đẹp và code dễ đọc”
/
Blogumulus by Roy Tanck and Amanda FazaniInstalled by CahayaBiru.com

Followers

Cộng đồng Blogger

Comedown's Blog
TruongGTGR - Nơi siêu xe hội tụ
Tư vấn tin học