Một ví dụ thực tế của Factory chính là trình duyệt ảnh như ACDSee chẳng hạn. Bạn có 1 list các hình ảnh, tuy nhiên mỗi hình ảnh có thể là 1 đối tượng của JPEGRenderer hoặc PNGRenderer, nghĩa là thuôc các lớp hoàn toàn khác nhau. Và khi render list các hình ảnh này thì ACDSee cần phải xác định lớp nào – JPEGRenderer hoặc PNGRenderer sẽ được chọn.  Một FactoryClass sẽ đóng vai trò chọn ra class instance thich hợp.

Bài viết này chi gói gọn trong phạm vi trình bày cách sử dụng ClassFactory và ItemRenderer hơn là đi sâu vào phân tích tính chất của mẫu thiết kế Factory. Hơn nữa mẫu thiết kế này được phân tích rất chi tiết trong tài liệu ActionScript 3.0 Design Patterns.

ClassFactory

Flex ClassFactory cho phép tạo ra một instance của lớp bất kỳ với các thuộc tính giống nhau. Để khởi tạo một đối tượng của FactoryClass thì điều đầu tiên là bạn phải chỉ rõ đối tượng lớp nào cần được khởi tạo bằng cách truyền class vào hàm dựng của ClassFactory

var animalHasTailRenderer:ClassFactory = new ClassFactory(AnimalRenderer);
animalHasTailRenderer.properties = { hasTail: true };

Trong đoạn mã trên,  để tạo ra một class instance của animalHasTailRenderer thì Flex sẽ gọi phương thức newInstance() của đối tượng factory và thiết lập thuộc tính hasTail = true thông qua việc gán setter properties.

ItemRenderers

Khi tiếp cận với DataGrid, List … bạn sẽ va chạm rất nhiều với ItemRenderer . Người tiền nhiệm của ItemRenderer chính là cellRenderer AS2 – nếu bạn đã có kinh nghiệm sử dụng các component của Flash.

Ngữ cảnh sử dụng ItemRenderer thường được dùng với DataGrid – bạn cần đặt các checkbox hay combobox vào từng dòng của DataGrid chẳng hạn, hay mỗi dòng sẽ là một component khác nhau.  Bạn có thể xem một ví dụ điển hình của việc sử dụng itemRenderer như đoạn mã mxml dưới đây

<mx:DataGrid id="myGrid" dataProvider="{customerXMLList}">
     <mx:columns>
          <mx:DataGridColumn dataField="Company" itemRenderer="org.catapult.renderers.CompanyRenderer"/>
          <mx:DataGridColumn dataField="Contact" itemRenderer="org.catapult.renderers.ContactRenderer"/>
     </mx:columns>
</mx:DataGrid>

Một ItemRenderer có thể được tao từ mã ActionScript thuần túy hay mã MXML, tuy nhiên phải được implement từ IFactory. Lý do là bạn phải cài đặt phương thức newInstance để ClassFactory có thể gọi được.

ActionScript

package org.catapult.renderers {
     import mx.containers.VBox;
     import mx.core.IFactory;

     public class CompanyRenderer extends VBox implements IFactory {       
           public function newInstance():* {
                return new CompanyRenderer();
           }
     }
}

MXML

<?xml version="1.0" encoding="utf-8"?>
<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" implements="mx.core.IFactory">
     <mx:Script>
           <![CDATA[
                public function newInstance():* {
                       return new CompanyRenderer();
                }
            ]]>
    </mx:Script>
</mx:VBox>

Bản chất của việc gán itemRenderer trong đoạn mã trên là việc tạo ra một class instance kiểu object factory.

Tham khảo:

1. ActionScript 3.0 Abstract Factory Design Pattern: Multiple Products and Factories

Trong bài viết này, tôi giữ nguyên tên gọi IoC và DI mà không cố gắng tìm bản tiếng Việt vì quả thật là rất khó để có thể tìm một danh từ tiếng Việt cho IoC cũng như DI. Bạn hãy hiểu thông qua định nghĩa của chúng hơn là tìm một cái tên thuần Việt cho chúng.

IoC – Inversion of Control là gì ?

Về bản chất thì IoC có thể hiểu như việc khi bạn thiết kế 1 class thì class đó nên phụ thuộc vào một abstract class hay  interface chứ không phu thuộc (hoặc được dẫn xuất) từ một lớp cụ thể. IoC gắn liền với các ý tưởng thiết kế trong OOP, vì lập trình hướng thủ tục (POP – Procedure Oriented Programming), các module cấp phía trẹn lại phụ thuộc vào các module cấp dưới, và vấn đề là nếu các module cấp dưới có sự thay đổi thì phải  thay đổi cả các module cấp phía trên. Bạn có thể hiểu như là control của cấp trên phụ thuộc vào cấp dưới. Với OOP thì lập trình viên sẽ đi theo hướng thiết kế các lớp cấp cao phụ thuộc vào 1 abstract class hay interface, hơn là phụ thuộc (hay dẫn xuất) từ môt lớp cấp dưới, và khi đó tất cả sự thay đổi của các lớp cấp dưới đều không ảnh hưởng đến cấp phía trên … Như vây sự phụ thuộc được đảo ngược lại – khái niệm IoC có thể diễn gỉải theo cách này.

