Yet Another Minifier for Hexo. Minify HTML, JS, CSS, SVG, XML and JSON. Compress static web assets using gzip, brotli and zstd.

• Installation
• Options
• HTML
• CSS
• JS
• SVG
• XML
• JSON
• Gzip
• Brotli
• Zstd
• Globbing

$ npm install --save hexo-yam

minify:
  enable: true
  previewServer: true
  html:
  css:
  js:
  svg:
  gzip:
  brotli:
  xml:
  json:

• enable – Enable the plugin. Defaults to true.
• previewServer – Disable the plugin when running hexo server. Defaults to true.
• html – See HTML section
• css – See CSS section
• js – See JS section
• svg – See SVG section
• gzip – See Gzip section
• brotli – See Brotli section
• xml – See XML section
• json – See JSON section

minify:
  html:
    enable: true
    exclude:

• enable – Enable the plugin. Defaults to true.
• priority – Plugin’s priority. Defaults to 10. Set lower value to set higher priority and vice versa.
• verbose – Verbose output. Defaults to false.
• exclude – Exclude files. Support wildcard pattern(s) in a string or array.
• globOptions – See globbing section.

For more options, see HTMLMinifier.

minify:
  css:
    enable: true
    exclude:
      - "*.min.css"

• enable – Enable the plugin. Defaults to true.
• priority – Plugin’s priority. Defaults to 10.
• verbose – Verbose output. Defaults to false.
• exclude – Exclude files. Support wildcard pattern(s) in a string or array.
• level – Optimization level. Defaults to 2.
• globOptions – See globbing section.

For more options, see clean-css.

minify:
  js:
    enable: true
    exclude:
      - "*.min.js"

• enable – Enable the plugin. Defaults to true.
• priority – Plugin’s priority. Defaults to 10.
• verbose – Verbose output. Defaults to false.
• exclude – Exclude files. Support wildcard pattern(s) in a string or array.
• compress – Compress options.
• mangle – Mangle variable names. Defaults to true. Pass an object to specify mangle options.
• output – Output options.
  • To retain comments, output: {comments: true}.
• globOptions – See globbing section.

For more options, see Terser.

minify:
  svg:
    enable: true
    include:
      - "*.svg"
      - "!*.min.svg"

• enable – Enable the plugin. Defaults to true.
• priority – Plugin’s priority. Defaults to 10.
• verbose – Verbose output. Defaults to false.
• include – Include files. Support wildcard pattern(s) in a string or array.
  • Exclude *.min.svg by default.
• plugins – Plugin options.
  • Examples:

  plugins:
    # Retain comments
    removeComments: false
    # Do not remove unused ID attributes
    cleanupIds: false

  • For more options, see svgo.
• globOptions – See globbing section.

Remove whitespaces in xml.

minify:
  xml:
    enable: false
    include:
      - "*.xml"
      - "!*.min.xml"

• enable – Enable the plugin. Defaults to false.
• priority – Plugin’s priority. Defaults to 10.
• verbose – Verbose output. Defaults to false.
• include – Include files. Support wildcard pattern(s) in a string or array.
  • Exclude *.min.xml by default.
• removeComments – Remove comments in xml. Defaults to true.
• globOptions – See globbing section.

For more options, see minify-xml.

Remove whitespaces in json.

minify:
  json:
    enable: false
    include:
      - "*.json"
      - "!*.min.json"

• enable – Enable the plugin. Defaults to false.
• priority – Plugin’s priority. Defaults to 10.
• verbose – Verbose output. Defaults to false.
• include – Include files. Support wildcard pattern(s) in a string or array.
  • Exclude *.min.json by default.
• globOptions – See globbing section.

minify:
  gzip:
    enable: true
    include:
      - "*.html"
      - "*.css"
      - "*.js"
      - "*.txt"
      - "*.ttf"
      - "*.atom"
      - "*.stl"
      - "*.xml"
      - "*.svg"
      - "*.eot"
      - "*.json"

• enable – Enable the plugin. Defaults to true.
• priority – Plugin’s priority. Defaults to 10.
• verbose – Verbose output. Defaults to false.
• include – Include files. Support wildcard pattern(s) in a string or array.
  • Support one-liner, include: ['*.html','*.css','*.js'].
  • Must include asterisk and single quotes. .html is invalid. '*.html' is valid.
• globOptions – See globbing section.
• level – Compression level; lower value may results in faster compression but slightly larger (compressed) file. Range 1-9. Defaults to 9, or the value of zlib.constants.Z_BEST_COMPRESSION

minify:
  brotli:
    enable: true
    include:
      - "*.html"
      - "*.css"
      - "*.js"
      - "*.txt"
      - "*.ttf"
      - "*.atom"
      - "*.stl"
      - "*.xml"
      - "*.svg"
      - "*.eot"
      - "*.json"

• enable – Enable the plugin. Defaults to true.
• priority – Plugin’s priority. Defaults to 10.
• verbose – Verbose output. Defaults to false.
• include – Include files. Support wildcard pattern(s) in a string or array.
• globOptions – See globbing section.
• level – Compression level. Range 1-11. Defaults to 11, or the value of zlib.constants.BROTLI_MAX_QUALITY

