#OpenSource

Новая лицензия ПЛМПНЗ.
Добиваемся ее использования во всех новых проектах!

Публичная лицензия, по которой можно пиздить, но нельзя закрывать (ПЛМПНЗ) версии первой

Для защиты открытого исходного кода программы, далее просто исходного текста, существует настоящая Публичная лицензия, по которой можно пиздить, но нельзя закрывать (а еще потому что GPL скучная хуйня)

Данный исходный код принадлежит этому человеку: дябло, а так же сообществу, вносящему свой вклад в это произведение искусства (да-да, программы, особенно попенсурс, тоже искусство)

Что есть что:
Бинарник - результат компиляции исходного текста в двоичный код или в другой текст (не обязательно состоящей из 0 или 1, это устоявшееся выражение, мне похуй, понимаете?), еще эту хуйню может запустить пользователь без дополнительной компиляции (интерпердаторы не в счет)
Исходный текст - текст, он же код, который написал настоящий разработчик настоящей программы, будучи в трезвом (исходный код читаем) или не в трезвом (исходный код нечитаем) состоянии, могут быть использованы средства вайбкодинга (то есть некоторые фрагменты написаны с помощью нейросетей, зачастую мало чем отличается от кода, написанного в нетрезвом состоянии)
Компиляция - процесс преобразования исходного текста в другой формат, например в другой текст, написанный на другом языке программирования, или вообще в циферки (которые только в бинарной система типа 1 или 0, поняли да?)
Форк, она же вилка, оно же ответвление (я буду называть вилкой, потому что смешно) - другой исходный текст, производный (то есть основан) от данного исходного текста программы.
Интерпретатор - программа, который выполняет код (в том числе и исходный текст), по сути любая программа исполняется внутри интерпретатора, который поставляется вместе с операционной системой или вы его скачивается (например питухон (он же Python))

САМА ЛИЦЕНЗИЯ:
1. Вместе с бинарником обязан поставляться исходный текст (либо отдельно, но исходный текст всегда должен быть доступен без ограничений)
2. Если исходный код автор захотел закрыть, то он становится петухом, ибо охуел, увы в суд его повести нельзя
3. Кстати форки нельзя закрывать, если они лицензируются под этой лицензией, но в этом случае автор может стать петухом не только в попенсурс камунити, но и на зоне
4. Нельзя запрещать пользоваться программой вне зависимости от целей пользователя (даже если пользователь экстр*мист (мы если что осуждаем), но автор за это не отвечает)
5. А, кстати, программа поставляется в таком виде в каком есть, но так как программа попенсурс, то вы вольны её улучшать
6. Ещё, если программа является цифровой платформой, то есть ей пользуются другие люди удалённо (она если, что находится не на их компе, а находится типа далеко-далеко на сервере, а не типа удаляют пользователя или программу), то эти пользователи тоже должны видеть это произведение чуда (то есть исходный код)
7. Если цифровая платформа хочет следовать законом (ну точнее обязана), то пользователи всегда могут сделать вилку от этого проекта со своими правилами и т.д.
8. Ну кстати исходя из всего этого крайне нежелательно использовать всякие системы защиты авторского права, ибо они нахуй не нужны

Ну это основные положения пока что, лицензия может улучшаться, она совместима с GPL кста, вроде как

(From DiabloSat_off)

#Education #Programming

Архитектура проекта

Знакомо чувство, когда смотришь на свой код трехмесячной давности и хочется выколоть себе глаза? Или когда простое изменение растягивается на неделю, потому что всё рассыпается,как карточный домик?

Поздравляю, вы обмазались кое-чем коричневым. Это не криминал, это всего лишь этап взросления программиста. Но можно его пройти гораздо быстрее.

Архитектура это не про красивые диаграммы для начальства, а про то чтобы вам самим не было мучительно больно за свой код через месяц, полгода или год. Это стратегия «не обосраться», воплощенная в коде.

Почему все летит в помойку?

Хаотичное разрастание. «О, тут нужно добавить одну фичу...» — и вы лепите её прямо в ядро, создавая спагетти-зависимости. Через 10 таких фич ваш код превращается в болото, в котором тонет любая попытка что-то изменить.

Сломанная модульность. Модули знают друг о друге всё. Изменение кнопки на фронтенде ломает логику на бэкенде. Это как если бы двигатель вашей машины глох каждый раз, когда вы меняете цвет кузова.

