project goes from scraping the data to EDA to prediction

The project is composed of 3 main parts:

• Data collection by scraping http://www.ufcstats.com/ with Scrapy
• Data preprocessing
• Predictive model with XGBoost

You can find the 2 scrapers for fightcards and fighters in their respective folders. More details about what information do we scrape are presented in the README file of these folders

The 2 csv raw file are what we obtain from the scrapers

The preprocessing notebook details all the steps that was used to arrive to the cleaned_dataset.csv

The EDA and predictor notebooks relies on the cleaned_dataset.csv that was produced by the preprocessing notebook

Admittedly, the predictor utilized the information that would only be available during the fight itself (such as the accuracy of punches, number of takedown attempts, etc.) therefore, in the context of predicting for an upcoming fight, the accuracy will be lower than the result previously mentioned.
One way to overcome this challenge would be to have a 3rd scraper that would focus on scraping the fight statistic of a fighter in the 3 previous fight prior to the match we want to predict.

• Sobrecarga de métodos é uma forma de termos mais de um método com o mesmo nome em nosso código. O que vai diferenciá-los é o tipo e quantidade de parâmetros recebidos. Com ela conseguimos aplicar o conceito de polimorfismo, no qual um comportamento responde de maneira diferente de acordo com os dados informados em sua chamada.
• Usamos o operador this para trabalhar com elementos da própria instância do objeto.
• Vimos boas práticas na organização de projetos como a organização dos arquivos em diretórios distintos, que irão facilitar futuras manutenções e até no entendimento do projeto com base em suas responsabilidades.

• Na orientação a objetos, a herança é um mecanismo que nos permite reaproveitar código.
• Podemos redefinir um comportamento escrito em uma classe base em uma classe derivada. Assim, ele passará a funcionar de forma específica em uma classe derivada.
• Acessamos definições presentes na classe base usando o operador base.

• Invocamos o construtor da classe base, a partir do construtor da classe derivada.
• Protegemos propriedades usando o operador de visibilidade protected para impedir o acesso direto a uma propriedade de um objeto.
• Utilizamos classes abstratas para definir uma classe que será modelo para criação de novas classes.
• Como usar métodos abstratos para definir como obrigatória a implementação de determinado comportamento em classes derivadas.

• Como adicionar uma nova classe à hierarquia de classes já definida com a intenção de atender a uma nova demanda do projeto.
• Avançamos na utilização da herança de classes fazendo uma classe herdar de outra.

• O C# não implementa o conceito de herança múltipla, pois classes muito distintas com métodos de mesmo nome poderiam causar problemas para o compilador definir qual usar na nova instância.
• O funcionamento das interfaces na orientação a objetos, que são contratos que definem comportamentos a serem implementados pelas classes que assinam este contrato.
• Como utilizar o padrão de nomenclatura adotada para nomeação de interfaces, aplicando a convenção que utiliza o prefixo I.

This repository contains the homework assignment for Node.js Master Class by Pirple that is focused on building a RESTful API, web app GUI, and a CLI in plain Node JS (ES6 Javascript) with no NPM or 3rd-party libraries.

You are building the API for a pizza-delivery company.

Here’s the spec from your project manager:

1. New users can be created, their information can be edited, and they can be deleted. We should store their name, email address, and street address.
2. Users can log in and log out by creating or destroying a token.
3. When a user is logged in, they should be able to GET all the possible menu items (these items can be hardcoded into the system).
4. A logged-in user should be able to fill a shopping cart with menu items
5. A logged-in user should be able to create an order. You should integrate with the Sandbox of Stripe.com to accept their payment. Note: Use the stripe sandbox for your testing. Follow this link and click on the “tokens” tab to see the fake tokens you can use server-side to confirm the integration is working.
6. When an order is placed, you should email the user a receipt. You should integrate with the sandbox of Mailgun.com for this. Note: Every Mailgun account comes with a sandbox email account domain (whatever@sandbox123.mailgun.org) that you can send from by default. So, there’s no need to setup any DNS for your domain for this task. Read more here.

It is time to build a simple frontend for the Pizza-Delivery API you created in Homework Assignment #2. Please create a web app that allows customers to:

1. SignUp on the site.
2. View all the items available to order.
3. Fill up a shopping cart.
4. Place an order (with fake credit card credentials), and receive an email receipt

It is time to build the Admin CLI for the pizza-delivery app you built in the previous assignments. Please build a CLI interface that would allow the manager of the pizza place to:

1. View all the current menu items.
2. View all the recent orders in the system (orders placed in the last 24 hours).
3. Lookup the details of a specific order by order ID.
4. View all the users who have signed up in the last 24 hours.
5. Lookup the details of a specific user by email address.

Too launch the application please run the following command from the project root folder:

node index.js

You may also run the application in debugging mode:

env NODE_DEBUG=server,stripe,mailgun,cli,workers node index.js

Running the APP for different environments:

NODE_ENV=staging node index.js

The APP is currently supporting staging (default) and production environments.

The following CLI command are available for the execution:

-----------------------------------------------------------------------------------------------------------
                               CLI Manual
-----------------------------------------------------------------------------------------------------------

exit                           Kill the CLI (and the rest of the application)

man                            Show this help page

help                           Alis of the "man" command

menus                          Show the list of available menu items (pizzas)

orders                         View all the recent orders in the system (orders placed in the last 24 hours)

order --{orderId}              Lookup the details of a specific order by order ID

users                          View all the users who have signed up in the last 24 hours

user --{email}                 Lookup the details of a specific user by email address

-----------------------------------------------------------------------------------------------------------

The following paths are available for the user in browser after launching the app.

Path: http://localhost:3000/

Path: http://localhost:3000/user/session/create

Path: http://localhost:3000/menu/list

Path: http://localhost:3000/user/cart/read

Path: http://localhost:3000/user/order/create

Path: http://localhost:3000/user/order/success

Path: http://localhost:3000/user/account/edit

The following endpoints are available from API perspective.

Request example:

curl -X GET http://localhost:3000/ping

Request example:

curl -X POST \
  http://localhost:3000/users \
  -d '{
	"name": "John",
	"email": "any@email.com",
	"password": "1111",
	"address": "San Francisco, CA",
	"streetAddress": "Sunset blvd, 15"
}'

Request example:

curl -X GET \
  'http://localhost:3000/users?email=any@email.com' \
  -H 'token: 48df0wibmpqz69rzgb5y'

Request example:

curl -X PUT \
  http://localhost:3000/users \
  -H 'Content-Type: application/json' \
  -H 'token: 48df0wibmpqz69rzgb5y' \
  -d '{
	"name": "Bill",
	"email": "any@email.com"
}'

Request example:

curl -X DELETE \
  'http://localhost:3000/users?email=any@email.com' \
  -H 'token: b3xg95c3wp0ol1pk46vm'

Request example:

curl -X POST \
  http://localhost:3000/tokens \
  -d '{
	"email": "any@email.com",
	"password": "1111"
}'

Request example:

curl -X GET 'http://localhost:3000/tokens?id=gjfek6ha08p2x8877mno'

Request example:

curl -X PUT \
  http://localhost:3000/tokens \
  -H 'Content-Type: application/json' \
  -d '{
	"id": "gjfek6ha08p2x8877mno"
}'

Request example:

curl -X DELETE 'http://localhost:3000/tokens?id=bivegzlqhs1z5q4np0yo'

Request example:

curl -X GET \
  http://localhost:3000/menus \
  -H 'token: 3c3nld8owylf927r5txu'

Request example:

  http://localhost:3000/carts \
  -H 'token: ket278eemafcehh9vq30'

Request example:

curl -X GET \
  http://localhost:3000/carts \
  -H 'token: ket278eemafcehh9vq30'

Request example:

curl -X DELETE \
  http://localhost:3000/carts \
  -H 'token: ket278eemafcehh9vq30'

Request example:

curl -X PUT \
  http://localhost:3000/carts \
  -H 'Content-Type: application/json' \
  -H 'token: sdvr4w4e85gw8slgycnt' \
  -d '{
	"id": 4,
	"quantity": 2
}
'

Request example:

curl -X POST \
  http://localhost:3000/orders \
  -H 'Content-Type: application/json' \
  -H 'token: 8l06rtpic4y4kps54pe4' \
  -d '{
	"paymentSource": "tok_mastercard"
}'

Request example:

curl -X GET \
  'http://localhost:3000/orders?id=un2yhgqoajzmv76fozkd' \
  -H 'token: 4dpj97yqr53druol20ru'

The LBConfig Operator, manages the configuration of External Load Balancer instances (on third-party equipment via it’s API) and creates VIPs and IP Pools with Monitors for a set of OpenShift or Kubernetes nodes like Master-nodes (Control-Plane), Infra nodes (where the Routers or Ingress controllers are located) or based on it’s roles and/or labels.

