This is a MSX-C version of cowsay.

cowsay [OPTION] ...  

-b borg mode  
-d dead mode  
-g gready mode  
-s stoned mode  
-t tired mode  
-w wired mode  
-y youthfull mode  
-e manually specifies eyes (DEFAULT = oo)  
-T manually specifies tongue  
-f select cow file  
-l display COWPATH directory and exit  
-W Word wrap on x column (DEFAULT = 40)  

-h display this help and exit  
-v output version information and exit  

e.g:

When no text is given the command will wait for text from the command line which can be ended with ctrl+Z. It’s also possible to pipe text into the cowsay program, e.g.:

To tell the cowsay package where the cows are, set your COWPATH environment variable to the directory these cows are in. At the moment only one path can be set, e.g.:

set COWPATH=A:/cows

These are the simplest sorts of cows; they are just a plaintext file with the ASCII that is the cow in it. It has extension ‘.cow’.

Use $eyes, $tongue and $thoughts in the file. $eyes and $tongue are replaced by the user-specified eyes and tongue, being strings of length two (if the user specifies longer eyes only the first two characters are used; if they specify a one-character eye it is padded with a space). The $thoughts token is the ‘stem’ part of the speech bubble, not the speech bubble itself. For a cow that is thinking, this is ‘o’ (dots leading up to the thought bubble); for a cow that is speaking, this is ” (speech bubble stem).

Any line starting with a ‘#’ will be ignored, even if it is part of your cow!. If your cow has lines that start with ‘#’ that should be part of the cow, indent the entire cow one space.

Example (the default cow, you can see him at the start of the Readme):

# e.g. as default.cow
        $thoughts   ^__^
         $thoughts  ($eyes)\_______
            (__)\       )\/\
             $tongue ||----w |
                ||     ||

To compile the source code, use the ccfull.bat batch file. Don’t forget to edit the batch file for the standard C libraries, beware that this line can’t be longer then 127 chars!

• Fix bugs 🙂

• Relearning MSX
  Greate series of blog posts written by Javier Lavandeira to setup your MSX-C environment and start learning MSX-C.
• Generation MSX
  Large MSX Software database.
• MSX Resource Center
  All the MSX News you need!

This is a MSX-C version of cowsay.

cowsay [OPTION] ...  

-b borg mode  
-d dead mode  
-g gready mode  
-s stoned mode  
-t tired mode  
-w wired mode  
-y youthfull mode  
-e manually specifies eyes (DEFAULT = oo)  
-T manually specifies tongue  
-f select cow file  
-l display COWPATH directory and exit  
-W Word wrap on x column (DEFAULT = 40)  

-h display this help and exit  
-v output version information and exit  

e.g:

When no text is given the command will wait for text from the command line which can be ended with ctrl+Z. It’s also possible to pipe text into the cowsay program, e.g.:

To tell the cowsay package where the cows are, set your COWPATH environment variable to the directory these cows are in. At the moment only one path can be set, e.g.:

set COWPATH=A:/cows

These are the simplest sorts of cows; they are just a plaintext file with the ASCII that is the cow in it. It has extension ‘.cow’.

Use $eyes, $tongue and $thoughts in the file. $eyes and $tongue are replaced by the user-specified eyes and tongue, being strings of length two (if the user specifies longer eyes only the first two characters are used; if they specify a one-character eye it is padded with a space). The $thoughts token is the ‘stem’ part of the speech bubble, not the speech bubble itself. For a cow that is thinking, this is ‘o’ (dots leading up to the thought bubble); for a cow that is speaking, this is ” (speech bubble stem).

Any line starting with a ‘#’ will be ignored, even if it is part of your cow!. If your cow has lines that start with ‘#’ that should be part of the cow, indent the entire cow one space.

Example (the default cow, you can see him at the start of the Readme):

# e.g. as default.cow
        $thoughts   ^__^
         $thoughts  ($eyes)\_______
            (__)\       )\/\
             $tongue ||----w |
                ||     ||

