RISC и CISC: два кита процессоров

В мире процессоров существует два принципиально разных подхода к архитектуре команд: RISC (Reduced Instruction Set Computing) и CISC (Complex Instruction Set Computing).

Основная идея

RISC — архитектура с умеренным и простым набором команд. Каждая команда выполняет простое действие и обычно укладывается в один такт процессора.

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

Предположим, нам нужно сложить два числа из памяти и сохранить результат обратно:

CISC (например под x86 архитектуру):

ADD [RAX], RBX ; сразу добавляет значение из RBX к тому, что лежит по адресу RAX

RISC (например под ARM архитектуру):

LDR R1, [R0]   ; загружаем значение из памяти в R1
ADD R1, R1, R2 ; складываем значения в регистрах
STR R1, [R0]   ; сохраняем обратно в память

Заметно, что в RISC каждое действие вынесено в отдельную инструкцию.

Что используется сейчас?

Большинство современных архитектур — гибриды. Например:

x86-64 (Intel/AMD) — формально CISC, но внутри выполняется микро-декодинг в RISC-подобные микрокоманды.

ARM (включая Apple Silicon) — классический RISC с мощной оптимизацией.

Выбор между RISC и CISC — это компромисс между простотой, мощностью и совместимостью. RISC часто проще и эффективнее в мобильных и встраиваемых системах. CISC даёт гибкость и обратную совместимость на десктопах и серверах.

#Programming #ITLife #Other

Что в сумке у программиста?

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

1. Ноутбук (или боевой ультрабук/MacBook) Рабочая лошадка, твоя консольная катана. Без него ты просто человек с хорошей осанкой. Желательно на Linux или dual-boot с Windows и FreeBSD, чтобы можно было не только кодить, но и чинить прод в 4 часа ночи.

2. Power Bank (и желательно два). В мире где розетки редкий артефакт, power bank — это артефакт уровня S++ класса. Один на телефон, другой на ноут, потому что зум коллы не ждут.

3. USB-hub. Твой порт в мир legacy-оборудования. Особенно если у тебя модный макбук с двумя Type-C. Сплиттер, кард-ридер, адаптер — пусть будет всё.

4. Переходники всех видов

USB-C ➖ USB-A

HDMI ➖ VGA (да-да, в некоторых местах проекторы остались из эпохи динозавров)

Ethernet ➖ USB

DisplayPort ➖ HDMI

5. Несколько флешек. Минимум две: одна для файлов, проектов и прочего говна, другая — для переноски "вот этих трёх скриптов, только никому не показывай". Лучше, если они зашифрованы и подписаны твоим GPG-ключом.

6. Внешний SSD с ISO образами, утилитами, бэкапами, фотками кота и Minecraft-сервером. Бывает момент, когда именно он спасает день.

7. Умная отвёртка/мультитул. Разобрать ноутбук, закрутить стойку в серверной или просто открыть бутылку пива после релиза.

8. Зарядки и кабели. Как минимум по два каждого типа: Type-C, microUSB, Lightning — и кабель для зарядки ноутбука, конечно. Никаких "а можно у тебя провод взять?".

9. Wi-Fi адаптер. Потому что встроенный в Linux сломался. Опять. А заказчик уже на зуме.

10. Блокнот и ручка. Иногда написать от руки — это тоже dev-магия. Особенно, если внезапно планируешь архитектуру микросервисов на салфетке в баре.

11. Антистресс-игрушка. Релиз выкатился с багами, клиент хочет за два часа то, что делается две недели, а интернет упал. Сжав игрушку, ты не сожмешь чью-то глотку.

12. Удлинитель и тройник. Программист без розетки — как код без комментов: вроде работает, но страшно.

Уважающий себя программист — это не просто чувак с ноутбуком. Это настоящий выездной DevOps-юнит с баг-фиксом в одной руке и ISO-шниками в другой. Твоя сумка — твой арсенал. И если ты к этому готов, то никакой прод тебя не испугает.

#DevOPS #Education

Docker изнутри: как запускается магия контейнеров

Ты пишешь docker run nginx и всё как бы работает. Но за этой командой скрыт целый механический оркестр из системных вызовов, демонов и Linux-чародейства. Погнали разбирать по полочкам.

1. Контейнер — это не виртуалка.
Никаких виртуальных машин, BIOS и танцев с ISO-шаманом. Контейнер — просто изолированный процесс. Ядро общее, но ты в своей песочнице. Типа общага с личной комнатой, но общей кухней.

2. Docker Engine: тройка в упряжке.

dockerd — демон(Daemon), главный шеф всех контейнеров

CLI (docker) — тыкаешь команды

REST API — всё общение между ними

Написал docker run nginx → твой терминал шлёт демону запрос → демон орёт: "Тащите образ!" → запускается контейнер → появляется nginx → магия.

3. Изоляция через namespaces.
Docker делает вид что каждый контейнер — отдельный мир:

свои процессы
своя сеть
своя файловая система

даже свой hostname, например, i-am-root-but-only-here.local

Выглядит как отдельная ОС. А по факту? Просто изолированный шальной процесс.