The operator dynamically handles creating, updating or deleting the IPs of the pools in the Load Balancer based on the Node IPs for each role or label. On every change of the operator configuration (CRDs) or addition/change/removal or cluster Nodes, the operator updates the Load Balancer properly.

The objective is to have a modular architecture allowing pluggable backends for different load balancer providers.

To use the operator, you will need a Kubernetes cluster to run against. You can use KIND to get a local cluster for testing, or run against a remote cluster. Note: Your controller will automatically use the current context in your kubeconfig file (~/.kube/config) (i.e. whatever cluster kubectl cluster-info shows).

Quick demo:

The main users for this operator is enterprise deployments or clusters composed of multiple nodes having an external load-balancer providing the balancing and high-availability to access the cluster in both API and Application levels.

Apply the operator manifest into the cluster:

kubectl apply -f https://github.com/carlosedp/lbconfig-operator/raw/v0.5.1/manifests/deploy.yaml

This creates the operator Namespace, CRD and deployment using the latest container version. The container image is built for amd64, arm64, ppc64le and s390x architectures.

Create the instances for each Load Balancer instance you need (for example one for Master Nodes and another for the Infra Nodes). If installing on OpenShift or Kubernetes with OLM (or in a different namespace), adjust the sample YAMLs to match the created namespace.

The provider vendor field can be (case-sensitive):

• F5_BigIP – Tested on F5 BigIP version 15
• Citrix_ADC – Tested on Citrix ADC (Netscaler) version 13
• HAProxy – HAProxy with Dataplane API. (Docs)
• Dummy – Dummy backend used for testing to only print log messages on operations

Create the secret holding the Load Balancer API user and password:

oc create secret generic f5-creds --from-literal=username=admin --from-literal=password=admin123 --namespace lbconfig-operator-system

After creating the CR, kubectl get output shows each ExternalLoadBalancer instance details:

Master Nodes using a Citrix ADC LB:

apiVersion: lb.lbconfig.carlosedp.com/v1
kind: ExternalLoadBalancer
metadata:
  name: externalloadbalancer-master-sample
  namespace: lbconfig-operator-system
spec:
  vip: "192.168.1.40"
  type: "master"
  ports:
    - 6443
  monitor:
    path: "/healthz"
    port: 6443
    monitortype: "https"
  provider:
    vendor: Citrix_ADC
    host: "https://192.168.1.36"
    port: 443
    creds: netscaler-creds
    validatecerts: false

Infra Nodes using a F5 BigIP LB:

apiVersion: lb.lbconfig.carlosedp.com/v1
kind: ExternalLoadBalancer
metadata:
  name: externalloadbalancer-infra-sample
  namespace: lbconfig-operator-system
spec:
  vip: "192.168.1.45"
  type: "infra"
  ports:
    - 80
    - 443
  monitor:
    path: "/healthz"
    port: 1936
    monitortype: http
  provider:
    vendor: F5_BigIP
    host: "https://192.168.1.35"
    port: 443
    creds: f5-creds
    partition: "Common"
    validatecerts: false

To choose the nodes which will be part of the server pool, you can set either type or nodelabels fields. The yaml field type: "master" or type: "infra" selects nodes with the role label "node-role.kubernetes.io/master" and "node-role.kubernetes.io/infra" respectively. If the field nodelabels array is used instead, the operator will use nodes which match all labels.

If you have in your cluster Infra-Nodes for different roles (for example Infra-nodes dedicated for OpenShift Data Foundation), don’t use type: "infra" config as the Load Balancer will point to all nodes with that label. Instead use the nodelabels: syntax as below specifying the correct labels for the nodes that have the routers/ingress controllers. The listed labels follow an “AND” rule.

Clusters with sharded routers or using arbitrary labels to determine where the Ingress Controllers run can be configured like:

spec:
  vip: "10.0.0.6"
  ports:
    - 80
  nodelabels:
    "node.kubernetes.io/ingress-controller": "production"
    "kubernetes.io/region": "DC1"
  ...

Please check the additional documentation for more information like tracing, adding new providers, development, release and more.