To compile the source code, use the ccfull.bat batch file. Don’t forget to edit the batch file for the standard C libraries, beware that this line can’t be longer then 127 chars!

• Fix bugs 🙂

• Relearning MSX
  Greate series of blog posts written by Javier Lavandeira to setup your MSX-C environment and start learning MSX-C.
• Generation MSX
  Large MSX Software database.
• MSX Resource Center
  All the MSX News you need!

• Start Student Performance Project ASAP
• Stop being a lazy cunt

• Start Student Performance Project
• Finish 3 Andrew Ng videos

• Start Student Performance Project
• Problem solving for at least 3 hrs
• Finish 3 Andrew Ng videos

• Spend at least 3 hrs on problem solving
• Start student performance project

• Start doing Student Performance project
• Follow mentors guideline

• Wake up at 7 am
• Do more activities
• Looking for more Projects to do
• Explore how Chess can be played using ML

• Start the week 3 of Andrew Ng
• Refine the project a little bit.

• Complete the House Price Prediction project and adding context to it

• Getting over with the exam and resume the projec

• Getting over with the exam and resume the project

• Continue Mid & Progress as much as I can.

• Continue Mid & Progress as much as I can.

• Continue Mid & Progress as much as I can.

• Continue Mid & Progress as much as I can.

• Continue Mid & Progress as much as I can.

• Continue Mid & Progress as much as I can.
• Finish vectorization & Gradient Descent for Multiple Linear Regression.

• Continue Mid & Progress as much as I can.

• Continue Mid & Progress as much as I can.

• Continue Mid & Progress as much as I can.

• Continue Mid & Progress as much as I can.

• Simply avoid Phone
• Start Module 2 of Andrew Ng and go through it fast

• Finish the Module 1 of Andrew Ng
• Explore beginner projects to do later

• Resume Python Data-camp
• Resume Rock vs Mine Project
• Finish the first week of Andrew Ng

• Use less time lying around
• Starting Khanacademy because I am falling behind
• Do more data-camp

• Beautify the project with details about Linear Regression theory
• Spend less time on a project
• Use time efficiently
• Starting Khanacademy

• Understanding Model representation lab, eventually disscuss it with Safaet
• Start linear algebra from Kahanacademy
• Start Panda package tutorial

• Waste less time on the phone
• Recapture the git a little more
• Implement linear regression in Jupyter Notebook

• Python
  • Introduction to Python
  • NumPy
  • Matplotlib
  • Pandas
• Markdown

• Supervised Machine Learing
  • Regression
    • Linear Regression
      • For Single Variable (Univariate)
      • Multiple Features
  • Classification
    • Logistic Regression
• Unsupervised Machine Learning
  • Clustering
  • Anomaly Detection
  • Dimentionality
• Gradient Descent

• Student Score Prediction using Linear Regression (Univariate)
• Rock vs Mine Prediction using Logistic Regression

Is it possible to implement NAT routing or firewalling withing docker containers? YES!

Should you use a setup like this in production? Probably NOT!

An example for building routed networks with docker and docker-compose; intended for use in automated testing setups.

⚠ This is no reference implementation of a NAT router container to be used in production! While the provided material may be used to build test benches, it is considered purely educational!

💻 ⇆ { external ☁ } ⇆ [ 💻 ROUTER ] ⇄ { ☁ internal } ⇄ 💻

Default docker bridge network (default in docker-compose) Represents the external network to be routed to (e.g. “the internet”).

Building a NAT router in docker is only possible from macvlan networks, as otherwise all IP traffic is handled directly by the host, outside the realm of influence of a container!

A macvlan network without parent interface. Containers in this network can communicate with each other but not reach targets outside the network by default. A virtual interface is automatically created as parent by docker. A custom subnet and gateway address may be specified from the compose file; if not, docker will assign a random subnet and the first usable (non-broadcast) address on the subnet as gateway to containers on the network.

The stack is made up of three containers, where each container shares one network with the router container:

