Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

Пройдя путь от простых Bash-скриптов и сторонних туннелей до полностью автоматизированной инфраструктуры, я создал проект ServeHub-2. В этой статье я подробно разберу, как эволюционировала сеть проекта, почему декларативный подход победил императивный и с какими неочевидными багами пришлось столкнуться в процессе автоматизации.

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

Также доп. фишка в том что основная конфигурация происходит именно в frpc, который, в свою очередь, передает часть настроек на frp на удаленном сервере.

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

Со временем архитектура эволюционировала в сторону полноценной VPN-сети на базе WireGuard, а точнее — его модификации AmneziaWG. Причин для этого шага было несколько:

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

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

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

Первыми на домашнем сервере прижились медиа-сервисы: Navidrome для стриминга музыки и Audiobookshelf для аудиокниг и подкастов. Они легковесные, имеют отличные мобильные клиенты с синхронизацией прогресса и полностью закрывают мои потребности. Позже к ним добавился Nextcloud как единое независимое облако для файлов, контактов и семейных документов.

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

Из интересных моментов, где мне пришлось немного больше возиться, чем с остальными сервисами это nextcloud настройка:

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

Так я пришел к декларативному подходу и Ansible. Теперь вся конфигурация описывается в виде плейбуков и ролей, отражающих конечное желаемое состояние серверов. Конфиденциальные данные перенесены в файл secrets.yml, а хрупкие конструкции автоматизированы через шаблоны Jinja2. Проект стал идемпотентным: если шаги уже выполнены, Ansible их просто пропускает.

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

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

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

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

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

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

В итоге я заменил самописную страницу на полноценный комьюнити-проект Homepage. Это дало некоторую гибкость: вся панель настраивается через простые YAML-файлы и поддерживает встроенные виджеты интеграции. Пока что она простенькая, но возможно в будущем сделаю что-то более продвинутое.

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

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

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

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

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

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

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

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

Через восемь месяцев проект всё ещё не был готов к выкатке, а к десятому месяцу команда откатила миграцию полностью. Причин было несколько.

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

Во-вторых, команда не написала характеристических тестов. Поведение «как есть» нигде не было зафиксировано, и расхождения находились только в продакшене после переключения.

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

В итоге миграцию свернули, потратив около десяти человеко-месяцев и потеряв доверие бизнеса. Сервис до сих пор работает в исходной реализации, а команда переходит к плану, описанному ниже.

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

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

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

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

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

Feature toggles, или фича-флаги, — один из главных инструментов безопасной миграции. Они позволяют включать и выключать новую логику без деплоя.

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

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

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

Важно, что фича-флаг — это не просто if в коде. Для серьезной миграции нужны правила: кто может включать флаг, как быстро его можно отключить, какие метрики отслеживаются, когда флаг должен быть удален.

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

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

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

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

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

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

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

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

Технических метрик недостаточно. Если команда переносит оформление заказа, важно смотреть не только на 500 ошибки и время ответа, но и на конверсию в оплату, количество брошенных корзин, повторы запросов, обращения в поддержку.

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

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

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

Откатить миграцию, в которой ещё не было записи в БД, легко: достаточно переключить фича-флаг, и трафик снова идёт через старую реализацию. Откатить миграцию, в которой новая система уже неделю писала данные в новые таблицы, — отдельный, гораздо более тяжёлый разговор.

Поэтому ещё на этапе проектирования каждое изменение должно сопровождаться явным планом отката. Удобно различать три типа шагов.

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

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

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

Пример: как тот же сервис мигрировали со второй попытки

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

На первом шаге они зафиксировали поведение существующего сервиса. На самые часто используемые сценарии (создание путевого листа, подпись акта осмотра, выгрузка пакета документов за период) написали характеристические тесты на реальных продакшен-данных, обезличенных и сохранённых как фикстуры. Любое будущее изменение поведения теперь падало в CI как явное расхождение.

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

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

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

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

Четвертая ошибка — не договариваться с бизнесом. Модернизация не должна быть невидимой «инженерной активностью в стол». Её нужно встраивать в roadmap, объяснять эффект и договариваться о приоритетах. Если бизнес не понимает, зачем команда тратит время на миграцию, работа будет постоянно проигрывать новым фичам.

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

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

Отдельно стоит упомянуть организационную сторону. Закон Конвея работает и в обратную сторону: если новый и старый код владеются разными командами с разными приоритетами, миграция будет тормозиться независимо от выбранного паттерна. На время миграции имеет смысл явно проговорить, кто отвечает за переход, и не разделять старую и новую реализации между несовместимыми roadmap’ами.

Компромиссы, к которым нужно быть готовыми

Постепенная модернизация безопаснее Big Bang-переписывания, но она не бесплатна. Некоторое время система будет сложнее, чем раньше. В ней появятся старый и новый код, прокси-слой, фича-флаги, дублирование логики, дополнительные метрики.

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

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

Когда Strangler Fig особенно оправдан

Постепенная миграция особенно хорошо подходит для систем, где downtime невозможен или слишком дорог. Это финтех, e-commerce, биллинг, мобильные бэкенды с большой аудиторией, высоконагруженные продукты, старые монолиты и системы с большим количеством интеграций.

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

Этот подход также полезен там, где бизнес продолжает активно развивать продукт. Если фичи нельзя заморозить на полгода, модернизация должна идти параллельно с продуктовой разработкой.

Когда модернизацию лучше не делать

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

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

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

Простой тест: если на вопрос «какой бизнес-сценарий мы откроем после миграции» нет внятного ответа — модернизацию имеет смысл отложить и заняться чем-то другим.

Что получает команда

Главный результат постепенной модернизации — управляемость. Команда начинает лучше понимать систему, контролировать изменения и снижать риск инцидентов.

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

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

Модернизация — это процесс, а не проект

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

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

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

В центре релиза сразу две большие новинки: экспериментальная система изоляции Ruby Box и новый JIT-компилятор ZJIT.

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

Ruby Box: изоляция без контейнеров и процессов

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

Включается он через переменную окружения RUBY_BOX=1, а основной интерфейс — класс Ruby::Box.

Идея проста: изолировать побочные эффекты. Monkey patch больше не должен ломать соседние тесты или весь процесс.

Среди предполагаемых сценариев — запуск тестов с агрессивными патчами, параллельный запуск нескольких версий веб-приложения для blue-green деплоя и эксперименты с зависимостями в одном Ruby-процессе.

В перспективе, Ruby Box может стать фундаментом для более высокого уровня модульности и «пакетной» системы, хотя пока это именно низкоуровневый API.

ZJIT: новый курс для производительности

Вторая ключевая новинка — ZJIT. Это новый just-in-time компилятор следующего поколения. Он должен прийти на смену YJIT и строится как более классический метод-ориентированный JIT с SSA-представлением.

ZJIT написан с расчетом на расширяемость и вклад сообщества, но требует Rust 1.85 и новее для сборки.

Сейчас ZJIT быстрее интерпретатора, но все еще уступает YJIT. Да и сами разработчики языка открыто предупреждают — да, экспериментировать можно. Но в продакшен лучше пока с новинкой не лезть. Цель — сделать ZJIT быстрее YJIT и полностью готовым к бою уже в Ruby 4.1.

Ractor становится ближе к «неэкспериментальному»

Параллелизм в Ruby тоже заметно продвинулся. Ractor получил новый механизм синхронизации Ractor::Port, упрощающий обмен сообщениями, а внутренние структуры были переработаны для снижения блокировок и конкуренции за CPU-кэш.

• Решить, с какого языка/технологии вы хотите начать.
• Решить, на каком ресурсе вы хотите обучаться.
• Выделить время на само программирование.

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

Некоторые люди начинают с относительно низкоуровневого программирования на C и C++. Другие выбирают более традиционный путь, изучая Java или C#. Есть и те, кто начинает с высокоуровневых или скриптовых языков вроде Python, Ruby или JavaScript.

Мы классифицируем языки по уровню абстракции. Для новичков: низкоуровневые — как ручная сборка машины (контроль, но сложный); среднеуровневые — как готовый конструктор с инструкцией (сохраняем баланс); высокоуровневые — как приложение на смартфоне (быстро, но меньше контроля). Ниже разберём плюсы и минусы и поможем сделать правильный выбор.

Низкоуровневые языки: близко к «железу»

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

Примеры: C (для ОС вроде Linux), C++ (для игр на движке вроде Unreal Engine), Assembler (для оптимизации критических частей кода).

Плюсы:

• Полный контроль: вы решаете, как использовать ресурсы. Так, в C++ можно вручную выделять память для массивов, избегая ненужных копий данных.
• Высокая скорость: прямой доступ к памяти позволяет писать код, который работает быстрее (это важно для работы с играми или серверами).
• Основы основ: такие языки учат, как компьютер работает изнутри, чтобы в будущем ценить удобства других языков. Например, вы узнаёте, почему «утечка памяти» — это проблема.
• Эффективность: низкоуровневые языки мотивируют думать об оптимизации заранее, снижая расход батареи или CPU.
• Компактность: минимальная библиотека, приложения получаются лёгкими (идеально для embedded-систем, как в IoT-устройствах).

Минусы:

• Всё-таки это сложно: рутинные задачи (например, чтение файла) требуют больше кода и внимания к деталям, рискуя ошибками вроде переполненного буфера.
• Ручное управление памятью: можно легко «забыть» освободить память, вызвав утечки или краши. Например, в C нужно использовать malloc/free, иначе программа съест всю RAM.
• Много копипасты: придётся писать шаблонный код, и делать это часто.
• Платформо-зависимость: код для Windows может не работать на Linux без правок.

Среднеуровневые языки: баланс контроля и удобства

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

Примеры: Java (для Android-приложений), C# (для Unity-игр или .NET-серверов).

Плюсы:

• Автоматическая память: память очищается автоматически благодаря сборщику мусора, что избавляет от ручной работы и снижает вероятность ошибок, вроде утечек памяти в больших проектах. При этом можно получить доступ к низкоуровневым функциям для особых задач, например, через специальные инструменты в Java.
• Богатые библиотеки: готовые инструменты для сетей, GUI или баз данных. Пример: Java’s Spring для веб-серверов.
• Кроссплатформенность: компиляция в байт-код (JVM для Java) позволяет запускать код везде. Например, пишешь на Windows, запускаешь на Linux.
• Безопасность: язык проверяет типы данных перед запуском программы, помогая заранее найти ошибки. Среда выполнения защищает от опасных сбоев, например, от переполненной памяти.
• Масштабируемость: встроенные инструменты для параллельных вычислений позволяют легко создавать программы, которые одновременно выполняют много задач (серверы для тысяч пользователей и т.п.).

Минусы:

• Дополнительная нагрузка от рантайма: Среда выполнения и автоматическая очистка памяти создают дополнительную нагрузку. Сборщик мусора может ненадолго останавливать программу, что заметно в играх или при обработке видео.
• Меньше контроля: абстракции скрывают детали памяти, усложняя оптимизацию (например, в Java сложно избежать боксинга примитивов).
• Повторяющийся код, которого много: приходится писать повторяющийся код и тренировать свою усидчивость, например, для доступа к данным объекта. Кстати, инструменты вроде Lombok могут упростить эту задачу.
• Зависимость от среды: для запуска программ нужна специальная среда (например, JVM для Java), что влияет на размер программ и замедляет их старт.
• Сложность интеграции: подключение кода на других языках, например, на C, требует писать специальные обёртки, что усложняет работу и снижает скорость.

Высокоуровневые языки: удобство и скорость разработки

Эти языки скрывают технические детали, позволяя сосредоточиться на создании логики программы. Подходят для веба, data science или скриптов.

Примеры: Python (для ML), Ruby (для веб-разработки), JavaScript (для фронтенда).

Плюсы:

• Простота: сложные задачи решаются в пару строк. Так, в JS async/await упрощает API-запросы.
• Быстрая разработка: динамическая типизация позволяет быстро писать и тестировать код без необходимости его компиляции.
• Богатые экосистемы: есть библиотеки для всего (к примеру, NumPy для данных в Python).
• Гибкость: легко менять код, идеально для прототипов или стартапов.

Минусы:

• Низкая производительность: абстракции добавляют нагрузки. Например, циклы в Python медленнее, чем в C.
• Ошибки на рантайме: из-за слабой типизации ошибки выявляются только при запуске программы, что усложняет отладку.
• Риск «спагетти-кода»: лёгкость изменений может привести к хаосу без дисциплины.
• Скрытые проблемы: абстракции маскируют баги.
• Зависимость от интерпретатора: программы требуют установленного интерпретатора, что замедляет их запуск и добавляет зависимость от дополнительного ПО.

Чек-лист: как выбрать язык программирования для новичка

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

1. Определите, что вас вдохновляет, и выберите сферу. Подумайте, что вы хотите создавать: сайты, игры, мобильные приложения или серверы. Разные сферы требуют разных языков. Например, для веб-разработки подойдут JavaScript или Python, для мобильных приложений — Java, Kotlin, Swift или Dart, а для игр — C# или C++. Составьте список идей (например, сайт-визитка, игра, аналитика данных) и найдите, какие языки для них используют.
   — Аня Жаркова, руководитель мобильной разработки в USETECH
2. Ищите язык с широким применением. Выбирайте языки, которые используются в разных областях, чтобы легче переключаться между задачами. Например, Kotlin подходит для мобильной разработки, веба и серверов, а C# — для десктоп-приложений, игр (Unity) и бэкенда. Это даёт гибкость и упрощает изучение новых языков в будущем.
   — Аня Жаркова, руководитель мобильной разработки в USETECH
3. Проверьте спрос на рынке труда. Если цель — смена профессии, изучите вакансии на HH.ru или LinkedIn. Введите «junior Python», «junior Java» и сравните, где больше предложений и какие требования. Избегайте языков с низким спросом, если хотите быстро найти работу. Например, Java, Kotlin, Python и JavaScript популярны для найма.
   — Владислав Масунов, Head of Development
4. Опробуйте языки на практике. Напишите простые программы (например, "Hello World" или калькулятор) на нескольких языках, чтобы понять, какой синтаксис вам ближе. Используйте онлайн-редакторы вроде Replit или CodePen. Например, попробуйте TypeScript для веба (он поддерживает типизацию и разные подходы к программированию) или C++ для понимания работы с памятью. Это поможет почувствовать, к чему лежит душа.
   — Рома Троицкий, фронтенд-инженер в Сбер B2C, член ПК HolyJS & MoscowCSS; Евгений Антонов, ИТ-консультант, автор тг-канала @general_it_talks
5. Выберите язык с хорошей документацией и сообществом. Убедитесь, что у языка много обучающих материалов и активное сообщество. Например, TypeScript имеет богатую документацию и поддержку, что упрощает старт. Проверьте ресурсы вроде LearnPython.org, freeCodeCamp для JavaScript или Telegram-чаты для C++. Это поможет быстрее решать вопросы.
   — Рома Троицкий, фронтенд-инженер в Сбер B2C, член ПК HolyJS & MoscowCSS
6. Учитывайте сложность и карьерные цели. Для небольших проектов или быстрого старта берите Python или PHP — они проще и подходят для веб-разработки или скриптов. Для сложных задач с высокой нагрузкой (например, серверы или оптимизация) попробуйте C++ или Go. Если цель — работа в крупных компаниях, Java и Kotlin востребованы и часто используются с ИИ-инструментами. Выбирайте, исходя из сложности и ваших амбиций.
   — Евгений Антонов, ИТ-консультант, автор тг-канала @general_it_talks
7. Смотрите на универсальность и переход к другим языкам. Выбирайте язык, который учит основам программирования и упрощает переход к другим. Например, изучение C# может помочь освоить Java, а затем — Android-разработку. TypeScript учит объектно-ориентированному и функциональному программированию, что полезно для разных задач. Это создаёт базу для дальнейшего роста.
   — Аня Жаркова, руководитель мобильной разработки в USETECH; Рома Троицкий, фронтенд-инженер в Сбер B2C, член ПК HolyJS & MoscowCSS
8. Не гонитесь за гилти плежа. Избегайте языков, которые изучают «для удовольствия» без практического применения. Выбирайте те, которые можно применить в реальных проектах или которые востребованы в индустрии. Например, вместо нишевых языков берите Python, Java или Kotlin: они имеют чёткие сценарии использования.
   — Аня Жаркова, руководитель мобильной разработки в USETECH
9. Практикуйтесь с ИИ-инструментами. Если хотите работать в крупных компаниях, освойте язык, который хорошо сочетается с ИИ-инструментами (например, Go или Java). Практикуйтесь с ИИ-агентами по типу GitHub Copilot для автоматизации задач — это ценится работодателями.
   — Евгений Антонов, ИТ-консультант, автор тг-канала @general_it_talks
10. Составьте план развития. Создайте roadmap: определите, какие проекты хотите делать через 3-6 месяцев (например, мобильное приложение или веб-сервис), и подберите язык под эти цели. Если выбрали C#, начните с десктоп-приложений, затем попробуйте Xamarin для кроссплатформенной разработки. Постепенно добавляйте новые языки, опираясь на первый.
    — Аня Жаркова, руководитель мобильной разработки в USETECH

Если не определились, предлагаем пройти квиз и расставить всё по полочкам:

Теперь они предлагают решения, которые не хуже, а где-то даже и лучше международных аналогов и по надёжности, и по цене.

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

1. FirstVDS: профессиональные решения для любых проектов

FirstVDS — хостинг-провайдер с опытом на рынке более 20 лет. Предлагают VPS и VDS с виртуализацией KVM для проектов любого размера. Все серверы работают на современном оборудовании. Трижды победитель в номинации «Хостер года» Национальной премии «ЦОДы.РФ».

Хостинг подойдет бизнесу любого масштаба: для любых сайтов — от визиток до высоконагруженных интернет-магазинов, для разработки и тестирования, для сервисов и других проектов. Отдельные решения для Битрикс, установка ОС семейства Linux и Windows Server.

Особенности хостинга

Надёжность

FirstVDS обеспечивает аптайм 99,97–99,99% в 2025 году, подтверждённый замерами (например, отклик из Москвы — 27 мс в апреле 2025). Серверы размещены в трёх дата-центрах уровня Tier III: два в Москве (IXcellerate и Web DC) и один в Амстердаме (euNetworks). Отказоустойчивый кластер Ceph гарантирует работу даже при сбоях точки или канала.

Инфраструктура

Серверы работают на процессорах Intel Xeon и AMD EPYC (до 5,7 ГГц в линейке CPU.Турбо), с быстрыми NVMe-дисками объёмом до 8 ТБ и оперативной памятью DDR5 (до 768 ГБ в VDS Атлант). Это обеспечивает высокую производительность для ресурсоёмких задач, таких как Битрикс или высоконагруженные приложения.

Гибкость

Тарифы масштабируются: от базовых конфигураций (1 CPU, 1 ГБ RAM, 40 ГБ SSD) до мощных серверов (192 ядра, 768 ГБ RAM, 8 ТБ NVMe). Линейки:

• VDS Форсаж: AMD EPYC, до 128 ядер, 512 ГБ RAM, 4 ТБ NVMe, от 749 ₽/мес (Москва/Амстердам).
• CPU.Турбо: AMD Ryzen до 5,7 ГГц, DDR5, от 624 ₽/мес (Москва).
• VDS Атлант: отказоустойчивый, до 192 ядер, 8 ТБ NVMe, от 1619 ₽/мес (Москва).
• VDS Storage: хранилище, от 704 ₽/мес (Москва).Горячее масштабирование (hot-resize) позволяет добавлять CPU, RAM или диск без перезагрузки.

Автоматизация

Шаблоны для быстрого развёртывания: Django, Redmine, Tomcat, Teamspeak, Nextcloud, LAMP, LEMP, Forgejo Git, GitLab, Битрикс. Поддерживаются ОС Linux (Ubuntu, Alma, Debian, Rocky, CentOS, Oracle), FreeBSD, Windows Server. API и панель ispmanager 6 lite (бесплатно на месяц) упрощают управление.

Безопасность

Включена защита от DDoS-атак на сетевом уровне, BitNinja для защиты сервера и сайта, SSL-сертификаты GlobalSign. Доступны автобэкапы, снапшоты, Кибер-бэкап и объектное хранилище S3 для больших данных.

Поддержка

Круглосуточная поддержка 24/7 без чат-ботов, ответ до 15 минут через чат, личный кабинет или телефон. Бесплатно: помощь с активацией и первичной настройкой. Платно: установка ПО, администрирование. Экспертная линия для мониторинга и устранения сбоев.

Бонусы

• Тестовый период 3 дня.
• Бесплатный перенос до 10 сайтов с другого хостера.
• Скидки: 40% на первый месяц при оплате на 1/3/6 месяцев или 3 месяца бесплатно при оплате за год.
• Лояльность: скидка 5–20% для клиентов от 5 лет.
• Реферальная программа: 10% от расходов привлечённых клиентов для партнёра, 25% скидка для нового пользователя на первый месяц.
• Домены: продление по цене регистрации.

Тарифы и условия

Тестовый период 3 дня, после него подключаете один из основных тарифов:

• Линейка готовых конфигураций от 1 CPU, 1 Гб RAM, 40 Гб SSD-накопителя и от 219 руб/мес. до сервера с 8 CPU, 12 Гб RAM, 150 Гб NVMe-накопителя. Локация в РФ и Нидерландах.
• VDS Форсаж: на AMD Epyc от 749 ₽/мес. Локации: РФ и Нидерланды.
• CPU.Турбо: гибкая конфигурация на базе высокочастотных AMD Ryzen 9 от 624 ₽/мес. При покупке лицензии Битрикс дополнительная скидка 30% на 3 месяца аренды CPU.Турбо. Локация в РФ.
• VDS Атлант: отказоустойчивый с автобэкапами от 1 619 ₽/мес. Локация: РФ.
• VDS Storage: сервис как хранилище с гибкой конфигурацией от 704 ₽/мес. Локация: РФ

Все тарифы доступны для тестирования по согласованию с отделом продаж. Для точного подбора конфигурации используйте гибкую настройку.

2. UltraVDS: для малого бизнеса и стартапов

Компания UltraVDS, провайдер услуг виртуальных серверов (VPS/VDS), работает на рынке с 2014 года — предлагает решения для разных операционных потребностей. Сервисы UltraVDS можно использовать для развертывания торговых роботов, запуска чат-ботов, хостинга веб-сайтов, а также для создания FTP-хранилищ данных. Есть предложения для фрилансеров, цифровых агентств, корпоративных пользователей и стартапов, которым требуются функциональные инфраструктурные решения.

Технические особенности

Серверы UltraVDS размещены в современном дата-центре, расположенном в Москве. Доступность сервиса (аптайм) составляет 99,98%, что обеспечивает высокую стабильность работы. Сетевая пропускная способность превышает 200 Мбит/с, при этом трафик предоставляется без ограничений.

Система защиты от DDoS-атак способна обрабатывать трафик до 1,5 Тбит/с и поддерживает стабильность работы сервера даже при интенсивном внешнем воздействии. Лицензия на Windows Server входит в стоимость обслуживания в данном предложении. Это упрощает развертывание сервера: вам не нужно отдельно покупать и устанавливать лицензию. Плюс снижает общие операционные расходы для пользователей этой операционной системы.

Тарифные планы

Для новых пользователей UltraVDS предусмотрена возможность 3-дневного тестового периода, позволяющего оценить функциональность и производительность сервиса.

После тестового периода стоимость тарифов начинается от 119 рублей в месяц. На сайте доступен онлайн-калькулятор, позволяющий подобрать конфигурацию сервера и рассчитать итоговую стоимость.

Клиентам доступны различные варианты оплаты, включая ежемесячную систему без предоплаты. При авансовой оплате на период от 3 до 12 месяцев предоставляются скидки до 20%, размер которых зависит от выбранного срока. В случае досрочного прекращения использования сервиса, неиспользованный остаток средств возвращается на баланс пользователя.

Поддержка и обслуживание

Техническая поддержка UltraVDS работает круглосуточно, 7 дней в неделю. Среднее время ответа на запросы составляет до 15 минут. Связь со службой поддержки возможна по электронной почте и телефону, указанным на официальном сайте.

3. RUVDS: 10 лет на рынке облачных решений

RUVDS — облачный провайдер, имеющий десятилетний опыт работы на рынке услуг виртуальных серверов (VPS/VDS). Является официальным партнером Huawei в России, работает по SLA. Компания предоставляет инфраструктурные решения, которые могут быть применены для широкого спектра задач, включая хостинг высоконагруженных интернет-магазинов, корпоративных порталов, игровых серверов, сложных backend-систем и чат-ботов.

Платформа RUVDS спроектирована для оптимизации процесса развертывания ресурсов. Одной из ее особенностей является маркетплейс, который позволяет быстро запускать серверы с предустановленным программным обеспечением. Это способствует ускорению старта проектов, снижая потребность в ручной настройке распространенных CMS, игровых серверов и сред разработки.

Тарифная политика и варианты оплаты

RUVDS предлагает различные тарифные планы. Например, стоимость конфигурации Linux-сервера (1 CPU, 512 МБ RAM, 10 ГБ HDD, 1 IPv4) начинается от 139 ₽/месяц. Это может быть рассмотрено как экономичное решение для запуска небольших проектов и проведения тестирования.

Клиентам доступны разные опции оплаты:

1. Ежемесячные платежи или предоплата на срок от 3 до 12 месяцев, при которой предоставляются скидки до 20%, зависящие от продолжительности периода.
2. Для проектов с динамической нагрузкой предусмотрена посекундная тарификация, оплата по которой взимается только за фактически использованные ресурсы. Неиспользованный остаток средств в рамках этой модели возвращается на баланс пользователя

Дополнительно, до конца 2025 года панель управления ISP Manager для сервера и сайта предоставляется без дополнительной платы при создании любого VPS.

Глобальная инфраструктура и стабильность

Инфраструктура включает 17 дата-центров уровня Tier III, расположенных по всему миру. Это один из самых больших показателей по количеству геолокаций среди российских провайдеров. Для работы используются корпоративное оборудование и накопители (HDD, SSD, NVMe), чтобы обеспечить стабильную работу и производительность размещенных проектов.

Поддержка клиентов и доступные ресурсы

Техническая поддержка RUVDS доступна круглосуточно, 7 дней в неделю. Среднее время ответа на запросы через тикет-систему или онлайн-чат составляет 15 минут. Клиентам предоставляются полные административные права и консультации по вопросам запуска и настройки серверов. Для самостоятельного изучения доступна база знаний, включающая инструкции и руководства.

Безопасность и масштабирования

В контексте безопасности данных, RUVDS предлагает несколько решений:

- Встроенная защита от DDoS-атак, способствующая поддержанию бесперебойной работы серверов при внешнем воздействии.

- Стандартный IPv4-адрес включен в стоимость каждой виртуальной машины, с опцией аренды дополнительных IP-адресов.

- API, соответствующий OpenAPI 3.0.0, предоставляет возможности для интеграции и автоматического масштабирования серверных ресурсов в зависимости от нагрузки.

- Компания официально подтверждает соответствие требованиям ФСТЭК и ФЗ-152 по защите персональных данных, что обеспечивает соблюдение соответствующих законодательных норм.

4. McHost: решения для бизнеса разного масштаба

McHost предоставляет комплексные хостинговые решения, включая виртуальный хостинг и VPS/VDS с NVMe-накопителями. Сервис поддерживает популярные CMS (WordPress, Joomla, 1С-Битрикс) с оптимизированными настройками и автоматической установкой через панель управления.

McHost ориентирован на широкий круг клиентов:

• владельцы сайтов-визиток, блогов и лендингов — благодаря низким тарифам и полному набору опций;
• интернет-магазины с небольшой нагрузкой — тарифы с SSD-накопителями и автоматическим резервным копированием обеспечивают стабильную работу;
• разработчики, которым нужны
  VPS/VDS с root-доступом — работают серверы на KVM-виртуализации с ОС Linux и Windows;
• госучреждения и компании,
  работающие с персональными данными — соответствие 152-ФЗ и размещение в дата-центрах Tier III в Москве.

Особенности сервиса

McHost поддерживает стабильную работу с аптаймом 99.9% за счет размещения оборудования в дата-центрах уровня Tier III — в Москве и Нидерландах.

Сервис предоставляет защиту от DDoS-атак, автоматическое резервное копирование раз в два дня с хранением данных в течение 30 дней для виртуального хостинга и 14 дней для VPS, а также поддержку российских криптографических стандартов. Клиентам доступны различные варианты размещения: от виртуального хостинга с SSD (от 157.5 ₽/мес) до выделенных серверов с NVMe-накопителями.

Технические параметры и условия

Инфраструктура McHost базируется на серверах Dell с NVMe-накопителями и процессорами Intel Xeon (частота ядер от 2.35 ГГц). Для виртуального хостинга используется CloudLinux с технологией CageFS, обеспечивающей изоляцию аккаунтов. Поддержка российских ОС («Альт») подтверждена для VPS-тарифов.

В техподдержку можно обратиться по телефону, через тикет или в Telegram-боте. Время ответа — до 10 минут.

Текущие тарифы:

• Виртуальный хостинг: от 157 ₽/мес
  (3 ГБ SSD, 1 сайт).
• VPS: от 396 ₽/мес (15 ГБ SSD, 1
  ядро CPU).
• Выделенные серверы: от 3 000 ₽/мес
  (32 ГБ RAM, 2×1 ТБ HDD).

5. UFO Hosting: VPS/VDS и выделенные серверы с портом до 10 Гбит/с и безлимитным трафиком

UFO Hosting предлагает VPS/VDS и выделенные серверы на партнёрской инфраструктуре IXcellerate (Tier III). В портфолио — недорогие виртуальные машины и серверы с портом 10 Gbps для проектов, которым нужна стабильность без завышенных цен.

Сервис подходит для пользователей разных масштабов: от фрилансеров и веб‑студий до средних и крупных компаний. Для DevOps‑специалистов доступны API и инструменты автоматизации.

Основные сценарии использования

• корпоративные сайты, CRM‑системы и веб‑приложения;
• аналитические сервисы и SaaS‑продукты;
• инфраструктура для разработки и тестирования;
• задачи фрилансеров, агентств и digital‑команд.

Формат работы, особенности и интеграции

Серверы установлены в российском дата‑центре Tier III (IXcellerate), что означает резервирование по питанию и каналам связи. Заявленный аптайм — 99,98 %. Поддержка работает круглосуточно в тикетах, чате и по телефону; среднее время ответа 5–10 минут.

Сервис UFO Hosting делает акцент на безопасности и гибкости. Есть сеть с защитой от DDoS, возможность горячего расширения ресурсов, автоматическое развёртывание из шаблонов и API для интеграции. Поддерживаются популярные фреймворки и CMS, есть интеграции с GitLab, Telegram и DockerHub. Бэкапы, снапшоты и резервирование входят в стандартный набор, так что восстанавливать тестовую среду не придётся вручную.

В панели управления можно автоматически установить популярные CMS, панели управления, хранилища и DevOps‑инструменты. Это экономит время на настройку и подходит тем, кто не хочет поднимать всё с нуля.

Условия использования и тарифы

Базовые конфигурации начинаются от 577 руб./месяц. Заявленная скорость порта — до 10 Gbps, что подходит для проектов, где много трафика.

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

В целом, UFO Hosting выглядит как практичное решение для тех, кому нужны производительные VPS/VDS и выделенные серверы в России. При выборе стоит оценить, насколько конфигурации подходят под конкретные нагрузки и есть ли необходимость в интеграциях из коробки.

6. Timeweb: хостинг для веб-проектов

Timeweb предоставляет услуги хостинга для различных типов веб-проектов. Сервис поддерживает популярные CMS, включая WordPress, 1C-Битрикс и Joomla, что делает его подходящим как для личных блогов, так и для корпоративных сайтов.

Платформа использует собственную панель управления с инструментами для работы с сайтами, базами данных и резервными копиями. Ежедневное автоматическое резервное копирование с хранением данных до 30 дней включено во все тарифные планы. Базовая защита от DDoS-атак доступна для всех клиентов без дополнительной платы.

Инфраструктура Timeweb размещена в дата-центрах уровня Tier III в России (Санкт-Петербург) и Казахстане (Алматы). Гарантированный показатель uptime составляет 99.98%. Поддерживаются современные технологии: PHP версий от 5.3 до 8.4, MySQL от 5.6 до 8.0, а также Perl, Python, SSH, FTP и Cron.

Тарифные планы:

• Year+: от 164 ₽/мес (2 сайта, 15
  ГБ NVMe, 2 БД);
• Optimo+: от 248 ₽/мес (15 сайтов,
  40 ГБ NVMe, безлимитные БД);
• Century+: от 347 ₽/мес (35 сайтов,
  50 ГБ NVMe, безлимитные БД);
• Millennium+: от 482 ₽/мес (60
  сайтов, 60 ГБ NVMe, безлимитные БД).

Все тарифы включают бесплатный SSL-сертификат, 10 ГБ почтовой квоты с неограниченным количеством ящиков и DNS-хостинг. При оплате годового тарифа предоставляется домен в зонах .RU/.РФ в подарок.

Техническая поддержка доступна круглосуточно через онлайн-чат, тикет-систему и по телефону. Среднее время ответа не превышает 15 минут. Новые клиенты могут протестировать сервис бесплатно в течение пробного периода.

7. Reg.ru: комплексные решения для сайтов и доменов

Reg.ru сочетает услуги хостинга и регистрации доменов, что упрощает управление веб-проектами. Компания работает с 2005 года, имеет статус аккредитованного регистратора доменных имён в зонах .RU и .РФ.

Функциональные возможности

Платформа предоставляет доступ к трём панелям управления: ISPmanager, cPanel и Plesk. Это позволяет выбрать наиболее удобный интерфейс для работы с сайтами. Все тарифы включают бесплатный SSL-сертификат от Let’s Encrypt, который автоматически устанавливается при создании сайта.

Начинающим пользователям доступен конструктор сайтов с готовыми шаблонами. Поддерживаются популярные CMS, включая WordPress, Joomla и 1С-Битрикс. Ежедневное резервное копирование данных с хранением копий в течение 30 дней входит в стандартный набор услуг.

Техническая инфраструктура

Серверы размещены в дата-центрах уровня Tier III в Москве. Средний показатель uptime составляет 99.9%, что подтверждается ежемесячной статистикой. Подключение к сети осуществляется по выделенным каналам со скоростью до 1 Гбит/с на выделенных серверах.

Поддержка и тарифы

Техническая поддержка доступна 24/7 через онлайн-чат и тикет-систему. Среднее время ответа составляет 15-20 минут. Для срочных вопросов можно обратиться по телефону.

Тарифы — от 151 ₽/мес (7 ГБ SSD, 15 сайтов). При регистрации домена в зонах .RU или .РФ предоставляется скидка на другие доменные имена.

8. Спринтхост: хостинг с персональным подходом

Sprinthost предлагает услуги хостинга с акцентом на индивидуальную поддержку клиентов. Сервис работает с 2011 года и специализируется на VPS-решениях для различных веб-проектов.

Особенности сервиса

Компания предоставляет персонального менеджера для каждого клиента, который помогает с настройкой сервера и решением технических вопросов. А если вы остались недовольны услугами, то в течение 30 дней сервис вернёт деньги. Sprinthost проводит бесплатные обучающие вебинары по DevOps и администрированию серверов.

Технические характеристики и тарифы

Инфраструктура размещена в дата-центрах Москвы и Санкт-Петербурга с аптаймом 99.9%. Поддерживаются современные технологии разработки, включая Ruby on Rails, Node.js, Python и Docker. Все серверы используют SSD-накопители с гарантированной скоростью чтения/записи.

Тарифные планы:

• Start: 290 ₽/мес (1 ядро, 1 ГБ
  RAM, 15 ГБ SSD);
• Turbo: 1 900 ₽/мес (4 ядра, 8 ГБ
  RAM, 100 ГБ NVMe).

Поддержка

Техническая помощь доступна 24/7 через тикет-систему и онлайн-чат. Среднее время ответа составляет 10-15 минут. Для корпоративных клиентов предусмотрена приоритетная поддержка по телефону.

Как выбрать хостинг в 2025 году

Выбор хостинга зависит от типа проекта и его требований. Для небольших сайтов и блогов подойдет виртуальный хостинг с поддержкой популярных CMS — важно проверить наличие автоматических бэкапов и базовой защиты от DDoS. Если проект связан с обработкой персональных данных, убедитесь, что провайдер соответствует 152-ФЗ и использует сертифицированное оборудование.

Для высоконагруженных сервисов и интернет-магазинов лучше рассматривать VPS или выделенные серверы. Обратите внимание на тип накопителей (SSD/NVMe), возможность масштабирования ресурсов и аптайм дата-центров (рекомендуется от 99.9%).

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

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

FAQ

Что такое виртуальный хостинг и когда его выбирать?

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

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

Что такое VPS/VDS и для каких проектов он подходит?

VPS (Virtual Private Server) или VDS — это виртуальный сервер с выделенными ресурсами (процессор, память, диск), предоставляющий доступ для полной настройки. Идеален для проектов среднего масштаба: интернет-магазинов, API, SaaS, чат-ботов, корпоративных порталов или приложений с умеренным трафиком.

Преимущества: гибкость конфигураций, выбор ОС, изоляция ресурсов. Минусы: требует базовых навыков администрирования, стоимость выше, чем у виртуального хостинга.

Что такое выделенный сервер и когда его использовать?

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

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

В чём основные различия между виртуальным хостингом, VPS и выделенным сервером?

Виртуальный хостинг — самый дешёвый и простой, но ресурсы делятся между пользователями, что ограничивает производительность (до 1000–2000 посетителей в сутки).

VPS обеспечивает выделенные ресурсы и гибкость, справляясь с нагрузкой до 5000–10 000 пользователей в сутки.

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

Выбор зависит от масштаба: виртуальный для старта, VPS для роста, выделенный для enterprise.

Нужны ли навыки администрирования для хостинга?

Для виртуального хостинга навыки не нужны — управление идёт через интуитивные панели, а провайдеры обеспечивают обновления и базовую поддержку. Для VPS желательны базовые знания (настройка ОС, установка ПО), хотя многие провайдеры предлагают помощь. Для выделенного сервера навыки администрирования необходимы, так как вы полностью отвечаете за сервер, хотя провайдеры могут предлагать платное администрирование.

1. МояДоска

«МояДоска» — это российский SaaS-сервис для совместной работы и визуализации идей. У онлайн-доски бесконечный размер: это значит, что вы можете размещать сколько угодно элементов и никогда не упретесь в границу. Так, команды, преподаватели и креативные специалисты могут проводить брейнштормы, планирования, презентации и обучение в одном пространстве.

Что под капотом

Фронт написан на React + PixiJS, а бэк — Node.js + PostgreSQL. Это обеспечивает быстрый и понятный интерфейс и стабильную работу даже при большом объёме объектов на доске. Команда выпускает обновления несколько раз в месяц, а о новинках можно узнать в Telegram-канале сервиса. Например, в недавнем апдейте появилась возможность превратить фрейм в таблицу или тетрадь за пару кликов, а еще задать нужное число столбцов, колонок, толщину границ и цвет.

Из главных функций:

• Понятный интерфейс
• Совместная работа в реальном времени
• Привычные инструменты: фигуры, стрелки, стикеры, текст, загрузка файлов, маркер, карандаш
• Обрезка фото прямо на доске, воспроизведение аудио, поддержка PDF
• Гибкое управление доступом
• Возможность повторного использования шаблонов
• Поддержка фреймов и создание логичных пространств для разных задач

Переезд на сервис

«МояДоска» интегрируется в процессы на разных этапах, упрощая жизнь команде. Например, сама команда сервиса перешла с Miro на свою доску для стратегического планирования. С помощью стикеров и стрелок они построили дерево решений, чтобы лучше расставить приоритеты. А одно маркетинговое агентство перевело все документы и сессии планирования на доску, отказавшись от Google Docs и таблиц. Это ускорило принятие решений: сотрудники работали с данными в одном формате, точно собрались в одном кабинете перед маркерной доской.

2. METEOR

METEOR — инструмент управления проектами. Это трекер задач с дашбордами, досками канбан, диаграммами Ганта и API, который работает в виде веб-приложения как в облаке, так и на своих серверах. Продукт создавался как универсальный центр управления задачами: он объединяет в себе все — от разработки и тестирования до маркетинга и поддержки. Сейчас его используют более 250 команд и свыше 2000 пользователей ежедневно.

Что под капотом

В основе — стек Ruby on Rails, React и TypeScript, PostgreSQL и Redis, плюс современная инфраструктура на Docker и Kubernetes.

Система разбита на микросервисы — за фоновую обработку, нотификации и работу с файлами отвечает отдельный функционал. Авторизация построена через OAuth 2.0 (Google, Yandex), а для аналитики используется Posthog и ELK-стек. Мониторинг реализован на Prometheus + Grafana. Обновления выходят каждую неделю, а обратная связь приходит разработчикам METEOR через Telegram-бот.

Вот главные функции:

• Гибкие доски задач (Kanban, Scrum) — 6 видов.
• Списки задач с группировками и иерархией.
• Автоматические отчеты (ежедневные/еженедельные сводки).
• Умные напоминания (Telegram-бот, email).
• Глубокая аналитика (время выполнения задач, загрузка команды).
• Потоковая автоматизация процессов

METEOR — мощный инструмент для автоматизации процессов, с триггерами, серверными функциями и ИИ-аналитикой. Он позволяет гибко настраивать сложные операции.

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

Разработчики используют METEOR для линковки задач с pull-requests и контроля бэклога. Менеджеры получают отчеты автоматически и не тратят часы, чтобы собрать всю информацию вручную. QA ведут тест-кейсы и баги в удобных досках, а DevOps отслеживают инциденты и шаги деплоя. Даже HR подключаются — через систему проходят кандидаты и стажеры.

Переезд на сервис

После внедрения METEOR команды замечают, что продуктивность их работы сильно повышается:

• скорость выполнения задач увеличивается в среднем на 25% — благодаря автоматическим напоминаниям и чётким процессам;
• количество потерянных задач снижается на 70% — исчезают хаотичные чаты и забытые письма;
• на составление отчетов и сбор метрик уходит не 5 часов, а всего 30 минут в неделю;
• а экономия времени — около 75 часов в месяц на команду из 10 человек.

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

3. Gitlife

