org-ref is available on Melpa so to install it just type M-x package-install org-ref. Afterwards copy the code below to your init file and adjust the paths:

  (setq reftex-default-bibliography '("~/Dropbox/bibliography/references.bib"))
  ;; see org-ref for use of these variables
  (setq org-ref-bibliography-notes "~/Dropbox/bibliography/notes.org"
	org-ref-default-bibliography '("~/Dropbox/bibliography/references.bib")
	org-ref-pdf-directory "~/Dropbox/bibliography/bibtex-pdfs/")

  (setq bibtex-completion-bibliography "~/Dropbox/bibliography/references.bib"
	bibtex-completion-library-path "~/Dropbox/bibliography/bibtex-pdfs"
	bibtex-completion-notes-path "~/Dropbox/bibliography/helm-bibtex-notes")

With org-ref in place, it was time to setup the reading list so I created a new file named reading-list.org under ~/Dropbox/bibliography/ with the following header:

  #+TITLE: Reading list
  #+STATUS: "Maybe" "Pending" "Reading" "Finished" ""
  #+COLUMNS: %120ITEM %STATUS

The first line obviously defines the title of the document. The second line defines the values for status where:

• Maybe means that reading the entry is optional
• Pending - the entry will be read sometime after finishing the item that I'm currently reading
• Reading - the item currently being read
• Finished - the entries that are already read.

• Add bibtex entry in references.bib file. E.g.:

      @inproceedings{le2014distributed,
        title={Distributed representations of sentences and documents},
        author={Le, Quoc and Mikolov, Tomas},
        booktitle={Proceedings of the 31st International Conference on Machine Learning (ICML-14)},
        pages={1188--1196},
        year={2014}
      }
  

• In the reading-list.org file add the title to the list using M-return
• Add Status and Source properties
  • With the cursor on the header:
    • Press C-c C-x p
    • Select or write Status
    • Press return
    • Select the value for status (e. g. Pending)
    • Press return
  • With the cursor on the header:
    • Press C-c C-x p
    • Write or select Source
    • Press return
    • If you know the citation key (le2014distributed in the example above) then you can write directly cite:le2014distributed; otherwise, leave the value for Source empty and put the cursor after the property declaration. Then, press C-c ] and select the entry from the reference list.

Repeat the steps above and you should end up with a list like this:

To change the status of an entry:

• Navigate to the desired entry
• Repeat the steps above for setting the Status property and select the proper value for Status

After creating the list you may want to have an overview of the status for each entry. This can be achieved using Org Column View. The setup for column view is in the third line of the header

  #+COLUMNS: %120ITEM %STATUS

which tells org-mode how to display the entries. Namely, we're defining two columns:

1. Item which will display the heading on 120 characters and
2. Status which will take as much space as needed to display the status

1. The org-ref manual
2. Managing papers with Org-Mode and RefTex
3. Org Manual - Defining columns

This one is simple; just run:

  sudo apt-get install mysql-client

The first thing to do is to head to Docker documentation for instalation instructions which I've copied here:

• Install packages to allow apt to use a repository over HTTPS:

     sudo apt-get install \
         apt-transport-https \
         ca-certificates \
         curl \
         software-properties-common
  

• Add the official GPG key for Docker

     curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
  

• Setup the stable repository. Make sure to select the proper architecture; in my case it's amd64

     sudo add-apt-repository \
         "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
         $(lsb_release -cs) \
         stable"
  

• Update the package index

     sudo apt-get update
  

• Install Docker

     sudo apt-get install docker-ce
  

• Download the Docker image for MySQL

     sudo docker pull mysql
  

• Create an empty database

     sudo docker run --name <container-name> -e MYSQL_ROOT_PASSWORD=<password> -e MYSQL_DATABASE=<db-name> -d mysql
  

  This will create a new container with an empty database and login root.

• Restore database from dump

     sudo docker exec -i <container-name> mysql -u<user-name> -p<password> --database=<db-name> < <path-to-sql-file>
  

  Notes:

  1. Make sure that there is no space between -u and <user-name>, e.g. for user root the option should be -uroot
  2. The same goes for password - e.g. if password is my-secret then the option should be -pmy-secret
  3. path-to-sql-file should point to a file on host OS

• First, start the container sudo docker start <container-name>
• Get the IP Address of the container
• Get the container configuration using sudo docker inspect <container-name>
• Copy the IP Address from the output under NetworkSettings/IPAddress
• In Emacs execute M-x sql-mysql
  • For User: enter the value for <user-name> (root is the default)
  • For Password: enter the value for <password>
  • For Database: enter the value for <db-name>
  • For Server: enter the IP Address from 2.

