Апдейты!
Уже рассказывал, как я слежу за качеством воздуха в своем кабинете🤵 . За прошедшие год с небольшим провел ряд изменений для повышения качества работы и жизни через повышение качества воздуха. Все это в основном касается периода отопления, когда проблематично проветривать квартиру.
1️⃣ В дополнение к Qingping Air Quality Monitor первого поколения приобрел монитор второго поколения
Напомню про хороший обзор здесь. Что изменилось?
* поставили более продвинутые сенсоры CO2 и VOC (летучие органические соединения)
* в дополнение к сенсору твердых частиц до 2.5 микронов PM2.5 добавили сенсор PM10 (до 10 микронов)
* в целом сенсор PM теперь заменяемый (в первой модели он приказал долго жить), даже нашел его на Ali
* появилась возможность подключить к Алисе (еще не проверял)
* увеличили экран почти на дюйм (разница колоссальная)
* добавили измерение уровня шума (ок, пусть будет)
* в целом появилось больше гибкости в настройке
Пока они оба стоят у рабочего места (сверяю показания), но потом один из них переедет в спальню.
2️⃣ В спальню и кабинет поставил бризеры
Остановился на Тион 4S. Удовольствие не дешевое, но теперь нет необходимости постоянно открывать/закрывать окна или выверять щель для проветривания, чтобы впустить свежий, но очень холодный воздух (функция подогрева воздуха прекрасно справляется со своей задачей). Ночью теперь тоже спать очень комфортно. На второй скорости (из 6) бризер практически не слышно, но показатели CO2 остаются в норме.
3️⃣ Начал активнее пользоваться увлажнителем воздуха, чтобы не сушить слизистые
Несмотря на то, что относительная влажность (ОВ) воздуха на улице зимой может быть высокой (90%+), абсолютная влажность воздуха остается очень низкой из-за низкой емкости холодного воздуха. При нагревании в помещении такого воздуха ОВ снижается ниже комфортных 40%+.
На что тут стоит обратить внимание при выборе?
* тип увлажнения (ультразвуковые / естественного типа)
* как мыть / обслуживать
* за счет чего обеспечиваются антибактериальные свойства (серебряные картриджи / добавки в воду / антимикробные фильтры / УФ-лампы)
* объем бака с водой (как часто будете доливать воду)
* производительность под вашу квадратуру
* шум в ночном режиме и соответствующая производительность (к сожалению, почти нигде не афишируется)
* расходные материалы и их наличие в продаже
Мне верой и правдой трудится купленный более 5 лет назад iClima LUX-8000. Для того, чтобы реже его обслуживать (основная проблема всех увлажнителей воздуха) докупил серебряный стержень от мойки другого производителя.
Тут отмечу, что ультразвуковые увлажнители сложнее держать в чистоте. Они испаряют все, что в них налито, поэтому антибактериальный эффект можно достичь только (?) с помощью УФ-лампы. С учетом всего перечисленного перспективно выглядит их новая модель. Еще из интересных вариантов могу отметить Boneco, Venta, Stadler Form и Panasonic. Но, конечно, понимание об удачности той или иной модели приходит только по итогам эксплуатации хотя бы в течение сезона.
4️⃣ Поставил умные терморадиаторы на батареи.
Теперь есть возможность более точно регулировать температуру и делать спальню на ночь более прохладной.
Чувствую себя прекрасно, чего и вам желаю! Крепкого здоровья, всех благ❤️
Уже рассказывал, как я слежу за качеством воздуха в своем кабинете
Напомню про хороший обзор здесь. Что изменилось?
* поставили более продвинутые сенсоры CO2 и VOC (летучие органические соединения)
* в дополнение к сенсору твердых частиц до 2.5 микронов PM2.5 добавили сенсор PM10 (до 10 микронов)
* в целом сенсор PM теперь заменяемый (в первой модели он приказал долго жить), даже нашел его на Ali
* появилась возможность подключить к Алисе (еще не проверял)
* увеличили экран почти на дюйм (разница колоссальная)
* добавили измерение уровня шума (ок, пусть будет)
* в целом появилось больше гибкости в настройке
Пока они оба стоят у рабочего места (сверяю показания), но потом один из них переедет в спальню.
Остановился на Тион 4S. Удовольствие не дешевое, но теперь нет необходимости постоянно открывать/закрывать окна или выверять щель для проветривания, чтобы впустить свежий, но очень холодный воздух (функция подогрева воздуха прекрасно справляется со своей задачей). Ночью теперь тоже спать очень комфортно. На второй скорости (из 6) бризер практически не слышно, но показатели CO2 остаются в норме.
Несмотря на то, что относительная влажность (ОВ) воздуха на улице зимой может быть высокой (90%+), абсолютная влажность воздуха остается очень низкой из-за низкой емкости холодного воздуха. При нагревании в помещении такого воздуха ОВ снижается ниже комфортных 40%+.
На что тут стоит обратить внимание при выборе?
* тип увлажнения (ультразвуковые / естественного типа)
* как мыть / обслуживать
* за счет чего обеспечиваются антибактериальные свойства (серебряные картриджи / добавки в воду / антимикробные фильтры / УФ-лампы)
* объем бака с водой (как часто будете доливать воду)
* производительность под вашу квадратуру
* шум в ночном режиме и соответствующая производительность (к сожалению, почти нигде не афишируется)
* расходные материалы и их наличие в продаже
Мне верой и правдой трудится купленный более 5 лет назад iClima LUX-8000. Для того, чтобы реже его обслуживать (основная проблема всех увлажнителей воздуха) докупил серебряный стержень от мойки другого производителя.
Тут отмечу, что ультразвуковые увлажнители сложнее держать в чистоте. Они испаряют все, что в них налито, поэтому антибактериальный эффект можно достичь только (?) с помощью УФ-лампы. С учетом всего перечисленного перспективно выглядит их новая модель. Еще из интересных вариантов могу отметить Boneco, Venta, Stadler Form и Panasonic. Но, конечно, понимание об удачности той или иной модели приходит только по итогам эксплуатации хотя бы в течение сезона.
Теперь есть возможность более точно регулировать температуру и делать спальню на ночь более прохладной.
Чувствую себя прекрасно, чего и вам желаю! Крепкого здоровья, всех благ
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥3👍2
Все же заметили, что пошел повальный тренд внедрения геймификации? Многие любят играть в компьютерные (мои любимые — серия Command & Conquer: Red Alert и первая Stronghold Crusader) , мобильные и браузерные игры, чувствовать азарт, наблюдать за своим прогрессом, выигрывать. Значит этими нашими слабостями можно воспользоваться, чем и пользуются индустрии 👉
Для меня это особенно заметно в мобильных приложениях маркетплейсов и банков. Понятно, почему: у них есть большие бюджеты и в то же время плотное взаимодействие с партнёрами-продавцами. Крючки могут быть самыми разными: кэшбэки, скидки на товары, розыгрыш ценных и не очень призов и т.д.
При этом механика для завоевания внимания пользователя и его свободного времени обычно довольно "ядовитая" — задания и награды появляются каждый день, соответственно от вас требуется ежедневная активность. "Электронные" адвент-календари под Новый год — самый яркий пример. Даже не представляю, насколько выросли метрики DAU и время, проведенное в приложениях у тех, кто успел подсуетиться.
Признаюсь, сам грешен. Друг работает в Telegram — скинул в конце ноября мне их предновогоднюю игру Gift Fest, в которой можно выиграть реальные деньги. И я выиграл:
Точно стоило потраченного времени😃 Простые механики + азарт сделали свое дело. Эта игра хоть и сжигает время, но достаточно безобидна.
А вот кэшбэки и промкоды в банках и маркетплейсах, на мой взгляд, опаснее. В голове пользователя начинают постоянно проскальзывать мысли: "А ведь я могу получить хороший кэшбэк на товар, который мне нужен. Это не требует от меня почти никаких усилий, но сэкономит заработанные большим трудом деньги". Это побуждает все больше времени тратить в приложении, чтобы заполучить выгоду. Обычно установленных банковских и приложений маркетплейсов несколько, что усугубляет ситуацию: "Сейчас я найду, где максимальная скидка на эту подписку. Я точно где-то её видел. Не могу же я её упустить."
Это начинает напоминать лудоманию: один раз удачно получилось "выиграть" на покупке — и мозг ждёт повторения чуда. А "подкормить" нас несложно: по истории покупок можно достаточно точно подсовывать персонализированный кэшбэк.
Ещё заметил, что некоторые сервисы, если ими пользоваться точечно, проводя лишь избранные транзакции, будут долго и упорно подсовывать очень выгодные предложения, пытаясь переманить вас на свою сторону.
Кажется, немало людей уже заработали тревожность от недополучения часто эфемерной прибыли. Неудивительно, что даже термин для этого есть — FOMO, Fear of Missing Out — синдром упущенной выгоды / страх пропустить что-то интересное.
Нужна ли нам вся эта гонка или лучше вложить свои силы в что-то более важное?
P.S. Осталось только выгодно подарки все под Новый год купить💳
Для меня это особенно заметно в мобильных приложениях маркетплейсов и банков. Понятно, почему: у них есть большие бюджеты и в то же время плотное взаимодействие с партнёрами-продавцами. Крючки могут быть самыми разными: кэшбэки, скидки на товары, розыгрыш ценных и не очень призов и т.д.
При этом механика для завоевания внимания пользователя и его свободного времени обычно довольно "ядовитая" — задания и награды появляются каждый день, соответственно от вас требуется ежедневная активность. "Электронные" адвент-календари под Новый год — самый яркий пример. Даже не представляю, насколько выросли метрики DAU и время, проведенное в приложениях у тех, кто успел подсуетиться.
Признаюсь, сам грешен. Друг работает в Telegram — скинул в конце ноября мне их предновогоднюю игру Gift Fest, в которой можно выиграть реальные деньги. И я выиграл:
Поздравляем, ты выиграл в Розыгрыше №3 Wallet Акции и Фонды — $1 в токенизированных акциях (TSLAx, AAPLx, NVDAx, GOOGLx)!
Точно стоило потраченного времени
А вот кэшбэки и промкоды в банках и маркетплейсах, на мой взгляд, опаснее. В голове пользователя начинают постоянно проскальзывать мысли: "А ведь я могу получить хороший кэшбэк на товар, который мне нужен. Это не требует от меня почти никаких усилий, но сэкономит заработанные большим трудом деньги". Это побуждает все больше времени тратить в приложении, чтобы заполучить выгоду. Обычно установленных банковских и приложений маркетплейсов несколько, что усугубляет ситуацию: "Сейчас я найду, где максимальная скидка на эту подписку. Я точно где-то её видел. Не могу же я её упустить."
Это начинает напоминать лудоманию: один раз удачно получилось "выиграть" на покупке — и мозг ждёт повторения чуда. А "подкормить" нас несложно: по истории покупок можно достаточно точно подсовывать персонализированный кэшбэк.
Ещё заметил, что некоторые сервисы, если ими пользоваться точечно, проводя лишь избранные транзакции, будут долго и упорно подсовывать очень выгодные предложения, пытаясь переманить вас на свою сторону.
Кажется, немало людей уже заработали тревожность от недополучения часто эфемерной прибыли. Неудивительно, что даже термин для этого есть — FOMO, Fear of Missing Out — синдром упущенной выгоды / страх пропустить что-то интересное.
Нужна ли нам вся эта гонка или лучше вложить свои силы в что-то более важное?
P.S. Осталось только выгодно подарки все под Новый год купить
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍1🤔1🌚1
Постепенно выхожу из зимней спячки. Мысли пришли в движение, и я наконец понял для себя, за что люблю Новый год.
Перелистывание календаря в этот день для многих — событие, которое наполнено особым символизмом. Люди в этот день делятся теплыми пожеланиями и ставят цели. И эти цели обычно про то, как стать лучше в следующем году.
«Я должен подставить в этом году ещё больше людей», «в этом году я хочу разочароваться в людях окончательно», «мои ошибки в этом году должны стать фатальными». Ничего подобного я никогда не слышал, по крайней мере вслух.
И не так важно, что большинству поставленных амбициозных и не очень целей не суждено сбыться по самым разным причинам. Некоторые забывают о них буквально первого января или в лучшем случае сразу после праздников. Важен сам факт: для многих это возможность на момент остановиться и задуматься, куда стоит идти дальше, чем заниматься и как жить...
Вообще-то этим можно заниматься не привязываясь к конкретной дате, которая наступает неизменно, но всего раз в году. Просто так принято. И это, как по мне, уже неплохо.
А Новый год я люблю за длинные выходные😃
Перелистывание календаря в этот день для многих — событие, которое наполнено особым символизмом. Люди в этот день делятся теплыми пожеланиями и ставят цели. И эти цели обычно про то, как стать лучше в следующем году.
«Я должен подставить в этом году ещё больше людей», «в этом году я хочу разочароваться в людях окончательно», «мои ошибки в этом году должны стать фатальными». Ничего подобного я никогда не слышал, по крайней мере вслух.
И не так важно, что большинству поставленных амбициозных и не очень целей не суждено сбыться по самым разным причинам. Некоторые забывают о них буквально первого января или в лучшем случае сразу после праздников. Важен сам факт: для многих это возможность на момент остановиться и задуматься, куда стоит идти дальше, чем заниматься и как жить...
Вообще-то этим можно заниматься не привязываясь к конкретной дате, которая наступает неизменно, но всего раз в году. Просто так принято. И это, как по мне, уже неплохо.
А Новый год я люблю за длинные выходные
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4😁1
Как вам этот интерфейс?
Авторы книги Pro Spring 6, An In-Depth Guide to the Spring Framework утверждают, что:
Иными словами поместить такие методы конфигурации в бизнес-интерфейс — отличная идея. Называются следующие достаточно созвучные причины:
1️⃣ Configuration parameters are passive
Параметр
2️⃣ Configuration parameters are usually information, not other components
Здесь упор на то, что адрес
3️⃣ Configuration parameters are usually simple values or collections of simple values
Конфигурационные параметры или их коллекции достаточно примитивны и их невозможно по определению использовать неправильно.
Написано всё вполне логично! Однако обратимся к типичному использованию такого интерфейса в Spring-приложении:
Очевидно, что из всего многообразия методов в
Авторы, простите, но такой код на Spring'е нам не нужóн!
public interface NewsletterSender {
void setSmtpServer(String smtpServer);
String getSmtpServer();
void setFromAddress(String fromAddress);
String getFromAddress();
void send();
}Авторы книги Pro Spring 6, An In-Depth Guide to the Spring Framework утверждают, что:
Thus, placing setters and getters for configuration parameters in the business interface is a good idea and makes setter injection a valuable tool.
Иными словами поместить такие методы конфигурации в бизнес-интерфейс — отличная идея. Называются следующие достаточно созвучные причины:
1️⃣ Configuration parameters are passive
Параметр
smtpServer — пример пассивной зависимости, он сам не выполняет никаких действий, а лишь используется под капотом, в том числе другими (активными) зависимостями.2️⃣ Configuration parameters are usually information, not other components
Здесь упор на то, что адрес
smtpServer не является частью нашей системы/архитектуры. Условный набор эвристик (правил поведения) List<Rule> rules(), разрешающий/запрещающий отправку письма является контрпримером этого правила.3️⃣ Configuration parameters are usually simple values or collections of simple values
Конфигурационные параметры или их коллекции достаточно примитивны и их невозможно по определению использовать неправильно.
Написано всё вполне логично! Однако обратимся к типичному использованию такого интерфейса в Spring-приложении:
@Service
public Service NewsletterService {
private final NewsletterSender newsletterSender;
...
}
Очевидно, что из всего многообразия методов в
NewsletterService будет использоваться только void send(). А теперь, как бы это пошло ни звучало, обратимся к принципам SOLID, а именно к interface segregation principle (ISP), который гласит, что код не должен зависеть от методов, которые он не использует. Лишние методы еще и раскрывают детали реализации, указывая протокол в сигнатуре метода. Вишенкой на торте является передача параметров в "сыром" типе String, вместо специализированных классов, где не будет возможности ошибиться, передав адрес, например, в некорректном формате.Авторы, простите, но такой код на Spring'е нам не нужóн!
👍2❤1💯1
😁11
Почему каждый раз не делают собственное (простое / понятное / маленькое) решение, а берут Open Source?
Мы в банке часто пишем свои стартеры, библиотеки, боты и т.д. Хорошо ли это? Предлагаю обсудить.
1️⃣ Нет универсальности
Универсальность — обоюдоострый клинок. С одной стороны заточенное под решение нашей задачи ПО будет лучше справляться(по крайней мере после нескольких итераций разработки 😃 ) с этой самой задачей. С другой стороны любой шаг в сторону от исходной проблемы, о которой мы ранее даже не могли подумать, может потребовать значительной переработки архитектуры / кодовой базы исходного решения. Взрослый Open Source уже прошёл через все эти грабли, так как используется многими командами для решения разных задач со своими ограничениями.
2️⃣ Нет "бесплатных" мейнтейнеров
А значит нужно на постоянной основе выделять на это внутренний ресурс. Фичи не появятся сами собой, а баги не будут закрываться. В этом смысле заменить группу увлеченных энтузиастов не так просто.
Разработчики обычно не любят вникать в очень специфичные решения, которые более нигде, кроме как в вашей компании не используются. Будет проще, если это библиотека, которая решает распространенные задачи по типу кэширования / логирования / работы с БД и т.п.
3️⃣ Ограниченное коммьюнити
Вы будете чуть ли не один на один со своей проблемой, как с точки зрения разработки, так и с точки зрения эксплуатации. Хорошо, если вокруг внутреннего решения организовалось сильное комьюнити, которое подскажет и может подхватить написание кода. Если внутренний заинтересованный мейнтейнер всего один, то велика вероятность, что без него всё развитие проекта сойдёт на нет.
4️⃣ Вы всегда альфа- или бета-тестер
Обычно новые внутренние решения проходят процедуру "пилота", когда на нескольких командах-добровольцах отлавливаются детские проблемы. Моя команда много раз в числе первых подключала новые библиотеки, сервисы, процессы и т.д. И каждый раз это была боль, которую нам приходилось перетерпеть: это и падающие тесты, и несостыковки контрактов, и баги, из-за которых съезжал релизный цикл. Радует то, что мы до сих пор используем все те решения, они показали свою состоятельность. Но и флэшбэки одолевают нас до сих пор😢 А прямо сейчас правлю баг в библиотеке кэширования на стыке near-cache и синхронизации записи несколькими потоками по одному ключу... Кстати, этому багу год, но нарвались в проде на него почему-то только сейчас.
5️⃣ Вопросы безопасности
Безопасная разработка — по сути отдельная высокооплачиваемая профессия профессия, которую надо бы иметь всем, но большинство разработчиков имеют слабое (ограниченное) представление. Почему? Это сложно → таких людей мало (а задач много) → они занимаются своими узкоспециализированными вопросами, на всех их не хватает.
Понятное дело, что Open Source тоже дырявый, но он больше челенджится энтузиастами и становится лучше. Внутренние решения могут игнорировать этот аспект вовсе. И уж точно сложно представить, что кто-то пойдет пилить свой легковесный аналог Keycloak'а.
———
Тем не менее внутренние разработки должны быть. Мы упростили множество процессов и рутины благодаря им. Со временем плохие / невостребованные решения отмирают, а хорошие — приживаются и эффективно решают поставленные задачи, часто сами перерастая в Open Source решения.
Мы в банке часто пишем свои стартеры, библиотеки, боты и т.д. Хорошо ли это? Предлагаю обсудить.
Универсальность — обоюдоострый клинок. С одной стороны заточенное под решение нашей задачи ПО будет лучше справляться
А значит нужно на постоянной основе выделять на это внутренний ресурс. Фичи не появятся сами собой, а баги не будут закрываться. В этом смысле заменить группу увлеченных энтузиастов не так просто.
Разработчики обычно не любят вникать в очень специфичные решения, которые более нигде, кроме как в вашей компании не используются. Будет проще, если это библиотека, которая решает распространенные задачи по типу кэширования / логирования / работы с БД и т.п.
Вы будете чуть ли не один на один со своей проблемой, как с точки зрения разработки, так и с точки зрения эксплуатации. Хорошо, если вокруг внутреннего решения организовалось сильное комьюнити, которое подскажет и может подхватить написание кода. Если внутренний заинтересованный мейнтейнер всего один, то велика вероятность, что без него всё развитие проекта сойдёт на нет.
Обычно новые внутренние решения проходят процедуру "пилота", когда на нескольких командах-добровольцах отлавливаются детские проблемы. Моя команда много раз в числе первых подключала новые библиотеки, сервисы, процессы и т.д. И каждый раз это была боль, которую нам приходилось перетерпеть: это и падающие тесты, и несостыковки контрактов, и баги, из-за которых съезжал релизный цикл. Радует то, что мы до сих пор используем все те решения, они показали свою состоятельность. Но и флэшбэки одолевают нас до сих пор
Безопасная разработка — по сути отдельная высокооплачиваемая профессия профессия, которую надо бы иметь всем, но большинство разработчиков имеют слабое (ограниченное) представление. Почему? Это сложно → таких людей мало (а задач много) → они занимаются своими узкоспециализированными вопросами, на всех их не хватает.
Понятное дело, что Open Source тоже дырявый, но он больше челенджится энтузиастами и становится лучше. Внутренние решения могут игнорировать этот аспект вовсе. И уж точно сложно представить, что кто-то пойдет пилить свой легковесный аналог Keycloak'а.
———
Тем не менее внутренние разработки должны быть. Мы упростили множество процессов и рутины благодаря им. Со временем плохие / невостребованные решения отмирают, а хорошие — приживаются и эффективно решают поставленные задачи, часто сами перерастая в Open Source решения.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🤔1🌚1
😁2
На работе прилетело несколько интересных задач. Сегодня поделюсь одной из них.
Саппорт (функциональное сопровождение) прода пришел с жалобой на то, что алертинг, настроенный на логи, не может нормально работать. Причина простая: у большинства документов в Elasticsearch (ES), который мы используем как хранилище логов, по одной и той же ошибке (один и тот же
Почему так происходит? В полене😃 не😃
Важно отметить еще один неприятный побочный эффект. Если посмотреть на то, как работает ES, то, очевидно, мы получаем распухшие индексы и медленные агрегации.
Как решить проблему? Убрать лишнее из
Раз уж придется лезть в эту историю, то как будто хочется заиметь еще одно поле, которое будет отвечать за категорию (идентификатор) проблемы. Каждая категория — отдельный код. Мы заранее составляем справочник таких кодов и в логах используем их. Один и тот же код может использоваться сразу во многих местах для однотипных ситуаций. Кажется, что это должно быть удобно как для алертинга, так и для анализа, в т. ч. построения дашбордов. Надо подумать🎹
Саппорт (функциональное сопровождение) прода пришел с жалобой на то, что алертинг, настроенный на логи, не может нормально работать. Причина простая: у большинства документов в Elasticsearch (ES), который мы используем как хранилище логов, по одной и той же ошибке (один и тот же
logger.error(...) в коде) разное значение поля message.Почему так происходит? В поле
message кроме непосредственно описания происходящего мы часто фиксируем уникальные идентификаторы / параметры / свойства (и т.п.) важные для последующего анализа. И именно по этому полю Важно отметить еще один неприятный побочный эффект. Если посмотреть на то, как работает ES, то, очевидно, мы получаем распухшие индексы и медленные агрегации.
Как решить проблему? Убрать лишнее из
message. Совсем? Потеряем в информативности. Тогда вынесем "лишнее" в отдельное новое поле документа по аналогии с тем, как это делают с userId и traceId и другими. Как его назвать? Мне пока нравится универсальное context, так как содержимое от лога к логу в среднем будет абсолютно разное.Раз уж придется лезть в эту историю, то как будто хочется заиметь еще одно поле, которое будет отвечать за категорию (идентификатор) проблемы. Каждая категория — отдельный код. Мы заранее составляем справочник таких кодов и в логах используем их. Один и тот же код может использоваться сразу во многих местах для однотипных ситуаций. Кажется, что это должно быть удобно как для алертинга, так и для анализа, в т. ч. построения дашбордов. Надо подумать
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥2
Соскучились? Я тоже 👋
Только вернулся с тура по Байкалу! Отпраздновали день рождения и проводили на топовую позицию в международной компании нашего дорогого друга!
Красивая, вкусная и насыщенная на эмоции поездка. Мы ни в чём себе не отказывали и за неделю уложились в скромные ~250 т.р. на человека с учётом проживания и дороги😕
А ещё нам два раза несказанно повезло!
Мы не утонули. В последние дни было особенно тепло и лёд активно расходился. К сожалению, одна буханка с группой китайских туристов ушла на дно озера.
Не пересеклись с Шаманом. Без комментариев.
Всем прекрасных длинных выходных!
Только вернулся с тура по Байкалу! Отпраздновали день рождения и проводили на топовую позицию в международной компании нашего дорогого друга!
Красивая, вкусная и насыщенная на эмоции поездка. Мы ни в чём себе не отказывали и за неделю уложились в скромные ~250 т.р. на человека с учётом проживания и дороги
А ещё нам два раза несказанно повезло!
Мы не утонули. В последние дни было особенно тепло и лёд активно расходился. К сожалению, одна буханка с группой китайских туристов ушла на дно озера.
Не пересеклись с Шаманом. Без комментариев.
Всем прекрасных длинных выходных!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤5👍2
Всё! Больше никаких Merge Request! Как собственно и Pull Request... Шутка! Пока что...
Давече прочитал уморительную статью "Законъ о запрете иностранных словъ… в разработке". Причиной появления оной послужила новость:
Ну как будто в рознице все уже и так давно его соблюдают. А что делать нам, айтишникам, если разработку тоже русифицируют?
Предлагаю план из двух пунктов:
1. начать активно читать переведенные иностранные издания (для меня они абсолютно нечитабельные, вспомнить хотя бы Java Concurrency In Practice под авторством Brian Goetz)
2. запастись словарём иностранных слов. Почему им? Читай нормативы!
А знаете, что-то в этом есть. Не грубое legacy, анациональное достояние культурное наследие 😃 .
Давече прочитал уморительную статью "Законъ о запрете иностранных словъ… в разработке". Причиной появления оной послужила новость:
С 1 марта 2026 вся публичная информация для потребителя должна быть на русском — № 168-ФЗ.
Ну как будто в рознице все уже и так давно его соблюдают. А что делать нам, айтишникам, если разработку тоже русифицируют?
Предлагаю план из двух пунктов:
1. начать активно читать переведенные иностранные издания (для меня они абсолютно нечитабельные, вспомнить хотя бы Java Concurrency In Practice под авторством Brian Goetz)
2. запастись словарём иностранных слов. Почему им? Читай нормативы!
А знаете, что-то в этом есть. Не грубое legacy, а
Please open Telegram to view this post
VIEW IN TELEGRAM
😁5
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3😁3