Với một framework thì các phương thức mà lập trình viên kế thừa từ framework sẽ được gọi bởi chính framework hơn là từ mã chương trình của lập trình viên viết. Việc điều phối, sắp xếp hoạt động của các luồng trong ứng dụng cũng do framework quản lý, và IoC cho phép một framework hoạt động như một hệ điều khiển mở rộng hơn là đóng vai trò chính điều khiển ứng dụng.

Với Cairngorm, PureMVC thì IoC được tiếp cận theo hướng mở rộng các lớp của framework và framework sẽ được định hướng cho biết các interface nào thích hợp để truy cập và thao tác các ứng dụng các đối tượng cụ thể. Parsley, Swiz cung cấp metadata annotation để móc nối với hoạt động của framwork.

DI – Dependency Injection là gì ?

Thường thì bạn sẽ định nghĩa các đối tượng trong ứng dụng một cách cụ thể trong chính mã nguồn. Với DI, đó là một cơ chế bên ngoài “tiêm” một biến định nghĩa instance của một đối tượng. DI thường được áp dụng trong Unitest, cho phép bạn tạo ra các đối tượng có quan hệ lỏng lẻo với nhau và dễ dàng thay thế các đối tượng “demo” mà bạn phải hardcode sẵn trong mã nguồn. Quá trình test sẽ kiểm định các đối tượng một cách độc lập chứ không quan tâm đến mối quan hệ giữa các đối tượng khác nhau.

Ngoài ra, việc áp dụng DI cũng tăng khả năng tái sử dụng mã nguồn, vì khi việc phụ thuộc giữa các đối tượng không còn được hard code trực tiếp trong mã nguồn nữa thì quá trình tái sử dụng có thể dễ dàng hơn, vì đơn giản là thay đổi các đối tượng được “tiêm” từ bên ngoài vào mà thôi …

Các tính năng của Parsley

Để minh họa cho việc cài đặt IoC và DI, trong bài tiếp theo tôi sẽ nói về framework Parsley với một ứng dụng nhỏ để minh họa. Có thể điểm qua các chức năng của Parsley như sau:

• Flexible IOC Container: Hỗ trợ cấu hình với AS3 Metadata, MXML, XML , ActionScript
• Dependency Injection: “tiêm” theo kiểu hoặc id cho cả hàm dựng (constructor), phương thức, thuộc tính …
• Decoupled Bindings: Thông qua cơ chế đăng ký, Parsley cho phép binding dữ liệu khi nguồn dữ liệu và đối tượng đích tách biệt nhau.
• Messaging Framework: đối tượng gửi và nhận hoàn toàn tách rời, có thể làm cơ sở cho kiến trúc MVC
• Dynamic View Wiring:  Tạo kết giữa các  component Flex cho các đối tượng khai báo trong container
• Advanced container features: Bất đồng bộ khởi tạo các đối tượng, vòng đời đối tượng, ngữ cảnh  cấu hình mô-đun
• Integration with Flex Modules: Cho phép cấu hình được nạp và giải phóng cùng với module Flex
• Localization: Tích hợp với Flex ResourceManager cho các ứng dụng Flex, ngoài ra còn có Framework dành riêng cho việc localization (bản địa hóa) cho các ứng dụng Flash.
• Extensibility: Dễ dàng tạo ra các thẻ cấu hình do chính lập trình viên định nghĩa và có thể được sử dụng như AS3 Metadata, MXML hoặc tag XML.

Nhiều người sẽ thắc mắc, tại sao Adobe quyết định dùng Parsley thay vì dùng SpringActionScript, Mate … Thực sự vẫn chưa tìm được một tài liệu nào về việc này. Quan điểm chống MVC hay ủng hộ MVC vốn tồn tại từ lâu trong giới phát triển phần mềm, và từ những quan điểm trái ngược này mà nhiều giải pháp, framework được xây dựng. Adobe đã có một quyết định đúng đắn, là đưa ra Cairngorm 3 như một giải pháp tổng thể kết hợp các quan điểm trên. Tuy mất đi tính độc lập nhưng điều đó mang lại lợi ích cho lập trình viên.  Kiến trúc phần mềm thực sự phức tạp để quản lý và ứng dụng vào thực tế. Có nhiều mô hình cơ bản và hướng dẫn có thể giúp các nhà phát triển phầm mềm khi triển khai, và đôi khi tính đúng đắn không tồn tại mà thay đó là khả năng đáp ứng thực tế được quan tâm nhiều hơn.

Một số tính năng của mod_python

Một số tính năng của mod_python, bao gồm:

Trong phần này, tôi trình bày về mod_python handler và quản lý session. PSP và Authentication sẽ được trình bày ở loạt bài sau.

mod_python handlers

Bạn có thể chỉ định cho Apache xử lý các request bằng các module viết bằng python thông qua mod_python. Ví dụ, bạn cần tận dụng tính năng authentication có sẵn của Python để kiểm tra quá trình đăng nhập của User, bạn có thể sử dụng PythonAuthenHandler. Để báo cho Apache phần nào sẽ do mod_python xử lý, bạn cần khai báo các handler tương ứng trong tập tin httpd.conf . Xét một ví dụ sau trích từ file httpd.conf trên Apache 2.x

<Directory "/Users/lamdo/Documents/workspace/PythonWebApp/src">
    SetHandler mod_python
    PythonHandler base_http_handler
    PythonAuthenHandler base_authentication_handler
    PythonDebug on
    Order allow,deny
   Allow from all
