Happy Devops — сообщество адекватных инженеров – Telegram
Happy Devops — сообщество адекватных инженеров
1.91K subscribers
182 photos
8 videos
2 files
298 links
Сообщество адекватных инженеров | Все про DevOps и эксплуатацию.

Культура, инструменты, подходы и решения

Живо общаемся (чат): https://news.1rj.ru/str/+eNGNnbY_2mVkZTEy

По всем вопросам в бота: @HDFeedBackBot
Web: https://happydevops.ru
Download Telegram
VS Code в браузере

В сегодняшние #полезняшки попала совершенно чумовая, на мой взгляд, штука :)

Что получится, если скрестить 1С и гитхаб? Шутка, не тот 1С, о котором вы подумали. А просто добавляем к домену гитхаба 1s и получаем VS Code прямо в вашем в браузере, а в нем открыт тот репозиторий, который вы указали в URL

Пробуем https://github1s.com/kubernetes/kubernetes

Офигенно удобно чтобы полазить по коду в нормальном редакторе. К сожалению, поставить экстеншены не получится, но и без них это очень удобно.

Идея просто отличная, я считаю
Внутренний критик

В продолжение поста про писательский блок.

На самом деле начать зачастую мешает банальный перфекционизм (а он, как известно, всего лишь одна из форм прокрастинации). и вытекает он из того, что в голове уже сложилась не просто готовая картинка, а уже и все лавры от этой картинки пожаты. То есть кайфа от процесса не случается. А зря. Процесс приносит не меньшее удовольствие, его надо просто научиться извлекать.

Конкретно в моем случае мне надо просто разогнаться. После того, как я определился, что процесс мне нужен и важен, то я перестаю думать о том, как я начинаю, главное — начать. Пишу полную ерунду, что-то рисую, пишу странный код, который имеет мало отношения к решаемой задаче, все это нужно для того, чтобы запустить процесс. Дальше пойдет уже легче, это — вход в поток.

Обязательно необходимо декомпозировать задачу до мельчайших шагов, вычеркивать пункты из тудушника приносит определенное удовольствие и сразу видно, что нужно сделать.

Перфекционизм побеждается очень легко, на самом деле. Никто не определяет, что такое "хорошо", кроме тебя самого. Есть объективные критерии по которым будет оцениваться результат, но процесс-то итеративный. Поэтому надо как можно быстрее сделать "хорошо" в том виде, какой он есть на текущий момент и как можно быстрее получить обратную связь, чтобы приступить к следующей итерации.

Лучше сделать просто хорошо сейчас, чем охуенно и никогда. А удовольствие от сделанной работы — отличный мотиватор, на самом деле
Продуктовые решения и инженерная культура

Поиск баланса между этими двумя понятиями — всегда очень сложное дело. Общих решений нет, все всегда упирается в частности.

Зачастую создается сильное продуктовое решение, но слабое инженерное. Продакты управляют разработкой, не желая погружаться в детали.

На каких-то общих встречах при определении стратегии все выглядит хорошо. Все помнят про техдолг и про костыли, обещают дать время. Но когда дело доходит до реализации, то часто диалог выглядит так:

— Как сделать быстрее чем вы сказали? Никак? Нет, ну как-то же можно?
— Да, можно сделать через жопу, но мы не хотим, потому что итак там уже все через жопу, это трудно поддерживать и если делать так постоянно, то скоро все умрет.
— Ну давайте в этот раз все же сделаем через жопу, а?
— Нет, мы не хотим так больше.
— Ну ок, мы согласны записать в бэклог улучшения которые вы предлагаете, но прямо вот сейчас давайте не будем их делать, а засунем их в следующий спринт, потому что нам сейчас нужна эта фича позарез?
— Ну ок

И всегда все записывается в бэклог и там тихо умирает, потому что всегда появляются новые фичи, которые позарез надо сделать.

Техдолг — он, на самом деле, выглядит также, как и обычный долг. Если не следить за выплатой кредита, то он в конце концов тебя похоронит. Также и распухший бэклог рано или поздно похоронит архитектурное решение и будет принято волевое решение провести процедуру банкротства, то есть начать все заново.

И помните. Кредит — это как обосраться на морозе. Поначалу даже тепло. А техдолг — это тот же самый кредит по сути своей.
Выплачивайте техдолг равными долями. Выделяйте время в спринте на работу только над техдолгом. Добивайтесь того, чтобы задачи из техдолга попадали в спринт.
👍1
Приносите проблемы, а не задачи

