Константин про IT

Мой Obsidian без плагинов Прошла неделя, я в восторге! Перенёс рабочие заметки, прошелся по всем настройкам (офигел с того, что на это хватает 15 минут, а не часы, как это было с VS Code), накидал иерархии и связей и уже начал логгировать задачи и думать в заметках и на канвасах. Преимущества Obsidian (без плагинов, из коробки): 1. тратишь 20-30 минут на настройку и всё, готово 2. запускается моментально (в сравнении с моим личным с кучей плагинов) 3. (daily notes) пара кнопок, и ты в daily заметке уже пишешь что-то, что тебе важно в моменте 4. (slides) любые вываленные мысли за 5 минут превращаются в презентацию, которую можно показывать на совещании 5. (graph & links) всё собирается в связанную систему. К вопросам по таскам линкуются люди, которые могут дать ответ. К следующим таскам линкуются предыдущие, где уже решены какие-то проблемы и так далее 6. (canvas) Размышления опираются на ссылки, другие задачи, результаты встреч, фото, документы и т.п. Всё собирается, систематизируется, линкуется в единую доску, удобную для навигации и внесения исправлений, а так же критикуется и логгируются ответы на критику. Недостатки: не выявлено Как у меня организовано (так же устроен и мой личный Obsidian): . ├── core/ <- где будут лежать все заметки, папки, канвасы и пр./ │ ├── daily/ <- созданные дейли заметки будут тут │ ├── canvases/ <- созданные канвасы │ ├── ... <- ваше творчество по структуре папок =) │ └── zero_links/ <- папка с якорными заметками (все таски ссылаются на 0_tasks) ├── sources/ <- куда obs будет класть картинки, аудио и т.п. └── templates/ <- шаблоны для заметок How to (советы по настройке): - Зайдите в settings - Files and links -> default location for new attachments -> in the folder, specified below -> указываем sources - В Core plugins включите Slides (пункт 4 про презентации) и *опционально* Web Viewer (чтобы ссылки открывались внутри Obsidian). - Backlinks -> Show at the bottom -> ага. Позволит видеть, кто ссылается на заметку. - Canvas -> Default location -> core/canvases. Все автосозданные канвасы будут там. - Daily notes -> New file location -> core/daily - Создаём в templates/daily.md и кладём туда мой пример из комментов или пишем свой =) - Daily notes -> Template file location -> templates/daily.md. Теперь заметка автоматически будет иметь нужно форматирование - Templates -> Template file location -> templates/ Как использовать темплейты: - В папке templates создаём заметки (мои примеры и пояснения в комментах) - В новой заметке нажимаем cmd/ctrl + p -> начинаем писать "templ.." и выбираем insert template (или делаем хоткей ctrl+t в settings -> hotkeys). Выбираем какой шаблон добавить и вот у вас любая заметка может стать daily, task, material и вообще всем, чем захотите. Ещё пара советов: - cmd+p - наш лучший друг. - cmd+p -> dail... -> мы в daily заметке; -> canv... -> мы сделали канвас и т.п. - все заметки - это маркдаун синтаксис (оч простой) с сахарком от obsidian - походите немного по докам, они маленькие, простые и с примерами (слайды, темплейты, канвасы и т.п.) Подарочек от меня: Мне нравится дефолтная dark тема, но не нравится, что h1-h5 заголовки не отличаются по цвету. Так что я сделал маленькую стилизацию, которая мне приятна (картинка в комментах) - В папке с вашими заметками есть "скрытая" папка .obsidian. - Зайдите туда и создайте папку snippets - В ней создадите файл что-нибудь.css (например my_styles.css) - В настройках Obsidian в Appearance прокрутите в самый низ и включите ваш стиль. - добавьте стили в css файлик (например, как у меня, но можно ввести в гугле color picker и повыбирать самому) =) У меня my_styles.css такой: body { --h1-color: #c6d9f7; --h2-color: #b0f7f1; --h3-color: #3d93f5; --h4-color: #f7ab48; --h5-color: #f79448; --bold-color: #f748ee; /* Цвет для жирного текста */ --italic-color: #f748ee; /* Цвет для курсивного текста */ --underline-color: #fa3cb7; /* Цвет для подчеркнутого текста */ }

У меня сегодня настроение, когда хочется делиться крутыми материалами! У Лени, с которым мы записали подкаст, выходит серия постов про его опыт видения заметок в obsidian. Очень хочется поделиться ими с вами! Давайте вместе зайдём к нему в канал и накидаем реакций!

Всем привет! Сегодня — День космонавтики! С чем у вас ассоциируется космос и космонавтика в целом? Лично мне в голову приходит надежность. Люди, которые запускают ракеты в космос, продумывают всё до малейших деталей, резервируют всё, что можно: дублируют питание, все магистрали, оборудование. И знаете что? Это ведь не так уж далеко от большого IT! Многие, наверное, слышали, что 30 марта у нас отвалился один из ДЦ Яндекса. Кажется, новость не самая приятная, но для меня это стало отличным показателем того, насколько в Яндексе крутые подходы к надежности и резервированию! Мы не просто пережили полное отключение ДЦ, так и это никак не сказалось на платежах наших пользователей! Про резервирование, надежность и подробный разбор инцидента вышла супер интересная статья от коллег из инфраструктуры — рекомендую к прочтению: https://habr.com/ru/companies/yandex/articles/897626/

Всем привет! Сегодня хочу поделиться чек-листом, которым я пользуюсь каждый раз, когда разрабатываю новую фичу. 1️⃣ Бизнес-требования Самое важное перед началом работы над любой задачей — это сформулировать требования. А что конкретно мы хотим от решения этой задачи? Я, как и многие разработчики, люблю писать чистый и красивый код, но зачастую бизнесу не так важен сам код, как тот факт, что он закрывает конкретную потребность. Поэтому важно перед началом работы выровняться с автором задачи: а что именно мы хотим? 2️⃣ Ответить на вопрос: как мы поймём, что задача действительно выполнена? Часто при решении задачи погружаешься в архитектуру, красоту и прочее, и на выходе можешь получить красивый, рабочий код — но, увы, не решающий задачу. Поэтому полезно возвращаться к изначальной формулировке и сверяться: в том ли направлении я иду? 3️⃣ Надёжность Зачастую после решения мы получаем код, который будет работать долгое время и в суровых реалиях продакшена. Поэтому надёжность выходит на первое место. Важно не забывать оборачивать наше решение хотя бы базовым мониторингом, логами и тестами, которые позволят ответить на вопрос: а наша фича вообще ещё работает? 4️⃣ Воспроизводимость окружения для разработки Работая над проектами, наш фокус внимания постоянно меняется, и бывают ситуации, когда уже через неделю ты не помнишь, как запускать и проверять фичу. На такие случаи стоит сразу после разработки оставить какие-либо "рецепты" — будь то коллекции запросов или просто набор скриптов, позволяющих в пару команд быстро поднять окружение и протестировать фичу. 5️⃣ Продумать схему деплоя — и, что важно, схему отката! Думаю, не нужно объяснять, почему важно понимать, как будет раскатываться ваша фича. Но я заметил, что многие не продумывают схему отката. Увы, мы все люди, и нам свойственно ошибаться. Поэтому лучше заранее понять, что делать, если что-то пойдёт не так. Для себя я выделяю несколько вещей: 👉 миграции данных, позволяющие откатиться к предыдущей схеме; 👉 конфигурируемые флаги, отключающие новую функциональность (feature flags); 👉 ну и, на "advanced" уровне — канареечные деплои. 6️⃣ Документация Наверное, самое сложное в работе разработчиков — это поддержка документации. Буду честен, сам страдаю от написания инструкций, рецептов и прочего. Но в моменты инцидентов или доработки функциональности понимаешь всю её значимость. Необязательно писать многостраничную документацию о том, как это работает и почему было принято то или иное решение. Достаточно верхнеуровнево описать логику или использовать максимально человеко-понятные конструкции в коде. Например, в моей команде мы придерживаемся правила: неочевидные решения описываем в тикете задачи, и при необходимости — оставляем ссылку на тикет в комментарии к коду. А какие пункты добавили бы вы? Какие моменты кажутся вам спорными? Оставляйте комментарии — давайте обсудим!

Всем привет! Сегодня хочу поговорить на тему планирования. За свою жизнь я пробовал множество подходов к планированию и ведению задач. Я заметил, что на работе мы планируем год, кварталы, спринты, недели, и это позволяет понимать, что меня вообще ждёт. А вот что касается личных задач, тут уже не так всё радужно... Для меня раньше было очень сложно выполнять что-то для себя просто потому, что я не планировал время! Я планировал рабочую неделю, ставил в календарь события, которые имеют чёткое время выполнения, и их я выполнял. Но я стал замечать, что перестаю выполнять задачи и обязательства, которые не имеют дедлайна. Например, я раньше мог пообещать девушке, что мы сходим на свидание, и откладывать это неделями или месяцами... Не круто, кроме того, что я нарушаю свои договорённости, я ещё и попадал в ситуацию, когда сам себе не мог ответить, когда я что-либо сделаю. Такая ситуация была несколько раз в моей жизни, и каждый раз из этого рождались инструменты: * Календарь как место хранения задач с дедлайном. * Планирование недели — верхнеуровневая прикидка, что и когда я делаю. * Просмотр предыдущей недели и небольшая рефлексия: что сработало, а что нет. * Оценка задач по матрице Эйзенхауэра. * Список долгосрочных проектов и целей в жизни. * Рабочий таск-трекер как источник планов по работе. Кажется, что инструментов сильно больше, но я выписал те, которые работают у меня. Буду рад обсудить в комментариях те способы, которые работают у вас! P.S. Немного пропал с радаров, нужно было восстановиться! Сейчас я восстановился и буду радовать вас постами чаще!

Всем привет! Пришла интересная идея! Предлагаю делать разборы реальных проектов и технических решений, которые интересны именно вам. Как это будет работать: 1) Я публикую пост с анонсом разбора 2) Вы оставляете в комментариях свои предложения 3) Выбираем наиболее интересную тему 4) Организуем созвон (с записью, чтобы все могли посмотреть) 5) Обсуждаем всё в прямом эфире Что можно будет разобрать: - Архитектурные решения - Подходы к мониторингу - Оптимизацию сервисов - Любые другие интересные кейсы Как вам такой формат? Хотели бы поучаствовать? Пишите в комментариях: - Какие проекты хотели бы разобрать? - С какими задачами сталкиваетесь? - Какие подходы в разработке вас интересуют? Самые интересные предложения обязательно разберем!