GitLife — это универсальная платформа для хостинга репозиториев и построения полного DevOps-процесса внутри компании. Разработана с прицелом на закрытые контуры, импортозамещение и гибкость — подходит как для современных Git-проектов, так и для инфраструктур, где все еще используется SVN.

Помимо самого Gitlife, разработчики делают Gitlife AI, в котором есть доступ к топовым ИИ-моделям и инструментам, чтобы разрабатывать ИИ-решения.

Что под капотом

Внутри Gitlife собраны модули для:

• Кода — репозитории, ветвление.
• Задач — бэклоги, спринты, дашборды.
• Документации — совместное редактирование документов, управление правами.
• Аналитики — карты потока ценности, качество кода, метрики по инженерам.
• Пайплайны — модуль «Конвейер» управляет сборками и CI/CD.

Gitlife используется ИТ-отделами и R&D-подразделениями в компаниях с высокими требованиями к информационной безопасности. Подходит как для небольших команд, так и для распределённых корпораций с десятками проектов.

Что решает:

• Безопасный и полностью локальный хостинг исходного кода (Git + SVN)
• Управление задачами и CI/CD в одном месте
• Централизованный доступ, права, аудиты и история изменений
• Полная поддержка DevOps-процессов на российском ПО
• Альтернатива GitHub, GitLab и Bitbucket в условиях ограниченного доступа и санкционных рисков

Переезд на сервис

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

4. Cerebro

Cerebro — профессиональная система для совместной работы и управления проектами. Она помогает ставить задачи, планировать этапы, следить за выполнением, обмениваться файлами и комментировать их прямо в системе. Особенно полезна для команд, которые делают VFX, 3D, анимацию или дизайн — но при этом легко адаптируется и под другие команды.

Платформа охватывает полный цикл — от первых идей и планирования до комментирования финальных шотов (отдельных сцен или кадров в видео/анимации) и соблюдения дедлайнов. Такой подход помогает команде ускорить работу на 20%, сократить время на правки и держать весь процесс под контролем — от начала до сдачи проекта.

Cerebro подходит для команд от 1 до 1000+ человек с задачами на проекте от 1 до 10000+. Сервис работает с 2009 года, сейчас им пользуются более 400 команд в России и СНГ.

Что под капотом

Cerebro поддерживает десктоп (Windows, Mac и Linux), веб-версию и мобильное приложение, локальное, облачное и гибридное развертывание. Инструмент построен на клиент-серверной архитектуре — она гибкая, поэтому можно настраивать конфиги исходя из потребностей бизнеса.

Из технологий:

• Backend: C, C++, Python, SQL
• Frontend: JS, TypeScript, ReactJS, Qt, PyQt
• Мобильные клиенты: React Native
• БД: PostgreSQL с проприетарными расширениями + SQLite
• Файловое хранилище: Cargador
• Плагины: Tentaculo (встраивается в производственные программы)

Cerebro покрывает весь пайплайн — от идеи до финала. Вот основные возможности сервиса:

• Множественные уровни вложенности задач — подходит для сложных иерархий продакшена
• Планирование с помощью диаграммы Ганта и специального инструмента «План»
• Канбан-доска для визуального контроля задач
• Инструмент «Моё пространство» — для персонализированной фильтрации и отбора задач
• Уровни доступа и ролевое управление
• Расширенная статистика по проектам, командам, сотрудникам
• Совместная работа над большими файлами (видео, изображения, 3D) — Mirada позволяет комментировать, делать подрисовки, оставлять голосовые заметки
• Интеграция с пакетами Adobe, Autodesk и мессенджерами, возможность встраивать в любые пайплайны
• Удобное подключение фрилансеров

Переезд на сервис

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

После переезда снимается много рутинных задач: больше не нужно вручную назначать исполнителей, комментировать медиаконтент, передавать файлы между программами и так далее. В среднем проекты выполняются на 20% быстрее, без потери качества. В больших студиях объем выпускаемых шотов может вырасти до 20+ тысяч — это уже работает у других клиентов, среди которых СберМаркетинг, Sinners, Black Point и другие. Cerebro также помогает переехать с других такс-трекеров и систем для управления проектами.

5. Replit Teams

Replit Teams — это платформа для совместной разработки в реальном времени. По сути, это интегрированная IDE + git-репозиторий + система управления задачами — и все доступно через браузер. Подходит как для командной работы в стартапах, так и для образовательных проектов, хакатонов и небольших продуктовых команд.

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

Что под капотом

Внутри Replit Teams есть интерфейсы для:

• Кода — редактор с автокомплитом, подсветкой синтаксиса, терминалом и интеграцией с Git.
• Задач — встроенный таск-менеджер с распределением задач по участникам.
• Общения — встроенные комментарии в коде, возможность ревью и обсуждений.
• CI/DevOps — запуск и отладка приложений без настройки окружения.
• Доступа — гибкие роли, приглашения по ссылке, настройки приватности.

Переезд на сервис

Replit Teams позволяет моментально начать работу: не нужно ставить зависимости, конфигурировать CI или закупать сервера. Подходит как для быстрой прокачки навыков, так и для реальных командных проектов в продакшене.

Сейчас инструмент активно используют в стартапах — для быстрого MVP, парного программирования, хакатонов и удаленных командах — как замена локальным IDE и конфигурациям.

Рассказывайте в комментариях, какими сервисами пользуетесь вы.

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

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

Обучение программированию в этот период кардинально отличалось от современных подходов. Онлайн-курсы практически отсутствовали. Основными источниками знаний служили бумажные книги:

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

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

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

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

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

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

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

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

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

За два десятилетия программисты прошли путь от одиночек за CRT-мониторами до участников глобальных распределенных команд. Если в 2005 ключевым навыком было умение написать работающий код, то в 2025 главное — способность эффективно взаимодействовать с ИИ-ассистентами. Однако основы профессии остались неизменными — логическое мышление, способность к абстракции и желание автоматизировать рутинные задачи.

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

Оскар — разработчик с 18-летним стажем. Он решил разобраться, насколько утверждение про необходимость знать множество языков правдива.

Сам Оскар за свою карьеру успел поработать с C#, Java, C++, Python, Ruby, JavaScript, Perl и прочими языками. Но не потому что стремился к полиглотству, а потому что так сложилось — проекты, клиенты, задачи.

По его мнению, изучение новых языков не просто расширяет кругозор. Это помогает иначе смотреть на архитектуру и подходы к решению задач. Даже если вы продолжаете писать на своем основном языке, знакомство с другими помогает вырасти ментально.

Синтаксис — это не все

Проблема в том, что многие изучают новый язык на уровне «выучил синтаксис — значит, могу писать». Но это часто приводит к «Java-коду на Go» или «C#-архитектуре в TypeScript». Новички в языке переносят привычные паттерны, не понимая, как использовать сильные стороны новой платформы.

Чтобы писать идиоматично, нужно время. Неделя — чтобы освоить синтаксис. Пару месяцев — чтобы почувствовать экосистему. Год — чтобы писать как носитель языка.

Когда стоит добавлять новый язык в стек

Оскар выделяет три повода:

• Бизнес-задача. Например, для тяжелых расчетов стоит взять язык быстрее JavaScript.
• Кадровый вопрос. Иногда проще найти разработчиков под Node.js, чем под Java.
• Карьерный рост. Умение работать с востребованным стеком открывает больше возможностей.

Но главное — не делать выбор из любопытства. Однажды Оскару пришлось переписать модуль с F# на C#, потому что никто не хотел его поддерживать. В другом проекте Python-модуль оказался узким горлышком и потребовал переделки. Эти эксперименты дорого обошлись бизнесу.

Архитектору — особенно важно

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

Баланс между глубиной и гибкостью

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

Языки — это инструменты. Хороший разработчик остается таковым вне зависимости от того, на чем он пишет.

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

Чистые функции и отсутствие побочных эффектов

Чистые функции делают код более предсказуемым и надёжным. У них есть два главных признака:

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

Рассмотрим на примере:

Функция sum — чистая, потому что она всегда возвращает один и тот же результат для одних и тех же входных данных (a и b). Если мы вызовем alculator.sum(10, 5), то всегда получим 15. Она не меняет никаких данных вне себя и не взаимодействует с внешним миром. Результат зависит только от её аргументов.

А это пример нечистой функции:

Функция sum_with_config выглядит похожей на sum, но она нечистая, потому что зависит от внешнего состояния и ведёт себя непредсказуемо.

Значение b берётся из файла config.txt. Если файл пуст, содержит 5 или, например, 100, результат будет разным, даже если аргумент a не изменился.

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

Иммутабельность данных

Elixir, как язык функционального программирования, поддерживает иммутабельность данных.

Вспомним, как мы обычно изменяем значения переменных в других языках на примере Python:

Мы создаём переменную x, она записывается в память, где ей присваиваем значение 10.

Далее мы присваиваем ей новое значение 11, и оно обновляется в памяти. Десятки больше нет.

Теперь рассмотрим похожий пример на Эликсире:

В память записывается значение 10, а не x. Только после этого присваиваем нашему значению «ярлык» в виде x.

Если у нас несколько переменных с одинаковыми значениями, то все они ссылаются на один участок памяти. В данном случае y ссылается на туже самую десятку.

Когда мы меняем значение переменной, мы на самом деле создаём новое в памяти, в данном случае 11, и присваиваем к нему новый «ярлык» — x.

Старое значение 10 остаётся, если у него есть другие ссылки или ярлыки. Если их нет, то его удаляет сборщик мусора. В данном случае 10 останется вместе с переменной y.

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

Каррирование и композиция функций

Каррирование часто встречается в функциональных языках программирования. Оно означает, что мы превращаем функцию в цепочку, которая принимает только один аргумент.

• У нас есть функция sum(a, b), которая ожидает оба числа сразу.
• После каррирования мы получаем функцию curried_sum(a).
• Когда мы вызываем curried_sum(5), она не считает сумму. Вместо этого возвращает новую функцию. Назовём её условно add_five_func. Эта функция «запомнила», что a = 5, и теперь ждёт единственный аргумент — b.
• Следующим шагом мы берём эту только что полученную функцию (add_five_func) и вызываем её, передавая ей значение 3 в качестве аргумента b.
• Именно этот вызов (add_five_func(3)) запускает финальное вычисление (5 + 3) и возвращает нам результат 8.

Благодаря каррированию код получается более модульным, функции можно любым образом комбинировать и проще тестировать.

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

В некоторых языках программирования, например, в Haskell или F#, есть фишки для более удобного синтаксиса каррирования и даже автоматическое каррирование, но не в Elixir. В нём всё приходится делать с награмождением и без плюшек под капотом.

Композиция — это когда мы объединяем несколько функций в одну, где выходные данные одной функции передаются как входные данные для другой.

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

• Мы начинаем с initial_string.
• Оператор |> берёт значение initial_string и передаёт его как первый аргумент функции String.trim().
• Результат String.trim() ("hello elixir world") снова берётся оператором |> и передаётся как первый аргумент в String.upcase().
• Результат String.upcase() ("HELLO ELIXIR WORLD") аналогично передаётся в String.reverse().
• final_result получает итоговое значение этой цепочки — "DLROW RIXILE OLLEH".

Такие функции проще читать и комбинировать, но при отладке цепочки могут возникать проблемы.

Работа с рекурсией вместо циклов

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

Она работает как два зеркала, которые поставили друг напротив друга. Одно отображает другое.

Пример рекурсии в Elixir:

Этот код выводит числа меньше пяти. Он работает до тех пор, пока переменная n не будет равна нулю.

В отличие от цикла, функция print_down() в конце вызывает сама себя.

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

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

Здесь используется аккумулятор acc, который накапливает промежуточный результат. Рекурсивный вызов factorial(n - 1, n * acc) — это последнее действие в функции, и после него ничего не происходит.

Особенности языка Elixir

Синтаксис, вдохновлённый Ruby

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

Читаемость и минимум шума

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

Пример с Elixir:

Интерполяция строк с #{} — прямое заимствование из Ruby. Это делает вывод текста интуитивным.

Блоки с do...end

В Ruby и Elixir есть блоки кода с do...end для функций и управляющих структур:

Ruby:

Elixir:

В обоих языках do...end обозначает тело функции — это привычно для рубистов и делает переход на Elixir проще.

Сахарный синтаксис

Ruby славится «синтаксическим сахаром» — удобными сокращениями. Elixir тоже этим балуется:

Ruby — пропуск скобок в вызовах:

Elixir — короткая запись для однострочных функций:

Оба языка стараются убрать лишнее, чтобы код был лаконичным.

Модули вместо классов

В Ruby классы и модули — основа ООП:

В Elixir модули — это просто контейнеры для функций, без ООП:

Имена модулей и стиль их использования явно перекликаются с Ruby, хотя и Elixir функциональный язык.

Среди языков, как Elixir, которые ориентированы на функциональное программирование и конкурентность, мало кто предлагает столь же современный и читаемый синтаксис.

Конкурентность через Actor-модель (Erlang VM)

Эликсир основан на виртуальной машине Erlang VM. Она поддерживает конкурентность и работу при помощи Actor-моделей.

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

Обычно конкурентные задачи работают с общей памятью. Это может приводить к малозаметным ошибкам наподобие гонки данных или взаимоблокировок. Для таких случаев в Elixir есть Actor-модели.

Это сущности, которые отвечают за выполнение задач. Акторы в Эликсире изолированы. Каждый процесс — это легковесный актор с собственной памятью:

Этот код запускает новый процесс, который выведет сообщение и умрет. А теперь представим миллион таких:

Акторы не дерутся за ресурсы — они отправляют сообщения через send и ждут ответа с receive:

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

Распределённые вычисления и масштабируемость

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

Node.connect соединяет два узла. Node.spawn запускает процесс на узле node2@host. Код выполняется там, но мы управляем им с узла node1@host.

Встроенная поддержка обработки отказов (fault tolerance)

Изоляция процессов

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

Связывание и мониторинг

Иногда нужно знать, что процесс упал, чтобы отреагировать. Для этого есть связывание (Process.link) и мониторинг (Process.monitor).

Связывание соединяет процессы. Если один процесс падает, то другой получает сигнал и тоже падает.

В этом примере spawn_link связывает процессы. Когда дочерний процесс падает (raise), главный тоже падает, потому что они связаны. Поэтому IO.puts не выполнится.

Мониторинг мягче — мы просто получаем сообщение о сбое, падение процесса не тянет за собой другие процессы.

Process.monitor(pid) включает наблюдение за процессом. Когда тот падает, мы не падаем сами, а получаем сообщение. Мы его обрабатываем через receive.

Supervisor

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

• Demo.start запускает супервизор, который следит за одним процессом.
• start_crasher — запускает процесс, который тут же падает.
• Супервизор автоматически перезапускает его бесконечно.

Распределённость и отказоустойчивость

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

Всё происходит с одного узла (node1) — он управляет и следит. Если процесс на node2 падает (например, узел отвалился или exit(:boom)), то :DOWN ловится через monitor и запускается резерв на node3.

Сравнение Elixir с другими языками

Elixir vs Erlang: современный синтаксис против классического подхода

У Elixir и Erlang много общего. Во-первых, они оба придерживаются функционального подхода к программированию, во-вторых, у них общая виртуальная машина Erlang VM (BEAM). Именно от неё Elixir получил связанные с отказоустойчивостью фишки вроде акторов.

Общий синтаксис

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

У Erlang он классический, немного старомодный, с уклоном в функциональный стиль. Много точек, запятых и точек с запятой.

Elixir читаемый, минималистичный, с закосом под Ruby. Код выглядит чище и ближе к современным языкам:

Работа со строками

В Erlang строки — это списки символов, каждый «Hello» внутри — это [72,101,108,108,111].

Тут всё строго: ++ склеивает списки, а io:format с ~s выводит результат. Это работает, но медленно и неудобно, особенно для больших текстов.

А вот так выглядит код на эликсире:

Строки в эликсире — это бинарные данные, быстрые и удобные. Оператор <> соединяет их, а |> (pipe) делает код читаемым, как поток: взял «Hello», добавил «world», вывел. Никаких списков и лишних точек.

Работа со списками

Подход к работе со списками тоже отличается. В Erlang:

Тут всё вручную: [0|List] добавляет элемент в начало, а ~p выводит.

В Elixir списки тоже функциональны, но с бонусами:

У модуля Enum есть готовые функции вроде map, которые экономят время и нервы.

Работа со словарями

Erlang долго обходился без словарей, а когда они появились (maps), то остались простыми:

Всё по делу, но без изысков. А вот пример с эликсиром:

Точечная нотация (map.age), удобный синтаксис и pipe для обновлений.

Elixir vs Ruby: почему Elixir лучше подходит для высоконагруженных систем

Ruby: Использует потоки (threads) или процессы ОС (например, через Puma или Unicorn). Это тяжеловесный подход: каждый поток потребляет память, а глобальная блокировка интерпретатора (GIL в MRI Ruby) ограничивает параллелизм.

• GIL мешает реальной параллельности на одном ядре.
• Для масштабирования нужны новые сервера и внешние инструменты (Redis, Sidekiq).

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

Elixir vs Go: конкурентность через процессы BEAM против горутин

Процессы в Elixir благодаря акторам изолированы друг от друга, у них нет общей памяти и поэтому они более отказоустойчивые. Из-за изоляции один процесс весит от 300 кб.

У Go есть свои аналоги акторов, они называются горутины, но работают немного иначе. Гоурутины не изолированы между собой, у них общая память и они «дешевле». Один горутин весит от 2 кб., вместо 300 кб. как у Elixir.

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

Примеры кода на Elixir

Определение модуля и функций

Модули — это «коробки», в которые мы помещаем функции. Так проще организовать код:

• defmodule создаёт модуль, внутри него — функции с def.
• do...end — для многострочных функций, do: — для коротких.
• IO.puts — это как print, выводит результат в консоль.

Использование pipe (|>) для удобного комбинирования операций

Pipe-оператор (|>) — это фишка Elixir, которая делает код читаемым, передавая результат одной операции в следующую.

|> берёт результат и передаёт его как первый аргумент следующей функции.

Вместо вложенных вызовов (String.reverse(String.trim(String.upcase("elixir")))), мы пишем шаги сверху вниз.

Асинхронные процессы через spawn и GenServer

• spawn запускает новый процесс, который работает параллельно.
• pid — это идентификатор процесса, его можно использовать для общения между процессами.
• Процессы изолированы: один спит, другой идёт дальше.

Где применяется Elixir?

Веб-приложения с высокой нагрузкой (Phoenix Framework)

Фреймворк Phoenix, построенный на Elixir, идеален для веб-приложений, которым нужно обрабатывать тысячи или миллионы пользователей одновременно. Вот пара примеров его использования:

Bleacher Report: Этот спортивный сайт, их аудитория превышает 200 млн человек. В 2017 году его перенесли на Phoenix, чтобы улучшить производительность и справиться с пиковыми нагрузками во время крупных событий. Phoenix позволил эффективно использовать веб-сокеты для интерактивных функций, по типу обновлений в реальном времени.

Pinterest: Одна из крупнейших социальных платформ, которая использует Elixir для управления трафиком и отправки уведомлений с 2014 года. Благодаря Elixir компании удалось повысить производительность системы уведомлений до 14 тыс. в секунду. Также получилось сократить количество серверов для этой задачи с 30 до 15.

Чаты и мессенджеры

Elixir отлично подходит для real-time приложений, где важна мгновенная доставка сообщений и высокая отказоустойчивость:

Discord: Популярная платформа для геймеров и сообществ использует Elixir для обработки миллионов сообщений в реальном времени. Каждый пользователь или чат работает как отдельный процесс, что позволяет системе легко масштабироваться.

WhatsApp: В основном работает на Erlang, но Elixir здесь тоже присутствует. Он помогает обрабатывать миллиарды сообщений каждый день.

Микросервисная архитектура

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

Financial Times: Известное издание перешло на Elixir для своего GraphQL API, чтобы повысить производительность и обеспечить стабильность при росте числа читателей.

Lonely Planet: Этот туристический ресурс использует микросервисы на Elixir для управления контентом, что позволяет быстро обновлять данные и масштабировать систему под миллионы пользователей.

PepsiCo: Компания применяет Elixir в проектах eCommerce и IoT, где микросервисы помогают эффективно обрабатывать данные и взаимодействовать с клиентами.

Изолированные процессы и встроенные инструменты для распределённых систем делают Elixir надёжным выбором для микросервисной архитектуры.

Интернет вещей (IoT) и распределённые системы

Elixir также нашёл своё место в IoT, где важны стабильность и управление множеством устройств:

Nerves: Это открытый проект, который позволяет создавать прошивки для IoT-устройств на Elixir.

TeslaMate: Приложение, написанное на Elixir, собирает данные с автомобилей Tesla в реальном времени, предоставляя владельцам подробную статистику. Оно демонстрирует, как Elixir справляется с обработкой данных от распределённых источников.

В IoT каждое устройство может работать как отдельный процесс, а супервизоры обеспечивают стабильность, даже если одно из устройств временно отключается.

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

Frontend фреймворки

React

Это самый популярный фреймворк для создания веб-приложений. React используется в лендингах, динамических веб-приложениях и даже мобильных приложениях (React Native).

UI здесь разбивается на независимые и переиспользуемые блоки. Такие компоненты легко интегрировать, комбинировать в разных частях приложения или между проектами. Фреймворк ускоряет разработку и рефакторинг.