Возвращаясь к вопросу про найм людей умнее себя. Одна из проблема менеджера заключается в том, что он рассматривает исполнителей как продолжение своих рук. Никого нельзя засунуть себе в голову, а менеджер долго думал над задачей, он декомпозировал ее в голове до мельчайших подробностей и поэтому ему кажется, что он должен максимально передать это знание исполнителю. И начинается подробный рассказ, как именно надо сделать то или иное, при этом из вида часто упускается именно исходная проблема

Лучше всего расслабиться и принести именно проблему в ее исходном виде. И потратить усилия на то, чтобы объяснить, зачем именно мы это делаем и куда мы идем, а реализацию оставить на откуп тому, кто непосредственно будет это делать. На самом деле этим мы убиваем сразу двух зайцев: не тратим ресурсы на перекладывание информации из одной головы в другую, тем самым избегая ее искажения и повышаем мотивацию человека, который будет делать задачу. Люди чувствуют когда им доверяют и позволяют реализоваться как профессионалам и ценят это. От менеджера же требуется лишь доверять своим сотрудникам. Микроменеджеров никто не любит и эффективность ваших сотрудников будет падать

"К сервису заказов в корзине нужно добавить текстовое поле для промокода, а в базе сделать новую табличку с такими-то полями" — плохо

"Нам нужно добавить возможность использовать промокод, подумай как это можно сделать" — хорошо
Тестовые задания

Интересно, откуда пошло мнение, что можно давать тестовые из рабочих задач и это типа экономия на использовании беплатной рабочей силы? Код должен поддерживаться, код должен жить и код должен соответствовать контексту. Поэтому крайне маловероятно, что тестовое задание на несколько часов может быть выдернуто из воркфлоу и возвращено туда решенным.

Код в статике никому не нужен, на гитхабе огромное количество хорошего мертвого кода. Главное в процессе — это развитие.
Автоматизация

Сегодня капитанский пост. Про автоматизацию.

Вкратце мой посыл таков: автоматизируй все, что можно

Мне порой кажется странной ситуация с «растущими командами». Это понятно, когда расширяется бизнес и появляются новые направления, которые надо обслуживать. Но зачастую я встречаю ситуацию: «мы тут купили ещё сто серверов, нам нужен ещё один админ, старый уже не справляется». То есть у вас 100 однотипных серверов, гайз, и вы рулите ими руками админов, платите им зарплату, а еще и про бас фактор тоже забывать не стоит.
С увеличением количества серверов без увеличения функций, количество людей, обслуживающих эти сервера, увеличиваться не должно.

У меня в вакансии, кстати, есть пункт "понимать, почему не стоит ходить на сервера по ssh" и недавно один товарищ написал в отклике "все технологии, описанные вами. я готов изучить, но не понимаю, почему не стоит ходить на сервера по ssh"

Потому и не стоит, чувак, на сервера должны ходить скрипты, которыми ты мудро управляешь
Про nocode

Современный тренд на nocode-платформы меня прям умиляет. Я вспоминаю начало 2000-х и кучу CMS, которые должны были похоронить профессию программиста как факт. 15 лет прошло и до сих пор хоронят. Надо признать пару очевидных вещей: во-первых, из nocode-истории можно собрать только то, что задумал разработчик. Все хотят повторения чуда Lego, из которых реально можно собрать что угодно, но чуда не случается. А во-вторых, для использования nocode-платформ нужно быть технически подкованным человеком. Все истории успеха, все продукты, собранные на них, были собраны людьми, так или иначе имевших опыт в IT: разработчиками или админами.

Я разговаривал с "обычными пользователями", у них реально сносит крышу от сложности, они просто не понимают предметки. А программисты всегда могут накодить себе нужный обвес рядом и потребность в nocode-платформе резко снижается.

Так что это очередной булшит, революции не произойдет
Часто очень мелькает вопрос: а как отличить миддла от сеньора? Как определить мой грейд?
Я для себя определил очень простую шкалу:
- джун не знает как делать
- миддл знает как делать
- сеньор знает как не делать
Не бывает больше одной срочной задачи

Это бессмыслица уже по своей форме даже, не только по сути. Всегда есть градация приоритетов. Вот, например, как это сделано в гугле. Задача уровня Р0 (то есть имеющая максимальный приоритет) критична для бизнеса и все ресурсы должны быть брошены на ее выполнение. У таких задач должно быть явно обозначенное время реакции и четко прописанный регламент. Команда не должна выбирать и думать, какая из Р0 приоритетнее🤔
Поэтому когда приходят два менеджера со "срочными" задачами, и это не бизнес-критикал, а просто горит, то надо понимать: либо будет сделана одна, но хорошо. Либо обе, но хуево.

