What Tools I Use For Web Development

I use all of these applications/plug-ins

* Jetbrains IntelliJ Idea. The best IDE I've ever used.
* Textmate. The best text editor I've ever used.
* DBVisualizer. Makes working with databases easy.
* Fireworks, now from Adobe and likely to vanish someday.
* Interarchy. For moving stuff from one system to another.
* Path Finder. It's not a development tool but a Finder replacement; lots of neat programming assistant features.
* Firebug. If you don't use this for debugging javascript, you stand along in the world.
* Web Developer Toolbar. Although there is some overlap with Firebug, it's mostly complementary.

OK, you can argue with me, but these are my weapons of choice.

All I Need To Know To Be A Better Programmer

Programming is complicated stuff, but a lot of what makes a good programmer isn’t all that different from the earliest learning we did in school.

1. Share everything.

Use open source where possible, and contribute to it when you are able. The collective wisdom of the entire community is better than the limited vision of a few large companies.

2. Play fair.

Give other technologies, frameworks, methodologies and opinions a chance. Don’t think your choices are the only ones that work. The other choices may very well be better than yours; it doesn’t hurt to check them out with an open mind.

3. Don’t hit people.

Like #2, don’t attack people just because they happen to use .Net or Java or PHP (I learned my lesson there!). Sometimes they might be more usable and useful than you think. You can learn a lot more from someone when you are not pounding them to a pulp.

4. Clean up your own mess.

Strive to deliver code that works. Never expect QA to find all of your bugs for you. Test your code often, both narrowly and broadly.

5. Don’t take things that aren’t yours.

Follow the licenses for stuff you use, don’t just steal it and claim innocence later.

6. Say you’re sorry when you hurt somebody.

Code reviews are a good but rarely used idea. Mentoring programmers with less experience than you helps the entire team. Just don’t criticize people openly. Learning is not belittling people. Sometimes people will listen and sometimes they won’t. Sometimes you might learn a lot from people you think are inferior to you.

7. Wash your hands before you eat.

Try to understand things before you set out to write code. Do prototyping, check out examples on the web, talk with other folks who do it, or even just play around. Architecting something you’ve never done before or worked with is tough cold turkey. The end result will work much better if you start with a clue.

8. Flush.

Don’t be afraid to replace, rewrite, refactor or give up on something that is crap. Sometimes “when in doubt throw it out” is the best philosophy. Never fall in love with your code.

9. Warm cookies and cold milk are good for you.

Yes, programmers should be well supported in their work environment. A good chair, a quiet place to work, a decent computer and tools that make coding better and easier are essential. Managers should act as umbrellas to keep the crap from flowing down to the programmers. As a programmer, don’t accept a life of lowly servitude. If the employer treats you poorly then find one who treats you better.

10. Live a balanced life - learn some and think some and draw and paint and sing and dance and play and work every day some.

I like Google’s deal where 20% of your time is devoted to whatever you think it worth working on. Employers should (discretely) offer nap rooms or game rooms or some kind of chillout environment. Programming is hard mental work; sometimes you really need to give your brain a rest. Refuse to routinely work 80 hour weeks as the quality of your work will wipe out any gains in hours.

11. Take a nap every afternoon.

Working 24 hours a day doesn’t make you more productive. Take breaks, go home, take a real nap. Often I have solved nasty problems by going home, and the solution came to me as I was driving away, or the next morning.

12. When you go out in the world, watch out for traffic, hold hands and stick together.

Community is good for the soul; read blogs, learn about new languages or frameworks, participate in discussions and see what other people are doing. Just doing your job isn’t going to make you a better programmer. Keeping your head down means you will eventually be obsolete.

13. Be aware of wonder. Remember the little seed in the Styrofoam cup: the roots go down and the plant goes up and nobody really knows how or why, but we are all like that.

Every day something new and wonderful appears in the programming (and technology in general) world. Check it out. Be amazed. Learn something new everyday. It keeps your mind fresh, your options open, and your skills up to date. If you think programming is boring or dead then you may need a new career.

14. Goldfish and hamsters and white mice and even the little seed in the Styrofoam cup - they all die. So do we.

Code goes stale and dies. Sometimes you just have to bury it and do it again. Fight against keeping terrible code bases around just to save money.

