Blog

### 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 https://github.com/theirusername/their_repo.git Fetch their new commits and merge to your br...

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: http://befused.com/git/github-bitbucket-move

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. ...

This links highlights what's new in Chrome 56: https://developers.google.com/web/updates/2017/01/nic56?utm_source=frontendfocus&utm_medium=email 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: http://caniuse.com/#search=sticky As of now, it's not available in IE (not very surprising...)

Ever used git bisect?! https://www.metaltoad.com/blog/beginners-guide-git-bisect-process-elimination

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);   } }