quackbarc

\b(?:(?<fizzbuzz>(?:(?:[369]|[258][0369]*[147]|(?:[147]|[258][0369]*[258])(?:[0369]|[147][0369]*[258])*(?:[28]|[147][0369]*[147]))*(?:0|(?:[147]|[258][0369]*[258])(?:[0369]|[147][0369]*[258])*5))+)|(?<buzz>\d*[05])|(?<fizz>(?:[0369]|[258][0369]*[147]|(?:[147]|[258][0369]*[258])(?:[0369]|[147][0369]*[258])*(?:[258]|[147][0369]*[147]))+))\b

insanity, as i'd like to call it. although it isn't fizzbuzz per se, it's the best you can get with regex. here's a regexr link to it with sample text.

this matches a number (within word boundaries) if it falls under any of the three groups:

• fizzbuzz, which picks up numbers divisible by both 3 and 5, i.e. 15;
• buzz, which picks up numbers divisible by 5; and
• fizz, which picks up numbers divisible by 3.

mcroach

Storing image assets in your repo and referencing in markdown

Create an assets branch and make the initial commit

git checkout --orphan assets
git reset --hard
cp /path/to/cat.png .
git add .
git commit -m 'Added cat picture'
git push -u origin assets

qoomon

Conventional Commit Messages

See how a minor change to your commit message style can make a difference.

Tip

Take a look at git-conventional-commits , a CLI util to ensure these conventions, determine version and generate changelogs

Commit Message Formats

Default

fbaierl

No, you are not allowed to change the copyright notice. Indeed, the license text states pretty clearly:

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

But you are allowed to add a copyright notice.

If you want to keep the MIT license, which is what I would advise you to do, you only need to add a single line to the license file, before or after Copyright (c) 2012 Some Name with your own copyright notice. The final LICENSE file will look like this:

The MIT License (MIT)

fnky

ANSI Escape Sequences

Standard escape codes are prefixed with Escape:

• Ctrl-Key: ^[
• Octal: \033
• Unicode: \u001b
• Hexadecimal: \x1B
• Decimal: 27

timvisee

Falsehoods programmers believe about time

This is a compiled list of falsehoods programmers tend to believe about working with time.

Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.

Falsehoods

• There are always 24 hours in a day.
• February is always 28 days long.
• Any 24-hour period will always begin and end in the same day (or week, or month).