Программирование и структуры данных

Я думаю многие знают замечательного парня Линуса Торвальдса, который подарил миру Linux, Git, а также массу мемов и цитат типа "Nvidia, fuck you!". Ещё Линус человек прямолинейный, за словом в корман не лезет и не стесняется поучать других в переписке разработчиков Linux. В одной из таких переписок и находится интересная цитата про код и данные (перевод на русский): "Плохие программисты заботятся о коде, хорошие - о структурах данных и их взаимосвязях".

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

- Данные первичны. От постановки задачи до конечного результата "заказчика" интересуют данные, а не чудесный способ их получения/хранения/обработки.

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

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

- Если начинать Code Review со способа хранения, то обычно все остальное становится более понятным.

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

Думайте о данных и хорошего коддинга 🤟

Must have технологии - S3

С годами активного проектирования и разработки сервисов логично накапливать строительные блоки 🧱, которые, может быть, не идеальны, но вы умеете их готовить правильно. Начну постепенно описывать свой набор. Первый кирпичик - хранилище объектов S3. В рамках S3 вы можете создать сколько угодно контейнеров, а уже в самих контейнерах лежат папочки и файлы. Изначально был запущен в качестве компонента AWS, но S3 настолько удобен, что доступен сейчас у всех крупных и не очень облачных провайдеров, есть опенсорсные реализации и в принципе является почти стандартом хранения файлов.

Для чего использую:
- Cохраняю статические файлы после сборки веб-сайтов (js, css, картинки, шрифты) в публично доступный контейнер S3, подключаю сеть для раздачи контента (CDN), а дальше статика оказываются в браузере ваших клиентов 👨‍👩‍👧‍👦
- Кладу в S3 файлики, загружаемые пользователями. Обычно это бинарные данные типа картинок, документов и тд. S3 для этого должен быть приватным. Доступ к нужным файлам для нужных пользователей реализовывается на уровне вашего приложения.
- Храню бекапы БД . Здесь несколько моментов. Для разных окружений/контуров использую разные контейнеры, чтобы разграничить доступ. Для этой темы идеально подходят "холодные" контейнеры, они дешевле для редко запрашиваемых данных. И, наконец, бекапы обычно не хранят вечно, поэтому настраиваю для таких контейнеров автоматическое удаление через 1-2-3 месяца 📆

P.S. При разработке и в CI использую Minio - с задачей справляется. Есть Docker 👍

До связи 🤟

Бизнес на Open Source

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

- Платная версия. У опенсорс продукта появляется вторая версия, которая продается за деньги. Есть все тоже, что и в бесплатной версии плюс вагон и/или маленькая тележка ништяков. Часто эти ништяки не относятся к основной функциональности приложения. Модель хорошо работает с технически сложными решениями (для них сложно/дорого искать замену). Для меня каноническим примером является Nginx. Есть Open Source версия, а есть NGINX Plus - коммерческий вариант, в котором есть дополнительные модули, а у общепринятых модулей больше различных опций.

- Облачная версия. На базе опенсорс продукта создается сервис, который помогает развернуть решение в облаке ☁️. Оформили подписку и всю головную боль по развертыванию, обновлению, мониторингу и так далее отдали на откуп. Вспоминается MongoDB и их облочное решение MongoDB Atlas: выбрали тариф, облако развертывания (AWS, Azure или GCP) и вперед - документо-ориентированная БД готова.

- Продажа модулей. Если опенсорс продукт предоставляет механизм расширений 🛠, то вокруг этого строится marketplace, где можно публиковать и продавать дополнительные модули. В этой модели и маркетплейс может зарабатывать на комиссии, и совершенно сторонние разработчики могут какую-то денежку на своем коде получать. Яркий пример CMS Wordpress, для которой существуют сотни платных плагинов.

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

- Дополнительный продукт. Нередко вокруг основного опенсорс продукта можно создать связанные продукты, которая будут решать узкоспециализированные проблемы пользователей основного решения. Например, Postgres.ai решает проблему создания быстрых "клонов" для баз данных PostgreSQL, что очень полезно, если проверить работу на большом количестве данных необходимо, но создавать/хранить постоянно бекапы долго и дорого, а давать доступ к продакшену для тестирования никто не будет.

- Обучение. Пожалуй, это скорее отдельная сфера - EdTech 📚. Но в любом случае очень большая часть обучения построена вокруг Open Source: языки программирования, фреймворки, базы данных, devops инструменты и так далее. Примеров приводить не буду, сейчас любой может привести минимум 5 примеров компании, которая гарантирует обучить с нуля до Middle Developer за 3-6-9-12 месяцев 😄