</Directory>

Trong thiết trên, tất cả các request đến các script python trong /Users/lamdo/Documents/workspace/PythonWebApp/src đều được xử lý qua base_htpp_handler – vốn là 1 file python để nhận và xử lý các http_request. Bạn cũng thấy là tôi sử dụng PythonAuthenHandler và chuyển các request này cho 1 file python la base_authentication_handler.

Quản lý Session

Quản lý session là tính năng không thể thiếu của các web-server. Tất nhiên mod_python cũng phải có tính năng này. Không chỉ cung cấp các chức năng quản lý session có sẵn từ Apache mà còn cho phép bạn viết các API để tự quản lý session, tất nhiên là bằng ngôn ngữ python … Dưới đây là một ví dụ cụ thể về chức năng quản lý session của mod_python. Đoạn script này tôi trích từ file base_http_handler.py, file tôi dùng để quản lý các request.

from mod_python import apache, Session

def handler(request):
    session = Session.Session(request)
    if session.is_new():
       visit_token = 'application started'
    else:
       visit_token = 'application started already'
    session.save()
    echo(request, 'Token status %s' % visit_token, type='text/plain')
    return apache.OK

def echo(req, content, type='text/html'):
    req.content_type = '%s; charset=UTF8' % type
    req.write(content, 0)

Trong ví dụ trên, khi lần đầu bạn gửi request đến server, bạn sẽ thấy base_http_handler trả về application started, và nếu refresh lại sẽ thấy application_started_already.

Hai phe này, họ là ai ?

Những người ủng hộ Flash – lực lương xung phong đầu tiên có thể nói là các lâp trình viên và các thiết kế viên Flash (trong đó có cả tôi).  Với họ thì Flash chính là nồi cơm nuôi sống bản thân, gia đình của họ. Làm người thì phải có chính kiến của mình nên thái độ ủng hộ Flash của họ là hoàn toàn rõ ràng, dù đứng ở góc độ chuyên môn thì những vấn đề mà Flash đang bị như memory leak, memory over consuming họ đều biết cả chứ  :D Trong số các lập trình viên Flash hay chuyên viên thiết kế Flash thì cũng có những người có “số má”, và có vẻ họ đều có những phương pháp cũng như kinh nghiệm để né tránh những vấn đề này. Chính vì thế họ vẫn trung thành và ra sức bảo vệ cho công nghệ họ đã chọn lựa.

Những người “chống” Flash – họ có thể là các tín đồ của M$ mà một thời đã từng hy vọng vào Silverlight và đến giờ vẫn … hy vọng tiếp (sorry các bác silverlight ). Ngoài ra còn kể đến những người ghét quảng cáo và bị hàng tá “banner flash” làm cho nhức mắt. Tôi từng gặp những người này – khi cài một browser mới thì việc đầu tiên anh ta làm là  tắt plugin flash để khỏi thấy Flash . Số lượng lớn nhất phải nói đến là các iFan (ai – phang) với  khẩu hiệu “Flash will die”, “HTML5 – Flash Killer” xuất hiện khắp nơi. Sự ồn ào của phe này tưởng như  giới công nghệ sắp chuẩn bị cho tang lễ của Flash vậy. Một số bài viết bắt đầu đưa ra các tiên đoán về số phận những người làm việc với công nghệ Flash – họ sẽ đi về đâu một khi công nghệ Flash về với cát bụi Ngay cả khi tôi được yêu cầu chuyển sang làm Python thì các bạn tôi lại quả quyết rằng tôi đang chuẩn bị “hậu sự” cho công việc Flash Developer  …

Lao đông là vinh quang, cho dù làm bất cứ nghề gì ta đều có quyền tự hào và yêu quý nó. Ngay cả lúc nó sa cơ lỡ vận hoặc mai một dần khiến ta không còn kế sinh nhai … mặc dù tôi là người có cái nhìn lạc quan về Flash và luôn tin tưởng vào Adobe, vào Flash  … nhưng trước những biến động như vậy, tự mình không thể không … ưu tư. Tuy nhiên tôi lại ưu tư về nghề nghiệp hơn là về công nghệ Flash.

Làm Flash có lên “sếp” được không ?

Tính ra thì tôi cũng làm Flash được 4 năm rồi. Từ một người hoàn toàn không biết gì về Flash, tôi bắt đầu làm việc cho một công ty out sourcing có số má trong lĩnh vực Flash là Pyramid Consulting. Tất nhiên ở một vị trí starter thì tôi chỉ cắm đầu vào làm việc cho công ty và không biết gì khác hơn ngoài công ty. Rồi cũng mon men lên vị trí senior theo số năm, mà thực ra tôi nghĩ mình chỉ thuộc diện “sống lâu lên lão làng” mà thôi . Mà quả thực đến bây giờ tôi cũng chẳng là sếp hay là gì cả

