Forem: Digital Clouds

Summarized feature-rich plugin manager for Zsh

Sall — Wed, 12 Jan 2022 15:57:06 +0000

❮ ZI ❯ is a fast and feature-rich plugin manager for Zsh - Unix shell.

Fast user experience

Has a turbo mode that yields 50-80% faster Zsh startup.

Stay flexible

Run programs and scripts without adding anything to $PATH,
Install and run Ruby Gems, Node, and Python modules from within a local directory with $GEM_HOME, $NODE_PATH, and $VIRTUALENV automatically set,
Run programs, scripts, and functions with automatic cd into the plugin or snippet directory, plus also with automatic standard output & standard error redirecting.
Source scripts through an automatically created function with the above $GEM_HOME, $NODE_PATH, $VIRTUALENV, and cd features available,
Create the so-called shims known from rbenv – the same feature as the first item of this enumeration – of running a program without adding anything to $PATH with all of the above features, however through an automatic script created in $ZPFX/bin, not a function (the first item uses a function-based mechanism),
Automatic updates of Ruby gems and Node modules during regular plugin and snippet updates with zi update ….
Install almost everything from GitHub, and other Git providers.

Detailed information on how it works and how to achieve it is found in the wiki

Use what you want - not only what you can.

Supports loading Oh My Zsh and Prezto plugins and libraries, however, the implementation isn't framework-specific and doesn't bloat the plugin manager with such code, it allows to use of any framework. See our wiki on how to migrate from other plugin managers.

Boost performance with integrated tools

The dedicated packages offload the user from providing long and complex commands. See the Z-Shell ZI organization for a complete list of packages.
The specialized extensions — so-called annexes — expand with new commands, URL per-processors (used by e.g.: z-a-readurl annex), post-install and post-update hooks, and much more.

Keep it clean and consistent

The system does not use $FPATH, loading multiple plugins doesn't clutter $FPATH with the same number of entries (e.g. 10, 15, or more). Code is immune to KSH_ARRAYS and other options typically causing compatibility problems.

Focus on What Matters

Provides reports and statistics about the plugins, such as:

aliases
functions
bindkeys
zle widgets
zstyles
completions management
PATH, and FPATH elements.

Allows to quickly familiarize oneself with a new plugin and provides rich and easy-to-digest information that might be helpful on various occasions.
Supports the unloading of plugins and the ability to list, (un)install, and selectively disable, enable plugin's completions.

Documentation

ZI Wiki pages are often improved and updated. Easily find the topic you are looking for with the wiki search

New to Zsh or just need support?

Simply start a discussion and we will help. There is no such thing as a bad question - just ask :)

Join the open-source

Friendly for new contributors!

It's a good place to start with or just to show off your skills as we have almost 100 repositories that require different types of developers with different types of experience.

GitHub Org: z-shell

Unlimited and free uptime monitor and status page

Sall — Wed, 12 Jan 2022 08:30:05 +0000

With Upptime, you can get your own unlimited and free uptime monitor and status page, powered entirely by a GitHub repository. It uses Issues as incident reports, Actions as uptime monitors, and Pages for the status page. It is easy, fast, efficient, and costs nothing.

Upptime will automatically open a new issue when an outage occurs

If you haven't identified the cause of this outage, you can add a comment like: "Investigating: We're currently investigating the cause of this outage, and we'll update the details here shortly."
Then, you can add some comments with the details of the outage, and change the name of the issue with the details of the outage
The issue will be automatically closed when the site comes back up, so you can add a last comment with a postmortem of the outage disable Actions by default, you'll have to manually enable GitHub Actions, but this should probably not be your case.

Create a repository from the template

As an example, this is the repository I had set up. To use Upptime as an uptime monitor and status website generator, you start by creating a repository using the template on GitHub.

You can click on the following link to generate a repository using the template: Create a new repository from upptime/upptime. Alternatively, you can visit the Upptime repository on GitHub and click on the "Use this template" button on the top-right.

In both cases, the next steps are:

Enter a name for your new repository.
Important: Check "Include all branches".
Click on "Create repository from template".

For more details on how to create repositories using template, read the article on the GitHub website: Creating a repository from a template.

Billing note: Upptime uses thousands of build minutes every month (approximately 3,000 minutes in the default setting). If you use a public repository, GitHub offers unlimited free build minutes, but if you use a private repository, you'll have to pay for this time.

After creating your repository

The following steps apply to your new repository, not the upptime/upptime template repository.

Enable publishing

To get a static status website, you have to enable GitHub Pages on your new repository.

Go to your repository settings page
Go to the "Pages" sub-section on the left
Under "Source", change "None" to gh-pages
In the folder dropdown, select /(root)
Skip the "Theme Chooser" option
Click on "Save"

After saving, you will see confirmation text "Your site is ready to be published at...". For more information on enabling GitHub Pages, see the article on the GitHub website: Configuring a publishing source for your GitHub Pages site.