minify:
  zstd:
    enable: false
    include:
      - "*.html"
      - "*.css"
      - "*.js"
      - "*.txt"
      - "*.ttf"
      - "*.atom"
      - "*.stl"
      - "*.xml"
      - "*.svg"
      - "*.eot"
      - "*.json"

• enable – Enable the plugin. Defaults to false.
• priority – Plugin’s priority. Defaults to 10.
• verbose – Verbose output. Defaults to false.
• include – Include files. Support wildcard pattern(s) in a string or array.
• globOptions – See globbing section.
• level – Compression level. Range 1-22. Defaults to 3, or the value of DEFAULT_LEVEL

Use “globOptions” to customise how glob patterns match files. Refer to micromatch for available options.

• basename is enabled by default, unless the pattern has a slash.
• basename is disabled depending on each pattern.
• This means the following options would work,

exclude:
  - "*foo.html" # basename is enabled
  - "**/bar/*/*.html" # basename is automatically disabled
  - "*baz.css" # basename is enabled
globOptions:
  basename: true # default

• This behaviour doesn’t apply to pattern that starts with ! (negation).
• This limitation only applies to include: option used in svg, gzip and brotli.
• This means the following options would not work,

include:
  - "!foo.svg"
  - "!**/bar/*/*.svg"
globOptions:
  basename: true

• basename will stay disabled, if explicitly disabled in “globOptions”.

All credits go to the following work:

• hexo-neat by rozbo
• gzip feature is inspired by hexo-generator-optimize