React обращается к DOM только для обновления изменившихся компонентов. За счет этого повышается производительность приложения.

Пример простого React компонента:

Преимущества фреймворка:

• Облегчает повторное использование кода и поддержку приложений;
• Имеет множество дополнительных библиотек и инструментов;
• Виртуальный DOM снижает прямые манипуляции с DOM и повышает производительность приложения;
• Фреймворк пользуется популярностью в сообществе. Как результат  —  множество учебников, разборов документации и сторонних библиотек.

Недостатки фреймворка:

• Концепции JSX и управления состоянием могут быть сложны для новичков;
• Плохая кроссбраузерная поддержка;
• Требует дополнительных библиотек для маршрутизации и управления состоянием.

Vue.js

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

Преимущество Vue в его простоте и низком пороге входа. При этом фреймворк сохраняет статус мощного инструмента для разработки сложных веб-приложений.

Vue автоматически отслеживает зависимости между блоками и обновляет DOM при их изменении, как React.

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

Пример простого компонента Vue:

Экосистема Vue включает множество библиотек и плагинов, расширяющих возможности фреймворка. Например, Vuex для управления состоянием, Vue Router, Nuxt.js и другие.

Преимущества фреймворка:

• Понятный синтаксис и подробная документация;
• Может использоваться как библиотека или цельный фреймворк в зависимости от проекта;
• Есть поддержка серверного рендера;
• Автоматически обновляет интерфейс при изменении данных;
• Имеет небольшой вес файлов.

Недостатки фреймворка:

• Меньше ресурсов и сторонних библиотек по сравнению с React и Angular;
• Неполная документация на русском языке.

Angular

С помощью Angular разрабатывают клиентские части веб-приложений. Этот фреймворк сложнее Vue и React.

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

По аналогии с Vue и React, фреймворк разбивает приложение на независимые, переиспользуемые блоки кода. Компоненты: шаблон; класс, описывающий поведение; стили.

Освоение Angular требует больше времени и усилий по сравнению с Vue и React из-за архитектуры и специфических концепций. Нужны углубленные знания по внедрению зависимостей, декораторам и модулям.

Пример простого Angular-компонента:

Преимущества фреймворка:

• Богатый выбор инструментов, шаблонов, которые сокращают сроки реализации сложных приложений;
• Angular CLI расширяется за счет shematics, поэтому его легко доработать под конкретные задачи;
• Есть поддержка TypeScript: статическая типизация улучшает качество кода;
• Встроенная утилита для обновления проекта при переходе на новую версию Angular.

Недостатки фреймворка:

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

Backend фреймворки

Django (Python)

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

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

Django следует архитектурному шаблону Model-View-Controller (MVC). Модели определяют структуру данных, представления обрабатывают логику и взаимодействие с моделями, а шаблоны отвечают за представление данных пользователю.

Сильная сторона Django — его ORM (Object-Relational Mapping). Интерфейс для работы с базой данных на Python используется для написания сырых SQL-запросов. Django поддерживает PostgreSQL, MySQL, SQLite, Oracle.

Если ищете универсальный фреймворк для бэкенд-разработки на Python, Django определенно заслуживает вашего внимания.

Пример модели Django:

В примере определяем модель Article с полями title, content и published_at. Метод __str__ возвращает строковое представление объекта:

Представление article_list получает объекты Article из базы данных и передает их в шаблон для отображения.

Преимущества фреймворка:

• Широкий набор инструментов: включает ORM, аутентификацию и админ-панель;
• Фреймворк задаёт структуру проекта — помогает разработчикам понимать, как и где добавлять новую функцию;
• Защищен от SQL-инъекции и подделки межсайтовых запросов;
• Подходит для высоконагруженных приложений.

Недостатки фреймворка:

• Django ORM уступает последней SQLAlchemy.

Ruby on Rails (Ruby)

Rails подходит для быстрого прототипирования и проектов, ориентированных на работу с базами данных. Его используют для SaaS-платформ, CRM-систем, CMS, маркетплейсов и многого другого.

Rails применяет архитектурный паттерн MVC (Model-View-Controller). Фреймворк хорош с точки зрения бизнес-логики и взаимодействует с базой данных с помощью ActiveRecord ORM.

Rails поставляется со встроенными инструментами и библиотеками. Например, ActiveRecord для работы с базами данных, ActiveStorage для управления файлами, ActionMailer для отправки email.

В сообществе Rails огромное количество гемов (библиотек), расширяющих функциональность фреймворка.

Пример модели Rails (с использованием ActiveRecord):

Пример контроллера Rails:

В примере определяем модель Article с валидациями и связями. Контроллер ArticlesController содержит экшены для списка статей, отображения отдельной статьи, создания новой статьи. Приватный метод article_params используется для фильтрации параметров.

Преимущества фреймворка:

• Продуманная структура, которая продвигает стандарты качества и лучшие практики веб-разработки;
• Active Record ORM упрощает взаимодействие с базой данных;
• Vue, Angular.js и React легко интегрируются с Ruby on Rails.

Недостатки фреймворка:

• Ruby on Rails js медленнее Django и Node.js.

Node.js с Express (JavaScript)

Express — фреймворк Node.js с набором функций для разработки веб-приложений и API. В нем реализован простой интерфейс для HTTP-запросов и маршрутизации.

Node.js + Express используется для сервисов, серверных приложений (например, чатов или игр).

Преимущество Node.js и Express состоит в возможности писать на JavaScript как клиентскую, так и серверную сторону. Можно вести разработку на одном языке и делиться кодом с фронтендом и бэкендом.

Пример простого приложения на Express:

Преимущества фреймворка:

• JavaScript на всем стеке — один язык для фронтенда и бэкенда;
• Имеет минимальные ограничения, можно строить архитектуру как удобно.

Недостатки фреймворка:

• Отсутствуют встроенные компоненты, требуются дополнительные настройки для безопасности и работы с базами данных;
• Управление обратными вызовами усложняет код и его поддержку.

Full-Stack фреймворки

Laravel (PHP)

Laravel — фреймворк для веб-разработки на PHP. Он использует архитектуру MVC: разделяет логику приложения и улучшает организацию кода.

Laravel выбирают для разработки CMS, SaaS-платформ, электронной коммерции и др. Встроенные библиотеки ускоряют работу.

В фреймворке реализована:

• Система миграций для управления структурой базы данных;
• Eloquent ORM для работы с данными;
• Система шаблонизации Blade;
• Встроенная поддержка аутентификации и авторизации;
• Очередь заданий и планировщик для выполнения асинхронных задач.

Пример определения маршрута в Laravel:

Пример контроллера Laravel:

Пример модели Eloquent:

В примерах выше определяем маршрут, который принимает id и возвращает строку с идентификатором. Контроллер UserController методом show получает пользователя из базы данных по id и передает его в представление user.profile. Модель User представляет таблицу пользователей в базе данных и определяет заполняемые атрибуты.

Преимущества фреймворка:

• Шаблонизатор Blade упрощает создание представлений;
• ORM Eloquent облегчает работу с базами данных;
• Есть автоматизация задач с помощью встроенных инструментов и командной строки.

Недостатки:

• Сложности с долгосрочной поддержкой версий.

Spring Boot (Java)

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

Фреймворк имеет встроенный контейнер сервлетов (Tomcat, Jetty), чтобы запускать приложение как автономный JAR-файл без развертывания на внешнем сервере.

Фреймворк также предлагает:

• Автоконфигурацию библиотек (JPA, JDBC);
• Встроенные метрики мониторинга;
• Поддержку внешней конфигурации;
• Интеграцию с базами данных.

Преимущества фреймворка:

• Есть встроенные серверы Tomcat, Jetty и Undertow;
• Облегчает управление зависимостями с помощью стартовых пакетов;
• Оснащен встроенным контейнером сервлетов;
• Автоматическая конфигурация экономит время на старте проекта.

Недостатки:

• Spring Boot создает множество неиспользуемых зависимостей и увеличивает размер файла развертывания.

Meteor (JavaScript)

Особенность Meteor в том, что он синхронизирует данные в реальном времени. Фреймворк автоматически обновляет пользовательский интерфейс при изменении данных на сервере. Это возможно благодаря протоколу DDP (Distributed Data Protocol) и реактивным источникам данных, таких как MongoDB.

На JS + Meteor можно писать код, который работает как на клиенте, так и на сервере. Фреймворк также предоставляет интегрированную систему сборки, которая автоматически объединяет ресурсы приложения.

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

Преимущества фреймворка:

• Архитектура и синтаксис с понятным кодом упрощают обучение новичков и повышают производительность команды;
• Есть мгновенная синхронизация данных между клиентом и сервером;
• Возможна интеграция базы данных MongoDB.

Недостатки фреймворка:

• Не предлагает широкого функционала для масштабирования и разделения логики на модули;
• Сложности с масштабированием при увеличении числа пользователей из-за обработки данных в реальном времени.

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

1. Норман Бейтс («Психо»)

Почему Python?

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

Его путь в IT

Норман начинал как сисадмин в семейном мотеле "Бейтс". Ручное управление серверами быстро ему надоело — ну сколько можно делать одно и то же? Он начал писать скрипты на Python, автоматизируя бэкапы, мониторинг и деплой. Затем подсел на Docker и Kubernetes, завернул всю инфраструктуру в контейнеры и настроил CI/CD пайплайны.

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

Но позже выяснилось, что он сделал это под влиянием своего "второго я", не осознавая последствий.

2. Майкл Майерс («Хэллоуин»)

Почему C?

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

Его путь в IT

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

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

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

3. Пеннивайз («Оно»)

Почему JavaScript?

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

Его путь в IT

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

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

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

4. Гостфейс («Крик»)

Почему Ruby?

Гостфейс обожает интриги и игры разума. Ruby, по его мнению, идеально подходит для хакинга. Ему нравится быть на шаг впереди и всегда оставаться в тени. Ruby дает ему возможность быстро писать скрипты для поиска уязвимостей и эксплойтов.

Его путь в IT

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

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

5. Кожаное лицо («Техасская резня бензопилой»)

Почему C++?

Кожаное лицо любит работать с железом напрямую. C++ дает ему мощь и гибкость, позволяя писать эффективный код для микроконтроллеров. Он ценит контроль над памятью и возможность выжать максимум из ресурсов. Для него код — это инструмент, как и бензопила, которым он мастерски владеет.

Его путь в IT

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

Коллеги знают: если нужно что-то спаять, запрограммировать и заставить работать — это к нему. Хотя он не особо разговорчив и может показаться грубоватым.

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

6. Акула («Челюсти»)

Почему Go?

Акула — воплощение скорости и эффективности. Go для нее — идеальный инструмент для создания высокопроизводительных сервисов. Простота синтаксиса и мощные возможности конкурентности позволяют ей строить системы, которые не тонут под нагрузкой. Go — это язык для хищников, которые не терпят рутинных задач.

Ее путь в IT

Начинала с Java, но быстро поняла, что Go лучше подходит для ее целей. Стала экспертом в микросервисной архитектуре, разворачивая кластеры, способные обрабатывать миллионы запросов в секунду. Ее код оптимизирован на все 100%, как и она сама в погоне за добычей.

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

7. Существа из «Тихое место»

Почему Rust?

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

Их путь в IT

Начали как системные администраторы, но быстро поняли, что могут сделать больше. Освоили Rust для разработки внутренних инструментов и сервисов мониторинга. Настроили инфраструктуру так, что пользователи даже не подозревают о ее существовании — все работает как по маслу, без лишнего шума.

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

8. Сара Фир («Улица страха»)

Почему Kotlin?

Сара видит то, что скрыто от других. Kotlin дает ей мощь и гибкость для создания масштабируемых приложений. Он современный и лаконичный, позволяющий писать чистый и понятный код. В сочетании с ML она строит модели, которые могут предсказывать будущее.

Ее путь в IT

Начинала как аналитик данных, копаясь в цифрах и выявляя закономерности. Освоила Kotlin, чтобы писать эффективные приложения для обработки больших данных. Руководит командой Data Science, создавая алгоритмы, которые помогают компании быть на шаг впереди конкурентов.

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

9. Джейсон Вурхиз («Пятница, 13-е»)

Почему Java?

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

Его путь в IT

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

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

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

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

Рядом с изображениями сайтов есть ссылки на эти страницы.

Технические трудности и идеи для улучшения

Изначально проект начал набирать популярность благодаря посту на Reddit.

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

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

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

Идеи для оптимизации сайта

Кроме того, обсуждались способы улучшения сайта, чтобы сделать его более удобным.

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

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

Вдохновение для будущих разработок

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

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

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

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

— по рейтингам TIOBE и RedMonk (базируются на данных GitHub и активности обсуждений на Stack Overflow)

— порогу вхождения

— размеру зарплат разработчиков

В статье рассматриваем:

• Python
• JavaScript
• Java
• TypeScript
• Golang
• Ruby
• Swift

Python

Популярность

Язык находится на 1-м месте TIOBE. Несмотря на популярность, за год язык потерял в рейтинге 2,39%. Вот динамика изменения позиции Python с 2002 года.

Согласно рейтингу RedMonk, язык находится на втором месте. Ниже — динамика популярности языков программирования с 2012 года. На инфографике есть и другие языки, которые обсуждаем в этой статье — можете сразу обратить на них внимание.

Уровень зарплат

По данным Хабр Карьеры, медианная зарплата программистов на Python составляет 184 000 ₽. Минимальная заработная плата — 74 000 ₽ (джун), максимальная — 350 000 ₽ (лид).

Порог вхождения и перспективы

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

На Python можно писать как относительно несложные проекты, так и корпоративные системы с комплексной архитектурой. А библиотеки Python (TensorFlow и Keras) сделали его популярным среди специалистов для создания нейронных сетей и моделей машинного обучения.

JavaScript

Популярность

В рейтинге TIOBE JavaScript находится на 6-м месте, потеряв за год 0,11% (особой динамики нет). Это может означать только одно: JavaScript стабильно популярен у разработчиков.

В рейтинге RedMonk JavaScript на 1-м месте — он не сходит с этой позиции с 2012 года. Только один раз, в 2013 году, JavaScript уступил Java, но уже в 2014-м вернул место лидера.

Уровень зарплат

Согласно Хабр Карьере, медианная заработная плата составляет 176 000 ₽. Минимальная зарплата у джунов — 70 000 ₽, а максимальная, у сеньоров — 199 000 ₽ (данных по лидам у сервиса нет).

Порог вхождения и перспективы

Технологии JavaScript используют практически во всех отраслях IT. У языка не очень высокий порог входа, что делает его доступным для новичков.

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

В ближайшее время JavaScript вряд ли потеряет популярность, ведь с его помощью можно разрабатывать сайты (как фронтенд, так и бэкенд), приложения для смартфонов и даже игры. На JavaScript написан весь фронтенд Gmail и другие известные на весь мир приложения.

Java

Популярность

В рейтинге TIOBE Java находится на 4-м месте, язык потерял за год 4,34%. Сильнее сократился показатель лишь у языка С# — он упал на 4,81% за год. Тем не менее это не критическое падение.

Во втором рейтинге Java на 3-м месте — там он находится уже три года подряд. В RedMonk Java весьма стабилен: с 2012 года язык то падает до 3-го места, то поднимается на второе.

Уровень зарплат

По информации Хабр Карьеры, медианная зарплата специалистов по Java составляет 212 000 ₽. Джуны зарабатывают около 95 000 ₽, а лиды — 326 000 ₽. В целом, всё неплохо — компании предлагают разработчикам достойное вознаграждение.

Порог вхождения и перспективы

Здесь всё чуть сложнее, чем с предыдущими языками — порог вхождения у Java средний.

Java — объектно ориентированный язык. Помимо обычной базы в виде синтаксиса, структур данных и операторов придётся освоить концепции ООП: классы, объекты, наследование и полиморфизм.

В среднем у новичков это занимает от 2 до 6 месяцев. После вы сможете создавать несложные приложения для десктопов, смартфонов и веба: калькуляторы, todo-листы, игры.

Программисты на Java пользуются большой популярностью на рынке труда. На этом языке разрабатывают мобильные приложения под Android, большие корпоративные системы и игры. Так, на Java написаны Assassin’s Creed и Minecraft, серверная часть Pokemon Go, портала «Госуслуги» и приложений для интернета вещей, а также сервисы доставки еды и продуктов.

TypeScript

Популярность

У этого языка 35-е место в рейтинге TIOBE. За год TypeScript набрал примерно 0,39%, т. е. почти ничего не изменилось. Тем не менее разработчики советуют изучать TypeScript, в другом рейтинге он занимает более высокое положение.

По мнению RedMonk, TypeScript находится на 8-м месте, поднимаясь из «подвала» с 2016 года. В прошлом году он занимал то же место, из чего можно сделать вывод, что TypeScript явно востребован среди специалистов.

Уровень зарплат

На Хабр Карьере нет данных по зарплате разработчиков этой специальности. По информации сервиса Zarplan (сайт прекратил работу с 1 февраля 2024 года), медианная заработная плата программиста TypeScript составляет 201 000 ₽.

Порог вхождения и перспективы

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

Стоит ли учить TypeScript как первый язык программирования? Без знания JavaScript вам будет довольно сложно понять концепции и синтаксис TypeScript, обучение может затянуться на несколько месяцев. В описаниях стажировок и вакансий TypeScript обычно требуется в связке с JS или его фреймворками, поэтому начинать свой путь в программировании с TS не стоит.

TypeScript используют для создания пользовательских интерфейсов, frontend- и backend-частей веб-сайтов, а ещё больших бизнес-приложений, где требуется стабильность. Соответственно, популярность TypeScript вряд ли будет сильно снижаться.

Golang

Популярность

По рейтингу TIOBE язык Go находится на 11-м месте. Это один из немногих языков программирования, который за год стал популярнее: Golang набрал 1,38% рейтинга.

Вот динамика сразу за 14 лет, начиная с появления языка.

По RedMonk Go находится на 15-м месте. К слову, он занимал эту позицию ещё в 2018 году, затем несколько опустился в рейтинге и снова стал расти с 2021 года.

Уровень зарплат

Хабр Карьера сообщает, что медианная зарплата Golang-разработчика составляет 255 000 ₽. Джуны в среднем получают 125 000 ₽, а лиды — 424 000 ₽. Это один из лучших показателей среди языков программирования, о которых мы говорили выше.

Порог вхождения и перспективы

Golang — неплохой вариант для новичков, его можно начать осваивать в качестве первого языка программирования. Достоинство Golang в том, что он полный по Тьюрингу, относительно простой и лаконичный.

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

На Go разработаны инструменты для контейнеризации Kubernetes и Docker, консольное приложение GitHub CLI, а также база данных для работы с метками Prometheus. Пишут на Go в крупнейших компаниях России и мира, так что перспективы у языка хорошие.

Ruby

Популярность

В рейтинге TIOBE Ruby занимает 18-ю позицию. При этом за год он практически ничего не потерял, но и не набрал. Так что Ruby остаётся стабильно востребованным языком программирования.

А вот c RedMonk иная ситуация: в этом рейтинге у Ruby 9-е место. Но у языка неровная динамика: он то поднимается в рейтинге, то снова падает. Например, в 2012 году он занимал 5-ю позицию.

Уровень зарплат

Согласно Хабр Карьере, медианная зарплата специалистов составляет 223 000 ₽. По лидам данных нет. Зато известно, сколько получают джуны (в среднем 101 000 ₽) и сеньоры (350 000 ₽).

Порог вхождения и перспективы

С нуля учить этот язык вряд ли получится, уже практикующие кодеры рекомендуют освоить базовые концепции программирования (переменные, операторы, типы данных, циклы, функции, ООП) и только потом переходить к изучению этого языка. Чаще всего разработчики приходят в Ruby после нескольких лет работы на любых других языках.

Тем не менее этот язык стоит изучить, поскольку Ruby — современный, постоянно развивающийся язык программирования.

Ruby применяют в веб-разработке (фреймворк Ruby on Rails), создании скриптов для администрирования, DevOps и тестирования, научных вычислений и обработки данных. С использованием Ruby on Rails написаны серверные части веб-приложений Twitter, GitHub, Airbnb и Shopify, поэтому язык имеет хорошие перспективы в будущем.

Swift

Популярность

В рейтинге TIOBE язык занимает 16-е место. За год Swift потерял одну позицию, оставаясь тем не менее востребованным и популярным.

Вот его динамика.

По RedMonk видим, что Swift резко поднялся из «подвала» в 2016 году. После чего, начиная с 2018 года, стабильно занимает 11-е место.

Уровень зарплат

Медианный показатель здесь — 263 000 ₽, джуны получают около 110 000 ₽, а лиды — 430 000 ₽. Если верить Хабр Карьере, специалисты по Swift явно одни из самых высокооплачиваемых на рынке.

Порог вхождения и перспективы

Swift достаточно простой для освоения язык. Заниматься коммерческой разработкой приложений можно уже примерно через год после старта его изучения.

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

Что выбрать?

Новичку для старта карьеры в IT лучше выбрать язык с максимально низким порогом входа, например Python, Go, JavaScript.

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

В любом случае главное, чтобы процесс затягивал, а работа нравилась. И конечно, не стоит бросать освоение языка на полпути, если что-то не заладилось. Чтобы поддержать мотивацию, рекомендуем к прочтению «Как войти в IT и не слиться по дороге».

