«Жирный» сервис – ошибочка в проектировании

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

На первых итерациях разработки сервиса нужно было сделать раздел для генерации коммерческого предложения – КП. Он как лендос: текст, картинки, видео. Условный конструктор. Но контента много и каждый раз чтобы не заполнять основу, сделали первично заполненные шаблоны. Их можно скопировать и отредактировать под нового клиента. Когда делали копирование, не подумав, реализовали полное копирование файлов. Это казалось хорошей идеей – полностью разделить оригиналы и копии. Причем копии файлов делали физические. А в каждом КП 4-5 десятков картинок в хорошем качестве и десяток видео.

В итоге менеджеры делают полную копию КП каждый раз. И за год таких копий получилось приличное количество. Сервис стал весить 113 Гб. Это много, учитывая, что 99% этого объема занимает контент для КП. И по большей части все файлы являются дублями.

Пришлось полностью переписать логику хранения контента для КП и скрипты для удаления дублей. После отработки скриптов, которые ищут, мержут и удаляют дубли, оказалось, что из 18919 файлов только 326 уникальных. А вес всего сервиса уменьшился со 113 Гб до 15 Гб. Такие дела, 98 Гб было занято мусором – копиями. Сервис внутренний и пользуется им десяток человек, а 100 Гб им удалось заполнить примерно за 8-9 месяцев.

❗️ Описание новой реализации и алгоритма поиска дублей уже не влезает. Если интересно продолжение – дайте знать, допишу следующими постами.

#Юмор

Ключ от всех дверей

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

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

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

$USER->Authorize($user_id); 

Не сложней и в wordpress:

wp_set_auth_cookie($user_id);

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

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

❗️Пару раз приходили мысли сделать универсальный скрипт для такой авторизации под ходовые CMS и типовые авторизации во фреймворках, но вовремя остановился – есть вероятность, что кто-нибудь забудет этот файл на сервере и на сайте останется «дыра», даже если сам скрипт закрыть дополнительной basic auth или каким-либо еще доступом. Поэтому каждый раз подобные авторизации делаем заново и сразу удаляем.

#Кейсы

Сравнение скорости работы if…else и switch…case

📖 Пару дней назад писал пост про условные конструкции if…else и switch…case. В нем рассматривалось удобство и читаемость кода, и упомянул, что непонятно какой из блоков работает быстрее. Но в комментариях @Zizibob прислал примеры кода на C++, C# и Python, в которых происходит измерение скорости работы. Спасибо ему за это!

Результаты интересные – обе условные конструкции примерно одинаково быстро отрабатывают. Причем в коде на C++ switch…case чуточку быстрее, а в коде на C# наоборот if...else побеждает по скорости.

Для чистоты эксперимента и в рамках развлечения, переписали код еще на несколько языков. Чтобы проверка была максимально точная, алгоритм не менялся, а только переводился на другие языки, не меняя конструкции и способа измерения. Измерения на PHP, Go, Node.js, JavaScript, Ruby дают одинаковый результат – switch…case хоть и совсем немного, но работает быстрее, чем if…else. А вот Bash удивил, в нем switch...case отрабатывает ровно в два раза быстрее, чем if...else. Ну и еще один неожиданный поворот – код на Visual Basic сам по себе отработал очень быстро, а так же конструкция if...else опережает switch...case по скорости.

📌 Примеры кода, на разных языках программирования, можно посмотреть в онлайн-сервисе, который позволяет сразу запустить код и проверить результаты:
– Код на C++(победил switch…case): ссылка
– Код на C#(победил if…else): ссылка
– Код на Python(победил switch…case): ссылка
– Код на PHP(победил switch…case): ссылка
– Код на Go(победил switch…case): ссылка
– Код на JS(победил switch…case): ссылка
– Код на Ruby(победил switch…case): ссылка
– Код на Bash(победил switch…case в два раза): ссылка
– Код на VB(победил if…else): ссылка

❗️Из девяти проверенных языков, только в C# и Visual Basic побеждает if…else.
Если у кого-то есть замечания или комментарии по способу замера скорости или варианты замеров на других языках программирования – присылайте в комментарии, будем разбираться вместе.