И об этом надо говорить сразу и делегировать принятие этого решения именно менеджерам, горит-то у них. Зачастую, кстати, сделать обе, но хуево — это вариант, который устраивает все стороны. И можно сделать не тупо хуево, а в соответствии с принципом прогрессивного джипега и оставить возможность доделать до 100% уже имея какой-то работающий прототип на руках
​​Про рутину

Часто слышу, люди жалуются: работа неинтересная, рутина завалила, начинаю выгорать, жизнь не мила. Я нашего брата-ойтишника имею в виду конечно.
Ну вот как так? Если отбросить очевидный вариант "ты ж не дерево, встань и поменяй работу", почему люди ничего с этим не делают? Я рутину люблю например. Много рутинных действий — это простор для автоматизации. Можно начать оптимизировать, писать кодогенераторы, ямлогенераторы, хелмогенераторы, ввести метрики и явно замерить эффект от своих действий. Придти с ним к бизнесу и гордо сказать "воть!"
Ну, по возможности, надо избегать, конечно, таких мест, где нельзя придти и сказать "воть!", потому что всем пофиг или сначала надо продраться через чудовищную стену бюрократии. В этом случае надо, конечно, вспоминать, что ты не дерево
В продолжение темы Infrastructure as Software

Не так давно я писал пост про возрастающую сложность YAML-манифестов и про то, что рано или поздно мы придем к концепции описания инфраструктуры кодом. То есть декларативное описание становится слишком сложным и нам уже физически необходимо использовать стару-добрую императивную логику. Вот и первая ласточка в этом направлении (может и не первая, но до меня пока только эта долетела)
Встречайте Cloud Development Kit for Kubernetes

Идея ровно такая, как я писал в упомянутом посте. Генерация шаблонов из кода. На данный момент поддерживаются python, java, typenoscript и javanoscript. Идея проста до безобразия и именно тем и привлекательна. Буду пробовать обязательно, по результатам отпишусь
#полезняшки
В продолжении поста про рутину
Мне написали несколько человек про вторую часть, в частности про "всем пофиг"

Зачастую невнимание бизнеса к недостаткам в Operations, да и в разработке, обусловлены не тем, что они такие плохие, а тем, что они гораздо больше погружены в бизнес-процессы, а если техническая команда выдает какой-то приемлемый результат, то и лезть туда незачем. Это зона ответственности СТО, а они, к сожалению, не всегда бывают компетентны. В результате проблемы начинают замечать тогда, когда это уже превратилось в снежный ком. Но всегда есть шанс взять инициативу в свои руки, ввести метрики, найти проблемные места и оптимизировать их. Бизнес очень любит цифры, если придти к нему не с истерикой вида "аа, все плохо", а показать конкретные цифры, озвучить результаты своего исследования и предложить пути оптимизации, то в большинстве случаев это сработает. Меньшинство включает в себя случаи, когда реально пофиг (это очень плохо) и когда все это обвешано космическим количеством бюрократии (привет банки, бодишопы и всякий энтерпрайз). В этом случае, конечно, надо смазывать лыжи
Вообще, придание собственной ценности тому проекту, с которым ты работаешь, очень добавляет мотивации и защищает от выгорания. Вот это ощущение, когда ты действительно можешь что-то менять в рамках своих компетенций, оно очень крутое
Только мы успели проговорить про VSCode в браузере, как Майкрософт выкатил офигенную логичную фичу. Открываете любой репозиторий, нажимаете "." (точку) и вас кидает в открытый VSCode (открывается он на сайте https://github.dev). Отличий от предыдущего варианта вагон. Во-первых, это полнофункциональная среда разработки с возможностью выбрать цветовую тему, установить расширения, настроить шрифты и все такое. Во-вторых, ваши изменения сразу попадают на гитхаб с возможностью сделать пулл-реквест, если вы внесли правки в чужой репозиторий и сделать прямой коммит, если вы работаете в своем. В сочетании с GitHub Actions это отличная возможность поправить что-то по-быстрому с любого устройства и сразу запустить пайплайн. Ну и в-третьих используя Setting Sync вы можете иметь единообразно настроенную среду разработки, опять-таки, на любом устройстве
#полезняшки
Про отсутствие эго

В рабочем процессе нужно выключать свое эго. И решения стоит принимать не исходя из своей предпочтений, а из того, что двинет ваш проект вперед. Это все относится к "попробовать новые клевые штуки", "я не буду делать, потому что мне не нравится", "я устал от рутины" и все такое. Когда исключаешь "Я" из этого потока и начинаешь принимать решения исходя из business value, то работать становится
а) интереснее
б) эффективнее
Эго в рабочем процессе — это всегда конфликт. Ровно потому, что наши собственные стремления могут расходиться с требованиями бизнеса и надо таки выбирать бизнес. Я так уверенно говорю, потому что я был и на другой стороне баррикад. У меня был опыт запуска своего бизнеса, в который приходилось нанимать людей и как руководитель, я очень хорошо понимал, чего я хочу от сотрудников. Потом, вернувшись обратно в найм, я вспомнил про все вот эти свои хотелки и стал применять их уже в роли наемного работника. Это работает офигенно. Договариваться стало проще, реализовываться стало проще, работать стало интереснее. И когда я попытался суммировать как-то этот опыт, то пришел как раз к очень простому выводу: я выбросил эго и стал думать не про то, как мне хочется, а про то, как это будет полезно. А в итоге в выгоде остаются все, идеальный пример win-win стратегии
Все, что идет в комплекте с JDK — прекрасные, удобные, стабильно работающие вещи: javac, jar, javadoc, java. Наверное, потому что люди, программирующие JDK, на Джаве не пишут.
(с) Тонский
В продолжение поста про nocode. Комментарий "обычного пользователя" к статье, этот самый nocode, восхваляющей