• The operator does not check if the requested configuration (names, IPs) already exists and/or conflicts with existing configuration in the Load Balancer. The user is responsible for these checks before deployment;
• I am not responsible if the operator changes/deletes existing configuration on the Load Balancer if existing names are already configured.
• The operator creates the entries(Pools, VIPs, Monitors) in the provided Load Balancer with the name of the instance configured in the CustomResource prefixed with the type. Eg. For a CR with name externalloadbalancer-master-sample, the operator creates a server pool named Pool-externalloadbalancer-master-sample-6443 (suffixed with the port), a monitor named Monitor-externalloadbalancer-master-sample and a VIP named VIP-externalloadbalancer-master-sample-6443 (suffixed with the port).

1. Create a Gatsby site.

   Use the Gatsby CLI to create a new site, specifying the blog starter.

   # create a new Gatsby site using the blog starter
   gatsby new my-blog-starter https://github.com/gatsbyjs/gatsby-starter-blog

2. Start developing.

   Navigate into your new site’s directory and start it up.

   cd my-blog-starter/
   gatsby develop

3. Open the source code and start editing!

   Your site is now running at http://localhost:8000!

   Note: You’ll also see a second link: http://localhost:8000/___graphql. This is a tool you can use to experiment with querying your data. Learn more about using this tool in the Gatsby tutorial.

   Open the my-blog-starter directory in your code editor of choice and edit src/pages/index.js. Save your changes and the browser will update in real time!

A quick look at the top-level files and directories you’ll see in a Gatsby project.

.
├── node_modules
├── src
├── .gitignore
├── .prettierrc
├── gatsby-browser.js
├── gatsby-config.js
├── gatsby-node.js
├── gatsby-ssr.js
├── LICENSE
├── package-lock.json
├── package.json
└── README.md

1. /node_modules: This directory contains all of the modules of code that your project depends on (npm packages) are automatically installed.

2. /src: This directory will contain all of the code related to what you will see on the front-end of your site (what you see in the browser) such as your site header or a page template. src is a convention for “source code”.

3. .gitignore: This file tells git which files it should not track / not maintain a version history for.

4. .prettierrc: This is a configuration file for Prettier. Prettier is a tool to help keep the formatting of your code consistent.

5. gatsby-browser.js: This file is where Gatsby expects to find any usage of the Gatsby browser APIs (if any). These allow customization/extension of default Gatsby settings affecting the browser.

6. gatsby-config.js: This is the main configuration file for a Gatsby site. This is where you can specify information about your site (metadata) like the site title and description, which Gatsby plugins you’d like to include, etc. (Check out the config docs for more detail).

7. gatsby-node.js: This file is where Gatsby expects to find any usage of the Gatsby Node APIs (if any). These allow customization/extension of default Gatsby settings affecting pieces of the site build process.

8. gatsby-ssr.js: This file is where Gatsby expects to find any usage of the Gatsby server-side rendering APIs (if any). These allow customization of default Gatsby settings affecting server-side rendering.

9. LICENSE: This Gatsby starter is licensed under the 0BSD license. This means that you can see this file as a placeholder and replace it with your own license.

10. package-lock.json (See package.json below, first). This is an automatically generated file based on the exact versions of your npm dependencies that were installed for your project. (You won’t change this file directly).

11. package.json: A manifest file for Node.js projects, which includes things like metadata (the project’s name, author, etc). This manifest is how npm knows which packages to install for your project.

12. README.md: A text file containing useful reference information about your project.

Looking for more guidance? Full documentation for Gatsby lives on the website. Here are some places to start:

• For most developers, we recommend starting with our in-depth tutorial for creating a site with Gatsby. It starts with zero assumptions about your level of ability and walks through every step of the process.

• To dive straight into code samples, head to our documentation. In particular, check out the Guides, API Reference, and Advanced Tutorials sections in the sidebar.

• https://medium.com/javascript-in-plain-english/how-to-create-a-newsletter-with-mailchimp-gatsby-js-netlify-d48778d5c774
• https://chrisotto.dev/gatsby-create-an-audience-with-mailchimp/

docker run -p 5432:5432 -e ‘GAUSS_USER=gauss’ -e ‘GAUSS_PASSWORD=Gauss666’ -d –name OpenGaussTest lsqtzj/openeuler_open_gauss:latest

openGauss 极简版 基于openeuler/openeuler:20.03
包括 patroni自动主备切换，haproxy 负载均衡， pgAdmin4 管理工具
必须保证有两个以上的openGauss容器运行。

https://blog.csdn.net/lsqtzj/article/details/120850420

下载源码
git clone https://github.com/CyrusZhou-CN/openGauss_master_slave.git
cd openGauss_master_slave

