Social Media without Attention Incentives

I was watching the first episode of Black Mirror season 3 couple of nights ago titled ‘Nosedive’. Don’t worry, I’m not gonna give any spoilers. But it’s about a world where ranking on social media determines social status. There’s a score associated with everyone.

Guess what? we’re somewhat already there. On Twitter, how we deal with popular tweets/people is different from anyone else. Every person has a number next to their name to indicate their popularity and, indirectly, their worth. Every tweet has numbers next to it indicating its worth: favorites, retweets, replies.
You’re notified when people like and retweet what you say. It’s a small hit of dopamine to make you happy for a moment.
But you end up getting addicted. You change what you say (even just slightly) to get more likes and more retweets. You make sure to mention and reply to popular people to get their attention, and have them retweet your tweet hoping it’ll go viral.
I know this, because I do this.
There’s a quote from the show:

I’m just gonna play the numbers game, that’s how the world works.

But, I don’t want to do this anymore. No more numbers.
I wrote a userstyle that hides all the attention numbers from Twitter. Tweets will no longer have retweet/likes/reply counts.

Profile pages will no longer show tweet/likes/media counts.

Notifications page will no longer tell that you’ve been retweeted, liked, or other attention activities. Only replies will show up.
Removing this attention incentive will hopefully make us saner, and only seek meaningful interactions. If you like something, say something nice. If I write something, I’m hoping it’s to be right, not to be popular.
I named the userstyle ‘no-attention’. To install it, use Stylish for Firefox or Stylish for Chrome, then install the style. Addons for other browsers and more info available on userstyles home page.
I hope you find this useful. If you do, pass it on to your friends.

Preparing for a Talk

I’ve just finished watching Troy Hunt’s video on how he prepares for speaking at conferences. I was happy to see that he does dry runs in the same manner that I do; pacing at the living room, talking to empty space while imagining everyone is there, listening, some bored, and some paying attention.
Troy is an excellent speaker, plus being an security expert. Watch his talk at NDC Oslo that he was preparing for in the video above.

While I share much of what Troy does in preparation, I wanted to share a bit more on what I do differently. While some people are gifted at facing a big room with large audience, I’m not sure that I’m. I still feel terrible before I go on stage. Maybe it’s because I don’t do it that often, I’m not a speaker, I just do talks sometimes. Usually, it’s once or twice a year at most.

To help me calm down, and avoid surprises, I try to plan out as much as I can. So I start with an outline of my talk, then break them down into sections and bullet points, then expand each point into a paragraph or two. Each paragraph/point is accompanied by a slide which are made at the very end of the process. While most people start with making slides, I start with speaker notes first. I write an article and turn it into a talk. The downside to this is that it can be more work, and take longer to prepare, but by now, I did this enough to overcome this problem.

Knowing exactly what I want to say helps make things predictable. I know how this slide will go, and how it’ll lead to the next slide. I know what is the one sentence to describe this slide. I know how the content of the slide relates to what I want to say. I know where my jokes are, and that there’s enough of them, and not too many. More importantly, I know long I’ll take on stage, and that no side points will derail the whole thing into 15 minutes more than I have allocated.

Writing out the text of my talk means that I have to memorize what I’m gonna say. I don’t have a very good memory, but memorizing helps test how good my talk is. If I can’t remember what I want to say at a certain slide, then there’s usually something wrong with the flow of my talk, and it needs changing.

A problem for this approach is that delivering pre-prepared text can be difficult, it’s like reading from a teleprompter, you have to train yourself to seem natural at saying things that you’ve thought of a month ago, and make it seem like you’re just talking normally. The trick here is to understand that you’re writing words to be spoken, and not words to be read. You need to include pauses, voice inflation, speeding up and slowing down, passion (anger, happy, surprise, etc) in your text and not just in your delivery. The more talk-like your text is, the more natural it’ll sound to speak it. Of course, this can’t be done on the first time, but enough dry runs will do that.

This can seem like a lot, but it really helps me overcome being nervous and not being quick on my feet. It also, as I mentioned, helps me be on time. Last month, I gave a 90-minutes talk in 90 minutes. The margin of error on a talk this long can be big, but planning and trials helps. However, I’m still surprised it turned out so well.

