"Смерть" мессенджера telegram всё ближе. Проблемы дошли до бытового уровня, где многие пользователи начали жаловаться: "изображения не загружаются, связь пропадает, сообщения отправляются по 30 секунд". Примечательно, что десктопные версии работают хуже мобильных. У меня даже есть очевидное предположение, из-за чего смартфоны справляются лучше — их модифицировали.
Умрёт ли telegram полностью? Ну, что-то подобное прогнозировали и в отношении YouTube, который, по моим субъективным ощущениям, действительно в какой-то момент немного выпал из жизни, но сейчас вернулся и живее всех живых. Думаю, так будет и с telegram, если не придумают новых способов умерщвления.
Тем не менее я уверен, что многие пользователи не выдержат "сбоев" в виде отсутствия загрузки изображений и долгой реакции приложения, ничего не станут ремонтировать, и это приведёт к отказу от такого сервиса. А это значит, что я должен дать своим подписчикам альтернативный способ получения информации.
Выше я уже писал о том, что вижу два дополнительных альтернативных пути развития:
- Написать собственный блог;
- Дублировать посты в Max.
Так вот, я написал сервис блога, развернул инфраструктуру на облачном сервере, реализовал быстрый автоматический деплой всех изменений, прикрутил домен, и теперь меня можно читать на pjdev.ru.
У блога есть комментарии, но пока они будут скрыты. Надо разобраться с тем, как организовать модерацию и с вопросами законодательства. Соответственно, комментарии будут разрешены только после регистрации, а это сбор и хранение данных — вопрос, над которым тоже надо поработать с точки зрения ФЗ.
Кроме того, по ссылке можно присоединиться к моему новому каналу в Max.
P.S. Я начинал писать блог сначала около 3–4 раз из-за того, что очень сильно увлекался разными сторонами разработки и закапывался в них. Мои попытки довести один из аспектов до идеального состояния приводили к полному отказу от идеи. В итоге от попыток сделать идеально я перешёл к мысли: "сделать так, чтобы работало". Скорее всего, позже об этом расскажу более подробно, но если коротко, мысль такая: "идеальное — враг работающего".
P.s.s. я теперь не знаю где вы это читаете поэтому. Blog, Max, Telegram.
Умрёт ли telegram полностью? Ну, что-то подобное прогнозировали и в отношении YouTube, который, по моим субъективным ощущениям, действительно в какой-то момент немного выпал из жизни, но сейчас вернулся и живее всех живых. Думаю, так будет и с telegram, если не придумают новых способов умерщвления.
Тем не менее я уверен, что многие пользователи не выдержат "сбоев" в виде отсутствия загрузки изображений и долгой реакции приложения, ничего не станут ремонтировать, и это приведёт к отказу от такого сервиса. А это значит, что я должен дать своим подписчикам альтернативный способ получения информации.
Выше я уже писал о том, что вижу два дополнительных альтернативных пути развития:
- Написать собственный блог;
- Дублировать посты в Max.
Так вот, я написал сервис блога, развернул инфраструктуру на облачном сервере, реализовал быстрый автоматический деплой всех изменений, прикрутил домен, и теперь меня можно читать на pjdev.ru.
У блога есть комментарии, но пока они будут скрыты. Надо разобраться с тем, как организовать модерацию и с вопросами законодательства. Соответственно, комментарии будут разрешены только после регистрации, а это сбор и хранение данных — вопрос, над которым тоже надо поработать с точки зрения ФЗ.
Кроме того, по ссылке можно присоединиться к моему новому каналу в Max.
P.S. Я начинал писать блог сначала около 3–4 раз из-за того, что очень сильно увлекался разными сторонами разработки и закапывался в них. Мои попытки довести один из аспектов до идеального состояния приводили к полному отказу от идеи. В итоге от попыток сделать идеально я перешёл к мысли: "сделать так, чтобы работало". Скорее всего, позже об этом расскажу более подробно, но если коротко, мысль такая: "идеальное — враг работающего".
P.s.s. я теперь не знаю где вы это читаете поэтому. Blog, Max, Telegram.
👍10👎4❤3😁2🔥1
Почему я сделал собственный веб-сервис для блога после замедления Telegram в России
Я не ухожу с Telegram и не планирую этого делать в будущем. Telegram по-прежнему остаётся важной частью моего блога и основной платформой распространения, и так будет до тех пор пока это возможно, но теперь, в связи с "замедлениями", точно нужна альтернатива — и ей станет личный сервис-блог.
Однако web-сервис для меня — это не только способ распространения информации, но ещё и некое портфолио, а также инструмент, который позволит тестировать и изучать новые технологии. Уже сейчас, благодаря блогу, я знакомлюсь с frontend-разработкой, улучшаю CI/CD и DevOps-практики.
До текущей реализации я уже дважды пробовал сделать, в каком-то смысле, такой простой web-сервис, но каждый раз закапывался в какие-то узкие задачи и в итоге всё бросал.
— Первая попытка закончилась тем, что я создал очень жёсткие требования к коммитам: линтеры, форматтеры и, самое страшное, — очень строгая типизация. Любое, малейшее изменение сопровождалось тем, что было просто невозможно совершить коммит. Я явно переборщил и всё бросил.
— Вторая попытка закончилась тем, что я начал экспериментировать с архитектурой: пытался разбить всё на какие-то «молекулы», сервисы, модули, файлы, функции. Это было абсолютно необоснованно и бессмысленно. В итоге я получил огромное количество модулей и файлов — мне это не понравилось, и я снова всё забросил.
Это был интересный и ценный опыт. Как видите, третья попытка более успешная. Она точно не идеальная, мне многое ещё не нравится в текущем варианте, но он хотя бы рабочий.
Этот пост — первый в серии постов о том, как я решил создать собственный блог, дальше я постараюсь рассказать о поэтапном развитии сервиса. Буду последовательно разобрать все этапы: от идеи и архитектурных решений до реализации, инфраструктуры и планах дальнейшего развития проекта.
Если хотите посмотреть на блог или, может быть, даже добавить его в избранное.
#Мысливслух #Блог
Я не ухожу с Telegram и не планирую этого делать в будущем. Telegram по-прежнему остаётся важной частью моего блога и основной платформой распространения, и так будет до тех пор пока это возможно, но теперь, в связи с "замедлениями", точно нужна альтернатива — и ей станет личный сервис-блог.
Однако web-сервис для меня — это не только способ распространения информации, но ещё и некое портфолио, а также инструмент, который позволит тестировать и изучать новые технологии. Уже сейчас, благодаря блогу, я знакомлюсь с frontend-разработкой, улучшаю CI/CD и DevOps-практики.
До текущей реализации я уже дважды пробовал сделать, в каком-то смысле, такой простой web-сервис, но каждый раз закапывался в какие-то узкие задачи и в итоге всё бросал.
— Первая попытка закончилась тем, что я создал очень жёсткие требования к коммитам: линтеры, форматтеры и, самое страшное, — очень строгая типизация. Любое, малейшее изменение сопровождалось тем, что было просто невозможно совершить коммит. Я явно переборщил и всё бросил.
— Вторая попытка закончилась тем, что я начал экспериментировать с архитектурой: пытался разбить всё на какие-то «молекулы», сервисы, модули, файлы, функции. Это было абсолютно необоснованно и бессмысленно. В итоге я получил огромное количество модулей и файлов — мне это не понравилось, и я снова всё забросил.
Это был интересный и ценный опыт. Как видите, третья попытка более успешная. Она точно не идеальная, мне многое ещё не нравится в текущем варианте, но он хотя бы рабочий.
Этот пост — первый в серии постов о том, как я решил создать собственный блог, дальше я постараюсь рассказать о поэтапном развитии сервиса. Буду последовательно разобрать все этапы: от идеи и архитектурных решений до реализации, инфраструктуры и планах дальнейшего развития проекта.
Если хотите посмотреть на блог или, может быть, даже добавить его в избранное.
#Мысливслух #Блог
🔥12❤6👍6👏2
В прошлом посте я писал о том, почему вообще решил делать собственный web-сервис для блога, а теперь расскажу о технической реализации backend-части.
Недолго думая, я выбрал фреймворк Django по очень простой причине: это привычный для меня инструмент, который я хорошо понимаю. Был вариант ещё использовать FastAPI в академических целях, чтобы освежить его в памяти, но, так как впереди ещё стоял вопрос реализации frontend-части, я решил, что сосредоточу обучение на фронте.
После прошлых неудачных попыток мне совсем не хотелось уходить в архитектурные фантазии, и я решил, что буду делать всё просто и стабильно. Поэтому я сознательно придерживался минимализма во всём проекте. Решил, что пока обойдусь без регистрации/авторизации, ограничусь минимальными моделями Post и Tag, ну и дефолтным User для себя, чтобы управлять админкой. Скромный набор обязательных полей и связей, и всё было готово.
Отдельный плюс Django для такого проекта — это админка из коробки, которая на первых порах позволяла управлять данными без frontend-части. Да и в целом для блога это очень полезный инструмент, который с лёгкостью закрывает вопросы создания и редактирования постов, тем более если ты единственный автор. Django изначально создавался для журналистов с идеей быстрого создания контентных web-сервисов.
Я сразу принял решение, что буду развивать backend как API-приложение. Главная его задача: хранить и обрабатывать данные, реализовывать бизнес-логику и отдавать всё это наружу в понятном формате. Так что логичным продолжением стало дополнение в виде Django REST Framework, который дал сериализацию, пагинацию и разграничение прав доступа. В итоге backend получился API-only: опубликованные посты отдаются через публичные endpoint'ы, черновики доступны только из административного контура, а сам сервис сосредоточен именно на данных и логике публикации.
Когда backend начал обретать форму, стало понятно, что следующим шагом будут отдельный frontend и объединение этих двух сервисов в один рабочий продукт. Поэтому было принято решение создать три отдельных репозитория: backend, frontend, infra. Об этом и будут следующие посты.
#Backend #Django #Python #Блог
Недолго думая, я выбрал фреймворк Django по очень простой причине: это привычный для меня инструмент, который я хорошо понимаю. Был вариант ещё использовать FastAPI в академических целях, чтобы освежить его в памяти, но, так как впереди ещё стоял вопрос реализации frontend-части, я решил, что сосредоточу обучение на фронте.
После прошлых неудачных попыток мне совсем не хотелось уходить в архитектурные фантазии, и я решил, что буду делать всё просто и стабильно. Поэтому я сознательно придерживался минимализма во всём проекте. Решил, что пока обойдусь без регистрации/авторизации, ограничусь минимальными моделями Post и Tag, ну и дефолтным User для себя, чтобы управлять админкой. Скромный набор обязательных полей и связей, и всё было готово.
Отдельный плюс Django для такого проекта — это админка из коробки, которая на первых порах позволяла управлять данными без frontend-части. Да и в целом для блога это очень полезный инструмент, который с лёгкостью закрывает вопросы создания и редактирования постов, тем более если ты единственный автор. Django изначально создавался для журналистов с идеей быстрого создания контентных web-сервисов.
Я сразу принял решение, что буду развивать backend как API-приложение. Главная его задача: хранить и обрабатывать данные, реализовывать бизнес-логику и отдавать всё это наружу в понятном формате. Так что логичным продолжением стало дополнение в виде Django REST Framework, который дал сериализацию, пагинацию и разграничение прав доступа. В итоге backend получился API-only: опубликованные посты отдаются через публичные endpoint'ы, черновики доступны только из административного контура, а сам сервис сосредоточен именно на данных и логике публикации.
Когда backend начал обретать форму, стало понятно, что следующим шагом будут отдельный frontend и объединение этих двух сервисов в один рабочий продукт. Поэтому было принято решение создать три отдельных репозитория: backend, frontend, infra. Об этом и будут следующие посты.
#Backend #Django #Python #Блог
👍10❤6🔥4
Почему не стоит держать всё в одном Django-приложении: разделение на backend, frontend и инфраструктуру
Продолжаю серию постов о том, как пишу собственный блог.
После того, как минимальный backend был реализован, я задумался о том, как развивать систему дальше, чтобы не повторить прошлые ошибки и не загнать себя в архитектурный тупик.
Идею держать всё в одном Django-приложении я сразу отверг. На старте это удобно: один репозиторий, один деплой, минимум инфраструктуры, есть инструменты, которые позволяют реализовать frontend на шаблонах. Но как только появляется полноценный frontend и нормальные CI/CD процессы — границы начинают размываться, и система становится сложнее, чем должна быть.
Проекты, с которыми я работал, обычно не выделяли инфраструктуру в отдельный репозиторий. Хотя в одном из них эти процессы всё-таки были обособлены, и мне это понравилось. Поэтому я решил в качестве эксперимента попробовать реализовать новую для себя схему:
- backend — отдельный сервис с API
- frontend — отдельное приложение, которое работает с этим API
- infra — отдельный слой, отвечающий за деплой, окружение и сборку
Это не попытка уйти в микросервисы, а разделение проекта на зоны ответственности. Каждая часть системы отвечает за свою область и не тянет на себя лишнего. Если бы я оставил всё в одном репозитории, то любое изменение тянуло бы за собой всё сразу — от API до деплоя. В какой-то момент это начинает замедлять разработку сильнее, чем кажется на старте.
Такое решение даёт ощутимое преимущество: части системы перестали зависеть друг от друга. Backend можно менять, не думая о UI, frontend — развивать отдельно, а инфраструктура теперь живёт отдельно и не связана напрямую с кодом приложения. Однако у всего есть цена. Появляется необходимость явно поддерживать API-контракт. Ошибки на стыке сервисов становятся более вероятными, а деплой усложняется за счёт увеличения количества отдельных частей системы.
Моя практика показывает, что плюсов больше, чем минусов — прежде всего за счёт контроля связности. Явные границы через API фиксируют точки взаимодействия: зависимости перестают быть скрытыми и становятся управляемыми. Любое изменение проходит через контракт, а значит становится предсказуемым — понятно, где и что может сломаться.
По сути, это перевод сложности из неявных связей внутри кода в явные интерфейсы между частями системы. Это упрощает развитие: можно менять отдельные компоненты, не затрагивая остальные, пока соблюдается контракт.
В итоге это не про сложную архитектуру, а про управляемость и предсказуемость системы.
#Архитектура #Блог #МыслиВСлух #Разработка
Продолжаю серию постов о том, как пишу собственный блог.
После того, как минимальный backend был реализован, я задумался о том, как развивать систему дальше, чтобы не повторить прошлые ошибки и не загнать себя в архитектурный тупик.
Идею держать всё в одном Django-приложении я сразу отверг. На старте это удобно: один репозиторий, один деплой, минимум инфраструктуры, есть инструменты, которые позволяют реализовать frontend на шаблонах. Но как только появляется полноценный frontend и нормальные CI/CD процессы — границы начинают размываться, и система становится сложнее, чем должна быть.
Проекты, с которыми я работал, обычно не выделяли инфраструктуру в отдельный репозиторий. Хотя в одном из них эти процессы всё-таки были обособлены, и мне это понравилось. Поэтому я решил в качестве эксперимента попробовать реализовать новую для себя схему:
- backend — отдельный сервис с API
- frontend — отдельное приложение, которое работает с этим API
- infra — отдельный слой, отвечающий за деплой, окружение и сборку
Это не попытка уйти в микросервисы, а разделение проекта на зоны ответственности. Каждая часть системы отвечает за свою область и не тянет на себя лишнего. Если бы я оставил всё в одном репозитории, то любое изменение тянуло бы за собой всё сразу — от API до деплоя. В какой-то момент это начинает замедлять разработку сильнее, чем кажется на старте.
Такое решение даёт ощутимое преимущество: части системы перестали зависеть друг от друга. Backend можно менять, не думая о UI, frontend — развивать отдельно, а инфраструктура теперь живёт отдельно и не связана напрямую с кодом приложения. Однако у всего есть цена. Появляется необходимость явно поддерживать API-контракт. Ошибки на стыке сервисов становятся более вероятными, а деплой усложняется за счёт увеличения количества отдельных частей системы.
Моя практика показывает, что плюсов больше, чем минусов — прежде всего за счёт контроля связности. Явные границы через API фиксируют точки взаимодействия: зависимости перестают быть скрытыми и становятся управляемыми. Любое изменение проходит через контракт, а значит становится предсказуемым — понятно, где и что может сломаться.
По сути, это перевод сложности из неявных связей внутри кода в явные интерфейсы между частями системы. Это упрощает развитие: можно менять отдельные компоненты, не затрагивая остальные, пока соблюдается контракт.
В итоге это не про сложную архитектуру, а про управляемость и предсказуемость системы.
#Архитектура #Блог #МыслиВСлух #Разработка
👍4🔥3🤝2
Обстоятельства изменились, нужна новая работа
Так вышло, что проекты, где я работал backend разработчиком, не справились с экономической ситуацией: оба учредителя приняли решение — закрыть компании из-за того, что расходы растут, доходы падают, а кредитование дорогое. В итоге один проект закрылся чуть раньше, а второй доживает последний месяц и закрывается.
Вердикт был вынесен довольно неожиданно. На основном месте работы в один из обычных дней нам просто сообщили во время созвона, что мы дорабатываем до конца месяца и компания закрывается. Радует, что расходимся абсолютно мирным путём на основе заранее оговорённых договорённостей.
Информацию о том, что компания закрывается, я получил буквально за день до своего отпуска, так что он, по сути, стал бессрочным. Однако билеты куплены, отель оплачен — отпуску быть! Сейчас поеду, отдохну, вернусь и буду снова учиться проходить собеседования и искать работу. Так что открыт к предложениям, если у кого-то есть варианты, то с радостью обсужу с вами этот вопрос. Слышал, что рынок труда сейчас очень тяжёлый, так что теперь немного переживаю, но надеюсь, что всё пройдёт гладко.
P. S. Технические посты как-то не зашли, да и на свой блог времени совершенно не было из-за того, что делал большой рефакторинг всего проекта: написание тестов, документации, оптимизация кода, реструктуризация и формирование единого стиля, настройка CI\CD процессов и DevOps инструментов. Была потрачена уйма сил и времени, но теперь кажется, что это всё было впустую. Так что, наверное, пока техническую часть оставлю в стороне и буду дальше писать какие-то свои мысли.
P.s.s. ещё одни фактором отсутствия активности стала блокировка телеграмма из-за чего число просмотров упало почти в два раза. Я из-за этого расстроился и думал, что блог совсем умрёт, а я на него потратил больше трёх лет своей жизни, но кажется, что всё не так плохо.
#Мысливслух
Так вышло, что проекты, где я работал backend разработчиком, не справились с экономической ситуацией: оба учредителя приняли решение — закрыть компании из-за того, что расходы растут, доходы падают, а кредитование дорогое. В итоге один проект закрылся чуть раньше, а второй доживает последний месяц и закрывается.
Как говорил волшебник Ринсвинд:
«В интересные времена живём».
Вердикт был вынесен довольно неожиданно. На основном месте работы в один из обычных дней нам просто сообщили во время созвона, что мы дорабатываем до конца месяца и компания закрывается. Радует, что расходимся абсолютно мирным путём на основе заранее оговорённых договорённостей.
Информацию о том, что компания закрывается, я получил буквально за день до своего отпуска, так что он, по сути, стал бессрочным. Однако билеты куплены, отель оплачен — отпуску быть! Сейчас поеду, отдохну, вернусь и буду снова учиться проходить собеседования и искать работу. Так что открыт к предложениям, если у кого-то есть варианты, то с радостью обсужу с вами этот вопрос. Слышал, что рынок труда сейчас очень тяжёлый, так что теперь немного переживаю, но надеюсь, что всё пройдёт гладко.
P. S. Технические посты как-то не зашли, да и на свой блог времени совершенно не было из-за того, что делал большой рефакторинг всего проекта: написание тестов, документации, оптимизация кода, реструктуризация и формирование единого стиля, настройка CI\CD процессов и DevOps инструментов. Была потрачена уйма сил и времени, но теперь кажется, что это всё было впустую. Так что, наверное, пока техническую часть оставлю в стороне и буду дальше писать какие-то свои мысли.
P.s.s. ещё одни фактором отсутствия активности стала блокировка телеграмма из-за чего число просмотров упало почти в два раза. Я из-за этого расстроился и думал, что блог совсем умрёт, а я на него потратил больше трёх лет своей жизни, но кажется, что всё не так плохо.
#Мысливслух
💔15❤9
Беда не приходит одна
Мой отпуск закончился тем, что я сильно заболел, и в итоге мне пришлось сутки с температурой 38+ шататься по аэропортам и перенести 11-часовой перелёт. Развлечение так себе.
После прилёта меня посадили на карантин. Из-за вируса начались осложнения в виде конъюнктивита и отита. Неделю пролежал с закрытыми глазами и тоннами лекарств. Сейчас более-менее пришёл в сознание. Сил пока вообще никаких нет, но надо как-то возвращаться в рабочий режим.
Пока лежал, читал различные каналы о текущем рынке труда и, если честно, немного в шоке от того, что там пишут. Люди, которые попадают на технические собеседования, буквально заявляют, что им прямым текстом говорят, что их будут эксплуатировать и ни во что не ставить. И это я ещё мягко пересказал.
Естественно, это субъективное восприятие какой-то небольшой группы людей, на которых я случайно наткнулся в конкретный момент. Но люди опытные, и, кажется, врать им незачем. Пока не готов в такое верить. Когда появится личный опыт — поделюсь.
Есть и хорошие примеры. Некоторые знакомые говорят, что за минувшие полгода сменили работу, при этом увеличив доход. Так что тут всё, как всегда, зависит от человека, его навыков и в каком-то смысле от везения.
Плохое всегда воспринимается и передаётся ярче, чем хорошее. Посмотрим, что будет на самом деле.
#Мысливслух #поискработы
Мой отпуск закончился тем, что я сильно заболел, и в итоге мне пришлось сутки с температурой 38+ шататься по аэропортам и перенести 11-часовой перелёт. Развлечение так себе.
После прилёта меня посадили на карантин. Из-за вируса начались осложнения в виде конъюнктивита и отита. Неделю пролежал с закрытыми глазами и тоннами лекарств. Сейчас более-менее пришёл в сознание. Сил пока вообще никаких нет, но надо как-то возвращаться в рабочий режим.
Пока лежал, читал различные каналы о текущем рынке труда и, если честно, немного в шоке от того, что там пишут. Люди, которые попадают на технические собеседования, буквально заявляют, что им прямым текстом говорят, что их будут эксплуатировать и ни во что не ставить. И это я ещё мягко пересказал.
Естественно, это субъективное восприятие какой-то небольшой группы людей, на которых я случайно наткнулся в конкретный момент. Но люди опытные, и, кажется, врать им незачем. Пока не готов в такое верить. Когда появится личный опыт — поделюсь.
Есть и хорошие примеры. Некоторые знакомые говорят, что за минувшие полгода сменили работу, при этом увеличив доход. Так что тут всё, как всегда, зависит от человека, его навыков и в каком-то смысле от везения.
Плохое всегда воспринимается и передаётся ярче, чем хорошее. Посмотрим, что будет на самом деле.
#Мысливслух #поискработы
❤14