#КодРевью

Форма слова в зависимости от числа

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

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

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

📌 Вводная часть затянулась. Теперь к делу😁
Одной из таких мелочей является склонение слов, которые являются приписками к числам. Например, если выводить возраст, то он может иметь три разные формы: 1 год, 2 года и 5 лет. Такие склонения нужно обрабатывать перед выводом. Ситуации бывают разные, поэтому важно иметь заготовку кода как для фронта, так и для бекенда.

❗️ Примеры залиты в сервис, где можно посмотреть код и выполнить его:
– PHP: ссылка
– JS: ссылка

#БазаЗнаний

Дубли логики в сложном условии

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

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

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

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

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

#КодРевью

CodeReview. Проблема N+1

📖 Давно ждал в коде такой ошибки, название нравится – «Проблема N+1». Шутка, конечно, не надо так делать. Когда-нибудь мне нечего будет выкладывать в группу на тему код ревью, а все задачи будут готовы к релизу с первого подхода, но только не сегодня.

«Проблема N+1» – это ошибка производительности при выполнении запросов к базе данных, когда происходит N запросов для получения основных данных и еще один дополнительный запрос для каждой связанной записи, что приводит к возникновению N+1 запросов.

📌 На скрине в верхней части над красной чертой приведет исходный код, где есть эта проблема. Логика отработает и все данные будут верные. Но, с увеличением количества записей в таблицах БД, скрипт будет работать все медленнее и медленнее, пока совсем не перестанет работать и начнет выкидывать таймауты. В исходной реализации первой строкой происходит запрос к одной таблице, а потом в цикле происходят еще запросы к другой таблице для поиска связанных записей.

🔴 «Лечится» такая проблема с помощью связей и join-ов в запросах. В нижней части скрина приведет исправленный код. Логика тут написана на php фреймворке Laravel, который использует ORM. Но в итоге запрос будет вот таким, если писать его на чистом SQL:

SELECT *
FROM tbl_1
LEFT JOIN tbl_2
    ON tbl_1.tbl_2_id = tbl_2.id

🔴 Кроме проблемы N+1, тут еще есть странный момент. Заметил, когда уже писал пост. Зачем-то из базы выгребаются вообще все данные, без каких-либо условий и лимитов. Такие запросы могут так же серьезно сказаться на нагрузке, ведь в БД может быть больше количество данных. И вряд ли они нужны все сразу.

#КодРевью

Как не нужно дебажить

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

Поиски проблем в коде ни к чему не привели, логов нет, а проблема падений оставалась. Время от времени сайт просто сыпался и выдавал 500ю ошибку. А если страницу перезагрузить, то все приходило в норму, как ни в чем не бывало. Самое неприятное, что ошибку не получалось воспроизвести – полный рандом. Но ошибкой точно есть: заказчик присылал скриншоты и сами поймали пару раз.

📌 Чтобы локализовать проблему, включили логирование ошибок и предупреждений в php. Включили, походили по сайту – все число в логах. Но и падений не случается – ошибок нет. Решили оставить сайт в покое и подождать пока логи что-нибудь не поймают.

Через пару дней позвонил заказчик – сайт совсем упал. Раньше хоть перезагрузка страницы помогала, а теперь полностью лег и не встает. Побежали разбираться. Выяснили, что сайт кидает 500ю из-за нехватки места на жестком диске. И причиной является наш лог с ошибками, который насобирал эрорров и варнингов аж на 10-12Гб, забил все место и тем самым положил сайт.

Логи почистили, сайт подняли и начали искать откуда такое количество ошибок в журнале. Оказалось, что туда все предупреждения записываются, а на одной из страниц была не критическая ошибка, но код вызывался в цикле. Так за 1.5-2 дня этот код сгенерировал больше 10Гб логов и уложил сайт окончательно.

😀 Самое смешное, что логи никак не помогли найти причину периодических падений, с ней разобрались через созвоны с поддержкой хостинга – это блокировка у них такая: при достижении лимита нагрузки и на пиках сайт просто падал. Проблема была исправлена с помощью повышения тарифа хостинга. Довольно странный способ сообщения о превышении лимита ресурсов.