4. Cgroups — следим, чтоб не обожрался.
Ты программист, ты знаешь как легко аппка может жрать 20 ГБ RAM ради вывода “Hello world”. Cgroups не даст: хочешь 512 МБ — сиди на диете. CPU? Только половинку. Хочешь больше — иди в прод.

5. Union FS — многослойная кулинария.
Представь бургер: снизу булка (Ubuntu), сверху сыр (nginx), а потом твоя кастомная начинка. Docker собирает образы слоями. Всё, что не меняется — read-only, всё что ты ломаешь — в верхнем write-слое.

6. Запускаем через runc.
Когда пора стартовать, dockerd вызывает runc, который делает clone(), chroot() и другие тёмные ритуалы. А процесс уже не видит остальных — он в изоляции. Одинокий, но свободный.

7. Docker Images.
Образ = набор слоёв, каждый из которых — изменение. Установил apt update? Новый слой. Добавил .env? Ещё слой.
Образы можно хранить у себя или пушить на Docker Hub, типа Telegram, но только для системных админов.

8. Docker-сети.
Контейнеры не просто сидят, они умеют болтать: через bridge, host, overlay.
Нужно подключить Nginx к backend'у? Создай сеть.
Хочешь поиграть в sysadmin-ад? Настрой overlay и Swarm.

9. Безопасность: потому что ты не root
Docker прикручивает:

seccomp — список “не трогай это”

AppArmor/SELinux — чтобы контейнеры не начали читать твои секретные PDF

user namespaces — контейнер думает, что он root, но на деле — мелкий пользователь без прав

10. Что делает docker run nginx?

1. CLI: «Запускаем nginx!»
2. Демон: «Ща поищу образ...»
3. Создаётся слой для записи
4. Изоляция через namespaces
5. Cgroups — не обжирайся!
6. runc: "Ща всё сделаю"
7. Подключение к сети
8. Старт процесса

Контейнер живёт, пока жив запущенный процесс. Умер процесс? RIP контейнер.

11. Это не магия. Это Linux.
Всё работает на:

namespaces
cgroups
overlayfs

chroot, clone, seccomp,
Docker просто удобно это оборачивает.

Ты не волшебник — ты просто пользуйся Docker. Но если хочешь чтобы контейнеры не ссали в твой прод, понимай как они работают.

#Education #OS

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

1. x86 / x86-64 (aka архитектура которой пора на пенсию, но она держится)

Появилась в 1978 году с Intel 8086. С тех пор прошла через DOS, Windows 95, Crysis и дожила до ChatGPT.

Кто рулит: Intel и AMD

Где используется: ПК, ноуты, сервера, пекарни на Unreal Engine

Плюсы: Мощная, универсальная, поддерживает тонны legacy-программ

Минусы: Большая, жрущая и дико сложная — как бабушкин шкаф

Архитектура настолько древняя, что в ней до сих пор живёт режим совместимости с 16-битным кодом.

2. ARM (или как твой телефон выживает без зарядки хотя бы до обеда)

Родилась в 1983 году в Великобритании (Acorn Computers). Тогда думали — просто дешёвый процессор для школьных ПК. А теперь она везде.

Где используется: смартфоны, планшеты, Raspberry Pi, Apple M-серии

Кто рулит: ARM Holdings лицензирует, а Apple, Qualcomm, и другие внедряют

Плюсы: Энергоэффективна, дешёвая, масштабируемая

Минусы: Требует портирования ПО, ограничена в high-end серверных задачах (пока)

В ARM нет инструкции "делить", потому что "а зачем". Потом правда, добавили.

3. RISC-V (когда хочется всё и бесплатно)

Появилась в 2010-х в Университете Калифорнии в Беркли. Задумана как полностью открытая RISC-архитектура.

Где используется: исследовательские проекты, Китай, стартапы, IoT

Плюсы: Бесплатная, модульная, кастомная под что угодно

Минусы: Сырая экосистема, нехватка поддержки

Уже есть микроконтроллеры, полностью сделанные на RISC-V и открытых инструментах. Stallman одобряет.

4. MIPS (был легендой, теперь спит в шкафу истории)

С 1981 года один из пионеров RISC. Использовался в PlayStation, роутерах, принтерах и холодильниках.

Где используется: встраиваемые системы, маршрутизаторы, китайские дешёвые ноуты

Плюсы: Простота, стабильность

Минусы: Умер. Почти.

Его пытались реанимировать как open source, но никто не пришёл на похороны.

5. Power/PowerPC (когда IBM ещё что-то значила в железе)

Совместная разработка IBM, Apple и Motorola в 1990-х. Была основой первых Mac и Xbox 360.

Где используется: Суперкомпьютеры, серверы

Плюсы: Мощная, стабильная, масштабируемая

Минусы: Сложность, ограниченная поддержка

Некоторые современные процессоры для спутников всё ещё используют PowerPC, потому что "работает и хрен с ним".

6. SPARC (забудь, если не работаешь в Oracle или NASA)

Разработана Sun Microsystems в 1987. Была крута в серверах и научных вычислениях.

Где используется: Государственные суперкомпьютеры, серверы Oracle