That's it. Happy querying!

I use Emacs 25.2 on Kubuntu 17.04 and on Windows 10 using Cygwin and when working with remote files both systems behave the same.

1. Configure the remote machine to authenticate you with a key file as specified in this stackoverflow answer
2. Start Emacs

To open the remote file for editing invoke the find-file command either using C-x C-f (C = Ctrl) or with M-x find-file (M=Alt) and at the file prompt specify the path in the following format:

  /ssh:user@ip[:port]:path/to/file

To exemplify let's consider the following scenario: I have a virtual machine with the IP 192.168.13.13 to which I can connect remotely with ssh using the username petru and the default public key (~/.ssh/id_rsa.pub). On that machine I want to edit the file /home/petru/src/debugutils.py.

To do so, I open the file as usually in Emacs using C-x C-f and at the prompt (the minibuffer) I enter the following:

  /ssh:petru@192.168.13.13:/home/petru/src/debugutils.py

and press <Enter>.

Let's look at the simplest problem Steve mentiones - displaying enum values in the UI. Indeed using the DescriptionAttribute is not the best solution you can have.

The biggest grudge I have with DescriptionAttribute is that it doesn't play nice with applications that have to support multiple languages. However, for the past few years (basically since extension methods were added to .NET Framework) I've taken another approach on displaying enum values in the UI.

The idea behind this is simple - build a Dictionary<TEnum, string> where the keys are enum values and values are localized strings taken from a resource file and bind the results to whatever control is used to display the enum. And for that I use a single extension method:

  public static class EnumUtils
  {
      public static Dictionary<T, string> GetLocalizedEnumValues<T>(this ResourceManager resourceManager)
      {
	  return Enum.GetValues(typeof(T))
	      .Cast<T>()
	      .Select(val => new { Value = val, Text = resourceManager.GetString(val.ToString()) })
	      .ToDictionary(kvp => kvp.Value, kvp => kvp.Text);
      }
  }

Of course, this method relies on a convention that the resource file must have entries for each enum value in order for it to work but when working with applications that support multiple languages there is seldom a case when something that needs to be displayed in the UI is not localized.

And now let's look at how this method can be used to localize enum values; as the example platform let's consider ASP.NET MVC:

  public class ThemeController : Controller
  {
      public ActionResult Index()
      {
	  var viewModel = new ThemeViewModel
	  {
	      WeekDays = Resources.ResourceManager.GetLocalizedEnumValues<WeekDay>()
		  .Select(kvp => new SelectListItem { Value = kvp.Key, Text = kvp.Value})
	  };
	  return View(viewModel);
      }
  }

Granted, it's more work to do in order to display enums like this but there are advantages:

• No magic strings are involved compared to using DescriptionAttribute
• You have to do less repetitive work. If you declare your enum in a type safe manner you'll have the tedious task of pairing each enum value with its (localized) description by hand; GetlocalizedEnumValues method will do that automatically for all enums which have entries in the resources file.

Now, let's address the bigger issue when dealing with enums, namely calling (in our case) themeSelector.GetTheme((WeekDay)13). The problem here is that a lot of developers don't use defensive programming when dealing with enums (or at all).

Let's consider how our GetTheme method would look like in a non-defensive style and to emphasize things let's look at the worst-case scenario:

  public class ThemeSelector
  {
      public Theme GetTheme(WeekDay weekDay)
      {
	  switch(weekDay)
	      case WeekDay.Monday:
		  return new Theme { Playlist = "Monday mood" };
	      case WeekDay.Tuesday:
		  return new Theme { Playlist = "Four more days to Friday" };
	      case WeekDay.Wednesday:
		  return new Theme { Playlist = "It's hump day already!" };
	      case WeekDay.Thursday:
		  return new Theme { Playlist = "One more day!" };
	      case WeekDay.Friday:
		  return new Theme { Playlist = "Friday margueritas!" };
	      case WeekDay.Saturday:
		  return new Theme { Playlist = "Go away hangover!" };
	      case WeekDay.Sunday:
	      default: // BAD!!!
		  return new Theme { Playlist = "There's still time to party!" };
      }
  }

See the problem there? The developer assumes that the method will always receive a valid value thus he/she links the default case with an existing label instead of checking the value.