#Юмор

Лимиты размера файлов в ботах telegram

📖 С ростом аудитории телеграм и появлением в них ботов, появились и новые возможности, которые могут закрывать некоторые потребности бизнеса. Боты не стоят на месте и тоже развиваются, они уже умеют кроме переписок, отображать и веб-интерфейс. Но таких пока не много встречается – это относительно новая возможность. Возможно, кто-то их еще даже не видел. Чтобы понятней было, вот пример одного нашего тестового бота: ссылка. Такие интерфейсы открывается даже из общих чатов и каналов. Это просто веб-вью сверстанное и прикрепленное к чат-боту. При открытии интерфейса, запускается и бот, к которому всегда можно будет потом вернуться и продолжить пользоваться.

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

📌 Несколько дней ломали голову, как быть. А потом нашли, что у телеграм есть открытые исходники сервера для локальной разработки: ссылка. Их можно сбилдить и запустить локально, и отправлять запросы к api. Работает, как и обычные сервера телеграм, даже синхронизация переписок есть. Но в локального сервера есть преимущество – лимит по весу файлов там уже 2 Гб. Это именно то, что нужно. Дальше дело техники: накатили и сбилдили исходники у себя на сервере, прицепили к порту домен и стали использовать вместо телеграмовских серверов – все апи и хуки бота работают через наш сервер.
И приятный бонус – исходники можно дописывать под себя. Сервер написан на Си, с ним не работаем, но по мелочам в ознакомительных целях доработали одну апи.

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

#Кейсы

Pinger – альфа-версия проверяльщика сайтов

📖 Я уже рассказывал (Пинг и SSL), что у нас есть бот, который проверяет работу клиентских сайтов, где нельзя или нет ресурсов, чтобы развернуть полноценную систему мониторинга. Это внутренний инструмент, а управление им происходит через конфиг. К тому же на него еще куча других внутренних метрик завязаны. Поэтому бота не показывал, только скринами и описанием.

Но идея сделать подобный публичный инструмент уже давно появилась. Только больше 2 лет не получалось выделить время и оформить в рабочее и открытое решение. Сперва не рассчитали силы и хотели запилить большой инструмент проверок, чтобы все по-взрослому: с ЛК, сайтом и тд. Такая реализация растянулась на долго, с учетом что разработка внутренняя и время на нее всегда выделяется по остаточному принципу. Что-то пытались делать факультативно – по вечерам или на выходных. Но в итоге проект заглох и его совсем отложили.

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

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

📌 Итак, что умеет бот:
– Принимает сайты и ставит их в очередь на проверку
– Показывает список всех сайтов, которые добавлены
– Каждую минуту проверяет http-ответ сайта. И если случилась беда, то отправляет об этом сообщение
– Если сайт «упал», то так же наблюдает за ним. И когда сайт снова станет доступен, пришлет об этом уведомление
– Проверяет дату SSL и уведомляет за 7 дней до завершения
– Проверяет дату оплаты домена и уведомляет за 7 дней до завершения

❗️Ссылка на альфа-версию бота: @OWL_Pinger_Bot.
Очень важна обратная связь! Если интересно, то пишите в ЛС или в комментарии.

#НашиРазработки

Изменение php.ini для версии 7.4 и выше

📖 Начиная с версии PHP 5.3, появился FPM – менеджер процессов для php, он оптимизирует и ускорят работу. Но до 7й версии толком не использовался, возможно, это связано с отладкой оптимизации. А вот начиная с версии PHP 7.4, сам по себе php уже не умеет работать, только вместе с fpm.

Регулярно попадаются вопросы на stackoverflow, которые напрямую связаны с FPM. Вероятно, не все знают про этот менеджер процессов. И пытаются управлять настройками PHP по старинке, через конфиги Apache в .htaccess. Но когда процессами PHP начал управлять FPM, веб-сервер уже не может изменять параметры из конфига php.ini.

Раньше, до версии php 7.4 для обновления условной директивы upload_max_filesize, отвечающей за максимальный объем файла, который можно передать по http с помощью POST-запроса, достаточно было обновить .htaccess на серверах Apache. И тогда php бы поменял свои настройки. Сейчас такие фокусы уже не проходят.