Иллюзия «сначала сделаю, потом перепишу». Этого «потом» никогда не будет. Legacy-код работает как канализационная труба: чем дольше ждешь, тем страшнее в нее лезть.

Принципы, которые спасают репутацию

Здесь нет серебряной пули, но есть бронежилет от вашего же будущего «говнокода».

1. Принцип единственной ответственности (SRP)
Это святое. Один модуль = одна работа. Не «менеджер пользователей», который и в базе работает, и письма рассылает, и логи пишет. Это три разных модуля. Похерить этот принцип всё равно что гарантированно получить монстра, которого никто не посмеет тронуть.

2. Слои, как в торте
Четкое разделение на:

Слой представления (UI): только кнопки, формы и отображение. Никакой бизнес-логики!

Бизнес-логика (Ядро): самая важная часть: чистые правила, ради которых все затевалось. Она должна быть ИЗОЛИРОВАНА от всего внешнего.

Слой данных/Инфраструктура: работа с БД, внешними API, файловой системой.

Чем выше уровень, тем он важнее. Бизнес-логика не должна знать, какая у вас БД — PostgreSQL, MongoDB или текстовик на пергаменте.

3. Инверсия зависимостей
Ваше ядро не должно зависеть от базы данных, наоборот, БД должна «подключаться» к ядру через интерфейс (абстракцию). Хотите поменять базу? Просто реализуйте тот же интерфейс — ядро даже не узнает что что-то поменялось.

4. Доменно-ориентированное проектирование (DDD)
Это уже высший пилотаж. Вы сначала проектируете не таблицы в БД, а модель предметной области (домен) на языке бизнеса. «Заказ», «Пользователь», «Оплата» — это не просто классы, а объекты со своим поведением, инвариантами и правилами. Когда бизнес-логика выражена в коде так же четко, как в требованиях, то составить финальный продукт становится гораздо легче.

Так с чего начать?

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

Задавайте вопрос «А что, если?..». «А что, если нам придется сменить провайдера платежей?», «А что, если нужно будет добавить кэширование?». Ответы на эти вопросы и рождают гибкую архитектуру.

Декомпозируйте. Любую большую задачу можно и нужно разбить на маленькие, независимые модули. Собирайте проект как LEGO, а не как скульптуру из глины.

Архитектура это не про то, чтобы сделать всё «идеально». Это про то, чтобы минимизировать стоимость изменений. Хорошая архитектура позволяет вам вносить правки быстро и без страха, плохая (или её отсутствие) — превращает каждое изменение в квест.

Стройте так, чтобы ваш код через полгода вызывал не желание переписать всё с нуля и откатиться из жизни, а тихую гордость: «А ведь я сделал это хорошо».

Не обмазывайтесь. Проектируйте.

#Education #News

Что такое Экосистема?

Заметили, как все вокруг вдруг говорят про «экосистемы»? Не про болота с лягушками, а про технологические: Apple, Google, Яндекс, Сбер — все строят свои «миры». И яростно хотят чтобы вы в этом мире остались навсегда.

Экосистема это бизнес-модель, при которой компания делает всё, чтобы вы никогда из нее не ушли. Идеальный потребитель в экосистеме тот, кто просыпается от будильника на её смартфоне, ест завтрак, заказанный через её приложение, едет на её такси, работает в её облаке и ложится спать, посмотрев фильм на её стриминге.

Это не забота, а вертикальная и горизонтальная аннексия вашей жизни.

Как работает механика захвата?

Эффект колеи. Вам подарили умную колонку и она хорошо работает с телефоном того же бренда. Вы покупаете телефон и оказывается, (!) он идеально синхронизируется с часами и ноутбуком того же бренда. И так до того момента пока не купите все гаджеты компании. По итогу могу вас поздравить — вы в колее, выходить из нее становится все дороже и ленивее

Иллюзия простоты. «Один аккаунт, один пароль, всё на одном экране». Это правда удобно, но за это удобство вы платите вашими данными и свободой выбора. Компания получает полную цифровую копию вас: ваши маршруты, покупки, вкусы, здоровье, социальные связи. Такие данные дороже любой подписки.

Создание тюрьмы с красивыми обоями. Самые продвинутые экосистемы создают свои проприетарные стандарты (привет, Apple с ее Lightning/MagSafe). Ваши устройства не дружат с чужими "экосистемами", а файлы просто не открываются в других сервисах. Вы не клиент, а заложник.

