Можно было бы уже целую новую книжку прочитать (или еще один том Гарри Поттера) если бы люди перестали ныть о каком-то левом чуваке, который на их жизнь никак не влиял, а теперь уж точно никак не повлияет
Недавно я начал молоть и варить кофе сам. До этого я зачем-то пил растворимый и никогда он мне не нравился на все сто процентов, либо брал кофе в кофейнях и не понимал: неужели так мало кофеен, которые умеют варить кофе. Еще думал, как можно пить кофе без сахара, он же отвратительный. А иногда даже молоко/сливки не спасают. Еще хуже то, что все говорят о кофе машинах, каких-то мифических процессах, мол, шаг влево, шаг вправо - получится полное говнище, которое только и останется, что вылить в унитаз. Это все полная хуйня. Я просто решил попробовать - купил зерен и кемекс (тысяча рублей). Мелю зерна в блендере (!), по-варварски заливаю помол водой, как будто это чай какой-то или вообще суп. И что? Я уже месяц пью самый вкусный кофе из тех, что я когда-либо
Гит хуки? Хаха, как жаль, что вы написали эти бесполезные скрипты hooksPath = /dev/null И никакого мучения с принудительным линтингом и юнитами на коммит/пуш больше никогда Линт, форматирование, юниты и прочие вещи никогда не будут проходить за пару секунд, а поэтому нехер их гонять локально
Пиздец, больше всего меня бесит, когда люди читают какую-то новость, пересылают ее и пишут: "все, пиздец", "ууу кошмар". Зачастую эти новости не стоят выеденного яйца, 99.9% новостей - мусор и кликбейт, бОльшая часть новостей вообще никак не касается нашей жизни и не влияет на нас, какой страшной новость бы ни была. Особенно веселит, когда присылают какой-то очевидный высер какого-то ноунэйма, предложение о введении 0.00001% налога на длинну бороды. Это даже новостью считать нельзя.
Как за 5 минут понять, что сейчас происходит с приложением и работают ли критическими функции приложения в данный момент? Нужен инструмент, который визуально покажет работоспособность системы в целом, и его функций в частности. Работает ли тот или иной экран? А кнопка оплаты? А что со скоростью загрузки данных? Для этого уже существует инструмент - Grafana. По каждому приложению должен быть свой дашборд, а на нем - графики. На основе чего мы будем их строить? На основе метрик. Как мы будем их собирать? Мы же уже получаем информацию из логов и аналитики. Но логи обычно содержат довольно большое (излишнее) количество информации, а аналитика не всегда может ответить на вопрос "почему это не работает". В теории, метрики, аналитика и логи могут быть реализованы одной системой, но на деле все сложнее: Зачастую для отправки аналитики используется SDK, а для просмотра - дашборд провайдера услуг аналитики. Если все данные будут собираться в одной системе, это создает единую точку отказа. Все эти данные разные: Логи обычно содержат пояснительные сообщения и дополнительную информацию Аналитика - название события и данные, которые важны бизнесу Метрики (надежности) - название события и данные, отображающие работоспособность: время загрузки, присутствие контента для отрисовки, наличие ошибок Все эти данные могут отсылаться с разной частотой: Логи - на усмотрение разработчика, нечасто уделяется внимание частоте логгирования; Аналитика - при достижении условий для отправки события, частота - на усмотрение бизнеса; Метрики - настолько часто, насколько возможно и необходимо, но не чаще; Аналитика может отправляться либо приходить с задержкой. Логи и метрики должны быть доступны практически в режиме реального времени. Логи, метрики и аналитика не должны влиять друг на друга: Например, при достижении квоты аналитики, логи должны продолжать работать, и наоборот.
Логи являются обязательной частью любого проекта. Большинство разработчиков согласятся с тем, что логгирование должно быть. А логи об ошибках должны собираться автоматически. Но к логам надо подходить ответственно: маскировать персональные данные, писать информативные сообщения для разбора проблем. И это только часть вопросов, которые нужно решить. Я бы хотел подойти к этой проблеме с другой стороны. Представим, что у нас уже есть сервис, которым пользуются люди и там есть логгирование. Вот какие проблемы я вижу: * Логов будет много и очень много * 80% из логов - мусор и шум * Все логи не посмотреть * Смотреть и грепать логи - долго * Не всегда видно потерю логов * Имеют произвольный формат и данные * На них легко забить: как на покрытие логами, так и на их просмотр * Сбор ошибок и исключений в виде логов (а-ля Sentry) - не панацея Когда мы будем смотреть в эти логи? На дежурстве во время инцидента? Во время релиза? При разборе баг-репортов? Это очень редко. И исходя из вышеописанных проблем, не продуктивно. Логи нам нужны по двум разным причинам: 1. Есть проблема, о которой мы узнали извне: 1.1 При разборе баг-репорта мы знаем, что проблема реальна 1.1 При обращения в поддержку мы предполагаем, что пользователь скорее всего столкнулся с проблемой 2. Мы хотим убедиться, что проблем нет: 2.1 На дежурстве 2.2 Во время релиза Логи - практически единственный источник данных, на который мы можем положиться в первом случае. Без них никак. Но что, если бы мы могли находить сбои до обарщений в поддержку? Это бы позитивно повлияло на качество продукта. Почему бы не посмотреть в Sentry и посмотреть логи, которые отсылаются автоматически при возникновении ошибок? А как мы поймем, серьезная ли это ошибка или нет? Никак. В мире мобильной разработки существует такая метрика, как Crash-free: процент, который отображает, как часто приложение вылетает. Но что если у вас 99.9% пользователей crash-free, но они почему-то жалуются на ваш сервис? Это, несомненно, очень важная метрика, но она не покажет вам, что пользователи ждут загрузки контента по 30 секунд. Необходим инструмент, который сможет ответить на вопрос: испытывают ли пользователи трудности или нет? Как за 5 минут понять, что сейчас происходит с приложением и работают ли критическими функции приложения в данный момент?
Тяжело представить современный проект без сбора аналитики. И это реально важно, без этих данных невозможно понять: * какими функциями реально пользуются люди, а какими нет; * как именно пользователи используют наш продукт; * испытывают ли пользователи проблемы и как часто; Но бывает так, что аналитика собирается "для галочки": владелец продукта либо не смотрит на эти данные вовсе, либо никак не реагирует на них. Если аналитика не была продумана, имеет смысл обсудить это с владельцем продукта. И даже в том случае, если по какой-то причине, например нехватки времени, добавление аналитики не предполагается, как минимум стоит покрыть логами критичный функционал. Иначе в случае инцидента, либо при необходимости некуда будет смотреть. Есть случаи, когда проект покрыт аналитикой, данные присутствуют, бизнес исследует данные и принимает решения, но у разработчиков нет доступа к этим данным (при этом может быть доступ к логами). Я считаю это ошибкой, ведь при расследовании проблем эта информация может быть крайне полезной, и маловероятно, что разработка узнает что-то такое приватное, что не может узнать из логов. И это еще не все: владелец продукта может быть готов предоставить хотя бы частичную информацию, но система может быть неудобной, непонятной, медленной. Мне, разработчику, по большому счету не так уж важно, популярен ли тот или иной функционал. С другой стороны, мне важно понимать, возникают ли непридвиденные ошибки (баги) и как часто. Аналитика не ответит на этот вопрос и не ответит на вопрос, почему так происходит. Аналитика важна, нужна, обязательна; Но в конце концов, бизнесу с этим жить. Можно предложить улучшить сбор аналитики, но это не решит проблему. Инструменты аналитики недостаточно гибки для этого, и для этого есть инструменты лучше: логи, метрики, дашборды.
Самым простым и быстрым способом захостить статичный контент, будь то SPA приложение или HTML страница, на протяжении долгого времени был и остается GitHub Pages. Но у него есть сильные ограничения, и какой-то серьезный фронтенд я бы там хостить не стал. Давным давно неплохой альтернативной был Firebase Hosting, но сейчас существуют еще более простые и удобные сервисы. Их много, но я хотел бы подсветить один из них - Vercel. Мне удалось захостить статику буквально в один клик, еще за пару кликов я настроил свое доменное имя через стороннего провайдера и это абсолютно бесплатно. Более того, Vercel даже предоставляет услуги регистрации доменов, но в сравнении с другими провайдерами - цена за доменное имя кусается.