Бэкенд

Обновляем список актуальных вакансий в SSP SOFT

Напомним, кто мы: компания SSP SOFT занимается заказной разработкой и IT-аутсорсингом. Наши спецы помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.

Рабочие места в офисах в Москве (отличная локация в ЦАО) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.

📢 Кого мы сейчас приглашаем (это описание вакансий в hh, а ниже прямые контакты с нашим HR для быстрого отклика):

1️⃣ Разработчика и аналитика 1C
2️⃣ Разработчика Angular
3️⃣ Middle Java Developer
4️⃣ Системного аналитика
5️⃣ Бизнес-аналитика

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

🎁 Наши бонусы: ДМС со стоматологией, обучение за счет компании, бонусная программа.

👉 В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.

Пишите с резюме нашему HR в Telegram: @sspsoft
Или присылайте резюме на почту: job@ssp-soft.com.

Всегда актуальные вакансии на https://hh.ru/employer/5648224:

📍 Мы открыты к диалогу и ценим честные и профессиональные резюме (без накруток опыта).

Расширению PostgreSQL Hacker Helper исполнился год.

Это расширение VS Code для разработки исходного кода PostgreSQL. Почти год назад я сделал пост о его создании, а буквально пару дней назад (9 августа) наступил год со дня релиза 1.0.0 версии.

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

Самый яркий пример - это List , динамический массив. Что в нем такого особенного? Во-первых, структура данных одна, но внутри себя он хранит (либо-либо) указатель/int/TransactionId/Oid. Во-вторых, его реализация зависит от версии - раньше он был реализован как связный список, а сегодня - это массив.

Еще один занятный пример - Value. Сегодня этой структуры нет, так как она разбилась на отдельные String, Integer, Float, Boolean и BitString (src/include/nodes/value.h). Это также нарушает изначально красивую картину, так как приходится добавлять логику - название структуры не соответствует типу хранимого узла.

За этот год я добавил множество фичей:

• Рендеринг выражений (переменные, представляющие выражения отображаются выражением, которое они представляют)

• Отображение содержимого хэш-таблиц

• Указатели на отношения из переменных типа Relids

• Форматирование файла с помощью pgindent

• Бутстраппинг новых расширений (создание шаблонных файлов)

• Дамп представления узлов в лог или отдельный текстовый файл (через pprint/nodeToString)

Если же говорить о нефункциональных особенностях:

• Большая расширяемость за счет файла конфигурации

• Поддержка нескольких расширений отладчиков

• Тестирование и CI-пайплайн для этого

Больше всего мне запомнилось добавление поддержки отладчика CodeLLDB. Этим я занимался 5 дней с утра до ночи. В то же время и добавил тестирование.

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

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

Ссылки: репозиторий и расширение.

P.S. За это время у меня накопилось множество историй о том, как я это расширение писал и с какими проблемами столкнулся. Если интересно почитать об этом - дайте знать!

Найм сломан?

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

Готовы? Система найма в ИТ — это дискриминация по интеллектуальному признаку. 💥

Да-да, вы всё правильно услышали. Умные люди легко получают работу и продвигаются по карьерной лестнице. А всем остальным приходится пахать втрое больше. Разве это честно? Разве человек виноват в том, какой интеллект ему достался при рождении? Нет. И всё же дорога в ИТ открыта в первую очередь умным. Это прямое нарушение принципа равных возможностей!

Чем врождённый высокий интеллект отличается от «голубой крови» аристократа? Ничем. Оба даны при рождении, оба никак не зависят от воли человека. В современном обществе мы уже не преклоняемся перед детьми дворян. Почему же перед «детьми-умниками» мы не просто преклоняемся, а ещё и создаём для них тепличные условия?

А нам остаётся только, как крестьянам при дворе, тяжело трудиться.

SourceCraft поддержит опенсорс‑разработчиков: старт грантовой программы с 16 августа и новые возможности платформы

Платформа для разработчиков SourceCraft открывает приём заявок на участие в грантовой программе поддержки: гранты на облачные технологии Yandex Cloud в размере 600 тыс. рублей на год получат важные и интересные опенсорс‑проекты, отвечающие критериям отбора. Подать заявку можно с 16 августа на сайте программы.

