This Week I Learned - 2016 Week 12

Last week post or the whole series.

#1 LXD 2.0 blog post series. Write-up by St├ęphane Graber on the upcoming LXD 2.0 release. Since the REST API support are pretty much quite stable these days, you can't blame where numerous web front ends (lxd-webui and lxd-webgui) exists. Between two different container implementations, I still prefer LXC to Docker. The unfortunate case is Docker has the popularity and financial backing to move things faster.

#2 "End of file during parsing". Encountered this error message when I was customizing my Emacs. This is due to excess open or close parentheses. Surprised to know that the debugging procedures is quite tedious. I'm still not getting used to the enormous long Emacs default key bindings.

#3 Emacs' Sequence of Actions at Startup. For Emacs 24.x. That is one long list of items to run during program startup.

#4 .PNONY in a Makefile. It just dawned to me that the obvious reason is that we set certain targets as .PNONY because these are not file target!

#5 Certain metals antiseptic effect. Hence, why musical instruments and some door knobs are made from brass.

#6 Which activity brings out the worst in people? Sad but true, I've to agree with the discussion of the top post. Inheritance, mostly caused by the wife/husband of the siblings.

#7 Seeing the Current Value of a Variable. Either 'Ctrl+h v' or 'Mx describe-variable' to find the value of a configuration item in Emacs.

#8 Telsa's Euology. Surprised to found out about her passing. Used to follow her blog in the early days of GNOME project when Alan Cox was still the Linux kernel maintainer.

The Road to Evil

Few years back, I've tried it but the transition experience still a lot to be desired. But due to the recent circumstance which piqued my interest to revisit this long overdue to-do item in my someday list again. Yes, to become an engaged member of the Church of Emacs.

Joke aside. With the recent development of Emacs and the more stable releases of its related plugins, the transition from Vim to Emacs seems doable and manageable. You still can retain most of the Vim experience in Emacs through Evil (Extensible Vi Layer for Emacs), but not without some additional customization. More on that in coming posts.

Installation in Ubuntu.
$ sudo apt-get install emacs24

$ emacs --version
GNU Emacs 24.5.1
Copyright (C) 2015 Free Software Foundation, Inc.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Well, this is Ubuntu/Debian, checking the emacs binary. Maybe there other Emacs implementations available?
$ file $(which emacs)
/usr/bin/emacs: symbolic link to /etc/alternatives/emacs

$ file /etc/alternatives/emacs 
/etc/alternatives/emacs: symbolic link to /usr/bin/emacs24-x

$ sudo update-alternatives --config emacs
There is only one alternative in link group emacs (providing /usr/bin/emacs): /usr/bin/emacs24-x
Nothing to configure.

By default, Emacs starts with X window system. If you want to bypass this behaviour and start in console instead, use the '-nw' parameter or add an alias instead.
$ emacs -nw
$ alias emc='emacs -nw'

Next is to install the Evil package for Emacs. If you need something up fast, check out the blog post by Bling and his Evil-mode bootstrap config. There is also a tutorial video to demonstrate evil-mode in Emacs. Ironically, I learned more about Vim than Emacs from his video.