Tôi cũng không dám vơ đũa cả nắm mà tuyên bố rằng làm Flash ở Việt Nam là không có đường tiến, hay bi quan hơn là không có tương lai gì … Bằng chứng là khối bạn bè tôi vẫn sống trong vinh quang và no đủ khi làm flash đó thôi. Như Đăng Hải giờ đang “sếp xòng” ở Vinagame Sài Gòn, hay Trọng Thanh đang kéo cả đoàn tàu Flash của Pyramid Consulting Vietnam. Lãng tử như Hai Lúa Vũ Anh giờ cũng là người có số má ở PlaySoft . Mà nổi nhất vẫn là Lưu Xuân Việt, thằng bạn thời nối khố mới  làm Flash hơn 1 năm giờ đã bắt đầu “khạc ra lửa” ở VON. Nhưng thực tế là họ không làm đơn thuần Flash mà còn biết thêm các công nghệ server side như PHP, .NET … Điều đó chứng tỏ rằng để tồn tại  và phát triển trong lĩnh vực này, bạn cũng cần phải có kiến thức ở các lĩnh vực khác … nói chung là biết càng nhiều càng tốt.

Làm Flash có “giàu” không ?

Nếu tính đến thời điểm cuối cùng mà tôi vẫn còn làm “thuần” Flash – nghĩa là không làm gì khác ngoài Flash – khoảng hơn 1 năm trước thì mức lương của tôi cũng làng nhàng khoảng 10 triệu. Mặc dù con số đó không nhỏ nhưng cũng hết sức bình thường với vị trí và công việc của tôi mà thôi. Cách duy nhất để kiếm thêm đó là đi code dạo – hay nhận thêm dự án bên ngoài để làm thêm ở nhà. Tất nhiên bạn có thể kiếm được kha khá hơn chút … Nếu giỏi thì bạn có thể có thu nhập nhiều hơn công việc chính. Và nhất là khi bạn đã có được mối quan hệ tốt và nhận được rất nhiều dự án, bạn phải tìm kiếm thêm người để chia sẻ. Một số người bạn của tôi đã mạnh dạn bỏ luôn công việc chính và chuyển sang làm free – lancer đúng nghĩa và họ nhanh chóng trở thành đại gia có máu mặt trong lĩnh vực này …

Quay về chuyện đi code dạo của tôi – một thằng lờ khờ ít quen biết và chủ yếu nhận yêu cầu từ người quen cho nên số tiền tôi kiếm được cũng rất khiêm tốn. May mắn thì có một số đại gia số má trả tiền thơm, hơn nữa họ đều là những người có kỹ thuật tốt nên việc đưa các project phù hợp với khả năng của mình cũng như điều tiết được yêu cầu của khác hàng nên làm việc với họ là khá thoải mái. Phần còn lại thì … có nhiều điều để đáng nói đây

Cách đây khoảng 2 năm, có một người giới thiệu cho tôi một project làm flash site cho 1 cửa hàng uốn tóc. Tiền chưa biết trả đến đâu nhưng yêu cầu thì khá hoành tráng … Sau khi tôi làm demo và mang lên cho họ, còn nhận được một đống yêu cầu hoành tráng khác như , hình ảnh động và cả 1 tá yêu cầu về back office. Tưởng được khách hàng đại gia thì họ đề cập cái giá là 2 triệu đồng cho toàn bộ … thế là đành ngậm ngùi bỏ của chạy lấy người mà thôi

Như vậy để kiếm nhiều $ từ nghề này chắc hẳn việc đầu tiên là bạn phải có nhiều mối quan hệ tốt, nếu không chuyện “gặm xương” là không thể tránh khỏi …

Làm Flash có … cực không ?

Bỏ qua những vấn đề vể mặt công nghệ của Flash, tôi muốn nói đến chuyện làm Flash hơn … Lao động tất nhiên là cực khổ rồi Đâu có công việc nào nhẹ nhàng mà kiếm được nhiều tiền đâu. Bạn đừng tin quảng cáo tào lao kiếm 1 tháng 120 triệu mà chỉ ngồi làm survey. NHẢM.

Về bản chất Flash thường gắn liền với các campaign – chiến dịch mạrketing – quảng cáo nên đến khi 1 ý tưởng thành hình và trở thành 1 layout flash hoàn chỉnh thì bạn chẳng còn mấy thời gian để code. Điều đó nghĩa là bạn phải đua với thời gian. Đó là lý do ngày xưa tôi hay phải overtime vì đa số các project gắn liền với cái chiến dịch quảng cáo đã có deadline rõ ràng. Tất nhiên là thời gian để cài đặt tỉ lệ nghịch với số bug – nếu bạn càng ít thời gian để test, debug thì số bug sẽ nhiều. Điều an ủi duy nhất là các project này khi lên live site thường chỉ tồn tại trong thời gian ngắn và bạn hoàn toàn có thể “rũ bỏ trách nhiệm” bảo trì …  :D   Nếu bạn làm production thì cũng không đến nỗi, tuy nhiên cực hay không cực theo tôi lại đến từ tần suất thay đổi yêu cầu của khách hàng hơn là chuyện deadline. Bạn sẽ cảm thấy nản nếu khách hàng cứ bắt đập đi làm lại liên tục  :D

Kết luận

Cho dù bạn đã làm Flash, đang làm và sẽ làm Flash thì tôi khẳng định với bạn rằng bạn hoàn toàn có thể sống khỏe với công nghệ này. Mặc dù ưu tư thì vẫn là ưu tư nhưng tôi vẫn hoàn toàn tin tưởng vào Flash. Chuyện HTML5 thì cứ chờ đó. Hết Silverlight rồi đến Java FX, rồi Ajax – tất cả đều đã từng mạnh miệng là Flash Will Die nhưng rốt cuộc đã làm được gì đâu   Mà quan điểm của tôi: Flash là RICH MEDIA CONTENT  chứ không phải là WEB STANDARD nên việc cứ so với HTML5 thì thực là nực cười