- Донаты. Вы создаете популярный опенсорс инструмент и его поддержка стала занимать слишком много времени? Открывайте прием донатов и занимайтесь вашим github-детищем в режиме фул тайм 😍 Например, один из самых популярных сборщиков для фронтенд-приложений - Webpack - собрал за все время более $1 миллиона!!! 💸

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

Кеширование

Люблю заходить в тему с цитаты, итак: "Есть только две сложные штуки в Computer Science: инвалидация кеша и придумывание названий" (автор Фил Карлтон). Будем считать, что с названиями для нас всё понятно 😂

А что же с кешом, в чем проблема? Для осознания масштаба проще всего перечислить кеши, которые могут участвовать в обработке одного запроса типичного веб-приложения:

- кеш в браузере (всякие заголовки Cache-Control, Expires, ETag принимают в этом непосредственное участие)
- кеш CDN, в котором хранятся копии статических файлов поближе к пользователям по всему миру
- кеш на прокси-сервере, например, Nginx и директивы с префиксом proxy_cache
- кеш уровня приложения, например, в in-memory бд типа Redis
- кеш основной бд, например, PostgreSQL пытается держать индексы и часть данных в памяти для ускорения доступа к ним
- кеш для жёсткого диска (в Linux для этого есть Disk Cache - сохраняет данные с диска в памяти)
- так SSD может выступать в качестве кеша для HDD в некоторых гибридных дисковых системах
- кеш внутри процессора (обычно их называют L1, L2 и тд; скорость доступ к данным в них на порядки превосходит RAM)

Теперь чувствуется масштабность вопроса с кешом? 😉
До связи 🤟

Pooling и зачем это нужно?

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

Для систем, где важно время отклика или latency, такая техника может быть крайне полезной, ведь основные временные затраты в этом случае происходят в момент старта приложения 🚀

Наиболее распространенные виды пулов:
- Пул объектов или памяти (Object Pool / Memory Pool) - позволяет сократить время на выделение/освобождение оперативной памяти. Распространено во встроенных системах и видео играх.
- Пул тредов (Thread Pool) - экономим на создании/удалении потоков силами ОС. Часто используется в контекте Worker Pool для обработки задач из очередей.
- Пул TCP-соединений (Connection Pool) позволяет с сократить время на установку соединения. Обычно используется для работы с БД или между прокси-сервером и нашим приложением. В случае PostgreSQL каждое новое соединение пораждает новый процесс, так что с этой стороны пул соединений ещё и эту проблему сглаживает 👌

Используйте пул чего-нибудь с умом 🧠
До связи 🤟

Стартап DragonflyDB (убийца Redis)

Как сделать технологический продукт, которым захотят пользоваться консервативные разработчики, если уже есть проверенное решение? Ответ очевиден 😄
Нужно создать что-то полностью совместимое с оригиналом, но более быстрое и/или дешевое. По такому пути пошел DragonflyDB.

Dragonfly - свеженькая open source in-memory база данных, написанная на C++ и совместимая с Redis (но НЕ является форком).
Какие основные моменты отмечаем:
- многопоточная архитектура призвана легче масштабироваться вертикально и лучше утилизировать современный CPU
- первый публичный релиз состоялся в 2022 году (v0.1.0)
- в марте текущего года выпущена v1.0 (стабильная и Production Ready)
- поддерживает порядка 200 команд Redis (это еще не полная совместимость, но достаточно близко)
- по бенчмаркам обгоняют Redis в 25 раз по QPS (бенчмарк от автором Dragonfly, очевидно)
- более 20 тысяч звезд на Github

Из интересного, так это тот факт, что пока нет никакого коммерческого продукта, не заявлена какая-либо бизнес модель.
Но уже состоялся А-раунд инвестиций на шикарные $21 миллион. Видимо вся надежда, что в скором времени все Redis во всех облаках будет заменен на Dragonfly...
Хочется напомнить, что в 2019 году уже появляся многопоточный "убийца" Redis. Называется KeyDB. На дворе 2023 год, но Redis все еще на коне - повод задуматься 🤔

Так же предлагаю ознакомится с моим переводом для Хабра
https://habr.com/ru/articles/745406/, где рассказано, чем плох LRU-кеш и что используется в Dragonfly вместо него.

До связи 🤟

Продуктовые команды

