loading...

Better applications with Unix Philosophy

cotcotcoder profile image JeffD ・4 min read

devpath (2 Part Series)

1) 7 advices after 10 years of development 2) Better applications with Unix Philosophy

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 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 by johannesjo.
You can read this article 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
  • 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.
  • changelog with Gif: look at VSCode changelog or vscodecandothat
  • 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:

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

devpath (2 Part Series)

1) 7 advices after 10 years of development 2) Better applications with Unix Philosophy

Posted on by:

cotcotcoder profile

JeffD

@cotcotcoder

Developper, slow matured ten years in Web barrels, with Python flavour and opensource edge. Conference volunteer and hackathon participant. #tech4Good #minimalist #privacy #DIY

Discussion

markdown guide