Заметки правило


Как отличить хорошего учителя от плохого

Отличить хорошего учителя по химии или физике от плохого очень просто:

Хороший учитель химии или физики на первом же занятии показывает опыт.

Если ваш учитель химии на первый же урок не принёс вам две колбы с прозрачными жидкостями, не смешал их, не показал, как смесь стала красной, этот учитель плохой.

Я пишу это, и у меня кожа покрывается мурашками, потому что у меня были очень хорошие учителя химии и физики.

Правило легко расширяется на большинство других дисциплин.

Законы коммуникации Вийо

Законы Вийо — юмористически изложенные серьёзные замечания о том, что человеческая коммуникация, как правило, проваливается, за исключением редких случайностей. Можно сказать, что законы Вийо — это законы Мерфи для коммуникации.

Основные законы

Законы достаточно понятны даже без дополнительных пояснений.

1. Коммуникация, как правило, терпит неудачу, кроме случайностей.

1.1. Если коммуникация может потерпеть неудачу, она потерпит неудачу.

1.2. Если коммуникация не может потерпеть неудачу, она, как правило, терпит неудачу.

1.3. Если коммуникация кажется успешной, между сторонами есть непонимание.

1.4. Если вы довольны своим сообщением, коммуникация, конечно, терпит неудачу.

2. Если сообщение может быть истолковано по-разному, оно будет истолковано таким образом, который максимизирует ущерб.

3. Всегда есть кто-то, кто лучше вас знает, что вы имели в виду своим сообщением.

4. Чем больше мы коммуницируем, тем меньше успешность коммуникации.

4.1. Чем больше мы коммуницируем, тем быстрее распространяется непонимание.

5. В массовой коммуникации важно не то, что вещи собой представляют, а то, какими они кажутся.

6. Важность новости обратно пропорциональна квадрату расстояния.

7. Чем важнее ситуация, тем более вероятно, что вы забудете важную вещь, которую помнили мгновение назад.


Следствия

Первое следствие Корпела

Если никто не лает на вас, ваше сообщение не прошло.
Отсутствие отрицательной обратной связи часто преподносится как успешность коммуникации. Напротив, это означает, что вы потерпели неудачу.

Второе следствие Корпела

Поиск информации терпит неудачу, кроме случайностей.
Интернет используется для хранения большого количества неорганизованных и несекретных данных. На сегодняшний день он содержит огромное количество неорганизованных и несекретных данных, а также джунгли «поисковых систем», «каталогов», «виртуальных библиотек» и «порталов».

Педагогическое следствие

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


Мораль

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

 


Мои любимые, это, конечно, №2 и Первое следствие Корпела. (Ну а педагогическим следствием я ежедневно пользуюсь на работе.)

Я полагаю, если бы эти законы рассказывали на первом же уроке всем студентам-журналистам (да и не только журналистам), мы бы жили в другой стране.

Метаправило предбанника в ПДД: почему на трамваи не действует помеха справа

Правила дорожного движения следуют метаправилу предбанника достаточно последовательно. Находящийся в более ограниченном пространстве имеет приоритет в движении при отсутствии более важных факторов, влияющих на порядок движения.

Трамваи ограничены в манёврах из-за наличия присутствия рельс, поэтому при прочих равных условиях — в которых как раз и включается «помеха справа» — должны иметь приоритет. По этой причине «помеха справа» для трамваев отключается: от неё нет никакого толка, трамвай должен проехать первым, ему нужен приоритет.

Правило ограниченного пространства, или Метаправило предбанника

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

Два ряда дверей не то же самое, что один

Правило этикета для двойных дверей (предбанников) в помещениях и холлах:

Тот, кто выходит из предбанника, имеет приоритет (независимо от того, входит он в помещение или выходит из него).

В более общем виде получаем метаправило предбанника:

Находящийся в более ограниченном пространстве имеет приоритет в движении.

При двойных дверях и достаточно плотном движении следование классическому правилу этикета «выходящий из помещения имеет приоритет» автоматически означает пробку в предбаннике из тех, кто стоит в нём, чтобы войти в помещение. Классическое правило при таком подходе является просто частным случаем метаправила: помещение, очевидно, является более ограниченным пространством нежели улица. (Более ограниченный ресурс всегда более ценен.)

Кстати, правила дорожного движения следуют правилу ограниченного пространства: находящиеся на небольших пространствах (перекрёстки, кольца и т. п.) при прочих равных условиях обычно имеют приоритет.


В процессе обсуждения этой заметки с товарищами оказалось, что многие (даже заядлые автолюбители с большим стажем вождения) не совсем понимают, что ПДД не взяты с потолка, а имеют свой внутренний смысл. Например, почему «помеха» именно «справа», ведь можно было изначально договориться о «помехе слева», и результат был бы тем же. Почему результат был бы не тем же — в следующий раз.

