tgindex
P
@PyJDevрусский

История в прямом эфире о том, как я стал разработчиком, изменил свои привычки и улучшил качество жизни https://pjdev.ru/

Последний пост
19 июл.
Последнее чтение
ещё не заходили
Постов за неделю
0
Всего постов
22
Тип
открытый
Язык
русский
В каталоге с
13 авг.
Подписчики
480
−1 за 2 дн.
Сутки
0
0,00%
Неделя
 
Месяц
 
Просмотров на пост
690
22 постов
Вовлечённость
143,8%
к подписчикам
Постов в день
0,0
всего 22
Упоминаний
0
каналов
Охват размещения
оценка
1/24сутки в ленте
1/48двое суток
1/72трое суток

Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.

Посты

  • Беда не приходит одна Мой отпуск закончился тем, что я сильно заболел, и в итоге мне пришлось сутки с температурой 38+ шататься по аэропортам и перенести 11-часовой перелёт. Развлечение так себе. После прилёта меня посадили на карантин. Из-за вируса начались осложнения в виде конъюнктивита и отита. Неделю пролежал с закрытыми глазами и тоннами лекарств. Сейчас более-менее пришёл в сознание. Сил пока вообще никаких нет, но надо как-то возвращаться в рабочий режим. Пока лежал, читал различные каналы о текущем рынке труда и, если честно, немного в шоке от того, что там пишут. Люди, которые попадают на технические собеседования, буквально заявляют, что им прямым текстом говорят, что их будут эксплуатировать и ни во что не ставить. И это я ещё мягко пересказал. Естественно, это субъективное восприятие какой-то небольшой группы людей, на которых я случайно наткнулся в конкретный момент. Но люди опытные, и, кажется, врать им незачем. Пока не готов в такое верить. Когда появится личный опыт — поделюсь. Есть и хорошие примеры. Некоторые знакомые говорят, что за минувшие полгода сменили работу, при этом увеличив доход. Так что тут всё, как всегда, зависит от человека, его навыков и в каком-то смысле от везения. Плохое всегда воспринимается и передаётся ярче, чем хорошее. Посмотрим, что будет на самом деле. #Мысливслух #поискработы

  • Обстоятельства изменились, нужна новая работа Так вышло, что проекты, где я работал backend разработчиком, не справились с экономической ситуацией: оба учредителя приняли решение — закрыть компании из-за того, что расходы растут, доходы падают, а кредитование дорогое. В итоге один проект закрылся чуть раньше, а второй доживает последний месяц и закрывается. Как говорил волшебник Ринсвинд: «В интересные времена живём». Вердикт был вынесен довольно неожиданно. На основном месте работы в один из обычных дней нам просто сообщили во время созвона, что мы дорабатываем до конца месяца и компания закрывается. Радует, что расходимся абсолютно мирным путём на основе заранее оговорённых договорённостей. Информацию о том, что компания закрывается, я получил буквально за день до своего отпуска, так что он, по сути, стал бессрочным. Однако билеты куплены, отель оплачен — отпуску быть! Сейчас поеду, отдохну, вернусь и буду снова учиться проходить собеседования и искать работу. Так что открыт к предложениям, если у кого-то есть варианты, то с радостью обсужу с вами этот вопрос. Слышал, что рынок труда сейчас очень тяжёлый, так что теперь немного переживаю, но надеюсь, что всё пройдёт гладко. P. S. Технические посты как-то не зашли, да и на свой блог времени совершенно не было из-за того, что делал большой рефакторинг всего проекта: написание тестов, документации, оптимизация кода, реструктуризация и формирование единого стиля, настройка CI\CD процессов и DevOps инструментов. Была потрачена уйма сил и времени, но теперь кажется, что это всё было впустую. Так что, наверное, пока техническую часть оставлю в стороне и буду дальше писать какие-то свои мысли. P.s.s. ещё одни фактором отсутствия активности стала блокировка телеграмма из-за чего число просмотров упало почти в два раза. Я из-за этого расстроился и думал, что блог совсем умрёт, а я на него потратил больше трёх лет своей жизни, но кажется, что всё не так плохо. #Мысливслух

  • Почему не стоит держать всё в одном Django-приложении: разделение на backend, frontend и инфраструктуру Продолжаю серию постов о том, как пишу собственный блог. После того, как минимальный backend был реализован, я задумался о том, как развивать систему дальше, чтобы не повторить прошлые ошибки и не загнать себя в архитектурный тупик. Идею держать всё в одном Django-приложении я сразу отверг. На старте это удобно: один репозиторий, один деплой, минимум инфраструктуры, есть инструменты, которые позволяют реализовать frontend на шаблонах. Но как только появляется полноценный frontend и нормальные CI/CD процессы — границы начинают размываться, и система становится сложнее, чем должна быть. Проекты, с которыми я работал, обычно не выделяли инфраструктуру в отдельный репозиторий. Хотя в одном из них эти процессы всё-таки были обособлены, и мне это понравилось. Поэтому я решил в качестве эксперимента попробовать реализовать новую для себя схему: - backend — отдельный сервис с API - frontend — отдельное приложение, которое работает с этим API - infra — отдельный слой, отвечающий за деплой, окружение и сборку Это не попытка уйти в микросервисы, а разделение проекта на зоны ответственности. Каждая часть системы отвечает за свою область и не тянет на себя лишнего. Если бы я оставил всё в одном репозитории, то любое изменение тянуло бы за собой всё сразу — от API до деплоя. В какой-то момент это начинает замедлять разработку сильнее, чем кажется на старте. Такое решение даёт ощутимое преимущество: части системы перестали зависеть друг от друга. Backend можно менять, не думая о UI, frontend — развивать отдельно, а инфраструктура теперь живёт отдельно и не связана напрямую с кодом приложения. Однако у всего есть цена. Появляется необходимость явно поддерживать API-контракт. Ошибки на стыке сервисов становятся более вероятными, а деплой усложняется за счёт увеличения количества отдельных частей системы. Моя практика показывает, что плюсов больше, чем минусов — прежде всего за счёт контроля связности. Явные границы через API фиксируют точки взаимодействия: зависимости перестают быть скрытыми и становятся управляемыми. Любое изменение проходит через контракт, а значит становится предсказуемым — понятно, где и что может сломаться. По сути, это перевод сложности из неявных связей внутри кода в явные интерфейсы между частями системы. Это упрощает развитие: можно менять отдельные компоненты, не затрагивая остальные, пока соблюдается контракт. В итоге это не про сложную архитектуру, а про управляемость и предсказуемость системы. #Архитектура #Блог #МыслиВСлух #Разработка

  • В прошлом посте я писал о том, почему вообще решил делать собственный 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 #Блог

  • Почему я сделал собственный веб-сервис для блога после замедления Telegram в России Я не ухожу с Telegram и не планирую этого делать в будущем. Telegram по-прежнему остаётся важной частью моего блога и основной платформой распространения, и так будет до тех пор пока это возможно, но теперь, в связи с "замедлениями", точно нужна альтернатива — и ей станет личный сервис-блог. Однако web-сервис для меня — это не только способ распространения информации, но ещё и некое портфолио, а также инструмент, который позволит тестировать и изучать новые технологии. Уже сейчас, благодаря блогу, я знакомлюсь с frontend-разработкой, улучшаю CI/CD и DevOps-практики. До текущей реализации я уже дважды пробовал сделать, в каком-то смысле, такой простой web-сервис, но каждый раз закапывался в какие-то узкие задачи и в итоге всё бросал. — Первая попытка закончилась тем, что я создал очень жёсткие требования к коммитам: линтеры, форматтеры и, самое страшное, — очень строгая типизация. Любое, малейшее изменение сопровождалось тем, что было просто невозможно совершить коммит. Я явно переборщил и всё бросил. — Вторая попытка закончилась тем, что я начал экспериментировать с архитектурой: пытался разбить всё на какие-то «молекулы», сервисы, модули, файлы, функции. Это было абсолютно необоснованно и бессмысленно. В итоге я получил огромное количество модулей и файлов — мне это не понравилось, и я снова всё забросил. Это был интересный и ценный опыт. Как видите, третья попытка более успешная. Она точно не идеальная, мне многое ещё не нравится в текущем варианте, но он хотя бы рабочий. Этот пост — первый в серии постов о том, как я решил создать собственный блог, дальше я постараюсь рассказать о поэтапном развитии сервиса. Буду последовательно разобрать все этапы: от идеи и архитектурных решений до реализации, инфраструктуры и планах дальнейшего развития проекта. Если хотите посмотреть на блог или, может быть, даже добавить его в избранное. #Мысливслух #Блог

  • "Смерть" мессенджера telegram всё ближе. Проблемы дошли до бытового уровня, где многие пользователи начали жаловаться: "изображения не загружаются, связь пропадает, сообщения отправляются по 30 секунд". Примечательно, что десктопные версии работают хуже мобильных. У меня даже есть очевидное предположение, из-за чего смартфоны справляются лучше — их модифицировали. Умрёт ли telegram полностью? Ну, что-то подобное прогнозировали и в отношении YouTube, который, по моим субъективным ощущениям, действительно в какой-то момент немного выпал из жизни, но сейчас вернулся и живее всех живых. Думаю, так будет и с telegram, если не придумают новых способов умерщвления. Тем не менее я уверен, что многие пользователи не выдержат "сбоев" в виде отсутствия загрузки изображений и долгой реакции приложения, ничего не станут ремонтировать, и это приведёт к отказу от такого сервиса. А это значит, что я должен дать своим подписчикам альтернативный способ получения информации. Выше я уже писал о том, что вижу два дополнительных альтернативных пути развития: - Написать собственный блог; - Дублировать посты в Max. Так вот, я написал сервис блога, развернул инфраструктуру на облачном сервере, реализовал быстрый автоматический деплой всех изменений, прикрутил домен, и теперь меня можно читать на pjdev.ru. У блога есть комментарии, но пока они будут скрыты. Надо разобраться с тем, как организовать модерацию и с вопросами законодательства. Соответственно, комментарии будут разрешены только после регистрации, а это сбор и хранение данных — вопрос, над которым тоже надо поработать с точки зрения ФЗ. Кроме того, по ссылке можно присоединиться к моему новому каналу в Max. P.S. Я начинал писать блог сначала около 3–4 раз из-за того, что очень сильно увлекался разными сторонами разработки и закапывался в них. Мои попытки довести один из аспектов до идеального состояния приводили к полному отказу от идеи. В итоге от попыток сделать идеально я перешёл к мысли: "сделать так, чтобы работало". Скорее всего, позже об этом расскажу более подробно, но если коротко, мысль такая: "идеальное — враг работающего". P.s.s. я теперь не знаю где вы это читаете поэтому. Blog, Max, Telegram.

  • Наверняка вы играли в Sims или хотя бы знакомы с концепцией этой игры — симуляцией управления жизнью людей. Одна из возможностей этой игры — ускорение времени. Обычно я пользовался ей, чтобы быстрее достичь результата в освоении навыков, карьере и финансовом благополучии персонажа, а также чтобы пропустить тяжёлую, изнурительную и бедную часть жизни. Далее цифровой человечек жил очень успешную, но очень короткую жизнь. Ближе к сути: недавно меня посетила мысль: «вот бы было здорово перемотать жизнь на 10 лет вперёд». В тот момент, где я уже успешный разработчик с большим опытом работы, скорее всего накопил какую-то приличную сумму денег, улучшил качество жизни и вообще чувствую себя прекрасно. И это желание на самом деле вполне естественно. Когда находишься в процессе роста, неопределённости и регулярных усилий, хочется быстрее оказаться в точке стабильности и результата. Выходить из зоны комфорта всегда сложно, но, вероятно, это один из немногих способов роста. Тем не менее, мне очень быстро стало страшно от этих мыслей. Я задумался, а готов ли я потерять 10 лет своей жизни, даже если результат будет гарантирован? И почти сразу решил для себя, что не готов. В отличие от компьютерного человечка, жизнь у меня одна, а само течение жизни — главная ценность, и даже гарантированный успех не компенсирует утрату времени. Важно уметь довольствоваться тем, что есть. Наслаждаться процессами, в том числе учёбой, развитием, достижением карьерных целей и улучшением условий жизни, даже если эти процессы по-своему тяжёлые или неприятные. А если бы кнопка ускорения времени действительно существовала — вы бы её использовали? #Мысливслух

  • Я периодически сталкиваюсь с вопросом от людей, далёких от разработки: «Зачем держать программистов в штате на постоянной основе? Разве нельзя один раз сделать продукт и просто пользоваться им годами?» На первый взгляд вопрос может показаться логичным, но на практике такое почти никогда не работает. Я бы сравнил конечный продукт с живым организмом, который существует в постоянно изменяющейся среде. Бизнес всегда требует изменений Согласно известной шутке, просить внести правки в заранее оговоренный результат — это вообще самое любимое занятие заказчика. Хоть это и распространённая тема для шуток, но логика в этом есть: в бизнесе появляются новые направления, новые требования, новые законодательства, и всё это требует его адаптации к новым реалиям. Даже если сейчас продукт кажется «готовым», то требования к нему не зафиксированы навсегда. Они эволюционируют вместе с бизнесом. И каждый новый шаг — это доработка. Зависимость от технологий и их версий Любой продукт базируется на определённых технологиях, а они имеют тенденцию меняться: - Выходят новые версии языков и фреймворков; - Старые версии перестают поддерживаться; - Закрываются критические уязвимости; - Меняются требования к безопасности; - Изменяются API-контракты; - Вводятся новые ограничения. Такие изменения происходят у ресурсов, которые для вас являются посредниками. Вы никак не можете на них повлиять, но вполне можете пострадать из-за этого. Даже если ваш код кажется идеальным, внешний мир может его разрушить. Баги, которые сразу не удалось обнаружить Я лично знаю о случаях, когда баг всплывал через несколько лет после того, как он появился: при тестировании просто не был задет краевой случай, который впоследствии всплыл и оказался болезненным для бизнеса. Эти и другие баги нужно кому-то исправлять, а если нет постоянной команды разработки, то и исправить будет некому. Попытка отдать задачу на аутсорс тоже может оказаться болезненной: опытные разработчики не готовы браться за мелкие заказы или запрашивают несопоставимую сумму из-за разовости сделки и потребности вникать в код legacy проекта. Изменения в инфраструктуре Продукт должен где-то размещается и зависит от инфраструктуры своего размещения. Могут измениться тарифы или условия размещения. Хостинг может закрыться или перестать работать. Рост аудитории может потребовать масштабирования, а оно, в свою очередь, потребует пересмотра архитектуры. Всё это приводит к тому, что продукт требует постоянных изменений — доработки. В итоге разработка — это не разовая услуга по созданию продукта, а постоянный управляемый процесс сопровождения. При отсутствии технической поддержки продукт начинает постепенно терять актуальность: растёт технический долг, увеличивается стоимость доработок, страдает безопасность, повышаются риски простоев и инцидентов. На определённом этапе изменения могут стать не нормальной эволюцией, а вынужденной и дорогостоящей реанимацией или вовсе привести к смерти продукта. #Мысливслух

  • Я задумался о том, как оказался там, где нахожусь сейчас в профессиональном плане. Во многом это произошло потому, что я отказывался от гарантированно выгодных вариантов в пользу ещё более выгодных, но лишь потенциально. Одним из первых предложений с высокой зарплатой была работа в местном профессиональном колледже: ставка преподавателя, потенциальная возможность разработки внутренних продуктов, плотный график, рабочее место далеко от дома и зарплата 90 тысяч рублей. Учитывая, что тогда я зарабатывал около 40 тысяч, это было ощутимое увеличение дохода — более чем в два раза. Однако я отказался. Условия работы казались некомфортными, к тому же я всё больше хотел сосредоточиться на разработке. Затем поступило отличное предложение от крупного местного банка: 15 минут пешком от дома, полный рабочий день, премии, льготы — всё официально, зарплата 130 тысяч рублей. Предложение звучало очень привлекательно, но и от него я отказался. Главной причиной стали скучные задачи (нужно было парсить тысячестраничные договоры и извлекать из них нужные данные) и очень жёсткий контроль за сотрудниками (вплоть до того, какого цвета галстук необходимо носить). Хотя это уже было ближе к разработке. Было ещё несколько предложений стать разработчиком с условиями хуже, чем у меня на тот момент. О них я даже не задумывался. А вот отказаться от уровня оплаты труда в два, а то и в три раза выше моего — оказалось непросто. Я переживал, что не смогу найти вариант лучше, но при этом боялся, что если соглашусь, то это «болото» затянет меня на несколько лет, и я перестану искать что-то лучшее, пока буду осваиваться на новом месте. В итоге я сформировал для себя несколько требований к работе: - Уровень зарплаты должен вырасти; - Работа должна быть удалённой или с оплачиваемым переездом (даже было два таких предложения); - Это обязательно должно быть моё профильное направление — backend-разработка; - Желательно свободный график или плавающее начало дня. Многие мне говорили, что надо браться за любую работу, расти и менять её. Говорили, что идеальных условий не будет, что я зря трачу время. Действительно, времени на поиск работы у меня ушло значительно больше, чем у других разработчиков из моего окружения, может быть мне просто повезло, но меня это полностью устраивало тогда, и я абсолютно доволен результатом сейчас. #Мысливслух #ОРаботе

  • Небольшая тоска на меня напала: работы много, соответственно, свободного времени мало. Почти всё время работаю или тренируюсь, а в оставшиеся часы пытаюсь отдыхать. Поэтому на бложек сейчас времени не хватает, хотя, я бы сказал, что скорее — не хватает сил. Иногда что-то пишу, но мысли какие-то незаконченные, и не проходят самоцензуру. При этом на канале внезапно появляются новые люди, что для меня удивительно. Вроде в последнее время никакой медийной активности у меня не было, но это всё равно радует. Вроде так чуть-чуть осталось до круглой цифры в 500 подписчиков, но из низкой активности в последнее время циферки перестали расти. В общем, к лету планирую пересматривать свою занятость. Надеюсь в ближайшее время разгребу основную долю задач, станет полегче и снова начну писать. Уже в каком-то смысле соскучился по каналу. Вот такие у меня дела, если есть чем поделиться — пишите в комментариях, с радостью почитаю :) #Мысливслух

  • Так вышло, что на моей основной работе проводить ревью моего кода некому, и весь код, который я написал, прямиком отправляется в работу. Я к этому уже привык, стараюсь его перечитывать по нескольку раз, потом даю себе паузу минут на 15, и снова перечитываю. Обязательно тестирую всё руками и делаю авто-тесты, чтобы убедиться, что всё в порядке. Главное, что всё работает, но вот насколько оно оптимизированно и чисто написано — вопрос, который некому задать. Так вот, я сейчас параллельно принимаю участие в крутом стартапе, где у меня есть "старший" наставник. Тут то я и вспомнил, насколько классно, когда твой код читает кто-то ещё кроме тебя, тем более кто-то более опытный. Коллега проводил ревью моего кода, и сказал, что в целом всё хорошо, но отметил несколько мелких недоработок, которые я не заметил. Если честно, то я немного удивился, что допустил эти ошибки. Наверняка какие-то подобные мелки ошибки были и на основной работе, просто я их не замечал, а тут мне на них указали — и это очень хорошо. Буду набраться опыта у опытных товарищей #Мысливслух

  • 6 янв.861391

    Год эмоциональных потрясений — как очень хороших, так и очень плохих Работа ——— Главное достижение в 2025 году — новая работа, которая из подработки переросла в основную деятельность. За этот год на работе я столкнулся с огромным количеством проблем, которые в какой-то момент казались нерешаемыми, но по итогу, какими бы сложными они ни были, всегда находились решения. Это и есть точка роста — когда ты делаешь то, что кажется невозможным. В течение года я дважды был повышен в текущей компании. Причиной этого, в том числе, стали поступившие офферы от других крупных работодателей. Моё текущее место работы мне очень нравится, и я решил остаться, однако в конце года всё-таки согласился параллельно поучаствовать в небольшом стартапе, который меня заинтересовал. Чтобы высвободить время на стартап, пришлось пожертвовать своей подработкой на радио, которому я отдал около восьми лет своей жизни. Теперь с журналистикой меня больше ничего не связывает. У меня по-прежнему остаётся подработка педагогом по основам программирования для детей на выходных, однако совмещать её с основной работой становится всё сложнее. Один выходной в неделю на протяжении года заметно сказывается на уровне усталости. Возможно, доведу группы до выпуска и откажусь от неё. Хотя я так говорю уже несколько лет. Спорт ——— Весь 2025 год я занимался спортом — пляжным волейболом. Я прошёл путь от потемнения в глазах после двухминутной разминки до полноценной игры на соревнованиях по несколько часов подряд. Мне удалось занять первое место на любительском уровне и поучаствовать в крупных региональных соревнованиях. Да, в последних пока шансов ещё нет, но зато есть куда стремиться. Сейчас становится всё тяжелее и тяжелее сохранять мотивацию, так как рост стал менее заметным, а занятия более тяжёлыми. Но когда я смотрю на играющих профессионалов, они вызывают у меня дикий восторг. Я понимаю, что до такого уровня мне не дорасти, но хочу быть к нему как можно ближе. Бытовое ——— В 2025 году я планировал отпуск, однако в силу разных обстоятельств от него пришлось отказаться. Было грустно — я очень хотел хочу в отпуск, зато сэкономленные деньги позволили обновить технику: приобрёл новый компьютер и ноутбук. В течение года я много читал — техническую, художественную и научно-популярную литературу. Чтение было скорее постоянным фоном, чем отдельной целью, за исключением нескольких технических книг, и помогало переключаться между разными типами задач и контекстов. Также в этом году я выступал в роли эксперта на публичных и закрытых мероприятиях. Делился опытом получения новой профессии, обучения, разработки, поиска работы и другими темами, которые так или иначе связаны с моим каналом. Надеюсь, что этот опыт оказался полезным для аудитории, но он точно был полезен для меня самого — как способ структурировать собственные знания #Мысливслух #Итогигода #2025

  • Ну что друзья, всех с новым годом! Да по моему часовому поясу он настал именно сейчас. Желаю всем счастья, успехов и здоровья. Сейчас самое время провести теплые моменты с друзьями, семьёй, а может быть и с самим собой, а на каникулах подведём итоги года. Всех с новым годом 2026 годом!

  • "Мы забываем 95 процентов своей жизни", такое утверждение я прочитал в книге Светланы Кузиной "Всё что мозг хотел знать про мозг". И оно мне показалось очень интересным. Я раньше много об этом думал, и более того, это одна из причин почему я завёл личный дневник, который в последствии перерос в этот блог. Я веду свой канал чуть более трёх лет, казалось бы совсем небольшой отрезок моей жизни, но когда я перечитываю свои старые посты — я очень сильно удивляюсь. В каких-то местах своей наивности, в каки-то глупости, а иногда наоборот тому, что в некоторых вещах моя позиция осталась неизменной. А что если задуматься о каких-то более глубоких воспоминаниях: студенческих годах, старших классах... начальной школе или садике? Их действительно почти нет, лишь какие-то самые яркие, иногда в негативном смысле, воспоминания. Более того, они не всегда реальны: если воспоминание связано с другим человеком и попробовать это обсудить с ним, то вполне может оказаться, что в его памяти эта ситуация запечатлена совершенно иначе. Так что храните свои воспоминания бережно, записывайте свои мысли, делайте фотографии с близкими и друзьями, может быть даже просто бытовых мест где и как вы жили. Уверен, что потом вам будет интересно об этом повспоминать и придаться ностальгии. А я буду верить, что мне в этом поможет мой блог. P.s. ну и пара рекомендаций от меня по книгам, исходя из того, что я прочитал или читаю в последнее время: 1. Светлана Кузина. "Всё что мозг хотел знать про мозг" 2. Анил Сет. "Быть собой. Новая теория сознания" 3. Райан Норт. "Как изобрести все. Создай цивилизацию с нуля"

  • Это был просто отвратительный месяц Горящие сроки, переработки, множество проблем и самое плохое — потеря близкого человека. Всё это сопровождалось какими-то мелкими проблемами, которые на фоне общего стресса казались большими и страшными. Сейчас такое состояние, что бесит и раздражает буквально любая мелочь. Кажется, что всё вокруг против тебя. В общем сейчас как-то разгребу все эти последствия, постараюсь прийти в норму и буду ждать новогодних каникул, чтобы хоть немного выдохнуть. Уверен, что всё будет хорошо, но на это нужно время. Вот такие грустные новости, но что поделать, такова жизнь. #Мысливслух

  • Так случилось, что в эту красивую дату 11.11 у меня день рождения! Поздравления принимаю в комментариях под постом и на карту 😄 В очередной раз хочу поблагодарить вас за интересное общение, помощь и поддержку. Очень рад, что вы со мной :) #ДеньРождения

  • Я подумал над вашим предложением из комментариев: сделать собственный блог, и решил, что это действительно может быть интересно. Однако в качестве эксперимента начал делать его при помощи ИИ Агента от OpenAI. На начальных этапах он справляется весьма прилично. Я говорю ему, что хочу получить в итоге, а он предлагает разные пути решения, и более того, сам же их реализовывает после моих корректировок. Бывают моменты, когда он не может решить проблему и упирается в стену. Например, у меня была ситуация, когда агент ушёл в цикл из проверки двух решений, которые никак не исправляли ситуацию, и почему-то рассматривать другие решения он не собирался даже после прямого указания, что эти подходы неверны. Руками поправил, поехали дальше. Очень удобно, что у агента в качестве контекста есть весь проект. Ему н не нужно каждый раз объяснять всю цепочку связей объектов: он просто сам смотрит на них и делает выводы. Кроме того, я создал пару файлов с описанием стилевых ограничений, правил формирования коммитов и новых веток, и каждый раз прошу его при внесении изменений следовать правилам из этих файлов. И он следует. Тут вспоминается пост с хабра, где человек рассказывал, что их подобный файл с правилами для агента содержит десятки страниц с подробным описанием, как должен вести себя агент: некая попытка сделать из джун агента - мидл агента. В общем пока всё круто, за исключением очень малого количества свободного времени на собственный проект, но есть проблемка, которая появится в перспективе — фронтенд. Я сам в него не очень умею, и думаю либо всё делать на шаблонизаторе типа Jinja, либо не париться и просить кого-то помочь, либо пробовать самому в какой-то простой фронт? У меня вроде есть минимальный опыт html/css/js, но фреймворков я не знаю и даже выбор стека станет проблемой, которую надо изучить. Не знаю, пока не решил #Мысливслух

  • Роскомнадзор официально заявил, что Telegram в России начали "частично ограничивать". То что у мессенджера проблемы, было понятно уже давно: постоянные потери соединения, загрузка в течение 5-7 секунд после перезапуска приложения и т.д. Так вот, в этом контексте я задумался, что мой канал имеет единственную платформу и ничего более. И в случае, если тележку совсем прикроют, то по сути я потеряю весь канал или большую часть его аудитории. От этого стало как-то грустно. А самое обидное, что я сейчас не вижу альтернативы. Уйти в VK, Max? Верить, что люди будут заморачиваться и всё равно пользоваться тележкой? Есть мысли, идеи, предложения? #Мысливслух

  • Помог ты — помогут тебе, наверное Я тут недавно рассказывал вам о том, что помогал совершенно незнакомому человеку разобраться с устройством Docker, да и в целом — с инфраструктурой проекта. Так вот, на фоне всего этого полез в рабочие процессы CI/CD — посмотреть, что там происходит в части DevOps. А там, оказывается, огромное количество проблем, которые я даже сходу решить не смог. Но тут, как по волшебству, появилась возможность пообщаться с очень опытным DevOps-инженером со стажем работы более пяти лет. Мне дали его контакт и сказали, что он буквально горит своим делом и готов безвозмездно помочь. Мы с ним за час решили пару проблем, которые меня тревожили, и договорились, что в течение месяца ещё несколько раз созвонимся с целью улучшения моих компетенций. Мне в целом очень нравится такое отношение людей в IT-сфере: уже не раз бывало, что я с какими-то абсолютно незнакомыми людьми созванивался, что-то обсуждал, мы делились опытом — и всё это в рамках идеи, в духе увлечения общим делом. Я не раз уже говорил, и ещё не раз повторюсь: общение, новые знакомства — это очень важно. Так что общайтесь, знакомьтесь, задавайте вопросы и помогайте другим! #Мысливслух

  • Мои близкие друзья часто шутят, что я — ходячая энциклопедия: если нужно что-то узнать, то можно подойти ко мне и спросить, а я обязательно отвечу. Конечно же, это не так. Я вообще считаю, что уровень моей эрудиции довольно ограничен. Я действительно интересуюсь самыми разными темами, люблю изучать новое и готов рассуждать почти о чём угодно, если это действительно интересно. К чему я это всё: недавно мне на глаза попалась книга, которая сначала заинтересовала меня своим названием, а потом оказалось, что у неё и содержание отличное. «Физика. 65 ½ (не)детских вопросов о том, как устроено всё» — от кандидата физико-математических наук и популяризатора науки Кирилла Половникова. Сначала кажется, что чтение — лёгкое, почти школьный курс, но чем дальше продвигаешься, тем сложнее становится материал, и уже приходится всерьёз подумать, перечитать главу ещё раз, а иногда и после этого полная картина формируется не сразу. В итоге, когда я дошёл до неклассической физики пришлось даже обсудить некоторые моменты с другом, чтобы лучше понять их. В общем, если хотите лучше понимать, как устроен наш мир, разобраться в физике и почитать что-то действительно интересное — однозначно рекомендую. #Мысливслух #Книги