To automatically install missing packages, the '.emacs.d/init.el` as follows.
$ cat .emacs.d/init.el 
; required packages
(setq package-list '(evil))

; additional repository
(require 'package)
(add-to-list 'package-archives '("melpa" . ""))

; activate and refresh all the packages
(unless package-archive-contents

; install the missing packages
(dolist (package package-list)
  (unless (package-installed-p package)
    (package-install package)))

; enable evil-mode
(require 'evil)
(evil-mode 1)

Start Emacs in console but enable debugging. If there are no issues, Emacs will start normally and you can immediately start using it with Vim's default key bindings.
$ emacs -nw --debug-init

To prevent Repetitive strain injury (RSI), one the of way when using Vim is reducing your pinky or little finger usage. For the left pinky, the Escape (Esc) key and for the right pinky, the colon (:) key.

The Escape key.
This can be done by mapping 'jj' key to Escape key. Updates to our '.emacs.d/init.el' file.
$ cat init.el | grep "required\|exit" -A 3
; required packages
(setq package-list '(evil key-chord))

; additional repository
; exit insert mode by pressing j and then j quickly
(setq key-chord-two-keys-delay 0.5)
(key-chord-define evil-insert-state-map "jj" 'evil-normal-state)
(key-chord-mode 1)

Binding the Colon (:) key.
This can be achieved by binding the colon (:) key to semicolon (;) key. Thus remove the needs to use the right Shift key. Changes to '.emacs.d/init.el' as shown again.
$ cat init.el | grep "evil-ex" -B 1
; bind ';' to ':'
(define-key evil-normal-state-map (kbd ";") 'evil-ex)

Restart Emacs and both settings should be customized to our liking.

As someone who suffered from RSI (rare these days but still prevention is still better than cure), these two customization are the essential minimum requirements for me to have a painless typing sessions. Not sure why, but both these settings should be the sensible default to Evil-mode, not enable by default, but should be part of the settings.

Stay tuned, expect more Emacs customization posts in coming months.

This Week I Learned - 2016 Week 11

Last week post or the whole series.

#1 Undoing a git rebase. I've made a mistake where you can 'fixup' a previous commit during rebasing. Instead of trying the fix it, might as well undo the rebasing through these two commands, provided you haven't done anything else before hand.
$ git reset --hard ORIG_HEAD
$ git rebase -i --abort

#2 NextBug, a bug recommender for Bugzilla based on the textual recommendation. Rare to find an interesting academic project which have immediate impact in the industry. This makes the developer aware the context of the issue being looked into. Video presentation of the tool as well as published papers here, here and here.

#3 Journal of Software Engineering Research and Development. Surprising find, especially this paper, Patch rejection in Firefox: negative reviews, backouts, and issue reopening. There seems to be a lot of interesting research done in field of Empirical Software Engineering (ESE). The most prolific group in the industry for this field most likely is the Microsoft ESE group.

#4 Open Source Society University. Does pursuing a typical degree in Computer Science compare to self-taught is a sensible choice these days? Not anymore but unfortunately, a degree is the minimum requirement if you need to work oversea and to get pass the Human Resource department.

#5 Pollen, a book publishing system written in Racket. Right, another publishing system in another exotic programming language. Why not? I've enough of Sphinx, anyway.

#6 Lumen, a PHP micro-framework based on Laravel. Yes, another PHP micro-frameworks.

#7 pkgr, create DEB or RPM package for Ruby, NodeJS, or Go application.

This Week I Learned - 2016 Week 10

Last week post.

#1 Borg, Omega, and Kubernetes. Lessons learned from three container-management systems over a decade. Surprised to discovered that the recently released Kubernetes is not the latest container-management systems used internally at Google. Three people (two being non-technical) have brought up Kubernetes for the past two months. So it seems, the container fad have finally caught up in the local IT scene here.

#2 Modifiers. Add variety to in writing your sentences. May not be that suitable for technical writing. Should be fun to experiment different types of modifiers (resumptive, summative, or free) in exploring Writing Prompts.

#3 Shintar┼Ź Midorima, better long range basketball shooter than Stephen Curry? Which reminds me of this article I've read on The Steph Curry Fallacy. You can't just be another Stephen Curry without having the supporting environment and people to "nurture" your talent.

#4 SSHTron. Multiplayer Tron in your terminal. Not sure how they did it but it was technical fun and interesting.

This Week I Learned - 2016 Week 09

Last week post.

#1 Goals vs. Systems. Before pursuing any goals, make sure you're making an informed and educated decision. The strategy is to use knowledge instead of willpower to pursuit your goals. For example, as not all carbohydrate foods are equal, you can lose weight easier if you pick the right food choice by knowing its Glycemic Index, which have an effect on a person's blood sugar.

#2 Raspberry Pi 3 is out. (HN discussion) The built-in onboard Wifi and Bluetooth as well as 64 bits support are welcoming feature. Unfortunately, local Element14 still awaiting stock. Heck, I can't even procure a Pi Zero till today. Not sure if the specs boost is worth the upgrade, however, some review claimed this release it's a worthy desktop replacement. If you never own a Pi before and itchy get on the single-board computer bandwagon, then you should get a Pi 3. As for me, will skip this as I'm saving money to get a SSD drive which definitely help with my testing of containers.

#3 Git rebase and the golden rule explained. Detailed explanation on Git rebase. If you want to stick to the Subversion's model of a single linear tree, then Git rebasing is the preferred choice. The only caveat is you may need to force-push if you rebase already commits that have been shared.

#4 Prevalence of Healthy Sleep Duration among Adults — United States. (Reddit discussion) Seriously, sleeping less than 7 hours per day may increase your chances of mortality. Rest people, rest.

#5 Using Make with Django. Lots of people (especially those from non-Unix background) overlook or underestimate the useful of GNU Make to manage tasks with your software project.

#6 How do you remember what you read? It will take times to internalised or digest the information but memorization is the initial step. If you can't retain the information within your brain, you can't analyze it. Retention is useful to verify your understanding if you just follow the these steps.
  1. Read a paragraph.
  2. Close the book.
  3. Write down what you remember.
  4. Re-read the paragraph and check.