File "subprocess.py", line 970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB

MemoryError

Jedenfalls arbeite ich gerade an der Version 0.2 meines Reminders und werde hoffentlich noch vor dem Schlafengehen soweit sein.

Inzwischen kann man die Erinnerungen auch editieren und sie werden wahlweise farblich hervorgehoben, wenn sie am selben oder naechsten Tag anstehen. Außerdem ist das Aussehen ziemlich konfigurierbar geworden und ich habe eine bessere Methode gefunden, Daten (in diesem Falle der Plural von Datum ;) ) handzuhaben.

Was noch ansteht: Wenn man Aenderungen macht, sollen sie sofort erscheinen und nicht erst nach einem Neustart und ich habe immer noch kein Feld fuer "daysbefore", womit man einstellt, wieviele Tage vor Ablauf der Erinnerung diese angezeigt werden soll. Einstellen kann man es schon von Anfang an, aber ich habe schlicht und einfach vergessen, ein entsprechendes Feld in die GUI einzubauen :-/

Also dann mach ich mal weiter, jetzt wo mein Besuch weg ist ;)

da ich ein ziemlich zerstreuter Mensch bin, suchte ich heute nach einem nuetzlichen Programm, das mir effizient auf die Spruenge helfen kann. Ich dachte dabei an ein einfaches Teil, das ein paar "Notizzettel" auf den Desktop knallt, auf denen steht, was demnaechst bei mir ansteht.

Leider fand ich nach gut zehnminuetiger Recherche nichts und fing also an, mir selbst das gewuenschte Programm zu schreiben.

Ich programmiere schon laenger - etwa seit sechs oder sieben Jahren - vorallem mit Python, bin auch im Python-Forum aktiv und verdiene damit seit letztem Jahr sogar neben dem Studium Geld!

Nun ist es getan... den ganzen Tag habe ich daran gesessen und hier ist es zu bekommen:

• der Code
• der dazugehoerige Eintrag im Python-Forum

Und jetzt geh ich schlafen. Ich werde morgen dann sicherlich hier schreiben, wieviele Vorlesungen ich mal wieder verschlafen habe :-D

buồn chán, mò vô blog tính viết chút, lại cũng không vào được, vào trang chủ cũng rất lâu, các blog khác thì ... không thể. Hu hu... tức khí, chơi trò fake IP nhé. Đang nắm trong tay 1 IP USA khá ngon lành, thử xem.... ồ lê, load ầm ầm. Thầm chửi rủa cái thằng viettel này chặn wordpress sao? -> thế sao nó không chặn luôn trang chủ? DNS có vấn đề? -> ồ ko, mình change IP mà. IP VN bị chặn?-> ko bít, nhưng chặn thì 2 cái vô lý, 1 là vẫn vào được trang chủ, 2 là số lượng blogger là vietnamese khá đông. Thế tại làm sao?.... thôi thì chắc internet traffic đang có vấn đề, thông cảm vậy. hừ hừ.

Tức quá, giờ trình bày quy trình làm prj của mình nè, ít nhất là cái này... cái khác ko thèm nói đến.

hoangnd: Êu, bài toán ổn chứ?
xxx: ok, nhưng tôi thấy...
.... nói nói.... nói nói....
hoangnd: Ổn chưa?
xxx: ok, vậy để tôi làm cái nầy, ông làm cái nầy....
hoangnd: ok (cười sướng).
xxx: ...làm làm làm....
hoangnd: ... chơi chơi chơi ....

.....

hoangnd: êu, đến đâu rùi, đưa tôi coi cái.
xxx: ok, đợi mấy hôm nữa, tôi sửa mấy cái.
hoangnd: ok ... chờ chờ chờ....

.....

hoangnd: êu, xong chưa, coi cái nèo?
xxx: ok, mai ngày kia tôi gửi ông.
hoangnd: ok, hay đấy.

....

hoangnd: gửi chưa?
xxx: ông ra đây tui chỉ nè...
hoangnd: ok ok.
.... chỉ chỉ chỉ ...
hoangnd: huhm, đưa tôi về test cho.
hoangnd: test test test ....
.... tât nhiên là vài trang A4 lỗi rùi ...
hoangnd: êu, tui thấy cái nầy .... nói nói ...
hoangnd: lỗi tui ghi ra file word, ông ngó qua nè và sửa nhé.
xxx: ok ok.

.... chờ chờ chờ ...
hoangnd: xong chưa, ngó cái.
xxx: uhm, đang sửa, được mấy cái rùi, cũng đang làm thêm nữa.
hoangnd: hay quá hay quá, cố lên.

.... chơi chơi chơi ....

hoangnd: gửi tui xem zới!
xxx: uhm, xem nè.
hoangnd: xem xem, nhăn mặt.
lại vài trang A4 lỗi...

hoangnd: êu, tui thấy còn lỗi nầy nầy.... và mầy cái trước chưa sửa à....
xxx: ok, đang sửa
hoangnd: ok ok, có gì cứ ý kiến nhé.
xxx: uh, à mà tôi định.... nói nói nói...
hoangnd: thoải mái đi, làm sao cho tiện nhất là được.
xxx: vậy thế nhé ...

.... chơi chơi chơi ....

hoangnd: Demo đâu?
xxx: xem nè
hoangnd: ok, gọi thầy ra xem.
thầy: #$%%^$#^#%$#%$#%#!#$()_#%$^!#
xxx: ------------

hoangnd: uhm, thôi, để tôi về sửa lại tí giao diện, xong ông cứ thế làm nhé.
xxx: ok, zậy ông làm đi.

... làm làm làm...
hoangnd: nè, xem giao diện mẫu nè, ông làm theo thế nhé...
xxx: uh uh uh...
hoangnd: thui, để tui làm lại lun cho, ông gửi code đây tôi ghép.
xxx: ok, vậy thế nhé.
hoangnd: ghép ghép ghép....
hoangnd: êu, còn mấy lỗi, ông sửa nhé vì ông làm từ đầu mà ... lỗi lỗi lỗi ... tôi ghi ra giấy nè...
xxx: ok, xong ngay.

hoangnd:........ chờ chờ .....
hoangnd: xem nèo
xxx: ok, nè.
hoangnd: uhm uhm, lại lục đục sửa....
.... sửa sửa ...sửa ...

xxx: demo cho thầy phát.
hoangnd:ok
xxx: ông demo nhé
hoangnd: ok, xong ngay

