http://nhatthuy.com/

gì chứ cái này cứ gọi là thường xuyên

Q: Những cách thể hiện khác nhau của địa chỉ IP...?
A: Wireshark dựa vào nhiều yếu tố khác nhau (cổng, nội dung đuợc truyền qua lại v.v.) để đoán và hiển thị giao thức thích hợp, nhằm tiện lợi cho bạn.

Q: Trong các lần truyền tin khác nhau, có thể nó có những biểu diễn khác nhau...?
A: Chương trình bạn viết bị lỗi. Dựa vào yếu sau mà tôi đoán như vậy: Khi viết đoạn văn ngắn ở trên, bạn viết lúc thụt lúc không thục đầu dòng, lúc viết hoa lúc viết thuờng, lúc sau dấu phẩy có khoảng trắng lúc không v.v. nên lúc viết chương trình dài hàng trăm hàng ngàn dòng, bạn viết ẩu là điều dễ đoán. Có thể tìm đọc truyện Lập trình sư để biết lập trình viên cần tối thiểu các đức tính gì.

    chương trình của mình bản chất của nó là 1 ứng dụng desktop nhưng chạy trên giao diện web, do vậy phải sử dụng code server tự tạo và hoạt động trên localhost chứ không dùng DNS , thực ra chạy trên localhost thì cả ie lẫn firefox hay 1 trình duệt khác là advance cũng không hoạt động tốt như nhau... (nhưng  nếu chạy trên 2 máy khác nhau thì hoạt động tốt,tuy nhiên đó lại không phải là mục đích của dự án) .ie có tắt alert đi thì vẫn lỗi là ajax không hoạt động trong các vòng lặp tiếp theo.

    Nếu dùng firebug thì nó đưa ra lỗi như sau: uncaught exception: Permission denied to call method XMLHttpRequest.open

    Phía client  về cơ bản nó  ần có dòng lệnh sau:

        xmlHttp.open("GET","localhost:9999/~HTTPServerRoomAjax/",true);
        xmlHttp.send(null);
        setTimeout("ajaxFunction()",6000);

Giải thích: đối tượng xmlHTTP gọi địa chỉ ảo ~HTTPServerRoomAjax/  ..bởi lẽ gọi nó là địa chỉ ảo vì nó chỉ là cái tên để cho webserver của mình xử lý.mỗi khi trang web yêu cầu địa chỉ trên, webserver sẽ trả về 1 biến đếm với giá trị tăng dần... nếu ta đặt host= localhost:9999 thì chỉ có webbrowser tren localhost có thể truy cập, máy mạng Lan thì không (tất nhiên) thay vào đó nếu  ta muốn thử nghiệm trên 1 máy thứ 2 thì ở hàm trên ta phải thay host= địa chỉ tĩnh của máy chạy webserver vd: 192.168.1.102:9999... sau đây là những kết quả mà tớ đã thử nghiệm và chả kết quả nào giống kết quả nào hihi

th1: computer1: chạy localwebserver và IE browser:  kết quả trả về biến đém 0 , các vòng lặp tiếp theo, vẫn trả về biến đếm 0

th2: computer1: chạy local webserver và FireFox browser: không hiển thị kết quả và thông báo lỗi: Permission denied to call method XMLHttpRequest.open (firebug)

th3: computer2: chạy local webserver va IE browser: giống th1

th4: computer2: chạy local webserver và firefox browser: hoạt động tốt, mỗi vòng lặp trả về 1 giá trị tăng dần 1-->.....

th5: computer1 chạy webserver, (sửa code host-->192.168.1.102:9999 là địa chỉ tĩnh của máy 1) computer2 chạy browser bất kì --> hoạt động tốt, các biến đếm tiếp tục tăng

th6: làm ngược lại th5 cũng cho hoạt động  tốt