Оценивать проекты будут эксперты Яндекса. Среди ключевых критериев оценки:

• активность репозитория,

• актуальность,

• практическая польза проекта,

• понятный вектор развития.

Дополнительно, будет учитываться позиция в общем рейтинге на платформе SourceCraft, которая также пополнилась новыми инструментами:

• интеллектуальным алгоритмом для оценки значимости репозитория,

• системой личных достижений в профилях разработчиков.

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

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

Кроме того, 16 августа на платформе стартует конкурс проектов для опенсорс‑сообщества. Авторы новых репозиториев на платформе, которые наберут наибольший рейтинг до 31 августа, получат наборы эксклюзивного мерча от SourceCraft.
Следить за новостями от разработчиков и архитекторов платформы — также можно в блоге SourceCraft.

А вы уже пробовали запустить свой проект с помощью бесплатного объема облачных ресурсов Evolution free tier?

Тогда поделитесь опытом и мнением — опрос займет не больше 5-7 минут.

Пройти опрос 👈

Так мы узнаем, что еще можно улучшить, чтобы free tier стал для вас еще удобнее и полезнее. А еще, в перспективе сможем подключить его и для других облачных сервисов 😉

Текущие условия:

• виртуальная машина в конфигурации 2vCPU, 4 ГБ RAM, диск 30 ГБ;

• ежемесячный объем хранилища S3 — 15 ГБ, 100 000 операций PUT/POST/LIST, 1 000 000 операций GET/HEAD, 10 ТБ исходящего трафика;

• ежемесячный объем ресурсов для запуска контейнеров — 120 vCPU x час, 480 ГБ RAM х час.

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

Узнать больше про free tier и попробовать 🕹️

Вынос тестов Zig в отдельные файлы

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

Выносить тесты в отдельные файлы — хорошая практика. Рассмотрим это на примере проекта https://github.com/ktarasov/zigrep.

Для начала создадим директорию tests в корне проекта и файл unit_tests.zig. Перенесем туда все тесты из src/main.zig. В список зависимостей добавим импорт главного модуля: const main_mod = @import("../src/main.zig");. Вызовы функций и структур в тестах модифицируем, добавив к ним модуль, например: main_mod.parseArgs.

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

Далее нужно сообщить компилятору, что тесты теперь находятся в другом месте. Для этого изменим файл build.zig. После строки run_step.dependOn(&run_cmd.step) добавим создание модуля с тестами:

const unit_test_mod = b.createModule({
  .root_source_file = b.path("tests/unit_tests.zig"),
  .target = target,
  .optimize = optimize,
});

Также изменим блок добавления константы exe_unit_tests, указав unit_test_mod в качестве root_module.

Вроде всё готово. Попробуем скомпилировать и запустить тесты...

О нет, ошибка: "error: import of file outside module path: './src/main.zig'". Компилятор не импортирует файлы за пределами модуля unit_tests.zig.

Придется явно добавить основной модуль в импорт test-модуля. Для этого вернемся в build.zig и добавим после создания exe_unit_tests следующую строку:

exe_unit_tests.root_module.addImport("zigrep", exe_mod);

Снова запустим тесты — и они успешно пройдут!

Итого: мы вынесли тесты в отдельный файл и создали иерархию директорий, разделив основной код и тесты.

Пошаговый гайд по работе с RabbitMQ

RabbitMQ — брокер распределенных сообщений, разработанный на основе стандарта AMQP (Advanced Message Queuing Protocol). Этот инструмент собирает потоковые данные из нескольких источников, после чего распределяет и маршрутизирует их для дальнейшей обработки. Выбираем брокер сообщений и подробнее знакомим с его возможностями.

Бенефиты RabbitMQ, которые выделяют его на фоне других похожих сервисов: 

• надежность — все сообщения в RabbitMQ будут доставлены с соблюдением порядка, даже в случае технический сбой;

• масштабируемость — может работать с большими объемами данных. Также его можно развернуть не только на отдельном сервере, но и в распределенной среде;

