Learning Colemak, a Qwerty Keyboard Alternative

Colemak is an alternative keyboard layout to the standard Qwerty layout that we use everyday.

A better alternative? maybe? Up to you, however here are some stats and a quick FAQ page for your reference.

A couple of notes to get you started

These are specifically for a GNU/Linux machine but i am thinking it probably works similarly on other Operating systems.

While you are practicing/learning to touch type try not to use stickers or modify your physical keyboard in any manner, later on you can use visual aids.

  • Get a typing practice application (i.e. a touch typing program):

KTouch is awesome, FOSSΒ  and easy to install (i.e. apt-get install KTouch).

  • Set the Colemak keyboard mapping for your machine:

setxkbmap us -variant colemak

  • Launch KTouch, set up your profile and start practicing.

Better to unlock lessons as you go

  • When you have finished practicing for the day, set your keyboard back to Qwerty mapping.

setxkbmap us

Practice typing a little bit everyday as opposed to going cold turkey, otherwise it can feel very frustrating and you will probably loose heart

Baby steps to big dreams

Once you have finished all the typing lessons (i.e. the KTouch lessons) you can go ahead and start typing in the wild :). It will feel a little slow at first but you will get comfortable and faster as you start typing more. You will also see some of the advantages of the Colemak keyboard (e.g. your hands do not move all over the keyboard as you type, which does happen with Qwerty)

Please note: This is an ongoing little experiment on my part and you should also take it as such, do no expect to learn to type on Colemak in a couple of hours and start writing/programming professionally right away (everything takes practice).

Your mileage may vary, my opinions certainly will.

If you find mistakes or typos, kindly let me know so I can fix them πŸ™‚

Enjoy and share with others.


Lightweight Markup Languages and When to Use Them

Please note these are purely my opinions, feel free to disagree, comment …etc.

Use simple tools for simple tasks and always simplify tasks. Rinse and repeat.

First, read this if you don’t know what a markup language is, and then read this if you want to learn more about lightweight markup languages (LML).

Did you read it? Excellent. So over the past couple of days I have been doing some research to decide upon a lightweight markup language for my documentation purposes.

From my research it seems:

For Simple Notes

e.g. for your text-pad, note-pad, for keeping track of ideas …etc

Use Text files: for cases where you are interested in simplicity of form and content and you don’t care too much about visual appearance and presentation.

As a simple rule, always start with raw text-filesΒ by default. If you feel you need more,Β  you can always copy and paste to other formats later on.

For Short Readmes or Prose to Publish on the Web

e.g. Readmes for projects on GitHub, BitBucket, or quick blog posts …etc.

Use Markdown: this is basically the lightest markup language that exists, however it provides quite a bit of flexibility for formatting short documents (Headings, lists, bold, italics … etc).

But remember do not use Markdown for longer documents, it is really not suited for this (it gets hard to maintain really quickly). Also Markdown was primarily designed for web content (HTML) so if you are preparing documents for print (e.g. pdf) there are better formats especially suited for this, please see below.

Markdown is serviceable for simple short prose, but the instant you need more than basic formatting, you’re on your own.

For Documents to Send to Non-Technical (Office) Users*

Use a WYSIWYG document (e.g. libre office)* in open format so they can edit it.

*Not a lightweight markup language per-se, but in the interest of preserving friendships and peaceΒ  with people used to working with MS Office that swear by it (Why? … oh let’s not go there).

For Long Documentation Requiring Collaboration and Displayed on the Web.

Use AsciiDoc or reStructuredText: These are more flexible light markup languages especially suited for this purpose. Out in the field they are used for writing user manuals,Β  getting started guides, technical documentation, ebooks ..etc. (Here is an interesting article on AsciiDoc)

Markdown is great to write small and simple documents. But
ReST/ASCIIdoc are much better when you want more complex, richer docs.

For Individual Professional Documents for Print.

Use LaTeX: for both flexibility and excellent quality documents (especially if they include mathematics) for publication in print (i.e. for PDF documents that are meant to be displayed/printed as pages).

e.g. for research papers, academic dissertation, Journal papers, curriculum vitae, resume …etc.

LaTeX generates publication quality documents and formulas that look great on paper.