đó là những gì mình thử trên 2 computer và cho nhưng kết quả chả hiểu ra là sao cả.. thực ra vấn đề này không còn quan trọng,nhưng giá mà được giải đáp thắc mắc thì mình thấy thoải mái hơn hì

mình có gửi code phần client, các bạn chỉ xem tham khảo vì code này phải kết hợp với webserver mới hoàn chỉnh.

Có nhiều cách khác nhau để triển khai (deploy) chương trình Rails:

• Ruby LiteSpeed API (Ruby LSAPI)
• LiteSpeed RubyRunner (Run CGI in persistent interpreter like mod_perl to perl)
• FastCGI
• Mongrel
• CGI

Mongrel và FCGI là 2 cách thông dụng nhất, nhưng Litespeed với LSAPI cho Rails có vẻ hay. Hiện giờ cntt.tv đang sử dụng phương thức triển khai này.

Mọi người tham khảo thêm tại website của Litespeed Wiki

Ngồi vào bàn, bật máy tính lên. Nhìn cái loa bẩn bẩn, thế là cởi ngay cái tất ra lau lau. Lau xong thấy loa sạch bóng, chẳng lẽ lại không bật lên nghe mấy bài hits hôm qua mới down. Chà, vừa nghe nhạc, vừa check mail, lướt mấy trang web quen thuộc mới tuyệt vời sao chứ. Loáng một cái đã gân trưa rồi, thôi thì thư giãn tí chút, để chiều bắt đầu viết tiếp đoạn chương trình còn dang dở vậy. Buổi chiều, sau khi lau ... màn hình và thư giãn "một lúc", nhìn đồng hồ đã thấy "ồ 4h rồi, thôi thì đọc nốt blog của thằng này hay quá, nhanh rồi còn đi chơi cầu lông, mai viết chương trình vậy".

Bạn đã bao giờ trong tình trạng như thế chưa? Nếu chưa thì thật đáng ngưỡng mộ. Nếu bạn cũng giống tôi, hẳn sẽ thấy rất thú vị khi thử đọc bài sau đây để thấy những tâm sự của Joel - cây bút suất sắc về Công nghệ phần mềm - về thực trạng này.

Nguồn: Joel Blog

Sometimes I just can't get anything done.

Sure, I come into the office, putter around, check my email every ten seconds, read the web, even do a few brainless tasks like paying the American Express bill. But getting back into the flow of writing code just doesn't happen.

These bouts of unproductiveness usually last for a day or two. But there have been times in my career as a developer when I went for weeks at a time without being able to get anything done. As they say, I'm not in flow. I'm not in the zone. I'm not anywhere.

Everybody has mood swings; for some people they are mild, for others, they can be more pronounced or even dysfunctional. And the unproductive periods do seem to correlate somewhat with gloomier moods.

It makes me think of those researchers who say that basically people can't control what they eat, so any attempt to diet is bound to be short term and they will always yoyo back to their natural weight. Maybe as a software developer I really can't control when I'm productive, and I just have to take the slow times with the fast times and hope that they average out to enough lines of code to make me employable.



What drives me crazy is that ever since my first job I've realized that as a developer, I usually average about two or three hours a day of productive coding. When I had a summer internship at Microsoft, a fellow intern told me he was actually only going into work from 12 to 5 every day. Five hours, minus lunch, and his team loved him because he still managed to get a lot more done than average. I've found the same thing to be true. I feel a little bit guilty when I see how hard everybody else seems to be working, and I get about two or three quality hours in a day, and still I've always been one of the most productive members of the team. That's probably why when Peopleware and XP insist on eliminating overtime and working strictly 40 hour weeks, they do so secure in the knowledge that this won't reduce a team's output.

But it's not the days when I "only" get two hours of work done that worry me. It's the days when I can't do anything.

