Source controls explained

• CVS: Si Vi Ếch
• SVN: Si Vi Nhái

Copyright by BoBo :|

This is a test entry using gnome blog poster

Just to try the gnome-blog-poster after yumming.

Nghỉ Pyco

(This entry was closed due to unnecessary quotes in other websites. The comments are still there for you in case you want to read)

There is only one word about the pidgin logo

ugly!

http://pidgin.im/~seanegan/pidgin.png

it's pidgin but it doesn't mean that you have you put that ugly pigeon in your logo x-(

Pidgin for Fedora Core 4, 5, 6 users

At your root shell:

# cd cd /etc/yum.repos.d/
# wget http://garimbo.org/rpms/fedora/pidgin.repo
# yum -y install pidgin

How Windows Vista was coded

/**
* (c) 2007 Micro$oft Corp.
* All rights reserved :-w
*/

#include "osx_tiger_features.h";

class WindowsVista extends WindowsXP implement Nothing {

    boolean beta = true;
    WindowsVista() {
        checkIfHardwareIsCompatible();

        /*
         * OK. The idiot seems to have
         * some high end hardware.
         * Let make his life miserable >:)
         */
        runInternetExplorer7();
    }

    void checkIfHardwareIsCompatible() {
        /*
         * Lets make sure that half the world
         * cannot run this OS while
         * we fix all the bugs
         */
        if ((installedRam < 2GB) || (processorSpeed < 4GHz)) {
            MessageBox("Your system does not seem
                to be capable of running zero err.. aero glass
                and the like. Please upgrade
                the hardware and try again.");
      
            WaitTillPoorGuyReadsTheMessage();
            bsod();
        }
    }

    void runInternetExplorer7() {
        IE7 ie7 = new IE6();
        ie7.featureSet = firefox_features
                          + safari_features
                          + opeara_features
                            + lot_of_bugs;

        ie7.run();
        WaitWileThePoorGuyLooksAtTheNewInterface();
        bsod();
    }
}

//thanks mr. tom for sharing this :p

Trở lại Cam Ranh

Trở lại Cam Ranh sau một năm, vẫn nguyên vẹn, con người nơi đó, bến tàu nơi đó, bãi hoang nơi đó...

Trong cái khó ló cái... ngu

Biết đâu được, ngu ngu chứ vác cái lu chạy cái vù

Enjoying the last night

before sending the mail.
being early or being late, it should be done, monkey!
give up fighting and start thinking about yourself first :)

Nhiều kết nối hơn

Trong bài viết trước về kết nối từ xa giải pháp kết nối ngược dùng SSH đã được đưa ra. Tuy nhiên, đó chưa là tất cả.

Thứ nhất, nếu tận dụng công cụ netcat (nc) thì không những chỉ TCP connnection được tunneling mà cả UDP connection cũng được tunneling dễ dàng. Nếu tốc độ của kết nối đủ cao, thực hiện tunneling cho 2 port 27015 TCP và UDP qua SSH là bạn có thể chơi được Mini-dust-pro từ xa :D

Thứ hai, nếu không phải dùng một SSH Server, một SSH client mà là 2 SSH client thì sao? Kết hợp 2 lần tunneling liên tiếp bạn có thể là cho 2 máy workstation không có IP thật kết nối TCP được với nhau. Khi đó, bạn có thể đi xa, mang theo laptop, dùng kết nối Internet của khách sạn chẳng hạn mà vẫn có thể điều khiển được workstation trong công ty.

Kết nối

Tình huống và nhu cầu
Trong công việc của một developer, mọi người rất dễ gặp tình huống làm việc từ xa. Mỗi developer thường có một workstation trong công ty và một máy tính ở nhà với kết nối ADSL hoặc dialup. Nhu cầu nảy sinh trong làm việc từ xa là làm sao có thể "truy cập" vào máy tính trong công ty từ máy tính ở nhà. Truy cập ở đây có nghĩa rộng, nó bao gồm hầu hết các loại kết nối có thông dụng, như kết nối Remote Desktop thông qua RDP, kết nối X server, kết nối VNC, kết nối để truyền nhận file...

Giải pháp có sẵn
Nhu cầu này không hề mới và có nhiều giải pháp được đưa ra để dùng, trong đó có:

1. VPN: Hoàn toàn có thể tạo ra VPN dễ dàng với một front gateway dùng Windows Server hoặc một hiện thực PPTP nào đó trên Linux, đây là cách cung cấp nhiều tiện lợi nhất. Tuy nhiên, có nhiều nhược điểm phát sinh:
• Cần phải có một Windows Server làm front gateway; chi phí không phải thấp. Hơn nữa, M$ nổi tiếng là bèo nhèo về security và dùng Windows làm Gateway trong quan điểm của tôi là không thích hợp. Nếu mua thêm một ISA server nữa thì quả là quá tốn kém.
• Cần phải được cài đặt, cấu hình bởi quản trị hệ thống và phải nằm trong chính sách/quy định của công ty. Việc này không phải là khả thi với tất cả mọi nhân viên.
  
  
2. Incoming SSH Tunneling: Cũng có thể được tạo ra và sử dụng một cách dễ dàng, bảo mật. Một điểm quan trọng là giải pháp này đòi hỏi hầu như là $0 chi phí phần mềm vì hoàn toàn có thể dùng một Unix/Linux server làm front gateway vì trên các hệ nền này đã có sẵn SSHD. Hơn nữa Unix/Linux nhìn chung vẫn ổn định và an toàn hơn Windows, lại hoàn toàn miễn phí. Tuy nhiên nó cũng có nhược điểm:
• Nó vẫn đòi hỏi sự cài đặt của quản trị hệ thống và phải nằm trong chính sách/quy định của công ty.
• Vẫn phải tốn kém ít nhất một máy chủ để chạy SSHD
  
  
3. Các dịch vụ kết nối từ xa: có nhiều dịch vụ trực tuyến hỗ trợ việc này, chẳng hạn LogMeIn, pcAnyWhere... Các dịch vụ này có cả ưu điểm lẫn nhược điểm:
   
• Ưu điểm: Máy làm việc và máy ở nhà đều không cần có IP thật, dễ cấu hình, hầu hết có thể dùng trình duyệt web để điều khiển
• Nhược điểm: Khá nhiều. Đa phần đều là dich vụ phải trả tiền nếu không thì kết nối không phải là dạng kết nối bảo mật. Đa phần sử dụng Java Applet. Người dùng luôn phải lệ thuộc vào sự tồn tại của dịch vụ online này. Một số dịch vụ đòi hỏi máy từ xa phải là máy Windows và điều này là vô cùng đáng ghét. Kết nối chậm vì phải thông qua máy chủ của nhà cung cấp dịch vụ (thường là ở nước ngoài, trong khi văn phòng công ty và nhà đều nằm trong nước và thậm chí còn nằm chung trong mạng khi sử dụng cùng nhà cung cấp dịch vụ Internet)

Rõ ràng chưa có giải pháp nào thực sự an toàn, tiết kiệm, dễ triển khai, nhanh cho người dùng là các developer bình thường?

Lật ngược suy nghĩ
Tuy nhiên, nếu nhìn lại kỹ hơn, bạn có thể thấy rằng những điểm sau đây đã bị bỏ qua:

1. Nếu máy ở nhà dùng ADSL hay dialup thì hầu hết đều có IP thật, tuy có thể động. Việc này có thể dàn xếp tốt bằng cách dùng các dịch vụ dynamic DNS.
2. SSH Tunneling là 2 chiều. Nếu dùng Local Forwarding thì chỉ mới tận dụng được một nửa sức mạnh tunneling của SSH mà thôi.

Như vậy, tại sao không lật ngược suy nghĩ lại trong việc áp dụng SSH tunneling? Nếu như máy ở nhà là một SSH server, máy trong công ty là client rồi dùng Remote Forwarding thay vì Local Forwarding?

?!?

Hoàn toàn có thể được mà lại đạt được nhiều thứ:

1. Không cần phải có bất cứ thiết lập nào của công ty, máy làm việc trong công ty chỉ cần kết nối được ra internet không thông qua proxy (hầu hết các cty đều cho phép việc này.)
2. Không tốn bất cứ chi phí phần mềm nào (SSHD trên Unix/Linux thì có sẵn, trên Windows thì có FreeSSHD và OpenSSH chạy với Cygwin). SSH Client thì rất nhiều và cái free chạy tốt hơn cái phải trả tiền.
3. Không bị ràng buộc bởi hệ điều hành. Không có chuyện anh phải là Windows User (hừ!)
4. Có thể thực hiện rất nhiều loại kết nối, không riêng gì các kết nối để điều khiển từ xa
5. Thậm chí có thể kết nối đến máy khác trong công ty (ặc ặc, vụ này căng à nha)
6. Kết nối hoàn toàn bảo mật, thậm chí bảo mật hơn khi dùng public key authentication
7. Kết nối là trực tiếp từ máy ở nhà đến máy công ty, không thông qua hay lệ thuộc một dịch vụ trực tuyến nào (bạn có thể không đồng ý vì vẫn lệ thuộc các dịch vụ DNS động, tuy nhiên cái này hoàn toàn có thể vượt qua được nếu chịu khó tự lập trình. Khi đó, chẳng cần ai bên ngoài cung cấp dịch vụ cả.) Và khi đó, bạn tự vận hành dịch vụ cho chính mình, không lệ thuộc ai cả.

Nghe rất hứa hẹn! :)