• гибкость — поддерживает большое количество сценариев для маршрутизации и распределения сообщений. Это позволяет сочетать программу со многими приложениями.

Как настроить RabbitMQ на трех операционных системах: Ubuntu, Debian и CentOS Stream, а также об основных принципах работы этой технологии — читайте в подробном гайде в базе знаний Рег.облака.

Красные флаги в код-ревью: перегибы, которых лучше избегать

1. Фокус на мелочах. Если уделять много внимания опечаткам и код-стайлу, то времени уйдет много, а реальных результатов будет мало. Главное — это всё-таки архитектура, алгоритмы и производительность, а косметика только на втором плане. Зачем портить настроение себе и команде, если можно ничего никому не портить?

2. Поверхностный анализ. Забивать на проверку кода — тоже плохая идея. И дело даже не в багах, их отловит тестировщик. Дело в безопасности всей системы. Если какой-нибудь хакер найдет уязвимость, которую QA не нашел, — жди беды. Ну и техдолг никто не отменял: если не делать сразу хорошо, однажды придется переделывать.

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

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

А каким должен быть хорошее код-ревью — в нашем блоге.

Что такое корпоративный ИТ, если не гарем?

Заметьте: компании требуют от вас эксклюзивности - никакой второй работы, никаких сторонних проектов. У вас два работодателя? Ах ты профурсетка! (А если вы сеньор - извините, куртизанка.)

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

Почему недостаточно Unit тестов и нужны Интеграционные?

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

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

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

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

Почему я больше никогда не буду использовать сервис bitly?

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

Long story short: помогают тут ребятам с одним оффлайн проектом, нужно было быстро сделать QR код для флайеров, google выдает миллион сервисов для генерации, выбрал первый попавшийся “Create Your Free QR Codes”.  Удачно все сделал, заказали флаеры, не смотря на то, что по пути на каждому этапе было Free через 2 недели (когда уже все напечатано) прилетает вежливое “Oh no! Your Dynamic QR Codes will expire in 3 days”. И конечно же он перестанет работать если не заплатить ($20/month). 

Масштаб “потерь” - $40, но я готов заплатить $200 чтобы объяснить они строян бизнес на скаме и для кармы это вредно. 

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

Как вы поступаете в такой сиутации?  Я как-то с детства считаю что нельзя потокать и платить. 

Мои действия:

✅ никогда в жизни ни на одном из моих проектов не будет использоваться сокращалка Bitly

✅ написал далобу в FTC

✅ написал отзыв на Google Maps (там таких много)

☑️ найду и напишу отзывы на других сервисах

✅ попрошу вас помочь мне и присоединиться

P.S. Ресеч показал, что это не просто какие-то горе стартаперы, а проект компании Bitly (рейтинг 1.6 на Trustpilot).

Если вам нечем заняться и вам не сложно уделить 2-5 минут своего времени. 

Промпт для генерации отзыва:

Write a concise, neutral review of qr-code-generator.com (Bitly) in plain, easy-to-read language, 80-120 words. Context: It appears in Google for queries like "free qr code generator." During setup, the process is presented as free; any expiration notice, if present, seems absent or buried in terms. About 14 days later, the QR may be deactivated behind a paywall, leaving printed materials unusable unless payment is made to reactivate. The system does not allow converting that now paid QR to a free static code or redirecting it without payment. Many users report similar experiences online, including numerous Reddit comments. Keep the tone calm, factual, and non-accusatory. Do not include personal info or insults. Write in your own words.

Места куда стоит запостить отзыв:

- Google Maps (Bitly Office Google Maps)

- Trust Pilot

- G2

- Capterra

P.P.S. Есть кто-то из СМИ хочет изучить эту историю и написать подробнее - я буду рад ответить на вопросы и предоставить материалы. 

P.P.P.S. Особенно иронично выглядит позиция “Head of Happiness” в подписи письма

#justice 

CSI-драйвер и Swordfish API: как заставить Kubernetes дружить с любым хранилищем

