Дело в том, что index-only scan возможен только, если в Visibility Map установлен <code class="inline-code">visibility</code> флаг для искомых страниц.&nbsp;

Флаг <code class="inline-code">visibility</code> устанавливается вакумом и означает, что в странице нет старых версий строк и нет никаких незакоммиченных новых. – т. е. страница целиком и полностью состоит из видимых версий строк.&nbsp;

Соответственно <code class="inline-code">visibility</code> флаг снимается как только какая-либо транзакция начинает добавлять новые версии строк в страницу.

Поэтому для index-only scan недостаточно наличия одних только данных в индексе. Важно, чтобы страницы с данными были почищены от старых версий строк и никакие новые транзакции не работали с новыми версиями строк.

Выключенный VACUUM и постоянные обновления мешают index-only scan в PostgreSQL

While reuse is beneficial, remember the First Law of Software Architecture regarding trade-offs. The negative trade-off of reuse is coupling. When an architect designs a system that favors reuse, they also favor coupling to achieve that reuse, either by inheritance or composition.

About reuse

Озеро Лиси

Для тех, кто не в курсе, <a href="https://containers.dev/">devcontainer</a> - это спецификация от майкрософт, с помощью которой можно универсально описывать параметры окружения для разработки и поднимать все в один клик на любом устройстве, включая клауды.

Этот подход похож на стандартный запуск окружения с помощью docker compose, но намного удобнее за счет стандартизации.&nbsp;

Пока что в полной мере спека поддерживается только в VS Code. Jetbrains <a href="https://youtrack.jetbrains.com/issue/IDEA-292050">обещают</a> добавить поддержку уже скоро. Так же можно использовать <a href="https://www.npmjs.com/package/@devcontainers/cli">CLI</a> для запуска и управления контейнером.

В этой статье мы настроим Node.js + PostgreSQL + PGAdmin4 стэк для разработки.

Для начала нужно создать папку <code class="inline-code">.devcontainer</code>. В ней будет находиться <code class="inline-code">docker-compose.yml</code>, различные <code class="inline-code">Dockerfile</code> и <code class="inline-code">devcontainer.json</code>.

Основным контейнером будет тот, внутри которого мы хотим находиться во время разработки. В нашем случае это будет контейнер с Node.js приложением. Cоздадим файл <code class="inline-code">.devcontainer/app/Dockerfile</code> со следующим содержимым:

Помимо образа ноды, мы дополнительно устанавливаем socat и sudo. Чуть позже станет понятнее зачем это надо.

Так же создадим <code class="inline-code">.devcontainer/docker-compose.yml</code>,

