Nikita Makhov Defite

Using Git Commit Message Templates to Write Better Commit Messages

One of my colleagues shared an article on writing (good) Git commit messages today: How to Write a Git Commit Message. This excellent article explains why good Git commit messages are important, and explains what constitutes a good commit message. I wholeheartedly agree with what @cbeams writes in his article. (Have you read it yet? If not, go read it now. I'll wait.) It's sensible stuff. So I decided to start following the

Using Git Commit Message Templates to Write Better Commit Messages

One of my colleagues shared an article on writing (good) Git commit messages today: How to Write a Git Commit Message. This excellent article explains why good Git commit messages are important, and explains what constitutes a good commit message. I wholeheartedly agree with what @cbeams writes in his article. (Have you read it yet? If not, go read it now. I'll wait.) It's sensible stuff. So I decided to start following the

О сжатии на протокольном уровне (http)

Актулизировано на момент 22.11.2018

Обозреваемые форматы сжатия:

gzip 1 - минимальный уровень сжатия gzip, результат .gz
gzip 9 - максимальный уровень сжатия gzip, результат .gz
zopfli - отдельный алгоритм совместимый с распаковщиком gzip, результат .gz
brotli 11 - полностью новый формат, 11 это максимальный уровень сжатия, результат .br

Не рассматривается - sdch(нет поддержки в современных браузерах), попытки запустить gzip > 1, zopfli, brotli на лету без пребилда сжатых файлов (для нас не актуально, очень много данных)

There are certain files created by particular editors, IDEs, operating systems, etc., that do not belong in a repository. But adding system-specific files to the repo's .gitignore is considered a poor practice. This file should only exclude files and directories that are a part of the package that should not be versioned (such as the node_modules directory) as well as files that are generated (and regenerated) as artifacts of a build process.

All other files should be in your own global gitignore file. Create a file called .gitignore in your home directory and add anything you want to ignore. You then need to tell git where your global gitignore file is.

Mac

git config --global core.excludesfile ~/.gitignore

Windows

git config --global core.excludesfile %USERPROFILE%\.gitignore

	# Backup
	docker exec CONTAINER /usr/bin/mysqldump -u root --password=root DATABASE > backup.sql

	# Restore
	cat backup.sql \| docker exec -i CONTAINER /usr/bin/mysql -u root --password=root DATABASE

	/**
	* Split a string into chunks of the given size
	* @param {String} string is the String to split
	* @param {Number} size is the size you of the cuts
	* @return {Array} an Array with the strings
	*/
	function splitString (string, size) {
	var re = new RegExp('.{1,' + size + '}', 'g');
	return string.match(re);
	}

	// ### Content Helper
	//
	// Usage example:
	// `{{content}}`
	// `{{content words="20"}}`
	// `{{content characters="256"}}`
	// `{{content preview="true"}}`
	//
	// Turns content html into a safestring so that the user doesn't have to
	// escape it or tell handlebars to leave it alone with a triple-brace.

	/*
	Adaption of Hexo's hexo\node_modules\hexo-util\lib\util\highlight.js

	original code highlighter uses <figure> and <table>s as gutter. Had some validation issues. Also did not accept
	standard higlightjs themes (https://github.com/isagalaev/highlight.js/tree/master/src/styles) which are now
	just drop in.

	captions still require a tiny bit of css of your own because they're not standard in highlightjs.

	I'm accompanying this by a tiny JS that adds .hljs to every pre tag that doesn't contain it, so it applies to

	// Use Gists to store code you would like to remember later on
	console.log(window); // log the "window" object to the console