Artificial Dependencies and Pseudo-blockers

Someone on a development team could come up with an idea like: “Let’s do these 2 features in a single epic! They both are cool and about similar topic.”. Being inspired, they convince everyone to do things that way. And everything goes quite well until the release date. Sprint or waterfall - doesn’t matter. There suddenly it’s been becoming revealed that the wunder-epic is ready by 99%. Nothing is going to be released as a result. Users are bored. Management scolds.

The saddest part of this story is that the 1-st feature is 100% ready. It could be released with no effort if the brilliant mind hadn’t suggested to mix the things up. Now it requires additional effort to cherry-pick the related commits to another branch at least. So being united the 98%-ready 2-nd feature becomes a pseudo-blocker for the 1-st feature release.

To avoid this resist the temptation to put similar things to the same cauldron. Make your scopes granular and bite-sized. This keeps them more manageable and easier to clarify.

Be the bless with you against the artificial dependencies!

Free wireframe tools

Let’s assume we want to mock up screens of an app. What except well-known can we find?

First of all, they’re called “wireframes”, not “mockups”. A mockup is some mock with your text on anything from cups and T-shirts to ad-shields. So, free tools to create wireframes:

NTFS mount options

There are lots of articles on mounting of NTFS partitions. Some are way too simple, some are outdated. Almost none of them explain the decisions made. We’ll fix all of that.

Every emphasized option is a default and maybe omitted.

Let’s start from the common useful options in man mount.

  • defaults: implies rw, suid, dev, exec, auto, nouser, and async.

  • async: a strong default until you want sync for some reason.

  • auto: let’s take part in “mount all” command.

  • nostrictatime: forbid OS to change inode on every access.

And NTFS-specific from the same man:

  • utf8: to use it for converting file names.

  • uid=1000: set the very first user (usually admin) as the owner.

  • gid=plugdev: set the plugdev group as the owner group. It’s handy since every Ubuntu user is in that group by default.

  • umask=0002: by design should give 3775 octal permission, or sgrwxrwxr-x. But in fact sticky and guid seem not to work.

Additional NTFS-specific options from man ntfs-3g:

  • windows_names: enable Windows restrictions for new file names.

  • streams_interface=xattr: enable “Alternate Data Streams” support in Linux flavor.

  • allow_other: without it file access will be restricted to the user mounting the FS.

  • nocompression: disable Windows compression for new files.

If you’ve mapped users:

  • usermapping=abs_file_name: set the map file if not default.

  • permissions: full POSIX features of ownership and permissions. acl is only good when you need complex permissions.

  • inherit: enable Windows-compatible inheritance of permissions.

So the minimal option pack without mapping is:


Doubtful options I’ve met:

  • nls: see no sense in it, since utf8 is on board.

  • locale: “It is however discouraged as it leads to files with untranslatable chars to not be visible.”

  • default_permissions:

    The permissions option is ignored and automatically changed to default_permissions whenever any of the following options is also included with it:

    uid, gid, umask, dmask, or fmask

  • blksize: even couldn’t google the origin.

Best D&D 5 Virtual Tabletop for Free

The short answer is: use Roll20 or MapTool - what works better for you.

The alternatives considered:

  • Fantasy Grounds: too limited in free edition.

  • D&D beyond: has poor features for free, too.

  • d20pro: has only 30-day free trial.

  • hextml: an interesting alternative, but with hexes and looks like less feature-rich.


Some cool stuff that came cross along the search:

Пайтон, начало

С абсолютного нуля:

  • : Подробный и последовательный учебник. Самый большой недостаток - цель продать ПДФ-версию и мобильное приложение.

  • : Не пугайтесь оформления сайта. Книга и видео оформлены много лучше. Автор - преподаватель, поэтому весьма последователен. Если нет подготовки, начинать лучше с книги. В видео Дмитрий сразу берет “Анаконду” наперевес и пишет все в “юпитер-блокноте”.

    Отдельно отмечу, что книга хороша скорее для взрослых и старших школьников. Для учеников средней школы начало перегружено косвенными вещами и излишне подробно. Введение в типы данных довольно сумбурное, и с порога - про ссылки в памяти.

  • : Часть курса МФТИ. Также очень краткое введение. По ощущениям хорошо пойдет только старшей школе и выше.

  • : Очень подробный и последовательный учебник, переведенный на русский. Если среднешкольники готовы пропускать непонятное, например, тригонометрию, то все у них получится.

    Как ни грустно, переведен кривовато, написан во времена Python 3.2, местами нарушает PEP8. Т.е. читать стоит только не принимая за конечную истину. Тоже взрослым и старшим школьникам.

  • : Очень плотное, достаточно последовательное и подробное введение. Но очень интенсивное, т.ч. тоже походит на 8+ класс. Еще и код не по PEP8. Плохой первый источник.


Кто знает хотя бы один язык:

Для тех, кто точно собрался в профессию:

  • : Вводная в информатику с финалом для продвинутых. На странице курса 2 очень полезных ссылки на обширные подборки материала для обучения.

  • : Алгоритмы и структуры данных на примере питона. Осторожно, много матчасти.

  • : Для сетевых инженеров. Не слишком плавный ввод и с минимальным учетом пользователей Виндоуз.

  • : Введение в научный пайтон и машинное обучение.

