Обработка несуществующих файлов
📖 В процессе работы над проектами, которые имеют большую контентную базу, зачастую возникают проблемы с тестовыми или локальными файлами – сложно поддерживать их актуальное состояние. К примеру, если на сайте 30-50 гигабайт картинок, то не особо хочется их таскать с продакшена на тестовую или локальную версию.
Контент, естественно, заигнорирован в репозитории и находится без контроля версий. Но в базе данных есть все адреса и пути к картинкам – они нужны для корректной отладки. И чтобы на тестовом стенде отображались изображения, их нужно скачивать.
Самым верным решением будет прописывать полные пути к картинкам и хранить домен сайта в конфиге, чтобы можно было на тесте или локалке подгружать сайты с «боевой» версии. Но не всегда проект построен так, что можно быстро обновить все шаблоны страниц и прописать в них переменные из конфига.
Можно, конечно, и не обращать внимание на битые картинки – сайт тестовый. Но проблема не только в отображении. Есть еще ряд, более критичных, последствий. Во-первых, уже не получится корректно отладить верстку блоков, завязанных на размер картинок. Во-вторых, сайт будет сильно «тормозить», битые файлы в разы дольше обрабатываются браузером. Страница каталога с несколькими десятками товаров, у которых все картинки отдают 404ю ошибку, может грузиться до минуты. Это жутко бесит и мешает работать.
📌 Извернуться в такой ситуации можно через настройку сервера. При запросе к файлу, проверять его наличие, и если изображение отсутствует, то подменять одной и той же «заглушкой» или полным путем к этой же картинке на рабочем сайте.
Приведу пример, как это настроить на веб-сервере Apache, через конфигурации в htaccess.
📖 В процессе работы над проектами, которые имеют большую контентную базу, зачастую возникают проблемы с тестовыми или локальными файлами – сложно поддерживать их актуальное состояние. К примеру, если на сайте 30-50 гигабайт картинок, то не особо хочется их таскать с продакшена на тестовую или локальную версию.
Контент, естественно, заигнорирован в репозитории и находится без контроля версий. Но в базе данных есть все адреса и пути к картинкам – они нужны для корректной отладки. И чтобы на тестовом стенде отображались изображения, их нужно скачивать.
Самым верным решением будет прописывать полные пути к картинкам и хранить домен сайта в конфиге, чтобы можно было на тесте или локалке подгружать сайты с «боевой» версии. Но не всегда проект построен так, что можно быстро обновить все шаблоны страниц и прописать в них переменные из конфига.
Можно, конечно, и не обращать внимание на битые картинки – сайт тестовый. Но проблема не только в отображении. Есть еще ряд, более критичных, последствий. Во-первых, уже не получится корректно отладить верстку блоков, завязанных на размер картинок. Во-вторых, сайт будет сильно «тормозить», битые файлы в разы дольше обрабатываются браузером. Страница каталога с несколькими десятками товаров, у которых все картинки отдают 404ю ошибку, может грузиться до минуты. Это жутко бесит и мешает работать.
📌 Извернуться в такой ситуации можно через настройку сервера. При запросе к файлу, проверять его наличие, и если изображение отсутствует, то подменять одной и той же «заглушкой» или полным путем к этой же картинке на рабочем сайте.
Приведу пример, как это настроить на веб-сервере Apache, через конфигурации в htaccess.
# Взять картинку с рабочего сайта
RewriteCond %{DOCUMENT_ROOT}/images/$1 !-f
RewriteRule ^images/(.*)$ https://production-site-name/images/$1 [QSA,L]
# Или подставить заглушку 404.png:
RewriteCond %{DOCUMENT_ROOT}/images/$1 !-f
RewriteRule ^images/(.*)$ /images/404.png [QSA,L]
#БазаЗнаний👍6
Лимиты в полях таблиц БД при строгом режиме MySQL
В новых версиях MySQL по умолчанию включен строгий режим(strict mode). Он не позволяет делать ошибки в типах и объемах данных при записи. Если его отключить и попытаться записать строку на 100 символов в поле, с выделенным местом под 32 символа, то первые 32 запишутся, а все остальное проигнорируется. Так можно потерять данные и даже не узнать об этом.
Но сейчас на серверах почти всегда включен строгий режим и при попытке впихнуть невпихуемое, MySQL забьет тревогу. Пример есть на скриншоте – это ошибка в консоле от скрипта на node.js, который пытается записать строку длиной 80 символов в поле с типом и размером varchar(50).
В этом кодревью нечего показывать по коду, но можно рассказать, как предотвратить подобные ситуации.
🔴 Ошибка случилась при оформлении заказа, когда пользователь ввел слишком длинный адрес доставки. В ответ он ничего не видел, просто не «тыкалась» кнопка. Это плохо, нужно всегда выводить понятные ошибки. Даже при самом негативном сценарии лучше отдать на фронт сообщение, что случилась беда. Пользователя нельзя оставлять без ответа.
🟡 В форме нужно добавить проверку на длину строки, если такой лимит есть в БД. Фронтовая валидация предотвратит 90% проблем.
🔴 Клиентские проверки спасут от некорректных данных только от рядовых пользователей. Но бывают умники, которые пользуются этой проблемой – могут отправить запрос с переполнением в обход фронтовой валидации. Это одни из первых шагов для взлома БД. Поэтому на бекенде тоже должны быть проверки, дублирующие фронтовые.
🟢 Хорошая практика вести логи ошибок. Их можно хранить, как в файлах, так и в базе данных. Мы для простоты и удобства, пишем логи в MongoDB, создавая под каждый проект отдельную БД и коллекции для разных логических кусков.
🟢 Ну и раз на скрин попала опечатка, упомяну и её. Название поля «adress» нужно переименовать в «address». Чтобы не создавать путаницу при работе с таблицей заказов
#КодРевью
В новых версиях MySQL по умолчанию включен строгий режим(strict mode). Он не позволяет делать ошибки в типах и объемах данных при записи. Если его отключить и попытаться записать строку на 100 символов в поле, с выделенным местом под 32 символа, то первые 32 запишутся, а все остальное проигнорируется. Так можно потерять данные и даже не узнать об этом.
Но сейчас на серверах почти всегда включен строгий режим и при попытке впихнуть невпихуемое, MySQL забьет тревогу. Пример есть на скриншоте – это ошибка в консоле от скрипта на node.js, который пытается записать строку длиной 80 символов в поле с типом и размером varchar(50).
В этом кодревью нечего показывать по коду, но можно рассказать, как предотвратить подобные ситуации.
🔴 Ошибка случилась при оформлении заказа, когда пользователь ввел слишком длинный адрес доставки. В ответ он ничего не видел, просто не «тыкалась» кнопка. Это плохо, нужно всегда выводить понятные ошибки. Даже при самом негативном сценарии лучше отдать на фронт сообщение, что случилась беда. Пользователя нельзя оставлять без ответа.
🟡 В форме нужно добавить проверку на длину строки, если такой лимит есть в БД. Фронтовая валидация предотвратит 90% проблем.
🔴 Клиентские проверки спасут от некорректных данных только от рядовых пользователей. Но бывают умники, которые пользуются этой проблемой – могут отправить запрос с переполнением в обход фронтовой валидации. Это одни из первых шагов для взлома БД. Поэтому на бекенде тоже должны быть проверки, дублирующие фронтовые.
🟢 Хорошая практика вести логи ошибок. Их можно хранить, как в файлах, так и в базе данных. Мы для простоты и удобства, пишем логи в MongoDB, создавая под каждый проект отдельную БД и коллекции для разных логических кусков.
🟢 Ну и раз на скрин попала опечатка, упомяну и её. Название поля «adress» нужно переименовать в «address». Чтобы не создавать путаницу при работе с таблицей заказов
#КодРевью
👍3
Логи-убийцы или история бесконечных падений
🤯 Что-то я перестарался с историей, начал писать и понесло. Весь текст не влезает даже в два поста – лимиты телеграма не большие. Но удалять жалко, а разбивать на 3-4 поста не хочется, такое читать не удобно. Поэтому попробую новый формат — публикация в telegraph, ссылка будет ниже.
📖 Кусочек истории, чтобы было понятно, о чем она:
Акт второй. Падение
Запуск запланировали на 12:00. Проверка всех систем – порядок. Ключ на старт и поехали! Ссылки на страницу публикуются в ВК, ютуб, почтовая рассылка и тд. Сразу же полетели заказы, оплаты проходят, сайт держится. Пять минут – полет нормальный. Трафик посетителей, если судить по метрике, скакнул примерно в 20-25 раз относительно спокойных дней.
12:07, сайт падает. Караул! Семь минут всего продержались. В чем дело? Бегом разбираться. Сервер выкидывает 504ю ошибку – лютые таймауты. На хостинге нагрузка запредельная, до 500% перерасход допустимых ресурсов. В консоле карнавал из подвисших процессов php.
📌 Полный текст истории: ссылка.
#Юмор #Статьи
🤯 Что-то я перестарался с историей, начал писать и понесло. Весь текст не влезает даже в два поста – лимиты телеграма не большие. Но удалять жалко, а разбивать на 3-4 поста не хочется, такое читать не удобно. Поэтому попробую новый формат — публикация в telegraph, ссылка будет ниже.
📖 Кусочек истории, чтобы было понятно, о чем она:
Акт второй. Падение
Запуск запланировали на 12:00. Проверка всех систем – порядок. Ключ на старт и поехали! Ссылки на страницу публикуются в ВК, ютуб, почтовая рассылка и тд. Сразу же полетели заказы, оплаты проходят, сайт держится. Пять минут – полет нормальный. Трафик посетителей, если судить по метрике, скакнул примерно в 20-25 раз относительно спокойных дней.
12:07, сайт падает. Караул! Семь минут всего продержались. В чем дело? Бегом разбираться. Сервер выкидывает 504ю ошибку – лютые таймауты. На хостинге нагрузка запредельная, до 500% перерасход допустимых ресурсов. В консоле карнавал из подвисших процессов php.
📌 Полный текст истории: ссылка.
#Юмор #Статьи
👍8😁2
Лотерея с id-шником записи
📖 На скрине два куска кода из разных функций, вырезал только нужные части для понимания. Логика следующая:
– получаем сообщение от пользователя и записываем его в БД
– проверяем сообщение, если это одна из служебных команд, то отправляем сообщение в ответ
– обновляем статус пользовательского сообщения в БД, ставим пометку, что успешно его обработали и не потеряли
Это логирование общения бота с пользователем — отмечаем, какие сообщения были обработаны, а какие остались без ответов.
📌 Если начать проверять эту логику, то все отработает без ошибок. Но как только ботом станут активно пользоваться, хотя бы несколько человек одновременно, то все перепутается. Флаги успешной обработки начнут выставляться не там сообщениям. Поскольку есть задержка между двумя запросами к БД: создание сообщения и его обновление.
🔴 ID сообщения, которое будет обновляться, нужно возвращать функцией writeDataToDB и передавать в updateQuerySuccess, чтобы работать с конкретной записью в БД. А не надеяться на лучшее и брать последнюю запись в таблице
🟡 ID – это уникальный идентификатор, он только для определения уникальной записи. Для сортировки по порядку должно быть поле с датой создания/обновления или отдельное поле для сортировки, а не MAX(id).
🟡 Бонус-пункт. В switch…case проверяется прямое вхождение сообщения. Тут тоже сломается очень быстро, поскольку пользователи могут написать что угодно и в любом формате. Нужно добавить приведение сообщения к нижнему регистру и обрезать пробелы вначале и в конце текста.
#КодРевью
📖 На скрине два куска кода из разных функций, вырезал только нужные части для понимания. Логика следующая:
– получаем сообщение от пользователя и записываем его в БД
– проверяем сообщение, если это одна из служебных команд, то отправляем сообщение в ответ
– обновляем статус пользовательского сообщения в БД, ставим пометку, что успешно его обработали и не потеряли
Это логирование общения бота с пользователем — отмечаем, какие сообщения были обработаны, а какие остались без ответов.
📌 Если начать проверять эту логику, то все отработает без ошибок. Но как только ботом станут активно пользоваться, хотя бы несколько человек одновременно, то все перепутается. Флаги успешной обработки начнут выставляться не там сообщениям. Поскольку есть задержка между двумя запросами к БД: создание сообщения и его обновление.
🔴 ID сообщения, которое будет обновляться, нужно возвращать функцией writeDataToDB и передавать в updateQuerySuccess, чтобы работать с конкретной записью в БД. А не надеяться на лучшее и брать последнюю запись в таблице
🟡 ID – это уникальный идентификатор, он только для определения уникальной записи. Для сортировки по порядку должно быть поле с датой создания/обновления или отдельное поле для сортировки, а не MAX(id).
🟡 Бонус-пункт. В switch…case проверяется прямое вхождение сообщения. Тут тоже сломается очень быстро, поскольку пользователи могут написать что угодно и в любом формате. Нужно добавить приведение сообщения к нижнему регистру и обрезать пробелы вначале и в конце текста.
#КодРевью
👍5
Автоматическое снятие режима «Без звука» в задачах Битрикс24
📖 В облачной CRM-ке Битрикс24(версия таскменеджер), есть интересная «особенность». По умолчанию при добавлении участников-наюлюдателей в задачу, включается беззвучный режим. И никакие уведомления не приходят из этой задачи. Если дополнительно не «пнуть», то есть большая вероятность потерять задачу.
Эту фичу нельзя выключить через настройки. А поскольку битрикс24 почти всегда облачный, в код не попасть – допилить не получится. Техподдержка разводит руками и ничем помочь не может. Обещали поправить, но, не понятно когда – почти год прошел с момента обращения, ничего не изменилось.
Потеряв очередную задачу, начали искать решения. У БХ24 есть хуки, но через них не всё доступно. В официальной документации нет ни одной апи, которая может обновить или получить статус этого колокольчика. Но открыв консоль браузера, можно увидеть, что запросы-то идут. Значит до них можно попробовать достучаться. На скрине показан запрос, он отправляется при снятии режиме «Без уведомлений».
📌 Чиним:
1. Берем класс, который умеет авторизовываться в БХ24 через хуки, вот такой подойдет: ссылка.
2. Создаем в БХ24 входящий хук с полными правами доступу к задачам
3. Далее пишем простенький скрипт, который потом будем вызывать по расписанию:
— Сперва достаем все свои задачи через апи tasks.task.list и фильтром по полю 'IS_MUTED' == 'Y'. Это флаг, который не задокументирован, в консоле тоже откопали. Отдает только те задачи, которые с выключенными уведомлениями. Можно еще докинуть фильтров по статусам, чтоб не тащить закрытые или какие-то еще не нужные.
— И далее включаем уведомления для задач через запрос к апи tasks.task.unmute, которая принимает всего один параметр taskId – id задачи. А id-шники у нас уже есть, достали предыдущим запросом
4. Вешаем скрипт на крон. Нам хватает вызова раз в час. Но тестил и каждые 10 минут, бан от битрикса не получили
5. Радуемся уведомлениям о задачах. Ну или не очень радуемся, задачи ж делать придется…
#Костыли
📖 В облачной CRM-ке Битрикс24(версия таскменеджер), есть интересная «особенность». По умолчанию при добавлении участников-наюлюдателей в задачу, включается беззвучный режим. И никакие уведомления не приходят из этой задачи. Если дополнительно не «пнуть», то есть большая вероятность потерять задачу.
Эту фичу нельзя выключить через настройки. А поскольку битрикс24 почти всегда облачный, в код не попасть – допилить не получится. Техподдержка разводит руками и ничем помочь не может. Обещали поправить, но, не понятно когда – почти год прошел с момента обращения, ничего не изменилось.
Потеряв очередную задачу, начали искать решения. У БХ24 есть хуки, но через них не всё доступно. В официальной документации нет ни одной апи, которая может обновить или получить статус этого колокольчика. Но открыв консоль браузера, можно увидеть, что запросы-то идут. Значит до них можно попробовать достучаться. На скрине показан запрос, он отправляется при снятии режиме «Без уведомлений».
📌 Чиним:
1. Берем класс, который умеет авторизовываться в БХ24 через хуки, вот такой подойдет: ссылка.
2. Создаем в БХ24 входящий хук с полными правами доступу к задачам
3. Далее пишем простенький скрипт, который потом будем вызывать по расписанию:
— Сперва достаем все свои задачи через апи tasks.task.list и фильтром по полю 'IS_MUTED' == 'Y'. Это флаг, который не задокументирован, в консоле тоже откопали. Отдает только те задачи, которые с выключенными уведомлениями. Можно еще докинуть фильтров по статусам, чтоб не тащить закрытые или какие-то еще не нужные.
— И далее включаем уведомления для задач через запрос к апи tasks.task.unmute, которая принимает всего один параметр taskId – id задачи. А id-шники у нас уже есть, достали предыдущим запросом
4. Вешаем скрипт на крон. Нам хватает вызова раз в час. Но тестил и каждые 10 минут, бан от битрикса не получили
5. Радуемся уведомлениям о задачах. Ну или не очень радуемся, задачи ж делать придется…
#Костыли
👍3❤1
Автоматическое закрытие тестовых сайтов
📖 Любая адекватная разработка ведется отдельно от рабочего сайта. Прежде, чем запустить новый проект или доработки по существующему, проходит ряд проверок и утверждений на тестовых площадках. Чтобы корректно отладить все доработки, тестовый сайт должен быть максимально идентичен рабочему. В том числе и по контенту.
Тестовые площадки посещают еще и заказчики, поэтому сайты и сервисы доступны за пределами локальной сети. Это проблема, ведь поисковые роботы шастают там, где их не ждут. И тесты попадают в поиск, снижая поисковый вес рабочему сайту.
В мануалах гугла и яндекса пишут и утверждают, что поисковых роботов можно блокировать через robots.txt или мета-теги noindex. Но это не всегда так, проверено уже. К тому же, robot.txt или noindex нужно игнорировать в репозитории, чтобы они не попали на боевой и не натворили дел. За этим сложно уследить, особенно если много проектов в работе и на каждом проходят регулярные релизы.
📌 Чтобы без лишних проблем и наверняка заблокировать все тестовые сайты, мы написали несколько скриптов, которые проверяют наличие и добавляют Basic Authorization:
1. Скрипт проверки и обновления всех .htaccess для сайтов, которые работают на веб-сервере Apache. Если нет правила для блокировки, то оно дописывается
2. Скрипт проверки конфигов для хостов, работающих на веб-сервере nginx. Аналогично первому пункту следит и добавляет авторизацию
3. Скрипт генерации нового пароля каждый месяц. Это защита от сторонних пользователей
4. Ежедневно пингуются все тестовые сайты и проверяется код ответа http. Если код отличается от 401го(Unauthorized), то телеграм бот присылает в общую группу уведомление со списком таких доменов
❗️P.S. Авторизация бесючая, но способ стопроцентный – сайт точно будет закрыт. Главное не забыть про исключения для IP-адресов, где не использовать авторизацию: рабочий для удобства и серверный, для запросов к api.
❗️P.P.S. Скрипты не выкладываю, их оформить сперва нужно. Если будет интерес, то соберу через неделю-две.
#Кейсы
📖 Любая адекватная разработка ведется отдельно от рабочего сайта. Прежде, чем запустить новый проект или доработки по существующему, проходит ряд проверок и утверждений на тестовых площадках. Чтобы корректно отладить все доработки, тестовый сайт должен быть максимально идентичен рабочему. В том числе и по контенту.
Тестовые площадки посещают еще и заказчики, поэтому сайты и сервисы доступны за пределами локальной сети. Это проблема, ведь поисковые роботы шастают там, где их не ждут. И тесты попадают в поиск, снижая поисковый вес рабочему сайту.
В мануалах гугла и яндекса пишут и утверждают, что поисковых роботов можно блокировать через robots.txt или мета-теги noindex. Но это не всегда так, проверено уже. К тому же, robot.txt или noindex нужно игнорировать в репозитории, чтобы они не попали на боевой и не натворили дел. За этим сложно уследить, особенно если много проектов в работе и на каждом проходят регулярные релизы.
📌 Чтобы без лишних проблем и наверняка заблокировать все тестовые сайты, мы написали несколько скриптов, которые проверяют наличие и добавляют Basic Authorization:
1. Скрипт проверки и обновления всех .htaccess для сайтов, которые работают на веб-сервере Apache. Если нет правила для блокировки, то оно дописывается
2. Скрипт проверки конфигов для хостов, работающих на веб-сервере nginx. Аналогично первому пункту следит и добавляет авторизацию
3. Скрипт генерации нового пароля каждый месяц. Это защита от сторонних пользователей
4. Ежедневно пингуются все тестовые сайты и проверяется код ответа http. Если код отличается от 401го(Unauthorized), то телеграм бот присылает в общую группу уведомление со списком таких доменов
❗️P.S. Авторизация бесючая, но способ стопроцентный – сайт точно будет закрыт. Главное не забыть про исключения для IP-адресов, где не использовать авторизацию: рабочий для удобства и серверный, для запросов к api.
❗️P.P.S. Скрипты не выкладываю, их оформить сперва нужно. Если будет интерес, то соберу через неделю-две.
#Кейсы
❤4
Массовая оптимизация картинок сервисом TinyPNG
📖 Оптимизация изображений для веба – это один из важных шагов ускорения работы сайта или сервиса. Динамические картинки, которые добавляются через админку, должны обрабатываться бекендом в момент их добавления. Но кроме динамики, часто на страницах используется и статика. Под сборки верстальщиков есть много плагинов, которые выполняют оптимизацию изображений, но они все уступают профессиональным программам и сервисам. Мы много перепробовали различных вариантов и самым идеальным для себя выбрали TinyPNG. Качество изображений совсем не страдает, а уровень оптимизации удивляет – часто картинки удается сжать на 60-75% по весу.
У сервиса есть ряд ограничений. Через веб-интерфейс одновременно можно сжать не более 20 картинок, а один файл не может превышать 5мб. Но если обращаться по api к сервису, то таких лимитов нет. Бесплатное ограничение на использование api составляет 500 обработок в месяц. Этого хватает, если каждый дизайнер и верстальщик использует свой индивидуальный аккаунт (api key).
Чтобы было удобней пользоваться сервисом по апи, набросали скрипт на go lang и скомпилировали его под Windows и MacOs. Теперь пользоваться сервисом TinyPNG стало в разы быстрей и удобней, приложение за счет многопоточности go lang, параллельно обрабатывает всю пачку картинок. Так же приложение не ломает структуру папок, если картинки разложены по разным директориям. Достаточно перенести все папки с изображениями в служебную директорию input, запустить скрипт и забрать такую же структуру папок и файлов из output-а.
📌 Подробная инструкция по использования готового приложения у нас собрана с описаниями и скринами в ридми открытого репозитория: README.md.
Так же открыли и исходники, если кто-то решит доработать приложение под свои нужны: репозиторий.
❗️P.S. В конфиге тестовый ключ от TinyPNG, он бесплатный – лимит 500 обращений в месяц. Сильно не балуйтесь, это для тестов и посмотреть, как работает приложение. Перед использованием нужно создать личный ключ.
#НашиРазработки
📖 Оптимизация изображений для веба – это один из важных шагов ускорения работы сайта или сервиса. Динамические картинки, которые добавляются через админку, должны обрабатываться бекендом в момент их добавления. Но кроме динамики, часто на страницах используется и статика. Под сборки верстальщиков есть много плагинов, которые выполняют оптимизацию изображений, но они все уступают профессиональным программам и сервисам. Мы много перепробовали различных вариантов и самым идеальным для себя выбрали TinyPNG. Качество изображений совсем не страдает, а уровень оптимизации удивляет – часто картинки удается сжать на 60-75% по весу.
У сервиса есть ряд ограничений. Через веб-интерфейс одновременно можно сжать не более 20 картинок, а один файл не может превышать 5мб. Но если обращаться по api к сервису, то таких лимитов нет. Бесплатное ограничение на использование api составляет 500 обработок в месяц. Этого хватает, если каждый дизайнер и верстальщик использует свой индивидуальный аккаунт (api key).
Чтобы было удобней пользоваться сервисом по апи, набросали скрипт на go lang и скомпилировали его под Windows и MacOs. Теперь пользоваться сервисом TinyPNG стало в разы быстрей и удобней, приложение за счет многопоточности go lang, параллельно обрабатывает всю пачку картинок. Так же приложение не ломает структуру папок, если картинки разложены по разным директориям. Достаточно перенести все папки с изображениями в служебную директорию input, запустить скрипт и забрать такую же структуру папок и файлов из output-а.
📌 Подробная инструкция по использования готового приложения у нас собрана с описаниями и скринами в ридми открытого репозитория: README.md.
Так же открыли и исходники, если кто-то решит доработать приложение под свои нужны: репозиторий.
❗️P.S. В конфиге тестовый ключ от TinyPNG, он бесплатный – лимит 500 обращений в месяц. Сильно не балуйтесь, это для тестов и посмотреть, как работает приложение. Перед использованием нужно создать личный ключ.
#НашиРазработки
👍5
Оптимизация видео под Web
📖 В продолжение темы прошлого поста, займемся еще немного оптимизацией. На этот раз обработаем видео, чтобы работало шустрей на страницах сайта. В первую очередь, чтобы ролик вообще работал, он должен иметь формат mp4 – этот формат поддерживается всеми браузерами, как десктопными, так и мобильными. Далее можно порезать вес файла за счет уменьшения его размера до 720, на страницах сайтов этого более, чем достаточно. И еще по мелочам можно сэкономить веса: уменьшить битрейт звуковой дорожки, вырезать лишние кадры и немного пожать качество видео.
Все вышеописанные манипуляции легко выполнять с помощью FFmpeg – это мощный инструмент для работы с аудио и видео файлами. С его помощью можно легко и быстро обработать файлы. FFmpeg кроссплатформенный, что позволяет использовать этот пакет библиотек как на серверах с ОС linux, так и на любом рабочем компьютере с windows или macOs. Все действия можно выполнять из консоли, далее приведен пример запроса и расшифрованы все его куски.
📌 Команда с пример обработки видео input.avi, на выходе получится оптимизированный файл output.mp4:
– разрешаем перезаписывать выходные файлы, если такой уже существует: -y
– заменяем аудио кодек: -acodec aac
– уменьшаем битрейт звука до 128 кбит/с: -b:v 128K
– ресайзим до 720 по ширине, высота пропорционально расчитывается. Тут важно, чтобы были четные значения, иначе ffmpeg не сможет сделать ресайз: -filter:v scale=-2:720
– Уменьшаем fps до 24 кадров: -r 24
– Задаем контроль качества виодео на середине (30 из 51 возможных): -crf 30
– И переносим мета-данные в начало видео, для ускорения прогрузки первых кадров: -movflags +faststart
#БазаЗнаний
📖 В продолжение темы прошлого поста, займемся еще немного оптимизацией. На этот раз обработаем видео, чтобы работало шустрей на страницах сайта. В первую очередь, чтобы ролик вообще работал, он должен иметь формат mp4 – этот формат поддерживается всеми браузерами, как десктопными, так и мобильными. Далее можно порезать вес файла за счет уменьшения его размера до 720, на страницах сайтов этого более, чем достаточно. И еще по мелочам можно сэкономить веса: уменьшить битрейт звуковой дорожки, вырезать лишние кадры и немного пожать качество видео.
Все вышеописанные манипуляции легко выполнять с помощью FFmpeg – это мощный инструмент для работы с аудио и видео файлами. С его помощью можно легко и быстро обработать файлы. FFmpeg кроссплатформенный, что позволяет использовать этот пакет библиотек как на серверах с ОС linux, так и на любом рабочем компьютере с windows или macOs. Все действия можно выполнять из консоли, далее приведен пример запроса и расшифрованы все его куски.
📌 Команда с пример обработки видео input.avi, на выходе получится оптимизированный файл output.mp4:
ffmpeg -y -i input.avi -filter:v scale=-2:720 -acodec aac -b:v 128K -q:v 10 -r:v 24 -crf 30 -movflags +faststart output.mp4📌 Расшифровка модификаторов команды:
– разрешаем перезаписывать выходные файлы, если такой уже существует: -y
– заменяем аудио кодек: -acodec aac
– уменьшаем битрейт звука до 128 кбит/с: -b:v 128K
– ресайзим до 720 по ширине, высота пропорционально расчитывается. Тут важно, чтобы были четные значения, иначе ffmpeg не сможет сделать ресайз: -filter:v scale=-2:720
– Уменьшаем fps до 24 кадров: -r 24
– Задаем контроль качества виодео на середине (30 из 51 возможных): -crf 30
– И переносим мета-данные в начало видео, для ускорения прогрузки первых кадров: -movflags +faststart
#БазаЗнаний
👍5🔥1
БАГодельня
Оптимизация видео под Web 📖 В продолжение темы прошлого поста, займемся еще немного оптимизацией. На этот раз обработаем видео, чтобы работало шустрей на страницах сайта. В первую очередь, чтобы ролик вообще работал, он должен иметь формат mp4 – этот формат…
Опубликовать приложение(под win и mac) с инструкцией для автоматической оптимизации видео под web(прошлый пост)?
Anonymous Poll
53%
Да, а то в консоле неудобно
21%
Нет, я и в консоле справляюсь
26%
Я не пользуюсь оптимизацией видео
Четырехбайтовые символы в базе данных MySQL
📖 В 2017 году, я впервые столкнулся с проблемой хранения эмодзи в базе данных, даже статью про это писал: ссылка. Тогда набор смайликов был совсем небольшим – грустные и веселые мордочки, сейчас же их словарь ощутимо пополнился. И встретить такие символы (да, это символы) можно почти везде.
Особенно часто эмодзи встречаются в соц.сетях, в том числе и телеграм. На скрине ошибка, которую поймали в телеграмовском боте, его только запустили и находится в режиме тестового запуска. Прозевали и не проверили кодировку соединения с базой данных. В самой БД, таблицах и полях корректная кодировка – utf8mb4. Но коннект в коде не обработан, по умолчанию соединение с MySql использует utf8. Ошибку выловили и исправили быстро, но пользователь понервничал, не мог запустить бота.
Обычные символы из алфавита имеют 3-х байтовую кодировку, а эмодзи уже не помещается, ему нужно 4 байта. Соответственно utf8, который работает только с 3-байтовыми символами, уже не справляется.
🔴 Важно проверять данные, которые приходят на бекенд. Должна быть валидация, как значений, так и их формата. Например, если экранировать эмодзи, то и в таблицу с кодировкой utf8 можно записать данные.
🔴 Но лучше не ограничивать пользователей в наборе символов и при работе с соц.сетями, комментариями и другими полями, где доступны эмодзи, нужно это учитывать и использовать кодировку utf8mb4.
#КодРевью
📖 В 2017 году, я впервые столкнулся с проблемой хранения эмодзи в базе данных, даже статью про это писал: ссылка. Тогда набор смайликов был совсем небольшим – грустные и веселые мордочки, сейчас же их словарь ощутимо пополнился. И встретить такие символы (да, это символы) можно почти везде.
Особенно часто эмодзи встречаются в соц.сетях, в том числе и телеграм. На скрине ошибка, которую поймали в телеграмовском боте, его только запустили и находится в режиме тестового запуска. Прозевали и не проверили кодировку соединения с базой данных. В самой БД, таблицах и полях корректная кодировка – utf8mb4. Но коннект в коде не обработан, по умолчанию соединение с MySql использует utf8. Ошибку выловили и исправили быстро, но пользователь понервничал, не мог запустить бота.
Обычные символы из алфавита имеют 3-х байтовую кодировку, а эмодзи уже не помещается, ему нужно 4 байта. Соответственно utf8, который работает только с 3-байтовыми символами, уже не справляется.
🔴 Важно проверять данные, которые приходят на бекенд. Должна быть валидация, как значений, так и их формата. Например, если экранировать эмодзи, то и в таблицу с кодировкой utf8 можно записать данные.
🔴 Но лучше не ограничивать пользователей в наборе символов и при работе с соц.сетями, комментариями и другими полями, где доступны эмодзи, нужно это учитывать и использовать кодировку utf8mb4.
#КодРевью
👍5
Пиздосометр – измеритель уровня пиз*еца
📖 Каждый год в 256-й день отмечается «День программиста». В этот раз празднование выпало на 13 сентября, сегодня. И в такую знаменательную дату хочется рассказать что-то веселое из жизни разработчиков. Делиться рабочими моментами не так весело, как «факультативными» проделками, и одна из таких – устройство «Пиздосометр». Это история про то, как мы уже почти год пытаемся оцифровать уровень пиз*еца в офисе.
[…]
📌 Cтатья получилась большая и не влезает в одну запись телеграма. Полный текст с фото и видео можно прочитать и посмотреть на VC: ссылка на полную статью.
[…]
Поздравляю всех с «Днем программиста», желаю не отчаиваться и не опускать руки. Если долго мучаться, то что-нибудь обязательно получится или подвернется счастливый случай!
❗️P.S. Присылайте свои идеи, как можно оцифровать уровень пиздеца. Предложения можно писать в комментарии или мне в личку. Вдруг всем миром, все-таки придумаем идеальные параметры оценки и запустим автоматическую версию девайса, чтобы он сам начала шевелить стрелкой, опираясь на максимально релевантные показатели!
#Юмор #Статьи
📖 Каждый год в 256-й день отмечается «День программиста». В этот раз празднование выпало на 13 сентября, сегодня. И в такую знаменательную дату хочется рассказать что-то веселое из жизни разработчиков. Делиться рабочими моментами не так весело, как «факультативными» проделками, и одна из таких – устройство «Пиздосометр». Это история про то, как мы уже почти год пытаемся оцифровать уровень пиз*еца в офисе.
[…]
📌 Cтатья получилась большая и не влезает в одну запись телеграма. Полный текст с фото и видео можно прочитать и посмотреть на VC: ссылка на полную статью.
[…]
Поздравляю всех с «Днем программиста», желаю не отчаиваться и не опускать руки. Если долго мучаться, то что-нибудь обязательно получится или подвернется счастливый случай!
❗️P.S. Присылайте свои идеи, как можно оцифровать уровень пиздеца. Предложения можно писать в комментарии или мне в личку. Вдруг всем миром, все-таки придумаем идеальные параметры оценки и запустим автоматическую версию девайса, чтобы он сам начала шевелить стрелкой, опираясь на максимально релевантные показатели!
#Юмор #Статьи
👍6😁2
Мониторинг бекапов
📖 Работает сайт месяц, второй, год. Все хорошо, контент пополняется, фичи добавляются. Работает и проблем нет. Логи пишутся, коммиты пушатся, бекапы создаются. А потом бац и все упало – хостинг умер или жесткий диск на сервере; ну или что-то более реальное: релиз выпустили, а он вместо того, чтобы покрасить кнопку, снес папку с контентом, которая без контроля версий; или таблица в базе данных не так обновилась и вместо добавления нового поля, все записи перепутались. Бывает.
Не беда, у нас есть бекапы, сейчас достанем контентную потеряшку, да и записи в таблице БД восстановим. Тээкс, а бекапы-то мертвые. Архивы с файлами битые, дампы уже 3 недели не актуализировались. Что за дела? Место на хостинге закончилось пару недель назад и не удается создать корректный архив, а крон исправно дергает скрипты в попытках создать резервные файлы. Вроде, и логи добавлялись на бекапы, но кто их смотрит, когда все хорошо? Вот сейчас залез, глянул – ага, ошибка создания архива из-за нехватки места.
📖 Ситуация гипотетическая, но обязательно случится, если не контролировать скрипты. Просто записи логов мало, проверять их ежедневно никто не будет. А если проектов много, то можно весь день только и заниматься, что проверкой выполнения автоматизированных скриптов. Нужны уведомления со статусом отработавших скриптов. В идеале сгруппированные в один отчет. И слать нужно на видное место. Почта не подходит – пробовали, через неделю уже на автомате начинаешь удалять письма, даже не открывая. Идеальный вариант – это телеграм, причем в общий чат со всеми разработчиками. Так точно не потеряется. И хорошо, когда отчет визуализирован, поскольку текст можно пропустить, не прочитав. Достаточно вывести зеленую эмодзи, когда все в порядке, а красную при ошибке. На скрине пример отчета по нашим ночным бекапам, который приходит от бота каждое утро. Можно не читать весь список, если он «зеленый», в таком случае все проекты сохранены за ночь и сегодня можно безобразничать – сносить базы и выполнять rm -rf в любой папке.
#Мысли
📖 Работает сайт месяц, второй, год. Все хорошо, контент пополняется, фичи добавляются. Работает и проблем нет. Логи пишутся, коммиты пушатся, бекапы создаются. А потом бац и все упало – хостинг умер или жесткий диск на сервере; ну или что-то более реальное: релиз выпустили, а он вместо того, чтобы покрасить кнопку, снес папку с контентом, которая без контроля версий; или таблица в базе данных не так обновилась и вместо добавления нового поля, все записи перепутались. Бывает.
Не беда, у нас есть бекапы, сейчас достанем контентную потеряшку, да и записи в таблице БД восстановим. Тээкс, а бекапы-то мертвые. Архивы с файлами битые, дампы уже 3 недели не актуализировались. Что за дела? Место на хостинге закончилось пару недель назад и не удается создать корректный архив, а крон исправно дергает скрипты в попытках создать резервные файлы. Вроде, и логи добавлялись на бекапы, но кто их смотрит, когда все хорошо? Вот сейчас залез, глянул – ага, ошибка создания архива из-за нехватки места.
📖 Ситуация гипотетическая, но обязательно случится, если не контролировать скрипты. Просто записи логов мало, проверять их ежедневно никто не будет. А если проектов много, то можно весь день только и заниматься, что проверкой выполнения автоматизированных скриптов. Нужны уведомления со статусом отработавших скриптов. В идеале сгруппированные в один отчет. И слать нужно на видное место. Почта не подходит – пробовали, через неделю уже на автомате начинаешь удалять письма, даже не открывая. Идеальный вариант – это телеграм, причем в общий чат со всеми разработчиками. Так точно не потеряется. И хорошо, когда отчет визуализирован, поскольку текст можно пропустить, не прочитав. Достаточно вывести зеленую эмодзи, когда все в порядке, а красную при ошибке. На скрине пример отчета по нашим ночным бекапам, который приходит от бота каждое утро. Можно не читать весь список, если он «зеленый», в таком случае все проекты сохранены за ночь и сегодня можно безобразничать – сносить базы и выполнять rm -rf в любой папке.
#Мысли
👍9
CSS, который «убивает» браузер
📖 Вспомнил старый код, который попался в прошлом году, во время проверки тестового задания. Случай интересный и очень показательный. Это не логика, а верстка. Причем просто статика, без js-фреймворков. Но статика настолько занятная, что я не поленился откопать архив с исходниками, чтобы сделать скрины для поста. На скриншоте видна нагрузка – потребление ресурсов центрального процессора(ЦП) и графического процессор(ГП). Скрины с MacBook Air на M1 – шустрый компьютер, если не запускать ничего тяжелого, то нагрузка не поднимается выше 20-25%. А тут статичная страница просто при загрузке стала отъедать 70-100% всех ресурсов.
Первый раз открыв страницу, браузер подвис на 1-2 секунды. Сперва не понял, что случилось. Перезагрузил. Лаги повторилось. Полезли разбираться в чем дело и наткнулись на стиль с восемью тенями(drop-shadow) в одном фильтре(filter).
🔴 Тени очень требовательны к ресурсам. А когда их добавляется сразу десяток на один элемент, процессору становится очень тяжело все это дело просчитать и отрисовать. Такой набор drop-shadow появился не просто так в стилях. Это скопировано из фигмы. Дизайнеры, чтобы добиться идеальной тени, накладывают их целую стопку, каждую под своим углом и разной интенсивности. Выглядит красиво, но процессору такое не нравится. Пользователям сайта, думаю, тоже не очень приятно ловить заморозку браузера на несколько секунд. Нужно все эти тени собрать в одну, другого хорошего решения нет.
Можно добавить стиль transform-style: preserve-3d для аппаратного ускорения, но это не спасет от 8 теней, браузер все равно будет зависать, слишком много математики.
🔴 Вредный совет. Чтобы окончательно «убить» браузер можно еще добавить анимацию для блока с тенями, тогда процессору придется без остановки просчитывать отображение. Такого же эффекта можно добиться, если сделать подложку с видео – динамическое изображение под тенью. Ну или добавить еще сверху блюр(filter: blur), такой фильтр тоже просчитывается очень долго и требовательный к ресурсам.
#КодРевью
📖 Вспомнил старый код, который попался в прошлом году, во время проверки тестового задания. Случай интересный и очень показательный. Это не логика, а верстка. Причем просто статика, без js-фреймворков. Но статика настолько занятная, что я не поленился откопать архив с исходниками, чтобы сделать скрины для поста. На скриншоте видна нагрузка – потребление ресурсов центрального процессора(ЦП) и графического процессор(ГП). Скрины с MacBook Air на M1 – шустрый компьютер, если не запускать ничего тяжелого, то нагрузка не поднимается выше 20-25%. А тут статичная страница просто при загрузке стала отъедать 70-100% всех ресурсов.
Первый раз открыв страницу, браузер подвис на 1-2 секунды. Сперва не понял, что случилось. Перезагрузил. Лаги повторилось. Полезли разбираться в чем дело и наткнулись на стиль с восемью тенями(drop-shadow) в одном фильтре(filter).
🔴 Тени очень требовательны к ресурсам. А когда их добавляется сразу десяток на один элемент, процессору становится очень тяжело все это дело просчитать и отрисовать. Такой набор drop-shadow появился не просто так в стилях. Это скопировано из фигмы. Дизайнеры, чтобы добиться идеальной тени, накладывают их целую стопку, каждую под своим углом и разной интенсивности. Выглядит красиво, но процессору такое не нравится. Пользователям сайта, думаю, тоже не очень приятно ловить заморозку браузера на несколько секунд. Нужно все эти тени собрать в одну, другого хорошего решения нет.
Можно добавить стиль transform-style: preserve-3d для аппаратного ускорения, но это не спасет от 8 теней, браузер все равно будет зависать, слишком много математики.
🔴 Вредный совет. Чтобы окончательно «убить» браузер можно еще добавить анимацию для блока с тенями, тогда процессору придется без остановки просчитывать отображение. Такого же эффекта можно добиться, если сделать подложку с видео – динамическое изображение под тенью. Ну или добавить еще сверху блюр(filter: blur), такой фильтр тоже просчитывается очень долго и требовательный к ресурсам.
#КодРевью
👍16🔥1
Мониторинг почтовых форм
📖 На любом коммерческом сайте есть контакты и формы сбора лидов – контактов. Если утрировать и отбросить всю мишуру, то можно сказать, что сайты создаются только ради этих двух блоков. Поэтому очень важно держать эти инструменты всегда в рабочем состоянии. Если с контактами все понятно, достаточно поддерживать их актуальность, то с формами сложней. Они могут быть сильно разные по функционалу и запись лидов там тоже разная. Начиная от письма на почту, заканчивая сделкой в CRM. Серьезные интеграции не всегда оправданы и зачастую даже больше организации останавливаются на приеме заявок по email.
В итоге мы имеем большое количество сайтов, где по разным страницам разнесены формы сбора контактов, уведомления с которых отправляются на email. Но почтовые отправки не стабильные, есть ряд причин, по которым письма могут перестать отправляться менеджерам: сервер попадают в бан, smtp сбоит или меняются настройки, банально не оплачен smtp и тд. Все эти проблемы решаемы, но их сложно вовремя заметить.
📌 Чтобы своевременно реагировать на проблему, мы написали скрипт, который проверят внутренний почтовый ящик на наличие писем. Сам же почтовый ящик-мониторинг добавляем в копию получателей для каждой формы, нуждающейся в проверке. То есть мы не надеемся на условия ответа smtp или простого mail. Это может быть ложный статус, если письмо принял smtp-сервер, но не отправил из-за внутренних проблем или попадания в спам.
Скрипт мониторинга каждый час подключается к почтовому сервису по IMAP-протоколу, проверяет наличие новых писем и делает их выборку по маске в теме: «Название сайта – имя формы». Дальше дело техники – посчитать письма и записать данные в БД с разбивкой по доменам и названиям форм. А чтобы держать руку на пульсе, каждое утро собираем и отправляем отчет ботом себе в телеграм, примеры на скрине. Нам достаточно двух уведомлений: отчет по формам за вчерашний день и сводка по сайтам/формам, с которых уже три дня не приходили письма, это повод проверить форму на работоспособность.
#Кейсы
📖 На любом коммерческом сайте есть контакты и формы сбора лидов – контактов. Если утрировать и отбросить всю мишуру, то можно сказать, что сайты создаются только ради этих двух блоков. Поэтому очень важно держать эти инструменты всегда в рабочем состоянии. Если с контактами все понятно, достаточно поддерживать их актуальность, то с формами сложней. Они могут быть сильно разные по функционалу и запись лидов там тоже разная. Начиная от письма на почту, заканчивая сделкой в CRM. Серьезные интеграции не всегда оправданы и зачастую даже больше организации останавливаются на приеме заявок по email.
В итоге мы имеем большое количество сайтов, где по разным страницам разнесены формы сбора контактов, уведомления с которых отправляются на email. Но почтовые отправки не стабильные, есть ряд причин, по которым письма могут перестать отправляться менеджерам: сервер попадают в бан, smtp сбоит или меняются настройки, банально не оплачен smtp и тд. Все эти проблемы решаемы, но их сложно вовремя заметить.
📌 Чтобы своевременно реагировать на проблему, мы написали скрипт, который проверят внутренний почтовый ящик на наличие писем. Сам же почтовый ящик-мониторинг добавляем в копию получателей для каждой формы, нуждающейся в проверке. То есть мы не надеемся на условия ответа smtp или простого mail. Это может быть ложный статус, если письмо принял smtp-сервер, но не отправил из-за внутренних проблем или попадания в спам.
Скрипт мониторинга каждый час подключается к почтовому сервису по IMAP-протоколу, проверяет наличие новых писем и делает их выборку по маске в теме: «Название сайта – имя формы». Дальше дело техники – посчитать письма и записать данные в БД с разбивкой по доменам и названиям форм. А чтобы держать руку на пульсе, каждое утро собираем и отправляем отчет ботом себе в телеграм, примеры на скрине. Нам достаточно двух уведомлений: отчет по формам за вчерашний день и сводка по сайтам/формам, с которых уже три дня не приходили письма, это повод проверить форму на работоспособность.
#Кейсы
👍4🔥1
Плагин для Google Chrome, который определяет уникальный css-селектор
📖 У нас в команде не только разработчики, но и маркетологи и дизайнеры. Им тоже иногда требуется подмога с автоматизацией. Хочу поделиться одной из таких наработок. Дизайнеры, кроме макетов, частенько собирают сайты на конструкторе Tilda. Удобный инструмент для создания промо-лендингов, которые нужно быстро запустить. Если не брать готовые шаблоны, а собирать страницу «руками», то получаются красивые решения. Но кастомная сборка зачастую ведет к тому, что нужно дописывать css и js, готовых блоков и настроек не всегда хватает в таких случаях. Тильда – это конструктор, поэтому все селекторы элементов там сгенерированные, в консоле браузера сложно найти уникальный или наоборот такой, чтобы применить стили ко всем похожим блокам. Чтобы упростить жизнь дизайнерам, мы написали небольшой плагин для браузера Chrome.
Плагин можно активировать на любой странице и по аналогии с инспектором консоли разработчика, по наведению на блоки, те подсвечиваются и показывают похожие. Так же добавили в контекстное меню возможность сразу скопировать селектор в нескольких вариациях: уникальный, для всех похожих элементов внутри блока и для всех похожих на странице. На скриншоте пример, как подсвечиваются элементы и каким образом копируются селекторы. И бонусом появляется плашка с расшифровками, где указано название элемента, сколько подобных элементов внутри блока и всего на странице.
📌 Установка:
– Скачать плагин: ссылка
– Скачать и распаковать архив
– Перейти в плагины хрома, можно по ссылке: chrome://extensions/
– Нажать «Загрузить распакованное расширение» и выбрать папку куда распаковался архив
– Можно закрепить плагин в браузере, чтобы было удобней пользоваться
📌 Использование:
– После активации плагина, по ховеру на элемент, появляется плашка с информацией о селекторе. Похожие элементы подсветятся на странице
– Кликом правой кнопкой мыши, вызывается контекстное меню, в котором можно скопировать в буфер обмена нужный селектор
#НашиРазработки
📖 У нас в команде не только разработчики, но и маркетологи и дизайнеры. Им тоже иногда требуется подмога с автоматизацией. Хочу поделиться одной из таких наработок. Дизайнеры, кроме макетов, частенько собирают сайты на конструкторе Tilda. Удобный инструмент для создания промо-лендингов, которые нужно быстро запустить. Если не брать готовые шаблоны, а собирать страницу «руками», то получаются красивые решения. Но кастомная сборка зачастую ведет к тому, что нужно дописывать css и js, готовых блоков и настроек не всегда хватает в таких случаях. Тильда – это конструктор, поэтому все селекторы элементов там сгенерированные, в консоле браузера сложно найти уникальный или наоборот такой, чтобы применить стили ко всем похожим блокам. Чтобы упростить жизнь дизайнерам, мы написали небольшой плагин для браузера Chrome.
Плагин можно активировать на любой странице и по аналогии с инспектором консоли разработчика, по наведению на блоки, те подсвечиваются и показывают похожие. Так же добавили в контекстное меню возможность сразу скопировать селектор в нескольких вариациях: уникальный, для всех похожих элементов внутри блока и для всех похожих на странице. На скриншоте пример, как подсвечиваются элементы и каким образом копируются селекторы. И бонусом появляется плашка с расшифровками, где указано название элемента, сколько подобных элементов внутри блока и всего на странице.
📌 Установка:
– Скачать плагин: ссылка
– Скачать и распаковать архив
– Перейти в плагины хрома, можно по ссылке: chrome://extensions/
– Нажать «Загрузить распакованное расширение» и выбрать папку куда распаковался архив
– Можно закрепить плагин в браузере, чтобы было удобней пользоваться
📌 Использование:
– После активации плагина, по ховеру на элемент, появляется плашка с информацией о селекторе. Похожие элементы подсветятся на странице
– Кликом правой кнопкой мыши, вызывается контекстное меню, в котором можно скопировать в буфер обмена нужный селектор
#НашиРазработки
👍6
Автоматическая установка SSL-сертификата Let’s Encrypt
📖 Что такое SSL и защищенное https-соединение никому не нужно рассказывать, это давно стало обязательным для сайтов и сервисов. Но, как автоматически установить сертификат, можно показать, поскольку есть много способов. Расскажу про тот, которым мы пользуемся для всех тестовых сайтов и некоторых клиентских, где не критично применять бесплатные сертификаты. Не всем нужен платный SSL с подтверждением организации (OV или EV).
Большинство хостингов предоставляют возможность установить бесплатный Let’s Encrypt из панели управления. Но если пользоваться VPS, VDS или выделенным сервером, то все настройки нужно выполнять «руками», в том числе и по настройке сертификатов. Самый простой вариант – это сходить на сайт Let’s Encrypt, подтвердить домен, получить ключи сертификатов и установить их. Такой сертификат живет 3 месяца, потом все по новой.
Чтобы не мучаться в ручном режиме, можно автоматизировать процесс с помощью Certbot – бесплатный сервис. Официальный сайт с инструкциями тут. Установку под каждую операционку и веб-сервер рассказывать не буду, на сайте есть. Показываю на примере веб-сервера nginx и ОС Ubuntu.
📌 Установка certbot:
– Устанавливаем snap:
Вызываем certbot командой:
Далее запустится установка, где нужно выбрать домен, для которого сгенерируется и настроится сертификат – на скрине пример. Все остальное проходит в автоматическом режиме.
Перевыпуск сертификатов:
#БазаЗнаний
📖 Что такое SSL и защищенное https-соединение никому не нужно рассказывать, это давно стало обязательным для сайтов и сервисов. Но, как автоматически установить сертификат, можно показать, поскольку есть много способов. Расскажу про тот, которым мы пользуемся для всех тестовых сайтов и некоторых клиентских, где не критично применять бесплатные сертификаты. Не всем нужен платный SSL с подтверждением организации (OV или EV).
Большинство хостингов предоставляют возможность установить бесплатный Let’s Encrypt из панели управления. Но если пользоваться VPS, VDS или выделенным сервером, то все настройки нужно выполнять «руками», в том числе и по настройке сертификатов. Самый простой вариант – это сходить на сайт Let’s Encrypt, подтвердить домен, получить ключи сертификатов и установить их. Такой сертификат живет 3 месяца, потом все по новой.
Чтобы не мучаться в ручном режиме, можно автоматизировать процесс с помощью Certbot – бесплатный сервис. Официальный сайт с инструкциями тут. Установку под каждую операционку и веб-сервер рассказывать не буду, на сайте есть. Показываю на примере веб-сервера nginx и ОС Ubuntu.
📌 Установка certbot:
– Устанавливаем snap:
sudo apt install snapd
– Устанавливаем certbot: sudo snap install --classic certbot
– Добавляем симлинк: sudo ln -s /snap/bin/certbot /usr/bin/certbot
📌 Использование:Вызываем certbot командой:
sudo certbot --nginx. Далее запустится установка, где нужно выбрать домен, для которого сгенерируется и настроится сертификат – на скрине пример. Все остальное проходит в автоматическом режиме.
Перевыпуск сертификатов:
sudo certbot renew --dry-run
❗️После установки сертификата, certbot предлагает добавить редирект с http на https в конфиге веб-сервера. Это тоже удобно, можно использовать. А самое главное, что все установленные сертификаты, будут автоматически продлеваться без нашего участия. Certbot висит на кроне и сам следит, когда нужно перегенерировать сертификаты.#БазаЗнаний
👍9
Code review. Длинное и непонятное условие
📖 В этот раз пост с тремя картинками – первая реализация кода и два варианта исправления. По-другому не влезает исходный и переработанные варианты кода.
Код обрабатывает запрос, который должен содержать 10 параметров и каждый из них обязательный. Но в запросе, кроме этого десятка, могут быть еще не обязательные, которые обрабатываются дальше по логике. Первично нужно проверить наличие всего набора обязательных свойств и если чего-то не хватает, то сразу забраковать данные.
Делая впопыхах или на второй день без сна, появилось решение с первой картинки, где просто внутри одного if собраны десять проверок. Это рабочий код, но совсем не читаемый и не поддающийся нормальному расширению.
🟢 Хорошо, что в коде есть комментарий TODO и признание в том, что код не самый лучший. ТуДу-комментарии полезные, всегда к ним можно вернуться и довести до ума, особенно если предполагается, что будет выделено время на рефакторинг или доработку конкретного участка.
🔴 Плохо, что условие стало таким большим. Каждая дополнительная проверка внутри одного IF, серьезно усложняет понимание кода, а вероятность допустить ошибку возрастает. В идеале, не должно быть более 1-2 проверок, по аналогии с количеством параметров для функции. Но это субъективные представления о прекрасном, жестких правил не существует.
❗️Оба варианта переписанного и исправленного кода имеют в два раза больше строк. Но это никак не сказывается на читаемости и понимании. Логика очевидна и быстро считывается. А при необходимости можно легко поменять набор проверяемых параметров или расширить условия валидации.
#КодРевью
📖 В этот раз пост с тремя картинками – первая реализация кода и два варианта исправления. По-другому не влезает исходный и переработанные варианты кода.
Код обрабатывает запрос, который должен содержать 10 параметров и каждый из них обязательный. Но в запросе, кроме этого десятка, могут быть еще не обязательные, которые обрабатываются дальше по логике. Первично нужно проверить наличие всего набора обязательных свойств и если чего-то не хватает, то сразу забраковать данные.
Делая впопыхах или на второй день без сна, появилось решение с первой картинки, где просто внутри одного if собраны десять проверок. Это рабочий код, но совсем не читаемый и не поддающийся нормальному расширению.
🟢 Хорошо, что в коде есть комментарий TODO и признание в том, что код не самый лучший. ТуДу-комментарии полезные, всегда к ним можно вернуться и довести до ума, особенно если предполагается, что будет выделено время на рефакторинг или доработку конкретного участка.
🔴 Плохо, что условие стало таким большим. Каждая дополнительная проверка внутри одного IF, серьезно усложняет понимание кода, а вероятность допустить ошибку возрастает. В идеале, не должно быть более 1-2 проверок, по аналогии с количеством параметров для функции. Но это субъективные представления о прекрасном, жестких правил не существует.
❗️Оба варианта переписанного и исправленного кода имеют в два раза больше строк. Но это никак не сказывается на читаемости и понимании. Логика очевидна и быстро считывается. А при необходимости можно легко поменять набор проверяемых параметров или расширить условия валидации.
#КодРевью
👍3🥴1
Реклама от провайдера – первая встреча
Вспомнил историю, которая приключилась в 2018 году, она как раз в тему недавнего поста про установку SSL-сертификатов: пост тут.
Но я опять перегнул палку, получился не короткий пост-заметка, а статья на 7 тыс символов. Лимит телеграма 2 тыс символов на пост с картинкой или 4 тыс без нее.
Поэтому выкладываю полный пост на VC, вот ссылка: читать всю историю.
📖 Кусочек для затравки:
Решили выловить отображение рекламы, чтобы хоть как-то понять в чем дело. Расспросили все характеристики устройства, на котором смотрят сайт менеджеры клиента. У нас в офисе ни у кого подобных моделей нет. Начали мучать знакомых, один нашелся – скидываем ссылку, а там тоже полный порядок. Значит дело не в девайсе.
Что может быть еще? Пришла еще идея – вдруг вирус по геопозиции или ip определяет город и только там показывает рекламу. Заказчик из столицы, а мы в Брянске. Новая зацепка, продолжаем расследование и узнаем ip клиента. Вместе со скрином ip-шника нам досталась полная расшифровка интернет-соединения, на которой в том числе и провайдер указан – Ростелеком. Для проверки гипотезы объясняю клиенту как установить и включить VPN для смены ip. И вот оно, при подключении через VPN, все хорошо – рекламы нет. Снова лезем в исходники сайта и пытаемся найти хоть что-то связанное с ip или каким-то еще определением местоположения. Но ничего криминального нет. Тупик.
📌 Полный текст истории: почитать.
#Мысли
Вспомнил историю, которая приключилась в 2018 году, она как раз в тему недавнего поста про установку SSL-сертификатов: пост тут.
Но я опять перегнул палку, получился не короткий пост-заметка, а статья на 7 тыс символов. Лимит телеграма 2 тыс символов на пост с картинкой или 4 тыс без нее.
Поэтому выкладываю полный пост на VC, вот ссылка: читать всю историю.
📖 Кусочек для затравки:
Решили выловить отображение рекламы, чтобы хоть как-то понять в чем дело. Расспросили все характеристики устройства, на котором смотрят сайт менеджеры клиента. У нас в офисе ни у кого подобных моделей нет. Начали мучать знакомых, один нашелся – скидываем ссылку, а там тоже полный порядок. Значит дело не в девайсе.
Что может быть еще? Пришла еще идея – вдруг вирус по геопозиции или ip определяет город и только там показывает рекламу. Заказчик из столицы, а мы в Брянске. Новая зацепка, продолжаем расследование и узнаем ip клиента. Вместе со скрином ip-шника нам досталась полная расшифровка интернет-соединения, на которой в том числе и провайдер указан – Ростелеком. Для проверки гипотезы объясняю клиенту как установить и включить VPN для смены ip. И вот оно, при подключении через VPN, все хорошо – рекламы нет. Снова лезем в исходники сайта и пытаемся найти хоть что-то связанное с ip или каким-то еще определением местоположения. Но ничего криминального нет. Тупик.
📌 Полный текст истории: почитать.
#Мысли
👍5
Code Review. Запросы к БД в цикле
Этот кусок кода я проглядел, смержил и апнул на боевой. Код пробыл на рабочем сайте полтора месяца. Заметили его, когда начали заниматься оптимизацией и на одной странице оказалось полторы сотни лишних и одинаковых запросов.
🔴 При выводе списка, для каждой отдельной записи происходит запрос к таблице с пользователями и проверяются права доступа к списку. Это явно опечатка или спешка, а не умышленное построение цикла с одним и тем же одинаковым запросом. Но такой код – серьезный баг, расходуются лишние ресурсы и создается лаг времени ответа бекенда.
🟡 В идеале код стоит переписать: убрать их вьюхи запрос и перенести его глубже в логику – в модели. Во вьюхах нужно избегать запросов к БД и обработки данных. Логика не должна сюда попадать.
🟢 Это код вьюхи Laravel, в котором используется шаблонизатор Blade. Движок шаблонизатора позволяет использовать вставки php, но в документации об этом пишут, что только в крайних случаях. Поэтому лучше избегать такие вставки и пользоваться синтаксисом самого Blade.
#КодРевью
Этот кусок кода я проглядел, смержил и апнул на боевой. Код пробыл на рабочем сайте полтора месяца. Заметили его, когда начали заниматься оптимизацией и на одной странице оказалось полторы сотни лишних и одинаковых запросов.
🔴 При выводе списка, для каждой отдельной записи происходит запрос к таблице с пользователями и проверяются права доступа к списку. Это явно опечатка или спешка, а не умышленное построение цикла с одним и тем же одинаковым запросом. Но такой код – серьезный баг, расходуются лишние ресурсы и создается лаг времени ответа бекенда.
🟡 В идеале код стоит переписать: убрать их вьюхи запрос и перенести его глубже в логику – в модели. Во вьюхах нужно избегать запросов к БД и обработки данных. Логика не должна сюда попадать.
🟢 Это код вьюхи Laravel, в котором используется шаблонизатор Blade. Движок шаблонизатора позволяет использовать вставки php, но в документации об этом пишут, что только в крайних случаях. Поэтому лучше избегать такие вставки и пользоваться синтаксисом самого Blade.
#КодРевью
👍3