Do yêu cầu của công việc nên tôi bắt đầu làm việc với Python. Có thể nói đây là lần đầu tiên tôi làm việc với một môi trường hoàn toàn xa lạ với mình – MAC OS X, Debian, Python, Apache … khi mà tôi đã quen thuộc từ lâu với Windows, .NET và IIS … Vạn sự khởi đầu nan, và sau 1 tuần mò mẫm thì cuối cùng cũng thấy ánh sáng cuối đường hầm

Tất nhiên để lập trình web thì ta phải có máy chủ phục vụ web (web server). Tôi cũng biết rằng MAC os X phiên bản 10.6.4 này đã có sẵn Apache 2.2, và hoàn toàn có thể hỗ trợ tốt python, và hơn nữa Python 2.6 cũng được tích hợp sẵn trong hệ điều hành này. Việc còn lại là tôi cần cài đặt mod_python – vốn là module nhúng trình thông dịch python vào máy chủ Apache theo mô hình CGI.Như vậy tôi chỉ cần tải về mod_python và cài đặt là xong ? Cuộc sống không đơn giản như thế

Vạn sự khởi đầu nan …

mod_python có thể download dễ dàng từ trang chủ của mod_python. Thực ra đây chỉ là source code của mod_python, trước khi cài đặt bạn phải compile và tất nhiên trong máy của bạn phải có GCC – GNU Complier Collection, nói nôm na là trình biên dịch C/C++. Nếu bạn sử dụng Linux, Unix thì sẽ chẳng bận tâm đến GCC vì nó đã được tích hợp sẵn. Tuy nhiên phiên bản MAC os X 10.6.4 không tích hợp sẵn trình biên dịch này… và cách “chuối bưởi” nhất đó là cài đặt thêm XCode 3 -bộ SDK của Apple, mặc dù có rất nhiều cách nhanh và gọn hơn để cài GCC. Tôi mất thêm hơn 2GB và gần 1 tiếng để download bộ XCode từ trang developer của Apple.

Sau khi download và cài đặt xong XCode, tôi liền mở terminal và thử luôn việc cài đặt mod_python bằng các lệnh sau:

$ tar xvzf mod_python-3.3.1.tar
$ cd mod_python-3.3.1
$ ./configure --with-apxs=/usr/sbin/apxs
$ make
$ sudo make install

Một loạt các lệnh được thực thi, tuy nhiên kết quả cuối cùng tôi nhận được là một thông báo lỗi

connobject.c:142: error: request for member 'next' in something not a structure or union apxs:Error: Command failed with rc=65536

Bó tay thật …

Gian nan nhưng chưa … chán

Tôi lại tiếp tục mò mẫm tìm xem nguyên nhân và cuối cùng thì tôi tìm ra được đây là lỗi của mod_python khi compile trên Snow Leopard – tức là cái hệ điều hành MAC os X 10.6.4 này  :| , và bug cũng được mô tả kèm theo bản vá (patch) tại đây. Tôi tải bản vá này vào chính folder source của mod_python 3.3.1, sau đó cài đặt nó bằng các lệnh sau:

$ cd mod_python-3.3.1
$ patch -p1 < mod_python-3.3.1-apr.patch 

Sau khi thực thi, hệ thống gửi lại cho tôi một thông báo để biết rằng quá trình patch đã … thành công

patching file src/connobject.c

và bây giờ, tôi thực hiện lệnh compile, sau khi đã vượt qua hàng tá thứ để cài đặt … bằng lệnh:

$ ./configure --with-apxs=/usr/sbin/apxs

$ make
$ sudo make install

Như vậy là tôi đã cài đặt thành công mod_python lên server apache, và thao tác còn lại là restart apache server lại bằng lệnh  …

$ sudo /usr/sbin/apachectl restart

Ánh sáng cuối đường hầm

Sau một vài thao tác sửa file httpd.conf của Apache và viết một module python xử lý các HTTP Request thì cuối cùng tôi cũng build được cái project của mình chạy local. Mặc dù tốn hết một tuần nhảm nhí nhưng tôi cũng rút ra được khá nhiều bài học khi làm việc với open source và bỗng dưng biết sử dụng thêm … linux (debian) và hiểu rõ hơn về cơ chế hoạt động của MAC os X … Tôi đã lún quá sâu với Windows và Microsoft, có lẽ đây là lúc thích hợp để tìm đường thoát khỏi chăng )

Vấn đề này có thể giải quyết bằng cách cài đặt Gallery 3D của Google, thay thế cho Media Gallery hiện tại. Link download tại đây. Bạn có thể tải về rồi chép vào thẻ nhớ và cài đặt thông qua Astro File Manager, hoặc download trực tiếp từ trình duyệt của Android.

Có thể cách suy nghĩ cũng bi quan, hơi tiêu cực nhưng dù sao nó cũng phản ánh chính xác về cuộc sống, sự nghiệp của các lập trình viên Việt Nam (cá nhân tôi nghĩ thế :d)