📌 Теперь везде, начиная с версии php 7.4, а на некоторых серверах, где и раньше начали использовать FPM, для обновления директив PHP, нужно редактировать непосредственно конфиг php.ini. После чего, нужно перезапуускать службу FPM.

Чтобы было понятней, приведу полный маршрут обновления конфига php, на примере версии 7.4. Самой частой проблемой бывает, как раз лимит размера файла, который нужно передать на сервер. Для этого нужно обновить директивы upload_max_filesize – отвечает за лимиты передаваемых по http файлов методом post и post_max_size – отвечает за максимальный размер всего post-запроса, а не только файлов. Поэтому post_max_size не может быть меньше, чем upload_max_filesize.

📌 По шагам, команды в консоле:
– Сперва нужно найти расположение php.ini. Это можно сделать командой:

php --ini

– Редактируем upload_max_filesize и post_max_size на нужный размер. Например, 20M – 20 Мб. По умолчанию там 5 Мб.
– После сохранения php.ini достаточно перезапустить только службу FPM. Вот так:

service php7.4-fpm restart

Перезапускать Apache или Nginx не нужно.

#БазаЗнаний

Тысяча кликов

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

На одной странице сайта выводится большая карта с уже отмеченными на ней точками. Точек много – 843 штуки, почти тысяча. Но их сразу все нужно показать и подгружать порциями нельзя, кластеризация тоже не подходит по условиям задачи. Деваться некуда, нужно работать сразу с таким объемом. Карта для отображения используется от Google, точки рисуются через api. Однако, кроме отображения всех точек, на них еще висит немного логики: по клику на точку, карта смещается так, чтобы эта отметка стала по центру. И в интерфейсе верстки есть точно такая же дублирующая логика – выводится стилизованный список всех адресов, по клику на которые карта также смещается и показывает нужную точку в центре.

📌 И вот как раз в дублирующей логике, для обработки клика по адресу из списка, есть ошибка. Код обработки клика на скриншоте к посту. Добавил на картинку подписи, чтобы было понятней. Есть цикл, который перебирает всю тысячу точек, выполняет там свою логику и в конце происходит добавление обработчика клика по точке.
Поскольку цикл выполнится только же раз, сколько есть адресов (843 шт), то и обработчиков кликов добавится столько же. Плюс ко всему, внутри обработчика клика по элементу из списка, вызывается триггер клика по точке на карте google. Триггер – это костыль, чтобы логику центровки проще вызвать. Но речь не про него.

❗️При каждом клике по элементу, сработает 843 события. И в каждом таком событии отрабатывает вызов карты. Браузеру такие повороты не очень нравятся и появляются подвисания. Для фикса, достаточно вынести обработчик за пределы цикла, логика не пострадает.

#КодРевью

Легкий способ усвоить материал

📖Разработчики, как и любые другие специалисты, постоянно находятся в процессе освоения, нарабатывания и оттачивания навыков. Нельзя дойти до какого-то точки и остановиться. Это актуально при условии, что спец уважает себя и свое ремесло, и если не с любовью, то хотя бы с теплотой относится к своему труду и его результату. Иначе нет смысла «прокачиваться», чтобы повышать качество результата. Одними деньгами это нельзя измерять, на долго запала не хватит.

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

📌 А вот для применения на практике такого недостаточно, всегда нужно поковырять «руками» и набить шишек, чтобы новый инструмент или подход можно было полноценно добавить к себе в арсенал. И вот как раз про набивание шишек моя заметка. Это только мои наблюдения и ничем более не подтверждены. Но из опыта точно уверен, что, чем больше шишка, чем больнее ее набиваешь, там лучше запоминается проблема и способ решения. Если промучиться целый день и перепробовать десяток подходов, изойти на псих, скурить пачку сигарет, забыть про обед, а потом еще и на несколько часов задержаться в офисе, но в итоге победить – решить задачу, то такой способ решения запомнится на всю жизнь. Хоть решением может быть и 2-3 строчки кода, но к ним нужно сперва прийти, написав и переписав ни одну сотню строк.