"А теперь посмотреть на [это все] со стороны. И понять, что юзер утонет в этом. Не разберётся. Психанёт. И точно, его час по жизни стоит дешевле, чем у программиста. А значит он нищеброд. А должен придти дядя и всё это настроить и в узлы связать. А перед этим выслушать бизнес-задачу вообще. Или юзер должен потратить много времени. Потому что статья очень техническая. Гуманитарий может осилить 5 кнопок это край"
Вот такая вот прекрасная тема для пятничного вечера. События давно прошли, моя пятая точка погасла, решил поделиться со всеми :)
Краткая предыстория: у нас прилег кластер (что в MCS совершенно обычное будничное событие, они там лежат стабильно раз в неделю), а назывался он k8s-dev
И вот это чудо из саппорта решило, что оно вправе двигать SLA в зависимости от "назначения кластера". То есть если вы не управляете, видимо, медицинским или атомным оборудованием через кубернетес в мейл.ру, то вас можно и подвинуть
Не будьте как #mailru
Про фокус

Фокус — это важно. На это вводную часть закончим и приступим к основной.

Фокус, поток — все это названия одного и того же явления, то самое блаженное состояние, когда из-под вашего пера выходит вдохновенный код, когда все получается и вы получаете истинное удовольствие от своей работы. К сожалению, оно столь же хрупко, сколько прекрасно. Все знают, насколько легко оно разрушается случайным словом, не вовремя пришедшим уведомлением или нелепым вопросом. Раньше я считал поток непродуктивным в силу его нестабильной природы, типа дисциплина лучше и все такое. А потом понял, что события эти не исключают друг друга. Дисциплина нужна, чтобы войти в поток, а поток нужен, чтобы творить вдохновенно. К сожалению, сейчас специфика моей работы такова, что я вынужден общаться с большим количеством коллег, но я все равно стараюсь найти время для потока. 2-3 часа проведенные в нем, дают результат гораздо больший, нежели эти несчастные 8 вымученных часов просиживания задницы в условном офисе, неважно, в реальном или виртуальном.

Главное в бережном отношении к потоку — это сохранять его хрупкость.

Я сейчас скажу страшное для 21 века, но выключите уведомления. Все. Совсем. Навсегда. Неважно, это все неважно, это все может подождать. Красные кружочки жрут ваше внимание большой ложкой, постоянно что-то всплывающее на лок-скрине вашего смартфона требует от вас действия. Даже если вы умеете не обращать на это внимания и усилием воли заставляете себя продолжить работу, тревожность все равно подтачивает там где-то внутри. Она копится, и психотерапевты где-то уже потирают руки, готовясь встретить вас как очередного клиента.