Всем привет! Сегодня хочется немного подушнить) Поговорим про трейсинг и OpenTelemetry. Трейсинг — это подход, позволяющий смотреть, как выполнялся тот или иной запрос, какие вызовы происходили и какие были взаимодействия между микросервисами. Сейчас трейсинг — это уже база для observability микросервисной архитектуры. Вся магия работает на двух основных понятиях: трейс и спан. Трейс, как можно догадаться, это уникальный путь запроса, который состоит из спанов — конкретных шагов выполнения. Чаще всего спаны содержат информацию о запросах к БД, внешних вызовах к другим сервисам или же просто ключевых моментах работы сервиса. Сейчас становится уже стандартом использовать OpenTelemetry. Огромное SDK позволяет почти не думать о том, как собирать трейсы, как связывать спаны друг с другом, куда сохранять трейсы, а также как распространять трейсы между микросервисами при запросах. Казалось бы, всё круто! Но есть нюанс… Если вы пользуетесь стандартными инструментами OpenTelemetry, то с минимальными настройками вы сможете настроить трейсы для синхронных вызовов, но что делать с асинхронными задачами? Под асинхронными задачами я имею в виду те задачи, которые запускаются где-то в фоновых процессах, воркерах и зачастую фактически выполняются в другом месте (контейнере или сервере). Например, у нас есть очередь с использованием базы данных: один процесс записывает запись в БД, а другой периодически обращается к БД и выполняет какую-то работу. Если мы хотим в одном трейсе видеть все процессы, включая фоновые, нам придётся подумать, как именно наша система трейсинга узнает, что трейсы на самом деле связаны? Для этого нам на помощь приходит механизм Propagation (если быть честным, то под капотом мы его же используем и для синхронных вызовов, но сейчас опустим это). Идея очень простая: давайте просто сохраним ID в какую-нибудь промежуточную структуру, сохраним её, например, в БД, а потом в другом процессе извлечём и скажем OpenTelemetry: “Привяжи спаны к трейсу, который мы тебе даём”. Такой подход позволяет наглядно видеть, какие процессы вообще происходят в нашей системе, и делает проще поиск проблем в нашем сложном распределённом мире! Ну всё, подушнил немного и хватит😂 А вы используете трейсинг в своих проектах? И если да, то настраиваете ли его для асинхронных задач? Оставляйте свои комментарии, буду рад обсудить данный подход!