Желаем удачи!

CI/CD-инструменты

CI/CD-инструменты позволят автоматизировать сборку исходного кода и процессы поставки. Разработчики теперь могут воспользоваться уже написанными скриптами сборки, в один клик перенося свои проекты с Git-репозиториев. Технология оповещения о новых событиях на сервере (вебхуки) позволяет реализовать еще больше сценариев автоматизации. По событиям в GitVerse можно вызвать через API сторонние сервисы. Например, при определенных событиях в репозитории можно запустить сторонний сборочный конвейер или отправить уведомление в мессенджер.

Новые функции персонального AI-ассистента разработчика GigaCode

Теперь AI-ассистент поможет разработчику решать задачи, связанные с кодом, в окне чата непосредственно в среде разработки. Сервис чата также доступен и в GitVerse, где при просмотре репозитория можно получить объяснение, что делает та или иная часть кода, а также советы по его улучшению. Список языков программирования, которые поддерживает GigaCode, пополнил Ruby, а также стала доступна генерация текстовых данных в формате JSON. На сегодняшний день AI-ассистент поддерживает уже более 15 популярных языков программирования и устанавливается как плагин в привычные среды разработки, включая IDEA, PyCharm, VSCode, Jupyter.

Функциональность для организаций

Теперь разработка на GitVerse доступна не только индивидуальным разработчикам, но и малым и средним предприятиям. Компании могут организовать совместную работу команды и управлять доступами к своим репозиториям.

При разработке новой функциональности мы учитываем пожелания пользователей, добавляем необходимые инструменты, чтобы они могли вести разработку еще проще и быстрее. С каждым релизом платформа будет становиться все более удобной и пополняться новыми популярными репозиториями, open source-версиями продуктов и инструментами для эффективной разработки. Будущее разработки мы видим в создании удобной среды по принципу единого окна, в которой все члены команды могут работать на своем этапе производственного процесса, заказывать облачную инфраструктуру и общаться. На всех этапах разработки партнерскую роль будет занимать AI: помогать писать код, советовать, как сконфигурировать стенд, готовить документацию, подсказывать шаги по CI/CD-конвейеру

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

• новые инструменты для управления проектами, позволяющие удобно организовывать рабочие процессы;
• интегрированная среда разработки позволит разворачивать полностью настроенные инструменты разработки в облаке. Функциональность будет доступна прямо из браузера: разработчик сможет легко и быстро открыть любой репозиторий GitVerse в среде разработки;
• новые функции GigaCode: генерация тестов, автоматическое создание документации и умный рефакторинг. Число языков, которые поддерживает GigaCode, пополнят PHP, HTML, CSS, Markdown и Rust;
• инструменты для безопасной разработки (оркестрация CI/CD, статический анализатор, управление секретами и безопасность зависимостей);
• удобный и безопасный вход через популярные сервисы идентификации личности, а также мобильная версия платформы.

Реклама Реклама АО “Сбертех” ИНН 7736632467, LjN8KXJG3

В этой статье мы рассмотрим как начинающему программисту подготовить себе рабочее место для разработки на фреймворке Ruby on Rails, который предназначен для создания веб-приложений.

Выбор подходящего дистрибутива

Первый шаг – выбор правильного дистрибутива. Для новичков идеально подходят такие дистрибутивы, как Ubuntu, Fedora и Mint. За основу возьмем ОС Ubuntu 22.04. Стоит отметить, что в Ubuntu уже есть предустановленные языки, такие как Perl, Python, а также Ruby, который и будем использовать

Установка необходимого программного обеспечения

Ключевым элементом является установка инструментов разработки. Для начала проверим какая версия Ruby установлена у тебя по умолчанию.

Откроем консоль через комбинацию клавиш Alt+Tab и напишем команду ruby -v. В консоли ты увидишь что-то вроде «ruby 2.4.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux]».

Версия, которая предустановлена в системе обычно устаревшая, поэтому имеет смысл ее обновить. Обновлять надо через RVM — Ruby Version Manager.

Для этого опять потребуется консоль, в которой нужно ввести следующие команды:

Разберем, что здесь написано.

1. $ – показывает, что в консоли ты работаешь под правами текущего пользователя. Печатать его перед командой не нужно, его итак видно в консоли перед курсором.
2. sudo — команда указывает, что команда после нее будет выполняться под правами суперпользователя (root).
3. apt update (или apt-get update, как устаревший вариант) — выполняет обновление доступных пакетов программного обеспечения из репозиториев, другими словами актуализирует список доступных версий программ для установки.

Выполняем обновление всех установленных программ и библиотек в системе

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

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

1. Команда curl c указанными ключами выкачивает скрипт, который находится по адресу https://get.rvm.io;
2. Команда bash -s stable запускает этот скрипт в системе. Скрипт установит в систему репозиторий RVM и установит сам RVM версии stable в систему.

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

Команда покажет список всех возможных версий языка Ruby, доступных для установки. Тебя интересует версия ruby-3.0.0

Устанавливаем посредством RVM Ruby версии 3.0.0

Ты должен убедиться, что все прошло успешно, проверив установленную версию (если увидишь версию 3.0.0, то ты справился).

Выполнив шаги выше ты обновил версию языка Ruby в системе и готов перейти к следующему этапу — установке фреймворка Ruby on Rails для разработки веб-приложений.

Рассмотрим термины, которые будут встречаться дальше

Gem — сторонняя библиотека, которая содержит в себе необходимый набор классов и методов, которая позволяет ускорить процесс разработки. Например, тебе нужно написать Телеграм-бота. А для этого что необходимо? Правильно, ознакомиться с официальной документацией, разобраться с http запросами, написать километры кода…

Но можно пойти по другому пути, а именно — установить gem telegram-bot-ruby и использовать в своем коде методы этого джема, потому как всю логику работы с Телеграм и все километры кода о которых говорили выше, кто-то уже написал.

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

Ruby on Rails (RoR) — фреймворк, написанный на языке ruby, предназначенный для разработки веб-приложений и реализующий архитектуру MVC (model, view, controller).

Приступим к установке Ruby on Rails

Для этого необходимо выполнить всего одну команду:

Команда установит джем rails в систему. Как видишь, ничего сложного:

Проверь версию установленного фреймворка (по умолчанию установится последняя версия RoR)

Создадим наше первое веб-приложение

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

Перейдем в папку с приложением

И запустим наше шаблонное приложение:

Теперь ты можешь перейти в браузере по адресу http://localhost:3000 и увидеть графическую заглушку, которая свидетельствует, что наше приложение запустилось.

Linux предлагает множество возможностей для разработчиков всех уровней. Вот так, за 14 коротких шагов ты смог создать и запустить свое первое веб-приложение. Успехов в дальнейшей разработке, изучению языка Ruby и фреймворка Ruby on Rails.

Мы уже проводили батл в прошлых 2020, 2021 и 2022 годах: первые два раза в голосовании победил Python, а в прошлом году — C#.

Вот, кто поборется за звание лучшего языка в 2023 году:

Правила батла остаются прежними:

1. В батле участвует 16 языков программирования.
2. Ежедневно соревнуются две пары.
3. За любимый язык можно проголосовать в течение 24 часов.
4. Пары составляются рандомно, так что выбирайте язык, который субъективно нравится больше.
5. В финале мы определим тройку победителей.
6. Старт — 19 декабря, финал — 26 декабря.

Примечание Сохраните эту запись в закладки: сюда мы добавим ссылки на все раунды батла во время голосования.

1. Первый раунд
2. Второй раунд
3. Третий раунд
4. Четвёртый раунд
5. Пятый раунд
6. Шестой раунд
7. Полуфинал
8. Финал
9. Результаты

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

Старт уже завтра — 19 декабря в 11:00 МСК. Следите, участвуйте, голосуйте!

Начитавшись новостей о противостоянии Илона Маска и Марка Цукерберга, которое перетекает из борьбы бизнесов в борьбу физическую и наоборот, мы решили провести новый летний батл за звание лучшего программиста мира.

Читатели Tproger смогут проголосовать за своего фаворита и выяснить, кто на самом деле самый крутой айтишник.

Правила батла просты:

1. В батле участвует 16 всемирно известных программистов.
2. Ежедневно соревнуются две пары.
3. За любимого программиста можно проголосовать в течение 24 часов.
4. Пары составляются рандомно, так что выбирайте программиста, который субъективно, лично вам нравится больше.
5. В финале мы определим тройку победителей.
6. Старт — 25 июля, финал — 1 августа.

Забирайте эту запись в закладки, ведь именно в неё будут добавляться ссылки на последующие этапы голосования.

Турнирная таблица:

Старт уже завтра — 25 июля в 11:00 МСК. Следите, участвуйте, голосуйте!

Dry-Types

Dry-Types предоставляет возможность определять и использовать строгие типы данных в Ruby. Это позволяет сделать код более надежным и понятным. Вот пример:

Dry-Struct

Dry-Struct – это простой и легковесный способ определения структур данных с строгой типизацией. Он помогает избежать нежелательных мутаций объектов и обеспечивает простой доступ к атрибутам. Вот пример:

Dry-Validation

Dry-Validation предоставляет декларативный способ проверки данных и валидации входных параметров. Он помогает управлять сложной валидацией и предоставляет легкую интеграцию с другими инструментами проверки данных. Вот пример:

Dry-rb предлагает широкий спектр инструментов, которые помогают разработчикам создавать более чистый, гибкий и надежный код на языке Ruby. В этой статье мы кратко рассмотрели dry-types, dry-struct и dry-validation, но dry-rb также включает другие библиотеки, такие как dry-transaction и dry-view, которые улучшают разработку программного обеспечения в различных областях. Если вы хотите узнать больше о dry-rb, рекомендуется ознакомиться с его официальной документацией и начать применять его в своих проектах для достижения более высокого уровня качества кода.

Одним из языков программирования, используемых для создания чат-ботов, является Ruby. Ruby предоставляет множество инструментов и библиотек, которые делают разработку чат-ботов быстрой и простой.

В этой статье мы рассмотрим преимущества Ruby для разработки чат-ботов с примерами кода.

Преимущества Ruby для разработки чат-ботов:

1. Простота и ясность кода: Ruby имеет удобный и понятный синтаксис, который делает код легким для чтения и понимания. Это особенно важно при разработке чат-ботов, так как код должен быть легко поддерживаемым и расширяемым.
2. Большое сообщество и библиотеки: Ruby имеет активное сообщество разработчиков, которое создало множество полезных библиотек и фреймворков для разработки чат-ботов. Например, библиотеки, такие как «Telegram Bot API» и «Slack Ruby Bot», предоставляют простой и удобный способ взаимодействия с популярными платформами мессенджеров.
3. Поддержка API и веб-сервисов: Ruby имеет мощную поддержку для работы с API и веб-сервисами. Это позволяет чат-ботам взаимодействовать с различными веб-приложениями и сервисами, открывая широкие возможности для автоматизации и интеграции.

Пример разработки простого чат-бота на Ruby с использованием библиотеки «Telegram Bot API»:

В этом примере мы используем библиотеку «Telegram Bot API» для создания простого чат-бота. Бот принимает сообщения от пользователей, обрабатывает команды «/start» и «/help», и отвечает на них соответствующими сообщениями. Если полученное сообщение не является командой, бот отправляет ответ «Извините, я не понимаю ваш запрос.»

Пример разработки чат-бота на Ruby с использованием библиотеки «Slack Ruby Bot»:

В этом примере мы используем библиотеку «Slack Ruby Bot» для разработки чат-бота, который работает в Slack. Бот реагирует на две команды: «/hello» и «/weather». При получении команды «/hello» он отправляет приветственное сообщение, а при получении команды «/weather» он вызывает функцию

, которая получает информацию о погоде с внешнего API, и отправляет результат в чат.

Ruby предоставляет множество библиотек для разработки чат-ботов, и вы можете выбрать ту, которая лучше всего подходит для вашего проекта. Помимо «Telegram Bot API» и «Slack Ruby Bot», существуют и другие библиотеки, такие как «Discordrb» и другие, которые позволяют взаимодействовать с соответствующими платформами мессенджеров.

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

В этой статье мы рассмотрим несколько советов и примеров кода по оптимизации производительности Ruby-приложений, которые помогут вам создать быстрые и эффективные программы.

Используйте правильные структуры данных

Выбор правильной структуры данных может значительно повлиять на производительность вашего Ruby-приложения. Рассмотрим пример использования хэш-таблицы (Hash) вместо массива (Array) для быстрого доступа к данным:

Оптимизация базы данных

База данных часто является узким местом в производительности Ruby-приложений. Вот пример оптимизации запроса с использованием индексов:

Избегайте медленных операций

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

Оптимизация производительности Ruby-приложений является важной задачей для создания эффективных программ.

В данной статье мы рассмотрели несколько советов и примеров кода, которые помогут вам улучшить производительность ваших Ruby-приложений.

Применяйте эти рекомендации, проводите профилирование кода и постоянно ищите возможности для оптимизации. Это позволит создать быстрые и отзывчивые приложения на Ruby.

Напомним, что индекс TIOBE оценивает популярность языков программирования, основываясь на поисковых запросах, которые содержат тот или иной язык. Для формирования индекса используются такие ресурсы, как Google, YouTube, Amazon, Wikipedia, Yahoo!, Bing и Baidu.

В 2023 году популярность языков изменилась. Какие языки потеряли популярность, а какие — нет, рассказали в этой статье.

1. Python, C и C++ соревнуются за звание лучшего языка
2. Пара слов о других языках
3. Выводы

Python, C и C++ соревнуются за звание лучшего языка

Именно таковы результаты по состоянию на конец декабря — двадцать языков программирования с наибольшей рыночной долей по версии TIOBE:

Ещё в прошлом году Java уверенно держалась в тройке, но теперь уступила своё место «плюсам». Любопытно, что в последний раз C++ становился лидером рейтинга TIOBE в далёком 2003 году, и это впервые, когда данный язык программирования обошёл Java по поисковым запросам. При этом Java входила в топ-3 свыше двадцати лет, начиная с 2001.

Уже в следующем месяце мы узнаем имя победителя. Каждый из лидирующей тройки уже занимал первое место по итогам года:

1. C++ — 1 раз (2003).
2. C — 3 раза (2008, 2017, 2019).
3. Python — 5 раз (2007, 2010, 2018, 2020, 2021).

Пара слов о других языках

Помимо прочего, мы видим, как Kotlin и Julia приближаются к топ-20, JavaScript держится в семёрке, а PHP вырывается в десятку, тогда как в прошлом году занял 12-е место.

Интересно, что Go поднялся аж на 7 позиций и теперь занял 12-е место рейтинга. Стоит отметить, что по версии GitHub за третий квартал 2022 Golang также находится на четвёртом месте по популярности, обогнав при этом PHP, C, C#, Ruby, TypeScript и JavaScript. Тенденция налицо:

На 18-е место рейтинга TIOBE вернулся Perl. Rust удерживает 20 позицию. Что касается Delphi, то он всю осень прыгал туда-сюда:

• сентябрь — 13 место (1.09%);
• октябрь — 18 место (0.85%);
• ноябрь — 14 место (1.08%).

В декабре же язык опустился на 16 место (0.85%), что соответствует результатам декабря прошлого года.

Выводы

Разумеется, рейтинг языков программирования 2022 TIOBE сложно назвать объективным, так как он рассматривает лишь один аспект — популярность ЯП в поисковых запросах пользователей. Он не отражает реальный рыночный спрос или количество написанного кода, как это делает GitHub в своих отчётах на основе проектов.

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

Не хотите пропустить новые раунды? Подпишитесь на тэг Лучший язык 2022 и следите за обновлениями в личной ленте.

Сегодня между собой соревнуются:

• Ruby и PHP;
• Swift и Kotlin.

Голосование по этим языкам программирования продлится до 16 декабря 2022 года. Опросы будут закрыты в 11:00 по МСК.

Правила батла по-прежнему просты:

1. В батле участвует 16 языков программирования.
2. Ежедневно соревнуются две пары.
3. За любимый язык можно проголосовать в течение 24 часов.
4. Пары составляются рандомно, так что выбирайте язык, который субъективно нравится больше.
5. В финале мы определим тройку победителей.
6. Старт — 13 декабря, финал — 20 декабря.

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

• Этап 1
• Этап 2
• Этап 3
• Этап 4
• Этап 5
• Этап 6
• Полуфинал
• Финал
• Результаты

Турнирная таблица:

Старт уже завтра — 13 декабря в 11:00 МСК. Следите, участвуйте, голосуйте!

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

• JavaScript vs. C++
• Ruby vs. Kotlin

Слушайте сердце и выбирайте язык, исходя из личной симпатии. Голосование в четвёртом раунде будет завершено 18 декабря 2021 года в 11:00 по Москве.

Но давайте отвлечёмся от официальной статистики и узнаем, какие языки предпочитаете именно вы! Завтра стартует баттл языков программирования 2021. Правила просты:

1. Всего участвует 16 языков программирования.
2. Каждый день соревнуются две пары.
3. На возможность проголосовать за любимый язык отводится 24 часа.
4. Пары составляются рандомно.
5. Выбирайте тот язык, который субъективно нравится вам больше.
6. В финале мы определим победителей — языки которые заняли первое, второе и третье место.
7. Старт — 14 декабря, финал — 21 декабря.

Так выглядит изначальная турнирная таблица:

А вот как мы выбирали лучший язык программирования в прошлом году.

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

Результаты баттла можно посмотреть по ссылке.

Codex — одна из моделей, которая используется для работы ИИ-помощника для программистов GitHub Copilot.

Инструмент лучше всего работает с Python, но спокойно справляется и с другими языками: JavaScript, TypeScript, Go, Perl, PHP, Ruby, Shell, Swift и так далее.

Как работает

OpenAI продемонстрировала в нескольких видео, как новый инструмент переводит команды на английском языке в код и таким образом может построить целую игру.

Вот видео, как Codex сделал простую компьютерную игру:

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

Например, если пользователь напишет в специальном окне фразу Print Hello World («напечатай Hello World»), Codex сгенерирует код print(“Hello World”), если выбран язык Python.

Codex печатает Hello World:

Codex — потомок GPT-3

Инструмент Codex — это почти как ИИ-модель на основе GPT-3 от Microsoft, но c несколькими улучшениями.

Codex выделяет память 14 КБ памяти для кода на Python, когда GPT-3 — только 4 КБ. Благодаря этому новый инструмент может учитывать в 3 раза больше контекста.

Где попробовать

OpenAI Codex вчера вышел в бета-тестирование.

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

Когда Codex полноценно запустится, его можно будет бесплатно попробовать в течение пробного периода.

Источник: OpenAI

В качестве полнофункциональной среды разработки мы будем использовать Docker-контейнеры и Visual Studio Code. По тому, как установить и пользоваться Docker есть масса статей и видео, поэтому этот увлекательный путь вы без труда пройдёте сами. А вот для Visual Studio Code нам потребуется установить специальное приложение Remote-Containers plugin, которое позволит работать внутри контейнера и использовать весь набор функций.

Шаг первый: завернуть весь проект с помощью Docker и Docker-Compose. Создать докер файл легко: вам достаточно нажать в VS Code F1, выбрать Docker: Add Docker Files to Workspace и следовать подсказкам. Также можно создать Dockerfile в корневой папке. Пример файла для Ruby on Rails приложения:

Далее создаем файл со скриптами entrypoint.sh, который так же добавим в корневую папку:

Чтобы магия сработала, создадим docker-compose.yml:

После этого устанавливаем Remote-Containers plugin в VS Code — плагин позволит работать внутри контейнера. Затем создаем файл конфигурации: F1 >> Remote-Containers: Add Development Container Configuration Files

В папке .devcontainer вы найдете файл devcontainer.json

Внесём новые настройки и уберем лишние комментарии. Добавим все сервисы из docker-compose.yml в "runServices": ["workspace", "db", "redis"], чтобы запустить их на старте.

Для того, чтобы VS Code останавливал контейнеры, когда окно закроется, добавим строчку "shutdownAction": "stopCompose", а также добавим список портов внутрь контейнера, которые будут доступны локально "forwardPorts": [3000]

Пример итогового содержания файла:

Теперь подготовим базу для нашего приложения и запустим в терминале: docker-compose run workspace rake db:create. Запускаем F1 >> Remote-Containers: Rebuild and Reopen in Container и с помощью команды в терминале rails s открываем готовое приложение.

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

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

Задачи на создание или отладку кода

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

1. Найдите ошибку в коде

Решение задачи

Здесь приведены методы ActiveRecord. Метод .find_by! вернёт первый объект из базы без ключа. Так как бесключевой метод не экранирует SQL-запрос, появляется возможность сделать sql инъекцию. Это делает код небезопасным и уязвимым. Подробнее можно узнать про SQL Injection в Ruby on Rails на этой странице.

Вторая ошибка в применении метода .delete, он удаляет запись без вызова коллбеков. Здесь необходимо заменить его на метод .destroy, чтобы вновь включить работу коллбеков.

2. Опишите, как работает этот код

Решение задачи

Cоздается Lambda, которая принимает единственный параметр a. Этот параметр выводится с помощью команды p, которая вызывает и передает атрибут строку "Lambda worked" с помощью [], где [] — это сокращённый вариант метода call.

