#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

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

#Education

Кристаллы на процессоре

Когда смотришь на новенький Ryzen или Core i9, видишь лишь металлическую крышку и логотип. Но под ней, в самом сердце, лежит не просто «камень», там искусственно выращенная вселенная, самый совершенный кристалл на планете. И от его качества зависит будет ли твой процессор летать или едва ползти.

Что это вообще такое — «кристалл»?

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

Что на нём «делают»?

Каждый кристалл это целый мегаполис, спроектированный с точностью до атома.

Транзисторы это здания. Каждое по-сути микроскопический переключатель, который либо пропускает ток (1), либо нет (0). Современный 3нм техпроцесс это когда «здание» настолько мало, что для его постройки используют пучки единичных атомов.

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

Кэш это сверхбыстрые склады прямо в городе. Чтобы процессор не бегал за каждой инструкцией в медленную оперативную память, прямо на кристалле встраивают сверхбыструю статическую память (SRAM). L1, L2, L3 кэш это как полки, холодильник и кладовая прямо на кухне, чтобы не ходить в магазин через дорогу каждый раз.

Почему это так сложно?

Чистота. Одна пылинка, попавшая на пластину во время производства, убьёт десятки тысяч транзисторов. Заводы чище, чем операционная, а воздух фильтруется до класса 1 (менее 1 частицы на куб. фут).

Точность. Линии на кристалле сегодня тоньше длины волны видимого света. Чтобы их нарисовать, используют хитрости вроде EUV-литографии — «печатают» лазером, бьющим по каплям олова, чтобы создать плазму с излучением в 13.5 нм. Это одна из самых сложных машин, созданных человечеством.

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

А зачем там несколько кристаллов?

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

Кристалл процессора не просто «железо», а вершина человеческой инженерии, граничащая с алхимией и квантовой механикой. Мы буквально строим миры из песка, заставляя его думать и каждый раз, когда ты запускаешь игру или компилируешь код, ты заставляешь целый город атомов танцевать под твою дудку.

#Programming #Kotlin #Dart #KMP #Flutter

KMP vs Flutter

Если вы думаете что это выбор между двумя фреймворками, вы ошибаетесь. Это два лагеря, два видения мира, где каждый искренне убеждён, что оппоненты недалёкие анунаки, не понимающие очевидных вещей.
Посадите в одну комнату Senior Android-разработчика, который три года пилит KMP и Flutter-энтузиаста, который с нуля сделал пять приложений. Они не договорятся и в лучшем случае порвут друг друга в клочья.

Основная философия

Лагерь Flutter: «Ребята, какой нативный UI? Мы живём в 2026 году, у нас везде одни и те же дизайн-системы Material и Cupertino, которые пользователи уже давно не отличают от родных. Наша миссия убить дублирование кода насовсем: одна кодобаза, один язык, одна команда и приложение на iOS, Android, Web и даже на десктопе как с конвейера. Мы строим кроссплатформенный монолит и это прекрасно, а вы с вашими танцами с бубнами, вокруг двух кодобаз, просто застряли в 2010-х».

Лагерь KMP: «Вы, флаттеровцы, как дети которые радуются фломастеру, рисуя поверх шедевра. Ваша философия это вандализм, ведь вы берёте сложнейшие, отточенные годами платформенные UI-киты UIKit, Jetpack Compose и просто заменяете их своим самопальным рендерером на Skia. Да, он быстрый, но он чужой. Наш путь это путь архитектурной чистоты, потому что мы не трогаем святое — UI. Мы берём то, что действительно должно быть общим: логику, бизнес-правила, состояние, данные. Пишем это один раз на Kotlin и встраиваем в нативные приложения, которые пользователи ожидают получить. Мы не строим стену между юзером и его телефоном, Мы творим проход между разумными командами».

Язык и экосистема

Flutter-отряд: «Вы хотите заставить моих iOS-разработчиков, которые 10 лет дышали Swift и Xcode, учить Kotlin? Это бред, а Dart это современный, строгий, предсказуемый язык. У него потрясающий тулинг: hot reload, который реально работает, а не та унылая поделка что у вас. Вся экосистема заточена под фронтенд. Pub.dev это рай где на любой случай жизни есть три пакета. Ваш expect/actual это костыль уровня #ifdef из 90-х за который должно быть стыдно».