Правила программирования. Стиль кодирования

Правило очень простое:

Если ты не следуешь одному стилю кодирования в проекте, ты мудак.

Это правило не обсуждается, и никаких других интерпретаций быть не может.

Правило относится к числу так называемых командных правил. Оно расширяется до следующей формулировки:

Если команда не следует единому стилю кодирования в проекте, каждый член команды — мудак.

Код независимо от того, сколько человек над ним работает, должен выглядеть так, как будто он написан одним человеком.

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

Почти для каждого языка программирования существуют автоматические средства проверки стиля кодирования. Необходимо в своей команде настроить их таким образом, чтобы без проверки формальных требований ко внешнему виду код даже не доходил до просмотра людьми (код-ревью). C помощью дешёвого машинного труда освобождается часть дорогого человеческого времени (см. правило про автоматизацию).

(В команде Сиджеко код даже не попадёт в основной репозиторий, пока не будет выглядеть красиво.)

Идентификация, аутентификация и авторизация

В работе инженера-программиста и системного архитектора важно не путать понятия идентификации, аутентификации и авторизации. (Наибольшая путаница, как правило, возникает с последними двумя.)

Легко их отличать помогут вспомогательные вопросы:

  1. Ты кто такой? — идентификация (выделение или распознавание конкретной сущности, лиц или группы лиц из некоего множества);
  2. Чем докажешь? — аутентификация (процедура проверки подлинности с помощью предъявление паспорта, пароля и т. п.);
  3. Что можешь делать? — авторизация (проверка или предоставление определённых прав на выполнение конкретных действий).

(Контроль в аэропорту: «Ваша фамилия? Ваш паспорт? Ваш билет?»)

Теперь не спутать.


Статьи в Википедии:

  1. https://ru.wikipedia.org/wiki/Идентификация_(информационные_системы)
  2. https://ru.wikipedia.org/wiki/Аутентификация
  3. https://ru.wikipedia.org/wiki/Авторизация

Правила программирования. Автоматизация

Правило очень простое:

Если ты заставляешь человека делать работу, с которой прекрасно справляется машина, ты мудак.

За контрпримерами далеко ходить не надо. Вот цитата со страницы отслеживания почтовых отправлений Почты России:

Почтовый идентификатор находится в чеке, выдаваемом при приеме почтового отправления.
Вид номера: 115127(80)15138 4. Следует вводить:
Почтовый идентификатор: 11512780151384 (весь номер без скобок и пробелов).

В случае отслеживания международного почтового отправления и EMS-отправления необходимо вводить 4 буквы и 9 цифр. Буквы вводятся обязательно ЗАГЛАВНЫЕ и в латинском алфавите.
Пример: YF123456789RU (весь номер без пробелов).

Почему, о, тупейший из тупейших, я должен это всё делать? С какой целью? Чтобы тебе было удобнее искать значение в базе данных? Пусть программа сама уберёт пробелы и скобки, приведёт символы к нужному регистру, заменит кириллические буквы на похожие латинские (раз только такие и могут быть). Почему я должен тратить несколько секунд или минут на работу, с которой компьютер справляется за несколько микросекунд.

Это настолько просто, что займёт не больше 15-20 минут на написание кода.


См. также: Правило про Юникод.

Правила программирования. Юникод

Правило очень простое:

Если твоя программа не использует Юникод, ты мудак.

Это правило не обсуждается, и никаких других интерпретаций быть не может.

Юникод-кодировок несколько, но лучше всего использовать UTF-8 по причине его обратной совместимости с базовой 7-битной таблицей ASCII, а также общей гениальности архитектуры (круче никто не сделал).

В идеале, конечно, Юникод должен использоваться и в базе данных, и в файлах, и в исходном коде программы, но здесь, само собой, всё зависит от выбранных языков и технологий. С другой стороны, почему в 21 веке всё ещё существуют языки программирования, которые не переваривают исходные тексты программ в многобайтовой кодировке, технологии, поддерживающие только однобайтовые кодировки, и использующие их люди, для нормального инженера должно быть загадкой.

Историю вопроса можно описать одним абзацем. Поскольку основные компьютерные технологии придуманы западным миром, они изначально были рассчитаны только на английский язык и латинский алфавит. Но потом внезапно оказалось, что компьютеры нужны всем, а программисты — люди ленивые, поэтому переучиваются неохотно и медленно. Посему мы до сих пор встречаем эти осколки прошлого, однако брать с них пример — нездоровая идея.


См. также: Правило про автоматизацию.