15. And then remember the Dick-and-Jane books and the first word you learned - the biggest word of all - LOOK.

You won’t learn anything at all if you don’t try. Everything I learned in programming came from trying new stuff and generally playing around. Every morning I read a lot of sites to see what is happening in the programming world; I have been doing this since my first job in the early 80’s (when it meant reading catalogs and magazines).

See, programming is easy when you look at it through 3-year-old eyes.

Fix The Bug, Not The Symptom

I'm a big believer that a large part of the art of successful debugging is attitude. If you adopt the attitude that you can fix the problem and you're not getting to let this piece of technology make you look feeble and unworthy, you'll usually win.

There's more to write about that another time. Today I want to write a bit more about the flip side of this: being a responsible debugger and making sure you are fixing the real problem, not merely making the symptoms go away.
Learn A Lesson From The Villagers

Imagine that you live in a village on the edge of some grassy plains in Africa in the 19th century. Every now and again, a lion comes through the fence, enters a hut and eats all the meat inside. You decide to "fix" this problem. It seems to be a choice between two options:

1. Put a stronger door on your hut and maybe hang a slab of meat on your neighbours' huts as an extra incentive for the lion to go and visit them instead of you.
2. Look for all the places where the fence line can be breached and fix them.

Why is it that the 19th century African villager will pick the right solution (you picked #2, right?) and the 21st century software developer will often go for something akin to solution #1? Is it just because "screw your buddy" is much more obvious in this scenario than in the software band-aid patching approach?
Be Doubtful. Be Reluctant. Work Hard.

Tracking down the place where a bug appears is only the first step. That isn't the place where you necessarily need to fix the code. It's the place where the problems have finally mounted up to such an extent that the software falls over. It's the lion coming through the door of the hut when the problem was really the lion getting into the village in the first place.

When you're debugging a problem, as a practical matter, doubt that the problem you're seeing is the root cause. Maybe — once in a while — the problem is something obvious that was caused by a bad piece of logic a few lines earlier. More often, though, you're going to find that the current method or function was passed bad data by something else and that added to the problems until the camel's back completely broke.

The data might not necessarily be bad in the obvious sense. It might be perfectly valid data in another part of the program but you weren't expecting to handle it at the point the bug appeared. Sure, you could adjust the final location to handle this new data type, but why do this? Be very reluctant to broaden the interface you allow as input to a function. It just increases the number of code paths you have to worry about. Why is the unexpected data type getting here? Is there a broken assumption somewhere else? Is it newly added code that didn't respect the (possibly unadvertised or implicit) interface? It might be a legitimate oversight, but don't make that your first approach to a fix. That's a band-aid solution. You're fixing the symptom.

I will claim that for any reasonably large and stable body of code, there is usually a coherent set of design choices floating through the implementation. They might not be your choices and they might vary from component to component (particularly if the code has been built up over years and years), but there is going to be some logic to things. Try to understand this imlpicit logic. Work hard to ferret out the reasoning behind the interfaces and information flow. At some level, a "proper" bug fix feels very right. It feels like you've fixed it in the right place.

Applying a fix that makes the symptom disappear is lazy development. Maybe it's the right fix, but you'd better be able to explain why the problem should be fixed there. Why is that place the cause of the problem? Does the design back you up?

If you write a quick change to the code, run it and think to yourself "cool, that seems to have worked," it should make you feel uncomfortable. Why are you surprised that it worked? Lack of understanding of the root problem, perhaps?
Reviewing Proposed Fixes

Donald Knuth wrote somewhere (maybe in the TeX book?) that debugging was easier if you were already in a bad mood. The logic being that it's easier to be prepared to rip something apart if you want to do exactly that.

This might sound abstract, but on some level it's very true. I find my most successful periods of reviewing patches or designs — in my own code, just as much as other peoples' — is when I walk in dying to find a way to reject the proposed solution. If it holds up despite my best efforts to tear it down, it's probably a reasonable fix. This is, of course, the software development equivalent of statistic's null hypothesis; you have to disprove the opposite claim to have your version accepted.

The one line fix that applies to the precise spot of the traceback in a bug report is a prime candidate for this treatment. Without a lot of hard data, but with the benefit of about 15 years of professional experience, I will claim that most of those fixes are band-aids. Particularly if they're in an area that is likely to be executed with some frequency. Why hasn't this problem been noticed before? What special conditions caused the pile up of problems that made it noticeable only now? Again, working hard and being reluctant to apply the fix that makes the symptom disappear makes for stronger code.
Surely This Doesn't Happen In Practice?

I'd been planning to write this entry for a little while now. I spend a lot of time reading and reviewing bug reports and proposed fixes. I see more than a few messages on mailing lists asking why ticket number XYZ hasn't been fixed despite having three patches attached that make the problem go away.

Symptom removal happens. Unless you recognise it that way, and are prepared to look for the disease in every patch, it's easy to overlook. Particularly in Open Source code. We (Open Source developers) encourage community submissions. This pays off in the form of lots of bug reports, feature suggestions and patches to fix problems. The hidden downside is that a lot of patches for problems are written by somebody trying to get real work done. They want the fastest fix possible so they can get on with their real work, not devote a lot fo time to work on this piece of code that they downloaded from somewhere. Under those circumstances, it's easy to forget to look at the bigger picture. It's not a black mark against the person writing the patch — all contributions are welcome and if we don't take a particular patch, it causes no harm. It does explain why an existing patch might not necessarily be the right solution.

So, yes, the problem exists in practice.

Coincidentally, the issue was brought into the light recently when a couple of articles appeared on IT websites pointing out that Microsoft's Vista had degraded network performance when playing and mp3 file. That sounded odd on first reading. Microsoft's statement to explain why it was expected (for some value of "expected" that means "we thought it would be acceptable") raised eyebrows around the world.

Robert Love has written a good deconstruction of why this explanation is a model case of symptom hiding rather than bug fixing. You can see from Robert's write-up that a detrimental effect was made to go away, instead of investigating the root cause: why does using the network take up so much CPU? As noted in that article, Linux (amongst many others) has already solved this problem. It's hardly new technology any longer.

Clearly the solution isn't having more funds, more available developers or more process in place. Eternal vigilance is the last defender here. How you choose to get into that mode, using my "I'm going to assume this is busted until I can prove otherwise" approach or some other way, is entirely up to you.

Programmer’s life (cartoon)

Programmers carry small world with their selves. They require really small things to be happy. If they done their tasks according to specs, they will be very happy. Some times little showstopers make them sad, and they got frustrated. And start thinking diffrent kind of things like switching the job, how cruel the managers are, do I get appraisal etc, etc.

The given cartoon depicts interesting thing about programmers…

IIS 7

Trong chiến lược giành thị phần Internet của Microsoft, máy chủ Web IIS (Internet Information Service) là một trong những ưu tiên hàng đầu. Phiên bản đầu tiên IIS 1.0 được giới thiệu cách đây 11 năm cùng với Windows NT 4.0 vào năm 1996. Đến năm 1999, IIS 5.0 (trên nền Windows Server 2000) nhanh chóng trở thành máy chủ web phổ biến nhất vào thời điểm đó, mặc dù chỉ vài tháng sau nó phải đối mặt với những lỗ hổng bảo mật nghiêm trọng, bị các virus như Red Code, Nimbda khai thác. Phiên bản gần đây nhất, IIS 6.0 trên nền Windows Server 2003 được đánh giá là máy chủ web chắc chắn, ổn định, nhờ những thay đổi quan trọng trong kiến trúc. Kể từ lúc được phát hành đến nay, IIS 6.0 mới chỉ mắc một lỗi bảo mật nghiêm trọng, một "thành tích" đáng ghi nhận với sản phẩm của Microsoft!

Cùng với sự ra đời của hệ điều hành mới Windows Vista, IIS cũng được nâng cấp lên phiên bản 7.0. Với một hệ điều hành mang tính cách mạng như Vista, không có gì khó hiểu khi IIS 7.0 thực hiện bước nhảy vọt so với các phiên bản trước đây. Được viết lại trên nền tảng mã của IIS 6.0, với những cải tiến tốc độ, độ ổn định và khả năng an ninh, mục tiêu của IIS 7.0 là trở thành một máy chủ web uyển chuyển và dễ dùng, cũng như đủ mạnh để chạy các ứng dụng web trong tương lai. Được coi là máy chủ web nhiều tham vọng nhất của Microsoft từ trước đến nay, cũng như là lần nâng cấp có những thay đổi quan trọng nhất trong lịch sử, IIS 7.0 hứa hẹn là "món quà” hấp dẫn cho giới CNTT. Bài viết này sẽ giới thiệu những điểm mới ấn tượng nhất trong IIS 7.0, cũng như cách Microsoft đã làm để đạt được điều đó.

Máy chủ web dạng Module

Vista là hệ điều hành đầu tiên của Microsoft hiện thực việc module hóa: phía dưới là nhân của hệ điều hành, phía trên là các phần tương đối độc lập, mà việc có chúng hay không không ảnh hưởng đến phần còn lại của hệ thống. Điều này cho phép người dùng lựa chọn phiên bản chứa các module thích hợp với mình. Ý tưởng này cũng đã được đưa vào thiết kế của IIS 7.0. Thay vì phát triển IIS thành một khối như các phiên bản trước, IIS chia máy chủ web thành 2 phần: một nhân được thiết kế khá nhỏ gọn và hơn 40 module thành phần chạy trên nó.

Đây là một thiết kế hết sức linh hoạt cho phép nhà quản trị có thể cài đặt/gỡ bỏ các module thành phần bất cứ lúc nào, thậm chí cấm một tính năng nào đó không chạy với một ứng dụng web cụ thể. Cấu trúc này là một phần đặc biệt quan trọng của IIS, là cơ sở cho các cải tiến khác trong phiên bản 7.0.

Thiết kế dạng module giúp nhanh chóng xây dựng máy chủ web có thành phần tối thiểu đáp ứng được nhu cầu sử dụng. Do loại bỏ các phần không cần thiết nên đồng thời giảm được nguy cơ bị tấn công, cũng như tăng tốc độ một cách đáng kể do không phải thực thi các đoạn mã không cần thiết.

Với các nhà phát triển, điều đáng quan tâm là các thành phần bổ sung của IIS 7.0 được xây dựng trên một nền tảng API mở rộng, dựa trên nền mở rộng ISAPI trước đây. Bạn có thể xây dựng các thành phần bổ sung của riêng mình, sau đó thêm nó vào máy chủ IIS, hoặc thay thế một thành phần đang có, giúp tăng cường máy chủ web một cách mềm dẻo và dễ dàng.

Đơn giản hoá quá trình triển khai và cấu hình

IIS 7.0 sử dụng một hệ thống cấu hình mới, được xây dựng dựa trên cấp bậc của các file XML. Hệ thống cấu hình này có nhiều điểm tương tự với hệ thống cấu hình của ASP.NET.

Ở cấp độ máy chủ, có 2 file riêng biệt chứa những thiết lập cơ bản nhất của hệ thống:

• system32\inetsrv\applicationHost.config: Chứa các thiết lập mặc định của IIS

• \windows\microsoft.net\framework\v2.0.50727\config\machine.config: Chứa các thiết lập mặc định của .NET Framework

Ở cấp độ ứng dụng là file web.config, chứa những thiết lập cụ thể dùng cho ứng dụng đó. Trong phiên bản 7.0, thậm chí IIS và ASP.NET có thể sử dụng chung file web.config để lưu cấu hình, dưới đây là một ví dụ.

Nhờ cách cấu hình này đã tận dụng được ưu điểm của ASP.NET, giúp xây dựng các trang web dạng "portable", có thể copy sang một máy chủ khác và chạy trực tiếp mà không cần chỉnh sửa.

Bên cạnh khả năng chỉnh sửa trực tiếp các file cấu hình (bằng một trình soạn thảo như Notepad chẳng hạn), IIS 7.0 vẫn tiếp tục hỗ trợ việc thiết lập bằng Admin Base Object (ABO), hoặc Active Directory Service Interfaces (ADSI) và đối tượng Windows Management Instrumental (WMI). Phần lớn các đoạn mã cấu hình viết dựa trên các công cụ này đều có thể dùng lại, do IIS 7.0 cung cấp một lớp tương thích đối với ABO. Bên cạnh đó, IIS 7.0 cũng bổ sung thêm các công cụ quản lý và một số hàm API nhằm đơn giản hoá công việc quản lý, đồng thời cho phép cấu hình và triển khai một cách tự động.

Tích hợp tốt hơn với ASP.NET

Không có gì khó hiểu khi Microsoft tích cực lăng xê cho "gà nhà”. Khuyết điểm lớn nhất của ASP.NET chính là chỉ chạy trên nền IIS/Windows, khiến cho sự phổ biến của nó bị hạn chế. Tuy nhiên, Microsoft đã đáp trả bằng cách đưa ASP.NET 2.0 trên nền IIS 7.0 thành một khung phát triển các ứng dụng web xuất sắc, bằng việc tích hợp ASP.NET vào nhân của máy chủ web (ASP.NET 1.0 không được hỗ trợ trên IIS 7.0, và Microsoft khuyến cáo sử dụng ASP.NET 2.0 trên máy chủ này).

Chúng ta hãy xem cấu trúc của việc tích hợp này:

Trong IIS 6.0 trở về trước, ASP.NET chỉ là một mở rộng của IIS thông qua ISAPI.

Khi có một yêu cầu (request) đến một file ASP.NET, nó sẽ được xử lý bằng IIS trước, sau đó mới chuyển sang cho ASP.NET (aspnet_isapi.dll). Với các yêu cầu không phải đến một file ASP.NET, như các trang ASP, sẽ được xử lý bởi IIS và các mở rộng ISAPI khác. ASP.NET "đứng ngoài cuộc" trong quá trình xử lý này.
Hạn chế chính của kiểu xử lý này là các dịch vụ cung cấp bởi ASP.NET, cũng như mã ASP.NET sẽ không thể dùng bởi các request không phải là ASP.NET. Ngoài ra, các module của ASP.NET sẽ không thể tác động đến các phần xử lý request của IIS trước và sau khi ASP.NET thực thi.

Trong IIS 7.0, ASP không phải là một bổ sung cho IIS mà thực sự là một phần trong nhân của IIS. Một request chứa nội dung bất kì được xử lý bởi IIS, bao gồm cả các module của IIS và của ASP.NET trong tất cả các quá trình. Điều này cho phép các request tới các trang ASP, PHP, .. có thế sử dụng các dịch vụ của ASP.NET như Forms Authentication hay Output Cache,...

Khả năng "cắm" trực tiếp vào máy chủ cho phép các module của ASP.NET thay thế, chạy trước hay sau bất kì chức năng nào của IIS.

Ngoài ra, khi tích hợp trực tiếp, các hàm API mở rộng của ASP.NET cho phép xử lý request sâu hơn. Ví dụ, các module ASP.NET có thể sửa đổi header của các request trước khi các phần khác xử lý, thêm header Accept-Language trước khi các ứng dụng ASP thực thi theo thứ tự để bắt buộc gửi các nội dung đã địa phương hóa về client dựa trên tùy chọn của người dùng.

Tăng cường An ninh

Được xây dựng trên nền IIS 6.0, IIS 7.0 có những thay đổi về mặt cấu trúc để tăng cường an toàn, đồng thời cung cấp các công cụ giúp bạn xây dụng web an toàn hơn.

Với cấu trúc module như đã trình bày ở trên, IIS 7.0 có thể loại bỏ tất cả những gì không cần thiết, làm giảm những lỗ hổng mà hacker có thể lợi dụng. Mặt khác, khi một điểm yếu được tìm thấy trong các phần mà bạn không dùng, bạn sẽ không phải ngừng chạy web của mình để vá, đồng nghĩa với việc tăng độ sẵn sàng cũng như giảm chi phí bảo trì hệ thống.

Về phía các nhà phát triển, IIS 7.0 cung cấp những công cụ mạnh mẽ hỗ trợ cho việc tăng cường an ninh cho web. Với việc tích hợp ASP.NET, bạn có thể sử dụng các tính năng của ASP.NET như Forms Authentication, Membership và Login controls để cung cấp một quá trình xác nhận hoàn chỉnh trong toàn ứng dụng. Bạn có thể làm việc này trong vài phút và không phải viết một dòng mã nào cả!

Tính năng URL Authorization mới, tương tự như tính năng URL Authorization của ASP.NET, dùng để cấu hình các quy tắc truy cập cho toàn bộ ứng dụng. Qui tắc truy cập cho phép/từ chối truy cập tới các địa chỉ URL trong ứng dụng dựa theo tên và quyền hạn của người dùng. URL Authorization tích hợp một cách trong suốt với tính năng Membership và Role Management của ASP.NET 2.0, và có thể dùng một cách hiệu quả với Forms Authentication và Login controls của ASP.NET để nhanh chóng thiết lập an ninh từ phía người dùng trong ứng dụng của bạn.

Tính năng lọc request mới cung cấp cho bạn chức năng khóa mạnh mẽ, một phần của nó chính là công cụ URLScan. Bạn có thể dùng tính năng này để bảo vệ site của mình chặt chẽ hơn bằng cách từ chối các request chứa các dữ liệu đáng nghi, bảo vệ tài nguyên nhạy cảm hay giới hạn request tấn công.

IIS 7.0 cũng cung cấp một số thay đổi giúp cho việc triển khai và quản lý các thiết lập an ninh dễ dàng hơn. Đáng chú ý là tài khoản IIS_IUSR và nhóm tài khoản IIS_IUSRS mới. Là một tài khoản built-in (có sẵn), IIS_IUSR không bị hạn chế bởi việc hết hạn password, cũng như phải đồng bộ password giữa các máy với nhau. Dùng để thay thế nhóm tài khoản IIS_WPG trước đây, IIS_IUSRS tự động thêm vào quá trình nhận diện thành viên trong lúc chạy, giúp giảm việc nhận diện thủ công vào trong nhóm khi sử dụng các tài khoản tùy chọn.

Tăng cường chẩn đoán

Với một máy chủ phức tạp như IIS, việc xác định lỗi nằm ở đâu là một công việc khó khăn và tốn nhiều thời gian. May mắn là IIS 7.0 đã đưa ra những công cụ mới hỗ trợ giám sát hoạt động của máy chủ cũng như gỡ rối ứng dụng.

Một trong những tính năng đáng chú ý là Runtime State and Control API (RSCA) cho phép bạn xem xét trạng thái hoạt động của các trang và các ứng dụng, các tiến trình đang chạy, thậm chí cả các request hiện đang được xử lý trên máy chủ. Nó cũng cho phép bạn điều khiển trạng thái của máy chủ, như khởi động/dừng các site, hoặc thu hồi bộ nhớ từ các ứng dụng. Trong Windows Vista, bạn có thể truy cập thông tin này thông qua công cụ appcmd.exe (dạng dòng lệnh), hoặc lập trình sử dụng các hàm API của Microsoft.Web.Administration. Với khả năng cung cấp thông tin chi tiết về những gì đang xảy ra, RSCA rất thuận tiện khi bạn tiến hành chẩn đoán hoặc tối ưu máy chủ.

Khi có lỗi trong ứng dụng web, nguyên nhân có thể là thiết lập máy chủ sai, lỗi ứng dụng, hoặc do các yếu tố môi trường khác. IIS 7.0 cung cấp thông tin chi tiết cho hầu hết các lỗi, báo cho bạn biết chính xác điều gì sai, tại sao và gợi ý cách để sửa chúng. Chi tiết về lỗi mà IIS 7.0 cung cấp tương tự như của ASP.NET. Theo mặc định, bạn chỉ nhận được thông tin chi tiết khi truy cập website từ máy cục bộ. Giống như trước đây, bạn có thể cấu hình thông tin trang báo lỗi cho mỗi mã lỗi hoặc chuyển sang một URL khác. Trang lỗi chi tiết cũng có thể địa phương hóa, cung cấp mô tả lỗi dựa trên ngôn ngữ của client.

Tăng cường quản lý

IIS 7.0 cung cấp một tập hợp phong phú các chức năng quản trị giúp việc quản lý máy chủ trở nên thuận tiện trong nhiều tình huống khác nhau. Công cụ quản lý IIS Manager mới dạng đồ hoạ, thay thế cho InetMgr.exe trước đây, giúp việc quản trị máy chủ trở nên rất đơn giản với giao diện dựa trên các công việc cụ thể.

IIS Manager cho phép bạn quản lý phần lớn tính năng của IIS 7.0 cũng như theo dõi hoạt động của máy chủ. Công cụ này hỗ trợ quản trị từ xa thông qua kết nối HTTP/SSL, với tùy chọn hỗ trợ cho cả việc xác thực dựa trên Windows và các cách xác thực khác.

Ngoài ra, IIS Manager cho phép ủy quyền quản lý, tức là cho phép chủ ứng dụng quản lý ứng dụng của họ từ xa mà không phải truy cập với quyền quản trị trên máy chủ. Cùng với khả năng này, người dùng của dịch vụ host có thể chạy công cụ quản trị trên desktop và kết nối từ xa để quản lý ứng dụng trên máy chủ host. Tất nhiên, các nhà quản trị máy chủ có toàn quyền quyết định tính năng quản lý nào được ủy quyền cho chủ ứng dụng.

Công cụ quản trị rất mềm dẻo, xây dựng trên một hệ thống cấu hình có thể mở rộng, cho phép thêm các giao diện quản lý tùy chọn vào công cụ. Bạn có thể tìm hiểu thêm về công cụ quản lý IIS Manager và cách thêm plug-in quản trị của chính bạn tại địa chỉ iis.net/default.aspx?tabid=7&subtabid=73

Nếu cần công cụ quản lý mềm dẻo hơn nữa, IIS 7.0 cung cấp công cụ dạng dòng lệnh appcmd.exe. Công cụ này tập hợp đầy đủ các chức năng quản lý và hỗ trợ cho các thao tác hàng loạt tốt hơn giao diện đồ hoạ, giúp đơn giản hoá việc đọc/ghi cấu hình, truy cập site và thông tin trạng thái về các ứng dụng, đồng thời thực hiện gần như bất kì công việc quản lý nào khác, tất cả thông qua dòng lệnh.

Chuẩn đoán lỗi mà không phải gỡ rối

Đối với nhà quản trị, lỗi thuộc dạng "Unknown" (không biết), hoặc lỗi gây ra trong quá trình tương tác của các thành phần máy chủ web thật sự là một thảm hoạ. Để giải quyết vấn đề đau đầu đó, IIS 7.0 cung cấp một cơ cấu dò vết (tracing) toàn diện, cung cấp thông tin chi tiết về mỗi request, giúp xác định vấn đề một cách nhanh chóng.

IIS 7.0 bổ sung các sự kiện chứa nhiều thông tin lên Event Tracing for Windows (ETW), vốn đã được thêm vào Windows Server 2003 SP1. Các sự kiện này chứa các thông tin hữu ích về mỗi giai đoạn trong quá trình xử lý của máy chủ, có thể kiểm tra để dò vết thông qua việc thực thi các request và xác định chính xác chỗ bị lỗi. Các sự kiện này cũng có thể được gửi tới cơ cấu dò vết của Windows, cho phép nhiều thành phần khác, như ASP.NET và SQL Server, liên kết các thông tin tracing của chúng thành một khối thông tin thống nhất và chi tiết về mỗi request. Chúng cũng có thể được gửi đến tính năng Failed Request Tracing mới (được gọi là FREB), lưu lại trace log dưới dạng XML.

Điều thú vị nhất về Failed Request Tracing là bạn có thể bật nó lên với các request gây lỗi hoặc cần nhiều thời gian xử lý hơn bình thường. Với Failed Request Tracing, bạn luôn có thể nhận được các thông tin dò vết đáng giá khi lỗi xảy ra, ngay cả khi lỗi không liên tục hay khó lặp lại. Khả năng này giúp chẩn đoán và sửa các lỗi mà trước đây cần debug đầy đủ mới làm được.

Nền tảng của việc dò vết được đặt vào các module của IIS thông qua mô hình mở rộng máy chủ, cho phép tất cả các thành phần máy chủ, bất kể chúng được phân phối cùng với IIS hay là được phát triển bởi bên thứ 3, tạo ra các thông tin dò vết chi tiết trong quá trình xử lý request. Việc dò vết của IIS 7.0 tích hợp với ASP.NET thông qua System.Diagnostics và cơ cấu dò vết của ASP.NET, cho phép các module được quản lý sử dụng một mẫu dò vết thống nhất. Xa hơn, bạn có thể viết module để xử lý và xuất thông tin dò vết theo cách của bạn.

Tăng cường tốc độ

Phiên bản IIS 7.0 trên Windows Vista chỉ cho phép xử lý tối đa 10 request cùng lúc. Tuy nhiên, ngay cả phiên bản này, người ta đã thấy có những thay đổi ấn tượng về mặt tốc độ, chứng tỏ đã có những thay đổi quan trọng ở cấu trúc bên trong. Người ta đang trông chờ vào hiệu năng thật sự mà IIS 7.0 trên nền Windows Longhorn Server mang lại.

Trước hết do cấu trúc module hoá của máy chủ. Cấu trúc này cho phép nhà quản trị loại bỏ các thành phần không cần thiết, nhờ đó tiết kiệm được RAM và thời gian CPU mỗi khi xử lý các request. Điều này làm tăng tốc độ đáng kể và khả năng xử lý của máy chủ. Xa hơn, việc cho phép/cấm một thành phần của máy chủ làm việc với mỗi ứng dụng sẽ tăng tốc độ của ứng dụng đó nhờ việc nó chỉ sử dụng những thành phần cần thiết cho mình.

Thứ hai, một thành phần đáng chú ý trong IIS 7.0 là IIS Output Cache mới, được đánh giá là nhanh hơn tính năng Cache trong ASP.NET. Mặc dù chỉ cung cấp một số chức năng, nhưng Output Cache vẫn đủ linh hoạt trong việc dùng lại các trang đã được xử lý, giúp mềm dẻo hóa việc xử lý trang web cũng như truy vấn cơ sở dữ liệu để trả về kết quả cho client. Việc sử dụng IIS Output Cache được trông đợi tăng tốc độ các trang ASP.NET, PHP hay ứng dụng CGI lên từ 5-10 lần, trong khi sử dụng ít tài nguyên hệ thống hơn.

Một vài chi tiết về IIS 7.0

IIS 7.0 chỉ có mặt trong các phiên bản Vista Home Premium, Business, và Ultimate, bản Home Basic sẽ không có thành phần này. Khi tiến hành nâng cấp từ các phiên bản trước, cần chú ý như bảng dưới

Phiên bản IIS 7.0 trên Windows Vista sử dụng cùng nhân với phiên bản trên Longhorn Server, và khi phiên bản trên Longhorn hoàn tất, người dùng Vista cũng có thể sử dụng đầy đủ các tính năng của một máy chủ thực sự thông qua một gói dịch vụ (service pack) cho Vista, giúp các nhà phát triển có thể xây dựng và chạy thử ứng dụng web một cách hoàn chỉnh ngay trên máy tính chạy Vista của mình.

Kết luận

Bài viết này hi vọng đem đến cho các bạn một cái nhìn tổng quan về IIS 7.0. Với những điều đã trình bày ở trên, IIS 7.0 thật sự đáng giá, đúng như tuyên bố của Microsoft về một kiến trúc nền tảng cho máy chủ web thế hệ tiếp theo. Đối với các nhà phát triển, IIS 7.0 là một trong những lý do thuyết phục để họ nâng cấp lên Vista/Longhorn Server. Còn người dùng sẽ được lợi với những ứng dụng/dịch vụ web nhanh, an toàn và sẵn sàng hơn.

Home

Techzone Viet Nam Outsourcing (TCVNS) provides custom web application development to serve your business needs to both local and offshore customers since 2007. At our outsourcing services company, we understand it's a matter of understanding the client's business goals.

The experts at TCVNS have significant experience delivering Rich Internet Applications that are designed to improve the satisfaction of end users while increasing their productivity by providing engaging, rich user experiences.

By completing numerous custom software solutions and custom e-business software

By developing compatible and efficient Intranet & Extranet applications, we cultivate methods to build an effective approach to each customer's situation.

We are providing low-cost online site design and development services to offshore web development.
Low-priced site design and development has proved to be a decision making factor for companies that offer offshore web development in a competitive market. The achiever of Offshore Outsourcing relies on the word "customer satisfaction". Offshore web development is much about building relationships based on trust, and mutual respect.

We are experienced in providing low-cost web site design and development services to United States, Japan, and Singapore as their offshore web development company.

We are committed to excellence in our services and work towards delivering high quality IT services to our customers

Feel free to contact for quotes and demos of our affordable web site design development development, we have built our expertise so that we can support many business models. services.