The simplest fix for this is below:

  public class ThemeSelector
  {
      public Theme GetTheme(WeekDay weekDay)
      {
	  switch(weekDay)
	      case WeekDay.Monday:
		  return new Theme { Playlist = "Monday mood" };
	      case WeekDay.Tuesday:
		  return new Theme { Playlist = "Four more days to Friday" };
	      case WeekDay.Wednesday:
		  return new Theme { Playlist = "It's hump day already!" };
	      case WeekDay.Thursday:
		  return new Theme { Playlist = "One more day!" };
	      case WeekDay.Friday:
		  return new Theme { Playlist = "Friday margueritas!" };
	      case WeekDay.Saturday:
		  return new Theme { Playlist = "Go away hangover!" };
	      case WeekDay.Sunday:
		  return new Theme { Playlist = "There's still time to party!" };
	      default:
		  throw new ArgumentException("Invalid value for WeekDay enum.");
      }
  }

Throwing the ArgumentException when receiving an invalid value will crash the application but this crash gives us at least two benefits:

• The application behavior becomes predictable: GetTheme method will either return a valid Theme or will throw an error
• It makes debugging a lot easier; you know the point of failure, you know the reason and you have the full stack trace. When the application crashes twenty steps after receiving the invalid value there are a lot more unknows to why the application crashed and it may be harder to reproduce the problem.

However, the best way to use switch statements is to avoid it altoghether. Why? Mainly because switch statements are the main violators of Open/Closed Principle i.e.every time a new member of the enum is added, every switch on that enum values needs to be changed in order to accomodate the new member (except for the cases that use the default label).

In such cases I prefer to use something that I call specialized builders to avoid the switch statement.

The ideea is simple: the logic behind each label of the switch statement is refactored into a separate class which implements a common interface for all the labels. The same interface exposes a property of the enum type which tells the clients of the interface which enum value it can process. The client code receives as a dependency a collection of such instances and instead of a switch statement it just iterates through the collection to find the suitable instance.

Let's exemplify using our scenario; instead of having the switch statement inside the GetTheme method from the previous example, let's refactor each labels logic into a separate class. But before that, let's define an interface that will be implemented by all the classes.

Since the switch is used to build instances of Theme class, let's call the interface IThemeBuilder; here is it's definition:

  public interface IThemeBuilder
  {
      WeekDay WeekDay { get; }

      Theme BuildTheme();
  }

Now an implementation of this interface for WeekDay.Monday would look like this:

  public class MondayThemeBuilder
  {
      public WeekDay WeekDay
      {
	  get { return WeekDay.Monday; }
      }

      public Theme BuildTheme()
      {
	  return new Theme { Playlist = "Monday mood" };
      }
  }

With all the implementations in place, all it remains to do is to register the implementations of IThemeBuilder interface in the DI container and inject them into the ThemeSelector class. The GetTheme method now becomes an iteration to find a suitable builder for the argument received. If no such instance is found, an exception is thrown to signal the error.

  public class ThemeSelector
  {
      private readonly IEnumerable<ThemeBuilder> builders;

      public ThemeSelector(IEnumerable<IThemeBuilder> themeBuilders)
      {
	  builders = themeBuilders;
      }

      public Theme GetTheme(WeekDay weekDay)
      {
	  var builder = builders.SingleOrDefault(b => b.WeekDay == weekDay);
	  if( builder == null)
	      throw new ArgumentException(String.Format("Invalid value '{0}' received for week day.", weekDay));
	  return builder.BuildTheme();
      }
  }

Now everytime a new member needs to be added to WeekDay enum, although not the case here, there are at most three changes to make to accomodate the new value:

1. Add the new value to the enum
2. Create a new class that will implement IThemeBuilder for the new value
3. Register the new class in the DI container

Depending on which dependency injection library you use, there may be no change required for registering the new class in the container.

The main conclusion of the article is that enums aren't bad they're just improperly used. Sometimes creating a thick class to represent type safe enums may be suitable for your scenario but most of the time it's not worth the effort. Instead, you should concentrate more on the places in code where the enum is used to make them safer, more clean and elegant.

Abstraction is a core concept in programming and not a principle that is solely applicable in OOP, because programming is all about dealing with an abstract representation of the business model (application space).

There are a lot of articles saying that OOP has four principles:

• Encapsulation
• Inheritance
• Polymorphism
• Abstraction

But if we do a web searh for what is abstraction? we get more or less the same definition as the one from here.