Tuần rồi có gặp lại mấy người bạn cũ, nghe họ than thở sao đi làm lập trình viên áp lực và đòi hỏi suy nghĩ nhiều vậy mà lương lại không tăng được bao nhiêu. Nghe vậy tôi cũng không biết nói sao, chỉ cười thầm trong bụng “Ôi, làm ngành này mà không …nhảy công ty thì bao giờ lương mới lên nhanh )”

Biết lập trình là cái nghiệp mình đã trót theo vì niềm đam mê hay một lý do nào khác, nhưng liệu nó có thực sự triển vọng để mình có thể gắn bó lâu dài?

Với tôi thì đây quả thật là một vấn đề cần tính đến bởi có lẽ hiếm có nghề nào lại ….”bạc bẽo” như lập trình viên. Nếu các ngành khác như giáo viên, bác sĩ, bán hàng… càng làm lâu càng có quan hệ và kinh nghiệm thì ngược lại khả năng tư duy của các lập trình viên sẽ ngày một chậm đi do tuổi tác. Đứng ở tư cách một chủ doanh nghiệp, rõ ràng bạn sẽ thích thuê những lập trình viên trẻ trung, vừa nhanh nhẹn, chi phí phải chăng hơn là thuê các lão tướng lương cao mà lại ngày một chậm chạp hơn.

Và rõ ràng trước tình hình như thế, người lập trình viên cần tính cho mình một lối thoát trước khi chạm đến ngưỡng không còn khả năng lập trình được nữa

1. Thăng tiến theo con đường lập trình
Với một lập trình viên thuộc loại khá, hiện nay sau khi ra trường sẽ được trả mức lương trung bình vào khoảng 400-500$ (Theo số liệu các công ty gia công ở TPHCM, ở Hà Nội có thể thấp hơn). Sau khoảng 2 năm con số này sẽ tăng lên khoảng 1000$, và 2-3 năm nữa có thể lên đến 2000$. Tuy nhiên đến đây có thể xem là đã chạm ngưỡng. Sở dĩ nói vậy vì theo tôi được biết một số công ty nước ngoài trả tiền gia công cho các công ty Việt Nam theo đầu người khoảng 2000$/người, trừ đi các chi phí điện nước, thuế má… thì có lẽ mức lương trung bình cho mỗi người sẽ chỉ có thể khoảng 1000-1500$ mà thôi, trả cho tôi 2000$ tức là phải bù lỗ từ các lập trình viên trung bình khác. Tất nhiên con số này có thể sẽ cao hơn ở những công ty gia công tầm cao không trả theo đầu người, tuy nhiên chỉ là thiểu số.

Để có thể leo đến mức này thì không chỉ đòi hỏi tôi phải có năng lực thật tốt mà còn phải khéo léo trong việc đàm phán, cũng như phải chọn đúng những công ty đủ triển vọng có hầu bao tốt sẵn sàng chi trả mức trên. Và đến khi đạt được, tất nhiên tôi cũng sẽ nhận được những áp lực cho “tương xứng” với mức lương đó cũng như sẽ là mục tiêu sa thải đầu tiên trong các thời kì kinh tế khó khăn. Một khi bị sa thải, sẽ rất khó để có thể tìm được công việc mới với mức lương như cũ.

Tuy nhiên nếu leo lên tới được mức ở trên thì theo tôi cũng đã đủ sống ở Việt Nam. Với giá một căn hộ dành cho người thu nhập trung bình vào khoảng 600 triệu hiện nay, thì tôi nhẩm tính với mức lương 1000$ mỗi tháng để dành 10 triệu là chỉ cần 5 năm là có thể trả hết. Với mức lương 2000$ thì chỉ cần 2.5 năm. Như vậy thì tôi cũng có thể tập trung vào công nghệ, từng bước trau dồi để leo lên các vị trí quản lý công nghệ cao hơn.

Tuy nhiên phần lớn số lượng lập trình viên Việt Nam sẽ không nằm trong tốp này, cũng như các công việc gia công ở Việt Nam chỉ quanh quẩn ở tầm thấp nên đến một lúc nào đó những người có năng lực cũng sẽ từng bước tách ra tìm cho mình một con đường triển vọng hơn.

2. Tìm một nghề mới triển vọng hơn
Vậy nếu không làm lập trình viên thì sẽ làm gì? Nhìn vào số lượng những người bạn xung quanh, tôi thấy phổ biến nhất là chọn một ngành triển vọng hơn nhưng có liên quan đến IT

- Làm IT trong các ngân hàng, công ty chứng khoán: Các công ty này cũng cần rất nhiều đến IT, đôi lúc cả những công việc lập trình. Làm trong những công ty này có thể dễ dàng tiếp cận được với những nguồn thông tin khá tốt, cộng với khả năng xử lý thông tin thế mạnh của các lập trình viên thì có lẽ sớm muộn cũng tìm được một hướng đi triển vọng như một nghề tay trái bên cạnh nghề lập trình hiện tại. Tôi còn biết có vài đại ca ngành này làm một hồi còn chuẩn bị có ý định tách ra lập ngân hàng nữa chứ