• external
• router
• internal

Dummy container as ping target. Sharing the default docker bridge network (external above) with the router container. No further configuration requirements for this container exist.

Attached to both networks. Performing NAT routing from internal to external network and DNS forwarding.

📌 The router assumes the routed internal network to be attached at the interface with the lowest index! Interface order is achieved by providing a priority value in compose. To not rely on interface ordering, use a fixed subnet and provide it in CIDR notation as environment variable ROUTE_NET.

Docker assigns a gateway address as described above to all containers on the internal network. The router assigns itself this gateway address on the internal network interface, using either the explicitly specified address, or deducing the gateway address from the interfaces’ subnet.

The address assigned by docker on the internal interface will be kept, to allow using dockers’ internal DNS resolver to resolve the routers’ address.

NAT routing is performed using iptables rules. Modifying iptables, requires the container to be ran with NET_ADMIN capabilities. Routing will be configured from internal network to all other networks attached to the router container!

dnsmasq performs DNS forwarding for containers on the internal subnet, to the routers DNS resolver provided by docker. Dockers’ DNS resolver only resolves container names on the same network. As the router is attached to both networks, the local resolver is able to resolve names from both these networks. The router mounts and updates a resolv.conf file in the data/ directory, to be mounted by the internal containers as /etc/resolv.conf.

A note on docker networks and DNS servers

Docker uses an internal DNS resolver for containers. Supplying additional DNS servers via command line or docker-compose adds these addresses to the internal resolver, but does not modify /etc/resolv.conf (except, when explicitly using and specifying a network as bridge-network). The internal resolver does not perform name lookup for DNS servers and has to reach all DNS server from the host network, thus prohibiting the use of container names as DNS servers.

Connected to the internal network only. For DNS resolution to containers on the external network, mounting /data/resolv.conf as /etc/resolv.conf is necessary! To ensure name resolution for applications, the internal container waits for the router to be up, using depends_on: [router] in compose. Gateway address is assigned by docker automatically, while the router container takes care of providing routing at that address.

Apart from mounting resolv.conf for container name resolution – if desired -, no further configuration requirements for this container exist.

Examples are provided in examples/. Run docker-compose on the main compose file and the example to examine. Afterwards, play around; connect to containers and observe behavior; e.g:
add more containers, remove containers, remove the router-container, do not mount resolv.conf, etc..

compose files from examples/

Starts all containers. Runs a shell with attached tty in internal and external container to keep them alive. Use to run commands in the containers and observe the behavior; e.g. docker-compose exec internal ping external.

docker-compose -f docker-compose.yml -f examples/up.yml up

• external container listens on port 8888 using netcat, echoing hello from external @ channel opened from remote.
• internal container connects to external on port 8888 using netcat, echoing hello from internal

The output from both containers can be observed in the docker-compose log.

docker-compose -f docker-compose.yml -f examples/hello.yml up

Tries to ping internal from external. Uses router as DNS to resolve internal network container names. Run with --abort-on-container-exit to bring down all containers on individual container exit and observe exit code.

# NIX
docker-compose -f docker-compose.yml -f examples/reverse-fail.yml up --abort-on-container-exit; echo exit code: $?

# WIN
docker-compose -f docker-compose.yml -f examples/reverse-fail.yml up --abort-on-container-exit & echo exit code: %errorlevel%

Find commented sections in docker-compose.yml relating to ROUTE_NET and/or ROUTE_GATEWAY. Setup IPAM config, and provide the subnet in CIDR notation to the router-container as ROUTE_NET=<my.su.bn.et/prefix>, to use a specific subnet. To use a specific gateway, provide ROUTE_GATEWAY in IPAM config and router-container environment.

A better version of cd (and pushd) for your Fish shell.

With fisher:

fisher add eth-p/fish-plugin-better-cd

You can also alias cd to bettercd, if you like:

alias cd bettercd
alias cdun bettercd --undo

