#ItLife
Иногда кажется, что отключить себя от IT это не про кнопки и выключатели, а про саму привычку жить внутри системы. Мы же прячемся туда не только ради работы, но и ради ощущения контроля. В любой ЭВМ всё чётко: если есть ошибка, то она где-то в коде; если что-то сломалось — вероятно это можно починить. В жизни так не работает.
И, скорее всего, поэтому мы зависаем в технологиях дольше чем надо. Потому что там понятные правила, а с людьми и самим собой их нет.
Но человек ведь не может быть только процессором. У нас есть тело, которое требует банальных вещей: солнца, движения, касания. Есть сознание, которому нужно чуть больше чем сообщения в Telegram или таблицы в Excel. И когда мы слишком глубоко уходим в технологии, то по не многу теряем контакт с этим «живым» слоем.
Отключение от IT не про бегство от технологий, а напоминание себе что реальность не сводится к экрану. Что ценность не в том, сколько строк кода ты написал, а в том, как ТЫ проживаешь свой день.
Иногда кажется, что отключить себя от IT это не про кнопки и выключатели, а про саму привычку жить внутри системы. Мы же прячемся туда не только ради работы, но и ради ощущения контроля. В любой ЭВМ всё чётко: если есть ошибка, то она где-то в коде; если что-то сломалось — вероятно это можно починить. В жизни так не работает.
И, скорее всего, поэтому мы зависаем в технологиях дольше чем надо. Потому что там понятные правила, а с людьми и самим собой их нет.
Но человек ведь не может быть только процессором. У нас есть тело, которое требует банальных вещей: солнца, движения, касания. Есть сознание, которому нужно чуть больше чем сообщения в Telegram или таблицы в Excel. И когда мы слишком глубоко уходим в технологии, то по не многу теряем контакт с этим «живым» слоем.
Отключение от IT не про бегство от технологий, а напоминание себе что реальность не сводится к экрану. Что ценность не в том, сколько строк кода ты написал, а в том, как ТЫ проживаешь свой день.
Мы создали компьютеры чтобы они служили нам, а не наоборот.
#ItSecurity
Что будет с шифрованием в будущем?
Мы привыкли думать что криптография это что-то вечное: зашифровал и всё в безопасности. Но у каждого алгоритма есть свой «срок годности» и потенциально они скоро все сломаются.
Суть проста: один ключ и для шифрования, и для расшифровки.
Сейчас AES-256 считается золотым стандартом. Сломать его перебором нереально — нужно больше времени, чем существует вселенная.
Проблема в другом: управление ключами. Чем больше участников, тем труднее безопасно делиться секретом.
Будущее: симметричные алгоритмы никуда не исчезнут, т.к. они быстрые и надёжные. Но их роль всё больше и больше будет связана с гибридными схемами (например, симметрия + асимметрия).
Здесь два ключа: публичный и приватный. Удобно для обмена и цифровых подписей.
RSA когда-то был непоколебимым, но рост вычислительных мощностей уже делает его уязвимым (2048 бит ещё ок, но меньше уже не вариант).
Эллиптические кривые (ECC) дают ту же безопасность при меньших размерах ключей. Сейчас это активно используется в TLS, криптовалюте и т. д.
Будущее: RSA постепенно уйдёт в архив, ECC останется в ходу, пока не придут квантовые компьютеры.
Хэш это не шифрование, а «отпечаток данных». Используется для проверки целостности и паролей.
Коллизии — главный враг (когда разные данные дают одинаковый хэш). MD5 и SHA-1 уже сданы на металлолом. SHA-2 и SHA-3 пока держатся.
Будущее: хэширование будет жить дольше всех. Даже квантовые компьютеры ломают их не так легко, как RSA.
Квантовая угроза
Пока её нет, но она стремительно надвигается. Алгоритм Шора (link1, link2) теоретически ломает RSA и ECC. Это значит, что всё что мы шифруем сегодня «надолго», завтра может оказаться прозрачным.
Будущее здесь уже формируется:
Итого:
То есть пока квантовые компьютеры не вышли из лабораторий, нас ждёт эволюция уже существующих методов: больше симметрии, новые хэши и отказ от старых схем.
А когда «кванты» станут реальностью — придётся пересматривать всю криптографию с нуля.
Что будет с шифрованием в будущем?
Мы привыкли думать что криптография это что-то вечное: зашифровал и всё в безопасности. Но у каждого алгоритма есть свой «срок годности» и потенциально они скоро все сломаются.
1. Симметричное шифрование (AES, DES, ChaCha20)
Суть проста: один ключ и для шифрования, и для расшифровки.
Сейчас AES-256 считается золотым стандартом. Сломать его перебором нереально — нужно больше времени, чем существует вселенная.
Проблема в другом: управление ключами. Чем больше участников, тем труднее безопасно делиться секретом.
Будущее: симметричные алгоритмы никуда не исчезнут, т.к. они быстрые и надёжные. Но их роль всё больше и больше будет связана с гибридными схемами (например, симметрия + асимметрия).
2. Асимметричное шифрование (RSA, ECC)
Здесь два ключа: публичный и приватный. Удобно для обмена и цифровых подписей.
RSA когда-то был непоколебимым, но рост вычислительных мощностей уже делает его уязвимым (2048 бит ещё ок, но меньше уже не вариант).
Эллиптические кривые (ECC) дают ту же безопасность при меньших размерах ключей. Сейчас это активно используется в TLS, криптовалюте и т. д.
Будущее: RSA постепенно уйдёт в архив, ECC останется в ходу, пока не придут квантовые компьютеры.
3. Хэш-функции (SHA-2, SHA-3, BLAKE2)
Хэш это не шифрование, а «отпечаток данных». Используется для проверки целостности и паролей.
Коллизии — главный враг (когда разные данные дают одинаковый хэш). MD5 и SHA-1 уже сданы на металлолом. SHA-2 и SHA-3 пока держатся.
Будущее: хэширование будет жить дольше всех. Даже квантовые компьютеры ломают их не так легко, как RSA.
Квантовая угроза
Пока её нет, но она стремительно надвигается. Алгоритм Шора (link1, link2) теоретически ломает RSA и ECC. Это значит, что всё что мы шифруем сегодня «надолго», завтра может оказаться прозрачным.
Будущее здесь уже формируется:
разрабатываются постквантовые алгоритмы (NIST сейчас как раз выбирает финалистов);
часть из них основана на решении задач, которые сложны даже для квантов (например, на решётках).
Итого:
Симметричное шифрование будет жить и дальше, его не страшат даже квантовые атаки напрямую.
RSA доживает последние годы как стандарт.
ECC будет в ходу, но с горизонтом «до квантов».
Хэшиотносительно безопасны, но постепенно будут меняться на новые стандарты.
То есть пока квантовые компьютеры не вышли из лабораторий, нас ждёт эволюция уже существующих методов: больше симметрии, новые хэши и отказ от старых схем.
А когда «кванты» станут реальностью — придётся пересматривать всю криптографию с нуля.
Blutengel - You Walk Away (2K23 Anniversary Version) (2K23 Anniversary…
<unknown>
Кто прошел и написал 95% кода для хакатона? Кто сражался с командами по 5 человек в состоянии мертвеца?
Правильно — @Ximelay_y
Наступила эпоха получения своих дивидендов с бессонных ночей, убитых нервов и сломанных клавиш.
Правильно — @Ximelay_y
Наступила эпоха получения своих дивидендов с бессонных ночей, убитых нервов и сломанных клавиш.
#Programming
REST, gRPC и GraphQL: три способа разговаривать с сервером
В любой современной системе сервисы постоянно общаются между собой. Один хранит данные, другой обрабатывает запросы, третий показывает пользователю результат. Но чтобы это всё работало, им нужно договориться о языке общения.
Вот тут и начинаются халевары: REST, gRPC или GraphQL?
Каждый из них решает одну и ту же задачу — как клиент будет получать данные от сервера.
REST: старый, но надёжный
REST появился раньше всех и до сих пор живее многих «модных» технологий.
Он строится на простых принципах HTTP-ресурсов, методов GET, POST, PUT, DELETE, статусов ответов (200, 404, 500).
Всё что тебе нужно — это URL, например
REST хорош, когда:
Почти все публичные API (Discord, GitHub, Telegram) испольуют REST, так как он универсален, понятен и предсказуем.
Минусы тоже есть:
gRPC: быстрый и умный
gRPC придумали в Google, когда REST перестал справляться с микросервисами.
Он работает на HTTP/2 и использует Protocol Buffers — формат бинарных данных.
Это значит: меньше байтов, больше скорости.
Вместо ручной сериализации JSON ты описываешь структуру в
И всё — система сама генерирует код под нужный язык (Go, Java, Python).
Плюсы gRPC:
Минусы:
GraphQL: гибкость и контроль
GraphQL появился из другой боли — фронтендерам надоело запрашивать слишком много или слишком мало данных.
В REST ты получаешь всё что сервер решил отдать. В GraphQL ты сам говоришь:
«дай мне только имя и email вот этого пользователя».
И сервер возвращает ровно это, ничего лишнего.
GraphQL работает поверх HTTP, но у него свой язык запросов.
Есть только одно подключение (endpoint), через которое идут все запросы.
Плюсы:
Минусы:
Где что использовать
Идеальной технологии нет.
Есть правильный выбор под задачу.
REST, gRPC и GraphQL: три способа разговаривать с сервером
В любой современной системе сервисы постоянно общаются между собой. Один хранит данные, другой обрабатывает запросы, третий показывает пользователю результат. Но чтобы это всё работало, им нужно договориться о языке общения.
Вот тут и начинаются халевары: REST, gRPC или GraphQL?
Каждый из них решает одну и ту же задачу — как клиент будет получать данные от сервера.
REST: старый, но надёжный
REST появился раньше всех и до сих пор живее многих «модных» технологий.
Он строится на простых принципах HTTP-ресурсов, методов GET, POST, PUT, DELETE, статусов ответов (200, 404, 500).
Всё что тебе нужно — это URL, например
/users/1, и сервер. Последний ответит тебе JSON-ом:{ "id": 1, "name": "Alex" }REST хорош, когда:
тебе нужен простой API без лишней логики;
клиенты разные — от браузеров до мобильных приложений, а также curl;
важна стабильность и совместимость.
Почти все публичные API (Discord, GitHub, Telegram) испольуют REST, так как он универсален, понятен и предсказуем.
Минусы тоже есть:
для получения связанных данных (например, user + его посты) приходится делать несколько запросов;
из-за JSON и HTTP-заголовков передаётся много «воздуха»;
строгой схемы нет — всё можно поломать случайно.
gRPC: быстрый и умный
gRPC придумали в Google, когда REST перестал справляться с микросервисами.
Он работает на HTTP/2 и использует Protocol Buffers — формат бинарных данных.
Это значит: меньше байтов, больше скорости.
Вместо ручной сериализации JSON ты описываешь структуру в
.proto файле:message User {
int32 id = 1;
string name = 2;
}И всё — система сама генерирует код под нужный язык (Go, Java, Python).
Плюсы gRPC:
очень быстрый, особенно на больших потоках данных;
поддерживает стриминг — сервер и клиент могут обмениваться сообщениями в реальном времени;
строгая типизация, меньше ошибок.
Минусы:
сложнее тестировать и смотреть ответы потому что вся информация находится в двоичном виде;
полноценно gRPC в браузере не работает, поэтому вротендерам нужен прокси;
требует внимательности при версионировании схем.
GraphQL: гибкость и контроль
GraphQL появился из другой боли — фронтендерам надоело запрашивать слишком много или слишком мало данных.
В REST ты получаешь всё что сервер решил отдать. В GraphQL ты сам говоришь:
«дай мне только имя и email вот этого пользователя».
И сервер возвращает ровно это, ничего лишнего.
{
user(id: 1) {
name
email
}
}GraphQL работает поверх HTTP, но у него свой язык запросов.
Есть только одно подключение (endpoint), через которое идут все запросы.
Плюсы:
меньше запросов — можно собрать все данные за один;
гибкость на стороне клиента;
хорошая документация и автогенерация схем.
Минусы:
сложнее кэшировать;
если запросы составлены неаккуратно, то серверу может стать ОЧЕНЬ плохо;
требует продуманной архитектуры.
Где что использовать
REST: публичные API, простые интеграции JSON / HTTP.
gRPC: микросервисы, внутренние системы Binary (ProtoBuf).
GraphQL: клиентские приложения (веб, мобильные) JSON / HTTP.
Идеальной технологии нет.
Есть правильный выбор под задачу.
#OS #Windows #Linux
Microsoft сделала лучшую рекламу Linux, сама того не хотя
14 октября 2025 года — дата, которую Microsoft назвала «концом поддержки Windows 10».
По сути это «ваш компьютер больше не под защитой, покупайте новый или платите нам».
И ведь 10-ка не старая XP'шка. Система стабильна, у многих стоит на рабочих станциях, в школах, у бизнеса.
Но Microsoft решила что хватит. Кто не перешёл на Windows 11тот «выпал из эволюции».
Проблема в том, что половина мира просто не может перейти. У кого-то процессоры без TPM 2.0, у кого-то старое «железо»,
а у кого-то банально нет желания менять ноут который и так нормально работает.
И вот тут в игру входит Linux.
Linux всегда был где-то рядом с «теми, кто шарит».
А теперь к нему придут обычные пользователи и не потому что «open source»,
а потому что Windows их выкинула.
Microsoft сама создала рекламную кампанию конкурента:
И люди пойдут по наименьшей силе сопротивления:
«как перейти на Linux»,
«какой дистрибутив проще»,
«что выбрать вместо Windows 10». Поисковики закипят.
Разработчики Linux-дистрибутивов даже сделали сайты вроде endof10.org, где показывают, как за 15 минут перейти на Linux Mint или Fedora.
Почти без боли и команд в консоли. С нормальным интерфейсом, без слежки и телеметрии.
Знаете, что самое ироничное?
Microsoft десять лет убеждала всех, что Windows 10 — «последняя версия». Теперь оказалось, что в смысле «последняя, которую вы получите бесплатно». Может это и есть настоящая точка невозврата.
Когда люди начали понимать: не нужно платить, чтобы иметь стабильную систему. Не нужно покупать новый ноут ради «обновлённого дизайна панели задач». Не нужно быть «айтишником», чтобы поставить Linux и забыть про постоянные обновления, перезагрузки и рекламу в меню «Пуск».
Microsoft сделала всё правильно с точки зрения бизнеса.
Но с точки зрения пользователя это просто идеальная реклама того, что у тебя есть выбор.
Microsoft сделала лучшую рекламу Linux, сама того не хотя
14 октября 2025 года — дата, которую Microsoft назвала «концом поддержки Windows 10».
По сути это «ваш компьютер больше не под защитой, покупайте новый или платите нам».
И ведь 10-ка не старая XP'шка. Система стабильна, у многих стоит на рабочих станциях, в школах, у бизнеса.
Но Microsoft решила что хватит. Кто не перешёл на Windows 11тот «выпал из эволюции».
Проблема в том, что половина мира просто не может перейти. У кого-то процессоры без TPM 2.0, у кого-то старое «железо»,
а у кого-то банально нет желания менять ноут который и так нормально работает.
И вот тут в игру входит Linux.
Linux всегда был где-то рядом с «теми, кто шарит».
А теперь к нему придут обычные пользователи и не потому что «open source»,
а потому что Windows их выкинула.
Microsoft сама создала рекламную кампанию конкурента:
– отказ от бесплатных обновлений безопасности;
– платные «Extended Security Updates» (ESU) для бизнеса;
– предложение купить новое железо ради Windows 11.
И люди пойдут по наименьшей силе сопротивления:
«как перейти на Linux»,
«какой дистрибутив проще»,
«что выбрать вместо Windows 10». Поисковики закипят.
Разработчики Linux-дистрибутивов даже сделали сайты вроде endof10.org, где показывают, как за 15 минут перейти на Linux Mint или Fedora.
Почти без боли и команд в консоли. С нормальным интерфейсом, без слежки и телеметрии.
Знаете, что самое ироничное?
Microsoft десять лет убеждала всех, что Windows 10 — «последняя версия». Теперь оказалось, что в смысле «последняя, которую вы получите бесплатно». Может это и есть настоящая точка невозврата.
Когда люди начали понимать: не нужно платить, чтобы иметь стабильную систему. Не нужно покупать новый ноут ради «обновлённого дизайна панели задач». Не нужно быть «айтишником», чтобы поставить Linux и забыть про постоянные обновления, перезагрузки и рекламу в меню «Пуск».
Microsoft сделала всё правильно с точки зрения бизнеса.
Но с точки зрения пользователя это просто идеальная реклама того, что у тебя есть выбор.
#OpenSource
Почему без проприетарного софта в продакшене никуда
Все любят рассказывать, что «мы только на open source, никаких корпораций, свобода, братство, Linux и Docker из исходников».
Да, звучит круто. Пока не начался продакшен.
А потом ты ставишь платный инструмент, потому что у него есть техподдержка, SLA и ответственность. А ещё можешь написать тикет, получить фикс, апдейт и гарантию, что завтра всё не развалится🤩
Да, за это надо платить. Но ты платишь не за «бренд» и не за «закрытость». Ты платишь за то чтобы твой бизнес стоял и сервер не умер в пятницу вечером. А также чтобы у тебя был номер телефона по которому реально поднимут инженера.
Open source это свобода. Но свобода без ответственности всегда заканчивается хаосом. А в продакшене хаос — минус деньги, клиенты и сон.
Поэтому да, идеологически круто писать всё на open source, но практически ты всё равно используешь проприетарное ПО: мониторинг, облака, базы, CI/CD и. т. д.
И это не плохо. Это просто взрослая реальность: иногда стабильность стоит денег и это нормально.
Почему без проприетарного софта в продакшене никуда
Все любят рассказывать, что «мы только на open source, никаких корпораций, свобода, братство, Linux и Docker из исходников».
Да, звучит круто. Пока не начался продакшен.
Пока у тебя не упал сервис ночью, а автор библиотеки из Индии ушёл в отпуск.
Пока новая версия пакета не ломает совместимость и никто не отвечает на issue уже третий месяц.
Пока ты не осознал что документация это README из четырёх строк и баги, описанные в комментариях на StackOverflow.
А потом ты ставишь платный инструмент, потому что у него есть техподдержка, SLA и ответственность. А ещё можешь написать тикет, получить фикс, апдейт и гарантию, что завтра всё не развалится
Да, за это надо платить. Но ты платишь не за «бренд» и не за «закрытость». Ты платишь за то чтобы твой бизнес стоял и сервер не умер в пятницу вечером. А также чтобы у тебя был номер телефона по которому реально поднимут инженера.
Open source это свобода. Но свобода без ответственности всегда заканчивается хаосом. А в продакшене хаос — минус деньги, клиенты и сон.
Поэтому да, идеологически круто писать всё на open source, но практически ты всё равно используешь проприетарное ПО: мониторинг, облака, базы, CI/CD и. т. д.
И это не плохо. Это просто взрослая реальность: иногда стабильность стоит денег и это нормально.
Please open Telegram to view this post
VIEW IN TELEGRAM
#Programming #ItSecurity
Кэширование
Все же любят когда сайт открывается мгновенно? Благодаря кэшу браузер или любой другой продукт может сохранять картинки, логины, шрифты и.т.п.
Экономия, скорость, красота.
Но вот беда — всё, что хранится в нём может достаточно легко утечь.
Кэш часто содержит куски страниц, запросов и сессий, а если разработчик не подумал о настройках заголовков вроде
то приватные данные пользователя могут спокойно сохраниться прямо в трусах в сервера.
Бывает и хуже
Например, прокси-сервер или CDN (Cloudflare, Nginx, Varnish) кэшируют ответ,
а потом показывают его другому пользователю. И всё — чужой JSON с именем, адресом и токеном доступа уже в чьём-то браузере.
HTTPS тут не спасает, если внутри всё кэшируется без головы. Шифрование защищает транспорт, но не то что хранится после.
Кэш можно предоставить как сейф без замка: можно быстро достать, но и легко потерять.
А ещё есть браузерный кэш.
Ты заходишь в интернет-банк, выходишь, но если браузер не сбрасывает данные, то HTML и даже части запросов остаются в памяти устройства.
На чужом компе это уже не «ускорение загрузки», а риск утечки.
Кэширование похоже на нож.
Если пользоваться с умом, то ускорит и спасёт ресурсы.
Если нет, то начнет резать по живому. (Все вдоль а ты поперёк)
Особенно когда речь о данных, которые никому видеть не стоит.
Кэширование
Все же любят когда сайт открывается мгновенно? Благодаря кэшу браузер или любой другой продукт может сохранять картинки, логины, шрифты и.т.п.
Экономия, скорость, красота.
Но вот беда — всё, что хранится в нём может достаточно легко утечь.
Кэш часто содержит куски страниц, запросов и сессий, а если разработчик не подумал о настройках заголовков вроде
Cache-Control, Pragma или no-store,то приватные данные пользователя могут спокойно сохраниться прямо в трусах в сервера.
Бывает и хуже
Например, прокси-сервер или CDN (Cloudflare, Nginx, Varnish) кэшируют ответ,
а потом показывают его другому пользователю. И всё — чужой JSON с именем, адресом и токеном доступа уже в чьём-то браузере.
HTTPS тут не спасает, если внутри всё кэшируется без головы. Шифрование защищает транспорт, но не то что хранится после.
Кэш можно предоставить как сейф без замка: можно быстро достать, но и легко потерять.
А ещё есть браузерный кэш.
Ты заходишь в интернет-банк, выходишь, но если браузер не сбрасывает данные, то HTML и даже части запросов остаются в памяти устройства.
На чужом компе это уже не «ускорение загрузки», а риск утечки.
Кэширование похоже на нож.
Если пользоваться с умом, то ускорит и спасёт ресурсы.
Если нет, то начнет резать по живому. (Все вдоль а ты поперёк)
Особенно когда речь о данных, которые никому видеть не стоит.
#ITLife #OSINT
Меня не поставить на колени
Есть один принцип, который я исповедую и в коде, и в жизни: меня никто и никогда не заставит унижаться, ползать по кабинетам или мириться с искусственными преградами. Если есть стена, то я найду дверь. Если двери нет — я либо проточу тоннель хоть ложками с зубной пастой, либо просто перешагну через нее. И ТОЧКА.
Это не заносчивость, А результат иного типа мышления — мышления инженера.
Вот смотрите. Когда обычный человек видит ошибку, он злится. Когда я вижу ошибку в большинстве случаев я вижу систему: её входные данные, логику, уязвимости и, в конечном счёте, её дыхательное горло. Я нахожу такие способы решения проблемы, что у неподготовленного человека мозг сломается, прежде чем он поймет что происходит в моем коде.
И дело не в том что код — «говнокод». Как раз наоборот. Он написан с доскональным пониманием работы инструмента, на стыке знаний о которых большинство «вайбкодеров» даже и не слышали. Это высшая форма уважения к машине — говорить с ней на её (почти) родном языке, а не тыкать палкой в надежде что она как-то заработает.
И эта философия взламывает не только компиляторы, но и саму реальность.
Жизнь тот же код. И в нем полно багов, которые можно и нужно исправлять.
Поэтому любые санкции, географические блокировки, «личностные ограничения» или попытки что-то мне запретить это просто смешно. Они рассчитаны на пассивного потребителя который смирится. На меня они не подействуют с вероятностью 99.8%.
Оставшиеся 0.2% на случай апокалипсиса, когда рухнут все сети и наступит хаос. Тут уж придётся идти на принципиально другие компромиссы. Но это крайний случай.
Так что всем господам пидорасинам, которые строят свои виртуальные заборы и думают, что могут что-то контролировать, я желаю лишь одного: удачи. Вам она понадобится.
А вам, мои лучшие подписчики, я желаю самого ценного в наше время: необходимых знаний и смекалки. Чтобы вы никогда не зависели от чьего-то разрешения и вы могли творить, строить, обходить любые стены.
Вы у меня самые умненькие. Оставайтесь такими. И помните: там, где другие видят тупик, мы видим точку входа.👩💻
Меня не поставить на колени
Есть один принцип, который я исповедую и в коде, и в жизни: меня никто и никогда не заставит унижаться, ползать по кабинетам или мириться с искусственными преградами. Если есть стена, то я найду дверь. Если двери нет — я либо проточу тоннель хоть ложками с зубной пастой, либо просто перешагну через нее. И ТОЧКА.
Это не заносчивость, А результат иного типа мышления — мышления инженера.
Вот смотрите. Когда обычный человек видит ошибку, он злится. Когда я вижу ошибку в большинстве случаев я вижу систему: её входные данные, логику, уязвимости и, в конечном счёте, её дыхательное горло. Я нахожу такие способы решения проблемы, что у неподготовленного человека мозг сломается, прежде чем он поймет что происходит в моем коде.
И дело не в том что код — «говнокод». Как раз наоборот. Он написан с доскональным пониманием работы инструмента, на стыке знаний о которых большинство «вайбкодеров» даже и не слышали. Это высшая форма уважения к машине — говорить с ней на её (почти) родном языке, а не тыкать палкой в надежде что она как-то заработает.
И эта философия взламывает не только компиляторы, но и саму реальность.
Жизнь тот же код. И в нем полно багов, которые можно и нужно исправлять.
🚫 Не работает нужный сервис в стране? Привет «виртуальный загранпаспорт». Несколько букв в поиске системы, нажать "Включить" как тут-же оказываешься за стенами ограничений.🧑💻 Нужна лицензия на софт за 300к рублей? Пфф. Три фикса, один чуть измененный .exe, пара правок в реестре и вот уже все программы для диагностики автосервиса работают как часы. (будет время расскажу как я регулировал этот процесс для целой СТО на «мёртвом» софте — это отдельная история).👉 Человек пропал, заблокирован, недоступен? Да-да, OSINT никто не отменял. Цепочка из открытых данных, перекрёстные проверки, соцсети, метаданные и вот уже картина ясна.
Поэтому любые санкции, географические блокировки, «личностные ограничения» или попытки что-то мне запретить это просто смешно. Они рассчитаны на пассивного потребителя который смирится. На меня они не подействуют с вероятностью 99.8%.
Так что всем господам пидорасинам, которые строят свои виртуальные заборы и думают, что могут что-то контролировать, я желаю лишь одного: удачи. Вам она понадобится.
А вам, мои лучшие подписчики, я желаю самого ценного в наше время: необходимых знаний и смекалки. Чтобы вы никогда не зависели от чьего-то разрешения и вы могли творить, строить, обходить любые стены.
Вы у меня самые умненькие. Оставайтесь такими. И помните: там, где другие видят тупик, мы видим точку входа.
Please open Telegram to view this post
VIEW IN TELEGRAM
#Education #Other
Тайм-менеджмент для гениев: почему ваши to-do списки не работают
Вы когда-нибудь чувствовали, что вашзавтрак утром.
Поздравляю, вы столкнулись с ограничениями линейного мышления. Мир стал слишком сложным и быстрым для простых списков дел. Пора переходить на профессиональный инструмент — методологии управления задачами.
Не пугайтесь этих слов. По сути, это готовые алгоритмы для вашего времени и проектов. Давайте разберем самые главные.
Представьте, что вы ведете машину в тумане по незнакомой дороге. Вы не можете построить идеальный маршрут так как вам нужно постоянно подруливать исходя из того, что вы видите прямо перед собой.
Agile это и есть это «подруливание». Его главная идея: нельзя заранее предусмотреть всё. Нужно разбивать большой путь на короткие отрезки, быстро доезжать до следующей точки, оценивать обстановку и, что ключевое — менять план, если он не работает.
Кредо Agile: «Лучше работающий продукт, чем идеальная документация».
Если Agile это философия вождения, то Scrum — конкретная инструкция к вашей BMW.
Как это работает:
Кому подойдет Scrum? Любому, у кого есть долгосрочный проект, который можно дробить на части: от запуска стартапа до планирования ремонта в квартире.
Пока Scrum заставляет вас работать циклами, Kanban позволяет вести более гибкий и непрерывный поток задач.
Его суть — знаменитая доска с тремя колонками: «
Его главная магия в ограничении задач «в процессе». Вы договариваетесь, что в колонке «Doing» не может быть больше, скажем, 3 задач одновременно. Нельзя брать новую, пока не закончил старую.
Это мгновенно лечит «выгорание от многозадачности» и вытаскивает на свет божий все узкие места. Если задача неделю висит в «Doing», всем сразу видно, что тут кто-то недорабатывает.
Кому подойдет Kanban? Отлично работает для команд поддержки, контент-менеджеров, а также для личных дел, которые приходят спонтанно и их нельзя жестко планировать спринтами.
🤯 Getting Things Done (GTD): Система для персонального хаоса
GTD — это не про команды, а про ваш личный мозг. Его создатель, Дэвид Аллен, считает, что наш мозг — плохое место для хранения информации. Он постоянно напоминает нам о делах, вызывая стресс.
Алгоритм GTD прост:
Результат: голова освобождается для мышления, а не для запоминания.
Так что же выбрать?
Главный вывод? Не существует единственно правильной методологии. Существует та, которая решает вашу проблему.
Перестаньте бороться с хаосом волевыми усилиями. Начните использовать систему. Ваш мозг скажет вам спасибо.
Тайм-менеджмент для гениев: почему ваши to-do списки не работают
Вы когда-нибудь чувствовали, что ваш
to-do список живет своей жизнью? Вы вычеркиваете три мелких дела, а на их место приходят пять новых. К концу дня вы уставшие, а список длиннее, чем ваш Поздравляю, вы столкнулись с ограничениями линейного мышления. Мир стал слишком сложным и быстрым для простых списков дел. Пора переходить на профессиональный инструмент — методологии управления задачами.
Не пугайтесь этих слов. По сути, это готовые алгоритмы для вашего времени и проектов. Давайте разберем самые главные.
🌟 Agile: не методология, а философия
Представьте, что вы ведете машину в тумане по незнакомой дороге. Вы не можете построить идеальный маршрут так как вам нужно постоянно подруливать исходя из того, что вы видите прямо перед собой.
Agile это и есть это «подруливание». Его главная идея: нельзя заранее предусмотреть всё. Нужно разбивать большой путь на короткие отрезки, быстро доезжать до следующей точки, оценивать обстановку и, что ключевое — менять план, если он не работает.
Кредо Agile: «Лучше работающий продукт, чем идеальная документация».
🌟 Scrum: Agile в кроссовках
Если Agile это философия вождения, то Scrum — конкретная инструкция к вашей BMW.
Как это работает:
Есть «Бэклог» — это ваш общий, приоритизированный список всех хотелок и задач (как тот самый to-do list, но с умом).
Работа идет «Спринтами» — это короткие, фиксированные по времени отрезки (обычно 1-4 недели). В начале спринта команда смотрит на бэклог и говорит: «Окей, вот этот кусок мы гарантированно сделаем за следующие 2 недели».
Каждый день — 15-минутный «Стендап» (или «летучка»). Три вопроса: Что сделал вчера? Что сделаю сегодня? Что мешает?
В конце спринта — показ работающего куска продукта и анализ: что прошло хорошо, а что можно улучшить в следующем спринте.
Кому подойдет Scrum? Любому, у кого есть долгосрочный проект, который можно дробить на части: от запуска стартапа до планирования ремонта в квартире.
🥺 Kanban: Визуализируй и ограничивай
Пока Scrum заставляет вас работать циклами, Kanban позволяет вести более гибкий и непрерывный поток задач.
Его суть — знаменитая доска с тремя колонками: «
Сделать» (To Do) → «В процессе» (Doing) → «Сделано» (Done).Его главная магия в ограничении задач «в процессе». Вы договариваетесь, что в колонке «Doing» не может быть больше, скажем, 3 задач одновременно. Нельзя брать новую, пока не закончил старую.
Это мгновенно лечит «выгорание от многозадачности» и вытаскивает на свет божий все узкие места. Если задача неделю висит в «Doing», всем сразу видно, что тут кто-то недорабатывает.
Кому подойдет Kanban? Отлично работает для команд поддержки, контент-менеджеров, а также для личных дел, которые приходят спонтанно и их нельзя жестко планировать спринтами.
GTD — это не про команды, а про ваш личный мозг. Его создатель, Дэвид Аллен, считает, что наш мозг — плохое место для хранения информации. Он постоянно напоминает нам о делах, вызывая стресс.
Алгоритм GTD прост:
Соберите все дела, мысли и напоминания, которые крутятся у вас в голове, в одно место («Входящую корзину»).
Разберите: По каждой задаче спросите: «Что это?». Если действие занимает меньше 2 минут — сделайте его сразу. Если нет — делегируйте, отложите в календарь или превратите в конкретную задачу в вашем списке.
Организуйте задачи по проектам и контекстам («@компьютер», «@город», «@дом»).
Пересматривайте свою систему регулярно, чтобы она не устаревала.
Результат: голова освобождается для мышления, а не для запоминания.
Так что же выбрать?
Scrum — если у вас есть большой и сложный, но понятный проект.
Kanban — если задачи приходят стихийно и важна гибкость.
GTD — если вы хотите навести порядок в своей личной вселенной.
Главный вывод? Не существует единственно правильной методологии. Существует та, которая решает вашу проблему.
Перестаньте бороться с хаосом волевыми усилиями. Начните использовать систему. Ваш мозг скажет вам спасибо.
Please open Telegram to view this post
VIEW IN TELEGRAM
#OpenSource
Новая лицензия ПЛМПНЗ.
Добиваемся ее использования во всех новых проектах!
Публичная лицензия, по которой можно пиздить, но нельзя закрывать (ПЛМПНЗ) версии первой
Для защиты открытого исходного кода программы, далее просто исходного текста, существует настоящая Публичная лицензия, по которой можно пиздить, но нельзя закрывать (а еще потому что GPL скучная хуйня)
Данный исходный код принадлежит этому человеку: дябло, а так же сообществу, вносящему свой вклад в это произведение искусства (да-да, программы, особенно попенсурс, тоже искусство)
Что есть что:
Бинарник - результат компиляции исходного текста в двоичный код или в другой текст (не обязательно состоящей из 0 или 1, это устоявшееся выражение, мне похуй, понимаете?), еще эту хуйню может запустить пользователь без дополнительной компиляции (интерпердаторы не в счет)
Исходный текст - текст, он же код, который написал настоящий разработчик настоящей программы, будучи в трезвом (исходный код читаем) или не в трезвом (исходный код нечитаем) состоянии, могут быть использованы средства вайбкодинга (то есть некоторые фрагменты написаны с помощью нейросетей, зачастую мало чем отличается от кода, написанного в нетрезвом состоянии)
Компиляция - процесс преобразования исходного текста в другой формат, например в другой текст, написанный на другом языке программирования, или вообще в циферки (которые только в бинарной система типа 1 или 0, поняли да?)
Форк, она же вилка, оно же ответвление (я буду называть вилкой, потому что смешно) - другой исходный текст, производный (то есть основан) от данного исходного текста программы.
Интерпретатор - программа, который выполняет код (в том числе и исходный текст), по сути любая программа исполняется внутри интерпретатора, который поставляется вместе с операционной системой или вы его скачивается (например питухон (он же Python))
САМА ЛИЦЕНЗИЯ:
1. Вместе с бинарником обязан поставляться исходный текст (либо отдельно, но исходный текст всегда должен быть доступен без ограничений)
2. Если исходный код автор захотел закрыть, то он становится петухом, ибо охуел, увы в суд его повести нельзя
3. Кстати форки нельзя закрывать, если они лицензируются под этой лицензией, но в этом случае автор может стать петухом не только в попенсурс камунити, но и на зоне
4. Нельзя запрещать пользоваться программой вне зависимости от целей пользователя (даже если пользователь экстр*мист (мы если что осуждаем), но автор за это не отвечает)
5. А, кстати, программа поставляется в таком виде в каком есть, но так как программа попенсурс, то вы вольны её улучшать
6. Ещё, если программа является цифровой платформой, то есть ей пользуются другие люди удалённо (она если, что находится не на их компе, а находится типа далеко-далеко на сервере, а не типа удаляют пользователя или программу), то эти пользователи тоже должны видеть это произведение чуда (то есть исходный код)
7. Если цифровая платформа хочет следовать законом (ну точнее обязана), то пользователи всегда могут сделать вилку от этого проекта со своими правилами и т.д.
8. Ну кстати исходя из всего этого крайне нежелательно использовать всякие системы защиты авторского права, ибо они нахуй не нужны
Ну это основные положения пока что, лицензия может улучшаться, она совместима с GPL кста, вроде как
(From DiabloSat_off)
Новая лицензия ПЛМПНЗ.
Добиваемся ее использования во всех новых проектах!
Публичная лицензия, по которой можно пиздить, но нельзя закрывать (ПЛМПНЗ) версии первой
Для защиты открытого исходного кода программы, далее просто исходного текста, существует настоящая Публичная лицензия, по которой можно пиздить, но нельзя закрывать (а еще потому что GPL скучная хуйня)
Данный исходный код принадлежит этому человеку: дябло, а так же сообществу, вносящему свой вклад в это произведение искусства (да-да, программы, особенно попенсурс, тоже искусство)
Что есть что:
Бинарник - результат компиляции исходного текста в двоичный код или в другой текст (не обязательно состоящей из 0 или 1, это устоявшееся выражение, мне похуй, понимаете?), еще эту хуйню может запустить пользователь без дополнительной компиляции (интерпердаторы не в счет)
Исходный текст - текст, он же код, который написал настоящий разработчик настоящей программы, будучи в трезвом (исходный код читаем) или не в трезвом (исходный код нечитаем) состоянии, могут быть использованы средства вайбкодинга (то есть некоторые фрагменты написаны с помощью нейросетей, зачастую мало чем отличается от кода, написанного в нетрезвом состоянии)
Компиляция - процесс преобразования исходного текста в другой формат, например в другой текст, написанный на другом языке программирования, или вообще в циферки (которые только в бинарной система типа 1 или 0, поняли да?)
Форк, она же вилка, оно же ответвление (я буду называть вилкой, потому что смешно) - другой исходный текст, производный (то есть основан) от данного исходного текста программы.
Интерпретатор - программа, который выполняет код (в том числе и исходный текст), по сути любая программа исполняется внутри интерпретатора, который поставляется вместе с операционной системой или вы его скачивается (например питухон (он же Python))
САМА ЛИЦЕНЗИЯ:
1. Вместе с бинарником обязан поставляться исходный текст (либо отдельно, но исходный текст всегда должен быть доступен без ограничений)
2. Если исходный код автор захотел закрыть, то он становится петухом, ибо охуел, увы в суд его повести нельзя
3. Кстати форки нельзя закрывать, если они лицензируются под этой лицензией, но в этом случае автор может стать петухом не только в попенсурс камунити, но и на зоне
4. Нельзя запрещать пользоваться программой вне зависимости от целей пользователя (даже если пользователь экстр*мист (мы если что осуждаем), но автор за это не отвечает)
5. А, кстати, программа поставляется в таком виде в каком есть, но так как программа попенсурс, то вы вольны её улучшать
6. Ещё, если программа является цифровой платформой, то есть ей пользуются другие люди удалённо (она если, что находится не на их компе, а находится типа далеко-далеко на сервере, а не типа удаляют пользователя или программу), то эти пользователи тоже должны видеть это произведение чуда (то есть исходный код)
7. Если цифровая платформа хочет следовать законом (ну точнее обязана), то пользователи всегда могут сделать вилку от этого проекта со своими правилами и т.д.
8. Ну кстати исходя из всего этого крайне нежелательно использовать всякие системы защиты авторского права, ибо они нахуй не нужны
Ну это основные положения пока что, лицензия может улучшаться, она совместима с GPL кста, вроде как
(From DiabloSat_off)
#Education #Programming
Архитектура проекта
Знакомо чувство, когда смотришь на свой код трехмесячной давности и хочется выколоть себе глаза? Или когда простое изменение растягивается на неделю, потому что всё рассыпается,как карточный домик?
Поздравляю, вы обмазались кое-чем коричневым. Это не криминал, это всего лишь этап взросления программиста. Но можно его пройти гораздо быстрее.
Архитектура это не про красивые диаграммы для начальства, а про то чтобы вам самим не было мучительно больно за свой код через месяц, полгода или год. Это стратегия «не обосраться», воплощенная в коде.
Почему все летит в помойку?
Принципы, которые спасают репутацию
Здесь нет серебряной пули, но есть бронежилет от вашего же будущего «говнокода».
1. Принцип единственной ответственности (SRP)
Это святое. Один модуль = одна работа. Не «менеджер пользователей», который и в базе работает, и письма рассылает, и логи пишет. Это три разных модуля. Похерить этот принцип всё равно что гарантированно получить монстра, которого никто не посмеет тронуть.
2. Слои, как в торте
Четкое разделение на:
Чем выше уровень, тем он важнее. Бизнес-логика не должна знать, какая у вас БД — PostgreSQL, MongoDB или текстовик на пергаменте.
3. Инверсия зависимостей
Ваше ядро не должно зависеть от базы данных, наоборот, БД должна «подключаться» к ядру через интерфейс (абстракцию). Хотите поменять базу? Просто реализуйте тот же интерфейс — ядро даже не узнает что что-то поменялось.
4. Доменно-ориентированное проектирование (DDD)
Это уже высший пилотаж. Вы сначала проектируете не таблицы в БД, а модель предметной области (домен) на языке бизнеса. «Заказ», «Пользователь», «Оплата» — это не просто классы, а объекты со своим поведением, инвариантами и правилами. Когда бизнес-логика выражена в коде так же четко, как в требованиях, то составить финальный продукт становится гораздо легче.
Так с чего начать?
Стройте так, чтобы ваш код через полгода вызывал не желание переписать всё с нуля и откатиться из жизни, а тихую гордость: «А ведь я сделал это хорошо».
Архитектура проекта
Знакомо чувство, когда смотришь на свой код трехмесячной давности и хочется выколоть себе глаза? Или когда простое изменение растягивается на неделю, потому что всё рассыпается,как карточный домик?
Поздравляю, вы обмазались кое-чем коричневым. Это не криминал, это всего лишь этап взросления программиста. Но можно его пройти гораздо быстрее.
Архитектура это не про красивые диаграммы для начальства, а про то чтобы вам самим не было мучительно больно за свой код через месяц, полгода или год. Это стратегия «не обосраться», воплощенная в коде.
Почему все летит в помойку?
Хаотичное разрастание. «О, тут нужно добавить одну фичу...» — и вы лепите её прямо в ядро, создавая спагетти-зависимости. Через 10 таких фич ваш код превращается в болото, в котором тонет любая попытка что-то изменить.
Сломанная модульность. Модули знают друг о друге всё. Изменение кнопки на фронтенде ломает логику на бэкенде. Это как если бы двигатель вашей машины глох каждый раз, когда вы меняете цвет кузова.
Иллюзия «сначала сделаю, потом перепишу». Этого «потом» никогда не будет. Legacy-код работает как канализационная труба: чем дольше ждешь, тем страшнее в нее лезть.
Принципы, которые спасают репутацию
Здесь нет серебряной пули, но есть бронежилет от вашего же будущего «говнокода».
1. Принцип единственной ответственности (SRP)
Это святое. Один модуль = одна работа. Не «менеджер пользователей», который и в базе работает, и письма рассылает, и логи пишет. Это три разных модуля. Похерить этот принцип всё равно что гарантированно получить монстра, которого никто не посмеет тронуть.
2. Слои, как в торте
Четкое разделение на:
Слой представления (UI): только кнопки, формы и отображение. Никакой бизнес-логики!
Бизнес-логика (Ядро): самая важная часть: чистые правила, ради которых все затевалось. Она должна быть ИЗОЛИРОВАНА от всего внешнего.
Слой данных/Инфраструктура: работа с БД, внешними API, файловой системой.
Чем выше уровень, тем он важнее. Бизнес-логика не должна знать, какая у вас БД — PostgreSQL, MongoDB или текстовик на пергаменте.
3. Инверсия зависимостей
Ваше ядро не должно зависеть от базы данных, наоборот, БД должна «подключаться» к ядру через интерфейс (абстракцию). Хотите поменять базу? Просто реализуйте тот же интерфейс — ядро даже не узнает что что-то поменялось.
4. Доменно-ориентированное проектирование (DDD)
Это уже высший пилотаж. Вы сначала проектируете не таблицы в БД, а модель предметной области (домен) на языке бизнеса. «Заказ», «Пользователь», «Оплата» — это не просто классы, а объекты со своим поведением, инвариантами и правилами. Когда бизнес-логика выражена в коде так же четко, как в требованиях, то составить финальный продукт становится гораздо легче.
Так с чего начать?
Рисуйте. Прежде чем писать код, набросайте схему взаимодействия модулей на салфетке (можно даже в кофейне с маком за 10000к). Кто от кого зависит? Кто за что отвечает?Архитектура это не про то, чтобы сделать всё «идеально». Это про то, чтобы минимизировать стоимость изменений. Хорошая архитектура позволяет вам вносить правки быстро и без страха, плохая (или её отсутствие) — превращает каждое изменение в квест.
Задавайте вопрос «А что, если?..». «А что, если нам придется сменить провайдера платежей?», «А что, если нужно будет добавить кэширование?». Ответы на эти вопросы и рождают гибкую архитектуру.
Декомпозируйте. Любую большую задачу можно и нужно разбить на маленькие, независимые модули. Собирайте проект как LEGO, а не как скульптуру из глины.
Стройте так, чтобы ваш код через полгода вызывал не желание переписать всё с нуля и откатиться из жизни, а тихую гордость: «А ведь я сделал это хорошо».
Не обмазывайтесь. Проектируйте.#Education #News
Что такое Экосистема?
Заметили, как все вокруг вдруг говорят про «экосистемы»? Не про болота с лягушками, а про технологические: Apple, Google, Яндекс, Сбер — все строят свои «миры». И яростно хотят чтобы вы в этом мире остались навсегда.
Экосистема это бизнес-модель, при которой компания делает всё, чтобы вы никогда из нее не ушли. Идеальный потребитель в экосистеме тот, кто просыпается от будильника на её смартфоне, ест завтрак, заказанный через её приложение, едет на её такси, работает в её облаке и ложится спать, посмотрев фильм на её стриминге.
Это не забота, а вертикальная и горизонтальная аннексия вашей жизни.
Как работает механика захвата?
Почему они это делают?
Все просто. Один клиент, купивший раз в два года телефон это разовая сделка. А клиент, который живет внутри экосистемы может бесконечно генерировать прибыль.
Так что делать?
Я не призываю вас разбить свой смартфон и уйти в лес. Я призываю к осознанности.
Экосистема это не зло, а эффективная бизнес-модель. Но это золотая клетка: в ней тепло, сухо и раздают корм по расписанию. Вопрос лишь в том, готовы ли вы променять свободу на этот комфорт.
Что такое Экосистема?
Заметили, как все вокруг вдруг говорят про «экосистемы»? Не про болота с лягушками, а про технологические: Apple, Google, Яндекс, Сбер — все строят свои «миры». И яростно хотят чтобы вы в этом мире остались навсегда.
Экосистема это бизнес-модель, при которой компания делает всё, чтобы вы никогда из нее не ушли. Идеальный потребитель в экосистеме тот, кто просыпается от будильника на её смартфоне, ест завтрак, заказанный через её приложение, едет на её такси, работает в её облаке и ложится спать, посмотрев фильм на её стриминге.
Это не забота, а вертикальная и горизонтальная аннексия вашей жизни.
Как работает механика захвата?
Эффект колеи. Вам подарили умную колонку и она хорошо работает с телефоном того же бренда. Вы покупаете телефон и оказывается, (!) он идеально синхронизируется с часами и ноутбуком того же бренда. И так до того момента пока не купите все гаджеты компании. По итогу могу вас поздравить — вы в колее, выходить из нее становится все дороже и ленивее
Иллюзия простоты. «Один аккаунт, один пароль, всё на одном экране». Это правда удобно, но за это удобство вы платите вашими данными и свободой выбора. Компания получает полную цифровую копию вас: ваши маршруты, покупки, вкусы, здоровье, социальные связи. Такие данные дороже любой подписки.
Создание тюрьмы с красивыми обоями. Самые продвинутые экосистемы создают свои проприетарные стандарты (привет, Apple с ее Lightning/MagSafe). Ваши устройства не дружат с чужими "экосистемами", а файлы просто не открываются в других сервисах. Вы не клиент, а заложник.
Почему они это делают?
Все просто. Один клиент, купивший раз в два года телефон это разовая сделка. А клиент, который живет внутри экосистемы может бесконечно генерировать прибыль.
Данные. Ваше поведение это нефть 21 века. На основе треков в фитнес-приложении можно продавать рекламу спортивного питания, на основе поездок строить логистические маршруты и.т.п.
Лояльность. Вам лень уходить, потому что больно сложно так как теряете не сервис, а интегрированный опыт.
Перекрестные продажи. Тот, кто купил у вас телефон, с вероятностью 90% купит подписку на музыку, а потом и на кино. Это маркетинговая утопия, где клиента не нужно искать — он уже там.
Так что делать?
Я не призываю вас разбить свой смартфон и уйти в лес. Я призываю к осознанности.
Задавайте вопрос «А что, если я захочу уйти?». Насколько это будет болезненно? Если ответ «очень», значит вы глубоко в системе.
Ищите альтернативы. Используйте сервисы-«мосты». Менеджер паролей (типа Bitwarden), независимые облака (Nextcloud), Мессенджеры с открытым протоколом (Matrix/Element). Не кладите все цифровые яйца в одну корзину.
Помните: если вы не платите за продукт, то продукт это вы. Ваше внимание и ваши данные и есть валюта, которой вы расплачиваетесь за «бесплатное» удобство.
Экосистема это не зло, а эффективная бизнес-модель. Но это золотая клетка: в ней тепло, сухо и раздают корм по расписанию. Вопрос лишь в том, готовы ли вы променять свободу на этот комфорт.
#Programming
Стоимость погружения вдерьмо древний код: сколько бизнес заплатит за разбор чужого говнокода?
Любоваться говнокодом в сторонке это одно, а вот лезть в него с голыми руками, чтобы всё починить уже совсем другая, ДОРОГАЯ история.
Скажу так: бизнес готов платить непропорционально много. Почему? Потому что альтернативы не существует.
Представь: у компании есть старый, говняный, но ГЛАВНЫЙ скрипт, который держит всю логику оплат. Он написан 10 лет назад тем самым «Васечкой_1976», который давно ушел в запой и монастырь. Скрипт начинает глючить, деньги не приходят, клиенты уходят. Паника.
В этот момент бизнес осознает, что данный кусок дерьма его главный позвоночник и он готов заплатить за костыль любые деньги.
От чего зависит твой прайс?
1. Цена паники (Срочность). «Нам надо вчера» — это +100% к стоимости. Каждый час простоя = тысячи долларов убытков. Твоя способность быстро найти, где там
2. Степень погружения (Сложность).
Понять, почему падает — одна цена. Сделать, чтобы не падало, не трогая логику, в 2 раза дороже. Добавить новую фичу в этот ад уже в 3 раза дороже. Это высший пилотаж вписывания новой сущности в архитектуру, где нет никакой архитектуры.
3. Цена ошибки (Риск). Если твоя правка похоронит данные о продажах за год или сделает недействительными 10 000 лицензий, то бизнес умрет. Соответственно, чем выше риски, тем дороже твоя работа и твоя страховка (в виде экспертизы).
4. Эффект шаманства. Ты шаман, который умеет общаться с духами старого кода. Ты понимаешь, что
Бизнес платит не за код, а за снижение рисков и сохранение денежного потока. Твою работу с говнокодом по сути можно считать не программированием, а археологией, психоанализом и сапёрным делом в одном флаконе. И за это платят, иногда очень-очень хорошо.
Так что в следующий раз, когда увидишь ворох долларов и спагетти-код, не плачь, усмехнись. Это не помойка, а твой личный золотой прииск.
Стоимость погружения в
Любоваться говнокодом в сторонке это одно, а вот лезть в него с голыми руками, чтобы всё починить уже совсем другая, ДОРОГАЯ история.
Скажу так: бизнес готов платить непропорционально много. Почему? Потому что альтернативы не существует.
Представь: у компании есть старый, говняный, но ГЛАВНЫЙ скрипт, который держит всю логику оплат. Он написан 10 лет назад тем самым «Васечкой_1976», который давно ушел в запой и монастырь. Скрипт начинает глючить, деньги не приходят, клиенты уходят. Паника.
В этот момент бизнес осознает, что данный кусок дерьма его главный позвоночник и он готов заплатить за костыль любые деньги.
От чего зависит твой прайс?
1. Цена паники (Срочность). «Нам надо вчера» — это +100% к стоимости. Каждый час простоя = тысячи долларов убытков. Твоя способность быстро найти, где там
$dollar8 перезатирает $dollar4, становится золотой.2. Степень погружения (Сложность).
Понять, почему падает — одна цена. Сделать, чтобы не падало, не трогая логику, в 2 раза дороже. Добавить новую фичу в этот ад уже в 3 раза дороже. Это высший пилотаж вписывания новой сущности в архитектуру, где нет никакой архитектуры.
3. Цена ошибки (Риск). Если твоя правка похоронит данные о продажах за год или сделает недействительными 10 000 лицензий, то бизнес умрет. Соответственно, чем выше риски, тем дороже твоя работа и твоя страховка (в виде экспертизы).
4. Эффект шаманства. Ты шаман, который умеет общаться с духами старого кода. Ты понимаешь, что
if ($a == true && $b != false || $c > 0) на самом деле значит «если не пятница и не после обеда». За эту магию платят отдельно.Бизнес платит не за код, а за снижение рисков и сохранение денежного потока. Твою работу с говнокодом по сути можно считать не программированием, а археологией, психоанализом и сапёрным делом в одном флаконе. И за это платят, иногда очень-очень хорошо.
Так что в следующий раз, когда увидишь ворох долларов и спагетти-код, не плачь, усмехнись. Это не помойка, а твой личный золотой прииск.
#Programming #OOP
Принципы написания кода: когда DRY, SOLID и подобные становятся проблемой
Все мы слышали эти мантры: «Не повторяйся» (DRY), «Будь проще, дурачок» (KISS), «SOLID — это наш светоч». Их вдалбливают неопытным малятам на каждом углу Интернета, как будто исключительное следование им автоматически сделает тебя сеньором-помидором.
А теперь давайте по-честному: слепое следование догмам ведёт в ад переусложненного кода.
Что это за принципы
⬛ DRY (Don't Repeat Yourself): не копипасть один и тот же код в 10 мест. Вынеси в одну функцию, вроде бы логично.
🍷 KISS (Keep It Simple, Stupid): лучше простое, но работающее решение, чем навороченное, но сломанное.
⭐️ SOLID: это уже целая библия из 5 принципов, которые по сути говорят: «Дроби код на маленькие, независимые кусочки чтобы его было легче менять».
В теории — прекрасно, всегда хотел туда переехать, там и трава зеленее, дома красивее и инкапсуляция не является сокрытием. Но практика берёт и рождает из данных парадигм ужасных чудовищ.
Как эти принципы вырождаются в говнокод
Нашел два куска кода, которые похожи на 80%? БЕГОМ ВЫНОСИТЬ В ОБЩУЮ ФУНКЦИЮ! А через месяц появляется третье место, где нужно чуть-чуть иначе. В функцию добавляется параметр
Иногда дублирование это безопасность. Две простые, но немного похожие функции, лучше одной «универсальной», которая знает всё на свете и завтра сломает тебе пол-проекта.
«А чо, у меня работает, я не стал заморачиваться с архитектурой». И вы получаете монолитного Франкенштейна на 10 000 строк, где бизнес-логика перемешана с выводом в браузер. Это не KISS, а лень.
KISS не про «писать как попало», а про «не городить лишнего там, где этого не нужно». Сложная задача может требовать сложного решения. Главное чтобы это решение было максимально прямым и понятным.
Это главное поле битвы джунов, прочитавших Макконала, Столярова и подобных. Они готовы дробить каждую операцию на 15 интерфейсов и 30 классов, чтобы соблюсти «Принцип единственной ответственности» и «Инверсию зависимостей».
В итоге чтобы сделать
SOLID не про цель, а средство для достижения гибкости и поддерживаемости. Если ваш проект это Pet-project на 1000 пользователей, возможно, вам не нужны 5 уровней абстракции для сущности «Кот».
Так что же делать?
Принципы не должны заменять ваши руки. Это простые инструменты в вашем поясе программиста.
Прежде чем слепо выносить код по DRY, спросите: «А действительно ли эти куски логически ОДИНАКОВЫЕ? Или они просто сейчас похожи?». Если есть шанс, что они будут меняться по-разному — дублируйте без страха.
То, что хорошо для корпоративной CRM-системы с командой 50 разработчиков, может быть смертью для стартапа, который нужно запустить вчера.
Главный принцип, которому нет названия — читаемость. Будет ли ваш код через полгода понятен вам или вашему коллеге? Если ради «чистой архитектуры» вы сделали его непонятным, то вы проиграли.
Все эти принципы созданы, чтобы помогать, а не усложнять. Когда архитектура начинает выносить мозг, то скорее всего, вы где-то перемудрили. Пишите код, который работает и который можно понять. А попытки стандартизировать итэшку... оставьте теоретикам.
Принципы написания кода: когда DRY, SOLID и подобные становятся проблемой
Все мы слышали эти мантры: «Не повторяйся» (DRY), «Будь проще, дурачок» (KISS), «SOLID — это наш светоч». Их вдалбливают неопытным малятам на каждом углу Интернета, как будто исключительное следование им автоматически сделает тебя сеньором-помидором.
А теперь давайте по-честному: слепое следование догмам ведёт в ад переусложненного кода.
Что это за принципы
В теории — прекрасно, всегда хотел туда переехать, там и трава зеленее, дома красивее и инкапсуляция не является сокрытием. Но практика берёт и рождает из данных парадигм ужасных чудовищ.
Как эти принципы вырождаются в говнокод
1. DRY: мания абстракций
Нашел два куска кода, которые похожи на 80%? БЕГОМ ВЫНОСИТЬ В ОБЩУЮ ФУНКЦИЮ! А через месяц появляется третье место, где нужно чуть-чуть иначе. В функцию добавляется параметр
isSpecialCase, потом extraOption, а через месяц метод становится doEverythingUniversal($data, $options = []), в который засунули 15 if-ов и теперь даже создатель не понимает что с этим делать.Иногда дублирование это безопасность. Две простые, но немного похожие функции, лучше одной «универсальной», которая знает всё на свете и завтра сломает тебе пол-проекта.
2. KISS: Оправдание криворукости
«А чо, у меня работает, я не стал заморачиваться с архитектурой». И вы получаете монолитного Франкенштейна на 10 000 строк, где бизнес-логика перемешана с выводом в браузер. Это не KISS, а лень.
KISS не про «писать как попало», а про «не городить лишнего там, где этого не нужно». Сложная задача может требовать сложного решения. Главное чтобы это решение было максимально прямым и понятным.
3. SOLID: Архитектурный астрокодинг
Это главное поле битвы джунов, прочитавших Макконала, Столярова и подобных. Они готовы дробить каждую операцию на 15 интерфейсов и 30 классов, чтобы соблюсти «Принцип единственной ответственности» и «Инверсию зависимостей».
В итоге чтобы сделать
UserService, нужно создать UserRepositoryInterface, UserDTO, UserMapper, UserController, UserResponseModel и UserFactory. Простая авторизация обрастает такой структурой, что кажется ты проектируешь ракетоноситель NASA Space Falcon 9, а не форму логина для сайта-визитки.SOLID не про цель, а средство для достижения гибкости и поддерживаемости. Если ваш проект это Pet-project на 1000 пользователей, возможно, вам не нужны 5 уровней абстракции для сущности «Кот».
Так что же делать?
Принципы не должны заменять ваши руки. Это простые инструменты в вашем поясе программиста.
Включайте здравый смысл
Прежде чем слепо выносить код по DRY, спросите: «А действительно ли эти куски логически ОДИНАКОВЫЕ? Или они просто сейчас похожи?». Если есть шанс, что они будут меняться по-разному — дублируйте без страха.
Смотрите на масштаб
То, что хорошо для корпоративной CRM-системы с командой 50 разработчиков, может быть смертью для стартапа, который нужно запустить вчера.
Пишите код для людей, а не для машин
Главный принцип, которому нет названия — читаемость. Будет ли ваш код через полгода понятен вам или вашему коллеге? Если ради «чистой архитектуры» вы сделали его непонятным, то вы проиграли.
Все эти принципы созданы, чтобы помогать, а не усложнять. Когда архитектура начинает выносить мозг, то скорее всего, вы где-то перемудрили. Пишите код, который работает и который можно понять. А попытки стандартизировать итэшку... оставьте теоретикам.
Please open Telegram to view this post
VIEW IN TELEGRAM
#Programming #Education
Инструменты анализа кода
Вы же не просто пишете код, вы его профилируете, дебажите и смотрите где он сосёт ресурсы. Анализ кода это следующая ступень: поиск плохого кода до того как он попадёт в продакшен.
Речь не про «ах, тут отступ не тот». Речь про то, что ваш код по умолчанию потенциальная дыра в безопасности, точка отказа и будущий техдолг.
Платформенные анализаторы
Это не просто линтеры, а системные средства которые смотрят на проект свысока.
Что это: мозги их IDE, вынесенные в отдельный продукт, тот самый ReSharper/Rider/IntelliJ IDEA, который орал на вас в редакторе, но теперь в виде CI-плагина.
Фишка: беспрецедентно глубокий анализ для JVM-языков, PHP, Python, Go. Понимает их экосистемы изнутри, не просто находит ошибки, а предлагает умные исправления — ровно те что вы видели в IDE.
Где: в любом CI (TeamCity, GitHub Actions, и другие). Ловит то, что вы могли пропустить прежде чем пул-реквест уйдет на ревью.
Что это: такой же как и Qodana, но в виде «швейцарского ножа» т.к. охватывает 30+ языков.
Фишка: проверяет не только на баги, но и на уязвимости и «запахи кода» (code smells). Выдает сводную метрику качества + «статус» вашего проекта. Покажет не только где ошибка, но и насколько она критична.
Где: SonarQube — самописный сервер, SonarCloud — SaaS, де-факто стандарт для многих корпораций.
Эти ребята не пытаются объять необъятное, они берут одну задачу и делают ее лучше всех.
PVS-Studio: гроза Си++, C# и Java. Специализируется на глубоких, сложных багах которые часто пропускают компиляторы и другие анализаторы. Диагностирует утечки, неопределенное поведение, ошибки в условиях. Это не просто проверка стилей, а анализ вшивости ядра вашего приложения.
Snyk Code / Checkmarx: фокусируются на безопасности (SAST). Их не волнуют ваши отступы, они ищут уязвимости в виде SQL-инъекций, XSS-атак, проблем с аутентификацией. Очень необходимы если ваш код хоть как-то взаимодействует с внешним миром.
Вы с ними общаетесь каждый день, даже не замечая.
ReSharper (JetBrains для Visual Studio): по сути дедушка Qodana. В реальном времени подсвечивает мусор, предлагает рефакторинги.
Встроенный анализатор в IntelliJ IDEA / PyCharm: тот же движок что и в Qodana, но работает прямо в редакторе.
Встроенный анализатор в Visual Studio: для C# и C++ там своя, весьма продвинутая система статического анализа.
SonarLint: плагин для IDE, который подтягивает правила из вашего SonarQube, чтобы вы ловили проблемы еще до коммита.
Так кто круче? Qodana или SonarQube?
Вопрос из разряда «отвёртка или шуруповёрт?»
Qodana это глубокая интеграция и «родное» понимание конкретных языков от JetBrains. Если ваш стэк это их IDE, то Qodana говорит с вами на одном языке.
SonarQube это широта охвата и универсальность. Один инструмент на всю компанию, от JavaScript до COBOL.
В идеальном случае лучше использовать их вместе: SonarQube как единый дашборд для руководства и общих метрик, а Qodana/PVS-Studio как глубокие эксперты на этапе CI, которые не дадут просочиться никакому говну.
Современная разработка — это когда ваш код проверяют не только вы и тимлид, но и армия ботов, каждый со своей специализацией. Настройте этот конвейер и вы будете спать спокойнее, а ваш репозиторий станет чище.
Инструменты анализа кода
Вы же не просто пишете код, вы его профилируете, дебажите и смотрите где он сосёт ресурсы. Анализ кода это следующая ступень: поиск плохого кода до того как он попадёт в продакшен.
Речь не про «ах, тут отступ не тот». Речь про то, что ваш код по умолчанию потенциальная дыра в безопасности, точка отказа и будущий техдолг.
Платформенные анализаторы
Это не просто линтеры, а системные средства которые смотрят на проект свысока.
Qodana (JetBrains)
Что это: мозги их IDE, вынесенные в отдельный продукт, тот самый ReSharper/Rider/IntelliJ IDEA, который орал на вас в редакторе, но теперь в виде CI-плагина.
Фишка: беспрецедентно глубокий анализ для JVM-языков, PHP, Python, Go. Понимает их экосистемы изнутри, не просто находит ошибки, а предлагает умные исправления — ровно те что вы видели в IDE.
Где: в любом CI (TeamCity, GitHub Actions, и другие). Ловит то, что вы могли пропустить прежде чем пул-реквест уйдет на ревью.
SonarQube/SonarCloud (SonarSource)
Что это: такой же как и Qodana, но в виде «швейцарского ножа» т.к. охватывает 30+ языков.
Фишка: проверяет не только на баги, но и на уязвимости и «запахи кода» (code smells). Выдает сводную метрику качества + «статус» вашего проекта. Покажет не только где ошибка, но и насколько она критична.
Где: SonarQube — самописный сервер, SonarCloud — SaaS, де-факто стандарт для многих корпораций.
Узкоспециализированные бойцы
Эти ребята не пытаются объять необъятное, они берут одну задачу и делают ее лучше всех.
PVS-Studio: гроза Си++, C# и Java. Специализируется на глубоких, сложных багах которые часто пропускают компиляторы и другие анализаторы. Диагностирует утечки, неопределенное поведение, ошибки в условиях. Это не просто проверка стилей, а анализ вшивости ядра вашего приложения.
Snyk Code / Checkmarx: фокусируются на безопасности (SAST). Их не волнуют ваши отступы, они ищут уязвимости в виде SQL-инъекций, XSS-атак, проблем с аутентификацией. Очень необходимы если ваш код хоть как-то взаимодействует с внешним миром.
Анализаторы в IDE
Вы с ними общаетесь каждый день, даже не замечая.
ReSharper (JetBrains для Visual Studio): по сути дедушка Qodana. В реальном времени подсвечивает мусор, предлагает рефакторинги.
Встроенный анализатор в IntelliJ IDEA / PyCharm: тот же движок что и в Qodana, но работает прямо в редакторе.
Встроенный анализатор в Visual Studio: для C# и C++ там своя, весьма продвинутая система статического анализа.
SonarLint: плагин для IDE, который подтягивает правила из вашего SonarQube, чтобы вы ловили проблемы еще до коммита.
Так кто круче? Qodana или SonarQube?
Вопрос из разряда «отвёртка или шуруповёрт?»
Qodana это глубокая интеграция и «родное» понимание конкретных языков от JetBrains. Если ваш стэк это их IDE, то Qodana говорит с вами на одном языке.
SonarQube это широта охвата и универсальность. Один инструмент на всю компанию, от JavaScript до COBOL.
В идеальном случае лучше использовать их вместе: SonarQube как единый дашборд для руководства и общих метрик, а Qodana/PVS-Studio как глубокие эксперты на этапе CI, которые не дадут просочиться никакому говну.
Современная разработка — это когда ваш код проверяют не только вы и тимлид, но и армия ботов, каждый со своей специализацией. Настройте этот конвейер и вы будете спать спокойнее, а ваш репозиторий станет чище.
#Programming
Лямбда-функции
Вы наверняка видели эту странную стрелочку
Лямбда — это анонимная функция, без привычного нам имени. Как тот самый лом в руках Фримана.
Разберём на понятном для масляток примере:
Представим что вы начальник «ООО ХлебЖуй». Вам нужно чтобы ваш подчиненный (функция) сходил в магазин за хлебом.
1. Вы нанимаете постоянного сотрудника, даете ему имя и должность:
2. Потом вызываете его по имени:
Это нормально если «сходить за хлебом» сложная процедура, которая повторяется каждый день.
Но если вам необходимо чтобы кто-то один раз нажал на кнопку
Вы берете лямбду и сами вскрываете щель. Сделали дело — лом отложили.
В коде это выглядит так:
Видите?
Так зачем это надо?
1. Локальность и скорость. Вам не нужно прыгать взглядом в другое место файла чтобы понять, что делает
2. Код становится декларативным. Вы говорите «сделай ТАКОЕ с каждым элементом»
3. Удобно для колбэков. Когда вы передаете функцию в другую функцию (например, «вызови этот код, когда произойдет клик»), лямбда идеальна. Зачем давать имя одноразовому действию?
Можно сказать даже так:
Лом (лямбда) это инструмент, который закреплен за кем-то одним (у него нет имени). Он просто делает свою работу здесь и сейчас.
Он универсален, ломом можно и дверь вскрыть, и голову снести, и число умножить, и условие проверить.
Он решает проблему прямо на месте. Не нужно бегать и искать нужного специалиста (поиск по коду объявленной функции). Все делается в точке возникновения задачи.
Лямбда — это не какая-то магия высшего программирования. Это просто инструмент для одноразовых операций, который делает код компактнее и зачастую читаемее. Конечно, не стоит тыкать лямбдой везде где нужно и не нужно. Если операция сложная и используется много раз — заведите нормальную функцию. Но для мелких, локальных действий это оружие массового поражения говнокода.
Лямбда-функции
Вы наверняка видели эту странную стрелочку
=> в коде и слышали как какие-то умники щеголяют словом «лямбда». А потом кто-то сказанул: «Это как лом Гордона Фримана!». И все такие: «Ага, понятно...». А на деле нихера не понятно.Лямбда — это анонимная функция, без привычного нам имени. Как тот самый лом в руках Фримана.
Разберём на понятном для масляток примере:
Представим что вы начальник «ООО ХлебЖуй». Вам нужно чтобы ваш подчиненный (функция) сходил в магазин за хлебом.
1. Вы нанимаете постоянного сотрудника, даете ему имя и должность:
function сходитьЗаХлебом() { ... }.2. Потом вызываете его по имени:
сходитьЗаХлебом().Это нормально если «сходить за хлебом» сложная процедура, которая повторяется каждый день.
Но если вам необходимо чтобы кто-то один раз нажал на кнопку
сходитьЗаХлебом()? Вы же не будете для этого нанимать человека в штат, давать ему имя, трудовую и соцпакет, так ведь?Вы берете лямбду и сами вскрываете щель. Сделали дело — лом отложили.
В коде это выглядит так:
# Вместо того чтобы объявлять целую функцию...
def умножить_на_два(x):
return x * 2
# ...можно взять и сделать это на месте.
result = list(map(lambda x: x * 2, [1, 2, 3]))
# Получится [2, 4, 6]
Видите?
lambda x: x * 2 это и есть тот самый лом. У него нет имени, он создан прямо здесь для одной конкретной операции внутри map() и после этого его как бы не существует.Так зачем это надо?
1. Локальность и скорость. Вам не нужно прыгать взглядом в другое место файла чтобы понять, что делает
умножить_на_два. Всё описано в одну строчку прямо на месте.2. Код становится декларативным. Вы говорите «сделай ТАКОЕ с каждым элементом»
(map(lambda x: x+1)), вместо того чтобы писать цикл, объявлять переменную, и т.д. Фокус смещается с процесса на результат.3. Удобно для колбэков. Когда вы передаете функцию в другую функцию (например, «вызови этот код, когда произойдет клик»), лямбда идеальна. Зачем давать имя одноразовому действию?
Можно сказать даже так:
Лом (лямбда) это инструмент, который закреплен за кем-то одним (у него нет имени). Он просто делает свою работу здесь и сейчас.
Он универсален, ломом можно и дверь вскрыть, и голову снести, и число умножить, и условие проверить.
Он решает проблему прямо на месте. Не нужно бегать и искать нужного специалиста (поиск по коду объявленной функции). Все делается в точке возникновения задачи.
Лямбда — это не какая-то магия высшего программирования. Это просто инструмент для одноразовых операций, который делает код компактнее и зачастую читаемее. Конечно, не стоит тыкать лямбдой везде где нужно и не нужно. Если операция сложная и используется много раз — заведите нормальную функцию. Но для мелких, локальных действий это оружие массового поражения говнокода.
3
#Programming #Education
Корутины
Представьте что вы официант в очень модном MacBook-кафе. У вас есть два способа работать:
Способ первый, обычный (как потоки): вы подходите к первому столику, принимаете заказ, бежите на кухню и... Стоите там пока повар готовит бургер. Вы не можете отлучиться, вы просто ждёте. Потом несёте бургер, подходите ко второму столику и снова стоите на кухне, пока заваривают кофе. Все клиенты злые, вы уставший и кафе обслуживает человек пять за вечер. Это — блокирующие операции. Поток (официант) блокируется на время ожидания.
Способ второй, волшебный (как корутины): вы подходите к первому столику, принимаете заказ и, прежде чем побежать на кухню, ставите себе в уме флажок: «Жду бургер». Затем вы идёте ко второму столику, принимаете заказ на кофе и ставите флажок: «Жду кофе». Потом к третьему. Вы не стоите без дела! Вы возвращаетесь на кухню и если какой-то заказ готов то сразу его несёте. Вы управляете множеством задач одновременно, не разрываясь на части и не заставляя никого долго ждать вашего возвращения.
Вот эти «флажки» и есть корутины.
Корутина — это функция, у которой есть суперспособность: она умеет ставить себя на паузу (
Обычная функция когда её вызывают работает от начала до конца и забывает о своём состоянии. Корутина же, встретив операцию которая требует ожидания (например запрос в сеть или чтение файла), вежливо говорит: «Знаете, я тут подожду, а вы пока займитесь другими делами». Она не блокирует весь процесс, а просто «засыпает», освобождая ресурсы для других корутин.
Когда её заказ готов (пришел ответ из сети), она «просыпается» ровно в том месте где остановилась, со всеми своими локальными переменными и состоянием, и продолжает работу.
Так в чём же главная магия? Зачем это всё?
1. Экономия ресурсов. Потоки в компьютере — это как настоящие официанты. Каждому новому нужно своё рабочее место (стек), их переключение отнимает силы у системы процессора. А корутины это как один супер-официант с феноменальной памятью. Они невероятно легковесны и их можно запускать тысячи в рамках одного потока.
2. Отзывчивость. Представьте что вы скачиваете десять файлов одновременно. В старом подходе интерфейс бы завис до конца закачки. С корутинами — пока один файл качается (аналог
3. Читаемость кода. Раньше асинхронность делали через адские цепочки колбэков (callback hell), где можно было утонуть. Теперь код выглядит почти как обычный, последовательный, просто расставлены ключевые слова
Где это применяется в реальной жизни?
Корутины не какая-то нишевая магия, а современный и уже обязательный для понимания инструмент. Они не делают вычисления быстрее, они делают ожидание — тем, чем оно и должно быть: паузой, а не остановкой всего процесса.
Корутины
Представьте что вы официант в очень модном MacBook-кафе. У вас есть два способа работать:
Способ первый, обычный (как потоки): вы подходите к первому столику, принимаете заказ, бежите на кухню и... Стоите там пока повар готовит бургер. Вы не можете отлучиться, вы просто ждёте. Потом несёте бургер, подходите ко второму столику и снова стоите на кухне, пока заваривают кофе. Все клиенты злые, вы уставший и кафе обслуживает человек пять за вечер. Это — блокирующие операции. Поток (официант) блокируется на время ожидания.
Способ второй, волшебный (как корутины): вы подходите к первому столику, принимаете заказ и, прежде чем побежать на кухню, ставите себе в уме флажок: «Жду бургер». Затем вы идёте ко второму столику, принимаете заказ на кофе и ставите флажок: «Жду кофе». Потом к третьему. Вы не стоите без дела! Вы возвращаетесь на кухню и если какой-то заказ готов то сразу его несёте. Вы управляете множеством задач одновременно, не разрываясь на части и не заставляя никого долго ждать вашего возвращения.
Вот эти «флажки» и есть корутины.
Корутина — это функция, у которой есть суперспособность: она умеет ставить себя на паузу (
yield или await) и потом возобновлять работу с того же места.Обычная функция когда её вызывают работает от начала до конца и забывает о своём состоянии. Корутина же, встретив операцию которая требует ожидания (например запрос в сеть или чтение файла), вежливо говорит: «Знаете, я тут подожду, а вы пока займитесь другими делами». Она не блокирует весь процесс, а просто «засыпает», освобождая ресурсы для других корутин.
Когда её заказ готов (пришел ответ из сети), она «просыпается» ровно в том месте где остановилась, со всеми своими локальными переменными и состоянием, и продолжает работу.
Так в чём же главная магия? Зачем это всё?
1. Экономия ресурсов. Потоки в компьютере — это как настоящие официанты. Каждому новому нужно своё рабочее место (стек), их переключение отнимает силы у системы процессора. А корутины это как один супер-официант с феноменальной памятью. Они невероятно легковесны и их можно запускать тысячи в рамках одного потока.
2. Отзывчивость. Представьте что вы скачиваете десять файлов одновременно. В старом подходе интерфейс бы завис до конца закачки. С корутинами — пока один файл качается (аналог
await), программа может обрабатывать ваши клики, анимацию и другие задачи.3. Читаемость кода. Раньше асинхронность делали через адские цепочки колбэков (callback hell), где можно было утонуть. Теперь код выглядит почти как обычный, последовательный, просто расставлены ключевые слова
async и await. Вот пример на Python:async def скачать_картинку(ссылка):
# На этом моменте корутина "засыпает", пока данные качаются,
# и программа может делать что-то ещё
response = await aiohttp.get(ссылка)
# "Просыпается" здесь, когда данные уже пришли
данные = await response.read()
return записать_в_файл(данные)
# И мы можем легко запустить много таких задач
задачи = [скачать_картинку(url) for url in списко_ссылок]
await asyncio.gather(*задачи)
Где это применяется в реальной жизни?
Веб-серверы, которые держат десятки тысяч одновременных подключений.
Игры, где одновременно движутся сотни объектов, каждый со своей логикой.
Мобильные приложения, где нельзя чтобы интерфейс замирал при загрузке данных.
Любые программы, которые много общаются с сетью или диском.
Корутины не какая-то нишевая магия, а современный и уже обязательный для понимания инструмент. Они не делают вычисления быстрее, они делают ожидание — тем, чем оно и должно быть: паузой, а не остановкой всего процесса.
#ITLife #Other
Рабочее место: чтобы не уставать, а кайфовать
Есть одна странная вещь: мы можем выбирать идеальный стек технологий для проекта, но годами миримся с неудобным столом, от которого затекает спина и светом, который режет глаза. Мы терпим, считая это мелочью, а потом удивляемся вечерней усталости, туману в голове и ноющей шее.
Ваше рабочее место не просто стол и стул, это интерфейс между вами и миром, в котором вы создаёте код. И если этот интерфейс глючный, то и работа даётся тяжелее. Организовать его такая же важная часть как и выбор архитектуры вашего проекта
Главное не следовать всем советам подряд, а найти то что работает лично для вас. Вот на что стоит обратить внимание:
Основа это положение тела. Стул и стол должны позволять сидеть так чтобы спина чувствовала опору, а не напрягалась, пытаясь удержать равновесие. Локти под углом, ступни на полу или на подставке. Монитор нужно поставить так, чтобы смотреть на него прямо, не задирая и не опуская голову, это снимет нагрузку с шеи.
Свет под настроение. Резкий световой луч от настольной лампы в темноте или блик на экране от окна незаметно утомляют. Мягкий рассеянные фотоны сбоку и отсутствие контраста между экраном и комнатой делают работу спокойнее. Экран не должен быть ярче всего вокруг.
Движения (не в Бристоль). Сидеть неподвижно часами противоестественно для человека: тело затекает, внимание притупляется. Просто встать, пройтись, посмотреть вдаль уже хорошая перезагрузка не только для мышц, но и для мыслей. Не нужно сложной гимнастики, достаточно не превращаться в статую.
Порядок на столе создаёт гармонию в голове. Хаос из бумаг, проводов и банок энергетиков создаёт фоновый шум для сознания. Не обязательно стремиться к минимализму, но стоит убрать то, что точно не нужно прямо сейчас. Свободное пространство помогает думать.
В итоге смысл не в том чтобы купить самое дорогое кресло или идеально всё организовать с понедельника. Смысл — постепенно приходить к тому чтобы ваше пространство работало на вас, а не против вас. Прислушиваться к телу: если через час начинает болеть спина, значит нужно что-то менять в посадке. Если глаза устают, то возможно дело в свете или в настройках монитора.
Это такой же процесс настройки как и поиск удобного инструмента для работы. Только в данном случае вы настраиваете главный инструмент который никакими костылями не фиксится — себя. И это самая важная задача.
Рабочее место: чтобы не уставать, а кайфовать
Есть одна странная вещь: мы можем выбирать идеальный стек технологий для проекта, но годами миримся с неудобным столом, от которого затекает спина и светом, который режет глаза. Мы терпим, считая это мелочью, а потом удивляемся вечерней усталости, туману в голове и ноющей шее.
Ваше рабочее место не просто стол и стул, это интерфейс между вами и миром, в котором вы создаёте код. И если этот интерфейс глючный, то и работа даётся тяжелее. Организовать его такая же важная часть как и выбор архитектуры вашего проекта
hello world.Главное не следовать всем советам подряд, а найти то что работает лично для вас. Вот на что стоит обратить внимание:
Основа это положение тела. Стул и стол должны позволять сидеть так чтобы спина чувствовала опору, а не напрягалась, пытаясь удержать равновесие. Локти под углом, ступни на полу или на подставке. Монитор нужно поставить так, чтобы смотреть на него прямо, не задирая и не опуская голову, это снимет нагрузку с шеи.
Свет под настроение. Резкий световой луч от настольной лампы в темноте или блик на экране от окна незаметно утомляют. Мягкий рассеянные фотоны сбоку и отсутствие контраста между экраном и комнатой делают работу спокойнее. Экран не должен быть ярче всего вокруг.
Движения (не в Бристоль). Сидеть неподвижно часами противоестественно для человека: тело затекает, внимание притупляется. Просто встать, пройтись, посмотреть вдаль уже хорошая перезагрузка не только для мышц, но и для мыслей. Не нужно сложной гимнастики, достаточно не превращаться в статую.
Порядок на столе создаёт гармонию в голове. Хаос из бумаг, проводов и банок энергетиков создаёт фоновый шум для сознания. Не обязательно стремиться к минимализму, но стоит убрать то, что точно не нужно прямо сейчас. Свободное пространство помогает думать.
В итоге смысл не в том чтобы купить самое дорогое кресло или идеально всё организовать с понедельника. Смысл — постепенно приходить к тому чтобы ваше пространство работало на вас, а не против вас. Прислушиваться к телу: если через час начинает болеть спина, значит нужно что-то менять в посадке. Если глаза устают, то возможно дело в свете или в настройках монитора.
Это такой же процесс настройки как и поиск удобного инструмента для работы. Только в данном случае вы настраиваете главный инструмент который никакими костылями не фиксится — себя. И это самая важная задача.