Collection of bad / confusing UI

In this post I want to share some examples of UIs that I find really confusing. Maybe you'll agree or maybe you won't but I think it's still fun to show what I think is bad UI. It's probably going to be an ongoing post - because I always find sites that are confusing online. I won't tell which site it comes from so that we can keep them anonymous. I've wanted to write this post a while ago but never did. There's a saying that goes by "better now than never" 1.  This tab color is really strange to me. Which one is currently selected? Every time I use this, I end up clicking on "Activity Details" (light colored one) but that one is already selected. The one not selected is the one in dark blue. I don't think there's a right and wrong here but my brain cannot come to the conclusion that the light white background color is the selected one. More to come!

Git commands cheat sheet (in progress)

### Use case: Working on 2 dev branches and merging one into the other and want to revert git checkout dev_branch git merge my_new_feature // merging my branch into develop Ooops, now I realized `my_new_feature` has something wrong git revert -m 1 <sha of merged commit> OR git revert HEAD -m 1 means we keep the parent side of merge ( dev_branch  branch) ### Fetch their new commits and merge to your branch git fetch protected_repo Committed but not pushed to remote. Want to get rid of latest commit git reset --hard HEAD~1 Get a branch from a forked repo to your own repo (or to your own forked repo) git reset HEAD~1  Get a branch from a forked repo to your own repo (or to your own forked repo) git fetch git@github . com : theirusername / reponame . git theirbranch : ournameforbranch Associate your local copy to the upstream branch git remote add repo_name Fetch their new commits and merge to your branch git

Moving private repos to bitbucket

As much as like github for repos - I didn't feel it was *yet* worth to pay the monthly fee to get unlimited private repos. So I decided to move all my private repos to bitbucket, which is free! If you ever need to do the same, here's a link that explains it really well:

Chrome dev tools - secret weapon?

When I started working back in 2010, we used to support IE7. I still remember how much of a paint it was to debug javascript code. With IE8/IE9 debuggers, what I learned is patience, rather than figuring out how to fix all those weird bugs that *always show up *only in IE. The debuggers were so slow. Also back then, firebug was the norm. Chrome dev tools was relatively new and most people I knew did not use it. I liked Chrome so I sticked with it. Now, it's a tool that I use almost every day. In fact, I try to spend some time and follow what's new with the dev tools. I also spend some time experimenting with soon to be features/apis on Chrome Canary. This year, well last year... (2016), I've been pretty busy and haven't had much time to look at the new features. But today, I spent a few hours catching up on the last Google I/O and watch what's new with the dev tools. I wanted to share this link and give back some love to the chrome dev tools by writing this post.

css position: sticky

This links highlights what's new in Chrome 56: One cool thing amongst others (bluetooth access is also cool but this one css feature is something I wish we had a while back) is position:sticky . It's available in Chrome 56 (stable as of Jan 2017) and to summarize, it allows to fix an element into the viewport when it's within a threshold. .header {  // Element will be "fixed" when it is 10px from the top of the viewport  position:sticky;  top: 10px } You could set top : 0; to make it stick directly to the top of the viewport. Have to be conscious that this positioning might not be available in other browsers as of yet. There's this site I use to check what's available: As of now, it's not available in IE (not very surprising...)

Git bisect

Ever used git bisect?!

async promises in a sync way?

This blog post title is pretty confusing - but if you get to read this blog post by Google, it actually makes sense. It's actually pretty cool. Not that I don't like callbacks or promises, but I can see this being useful in more complex examples. async function fetchDogPics(url) {   try {     //this looks synchronous but it isn't...     const response = await fetch(url);     await response.text();   } catch (err) {     console.log('failed', err);   } }