I have personally used LaTeX quite a bit and I really like it, however for collaboration LaTeX is not the best candidate (though there are some alternatives if you really want to go this route): there is a steep learning curve for beginners and you have to download about 1GB just to be able to start working with it locally.

Hope this helps,

Did I miss anything? leave your comments below,

Why Documentation is Important

Documentation is planning ahead.

Development without prior learning or planning is akin to heading to the ocean without a map and expecting to come out alive. It can happen, it’s just not very likely.

When you are working in engineering projects sometimes it is hard to explain (or to justify) to others the importance of writing good documentation to back up your ideas and avoid major obstacles later on.

A lot of people seem to think that pushing forward without a plan will somehow get you there, in reality (or perhaps in engineering?) things are a little different:

Hacking your way around a problem (kind of like beating a screw with a hammer) sometimes does work for small quick and dirty projects (mostly when you are working alone) but it almost certainly will not work for major important projects (more so for team projects); you will make wrong design decisions and continue onward until you meet a dead end, and then you will have to go back to the drawing board and start over (tell that to your colleagues)… Fun!

As a last note: A while ago I found this set of articles published by Joel Spolsky which I thought were excellent and quite entertaining, totally worth reading.

Text Simple Planner, Managing Tasks With Text Files

No fancy apps, plain and simple, just a text based planner.

This post is for those that love the utter simplicity and flexibility of text files (.txt), the following are some advantages you might have heard of :

  1. You can open text files literally anywhere (your phone, your tablet, your desktop computer …etc) and they are supported by every operating system I know of (talk about cross-platform).
  2. You don’t need any special software to open text-files (no calendar, planning apps …etc. none of that nonsense), hell you can even use a browser (not that you would particularly want to do that).
  3. Completely open format.
  4. No vendor lock-in. (thanks to bullet points 1, 2 and 3) This is extremely important: i.e. do you want to be forced to purchase a copy of your favorite planning software just to be able to open your notes? or do you want to be monitored 24×7 to be served with “better ads”? better ads, for who? Nah. (Here is more info on the benefits of open formats/technology)
  5. Dead simple interface. What you see is what you get, and it ain’t pretty, no fancy colors or multiple fonts or … you get the point. I personally don’t care too much about these except when you have to send it to other people and they complain (so you have to put a nice ribbon around it).

So a while ago (a couple of years ago) I started to use text files to handle my day to day planning, it was a bit rough at the beginning but over the years the system has evolved and has gotten more efficient, to the point where it might actually be useful to others (though nowhere as developed as Todo.txt or other applications).

Here is the default directory setup with folders and text files, plus spreadsheet and drawing files (I know, I know, I cheated but sometimes these are useful for formulas, tables, block diagrams …etc, plus they are open tools):

β”œβ”€β”€ ideas_projects
β”‚Β Β  └── person_ideas_projects.txt
β”œβ”€β”€ inkpad
β”‚Β Β  └── person_inkpad.xoj
β”œβ”€β”€ license
β”œβ”€β”€ quotes
β”‚Β Β  └── person_quotes.txt
β”œβ”€β”€ readme.md
β”œβ”€β”€ spreadsheet
β”‚Β Β  └── person_spreadsheet.ods
β”œβ”€β”€ textpad
β”‚Β Β  └── person_textpad.txt
└── todo
Β Β Β  β”œβ”€β”€ person_calendar_todo.txt
Β Β Β  β”œβ”€β”€ person_pending_todo.txt
Β Β Β  └── person_recurrent_todo.txt

and here is my personal setup in use (note that I keep a reference of old files simply by appending a date at the end, current files are undated):