Nhưng bên trong nó ẩn chứa vấn đề:

• Nếu máy trong cty là client, bạn không có trong cty, ai vận hành chương trình client? Bạn cần phải kết nối vào được thì mới tự tay vận hành được, nhưng phải vận hành được thì mới kết nối vào được chứ! Ặc ặc, trứng và gà.

Điều đó dập tắt mọi toan tính?

Không!

1. Nếu mình không tự tay vận hành được thì mình sẽ để chương trình client đó... tự vận hành mà cung cấp thông tin từ xa để nó biết nên vận hành thế nào! (Nghe hơi giống IoC nhể :D)
2. Mà như vậy thì chương trình client đó không thể là các SSH client bình thường được. Cũng chẳng sao. Java có JSCH. Chạy tuyệt vời. Tại sao không tự viết một SSH client chỉ cần tunneling và khả năng tự vận hành theo chỉ thị từ xa? (thông qua HTTP connect chẳng hạn ?!?!)

Kết luận
Rõ ràng là làm được!

Nhưng vấn đề là phải code :(

Phải chăng, cái đầu của developer nó vậy? Nghĩ đâu rồi cuối cùng cũng quay về với code.

Tất niên

Cuối năm, anh Lâm và BoBo bệnh nặng, cả hai bé bị "nhốt" ở nhà buồn hiu...

Tối. Lòng vòng mua mấy món đồ. Vác một chai Gold như anh Phước dặn về nhà. Chai Gold này để dành mai đón Gấu :). Này Gấu nhá, mai tớ cho cậu chít nhá >:)