Почему они это делают?

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

Данные. Ваше поведение это нефть 21 века. На основе треков в фитнес-приложении можно продавать рекламу спортивного питания, на основе поездок строить логистические маршруты и.т.п.

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

Перекрестные продажи. Тот, кто купил у вас телефон, с вероятностью 90% купит подписку на музыку, а потом и на кино. Это маркетинговая утопия, где клиента не нужно искать — он уже там.

Так что делать?

Я не призываю вас разбить свой смартфон и уйти в лес. Я призываю к осознанности.

Задавайте вопрос «А что, если я захочу уйти?». Насколько это будет болезненно? Если ответ «очень», значит вы глубоко в системе.

Ищите альтернативы. Используйте сервисы-«мосты». Менеджер паролей (типа Bitwarden), независимые облака (Nextcloud), Мессенджеры с открытым протоколом (Matrix/Element). Не кладите все цифровые яйца в одну корзину.

Помните: если вы не платите за продукт, то продукт это вы. Ваше внимание и ваши данные и есть валюта, которой вы расплачиваетесь за «бесплатное» удобство.

Экосистема это не зло, а эффективная бизнес-модель. Но это золотая клетка: в ней тепло, сухо и раздают корм по расписанию. Вопрос лишь в том, готовы ли вы променять свободу на этот комфорт.

#Programming

Стоимость погружения в дерьмо древний код: сколько бизнес заплатит за разбор чужого говнокода?

Любоваться говнокодом в сторонке это одно, а вот лезть в него с голыми руками, чтобы всё починить уже совсем другая, ДОРОГАЯ история.

Скажу так: бизнес готов платить непропорционально много. Почему? Потому что альтернативы не существует.

Представь: у компании есть старый, говняный, но ГЛАВНЫЙ скрипт, который держит всю логику оплат. Он написан 10 лет назад тем самым «Васечкой_1976», который давно ушел в запой и монастырь. Скрипт начинает глючить, деньги не приходят, клиенты уходят. Паника.
В этот момент бизнес осознает, что данный кусок дерьма его главный позвоночник и он готов заплатить за костыль любые деньги.

От чего зависит твой прайс?

1. Цена паники (Срочность). «Нам надо вчера» — это +100% к стоимости. Каждый час простоя = тысячи долларов убытков. Твоя способность быстро найти, где там $dollar8 перезатирает $dollar4, становится золотой.

2. Степень погружения (Сложность).
Понять, почему падает — одна цена. Сделать, чтобы не падало, не трогая логику, в 2 раза дороже. Добавить новую фичу в этот ад уже в 3 раза дороже. Это высший пилотаж вписывания новой сущности в архитектуру, где нет никакой архитектуры.

3. Цена ошибки (Риск). Если твоя правка похоронит данные о продажах за год или сделает недействительными 10 000 лицензий, то бизнес умрет. Соответственно, чем выше риски, тем дороже твоя работа и твоя страховка (в виде экспертизы).

4. Эффект шаманства. Ты шаман, который умеет общаться с духами старого кода. Ты понимаешь, что if ($a == true && $b != false || $c > 0) на самом деле значит «если не пятница и не после обеда». За эту магию платят отдельно.

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

Так что в следующий раз, когда увидишь ворох долларов и спагетти-код, не плачь, усмехнись. Это не помойка, а твой личный золотой прииск.

#Programming #Education

Инструменты анализа кода

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

Платформенные анализаторы

Это не просто линтеры, а системные средства которые смотрят на проект свысока.

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. Вы нанимаете постоянного сотрудника, даете ему имя и должность: 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. Удобно для колбэков. Когда вы передаете функцию в другую функцию (например, «вызови этот код, когда произойдет клик»), лямбда идеальна. Зачем давать имя одноразовому действию?

Можно сказать даже так:

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

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

#Programming #Education

Корутины

Представьте что вы официант в очень модном 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.

Главное не следовать всем советам подряд, а найти то что работает лично для вас. Вот на что стоит обратить внимание:

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

Свет под настроение. Резкий световой луч от настольной лампы в темноте или блик на экране от окна незаметно утомляют. Мягкий рассеянные фотоны сбоку и отсутствие контраста между экраном и комнатой делают работу спокойнее. Экран не должен быть ярче всего вокруг.