If you don't want to have a publicly-available status website, you don't have to enable publishing. If that is the case, you can also choose to keep your repository private. It is not possible to publish a status website from a private repository without using an API proxy with authentication. See #54 and the Configuration for apiBaseUrl to learn how to set up a status website from your private repository.

Add repository secrets

All sensitive information required, such as API keys, are provided as environment variables. These are stored as GitHub repository secrets (see Creating and storing encrypted secrets).

To make commits and publish your website, Upptime requires a personal access token (PAT) with the repo and workflow scope, stored as a repository secret GH_PAT. You can create a personal access token by following these steps:

Click on your profile picture on the top-right corner and select "Settings"
In the left sidebar, select "Developer settings"
In the left sidebar, click "Personal access tokens"
Click "Generate new token"
Select the "repo" and "workflow" scopes
Click "Generate token"

After generating your token, copy it (you will not see it again). Then, add it as a repository secret:

In your Upptime repository, select "Settings"
In the left sidebar, click "Secrets"
Press the button "New repository secret"
Enter the name of the secret as GH_PAT
Paste your personal access token into the Value field
Be sure there are no spaces before or after the token and/or linebreaks after your token
Save your PAT by selecting "Add secret"

For more information on PATs, read article on the GitHub website: Creating a personal access token.

Update configuration

The .upptimerc.yml file is used as the central configuration store. In that file, you can specify which endpoints you want to monitor and configure your status website. For more information, visit Configuration.

You can start by adding your endpoints under sites, here is example of .upptimerc.yml:

owner: koj-co # GitHub username
repo: upptime # GitHub repository name
sites: # List of endpoints to track
  - name: Google
    url: https://www.google.com
assignees: # Users to assign downtime issues (optional)
  - AnandChowdhary
status-website: # Status website (optional)
  cname: upptime.js.org # Custom domain CNAME
  name: Upptime # Status website title

If you're not using a custom domain, you can remove the line starting with cname: and instead add the GitHub repository name:

status-website:
  baseUrl: /repo # where "repo" is your repository name
  name: Your Status Website

Then, your status page may be hosted on https://user.github.io/repo/, where user is your GitHub username and repo is your repository name.

Viewing GitHub Actions workflows

After updating the configuration file, Upptime should run workflows using GitHub Actions to update your README.md and generate API endpoints and graphs. To view the status, click on the "Actions" tab in your repository. You should see pending or complete workflows. If you don't, you can manually trigger the "Setup CI" using the Triggers article.
If you've forked the Upptime repository or have rules to disable Actions by default, you'll have to manually enable GitHub Actions, but this should probably not be your case.

Are you a writer?

Sall — Tue, 28 Dec 2021 05:30:31 +0000

📜

Are you a code-newbie and want to start coding?
Are you a content writer and want to build your name?
Do you like open-source and would like to give it a try?
Or maybe you are somewhere in between or just want to be a better writer. Well, then we might make a good team.

⚙️
I am the owner and co-maintainer of several projects with a few hundred repositories. Some projects might have several issues despite they are or could be a masterpiece. For reasons like:

It doesn’t matter how good software is because if the documentation is not good enough, people will not use it.
Even if for some reason they have to use it, without good
documentation, they won’t use it effectively or the way you’d like them to.
You using your code in 6 months. Code that was written 6 months ago is often indistinguishable from code that someone else has written today.

And many more similar issues.

🔥

This is where we could make a great team:

🎨
I can provide tools and content on many different topics. If you can write and organise the docs then you are the author of those docs which means you are the co-maintainer of the project. It doesn't necessarily have to be published or advertised. You will have all the rights to share it as yours having interesting material to write about. If you make reasonable progress - your work can be evaluated by professionals with detailed feedback which is very beneficial for the carrier and self-evaluation. Depending on time and progress more access and more popular projects can be introduced. 🚀

👨‍🚀
What is expected?

Keep a lighthearted friendly tone. Treat the reader as someone who doesn't have a lot of knowledge about the topic but is very interested. ❤️
Keep things brief 👁‍🗨
Use headings frequently. This breaks things up when reading and often it is good for linking to specific information.
Link to other places in the documentation often but only for additional information. Readers should not have to navigate through several pages to find information regarding one specific thing. Just inline the immediately relevant information and link off if they want to know more.
Use as many code snippets, CLI, etc. examples as possible. Show the reader what you mean
Gently introduce a guide before diving into technical details. This gives context and readers are more likely to stay engaged longer
It is always good to describe the functionality of the various files in the project.
Always use gender-neutral pronouns. A gender-neutral pronoun is a pronoun that does not associate a gender with the individual who is being discussed. 👍🏿
For e.g. using 'they' instead of 'he/she'. ❤️

That's all! Friendly to code-newbies. Many things can be discussed to benefit everyone. 👍🏼

https://developers.google.com/tech-writing

If you like to discuss or give it a try reach out:

digitalclouds@pm.me
admin@digitalclouds.dev
sall@digitalclouds.pro