SSP SOFT продолжает найм — ищем крутых ребят в команду 🔥
Кто мы такие и что делаем? SSP SOFT — это компания среднего бизнеса, наши направления: разработка заказного софта, IT-аутсорсинг выделенных команд и еще мы немного аутстафферы. Кандидатов ждут реальные, интересные проекты, прокачка скиллов и приятные бенефиты. Стараемся делом показывать, что для нас сотрудник — главная ценность. Минимум бюрократии, только рабочие процессы.
✅ Что мы предлагаем нашим будущим коллегам: — Интересные задачи, — Персонального наставника — мы позаботимся о твоем онбординге, — Центр компетенций — прокачивай свои скиллы без ограничений, — Свободу передвижения — работай откуда душа желает в РФ,(ино-локации обсуждаются), — Офисы для общительных — добро пожаловать в наши уютные пространства в Москве (офис в ЦАО) и в Томске. — Разумный Work-Life Balance — чтобы хватало сил и на работу, и на жизнь.
🎁 А еще: — Бонусная программа с «плюшками в рынке», — Обучение за наш счет — вкладываем в будущее, — ДМС с заботой о твоей улыбке (стоматология включена).
👉Если ты открыт для классной работы, топовых бонусов и профессионального роста — присылай резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina). Не забудь в сопроводительном или в начале переписки указать секретную фразу «Нашел(ла) вас на Хабре».
Бессерверные вычисления: почему ваш код может стать заложником провайдера
Бессерверная архитектура обещает не думать об инфраструктуре, но скрывает риски vendor lock-in, которые проявятся слишком поздно. Пока вы наслаждаетесь отсутствием серверов, ваша бизнес-логика медленно превращается в заложника облачного провайдера.
Проблема:
Cold start в критичных приложениях достигает 10-15 секунд
Стоимость непредсказуема при скачках нагрузки
Локальная разработка и отладка превращаются в квест
Реальные кейсы:
python
# Проблема: разрыв между продакшеном и локальной средой
def lambda_handler(event, context):
# На локальной машине работает
# В AWS Lambda падает с таймаутом
return expensive_operation() # 25+ секунд
Что мониторим в бессерверной среде:
Performance
Холодные/горячие старты
Потребление памяти
Execution duration
Безопасность
Права IAM-ролей
Доступ к секретам
Цепочки вызовов функций
Экономика
Стоимость вызова
Количество параллельных исполнений
Использование сторонних сервисов
Когда бессервер оправдан:
Обработка событий с неравномерной нагрузкой
Фоновые задачи (генерация отчетов, ночные джобы)
API с низким RPS
Альтернативы:
Kubernetes + Knative — гибридный подход
Cloudflare Workers — edge-вычисления
Self-hosted FaaS — полный контроль
Вывод: Бессерверные технологии — мощный инструмент, но требуют тщательного проектирования и постоянного мониторинга затрат. Прежде чем погружаться в serverless, оцените, готовы ли вы к зависимости от вендора и непредсказуемым расходам.
Контейнеры не панацея: скрытые затраты на содержание Kubernetes, о которых молчат вендоры
Kubernetes стал де-факто стандартом оркестрации, но за кадром остаются реальные эксплуатационные расходы. Когда стоимость обслуживания кластера превышает стоимость самих сервисов — пора пересматривать архитектурные решения.
Что не учитывают при внедрении:
Эффективность нод: В среднем 35-40% ресурсов простаивают "на всякий случай"
Стоимость сетей: Service mesh + CNI добавляют 15-20% к потреблению CPU
Трудозатраты: 1 инженер на 3-5 кластеров — утопия для средних компаний
Реальные метрики из практики:
bash
# Анализ утилизации за 3 месяца
kubectl top nodes | awk '{sum += $3} END {print "Средняя загрузка:", sum/NR "%"}'
# Результат: 41% по CPU, 28% по памяти
Где теряем деньги:
Overprovisioning "На всякий случай" развертываем на 200% больше ресурсов
Сложность мониторинга Требуется отдельный стек: Prometheus + Grafana + Alertmanager
Безопасность Pod Security Policies, network policies — +20% к времени развертывания
Когда Kubernetes оправдан:
50+ микросервисов
Непредсказуемая нагрузка
Команда из 3+ DevOps инженеров
Альтернативы для средних проектов:
Nomad — проще оркестратор без привязки к контейнерам
Docker Swarm — для простых сценариев
Managed k8s — если нет своей экспертизы
Вывод: Kubernetes — мощный инструмент, но не серебряная пуля. Прежде чем прыгать в эту экосистему, посчитайте TCO и убедитесь, что сложность управления не съест всю экономию от контейнеризации.
Записки параноика: почему Zero Trust — это не мода, а новая реальность для ИТ-инфраструктуры
Современные угрозы больше не останавливаются на периметре. Атаки стали целевыми, изощренными и часто исходят изнутри. Традиционный подход «замок и ров» безнадежно устарел.
Почему Zero Trust — это не просто buzzword:
68% компаний сталкивались с инцидентами внутренних угроз
Среднее время обнаружения нарушителя в сети — 207 дней
Традиционные VPN стали главным вектором атак в 2024
Как мы внедряли Zero Trust без переписывания всей инфраструктуры:
Post-Quantum Cryptography: тихая революция в инфраструктуре, которую нельзя игнорировать
Пока большинство обсуждает ИИ, в мире криптографии происходит настоящая революция. NIST утвердил первые стандарты постквантовой криптографии, и это потребует фундаментальных изменений в ИТ-инфраструктуре уже в ближайшие 2–3 года.
Проблема:
Современные алгоритмы (RSA, ECC) могут быть взломаны квантовыми компьютерами в обозримом будущем. Миграция на PQC — не вопрос «если», а вопрос «когда».
Что меняется:
Размер ключей увеличивается в 5-10 раз
Процессоры испытывают нагрузку на 30-50% выше
TLS-хендшейки становятся значительно объемнее
Наши тесты с OpenSSH 9.8:
bash
# Стандартный ключ Ed25519: 68 байт
# PQC-ключ Dilithium3: 1842 байта
# Рост трафика при подключении: ~2700%
Практические рекомендации:
Аудит инфраструктуры:
python
# Скрипт для поиска уязвимых сервисов
import ssl
for protocol in ['TLSv1.2', 'TLSv1.3']:
ctx = ssl.create_default_context()
ctx.set_ciphers(protocol)
Откладывание перехода на PQC аналогично игнорированию проблемы Y2K в 90-х. Уже сегодня нужно начинать тестирование и планирование, чтобы избежать хаотичной миграции под давлением регуляторов.
Уже проводили тесты с постквантовыми алгоритмами? Делитесь результатами в комментариях — соберем статистику по разным конфигурациям.
Привет, потенциал kui еще немного увеличился! Случилось то что случилось, в продской cronjoпеb'е что-то застряло. Добавил в kui ручной запуск кронжоб и kui'ем протолкнул застрявшее в кронжобе ...
Когда TLS 1.3 ломает мониторинг: тонкая настройка под новые протоколы
С переходом на TLS 1.3 многие системы мониторинга внезапно "ослепли". Старые методы перехвата трафика перестали работать, а бизнес требует полной видимости. Разбираем, как адаптировать мониторинг под современные стандарты безопасности.
Проблема:
eSNI и Encrypted Client Hello шифруют метаданные подключения
PFS (Perfect Forward Secrecy) делает историческую расшифровку трафика невозможной
70% инструментов мониторинга показывают "encrypted traffic" вместо полезных метрик
Решение через eBPF:
bash
# Вместо SSL-инспекции - анализ системных вызовов
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_connect {
printf("%s → %s:%d\n", comm, args->uservaddr, args->port);
}'
Наша реализация:
Мониторинг на уровне ядра - eBPF-программы для анализа сокетов
Анализ временных метрик - latency между SYN и ACK без расшифровки содержимого
Косвенные метрики - количество новых соединений, размер передаваемых данных
Снизили время диагностики проблем с подключением с 25 до 3 минут
Соответствуем требованиям GDPR и PCI DSS (без декриптации трафика)
Вывод: Современный мониторинг требует смещения фокуса с инспекции содержимого на анализ метаданных и поведенческих паттернов. Безопасность и наблюдательность больше не противоречат друг другу.
Grafana: когда красивые графики становятся рабочим инструментом
Все мы видели скриншоты дашбордов Grafana с красочными графиками. Но когда красивая визуализация становится реальным инструментом мониторинга, а не просто картинкой для отчёта?
Проблема типового подхода:
Собираем все метрики подряд — «на всякий случай»
Создаём дашборды с 20+ графиками, где невозможно найти нужную информацию
- HTTP-коды ответов (1xx, 2xx, 3xx, 4xx, 5xx)
- Latency: p50, p95, p99
- Rate of errors (> 5%)
- SLO: доступность за последний час
4. Интеграция логов и трейсов: Теперь не просто видим, что latency вырос, а сразу находим причину в логах конкретного микросервиса.
Реальные результаты:
Время диагностики инцидентов сократилось с 40 до 8 минут
Количество ложных алертов уменьшили в 5 раз
Единая система вместо 3 разных инструментов мониторинга
Ошибки, которых стоит избегать:
Не создавайте дашборды «для галочки»
Настройте meaningful алерты, а не «disk usage > 90%»
Используйте единый стек данных (метрики + логи + трейсы)
Вывод: Grafana — это не про красивые графики, а про единое информационное пространство для принятия решений. Когда каждый инженер видит одну и ту же картину — проблемы решаются в разы быстрее.
А какие подходы к мониторингу используете вы? Делитесь кейсами в комментариях!
Когда мониторинг слепнет: почему 90% алертов — это ложные срабатывания и как с этим жить
Системы мониторинга должны помогать, но вместо этого часто создают информационный шум. Когда на каждый чих приходит алерт, админы просто перестают на них реагировать. И тут случается реальная проблема.
Проблема ложных срабатываний
📊 15% нагрузки на Zabbix/Prometheus — сбор и обработка бесполезных метрик
⏰ До 3 часов в день senior-инженеры тратят на фильтрацию алертов
🔕 68% инженеров признаются, что пропускали важные уведомления из-за "алертной усталости"
Почему это происходит
Мониторим всё подряд — собираем метрики "на всякий случай"
Неправильные пороги — одинаковые thresholds для dev и prod
Отсутствие бизнес-логики — система не понимает контекст сбоя
Решение: умный мониторинг
# Вместо этого:
alert: CPU > 90%
# Мониторим так:
alert:
condition: CPU > 90%
and LoadAverage > 5
and duration > 5m
and business_impact = true
Что внедрили у себя
Сезонные пороги — разные thresholds в рабочее/нерабочее время
Корреляцию событий — не алертим о высокой нагрузке, если это время бэкапов
Бизнес-метрики — мониторим не "доступность сервера", а "доступность оплаты"
Результаты через 3 месяца
✅ Снизили количество алертов в 7 раз
✅ 98% срабатываний требуют реакции
✅ Время реакции на реальные инциденты сократилось с 25 до 8 минут
Вывод Мониторинг должен говорить, когда бизнес теряет деньги, а не когда у сервера чихнул процессор. Лучше 10 точных алертов, чем 1000 мусорных.
А как у вас с алертами? Тоже тонете в ложных срабатываниях?
О скрипте: быстрая и безопасная оценка экспозиции устройств Cisco IOS/IOS XE, связанная с CVE-2025-20352 (подсистема SNMP).
Сканируем подсети на SNMP через onesixtyone с дефолтными сообществами. Парсим баннеры sysDescr.0 Python-скриптом: помечаем Cisco IOS/IOS XE и проставляем статус Fixed (если в белом списке) или Potentially Vulnerable (проверить в Cisco Software Checker).
Проект не эксплуатирует уязвимость. Он лишь определяет устройства, отвечающие на дефолтные SNMP-сообщества, и извлекает версию из sysDescr.0.
Подборка обучающих материалов по Docker и Kubernetes
Привет, Хабр! Сегодня пятница, поэтому я снова со своей нерегулярной подборкой полезных материалов для начинающих специалистов. На этот раз несу статьи о Docker и Kubernetes. Как обычно: все бесплатно, без регистрации и смс. Читайте и практикуйте.
Первые шаги в Kubernetes
Здесь 12 статей примерно на два часа чтения. Будет полезно, если нужно освоить базу: что такое K8s, какие задачи помогает решить, основные понятия, с чего начать, как работать с контейнерами и настроить мониторинг.
Docker с нуля: как работают контейнеры и зачем они нужны
Эта подборка из шести статей — ваш гид в мир контейнеризации. Вы узнаете, что такое Docker, как запускать контейнеры, собирать образы и использовать Docker Compose, а еще разберетесь, чем эта технология отличается от Kubernetes. Все материалы подкреплены практическими примерами и будут понятны начинающим. На полное изучение уйдет менее двух часов.
Основы безопасности в Docker-контейнерах
Если вы прочитали предыдущую подборку и почувствовали в себе силы начать работу с контейнерами, не спешите. Изоляция, которую они обеспечивают, может вызывать ложное чувство безопасности. Чтобы вы могли погрузиться в вопросы защиты своего Docker, есть еще одна мини-подборка из трех исчерпывающих материалов. Изучение — чуть больше часа, а эффект — бесценен.
Приглашаем на Infra Meetup от Wildberries & Russ! Расскажем про внутреннее файловое хранилище собственной разработки, поговорим о методах автоматизации репозиториев в Nexus, разберём существующие сервисы и процедуры их сопровождения, обеспечивающие бесперебойную работу. И обязательно затронем важнейшую тему культуры инженерного взаимодействия в команде.
В программе:
Файловое хранилище Wildberries: бескомпромиссный HighLoad | Иван Волков, CTO CDN
Как устроено одно из важнейших файловых хранилищ Wildberries
1,2+ млн RPS на выдачу фото и видео — и это не предел
Код Оккама: органический подход к разработке и процессам
Путь автоматизации репозиториев в Nexus | Владислав Раев, DevOps & DevTools Engineer
Автоматизация без стандартизации, или путь в никуда
Что работает для 10, может сломаться на 100
Меньше состояния — меньше проблем
Явное лучше неявного
У вас завелся сервис: рекомендации лучших сервисоводов (наверное) | Александр Стовбунский, Tools Team TechLead
«Пап, можно мы его оставим?» — почему приносят одни, а чиним мы
«А выгуливать кто будет?» — что может требовать тот, у кого нет права отказаться
«Он большим не вырастет!» — как считать трудозатраты и сроки
Вредные советы: как гарантировано всё испортить
Для участия в офлайне она обязательна. После докладов — продуктивный нетворкинг и афтерпати.
Мы создали графический установщик, который превращает развёртывание Deckhouse Kubernetes Platform в несколько кликов и упрощает начало использования платформы через веб-интерфейс.
На вебинаре 25 сентября технический директор веб-интерфейсов Deckhouse покажет live-демо Installer:
Развернёт полноценный кластер Deckhouse Kubernetes Platform за 10 минут.
Включит виртуализацию ещё за 10 — и запустит Doom на виртуальной машине.
Расскажет, какие проблемы установки закрывает Installer.
Покажет планы развития графического установщика и где его взять.
Привет всем хабровцам! Мы регулярно публикуем посты о наших вакансиях, включая 1С и DevOps.
Полный и актуальный список вакансий здесь: https://spb.hh.ru/employer/5648224. Но откликаться на портале хх необязательно — внизу дадим прямые контакты с нашим HR.
Рабочие места в офисах в Москве (топ локация в ЦАО у Красной площади) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.
Вот примеры вакансий 1С и девопс — остальные 20 штук на см. на хх.ру:
Из сегодняшнего. Давно уже напрашивается MCP registry. Появился MCP реджистри. Не знаю, насколько аудитория погружена, поэтому если нет, то я подробнее распишу
Model Context Protocol (MCP) — это не классическое API, а новый слой взаимодействия между LLM и источниками данных: вместо того чтобы самому писать запросы, интеграции и «велосипеды», бизнес просто подключает MCP-серверы, которые находятся у провайдеров данных. Провайдер отвечает за подготовку промптов, функций, агрегацию источников и поддержку версий, а компания получает централизованный доступ к данным и готовым описаниям. Важно: MCP разводит зоны ответственности — финансы за работу LLM остаются у вас, а ответственность за качество данных и промптов несёт провайдер; таким образом, вы оптимизируете бюджеты, снижаете риски и можете гибко строить оркестрацию (через LangChain или свои пайплайны) без затрат на «ручные» интеграции с контролем версий отпровайдера
Раньше каждая команда или компания искала MCP-сервера вручную, через частные списки или разрозненные каталоги, что замедляло внедрение и поддержку клиентов. Теперь MCP Registry выступает единым «источником правды», где можно быстро находить, подключать и проверять сервера
Думаю, что ближайший год-два мы будем наблюдать, как наровне с публичными АПИ, будут появляться публичные MCP для интеграций. Что уж там, они есть уже у 1С даже, хотя там нюансы, конечно
LLamaSwap - гибкая альтернатива Ollama Ollama — прекрасное приложение, основанное на llama.cpp, которым я пользовался для инференса локальных моделей до недавних пор, однако у него есть несколько критических недостатков:
Отсутствие поддержки всех GPU и BLAS, доступных в llama.cpp. Для меня это стало проблемой после перехода на Radeon RX 6800: инференс через Vulkan на llama.cpp работает быстрее и стабильнее, чем ROCm, но Ollama не поддерживает Vulkan.
Отсутствие тонкой настройки. Например, на момент написания статьи в Ollama нельзя выгружать часть MoE-слоев на CPU, что позволяет сильно увеличить скорость инференса при нехватке VRAM для загрузки всех слоев на GPU.
Ollama использует собственное хранилище моделей, несмотря на то, что под капотом работает с GGUF. Если загрузить модель с Hugging Face, Ollama всё равно скопирует её в своё хранилище, а модели в наше время весят не мало и занимают лишнее место на SSD.
Функции доступные в llama.cpp появляются в ollama с задержкой , а иногда и вовсе не появляются.
Мне нужна была альтернатива, способная динамически управлять загрузкой моделей в памяти через API без моего участия, как это делает Ollama, но без вышеперечисленных недостатков. В итоге я остановил выбор на проекте llama-swap.
Llama-Swap — приложение на Go, которое запускает несколько инстансов llama-server и проксирует запросы к ним по заданным правилам.
Плюсы по сравнению с Ollama:
Полный доступ ко всем возможностям llama-server (например --override-tensor для выгрузки MoE слоев на CPU).
Поддержка большего количества GPU кскорений (таких как Vulkan или даже связки Vulkan + CUDA)
Возможность настроить отдельную версию llama-server для каждой модели (если в будущих обновлениях что то сломается).
Более гибкая настройка правил загрузки/выгрузки моделей в память: (одновременная загрузка, поочередная по запросам).
Не дублирует модели на диске (если используются форматы поддерживаемые llama.cpp).
Из коробки есть WebUI для управления загрузкой/выгрузкой моделей.
Минусы:
Из коробки не работает, требуется настройка через config.yaml и наличие рабочего llama-server.
Проект молодой, и его дальнейшая судьба пока не ясна.
Основные пункты файла конфигурации
Список моделей с указанием их расположения и параметров запуска (влючая путь к llama-server).
Группировка моделей, к группам применяются правила загруpки/выгрузки из памяти: - Все модели в группе загружены одновременно. - Модели загружаются по мере поступления запросов
Различные настройки прокси, порты, таймауты и пр.
У меня мини-ПК с интегрированной Radeon 780m, 32 ГБ ОЗУ и eGPU RX 6800. Я полностью перешел на Llama-Swap + OpenWebUI и всё больше отказываюсь от использования онлайн-сервисов вроде OpenRouter — ведь возможностей моего недорогого, по современным меркам ПК, хватает для запуска, таких моделей как Gemma3 30B и Qwen3-Coder-30B-A3B-Instruct. Думаю, в скором времени, когда ПК с объёмами памяти от 64 ГБ и выше станут ещё дешевле, интегрированная графика — мощнее и на рынке окажется множетсво БУ GPU с объемом VRAM 16ГБ и выше, часть людей, использующих LLM для своих задач, сможет полностью перейти на локальный инференс. Хотя это, возможно, это только моя фантазия. Всем спасибо за прочтение.
Успеть за пять дней: отклик — интервью — оффер за пять дней для инженеров по безопасности
Надежные продукты начинаются с безопасного кода. Команда безопасности следит за уязвимостями, укрепляет процессы и поддерживает CI/CD в форме. И мы в YADRO укрепляем команду — ищем специалистов на позиции Application Security Engineer и DevSecOps. Принимаем заявки до 28 сентября.
Это вакансия на позицию инженера по безопасности приложений, который поможет создавать устойчивые к атакам продукты и внедрять лучшие практики SSDLC на всех этапах разработки. В этой роли вы будете:
проводить триаж уязвимостей, найденных с помощью SAST, SCA, Secret Detection и других инструментов;
оценивать защищенность продуктов на основе моделей угроз и выполнять специализированные тесты (fuzzing, сканирование портов и др.);
исследовать новые векторы атак и участвовать в тестировании на проникновение;
разрабатывать PoC решений для функций безопасности;
участвовать в выборе и внедрении инструментов тестирования.
Подать заявку и узнать больше о вакансии можно по ссылке →
DevSecOps / Infrastructure Engineer
Присоединяйтесь к нам в роли инженера, который будет развивать практики DevSecOps, совершенствовать подходы к безопасности инфраструктуры разработки и CI/CD, а также помогать командам интегрировать проверки безопасности в процессы. В этой роли вы будете:
внедрять и развивать DevSecOps-практики;
выявлять и устранять угрозы в инфраструктуре продуктов и CI/CD-процессах,
проектировать и внедрять безопасную архитектуру CI/CD;
обеспечивать стабильную работу инструментов SAST/SCA/DAST и создавать Quality Gates;
автоматизировать процессы с помощью GitLab CI, Ansible, Helm;
ставить задачи командам по улучшению безопасности и контролировать их выполнение.
Изучение Python может показаться сложным, но с правильным подходом и пониманием ключевых аспектов процесс станет понятным и увлекательным. Привет, я Иван Чернов, senior system architect, кратко расскажу, как начать вкатываться в Python, с какими проблемами сталкиваются новички и как их преодолеть.
Первые шаги
Определяемся с направлением, в котором вы хотите развиваться. Это может быть веб-разработка, машинное обучение, DevOps и т. д. Каждое направление требует своих знаний и навыков. Поэтому важно понять, что конкретно вам интересно и на какой позиции не будет скучно или слишком сложно.
Начните с изучения базовых понятий, таких как переменные, типы данных, структуры данных и функции. Это заложит фундамент для дальнейшего изучения.
Когда определились с направлением и изучили теорию — проходите курсы с практическим обучением или начинайте работать с кодом сами. Всегда лучше писать, чем читать. Как только вывели “Hello, World!”, переходите к обучающим программам, где первые задачки применимы к жизни. Например, на некоторых курсах учат разрабатывать Telegram-бота под ваши нужды. Это отличная практика для понимания процессов.
Также можете прочитать базу «Питона» — книгу “Automated Boring Stuff with Python”. В ней много практических задач, которые помогут вам освоить язык. А ещё есть полезный курс “Learning How to Learn”, который учит, как правильно учиться, опираясь на достижения нейронауки.
Этап, на котором новички отваливаются
При более глубоком изучении «Питона» новичок столкнётся с первой проблемой — настройкой инфраструктуры. На этом этапе многое пугает: установка редакторов кода, интерпретаторов, пакетных менеджеров и прочее. Даже опытные программисты каждый день ищут подходящие инструменты и пытаются освоить новые.
Чтобы облегчить старт, можно для начала научиться использовать онлайн-среду разработки, например Replit. Можно просто зайти на сайт, выбрать язык Python и сразу приступать к написанию кода.
Replit — это сервис для вайб-кодинга. В нём можно быстро экспериментировать с задачами и сразу видеть результат. Так вы сконцентрируетесь именно на изучении языка, а не на технических сложностях.
Тут есть большое «но»: на вайб-кодинге далеко не уедешь. Использование онлайн-сред — это чит-код, который облегчает старт, но не учит решать реальные проблемы. Так что с комплексной инфраструктурой всё же придётся разобраться.
Концептуальные вопросы
Отдельно стоит отметить концептуальные вопросы, которые могут возникнуть на старте. Новички часто сталкиваются с трудностями в понимании таких понятий, как переменные и функции.
Например, в Python переменная может принимать разные значения, что противоречит математическим представлениям. Это может привести к путанице и неправильному пониманию основ программирования.
Важно понимать, что программирование — это не только про то, как писать код, но и о то, как мыслит как программист. Необходимо развивать критическое мышление и осознавать, что многие концепции, которые мы учили на уроках математики, могут быть неверными в программировании.
Советы начинающим питонщикам
Постоянная практика. Пишите код каждый день, хотя бы немного. Работайте над проектами, которые вас интересуют, и решайте проблемы, которые вас раздражают. Я в 2010-м хотел, чтобы дома лампочка включалась по голосу. С помощью Python удалось сделать это.
Изучайте чужой код. Чтение и понимание чужого кода поможет вам увидеть, как другие решают задачи и какие подходы используют. Однако не стоит изучать рандомный код. Лучше ищите тот, что поможет улучшить ваши проекты.
Go sport, go team. Физическая активность способствует лучшему усвоению информации. Поэтому не забывайте делать перерывы и заниматься спортом.
Заключение
Определитесь с направлением, изучите теорию, но не медлите с практикой. Не пугайтесь сложностей инфраструктуры: всегда можно нагуглить или спросить на форумах. Пользуйтесь онлайн-средами, но не делайте большую ставку на вайб-кодинг. Не бойтесь начинать и ошибаться — и у вас всё получится.
Наступает осень, а значит и высокий сезон в IT. У нас больше 20 вакансий в командах аналитиков, девопсов, QA и разработчиков. Полный и актуальный список вакансий здесь: https://spb.hh.ru/employer/5648224. Но откликаться на хх необязательно — внизу дадим прямые контакты с нашим HR.
Напомним, кто мы: компания SSP SOFT занимается заказной разработкой и IT-аутсорсингом. Наши спецы помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.
Рабочие места в офисах в Москве (топ локация в ЦАО) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.
Резюме на вакансии 1С, Elixir, Ruby, девопс и инфобез — рассмотрим в приоритетном порядке.
Data Scientist
DevOps-инженер
Data Scientist
DevOps-инженер
Сетевой инженер
Тестировщик 1C
QA Auto Java
Automation QA Engineer (Lead)
Elixir разработчик
Middle Java Developer
Ruby Developer
Jira Developer
С++ Developer (Senior)
Ведущий разработчик 1С (ERP, УХ)
Разработчик 1С (ЗУП)
Разработчик DWH
Аналитик DWH
Ведущий аналитик 1С ERP
Аналитик 1С (Управление недвижимостью и арендой)
Аналитик 1С (регламентированный учет)
Мы ценим сотрудников — работа без лишней бюрократии — акцент на задачи, которые приносят результат и развитие профессиональных навыков. 🎁 Наши бонусы: ДМС со стоматологией, обучение за счет компании, бонусная программа.
👉 В SSP SOFT мы рассматриваем найм с прицелом на долгосрочную совместную работу. Многие сотрудники у нас работают по 5 лет и более.
