As frequent readers know, I'm very interested in communication and social interaction. One of my unspoken rules is that you must respond to received communications in the medium in which it was sent or else a medium higher up in the communication hierarchy. What is the communication hierarchy, you may ask? Well, here it is:
Basically, it works like this. If someone calls you up and leaves a message (#2), you should respond either by calling them back (#2) or if you run into them, by mentioning it in person (#1). You should not respond to a phone call by sending an email because you're moving down the communication hierarchy. If you made plans with someone by phone (#2), then you should cancel by phone if necessary; cancelling by text message (#3) is rude.
The idea behind this is simple: the further down the hierarchy you go, the less personal the communication is and the more difficult it is to sustain a meaningful conversation. Text messages are good for sending quick notes but not for having conversations. I can't stand when someone sends me a text message that says, "hey". That's something you say in person to start a conversation, it doesn't work as a text message.
The more important the topic or the longer the conversation must be, the closer to the top of the hierarchy you need to go in order to eliminate misunderstandings. This means that most important decisions need to take place either over the phone or in person. On some level, you already know this. You'd certainly not feel comfortable if you called your doctor and he/she told you to report for surgery the next day without seeing you in person first. And anyone who's ever been dumped by email or IM knows that breakups, as painful as they may be, should be done in person.
I'm probably a rarity, as I prefer to do as much communication as possible in person. I'm more apt to yell over the wall at work than I am to send an IM to that same person, and I'd much rather interview someone in person than over the phone. I hate text messaging and I think people overuse it. I'm also not a huge fan of the phone except when face-to-face isn't possible, as is the case with my family on the east coast.
So as you're communicating, mind the hierarchy and you're likely to have more successful and meaningful communications in the future.
From time to time, I get kind of down about the state of the world. It seems like there's less compassion and consideration than yesterday with more and more people becoming increasingly self-centered. The news tends to celebrate individual accomplishments and leads with tragedies, while true acts of compassion are relegated to "in other news" sections of newspapers. This morning, I caught a story on SportsCenter that went a long way towards restoring my faith in humanity.
During a college softball game between Western Oregon and Central Washington, Western Oregon senior Sara Tucholsky hit her first-ever home run. The two teams were separated by a single game with the chance of going to the NCAA tournament on the line. It seemed like a perfect story for Tucholsky, but that story took a dramatic turn as she rounded first base. She missed tagging the base and then doubled back to touch it. In doing so, she tore her ACL and fell to the ground unable to get up under her own power. The other base runners had already tagged home and were back in the dugout. A little known fact: a home run is not an automatic run, you must touch all bases for it to count. She could have stayed at first base and been replaced by a pinch runner, but that would have counted only as a single.
No other offensive players are allowed to come onto the field; once they do, the play is dead and she is called out. Central Washington's Mallory Holtman, the division II owner of multiple softball offense records, realized that she could help Tucholsky without penalty. As she said, she knew Tucholsky from playing with her and knew how important a home run for a senior is. She and teammate Liz Wallace picked up Tucholsky and brought her to each base, making the home run official.
This is perhaps one of the most selfless acts that I've ever seen in sports. Being members of the opposing team and knowing that they would be down by 3 runs instead of 2, these two girls went above doing what was right: they redefined what right meant. For most people, right would have been to replace Tucholsky at first base with a pinch runner and say, "that's too bad, she's a gutsy kid." One could argue that that's exactly what would mappen in Major League Baseball or even men's college baseball. Is it that women really are just more caring and considerate? I don't think so; I think that these particular girls were more caring and considerate than most people regardless of gender.
The biggest shame about all of this is that the story was buried almost as quickly as it was reported. I searched for a good 10 minutes online to find a decent account of what actually happened. It wasn't on the front page of any major sports site. This is something that should be celebrated and talked about as often as possible. Kids should hear about this story and understand that this is what we call sportsmanship. Anyone who's ever played a sport should look inside themselves and ask if they would've done the same thing. And everyone should feel better that people like these girls exist.
When Internet Explorer 8 introduced the XDomainRequest object, I was really excited because I had just read John's post about cross-domain XHR in Firefox 3. Great, I thought to myself, the top two browsers now support cross-domain requests...we're finally getting somewhere.
This weekend I was digging in a little more when I found the Firefox cross-domain XHR documentation. A note at the top now boldly states that this feature is enabled only for privileged scripts and extension developers. While this feature was included in Firefox 3 betas at least through 3 (I missed 4), in beta 5 this feature has been removed for web content.
I must say that I'm pretty disappointed in this. Digging through some of the documentation and discussions surrounding the implementation, I'm hoping that everyone can rationalize how this should work in Firefox so it can be brought back. I was never a huge fan of overloading the XHR object to do this because it seems like there are just too many differences and security issues you'd have to lock down. IE's approach, making a completely different object, makes a lot of sense to me and quite logically locks down functionality that otherwise would be part of an if statement in the XHR code.
I do think it's a shame that the removal of cross-site XHR in Firefox 3 wasn't more widely publicized. It's inclusion was announced and featured on blogs everywhere; one would think it's removal would also garner such attention.
Just thought I'd share a quick tip. I'm one of the few developers I know who uses Windows almost exclusively (sorry, no Mac here). Lately, I've been wanting to see how my JavaScript files would be compressed using Julien's YUI Compressor. Previously, I was keeping a command window open and typing the command in directly. I figured there must be a simpler way to do this, and I was right.
The first step is download the YUI Compressor and put it somewhere handy. I put it directly in the c:\ directory for easy access. Then, I created a simple batch file called compress.bat and also placed it in c:\ for each access. The content of the batch file are as follows:
java -jar c:\yuicompressor-2.1.2.jar %1
This line essentially runs the YUI Compressor against a file that is specified as the first command-line argument (%1). You can now simply type the following into a command window:
c:\>compress.bat myfile.js
To take this one step further, you can add a "Compress" context menu item. To do so, follow these steps:
Once that is done, you can right-click on any file ending with a .js extension and see a context menu item called "Compress". When clicked, the command runs the YUI Compressor and the output is placed in the same directory.
I've found this to be a very handy way to use the YUI Compressor. I hope it's equally as useful for you.
A little while ago, Doug Crockford wrote a blog entry where he proclaimed that web development was broken. His example was the suggestion that browsers implement a strict mode that would give informative errors. The assertion was that this type of validation was being done at the wrong end of the network, that code should be validated before being sent to the user. His main point was that validation should be done by developers so users don't have to worry about it. No argument there.
After a recent conversation with Chris Heilmann, I got to thinking about Crockford's assertion again. In traditional software engineering, you write some code, compile it, and test it (running it). You do this frequently before the final compiled output is delivered to the user. The compiler catches syntax and data type errors such that your program won't compile if even one exists. This is excellent feedback for developers and a lot of bugs never make it to production because of this.
Web development is interesting in that the browser acts like a compiler to developers and acts like an operating system to users. Our mode of operation is to write some code, load it into a browser, and test it. Users, on the other hand, fire up a web browser and navigate to a page. In effect, the browser is serving two different needs to two different audiences. It does one of these jobs very well; the other, not so much.
Browsers are optimized for the viewing experience, plain and simple. All kinds of errors are silently ignored or worked around as a page is being loaded. The browser will never tell you about a syntax error in your HTML or CSS (we lucked out and at least get notice of JavaScript errors). I'm not saying that browsers shouldn't do this, mind you. Browsers are necessarily targeted at users as their as far more of them than there are of us. But since browsers really do two jobs, can't we have it do both well?
What I'd like to see all browser vendors implement is a debug mode for browsers. This could be a setting buried deep in the browser options or a config file change...it doesn't matter how it's enabled. The end result is that the browser should tell you whenever a parsing error occurs in HTML or CSS. This would mean not failing over and trying to do the right thing, but exploding with a message that says why your code is incorrect. Right now, there's a lot of theorizing around what breaks parsers - this debug mode would answer those questions forever. Does an extra slash before the closing greater-than symbol really give the parser fits? How about non-escaped quotation marks inside of text nodes? Seriously, how many hours have you wasted trying to track down some obscure HTML or CSS syntax error that was causing layout issues?
I think Crockford is wrong about the location of validation. Since the browser acts as the compiler for us, we need it to tell us when it's unhappy. These errors should be supressed when the browser is in normal viewing mode so as not to disturb or confuse the user. When in debug mode, however, the gloves should come off and all manner of parsing errors should be exposed to the developer. It really shouldn't be that hard to implement and the payoff for developers would be huge.
The global object in JavaScript is vitally important: all global variables and functions become properties fo the global object. In browsers. the window object doubles as the global object, and most developers use it as such without even realizing. In other JavaScript environments, however, the global object is something else. Most of the time, it's not assigned to a global variable for you to access.
If you code is to run in non-browser JavaScript environments, you'd better avoid using window for dealing with globals. However, referencing the global object can be necessary. To that end, I present the getGlobal() function, which works in any JavaScript environment and always returns the global object:
function getGlobal(){
return (function(){
return this;
}).call(null);
}
The key to this function is that the this object always points to the global object anytime you are using call() or apply() and pass in null as the first argument. Since a null scope is not valid, the interpreter inserts the global object. The function uses an inner function to assure that the scope is always correct. You can then use this function as follows:
var global = getGlobal();
And I suggest you do this whenever writing JavaScript that should be executable in non-browser environments. Enjoy.
I've come to realize lately that for some reason or another, most people think the only book I've written is Professional Ajax. Perhaps it's because that's the book I feature prominently on my home page or because the buzz around Ajax was so great that people bought that book before they even knew I had another. In fact, I think the story of how Professional JavaScript came into being is much more interesting.
It really began when the company I was working at shut down, leaving me with a lot of free time on my hands. I started giving myself small projects to keep my mind sharp and quickly discovered that I was doing really complicated things that I feared I wouldn't be able to remember later on. So, I started writing down exactly what I was doing and posted it to my fledgling web site. A former colleague read one and suggested I submit some work to coding magazines. I did exactly that and fairly rapidly I had articles up on major web development sites.
One of the sites I used to write for frequently was WebReference. I also was an avid reader of the site and happened upon an article explaining how one the other article writers had pooled her articles into a book that would be published soon. A light bulb went off on my head. A book is just a series of articles? Hell, I can do that.
I was stuck in a dead end job with lots of free time and a lack of creative avenues to keep my mind stimulated, so writing became my refuge. I'd run home after work and spend 2-3 hours writing. I had no idea what this book would be or what the topics would include, so I just resolved to write whatever came to my mind. And a lot came to my mind. Enough that I was writing every day after work and all day Saturday and Sunday. My mom would ask me every day (literally), "what are you doing on that computer?" And every day I'd answer, "I'm writing my book." She would chuckle like one would when a five year old says he wants to be a fireman.
As I continued to learn about JavaScript, I came to realize that I had gone farther than any book could teach me. I kept buying more books hoping to learn new tricks, but I ultimately found that the books available weren't even covering what I was doing. Then the idea for my book solidified: I want this to be a book that is targeted at professional software engineers. I'll skip over the swapping out images techniques and how to create jigsaw puzzles and family trees. Instead, I'll focus on actual programming techniques and things will need to do as professional web developers.
Keep in mind that interest in JavaScript at this time was flat. This was years before Ajax popped up and people were fighting to get basic functionality working in Internet Explorer 4 and Netscape Communicator 4. Most of the books on JavaScript had been out for several years and there didn't seem to be a need for any new books. But my opinion was that the market didn't provide was developers actually needed. It was a perfect time to introduce a new book.
I put together a proposal and sent it off to a couple of publishers. The first publisher I contacted was Sitepoint. I had written several articles for them and they didn't have any JavaScript books at the time, so I thought it would be a great fit. Unfortunately, they thought differently. I was told that my proposal didn't make sense, that they didn't see why anyone would want to buy this book, and that my writing style was lousy. I politely responded with a thank you and asked if they had any advice for things I could work on. I got no response.
My next stop was a new company called APress. They also didn't have any JavaScript books, so I thought I'd have a shot. My proposal was accepted and someone began reviewing it. After waiting for months without hearing back, I followed up to find that the editor who had been assigned my proposal had left the company. I found another contact, the person who would have been his boss, and he assigned me to someone else. After several more months of email tag, I was finally told that APress didn't want to get into the JavaScript book business because it's already being dominated. I wrote a note back and thanked him for his time and input. The next day I got an email back saying that he, personally, believed that a book like this could do quite well with a bigger publisher who could take the risk of going head-to-head with Flanagan's book. He then suggested that I contact Jim Minatel over at Wrox to see if he'd be interested. He said a big company like Wrox would have a better chance at publishing my book than a small one like APress (yes, APress has a ton of JavaScript books now - apparently their fear of the JavaScript book market subsided with the rise of Ajax).
So, I contacted Jim and introduced myself. I explained what I'd gone through so far and that I had a proposal for a book on JavaScript that I believed would change the market. As luck would have it, Jim was looking for someone to rewrite the Wrox classic Professional JavaScript. We had several discussions about his vision and my vision and worked together to come up with a proposal that we both felt comfortable with. And Professional JavaScript for Web Developers was born.
All in all, it took close to three years between the time I first started writing until the book was finally published. The result? Professional JavaScript was the most up-to-date JavaScript book available for about a year and people really took to it. Since it first came out in 2005, Professional JavaScript has sold the second-most copies of any professional guide covering the entire JavaScript language (this excludes the For Dummies and Visual Quickstart beginning guides as well as the DOM-specific DOM Scripting), behind Flanagan's legendary tome. It's also been translated into numerous languages including Chinese, Spanish, French, and Polish. Beyond sales and translations, the book has helped me in other ways, such as getting me out of the miserable I had when I started writing it and ultimately getting my foot in the door at Yahoo!.
There's two things I really hope that everyone gets out of this story. First, be persistent in the pursuit of your dreams. Just because you fail a couple of times doesn't mean you're ultimately going to fall short. Don't be deterred by people who don't share your vision. Second, never forget to say thank you, even to the people who stand in the way of your dream. If I hadn't written back to say thank you to the APress editor, I never would have been put in contact with Jim and Professional JavaScript may have ended up with another author.
Continuing on my comedy tour of California, I saw Chris Rock tonight in Oakland. This time I was only a third wheel, so the comfort level was higher. Opening for the night was Mario Joyner, who I've seen at various times during my life...I actually couldn't believe he was still around and doing comedy.
Now, I've been a fan of Chris Rock for a while. I still think he's had the best opening monologues of anyone that's ever been on Saturday Night Live. I'm not sure what I expected from this show but I felt a bit let down. He was funny, though I found myself chuckling more than falling out of my seat with laughter.
Perhaps more interesting were the characters sitting around us. The guy to the right of me was quite odd. I don't think he even smiled the entire night. Most of the time, he sat with a death gaze on the stage, hands tightly gripped between his knees. I half expected him to pull out a knife or gun at any minute and take a hostage. I was going through in my head what could make someone go to a comedy show when they were so miserable. Maybe he'd just broken up with his girlfriend but didn't want to miss the show? No, he just had one seat. In any event, I felt a little uncomfortable sitting next to him and was happy when the show was over without incident.
That guy was in stark contrast to the guys behind us, who would start laughing at every joke before the punchline even got there. I couldn't decide if I thought they were high or drunk or both, but they laughed so loud and so often that you'd think they were saving up for this event to let it all out. Shelby and Court actually had to lean forward to protect their ears from the ferocious laughter assault.
Chris Rock, as usual, made some good points about politics and life. My favorite line from the night was, "George W. Bush messed up so bad that he made it hard for white men to run for president." The show was mostly made up of your typical comedy faire: sex, racism, and politics. Still, I was amazed as he talked for nearly two hours straight without a pause and without even having a drink onstage. I have a hard time speaking after about 15 minutes without having some water nearby, but two hours? Crazy. We definitely got our money's worth.
Not too long ago, I was interviewed by Jennifer deJong of Software Development Times about Ajax, its use and misuse. We had a great conversation about Ajax's early missteps and how things have evolved in the past couple of years. One of the main points I wanted to be clear on, as I try to be whenever possible, is that Ajax is not a feature. You should never be saying, "how can we use Ajax?" You should be designing the best user experience possible and if Ajax helps with that goal, then use it.
My thoughts, along with a host of other industry experts, are summarized and tied together nicely in Jennifer's article, All Sizzle and No Substance?. There's a lot of good perspectives on Ajax pain points as well as what to do and avoid.
At the end of the movie, Matrix Revolutions, Agent Smith stands above a beaten Neo and wonders aloud why his adversary continues to get up just to be beaten down:
Why, Mr. Anderson? Why do you do it? Why get up? Why keep fighting? Do you believe you're fighting for something? For more that your survival? Can you tell me what it is? Do you even know? Is it freedom? Or truth? Perhaps peace? Yes? No? Could it be for love? Illusions, Mr. Anderson. Vagaries of perception. The temporary constructs of a feeble human intellect trying desperately to justify an existence that is without meaning or purpose. And all of them as artificial as the Matrix itself, although only a human mind could invent something as insipid as love. You must be able to see it, Mr. Anderson. You must know it by now. You can't win. It's pointless to keep fighting. Why, Mr. Anderson? Why? Why do you persist?
I think it's a question that we all try to answer and, at times, struggle with. Why do we get up? When we've experienced a setback, a major health issue, a catastrophic loss, what is it that makes up get up? What is it that makes us push through?
Referees in professional fights are there not just to enforce the rules, but also to protect the fighters from themselves. Many boxers and mixed martial artists don't know enough to give up even when it's apparent that they can't win. It's at that point that the referee steps in and stops the fight. For some reason, the fighters just keep bouncing back up no matter how much they've been beaten. Bloodied, battered, and bruised, they attempt to get to their feet with all their might. Why?
Do we even know why we get up? Is it just instinct? Is it inertia? Maybe we get up because we've done it before and don't realize that staying down is an actual option. Do we just pop back up automatically without thought? Is it a conscious decision?
If it is a conscious decision, what is the rationale? Do you believe that things will be better if you get up again? What leads you to that decision when you know, from past experience, just how wrong things can go? And if this isn't the first time you've gotten back up, why doesn't the thought of getting knocked down again stop you?
Of course, not everyone gets up after being knocked down. We label these people as having psychological disorders because it is considered "normal" to get up when you're knocked down. If someone can't do this, they're seen as deficient in some way. There's even a theory called learned helplessness that seeks to explain why people (and animals) stop trying to improve their situation after they've failed. Not everyone falls into this category, however.
What about 13 year old Bethany Hamilton whose arm was torn off by a shark while surfing? That girl was back in the water as soon as she could be. Cleary, she decided to get back up. Not only did she get back up, but she went right back to the thing that knocked her down in the first place. This may seem like an extreme example, but there are many, many more stories like this.
So do we know why we get up? Do we do it out of fear of staying down? Or maybe it's because we'll be letting someone else down by giving up, a family, a lover, a friend? Is it a sense of responsibility to someone or something that ultimately makes us get back up? We're constantly being encouraged by our leaders to never give up. In the words of Martin Luther King, Jr.:
If you can't fly, then run.
If you can't run, then walk.
If you can't walk, then crawl.
But whatever you do, keep moving.
The idea of perseverance seems to be one of the most basic precepts of humanity. Maybe it's our DNA that makes us feel like we can't give up. Maybe it's part of our soul that drives us towards something more. Or maybe it's fear. If you're afraid of being down, then your only choice is to get up. Maybe you get up because you have hope, and that alone is a good enough reason.
I don't have the answer to this question, and I suspect that it's different for everyone. Ultimately, perhaps the reason why we get up is summed up in Neo's response to Agent Smith's question: "Because I choose to."