Giter Club home page Giter Club logo

sjb_cheatsheet's Introduction

Overview

A simple CRUD command-line program for working with 'cheat sheets'

This project is licensed under the MIT license.

sjb-cheatsheet is a simple command-line program to add entries to a cheat sheet and display them in an organized manner. Similar to 'git' this program has subcommands to interact with the cheatsheet. The basic subcommands are 'add', 'show', 'remove', and 'update'

Each cheatsheet entry has four components:

  1. Clue - this is a short description of the cheat sheet entry. For example 'markdown italics' would be a valid clue.
  2. Answer - this is the long explanation of the clue. In the above example, the answer could be 'Italics are done with asterisks like this'
  3. Primary - this is the primary tag classifying this entry. In the above example, this could be 'markdown'
  4. Tags - These are any other tags which might apply to the entry. In the above example this could be 'formatting'

The basic idea is to centralize all 'cheat sheet' like notes into a single file. Then to see all notes concerning a single topic you can filter them by the primary tag or secondary tags.

Installation

This program is in pre-alpha and is not using any deployment tools so I make zero guarantees about installation.

However, I have written a crude script that should more or less work provided the user has python3.6 installed in a linux environment and has all of the required python dependencies. Since these dependencies are subject to change, and this is my first time writing a deployed python app, I have not bothered to record them or incorporate them into the install script. In the future I hope to fix this.

Instructions

$ cd <this directory>
$ ./install.sh
$ mkdir -p ~/.local/share/sjb/cheatsheet

where <this directory> is the directory containing this README file. Also it's important that you run ./install.sh as a regular user (dont use sudo).

Developing

There is a script setup_dev.sh which sets up a virtual environment. This causes sjb-cheatsheet to execute the local code in src instead of the code installed on the system.

To enter the development environment:

$ cd <this directory>
$ . setup_dev.sh

where <this directory> is the directory containing this README file.

To leave the development environment just type:

$ deactivate

Warning: the development environment still uses the same data files as the real environment. This will eventually be fixed.

Usage

See sjb-cheatsheet -h for more information. The most basic usage of this program could consist of just the 'add' and 'show' commands.

Example

$ sjb-cheatsheet add bash echo 'echo is a simple program that prints its argument to stdout' bash,unix,posix
$ sjb-cheatsheet add python 'get user input' 'In python2, raw_input() is a simple way to get user input. In python3, input(msg) is preferred.' python,code
$ sjb-cheatsheet show
1  bash             bash, unix, posix
   echo             echo is a simple program that prints its argument to
                    stdout
2  python           python,code
   get user input   In python2, raw_input() is a simple way to get user
                    input. In python3, input(msg) is preferred.
$ sjb-cheatsheet show --tags python
2  get user input   In python2, raw_input() is a simple way to get user
                    input. In python3, input(msg) is preferred.

sjb_cheatsheet's People

Watchers

Sam Bryant avatar

sjb_cheatsheet's Issues

[Feature] Look into adding artificial typedefing

I have seen projects with rigid type markup in docstrings. I have also seen projects that have rigid typing using decorators.

Both of these might be overkill, especially if there is unit testing. But we I should at least consider the idea

[Feature] Make program prompt when adding to a new cheatsheet list (error otherwise)

Currently the program outputs an unhelpful, not-user friendly warnings.warning message when dealing with a non-existent list file. This should be switched to more explicitly handling, similar to how adding new tags works.

Keep in mind that the user interaction stuff should remain strictly on the frontend. Keep the backend agnostic.

[Feature] Change default show format

By default, the cheatsheet should sort by the primary tag. When outputting all of the entires, each different primary tag should be like a section title, listed once followed by all of its entries with the primary tag ommited. In this style, the individual entries can look more like the todo entries (with secondary tags shown via hashtags).

Example:

*** linux ***
21 cp -p 'Copies files while preserving the mod, ownership and timestamp attributes'
23 brightness 'the brightness file is at /sys/class/backlight/intel_backlight #system'
*** i3 ***
36 mod+sh+sp 'Togle between floating and tiling mode'

[Feature] Merge this project into sjb-todo in a way that allows the pieces to stay modular

This might be impossible.

Recall: One of the key goals of this project is a lightweight library that handles lists in easy to understand reusable ways with minimal external dependencies. The project should be decoupled from other efforts.

However, there is a lot of code overlap between this project and sjb_todo (in fact the Issues are basically identical).

I should consider trying to merge them into a single github project in a way that allows for them to be installed separately.

depends on #3

[Feature] Add a better search system

the 'show' command is limited in it's ability to search by essentially just filtering tags.

Add a search system with a more powerful interface. It should be able to look for a term in text or tags. It should have the ability to consider conjunctions of smaller statements. It should have the ability to invert things

[Feature] Enable ability to edit entries in a text editor

Similar to git commit -a versus git commit -m 'message' (where the latter is what we currently do). Since entries can get very complex, we should allow the user to enter them via a text editor. The command line is really no place for what we are currently doing

Dynamic versioning from git

This may be impossible.

I would like to do the following: If the prog is being run from a venv (dev environment), then i would like --version to output the last official version followed by the local git commit (i.e. the output of git describe).

If the prog is being run from system, then it should do one of the following:

  1. Output the last committed version string.
  2. Output the same thing that 'git describe' would output on the revision that was last installed

Make app create directories as needed

The current app is "fragile". If the config or data directory doesnt exist, it will completely fail.

This should add the ability to create the base config/data dirs as needed, either at runtime or at install (maybe both).

[Feature] Testing environment automatically uses a different file

While there is a testing environment setup, currently it reads from the same data. I should add a flag in fileio.py to use a different list name by default whenever I'm in the testing environment.

Also in general, the application needs to be aware of whether or not it is running from the test environment

[Refactor] Proper logging

Currently the only warning in the system is generated via warn.warning which spits out unreadable text.

Ideally the user would never be aware that the backend is python.

Logging should be done the 'right way' without having to handroll anything. I don't know what this is though and I haven't explored it at all.

[Refactor] Split out program logic from main.py

Main.py should really only handle reading commands and arguments. The actually program behavior should be put into a new file, workflow.py.

I should take the time to describe in detail the separation of labor. But roughly it works like this:

classes.py: responsible for containing data and doing primitive operations
workflow.py: responsible for doing all application logic that should be exposed to the outside world (the public methods here should be 1-1 with the API)
main.py: the command line frontend to interact with workflow.py's commands

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.