Движения (не в Бристоль). Сидеть неподвижно часами противоестественно для человека: тело затекает, внимание притупляется. Просто встать, пройтись, посмотреть вдаль уже хорошая перезагрузка не только для мышц, но и для мыслей. Не нужно сложной гимнастики, достаточно не превращаться в статую.

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

В итоге смысл не в том чтобы купить самое дорогое кресло или идеально всё организовать с понедельника. Смысл — постепенно приходить к тому чтобы ваше пространство работало на вас, а не против вас. Прислушиваться к телу: если через час начинает болеть спина, значит нужно что-то менять в посадке. Если глаза устают, то возможно дело в свете или в настройках монитора.

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

#Education #Programming

Стэк: что это и почему из него всё вываливается

Если объяснять на пальцах, то стэк (stack) — это как стопка тарелок в баре. Тарелку можно класть только сверху и брать тоже только сверху. Первая положенная тарелка будет взята последней, это принцип LIFO (Last In, First Out). Программистский стэк в памяти работает так же, только вместо тарелок там локальные переменные и адреса возврата из функций.

Зачем это создано?

Вызов функции? Процессор кладёт в стэк адрес, куда нужно вернуться после её выполнения, и все локальные переменные этой функции.

Функция завершилась? Всё, что она положила в стэк (свой «слой»), снимается. Освобождается память, процессор смотрит на верхний адрес возврата и прыгает обратно в предыдущую функцию.

Вызвана новая функция? На старый слой сверху кладётся новый. И так далее.

Это гениально, потому что:

Быстро. Добавление и удаление происходит только с одного конца (вершины стека), не нужно ничего сдвигать в памяти.

Предсказуемо. У каждого вызова функции есть свой изолированный контекст.

Естественно для вложенности. Функция А вызывает Б, Б вызывает В и стэк идеально отражает слои: А → Б → В.

Почему он переполняется?

Стэк не бесконечный. Это выделенный кусок оперативки (обычно 1-8 МБ) и если класть тарелки без остановки, то рано или поздно они упрутся в потолок. В программировании это происходит в двух случаях:

1. Бесконечная или очень глубокая рекурсия

def скажи_привет_вечно():
    return скажи_привет_вечно()  # Вызов себя же, без выхода

Каждый новый вызов кладёт в стэк новый слой данных. Через миллион вызовов (а на самом деле гораздо раньше) место кончится. Stack Overflow.

2. Огромные локальные переменные

void съесть_память() {
    int огромный_массив[1000000]; // Выделится в стеке, не в куче
    // ...
}

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

Представь револьвер. Стэк — это обойма.

1. Патрон (вызов функции) можно дослать только в верх обоймы.
2. Чтобы выстрелить (завершить функцию), нужно вынуть верхний патрон.
3. Если пихать патроны не стреляя, то в какой-то момент обойма переполнится. Защёлкнешь, а лишний патрон уже не лезет — заклинило.

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

Понимание стека это как понимание, куда в машине заливать бензин, а куда тормозную жидкость. Без этого далеко не уедешь, а если перепутать — будет бабах.

#Programming #Cs

Делегаты: что за такие посредники

Если говорить грубо то, делегат это профессиональный «стрелочник». Такой типобезопасный указатель на функцию, которая умеет делать одну простую вещь: передавать выполнение задачи кому-то другому, не завязываясь на конкретную реализацию.

Представь: ты — менеджер (основной код). Тебе нужно выполнить задачу, допустим «обработать данные». Но как именно обрабатывать ты не знаешь и знать не хочешь. Это решает кто-то другой, ты просто говоришь: «Эй, вот тебе данные, сделай с ними что надо» и передаёшь вызов через делегата.

