Monday, March 2, 2015

Ubuntu: Remapping Right Ctrl with Right Alt

Ubuntu uses xkb to handle its keyboard mapping. You can read more about it here:

  • https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg

Because I use the CTRL key a lot, I want it to be easier to access. Since I always use the ALT key with my left hand, I decided to switch the right ALT key with the Right CTRL key.

To do this, I opened 10-evdev.conf as an admin:
  • sudo pico /usr/share/X11/xorg.conf.d/10-evdev.conf
and added the following to the file:

Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "us"
        Option "XkbModel" "pc104"
        Option "XkbOptions" "ctrl:rctrl_ralt,ctrl:ctrl_ralt"
EndSection
Restart your computer to verify your changes.

As you can see, most of the setting is for the keyboard. The most important thing is the second to last line, Option "XkbOptions" "ctrl:rctrl_ralt,ctrl:ctrl_ralt". This states that I want to right CTRL key as right ALT key and vice versa. You see more xkb options in the base file (start on line 692):
  • /usr/share/X11/xkb/rules/base.lst

I haven't tried it, but you can probably switch the caps lock with the control key with ctrl:swapcaps

Resource:

Thursday, February 26, 2015

Ubuntu hangs on boot on Asus U46E

Recently, I installed Ubuntu on my Asus laptop, but it keeps hanging on the start up screen. It seems like Asus laptop has a problem with this. After reading several options, this one works for me:
  1. Go into your BIOS
  2. Select "Advance" using the right arrow button
  3. Select "VT-d" by pressing the down arrow button
  4. Press "Enter"
  5. Select "Disable"
  6. Press "F10" to exit the screen
  7. Select "Yes" to save
Note: You can read on VT-d on Intel blog to see if that's the best option for you.

If that doesn't work, you may find these solutions helpful:
  1. Ubuntu 10.10 [64 Bit] hang on boot 
  2. Ubuntu 12.10 boot hangs on purple screen 
  3. Ubuntu hangs at purple screen

Tuesday, September 2, 2014

Elixir: Phoenix compilation error

I got the following error when I tried to compile master. If you get it too, just delete the _build folder.

==> plug
Compiled lib/plug.ex
Compiled lib/plug/adapters/cowboy.ex

== Compilation error on file lib/plug/conn/adapter.ex ==
** (RuntimeError) cannot compile Plug because the :cowboy application is not available. Please ensure it is listed as a dependency before the plug one.
    lib/plug/conn/adapter.ex:4: (file)
    (elixir) src/elixir_lexical.erl:17: :elixir_lexical.run/3
    (elixir) lib/kernel/parallel_compiler.ex:97: anonymous fn/4 in Kernel.ParallelCompiler.spawn_compilers/8

could not compile dependency plug, mix compile failed. You can recompile this dependency with `mix deps.compile plug` or update it with `mix deps.update plug`

--------------------------------------------------------------------------
When you get the error below, remove the deps `rm -r deps` and redownload them again `mix deps.get`

== Compilation error on file lib/postgrex/types.ex ==
** (CompileError) lib/postgrex/types.ex:6: module Decimal is not loaded and could not be found
    (elixir) src/elixir_exp.erl:104: :elixir_exp.expand/2
    (stdlib) lists.erl:1352: :lists.mapfoldl/3
    (stdlib) lists.erl:1353: :lists.mapfoldl/3
    (elixir) src/elixir_exp.erl:49: :elixir_exp.expand/2
    (elixir) src/elixir.erl:206: :elixir.quoted_to_erl/3
    (elixir) src/elixir.erl:175: :elixir.erl_eval/3

Friday, August 22, 2014

Brew commands

Normal install
brew install elixir 

Install github master version of Elixir
brew install elixir --HEAD

Upgrade Elixir to github master:
brew upgrade elixir --HEAD

Uninstall
brew uninstall elixir

Your best friend
brew man  

Manually install Elixir
  1. Clone elixir https://github.com/elixir-lang/elixir.git
  2. Check out the branch/version/hash you want to build (git co branch/hash)
  3. In the elixir directory, make clean test
  4. Make the version directory mkdir /usr/local/Cellar/elixir/version
  5. Copy the bin and lib files to the directory 
    1. cp /Users/nhu/me/elixir/elixir/bin /Users/nhu/me/elixir/elixir/lib CHANGELOG.md LICENSE README.md  /usr/local/Cellar/elixir/1.0.0
    2. Brew install elixir
    3. Brew switch 1.0.0

Wednesday, August 20, 2014

My Testing Style


Before we get into the topic, let’s define some vocabularies. I know people will disagree with how I use the term, however, I want to define it so you know what I mean when I use these words.

Unit test - Isolated tests that test a single class. Dependencies are mocked.
Integration test - Tests that test through API. It could reach several classes and/or databases.

A few years ago, my testing structure follows the testing pyramid. By default, I wrote unit test first. I wrote a test for every single functional class. (I usually didn't write test for model/bean because they were simple getter and setter. They usually didn't have a lot of functionality.) I mocked dependencies, regardless if the dependencies were written by me or not. On top of the unit test, I wrote a few integration tests to ensure everything worked well together. 

Lately, I noticed that I am leaning toward writing integration tests by default. I find that I am more confident that the code work because I don't have a lot of mocks. I also write less tests because one single test scenario could touch several classes. It is also easier to refactor because the test uses the API, therefore I can change the internal structure as much as I like. There is a downside to this. Integration often takes longer to run. It is harder to pinpoint a bug. Sometimes the setup makes it hard to understand what the test is doing. When I run into these situations, I add unit tests.
Even though I prefer integration heavy test, when I have a resident apprentice, I will make my apprentice follows the testing pyramid and write more unit tests. I believe unit tests train your mind to build cleaner code because it exposes design flaws. When you are writing a unit test and it takes 50 lines to set up the test, there is problem. My philosophy is if it’s hard to unit test, there is probably a code smell. As the apprentice develops a sense for writing clean code, I believe the apprentice will develop his/her own style of testing.

My advice on testing is to write the kind of test that let you sleep at night, literally. When you don’t write test or when you write bad test, things break and you worry when you deploy. Or your code might break at midnight and you have to stay up and fix it. Therefore write tests that makes you feel confident that you won’t have nightmare or midnight emergency.

The reason why robot can’t do our job yet is because we change our style depend on the situation. You can’t go with one extreme or another. Not writing test is bad. However, if it will takes you half a day to write a test so you can change one simple line of code, is it worth it? Can you sleep with changing that code without a test? If you are choosing one practice over another, make sure you understand why. Develop a style that let you have a good night sleep.


Here are a few pros and cons to both style:
Unit testing
Pro
- Run quickly
- Quick bug detection
- Easy to adhere to the single responsibility

Con
- Coupled to the code, thus hard to refactor
- May need a lot of set up for mocks
- May mock the wrong return

Integration test
Pro
- Test code is decoupled from production code, thus allowing you to refactor to your heart content.
- Confidence everything works well together
- Understand how to use the code

Con
- Slow
- Could be a lot of data to set up
- Harder to find bugs

Disclaimer: The content written on here is based purely on my experiences and what I’ve seen so far. It is my opinion at this time. My opinion will change.