Abstraction (from the Latin abs, meaning away from and trahere, meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.

Although the article defines abstraction in an OOP context, abstraction is actually a an overall programming principle.

Why? Because programming means modeling entities and interactions of an abstract representation of the business model. And since there are several programming paradigms all of which are used to represent a set of specific business models all of those paradigms use abstraction to succeed in that representation.

To better clarify what abstraction is (in OOP) let's consider a trivial example: A StudentRegistrationController (ASP.NET MVC) needs to save the data from a registration form (Student) into some sort of database represented by an instance of IStudentDataStore.

For the sake of brevity let's say that IStudentDataStore interface has the following definition:

  public interface IStudentDataStore
  {
      void Save(Student student);
  }

With that in mind, the code for the example above would look like this:

  public class Student
  {
      public string FirstName { get; set; }

      public string LastName { get; set; }

      public DateTime DateOfBirth { get; set; }

      public Gender Gender { get; set; }

      public string Email { get; set; }

      public string PhoneNumber { get; set; }
  }

  public class StudentRegistrationController : Controller
  {
      public StudentRegistrationController(IStudentDataStore dataStore)
      {
	  _dataStore = dataStore;
      }

      public ActionResult Save(Student viewModel)
      {
	  // Validation ommited for brevity
	  _dataStore.Save(viewModel);
      }
  }

As we can see from the code the IStudentDataStore abstracts the details of how Student data is persisted. The interface doesn't tell whether the data is persisted to a flat file, SQL Database, NoSQL database or other media. As long as we have an implementation of IStudentDataStore the controller works just fine.

But is this abstraction technique available only in OOP paradigm? The answer is no. The same thing, although in a different form can be used in other paradigms. To demonstrate so, let's use lisp as a programming language and let's see how abstraction works in a functional programming paradigm.

To see how the same thing would be written in a functional style let's first see what are the entities from the previous example and how those entities interact between them:

• StudentRegistrationController
  • Is the top-most entity
  • Has an IStudentDataStore on which calls the Save method
• IStudentDataStore
  • Defines a contract between the controller and the underlying data store
• Student
  • Is a data contract, i.e. encapsulates all the properties of a student into a single entity

Having the above and knowing that in functional programming everything is a function we replace every entity with a function:

• We'll create a top-level function named save-student; it will have the following parameters:
  • student-info -> a hash map containing the data contract
  • persist-func -> a function that will be called to save the data to a data store
• Another two functions persist-student-info-to-file and persist-student-info-in-memory will encapsulate the logic of persisting data to a data store.

Note that both functions have the same signature. The parameters of these functions represent the data contract.

  (defun persist-student-info-to-file (first-name last-name dob gender email phone)
    ;; Writes the info as a new line into the file specified by *database-location*
    (let ((stream (open *database-location*
		:direction :output
		:if-exists :append)))
      (format stream "~s|~s|~s|~s|~s|~s"
	  first-name
	  last-name
	  dob
	  gender
	  email
	  phone)
      (close stream)))


  (defun persist-student-info-in-memory (first-name last-name dob gender email phone)
    ;; Persists student data into an in-memory data store named *all-students*
    (let ((student-id (list-length *all-students*)))
      (setq *all-students*
	(append *all-students*
	    (list student-id first-name last-name dob gender email phone)))))

  (defun save-student (student-info persist-func)
    ;; Saves student data to a persistent store
    (let ((first-name (gethash 'first-name student-info))
	  (last-name (gethash 'last-name student-info))
	  (dob (gethash 'date-of-birth student-info))
	  (gender (gethash 'gender student-info))
	  (email (gethash 'email student-info))
	  (phone (gethash 'phone-number student-info)))
      (funcall persist-func first-name last-name dob gender email phone)))

Having the definitions above we can achieve the same level of abstraction by putting everything together and defining global variables (think of it as poor mans dependency injection):

  (defparameter *database-location* "/tmp/students")
  (defparameter *student-info* (make-hash-table))

  (progn
    (setf (gethash 'first-name *student-info*) "John")
    (setf (gethash 'last-name *student-info*) "Doe")
    (setf (gethash 'date-of-birth *student-info) "2000-05-14")
    (setf (gethash 'email *student-info*) "john.doe@example.com")
    (setf (gethash 'phone-number *student-info*) "1234567981"))

  (save-student *student-info* 'persist-student-info-to-file)

Et voilà! We have used abstraction in a functional style to remove the details of how the data is persisted thus showing that abstraction isn't a principle applicable only to object oriented programming.

A big thank you to Ion Cojocaru and Florin Olariu who reviewed this post before publication.