В современных enterprise-средах важно обеспечить стандартизированный доступ к системам хранения данных (СХД) от разных производителей, избегая жесткой привязки к конкретному вендору. Одним из решений этой задачи является использование CSI-драйвера, который взаимодействует с Swordfish API. Такая интеграция позволяет Kubernetes автоматически создавать, подключать и удалять тома, избавляя команды от множества ручных операций.

Процесс выглядит так: когда приложение в Kubernetes запрашивает постоянное хранилище, оркестратор формирует PersistentVolumeClaim (PVC) с нужными параметрами — размером, типом и характеристиками. Kubernetes определяет, что создание тома должно выполняться через CSI-драйвер, и передает запрос в эмулятор Swordfish API. Тот создает том, а в случае работы с файловыми системами (например, NFS) дополнительно настраивает подключение к серверу и возвращает CSI-драйверу сведения о готовом ресурсе.

Дальше Kubernetes связывает созданный том с заявкой PVC, после чего CSI-драйвер монтирует его на рабочий узел к нужному контейнеру или поду. Эмулятор Swordfish API при этом добавляет путь к каталогу в конфигурацию NFS (/etc/exports), что позволяет клиентам подключаться к сетевому хранилищу.

Когда хранилище больше не нужно:

• DevOps удаляет PVC.

• Kubernetes вызывает NodeUnpublishVolume для размонтирования тома с узла.

• CSI-драйвер передает команду Swordfish API.

• API удаляет том и освобождает ресурсы (в случае NFS — удаляет запись из /etc/exports и каталог).

• Kubernetes удаляет объект PV, завершая процесс.

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

Если интересно, как самостоятельно разработать CSI-драйвер с поддержкой Swordfish API и запустить его даже без реального оборудования, то об этом — в статье, где пошагово показано, как реализовать и протестировать решение.

В прошлом году я помог Дмитрию Свиридкину подготовить и опубликовать цикл из 12 статей "Путеводитель C++ программиста по неопределённому поведению". Теперь этот расширенный, доработанный и обобщённый материал доступен в виде печатной книги:

Экскурс в неопределенное поведение C++ / Д. О. Свиридкин, А. Н. Карпов, – СПб.: БХВ-Петербург, 2025. – 384 с. – (Профессиональное программирование)

ISBN 978-5-9775-2073-7

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

Книгу можно найти в offline и online магазинах.

Ещё какое-то количество книг я и коллеги раздадим в качестве сувениров и призов на различных мероприятиях, таких как:

• Сплошные плюсы. Клуб С++ разработчиков.

• Митап «Мир С++».

• И т.д. Узнать о подобных мероприятиях можно, например, в моём ТГ канале "Бестиарий программирования".

Приятного и вдумчивого чтения!

Рецепт приготовления кролика от нашего Backend Lead U^ｪ^U

Брокеры сообщений, в частности RabbitMQ, широко применяются во всем IT. Однако это далеко не магическая коробка, а написать код так, чтобы не потерять свои сообщения — крайне нетривиальная задача.

Этим летом наш Backend Lead Витя Михайлов выступил на Saint HighLoad++ 2025, где рассказал, как же правильно готовить RabbitMQ, и поделился классными кейсами.  

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

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

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

Разве это честно? Пока мы зубрили вопросы к экзамену, кто-то звал халяву. Пока мы пахали, кто-то пил шампанское, приправленное пеплом сожжённого желания. И вот теперь еще и это.

Товарищи, это уже не карьерный рост, а магическая допинг-программа. И с ней нужно бороться.

P.S. Интересно, а пользуется ли нанимающая сторона какими-то секретными техниками поиска и найма?

Выходные не прошли зря.

В пьяном дурмане (это наркоз от попоболи) я продолжал разработку своего AI-трейдера, воспользовался вашими предложениями в телеграм (огромное спасибо за подсказку), и кое-что получилось:

• Добавлены бусты LightGBM (LGBMRegressor) и CatBoost (CatBoostRegressor). Теперь обучаю три модельки, сравниваю результаты и выбираю лучшую.

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

И вот результат тестовой торговли модельки на исторических данных:

Начальный баланс: 1000 USDT

===== Отчёт по сделкам =====

Всего сделок: 66

Винрейт: 40.91%

