As a young boy, whenever I asked for the definition of something I was told to “look it up”. I hated that answer! It seemed so futile: if the task was to get something done and you knew the answer, why should I look it up?

It is clear to me now that I was told to look it up as a young boy to get me into the habit of being independent, of being able to fend for myself, and probably more importantly, not bothering busy people when the answer was available elsewhere.

In fact, that response has ended with me:

Learning to read by looking up words in the dictionary.

Learning to juggle by dropping lots of balls.

Reading El Quijote in Spanish the same way I learned how to read.

Learning to connect to the Oxford English Dictionary hosted at the University of Illinois Urbana-Champagne from home via a 2400 baud modem and a connection to the dial-up lines at UIC-Chicago the same way I learned how to read (and by bothering more than one techie…).

Along the way I also learned:

• how to use PowerPoint (via Aldus Persuasion, which in my opinion was infinitely more powerful)
• how to write HTML
• how to write JavaScript
• how to program in Perl, PHP, XSLT, ASP, JSP, JavaScript, AppleScript, Java, .Net, Fusebox, VBA, C, C++, Bash, SQL (Server), HyperCard, Director, Authorware, MS Office Macros, Photoshop Actions, Flash (yes, I even learned how to program in Flash), and more that I’m forgetting…

And remember, I started out not knowing how to read.

I guess my teachers weren’t so dumb after all.

And the next time you consider asking someone you know for the answer to a question just as easily answered by Google, consider looking it up first. Just look where it might lead you!

Based on these instructions on how to compile mod dav svn, I managed to get our old Red Hat server serving our public subversion repository.

I’m a little surprised by how little documentation there is on how to do this considering it is such a great way to make a code repository available to authorized users. I was unable to find any clear information on how to do this on subversion.tigris.org or on apache.org.

So, how do I know what name to use with the Apache configuration option –enable-MOD_NAME? The configure option –enable-mods-shared=all is a nice shortcut, but not very realistic in a real hosting environment. I’ve read in several places that you should only enable the modules you are really going to use and enabling all just seems like a bad idea. Can anyone help?

WARNING: major rant!

I understand why some people like the term “web 2.0” and its ilk. The problem is it leads people with little or no idea of the web to believe it is a product produced by a single organization and that it will have incremental “releases” when it is the exact opposite and evolves daily.

Furthermore, the concepts the term tries to define have been around since the beginning of computer mediated communication, so they’re not new, just redefined, and thus lead to additional confusion among novice web users. Fundamentals of usability state quite clearly that we should call things by their names, not invent new ones to sound cool, or just new. The only people who find value in marketing terms are marketers. The rest of us experience such terms as garbage and filter them out.
Also, since this is not a product produced by a single organization, the use of the numbers leads me to wonder where will the numbering stop?

If you are a web developer or work in the internet field, please, I beg you, don’t use “web 2.0, 3.0, 4.0” etc. when trying to define what you are doing. There are plenty of other techno-bable terms that probably suit your needs just as well that already exist. In my opinion, using such terms just makes you sound uninformed.

I feel a little better now that I got that off my chest…

PS: The link to the other techno-bable terms was the by product of the first Internet bubble. It shouldn’t surprise anyone that these terms continue to show up in today’s “web 2.0” world. Empty language = noise. Let’s try improving the signal-to-noise ratio and minimize the interference. My job is already hard enough.

Esta semana pasada publicamos nuestro proceso de desarrollo de aplicaciones web (en inglés y en español). Si te dedicas al desarrollo web, merece la pena leerlo, no es muy largo y te puede ser de mucha ayuda.

Por cierto, ¿hay gente que lee este blog regularmente? Me gustaría saber si es que sí, cuáles contenidos te han interesado hasta ahora.

Following the instructions for “shelving” work in progress using Subversion, I tried to merge my work back onto the trunk, but kept getting the following “error” messages:

“Skipped ‘path/to/file/on/shelf/but/not/in/trunk'”

I read and re-read the Subversion documentation for merging and it made it sound like I was doing something wrong. I finally found a posting with instructions on how to merge in spite of the “Skipped” error message… so I tried it, and it worked (in spite of the misleading messages). The trick really is to ignore the messages.

Note that following the merge, files that are in the source branch and not in the destination branch need to be svn added before they will end up in the destination.

I sincerely hope this post helps others save the two or three hours I lost trying to figure out what I was doing wrong!

This just a quick post about a great article on how to “shelve” a project with local changes so you can work on something else without sending the changes to the trunk.

For those of you wondering what I’m talking about, when we write software, we use systems that allow us to undo changes on hundreds of files at a time. This can be very useful when, in the middle of adding new features, you need to fix a security vulnerability but you don’t want to lose the work you’ve already done.

If you were building a house and had already laid the foundation, built the frame, ran the electric and plumbing, put up the drywall, and then realized you forgot the insullation between the foundation and the frame, it would be a small disaster.

Shelving code allows us to lift the entire house up off the ground so that we can put in the insullation, and then return the house to its rightful place without losing our work.

Techniques such as this allow us to be very productive programmers.

El desarrollo web en equipo es cada vez más una realidad inevitable. Fusebox, y el FLiP facilitan tanto la organización del proyecto como la comunicación con el cliente. Aquí tienen una introducción a Fusebox.