docker-compose -f “docker-compose-build.yml” up -d –build

docker-compose -f “docker-compose.yml” up -d

用户名/密码 root / root 、omm / omm

管理员 / 密码：gauss / Gauss666

http://localhost:9980/pgadmin4/browser/
默认管理员 / 密码：admin@domain.com / admin

etcd Version: 3.5.1
patroni Version 2.0.2

http://localhost:7000/ 监控

haproxy:5000 读写
haproxy:5001 读

docker-compose 基本配置 放到 .env 文件中。

默认保存在 ./data 目录

/opt/software/openGauss/data/db 数据库目录 /opt/software/openGauss/data/conf 配置文件目录 /opt/software/openGauss/logs 日志目录

如：新添加 slave03 主机，打开docker-compose.yml 文件复制 slave02 节点的配置，用来创建新主机。

...
slave03:
    image:  lsqtzj/openeuler_open_gauss:${OPEN_GAUSS_VERSION}
    restart: always
    container_name: slave03
    hostname: slave03
    networks:
      gauss:
        ipv4_address: 10.8.0.13
    environment:
      TZ: Europe/Rome #Asia/Shanghai 时区
      GAUSS_USER: ${GAUSS_USER}
      GAUSS_PASSWORD: ${GAUSS_PASSWORD}
      NODE_NAME: datanode4
      RUN_MODE: "slave"
      HOST_NAMES: ${HOST_NAMES}
    volumes:
      - ./data/slave03/data:/opt/software/openGauss/data      
      - ./data/slave03/logs:/opt/software/openGauss/logs
    depends_on:
      - master
...

修改 .env 文件添加新主机

...
HOST_NAMES=master,slave01,slave02,slave03
HOST_IPS=10.8.0.10,10.8.0.11,10.8.0.12
HAPROXY_IPS=10.8.0.10,10.8.0.11,10.8.0.12,10.8.0.13
HAPROXY_PORTS=5432,5432,5432,5432
...

volumes:
      - ./test.sql:/docker-entrypoint-initdb.d/test.sql # 初始化数据表

CPU Process Scheduling and Deadlock Detection Using Bankers Algorithm

The process scheduling is the activity of the process manager that handles the removal of the running process from the CPU and the selection of another process on the basis of a particular strategy. Process scheduling is an essential part of a Multiprogramming operating systems.

Features of this program:

FCFS (First come first serve): The first come, first served (commonly called FIFO ‒ first in, first out) process scheduling algorithm is the simplest process scheduling algorithm. It is rarely used in modern operating systems, but is sometimes used inside of other scheduling systems.

SJF (Shortest Job First) : SJF can be either preemptive or non-preemptive. Preemption occurs when a new process arrives in the ready queue that has a predicted burst time shorter than the time remaining in the process whose burst is currently on the CPU. Preemptive SJF is sometimes referred to as shortest remaining time first scheduling.

Round Robin : Round Robin is a CPU scheduling algorithm where each process is assigned a fixed time slot in a cyclic way. One of the most commonly used technique in CPU scheduling as a core. It is preemptive as processes are assigned CPU only for a fixed slice of time at most.

Shortest Remaining Time First (SRTF) : Shortest remaining time, also known as shortest remaining time first (SRTF), is a scheduling method that is a preemptive version of shortest job next scheduling. In this scheduling algorithm, the process with the smallest amount of time remaining until completion is selected to execute.

Deadlock detection using Banker’s algorithm : A deadlock detection algorithm is correct if it satisfies two conditions: 1) every deadlock is eventually detected (ba- sic progress property), and 2) every detected deadlock really exists, i.e., only genuine deadlocks are detected (safety prop- erty). While the first condition is intuitive, the second one needs to be explained.

Gantt chart : A Gantt chart is a type of bar chart that illustrates a project schedule. Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the work breakdown structure of the project.

All of the above mentioned features and properties are supported by this program.
It can be helpful for those having trouble in coding these algorithms.

Zig’s @import("std").fmt may be good, but in some cases you just need a little bit more functionality.

Now why not just link in libc and use sprintf() and such?
Either because you are on some device where there isn’t (yet) a libc to link against,
because you just don’t want to link against libc,
or lastly because you’re using some types c doesn’t understand (u19, f128, etc.) and want a native zig solution.

That being said, this is not a drop in replacement, the format specifiers are a little different from c’s.
I did design them to be as close as possible though, requiring little rethinking if you’re already used to c.