β”œβ”€β”€ ideas_projects
β”‚Β Β  └── camilo_ideas_projects.txt
β”œβ”€β”€ inkpad
β”‚Β Β  └── camilo_inkpad.xoj
β”œβ”€β”€ quotes
β”‚Β Β  β”œβ”€β”€ camilo_quotes_2014.txt
β”‚Β Β  β”œβ”€β”€ camilo_quotes_2015.txt
β”‚Β Β  └── camilo_quotes.txt
β”œβ”€β”€ spreadsheet
β”‚Β Β  β”œβ”€β”€ camilo_spreadsheet_2015.ods
β”‚Β Β  └── camilo_spreadsheet.ods
β”œβ”€β”€ textpad
β”‚Β Β  β”œβ”€β”€ camilo_textpad_2014.txt
β”‚Β Β  β”œβ”€β”€ camilo_textpad_2015.txt
β”‚Β Β  └── camilo_textpad.txt
└── todo
Β Β Β  β”œβ”€β”€ camilo_calendar_todo_2014.txt
Β Β Β  β”œβ”€β”€ camilo_calendar_todo_2015.txt
Β Β Β  β”œβ”€β”€ camilo_calendar_todo.txt
Β Β Β  β”œβ”€β”€ camilo_pending_todo.txt
Β Β Β  └── camilo_recurrent_todo.txt

And I just keep a simple text editor open to edit the files directly (I am using Geany).


Finally here is a brief snippet illustrating how each one of these text files looks like (I loosely use Markdown for the syntax, just for aesthetics) and how I use them in my real day to day planning (If you haven’t done so, go on and download the template setup from my Github account, otherwise the next paragraphs might not make much sense, you have been warned, hey).


# Camilo Ideas and Projects #

## Quick Guidelines. ##
Only project ideas and ongoing projects should be here, 
the rest should be moved out and stored in our textpad 
for reference. Β 

## Current Projects ##

### Assorted book summaries (part-time).
Ongoing transcription of book summaries from finished 
common books.

## Future Projects ##

### Search Notes Script - Add support for ODF formats.
It can search in all text files as well as open 
spreadsheets and other open office documents.


# Camilo Quotes #
##Β Β Β  2016Β Β Β Β  ##

Perfection is impossible. Improvement is our goal.

Listen attentively and ask questions. Always give 
others the benefit of doubt.

Have a general intuitive understanding of physics, 
and a deep understanding of a single specific area 
of research. 

While proprietary technology will probably continue 
to be our standard for product development, our 
efforts to grow open technology as a viable 
alternative will plant the seed that will inspire 
future generations to bring about change.


# Camilo Textpad #
##Β Β Β Β  2016Β Β Β Β Β  #

### C and C++, a couple of notes.
C is designed to model how the hardware processes the 
information (forcing the programmer to understand the 
hardware details) C++ is designed to model how the 
programmer/user thinks when designing complex 
applications (while still allowing those 
interested/curious to peak under the hood.)

#### Practical usage.

### KiCad Libraries
It's actually not bad, KiCad actually has more 
flexibility than any other CAD software package 
(don't all open source programs always do :)). You 
just have to keep in mind what official libraries 
are (in Altium, KiCad, Eagle or any other PCB Cad 
package) and what they will always be: a starting 
point. Never a personal manufacturing-ready library. 
You can always use the official libraries as a 
starting point (and having good official libraries 
- github is a great move in this direction - 
streamlines the process because you can copy and 
paste good components) but you should always make 
sure you build your own personal libraries with 
only the components you need. 


# Camilo Calendar Todo #
##Β Β Β Β Β Β Β  2016Β Β Β Β Β Β Β  ##


### Wed 03/16/2016 ###
* Transcribe your quotes 
Β Β Β  Took a while, let's clear them more often.
Β Β Β  > Done.

* See if we can finish the notes templates blog post
Β Β Β  Lots of info, will take a while...
    > Done.

### Thu 03/17/2016 ###
* Solidify cat RCL spreadsheet for KiCad.
    Based on IPC standards.


# Camilo Pending Todo #


### Unscheduled Tasks ###
* Fix music mp3 tags.

* Do taxes.



# Camilo Recurrent Todo #

### Monthly Todo ###
* Unison Synchronization of all devices.

* Transcribe your personal quotes.

### Daily Todo ###
* Work on book summary.

* Learn about KiCad (tasks in order).

* Practice accordion.

### Sundays Todo ###
* Do Laundry.

* Clean/organize Room.


As an added bonus, I also have been working on a couple of scripts to help me manipulate these text files (e.g. find text, create new annual calendar …etc).

Let me know what y’all think, hope it helps some lost soul somewhere out there.

enjoy and share with others πŸ™‚