--- demo demo ---
hoangnd: tính huống chính của tụi em xảy ra như vầy, thầy có hỏi gì ko ạ?
thầy: ko, nhưng trước khi bảo vệ nhớ test kỹ hơn chút, test ác liệt vào.
hoangnd: zét zét
thầy: đĩa đâu
hoangnd: hôm tới nhé thầy.
thầy: ok, chuẩn bị đi, đĩa chứa code + tài liệu.
hoangnd: zét zét.
xxx: ok, ổn đấy.

---- chơi chơi chơi ----

---- chơi típ ----

hoangnd: prj tụi mình seo rùi ông?
xxx: uhm..... tui gửi cho ông cái vừa phần tui vừa sửa rùi, ghép vào nhé, mai vác code lên apt nhé.
hoangnd: ừa, ok xong ngay.

.... ngó ngó ngó .... test test .... sửa sửa ....
-> logic hơi chuối.

.... uhm uhm....
hoangnd: uhm, cái tội ko chịu làm.
hoangnd: quyết định nhé, thiết kế lại

---> pó chim. Đúng là ... ' cứt trâu để lâu hóa bùn'.

1. Add comments to your code.
2. Do not complicate things.
3. Keep in Mind - "Less is more" is not always better.
4. No hard coding please.
5. Do not invent your own frameworks.
6. Say no to Print lines and String Concatenations.
7. Pay attention to the GUI.
8. Always Prepare Document Requirements.
9. Unit-test. Unit-test. Unit-test.
10. Remember - quality, not quantity.

By Sarah George
Published April 19, 2006

How do people become professional programmers? Many people go the "traditional" path through a computer science or software engineering education and from there into professional programming work.

Others become professional programmers by accident. A person writes a small program to help at work, and their workmates say, "Oh great, you can write programs! You're our programmer now!"

Other people start out as hobbyists and follow a less traditional path, not always getting a degree, but clearly wanting to be programmers from the start and working actively towards that goal.

I've been a hobbyist programmer since I was 6. I wasn't writing anything amazing back then but I had started writing and soon found it was absorbing most of my time. Since I never really stopped, that gives me 24 years "programming experience" and counting.