У меня даже некоторые точечные решения или глобальные заготовки в проектировании очень четко отпечатываются и ассоциируются с воспоминаниями, как к ним пришел. Возможно, это что-то на психологическом и сильные эмоции лучше запоминаются, но я не психолог😁
⁉️Если есть объяснения, то поделитесь.

#Мысли

Ревью комментариев

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

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

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

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

❗️ Есть простое решение – регламентирование и проверки. Но все-таки хочется достучаться словами и объяснить, чтобы разработчики сами осознали важность и пользу комментариев. Ведь это такая же часть кода и задачи, над которой идет работа.

#КодРевью

Релиз мимо сервера

📖 Ну вот и очередная пятница, с чем всех и поздравляю. И уже по сложившейся традиции, пятничный пост с хохмами.

Буквально 5-6 часов назад инцидент произошел. 5-6 часов для меня, пишущего этот текст в четверг ночью. Но не в этом суть, а просто уточнение, чтобы «сегодня» правильно понимали. Релизили мы сегодня сайт. Проект не сложный, логики нет. Это промо-визитка для организации, на которой из функционала только админка под контент и api для связи с фронтом. Фронт на vue 3 + nuxt 3 и работает отдельно от админки, связываясь по api. То есть у нас два куска сайта – админка и фронт.

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

У нас есть тестовый физический серверов, пяток VPS и несколько хостингов. Ребята развернули боевые версии админки и фронта, оставалось только передать ip сисадмину и дождаться, когда он впишет их в A-записи. Потом проверить, как все работает и установить SSL сертификаты.

📌 Я передал IP-адреса и все пошли дальше заниматься своими задачками, ожидая линковки. Время 18:00, начали расходиться по домам из офиса. И как раз заказчик сообщает, что прописали IP, скоро все заработает. Пошел смотреть и понимаю, что для фронта я отправил не тот IP, перепутал сервера. Админка заработала, а фронт, конечно же нет. Сисадмин заказчика закончил рабочий день – поменять IP не получится. И наши разработчики разошлись.

Деваться некуда, «вылет» домой откладывается. Пришлось самому разворачивать фронт на втором сервере, IP от которого отправил по ошибке. Вот так на ровном месте нажил себе приключений на 1.5-2 часа. Зато освежил навыки запуска vue + nuxt и настройку окружения под него.

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

#Юмор

Имитация прелоадера

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

Делали как-то страницу с большими картинками – несколько штук на странице, которые обязательно нужно сразу загружать. Иначе весь смысл теряется. Это карта микрорайона со хорошо нарисованной детализацией и еще несколько графических элементов. Весило все это дело 4-5 Мб. Плюс еще стили, js, сама html с svg-шками и остальные мелкие картинки и иконки. И если открыть страницу с медленным интернетом, то какое-то время кажется, что сайт сломался, пока не прогружены основные большие картинки и не понятна вся композиция. Поэтому решили добавить прелоадер, который скроет все это безобразие, до полной загрузки важных картинок.

📌 Как сделать прелоадер понятно – тут ничего особо интересного: можно считать количество прогруженных картинок, если много мелких, а можно через объем полученных данных xhr.onprogress. Но чтобы начать считать, нужно прогрузить js на страницу. А с этим были оказались проблемы, билд js имел тоже приличный размер – 250-300 Кб. Быстро раздробить его на мелкие куски не получилось. Даже оказалось проблемой вынести только js-код прелоадера в отдельный js или вообще в шаблон страницы. Никак не могу вспомнить, что именно мешало, но точно были сложности. Если вспомню или наши ребята фронты потом расскажут – допишу в комментарии.

В итоге мы получили страницу с прелоадером, который не работает – стоит на месте первую секунду, а на медленном интернете может и 2-3 секунды не шевелиться, пока не прогрузятся шаблон и js, который начнет расчет загрузки и анимацию прелоадера.
И чтобы замаскировать это подвисание, добавили просто CSS-анимацию прогрессбара, а также вывод процентов от 0 до 10. И засунули эти стили в начало шаблона. Так создается впечатление мгновенного отклика страницы и старта загрузки.

