alert vs console.log is not the main problem

Facing Security
4 min readAug 23, 2014

--

I just started using browserify and I had (and still have) a problem using it. I produced a minimal test case. I tried my best to do my homework before asking help. Reached out on IRC hoping someone could jump in and help. By the way, browserify looks promising and helpful so kudos to the people who came up with the idea and maintain browserify.

Now, the chat did not go well. See these imgur screenshots. http://imgur.com/tR9nnpg,XnIv7ON,wgjdJyo

Why am I making a big deal out of this situation?

First, I asked him don’t get caught up on whether I should be using alert or console.log. It is not part of the problem, unless proved otherwise. As someone who does some client-side security testing occasionally, alert(…) is very common to me, more natural than using console.log. I know why alert is bad and why I should prefer console.*. I do use console.log A LOT in my other projects, however, It is not uncommon to use alert over console.log in a minimal test case. It is like asking a Python developer to use pdb over print() in true debugging but most people still find print() effective and useful (there are situations in which pdb is totally useless and inadequate though) and I am one of the 99% of the developers that use print() every day.

If browserify was to work, alert(…) would work too. You can’t run alert(…) from plain Node environment. It is not part of Javascript. So if browserify were to work, I should be able to see an alert pop-up. It is that simple. Whether it is a smart or a dumb rationale is subjective. Maybe console.log is sufficient, but it is not a reason to take the request personal and insult people on public IRC.

When someone reminds me that I am living in 2014 I can sense a religious war about to begin. I sit on many public IRC (#python, #javascript, #node.js, #ruby) often enough I know this kind of “FOR REAL?” attitude is not rare.

It is obvious that he took it personal as soon as he said “hf then” (have fun then), which upset me a lot. If you were to stay on a public channel, please respect yourself and respect others. I was glad someone jumped in on Saturday to help, honestly. But did I say anything actually offensive enough to cause this trouble? I doubt.

The IRC channel seems dead. Maybe someone is actually reading the chat between me and him and if that was the case, I would really hope this “someone” would jump in and do the right thing: be the middle man to put the unprofessional chat to a stop.

Public IRC channels like #python and #javascript are old enough that people can regulate themselves properly. It is true that in IRC there are jerks and helpers. Maybe he is not a jerk to others, but he is a jerk to me today, after asking NOT to argue about alert vs console.log.

What if instead I said “okay” and ignore his comment about alert vs console? Will the story turn out different? I will not know but one thing is sure: the bomb could go off any moment and you, the reader, could be the next person in line to witness the explosion.

Last bit: I was told to find answer on #javascript. That’s not always a good option. I would not ask Ansible question on #python just because Ansible happens to be a Python program. I might ask something related to infrastructure provision automation on #python if I need pointer to find out Farbic, Ansible and SaltStack. I do ask some Node and NPM related questions on #javascript, but I paid my respect for going to #browserify to ask question about browserify. So don’t ask me to leave because I will not get any more help from you or possibly from other users and developers on #browserify.

Also, going to vendor/software specific channel can usually yield better answer and can lead to unexpected new knowledge that is specific to the software you are using. For example I could sit on #ansible and see the automation challenge people are facing but you rarely find that kind of conversation on #python.

Lesson #1: Don’t assume people are stupid or ignorant of other technology. Suggest, explain and leave it unless the suggestion will help solve the actual problem. If you really want to help, try to focus on the main problem. If alert(…) is your pet peeve, please don’t show that until you have to (e.g. don’t use alert(…) to read an Object).

Lesson #2: If you run an open source project, you should spend time helping regulate the basic Code of Conduct.

Lesson #3: Stop using alert(...) even in security testing. Maybe the subtle blocking effect of alert(…) will make testing harder. Worth investigating.

Lesson #4: end the conversation and stop arguing on IRC. It makes me look bad too. As someone have suggested, use /ignore if necessary.

We’ve heard a lot of discrimination against minority, females and disabled developers in this industry. Now a simple conversation turning into a religious war is not acceptable. Suggest, explain and leave it.

In the end, I apologize if I also take this too personal, but I insist I do not deserve aggressive attitude for asking help and rejecting an advice in order to avoid conflict in the first place.

So what is the problem? It’s the way we criticize. I wish I could show you Brandon Rhose’s ending keynote (http://pygotham.org/talks/108) right now but the video is not up yet. It is the best talk ever about how to become a better critic. I also need to be a better critic. Conflict is bi-directional and I am also responsible for the conflict.

P.S. Releasing the actual conversation seems dangerous and unprofessional to some, but if you dare to stay on public IRC, there is no secrecy. Who should I go to first? substack? I think I am going to make myself look bad in the community, but I have to get this out of my chest.

Unlisted

--

--