Projects

Each project is a web app, a subdomain of voyc.com, stored in gitlab (previously github).

layout - browser screen splitter

account - submodule, user management

fx - submodule, library of game effects

icon - submodule, library of icons

jslib - library of javascript tools

minimal - html, css, javascript for a minimal web app

homepage - homepage for voyc.com

pokerface - facial expressions of artificial feelings

geo - geopolitics map drawing

curriculum - voycipedia

global - previously voyc, before geo

samantha - AI webchat

classy - comment classifier

sandbox - experiment and demo

bahasa - language

flash - flash card memorization

guru - random quote

mai - language

plunder - game added atop voyc

sanskrit - language

robots - multiple hardware projects

vote - ranked choice voting

wordnet - database only, sql version of Princeton's WordNet

model - starter project template

timeline - timeline

voyc - leftover from when geo/global was voyc.com

projects checklist sheet

webapps sheet

Always use the tab character to indent.

robots.txt
.well-known/*
js.min
css.min
index.php
RELEASES.md

Most of our projects have a dev and a production version.
Example:

• jslib.voyc.com
• jslib.hagstrand.com

These two sites have duplicate content.
We want to tell the search engines to index prod, not dev.
How do we do that?

User-agent: *
Disallow: /

This prevents the search engines from crawling the site.
But it does NOT prevent the search engines from indexing the site.

<meta name='robots' content='noindex,follow' />

This means that prod and dev will have a different line in index.html.
How can I do this dynamically? The crawlers are probably scraping the HTML without preprocessing javascript or PHP.

How do we do that?

• Take care to not allow any links to the dev subdomains.

1. Note that the a2 cpanel domains page has the <meta robots noindex> tag.
2. When starting server development, manually add the <meta robots noindex> tag.
3. After completion, delete the worktree, and/or put up a fake page.
4. Maybe we only need one dev subdomain?

gitlab, voycgit, and webprod have a master branch only.
webdev and webapps have a master branch and also a temporary feature branch.

voycgit has no remotes.
gitlab has no remotes.
All other repositories have remote origin pointing to voycgit.
webprod also has remote gitlab.

get remote -v
$ origin ssh://voyccom@az1-ss8.a2hosting.com:7822/home/voyccom/voycgit/jslib.git	
$ gitlab https://gitlab.com/voyc/jslib.git

Note that use the ssh protocol; never the local protocol.

git clone ssh://voyccom@az1-ss8.a2hosting.com:7822/home/voyccom/voycgit/vote.git
git branch   # make sure you're in the master branch
git pull origin master
git submodule foreach git pull origin master

git branch popup         # create a feature branch
git checkout popup

<make changes>
git status
git add .
git commit -m 'New popup architecture'   # version control
git push origin popup      # remote backup

git switch master
git pull origin master 
git checkout popup
git rebase master               # merge modified master into popup branch, resolve conflicts here

git checkout master
git merge popup
git diff master..popup
git branch -d popup
git push origin master      # push to central
git push origin -d popup   # delete branch from central

git pull origin master
git push gitlab master

Trends in release management as of 2026.

• 50/72 rule. A commit message has three lines (title, blank, body). The first line is the title and it is 50 characters long. The second line is blank. The third and subsequent lines make up the body; they are bullets, and they are 72 characters long. [Ed. title is my word. Other people say description or subject.]
• Conventional Commits. The first line of the commit message is prefixed with a category: feat, fix, perf, style, refactor, test, build, chore. This rule overrides an earlier rule that the title should be capitalized.
• Semantic Versioning. Each release is numbered major.minor.patch, like 14.3.5. When a development group breaks backward compatibility, now a normalized behavior, they assign a new major number. When a bug is discovered that is so dangerous it must be fixed immediately, they release a patch.

more on Conventional Commits
more on Semantic Versioning
Tim Pope: A Note About Git Commit Messages, 2008.

At voyc we use these above trends in commit messages and tag messages. The log of commit messages is detailed for developers. The list of tag messages is more abstract, for users and managers. Release histories are generated by script from the list of tag messages.

At deployment, a file named RELEASES.md is generated from the tag messages by a script. It is not committed; it listed in .gitignore.

more about log and tag

# All tags with their full messages, most recent first
git tag -l --sort=-version:refname | xargs -I{} git show {} --no-patch --pretty=format:"%tag %*%(tag)%n%s%n%b%n---"

git for-each-ref --sort=-version:refname --format="%(refname:short)%0a%(contents)%0a---" refs/tags

Practices:

• Commits made only in feature branch. Never on the master branch.
• We let aider auto-commit every change.
• At merge, we generally keep the detailed commits, but squash is optional.
• The commit log is for developers.
• At release, we create a tag, observing SemVer, with hand-written message.
• Public release history is generated from the tag messages.
• Conventional commits types are used only on the commit messages, not the tag messages.

# in laptop dev repo

# git filter-repo --mailmap .mailmap --force
# lint

git checkout master
git merge blend
git branch -d blend

git tag v0.0.0 -m'...'

git push origin master --force --tags
git push origin --delete blend

# in production webserver

git fetch origin
git reset --hard origin/master

git push gitlab master --tags