Плюсы: Надёжная, масштабируемая

Минусы: Практически мертва, Oracle всё закопало

SPARC до сих пор работает в некоторых ядерных центрах. Там просто не рискуют менять что-либо вообще.


Что общего между ними?

Все исполняют машинный код

Все оперируют с регистрами, памятью, ALU и прочей схемотехникой

Все создают проблемы разработчикам под разные платформы

По итогу:

Хочешь удобства и мощи — x86/x64;
Хочешь энергоэффективности и мобильности — ARM;
Хочешь свободы и DIY — RISC-V;
Хочешь заниматься некромантией — PowerPC или SPARC;

Архитектура — это не просто выбор, это мировоззрение.

#OS #Linux

Unix-подобные системы: легенды, которые живы

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

Что вообще значит "Unix-подобная"?

Это не "почти Unix", это "почти святая троица":

всё — файл

всё, что можно, делаем через терминал

ничего лишнего, пиши свои костыли сам

Главные ветки Unix-еволюции:

1. GNU/Linux — буйный сын, который ушёл в рейв

Ядро — Linux, оболочка — GNU

Массово на серверах, в роутерах, у анонимусов и задротов

"Linux — это не Unix", говорили бородатые деды, но мир решил иначе

Дистрибутивов столько, что если пересчитать — можно вызвать дьявола

2. BSD-семейка — элита в очках

FreeBSD, OpenBSD, NetBSD, DragonFlyBSD

Академичные, стабильные и скучные — как профессор, который ещё и код ревьюит

Используются в Netflix, Juniper, даже в PlayStation 4

FreeBSD — стабильность, OpenBSD — безопасность, NetBSD — "запустится даже на кофемашине"

MacOS частично построена на FreeBSD. Так что каждый раз, когда ты тыкаешь по Finder — где-то в душе рыдает бородатый Unix-дед.

3. MacOs — гламурный фрейм Unix-моды

Под капотом ядро XNU + Darwin + POSIX-совместимость

Выглядит как Instagram*, ведёт себя как FreeBSD

Разработчики на Mac работают в терминале, чтобы казаться серьёзнее так как не знают, что у них Unix. Но у них brew работает и хер с ними.

4. Solaris/illumos — древняя религия

От Sun Microsystems, ныне Oracle

ZFS, DTrace, контейнеры до Docker'а — всё это появилось здесь

Сейчас в полураспаде, но в академии до сих пор на алтарях

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

5. AIX, HP-UX, SCO — системные динозавры

Живут в дата-центрах, которые никому нельзя показывать

Их админы старше всех твоих IDE вместе взятых

С ними всё как в старой притче: "работает — не трогай"

SCO когда-то судился с IBM за Linux. Проиграл. Ушёл в небытие.

Фишки всех Unix-подобных:

man(мануал) — твой лучший друг, если ты не гуглишь

/etc/shadow — даже звучит как магия

Файлы конфигураций могут быть 500 строк и все важные

Ничего не спрашивают — просто делают. Или умирают с Segfault.

А что ещё?

Терминал — царь. Всё остальное — его вассалы.

Pipes (|) — склеивают мир, как суперклей для текстовых потоков

grep + awk + sed — секретные заклинания UNIX-мага

Кто не читал "The Art of Unix Programming" — тот не шарит


Unix — это не просто ОС, это способ жить:
пиши сам, читай man, не доверяй GUI и никогда, слышишь, никогда не редактируй /etc/fstab в пьяном виде.

*Instagram запрещен на территории РФ.

#Programming #Backend

Веб-серверы

Ты заходишь на сайт и видишь котиков. А кто тебе этих котиков подаёт? Правильно — веб-сервер. Без него твой браузер просто смотрит в пустоту, как студент на экзамене без шпоры.

Очень нужная духота:

1989 — Тим Бернерс-Ли в CERN придумывает WWW и первый веб-сервер CERN httpd. Работал только на NeXT и с HTML 1.0. Представь: никакого CSS, ни JS, просто текст. Красота!

1995 — появляется Apache. Почему такое название? Потому что это был «a patchy server» — сервак на костылях и патчах.

2000-е — Nginx от Игоря Сысоева становится спасением от перегрева серверов на больших нагрузках.

Сегодня — всё крутится на Nginx, Apache, LiteSpeed, Caddy и даже Node.js, если ты вfrontend-инженер с амбициями.

Главные игроки:
1. Apache
– дед,
– умеет всё: CGI, .htaccess, виртуальные хосты, логирование на уровне NASA
– но жрёт память как браузер с 30 вкладками и 3 YouTube

2. Nginx

– лёгкий, быстрый как курьер на самокате
– не жрёт ресурсы даже когда к тебе ломится 100к пользователей
– идеален как реверс-прокси, балансировщик, статика-фетчер и девопс-друг

3. Caddy

– встроенный HTTPS по умолчанию (даже если ты не просил)
– конфиг простой, как инструкция к дошираку
– но кастомизация — боль

4. LiteSpeed

– платный, но эффективный
– любят хостинг-провайдеры за производительность
– идеален для Wordpress и других клонов php-адской хуйни

5. Node.js + Express