One tip regarding time is to plan for some sections to be dropped off without breaking your flow. There are presentation software that helps you have optional slides that you can skip with the audience noticing. But the big burden is to plan your talk so that you can do this skipping with breaking down later sections that might rely on something you skipped.

One big benefit of this approach is, sometimes I lose my train of though during the talk or be not sure of the exact wording, and having to fall back to the text helps me calm down and carry on. It’s strange to be reading from the stage, but for that one slide I needed to get the wording exactly right. With a font large enough for the speaker notes, I can step away from the monitor while being able to read off the monitor. I have to keep looking at the audience between each sentence and the next, and make sure that I use the right pace; a talking pace and not a reading pace. It can be a tough moment, but it’s better than freaking out and trying to figure out where you are in the story.

Sadly, there’s no recording of my talk from last month. But I’m working on recording the audio for it to go along with the slides. It should be easy enough given that I have a full transcript of what I said. This is another big benefit of this approach. Try it sometime and let me know how it goes. Or, maybe you have an approach you prefer and you’d like to share.

How to Use IPFS to Fix NPM

Last night and this morning, everyone is talking about how one developer took down big number of large JavaScript projects by removing his modules from NPM.
People always talk about how NPM is a single point of failure. “boy, if NPM is gone, we’ll be in big trouble”. Usually the concern is about NPM having problems, or NPM (the company) going evil. We don’t usually think about one package disappearing like what happened yesterday.

There’s a lot to be said about what happened, and decry the irony of Open Source depending on one company. But, I’m not gonna talk about this. Let’s move directly to one possible solution.

One solution is to use IPFS to refer to packages instead of file names and URLs that point to a location.
IPFS (InterPlanetary File System, a not-great name by the admission of its creator) is a proposed distribution protocol for addressing content (creating URLs) that points to content using their signature rather than their location. The signature (the file name) is unique and depends on the content.
Once a package is created, it gets uploaded to any site, and people can copy it.
If you ask the network for a certain signature, it’ll get you that file from wherever is closer to you. It uses a distributed hash table (DHT) to find where to find the content.
Content can still be referred to using a human-friendly name using IPNS (a DNS for IPFS) and (later) Namecoin.
Neocities (the CMS/blog hosting services) is already working to add IPFS support. By the way, this last link is an IPFS link. So, an implementation is already out there and can be tested.
This way, if you decide to put out a release of a package, you don’t have to maintain its hosting forever. As long as someone else is hosting a copy, people will get it. As long as someone has a copy of the file, they can re-upload it (offer it on the network) and it’ll be offered using the same name.
If you decide to remove your code repository, you aren’t breaking anyone’s code.
This way, people decide to put their content online package by package and release by release. You can’t go back and remove old stuff you already released.

awesome-ipfs has some great resources.
Here’s a good talk on the motivations and ideas for IPFS

Update: Last December, David Dias did a demo on one way IPFS could be used to mirror NPM. Here’s a video of the talk, and his blog post on the topic.

Customize Windows Cmder Prompt

Update (Nov. 26, 2016): Cmder 1.3 changed how customizations work. This change was for the better, it’s simpler to apply this customization, you only need to drop in one file in the config folder. I’ve posted the code as cmder-powerline-prompt

I’m finding myself spending more and more time in the command line. But I use Windows, which isn’t very clever in the command line. It doesn’t have Linux OhMyZsh, but it has Cmder, which I like a lot.
Cmder comes with Git integration. It shows the Git status of current folder. Install it from Chocolatey.

What Cmder lacks (as far as I know) is customization packages you can download and install easily.

I was watching a video on YouTube when the speaker showed his Shell, and I wondered if I can get the same prompt on Cmder.

Cmder uses an init.bat file to set the prompt. It customizes Git using a git.lua file.
The shell in the video seems to be done using powerline or something similar.

After lots of poking around, I managed to get the same look in Cmder. Here’s what I’ve done:
CAUTION: Please backup your settings before making any changes. These changes work on my machine, not sure how it will affect yours.