If you’re familiar with fzf or z, there’s a couple of recommended defaults:

set -U bettercd_resolve  fzf
set -U bettercd_tiebreak common,fzf

set -U bettercd_resolve  z,fzf
set -U bettercd_tiebreak common,z
set -U bettercd_search_z all

Change directories with :/path-relative-to-git-root.
Just like git add, and with completion support.

$ git init
$ mkdir folder
$ mkdir -p other/folder
$ bettercd folder && pwd
/repo/folder

$ bettercd :/other/folder && pwd
/repo/other/folder

Fuzzy find your directories with fzf or z
(requires fzf and either fd or z; must be enabled, see below)

$ mkdir -p foo/bar/baz
$ mkdir -p foo/cat/dog
$ bettercd baz && pwd
/tmp/foo/bar/baz

$ bettercd ../../dog && pwd
/tmp/foo/cat/dog

$ bettercd proj && pwd
/home/me/projects

Undo your previous bettercd.
Did you not mean to change to that directory?

$ pwd
/home/me/desktop

$ bettercd ~/downloads && pwd
/home/me/downloads

$ bettercd --undo && pwd
/home/me/desktop

All configuration is done with variables, preferably with set -U for universal variables.

• bettercd_resolve (default: fzf, format: resolver,resolver,...)
  Specifies which resolvers are used for populating the list of candidate directories.

• bettercd_tiebreak (default: common,fzf, format: tiebreaker,tiebreaker,...)
  Specifies which tiebreakers are used for picking between multiple candidate directories.

• bettercd_reporel (default: true, format: true or false)
  If enabled, allows navigating relative to the git repo root with :/path/from/root.
  Fuzzy matching is also still available for this!

• bettercd_search_depth (default: 4, format: number)
  Specifies how deep of a search the fzf resolver will do.

• bettercd_search_z (default: best, format: all, best or common)
  When using the z resolver, what answers returned by z will be used.

• bettercd_user_search_exclude_paths (format: array)
  Speicifes a list of absolute paths that the fzf resolver will ignore.

• bettercd_user_search_exclude_names (format: array)
  Speicifes a list of file globs that the fzf resolver will ignore.

• bettercd_fzf_args (format: array)
  A list of arguments passed to fzf in the fzf resolver.
• bettercd_fzf_interactive_args (default: something nice, format: array)
  A list of arguments passed to fzf in the fzf tiebreaker.
• bettercd_fd_args (format: array)
  A list of arguments passed to fd in the fzf resolver.

Bettercd’s fuzzy matching works by collecting a list of candidate paths for the provided search path. This is done with resolver functions, which take the search path and print out a list of candidate paths.

(requires fzf and fd)

The fzf resolver uses a combination of fd and fzf to return a list of fuzzily-matching paths under the target directory. It is very likely to return a ton of candidates, and it’s recommended to use the fzf tiebreaker to pick one.

(requires z)

The z resolver uses z to print a list of paths that would be matched by z.
You can configure how many paths are returned by setting bettercd_search_z to either best, all, or common.

You can create custom resolvers by defining a __bettercd_resolve_with_RESOLVER function:

