30PARA
или как я навел порядок в заметках (и не только)
Сколько раз у вас было такое: открыл Obsidian, а там полный хаос? В одной заметке мысли по проекту, в другой — случайные цитаты, где-то ссылка на статью, которая «точно пригодится» (но ты уже забыл, зачем). У меня так было постоянно. Решил, что пора с этим что-то делать, и наткнулся на метод PARA от Тиаго Форте.
⚡ В чем суть? Все заметки (да и вообще любая информация) делятся на 4 категории:
📂 Projects (Проекты) — текущие задачи с четким результатом.
Что у меня в этой папке?
Разработка Telegram-бота — заметки по архитектуре, багам, идеи по фичам.
Подготовка к конференции — тезисы выступления, список примеров, которые хочу использовать.
Продвижение блога — контент-план, идеи для постов, статистика.
📂 Areas (Области ответственности) — долгосрочные сферы жизни.
Что у меня в этой папке?
Фитнес — программа тренировок, прогресс, заметки по питанию.
Финансы — личный бюджет, инвестиции, список крупных целей.
Развитие — книги, которые читаю, идеи для новых навыков.
📂 Resources (Ресурсы) — полезные материалы без привязки к дедлайнам.
Что у меня тут?
Конспекты книг — краткие выводы, чтобы не перечитывать заново.
Статьи по разработке — крутые гайды, которые стоит изучить.
Шаблоны и чек-листы — например, как быстро собрать лендинг или подготовиться к переговорам.
📂 Archive (Архив) — то, что уже не актуально, но может пригодиться.
Что я туда отправил?
Старые проекты — дипломная работа, идеи, которые пока не реализовал.
Заметки по прошлым курсам — мало ли, вдруг когда-то снова понадобится.
Старые планы и цели — интересно иногда пересматривать и анализировать.
Сначала я навел порядок только в Obsidian, но потом понял, что это реально удобно. В итоге:
✅ Файлы на ноуте теперь тоже разложены по этой системе.
✅ Закладки в браузере разбиты по тем же категориям (вместо тысяч «прочитать потом»).
✅ Даже в голове стало легче — когда знаешь, где искать нужную инфу, мозг не перегревается.
Если у вас тоже цифровой бардак — попробуйте PARA. Внедряется за 30 минут, а пользы на годы вперед. 🚀
#толки
или как я навел порядок в заметках (и не только)
Сколько раз у вас было такое: открыл Obsidian, а там полный хаос? В одной заметке мысли по проекту, в другой — случайные цитаты, где-то ссылка на статью, которая «точно пригодится» (но ты уже забыл, зачем). У меня так было постоянно. Решил, что пора с этим что-то делать, и наткнулся на метод PARA от Тиаго Форте.
⚡ В чем суть? Все заметки (да и вообще любая информация) делятся на 4 категории:
📂 Projects (Проекты) — текущие задачи с четким результатом.
Что у меня в этой папке?
Разработка Telegram-бота — заметки по архитектуре, багам, идеи по фичам.
Подготовка к конференции — тезисы выступления, список примеров, которые хочу использовать.
Продвижение блога — контент-план, идеи для постов, статистика.
📂 Areas (Области ответственности) — долгосрочные сферы жизни.
Что у меня в этой папке?
Фитнес — программа тренировок, прогресс, заметки по питанию.
Финансы — личный бюджет, инвестиции, список крупных целей.
Развитие — книги, которые читаю, идеи для новых навыков.
📂 Resources (Ресурсы) — полезные материалы без привязки к дедлайнам.
Что у меня тут?
Конспекты книг — краткие выводы, чтобы не перечитывать заново.
Статьи по разработке — крутые гайды, которые стоит изучить.
Шаблоны и чек-листы — например, как быстро собрать лендинг или подготовиться к переговорам.
📂 Archive (Архив) — то, что уже не актуально, но может пригодиться.
Что я туда отправил?
Старые проекты — дипломная работа, идеи, которые пока не реализовал.
Заметки по прошлым курсам — мало ли, вдруг когда-то снова понадобится.
Старые планы и цели — интересно иногда пересматривать и анализировать.
Сначала я навел порядок только в Obsidian, но потом понял, что это реально удобно. В итоге:
✅ Файлы на ноуте теперь тоже разложены по этой системе.
✅ Закладки в браузере разбиты по тем же категориям (вместо тысяч «прочитать потом»).
✅ Даже в голове стало легче — когда знаешь, где искать нужную инфу, мозг не перегревается.
Если у вас тоже цифровой бардак — попробуйте PARA. Внедряется за 30 минут, а пользы на годы вперед. 🚀
#толки
👍1
DevEx? а я думал сова 🦉
Сегодня наткнулся на статью про Developer Experience (DevEx) и подумал: «О, что-то новенькое!». Но чем дальше читал, тем больше понимал — это просто модное название для адекватно настроенных рабочих процессов.
То есть, представь себе компанию, где:
✅ Рабочее окружение настраивается за 5 минут, а не за неделю.
✅ Доступы выдаются автоматически, а не через квест с тремя согласованиями.
✅ Деплой понятен даже джуну, а не превращается в «давай позовем DevOps».
✅ Метрики доступны, логирование удобное, а не «ну посмотри в Kibana, только тебе туда пока доступа нет».
Это не DevEx, это нормальная разработка.
❌ Почему DevEx вообще обсуждают?
Потому что многие разработчики до сих пор:
🚧 Тратят часы (а то и дни) на настройку окружения.
🚧 Страдают с деплоем из-за ошибок вроде «не та версия библиотеки» или «нужно пересобрать вручную».
🚧 Не видят, что происходит на проде, потому что «метрики у админов».
🚧 Вынуждены заполнять заявки, чтобы просто начать работать.
И все это в компаниях, которые вешают на офисные стены слова «инновации» и «эффективность».
🔥 Почему это вообще проблема?
Потому что плохой DevEx — это не просто раздражающий геморрой. Это:
⚡ Упущенная прибыль, когда разработчики решают не бизнес-задачи, а бюрократию.
⚡ Выгорание, когда даже простая задача превращается в мучение.
⚡ Текучка кадров, потому что никто не хочет страдать.
Но компании почему-то думают, что бесплатные печеньки и корпоративный фитнес это решат.
💡 Что с этим делать?
В идеальном мире DevEx даже не должен быть темой разговора, потому что нормальные процессы должны быть стандартом.
Но раз уж мы живем не в идеальном мире, вот что поможет:
✔ Автоматизировать рутинные процессы: CI/CD, выдача доступов, настройка окружения.
✔ Давать разработчикам информацию, а не прятать метрики за семью паролями.
✔ Упрощать деплой и тестирование, а не превращать их в квест.
✔ Слушать разработчиков, а не только топ-менеджмент.
🎯 Итог: это не DevEx, а просто нормальная разработка
Если в вашей компании говорят «мы улучшаем DevEx», это, скорее всего, значит «мы просто пытаемся сделать так, чтобы работа не была болью».
Как у вас с этим? Делитесь в комментах! 👇
#толки
Сегодня наткнулся на статью про Developer Experience (DevEx) и подумал: «О, что-то новенькое!». Но чем дальше читал, тем больше понимал — это просто модное название для адекватно настроенных рабочих процессов.
То есть, представь себе компанию, где:
✅ Рабочее окружение настраивается за 5 минут, а не за неделю.
✅ Доступы выдаются автоматически, а не через квест с тремя согласованиями.
✅ Деплой понятен даже джуну, а не превращается в «давай позовем DevOps».
✅ Метрики доступны, логирование удобное, а не «ну посмотри в Kibana, только тебе туда пока доступа нет».
Это не DevEx, это нормальная разработка.
❌ Почему DevEx вообще обсуждают?
Потому что многие разработчики до сих пор:
🚧 Тратят часы (а то и дни) на настройку окружения.
🚧 Страдают с деплоем из-за ошибок вроде «не та версия библиотеки» или «нужно пересобрать вручную».
🚧 Не видят, что происходит на проде, потому что «метрики у админов».
🚧 Вынуждены заполнять заявки, чтобы просто начать работать.
И все это в компаниях, которые вешают на офисные стены слова «инновации» и «эффективность».
🔥 Почему это вообще проблема?
Потому что плохой DevEx — это не просто раздражающий геморрой. Это:
⚡ Упущенная прибыль, когда разработчики решают не бизнес-задачи, а бюрократию.
⚡ Выгорание, когда даже простая задача превращается в мучение.
⚡ Текучка кадров, потому что никто не хочет страдать.
Но компании почему-то думают, что бесплатные печеньки и корпоративный фитнес это решат.
💡 Что с этим делать?
В идеальном мире DevEx даже не должен быть темой разговора, потому что нормальные процессы должны быть стандартом.
Но раз уж мы живем не в идеальном мире, вот что поможет:
✔ Автоматизировать рутинные процессы: CI/CD, выдача доступов, настройка окружения.
✔ Давать разработчикам информацию, а не прятать метрики за семью паролями.
✔ Упрощать деплой и тестирование, а не превращать их в квест.
✔ Слушать разработчиков, а не только топ-менеджмент.
🎯 Итог: это не DevEx, а просто нормальная разработка
Если в вашей компании говорят «мы улучшаем DevEx», это, скорее всего, значит «мы просто пытаемся сделать так, чтобы работа не была болью».
Как у вас с этим? Делитесь в комментах! 👇
#толки
👍1
💨 Как я бросил курить и почему это оказалось проще, чем казалось
В одном из прошлых постов я обещал рассказать, как прошел путь от заядлого курильщика до человека, который уже почти три года не берет сигарету в руки.
С тех пор в моей жизни многое изменилось: привычки, режим, осознанность. Но сегодня не об этом. Сегодня — о том, как я быстро и окончательно бросил курить и какие выводы сделал.
🚬 Курил, пытался бросить, курил снова
Как и все курильщики, я много раз говорил себе: «Все, завязываю». Но каждый раз заканчивалось примерно одинаково: ритуальное «последнее» стреляние сигарет, несколько дней без табака, потом «одну и всё» — и привет, старые привычки.
Но однажды что-то изменилось.
👶 Узнал, что стану отцом
Когда я узнал, что скоро у меня родится ребенок, в голове запустился необратимый процесс осознания ответственности. И первое, что я решил — бросить курить.
Раз уж все советуют книгу Алана Карра, я выбрал аудиоверсию и стал слушать её во время прогулок с собакой… куря при этом сигарету.
🧠 Одна мысль, которая перевернула всё
По ходу книги автор повторяет: курильщик должен прийти к последней сигарете осознанно и покурить её в финале книги. Я готовился.
Но в какой-то момент услышал вопрос:
— Чего хочет читатель книги?
— Бросить курить.
— Чего хочет курильщик?
— Курить.
❗ То есть я одновременно хочу бросить курить и хочу курить. Это же нелогично. Так не может быть.
В этот момент у меня в голове случился щелчок: чего я действительно хочу?
И… я просто перестал курить. Даже не дослушал книгу.
🔥 Главный вывод
Все получится, если ты действительно этого хочешь.
Я вспоминаю себя в прошлом и понимаю: если я хотел курить — я курил. Всегда.
В аэропорту? В туалете.
В поезде? Между вагонов.
Где нельзя? Придумывал, как можно.
И тогда я понял: если я действительно хочу не курить, то это должно работать точно так же.
Хочешь курить — куришь. Не хочешь — не куришь. Всё просто.
Бросить курить оказалось проще, чем пытаться бросить.
#bio
В одном из прошлых постов я обещал рассказать, как прошел путь от заядлого курильщика до человека, который уже почти три года не берет сигарету в руки.
С тех пор в моей жизни многое изменилось: привычки, режим, осознанность. Но сегодня не об этом. Сегодня — о том, как я быстро и окончательно бросил курить и какие выводы сделал.
🚬 Курил, пытался бросить, курил снова
Как и все курильщики, я много раз говорил себе: «Все, завязываю». Но каждый раз заканчивалось примерно одинаково: ритуальное «последнее» стреляние сигарет, несколько дней без табака, потом «одну и всё» — и привет, старые привычки.
Но однажды что-то изменилось.
👶 Узнал, что стану отцом
Когда я узнал, что скоро у меня родится ребенок, в голове запустился необратимый процесс осознания ответственности. И первое, что я решил — бросить курить.
Раз уж все советуют книгу Алана Карра, я выбрал аудиоверсию и стал слушать её во время прогулок с собакой… куря при этом сигарету.
🧠 Одна мысль, которая перевернула всё
По ходу книги автор повторяет: курильщик должен прийти к последней сигарете осознанно и покурить её в финале книги. Я готовился.
Но в какой-то момент услышал вопрос:
— Чего хочет читатель книги?
— Бросить курить.
— Чего хочет курильщик?
— Курить.
❗ То есть я одновременно хочу бросить курить и хочу курить. Это же нелогично. Так не может быть.
В этот момент у меня в голове случился щелчок: чего я действительно хочу?
И… я просто перестал курить. Даже не дослушал книгу.
🔥 Главный вывод
Все получится, если ты действительно этого хочешь.
Я вспоминаю себя в прошлом и понимаю: если я хотел курить — я курил. Всегда.
В аэропорту? В туалете.
В поезде? Между вагонов.
Где нельзя? Придумывал, как можно.
И тогда я понял: если я действительно хочу не курить, то это должно работать точно так же.
Хочешь курить — куришь. Не хочешь — не куришь. Всё просто.
Бросить курить оказалось проще, чем пытаться бросить.
#bio
❤1👍1
☀️ Доброе утро! Мир снова стал чуть более киберпанковым.
Google тихо удалил из своих принципов запрет на создание ИИ для оружия.
📌 Бывший глава команды по этике ИИ:
🤖 Мы шутили про Skynet, но, похоже, ИИ перестает шутить.
А пока — хорошего дня! 💀
Google тихо удалил из своих принципов запрет на создание ИИ для оружия.
📌 Бывший глава команды по этике ИИ:
Google теперь, вероятно, будет разрабатывать технологии, которые могут убивать людей.
🤖 Мы шутили про Skynet, но, похоже, ИИ перестает шутить.
А пока — хорошего дня! 💀
👍1👀1
⚡ Outbox-паттерн: спасение от потерянных событий (и денег)
В одном из первых постов я рассказывал, как из-за моей ошибки контора потеряла 10к $. Тогда я отправлял события в очередь до записи в БД. Запрос к БД упал, а уведомление уже улетело в платежный сервис. В итоге деньги списали, но не зафиксировали в системе, а потом это повторилось еще много-много раз.
Если бы тогда использовали реляционную БД и Outbox-паттерн, этого бы не случилось.
🤔 В чем проблема?
Типичная схема взаимодействия с брокером:
1️⃣ Пишем данные в БД
2️⃣ Отправляем событие в очередь
Но что если брокер упал или вызов события не прошел после успешного коммита в БД? Система потеряет важное уведомление, а другой сервис никогда не узнает об изменениях.
Решения без Outbox:
🔹 Повторять отправку? — Дубликаты и сложность в обработке
🔹 Держать транзакцию до подтверждения от брокера? — Тормоза в БД
🔹 Игнорировать? — Потерянные данные и баги
🛠 Как решает Outbox?
Вместо того чтобы сразу пушить событие:
✅ Записываем его в специальную таблицу (outbox) в той же транзакции, что и изменение данных
✅ Отдельный процесс (consumer, cron-job, Debezium) читает outbox и отправляет события в брокер
✅ После успешной отправки удаляем запись из outbox
🎯 Почему это круто?
✔️ Гарантия доставки — без потерь, даже если брокер лег
✔️ Идемпотентность — события можно повторно обработать без дубликатов
✔️ Разделение ответственности — бизнес-логика в одном месте, отправка в другом
🚀 Когда использовать?
✔ Если твои сервисы взаимодействуют через event-driven архитектуру
✔ Если тебе нужно гарантированно отправлять события, даже при сбоях
✔ Если ты используешь реляционную БД и хочешь избавиться от сложностей с distributed transactions
Если бы у нас тогда был Outbox + реляционная БД, я бы просто записал событие в outbox в одной транзакции с изменением данных. Даже если бы платежный сервис упал, событие никуда бы не пропало — оно бы отправилось при следующей обработке.
Вывод: если работаешь с реляционной БД и событиями — Outbox обязателен. Уже используешь или пока надеешься на удачу? Давай обсудим в комментах! 💬
#тек
В одном из первых постов я рассказывал, как из-за моей ошибки контора потеряла 10к $. Тогда я отправлял события в очередь до записи в БД. Запрос к БД упал, а уведомление уже улетело в платежный сервис. В итоге деньги списали, но не зафиксировали в системе, а потом это повторилось еще много-много раз.
Если бы тогда использовали реляционную БД и Outbox-паттерн, этого бы не случилось.
🤔 В чем проблема?
Типичная схема взаимодействия с брокером:
1️⃣ Пишем данные в БД
2️⃣ Отправляем событие в очередь
Но что если брокер упал или вызов события не прошел после успешного коммита в БД? Система потеряет важное уведомление, а другой сервис никогда не узнает об изменениях.
Решения без Outbox:
🔹 Повторять отправку? — Дубликаты и сложность в обработке
🔹 Держать транзакцию до подтверждения от брокера? — Тормоза в БД
🔹 Игнорировать? — Потерянные данные и баги
🛠 Как решает Outbox?
Вместо того чтобы сразу пушить событие:
✅ Записываем его в специальную таблицу (outbox) в той же транзакции, что и изменение данных
✅ Отдельный процесс (consumer, cron-job, Debezium) читает outbox и отправляет события в брокер
✅ После успешной отправки удаляем запись из outbox
🎯 Почему это круто?
✔️ Гарантия доставки — без потерь, даже если брокер лег
✔️ Идемпотентность — события можно повторно обработать без дубликатов
✔️ Разделение ответственности — бизнес-логика в одном месте, отправка в другом
🚀 Когда использовать?
✔ Если твои сервисы взаимодействуют через event-driven архитектуру
✔ Если тебе нужно гарантированно отправлять события, даже при сбоях
✔ Если ты используешь реляционную БД и хочешь избавиться от сложностей с distributed transactions
Если бы у нас тогда был Outbox + реляционная БД, я бы просто записал событие в outbox в одной транзакции с изменением данных. Даже если бы платежный сервис упал, событие никуда бы не пропало — оно бы отправилось при следующей обработке.
Вывод: если работаешь с реляционной БД и событиями — Outbox обязателен. Уже используешь или пока надеешься на удачу? Давай обсудим в комментах! 💬
#тек
👍1
🚨 DeepSeek приостанавливает платежи за API
Из-за перегрузки серверов компания DeepSeek временно отключила пополнение счетов. Пользователи могут использовать только те средства, что уже на балансе. 💳
Похоже, растущий спрос на их API требует масштабирования. ⏳
Вот тут подробнее ТЫК
#новости
Из-за перегрузки серверов компания DeepSeek временно отключила пополнение счетов. Пользователи могут использовать только те средства, что уже на балансе. 💳
Похоже, растущий спрос на их API требует масштабирования. ⏳
Вот тут подробнее ТЫК
#новости
Bloomberg.com
DeepSeek Limits Access to AI Model as Demand Strains Capacity
DeepSeek, the Chinese startup whose artificial-intelligence model roiled global markets last week, said it would restrict access to its application programming interface service because of shortages with its server capacity.
👍1
🌞 Доброе утро! Пока вы разбираетесь с делами, соцсети снова и снова подсовывают мне одну и ту же новость… Ну что ж, поделюсь.
⚡️ Рабочую неделю сократят до 36 часов! Но… только после завершения СВО.
📌 Законопроект уже готов, и изменения коснутся офисных работников и торговли. В Испании такая схема пошла экономике на пользу, а у нас пока 40 часов в неделю.
📅 Но обсуждать реформу начнут только после окончания боевых действий.
Так что ждём. ⏳
⚡️ Рабочую неделю сократят до 36 часов! Но… только после завершения СВО.
📌 Законопроект уже готов, и изменения коснутся офисных работников и торговли. В Испании такая схема пошла экономике на пользу, а у нас пока 40 часов в неделю.
📅 Но обсуждать реформу начнут только после окончания боевых действий.
Так что ждём. ⏳
👍1
🚀 Нейросеть за $50. Технологии становятся дешевле или хуже?
Сегодня наткнулся на новость: американские спецы обучили нейросетку за $50. Причем данные для обучения им сгенерил... GPT. Да, та самая нейросетка учила другую нейросетку. Матрешка технологий.
И вот я сижу и думаю, в каком же некачественном мире я живу. Это ощущение меня не покидало с тех пор, как я впервые услышал про Agile.
📉 Как работает реальный мир технологий?
Бюджет на маркетинг больше, чем бюджет на разработку.
То есть, насколько крутой продукт ты пилишь — вообще не важно, если никто о нем не узнает.
Компании стремятся как можно быстрее закинуть на рынок сырую поделку, снять метрики и если зашло — тогда уже допиливают.
А самое главное — потребитель давно не цель, а товар.
👕 Если массово шьют футболки, значит, есть массовый потребитель.
🧠 Если каждая вторая компания заявляет, что у нее есть своя нейросеть, значит, просто так надо говорить. Потому что если не скажешь — инвестор унесет деньги тем, кто сказал.
А на чем реально обучали нейросеть? На реальных данных или синтетике?
Какая разница, главное, чтобы звучало хайпово.
🧐 Что думаешь? Мир технологий реально деградирует или это просто новая норма? 👇
#толки
Сегодня наткнулся на новость: американские спецы обучили нейросетку за $50. Причем данные для обучения им сгенерил... GPT. Да, та самая нейросетка учила другую нейросетку. Матрешка технологий.
И вот я сижу и думаю, в каком же некачественном мире я живу. Это ощущение меня не покидало с тех пор, как я впервые услышал про Agile.
📉 Как работает реальный мир технологий?
Бюджет на маркетинг больше, чем бюджет на разработку.
То есть, насколько крутой продукт ты пилишь — вообще не важно, если никто о нем не узнает.
Компании стремятся как можно быстрее закинуть на рынок сырую поделку, снять метрики и если зашло — тогда уже допиливают.
А самое главное — потребитель давно не цель, а товар.
👕 Если массово шьют футболки, значит, есть массовый потребитель.
🧠 Если каждая вторая компания заявляет, что у нее есть своя нейросеть, значит, просто так надо говорить. Потому что если не скажешь — инвестор унесет деньги тем, кто сказал.
А на чем реально обучали нейросеть? На реальных данных или синтетике?
Какая разница, главное, чтобы звучало хайпово.
🧐 Что думаешь? Мир технологий реально деградирует или это просто новая норма? 👇
#толки
TechCrunch
Researchers created an open rival to OpenAI's o1 'reasoning' model for under $50 | TechCrunch
AI researchers at Stanford and the University of Washington were able to train an AI "reasoning" model for under $50 in cloud compute credits, according
👍1
🛠 Битва языков: Rust vs C в контексте Linux
В мире Linux заваривается новый срач. И на этот раз не про systemd, а про Rust vs C.
Пока одни с пеной у рта доказывают, что Rust — это спасение от багов и UB, другие (особенно старожилы Linux-кода) видят в нем раковую опухоль. Нет, не сам язык, а кросс-языковую кодовую базу — монстра, который ломает чистоту C-шного мира.
Почему Rust вообще залез в ядро?
Linux исторически написан на C, но проблемы с безопасностью никуда не делись: use-after-free, buffer overflow, null-pointer dereference — старые добрые товарищи. Rust решает это на уровне компилятора. То есть просто нельзя написать кривой код, потому что компилятор скажет: «Ты дебил, переделывай».
Но есть нюанс. Кросс-языковая кодовая база — это боль. Когда ядро на C, а новый код пишется на Rust, начинается зоопарк зависимости, ABI, совместимости, и вот уже приходится не разрабатывать, а разруливать.
Что дальше?
Rust не вытеснит C из ядра, но будет отгрызать куски кода, где критична безопасность. Одни ликуют, другие возмущены, но назад пути нет.
А ты за кого: C или Rust? Или вообще на асме писал бы? 🧐
#новости
В мире Linux заваривается новый срач. И на этот раз не про systemd, а про Rust vs C.
Пока одни с пеной у рта доказывают, что Rust — это спасение от багов и UB, другие (особенно старожилы Linux-кода) видят в нем раковую опухоль. Нет, не сам язык, а кросс-языковую кодовую базу — монстра, который ломает чистоту C-шного мира.
Почему Rust вообще залез в ядро?
Linux исторически написан на C, но проблемы с безопасностью никуда не делись: use-after-free, buffer overflow, null-pointer dereference — старые добрые товарищи. Rust решает это на уровне компилятора. То есть просто нельзя написать кривой код, потому что компилятор скажет: «Ты дебил, переделывай».
Но есть нюанс. Кросс-языковая кодовая база — это боль. Когда ядро на C, а новый код пишется на Rust, начинается зоопарк зависимости, ABI, совместимости, и вот уже приходится не разрабатывать, а разруливать.
Что дальше?
Rust не вытеснит C из ядра, но будет отгрызать куски кода, где критична безопасность. Одни ликуют, другие возмущены, но назад пути нет.
А ты за кого: C или Rust? Или вообще на асме писал бы? 🧐
#новости
👍1
🚀 Мизулина предложила разблокировать X (бывший Twitter) в России — мол, теперь там меньше цензуры и деструктива.
А у меня X давно был, просто стоял пыльный в углу. Но теперь я его почистил, помыл и готов к разблокировке 😎
А вот и ссылочка, если что 👉 https://x.com/debug_leg
#новости
А у меня X давно был, просто стоял пыльный в углу. Но теперь я его почистил, помыл и готов к разблокировке 😎
А вот и ссылочка, если что 👉 https://x.com/debug_leg
#новости
👍2
📱 Цифровой шаббат: мозгам тоже нужен выходной
Всё чаще ловлю себя на том, что залипаю в соцсетях. Эти короткие видео засасывают так, что даже не замечаешь, как прошло полчаса. А месяц назад наткнулся на статью, где написано, что от этого чуть ли не мозги гниют. Теперь мы с Юлей подкалываем друг друга: если кто-то зависает в телефоне, сразу получаем «Эй, у тебя там уже плесень растёт?» 😆
Но шутки в сторону — надо что-то делать. Первая мера — цифровой шаббат. День без телефона, соцсетей, новостей и прочего инфошума. Только офлайн, только хардкор.
А может, ну его нафиг и взять Nokia 3310? 🤔
#bio
Всё чаще ловлю себя на том, что залипаю в соцсетях. Эти короткие видео засасывают так, что даже не замечаешь, как прошло полчаса. А месяц назад наткнулся на статью, где написано, что от этого чуть ли не мозги гниют. Теперь мы с Юлей подкалываем друг друга: если кто-то зависает в телефоне, сразу получаем «Эй, у тебя там уже плесень растёт?» 😆
Но шутки в сторону — надо что-то делать. Первая мера — цифровой шаббат. День без телефона, соцсетей, новостей и прочего инфошума. Только офлайн, только хардкор.
А может, ну его нафиг и взять Nokia 3310? 🤔
#bio
🔥1