Better applications with Unix Philosophy
Tags: webdev, opensource, linux, programming
Published: 2020-04-14 16:41:55

---
title: Better applications with Unix Philosophy
published: true
description: 
tags: webdev, opensource, linux, programming
series: devpath
---

Unix system works with command, a small program with a lot of possibilities, and we will take a closer look at their use.
Because this ecosystem is based on a philosophy very useful for any software and web application.
Note: 5 and 6 are not directly related to Unix philosophy :)


## 1. One tool do one job done 🔬
It's sound like [Single Responsability](https://dev.to/trekhleb/s-o-l-i-d-principles-around-you-1o17) and it is, 
in Unix system you find *chown* to change owner of a file, but if you want to create a new user, you should use *useradd*.
So, rights management is divised into many commands.

In his book Rework, Jason Fried regrets that the applications became heavy, with so many features:
it's difficult to maintain, and the user is lost. 
We have plugin architecture, we use it in our browser (and IDE and it helped them get their groove on).

So start with **minimal functionality** and add feature with **plugin**. 
A good example is [this todo app](https://app.super-productivity.com) by johannesjo.
You can read [this article](https://dev.to/arcanis/plugin-systems-when-why-58pp) by arcanis (Javascript).


## 2. Tools are cumulative 🔗

In Unix this is *pipe*: result of the first command go in the second command.
For example *grep* to search a keyword: *history | grep keyword*: data returned by *history* are filtered by *grep*.
This compatibility allow a command to be used with another.

To make this, input or output of **your application must be compatible with another application**, 
this is why so many application allow to export (or import) in a **standard format** (csv, xml, json etc) and it's great, we can export data, treat them with another software, re-import them, you should always give this possibility to your user.


## 3. Norms and conventions 🌐
In Unix they're some conventions (not always respected):
- return code (0 for ok, 1 for minor erreur, 2 for fail)
- arguments (-h for help, -v for verbose...)
- paths (config, binary, logs, user profile files)

It's helpful for debug, for integration, backup, and to learn and understand application. For example, command and keywords in docker are similar to Unix ones (ls, ps, commit, env), it's easy to remember them. If your user already know keywords (from another application) for the same usage, it will facilitate learning curve to use the same.

Another example: IDE allow to use keyboard shortcuts of another IDE, it's perfect, your user can keep his habits.

And if your system recommand some rules, please respect them, and your user won't be looking during hours where is the log file :)


## 4. Extendable with configuration 🎲
In Debian system *apt* is the tool to manage packages (softwares and os updates).
You can create a Debian package for anything you want, for example a simple configuration file. 
So if you set up a personal package repository link in *apt* configuration file you'll get theses packages.

Application working with file don't care if theses file are local, on usb key, on a network or on web hosting.
They expecting a file and don't care about the source.

So if your application can read data from many sources without problem, allow a configuration for it.


## 5. Intuitive usage 🙂
Unix an comand line interface are not so friendly but autocompletion helps a lot. 
If you can implement some helper or search query builder it's always appreciated.

*Alias* is a command to make a personnal shortcut:
for example *alias cgst='clear && git status'*.
It's a favorite shortcut, for example in a transportation app, user can choose a geographical point as favorite (home, work place, library, ...).

In Unix system you can find the command *wereis* to locate binary of another command, *whatis* to explain a command, 
*man* to show documentation, *whence* to show if *alias* is used, etc.
This is great because it help user to have a fast overview of a software, where it is, what it do, how to use it.


## 6. Attractive Documentation 🎠
Unix system has man pages and so many documentation online (great community).
So manual, wiki and  FAQ or QA forum are some basics, but there is some idea for more attractive solutions:

- Readme: with common usage and frequent problem. See [How to write kickass Readme](https://dev.to/scottydocs/how-to-write-a-kickass-readme-5af9)
- Tutorial/Cookbook: advanced usage and usage categorized by needs/profile user/...
- cheat sheet: a list with all command or and annoted screenshot of the interface
- sandbox mode: allow user to dive into dangerous command without losing real data or web tool like [Git School](https://git-school.github.io/visualizing-git/).
- changelog with Gif: look at VSCode changelog or [vscodecandothat](https://vscodecandothat.com)
- alternative list: do a comparative listing concurrent alternative, 
because when we are looking for an alternative to Trello we type trello (rarely kanban).
so it's great for SEO (especially on Github).


## Conclusion:

- Start with minimal interface and add features in plugin
- Allow to export (and import) in standart format (json, csv, ...)
- Respect the OS norms, conventions, habits
- Allow configuration to extend your application usage
- Help user (autocompletion, favorite shortcut)
- Write attractive documentation


Learn more:
- [The (real) Unix philosophy](https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html)
- You want to start working with Linux/MacOS command line: see [IBM free articles](https://developer.ibm.com/technologies/linux/tutorials/l-lpic1-map) and the [explainshell webtool](https://explainshell.com)


Thanks for reading - Stay safe.
Sorry for the typo and mistakes (*#french* *#confinmentDay30*)