3. В чём разница между двумя нижеприведёнными методами?

Решение задачи

Оператор += повторно инициализирует переменную новым значением, поэтому a += b эквивалентно a = a + b. Может показаться, что += изменяет значение, на самом деле, он создает новый объект и указывает старую переменную на вновь созданный объект. Разница имеет значение для производительности.

Задачи по структурам данных и алгоритмам

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

1. Реализуйте алгоритм игры «Тайный Санта (Secret Santa)»

Основная идея игры — анонимный обмен подарками. В шляпу кладутся небольшие записки с именами участников. Затем каждый играющий по очереди вытягивает бумажку с именем того, кому предстоит вручить презент. Реализуйте алгоритм жеребьёвки игры.

Решение

Стоит отметить, что у этой задачи есть несколько решений. Рассмотрим один из вариантов.

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

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

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

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

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

Теперь мы можем реализовать логику методом assign_recipients :

Теперь следует подумать, как реализовать рандомайзер, то есть как «встряхнуть шляпу» и применить логику привязки даритель-получатель. Для этого возьмём массив участников и применим к нему метод .shuffle!, после чего назначим получателей.

Теперь запущенный тест упадёт с ошибкой. Чтобы это исправить, применим mock для метода .shuffle! и озеленим тест.

В итоге мы получим такой код:

Анализ сложности алгоритма

Метод shuffle! реализует генерацию случайной перестановки, применяя алгоритм Фишера-Йетса. Он имеет временную сложность равную O(n) и константную пространственную сложность.

Также в решении задачи использовался один цикл, который проходит по всему списку участников. В этом же цикле мы заполняли Hash дарителей и получателей. Отсюда следует, что временная сложность и пространственная сложность равно O(n) ,где n — это количество участников игры.

2. Проверьте сортировку слов по заданному алфавиту

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

Примеры:

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

Поскольку в этом языке d стоит после l , то words[0]> words[1], следовательно последовательность не отсортирована.

Первые три символа «app» совпадают, а второе слово короче по количеству символов. Согласно лексикографическим правилам, «apple» больше «app», потому что l больше ∅, где ∅ определяется как пробел, который меньше любого другого символа.

Решение

Хорошим тоном считается, если кандидат напишет тесты в первую очередь:

Далее необходимо создать словарь с помощью ассоциативного массива Hash или просто массива:

Теперь повторим логику из того, что было написано в примерах:

После этого кандидат должен ответить с какой сложностью выполняется алгоритм.

Анализ сложности выполнения алгоритма

Временная сложность:

1. Создание словаря для сохранения порядка каждой буквы занимает O(n) времени.
2. В первом цикле мы сначала перебираем слова, а во вложенном — проверяем буквы этого слова. Временная сложность займет O(m), где m — это количество всех букв в словах. Таким образом, временная сложность составляет O (m+n). Но в словаре всегда 26 букв, в примерах меняется лишь порядок. Следовательно, временная сложность O(m), где m — это количество всех букв в словах.

Пространственная сложность:

Мы используем только одну дополнительную структуру данных — это Hash или массив, где хранится порядок букв. Поскольку в словаре только 26 букв и их длина неизменна, мы имеем константную пространственную сложность.

Итоговый вид решения задачи:

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

«Дыру» обнаружили в официальном репозитории Homebrew Cask. Эксплуатируя её, хакеры могли внедрять произвольный код в контейнер, после чего автоматически объединять его.

Это [объединение] происходит из-за проблемы в зависимости git_diff действия GitHub review-cask-pr, которое используется для синтаксического анализа различий в pull-запросе для проверки. Синтаксический анализатор можно обмануть, и он полностью проигнорирует вредоносные строки, что приведет к успешному одобрению вредоносного pull-запроса.

Разработчики Homebrew объявили об удалении автоматического объединения кода в контейнере на GitHub. Вместе с тем они отключили и удалили действие review-cask-pr из всех уязвимых репозиториев.

Homebrew — один из самых популярных пакетных менеджеров. Используется пользователями macOS и Linux. Написан он на языке Ruby, а распространяется как свободное программное обеспечение с открытым кодом.

Источник: SecurityLab

В основу списка легли данные Burning Glass. Они собирали информацию о количестве вакансий с упоминанием языков с начала 2021 года по США.

В итоге на первом месте по уровню зарплаты расположился Ruby с показателем в 105 223 доллара. Второе место и 102 119 долларов достались Java. Третье — С++ с его 101 234 долларами:

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

Так, например, специалисты ожидают рост популярности TypeScript на 60% в ближайшие 10 лет. В свою очередь Python также будет продолжать своё «распространение» — примерно на 21% за те же 10 лет. Самым худшим показателем в этом плане обладают C# и С++ — у обоих -14% в ближайшее десятилетие.

Источник: Dice Insights

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

В этом материале создана подборка по основам Ruby, часто используемым функциям языка. И если Junior разработчик никак не привязан к языку программирования, а Senior может писать более сложный код, то если вы сможете решить эти задачи без подсказок — бо́льшая часть практической подготовки на позицию Middle пройдена и можно сфокусироваться на других темах при подготовке к собеседованию.

Реализуйте метод Array#map

Реализуйте метод attr_accessor

Перепишите код без использования if

Проверка использования:

Напишите код, чтобы строка (1..10).select(&3) возвращала результат [3, 6, 9]

Добавьте функциональность объекта post, изменяющую значение любого параметра объекта на требуемое и логирующую это изменение

Класс Post:

На официальном сайте Ruby вышел пост, посвящённый релизу третьей версии языка — Ruby 3.0.0. По словам разработчиков, в нём они сделали упор на повышении производительности, параллелизме и типизации.

Для демонстрации мощи новой версии языка, на сайте опубликовали результаты его тестирования в OptCarrot Benchmark. Утилита измеряет производительность одного потока на основе нагрузки во время эмуляции игр для Nintendo Entertainment System (NES). В нём Ruby 3.0 (JIT) набрал в три раза больше баллов, чем Ruby 2.0 (VM).

Разработчики также заявили, что обновили ряд библиотек в новой версии языка. К таковым относятся RubyGems 3.2.3, Bundler 2.2.3, IRB 1.2.6, JSON 2.5.0 и т.д. Также команда, работавшая над Ruby 3.0 заявила об изменении 4 028 файлов, о 200 058 вставках и 154 063 удалениях со времён Ruby 2.7.0. С полным списком изменений можно ознакомиться в оригинальной публикации на сайте.

Источник: Ruby

Сегодня у нас новые соперники: SQL/TypeScript и Python/Ruby.

Вы выбираете кто из-них пройдёт в следующий раунд нашей битвы языков. Главное правило при выборе — голосовать за любимый язык.

Голосование закончится ровно через 24 часа — 17 декабря 2020 года в 11:00 по московскому времени.

Финальное голосование — здесь.

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

Завтра начинается баттл языков программирования 2020. Правила просты:

• В баттле участвуют 16 языков;
• ежедневно соревнуются две пары;
• на каждое голосование отводится 24 часа;
• вы выбираете язык который субъективно нравится вам больше чем его оппонент;
• пары подбираются случайно;
• в результате мы определим победителей, занявших первое, второе и третье места;
• Старт завтра — 14 декабря, финал — 21 декабря.

Так выглядит изначальная турнирная таблица:

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

Суть проблемы

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

Исследователи из Elttam добавили к отчёту proof-of-concept эксплоит, который это реализует. Проблема состоит в том, что эти механизмы встроены в сам язык, а именно в версии от 2.0 до 2.5. Также предполагается, что возможно доработать методы атак и под более старые версии. Кроме того, в альтернативных реализациях Ruby под названием JRuby и Rubinius потенциально могут быть сходные проблемы.

Другие языки

Уязвимости сериализации и десериализации объектов есть и в других языках. В 2015 году их нашли в библиотеке FoxGlove Security для Java. В 2017 году похожую проблему обнаружили в библиотеках .NET, а в 2018 году — в PHP. В последнем случае это затрагивает движок WordPress. Зачастую проблемы решаются выпуском патчей, хотя нередко баги сложно выявить. При этом нужно понимать, что сериализация и десериализация данных сама по себе ослабляет их защиту.

В мае 2018 года Oracle сообщила, что собирается убрать из Java встроенную поддержку сериализации. Вместо неё будет использован компактный фреймворк.

Анализ кода

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

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

Менеджеры версий

Обновленная среда разработки получила поддержку chruby и asdf. Более того, теперь все менеджеры версий доступны в WSL, Docker, SSH и других удаленных соединениях.

Подробнее о новых менеджерах и их поддержке можно узнать в блоге IDE.

Тестирование

RubyMine 2018.2 позволяет проводить повторное тестирование только тех тестов, которые не прошли проверку. По словам разработчиков, это освобождает пользователя от ручного просмотра каждой проваленной проверки. Новая функция также работает с пресетами rake test и rake spec:

YAML

В этом обновлении разработчики уделили внимание формату сериализации данных YAML. Теперь его код можно форматировать прямо в IDE и использовать все функции автозаполнения и навигации по коду. Более того, новая версия RubyMine предоставляет автоматическое заполнение структур данных YAML, имеющих файлы JSON Schema, и возможность копирования/вставки ключевого пути к значению в файлах .yml.

Git

Поддержка системы контроля версий в RubyMine 2018.2 получила несколько новых функций:

• файлы с конфликтом слияния теперь группируются в отдельном узле;
• новое действие Browse Repository at Revision позволяет исследовать состояние репозитория после каждого пересмотра;
• появилась возможность пропускать действие Push во время команды Commit and Push или использовать его только для защищенных веток;
• к GitHub можно подключить неограниченное число аккаунтов и выбрать главный для каждого проекта.

Другие улучшения

Кроме общих улучшений производительности новая версия IDE принесла новые иконки, темную тему для MacOS, поддержку Touch Bar, усовершенствованную поддержку JS, TypeScript и CoffeeScript, с которыми можно познакомиться в обзоре обновления IDE WebStorm 2018.2, а также подключение отладчика к удаленным процессам без необходимости их перезагрузки.

Подробнее о новых функциях можно прочитать на сайте разработчиков.

Предыдущее крупное обновление RubyMine под номером 2018.1 вышло весной 2018 года. Оно было направлено на улучшение общей производительности среды разработки.

Что нового?

В RubyMine 2018.1 реализованы:

• переработанный механизм статического анализа, повышающий скорость работы IDE;
• улучшенная опция Code Insight для блочных переменных;
• новая функция Run anything, позволяющая моментально запускать задачи Rake, rails s, любой скрипт или консольную команду:

• режим Debug anything;
• улучшенный режим постфиксного автозаполнения кода:

• предпросмотр разметки с рендерингом встроенных диаграмм:

• улучшенный способ выставления брейкпоинтов, позволяющий не прерывать исполнение при возникновении исключительной ситуации;
• навигационная панель:

• улучшения в работе с TypeScript, Vue.js и CSS;
• три новые функции для упрощения процедуры перебазирования из IDE: Abort Rebase, Continue Rebase и Skip Commit;
• опция «Открыть в терминале»:

• улучшенная визуальная документация.

Среда разработки RubyMine 2018.1 доступна для скачивания на Linux, macOS и Windows.

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

Кроме того, в этом месяце Julia и Kotlin вошли в топ-40, тогда как Rust и Groovy потеряли позиции в первой полусотне.

Напомним, что TIOBE составляет рейтинги языков программирования в начале каждого месяца, исходя из статистики поисковых запросов. В феврале аналитиков удивил язык Visual Basic.

• Обработку исключений в rescue/else/ensure теперь можно использовать напрямую в блоке do/end.
• Добавлен метод yield_self. В отличии от tap, он возвращает результат блока.
• Осуществлена поддержка измерения использования методов и блоков кода. При запуске теста с новыми функциями пользователь будет знать об используемых методах и частях ветвлений, а также сможет более строго оценивать полное покрытие тестами.
• Добавлены Hash#slice и Hash#transform_keys.
• Struct.new может создавать классы, поддерживающие именованные аргументы.
• Методы Enumerable#any?, all?, none? и one? поддерживают аргументы по образцу.
• Поиск констант высшего уровня больше не поддерживается.
• Библиотека pp.rb теперь включена в ядро языка. Больше нет необходимости использовать команду require “pp”.
• Вывод сообщений об ошибках в терминале теперь осуществляется в обратном порядке.

Прирост производительности

• Скрипты на Ruby теперь в среднем на 5-10% быстрее благодаря удалению всех инструкций trace из генерируемого байткода. Хотя поддержка trace добавлена в TracePoint, его использование обычно излишне.
• Код, генерируемый ERB из шаблонов, работает в два раза быстрее аналогичного из Ruby 2.4.
• Улучшена производительность таких методов, как Array#concat, Enumerable#sort_by, String#concat, String#index, Time#+ и так далее.

Прочие изменения по сравнению с версии 2.4

• SecureRandom теперь обходится средствами ОС, если это возможно. Ранее в первую очередь проверялось наличие OpenSSL.
• Добавлены гемы cmath, csv, date, dbm, etc, fcntl, fiddle, fileutils, gdbm, ipaddr, scanf, sdbm, stringio, strscan, webrick, zlib.
• Реализована поддержка Unicode версии 10.0.0.
• RubyGems обновлена до 2.7.3.
• RDoc обновлена до 6.0.1.
• У Thread.report_on_exception теперь по умолчанию установлено значение true. Это изменение призвано облегчить отладку многопоточных программ.
• IO#Write теперь принимает множественные аргументы.

Загрузка новой версии языка доступна на официальном сайте Ruby.

WSL

В новой версии появилась поддержка Windows Bash, а также есть возможность установки WSL.

Рефакторинг

Изменения затронули также рефакторинг. В новой версии IDE можно извлекать методы прямо в разделы private или protected.

RuboCop

Претерпел изменения RuboCop. Теперь пользователь может не только произвести автокоррекцию всего файла, но и создать особый cop department или offence class. Более того, RubyMine 2017.3 поддерживает пользовательские конфигурации rubocop.yml, что делает редактирование кода ещё удобнее.

Стиль кода

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

Puppet

Новая версия RubyMine поддерживает синтаксисы шаблона EPP. IDE производит автодополнение шаблонов и манифестов и переключаться между ними. Функция Refactor Rename позволяет переименовывать переменные и параметры, а инструмент Find Usages — определять, в каких местах проекта применены пользовательские шаблоны.

Отладчик

Отладчик обзавёлся функцией оценки Trace to_s, ограничивающей время выполнения особенно ресурсоёмких операций, экономя время пользователя во время отладки программы.

REST-клиент

Ещё одним нововведением RubyMine 2017.3 стала возможность тестировать API в IDE. Для этого нужно написать HTTP-запросы в файле .http и запустить их иконками на боковой колонке.

JavaScript

Были доработаны функции автозавершения кода и выведения информации для стандартных объектов, методов и Web API JavaScript.

Поддержка Vue.js и функции завершения и перехода к определению теперь работают со входными параметрами Vue, свойствами в объектах данных, вычисляемыми свойствами, а также методами.

Улучшена работа с CSS: благодаря новым вариантам окончаний кода для значений со свойствами transform, transition и pointer-events повысилась точность работы функции автозавершения кода для свойств и значений CSS.

Контроль версий

Усовершенствована система контроля версий: так, в функцию просмотра событий добавлено действие Interactively Rebase from Here, позволяющее подбирать, редактировать, пропускать, сжимать, переформулировать код и фиксировать его изменения. Сохраняются настройки каждой области рабочего пространства: открытые файлы, текущую конфигурацию и все контрольные точки. Также IDE показывает файлы, которые были изменены коммитом слияния, даже если они отличаются от общего родителя.

Инструменты баз данных

Доработке подверглись базы данных: узлы схем в древе базы данных были заменены функцией в контекстном меню, показывающей количество схем, отображаемых на древе в определённый момент времени. Для создания DDL-скриптов теперь можно использовать SQL-генератор. Кроме того, были улучшены инструменты работы с SSH.

Прочие нововведения RubyMine 2017.3

Среди других изменений можно отметить поддержку Ruby 2.5, Gems.rb, Docker Compose v3, Cucumber Expressions, улучшенный Markdown, возможности переименования файлов из вкладок, свёртывания многострочных контейнеров, предложения установки gem’ов в сообщениях трассировки стека, а также встроенную функцию установки Bundler через меню «Инструменты».

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

Ruby on Rails (RoR) — фреймворк, написанный на языке программирования Ruby. Он реализует архитектурный шаблон Model-View-Controller для веб-приложений, а также обеспечивает их интеграцию с веб-сервером и сервером баз данных. Является открытым программным обеспечением и распространяется под лицензией MIT.

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

Эта книга предназначена для тех, кто хочет писать на Ruby как профи. В ней рассказывается, как проектировать красивые API и работать с приёмами функционального программирования. Новичкам книга не подойдёт, а вот тем, кто уже разбирается в Ruby, она точно пригодится.

Цель данной книги — научить читателей эффективно использовать язык Ruby. В книге рассматривается версия Ruby 2.1. Издание содержит около 400 различных примеров, сопровождающихся четкой постановкой задачи и ее решением с подробными комментариями.

Книга отличается достаточно низким входным порогом. Для ее изучения необязательно знать основы веб-разработки. В книге материал о Ruby on Rails, популярного фреймворка для разработки веб-приложений, дается с нуля. Автор Майкл Хартл, помимо Ruby on Rails, знакомит читателя с основами самого языка Ruby, языка запросов SQL, CSS, HTML. В книге много внимания уделено практическому использованию возможностей фреймворка. Также можно ознакомиться с фрагментом книги.

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

С «Изучаем Ruby» вы в легкой и увлекательной форме на практике освоите все возможности этого языка, который сначала стремительно захватил сердца программистов Калифорнии, а затем и России.

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

В этой книге подробное разбирается внутреннее устройство языка Ruby. Знать сам Ruby читателю не обязательно, но вот знание C и, в особенности, принципов ООП будет огромным плюсом.

Эта книга отлично подойдёт для знакомства с Ruby. В ней разбираются все необходимые основы: от установки языка до обработки файлов и ООП. Каждая тема снабжена понятными примерами.

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

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

В этой книге рассказывается об основах веб-разработки на популярном фреймворке Ruby on Rails. Чтобы дать читателю представление о работе с реальными проектами, в книгу включены примеры использования Git, GitHub и Heroku.

Эта книга посвящена использованию принципов ООП в веб-проектах на Ruby on Rails. Фокус смещён в сторону практических решений, которые берут наилучшее от «пути Rails» и объектно-ориентированного подхода.

Также советуем ознакомиться с этим руководством по стилю оформления Ruby-кода и официальными гайдами по Ruby on Rails.

Змея или драгоценный камень

Основные различия между фреймворками заключаются в подходе к языку, философии и языках программирования, которые они используют. Философия Python «Есть только один очевидный способ решения задачи» противоречит гибкости, свободе и силе выбора Ruby.

Большинство новичков начинают программировать на Python. Самый первый взгляд на код Python заманивает тех, кто не знаком с языком. Его синтаксис просто идеален: нет точек с запятой, странных специальных символов или ключевых слов. Если вы еще не программировали на Python — попробуйте, вы не разочаруетесь. Код на Python будет выглядеть следующим образом:

Синтаксис Python делает его подходящим для большинства проектов. Читаемость кода также упрощает присоединение новичков в команду разработчиков.

Python также хорош для прототипирования. Вы можете реализовать новую идею, используя Python. Если идея осуществима и ваше приложение требует высокой производительности, идея может быть повторно реализована на высокопроизводительном языке программирования вроде C++.

Прим. перев. Если вы захотите начать изучение Python, советуем обратить внимание на наши обучающие материалы по этому языку.

Ruby особенный. Его можно назвать экзотическим и изящным. Не удивительно, что этот язык был изобретен японцами. В его строках есть что-то исключительное, что вызывает интерес. И хотя код не так читаем, как на Python, синтаксис по-прежнему очень прост для понимания и изучения. Код на этом уникальном языке будет выглядеть так:

В Ruby всё является объектами. Каждый тип данных относится к определенному классу со встроенными методами. То же самое относится к Python. Другой популярной особенностью Ruby являются «блоки». Используя их, вы можете изменить любой метод (даже встроенный).

Особенности фреймворков

Ruby on Rails и Django — это веб-фреймворки для реализации схемы Model-View-Controller. Этот шаблон разделяет проблемы разработки на три блока. Вот как это работает:

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

• Model представляет базы данных: профили пользователей, комментарии, сообщения и т.д.
• View переносит данные в шаблон HTML и отправляет их в Controller.
• Controller соединяет Model и View, обрабатывает пользовательские запросы и отправляет ответы обратно в веб-браузер.

В Django имя шаблона немного отличается и может смутить сначала. Это тот же MVC, но View называется Template, а Controller называется View. Таким образом, мы получаем MTV.

Расположение файлов

Ruby on Rails и Django по-разному упорядочивают файлы внутри проекта . Представьте, что у нас есть веб-приложение Rails с именем my_taxi. Когда разработчик добавляет новый компонент, например «счета» или «платежи», он должен перейти в специальное место:

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

Продуктивность

И Ruby on Rails, и Django имеют так называемые «волшебные», готовые решения. Однако магия RoR намного превосходит всё остальное.