- Đi Sale IT: Với một thị trường khá tiềm năng thì Việt Nam đang là đích đến của rất nhiều công ty sales như Microsoft, IBM, Cisco, Oracle, HP… Làm nghề này thì đòi hỏi khả năng giao tiếp cũng nhiều mối quan hệ. Với mức lương khá cao cũng như hưởng huê hồng theo doanh số thì đến một lúc nào đó hoàn toàn có thể bứt xa so với mức lương lập trình viên ở trên. Ngoài ra làm nghề này được thêm cái dễ nhảy, không làm cho Microsoft thì sang làm cho IBM, Cisco… Nói chung với một thị trường đông dân và còn tăng trưởng cao như Việt Nam hiện nay thì không thiếu cơ hội.

- Đi buôn Bất Động Sản: Đi buôn BĐS cũng vui, chỉ có điều là nó không liên quan tới IT lắm và đòi hỏi vốn cũng phải kha khá. Nhưng nếu quyết tâm theo đuổi trong thời gian dài thì sớm hay muộn cũng sẽ đạt được những thành tựu, thậm chí là rất lớn. Nhìn quanh quẩn thấy đa phần tầng lớp giàu có ở Việt Nam đều giàu lên từ ngành này (Theo thống kê không chính thức là 50%). Do đó với khả năng của suy luận của lập trình viên cộng thêm giao tiếp khéo léo và từng bước mở rộng quan hệ, thì đây cũng là một hướng đi triển vọng có thể cân nhắc

- Đi làm nhà giáo: Suy nghĩ này có vẻ hơi “điên” bởi đa phần mọi người nghĩ lương nhà giáo ba cọc ba đồng, làm sao mà sống. Tôi cũng nghĩ vậy cho đến khi nghe một anh bạn nói trung bình mỗi buổi anh đó đi dạy được 1 triệu, Sau vài giây tính toán, tôi nhẩm tính như vậy là một tháng anh cũng kiếm được 30-40 triệu, với những người có tiếng tăm có lẽ còn cao hơn nữa. Ngoài ra làm ngành này được thêm lợi thế là xã hội trọng vọng, cũng như tích lũy được rất nhiều mối quan hệ để làm vô số điều khác sau này. Có lẽ đây là một trong những lối thoát rất tốt và tôi sẽ còn đề cập trong một bài viết khác )

3. Lập công ty tự xây dựng sự nghiệp cho mình
Bên cạnh hướng tìm một nghề triển vọng hơn ở trên, với những người với cá tính mạnh thì họ lại muốn tự lập công ty để khẳng định mình. Nhưng nếu làm một công ty IT thì nên đi hướng nào?

- Gia công: Đây là một trong những hướng mà tôi thấy khá nhiều các công ty phía Nam ưa chuộng. Xuất phát từ một số hợp đồng có được, họ tuyển nhân công vào làm rồi cứ thế từng bước mở rộng. Tuy nhiên làm nghề này có cái bấp bênh là nhân sự không ổn định, bởi rõ ràng với hướng này thì chỉ có thể mở rộng theo quy mô số lượng nhân viên mà thôi. Điều này thì buộc công ty phải luôn tìm kiếm những hợp đồng mới và việc này hoàn toàn không đơn giản bởi đòi hỏi những doanh nhân trẻ phải có nhiều mối quan hệ quốc tế. Ngoài ra, đến một lúc nào đó quy mô lớn thì chỉ cần không có hợp đồng trong vài tháng thì công ty cũng đi luôn. Nhiều công ty ở gia công ở VN đã rơi vào tình trạng như vậy.

- Làm giải pháp cho thị trường trong nước: Các công ty theo hướng này thi đa phần tôi nhận thấy họ thường có một khách hàng ban đầu với nhu cầu về một sản phẩm nào đó. Và họ từng bước làm sản phẩm để đáp ứng nhu cầu của khách hàng này rồi kì vọng sẽ bán được cho các khách hàng tiếp theo. Tuy nhiên phần lớn các công ty theo lĩnh vực này không ổn định và doanh số bấp bênh. Câu hỏi đặt ra là liệu thị trường sản phẩm họ đang làm có đủ để nuôi họ, cũng như việc các hợp đồng có quy mô ở Việt Nam đa phần đều dựa trên quan hệ. Việc họ có được hợp đồng ban đầu không chắc là họ sẽ kiếm được những hợp đồng tiếp theo. Có lẽ các công ty dù thành công trong lĩnh vực này cũng đều hiểu đây không phải là hướng đi lâu dài, họ cần phải có những sản phẩm chủ lực và bền vững hơn.

- Làm các dịch vụ dot-com: Có lẽ đây là một trong những lối thoát tốt nhất cho các công ty CNTT. Một sản phẩm thành công và doanh số ổn định sẽ là một nguồn đảm bảo rất lớn cho sự phát triển của công ty trong tương lai. Nhiều quỹ đầu tư lớn như IDG, DFJ Vinacapital… cũng đã vào Việt Nam để hỗ trợ cho những sản phẩm như vậy. Tuy nhiên thị trường này đang chịu một sức ì rất lớn, ngoài những sản phẩm đánh trúng mục tiêu vào thị trường game online, SMS… thì hầu hết các công ty còn lại đều đăng nằm trong tình trạng chờ thời và nỗ lực tìm kiếm đầu ra. Nhưng dẫu sao theo tôi đây vẫn là một hướng đi triển vọng, đặc biệt trong trường hợp sản phẩm mang một số yếu tố mới thì khi thành công ở Việt Nam sẽ có thể từng bước vươn ra thị trường bên ngoài, có thể chỉ dưới dạng gia công như ở trên nhưng sẽ ở một cấp độ cao hơn và đem lại giá trị gia tăng hơn rất nhiều.

