Хомский об этом ничего не писал

В интернете можно встретить текст “10 способов манипулирования с помощью СМИ” за авторством Ноама Хомского. Одна из самых старых версий в рунете датируется 2011 годом. Если смущает, что дата в архиве от 2022 года, перейдите по ссылке на испаноязычный оригинал - он есть от 20.05.2011.

Что нового или особенного в этой статье? Она примечательна тем, что сама есть объект информационной манипуляции с довольно высоким шансом.

Ниже приведены аргументы в пользу этой гипотезы.

Публикация в академической среде

Александр Федоров и Анастасия Левицкая в 2020 году опубликовали статью “Как осуществляются манипуляции в научных медиатекстах“. В ней авторы обращают внимание через множество примеров, что ссылки на фальсифицированные источники появляются даже в научных трудах. У статьи есть версия на английском.

Интервью от 13.10.2012

Ссылка на интервью приводится в вышеупомянутой научной статье за номером [24]. К сожалению интервью доступно только в архиве. Цитата:

M. N.: In the past, you’ve developed a list of media manipulation strategies that the media around the world uses in order to establish control and to manipulate in many ways the audience. Do you believe that the people of Greece are victims of any of these strategies, or do you believe that the global community has fallen victim to these strategies, as a result of the very negative reporting about Greece in the global media?

Chomsky: Well I should add a cautionary note here. You may be referring to something that circulates on the internet called, I think, 10 strategies of manipulation by the media, which is attributed to me, but I didn’t write it. There have been many efforts to correct it, to get it off, but once something’s on the internet, it’s hopeless. So if that’s what you mean, it’s not mine. …

К еще большему сожалению, подтверждения интервью на официальном сайте тоже нет.

Атрибуция Сильвену Тимситу

Кроме “ссылки-оригинала”, атрибуция замечена, например на некоей вики. Что даже более ценно, там есть ссылка на источник (фр.). Сверка с архивом сходится: публикация там как минимум с 2007 года (снимок от 2004 года - с перенаправлением).

Итог

Необходимые допущения:

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

Будьте бдительны при работе с источниками! Если найдете на официальном сайте фактологию, подтверждающую или опровергающую гипотезу, пожалуйста, сообщайте лично или публично.

Isolation word origin

While searching an antonym for the word “isolation” we found the origin of “isolated”:

mid 18th cent.: from French isolé, from Italian isolato, from late Latin insulatus ‘made into an island’, from Latin insula ‘island’.

So if there were a verb “to isle”, “isolated” could be a past participle “isled out”.

Continuous Delivery Git Workflow

Senior disclaimer: the flow below may seem pretty obvious for experienced developers. However, usually it’s hard to explain something without putting it down to any sign form. So, please either skip the following or share the link with your juniors. You’ve been warned.

Couple of general notes:

  • You don’t need the dev branch if you can easily deploy a test instance for any (feature-)branch.

  • You need release branches if you aren’t confident in your monitoring and cannot easily revert a bad prod deploy.

Please, note that the flow of code review (CR) in general is covered elsewhere.

  1. As an author start a feature branch from the current master branch. In our example for a task CV-000 let it be 000-some-feature forked from the master. We can’t start from dev considering it can include some out-of-release scope.

  2. Develop the feature and test it locally.

  3. When creating a merge request (MR) from a feature branch (000-some-feature) to dev:

    1. remove the checkbox “Delete source branch when merge request is accepted.”,

    2. set the milestone.

    3. If you created the MR during development, mark it as draft. Remove the mark at this point of the process.

  4. If there’re any conflicts in the MR to dev:

    1. First, from the feature branch (000-some-feature) create a conflict resolving branch, e.g. 000-dev-conflicts. The name doesn’t really matter, but must contain the task number.

    2. Merge the freshest dev branch (after pull) to the conflict resolving branch (000-dev-conflicts). Resolve conflicts. Push.

    3. Create another MR to dev with the source branch set to the conflict resolving branch (000-dev-conflicts).

    4. Set the checkbox “Delete source branch when merge request is accepted.” for this conflict MR.

  5. After successful CR merge into dev. When pipelines succeeded:

    1. Move the respective task to a QA assignee.

    2. Create another MR from the feature branch (000-some-feature) to the master branch or edit original MR to dev in case of dev conflicts by changing its target branch. In the MR:

      1. set the checkbox “Delete source branch when merge request is accepted.”,

      2. assign to the team lead,

      3. start the name from sprint’s ID and task number, e.g 21.10.a CV-000 …,

      4. set the milestone.

  6. If the task doesn’t pass the QA fix it in the feature branch and create another MR to dev, as usual (see pp.3-4). No action required for the master MR. It’ll be automatically updated since the feature branch is the same.

  7. When the task successfully passes the QA the team lead merges it to the master branch. If the QA process isn’t finished in the current sprint the author changes the milestone and title in the master MR to the next sprint.

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 draw.io 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:

defaults,utf8,uid=1000,gid=plugdev,umask=0002,windows_names,nocompression

Doubtful options we’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.

Addendum

Some cool stuff that came cross along the search:

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

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

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

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

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

  • http://judge.mipt.ru/mipt_cs_on_python3/labs/lab1.html#python-3 : Часть курса МФТИ. Также очень краткое введение. По ощущениям хорошо пойдет только старшей школе и выше.

  • http://programarcadegames.com/index.php?lang=ru : Очень подробный и последовательный учебник, переведенный на русский. Если среднешкольники готовы пропускать непонятное, например, тригонометрию, то все у них получится.

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

  • http://ai.lector.ru/?go=python : Очень плотное, достаточно последовательное и подробное введение. Но очень интенсивное, т.ч. тоже походит на 8+ класс. Еще и код не по PEP8. Плохой первый источник.

Курсы:

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

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

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

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

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

  • https://github.com/Yorko/python_intro : Введение в научный пайтон и машинное обучение.

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

Источники:

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. We’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}}.gitlab.io” there. Choose private for visibility level. The username part here must be the username of your GitLab account. Yes, it’s the part after gitlab.com/ at your profile address https://gitlab.com/{{username}}.

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

  5. After creating the new domain copy the text similar to _gitlab-pages-verification-code.{{your-domain.com}} 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 “hi@your-domain.com” 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: 35.185.44.232

    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.{{your-domain.com}}

    • 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 git@gitlab.com:{{username}}/{{username}}.gitlab.io.git
    cd {{username}}.gitlab.io
    
  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/conf.py}}:

    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:

    cache
    /public
    .doit.db
    
  8. Add the .gitlab-ci.yml file to the project root with this content:

    image: registry.gitlab.com/paddy-hack/nikola
    
    test:
      script:
      - nikola build
      except:
      - master
    
    pages:
      script:
      - cd {{proj_name}}
      - nikola build
      artifacts:
        paths:
        - public
      only:
      - 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}}.gitlab.io.

6. Final touches

  1. Check that demo-site is available on the https://{{your-domain.com}}. If not, recheck after 24-48 hours. If still not, try to investigate or write us 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.

We have some experience with webtech, so assuming gen1. And even for us the getting started guide was kind of mind blowing. The reason is: along the reading we were 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 we’re going to make a post for introductory guide to Python static gen Nikola published to Gitlab pages.