Команда архитекторов ЛАНИТ активно проводит у себя тематические встречи, чтобы сотрудники могли прокачивать экспертизу и делиться опытом с коллегами из других компаний.

В этот раз мы замахнулись еще круче и под одной крышей решили собрать более 300 специалистов и экспертов по ИТ-архитектуре на четырехдневную конференцию «(ИТ-) архитектор в ИТ-проектах и организациях».

О том, как это было и что обсуждали, читайте в этой статье.

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

В этой статье я делюсь своим видением воронки найма и предлагаю свои рекомендации для более эффективного найма.

Найм IT-специалистов – это непростая задача. Во-первых, сейчас на рынке наблюдается дефицит опытных кадров, они это понимают. Кандидаты часто не готовы тратить много времени на «отборочные мероприятия» работодателя, если их предварительно не заинтересовать. Ранее популярная практика «дадим тестовое на 8+ часов» сейчас уже не работает. Для первичной оценки знаний и отсева кандидатов до проведения полномасштабного технического собеседования приходится использовать другие, более быстрые способы. Во-вторых, для качественной оценки знаний и навыков необходимо самому обладать такими навыками или привлекать коллегу, обладающего такими навыками. Эти затруднения можно решить при помощи способов, о которых я расскажу в этой статье. Я сам применяю эти способы и составил для себя своего рода рейтинг.

Итак, мой топ-7 способов быстрой проверки компетенций IT-специалистов до собеседования:

7. Изучить портфолио, примеры кода, открытые репозитории кандидата.

6. Короткое тестовое задание на время (выполняется за 30-60 минут).

5. Короткое экспресс-собеседование про навыки по телефону/скайпу (как опросник, только онлайн и голосом).

4. Live-Doing (Coding) – решаем простую задачку в реальном времени с расшаренным экраном.

3. Опросники с открытыми вопросами про опыт.

2. Короткие тесты с вариантами ответов, ограниченные по времени прохождения.

1. Многоэтапное тестовое задание, первый этап выполняется до собеседования.

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

Обсуждение операторов сотовой связи в Телеграм t.me/opsosru

Уже давно как не смешные анекдоты ходят истории о платных мобильных подписках на IoT устройствах.


С Пикабу

Всем понятно, что без действий сотовых операторов эти подписки не обходятся.

Меня зовут Саша, и я руковожу backend-разработкой в Tutu.ru. Сегодня я расскажу, почему и как мы полностью поменяли процесс собеседования кандидатов за прошедший 2018 год.

Итак, диспозиция на начало года

• Мы быстро растем – нам нужно набирать новых сотрудников
• Сообщество разработчиков о нас думает примерно «Ну это сайт с расписанием электричек – там наверно 3 человека работает в подвале». На самом деле у нас сейчас 7 бизнес-направлений и два десятка команд, которые над ними трудятся.
  
  
  Кстати, немного об электричках

  Кстати, в команде Электричек 7 разработчиков, а еще там высоконагруженные микросервисы, которые мы начали переписывать на go
• На собеседовании мы задаем логические задачи, задачи по синтаксису php, ООП и базам данных

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

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

Сфера применения

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

Объектно-ориентированная парадигма — стандарт для прикладного ПО. Реляционные СУБД — стандарт хранения данных в прикладном ПО. Да, можно писать и на Haskell и хранить данные исключительно в ClickHouse. Но речь о мейнстриме.

ORM позволяет натянуть сову на глобус сделать вид, что RDBMS'а нет и данные хранятся в объектной модели, более подходящей для ООП. Остается «маленькая» такая проблемка — эта абстракция, как и многие другие, «течет». Там где в объектной модели ссылка на другой объект в базе данных foreign key и id. В момент материализации сущности мы встаем перед выбором:

1. Загрузить все и упасть с out of memory / timeout
2. Явно указать какие зависимости мы хотим загрузить, а какие — нет и нарушить принцип tell don't ask
3. Загружать зависимости неявно по требованию с помощью Lazy Load и получить проблемы с производительностью где-то в вызываемом коде

Какую-же ногу себе отрезать: левую или правую?

TLDR Lazy Load не так плох, если использовать только для записи и не использовать при чтении. Но все не так просто и есть куча нюансов.

Краткое знакомство с kubernetes для разработчиков на примере разворачивания простого шаблонного сайта, с постановкой его на мониторинг, выполнением джобов по расписанию и health checks (все исходники прилагаются)

— Установка Kubernetes
— Установка UI
— Запуск своего приложения в кластере
— Добавление кастомных метрик в приложение
— Сбор метрик через Prometheus
— Отображение метрик в Grafana
— Выполнение задач по расписанию
— Отказоустойчивость
— Выводы
— Заметки
— Список литературы

Пролог

— Ты, главное, не ссы! Держись меня, делай как я, и все будет чики-пуки.

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

— Коль, давай посерьезнее. — Жанна строго посмотрела на круглую самодовольную рожу. Потом перевела взгляд на новенького. — Сергей, не слушай этого старого коня. Борозды он, конечно, не испортит, но и целины не поднимет.

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

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

Сергей понимающе покивал головой. Он не знал, кто такой Кови, но метафору понял.

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

— Спасибо, Жанна Ивановна. Я буду стараться.

— Никакого отчества, просто Жанна! Велкам в нашу команду, Сережа!