KMP-защитники: «Дарт? Серьёзно? Язык-зомби, который оживили только чтобы толкать Flutter? Его нигде кроме как у вас не используют. А Kotlin это стандарт для Android, язык для бэкенда (Ktor) и соответственно Multiplatform. Мои разработчики уже знают его и могут взять существующую тонну бизнес-логики из нашего бэкенда или Android-приложения, и засунуть её в iOS почти без изменений. Мои iOS-ребята учат не Kotlin, а архитектуру. Они получают готовые, протестированные модули и просто рисуют под них вьюхи. А ваша экосистема это свалка из тысячи пакетов, половина из которых заброшена потому что каждый школьник, сделав виджет-кнопку, выкладывает её на pub.dev».

Разработка кода

Flutter-инженер, тыкая пальцем в экран: «Смотри: вот у меня список, мне нужно добавить сложную pull-to-refresh анимацию с параллаксом, кастомным индикатором и изменением цвета. В Flutter это 30 минут работы. Один пакет, или даже самописный CustomScrollView. А теперь расскажи, как ты это будешь делать в KMP? Ах да, сначала ты три дня будешь писать общий expect-класс с данными, потом твой Android-разработчик неделю будет имплементировать это на Compose, а еще позже iOS-разработчик две недели будет втыкать в документацию SwiftUI, проклиная всё на свете, потому что анимации там другие. И в конце вы получите два разных поведения и втрое больше кода. Гениально».

KMP-архитектор, хладнокровно поправляя очки: «Ты описал не проблему, а её решение. Да, UI должен быть разным на разных платформах, потому что UX на iOS и Android разный. И да, мы платим за эту гибкость сложностью координации, но теперь опиши мою задачу: у меня есть сложный модуль расчёта кредитов с десятком правил, интеграцией с банковским API и кэшированием. В Flutter ты будешь писать его на Dart и молиться, чтобы пакет для работы с gRPC был стабильным, а на iOS не отваливалась сборка из-за какой-нибудь проблемы с Carthage. А я возьму проверенную, юнит-тестированную годами библиотеку на Kotlin, которая уже работает на бэкенде.

...оберну её в KMP-модуль и она заработает на обоих платформах идентично и без сюрпризов. Ваша «простота» иллюзорна. Она работает, пока ты в песочнице. Когда приходит реальный, сложный бизнес вы начинаете городить Platform Channels, что по сути есть признание поражения вашей «универсальности»».

Кто ты по масти?

Вы Flutter-boy если:

Вам критически важна бешеная производительность и нативное ощущение (интерактивные карты, сложный скролл 60fps).

У вас уже есть большие нативные команды, которые не хотят и не будут учить Dart.

Ваше приложение — это по сути нативный системный компонент, глубоко интегрированный в ОС.

Вы Kotlin-org если:

У вас стартап из трёх человек, которым нужно за месяц выкатить MVP на все платформы.

Ваше приложение это простой CRUD с формочками, где бизнес-логики на 50 строк.

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

В мире не бывает серебряной пули. Flutter это феноменальная скорость и единство на начальном и среднем уровне сложности. KMP это стратегическая точность и контроль для сложных, долгоживущих проектов с устоявшимися командами. Один лагерь кричит: «Смотрите, какой у меня красивый единый интерфейс!». Другой парирует: «А мой интерфейс — родной для пользователя и логика у меня выверена алмазом».

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

#Programming #Kotlin #Dart #KMP #Flutter

#Programming #Python

Flask позволяет быстро создавать сайты, оказывается

Бывает такое: месяцами работаешь с монструозными enterprise-фреймворками, где нужно 10 конфигов, 5 скриптов инициализации и ритуал с бубном, чтобы поднять Hello, World. Ты погружён в инъекции зависимостей, слои абстракций и философию «сначала архитектура, потом код» и кажется что иначе нельзя. А потом случайно открываешь Flask и понимаешь что всё это время тебя просто водили за нос.

Моё откровение было простым до смешного: Хотел наскоро сделать сайт с размером в 10 эндпоинтов, логикой на 500 строк, обработкой файлов и отдать JSON. По привычке полез настраивать Laravel и нырять в дебри PHP, но я вспомнил про python и подумал: «А почему бы во второй раз не попробовать»? (До этого был печальный опыт с ним)

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

Вот весь код приложения, которое уже можно запустить и оно ответит по HTTP:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello():
    return {'message': 'Hello, World!'}

if __name__ == '__main__':
    app.run(debug=True)

И это не игрушка, а рабочий инструмент без настройки миллиарда конфигов, никаких обязательных папок controllers/, services/, repositories/. Никакого кодогенератора, который создаёт 20 файлов, просто пишешь функцию и говоришь: «Эй, эта функция будет отвечать на запросы по этому адресу».