Когда разработчик Rails создает контроллер, его методы могут автоматически обращаться к переменным и наследовать методы другого класса. Ни эти классы, ни переменные не определены явно. Ruby on Rails просто добавляет их автоматически. Он также автоматически устанавливает маршруты внутри MVC.

Разработчик Django, напротив, должен явно определять переменные и классы импорта. Они должны использовать регулярные выражения (что-то вроде ^[A-Z]+[a-z\g]$) для определения маршрутов и URL-адресов. Разработчики Django должны полностью понять, как все работает внутри, чтобы настроить код.

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

Производительность

Оба фреймворка основаны на интерпретируемых скриптовых языках. Это приводит к почти одинаковой производительности. Ранние версии Ruby, такие как 1.8 или 1.9.x, были низко производительными. В те дни Twitter перешел с Ruby on Rails на Scala, заявив, что «Twitter Search теперь стал в 3 раза быстрее». Но имейте в виду, что большинство компаний вряд ли достигнут такого же объема трафика, как Twitter.

Обычно Python считается немного быстрее Ruby. Некоторые люди могут спорить и ссылаться на сравнительное сравнение времени выполнения. Тесты показывают идентичные результаты с точки зрения производительности. Однако даже эксперты Ruby признают, что язык медленный. Хорошей новостью является то, что каждая новая версия языков программирования повышает производительность.

Документация и сообщества

Документация является личным предпочтением. Оба фреймворка хорошо документированы и организованы. Команды разработчиков Django Software Foundation и Rails проделали большую работу, чтобы документации были структурированными и удобными. Они похожи на простые книги, которые приятно читать.

Благодаря сообществам на StackOverflow и GitHub мы можем открыть Google и просто найти нужный код. Идея, которая придет вам на ум завтра, уже сегодня имеет готовое решение. Существует много программ, разработанных сообществом. Плагины могут помочь справиться с большинством задач.

Однако сообщества разные. Первоначально Ruby — это язык программирования общего назначения. Хотя существуют другие Ruby-структуры, такие как Sinatra или Lotus, большая часть Ruby относится к Rails. И Rails — это среда веб-разработки.

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

Что выбрать?

Django и Python

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

Ruby on Rails

• Если вы ожидаете поддержку от веб-сообщества.
• Если вы довольны большим количеством плагинов.
• Если вы ищете фреймворк, который будет работать за вас.

Заключение

Django и Ruby on Rails выглядят как близнецы от разных родителей: у каждого своя философия и свои особенности. Но когда дело доходит до работы, они действуют одинаково: они оба являются превосходными фреймворками, которые могут справляться с похожими задачами, используя свои уникальные подходы.

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

В минувшие выходные, пролистывая Amazon Web Services, я заметил новый сервис под названием «Rekognition». Я предположил, что это опечатка (recognition — англ. распознавание), но она привлекла мое внимание. Я заинтересовался: что это за сервис? Amazon привык добавлять новые сервисы в свою платформу с пугающей регулярностью, и этот я пропустил.

Я узнал, что в конце 2016 года Amazon выпустила свой собственный сервис для распознавания изображений на базе глубокого обучения на их платформе. Он может распознавать не только лица, но и объекты на фото. Так как сервис довольно новый, подробностей о нём было немного, но мне захотелось немедленно попробовать его. В общем, в течение часа я написал пример веб-страницы, которая может получать фотографии с моей веб-камеры и выполнять элементарное распознавания лица на нем.

Прим. перев. Чтобы не теряться в многочисленных сервисах Amazon, советуем вам прочитать нашу шпаргалку по AWS.

Раньше я занимался технологией распознавания лиц, используя сторонние библиотеки, а также Microsoft Face API, но все попытки создания подобного приложения не увенчались успехом. Но, просматривая документацию «Rekognition», я понял, что AWS API на самом деле очень прост в использовании. Я немедленно принялся за работу.

Цель

Мне была нужна простая веб-страница, которая позволила бы делать фотографию с помощью камеры моего iMac и выполнять распознавание на фотографии. В частности, я хотел бы определять пользователя, сидящего перед компьютером.

Сервис Amazon Rekognition позволяет создавать одну или несколько коллекций. Коллекция — это набор лицевых векторов для фотографий, которые вы хотите сохранить.

Примечание: Сервис сохраняет не фотографии, а их JSON-представление.

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

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

Фронтенд

Я не знал, какую библиотеку использовать для захвата изображения с помощью камеры iMac. В итоге я нашел на GitHub библиотеку JPEG Camera, которая позволяет использовать HTML5 Canvas или Flash для съёмки фото. Я решил использовать её и настроил под себя написанный на JavaScript образец.

Бэкенд

Для бэкенда я использовал Ruby-библиотеку Sinatra, которая может выполнять всю тяжёлую работу с помощью AWS. Я часто использовал Sinatra (на самом деле Padrino) в своих проектах и настоятельно рекомендую эту платформу.

Примечание: Amazon Rekognition предлагает сначала загружать исходные фотографии, которые использует его API, в Amazon S3, а затем обрабатывать их. Я хотел избежать этого ненужного шага и вместо этого отправлять изображения непосредственно в API, что мне в итоге удалось сделать.

Я сумел сделать то же самое с их приветствием Polly . Вместо того, чтобы сохранять аудио в MP3-файл и проигрывать его, у меня получилось закодировать данные MP3 непосредственно в тег <audio> на странице и воспроизвести их оттуда.

Код

Я разместил весь код этого проекта на моей странице на GitHub. Не стесняйтесь использовать и изменять его. Ниже я постараюсь объяснить код более подробно.

Пишем приложение

Прежде всего, вам понадобится учетная запись Amazon AWS. Я не буду вдаваться в подробности, поскольку это несложно, а в случае затруднений можно легко найти информацию в Интернете.

Создание пользователя AWS IAM

Как только вы создали учетную запись AWS, первое, что нам нужно сделать, — создать пользователя Amazon IAM (Identity & Access Management), который имеет права на использование службы Rekognition. Мы также зададим права для Amazon Polly.

В консоли Amazon нажмите на кнопку «Сервисы» в верхнем левом углу, затем выберите «IAM». В меню слева выберите «Пользователи». Вы должны увидеть список существующих пользователей IAM, которых вы создали в консоли, если вы делали это в прошлом.

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

Дайте пользователю имя и убедитесь, что вы отметили пункт «Programmatic Access», так как вы будете использовать этот IAM в вызове API.

Далее приведены настройки разрешений. Убедитесь, что вы щелкаете по третьему квадратику на экране с надписью «Attach existing policies directly». Затем в поле поиска «Filter: Policy Type» введите «rekognition». Выберите «AmazonRekognitionFullAccess» из списка, поставив рядом с ним галочку.

Затем измените фильтр поиска на «polly» и поместите галочку рядом с «AmazonPollyFullAccess».

Теперь у этого IAM есть права, достаточные для Amazon Rekognition и Amazon Polly. Нажмите «Next: Review» в правом нижнем углу.

На странице просмотра вы должны увидеть 2 политики использования, дающие вам полный доступ к Rekognition и Polly. Если вы их не видите, вернитесь и повторите предыдущий шаг. Затем нажмите кнопку «Создать пользователя» в правом нижнем углу.

Эта страница важна. Запишите ключи AWS Key и AWS Secret, которые вы указали на этой странице, поскольку нам необходимо включить их в наше приложение ниже.

Это единственный раз, когда вам будут показаны эти ключи, поэтому сохраните их и файл CSV с этой страницы в надёжном месте.

Загрузка кода

Теперь загрузите пример кода с моей страницы GitHub, чтобы вы могли изменить его по мере необходимости. Загрузите код в виде ZIP-файла, либо склонируйте его в вашу рабочую папку.

Первое, что вам нужно сделать, — это создать файл с именем .env в рабочей папке и ввести эти две строки, заменив в них ключи Amazon IAM на свои:

Теперь, если у вас установлен Ruby (не Ruby on Rails), то для установки зависимостей запустите команду:

Для запуска приложения введите эту команду:

Она должна запустить веб-браузер на порте 4567, чтобы вы могли увидеть веб-страницу и начать тестирование:

Использование приложения

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

Сперва создайте коллекцию, щелкнув по ссылке в самом нижнем левом углу страницы. Это создаст пустую коллекцию на серверах Amazon для хранения ваших изображений. Обратите внимание: имя по умолчанию для этой коллекции — faceapp_test, но вы можете изменить его в коде faceapp.rb (строка 17).

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

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

Обратите внимание, что обычный способ работы Amazon Rekognition заключается в том, чтобы загружать фотографию в Amazon S3 Bucket, а затем обрабатывать его оттуда, но я хотел обойти этот шаг и фактически отправить данные фотографии непосредственно в Rekognition как поток байтов, закодированный в Base64. К счастью, aws-sdk для Ruby позволяет использовать оба метода.

Разбор кода

Прежде всего, давайте взглянем на HTML-страницу:

Структура страницы проста: всего несколько блоков, кнопок и ссылок. Обратите внимание, что мы используем jQuery, а также Moment.js для настраиваемого приветствия. Следует обратить внимание на код faceapp.js, который выполняет все сложные задачи и ссылки на библиотеку камер JPEG.

Вы также можете заметить теги <audio> в нижней части файла — это аудио-приветствие, которое мы отправляем пользователю.

Теперь разберем JS-файл приложения:

Это настраивает библиотеку JPEG Camera, чтобы отображать канал на экране и обрабатывать загрузку изображений.

Функция add_to_collection() захватывает изображение с камеры, а затем выполняет запись в конечную точку /upload вместе с именем пользователя в качестве параметра. Функция проверяет, действительно ли вы ввели имя, которое нужно в качестве уникального идентификатора этих данных.

Функция загрузки проверяет вызов и выводит сообщение об успешном завершении или ошибке.

Функция compare_image() вызывается, когда вы нажимаете кнопку «Сравнить изображение». Она захватывает кадр из камеры и передает POST-данные в /compare. Эта конечная точка вернет либо ошибку, либо структуру JSON, содержащую id (имя) найденного лица, а также процент схожести.

Если лицо совпадёт с данными из коллекции, функция отправит имя найденного лица в /speech. Эта конечная точка вызывает службу Amazon Polly, чтобы преобразовать приветствие в файл MP3, который можно воспроизвести пользователю.

Служба Amazon Polly возвращает приветствие в виде бинарного потока MP3, поэтому мы берем этот поток ввода-вывода, шифруем его в формате Base64 и помещаем в качестве закодированной исходной ссылки в теги <audio> на нашей веб-странице. Затем мы можем вызвать .play() для воспроизведения MP3 через динамики пользователя с помощью HTML5 Web Audio API.

Прим. перев. Вы можете узнать о Web Audio побольше, прочитав нашу серию статей по этой теме.

Наконец, в JS-файле приложения есть функция greetingTime(). Она решает, стоит ли говорить «доброе утро / день / вечер» в зависимости от времени суток пользователя.

Теперь взглянем на код Ruby:

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

Остальная часть кода — это конечные точки, которые Sinatra будет слушать. Он прослушивает GET в /, чтобы отобразить фактическую веб-страницу конечному пользователю, а также слушает вызовы POST к /upload, /compare и /speech, которым JS-файл отправляет данные. Только 3–4 строки кода для каждой из этих конечных точек фактически выполняют задачи распознавания лиц и речи. Подробнее о них можно узнать из документации AWS SDK.

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

Уровень 0. Вступление

Взгляните на этот милый код:

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

А это выражение выдаст день недели для заданной даты:

А как вам этот код на Java?

Чему будет равно i? Он вообще скомпилируется? Да уж…

А программа на гифке ниже — это куайн по имени qlobe, написанный на Ruby. Ну разве это не изумительно?

А эта — ну просто шедевр! Анимированный 3D-пончик, какая вкуснятина!

Вставьте этот код в адресную строку:

и оцените всю магию самостоятельно!

А вообще лучше ничего не копипастьте, особенно код для командной строки, последствия могут быть неприятными.

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

Уровень 1. Начинающий

pyjava.java – Java-код, написанный, как на Python. Вычисляет факториалы больших чисел.
one_line_swap.c – Странные однострочники, меняющие местами значения двух переменных.
hello_world.java – Магическим образом выводит в консоли «hello world».
obfuscated.java – Выводит в консоли «Hi!», но выглядит как большой бессмысленный комментарий.

Уровень 2. Типичный

Исходник – Описание

bitwise_arithmetic.c – Складывает и перемножает числа при помощи битовых операций.
prefix2postfix.c – Преобразует префиксную нотацию в постфиксную.
sapin.c – Выводит движущуюся новогоднюю ёлку.
crazy_jvm.java – Похоже, что JVM сошла с ума и выводит случайные числа.
confusion.java – Удивительно, но этот код компилируется и выводит 1.
not_so_random.java – Выведет (случайным образом!) 1 1 1 1 1 1 1 1 1 1.
bangladesh.c – Выводит карту Бангладеша.
signature_prime.c – Бесконечно (теоретически) выводит простые числа.
day_of_week.c – Вычисляет день недели для заданной даты.
polyglot_so404.py.pl.rb.c.bf – Выводит 404 на Python, Perl, Ruby, C и Brainfuck.
polyglot_quine.c.py.pl.rb – Куайн, который работает в C, Python, Perl и Ruby.

Уровень 3. Продвинутый

Исходник – Описание

compound_eye.rb – Выводит анимированный узор.
best_short_program.c – Считывает число, записанное словами, и выводит его в десятичном виде.
check_prime.pl – Проверяет, является ли число простым, при помощи регулярного выражения.
quine_signature.c – Самый короткий код на Си, который печатает сам себя.
clock_in1line.c – Выводит текущее время в виде ASCII-арта.
japh.pl – Выводит «just another perl hacker».
matrix_effect.html – Выводит экран Матрицы.
pi_signature.c – Вычисляет первые 15 тысяч знаков числа пи после запятой.

Уровень 4. Просветлённый

Исходник – Описание

mandelbrot_imager.py – Создаёт множество Мандельброта (может работать до 20 минут!).
shortest_tetris.html – Очень простой вариант Тетриса.
qlobe.rb – Выводит вращающийся глобус.
animated_3d_doughnut.c – Показывает трёхмерный анимированный ASCII-пончик.
mandelbrot_flythrough.pl – Позволяет вращать, приближать, отдалять и прокручивать множество Мандельброта.

Программы для ценителей

Исходник – Описание

octaglot.cob.pas.f77.c.ps.sh.pl.com – Полиглот, выводит «hello polyglots» на 8 языках.
esoteric_polyglot.mal.bf.ws.asdf.​123.spoon.excon – Полиглот, написанный на 7 эзотерических языках.
palindrome_polyglot_quine.cs.java – Код-палиндром, компилируется в C# и Java и выводит сам себя.
quine_relay.rb – Программа-уроборос, написанная на 100 различных языках.

У многих программ есть обсуждения на сайтах StackOverflow, Quora, Programming Puzzles & Code Golf и Hacker News.

Если вам понравилась эта подборка, то обязательно понравится ещё одна: CuteVirusCollection. Будьте осторожны! Все программы оттуда немедленно перехватят контроль над системой, какой бы мощной она не была. Но поверьте, вирусы ещё никогда не были такими милыми.

Вам не хватило странного кода? Вот ещё несколько подборок:

• Рубрика «Красивый хак» на нашем сайте;
• IOCCC, IOCCC Winning Entries;
• PerlMonks;
• C Cignature Programs;
• CodeGolf-StackExchange: Tips, CodeGolf-StackExchange: Quine, StackOverflow: Strangest Language Feature;
• JS1K;
• Quora: Elegant Code, Quora: Shortest Effective Code, Quora: Coolest Thing in 10 Line;
• QuinePrograms;
• CodePoetry;
• Anarchy Golf;
• http://uguu.org/sources.html;
• JS Code Golfing.

Задача

Я хотел написать простое приложение для шифрования и дешифрования сообщений. Алгоритм AES показался хорошим выбором, так что я начал с поиска подходящей библиотеки.

Решение

Я пишу на Ruby, так что сделал то, что сделал бы любой на моём месте — загуглил «ruby gem aes». И сразу же нашёл библиотеку под названием (сюрприз!) «aes», простейший пример использования которой выглядел вполне понятно:

Если передать неверный ключ, то библиотека выдаст ошибку:

Баг

Во время разработки я заметил одну интересную особенность. Я написал тест для проверки расшифровки сообщений с неправильным ключом. Если говорить конкретнее, я заменил один символ в ключе, с которым сообщение было зашифровано и попытался получить обратный результат, ожидая ошибку. И… мой тест провалился! Ошибка не просто не была сгенерирована, ещё и само сообщение было корректно расшифровано:

Хорошо, допустим я нашёл один крайне особенный случай, один на миллион. Попробуем поменять два символа в ключе:

… и опять тот же результат!

Что же, осталась только одна вещь, которую стоило проверить — использовать совершенно другой ключ:

Это выглядело как серьёзная проблема безопасности, так что я решил разобраться, в чём дело.

Отладка

Проблема была вот в этой строчке библиотеки «aes»:

Для начала объясню часть про unpack. В данном случае эта функция разделяет строку на массив из 32 строк (смотрите документацию, если нужны подробности):

Затем для каждой из этих 32 коротких строк вызывается метод #hex. А String#hex в Ruby, как известно, преобразует шестнадцатеричные строки в их десятеричное числовое представление, а в случае неудачи возвращает 0:

Таким образом, любая строка не содержащая корректной шестнадцатеричной последовательности (как «ff» или «13») превратится просто в 32 нуля:

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

Итого

Библиотека «aes» не самая большая среди прочих в Ruby, всего 45 звёзд и 13 форков. Но проблема в том, что она выдаётся на первом месте в Google при поиске «aes gem» или «ruby aes gem», а мы обычно не задаём вопросов к тому, что Google выдаёт в топе. Мы вообще очень редко проверяем внешние библиотеки, хотя, судя по всему, должны бы. Особенно, когда дело касается безопасности.

Дополнение

Хочу пояснить, что у меня не было цели обвинить в чём-либо автора библиотеки. Он написал её несколько лет назад и не мог предвидеть, что она станет выдаваться поисковиками на первых строчках в 2017 году. Я просто нашёл серьёзный баг и хочу поделиться им с другими. Это то, как я представляю общественную ответственность в движении Open Source.

Технические детали

• Сама библиотека: https://github.com/chicks/aes
• Версия, использованная автором: 0.5.0 / 12c3648
• Пример кода

За годы работы я часто слышал вопросы о выборе технологий для того или иного веб-проекта. Кто-то спрашивает у нас, как у разработчиков, как правильно, а кто-то приходит и просит сделать на какой-то конкретной технологии.

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

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

Как чаще всего выбирают технологию сейчас:

1. Она мне нравится
2. Знакомый посоветовал
3. Прочитал в Интернете
4. На этой технологии сделан аналогичный сайт

В чем тут проблема:

1. Нравится. Очень субъективно. А что, если по требованиям она не подходит? Или на ней очень дорогие и редкие специалисты? Или она вообще умирает?

2. Знакомый. Обычно это тот знакомый, который «чуть лучше» разбирается в ИТ, чем тот, кому он советует. И даже если он программист с опытом, он не может знать всех решений на всех популярных языках. Ведь никто не спрашивает, по каким критериям выбирал этот знакомый. Если этот знакомы не CTO Google, я бы так просто не доверял такой рекомендации.

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

4. Аналог. Большинство популярных сайтов написаны на тех или иных технологиях потому, что так «исторически сложилось» . Если бы Facebook сейчас выбирал технологию для себя, я сомневаюсь, что он взял бы за основу PHP. А еще может быть, что технология уже устарела, её продавили на основе прошлых 3х пунктов, выбрали какую-то разрекламированную технологию, а не действительно эффективную и т.д. Вы вряд ли можете знать реальные причины выбор технологий в других проектах. Оптимальные технологии используются крайне редко в аналогичных проектах.

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

Важные критерии при выборе технологий:

1. Размер и тип проекта
2. Сложность проекта
3. Скорость разработки
4. Стоимость специалистов
5. Доступность специалистов
6. Доступные инструменты разработки
7. Наличие готовых решений
8. Гибкость решения
9. Наличие широкого сообщества
10. Отказоустойчивость решения
11. Тренд его развития
12. Наличие подробной документации
13. Стоимость поддержки
14. Требования к нагрузкам
15. Требования к безопасности
16. Кроссплатформенность
17. Возможности интеграции с другими решениями

Выбирая технологию по таким критериям мы сможем добиться объективного выбора и тем самым сэкономить себе время и деньги.

Какие бывают проекты

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

Сложность проекта

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

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

Языки программирования

В технологиях я бы выделил 3 уровня абстракции:

1. Чистый язык — это материал, из которого можно сделать все, что угодно. Ограничивают нас только возможности языка. На чистом языке сделаны все крупнейшие сайты мира с посещаемостью в сотни миллионов и миллиарды пользователей, такие как: Instagram, YouTube, Pinterest, Tumblr, Dropbox, Twitter, Facebook, Amazon, Digg, LinkedIn и другие. Более того, крупнейшие проекты в мире даже создают новые технологии для себя, так как уже существующие их не устраивают.
2. Фреимворк — это некая среда разработки для программиста с готовыми правилами и инструментами. Фреимворк с одной стороны помогает и ускоряет разработку, а с другой накладывает определенные ограничения. На фреимворках делаются проекты средней сложности с посещаемостью в миллионы.
3. CMS — это уже готовое решения, конструктор, в котором мы по частям собираем нужный проект. Его скорее не программируют, а настраивают. Ограничений тут огромное количество, выйти за границы коробки сложно и неэффективно. На CMS делаются простые сайты с посещаемостью до миллиона пользователей в месяц.

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