Tổng kết lại thì trên đây là một số hướng đi theo quan điểm của riêng tôi mà những lập trình viên có thể cân nhắc cho sự nghiệp tương lai của mình. Khó có một cá nhân nào có thể gắn bó với nghề lập trình mãi mãi. Tất nhiên việc chọn hướng đi nào sẽ phụ thuộc vào tính cách của từng người khác nhau. Với riêng bản thân, thì tôi vẫn đang trên đường tự đào tạo để trở thành một trong những “nhân vật chủ chốt” góp phần xây dựng một công ty IT hùng mạnh của Việt Nam trong tương lai và từng bước vươn ra bên ngoài. Có thể bạn sẽ cho tôi là người “mơ mộng” nhưng đôi lúc tôi nghĩ nếu cả cuộc đời mình có thể sống với những lý tưởng cá nhân thì không phải tôi đã là một người rất hạnh phúc à, dẫu cho những lý tưởng đó là …không tưởng ). Tất nhiên cũng có thể đến một lúc nào đó tôi nhận ra sự thật phũ phàng đó, nếu vậy thì thôi đành an phận làm một leader bình thường hướng dẫn thế hệ đàn em đi sau hay chuyển sang nghề nhà giáo, nếu được như ở trên thì cũng triển vọng phết nhỉ ^_^. Vậy còn với bạn, nếu bạn là lập trình viên thì bạn sẽ tính sao?

Tôi không bàn đến IoC nhiều, hơn nữa nó cũng không mới – nhất là đối với những người làm Java. Có vẻ Flex đang càng này tiệm cận với Java nhiều hơn khi có quá nhiều thứ của Java lần lượt xuất hiện ở Flex – như Flex Unit Test chẳng hạn.

Parsley là gì ?

Parsley là một framework dành cho các ứng dụng Flash/Flex/RIA . Có thể nói hệ thống document của Parsley là rất tốt và đầy đủ. Có lẽ tôi sẽ thử ứng dụng framework Parley này cho ứng dụng tiếp theo …

Nhiều ý kiến cho rằng ViewHelpers như một cách để xác định vị trí, theo dõi và đơn giản hóa việc sử dụng các View. Một ứng dụng lớn sẽ gồm cả trăm lớp View và việc quản lý các View này sẽ trở nên rất khó khăn. Chính vì thế khái niệm ViewLocator, cũng như ServiceLocator và ModelLocator được tạo ra nhằm quản lý các view thông qua các chuỗi định danh và giao tiếp với các View thông qua các phương thức có phạm vi public.

Như vậy, ViewHelper có thể được định nghĩa như sau:

Một ViewHelper là một lớp triệu gọi các phương thức trên tất cả các View mà nó quản lý. ViewLocator là một Singleton chứa tất cả các ViewHelper và quản lý các ViewHelper thông qua chuỗi định danh.

Khi nào cần cài đặt ViewHelper ?

Như tôi đã nhấn mạnh trong các phần trước thì một Command sau khi thực hiện một tác vụ từ web service sẽ cập nhật thay đổi vào Model (ModelLocator), từ đó sẽ update lên view thông qua cơ chế  binding. Tất nhiên, việc sử dụng ViewHelper sẽ tránh cho việc đặt quá nhiều dữ liệu vào ModelLocator. Trong trường hơp này, Command sẽ liên lạc với ViewLocator để tìm view tương ứng, sau đó gọi các phương thức public của view để cập nhật trực tiếp sự thay đổi.

Trong lớp LoginView (LoginView.mxml), bạn cần khai báo

<view:LoginViewHelper id="viewHelper" />

Nội dung của LoginViewHelper thì có sẽ giống như sau

package org.catapult.eslide.view {
        public class LoginViewHelper extends ViewHelper {
             public function LoginViewHelper() {
                    super();
        }

        public function itemClickHandler(e:ListEvent):void {
               LoginView(this.view).updateTitle(e.itemRenderer.name);
        }
     }
}

Như vậy từ LoginViewHelper, bạn hoàn toàn có thể truy cập các thành phần trong LoginView. Như vậy trong Command, thông qua ViewLocator, bạn có thể truy cập vào các ViewHelper. ViewLocator được khai báo và định nghĩa như ServiceLocator. Đó là 1 file MXML có hàng loạt các tag của các ViewHelper và id tương ứng mà qua đó các Command có thể truy xuất được.

Cairngorm 3.0 và Flex 4

Trong khi tôi đang thực hiện loạt bài về Cairgorm – phiên bản Cairngorm 2.2 – thì Adobe đã phát hành phiên bản tiếp theo là Cairngorm 3.0. Tất nhiên là tôi sẽ tiếp tục sử dụng Cairngorm 2.2 cho các project Flex 3 trước khi chuyển hoàn toàn sang Flex 4 với Cairngorm 3.0, mặc dù phiên bản Flex 3 hay 4 đều không ảnh hưởng đến việc dùng Cairngorm 2.2 hay 3.0. Vấn đề chính là “design – in – mind” – slogan mới của Adobe trong quy trình phát triển ứng dụng với Flex 4 và Cairngorm 3.0