Как это выглядит в коде (на C#)?

// Объявляем делегат — это как шаблон для всех, кто сможет выполнить роль
delegate string МанипуляторСтрокой(string text);

class Program
{
    // Метод, который соответствует шаблону делегата
    static string ДобавитьВосклицания(string s) => s + "!!!";

    static void Main()
    {
        // Создаём экземпляр делегата и "целим" его на метод
        МанипуляторСтрокой обработчик = ДобавитьВосклицания;

        // Вызов через делегат — как будто вызываем сам метод
        string результат = обработчик("Привет");
        Console.WriteLine(результат); // Вывод: Привет!!!
    }
}

И зачем?

1. Чтобы не зависеть от конкретного кода, мой пирожочек (инверсии зависимостей). Твой класс не должен знать проДобавитьВосклицания, УдалитьПробелы или Зашифровать. Он знает только про делегат МанипуляторСтрокой. Что именно будет делать этот манипулятор — решает тот, кто использует твой класс. Ты предоставляешь крючок, на который другие могут вешать свою логику.

2. Для событийной модели (event handling). Это основное применение так как Делегаты основа событий в C#. Ты подписываешь свой метод на кнопку Click и когда пользователь жмёт на неё, вызываются все методы прицепленные к делегату этого события. Без делегатов пришлось бы городить безумные switch-case или ещё более убогие конструкции.

button.Click += НажалиКнопку; // Подписали метод на событие через делегат

3. Для колбэков и асинхронных операций «Вот выполни эту задачу, а когда закончишь вызови тот метод, который я тебе дам». Классика: BeginInvoke, задачи с продолжениями. Делегат здесь это адрес куда нужно «отзвониться» о результатах.

А что за Action, Func и прочие generic-делегаты?

Это готовые шаблоны делегатов, чтобы не объявлять свои каждый раз:

Action — делегат для метода, который не возвращает ничего (void).

Action<int, string> — то же, но принимает параметры.

Func<string, int> — делегат для метода, который возвращает значение (последний generic-параметр — тип возврата).

Func<string, string> обработчик = s => s.ToUpper(); // Лямбда прямо в делегат

Делегаты это контракты на выполнение работы такой способ сказать: «Мне нужен кто-то, кто умеет делать ВОТ ЭТО (сигнатура). Кто именно мне уже не важно». Это фундамент для:

1. Гибкого кода, который можно переконфигурировать на лету.
2. Событий и реактивного программирования.
3. Паттернов вроде Strategy или Observer.

Без делегатов мы бы до сих пор клеили скотчем костыли из switch-ей и гигантских интерфейсов с одним методом. Это один из тех инструментов, который будучи понятым, начинает применяться почти везде потому что это элегантное решение для проблемы «как не превратить код в монолит».
Делегаты твои легальные, типобезопасные указатели на функции, которые делают код не просто рабочим, а архитектурно красивым. И да, их стоит освоить, даже если поначалу кажется, что можно обойтись без них.

#Other #ItLife

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

Я смотрю на людей вокруг, вроде и такие же — сидят за компьютерами, пьют кофе, смеются. Но у них есть какая-то… простота, они могут отвлечься. У меня же в голове вечно крутятся мысли: почему падает БД, как переписать тот легаси-модуль, каким образом закрыть 4 проекта и какой костыль я оставил в проде три месяца назад.

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

В моём рюкзаке лежит всё, чтобы починить почти что угодно:

1. Флешки со всеми сборками восстановления, от Windows до Red
2. Ноутбук, который не потянет только косчические программы
3. Кабели и адаптеры на все случаи жизни
4. Гаджеты, стоимостью как чья-то зарплата

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

100 вкладок в VSCode, четыре разные СУБД на локальной машине, виртуалки, удалённые десктопы — всё это не заменяет простого «Как дела?», сказанного не формально, а с настоящим интересом. Не заменяет той минуты когда тебя слушают не чтобы найти root проблемы, а чтобы услышать твой голос.

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

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

#DevOPS #Programming

Микросервисы

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

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

1. Отвечает за одну бизнес-способность (пользователи, платежи, нотификации, поиск).
2. Имеет свою отдельную базу данных (да, это важно!).
3. Общается с другими через чёткий API (чаще всего HTTP/REST или сообщения в очередях).
4. Развёртывается и масштабируется независимо.

Ну а теперь неоспоримые факты + и -:

Мнимые:

1. «Это модно и у всех крутых ребят».
2. «Мы же как Netflix и Amazon!». (Забывая, что у них 5000 инженеров и свой дата-центр).
3. «Это решит все наши проблемы!». (Чаще всего создаст в два раза больше).

Реальная причина:

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

Цена вопроса

1. Сложность. Вместо одного приложения у вас теперь оркестр из десятков сервисов. Нужны: система обнаружения сервисов, API-шлюз, централизованное логирование, распределённый трейсинг, балансировщики, контейнеризация, оркестратор. Вы из программистов превращаетесь в сисадминов Вселенной.

2. Сетевая связность вместо модульной. Раньше у вас был вызов метода, теперь — HTTP-запрос по сети. Сеть не всегда бывает надёжна: таймауты, обрывы, задержки. Ваша логика теперь должна быть устойчивой к отказам. Добавьте сюда проблемы консистентности данных и необходимость идемпотентности операций.

3. Отладка превращается в квест. Ошибка пользователя «Не могу оплатить заказ» теперь может быть где угодно: в сервисе заказов, в платежном шлюзе, в очереди сообщений, в сервисе нотификаций. Придётся собирать лог-пазл по десятку разных систем. Без ELK-стека и Jaeger/Zipkin вы слепой.

4. Тестирование. Чтобы протестировать один сценарий, нужно поднять пол-архитектуры. На помощь приходят интеграционные и контрактные тесты, но они сложнее и медленнее.

Когда это НЕ НАДО делать?

У вас стартап и нужно быстро проверить гипотезу.
Ваша команда состоит из 5 человек в гараже.
Ваше приложение простое и будет таким всегда.
Вы не готовы содержать отдельную команду DevOps из 3+ человек.

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

Начинайте с монолита, разделяйте его на чёткие модули, а когда боль от изменений и деплоев станет невыносимой, то тогда, возможно, вы дозрели до того чтобы аккуратно откалывать от него первые сервисы, а не потому что «так сейчас все делают».

#Kotlin #Programming

Kotlin Multiplatform (KMP): Наконец-то один код для всех платформ?

Если вы когда-нибудь пилили один и тот же набор фич на Android (Kotlin/Java), под iOS (Swift) и ещё для десктопа (Kotlin/JVM), то вы наверное знаете ад дублирования. Один баг фиксишь в трёх местах, логику синхронизируешь через силу воли, а про тесты вообще молчу.

Kotlin Multiplatform (KMP) — это попытка JetBrains и сообщества дать нам, разработчикам, законное право написать общую бизнес-логику один раз, а потом использовать её везде.

Как это работает?

Представьте, что Kotlin это универсальный переводчик. Вы пишете код на нём, а компилятор транслирует его в нужный формат:

Для Android в байткод JVM (как обычный Kotlin).
Для iOS в нативный байткод (через LLVM), который понимает Swift/Objective-C.
Для браузера в JavaScript (Kotlin/JS).
Для сервера/десктопа снова в JVM.

Ключевой момент: KMP не заставляет вас писать весь код один раз. Он делит код на три части:

1. Common (Общий код). Тут живёт ваша бизнес-логика, модели данных, репозитории. Всё, что не зависит от платформы.
2. Platform-Specific (Платформенно-зависимый код). Всё что касается UI, работы с сенсорами, файловой системой, нативными API. Для каждой платформы идёт своя реализация.
3. Expect/Actual механизм. Это мосты между мирами. В common вы объявляете ожидаемую функциональность, а в каждом платформенном модуле предоставляете реальную реализацию.

// COMMON
expect fun getCurrentTime(): Long

// ANDROID
actual fun getCurrentTime(): Long {
    return System.currentTimeMillis()
}

// iOS
import platform.Foundation.*

actual fun getCurrentTime(): Long {
    return NSDate().timeIntervalSince1970.toLong() * 1000
}

Какие от этого плюсы?

Везде одна логика. Баг в расчёте скидки? Чините в common-модуле. Он исправится на всех платформах сразу.

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

Не «убивает» нативный UI. В отличие от Flutter или React Native, KMP не навязывает свои виджеты. Вы по-прежнему пишете UI на SwiftUI/Jetpack Compose/UIKit/XML. Это главный аргумент для команд, которые ценят нативный опыт.

Плавная миграция. Можно внедрять постепенно, начав с общей логики для двух платформ, не переписывая всё приложение.

Где вас ждёт основная боль?

Мультиплатформенные библиотеки. Их пока мало, для многих вещей (работа с БД, криптография) вам придётся либо искать expect/actual-обёртки, либо писать их самому.

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

Двойная нагрузка на архитектуру. Нужно продумать, что выносить в common, а что оставлять в нативной платформе. Плохое разделение приведёт к уродливым expect/actual костылям.

Compose Multiplatform. Это уже надстройка, которая позволяет делить и UI-код. Но это совсем другая история, почти как Flutter, но на Kotlin. Пока она в активной разработке и для продакшена нужна смелость.

Итоги:

KMP для вас, если:

1. У вас есть приложение на Android и iOS с общей сложной бизнес-логикой.
2. У вас есть команда Kotlin-разработчиков, которые не хотят учить Swift, но хотят закрывать задачи под iOS.
3. Вы цените нативный UI и производительность, но устали от дублирования функционала.

Обходите стороной, если:

1. У вас простое приложение или всего одна платформа.
2. Вы ждёте волшебную таблетку «пишем один раз — работает везде». KMP так не умеет, он требует дисциплины и понимания архитектуры.
3. Вам нужно быстро сделать прототип. Настройка KMP-проекта — это огромное время для разработчиков.

По сути, KMP это мост между мирами, который позволяет Kotlin говорить на всех языках экосистемы. Не идеально, иногда с помехами, но это рабочий и элегантный способ перестать плодить одинаковый код и сосредоточиться на уникальных фичах каждой платформы.

#Frontend #JavaScript

Как мы чуть не просрали весь современный web

Было время когда мир стоял на развилке: с одной стороны JavaScript, кривой, торопливый, сделанный за 10 дней парнем, которому просто нужно было «сделать что-то похожее на Java», с другой стороны VBScript, аккуратный, чистый, родной язык от Microsoft, интегрированный в Windows так, как никогда не сможет ни один другой скриптовый яп.
И знаете что? Мы были в одном шаге от ада, где весь веб писался бы на VBScript.

Что такое VBScript и почему Microsoft его продвигала?

VBScript (Visual Basic Scripting Edition) это облегчённый диалект Visual Basic, созданный Microsoft для написания скриптов. Он был частью экосистемы Windows: работал в Internet Explorer, в административных скриптах (WSH), в классическом ASP на сервере.

Его преимущества для Microsoft:

Знакомый синтаксис для армии разработчиков выросших на VB.
Прямая интеграция с ActiveX и COM-объектами, можно было дергать что угодно из системы.
Контроль. Если бы веб строился на VBScript, то Microsoft контролировала бы его де-факто.

Почему это была бы катастрофа?

1. Только Internet Explorer. VBScript работал только в IE, ни Firefox, ни Opera, ни тем более что-то на Mac или Linux. Веб тут же делился на два лагеря: «сайты для IE» (полнофункциональные) и «сайты для всех остальных» (урезанные). Фрагментация наступила бы мгновенно.

2. Безопасность? Зачем? VBScript через ActiveX имел доступ к файловой системе и реестру. Представьте: заходите на сайт, а он через скрипт форматирует вам диск или крадёт документы. Мечта хакера.

3. Закрытая экосистема. VBScript — проприетарная технология Microsoft. Никакого открытого стандарта, сообщества, которое могло бы влиять на развитие. Веб стал бы заложником одной компании.

Как JavaScript выжил и победил?

Netscape сыграла ва-банк. Они сделали JavaScript открытым и передали его для стандартизации в ECMA. Это был ключевой ход, язык перестал быть игрушкой одной компании.

«Достаточно хорош». JavaScript был кривым, но кроссплатформенным. Он работал везде, где был браузер, даже если с небольшими ошибками.

Сообщество. Разработчики, несмотря на все недостатки JS, начали копать в его сторону. Появились библиотеки вроде jQuery, которые скрывали ужасы нативной разработки под IE и другими браузерами.

Microsoft сдалась. Они увидели, что мир выбирает открытость, поэтому они создали JScript (свою, чуть изменённую, но в целом совместимую реализацию ECMAScript) и начали постепенно двигаться в сторону стандартов.

А что было бы, если бы победил VBScript?

Веб-разработка сегодня — это Visual Studio и только Windows.

React, Vue, SPA? Забудьте. Вместо Node.js у нас был бы IIS + ASP + VBScript.

Писать скрипты для автоматизации на Mac или Linux? Мечтайте.

Браузерные войны закончились бы полной победой IE, а значит — стагнацией на 15 лет.

Веб выжил не потому что JavaScript был хорош. А потому что он был МЕНЬШИМ ЗЛОМ.
Он был достаточно открытым, чтобы его могли улучшать все. Он был достаточно убогим, чтобы закалить тех, кто на нём писал. И он был достаточно гибким чтобы пережить взрывной рост сложности веб-приложений, где его создатели не могли даже представить.

В следующий раз, когда будете ругать undefined, NaN или странности this, вспомните: это цена, которую мы заплатили за то, чтобы веб остался свободным и открытым. Или просто скажите: «Спасибо, что не VBScript».

#Other

Когда-нибудь я его обновлю, когда силы будут...