Сегодня есть огромное количество разных языков программирования, на которых делают сайты. И, более того, на всех популярных языках есть примеры огромных сайтов. Если 10 лет назад, говоря о технологиях больших сайтов, все говорили преимущественно про Java, то сегодня это может быть почти любой язык и утверждать, что сайты делаются на каком-то конкретном языке — стереотип. Это связанно с развитием самих языков, за последнее десятилетие многие сильно продвинулись в развитии и получили широкие возможности. Конечно, каждый язык чем-то отличается и выбирая мы опять же должны руководствоваться объективными критериями с оглядкой на задачи проекта.

На чистом языке, без использования фреимворков и коробочных решений, пишутся огромные проекты с повышенными требованиями по гибкости, нагрузкам и безопасности. Для таких огромных проектов часто бюджет не играет такого значения, как эффективность. Чем больше проект, тем больше будет требований по гибкости и нагрузкам, а значит, проще писать все с нуля, выделяя на это лучших специалистов, чем если брать какие-то готовые решения, которые непонятно кем писались и непонятно какие проблемы в них скрыты. К примеру, когда речь про небольшой проект с посещаемостью в 10 тыс. человек в день, то нам будет дешевле сделать его на CMS, которая будет потреблять в 3 раза больше ресурсов сервера, поставить дополнительный сервер за 50$ / мес. и оно будет работать. Когда же мы говорим про сайт с посещаемостью в 100 млн. пользователей в день, стоимость добавления серверов у нас будет просто космической, поэтому нам проще и дешевле вложить деньги в разработку решения на чистом языке, которое будет оптимальным именно для конкретного проекта.

Чем больше проект, тем больше стек технологий, который в нем используется. В огромных порталах может использоваться сразу несколько языков программирования. Опять же, мы приходим к объективным критериям выбора технологий. Часто один язык может хорошо делать одну задачу, а другой — другую. Такие проекты могут быть на столько огромными, что его части могут работать на разных серверах, с разными доменами (поддоменами) и разными технологиями. Не следует боятся винегрета технологий в большом проекте, хотя и допускать его нужно только когда это действительно необходимо, а также помнить, что далеко не все технологии совместимы. Самый яркий пример использования разных технологий — Google. Он на столько большой, что разные его части написаны на C/C++, Java, Python, JS и других языках. Более того, Google активно создает новые технологии, как, например, популярный нынче AngularJS.

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

1. PHP — его используют в основном для простых и средних проектов. Очень много коробочных решений. Относительно дешевые программисты. Антитренд последних лет, хотя с выходом последней версии языка под номером 7, он получил действительно мощные возможности.
2. Python — современный язык, разработка на нем быстрая и качественная. Используют его для средних и больших проектов. Программистов найти проблематично и стоят они не дешево.
3. Ruby — современный язык, разработка на нем так же быстрая. Его используют в основном для разработки простых и средних проектов, часто разрабатывают стартапы. Программистов также мало и они дорогие.
4. Java — разработка на нем очень долгая и дорогая. Его используют в основном для больших проектов со специфическими требованиями. Однако является самым популярным языком программирования в рейтинге TIOBE по состоянию на март 2016.
5. C# — аналог Java, также используют для больших проектов, часть в сфере FinTech.
6. JavaScript — очень быстро развивается, тренд последних лет и самый популярный язык программирования в рейтинге Redmonk по состоянию на июнь 2016. Огромное количество наработок и можно писать все, что угодно, даже игры. Его используют для средних и больших проектов, но действительно мощные возможности этот язык получит недавно, потому примеров больших проектов пока мало, специалисты самые дорогие и найти их сложнее всего.

Я описал самые популярные языки, которые сегодня используются под веб. Есть много новых языков, которые очень быстро растут, в частности Scala и некоторые другие. Но пока они довольно молодые и сырые. Я бы не рекомендовал бежать за модой и писать на них, пока они не разовьются во что-то большее.

Примеры больших сайтов:

• PHP: Facebook, Вконтакте, КиноПоиск
• Python: Instagram, Pinterest, Reddit
• Ruby: 500px, Groupon, Airbnb
• Java: Ebay, Amazon, Alibaba
• C#: Guru, Stack Overflow, Bank of America
• JS: LinkedIn, Walmart, PayPal

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

Фреймворки и платформы

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

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

Популярные фреймворки и платформы:

1. PHP: Symfony, Laravel
2. Python: Django
3. Ruby: Ruby On Rails
4. Java: Spring
5. C#: .NET
6. JS: Node.js, AngularJS

Больше всего фреймворков на PHP и на этом языке есть, из чего выбирать, но действительно функциональных не так много. Меньше на других языках, а на некоторых действительно качественных фреймворков вообще всего один, как у языка Ruby. У Java вообще очень много разных фреймворков для разных целей, и не только для сайтов. Все эти фреймворки ежегодно развиваются, выходят все новые и новые версии, одни фреймворки обгоняют другие. Например, Laravel только в последние несколько лет вышел на первое место по популярности, хотя самые сложные сайты до сих пор делаются на Symfony.

.NET и Node.js — это целые самостоятельные платформы, которые базируются на определенных языках, но имеют очень широкие возможности.

CMS и CMF

Это готовое программное обеспечение, которое нужно только настроить, реже — дописать / переписать какую-то из частей. Таких решений очень много на любом языке, но исторически так сложилось, что в основном все популярные CMS сделаны на PHP. Тут дело в развитие языков, раньше простые сайты, для которых и создавались CMS, писались на PHP. Я еще застал те времена, когда CMS почти не было, были скрипты — отдельные готовые части разных сайтов. Позже эти скрипты собирали в коробочный продукт, который был призван решить потребности 90% простых сайтов. Так и получилось, что основные CMS сделаны на PHP. Сегодня CMS на других языках развиваются слабо, потому, что уже есть сильные конкуренты на PHP, а простому сайту язык не играет большой роли, поэтому все смотрят на возможности этих готовых продуктов.

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

CMS бывают разные по назначению: общие, для интернет-магазинов, для блогов и т.д. Разные по условиям использования: платные и бесплатные. Для каждой популярной CMS есть куча разных платных и бесплатных модулей, которые легко подключать и использовать.

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

Именно в работе с CMS возникает больше всего непонимание среди конечных заказчиков таких решений. Любая CMS — это тонны готового программного кода, на все случае жизни. В коробочной поставке идут десятки и сотни модулей. Все это очень сильно ограничивает специалистов. Такие решения сильно «тормозят» , они абсолютно не гибкие, их очень легко взломать, особенно бесплатные CMS. Еще часто взламывают CMS через модули сторонних разработчиков, в которых есть критические уязвимости, потому что мы никогда не знаем, какого уровня программист писал тот или иной модуль. То есть любая CMS НЕ рассчитана для большого и сложного сайта. Она не могут выдержать большие нагрузки. Это решение не безопасно, чтобы не говорили разработчики конкретной CMS.

Я видел решения почти на всех популярных CMS, с многими за более, чем 10 лет работы, пришлось поработать лично. Часть из них популярна в рунете, а часть знают в основном на западе. На используемые в них языки CMS разбивать нет смысла, по причинам, описанным выше. Лучше сказать несколько слов про каждую популярную CMS:

1. WordPress — некогда блоговый движок, сейчас на ней делаются почти любые сайты, включая магазины. Одна из самых популярных CMS в мире, есть примеры довольно посещаемых сайтов. На ней часто делают информационные сайты, в том числе разные СМИ. Система бесплатная.
2. Joomla! — CMS общего назначения. Качеством особо не отличается, на ней делают очень маленькие сайты и обычно дешевле всех других вариантов, так как именно с этой CMS начинают учиться многие начинающие программисты. Система бесплатная.
3. Drupal — это уже CMF для общего назначения, с недавнего времени поставляется со встроенных фреймворком Symfony. Довольно мощная, на ней есть известные сайты, например, официальный сайт Белого Дома. Система бесплатная.
4. Magento — самая популярная система управления для интернет-магазинов в мире. Довольно мощная и сложная. В рунете используется редко, в основном на западе.
5. PrestaShop — одна из самых популярных CMS для магазинов в мире. Тоже довольно мощная, используют в основном на западе. Система бесплатная.
6. OpenCart — еще одна популярная система для интернет-магазинов, но её, наоборот, больше используют в рунете, чем на западе. В основном для маленьких и несложных магазинов. Система бесплатная.
7. 1С-Битрикс — очень распиаренная CMS общего назначения, номер 1 в рунете. Возможности очень широкие. На ней часто пытаются делать большие и сложные сайты, а после определенного порога в посещаемости переписывают их на других технологиях. Многие считают, что только эта CMS может интегрироваться с 1С, что не является правдой, поскольку все перечисленные CMS из этого списка могут интегрироваться с 1С, для этого у всех CMS есть специальные модули. Система платная.

Со всеми перечисленными CMS я работал. В основном со стороны разработчика. Точно НЕ рекомендую — Joomla, с остальными можно работать. Для магазинов лучше выбирать специализированные, а не общие CMS. Кроме 1С-Битрикс в рунете есть еще аналогичные коммерческие CMS, они во многом схожи. У каждой из систем есть свои особенности, но все они не предназначены для больших и сложных проектов, главное это не забывать.

Шаблоны

В последние 5 лет очень активно развивают шаблонные решения. Это еще на одну ступеньку выше, чем CMS. Если CMS — это конструктор и его нужно настраивать, то шаблоны — это уже готовые решения под типовые случаи. Например, в каждом городе есть свои рестораны, такси, клиники и т.д. Для всех этих типов малого бизнеса нужно примерно одно и тоже. Поэтому, можно просто выбрать готовый тематический шаблон, заменить в нем логотип, цвета и контент. При желании такие шаблоны можно дорабатывать по усмотрению владельца.

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

Есть специальные каталоги шаблонов: TemplateMonster, ThemeForest и др. Часто встречаются онлайн-конструкторы, в том числе тематические: Wix, PageCloud и др.

Мобильные приложения

В мобильных приложениях в последнее время используется два подхода: нативная разработка и кроссплатформенные технологии. Нативная ведется на оригинальных языках программирования, в частности Swift (для iOS, ранее был Objective-C) и Java (для Android). Кроссплатформенных технологий сейчас довольно много, они есть на базе разных языков программирования, в частности: Apache Cordova, React Native и др. Некоторые лучше, некоторые хуже. В любом случае, сложные приложения всегда пишутся на нативных технологиях. С кроссплатформой часто возникают проблемы, вплоть до того, что некоторые функции просто нереализуемы на тех или иных кроссплатформенных технологиях, сильно грузится оперативная память устройства, быстро садится батарея и т.д.

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

Стек технологий в больших проектах

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

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

Для примера рассмотрим технологии Instagram (данные Insight IT):

• Ubuntu Server 14.04 LTS — основная серверная операционная система
• Python — основной язык программирования серверной части
• Django — фреймворк
• nginx — второй уровень балансировки входящих HTTP-запросов
• gunicorn — WSGI-сервер
• HAProxy — балансировка нагрузки внутри системы
• PostgreSQL — основное хранилище данных
• postgis — поддержка гео-запросов
• pgfouine — отчеты на основе логов
• pgbouncer — создание пула соединений
• Redis — дополнительное хранилище данных
• Memcached — кэширование
• Gearman — очередь задач
• Solr — гео-поиск
• munin, statsd, pingdom — мониторинг
• Fabric — управление кластером
• xfs — файловая система

И это вполне нормальный стек технологий. Сам Instagram не самый большой и сложный сервис в мире.

Стоимость специалистов

Один из важнейших факторов выбора технологии является стоимость и доступность специалистов, потому что именно это самая затратная часть в любом проекте. В рунете есть только одна пузомерка по зарплатам — я отфильтровал по Киеву, уровень Senior, опыт 3-5 лет. Сравним средние значения.

Зарплаты:

1. C# — 3072$
2. Java — 3300$
3. JS — 3500$
4. PHP — 2780$
5. Python — 3000$
6. Ruby — 3000$
7. Scala — 3900$

В США немного другая картина:

Теперь переведем цифры на человеческий язык. Java хоть и не новый язык, но специалисты на ней всегда были одними их самых дорогих. PHP всегда был самым дешевым, да и специалистов на рынке очень много. В сравнение я внес еще и Scala как один из новейших и трендовых языков, по этой причине он дороже всех. Еще дорогой JS, это связанно с его бурным ростом в последние годы и растущей популярностью Node.js, а также AngularJS.

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

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

Тренды

Выбирая технологию, нам нужно смотреть вперед. Особенно, если речь о большом проекте. Все технологии очень быстро развиваются, выходят все новые и новые версии. Языки сильно меняются каждые 5-7 лет, фреймворки — каждые 2-3 года, а CMS — каждые 1-2 года. Важно выбрать не просто хорошую технологию сегодня, а предугадать тренды развития так, чтобы остаться на коне через несколько лет. Иначе, в конечном счете, придется переписывать проект, что всегда очень проблематично.

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

По результатам разных исследований можно выделить явных лидеров по росту — это JS (версия ES6 и выше) и мультипарадигмальные языки, в частности Scala. Кстати, именно Scala считается преемником языка Java и во многом на него похож. Также не плохо себя показывает Python.

Антитренды держат ряд старых языков и PHP. Правда, недавно вышла 7я версия PHP, в которой исправлены многие серьезные недостатки. Так что, я думаю, мы скоро увидим новый виток развития PHP. Еще многие большие проекты переписываются с Ruby на другие языки, тоже некий антитренд.

Для иллюстрации посмотрим, каких специалистов не хватает в США:

Именно это можно считать реальной картиной трендов, которые мы видим и у нас.

На чем делались большие проекты за последние 10 лет?

1. Airbnb — Ruby
2. Instagram — Python
3. Pinterest — Python
4. Foursquare — Python
5. Groupon — Ruby → JS
6. Twitter — Ruby → Scala
7. Uber — JS

Это уже не теоретическая статистика, а реальная практика. Python и JS очень хорошо себя показывают.

Стоимость поддержки

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

Стоимость часа зависит от зарплаты специалисты, с этим мы уже разобрались. А вот количество часов зависит от самой технологии и качества написания кода. Если решение коробочное, то часов на него может уходить очень много. То есть, с одной стороны, мы можем сэкономить при разработке первой версии проекта, но после погрязнуть в его постоянной доработке. Хорошо, когда решение популярное и есть официальная документация, но часто выбирают малоизвестные коробочные решения без какой-либо документации — в таких решениям стоимость поддержки будет во много раз выше стоимости самой коробки. То же касается некачественной разработки: у нас почему-то полностью отсутствует культура проведения технических аудитов готовых решений или его частей. В среднем за 20-40 часов можно проверить почти любое решение и найти его основные минусы. Чем более качественный код, тем легче, а следовательно и дешевле его поддерживать.

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

Так что выбрать?

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

Java

На Java Examples можно найти примеры на любой случай — от использования ключевых слов, вроде final, до объяснения, как выровнять иконку в Swing.

C#

Сайт для шарпистов С# Example вышел несколько более бедным, чем посвященный Java. Здесь вы не найдёте всех примеров, которые вам могут понадобиться, но можете найти что-то специфическое, например, как совместить несколько PrintDocument’ов.

JavaScript

Отдельный раздел JavaScript Book построен в форме самоучителя. Всего есть 13 тем, например: API, Error handling, jQuery, Events. Каждый из них содержит около десяти примеров. Правда, есть весомый минус — код выдаётся в виде текстового файла, без подсветки.

Haskell

Отличный способ изучить основы Haskell — ознакомиться с содержимым сайта Haskell By Examples. Здесь коротко описаны все базовые возможности языка, а примеры снабжены ссылками на Haskell Wiki.

Ruby

Существует и аналогичный ресурс по Ruby.

C++

Наверное, самый приятный сайт из этой подборки — это Cpp Examples. Красивый дизайн, подсветка кода, разнообразные сэмплы. Есть, несколько посвящённых паттернам, например, Observer или Builder.

PHP

Создатели русскоязычной подборки примеров с PHP.su сделали упор на практическое применение, а не на обучение новичков. Здесь не будет примеров, посвящённых ключевым словами и работе с переменными, но можно узнать, как сделать свою рассылку или гостевую книгу.

Gitdown использует DrinkShield в качестве анализатора дыхания и Ruby-скрипт в качестве git-хука. Проект был создан Alex Qin и Geoffrey Litt для участия в хакатоне hackNY в 2013 году, и занял там первое место.

Режимы

Gitdown может работать в трёх режимах:

• Normal: позволяет совершать коммиты с концентрацией алкоголя ниже 0.05%.
• Krunk: позволяет совершать коммиты с концентрацией алкоголя выше 0.05%.
• Ball(m)er: позволяет совершать коммиты с концентрацией алкоголя между 0.13% и 0.15%.

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

При этом, если включён параметр «verbose», gitdown также поделится полезными фактами об ухудшении вашего состояния.

Использование

Сперва клонируйте репозиторий и установите необходимые gem’ы:

Для использования скрипта в качестве хука его нужно скопировать:

Для использования этого проекта необходим Arduino Uno с модулем DrinkShield. Откройте файл arduino_gitdown/arduino_gitdown.ino в Arduino IDE и загрузите его на Arduino.

Затем откройте конфиг .gitdown и измените три параметра:

• mode: Нужно указать один из трёх вышеописанных режимов.
• port: Здесь нужно указать значение, которое можно найти в разделе “Serial Port” в Arduino IDE. Значение по умолчанию — /dev/tty.usbmodem1421, и оно работало на Macbook Air, используемом для разработки.
• verbose: Выставить «true» или «false» для выдачи полезной информации о состоянии при текущей концентрации алкоголя в крови.

Потом вы можете попробовать изменить файл в репозитории gitdown и закоммитить изменение для наблюдения за действием скрипта.

В зависимости от режима и концентрации алкоголя в крови скрипт либо разрешит, либо запретит совершить коммит.

jQuery

Очень приятный курс, проходить который можно, даже не зная, что такое jQuery вообще. Если что, jQuery — библиотека для JavaScript, с помощью которой можно находить и, например, изменять различные элементы HTML. Впрочем, это пояснение лишнее — курс начинается с весёлой песни, которая рассказывает про то, что такое jQuery.

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

Лекция ведущего сменяется практическими заданиями — с возможностью запросить подсказки. За просмотр подсказок условные баллы не снимаются, зато снимаются за просмотр ответов (такая возможность, естественно, тоже предусмотрена).

Задания сменяются новой теорией от ведущего, теория — снова практикой. В целом курс создан не для глубинного обучения jQuery, а для изучения основ синтаксиса и понимание общих принципов работы.

Github

Этот курс построен несколько иначе, чем предыдущий. Курс построен так, будто вам нужно запушить свой проект на Github — сначала даётся объяснение того, что на данном этапе нужно сделать, а чуть ниже — команда, которая это выполняет. Для перехода к следующему уроку эту команду необходимо перепечатать в терминал и выполнить. Результат работы команды вы можете увидеть в импровизированном диспетчере файлов. В общем-то, чаще всего к подобным самоучителям прибегают, именно когда появляется срочная необходимость выложить свой проект на Github. Лучшего способа, чем проделать все шаги самому под чутким руководством милого Октокота, наверное, нет. Ну, разве что наше руководство по быстрому старту с git.

Оформление заданий

Ruby

В этом туториале каждый урок строится достаточно простым образом — программа сообщает вам, как делается в Ruby то или иное действие, и немного теории. Переход к следующему уроку осуществляется, когда вы выполните это (или аналогичное действие) в консоли справа. Курс достаточно интересный, к тому же система довольно сносно шутит (например, сначала предлагает вам выполнить 40.reverse(), а потом сообщает, что перевернуть можно только строку, а число нельзя. Если вы, конечно, не поднесёте к монитору зеркало :D)

Первый урок на tryruby

А какие интерактивные самоучители знаете вы? Пишите в комментариях, лучшими из предложенных мы пополним статью.

Проекты и их кодовая база обычно находятся в постоянном развитии. Ситуации, когда вам необходимо переписать или заменить какую-то часть системы — неизбежны. Конечно, тут могут помочь тесты, однако если вы хотите сравнить поведение до и после рефакторинга под нагрузкой, то с помощью Scientist можете сделать вот так:

Оборачиваете код с исходным работающим поведением в блок use, а новый, проверяемый, в try. Команда experiment.run всегда вернёт именно то, что получилось бы при выполнении use, но при этом проделает много незаметной и важной работы:

• Решит, запускать или нет код в блоке try;
• Рандомизирует порядок, в котором выполняются блоки use и try;
• Замеряет время выполнения обоих случаев;
• Сравнивает результаты выполнения try с теми, что были получены, используя use;
• Проглатывает (но записывает) все исключения, случившиеся в try;
• Публикует всю эту информацию.

Чтобы не создавать каждый раз experiment можно использовать такой синтаксис:

Если вы не объявите блок try, то Scientist не будет делать ничего и дополнительных накладных расходов не будет.

Подробнее о Scientist можно почитать на GitHub.