На смену классического разделения команд по функциональным областям (frontend, backend, mobile, design, qa, product…) в IT-компаниях, все чаще создают команды, объединенные работой над конкретным продуктом или какой-то его большой независимой частью. Данное разделение объединяет специалистов разного профиля для работы совместно, значит и задачи такая команд может решать не узкие, а полный цикл - от идеи до продакшена.

Какие достоинства я выделяю в первую очередь:

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

В таком подходе все основные члены команды должны быть крепкими ребятами с опытом. Такой найм сам по себе челендж. Также в подобную структуру чуть сложнее набирать джунов. Морально проще взять одного Junior Backend в отдел бекенда из 5 человек, чем в продуктовую команду, где 1-2 бекендера 🥸

Последний момент заключается в том, в каком объеме данный подход по разделению команд реализован в той или иной компании. Тут все как в Agile, каждый его трактует по своему. У кого-то в рамках команды представлены вообще все компетенции, у кого-то разработка, qa и дизайн вместе, а продукт, аналитика где-то отдельно. Так что если вас зовут в продуктовую команду, нужно уточнять, что же это конкретно у них 😅

До связи 🤟

Кеширование для записи

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

Алгоритм простой:
- Сначала новые данные собираются в оперативной памяти;
- Затем накопленные данные периодически записываются на диск или в базу данных как единое событие. В англоязычном варианте может встречаться термины batching и/или bulk insert.

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

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

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

До связи 🤘

А зачем нам Graceful Shutdown?

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

‼️ Обработка сигналов. Первым шагом в Graceful Shutdown является обработка сигналов, таких как SIGINT и SIGTERM. Таким образом операционная система или система оркестрации контейнеров уведомляет приложение о том, что скоро оно будет завершено.

⛔️ Остановка обработки новых HTTP-запросов. Затем нужно перестать принимать новые HTTP-запросы от клиентов. Это гарантирует, что не будет создано новых активных соединений.

✅ Обработка текущих запросов. Сервер продолжает обслуживать текущие HTTP-запросы до их завершения. Это важно для сохранения целостности данных и предотвращения потери запросов, которые могли бы быть в процессе обработки.

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

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

До связи 🤟

TimSort - алгоритм сортировки, о котором мало говорят

Сортировка данных - не просто вопрос на собеседовании, а интересная алгоритмическая задача и важный прикладной инструмент в написании приложений и сервисов. И достаточно долгое время в этом вопросе доминировал алгоритм быстрой сортировки (Quick Sort или сортировка Хоара), который был встроен в стандартные библиотеки различных ЯП многие годы.
Кажется, что на фоне популярности быстрой сортировки, можно и не слышать о TimSort. И это удивительно, учитывая его эффективность и важность в современной разработке программного обеспечения.

Этот алгоритм был разработан Тимом Петерсом и впервые внедрен в Python в 2002 году. В этом плане алгоритм гораздо новее, чем QuickSort, первая публикация о котором появилась в 1960 году.

✅ В основе этой сортировки лежат сразу двух алгоритма - сортировка вставкой (Insertion Sort) и сортировка слиянием (Merge Sort). Эта комбинация позволяет алгоритму с одной стороны гарантировано сортировать случайный набор данных за О(n * log n), а частично упорядоченные данными будут отсортированы еще быстрее. Для быстрой сортировки - худший случай O(n^2).

✅ Также TimSort является устойчивым (или стабильным) алгоритмом сортировки. Это значит, что расположение элементов с одинаковыми значениями друг относительно друга не изменится после сортировки. QuickSort по умолчанию является нестабильным алгоритмом.

🤩 Все вышеописанное привело к тому, что TimSort стал использоваться в стандартных библиотека Python, Java, Swift и JavaScript (реализация V8) вместо быстрой сортировки. А в набирающем популярность языке Rust присутствует и стабильная (TimSort), и нестабильная сортировка (QuickSort).

Единственная небольшая ложка дегтя - это требование дополнительной памяти в размере O(n), как правило не более n / 2. В этом моменте TimSort проигрывает QuickSort, которому не нужно дополнительной памяти для работы.

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

До связи 🤘

Подходы в разработке фичей: тИповой vs тУповой

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

Часто, несмотря на все проделанные усилия, разработанная фича не приносит ожидаемых результатов. Множество времени и ресурсов были потрачены, и всё, что мы имеем, это разочарование. Но что, если существует другой подход? 🤔

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

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

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

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

Быстрой вам разработки крутых фичей!
До связи 🤘

Bun - новый runtime для JavaScript и TypeScript