Mai Gấu về, vui thật nhưng nếu có BoBo và anh Lâm chắc là vui hơn nhiều lắm...

Running more than one Firefox instance in the same X

It's sometimes really handy to run two or more Firefox instances simultaneously for testing purposes or the likes. This seems to be impossible since Firefox allows only one instance of it per user session. Running multiple "firefox" commands just creates new windows which share the same session data (cookies, authenticated sessions...)

Thanks to Linux, SSH and the X architecture which together make running multiple instances of Firefox in the same screen possible.

Step 1: Start your X and login with an account, start the first Firefox instance.

[dgthanhan@localhost ~]$ firefox&

Step 2: SSH to your own localhost using another account with X tunneled

[dgthanhan@localhost ~]$ ssh -X monkeya@localhost
monkeya@localhost's password:
Last login: Sat Jan 13 02:11:45 2007
/usr/bin/xauth: creating new authority file /monkeya/.Xauthority

Step 3: Start the second Firefox instance by invoking "firefox". Enjoy :)

[monkeya@localhost ~]# firefox&

(Note: This guide is only for *nix user)

Ặc Ặc

http://mendet.blogspot.com/2007/01/lm-cch-no-lm-hng-mt-lp-trnh-vin.html

Them cai thu hai

Cai thu hai dung hinh khac, ad khac

Test them mot lan nua

Test thu ne

Đây là kết quả

Đoạn quảng cáo sau có hình không thể copy static URL được nà

Testing the blogger API for Picscout

Foo!

This is a test post

Testing the Ad for Picscout

Hic hic, hôm nay phải viết một chương trình "demo" cho Picscout để thử khả năng post quảng cáo trực tiếp vào các dịch vụ Blog. Mình post thử cái này lên để thử nghiệm..

Không biết có chạy được hông nữa :-s
Còn đây là cái quảng cáo tạo ra từ Javascript. Cái này là căng thẳng nhất nè. Hy vọng chạy được :-ss

Chạy được hông ta...