Ответ: символ '('. Да, именно скобочка ломает компилятор любого ЯП, так как защита от леворекурсивного парсера зачастую работает как инкапсуляция в Python, то ошибка имеет место быть.

class Squire() {
  static int squire(int num) {
    ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
      ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
        ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
          ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
            ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
              ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                  ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                    ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                          ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
      ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
        ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
          ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
            ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
              ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                  ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                    ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                          ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
      ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
        ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
          ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
            ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
              ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                  ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                    ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                          ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
      ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
        ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
          ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
            ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
              ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                  ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
                    ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
    return num * num;
  }
}

#Education

ORM — это магия

Когда ты только начинаешь писать бекенд, ты думаешь: «Да я ща SQL бахну, нормас будет». А потом тебе кидают в лицо ORM и ты такой: что за проклятый интерфейс между мной и базой?!

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

ORM (Object-Relational Mapping) — это способ взаимодействия с базой данных через объектно-ориентированный код. Не надо больше писать кучу SQL-запросов — ORM сам сгенерит всё что нужно. Ты работаешь с сущностями как с объектами, а не как с табличками.

Пример для тех, кто только встал после ночного фикса прода:

# SQL way
SELECT * FROM users WHERE name = 'Иван';

# ORM way (Django, например)
User.objects.filter(name='Иван')

Красиво? Да. Опасно? Ещё как.

Плюсы:

Быстро и удобно — меньше кода, меньше боли.

Единый подход: не надо писать SQL, всё делается на языке приложения.

Автоматические миграции и управление схемой базы.

Минусы:

Производительность может страдать — ты не всегда понимаешь, что под капотом.

Иногда ORM — это «Overkill Relational Monster»: слишком громоздко.

Для сложных запросов всё равно нужен SQL, или ты устроишь себе локальный ад из .select_related() и .prefetch_related().

Программисты, которые пишут на чистом SQL, смотрят на ORM как на демоническое вмешательство в святые JOIN'ы.
А бекендеры с опытом 2+ лет просто: «ORM — как бывшая: удобно, пока не начались странности».

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 даже в состоянии полусмерти.

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

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

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