У меня нет уведомлений вообще. Ни на компьютере, ни на телефоне. Они отключены, абсолютно. Исключение составляют только уведомления от банка. Они приходят очень нечасто, их можно потерпеть. И знаете, я чувствую себя хозяином своей жизни. Я проверяю почту и мессенджеры когда удобно мне, а не когда удобно им. В этом мире нет ничего срочного, про пожар в ДЦ вам, я уверен, позвонят гораздо быстрее, чем вы прочитаете сообщение в мессенджере.

Один человек пытался мне возразить: "Хотел бы я жить такой жизнью, но, к сожалению, мне очень важно оперативно получать информацию". Тебе важно просто чувствовать себя важным, мэн, тебе кажется, что все это действительно касается тебя. Потому что иначе придется признать, что твоя жизнь пуста и скучна.

Современные приложения воюют за время пользователя, это единственно ценный товар. Ваше время принадлежит вам. Синк абут ит, как говорили во времена моей молодости
Про принятие

Сегодня интересная тема :) Про принятие нам твердят из каждого утюга, но никто не говорит толком, что именно такое, это принятие. Я какое-то время уже размышляю сам в себе над этим и вывел вот такое определение. Принятие — это не смирение, не прощение и не конформность. Принятие — это умение встроить нечто (этим нечтом может быть событие, человек, процесс, все что угодно) в свою жизнь, в свой повседневный ход мыслей, превратить в рефлекс, если угодно. Принять — значит убрать из объекта принятия триггер эмоций. Когда идет дождь, вы просто берете с собой зонт. Вы не пытаетесь изменить это событие, вы можете для виду поворчать, вы можете даже разозлиться, но знание внутри останется неизменным: дождь идет и это факт. Вы принимаете это как факт.
А причем тут технологии и все вот это?
Я всегда вспоминаю о принятии, когда кто-то начинает спорить о вкусах. Дженкинс vs. тимсити, пайтон vs. голанг, бмв vs. мерседес, oфис vs. удаленка... примеров масса и они вызывают искренние эмоции противостоящих сторон. Меня в последнее время стала интересовать лишь цель, а средства, различающиеся лишь на вкус, все меньше. Я принимаю правила игры и стараюсь играть в нее с максимальной эффективностью.
Про факап на $100K

На интервью я люблю спрашивать про факапы, очень нравится мне слушать такие истории. Кстати, если человек говорит, что фейлов у него в карьере не было, то либо мало работал, либо что-то скрывает. Мне скрывать нечего, косяков я напорол достаточно😃 И вот сегодня расскажу вам историю, как я наказал родную компанию на 100 тысяч долларов

Работал я какое-то время назад в компании, которая занималась монетизацией мобильного трафика. И вот, в какой-то момент времени мы купили китайскую компанию поменьше и ее инфраструктуру надо было интегрировать к нам. А особенностью было то, что компания эта существовала довольно давно и у нее был договор с пачкой мелких китайских вендоров, что их (купленной китайской компании) рекламный SDK был на телефоны этих мелких вендоров предустановлен.

Ну и конечно же шло время, обновлялся андроид, версии SDK обновлялись вслед за ним, а поддержкой этих нонейм-девайсов никто и не морочился. В их ценовой категории дешевле было выпустить новый, чем страдать с поддержкой старого. Но эти девайсы все еще оставались онлайн и генерировали безумное количество паразитного, никому не нужного трафика, который приземлялся на эндпоинты этой купленной китайской компании.

Ну а особенности китайского софтописательства заключались в том, что они пытались сохранить некое подобие обратной совместимости и для новых версий SDK использовали (🤪) теже самые эндпоинты и как-то очень хитровыделанно фильтровали это на балансерах, нормальный трафик пропускали внутрь, а по паразитному отдавали код 400 и благополучно отваливались. Документации на все это естественно не было.

Я еще подивился, что у них схема такая необычная, что весь траф проходит сквозь шесть балансеров на каком-то азиатском хостинге и заворачивается в GCP. В процессе общения (кто общался с китайцами на английском, тот меня поймет) я так толком и не понял для чего это и решил разобраться потом, поджимало время.

Хостились мы тогда у замечательных ребят servers.com, я все это добро затащил у нам в контур, поставил под мониторинг и забыл. Через полтора месяца пишет мне СТО мессагу вида: "Андрей, у нас срочный созвон, через полчаса жду тебя в зуме". Прихожу я в зум, а там несколько директоров и CFO с очень странным выражением лица показывает счет от провайдера на 98 с чем-то тысяч баксов и очень недобро смотрит на меня, спрашивая "откуда все это?". Обычный счет на инфру был в районе ~15К в месяц (точно уже не помню) и я прилично охуел.

