Продолжая тему прошлого поста. Тут друзья подсказывают про закон Дырявых абстракций Джоэла Спольски. Речь в нем о том, что любая абстракция имеет свои «дырки», т.е места, где она протекает на более низкий уровень в силу своей несовершенности. Абстракции призваны упростить нашу жизнь, перенести мышление на более высокий уровень, освободив его от несущественных на данном этапе деталей. Это позволяет решать все более и более высокоуровневые проблемы, решение которых было бы невозможным, если бы мы, скажем, все ещё продолжали писать на ассемблере, вместо языков следующего поколения или каждый раз писали свою сортировку, вместо использования библиотек и модулей. И в то же время, абстракции понижают естественный порог входа в профессию программиста. А вместе с ним и средний IQ сообщества. И вот тут нас атакуют дырявости в наших абстракциях. Прежде чем использовать абстракцию, правильно было бы научиться разбираться на один-два уровня ниже в вещах, на которых эта абстракция основана. Потому что в ситуациях, когда она протечет «в бою», уже поздно будет читать про TCP или ревьювить код импортированных пакетов. Добавим тягу к фундаментальному пониманию происходящих процессов и их анализ в копилку навыков настоящего программиста.

Итак, после десяти лет в консоли… десяти лет боли и страдания от emacs-стиля: set -o vi

Компетенции программиста:
- алгоритмы и структуры данных (основа основ, необходимый, но не достаточный элемент для решения более высокоуровневых задач);
- архитектура [программ] (декомпозиция, знание парадигм, подходов и шаблонов. В комбинации со знанием алгоритмов и структур данных даёт возможность реализовывать широкий спектр прикладных программ);
- операционные системы/платформы (знание среды, в которой выполняется код, её примитивов и API. В совокупности с первыми двумя пунктами расширяет круг возможностей программиста);
- архитектура распределённых систем (CAP теорема, осознание невозможности двухфазного коммита, распределённый консенсус плюс набор шаблонов для построения распределённых систем) - вжух, и ты - инженер.

nil leads to panic
panic leads to fear
fear leads to…
functional programming!

https://speakerdeck.com/campoy/understanding-nil

Интересная мысль у товарища. Он утверджает, что запоминание - это ненужная вещь. Речь идет про математику, формулы и определения, но, похоже, можно обобщить до любой области. Товарищ говорит, что нужно банально кучу раз решить на практике одни и те же задачи, тогда они станут как бы частью твоего мыслительного процесса. Как разговор на естесственном языке. Мы же не пытаемся вспоминать слова, а просто автоматически говорим. И так же нужно поступать с математикой - механически вдалбливать себе знания путем повторения пока не начнешь думать на этом языке.

https://math.stackexchange.com/a/33987/417969

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

У линуксовых сокетов нет никаких таймаутов, которые можно было бы настраивать из приложения. Только всякие обще-системные TCP счетчики. Типа максиальное кол-во передачи SYN, задержка между передачами и т.п.

И когда программист создает сокет в синхронном моде и делает на нем коннект, результата такого вызова можно прождать пару минут, все зависит от TCP настроек оси...

И поэтому всегда с сокетами работают в асинхронном виде (не тюнить же ось ради каждой проги). Создают асихронный сокет, вызывают коннект, который тут же заврешается с ошибкой. А дальше poll-ят на дескрипторе этого сокета, не произошло ли там коннетка. И если с точки зрения приложения коннекта нет слишком долго, то poll-инг прекращается с ошибкой уровня приложения, типа connection timed out.

Аналогичная история с операциями чтения и записи.

А всякие выскороуровневые языки, типа python, берут и делают всю эту магию под капотом, возвращая на уровень публичного API сокетов “блокирующие” операции коннекта, чтения и записи, которые доп параметром принимают timeout. Или еще круче - такой таймаут можно выставить глобально (все будущим сокетам) или для каждого сокета отдельно в момент создания. А JS пошел еще дальше - он впилил idle timeout. То есть если на сокет не приходит ничего (или с сокета не уходит ничего) дольше idle timeout milliseconds, вызывается socket.onTimeout коллбек.

Пруфы:
https://stackoverflow.com/a/2597774/1201488
https://docs.python.org/3/library/socket.html#notes-on-socket-timeouts
https://nodejs.org/api/net.html#net_socket_settimeout_timeout_callback
https://github.com/nodejs/node/blob/master/lib/net.js#L424
https://golang.org/pkg/net/#TCPConn.SetDeadline

Окей, ещё одна житейская мудрость... Если у тебя есть пул коннектов к какому угодно серверу (БД, HTTP, etc), проверь дважды, что keep-alive таймаут на твоей стороне хотя бы на несколько секунд меньше keep-alive таймаута этих соединений на стороне сервера. Иначе ошибок записи в сокет по причине race conditions в закрывающихся TCP соединениях не избежать.

Когда накрыла ностальгия - старый добрый C, но на этот раз в браузере, спасибо WebAssembly! Играть тут http://micromind.me/golife/?preset=spaceship, код смотреть тут https://github.com/iximiuz/golife.c.