Авторы этого проекта пытаются взять все лучшее из мира JavaScript и подарить новый инструмент по принципу все-в-одном:
- самописная и оптимизированная среда исполнения на базе JavaScriptCore и ЯП Zig
- сохранение обратной совместимости с Node.js
- встроенный транспилятор для TypeScript и jsx синтаксисов
- возможность сборки проектов для Frontend
- возможность запуска автотестов и expect-интерфейс проверок
- встроенный менеджер зависимостей со знакомым интерфейсом и высокой скоростью 🚀

8 сентября 2023 Bun добрался до релиза v1.0 (стабильного и готового к продакшену).

А подробности того, что вошло в релиз читайте в моей публикации на Хабре https://habr.com/ru/articles/760002/

До связи 🤘

Пакетные менеджеры и lock-файлы

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

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

Lock-файлы фиксируют конкретные версии всего дерева зависимостей вашего проекта и это дает нам:
🦾 консистентность установленных библиотек между всеми участниками процесса
🚀 ускорение установки (пакетный менеджер точно знает, какую версию нужно скачивать)

Давайте приведу ряд примеров:
- Pipenv и Poetry для языка Python используют pipfile.lock и poetry.lock
- Composer в мире PHP использует composer.lock
- Bundler для Ruby пологается на Gemfile.lock
- npm и yarn в экосистеме JavaScript используют package-lock.json и yarn.lock
- Cargo для Rust полагается на Cargo.lock

Стабильного управления зависимостями и не забывайте коммитеть lock-файлы в git.

До связи 🤘

Must have технологии: react-admin

При разработке проектов обычно возникает момент, когда необходимо создать административную панель управления данными. Она должна обеспечивать базовые операции CRUD (Create, Read, Update, Delete) и не требуют сложных дизайнерских решений, но при этом время на разработку съедает неадекватно (даже если собирать из говна и палок). Стоит ли писать кастомные админки? 🤔