function __bettercd_resolve_with_homedir
	for dir in $HOME/*
		printf "%s\n" -- "$HOME"
	end
end

Whenever bettercd’s fuzzy matching returns more than one candidate, it needs to be narrowed down to a single result. For this, there are tiebreaker functions.

(requires fzf)

The fzf tiebreaker displays a list of candidates, and asks you to pick one.

(requires z and perl)

The z tiebreaker uses the z database to pick the highest-weighted directory from the list of candidates. If no candidate is located in the database, the next tiebreaker will be used instead.

The common tiebreaker simply picks the common parent of all candiates, if there is one. This is good for navigating to a parent directory without considering any of its children.

You can create custom resolvers by defining a __bettercd_tiebreak_with_TIEBREAKER function:

function __bettercd_tiebreak_with_first
    argparse 'x-nothing' -- $argv || return $status
	echo $argv[1]
end

The reference implementation for the XMF markup language.

The XMF file format specifies a declarative and fairly simple language designed for “manifests”. It is designed to be easily
modified in order to be applied many different cases. The best way to think of these files are to compare them to
Docker’s Dockerfiles as they serve very similar purposes. The main differences are that XMFs are
entirely customizable, and have the ability to interact with and manipulate variables.

IMPORT path/to/another/file.xmf  # Extend xmfs or simply import their defined functions
IMPORT classpath:/xmf/utils.xmf  # We bundle some optional utilities for conveinence
DEFINE MyVerb some.identifier.MyVerb  # This hooks your implementation of MyVerb to the current .xmf file

MyVerb blah blah  # Interact with verbs

$MY_VARIABLE<-yes, this is my variable  # Declare a variable

PRINT $MY_VARIABLE  # Prints the contents of $MY_VARIABLE to stdout

Check out the XMF file specifications here or view some example (and builtin) xmf files here

This project focuses on building a comprehensive and robust backend-focused application using modern web development techniques and technologies. It includes API development, database integration, authentication, and deployment.

The application is deployed and accessible at:

• 🔗 Voyage – Render (takes ~1min to warm up since it’s a free tier)
• 🔗 Voyage – Vercel (if Render is not available, however User Photo Upload is not available on Vercel since it’s a serverless service)

• RESTful API for managing travel-related data.
• Secure authentication and authorization using JWT.
• Robust database design with MongoDB and Mongoose.
• Security enhancements to prevent vulnerabilities.
• Efficient routing and middleware management with Express.js.
• Frontend rendered using Pug for dynamic content.
• Payment processing with Stripe for bookings.
• Email notifications via Mailtrap for development and Brevo for production.
• Interactive map display using Mapbox.
• Deployment to a live production environment.

The following technologies will be used to develop this project:

• Node.js: A JavaScript runtime for building scalable server-side applications.
• Express.js: A web application framework for handling routes, middleware, and APIs efficiently.

• MongoDB: A NoSQL database for flexible and scalable data storage.
• Mongoose: An Object Data Modeling (ODM) library for MongoDB, providing schema validation and query building.

• JWT (JSON Web Tokens): For user authentication and authorization.
• Helmet.js: To secure HTTP headers.
• Express Rate Limit: To prevent brute-force attacks.

• Git: For version control.
• Postman: For API testing.
• Render: For deploying the application.

• Pug (formerly Jade): A template engine for generating HTML views on the server side.

1. Build a comprehensive understanding of backend development by creating a server-side application from scratch.
2. Enhance skills in Node.js, Express, and MongoDB.
3. Implement industry best practices for coding, database design, and security.
4. Learn how to manage application state, handle user authentication, and secure APIs.
5. Gain experience in deploying backend applications to production environments.
6. Showcase a polished project that demonstrates practical expertise and problem-solving skills in backend development.

Postman documentation available here.

Downloadable Collection and Environment Variables files also located in the ./postman directory.

Contains the functions of the following libraries

• dotenv
• dotenv-cli

• Multiple .env file support
• Command Line support
• Assign a mode mode

File Priority:

• .local file > not unassigned local
• .mode file > not unassigned mode

If the mode is ‘dev’, then the import order is:

1. .env.dev.local
2. .env.dev
3. .env.local
4. .env

# the local file has higher priority

# in .env file
HOST=127.0.0.1
PORT=3000
# in .env.local file
PORT=3001

# out
{"HOST": "127.0.0.1", "PORT": "3001"}

# the assigned mode file has higher priority

# in .env file
PORT=3000
# in .env.prod file
PORT=80

# mode=prod
# out
{"PORT": "80"}

💡If you have used vite, it works the same way.

npm i dotenv-multi-x
# or
yarn add dotenv-multi-x

import dotenv from 'dotenv-multi-x'
dotenv.init()

console.log(process.env)

or auto initial

// notice, keep it in the top of file.
import dotenv from 'dotenv-multi-x/lib/init'

console.log(process.env)

$ dotenv node ./example/cli.test.js
$ dotenv --mode=dev node ./example/cli.test.js

OR

$ node -r dotenv-multi-x/lib/init.js ./example/cli.test.js
$ node -r dotenv-multi-x/lib/init.js ./example/cli.test.js --mode=dev

• init
• parse
• getConfig

init will get mode from process.env or process.argv, read the .env* files, parse the content, handle the inheritance, and reture an object.

dotenv.init()

Parse the content and return an Object with the parsed keys and values.

dotenv.parse(Buffer.from('PROT=3001'))

Accept a mode and read .env* files, and handle the inheritance. return finally result.

# Windows Powershell
$env:mode="dev"
node .\example\index.mjs
# Mac
mode=dev node ./example/index.mjs

# or
node .\example\index.mjs --mode=dev

Add .env.local* in your .gitignore file.

When you run your code in multiple environments, you may need some different environments variable. But dotenv didn’t support multiple .env files.

If you don’t use docker or other CI/CD environment variable to instead of .env file, or don’t use shell script to replace .env file, the multiple files is the easiest way to make it work.

For example, your server launched on port 3000, but you want to run on 3001 in local device, the .env file will be shared on repos which used git, so you need a .env.local file, this file has higher-priority then .env and it can doesn’t share with git.

You can create mutiple .env* files, and use them in different environments as easier as possible.

Here you can find custom scripts created for the Orgmanager Hosted version needs.

You can pull in the package via composer:

composer require orgmanager/orgmanager-custom

Next up, the service provider must be registered:

// config/app.php
'providers' => [
    ...
    OrgManager\OrgmanagerCustom\OrgmanagerCustomServiceProvider::class,

];

• Invite To Org command

php artisan orgmanager-custom:inviteusers

Used to periodically invite all the OrgManager users to the OrgManager organization.

• List Users command

php artisan orgmanager-custom:listusers

Used to print a table of the users registered on OrgManager.

• List Orgs command

php artisan orgmanager-custom:listorgs

Used to print a table of the organizations registered on OrgManager.

• Get Stats command

php artisan orgmanager-custom:getstats (-T | --table)

Used to print the stats in plain text (or in a table format when using -T).

Please see CHANGELOG for more information what has changed recently.

Please see CONTRIBUTING for details.

If you discover any security related issues, please email soy@miguelpiedrafita.com instead of using the issue tracker.

• Miguel Piedrafita
• All Contributors

This package is licensed under the Mozilla Public license. Please see License File for more information.

In this workshop, we’ll explore how to create decentralized Library. We will use the pre-written Tron smart contract and deploy it using TronBox, we can deploy contract on any Testnet or Mainnet.

This dApp uses Nuxt, but is out of scope for this workshop, so don’t worry, we will only be focusing on the pieces that helps us build. In practice, any JS framework can be used.

Please refer to the following steps to deploy this DApp on Nile testnet

node -v
> v10.24.1

Download TronLink chrome extension

npm install -g tronbox 

If there is no Tron account, please use TronLink to create a new Account. And then apply for some test coins of Nile testnet for testing. Please make sure the account has enough TRX. Get test coins

Now we have Setup installed properly, let’s grab the dApp template that we will use as the skeleton of our dApp. This template is a website built using Nuxt.js (don’t worry if you don’t know Nuxt.js, we are not focusing on this part).

Clone the template into your folder:

git clone https://github.com/TRON-Developer-Hub/decentralized-library

cd decentralized-library

npm install

Paste your account’s private key to ‘privateKey’ in tronbox.js

Follow instructions to complete the smart contract code. If you only test the template code, please skip this step.

Compile contract:

tronbox compile

Deploy contract:

tronbox migrate --reset --network nile

On sucessfull deploy, copy the contract address

Follow dapps to complete the DApp code. If you only test the template code, please skip this step.

cd dapp-ui
npm install
npm run dev