О вычислительной сложности... Все конечно слышали про класс задач NP (задача коммивояжёра, укладка рюкзака, и пр.). Задачи, которые *похоже* (если P != NP) не возможно решить за полиномиальное время на обычном компе. Но очень много людей ошибочно считают, что NP расшифровывается как Non-Polynomial, ожидаемо противопоставляя этот класс классу задач P, aka Polynomial. Так вот, оказывается, был вариант назвать NP класс вовсе не NP, а PET (i.e. Probably Exponential Time). И в случае доказательства P != NP переименовать PET в Provably Exponentioal Time. Или в Previously Exponential Time, если вдруг P == NP. Но нет, назвали-таки Non-deterministic Polynomial...

После долгих лет в разработке, начавшихся с абсолютно бездарного теоретического старта основ ООП в универе, картинка сложилась!

Чему учили в универе: ООП - это абстракция, инкапсуляция, полиморфизм и наследование.

Что говорит Alan Kay (https://en.wikipedia.org/wiki/Alan_Kay): ООП - это общение посредством передачи сообщений, состояние [объектов в широком понимании этого слова], его (состояния) сокрытие и защита [aka инкапсуляция], и [максимально] позднее связывание.

И вот со вторым определением никаких проблем. Все, что обладает состоянием - объект. Как такие объекты создаются (с помощью классов, модулей, копирования и цепочек прототипов, etc) - абсолютно не важно. Как объекты общаются между собой? Передачей сообщений. По сути, даже простой myUser.setAge(42) - это передача сообщения setAge объекту myUser. В некоторых языках это прослеживается лучше, в некоторых хуже. Объекты должны иметь возможность прятать и защищать (от модификации) свое внутреннее состояние (C++/Java private, protected атрибуты классов такой же способ сокрытия и защиты, как JavaScript замыкания в module pattern или заглавные/строчные буквы в Go). Сообщения, передаваемые между объектами должны быть диспетчеризуемыми. На основе имени сообщения (связывание на этапе компиляции), типа получателя (single dispatching, т.е. связывание происходит уже в runtime), типа получателя и аргументов (double dispatching, опять же runtime). И из общения посредством передачи сообщений и позднего связывания возникает полиморфизм и дополнительный уровень абстракции.

Что мне не нравится в первом (и общеизвестном) определении ООП: полиморфизм и наследование представлены как объекты одного уровня. По факту же, наследование - это лишь один из вариантов реализации полиморфизма (https://en.wikipedia.org/wiki/Subtyping_polymorphism). Существуют и другие - ad hoc polymorphism (https://en.wikipedia.org/wiki/Ad_hoc_polymorphism), parametric polymorphism (https://en.wikipedia.org/wiki/Parametric_polymorphism). При этом полиморфизм сам по себе является одним из вариантов создания абстракций, делая вышеупомянутое определение еще более наивным.

Немного мыслей про readable streams в современном Node.js. В этот раз в форме статьи http://micromind.me/posts/nodejs-readable-streams-distilled

Продолжаем про Node.js стримы - коротко про writable streams https://micromind.me/posts/nodejs-writable-streams-distilled?msrc=tc

Неделя постов объявляется открытой. Конвертнул немного своей боли и недопонимания про protobuf3 и Go в статью про славный их союз https://micromind.me/posts/truly-optional-scalar-types-in-protobuf3?msrc=tc

И в завершение недели постов разродился статьей о всевозможных способах обработки запросов на сервере с примерами на python https://micromind.me/posts/writing-python-web-server-part-2?utm_medium=social&utm_source=tchannel

Веселые истории услышать не хотите ли? #python #gevent #asyncio вот это все https://micromind.me/posts/save-the-day-with-gevent?utm_medium=social&utm_source=tchannel

Идея even loop проста, но программные платформы на основе циклов событий получаются очень мощными. Про внутреннее устройство циклов событий и то, как можно написать свой всего в 100 строках https://micromind.me/en/posts/explain-event-loop-in-100-lines-of-code/?utm_medium=social&utm_source=tchannel

Продолжение предыдущей статьи - добавляем поддержку async/await в наш самописный event loop https://micromind.me/en/posts/from-callback-hell-to-async-await-heaven/?utm_medium=social&utm_source=tchannel

У Python очень богатая стандартная библиотека. Собрал в одном месте десяток способов запустить TCP и/или HTTP сервер с использованием только стандартных средств.

https://micromind.me/ru/posts/over-9000-ways-to-make-web-server-in-python/?utm_medium=social&utm_source=tchannel

Хоть практической пользы в этом видео наверное и нет, это интервью просто обязаны посмотреть все, кто имеет хоть какое-то отношение к программированию. Кен Томпсон: "К счастью, моя жена в тот момент уехала в трехнедельный отпуск с нашим годовалым ребенком, и - неделя, неделя, еще неделя - и получился Unix" https://youtu.be/EY6q5dv_B-o?t=1357

Как написать свой HTTP-сервер с нуля https://micromind.me/ru/posts/writing-python-web-server-part-3/?utm_medium=social&utm_source=tchannel. Продолжение серии статей про разработку веб-сервера на Python.