Я думаю нет, ведь есть замечательный react-admin (https://marmelab.com/react-admin/) - фреймворк для написания унифицированных административных панелей. С одной стороны структуру приложения диктует фреймворк (она скорее всего подойдет и вам - она всем подходит 😆). С другой стороны - предоставляет широкий набор готовых компонентов для декларативного описания интерфейса (от <TextInput> до `<DataGrid>`), но можно использовать и кастомные.

Какие моменты еще стоит отметить:
- Более 22 тысяч звезд на Github, более 55 тысяч скачиваний с npm за неделю
- Имеет провайдеры к различным популярным бекендам (REST, JSON API, GraphQL и другие). Есть достаточно простой гайд по написанию провайдера именно к собственному бекенду.
- Смотреть на такие админки приятно - это Material Design
- Предоставляет готовые решения в области авторизации и разграничении доступа, роутинга, интернализации, различным темам оформления
- Есть Enterprise Edition, в рамках которого можно получить еще больше сложных компонент, ролевую систему доступа (RBAC), упрощение работы с древовидными структурами данных, поддержку RealTime и много других плюшек

Жизнь слишком коротка, чтобы писать еще одну типовую админку. Воспользуйтесь react-admin.
До связи 🤘

С днем программиста! 🎉

Инструменты разработчика: RegExp

Регулярные выражения — это мощный инструмент для обработки текстовых данных. В программирование они пришли из математических теорий, таких как формальные языки 🤯, в середине XX века. Но настоящее признание этот инструмент получил ближе к 1970-ым годам, когда регулярные выражения были массово встроены в различные утилиты UNIX, например, awk или grep.

Основные сценарии использования в повседневной разработке следующие:
- Поиск подстрок или паттернов в тексте. Например, можно найти все цифры \d+ или символы английского алфавита [a-z]+ в исходной строке
- Замена подстрок или паттернов другими данными. Можно найти и убрать знаки препинания [\.,-;:!?]+ из оригинального текста
- Разделение текста на части на основе определенных правил. Делим строчку на слова по всевозможным пробельным сиволам \s+
- Валидация данных. Регулярные выражения могут быть использованы для проверки, соответствует ли введенная пользователем информация определенному формату. Например, ^\d{4}-\d{2}-\d{2}$ проверит, соответствует ли строка формату ГГГГ-ММ-ДД

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

✅ Так же помогает писать и понимать регулярные выражения возможность визуализации и быстрой проверки. Я использую https://regex101.com/, но возможно есть что-то и получше.

До связи 🤘

JavaScript внутри Redis

Годами для написания скриптов внутри Redis в основном использовали Lua (не самый популярный язык). Но с релизом 7.2 ситуация начинает меняться, наконец-то для написания скриптов можно использовать JavaScript. Пока доступно в режиме превью, не стабильно, но уже можно пробовать.

Что стоит отметить:
- под капотом используется свежая версия V8 (современный JS доступен!) 🚀
- js-модуль сохраняется в Redis и в режиме standalone, и в кластере на всех нодах (Redis сам следит за этим) 🧐
- обьявленные js-функции можно вызывать через TFCALL lib_name.func_name numkeys kyes args
- js-функцию можно зарегистрировать в качестве триггера, который будут реагировать на все события происходящие с ключами с определенным префиксом

Предлагаю ознакомиться с более подробным анонсом на Хабре https://habr.com/ru/articles/761514/

До связи 🤘

Факапы и что делать дальше?

В жизни каждого из нас бывают моменты, когда не всё идет по плану 🤯. Это могут быть плохие релизы, несоблюдение сроков, ошибки в принятии решений и так далее. Факапы - неотъемлемая часть любой деятельности. И, что важно понимать, это нормально. Мы не роботы, и совершать ошибки - часть процесса саморазвития и профессионального роста.

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

Важно дать своему организму возможность восстановиться после стресса. Иногда этим может быть день отдыха 🧘‍♂️, когда вы просто расслабляетесь и забываете о проблемах. Для других это может быть спортивный зал 🏋️, где физическая активность помогает очистить ум от негативных мыслей. Иногда это просто несколько часов в уединении с хорошей книгой или фильмом 📺.

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

P.S. В четверг был очень тяжелый релиз. Была потрачена куча времени на подготовку, но все равно очень многое пошло не так 😩
В пятницу не работал, посмотрел тупейший "Отряд самоубийц 2", лег рано спать. Суббота уже прошла нормально.

Падаем, но поднимаемся! До связи 🤘

Алгоритмы сжатия и gzip

Быстрая современная передача информации по проводным или беспроводным сетям была бы невозможна без алгоритмов сжатия. Ведь универсальный способ увеличить скорость доставки - это уменьшение объема. Неотъемлемой частью современной веб-разработки и обработки данных стал gzip. Скорее всего каждый сайт открытый в вашем браузере так или иначе использует Content-Encoding: gzip. Давате немного разберемся.

Первый публичный релиз Gzip состоялся в 1992 году, а в 1993 была выпущена версию 1.0. Gzip не является алгоритмом как таковым, а в первую очередь является форматом данных и программным обеспечением для хранения (обычно `.gz`) и сжатия. Под капотом gzip использует алгоритм сжатия без потерь Deflate, который является универсальным алгоритмом и, например, применяется для сжатия изображений в формате PNG.

Deflate в свою очередь является комбинацией из двух наиболее успешных и достаточно древних алгоритмов сжатия без потерь, которые используют разные подходы: LZ77 (1977 г.) и кодирование Хаффмана (1952 г.). LZ77 находит повторяющиеся последовательности байт и заменяет их на указатели на первое вхождение. Кодирование Хаффмана осуществляется путем частотного анализа - чем чаще последовательность кодов встречается, тем в более короткий код на выходе она преобразуется.

В мире Unix для работы с gzip можно использовать следующие утилиты:
gzip - собственно сжимает файл или поток данных (для сжатия нескольких файлов используется в паре с утилитой tar)
gunzip - распаковка .gz файлов
zcat - для чтения сжатых файлов без их распаковки (например, можно просматривать сжатые логи веб-сервера)

Используйте gzip и не забывайте сжимать данные на створе веб-сервера перед отправкой вашим клиентам.

До связи 🤘

Бинарный поиск или Binary search

Представьте себе задачу: вам нужно найти позицию определенного значения в массиве. 🤔

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

Алгоритм бинарного поиска поможет вам справиться с этой задачей за логарифмическое время! Принцип работы очень прост:

1. Находим средний элемент в отсортированном массиве
2. Сравниваем его с искомым значением. Если они совпали, значит задача выполнена
3. Если значение в среднем элементе больше искомого, то искомое значение находится слева от среднего элемента, и мы продолжаем поиск в левой половине массива.
4. Если значение меньше искомого, то продолжаем поиск в правой половине массива.
5. Возвращается к пункту 1 и так, пока не найдем элемент.

✅ Деление исходных данных пополам на каждом шаге и приводить нас в логарифмической оценке временной сложности алгоритма.

Бинарный поиск пользуется популярностью и входит в стандартные библиотеки С/C++, Java, Python, Go, .NET.

Эффективного поиска и до связи 🤘