Средний PnL: 44.82 USDT

Максимальная просадка: -35.63%

Финальный баланс: 3958.17 USDT

В общем, готов богатеть. И пусть только попробует не показать такой результат на реальном бабле!)))

Окей, собственно говоря, в подтверждение моих слов о том, что ИИ - это просто перехайпанная стагнация, в которую гигатоннами сливают деньги от нефиг делать - встречайте: ChatGPT 5!

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

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

Итог? У нас на руках одна модель, которая одна за всех. Почему? Потому что 99,95 % всех юзеров не знают разницы между 4.1 и 4о. В таком случае OpenAI сможет урезать финансирование и охладить своё безудержное использование серверов.

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

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

Что это? Оптимизация расходов.

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

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

Где учиться бэкенду

Привет! Мы на Хабр Карьере собираем сотни онлайн-курсов в IT или digital на маркетплейсе курсов и каждую неделю делаем подборки обучений для тех, кто хочет учиться какой-то специализации с нуля или для тех, кто уже в профессии, но чувствует, что хочет прокачать навыки.

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

— Алгоритмы и структуры данных

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

— Git

Система контроля версий. Позволяет вести историю изменений, работать с ветками, мержить и откатывать изменения в коде.

— Python 

Язык общего назначения, популярен в вебе, автоматизации, ML.

— FastAPI

Лёгкий и быстрый фреймворк для создания REST API с поддержкой async/await и автогенерацией схем.

— Django

Фреймворк для быстрой разработки web-приложений, включает ORM, авторизацию и админку из коробки.

— JavaScript / TypeScript

JavaScript — язык для веб-интерфейсов и серверной логики (через Node.js). TypeScript — его надстройка с типизацией, упрощающая масштабируемую разработку.

— Java / Spring

Java — строго типизированный язык. Spring — основной фреймворк для создания REST API, микросервисов и корпоративных приложений.

— Go

Компилируемый язык от Google с простым синтаксисом и встроенной поддержкой параллелизма. Используется в highload-системах, DevOps и backend-разработке.

— C#

Язык от Microsoft, используется с платформой .NET. Применяется в разработке desktop-, web-, enterprise- и игровых приложений.

— PHP

Скриптовый язык, ориентированный на веб. Часто используется с CMS (например, WordPress) и фреймворками (Laravel, Symfony).

— Ruby

Язык с лаконичным синтаксисом. Наиболее известен благодаря фреймворку Ruby on Rails, ориентированному на быструю разработку веб-приложений.

— SQL / PostgreSQL

SQL — язык запросов к реляционным БД. PostgreSQL — популярная СУБД, используется в веб-приложениях, аналитике, поддерживает расширения и транзакции.

— Docker

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

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

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

→ Смотреть курсы по всем специализациям

50 000 пользователей зарегистрировались в Amvera Cloud

Друзья, 8 августа 2025 в облаке Amvera зарегистрировался 50 000-й пользователь.

У нас юбилей!

В юбилей принято дарить подарки, и такой ждёт нашего юбилейного пользователя с ником aryachay. 

Amvera Cloud – облако для простого запуска проектов со встроенным CI/CD (деплой идёт через Git или загрузку файлов в интерфейсе). C Amvera вам не нужно думать о настройке NGINX, виртуальных машин и другой инфраструктуры.

Как понять, что ИИ не даст хорошего результата?

Бывало такое: пока игрался с промптами, мог уже два раза написать код сам, но нормального результата так и не добился?

Наш бэкенд-лид Максим вывел правило трех попыток

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

Тратишь время на ожидание результата, потом проверяешь этот результат: в первый раз ушло 15 минут, не получилось. Пробуешь другой запрос, это еще 15 минут, тоже не получилось. Третий раз еще 15 минут. И если руками задача делается за 2-3 часа, то нет смысла убиваать время на попытки сэкономить 5 минут. Да и лимит стоит денег, тратить впустую его не хочется. Поэтому такие условные ограничения в голове: два-три раза и дальше сам.

Кстати, Максим написал статью о том, как они в команде 2,5 месяца пилотили Junie. Успехи, цифры и боли - все здесь.