• Download the powerline fonts, they include the arrow ending and branch symbols. You can use the powershell script included in the downloaded zip file to quickly install those fonts. I used the Anonymice Powerline font with bold and monospace settings.
• In Cmder main settings, make sure to choose Font Charset as ANSI.
• In the settings, under Startup > Tasks, pick up where your init.bat is saved. Open the file and replace it with the content of the init.bat.
• The important changes in init.bat is line 12 where the prompt is modified.
  @prompt $E[37;44m$P$S{git}$_$E[34;40m{lamb}$S$E[0m
  This line sets the prompt’s font color and background color. Here’s a list of all colors. I’ve avoided using text attributes to make sure that font color and background colors will match.
• Find where Cmder is installed, you should find a config folder there.
• In the config folder, there’s a git.lua file. We’ll replace this with this git.lua file.
• This file adds the Git status to the command prompt if the folder contains a git repo.
• The changes I’ve made include changing colors, and adding arrow ending and branch symbols.
• You’ll notice that some characters aren’t readable in the gist (lines 30, 31, 40, 44 and 51). Those are characters that are only included in the powerline fonts. The picture below (from here) shows the symbols and their unicode number.

The two symbols I’m using are the right arrow for line ending with unicode E0B0 and branch with unicode E0A0.
If you copy the snippets from the gist and those symbols aren’t copied correctly. Go to Windows Character Map and find them using the unicode under the Anonymice Powerline font and copy and paste them in Notepad++ (or any application that will preserve the character).
Open Cmder and enjoy the new shell.
If you have any cool customizations for Cmder, please share them in the comments.

Proxy Goals and Actual Goals

My longest streak on GitHub is 129 days. I was aiming for 200 days during a time when I wanted to have measurement for my commitment to learning more stuff, and doing more side work.
One day I came back from work around 8pm really tired. So, I decided to lay on the bed before jumping into my afternoon routine. I woke up 45 mins after midnight, missing the deadline for my daily contribution. I won’t say that I almost cried for breaking my long streak, but missing the daily deadline was the first thing that came to my mind when I looked at the time.
I was very upset, and started searching online for something I heard about git’s ability to re-write history or something, maybe I can trick GitHub. Couldn’t find anything and went back to sleep.
The next day, I was still upset till the evening when it came time for my daily deadline. I noticed that I wasn’t stressed like I was the past few weeks.
See, at the start, I had lots of things to contribute. I was building this blog, and it was a lot of work and fun. Then there wasn’t much stuff to do, but I had a goal to achieve. Coming up with things to do was getting hard. Things that had to be small enough that I can do in a day. No, I can’t stop and learn something. Reading or watching a tutorial wasn’t gonna help keep my streak.
Somewhere along the line, I lost sight of my actual goal of learning more stuff, and doing more side work, and moved to a proxy-goal (not sure if that’s a word) of keeping a contribution streak on GitHub. I think of a proxy-goal as a measurable goal that you use to indicate whether or not you’re achieving your goal. The proxy-goal became the actual goal, and when the two were at odds, I chose the proxy-goal instead. In the last couple of weeks of my streak, I would do small tiny changes 15 mins before midnight to keep my streak going.
It’s helpful to have a metric of how well you’re doing, and how you’re progressing toward your goal, but it’s important to keep that metric in perspective. When it’s at odds with your actual goal, make sure to choose your actual goal.
This doesn’t apply only for GitHub contributions. Think of the proxy-goals that are replacing actual goals in your daily life.

Scott Hanselman started a conversation on his blog about GitHub activity guilt and this was my comment on the topic.

Fix Jekyll Case Sensitive URLs On GitHub Pages

I like to capitalize the first letters in names that doesn’t allow for spaces. It makes it easier to read.
Consider this name ‘fixjekyllcasesensitiveurlsongithubpages’ compared to this ‘FixJekyllCaseSensitiveUrlsOnGitHubPages’. The first is just a long string of characters while the second is easily readable text even without spaces.
This is why I like to maintain my URLs to have capital letters. However, GitHub pages URLs are case sensitive. It’s a well known issue.
While most people just use lower case for their URLs. I didn’t like this option.
To fix this, I can let the user go to the 404 page and have a script there match the URL entered by the user with the URLs of all pages on the site (while ignoring the casing). If there’s a match, forward the user to the URL with the correct casing.
To implement this in your Jekyll site hosted on GitHub Pages, add this script (inside a script tag) to your 404 page.

Try it by visiting this URL amreldib.com/blog/howtoaskaquestion/ which should be amreldib.com/blog/HowToAskAQuestion/

How to Ask a Question

I work in Technical Support, and I participate in a number of online communities. Not a week goes by without shaking my head when reading a question by someone seeking technical help.
I consider asking a question a form of communication. Any form of communication can be improved if we follow some guidelines and aim for some goals.
The main goal is to get an accurate answer to the question faster. This could be achieved by:

• Reaching expert audience
• Maintaining their attention
• Delivering the right question

Reaching Expert Audience

This is not just about going to the right forum or Q&A site to ask your question. Even in those places, there’s an audience reading your question that’s usually bigger than the experts you’re targeting.
Very early in your question, make clear what’s the focus of your question. Don’t start with background. It seems like a natural place to start with how things came to be. However, from the reader’s perspective, they want to know if this question is for them or not. Start with the big technology terms you’re using.
On the other hand, don’t be too specific to avoid pushing away some of your audience. Don’t say something like “Calling Adobe Flex Experts only”. Anyone who’s not an Expert will just move along, and it’s your loss because one of them have the answer to your question. Instead say “I’m having a problem with Adobe Flex”, or better, “I’m getting an error with Adobe Flex” or “I can’t do X with Adobe Flex”.
Your starting sentence is the synopsis of your problem.

Maintaining their Attention

Now that I have the right audience for my question, I gotta give them more details to get them thinking. The first paragraph of your question is a more detailed description of the problem. It’s not the most detailed description. The first sentence in a foot deep in the water, and the first paragraph is knee deep.
The first paragraph is the hardest part to write. You might think that the first sentence is more difficult because it’s shorter, but there’s only one (or at most, two) piece of information you need to deliver in the first sentence. The first paragraph is a summary of your problem with enough information to cause the reader to come up with a suggestion or ask for more details.
There’s a big upside in asking the question in this manner. You’re forced to think about how to phrase, or describe, the problem. This is a slightly different exercise than trying to solve the problem. In stepping back and looking at the problem from a far, you get to see things you’ve missed while neck deep into the details.
I’ve had clients emailing me with long technical details and attached code files asking for help, only to email me an hour later saying they’ve figured it out even though it wasn’t an easy problem. It’s just when they send the first email, they step away from the problem because someone else is looking into it now. This gives their minds enough space to wonder about the problem from a distance.
The same kind of thing happens to me as well. I would run into a problem. Frustrated, I run to a coworker asking for help. I start explaining the problem out loud, breaking down what’s wrong, and in the process of describing it I say “you know what? never mind. I found it”. They look at me not understanding what just happened but offering “you’re welcome” as I run back to my desk.
The first paragraph is about what not to write more than what to write. Don’t write about the background for the question, don’t write deep technical details like version numbers, don’t write long snippets of your code. Use your words, don’t just show your work and ask the reader to figure out what’s wrong.
There’s one exception to this which is error messages. These sum up the problem very well that they can cause the reader to offer a suggestion right away. However, they also beg the question: why didn’t you search for the error message. We’ll talk about this in a bit.

Delivering the Right Question

Your first paragraph got the reader thinking. The rest of your question is about answering the questions they’re most likely to ask, and shooting down the suggestions you’ve already tried.
This might be the place to provide background for your question. However, do so in a gradual manner. First, technical background, then less technical details. Start with “I’m trying to make the user data persistant on the client side”, then later talk about “I’m a contractor building an app for a financial institution”. Design your question on the assumption that the reader will stop reading half way either to leave or to answer.
Talk about what you’ve tried. It’s important to show that asking the question isn’t your first attempt to solve the problem. The reader’s time is precious and you want to show that you care about saving it. Give brief (one sentence) explanation on why this solution didn’t work for you.
Provide the technical details about your problem. This includes version numbers, configurations that you’ve set up, requirements and limitations you must adhere to. Any details that limit and rule out some of the possible solutions.
The idea here is to avoid wasting time on long exchanges about things other than solid suggestions you can act on. You don’t want to have a response like: “what version are you using?”. You don’t want to get answer like: “I’ve googled your question and I got this” then a response from you saying “I’ve tried this”. All these exchanges are wasting time and draining the attention of your audience. They’re losing interest in your problem as time goes on. The only people sticking around are the ones who have the same problem as you.

General Rules

Formatting
Formatting is very important. I don’t want to read through a ball of text. I want to be able to scan the text for a specific piece of information. Bold and italics are your friend. Break your text into paragraphs. Use lists and bullet points anywhere they make sense. Avoid stream-of-consciousness type of writing.
Be Mindful of your Readers
These are people who are trying to help you, usually only out of the goodness of their own hearts. Don’t waste their time. Understand that they could be busy if they don’t come back to follow up. Be grateful, not just for their suggestions but even for taking the time to read your question.
Finish the Story
When you finally find an answer, post it where you posted the question. You started out asking the Internet for help, it’s only suitable to help the Internet when you can. It’s temping to just move on, but think about all those long forum threads you stumble upon that matches your problem and goes on and on only to end with no good conclusion. It’s very frustrating.

You might end up with very short threads if you follow these rules. You can get the answer, or even shorter; no answer. It’s not as exciting as having people come in and ask you simple questions to get basic information or make basic suggestions. This gives the illusion that people are engaged and the solution is just around the corner. However, it’s not. It’s just wasting time, and giving the impression that you didn’t do your part.
People will read your question and probably end up not having an answer or making a suggestion. You can give them another chance to look at your question by providing an update every time you make some progress.
Happy troubleshooting!

Intro to GitHub Talk at MaptimeYVR

I got a chance last Tuesday to give a session at MaptimeYVR titled 'Intro to GitHub'. It was a lot of fun and a great chance to meet everybody. MaptimeYVR is getting more interesting with every meetup. My thanks to the organizers; Sarah, Liam and Joey.

Getting our Git on at @maptimeYVR with @AmrEldib cc/ @sarahmprz @mappingmashups pic.twitter.com/PPv5G0Rh9G— Joey Lee (@leejoeyk) February 18, 2015

Here are the slides to the talk. The sample is on GitHub, we'll use it for the exercise next meetup.

Change Style of Firefox DevTools

I spend a lot of time now in the Firefox Dev Tools. The console has a very nice dark theme which makes things easier but some times that’s not enough. You can find the font a little small (which you can fix with a Ctrl + ‘+’), but mostly after a while you just find yourself bored of looking at the same thing. Time for a bit of change.

After a quick search on DuckDuckGo, I find the answer on StackExcange (the AskUbuntu site), and it was really easy.

Create a new userChrome.css file (You read that right. Before Chrome, chrome just meant window). Create the file under:

%USERPROFILE%\AppData\Roaming\Mozilla\Firefox\Profiles\<PROFILE NAME>\chrome\userChrome.css

In the file, add the style you want.

@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document regexp("chrome://browser/content/devtools/.*") {
    * { 
        font-size: 20px !important 
    }
}

Update: In newer versions of Firefox and in the Firefox Developer Edition, the URL to the devtools is different. You should use this snippet instead:

@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document regexp("chrome://devtools/content/.*") {
	* {
		font-size: 16px !important;
	}
}

Restart Firefox.

Enable Windows Authentication in Firefox

TL;DR: for Firefox users, here’s how to integrate Windows Authentication to enable logging like IE (without entering credentials).

I use Firefox as my primary browser. At work, we’ve just started a big consolidation of all the companies sites and cloud services (that we use) to rely on Windows Authentication. Instead of just Windows and Outlook requiring your Windows credentials, now everything needs them including CRM, messaging service, partner sites, etc. So, I found that I’m entering my credentials over and over all the time.

IE, of course, integrates Windows Authentication. Firefox, for the longest time I thought, doesn’t.

But I wanted to avoid this (laziness is the mother of all inventions). So, I did a bit of research and found that Firefox actually does support integrating Windows Authentication. However, it’s done via a white-list of sites that are pre-approved. Once this is configured, signing in is done automatically without having to enter credentials anymore.

To configure Firefox to skip the Windows credentials dialog, do the following:

• In the address bar, type about:config and press Enter.
• Click “I’ll be careful, I promise!”.
• Search for “network.automatic-ntlm-auth.trusted-uris”.
• Double-click on the entry to modify its value.
• Enter a comma-separated list of sites you want to enable Windows Authentication for.
• The URLs to be added should be the base URL without ‘http://’ in front. This makes it easy to avoid entering the wrong value.

If you use Firefox, apply these steps to quickly log into sites that uses Windows authentication.

If you don’t use Firefox, you really should. Check out Tab Groups.

It’s better than this :D