#Костыли

Сортировка массива с помощью рандома

📖 Две недели назад мы с Ильей(@Zizibob) сравнивали скорость работы if…else и switch…case, написав тесты на десятке языков – результаты тут: смотреть.
На этих выходных решили продолжить тему странных, никому не нужных, но веселых и интересных экспериментов. В этот раз проверяем скорость работы и количество необходимых итераций для сортировки массива с помощью рандомного перемешивания.

ТЗ на эксперимент:
– Массив длиной 10 элементов
– Массив первично заполняется уникальными и случайными целыми числами от 0 до 9
– Сортировка должна быть меньшего к большему
– Для сортировки можно использовать только рандом
– Посчитать количество итераций перемешивания и время выполнения
Все обсуждения велись в чате(комментарии), если кому интересно подобное, то заходите: ссылка.

📌 Эксперимент еще продолжается.
Но уже есть три скрипта, их посмотреть и запустить:
– на C++ рандом полный: ссылка
– на C++ рандом по 2 элемента: ссылка
– на php рандом полный: ссылка
Результаты промежуточные: с вероятностью 75% сортировка массива происходит за 5 миллионов итераций (попыток рандома). Скрипты отрабатывают быстро: от 0.002 сек до 4 сек. Результат очень разный – рандом же. Сколько запускал выполнение, самый быстрый подбор произошел за 4830, а самый долгий за 16 миллионов попыток.

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

Пояснение расчета вероятности:
– каждая сортировка равновероятна
– вероятность отсортировать массив длины N с одной попытки равна: 1 / N!
– N! — факториал от 1 до N
– (отсортированный за K перемешиваний) = 1 минус (не отсортированный за K перемешиваний)
– вероятность того, что массив не будет отсортирован с одной попытки равна 1 - 1 / N!
– не отсортированный за K перемешиваний = (1 - 1 / N!)^K
– в итоге вероятность отсортировать массив за K случайных перемешиваний равна 1 - (1 - 1 / N!)^K
Формула вероятности из интернетов, только адаптирована под наш сценарий.

#Юмор

Конкурс на самый интересный алгоритм

📖 Появилась идея устраивать конкурсы/соревнования по мотивам предыдущего поста. Сперва коллективно, в течении недели собираем идеи, потом голосуем за самую интересную. И далее неделю пробуем реализовать задумку. В конце так же через общее голосование выбираем лучший результат. Если получится интересно, то можно устраивать подобное регулярно – два раза в месяц.
Для первого конкурса @Zizibob нашел хороший подарок – календарь от РКС на 2024 год, фото тут: фото.
По поводу призов и общей турнирной таблицы еще нужно подумать. Но это уже дело десятое, сперва достаточно понять – интересен такой формат тут в группе или нет.

📌 По пунктам, чтобы было понятней задумка:
– с 20 по 25 ноября собираем идеи на алгоритм
– идеи присылайте в комментарии к этому посту
– 26 ноября проводим голосование и выбираем самую интересную идею
– с 27 ноября по 3 декабря занимаемся реализацией алгоритма
– 4-5 декабря голосованием определяем победителя

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

❗️Примечание 1. Далее посты про конкурсы не будут заменять основную ленту и очередность заметок этой группы.

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

#Конкурс

Очень интересно, но ничего не понятно

📖 Исходный и отредактированный код можно посмотреть тут: ссылка. В сервисе onlinegdb подсветка кода работает, удобнее смотреть, чем в посте телеграм.

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

📌 Исходный код на скрине в верхней части – 6 строк, а отредактированный внизу – 22 строчки. Код стал длиннее почти в 4 раза. Плохо ли то, что код стал больше? Нет. Никто не будет бить по рукам за лишний код или дополнительные функции в файлах. Зато добавляется сразу несколько плюсов:
– Код стал понятнее за счет говорящих имен функций и из-за того, что логика разбита на понятные кусочки
– Каждую отдельную функцию теперь удобно комментировать
– Функции удобнее и понятнее дорабатывать и расширять
– Функции стало проще проверять и тестировать

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

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

#КодРевью