В чём фокус? Flask это микрофреймворк, его философия заключается в том чтобы дать самый минимум для старта, а всё остальное ты добавишь сам если нужно. Необходима работа с базой? Ставишь Flask-SQLAlchemy. Нужна аутентификация? Flask-Login. Нужны миграции? Flask-Migrate. Но если не нужно — не ставишь, никто не заставляет тебя тащить за собой килограммы зависимостей «на всякий случай».

Конечно, у этого подхода есть обратная сторона. Для большого проекта с командой из 10 человек можно наворотить таких костылей,что потом будет больно поддерживать. Flask не диктует архитектуру, он даёт свободу, а свобода это ответственность. Можно написать монстра на 5000 строк в одном файле, и Flask это проглотит и это будет твой выбор, и твоя проблема.

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

После Flask начинаешь с подозрением смотреть на все эти «промышленные» фреймворки и задаёшься вопросом: «А действительно ли мне нужны все эти слои абстракции или я просто следую модному тренду?».

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

1. Stud-Informer
2. irkpo-events

Оба проекта будут закрыты на неопределённый срок. Общий доступ (open source) сменится на проприетарную лицензию из-за невозможности продажи.

#DevOPS

Deploy проекта

Знаете этот трепет в пальцах когда вы делаете залив своей сборки на продакшен-сервер в 3 ночи, молясь чтобы не забыть какую-нибудь переменную окружения? А потом просыпаетесь от звонков потому что что-то пошло не так и вы не помните что именно залили?

Пора заканчивать с этим средневековьем. Deploy pipeline (пайплайн развертывания) это ваша автоматическая линия по сборке, проверке и доставке кода из гита на сервер. Это когда вы просто пушите в ветку, а дальше работает бездушная машина, которая делает всё за вас и вы не можете её отвлечь или заставить забыть шаг.

Зачем это нужно?

1. Повторяемость. Никаких «ой, я забыл запустить миграции». Если ты настроил пайплайн правильно, то он всегда выполнит все шаги.

2. Скорость. Автоматика делает всё быстрее и без твоих кофе-брейков.

3. Откат. Если после деплоя всё пошло по пизде, то одна команда откатит тебе приложение на предыдущую и стабильную версию.

4. Доверие. Ты знаешь что каждый коммит, который прошёл через пайплайн, был собран, протестирован и развёрнут одинаково.

Из чего состоит типичный пайплайн

1. Сборка (Build): твой код превращается в артефакт благодаря npm run build, docker build, mvn package. Если не собирается значит дальше не идём.

2. Тестирование (Test): запускаются автоматические тесты из юнитов, интеграционных и других. Если падают — не повезло.

3. Деплой на тестовое окружение (Deploy to Staging): артефакт летит на среду, максимально похожую на продакшен. Здесь можно провести ручное тестирование.

4. Деплой на продакшен (Deploy to Production): если всё окей, значит можно выкатывать на боевые сервера. Часто делается с ручным подтверждением (approval) или автоматически, если настроены canary-деплои/постепенное развертывание.

Инструменты: какие бывают конвейеры

Jenkins: старый, но могучий монстр. Гибкий, с кучей плагинов, но требует отдельного сервера и любви к настройке.

GitHub Actions / GitLab CI: модные, встроенные прямо в Git-платформу. Конфиг пишется в YAML-файле прямо в репозитории. Идеально для стартапов и большинства проектов.

TeamCity, CircleCI, Travis CI: другие облачные и self-hosted варианты. Выбор зависит от стека и бюджета.

Пример простейшего пайплайна на GitHub Actions для Node.js приложения

Файл .github/workflows/deploy.yml:

name: Deploy to Production

on:
  push:
    branches: [ main ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'

    - name: Install dependencies
      run: npm ci

    - name: Run tests
      run: npm test

    - name: Build project
      run: npm run build

    - name: Deploy to server via SSH
      uses: appleboy/ssh-action@master
      with:
        host: ${{ secrets.SERVER_HOST }}
        username: ${{ secrets.SERVER_USER }}
        key: ${{ secrets.SSH_PRIVATE_KEY }}
        script: |
          cd /var/www/myapp
          git pull origin main
          npm ci --only=production
          pm2 restart myapp

Что происходит: при пуше в main запускается виртуальная машина на Ubuntu, ставится Node.js, ставятся зависимости, прогоняются тесты, собирается проект и, если всё успешно, по SSH на боевой сервер отправляется команда на обновление.

Зачем всё это, если можно вручную?

Чтобы не быть заложником своего же процесса и любой разработчик в команде мог сделать деплой, не имея паролей от сервера в голове. Никому в 3 ночи не хочется гадать что сломалось, желательно иметь в логах пайплайна: «Упал на этапе тестов, потому что херня в коде».

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