Привет, Хабр! Сегодня для .NET-разработчиков у нас традиционный пост по следам DotNext 2018 Moscow: делимся десятью лучшими докладами конференции (по мнению её посетителей). Под катом — их видеозаписи, а также короткие описания и ссылки на презентации.

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

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

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

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

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

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

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

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

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

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

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

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

Встречали ли вы в C# конструкцию типа using (var scope = new TransactionScope(TransactionScopeOption.Required))? Это значит, что код, выполняющийся в блоке using, заключается в транзакцию и после выхода из этого блока изменения будут зафиксированы или отменены. Звучит понятно, пока не начинаешь копать глубже. И чем глубже копаешь, тем «страньше и страньше» становится. Во всяком случае, у меня при более близком знакомстве с классом TransactionScope и вообще транзакциями .NET возникла целая уйма вопросов.

Что за класс TransactionScope? Как только мы используем конструкцию using (var scope = new TransactionScope()), все в нашей программе сразу становится транзакционным? Что такое «управляющий ресурсами» (Resource Manager) и «управляющий транзакциями» (Transaction Manager)? Можно ли написать свой управляющий ресурсами и как он «подключается» к созданному экземпляру TransactionScope? Что такое распределенная транзакция и правда ли, что распределенная транзакция в SQL Server или Oracle Database — это то же самое, что и распределенная транзакция .NET?

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

Нередко слышишь мнение, что составление Технического задания по ГОСТ 34 (ТЗ) занятие не только трудоемкое, но и крайне раздражающее, поскольку приходится писать много всякой ерунды, воды. Но подумайте: разработкой этого ГОСТа занимались целые НИИ, это был проект на государственном уровне, обобщен опыт сотен проектов автоматизации, сложных проектов. Неужели они могли написать чушь?

На самом деле, при грамотном подходе ГОСТ очень сильно помогает не только при разработке ТЗ, но и в ходе реализации проекта автоматизации в целом (и не только в госконтрактах, но и для коммерческой разработки). Грамотные люди его писали. Но чтобы воспользоваться плодами их трудов, нужно немного понять замысел не только ТЗ, но и ГОСТ 34 в целом.

В данной статье мы пункт за пунктом разберем все требования ГОСТа и попробуем сделать разработку ТЗ по ГОСТ 34 не обременением, а большой помощью в проекте.

5 сентября в Москве состоялся Круглый стол «Архитектор ИТ проекта» в ВШЭ. Организатор круглого стола, Максим Смирнов, ведет блог про архитектуру и канал на Facebook.

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

На круглом столе было представлено 4 доклада по 15-20 минут, после чего были вопросы из аудитории и обсуждение.

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

Это была славная охота.

Моя жизнь была посвящена ИТ-сфере. Я был инженером, создававшим интересные продукты для больших промышленных компаний. Моей географией была вся Россия, я вживую видел цеха КАМАЗа, ВАЗа и других автогигантов. Но всему в нашей судьбе настаёт предел, и я выгорел. О причинах расскажу как-нибудь в другой раз. Главное, что я, опытный разработчик и техник, ушёл на вольные хлеба и, поскольку у меня появилась семья, решил сделать бизнес — свой магазин товаров для детей, по особым принципам. В общем, как многие из программеров, сделать то, чего не достаёт мне среди предложений на рынке. И знаете, что? Я выяснил, что найти простейших, базовых, нужных профессионалов-подрядчиков очень сложно. Миллион фрилансеров и фирм, а выхлоп… Это был квест, и о нём я должен поведать миру. Не ходите по моим граблям.


Это самое лучшее, что описало моё состояние

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

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

В этой статье мы расскажем, как адаптируем и применяем стек ELK на Java и .Net-проектах и находим ошибки в онлайн режиме без вскрытия или малоинвазивными методами. Да, мы разобрались и поняли, что не очень важно, Microsoft ли сделал это решение или Open Source — всё одинаково можно настроить под свои нужды.

В рамках недавно прошедшей конференции DotNext 2018 состоялся BoF по Domain Driven Design. На нем был затронут вопрос работы с исключениями, который вызвал жаркий спор, но не получил развернутой дискуссии, поскольку не являлся основной темой.

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

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

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

Кто-то делает валидацию на исключениях, а кто-то повсеместно использует монаду Result. Справедливо, что Result позволяет по сигнатуре метода понять, возможно ли не только успешное выполнение. Но не менее справедливо, что в императивных языках (к которым относится C#) повсеместное использование Result приводит к плохо читаемому коду, засыпанному конструкциями языка настолько, что с трудом можно разглядеть исходный сценарий.

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

Речь пойдет об enterprise-приложении, построенном на базе ASP.NET MVC+WebAPI. Приложение построено по луковой архитектуре, общается с базой данных и брокером сообщений. Используется структурированное логирование в ELK-стек и настроен мониторинг при помощи Grafana.

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

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

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

Поделиться своим опытом мы решили неспроста: неприятные кейсы от коллег по отрасли и самостоятельно набитые шишки подсказывают, что эта тема — больная для многих (причём, не только в IT). Читайте в материале, какую структуру договора выбрать при работе по SCRUM (и почему), а главное — как отстоять её у юристов заказчика. Лайфхаки при согласовании, 5 правил предосторожности, пара реальных историй, а также процесс документооборота в студии Сибирикс изнутри — здесь.