Если вы работаете на Windows или MacOS, обязательно нужно сделать отдельный volume для папки node_modules (строка #7) – это поможет ускорить работу вашего приложения внутри контейнера.&nbsp;

Cтроки #21, #33 и куча переменных окружения заставят pgadmin4 не требовать ввода логина и пароля при входе и непосредственно при подключении к бд. Так же надо создать <code class="inline-code">.devcontainer/pgadmin4/servers.json</code>:

Теперь самое сладенькое. Нужно создать <code class="inline-code">.devcontainer/devcontainer.json</code>:

В&nbsp;<code class="inline-code">service</code>&nbsp;указываем, который из контейнеров считать основным. Внутри основного контейнера будет вестись вся разработка. В нашем случаем это app, куда установлена нода.

В&nbsp;<code class="inline-code">postCreateCommand</code> меняем владельца <code class="inline-code">node_modules</code> на <code class="inline-code">node</code>, так как эта папка у нас отдельный volume, устанавливаем зависимости и настраиваем переменные окружения. Эти команды буду выполняться после создания контейнера.

В&nbsp;<code class="inline-code">postStartCommand</code> с помощью <code class="inline-code">socat</code> и <code class="inline-code">nohup</code> пробрасываем порт <code class="inline-code">pgadmin4</code>, в основной контейнер, а из основного контейнера, с помощью <code class="inline-code">"forwardPorts": [8080]</code>, форвардим этот порт вовне. На самом деле это можно сделать попроще через&nbsp;<code class="inline-code">forwardPorts</code>, указав <code class="inline-code">["pgadmin4:8080"]</code>, но этот способ не будет работать в Codespaces (почему-то они это пока не поддерживают).

Ну и в&nbsp;<code class="inline-code">postAttachCommand</code> прописываем код, чтобы git не ругался на разных владельцев.

Итого у нас получился devcontainer, который можно запускать из <a href="https://code.visualstudio.com/docs/devcontainers/containers">VS Code</a>, <a href="https://docs.github.com/en/codespaces/overview">Codespaces</a>,&nbsp;с помощью <a href="https://www.npmjs.com/package/@devcontainers/cli">CLI</a>, или даже в EC2 при помощи <a href="https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh">Remote – SSH расширения</a> для VS Code.

Настраиваем devcontainer, который будет работать локально, в EC2 и Codespaces

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

И это объясняется тем, что имеющиеся объяснения в интернете довольно противоречивые. Взять, к примеру, определение из&nbsp;<a href="https://ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B0">Википедии</a>:

Бизнес-логика – совокупность правил, принципов, зависимостей поведения объектов предметной области.&nbsp;Является синонимом термина «логика предметной области».

Так как понятие раскрывается через предметную область, то надо взглянуть и на&nbsp;<a href="https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D0%B4%D0%BC%D0%B5%D1%82%D0%BD%D0%B0%D1%8F_%D0%BE%D0%B1%D0%BB%D0%B0%D1%81%D1%82%D1%8C">этот термин</a>:

Предметная область — часть реального мира, рассматриваемая в пределах данного контекста. Под контекстом здесь может пониматься, например, область исследования или область, которая является объектом некоторой деятельности.

Из вышеизложенного следует, что бизнес-логика это только код связанный с процессами реального мира и ни что другое. Т. е. условные <code class="inline-code">ProductRepository</code> или <code class="inline-code">RedisCache</code>, или даже их интерфейсы не должны фигурировать в бизнес логике, потому что никакого отношения к моделируем процессам они не имеют.

Теперь давайте натянем это понятие на стандартную трёхслойную архитектуру:

Уже видите противоречие?

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

Тут сразу стоит сказать, что определение из википедии неправильное и путающее, хотя распространенное.

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

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

В примере с трехслойной архитектурой, конечно, сложно понять что относится к предметной логике, а что к логике приложения. Обычно такой код смешан в процедуры, которые еще называются <a href="https://martinfowler.com/eaaCatalog/transactionScript.html">транзакционным скриптами</a>. При реализации&nbsp;<a href="https://martinfowler.com/eaaCatalog/domainModel.html">богатой доменной модели</a>&nbsp;слой бизнес логики делится на два других слоя, и тут уже грань между логикой приложения и предметной логикой становится более явной.

Итого, все описанное можно упаковать в следующее определение:

Бизнес-логика – это правила, описывающие поведение части реального мира (предметная логика) и правила, отвечающие за варианты использования предметной модели и её связь с инфраструктурой (логика приложения).

При этом логика приложения не обязательно должна быть явно отделена от предметной.&nbsp;О патернах организации бизнес-логики можно почитать в книге&nbsp;<a href="https://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420">Patterns of Enterprise Application Architecture</a>.

Про бизнес-логику

Это вольный перевод <a href="https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html">статьи OWASP</a>.

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

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

В этой статье подробно рассказано как безопасно хранить пароли. Если лень читать, то вот основные выводы:

Определяемся с терминами

Разница между хеширование и шифрованием

Что хеширование, что шифрование являются инструментами для защиты данных. Но, практически во всех случаях пароли нужно только хешировать, а не шифровать.

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

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

Пароли шифруют только в редких случаях. Например, если пароль нужно будет использовать для аутентификация в друг сервисах, которые не поддерживают более безопасные методы вроде OpenID Connect (OIDC).&nbsp;

Подробнее про шифрование можно почитаться <a href="https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html">здесь</a>.

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

Это выглядит примерно так:

Все эти шаги обычно использую, но в больших масштабах:

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

Способы хранения пароля

Соль это уникальная, случайно сгенерированная строка, которая добавляется к паролю в процессе хеширования. Так как соль уникальная для каждого пользователя, злоумышленнику придется генерировать хеш заново при каждой сверке пароля. Это достаточно сильно усложняет процесс, потому что количество затраченного времени растет прямо пропорционально количеству паролей.&nbsp;

Соль также защищает от использования предварительного сгенерированных хешей – так называемых радужных таблиц. Так же при использовании соли становится невозможным узнать используют ли пользователи одинаковые пароли.

Некоторые современные алгоритмы хеширование (Argon2id, bcrypt, and PBKDF2) автоматически добавляют соль к паролю, поэтому зачастую никаких дополнительных действий не требуется.

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

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

Фактор работы это сколько итераций хеширования выполняется для пароля (обычно 2^фактор работы). Нужен, чтобы сделать вычисление хеша более ресурсно-затратным для злоумышленника. Фактор обычно хранится вместе с хешем.

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

Увеличение фактора работы

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

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

Алгоритмы хеширования паролей

В настоящее время существует несколько алгоритмов хеширования, которые были разработаны специально для безопасного хранения паролей. То есть они работают достаточно медленно (а не так как MD5 или SHA-1, которые создавались быстрыми), и то насколько они медленные можно изменить через фактор работы.&nbsp;

Если вы используете современный алгоритм хеширования с правильной конфигурацией, то не обязательно скрывать название алгоритма от всех – злоумышленнику это не поможет.

На сегодняшний день существует три основных алгоритма:

Argon2&nbsp;является победителем 2015 года в конкурсе <a href="https://password-hashing.net/">«Password Hashing Competition»</a>. Существуют три версии алгоритма: Argon2i, который защищает от атак по сторонним каналам, Argon2d, устойчивый к GPU атакам и Argon2id объединяющий все вместе.

Взамен указания простого значения фактора работы, Argon2id кофигурируется тремя параметрами: минимальный размер памяти (m), минимальное количество итераций (t) и степень параллелизма (p).

Обе приведенные кофигурации дают хорошую защиту от аттак. Выбор только в том, какие ресурсы вы готовы зайдействовать больше – CPU или RAM.

scrypt&nbsp;– алгоритм хеширования паролей, разработанный&nbsp;<a href="https://twitter.com/cperciva">Колином Персиваль</a>. Хоть&nbsp;Argon2id и является более предпочтительным алгоритмом,&nbsp;scrypt также может быть использован при правильной конфигурации. Например, в Node.js scrypt является частью ситемной библиотеки и может быть использован в сочетании с randomBytes для соли.

Так же как Argon2id, scrypt конфигурируется тремя параметрами: минимальной CPU/memory, стоимостью (N), размером блока (r) и степенью параллелизма (p)

Все описанные конфигурации дают максимальную степень защиты – разница только в использовании CPU и RAM.

bcrypt&nbsp;следует использовать если ни один из предыдущих вариантов недоступен.&nbsp;При этом подбирайте настолько большой фактор работы, насколько позволяют ресурсы сервера, но не меньше 10.

Ограничение на длину пароля

bcrypt принимает на вход максимум 72 байта <a href="https://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length">в большинстве случаев</a>. Это нужно учитывать при выборе длины пароля (72 байте это не длинна строки, некоторые символы, такие как emoji, могут занимать больше 1 байта)

Предварительное хеширование&nbsp;

Описанное выше ограничение можно обойти, если перед передачей пароля в bcrypt, предварительно хешировать его другим быстрым алгоритмом вроде&nbsp;SHA-256 (например,&nbsp;bcrypt(base64(hmac-sha256(data:$password, key:$pepper)), $salt, $cost)). Это популярная, но опасная практика из-за возможного&nbsp;<a href="https://www.youtube.com/watch?v=OQD3qDYMyYQ">«шакинга» пароля</a>&nbsp;и других проблем связанных <a href="https://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html">с комбинированием bcrypt с другими алгоритмами хеширования</a>.

PBKDF2&nbsp;алгоритм рекомендован&nbsp;NIST&nbsp;и соответствует FIPS-140. Поэтому его следует использовать в случаях, когда это обязанность по закону. Возможно в других юрисдикциях существует похожие требования относительно других алгоритмов и их тоже придется соблюдать.

PBKDF2 предоставляет выбор внутреннего алгоритма хеширования. HMAC-SHA-256 имеет хорошую поддержку и рекомендован NIST

Фактор работы PBKDF2 определяется количеством итераций.

Приведенные параметры гарантируют одинаковую степень защиты.

Если PBKDF2 используется одним из HMAC алгоритмов, и длина пароля больше размера блока (64 байта для SHA-256), пароль будет автоматически дополнительно предхеширован. Например, пароль "This is a password longer than 512 bits which is the block size of SHA-256" будет конвертирован в такой хеш fa91498c139805af73f7ba275cca071e78d78675027000c99a9925e2ec92eedd. В хороших реализациях&nbsp;PBKDF2, этап предхеширования будет исполнен до начала исполнения основного алгоритма. Но в некоторых реализациях, такое предхеширование происходит на каждой итерации, что приводит к значительному увеличению времени хеширования при использовании длинных паролей, например, как было в <a href="https://www.djangoproject.com/weblog/2013/sep/15/security/">Django</a>&nbsp;в 2013. В таком случает лучше делать ручное предварительное хеширование с солью.

Обновление легаси хешей

В старых приложениях могут использоваться менее защищенные алгоритмы хеширования вроде MD5 или SHA-1, поэтому их важно заменить на более современные и защищенные способы хеширования. 

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

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

Альтернативным подходом может быть перехеширование всех хешей с новым алгоритмом. Например было&nbsp;md5($password), а стало bcrypt(md5($password)). Недостатки такого подхода уже описывались выше. 

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

Но даже обновив алгоритм хеширования сейчас, будьте готовы перейти на новый алгоритм снова через какое-то время, потому что технологии не стоят на месте.&nbsp;

Международные символы

Также советуем убедиться в том, что выбранный алгоритм хорошо работает с большим количеством символов и совместим с Unicode. Пользователи не должны быть ограничены в выборе символов, которые они могут использовать для своих паролей. Также учитывайте, то что в пароле может содержаться NULL байт.

Гайд по хешированию паролей

Мы выбрали этот штат, потому что он не такой мейнстримный как Гоа, и самый чистый в Индии. Расположен на юге страны, вдоль&nbsp;Малабарского побережья.

Это также самый образованный штат Индии. Как объяснили местные, образованность тут заключается не в высоком уровне интеллекта, а в том, что родители следят, чтобы дети не пропускали школу, а после продолжили учиться в университете. Это может показаться необычным, но многие действительно не доучиваются и идут заниматься простым ручным трудом, особенно в деревнях.&nbsp;

В Керале туристический сезон начинается с ноября, а мы приехали в середине октября, когда еще не закончился сезон дождей. Сезон дождей звучит страшно, но на деле это 15 минут теплых осадков в сутки (в основном ночью). Единственный минус этого периода это закрытые пляжи, из-за бушующих волн.&nbsp;

На поездку ушло около 4000$ на двоих. Из них 2000$ это авиабилеты. Чтобы потратить вторую половину, пришлось сильно постараться, потому что Индия очень дешевая страна. Основная статья расходов это аренда жилья от 30$ до 50$ в сутки. Говорят, что на месте можно находить жилье еще дешевле, но мы не заморачивались и все бронировали через Airbnb и Booking.

Кстати, название штата правильно произносить с ударением на первую гласную – Кéрала.

Путешествие началось и закончилось в портовом городе Кочин. Это не столица Кералы, столица находится на самом юге штата и называется&nbsp;<del class="cdx-strikethrough">Твлва84ш8овол</del> Тируванантапурам

Дорога от аэропорта на убере стоила 10$. Интересно, чтобы заработала туристическая симка надо было ждать до 8 утра, потому что все симки активируются вручную сотовым оператором только в рабочее время.

Первые два дня путешествия мы провели в центре города. Мне всегда казалось, что в любой стране центр города это самое ухоженное место. В Кочине оказалось наоборот. Неприятный запах, свалки мусора под ногами, большое количество людей, шум и канализация под тротуарами. А нет, про тротуары соврал – их нет. При всем этом температура держалась на уровне 30°C-40°C.

Тут случился первый дзынь с индийцами. Пока я сидел в кафе и пытался понять как можно наесться индийским завтраком из тонкого блина и острого кари, ко мне начали подходить местные, чтобы сфотографироваться. Оказалось, что быть белым в Индии это быть звездой: с тобой постоянно делают фотографии, снимают из-за угла, разговаривают и пытаются услужить. Единственное спасение это не встречаться ни с кем взглядом.&nbsp;

Кстати, не знаю связано ли это с цветом кожи, но индийцы вели себя доброжелательно и всегда готовы были помочь. Никто не пытался обмануть (за исключение Варкалы, но там понятно почему) – возможно это связано с тем, что в Керале коммунизм и цены на продукцию печатаются прямо на упаковке, либо с тем, что в Керале не много белых туристов.

Еще у них есть один интересный жест – покачивания головой. И это не массовый тремор, а символ уважения, согласия или выражение внимания. Они вообще не кивают, когда говорят «да», а только трясут головой, поэтому первое время было не понятно, что же собеседник имеет в виду.

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

Несмотря на то, что Кочин это портовый город с развитым рыбным промыслом, рыбу мы здесь не ели. Достаточно было посмотреть на то, как ее продают: покупаешь 1 кг рыбы – 500 мух и аромат гнили в подарок. К сожалению, так было почти везде.

Город состоит из нескольких островов, между которыми ходит водный общественный транспорт за смешные 0.064$ (4 рубля за билет).

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

В целом Кочин это город на пару дней. Мы поехали дальше.

Мунар оказался спасением. Совсем другая Индия. Вообще этим мне и нравятся тропические страны – здесь достаточно переехать в горы, чтобы сбежать от жары.

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

Мунар – горный город, где выращивают чай, кофе и делают шоколад. По моему экспертному мнению, чай как чай, масала кофе на вкус напоминает землю, а шоколад один в один «Красная цена»‎. Даже чай со вкусом вымоченных в нем пальчиков индийского официанта не произвел на меня впечатления (да, к чистоте у них особое отношение).&nbsp;

А еще индийское вино. Вообще, алкоголь в Керале это редкость – его практически нигде не продают, даже в ресторанах. Но его здесь производят и называют herbal drink – это сладкий слабоалкогольный виноградный напиток естественного брожения с добавлением трав. Рекомендуется к употреблению даже детям. Стоит всего лишь 3$. Правда, его практически невозможно купить нигде, кроме Мунара. Мы пытались это сделать в Вагамоне, но там нашлось только 3 бутылки на весь город. Также рассчитывали на дьюти фри в аэропрту, но там его тоже не оказалось так же как и индийского шоколада. В Вагамоне есть свое производство вина, но по вкусу оно хуже, а некоторое отдавало металлической бочкой, в которой, видимо, выдерживалось. В целом еда в Индии часто была с неприятным привкусом местной фильтрованной воды.

Здесь обитают леопарды, тигры, пантеры, бизоны. Все они представляют опасность, в основном для местного домашнего скота. За пару недель до нашего приезда, тигр убил 10 коров выпив их кровь.

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

Самое сильное впечатление было от местной природы. Хайкинг в 7 утра с гидом Шивой остался лучшим событием за всю поездку. Рассказывать тут особо нечего, надо смотреть фотки:

В Мунаре мы впервые познакомились с индийским междугородним общественным транспортом. Он оказался не таким плохим как представлялось. Конечно, не без нюансов: автобусы напоминают тюрьму на колесах из-за отсутствия стекол, а водители словно водят <a href="https://harrypotter.fandom.com/ru/wiki/%D0%90%D0%B2%D1%82%D0%BE%D0%B1%D1%83%D1%81_%C2%AB%D0%9D%D0%BE%D1%87%D0%BD%D0%BE%D0%B9_%D1%80%D1%8B%D1%86%D0%B0%D1%80%D1%8C%C2%BB">«Ночного рыцаря» из узника аскабана</a>. Но при этом, в отличие от Грузии, здесь есть настоящие автостанции и автобусы ходят ровно по расписанию. Цена билета ~0.016$ (1 руб. 20 коп.) за километр пути.

Алапуджа (почему-то еще Аллепи, Аляпи, Аллепей) – индийская венеция. Правда, грязная и жаркая – ну, как и вся Индия. Город знаменит своими заводями и возможностью пожить на воде в хаузботе. Снять хаузбот на ночь стоит в районе 100$. Пожить в нем мы так и не решились, но отправились в тур по местным каналам.

В каналах Алапуджи люди ловят рыбу, моют посуду, стирают одежду и даже моются. Мы эту жижу не трогали даже пальцами. Я все хотел увидеть хоть одного крокодила, но оказалось, и они брезгуют тут жить.

Где-то читал что в заводях Алапуджи находится около 1600 хаузботов, треть из них нелегально.&nbsp;

В Керальских кафе и ресторанах (возможно во всей Индии) не подают никаких десертов, кроме мороженного. Нигде нет сладкого. Его просто не умеют готовить. Как нам объяснили, для этого требуется специально образование, а в Индии с этим плохо. Да и в целом в Индии нет того обилия вкусных блюд и фруктов, которое ожидаешь от тропической страны. Здесь в основном едят рис с каким-нибудь острым гарниром. Порции всегда большие, а прием пищи на двоих обходился в 8.5$.

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

Здесь есть пляж, на котором по вечерам посмотреть на заката, казалось, собирается вся Индия. Он закрыт для купания в это время года из-за неспокойного океана: отливом быстро уносит от берега, а волна может у дарить с такой силой, что потеряешь сознание.

На пляже не редко можно встретить больших усатых мужиков держащихся за руки. Такие люди самые что ни наесть консерваторы и привереженцы традиционных взглядов. В Индии, держание за руки и обнимания между мужчинами это давняя традиция, показывающая высокий уровень доверия и духовной близости. Подробнее про индийский «‎Броманс»‎ можно почитать <a href="https://economictimes.indiatimes.com/magazines/panache/bromance-is-a-strong-part-of-indian-tradition-and-different-from-same-sex-attraction/articleshow/63341108.cms">тут</a>.

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

Город расположен на краю скалы, на берегу индийского океана. Сюда приезжают за пляжным отдыхом, для серфинга и любители парглайдинга. На краю обрыва расположены магазины и рестораны. Местные активно пытаются заработать на белом человеке. Цены в ресторанах выше, чем в остальной Индии. А одежда, которая продается в магазинах, стоит в разы дороже и воняет старьем. Кажется, что это оверпрайснутый секондхенд. Благо цены можно сторговать практически в половину.&nbsp;

Да, цены здесь выше, но и сервис отличается от остальной Индии. Это единственное место, где выставленные на продажу морепродукты обложены льдом и не воняют дохлятиной.&nbsp;Мидии, которые подают в ресторанах, вылавливают прямо у берега руками.

Я думал, что я слишком экономный, пока не встретил француза, с которым мы решили расшарить поездку на тук-туке. Он посчитал, что заплатить 2$ за 3 км пути не так выгодно, как 40 минут в +40°C с кучей вещей тащиться до отеля. Ну зато пообщались.

Вся туристическая активность сосредоточена на краю скалы. Остальной город довольно спокойный, и почему-то чистый относительно другой Кералы. Кстати, у них нигде нет ни урн, ни мусорных баков, не удивительно что в Индии так много мусора – его просто некуда выбрасывать.

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

Хорошо, что эти отверстия слишком маленькие для местных летучих мышей, которых еще называют гигантскими летучими лисицами. Это такие рыжеватые создания размером с собаку, а иногда и <a href="https://www.sciencealert.com/here-s-what-you-need-to-know-about-that-human-sized-bat-going-viral">размером с человека</a>. К счастью питаются только фруктами.

Из Варкалы мы поехали на поезде обратно в Алапуджу, а из алапуджи вызвали убер до Варкалы. Билеты на поезд тут двух типов: с кондиционером и без. С кондиционером выходит дороже, но «по-индийски» дороже, а так это всего ~7$ за два билета.

Вагамон это второй горный город в Индии, который мы посетили. Наверное, так и надо путешествовать по тропическим странам – чередовать жару с горной прохладой.

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

В Керале в большинстве ресторанов позиции в меню делятся по времени суток. Например, в первой половине нельзя заказать суп или любую другую плотную пищу. Позавтракать можно либо пресно, либо остро.

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

Керала: путешествие в самый развитый регион Индии

Простой вопрос на первый взгляд. Но так ли это? Давайте разберемcя на примере. 

Дано 2 типа для функций:

Кто чей подтип? У f1 тип аргумента уже, поэтому можно предположить, что f1 будет подтипом f2. Но, на самом деле нет. Если скомпилировать код ниже, то мы увидим, что isSubtype равен false:

На деле f2 будет являться подтипом f1, несмотря на то, что тип аргумента шире. И это не какая-то условность языка, а вполне логические объясняемое правило.

Если бы f1 являлся подтипом f2, то мы бы могли с f1 работать как с f2. Но у f2&nbsp; тип аргумента шире, и в рантайме такое поведение приведет к ошибке. А вот с f2 можно смело обращаться как с f1.

С возвращаемыми типами обратная ситуация. В подтипе их надо сужать.&nbsp;Полностью правило звучит так:

Тип функции A будет являться подтипом базового типа B, если типы аргументов A будут являться контрвариантами типам аргументов B, а тип возвращаемого значения A будет являться ковариантом типа возвращаемого значения B.

Это правило работает только, если включен strict.

Подробнее можно почитать тут: <a href="https://dmitripavlutin.com/typescript-covariance-contravariance/">https://dmitripavlutin.com/typescript-covariance-contravariance/</a>

Как создать подтип функции в TypeScript?

Озеро «Лиси», Тбилиси

Парк вокруг озера «Лиси», Тбилси

Станция метро «Церетели», Тбилиси

Черепашье озеро с видом на Тбилиси

Дезертирский рынок

Да, их там действительно нет. Вернее так, там есть что-то с названием «репозиторий», но это не репозиторий. Сейчас объясню почему.

Есть такой паттерн Data Mapper, у которого одного предназначение – гонять данные между доменной моделью и базой, тобишь создавать объекты с данными и сохранять их обратно в бд. Чем, собственно, TypeORM и занимается.

В представлении многих разработчиков это и есть репозиторий. Но у репозитория другая задача – имитировать коллекцию.

Мы же все знаем, что объекты передаются по ссылке. И, следовательно, получив ссылку на объект, можно этот объект мутировать как душе угодно. Но в случае с дата мапером эта идеальная картина мира рушится. Во-первых дата мапер при каждом вызове будет возвращать новый объект, а во-вторых он не будет знать ни о каких манипуляциях с объектом, и по итогу придется вызывать <code class="inline-code">dataMapper.save</code>, чтобы записать состояние объекта в бд.

Кажется сверху дата мапера нужен еще один слой.

Тут в дело вступает репозиторий, который, напомню, имитирует коллекцию объектов. С правильным репозиторием достаточно написать следующий код, чтобы изменить состояние в бд:

Следующее так же будет верно:

Но как изменения попадут в базу? Дата мапер все равно не узнает, что объект мутировал. Кажется все таки нам нужен метод <code class="inline-code">repository.save</code>…

Ну нет. У этой проблемы есть решение и имя ему Unit of Work – это еще один патерн, которые реализуется поверх предыдущих двух и следит за границами работы с объектами.

Код с Unit of Work, Repository и Data Mapper выглядел бы так:

По итогу работы этого кода, UoW подсчитал бы все изменения которые произошли в репозиториях и вызвал бы нужные методы у дата маппера, а в базе бы оказалось 2 записи: первая со старым пользователем, у которого обновилось имя, и вторая с новым Гришей.

В TypeORM нет репозиториев

Лестница в доме, Тбилиси

Тбилиси

И почему это не работает.

До недавнего времени Яндекс.Карты никак не ограничивали запросы к непубличному API карт. Их можно было парсить в несколько потоков с одного IP адреса в течение недели и не словить бан.

Теперь же Яндекс стал подписывать каждый запрос. А это значит, что передать свои параметры в запрос без генерации новой подписи невозможно.&nbsp;

Подпись создается на стороне клиента, а значит найти алгоритм генерации это вопрос времени.

Для этого открываем&nbsp;<a href="https://maps.yandex.ru/">maps.yandex.ru</a>&nbsp;в Chrome, затем&nbsp;Dev Tools&nbsp;-&gt;&nbsp;Network&nbsp;-&gt;&nbsp;XHR. Кликаем на любой объект на карте, и во кладке с запросами наводим мышь на колонку&nbsp;Initiator&nbsp;у любого запроса с подписью.

Откроется такая цепочка вызовов:

Осталось найти в ней код, который генерирует подпись. Для этого сразу кликаем на вторую строчку и видим следующее:

Под цифрой 3 отмечена функция, которая генерирует подпись. Давайте ее разберем:

В качестве единственного аргумента функция принимает объект с параметрами будущего запроса.

После этого объект сортируется по ключу в порядке возрастания и преобразовывается в строку. Результат присваивается переменной t.

Последний этап это генерация подписи. За это отвечает странный код в цикле for, который является ничем иным как JS реализацией популярного хэш алгоритма&nbsp;<a href="https://theartincode.stanis.me/008-djb2/">djb2</a>.

Алгоритм делает следующее:

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

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

Возьмем оригинальный запрос Яндекс, как пример того, что должно получиться:

https://yandex.ru/maps/api//tycoon/fetchAuthorizedBusinesses?ajax=1&amp;csrfToken=b0c6443bcacfe78152b8dc3ca49f4754e1b0e88d%3A1626510632&amp;s=3267941894&amp;sessionId=1636510632632_659280

Параметр&nbsp;s&nbsp;равен&nbsp;3267941894. Значит при генерации подписи для строки&nbsp;ajax=1&amp;csrfToken=b0c6443bcacfe78152b8dc3ca49f4754e1b0e88d%3A1626510632&amp;sessionId=1636510632632_659280&nbsp;должно получиться именно это число.

В итоге мы выяснили, что подпись запросов не помогает защититься от парсинга, так как все вычисления происходят на стороне клиента. Скорее всего в Яндексе это понимают, и единственная причина по которой они ввели подписи – сломать все работавшие до этого момента парсеры

Как Яндекс.Карты защищаются от парсинга

Проект был запущен в январе 2021 года. На создание меня вдохновила онлайн карта <a href="http://how-old-is-this.house">с возрастом построек Питера</a> от Никиты Славина. Так как говорят, что Воронеж это маленький Питер, то и у него должна быть своя маленькая карта.

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

Данные о годах постройки зданий есть в кадастров реестре. Более того, существует <a href="https://pkk.rosreestr.ru">публичная кадастровая онлайн карта</a>. Поэтому зная адрес постройки, можно узнать её кадастровые данные, в том числе год постройки и год ввода здания в эксплуатацию.

Все адреса в любых государственных реестрах унифицированы и их можно скачать&nbsp;из базы&nbsp;<a href="https://fias.nalog.ru">ФИАС</a>. База организованна неудобно, нет отдельных региональных баз, но хорошо, что эти данные вообще есть в публичном доступе. Архив всех адресов на момент работы над проектом весил ~8гб.&nbsp;

Скачали. Спарсили. Выгрузили в PostgreSQL. Получили ~70к адресов.

Затем на каждый адрес нужно было сделать запрос к кадастровой карте. Этот процесс занял несколько дней. В итоге удалось собрать ~27к годов.&nbsp;

P.S. Потом выяснилось, что в парсере был баг и часть информации не собиралась. Повторив процедуру спустя пол года, получилось добавить в базу еще несколько тысяч годов.&nbsp;

Еще один источник, который использовался при сборе данных это <a href="https://opendata.mkrf.ru">Единый Государственный Реестр Объектов Культурного Наследия</a>.

В дальнейшем некоторые данные были взяты с <a href="https://www.reformagkh.ru">сайта реформы ЖКХ</a>. Так же пользователи сами присылали информацию о годах построек некоторых домов.&nbsp;Сейчас в базе хранятся даты построек ~35 000 домов.

Сбор картографических данных

Самые полные картографические данные о Воронеже есть только у Яндекса и 2GIS, но получить легальный доступ к ним не реально. Зато есть проект OpenStreeMap (OSM), где силами сообщества создается подробная бесплатная карта всего мира.