– не веб-сервер в чистом виде, но часто используется как таковой
– любим JS-девами: «Зачем использовать проверенные решения, если можно написать свой велосипед на async/await»

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

• Браузер отправляет HTTP-запрос

• Веб-сервер его принимает

• И либо отдаёт статику (HTML, CSS, JS), либо прокидывает дальше в backend (PHP, Python, C#)

• Ответ обратно летит в браузер

Если упрощённо: веб-сервер это официант, который несёт блюдо с кухни (бэкенда) к клиенту (браузеру). Чем лучше официант — тем быстрее еда и меньше жалоб в гугл-картах.

Зачем знать про веб-серверы?

Потому что если ты не понимаешь что именно делает proxy_pass, RewriteRule или Listen 443 ssl, то ты будешь чинить сайт так же, как бабушка чинит телевизор — крестясь и брызгая святой водой.

Веб-сервер — это основа любого сайта. Apache, Nginx и их братья не просто софт, а солдаты невидимого фронта, которые каждый день делают возможным наш клик по "открыть кота в новой вкладке".

#OOP

ООП — и почему нормальная его реализация возможна только в динамически типизированных языках

Когда очередной Java-дев говорит тебе: «Объектно-ориентированное программирование — наше всё», — хочется спросить: ты вообще понял что такое ООП, или просто полюбил extends и implements?

Что такое "нормальное" ООП?

Это не просто класс и объект. Это:

Инкапсуляция — прячем детали реализации

Наследование — расширяем и модифицируем поведение

Полиморфизм — используем объекты, не зная, как они реализованы

Динамическое поведение — возможность модифицировать поведение на лету

Теперь смотри что из этого ломается в статике:

C#, Java, и другие статично-типизированные мучители

1. Бессмысленные интерфейсы: Чтобы один метод render() можно было вызвать на разных объектах — ты обязан влепить всем им implements Renderable. Это не полиморфизм, это бюрократия. Это будто ты не можешь говорить «привет», пока не получишь лицензию на коммуникацию.

2. Наследование в ад: Ты хочешь просто изменить одно поведение? Лови 5 уровней наследования, абстрактный базовый класс и побочные эффекты в рантайме, которые ты будешь дебажить неделями. "SOLID"? Да ты блядь просто хочешь чтобы кнопка работала!

3. Компилятор = идиот: он запрещает тебе делать нормальные абстракции. Ты не можешь просто подменить метод. Всё должно быть чётко, строго, скучно и в рамках.

4. ООП в Java — это просто glorified switch-case: вроде классы разные, а внутри у каждого метода if (x instanceof Y) или switch(enum). Отлично, так можно было и процедурщиной обойтись, без всей этой шизофазии.

Теперь смотри как живут в динамике:

Python, Ruby, JavaScript:

Хочешь добавить метод объекту в рантайме? Добавил.

Хочешь объект, который просто умеет .bark()? Достаточно чтобы метод был, всё остальное по хую.

Хочешь объект, поведение которого зависит от ситуации? Легко: декораторы, monkey patching, всё, что хочешь.

Duck typing — вот истинный полиморфизм.
Если объект ведёт себя как утка, крякает как утка — значит, это утка. Не нужно наследование, не нужны интерфейсы, не нужно согласие компилятора.

Философская мысль:

ООП — не про классы, а про поведение.
Про то, что объект должен быть сущностью с обязанностями и возможностями.
А в Java он — раб абстрактного класса. В C# он — геттер-сеттерный NPC с автоматическим свойством. В Python — это живой организм.

"Но в динамике нет типов!" — говорят хрустящие сеньоры.

Да и хуй с ними.

У тебя в голове есть тип Human, но ты же не проверяешь у каждого прохожего instanceof Human.

Ты просто смотришь: если говорит, ходит, не кусается — значит норм чел.


ООП в C#/Java — это как BDSM с правилами от HR.

ООП в Python/JavaScript — это как импровизация в джазе: ты чувствуешь как надо и делаешь.

Компилятор должен помогать, а не мешать. Если ты боишься, что obj.dance() вызовет ошибку — пиши тесты, а не 40 слоёв обёрток.

#Backend #Education

Как Java стал популярным: спасибо JVM, а не заварке

Когда ты слышишь "Java", тебе может прийти в голову только Enterprise, Spring, маниакальные XML-конфиги и люди, которые пишут getUser().getAddress().getCity(), и называют это нормой.

Но на самом деле Java — это больше, чем просто язык. Это целая платформа. А теперь разберёмся, почему она вообще взлетела.

Как всё начиналось

1995 год. Sun Microsystems выпускает Java с лозунгом "Write Once, Run Anywhere".
И это не маркетинговая лапша как у некоторых…
Java реально дала возможность запускать один и тот же .class файл на любой ОС благодаря магии JVM.

JVM: сердце Java

JVM (Java Virtual Machine) — это та самая херня, которая позволяет твоему Java-коду жить вне зависимости от железа и операционки.
Ты пишешь в .java, компилируешь в байт-код .class (javac), а JVM уже разбирается как это крутить на Windows, Linux, MacOS, или, прости господи, Solaris с FreeBSD.

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

1. Ты пишешь код на Java

2. Компилятор превращает его в байт-код (не исполняемый код, а "среднее")

3. JVM получает этот код, проверяет, оптимизирует и запускает

4. Используется JIT (Just-In-Time compilation), который превращает байт-код в нативный прямо во время исполнения

JIT — тот самый чит благодаря которому Java не такая медленная, как её хейтят. Иногда даже быстрее Python и Ruby (что несложно).

Почему это выстрелило?

Кроссплатформенность: в 90-х это было революцией. Никаких компиляций под каждую ось.

Платформа, а не язык: Java не просто язык — это JVM + библиотеки + экосистема

Инфраструктура: сервера, банки, терминалы — всё это стало на Java так как стабильность и предсказуемость → короли для бизнеса.

Spring и прочий энтерпрайз: сложно, перегружено, но работает. А бизнес любит когда "работает".


Java стала популярной не из-за языка, а из-за:

JVM — виртуальной машины с хорошей оптимизацией;

IDE и tooling’а — попробуй IntelliJ и ты поймёшь;

огромной экосистемы;

бизнеса, которому надо предсказуемо, стабильно, и чтоб 10 лет без поддержки работало;

#Backend #Education

CLR — когда Microsoft решила: «а давайте как в Java, только наше»

Ты думал что .NET — это просто C#? Не-а. В центре всей этой империи — CLR (Common Language Runtime). Это такая же виртуальная машина как у Java — JVM, только с виндовым акцентом и .NET-флером.

Что такое CLR?

Это исполняющая среда, которая:

1. Компилирует твой код (C#, F#, VB.NET и даже Python через IronPython) в байт-код CIL (Common Intermediate Language)

2. Потом JIT-компилятор превращает CIL в машинный код

3. А после этот код исполняется под управлением CLR

Проще говоря: это JVM от Microsoft. Только они это не признают.

Как это работает (упрощённо):

1. Ты пишешь код на C#

2. Компилятор превращает его в CIL (аналог байт-кода)

3. CIL попадает в CLR, где:

3.1 Срабатывает JIT-компиляция (или AOT в .NET Native/CoreRT)

3.2 Применяется сборка мусора (Garbage Collection)

3.3 Производится валидация типов, безопасность и всякая магия

4. В итоге ты получаешь исполнение кода с управляемым рантаймом

Сходства CLR и JVM:

Java была первой: JVM в 1995, а CLR в 2002.
Microsoft такие: «Годно. Копируем. Только XML ещё добавим!»

JVM про "write once, run anywhere"
CLR — "run only on Windows..." ну, пока не появился .NET Core и потом .NET 5+

JVM открыли позже (OpenJDK)
CLR — тоже открыли, но долго и неохотно. Типа "ну ладно, смотрите если очень надо"

Почему CLR важен?

Мультиязычность — ты можешь писать и на F#, и на C#, и даже на COBOL.NET (если очень плохо себя вёл)

Интеграция с Windows — идеальная для бизнес-приложений, WinForms, WPF и всей этой корпоративной утвари

Скорость — с появлением CoreCLR, RyuJIT и AOT — платформа стала реально конкурентоспособной

Эволюция — от старого .NET Framework до .NET 9 всё упростилось и ускорилось

CLR это по сути "мы дома тоже так можем" от Microsoft в ответ на JVM.
Работает? Да. Быстро? Уже да. Удобно? Смотря где.
Java захватила банки, Microsoft — корпорации. У каждого своя секта и свои плюсы.

#Programming #Python

IronPython

В своё время Microsoft захотелось Python, но чтобы в .NET и создали IronPython. Это не просто реализация языка. Это попытка впихнуть питонячью душу в CLR-костюм.

Что это вообще?

IronPython — реализация Python на платформе .NET/Mono.
Вместо обычного интерпретатора (CPython) он компилирует Python-код в байт-код и запускает его в Common Language Runtime.

Плюсы:

Интеграция с .NET — можешь использовать C#-библиотеки, классы, WinForms и даже WPF из Python.

Работа на Windows максимально нативная. Прям вот "родной язык" в корпорациях.

JIT от CLR — Python-код работает через Just-In-Time-компиляцию CLR, и иногда шустрее чем CPython.

Минусы:

Не совместим с C-питонячьими расширениями — никакого тебе NumPy, SciPy и прочего C-магнитного добра.

Отстаёт по версиям — IronPython долго застревал на Python 2.7, а только недавно начал двигаться к 3.4+ (на текущий момент актуальная версия 3.13+)

Низкая популярность — большинство питухонеров даже не знают о нём

Когда использовать?

1. Если ты в .NET мире, но любишь Python

2. Нужно склеить C# и Python без плясок с COM, RPC, gRPC

3. Хочешь написать скриптовую логику на Python внутри C#-приложения

Пример: вызов .NET кода из Python

import clr
clr.AddReference("System.Windows.Forms")

from System.Windows.Forms import Form, Label, Application

form = Form()
form.Text = "IronPython rocks!"
form.Controls.Add(Label(Text="Привет из CLR"))

Application.Run(form)

Да, это реальный WinForms — на Python. Мир перевернулся, да?


IronPython — странный, мощный и немного забытый зверь.
Он не для всех, но если ты застрял в мире .NET и не можешь без print("hello world") — это твой выход.

#meme

Всем Cock-NET'чикам и Java-макакам посвящается:

Жду вас в комментариях, ой...

#Education #Frontend

Firebase — это как шаурма на углу: быстро, вкусно, но не факт что выдержит продакшн

Всё просто: ты фронтендер и хочешь бэкенд, но руки не доходят до Node.js, а база данных звучит как приговор? Тогда Google подлетает на белом облаке: "Держи Firebase, мой юный питомище, теперь ты — фуллстек".

Что вообще такое Firebase?

Это облачная платформа, которая предлагает тебе:

Базу данных
Аутентификацию
Сервера без серверов
Хостинг
Аналитику
Push-уведомления

Причём всё это "as-a-service", инициализирующаяся одной командой в терминале, как магия.

Компоненты Firebase:

Authentication — как Face ID, только для твоего проекта. Сюда можно затащить всех: Google, GitHub, Facebook*, бабушку с email'ом.

Realtime Database — база данных для тех кто не знает, что такое нормализация. Всё в JSON, всё в реальном времени, всё в одной ветке, как ёлка.

Cloud Firestore — тот же Realtime, только не на костылях, а уже с костылём от Google. Структура: коллекции, документы, вложенность. NoSQL, но с минимальной адекватностью.

Cloud Functions — тебе дали сервер, но сказали: "только тронь и он исчезнет". Это как волшебная палочка, только на Node.js. Пиши функции, вызывай их как API.

Hosting — "а можно я свой pet-проект задеплою?" — можно. Одной командой. С HTTPS. Без боли.

Analytics и Crashlytics — смотри как умирает твой проект в реальном времени и с графиками. Google знает, где ты ошибся.

Когда Firebase как спасение:

MVP: быстро, чётко, без бэкендера на фрилансе

Прототипы: показал — выкинул

Учебные проекты: чтоб дед из методички ахуел

Стартап на питании одной лапшой

Когда Firebase как шлакоблок:

Тебе нужен JOIN — иди на PostgreSQL

Считаешь каждую копейку — Blaze тариф может внезапно выжечь кошелёк

Пишешь сложную бизнес-логику — будешь упарываться в Firebase Rules, как в лабиринт Минотавра

Доверяешь только себе — тут ты полностью зависим от Google

Firebase — это как конструктор LEGO.
Ты собираешь идеальный pet-проект, пока не приходит взрослый дядя-бэкендер и не говорит: "где база на PostgreSQL, где доки, где CI/CD?"

Но для старта, демо, лайтовых продов это мечта, а не платформа.

*Facebook принадлежит компании Meta**, признанной экстремистской организацией и запрещенной в РФ;
**Meta признана экстремистской организацией и запрещена в РФ;

#OS #Windows

MS-DOS: мать всего, отец и дед современных ОС

Когда мир ещё не знал что Windows может синим экраном убивать нервы, в нём правил MS-DOS. Это была операционная система без окон, мышки и жалости.

Что такое MS-DOS?

Microsoft Disk Operating System — текстовая ОС, работающая напрямую с железом.
Да-да, никакого интерфейса: только ты и командная строка.
Ты либо учишься пользоваться cd, dir, copy, format, edit — либо ты просто не живёшь.

Краткая история:

Создана в 1981 году на основе 86-DOS, купленной Microsoft у Seattle Computer Products

Была основой для первых версий Windows (до 95-й запускалась прямо из неё)

Последняя официальная версия MS-DOS — 6.22 (1994)

После 2000-х заброшена, но легенда жива в виртуалках

Факты:

Занимала менее 1 МБ (влезала на дискету)

Поддерживала 640 КБ ОЗ, и этого «должно было хватить всем» © Билл Гейтс

Не имела многозадачности — одна программа за раз

Нет GUI — командная строка была всем (не совсем но это тема следующего поста)

Типичные команды MS-DOS:

C:\> DIR         # список файлов
C:\> CD GAMES    # зайти в папку
C:\> COPY A:\*.* C:\BACKUP  # скопировать файлы с дискеты
C:\> FORMAT C:   # случайно форматнуть весь винт (без подтверждения!)

Почему это было больно:

1. Один неверный FORMAT и весь винт идёт нахуй

2. Никакой защиты от сбоев

3. Файловая система FAT16 поддержка до 2 ГБ максимум

4. Любой сбой — перезагружаем комп кнопкой

Зачем знать MS-DOS сегодня?

1. Для ретро-фетишистов

2. Чтобы запустить старые игры через DOSBox

3. Чтобы понять, откуда растут ноги у современных командных оболочек, потому что cmd.exe — это потомок DOS, а dir, cd, echo, copy — всё оттуда


MS-DOS это как дед в кресле-качалке:
давно на пенсии, но если спросишь как починить загрузчик — он знает лучше тебя.

#ItLife

Я вас всех перебью. Виртуально, морально, технически.

Ты сидишь, читаешь это и думаешь: "Очередной заебанный айтишник выебывается".
А я и не выебываюсь. Я сдерживаю ярость.

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

Ты не знаешь. Ты просто видишь проект, который работает. А значит кто-то умер чтобы ты мог это увидеть.

Я не умничал, я работал. Писал ночью, фиксил утром.
Когда вы «отдыхали от всего», я шёл в бой с новой IDE.
Когда вы жаловались на стек технологий, я в нём жил.

Я не лучший. Я просто остался. А остальные — сгорели.

Каждый мой проект это список ошибок, багов и компромиссов, которые я прожил на себе.
Моя голова не отдыхает. Мой сон это список задач в фоне.
Мои руки помнят git push даже в состоянии полусмерти.

Так что не лезь со своими нравоучениями.
Я не просил сочувствия. Я — не вы.

Я просто знаю что если проект умрёт — его подниму я.
Если всё развалится — я соберу заново.
Потому что у меня нет другого выхода. И никогда не было.

Вот почему я лучший. Не потому что круче. А потому что я не сошёл с ума; пока ещё.

#OS #Windows

Windows: из графического костыля в императора офисных ПК

Когда вы запускаете Windows, то возможно думаете, что это нечто самостоятельное. Но нет — в самом начале своего пути, Windows была просто графической накладкой над MS-DOS.

Первая версия Windows вышла в 1985 году, она не была ОС в привычном смысле, а графической надстройкой над MS-DOS и запускалась через команду win.

MS-DOS отвечал за всё важное: доступ к дискам, памяти, управлению процессами.
А Windows... просто рисовала окошки.

Что было под капотом:

Windows 1.0–3.11: полностью зависимы от MS-DOS. Без COMMAND.COM ты никуда не денешься.

Windows 95/98/ME: уже выглядели как полноценные ОСи, но под капотом всё тот же DOS, грузящийся первым.

Любой краш и ты видишь знакомое C:\> как лобовое стекло после ДТП.

Когда всё изменилось:

С приходом Windows NT (New Technology) в 1993 году (и позже XP, 7, 10) Microsoft ушла от DOS-ядра.
Теперь Windows стала настоящей операционной системой, с собственной архитектурой ядра, защищённой памятью и многозадачностью.

Наследие DOS в Windows:

1.До сих пор жив cmd.exe, который по сути правнук COMMAND.COM

2. Многие команды (dir, cd, copy) из тех времён

3. Некоторые драйверы ещё долго опирались на устаревшие DOS-интерфейсы

4. Даже путь C:\Windows\System32 — отголосок древней архитектуры


Windows разрабатывалась как декоративная надстройка, а позже стала монополистом в ОСях.
Но мы всё ещё не забыли как win.com запускал графику, а autoexec.bat настраивал жизнь.

#ItLife

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

И да, мы не в 2003 году. Это не «прикол», это реальное нарушение закона.

Юридически ты сделал следующее:

1. УК РФ, 272 ст.:

Неправомерный доступ к компьютерной информации

До 200 тысяч рублей штрафа или до двух лет лишения свободы.
Просто за то что ты без спроса залез туда, где тебе быть не положено.

2. Федеральный закон №152

«О персональных данных»:

> Обработка без согласия субъекта — прямое нарушение.
Даже если «ничего не взял», «просто посмотрел» — уже нарушение.

3. Конституция РФ, ст. 23:

Нарушение неприкосновенности частной жизни и личной информации.

Ты не просто уебался, ты пошёл против базовых прав человека. Ты их нарушил.

А теперь ещё интереснее: ты не только залез в чужое,
ты потом пошёл и НАГЛО СОВРАЛ, что получил на это разрешение.
Что это? Попытка манипуляции? Давления? Или просто ты настолько привык врать, что не замечаешь?
Ты блядь всерьёз считаешь, что можно прикрываться «я ж просто по работе»?
Админ это не про вседозволенность. Админ — про доверие.
И если ты его нарушаешь, то тебя надо не просто увольнять, тебя надо гнать из профессии, как позорную шалаву.

У тебя есть логины, пароли, привилегии. Но это не делает тебя выше закона.
Это делает тебя ответственным.
А ты не справился. Ты проебал доверие.

И если ты думаешь, что никто не подаст жалобу, то ты сильно недооцениваешь последствия.

Что будет дальше:

Логи можно выгрузить.
Жалобу — написать.
Статьи — применить. Опыт есть

А Тебя — выебать юридически так, что в следующий раз подумаешь, прежде чем даже открывать чужие директории, потому что если ты снова сунешься туда куда не просили — я не напишу здесь. Я напишу заявление в нужные органы.
И ты пойдёшь не по Git-истории, а по статье.

Играешь во взрослую жизнь — отвечай по-взрослому.

#Backend #Database

Архитектор баз данных + backend — это не два человека. Это я. Один.

Да, можно быть просто "бэкоблядем", клепать эндпоинты и кидать JSON'ы в void.
Но в реальной жизни всё куда веселее: тебе прилетает задача сделать систему, а не просто «прикрутить логику».

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

Что я делаю как архитектор и бэкендер?

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

Сразу закладываю индексы, потому что SELECT без WHERE это пуля себе в колено.

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

Оптимизирую логику запроса чтобы система не легла на отчёте по 3 параметрам.

Бэкендер ≠ тупо API

Backend — это не просто «сделай, чтобы кнопка на фронте работала».
Backend — это:

бизнес-логика,
работа с БД,
миграции,
миграции миграций,
деплой,
докеризация,
документация,
и снова багфикс.

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

Почему это важно?

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

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

Так что да, архитектор баз данных и backend'ер — это один человек. И меня не надо "хлопать по плечу". Просто не лезьте в мой SQL без спроса.

#ItSecurity

Не доверяйте облакам. Никогда.

Если вы думаете, что Google Drive, Yandex Disk, Dropbox или даже S3 это «удобно, быстро и надёжно», то… вы правы. Но до первого факапа.

До первого бана, утечки, санкций или «мы решили, что ваш контент нарушает правила».
И всё: прощай, архив, база, проект, репозиторий, документы, диплом, жизнь.

Почему облакам нельзя доверять?

1. Они не ваши.
Это чужие сервера, чужая юрисдикция, чужие правила. Вас там никто не спрашивает. Могут удалить, ограничить, просканировать и не пискнешь.

2. Они читают ваши файлы.
Google, Microsoft, Apple — используют автоматическую индексацию, в том числе фото, документы, переписку. «Для улучшения качества» — ага, конечно.

3. Санкции.
Сегодня ты работаешь, завтра — всё заблокировано, аккаунт недоступен, доступ к Firebase закрыт, Copilot отключён, GPT отказывает. Просто потому что ты «не из той страны».

4. Утечки.
Слив баз данных, взломы, ошибки конфигурации регулярно происходят и с самыми крупными платформами. Что думаешь, твой аккаунт под надёжной защитой?

Что делать?

1. Локальные бэкапы.
SSD, жёсткие диски, флешки, сетевое хранилище — всё лучше облака, если оно под твоим контролем.

2. Шифрование.
Хранишь что-то в облаке? Минимум VeraCrypt, максимум вообще без доступа и не без ключа.

3. Собственный сервер.
VPS, Nextcloud, Syncthing — решение не для всех, но хотя бы ты знаешь, кто в ответе.

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

Облако — это не твой друг. Это просто арендованный ящик. Пока платишь, находишься в «нужной» стране, не нарушаешь правила, то он с тобой.
Потом хлоп — и нет ничего.


Доверяй себе, своим устройствам и своим резервным копиям. Облака только как дополнение, а не как основа.

#Education #Programming

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

Кажется магией: пишешь один раз, а запускается и на Android, и на iOS, и даже на вебе. Но давай разберёмся, что реально происходит «под капотом».

1. Язык: Dart

Flutter работает на Dart. Почему не JavaScript или TypeScript?
Потому что Dart это:

Компилируемый язык (можно в машинный код).

С предсказуемым поведением (что важно для UI).

Разработан Google (ну а куда же без лоббизма?).

2. Принцип: "всё своё"

Flutter не использует нативные компоненты UI Android или iOS.
Он сам рисует интерфейс, используя собственный движок Skia — тот же, что в Chrome.

Это значит:

Ты видишь интерфейс, который одинаково выглядит на всех устройствах.

Интерфейс не зависит от версии Android или кастомизации iOS.

Всё это максимально гибко, но и прожорливо.

3. Как запускается на Android

Dart-код компилируется в AOT (Ahead-of-Time) в нативный машинный код.

Flutter включает в себя движок и runtime, которые упаковываются в APK вместе с твоим UI.
Получается приложение, полностью работающее без WebView и без нативных компонентов.

Даже "пустое" Flutter-приложение весит ~4.5 МБ — это уже со встроенным движком и библиотеками.

4. Как запускается на iOS

Примерно так же: Dart → AOT → нативный код → интеграция с iOS runtime.

Под капотом используется Objective-C / Swift обвязка, но основная логика живёт в твоём Dart-коде.

iOS более капризная система, особенно по части сборки, но Flutter умеет это обходить через flutter build ios.

5. Как запускается на Web

Тут Dart компилируется в JavaScript через dart2js или Dart Dev Compiler.

Интерфейс рендерится через HTML + Canvas (или WebGL).
Да, производительность не как у React, но зато кроссплатформенно и "один код на всё".

6. Flutter Desktop

Да-да, Flutter работает и на Windows / macOS / Linux.

Dart компилируется в нативные бинарники, а интерфейс через Skia и API платформы.

Поддержка пока "молодая", но уже рабочая.

7. Hot reload и Dev-mode

Для удобства в разработке Flutter использует JIT-компиляцию и hot reload:

Меняешь код,

Flutter обновляет только изменённые части,

Сохраняется состояние приложения,

Магия!

Flutter это:

1. Собственный UI-движок (Skia).
2. Кроссплатформенная модель.
3. Компиляция Dart в машинный код (или JS).
4. Изоляция от нативной реализации.
5. И абсолютный контроль над тем, как всё выглядит и работает.

Много плюсов, много компромиссов. Но факт в том, что один код → куча платформ и это реально работает.