Ху ноуз инглиш:


Nikola Gitlab Pages No-Brainer IndieWeb Guide

1. Pre-requisites and disclaimer

We assume you’ve got basic knowledge of using git and Python infrastructure.

We’ll use git to keep the content of your site. We’ll use Python to run Nikola static site generator.

In order not to write everywhere “for example”, we’ll mark variable strings with double curly quotes: “name it {{some_name}}”. Feel free to variate any step if you’re aware what you’re doing.

Of course, there are plenty of alternatives for every single choice on this guide. I’ll add them later as spoilers, in order not to break the flow.

2. Buy a domain name

  1. Search for a great domain name at namecheap.

  2. Try to choose a TLD with “WhoisGuard”. That’ll close your private data from 3rd parties.

  3. Notice the renewal price. It comes on the second and following years and could be quite high.

  4. In 90% of possible cases you should be in range of 10-20$ per year. If not, check it twice.

  5. During checkout turn on “auto-renew” for “WhoisGuard”, it’s free. Turn on “auto-renew” for domain registration if you’re afraid to forget about it.

Don’t close the browser tab: we’ll return here right after creating and tuning the Pages repository.

3. Create a GitLab account and site repository there

If you’ve got a GitLab account with the SSH keys set up, start from step 8.

  1. Register to GitLab or sign in with a third-party.

  2. Set up your SSH public key.

  3. Create new project “{{username}}” there. Choose private for visibility level. The username part here must be the username of your GitLab account. Yes, it’s the part after at your profile address{{username}}.

  4. Visit the Pages settings of the new project at{{username}}/{{username}} Push the “New domain” button. Enter “https://{{}}” for “Domain” and turn on the “Certificate” checkbox.

  5. After creating the new domain copy the text similar to _gitlab-pages-verification-code.{{}} TXT gitlab-pages-verification-code={{a0bc186be3df54c6e7ad0890cb50a8b0}} to your favourite notepad application.

4. Set the domain up

We have to do this techy stuff first, since it’ll take some time to wait for the effect (up to 24-48 hours).

  1. On namecheap dashboard you should see your single domain in a list. Push the “Manage” button.

  2. On the “Domain” tab scroll down to the “Redirect email” section. With alias “hi” mail sent to “” will be sent to the forward address you choose.

  3. On the tab “Advanced DNS” remove all the records in the “Host records” section, if any.

    Create DNS record that links your domain name to the Pages IP address:

    • Type: A Record

    • Host: @

    • Value:

    Add another DNS record to make GitLab verify your ownership for the domain; use your favourite notepad application with the text copied:

    • Type: TXT Record

    • Host: _gitlab-pages-verification-code.{{}}

    • Value: gitlab-pages-verification-code={{a0bc186be3df54c6e7ad0890cb50a8b0}}

Congratulations! You’re all up with the domain. Let’s move to creating some sample content.

5. Clone the project repository and push the sample Nikola site there

  1. Clone the project repository to any suitable place locally.

    cd {{~/projects_folder}}
    git clone{{username}}/{{username}}
    cd {{username}}
  2. Optionally set python version for the repo: pyenv local 3.8.2

  3. Install Nikola into a separate virtual env and activate it.

  4. Bootstrap its default site: nikola init --demo {{proj_name}}

  5. Change the output folder in the {{proj_name/}}:

    OUTPUT_FOLDER = '../public'

    This is a requirement of GitLab pages: the static site must be in the public directory of the project root.

  6. Build the demo site and run it locally:

    cd {{proj_name}}
    nikola auto

    Check the demo-site is working on localhost:8000.

  7. Add the .gitignore file to the project root containing:

  8. Add the .gitlab-ci.yml file to the project root with this content:

      - nikola build
      - master
      - cd {{proj_name}}
      - nikola build
        - public
      - master
  9. Add all the files in the repo (except ignored) to new commit and push.

  10. After the push pipeline has finished check your site to be deployed to https://{{username}}

6. Final touches

  1. Check that demo-site is available on the https://{{}}. If not, recheck after 24-48 hours. If still not, try to investigate or write me on the IndieWeb slack chat.

  2. Create new post with Nikola and run nikola auto for your comfort.

  3. If stuck with any part of Nikola look through comprehensive Nikola handbook.

  4. And the last thing: enjoy your brand new site!

We Need the No-Brainer IndieWeb

Just sharing some concerns on starting with such a great community as the IndieWeb.

I have some experience with webtech, so assuming gen1. And even for me the getting started guide was kind of mind blowing. The reason is: along the reading I was overwhelmed with alternatives.

It’s easily understandable for marketers and teachers. Every unnecessary element on a page distracts a customer from the target action. Up to leaving the whole process. Every unknown term or sign of complexity confuses a student. Up to total frustration. In both cases we loose all the attention and effort of the participant.

To fix this we need more no-brainer guides for getting started.

They must contain alternatives only under the spoiler blocks or not contain alternatives at all. We have to make no hurt to the reading flow.

To scratch my own itch and for example I’m going to make a post for introductory guide to Python static gen Nikola published to Gitlab pages.