Есть интересная тема для обсуждения! Часто общаясь с ребятами из IT, я слышу от них, что в свободное время они продолжают писать код или заниматься чем-то связанным с IT. Мне это очень откликается, но для себя я решил, что мне такое не нравится, потому что для меня важно переключаться и в каком-то смысле соскучиться по разработке. Для себя я открыл новые увлечения. Так, в октябре-сентябре начал заниматься барабанами, недавно вновь вернулся к водному поло и наконец разрешил себе просто поваляться и поиграть в PlayStation. При этом я не могу сказать, что забросил IT — я всё так же продолжаю работать над своими пет-проектами и делать автоматизацию для себя, но теперь выделяю этому конкретное время, а не все выходные, как это было раньше. Я могу объяснить свою позицию тем, что когда ты находишься в некотором хобби-пузыре, начинает страдать качество жизни в целом. А я выбираю жизнь разнообразную и наполненную разными впечатлениями! И пусть IT будет лишь частью этой жизни, но никак не всей жизнью! Для меня это важная тема, поэтому хочется узнать ваше мнение по этому поводу. Оставляйте комментарии, буду рад пообщаться с вами! Ну и проходите небольшой опрос 📊

Хочу поделиться с вами моим прорывом! В воскресенье мы записывали подкаст для DeepSchool. Для меня это был первый опыт записи подкастов на IT-шную тему, так ещё и в студии🤯 Получился крутой разговор про разработку, ML и как это всё дружить между собой. В процессе для себя понял, что мне очень нравится создавать подобного рода контент. Так что подумываю, может, о своём подобном проекте🤔 Если вдруг кто хочет пообщаться про это, то жду в комментарии или личку @kNosorev! Уже жду не дождусь, когда увижу финальный вариант и смогу поделиться им с вами!!