At first I was into writing computer games. Later people asked me to write programs for them, and sometimes I even got paid. From this I learned that software is always for something. Programs are not self contained worlds of their own. People expect things out of a program that have more to do with Japanese or Geophysics or Engineering (or whatever they've got in mind) than with how a computer works. I had to learn something about all those domains in order to write programs for them.

At university it didn't take long before I was a tutor, and that's where I found I enjoy teaching, and especially enjoy teaching programming.

While I was at university I got my first "real" job, writing Visual C++ code for a financial database company. In terms of design and theory it was lightweight stuff. But in terms of working with others on a large project I was being thrown in the deep end! They had gigabytes of source code, growing cancerously through the efforts of a dozen developers of wildly differing skill levels.

In spite of my programming skills being well above average there, I learned to settle for being a junior programmer, a little fish in a large pond.

Skipping along a few more jobs and a lot more years, today I am a senior developer in a small research group—a big fish in a little pond. I've had to teach my co-workers a lot about professional programming, because most of them haven't been in industry to get that taste of what large code bases and diverse skill levels do to programs if you aren't using those "professional" skills to keep everyone pointed in the same direction.

There's quite a gap between "being able to program" and being a "professional programmer." It took me 15 years to go from beginner to hotshot programmer, then another 10 years to go from hotshot to professional—and I'm still learning.

Whatever the path we follow, most professional programmers have in common the fact that they learned to code first and how to be a professional later.

The Meaning of "Professional"
So what does it mean to be a professional programmer? What does it mean to be a professional anything? Some definitions simply say to be a professional is "to make money from a skill," but true professionals also have a set of qualities often described as "professionalism." In my opinion, these qualities are: trustworthiness, teamwork, leadership, communication, constant updating of skills, an interest in minimizing risks and accountability. Each of these effect the professional programmer in certain ways.

Trustworthiness The concept of trustworthiness applies in several different ways for programmers. Can you be trusted with a job? To perform a task without someone checking up on you? Can you be trusted to ask for help when you need it?

If you're given clients' data or have signed a non-disclosure agreement, then you are being trusted to respect privacy. You are trusted to check license agreements on third party tools or libraries and to get licenses or permission as required. And like any professional you are trusted to simply do a good job.

Teamwork Will you genuinely cooperate with your team mates? Will you work to mutual advantage and not just your own? Can you trust your team to work with you? Can you do your share of the work and trust your team to do the rest? And can you accept your management (and sometimes even clients) as part of the team, everyone trying to get the same job done?

Leadership Showing leadership means both earning respect from others and knowing what to do with it. Recognize the skills of your team members, and make sure you can offer each person challenges and development without exceeding what they can cope with at a given time.

Leadership involves not always getting to do the "fun" parts of a project yourself (that scary "delegation" word). It also involves not asking anyone to do a task that you wouldn't be willing to do yourself. It's not just the managers and lead programmers who need to show leadership, it's any professional programmer. The best programmers to work with are the ones that know what's going on, not just their little tasks.

Communication Respecting the people you work with, and your clients, enough to really listen to them is a critical part of communication. Teamwork can't happen without good communication, nor can accountability.

Communication is critical for helping clients to produce usable specifications and feedback. Will you question whether the specs you are given really will serve the purpose that the client has in mind?

Communication skills help with making meetings timely and effective. A professional's communication is effective and to the point, whether in person, in email, on the phone or in written documents.

Documentation at first seems like a programmer-specific concern until you consider how many people require documentation in a serious project: other programmers need high level, API level and in-code documentation; managers need planning, progress, and bug documentation; lawyers need proof of what was done and when; and users need documentation on how to use the software.

Updating Skills Keeping your skills up to date involves staying aware of what's going on in your industry. What are the current ideas about methodologies like eXtreme Programming? What libraries and tools are out there that might support your project? What are the current refactoring tools? How about standards, file formats and protocols? Are you up to date with Unicode, XML, SQL, and all the other acronyms? Perhaps you're missing out on something if you're not. What platforms are your potential clients using? Should you be learning about cross platform development?

Basically you need to possess a genuine interest in your field, and to read broadly so you know what's out there and which areas to then read deeply about. You also need to accept that even (or should I say "especially") the very best programmers are still learning.

Minimizing Risks Familiarity with best practices, combined with a healthy dose of common sense, will take you a long way towards managing risks. Professional programmers keep track of known bugs or any other change they intend to make. Bugs are risks, and a simple database can prevent you having a product ship with bugs you'd simply forgotten.

Another risk that's often not properly considered is any and all changes to the source code. Source is your livelihood and any change can be a mistake. There's good software out there that will keep track of every revision of your source code and even help merge code that multiple people have changed.

Professional programmers are careful to do enough testing. A software company will generally have testers but the developers need to know how to get the most out of testers and also how to write their own unit and regression tests to make sure every change in behavior is noticed and checked by a human.

Keeping your code simple and well styled is another commonly overlooked way to manage risks. If anyone can look at the code and see right away what it does, you are far less likely to find bugs in it later, and you are less likely to have a junior programmer attempt to change something without understanding it first.

Another risk is the client changing their mind, or more often changing their specifications because they've realized it wasn't what they had in mind. Write your code to be modular and reusable and you won't have any trouble adapting it to changing needs.

Accountability Writing code for others is a responsibility. You need to make sure your software is reliable. You need to make sure you and the client truly understand the requirements and specifications. You need to have documentation of your work, all current and past bugs, your progress, any problems, signed-off milestones, and more. You are also required to know about some basic legal issues, like software licensing, the terms of your employment contract, and intellectual property law.

* * *

As you can see, there is a huge gap between "coding" and "professional programming." Most programming courses focus on the coding side of things, and the professional skills tend to be glossed over or not covered at all. I have found myself regularly teaching these skills to new co-workers, which highlighted the need for "professionalism skills training." Teaching my co-workers reminded me how much I enjoy teaching. I decided to teach more people by trying my hand at professional writing for a change.

I set up a web site, which is completely independent from my day job. The site is called Developing Programmers.com. It is devoted to teaching people how to develop into professional programmers. Since founding the site, I've been presenting the tools and ideas that I think professionals should know about.

Some of my articles simply refer to other sites of benefit to would-be professionals. I research other articles from scratch: tutorials, guides, and discussions of things professionals should be thinking about, like revision control, documentation, keeping your group pointed in the same direction—and of course, each of the aspects of professionalism that I listed earlier.

These days I consider myself to be a professional programmer, though I am still discovering the depth and breadth of what exactly that means. Perhaps that ongoing exploration of programming and of professionalism is what makes this for me a career and not just a job.

Published March 14, 2006 

What exactly is software development, and why is it so hard? This is a question that continues to engage our thoughts. Is software development an engineering discipline? Is it art? Is it more like a craft?

We think that it is all of these things, and none of them. Software is a uniquely human endeavor, because despite all of the technological trimmings, we're manipulating little more than the thoughts in our heads. That's pretty ephemeral stuff. Fred Brooks put it rather eloquently some 30 odd years ago[Bro95]:

"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this very tractability has its own problems.)"

In a way, we programmers are quite lucky. We get the opportunity to create entire worlds out of nothing but thin air. Our very own worlds, complete with our own laws of physics. We may get those laws wrong of course, but it's still fun.

This wonderful ability comes at a price, however. We continually face the most frightening sight known to a creative person: the blank page.

1. Writer's Block

Writers face the blank page, painters face the empty canvas, and programmers face the empty editor buffer. Perhaps it's not literally empty—an IDE may want us to specify a few things first. Here we haven't even started the project yet, and already we're forced to answer many questions: what will this thing be named, what directory will it be in, what type of module is it, how should it be compiled, and so on.

The completely empty editor buffer is even worse. Here we have an infinite number of choices of text with which to fill it.

So it seems we share some of the same problems with artists and writers:

1. How to start
2. When to stop
3. Satisfying the person who commissioned the work

Writers have a name for difficulties in starting a piece: they call it Writer's Block.

Sometimes writer's block is borne of fear: Fear of going in the wrong direction, of getting too far down the wrong path. Sometimes it's just a little voice in your head saying "don't start yet". Perhaps your subconscious is trying to tell you that you're missing something important that you need before you can start.

How do other creative artists break this sort of logjam? Painters sketch; writers write a stream of consciousness. (Writers may also do lots of drugs and get drunk, but we're not necessarily advocating that particular approach.)

What then, is the programming equivalent of sketching?

Software Sketches

Sometimes you need to practice ideas, just to see if something works. You'll sketch it out roughly. If you're not happy with it, you'll do it again. And again. After all, it takes almost no time to do, and you can crumple it up and throw it away at the end.

For instance, there's a pencil sketch by Leonardo da Vinci that he used a study for the Trivulzio equestrian monument. The single fragment of paper contains several quick sketches of different views of the monument: a profile of the horse and rider by themselves, several views of the base with the figures, and so on. Even though the finished piece was to be cast in bronze, da Vinci's sketches were simply done in pencil, on a nearly-scrap piece of paper. These scribblings were so unimportant that they didn't even deserve a separate piece of paper! But they served their purpose nonetheless.[1]

Pencil sketches make fine prototypes for a sculpture or an oil painting. Post-It notes are fine prototypes for GUI layouts. Scripting languages can be used to try out algorithms before they're recoded in something more demanding and lower level. This is what we've traditionally called prototyping: a quick, disposable exercise that concentrates on a particular aspect of the project.

In software development, we can prototype to get the details in a number of different areas:

1. a new algorithm, or combination of algorithms
2. a portion of an object model
3. interactions and data flow between components
4. any high-risk detail that needs exploration

A slightly different approach to sketching can be seen in da Vinci's Study for the Composition of the Last Supper. In this sketch, you can see the beginnings of the placement of figures for that famous painting. The attention is not placed on any detail—the figures are crude and unfinished. Instead, da Vinci paid attention to focus, balance and flow. How do you arrange the figures, position the hands and arms in order to get the balance and flow of the entire piece to work out?

Sometimes you need to prototype various components of the whole to make sure that they work well together. Again, concentrate of the important aspects and discard unimportant details. Make it easy for yourself. Concentrate on learning, not doing.

As we say in The Pragmatic Programmer[HT00], you must firmly have in your head what you are doing before you do it. It's not at all important to get it right the first time. It's vitally important to get it right the last time.

Paint Over It

Sometimes the artist will sketch out a more finished looking piece, such as Rembrandt's sketch for Abraham's Sacrifice Of Isaac in 1635. It's a crude sketch that has all of the important elements of the final painting, all in roughly the right areas. It proved the composition, the balance of light and shadow, and so on. The sketch is accurate, but not precise. There are no fine details.

Media willing, you can start with such a sketch, where changes are quick and easy to make, and then paint right over top of it with the more permanent, less-forgiving media to form the final product.

To simulate that "paint over a sketch" technique in software, we use a Tracer Bullet development. If you haven't read The Pragmatic Programmer yet, here's a quick explanation of why we call it a Tracer Bullet.

There are two ways to fire a big artillery gun. The first way is to carefully measure the distance to the target, compensate for wind speed and direction, the weight of the ordinance, and so on, crunch all the numbers and give the orders to fire:

"Range 1000!"

whirr. click.

"Elevation 7.42!"

whirr. click.

"Azimuth 3.44"

whirr. click.

"FIRE!"

BOOM. Oh bad luck, there. Missed.

"Range 2015!"

whirr. click.

"Elevation 9.15!"

etc. . .

By the time you've set up, checked and rechecked the numbers, and issued the orders to the grunts manning the machine, the target has long since moved.

In software, this kind of approach can seen in any method that emphasizes planning and documenting over producing working software. Requirements are generally finalized before design begins. Design and architecture, detailed in exquisite UML diagrams, is firmly established before any code is written (presumably that would make coders analogous to the "grunts" who actually fire the weapon, oblivious to the target).

Don't misunderstand: if you're firing a really huge missile at a known, stable target (like a city), this works out just great and is the preferable way to go. If you're shooting at something more maneuverable than a city, though, you need something that provides a bit more real-time feedback.

Tracer bullets.

With tracer bullets, you simply fill the magazine with phosphorus-tipped bullets spaced every so often. Now you've got streaks of light showing you the path to the target right next to the live ammunition.

For our software equivalent, we need a skeletally thin system that does next to nothing, but does it from end to end, encompassing areas such as the database, any middleware, the application logic or business rules, and so on. Because it is so thin, we can easily shift position as we try to track the target. By watching the tracer fire, we don't have to calculate the effect of the wind, or precisely know the location of the target or the weight of the ammunition. We watch the dynamics of the entire system in motion, and adjust our aim to hit the target under actual conditions.

As with the paintings, the important thing isn't the details, but the relationships, the responsibilities, the balance, and the flow. With a proven base—however thin it may be—you can proceed in greater confidence towards the final product.

Group Writer's Block

Up till now, we've talked about writer's block as it applies to you as an individual. What do you do when the entire team has a collective case of writer's block? Teams that are just starting out can quickly become paralyzed in the initial confusion over roles, design goals, and requirements.

One effective way to get the ball rolling is to start the project off with a group-wide, tactile design session. Gather all of the developers in a room[2] and provide sets of Lego blocks, plenty of Post-It notes, whiteboards and markers. Using these, proceed to talk about the system you'll be building and how you think you might want to build it.

Keep the atmosphere loose and flexible; this gets the team comfortable with the idea of change. Because this is low inertia design, anyone can contribute. It's well within any participant's skills to walk up to the whiteboard and move a PostIt-note, or to grab a few Lego blocks and rearrange them. That's not necessarily true of a CASE tool or drawing software: those tools do not lend themselves readily to rapid-feedback, group interaction.

Jim Highsmith offers us a most excellent piece of advice: The best way to get a project done faster is to start sooner. Blast through that writer's block, and just start.

Just Start

Whether you're using prototypes or tracer bullets, individually or with a group, you're working—not panicking. You're getting to know the subject, the medium, and the relationship between the two. You're warmed up, and have started filling that blank canvas.

But we have one additional problem that the painters do not have. We face not one blank canvas per project, but hundreds. Thousands, maybe. One for every new module, every new class, every new source file. What can we do to tackle that multiplicity of blank of canvases? The Extreme Programming[Bec00] notion of Test First Design can help.

The first test you are supposed to write—before you even write the code—is a painfully simple, nearly trivial one. It seems to do almost nothing. Maybe it only instantiates the new class, or simply calls the one routine you haven't written yet. It sounds so simple, and so stupid, that you might be tempted not to do it.

The advantage to starting with such a trivial test is that it helps fill in the blank canvas without facing the distraction of trying to write production code. By just writing this very simple test, you have to get a certain level of infrastructure in place and answer the dozen or so typical startup questions: What do I call it? Where do I put it in the development tree? You have to add it to version control, and possibly to the build and/or release procedures. Suddenly, a very simple test doesn't look so simple any more. So ignore the exquisite logic of the routine you are about to write, and get the one-line test to compile and work first. Once that test passes, you can now proceed to fill in the canvas—it's not blank anymore. You're not writing anything from scratch, you're just adding a few routines. . . .

2. When to Stop

We share another problem with painters: knowing when to stop. You don't want to stop prematurely; the project won't yet be finished.[3] But if you don't stop in time, and keep adding to it unnecessarily, the painting becomes lost in the paint and is ruined.

There's only one way avoid either trap: feedback. Before you even start a particular task, you have to have a way to determine that you're done. For example:

We had a client once who seemed to have some difficulty in the definition of "done" with regard to code. After toiling for weeks and weeks on a moderately complex piece of software, Matthew (not his real name) proudly announced the Code Was Done. He went on to explain that it didn't always produce the correct output. Oh, and every now and again, the code would crash for no apparent reason. But it's done. Unfortunately, wishful thinking alone doesn't help us get working software out to users.

It's easy to err on the other side of the fence too—have you ever seen a developer make a career of one little module? Have you ever done that? It can happen for any number of political reasons ("I'm still working on XYZ, so you can't reassign me yet"), or maybe we just fall in love with some particularly elegant bit of code. But instead of making the code better and better, we actually run a huge risk of ruining it completely. Every line of code not written is correct—or at least, guaranteed not to fail. Every line of code we write, well, there are no guarantees. Each extra line carries some risk of failure, carries an additional cost to maintain, document, and teach a newcomer. When you multiply it out, any bit of code that isn't absolutely necessary incurs a shockingly large cost. Maybe enough to kill the project.

How then, can we tell when it's time to stop?

Painting Murals

Knowing when to stop is especially hard when you can't see the whole thing that you're working on. Mural painting, for instance, takes a special eye. In corporate software development, you may only ever see the one little piece of detail that you're working on. If you watch mural painters up close, it's quite difficult to discern that the splash of paint they're working on is someone's hand, or eyeball. If you can't see the big picture, you won't be able to see how you fit in.

The opposite problem is even worse—suppose you're the lone developer on a project of this size. Most muralists are simply painting walls, but anyone who's ever painted their house can tell you that ceilings are a lot harder than walls, especially when the ceiling in question covers 5,000 square feet and you have to lie on your back 20 meters above the floor to paint it. So what did Michelangelo do when planning to paint the Sistine Chapel? The same thing you should do when faced with a big task.

Michelangelo divided his mural into panels: separate, free-standing areas, each of which tells a story. But he did so fairly carefully, such that the panels exhibit these characteristics:

• High cohesion
• Low coupling
• Conceptual integrity

These are things we can learn from.

Cohesion

What is cohesion? As used here, cohesion refers to the panel's focus and clarity of purpose. In the Sistine Chapel ceiling, each panel tells a single Old Testament story—completely, but without any extraneous elements.

In software, the Unix command line tool's philosophy of small, sharp tools ("do one thing and do it well") is one example. Each tool is narrowly focused on it's primary task. Low cohesion occurs when you have giant "manager" classes that try to do too many disparate things at once.

Coupling

Coupling is related to orthogonality[HT00]: unrelated things should remain, well, unrelated. Following the object-oriented principle of encapsulation helps to prevent unintended coupling, but there are still other ways to fall into the coupling trap. Michelangelo's panels have low coupling; they are all self-contained; there are no instances of figures reaching from one panel into the next, for instance. Why is that important?

If you look closely at one of the panels that portrays angels gliding about the firmament of heaven, you'll notice that one of the angels is turning his back to, and gliding away from, the other angels. You'll also notice that said angel isn't wearing any pants. He's rather pointedly "mooning" the other angels.

There is surely a tale that explains the bare tail of the mooning angel, but for now let's assume that the Pope discovered the mooning angel and demanded that it be replaced. If the panels weren't independent, then the replacement of one panel would entail replacing some adjacent panels as well—and if you had to use different pigments because the originals weren't available, maybe you have to replace the next set of panels that were indirectly affected. Let the nightmare begin. But as it stands, the panels are independent, so the offending angel (who was apparently on Spring Break) could have been easily replaced with a less caustic image and the rest of the project would remain unaffected.

Conceptual Integrity

But despite that independence, there is conceptual integrity—the style, the themes, the mood, tie it all together. In computer languages, Smalltalk has conceptual integrity, so does Ruby, so does C. C++ doesn't: it tries to be too many things at once, so you get an awkward marriage of concepts that don't really fit together well.

The trick then is to divide up your work while maintaining a holistic integrity; each Sistine Chapel panel is a separate piece of art, complete unto itself, but together they tell a coherent story.

For our projects, we have several techniques we need to use inside code, including modularity, decoupling, and orthogonality. At the project level, consider architecting the project as a collection of many small applications that work together. These interacting applications might simply use a network connection or even flat files, or a heavier-duty component technology such as Enterprise Java Beans (EJB).

Time

Up until now, we've concentrated on splitting up a project in space, but there is another very import dimension that we need to touch on briefly—time. In the time dimension, you need to use iterations to split up a project.

Generally speaking, you don't want to go more than a few weeks without a genuine deliverable. Longer than that introduces too large of a feedback gap—you can't get the feedback quickly enough in to act on it. Iterations need to be short and regular in order to provide the most beneficial feedback.

The other important thing about iterations is that there is no such thing as 80% done. You can't get 80% pregnant—it's a Boolean condition. We want to get to the position where we only ship what really works, and have the team agree on the meaning of words like "done". If a feature isn't done, save it for the next iteration. As the iterations are short, that's not too far off.

In time or space, feedback is critical. For individual pieces of code, it is vital to have competent unit tests that will provide that feedback. Beware of excuses such as "oh, that code's too complicated to test." If it's too complicated to test, then it logically follows that the code is too complicated to write! If the code seems to be too complicated to test, that's a warning sign that you have a poor design. Refactor the code in order to make it easy to test, and you'll not only improve the feedback loop (and the future extensibility and maintainability of the system), you'll improve the design of the system itself.

3. Satisfying the Sponsor

Now comes the hard part. So far, we've talked about problems that have simple, straightforward answers. Organize your system this way; always have good unit tests; look for and apply feedback to improve the code and the process; etc. But now we're headed into much more uncertain terrain—dealing with people. In particular, dealing with the sponsor: the person or persons who are paying to make this project happen. They have goals and expectations all their own, and probably do not understand the technology with which we create the work. They may not know exactly what they want, but they want the project to come out perfect in the end.

This must be the artist's worst nightmare. The person paying for the portrait is also sitting for it, and says simply "Make me Look Good". The fact that the sitter is royalty who commands a well-oiled guillotine doesn't help. Sounds pretty close to the position we find ourselves in as we write software, doesn't it?

Let's look at it from the sitter's point of view. You commission an artist to paint you. What do you get? Perhaps a traditional, if somewhat flat looking portrait such as da Vinci's Portrait of Ginevra Benci in 1474. Or maybe the realistic, haunting face of Vermeer's Girl With a Pearl Earring. How about the primitive (and topless) look of Matisse's Seated Figure, the wild and fractured Portrait of Picasso by Juan Gris, or the stick-figured jumble of Paul Klee's Captive?

All of these are portraits, all interpretations of a commonplace thing—a human face. All of which correctly implement the requirements, but all of which will not satisfy the client.

Beyond The Obvious

Each of these paintings captures the essence of a person, not just the form. More than simple photographs, each painting looks below the surface to capture something that the camera can't. As programmers, we must do the same thing, only we tend to call it abstraction.

The phrase "requirements gathering" implies that requirements are simply lying about, ready to be scooped up and worked on. That's akin to a simple photograph, in that it only examines the obvious, surface level elements. In order to emulate the painter, we need to go beyond what's asked for. We need to ask the wicked questions to help the client discover what's really needed.

Systems Thinking[Sen90] suggests asking a minimum of five "whys" beyond the first one. The classic example involves a factory floor where the consultant notices a small puddle of oil on the floor. He asks the shop manager about it, who grumbles and barks an order to the cleaning crew to get over here and clean up the oil. But the consultant persists: why is the oil there? The manager says it's the cleaning crew's fault. But where did the oil come from?

A little investigating and more than five "why" questions later, it turns out that an overly cost-conscious purchasing agent got a deal on cases of O-ring seals for the overhead pipes. Problem was, the rings were the wrong size—that's why they were such a deal. What seemed like a cost savings was in fact costing quite a bit of money in various ways.

We once were approached to develop a complex, enterprise-level data processing system that mail room staff would use to coordinate, sort, and track incoming payment checks prior to their distribution to the correct department. The company's current manual procedure was error-prone and unreliable; checks were being lost or misrouted to the destination department.

What's the real requirement here? A fancy system to sort and catalog mail for the sole purpose of delivering it to the right address? Hmm. Seems like there's already a system in place that handles that sort of thing. So instead of a nice, fat, year-long contract, we told the company to use a different postal address for each department. Let the Post Office do the sorting, hopefully without opening the pieces and losing the checks.

Requirements are rarely simple, and shouldn't be taken at face value. Remember, a portrait is more than just a picture.

Conventional Wisdom

Even stories about requirements may need deeper examination.

There's a marvelous story of technology and consultants gone wild, developing the Fisher Space Pen. The story goes that the U.S. Government spent millions of dollars of taxpayer's money developing a space pen—a pen that the astronauts could take to the moon that would operate in the harsh conditions of weightlessness, extreme heat and cold. Technology rushes to the rescue, and develops a miracle pen that can write upside down in a boiling toilet.

The Russians, by comparison, decided to use a pencil.

A marvelous tale of an inappropriate solution, except for one small problem. It's not true. Both the Russian and the U.S. astronauts used pencils at first, but there was a danger of the leads breaking and shorting out electric components, and the wood of the pencil itself was combustible as well. In a pure oxygen atmosphere, that's a really bad thing. The Fisher corporation realized this and, at its own cost, designed the Fisher Space Pen, which it then sold to NASA at reasonable cost. After the disastrous Apollo One fire, NASA made the Fisher pens mandatory.

Fisher listened to the real requirement, even before the client knew it. In time, NASA came to realize that they were right. It was an appropriate use of high-technology to solve a very real problem.

Technology For It's Own Sake

Of course, there's always the inappropriate solution: engineering for it's own sake. As luck would have it, we happen to have an anecdote for this case as well.

There was this company that had developed a sophisticated video camera that could pan and tilt, looking for a subject in its field of view. A wonderful, high-tech solution in search of a problem. In time, the company sold this technology to a government agency to help take pictures for driving licenses. You'd go into the licensing agency and have a seat in front of the machine, which would whir and click, grind and gyrate until it had locked onto your face. The flash would fire, and in a few minutes your completed driver's license would be ready.

One day, 58 year-old Fred complained that the pretty 20 year-old blonde girl on his license just didn't look much like him.

The company and the government agency kinda scratched their heads; they weren't sure what the problem was. Problems like Fred's were popping up over, but other then getting a bunch in a row, there didn't seem to be any pattern to it. Finally, the police started to complain—and got quite upset—when they started seeing driver's licenses that featured beaming, cartoon smiley faces instead of a photo.

They discovered that the technology had gone awry: in some cases, the camera wouldn't get a lock, and would simply continue to grind and whir, looking all over the room for the subject. After a few minutes of watching the camera carefully inspect the ceiling and windows, folks like Fred would get bored and wander off. The next driver comes in, and with a flourish of clicks and whirs, the camera would snap their picture—and associate it with the previous driver's license.

Now the office staff figured out pretty quickly what the problem was, but they had no feedback path to the developers. They knew that once the machine got out of sync, they'd get bad licenses all day. So one clever user figured out that one could draw a happy face with marker on a piece of white paper, stick that over the chair, and the machine would happily snap the picture.

The real requirements were ignored in the rush to be clever, with predictably poor results.

How We Do It

So how do you find out what's in the client's head? At The Pragmatic Programmer's offices, we use "special equipment" (picture a 1950's mad scientist's laboratory replete with buzzing vacuum tubes, arcing Jacob's Ladders, and cranial implants). If that doesn't work, or if we're out in the field where health and safety restrictions prevent us from using our "special equipment", we resort to the old fashioned method of asking questions, both of the client and of ourselves.

What is the user's level of sophistication? What is the context in which the software is used? Real-time on the factory floor? In a life-critical system? For a home grocery list? What is the lifetime of the application? Unused after next week, or do you need to worry about the year-2038 bug? What are the risks? Not just the development or technical risks, but what are the sponsor's risks in taking on this project?

The best way to get these questions answered, of course, is to always involve the users as you go along. Seek frequent feedback to make sure you hear stories about anyone making smiley faces as soon as it happens.[4] Maintain short iterations with frequent deliveries, and work with the real users directly as much as possible. User representatives (such as a supervisor, manager or director) generally aren't as representative as we'd all like to think.

In our perpetual rush to jump in and start coding to the first neat idea we come across, we run the risk of getting locked in to a half-baked idea too early. Instead, try to cultivate emergence: Allow the solution to find itself where you can. Part of a developer's job is to provide a fertile ground in which ideas can grow. This means having code that is agile: code that supports rapid reassembly so you can try things out. Code that is easy to refactor, or that uses flexible configuration and/or metadata to facilitate rapid—but reliable—change, bolstered by a reliable safety net of complete revision control and competent unit tests.

Does all of this really work?

Yes, it does. We've done it successfully, we know other people who've done it successfully. It's lot of work, and it's a lot of hard work, and despite our best intentions, it might still not be a success due to factors beyond our control. So why do we bother with it all?

Because, as Brooks said, we programmers create. We can create awe-inspiring works with little more than the exertion of the imagination. Why do we do it? We do it for the pleasure of watching them show it off to others, of watching them use in novel ways we'd never imagined. For the thrill of watching millions on millions of dollars in transactions flow through your application, confident in the results. For the joy of building and being part of a team, and for the satisfaction of knowing that you started with a blank canvas and produced a work of art. And if you've gone to all that trouble, we think you should "sign your work". You should be proud of it.

It is, after all, a work of art.

### 

Endnotes

1 Sadly, the project's sponsor canceled the monument due to lack of funds. Some things never change.

2 If you've got more developers on the team than will fit in an ordinary room, then you've got bigger problems than we can address here.

3 In software as well as in modern art, the distinction between intentional and accidental omissions is often difficult to make.

4 Again, the longer the gap before you get feedback the higher the likelihood of getting feedback in the form of a subpoena.

References

[Bec00] Kent Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley, Reading, MA, 2000.

[Bro95] Frederick P. Brooks, Jr. The Mythical Man Month: Essays on Software Engineering. Addison-Wesley, Reading, MA, anniversary edition, 1995.

[HT00] Andrew Hunt and David Thomas. The Pragmatic Programmer. Addison-Wesley, Reading, MA, 2000.

[Sen90] Peter Senge. The Fifth Discipline: The Art and Practice of the Learning Organization. Currency/Doubleday, New York, NY, 1990.

How do people become professional programmers? Many people go the "traditional" path through a computer science or software engineering education and from there into professional programming work.

Others become professional programmers by accident. A person writes a small program to help at work, and their workmates say, "Oh great, you can write programs! You're our programmer now!"

Other people start out as hobbyists and follow a less traditional path, not always getting a degree, but clearly wanting to be programmers from the start and working actively towards that goal.

I've been a hobbyist programmer since I was 6. I wasn't writing anything amazing back then but I had started writing and soon found it was absorbing most of my time. Since I never really stopped, that gives me 24 years "programming experience" and counting.

At first I was into writing computer games. Later people asked me to write programs for them, and sometimes I even got paid. From this I learned that software is always for something. Programs are not self contained worlds of their own. People expect things out of a program that have more to do with Japanese or Geophysics or Engineering (or whatever they've got in mind) than with how a computer works. I had to learn something about all those domains in order to write programs for them.

At university it didn't take long before I was a tutor, and that's where I found I enjoy teaching, and especially enjoy teaching programming.

While I was at university I got my first "real" job, writing Visual C++ code for a financial database company. In terms of design and theory it was lightweight stuff. But in terms of working with others on a large project I was being thrown in the deep end! They had gigabytes of source code, growing cancerously through the efforts of a dozen developers of wildly differing skill levels.

In spite of my programming skills being well above average there, I learned to settle for being a junior programmer, a little fish in a large pond.

Skipping along a few more jobs and a lot more years, today I am a senior developer in a small research group—a big fish in a little pond. I've had to teach my co-workers a lot about professional programming, because most of them haven't been in industry to get that taste of what large code bases and diverse skill levels do to programs if you aren't using those "professional" skills to keep everyone pointed in the same direction.

There's quite a gap between "being able to program" and being a "professional programmer." It took me 15 years to go from beginner to hotshot programmer, then another 10 years to go from hotshot to professional—and I'm still learning.

Whatever the path we follow, most professional programmers have in common the fact that they learned to code first and how to be a professional later.

The Meaning of "Professional"
So what does it mean to be a professional programmer? What does it mean to be a professional anything? Some definitions simply say to be a professional is "to make money from a skill," but true professionals also have a set of qualities often described as "professionalism." In my opinion, these qualities are: trustworthiness, teamwork, leadership, communication, constant updating of skills, an interest in minimizing risks and accountability. Each of these effect the professional programmer in certain ways.

Trustworthiness The concept of trustworthiness applies in several different ways for programmers. Can you be trusted with a job? To perform a task without someone checking up on you? Can you be trusted to ask for help when you need it?

If you're given clients' data or have signed a non-disclosure agreement, then you are being trusted to respect privacy. You are trusted to check license agreements on third party tools or libraries and to get licenses or permission as required. And like any professional you are trusted to simply do a good job.

Teamwork Will you genuinely cooperate with your team mates? Will you work to mutual advantage and not just your own? Can you trust your team to work with you? Can you do your share of the work and trust your team to do the rest? And can you accept your management (and sometimes even clients) as part of the team, everyone trying to get the same job done?

Leadership Showing leadership means both earning respect from others and knowing what to do with it. Recognize the skills of your team members, and make sure you can offer each person challenges and development without exceeding what they can cope with at a given time.

Leadership involves not always getting to do the "fun" parts of a project yourself (that scary "delegation" word). It also involves not asking anyone to do a task that you wouldn't be willing to do yourself. It's not just the managers and lead programmers who need to show leadership, it's any professional programmer. The best programmers to work with are the ones that know what's going on, not just their little tasks.

Communication Respecting the people you work with, and your clients, enough to really listen to them is a critical part of communication. Teamwork can't happen without good communication, nor can accountability.

Communication is critical for helping clients to produce usable specifications and feedback. Will you question whether the specs you are given really will serve the purpose that the client has in mind?

Communication skills help with making meetings timely and effective. A professional's communication is effective and to the point, whether in person, in email, on the phone or in written documents.

Documentation at first seems like a programmer-specific concern until you consider how many people require documentation in a serious project: other programmers need high level, API level and in-code documentation; managers need planning, progress, and bug documentation; lawyers need proof of what was done and when; and users need documentation on how to use the software.

Updating Skills Keeping your skills up to date involves staying aware of what's going on in your industry. What are the current ideas about methodologies like eXtreme Programming? What libraries and tools are out there that might support your project? What are the current refactoring tools? How about standards, file formats and protocols? Are you up to date with Unicode, XML, SQL, and all the other acronyms? Perhaps you're missing out on something if you're not. What platforms are your potential clients using? Should you be learning about cross platform development?

Basically you need to possess a genuine interest in your field, and to read broadly so you know what's out there and which areas to then read deeply about. You also need to accept that even (or should I say "especially") the very best programmers are still learning.

Minimizing Risks Familiarity with best practices, combined with a healthy dose of common sense, will take you a long way towards managing risks. Professional programmers keep track of known bugs or any other change they intend to make. Bugs are risks, and a simple database can prevent you having a product ship with bugs you'd simply forgotten.

Another risk that's often not properly considered is any and all changes to the source code. Source is your livelihood and any change can be a mistake. There's good software out there that will keep track of every revision of your source code and even help merge code that multiple people have changed.

Professional programmers are careful to do enough testing. A software company will generally have testers but the developers need to know how to get the most out of testers and also how to write their own unit and regression tests to make sure every change in behavior is noticed and checked by a human.

Keeping your code simple and well styled is another commonly overlooked way to manage risks. If anyone can look at the code and see right away what it does, you are far less likely to find bugs in it later, and you are less likely to have a junior programmer attempt to change something without understanding it first.

Another risk is the client changing their mind, or more often changing their specifications because they've realized it wasn't what they had in mind. Write your code to be modular and reusable and you won't have any trouble adapting it to changing needs.

Accountability Writing code for others is a responsibility. You need to make sure your software is reliable. You need to make sure you and the client truly understand the requirements and specifications. You need to have documentation of your work, all current and past bugs, your progress, any problems, signed-off milestones, and more. You are also required to know about some basic legal issues, like software licensing, the terms of your employment contract, and intellectual property law.

* * *

As you can see, there is a huge gap between "coding" and "professional programming." Most programming courses focus on the coding side of things, and the professional skills tend to be glossed over or not covered at all. I have found myself regularly teaching these skills to new co-workers, which highlighted the need for "professionalism skills training." Teaching my co-workers reminded me how much I enjoy teaching. I decided to teach more people by trying my hand at professional writing for a change.

I set up a web site, which is completely independent from my day job. The site is called Developing Programmers.com. It is devoted to teaching people how to develop into professional programmers. Since founding the site, I've been presenting the tools and ideas that I think professionals should know about.

Some of my articles simply refer to other sites of benefit to would-be professionals. I research other articles from scratch: tutorials, guides, and discussions of things professionals should be thinking about, like revision control, documentation, keeping your group pointed in the same direction—and of course, each of the aspects of professionalism that I listed earlier.

These days I consider myself to be a professional programmer, though I am still discovering the depth and breadth of what exactly that means. Perhaps that ongoing exploration of programming and of professionalism is what makes this for me a career and not just a job.

http://sourceforge.net/projects/v2j/

 http://groups.google.com/group/google-talk-open/tree/browse_frm/month/2005-10/eddfd173d91c1475?rnum=51&_done=%2Fgroup%2Fgoogle-talk-open%2Fbrowse_frm%2Fmonth%2F2005-10%3F

http://ursine.ca/Ursine:Jabber

http://support.jabber.com/faqs/clientinfofaq/clientinfo.html

http://mail.jabber.org/pipermail/jdev/2001-August/008062.html

http://jabbercom.sourceforge.net/

Anh hùng không chết vì gươm đao mà chết vì bệnh … tiêu chảy.

Hồi học phổ thông, một thầy dạy lịch sử hay nói với bọn tôi như vậy. Hôm nọ xem TV, nghe bảo bọn ăn cướp/giết người học được rất nhiều mánh khóe của cảnh sát trên các phim truyền hình về điều tra hình sự (như CSI), cho nên chúng biết cách xóa dấu vết DNA bằng bleach, biết cách dọn dẹp tóc tai, dấu tay, … sau khi phạm pháp. Một anh chàng tội phạm xóa dấu vết rất sạch, nhưng sau đó bị bắt vì … dùng credit card của nạn nhân .

Nhiều system administrators yêu cầu users đổi password hàng tháng, chạy chương trình kiểm tra tính dễ đoán của password, vân vân, để rồi thấy users ghi luôn password vào một mảnh giấy be bé dán lên … màn hình máy tính. Thậm chí chính bọn sys admins cũng làm thế, vì secured passwords khó nhớ quá. Người dùng có khi còn đổi passwords lấy vài cây bút rẻ tiền.

\nTuần rồi bà con xôn xao về vụ CitiBank mất dữ liệu của cả mớ khách hàng, làm cho tất cả các transactions dùng số PIN (và thẻ ATM) đều bị cấm. Năm ngoái thì UPS chuyển dữ liệu của \n3.9 triệu khách hàng của CitiBank và UPS làm mất giữa đường (mớ dữ liệu này thì lại không mã hóa). Bọn nhà băng nghiên cứu rất kinh về việc áp dụng các phương thức bảo mật tối tân cho các transactions trên Net, để rồi mất một vài cái đĩa unencrypted.\n

\nChủ nhà sợ trộm vào cửa sổ quá, đầu tư cực nhiều tiền vào hệ thống báo động đặt trên cửa sổ, sau đó … quên khóa cửa chính \n . Các nhà làm bảo mật không thể bỏ qua yếu tố con người trong bảo mật. Social \nengieering vẫn là một trong các phương thức tấn công hệ thống hiệu quả nhất. (Xem thêm quyển \nThe Art of Deception: Controlling the Human Element of Security .)
\n--~--~---------~--~----~------------~-------~--~----~
\nBạn nhận được bài viết này do bạn là thành viên của nhóm "Blog Khoa Học Máy Tính".\r
Viết bài mới lên Blog K.H.M.T, xin vui lòng gửi nội dung bài đến: ",1] ); //--> .

Tuần rồi bà con xôn xao về vụ CitiBank mất dữ liệu của cả mớ khách hàng, làm cho tất cả các transactions dùng số PIN (và thẻ ATM) đều bị cấm. Năm ngoái thì UPS chuyển dữ liệu của 3.9 triệu khách hàng của CitiBank và UPS làm mất giữa đường (mớ dữ liệu này thì lại không mã hóa). Bọn nhà băng nghiên cứu rất kinh về việc áp dụng các phương thức bảo mật tối tân cho các transactions trên Net, để rồi mất một vài cái đĩa unencrypted.

Chủ nhà sợ trộm vào cửa sổ quá, đầu tư cực nhiều tiền vào hệ thống báo động đặt trên cửa sổ, sau đó … quên khóa cửa chính . Các nhà làm bảo mật không thể bỏ qua yếu tố con người trong bảo mật. Social engieering vẫn là một trong các phương thức tấn công hệ thống hiệu quả nhất. (Xem thêm quyển The Art of Deception: Controlling the Human Element of Security .)

Hiện trạng phổ biến của các website thế hệ 1.0 đó là chứa nhiều thứ phiền toái và làm việc chậm chạp, dường như luôn muốn gửi đến người dùng thông điệp: đây là website của chúng tôi chứ không phải của bạn. Căn nguyên của vấn đề có thể là do chủ sở hữu các website cảm thấy họ "cho không" cái gì đó. Đôi khi chủ sở hữu website cho rằng càng làm khó người dùng thì họ càng được lợi! Điển hình như một số site cho bạn đọc đoạn đầu của bài viết rồi yêu cầu bạn phải đăng ký (có phí hay không) để đọc nốt phần còn lại.

Dĩ nhiên, với sự phổ biến của các phần mềm máy chủ, trong đó có cả phần mềm miễn phí như Apache thì người dùng có thể đưa lên web bất kỳ thông tin gì. Tuy nhiên có nhiều yếu tố cản trở: kỹ năng tạo website, hạn chế của nhà cung cấp dịch vụ Internet, việc bảo mật và kiểm duyệt...

Không phải là viễn cảnh, Web 2.0 đã hiện hữu quanh chúng ta với hàng loạt website thế hệ mới. Xu hướng chuyển đổi sang Web 2.0 đang diễn ra mạnh mẽ và là xu thế tất yếu.

Theo pcworld.com.vn
Tham khảo:
• What is Web 2.0, OReilly
• Web 2.0, Wikipedia
• Web 2.0 Blog, web2.wsj.com