A lot of what’s written here isn’t implemented yet, I am working on it though.
Also any ideas are appreciated, making this more feature rich would be nice :3

Also also, I will add a build.zig.zon once this can be reasonably used as a library.
Might even make it so you can compile it to a static/dynamic library to use with other languages.

Format specifiers in cfmt look something like this:

"%s"     // a string
"%.4f"   // a floating-point value rounded to 4 digits after the period
"%-4.8i" // a left alligned integer of at least 4 and at most 8 digits

They can be split into five parts in this exact order:
A % character,
flags,
minimum width,
precision and lastly
the specifier.
All besides the specifier are optional.

The only exception to this is the specifier for writing a % character, which is %%.

Specifiers tell cfmt what kind of type you’re formatting and how you want it formatted.

The following specifiers exist:

Integers:

• i: Decimal integer
• b: Binary integer
• o: Octal integer
• x: Hexadecimal integer (lowercase)
• X: Hexadecimal integer (uppercase)

Floating-point:

• f: Decimal floating-point

Other:

• s: String
• c: Character
• p: Pointer (hexadecimal lowercase)
• P: Pointer (hexadecimal uppercase)

Special:

*cricket noises*

For better compatibility with c’s format specifiers, d and u work the same as i.

If a minimum width is specified and the formatted string isn’t that long, the string will be padded with space characters.

The minimum width can either be a decimal number, such as 4, 9 or 142,
or a *, in which case an usize is read from the arguments and its value is used as the minimum width.
If a * is used, the dynamic minimum width must be given before the value to be formatted (and the dynamic precision if used).
Please note that the decimal number may not have a leading zero as that could interfere with the 0 flag.

By default, the formatted contents will be right alligned (space characters on the left),
though this behavior can be changed with the - flag.

What exactly precision means depends on the type to be formatted:

If it’s a floating point value, precision is the amount of digits after the decimal separator.

If it’s a string, precision defines the maximum amount of characters written.
When truncation happens, the last characters are cut off.

If it’s a character, it will be repeated precision times.
Does it make sense to call that precision? No.
Could it still be a useful functionality? Yes.

For any other type, precision doesn’t do anything.

To set the precision, a . followed by a number or a * is used, similar to minimum width except with a . character.
Here however, the precision is put between the dynamic minimum width and value to be formatted.
If neither a * or a number follows the ., precision is set to 0.

Flags change some parts of formatting.

The following flags exist:

• -: Allign to the left instead of right (space characters on the right)
• +: Always write + and - sign for numeric types
• : (space) Write a space character at start of positive numeric values
• <: Write sign before any padding
• 0: Pad with 0 characters instead of space characters

Retrieve some Janet sample code.

“All your Janets are belong to us.”

First clone this repository and cd to the resulting directory:

git clone https://github.com/sogaiu/git-some-janets
cd git-some-janets

Next, choose from one of the following methods:

jpm install

janet install

Copy the git-some-janets.janet file somewhere on your PATH and
make sure it has appropriate executable permissions. Some might
prefer to remove the .janet file extension (and instructions /
usage assume that is done).

Usage: git-some-janets NUMBER [STRING]
       git-some-janets STRING [NUMBER]

Fetch some janet-related git repositories.

Examples:

  # fetch 2 janet-related repositories
  git-some-janets 2

  # fetch janet-related repositories whose urls contain "bakpakin"
  git-some-janets bakpakin

  # fetch 3 janet-related repositories whose urls contain "chambers"
  git-some-janets chambers 3
  git-some-janets 3 chambers

Parameters:

  NUMBER   maximum number of repositories to fetch (<= 0 means all
           remaining)

  STRING   used to match (substring) which repositories to fetch
           (STRING should not represent a number according to
           janet's `scan-number`)

With NUMBER as the first argument, fetch NUMBER repositories (see
above for what a non-positive NUMBER means).  If STRING is specified
as a second argument, fetch up to NUMBER repositories (inclusive)
whose urls contain STRING as a substring.

With STRING as the first argument, fetch repositories whose urls
contain STRING as a substring.  If NUMBER is specified as a second
argument, fetch up to NUMBER repositories (inclusive) whose urls
contain STRING as a substring (see above for what a non-positive
NUMBER means).

The git-some-janets script will use git to clone repositories from
a pre-specified list. The resulting directories will live under a
directory named repos.