I've thought about this a lot. I tried to remember the time when I got the most work done in my career. It was probably when Microsoft moved me into a beautiful, plush new office with large picture windows overlooking a pretty stone courtyard full of cherry trees in bloom. Everything was clicking. For months I worked nonstop grinding out the detailed specification for Excel Basic -- a monumental ream of paper going into incredible detail covering a gigantic object model and programming environment. I literally never stopped. When I had to go to Boston for MacWorld I took a laptop with me, and documented the Window class sitting on a pleasant terrace at HBS.

Once you get into flow it's not too hard to keep going. Many of my days go like this: (1) get into work (2) check email, read the web, etc. (3) decide that I might as well have lunch before getting to work (4) get back from lunch (5) check email, read the web, etc. (6) finally decide that I've got to get started (7) check email, read the web, etc. (8) decide again that I really have to get started (9) launch the damn editor and (10) write code nonstop until I don't realize that it's already 7:30 pm.

Somewhere between step 8 and step 9 there seems to be a bug, because I can't always make it across that chasm.For me, just getting started is the only hard thing. An object at rest tends to remain at rest. There's something incredible heavy in my brain that is extremely hard to get up to speed, but once it's rolling at full speed, it takes no effort to keep it going. Like a bicycle decked out for a cross-country, self-supported bike trip -- when you first start riding a bike with all that gear, it's hard to believe how much work it takes to get rolling, but once you are rolling, it feels just as easy as riding a bike without any gear.

Maybe this is the key to productivity: just getting started. Maybe when pair programming works it works because when you schedule a pair programming session with your buddy, you force each other to get started.


When I was an Israeli paratrooper a general stopped by to give us a little speech about strategy. In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can't fire at you. (That's what the soldiers mean when they shout "cover me." It means, "fire at our enemy so he has to duck and can't fire at me while I run across this street, here." It works.) The motion allows you to conquer territory and get closer to your enemy, where your shots are much more likely to hit their target. If you're not moving, the enemy gets to decide what happens, which is not a good thing. If you're not firing, the enemy will fire at you, pinning you down.

I remembered this for a long time. I noticed how almost every kind of military strategy, from air force dogfights to large scale naval maneuvers, is based on the idea of Fire and Motion. It took me another fifteen years to realize that the principle of Fire and Motion is how you get things done in life. You have to move forward a little bit, every day. It doesn't matter if your code is lame and buggy and nobody wants it. If you are moving forward, writing code and fixing bugs constantly, time is on your side. Watch out when your competition fires at you. Do they just want to force you to keep busy reacting to their volleys, so you can't move forward?

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That's probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can't spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don't have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it's just cover fire so that they can move forward and you can't, because this is how the game is played, Bubby. Are you going to support Hailstorm? SOAP? RDF? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond? The sales teams of the big companies understand cover fire. They go into their customers and say, "OK, you don't have to buy from us. Buy from the best vendor. But make sure that you get a product that supports (XML / SOAP / CDE / J2EE) because otherwise you'll be Locked In The Trunk." Then when the little companies try to sell into that account, all they hear is obedient CTOs parrotting "Do you have J2EE?" And they have to waste all their time building in J2EE even if it doesn't really make any sales, and gives them no opportunity to distinguish themselves. It's a checkbox feature -- you do it because you need the checkbox saying you have it, but nobody will use it or needs it. And it's cover fire.

Fire and Motion, for small companies like mine, means two things. You have to have time on your side, and you have to move forward every day. Sooner or later you will win. All I managed to do yesterday is improve the color scheme in FogBUGZ just a little bit. That's OK. It's getting better all the time. Every day our software is better and better and we have more and more customers and that's all that matters. Until we're a company the size of Oracle, we don't have to think about grand strategies. We just have to come in every morning and somehow, launch the editor.

Monitor, load, keyboard của mình lúc nào cũng sạch sẽ, sáng bóng :D

Chẳng qua vì em đẹp thôi chứ không phải vì em nhẹ :))

Chả nhẹ hơn firefox tí nào, có khi còn ì ạch hơn ý chứ