This is a series of EPrime (https://pstnet.com/products/e-prime/), Python, AFNI (https://afni.nimh.nih.gov/), FreeSurfer (https://surfer.nmr.mgh.harvard.edu/), and SLURM scripts built to streamline functional neuroimaging data analysis for the Aging Brain Cohort project at the University of South Carolina (ABC@UofSC) while leveraging the Hyperion supercomputing cluster. The current pipeline is designed specifically for the reading (‘fMRI_fam’) task which consists of single word presentations. However, in the future we will be adding scripts to generate word- or phrase-level timing files for the listening (‘passage_fMRI’) task, consisting of stories and passages presented auditorily to participants. There are many experimental questions that one can ask while analyzing these tasks due to a wide range of continuous and categorical variables of interest. Here, we have created an example pipeline for analysis of major contrasts (e.g. words vs. nonwords, pictures vs. words, foreign language passages vs. English passages), and we have provided notes advising users on how the pipeline may be modified to suit their more specific experimental questions.

Python 2.7 or later, with Pandas 1.0.3 or later

AFNI_20.1.02 or later

netpbm packages: pnmcat, pbmtext, pnmscale, pbmtopgm, (pnmcomp OR pamcomp)

FreeSurfer v6.0.0, or Freesurfer/2020-beta module if using the Hyperion Cluster

Access to Hyperion supercomputing cluster (optional but highly recommended)

For information about the stimuli, please see the ‘stimuli_and_design’ directory. Within this, there is a detailed README which describes the experimental design, stimuli, and provides examples of variables of interest that could be investigated. Also included in this directory are the EPrime scripts used for experimental presentation and .csv documents listing the stimuli and their associated psycholinguistic variables. Especially important is the ‘master_word’ directory, which provides the coding system that we have implemented for categorical variables of interest in the reading (‘fMRI_fam’) task. Understanding the coding system is vital for creating the fMRI timing files used by AFNI (Step #4 in the ‘Pipeline Flow’, described in sections below).

The figure above shows the order in which the pipeline should be executed. Steps #4 and greater will depend on the investigator’s desired analysis, and those scripts will need to be edited in order to reflect the specific experimental question (more information on this is provided in subsequent sections).

This is a SLURM batch array submission script calling AFNI’s @SSwarper command, which 1) aligns each subject’s anatomical T1 to a standard space target and 2) skull-strips that anatomical volume. This is AFNI’s recommendation for ‘pre-preprocessing’ (https://www.biorxiv.org/content/10.1101/308643v1.full.pdf), and is vital for proper execution of Steps #5 and above of our pipeline (actual analysis of the fMRI data). The script enters each desired subject’s data directory (named ‘1001’, ‘1002’, etc.) and applies @SSwarper to their anatomical scan (assumed to be named ‘T1.nii’), warping it to the MNI152_2009_template_SSW.nii.gz template. ‘giant_move’ and ‘deoblique’ are specified here in case the subject’s head was very tilted within the scanner.

Within each subject’s directory, output files should include (where $ = the subject’s number):

• anatDO.$.nii
• anatU.$.nii
• anatUA.$.nii
• anatUAC.$.nii
• anatS.$.nii
• anatSS.$.nii
• anatQQ.$.nii
• anatQQ.$.aff12.1D
• anatQQ.$WARP.nii
• anatQQ.$.nii
• AM$.jpg
• MA$.jpg
  The .jpg files are used to visually inspect the success of @SSwarper, while anatQQ.$.nii, anatQQ.$.aff12.1D, and anatQQ.$WARP.nii are called in Steps #5 and above of the pipeline.

This is a SLURM batch array submission script calling FreeSurfer’s ‘recon-all’ command (https://surfer.nmr.mgh.harvard.edu/fswiki/recon-all), which performs all of FreeSurfer’s standard cortical reconstruction processes using a subject’s anatomical scan (assumed to be named ‘T1.nii’). The script enters each desired subject’s data directory (named ‘1001’, ‘1002’, etc.), creates a new FS output directory (e.g. ‘1001_FS’), and places the output into that directory (example output files listed here: https://surfer.nmr.mgh.harvard.edu/fswiki/ReconAllOutputFiles). ‘parallel’ and ‘openmp #’ must be specified here in order to use multiple Hyperion cores. The # following openmp should match the number of cores you wish to use in the batch script.

Here, one must determine what type of analysis they wish to conduct, including which categorical or continuous variables of interest they want to choose. The scripts in the following sections have been written using very broad contrasts (i.e. words vs. nonwords, words vs. pictures, or foreign language vs. English passages), but a large number of more specific analyses are possible using our multiple psycholinguistic variables and categorical coding system provided in /stimuli_and_design/master_word/.

The following Python scripts use EPrime’s experimental output files for each subject (named ‘fMRI_fam-$subjectnumber-1-Export.txt’) to generate AFNI-formatted .txt timing files for response times and stimuli onset, which will be used in subsequent steps. The scripts should be executed in a single directory where every subject’s EPrime output file is stored. One should modify the scripts to reflect their desired analysis.

This script should be used if your desired analysis is purely categorical (i.e. no continuous psycholinguistic variables included). The current version creates separate timing .txt files for each subject for response times to all stimuli and onset times for the following categories: words, nonwords, pictures, concrete words, abstract words, high frequency words, and low frequency words. Categories can be added or deleted at the user’s discretion.

This script should be used if your desired analysis contains continuous variables (e.g. Age of acquisition, semantic diversity, etc.) for the purpose of ‘marrying’ stimuli onset times with the continuous variable associated with each specific stimulus. The current version, for each subject, marries our continous ‘Freq’ (word frequency) variable to the onset times for following categories: all words, concrete words, abstract words, high frequency words, and low frequency words. Output is .txt timing files that can be used with AFNI’s amplitude modulation regression (https://afni.nimh.nih.gov/pub/dist/doc/misc/Decon/AMregression.pdf), which is AFNI’s method of finding voxels whose activation is modulated by continuous variables. For example, using amplitude modulation and AM_marry.py for the all word category and frequency variable, you could find voxels that 1) are activated by words, regardless of frequency and 2) are modulated by the continuous frequency variable.

This script will be used for item-wise analysis, wherein an activation map will be created for each item, averaging across all of the subjects who saw that specific item. The current version creates a Pandas Dataframe where the rows are every stimulus seen by every participant thus far, and the columns represent each individual subject. The cells show the onset times at which the subjects saw a specific stimulus. Also included is the ability to search for a specific stimulus by its name, outputting a .csv file that contains the onset times for that single item, getting rid of all the subjects who did not see that item.

Note: If using the cluster, you do not actually run these scripts. Step #6 will call these scripts as needed.

These scripts assume that Steps #1 and #4 have been successfully completed. Within each subject’s directory should be the .txt timing files, the output of @SSwarper, and ‘fMRI_fam.nii’ and ‘fMRI_passage.nii’. The template MNI152_2009_template_SSW.nii.gz should be saved in a master directory with its path specified within the cmd.* scripts (via ‘set tpath’).

Two sample cmd.* scripts are provided:

• cmd.ap.ABC_fam_make_proc
• cmd.ap.ABC_pass_make_proc

These are scripts that will be used to generate AFNI’s proc analysis scripts (Step #6), with the ‘fam’ version being built for the reading task and the ‘pass’ version for the listening task. For the reading task, built-in contrasts include words vs. nonwords and words vs. pictures, while the listening task only contains foreign language vs. English passages. These scripts were closely based on AFNI’s current analysis recommendations (https://www.biorxiv.org/content/10.1101/308643v1.full.pdf). Users should feel free to modify these scripts as they see fit, and will need to modify their scripts based on the contrasts that they have chosen for their analysis.

This is a batch submission script which will run the cmd.* scripts from Step #5, generating AFNI proc scripts for every subject listed within the cmd.* scripts. Example output can be found in **proc.ABC_1006.

This step contains two scripts, depending on if the investigator is analyzing data from the reading (famWAV_array.sh) or listening (pass_array.sh) task. These are batch array submission scripts which will run all of the proc scripts for each subject that were generated in Step #6. Separate results directories will be generated for each subject in the master directory.

This application was created to give managers easy access to their team’s contact information.

• To utilize this application you will need Node.js.
• Clone this repository and open it within VS Code or any text editor of your choosing.
• Right-click on the index.js file within your explorer dock and select “open in integrated terminal”
• In your terminal type ‘NPM install’ and hit enter.
• Upon completion of the installation mentioned above, type ‘node index.js’ into the terminal, hit enter, and you will begin to receive a series of prompts.
• Once you have completed the series of prompts your team profile will be generated.

video demonstration: team generator

• Node.js
• Jest package
• Inquirer package
• Javascript
• Bootstrap
• JQuery
• HTML
• CSS

This application was created using test-driven development.
You can run these tests by going to the test folder, opening an integrated terminal, and typing in “npm test”.

Please follow the link below for a walkthrough video on how to run the tests mentioned above:
video demonstration: tests

Copyright (c) 2021 Olivia Lopez

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the “Software”), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Contact me @ https://github.com/DoubleLForce5 and/or lopez.olivia17@outlook.com

This app uses django rest framework to import csv files into the TeamScore Model on the backend. It is utilizing a postgres backend as well as a redis server to implement caching. It is also using HTMX for forms that enable team score objects to be added, edited and deleted. The front end utilizes bootstrap 5.

Below are the links to the documentation that was referred to in implementing this webapp:

HTMX for forms : https://htmx.org/

redis for caching : https://redis.io/

HTMX forms were implemented instead of standard Crispy forms to utilize immediate page updates without any refreshes using just HTML and minimal javascript instead of writing custom AJAX, Websockets or Server Event scripts.

To start the webapp manually, please have a redis server runnning and check your port connection to make sure it matches with the configurations on the .env file under the Cache section. If you are on a mac you can use homebrew and run:

brew install redis

brew services start redis

Test your connection by keying in PING, you should receive PONG as an output.

All sensitive information such as database password, secret keys and allowed hosts have been decoupled using python-decouple. These are stored in the .env file. Attached to this repository is a sample .env.example file, please rename this file to a .env file with your db parameters, secret key and allowed hosts.

Once redis is running, and a postgres db, db username and db password has been set up. Clone the repository and update the .env file with the appropriate settings, if you are in need of generating a secret key for the django web app you may retrieve one from : https://miniwebtool.com/django-secret-key-generator/

Create a python3 virtual environment in the root directory of the application, it is best to stick to the root directory as when this application is pushed to the production or staging server and is utilizing the Jenkinsfile for automated deployments, it is configured to look for the python virtual environment in the root directory (or you may choose to update this).

To create a virtual environment and activate it on a Mac:

python3 -m venv ./venv

source ./venv/bin/activate

Once your virtual environment has been activated you may install all libraries and dependencies for this application from the requirements.txt file.

pip install -r requirements.txt

To ensure that your static files are collected and a static folder is created in the root of your application run:

python manage.py collectstatic

When prompted key in Y for “Yes”

You should see a static folder in the root of your local repository

Next, run all migrations to ensure your tables are created in the database which you connected to using your .env file setup.

python manage.py makemigrations

python manage.py migrate

Run the following commands and input your desired username and password:

python manage.py createsuperuser

You may now run:

python manage.py runserver

Hit Ctrl + C to stop your server from running the application locally.

In case you would like to get a view of how mobile responsive the application is and how it works from a mobile device or an ipad. You may choose to run the application on your ip address at port 8000.

On a mac get your ip address by running:

ipconfig getifaddr en0

You should get your public IP address in this format :

190.16x.7x.1xx

Add this IP address to your ALLOWED_HOSTS in your .env file.

Now run the following command on your IP address at port 8000:

python manage.py runserver 190.16x.7x.1xx:8000

Your phone or ipad should be connected to the same WiFi your laptop is connected to. You may view the app on your mobile browser using this link:

190.16x.7x.1xx:8000

This application also uses Python’s default basicConfig logging, to log events for the API. You can find these outputs in the logging.log file generated. Refer to this for tracebacks should there be any errors with the core API to import CSV files.

To run tests:

python manage.py test

Logging is also implemented for tests, the output can be found in testing.log. All test files are found in individual app folders, they were not compiled into a single folder due to time constraints.

The attached Jenkinsfile assumes that there will be both a staging and production server assuming nginx and gunicorn will be used to serve the webapp.

To run the docker image of this application, install docker into your local environment

You may refer to their documentation : https://docs.docker.com/desktop/install/mac-install/

Once you have docker installed, it is important that you change these parameters on your .env file to follow the name of the service for postgres and redis on the docker-compose file.

DB_HOST=db

REDIS_HOST=redis

To build an image of the application run:

docker compose build

docker compose up -d

docker-compose exec tigerlab python3 manage.py migrate

You may view the application running on docker at:

localhost:8000

docker exec -t -i tigerlab-app /bin/bash

To execute any commands to your docker container, for e.g. to create a superuser:

docker-compose exec tigerlab python3 manage.py createsuperuser

The command below will stop the tigerlab-app container but will not remove the container or the tigerlab image built from your build command previously:

docker-compose stop

If you wish to stop and remove the container and image, run the command below:

docker-compose down

If you have previously started the container without specifing the environment variables, volumes would be created for the default postgres db and your .env file will be skipped, to fix this remove the volumes attached to your tigerlab image

TO remove all volumes:

docker volume rm $(docker volume ls -q)

TO remove a specific volume:

docker volume rm $(volumename)

Due to time constraints, I was not able to improvise on the data fetch event for the dashboard page using htmx, right now it is triggered every 1 second to check for new file uploads. Ideally it should implement a data fetch on an event change like the analytics page does to reduce server load.

Caching could be implemented for the dashboard page as well. Right now it is only implemented on the analytics page. More tests could be done.

On the OUTPUT page and DASHBOARD PAGE, if a huge amount of data is loaded the tables will be an endless scroll with data lag, it is best to implement Pagination should there be a huge amount of data uploads, the pagination can be implemented in pages or an infinite scroll with AJAX calling on data as the user scrolls instead of a one time data dump.

Dashboard for file submit, ranking, and points

CSV File upload output

Edit Data Points

Add Data Points

Modal pop up to confirm file deletes

1. Install hubot. Make sure to npm install --save hubot-botframework to add this module.

   • Authorization and Card-based interactions are in alpha testing and are not part of the published npm package, so to use these features, clone or download this repository and install it as a local dependency of your hubot. Then after running npm install for your hubot, in the local copy of the BotFramework adapter, run npm install --production then run npm install --save <<relative-path-to-your-hubot>>/node_modules/hubot to point the local copy of the BotFramework adapter to your hubot.

2. Create a Botframework Registration by completing the Bot Registration Page. Store the created app id and app password for use later.

3. Configure the required environment variables, and run the command ./bin/hubot -a botframework to run the bot from your local computer.

You can then interact with your hubot through any Bot Framework supported channel.

4. Create a Microsoft Teams app package (.zip) to upload in Teams. We recommend using the manifest editor in App Studio for Microsoft Teams. Include the bot’s app id and password in the bots section.

5. In Microsoft Teams, navigate to the Store and select Upload a custom app. Select the zipped Teams App Package, and install the bot for personal and/or team use.

You can then interact with hubot through a personal chat or by @mentioning the name of the uploaded custom app in a Team. In personal chats, the bot’s name can be dropped from messages(ping or hubot ping). In Teams, @mention the bot and omit the bot’s name from the command (@myhubot ping).

1. Microsoft Teams uses a push model to send messages. This means that hubots that want to communicate in Teams MUST expose themselves via a public HTTPS endpoint that Microsoft Teams services can push messages to.
2. The bot MUST be @ mentioned in a channel to receive a message. Microsoft Teams does NOT send all messages to the bot.

You can configure the Hubot BotFramework adapter through environment variables.

Required (obtained from the BotFramework portal):

1. BOTBUILDER_APP_ID – This is the Id of your bot.
2. BOTBUILDER_APP_PASSWORD – This is the secret for your bot.

Optional:

1. BOTBUILDER_ENDPOINT – Sets a custom HTTP endpoint for your bot to receive messages on (default is /api/messages).

2. HUBOT_TEAMS_ENABLE_AUTH – When set to true, restricts sending commands to hubot to a specific set of users in Teams. Messages from all non-Teams channels are blocked. Authorization is disabled by default.

3. HUBOT_TEAMS_INITIAL_ADMINS – Required if HUBOT_TEAMS_ENABLE_AUTH is true. A comma-separated list of user principal names (UPNs). The users on this list will be admins and able to send commands to hubot when the hubot is first run with authorization enabled.

These variables will only take effect if a user communicates with your hubot through Microsoft Teams.

Optional:

1. HUBOT_OFFICE365_TENANT_FILTER – Comma seperated list of Office365 tenant Ids that are allowed to communicate with your hubot. By default ALL Office365 tenants can communicate with your hubot if they sideload your application manifest.

NOTE: The UPNs used for authorization are stored in the hubot brain, so brain persistence affects the use of HUBOT_TEAMS_INITIAL_ADMINS as described below.

Authorization restricts the users that can send commands to hubot to a defined set of Microsoft Teams users. Authorization is currently only supported for the Teams channel, so when enabled, messages from all other channels are blocked. To maximize back compatibility, authorization is disabled by default and must be enabled to be used.

Authorization is set up using the HUBOT_TEAMS_ENABLE_AUTH and HUBOT_TEAMS_INITIAL_ADMINS environment variables.

• HUBOT_TEAMS_ENABLE_AUTH controls whether authorization is enabled or not. If the variable is not set, authorization is disabled. To enable authorization, set the environment variable to true.

• HUBOT_TEAMS_INITIAL_ADMINS is required if authorization is enabled. This variable contains a comma-separated list of UPNs. When the hubot is run with authorization enabled for the first time, the users whose UPNs are listed will be admins and authorized to send commands to hubot. These UPNs are stored in the hubot brain. After running hubot with authorization enabled for the first time:

  • If your hubot brain is persistent, to change the list of authorized users, first delete the stored list of authorized users from your hubot’s brain then change HUBOT_TEAMS_INITIAL_ADMINS to the new list. Also consider using the hubot-msteams script package to dynamically control authorizations.

  • If your hubot brain isn’t persistent, the HUBOT_TEAMS_INITIAL_ADMINS list will be used to set admins every time hubot is restarted.

Add screenshots (create an images folder to store them in)

Hubot is great, but hubot without needing to type in whole commands and with less typos is even better. Card-based interactions wrap hubot responses into cards and provide buttons on the card containing useful follow-up commands. To run a follow-up command, simply click the button with the command. If user input is needed, another card is shown with fields for input, and the rest of the command is constructed for you.

Currently, card based interactions are supported for the hubot-github package.

Adding new card-based interactions has two steps:

1. Add entries to HubotResponseCards located in src/hubot-response-cards.coffee. Each entry is from a regex to an array of follow up commands.

   • The regex should map to the command that you want to generate a card for with wildcards for the hubot’s name and regexes for each user input. See the hubot-github entries for examples.
   • The follow up queries should match the key for the follow up command in HubotQueryParts.

2. Add entries to HubotQueryParts located in src/hubot-query-parts.coffee. Each entry is from the command to two arrays containing the text and input parts of a command. These arrays are used to construct the query with any user inputs to send to hubot.

   • textParts contains the text surrounding any user inputs, if a command has no user input, it contains one string in textParts. Note that the first entry of textParts starts with ‘hubot’
   • inputParts contains representations of each user input in a command, if any. The text is used to prompt the user for input. A special syntax can used for inputs with finite choices to create a dropdown selector. In this case, a / is used followed by the choices separated by the word ” or “. See the hubot-github entries for examples.

Once these entries have been added, cards with follow up commands will be generated for the commands added to HubotResponseCards. For menu cards used to initiate card-based interactions for any command in a script library, use the hubot-msteams library.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments

SolutionBase is a social platform for users to address global sustainability issues like global warming, plastic free etc. Platform allows user to contribute their ideas/solutions to different topics and problems. Read more about sustainable development goals here.

SolutionBase

SolutionBase Wiki

Design

One main feature is users can filter and sort posts in multiple combination. Their preferences are stored so that when they returned to homepage, it is still in sorted order and/or filtered.

1. We have a slice of state to keep track of sorting and filtering, separated by topic page and homepage.

2. For sorting, we use thunk action updateSort to update Redux store, and then, depending on the key, either fetchTopic or fetchPosts using the data object, which becomes the parameter Topic or Post controller receives.

// frontend/actions/filter_actions.js
export const updateSort = (id, data, key) => dispatch => {
  dispatch(receiveSort(id, data, key));
  if (key === 'topic') {
    return fetchTopic(id, data)(dispatch);
  } else if (key === 'homepage') {
    return fetchPosts(data)(dispatch);
  }
};

3. The data object gets evaluated in the Topic or Post controller in index and calls Post’s class method sort_filter. This method checks the sorting type and calls the responsible class methods, which then uses ActiveRecord to query the database.

# app/models/post.rb
def self.sort_filter(sort)
  case sort[:sort]
  when 'most recent'
    self.most_recent(sort[:topic_id], sort[:post_type])
  when 'most comments'
    self.most_commented(sort[:topic_id], sort[:post_type])
  when 'most votes'
    self.most_votes(sort[:topic_id], sort[:post_type])
  end
end

4. When posts are received, we also receive a postOrder array, which is used to map posts in the sorted order.

5. Every sort and filter action is stored and updated in Redux store and passed down to a component with mapStateToProps. So component dispatches updateSort on mount with the latest filter and sorting parameters.

To have children comments nested under a parent comment, we use recursion and Javascript object to achieve better time complexity.

If we have 1000 comments c1, we do not want to iteratre all 1000 comments checking if its c2.parent_comment_id equals to c1.id. This will be 1000 * 1000 comparisons and an O(n^2) algorithm.

We can achieve this with O(n) time, where n is total number of comments.

1. When we receive a post, we receive an array of all_comments, which is stored in the comments slice of Redux store. In a selector function that takes in state and the currently viewed post as arguments, we create an object with keys as parent_comment_id and values arrays of their children comments. Comments with no parent have null as their keys.

// frontend/reducers/selectors.js
export const selectCommentsForPost = ({comments}, post) => {
  // handle cases where there are no comments or we have not fetchPost
  if (!Object.keys(comments).length) return {};
  if (post.commentIds.filter(commentId => !comments[commentId]).length) return {};
  // create map-like object
  let hash = {};
  post.commentIds.map(commentId => comments[commentId])
    .forEach((comment) => {
      let parent = comment.parent_comment_id;
      let children = hash[parent];
      let update;
      if (children) {
        update = { [parent] : [...children, comment] }
      } else {
        update = { [parent] : [comment] }
      }
      hash = Object.assign({}, hash, update);
    })
  return hash;
}

2. In the PostShow component, we have a renderComments method that takes a parent comment ID as an argument. This method lookups the children comments in the hash object created above and map over all the children comments. It makes a recursive call with each child comment ID to get its children comments. We call the function with null (comments with no parent) first, which will go through all their children and then their grandchildren and so on.

// frontend/components/posts/post_show.jsx
  function renderComments(id) {
    return (
      <>
        {comments[id].map(comment => (
          <>
            {singleComment(comment)} // returns <CommentIndexItem />
            <ul>
              {comments[comment.id] && <li>{renderComments(comment.id)}</li>}
            </ul>
          </>
        ))}
      </>
    )
  }
  ...
  return (
    ...
    renderComments(null)
    ...
  )

1. Front end

   Use the npm package manager to install dependencies in root directory.

   npm install
   npm run webpack

2. Back end

   Install rails dependencies in root directory, setup Postgres database and start development server.

   rails bundle exec install
   # create the database, load the schema, and initialize it with the seed data
   rails db:setup
   rails s

   You can view the full application on localhost:3000.

Front-end:

• React – Front end framework
• Redux – State management tool used with React
• jQuery – DOM Manipulation
• AJAX – AJAX used for API calls
• Javascript – Language for site functionality
• React-Bootstrap – – Used for advanced styling and design system
• Material-UI – Used for advanced styling
• Styled-Component – Used for custom styling React components
• CSS3 – Used in conjunction with Material-UI for styling
• HTML5 – Used for general structure of webpage

Back-end:

• Ruby
• Ruby on Rails
• Postgres
• jBuilder

• Lazy loading / Infinite scrolling
• Profile page
• Text based search
• Live time update new posts, comments and their vote counts with WebSockets

No entire COVID-19 statistics data of the Shanghai lockdown period can be found in the JHU CSSE COVID-19 Data project. Data of project shanghai-lockdown-covid-19 is crawled from Shanghai Government‘s public website, began on 19/03/2022, the date of my place lockdown.

Shanghai is divided by the Huangpu River into two parts, the Pudong area, and the Puxi area. Pudong’s lockdown began on 28/03/2022 firstly, and Puxi started its shutdown on 01/04/2022.

Shanghai Government has announced its city-wide lockdowns will be gradually lifted from 1 June on 16/05/2022, after 15 out of 16 districts achieving “social dynamic Zero-Covid cases”. My place alse reopened on the same day, but with some limits.

Shanghai returned to normal on 1 June, the epidemic wave in the city is under control effectively and this project has stopped updating at 2 June.

Data files can be found in directory data, including:

• JSON
• CSV
• Excel
• Sqlite

Notice: I think db files are too large, and they will make this repo hard to clone. If you want to get the latest db files, uncomment the line in db.py and run the file to generate all db files.

I have disabled the update workflow at 2 June, this project will not be updated anymore.

This project will be updated every 15min between 8am and 10pm GMT+8 by GitHub Actions.

git clone --depeth=1 https://github.com/lewangdev/shanghai-lockdown-covid-19.git

• New Cases = Confirmed Cases + Asymptomatic Cases – A2C Cases
• A2C Cases: Asymptomatic cases that are confirmed

• Shanghai Municipal Health Commission’s website

Fortify is a puzzle game where your objective is to protect teddy 🧸

This game was made during the Global Game Jam 2019 (GGJ). The theme of the jam was:

What home means to you

This project was bootstrapped with phaser-template and hosted on remarkablegames. To learn more, read the following blog post.

Play this game on:

• remarkablegames
• Newgrounds

• Node.js
• npm

Clone repository:

git clone https://github.com/remarkablegames/fortify.git

Install dependencies:

npm install

In the project directory, you can run:

Runs the game in the development mode.

Open http://localhost:3000 to view it in the browser.

The page will reload if you make edits.

You will also see any lint errors in the console.

Builds the game for production to the build folder.

It correctly bundles in production mode and optimizes the build for the best performance.

The build is minified and the filenames include the hashes.

Your game is ready to be deployed!

Bumps the package.json using standard-version.

Deploys the game to GitHub Pages by force pushing the build folder to the remote repository’s gh-pages branch.

If you’re uploading the game to a site, make sure to do the following:

1. Open package.json and change the "homepage" value to ".". This ensures the links are relative. Optional: update the game config url in src/index.js.

2. Optional: remove GitHub Corners from public/index.html and src/index.css.

3. Build the game, remove any unnecessary files, and compress the folder into a zip archive:

   npm run clean
   npm run build
   rm build/service-worker.js
   zip -r fortify.zip build

4. Don’t forget to clean up the project directory after the upload succeeds:

   rm fortify.zip

MIT

A strong foundation for building predictable and straight-forward Rust UI toolkits. Reclutch is:

• Bare: Very little UI code is included. In practice it’s a utility library which makes very little assumptions about the toolkit or UI.
• Platform-agnostic: Although a default display object is provided, the type of display object is generic, meaning you can build for platforms other than desktop. For example you can create web applications simply by using DOM nodes as display objects while still being efficient, given the retained-mode design.
• Reusable: Provided structures such as unbound queue handlers allow for the reuse of common logical components across widgets.

Reclutch implements the well-known retained-mode widget ownership design within safe Rust, following along the footsteps of popular desktop frameworks. To implement this behavior, three core ideas are implemented:

• A widget ownership model with no middleman, allowing widgets to mutate children at any time, but also collect children as a whole to make traversing the widget tree a trivial task.
• A robust event queue system with support for futures, crossbeam and winit event loop integration, plus a multitude of queue utilities and queue variations for support in any environment.
• An event queue abstraction to facilitate just-in-time event coordination between widgets, filling any pitfalls that may arise when using event queues. Beyond this, it also moves the code to handle queues to the constructor, presenting an opportunity to modularize and reuse logic across widgets.

There appears to be a bug with shared OpenGL textures on MacOS. As a result, the opengl example won’t work correctly. For applications that require rendering from multiple contexts into a single texture, consider using Vulkan or similar.

• Events and event queues
• Otway

All rendering details have been excluded for simplicity.

#[derive(WidgetChildren)]
struct Button {
    pub button_press: RcEventQueue<()>,
    graph: VerbGraph<Button, ()>,
}

impl Button {
    pub fn new(global: &mut RcEventQueue<WindowEvent>) -> Self {
        Button {
            button_press: RcEventQueue::new(),
            global_listener: VerbGraph::new().add(
                "global",
                QueueHandler::new(global).on("click", |button, _aux, _event: WindowEvent| {
                    button.button_press.emit_owned(());
                }),
            ),
        }
    }
}

impl Widget for Button {
    type UpdateAux = ();
    type GraphicalAux = ();
    type DisplayObject = DisplayCommand;

    fn bounds(&self) -> Rect { /* --snip-- */ }

    fn update(&mut self, aux: &mut ()) {
        // Note: this helper function requires that `HasVerbGraph` be implemented on `Self`.
        reclutch_verbgraph::update_all(self, aux);
        // The equivalent version which doesn't require `HasVerbGraph` is;
        let mut graph = self.graph.take().unwrap();
        graph.update_all(self, aux);
        self.graph = Some(graph);
    }

    fn draw(&mut self, display: &mut dyn GraphicsDisplay, _aux: &mut ()) { /* --snip-- */ }
}

The classic counter example can be found in examples/overview.

Children are stored manually by the implementing widget type.

#[derive(WidgetChildren)]
struct ExampleWidget {
    #[widget_child]
    child: AnotherWidget,
    #[vec_widget_child]
    children: Vec<AnotherWidget>,
}

Which expands to exactly…

impl reclutch::widget::WidgetChildren for ExampleWidget {
    fn children(
        &self,
    ) -> Vec<
        &dyn reclutch::widget::WidgetChildren<
            UpdateAux = Self::UpdateAux,
            GraphicalAux = Self::GraphicalAux,
            DisplayObject = Self::DisplayObject,
        >,
    > {
        let mut children = Vec::with_capacity(1 + self.children.len());
        children.push(&self.child as _);
        for child in &self.children {
            children.push(child as _);
        }
        children
    }

    fn children_mut(
        &mut self,
    ) -> Vec<
        &mut dyn reclutch::widget::WidgetChildren<
            UpdateAux = Self::UpdateAux,
            GraphicalAux = Self::GraphicalAux,
            DisplayObject = Self::DisplayObject,
        >,
    > {
        let mut children = Vec::with_capacity(1 + self.children.len());
        children.push(&mut self.child as _);
        for child in &mut self.children {
            children.push(child as _);
        }
        children
    }
}

(Note: you can switch out the reclutch::widget::WidgetChildrens above with your own trait using #[widget_children_trait(...)])

Then all the other functions (draw, update, maybe even bounds for parent clipping) are propagated manually (or your API can have a function which automatically and recursively invokes for both parent and child);

fn draw(&mut self, display: &mut dyn GraphicsDisplay) {
    // do our own rendering here...

    // ...then propagate to children
    for child in self.children_mut() {
        child.draw(display);
    }
}

Note: WidgetChildren requires that Widget is implemented.

The derive functionality is a feature, enabled by default.

Rendering is done through “command groups”. It’s designed in a way that both a retained-mode renderer (e.g. WebRender) and an immediate-mode renderer (Direct2D, Skia, Cairo) can be implemented. The API also supports Z-Order.

struct VisualWidget {
    command_group: CommandGroup,
}

impl Widget for VisualWidget {
    // --snip--

    fn update(&mut self, _aux: &mut ()) {
        if self.changed {
            // This simply sets an internal boolean to "true", so don't be afraid to call it multiple times during updating.
            self.command_group.repaint();
        }
    }

    // Draws a nice red rectangle.
    fn draw(&mut self, display: &mut dyn GraphicsDisplay, _aux: &mut ()) {
        let mut builder = DisplayListBuilder::new();
        builder.push_rectangle(
            Rect::new(Point::new(10.0, 10.0), Size::new(30.0, 50.0)),
            GraphicsDisplayPaint::Fill(Color::new(1.0, 0.0, 0.0, 1.0).into()),
            None);

        // Only pushes/modifies the command group if a repaint is needed.
        self.command_group.push(display, &builder.build(), Default::default(), None, true);

        draw_children();
    }

    // --snip--
}

The update method on widgets is an opportunity for widgets to update layout, animations, etc. and more importantly handle events that have been emitted since the last update.

Widgets have an associated type; UpdateAux which allows for a global object to be passed around during updating. This is useful for things like updating a layout.

Here’s a simple example;

type UpdateAux = Globals;

fn update(&mut self, aux: &mut Globals) {
    if aux.layout.node_is_dirty(self.layout_node) {
        self.bounds = aux.layout.get_node(self.layout_node);
        self.command_group.repaint();
    }

    self.update_animations(aux.delta_time());

    // propagation is done manually
    for child in self.children_mut() {
        child.update(aux);
    }

    // If your UI doesn't update constantly, then you must check child events *after* propagation,
    // but if it does update constantly, then it's more of a micro-optimization, since any missed events
    // will come back around next update.
    //
    // This kind of consideration can be avoided by using the more "modern" updating API; `verbgraph`,
    // which is discussed in the "Updating correctly" section.
    for press_event in self.button_press_listener.peek() {
        self.on_button_press(press_event);
    }
}