Пошли разбираться, быстро нашли причину, я понял основания для балансеров на азиатском хостинге (бесплатный трафик конечно же), быстренько соорудил что-то подобное на каком-то уже европейском хостинге без оплаты за трафик и расходы нормализовались.

Но 100 штук-то были уже потрачены. Я сразу сказал (и не соврал ни на секунду), что компенсировать я это не могу, даже если продам себя по частям, а пожить мне бы все-таки еще хотелось. Так что готов ко всему, выкидывайте меня как щенка нашкодившего если хотите, все было сделано по невнимательности и без злого умысла.

На что мне был дан ответ, что "мое обучение уже обошлось компании в 100 килобаксов и выкидывать меня, по меньшей мере, неразумно" (ну как в известной истории с гитлабом, последствия для инженера были такие же). Вот приятно все-таки работать с умными взрослыми людьми.

В итоге я поднапрягся, пару месяцев работал без выходных и с овертаймами, но таки смог оптимизировать расходы по инфре примерно процентов на 20 и нарисовал график, где мой факап постепенно гасится за счет сэкономленного бабла. В итоге даж премию получил, потому как после погашения моего проеба за счет экономии пошла чистая прибыль.

Вот такая вот история. Вы можете справедливо заметить, что сокращение костов и так являлось моей задачей (я работал в должности Head of Infra) и будете правы. Но в свое оправдание я скажу, что ценник всех устраивал, все было нормально оптимизировано, и за косты мне никто ничего не говорил. Я же проделал очень большую работу с закапыванием в код, кучей коммуникаций с разработчиками и приведения в порядок легаси в одно лицо.

Такая вот история🙂
👍19
Про прошлое, настоящее и будущее

"Как причудливо тасуется колода". Как интересно складывается жизнь. Думаю о людях, с которыми мы вместе когда-то давно начинали этот путь. Тогда никто не мог представить, что нам за это будут платить. Моя мама была уверена, что все, что я заработаю — это севшее зрение и геморрой.

Мы собирались в каких-то тесных каморках, которые гордо именовали "Серверная" (именно так, с большой буквы) и там осваивали всю эту премудрость. Наши компьютеры не очень подходили для игр, зато они прекрасно подходили для первых полусамосборных линуксов. Мне все это волшебством казалось. И ведь все добились чего-то сейчас.

Мой Сэнсей (года на 3-4 он меня младше кстати) прошел путь от админа в компьютерном клубе до CIO, потом внезапно пропал. Через какое-то время выяснилось, что он долго работал у Лебедева, а сейчас у него свой интересный бизнес. Другой мой друг радовался первым маленьким заказикам из-за рубежа, а сейчас генеральный директор одной довольно известной IT-компании с представительствами по всему миру. Моя карьера тоже довольно интересно сложилась, звезд с неба не нахватал, но было очень много всякой интересной движухи.

Что объединяло нас? Мы были и остались... ммм, задротами :) Нердами, хакерами в том первичном, сейчас уже фактически забытом смысле. Мы фигачили за идею и продолжаем это делать. За интерес. Из чистого прекрасного любопытства.

Писать эмуляторы x86 на javanoscript, с головой зарывшись в даташиты? Вай нот.
Раскапывать древний кернел, поспорив про то, как считается LA? Погнали.
Ставить OpenBSD, потому что у кого-то нашлась Та Самая Книжка и хочется радостно поностальгировать? Да легко.

Мне 40 почти, а я до сих пор могу не спать ночь, зарывшись в какую-нибудь прикольную хрень. Правда здоровье уже не то, и обычно на подобные развлечения я трачу ночь с пятницы на субботу, чтобы спокойно отоспаться днем. Осталась до сих пор какая-то магия в этом светящемся ночью мониторе и полной тишине. Какое-то вот это чувство, которое никому не объяснить, а тому, кто знаком с ним, и объяснять ничего не надо. Все понятно с полувзгляда, без слов.

Ох, старпёрский ностальгический пост получился🤓 Осень, чето накатило...
Завершить хочу прекраснейшим текстом Гриши Бакунова (aka bobuk), человека, не нуждающегося в представлении. Сотни раз читан и перечитан этот текст, очень крутой
https://github.com/bobuk/addmeto.cc/blob/master/pages/2013-04-19.md
👍2