Kurgan-Telecom Ru | Информационные технологии

Всем привет! Меня зовут Алексей, я техлид Android направления в компании Домклик.

На одном из собеседований зашла с кандидатом дискуссия об образовании. И была произнесена примерно такая фраза: «Зачем тратить 4–6 лет на обучение в вузе, если нужные по вашей вакансии навыки можно получить за год?» Пообщавшись ещё с некоторыми недавно вошедшими в отрасль знакомыми, сложилось впечатление, что этим вопросом задаются многие. И действительно, если, условно, на заводе требуется фрезеровщик, и у кандидата есть стаж работы или он окончил профильное училище, то какая разница, получал ли он высшее образование или нет?

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

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

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

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

Идея показалась мне настолько вдохновляющей, что я решил пойти дальше, а что если превратить эту консольную головоломку в настоящую игру с графикой и той самой атмосферой тумана войны, который так знаком игрокам в стратегиях

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

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

Меня зовут Ксюша Никульшина, и я исследователь B2B в Альфа-Банке в Alfa Research Center. Последние два с половиной года я наблюдала, как из прототипа концепции рождается новый продукт — «Альфа-Босс». И это не просто приложение, а инструмент для топ-менеджеров среднего бизнеса, у которого до нас не было аналогов.

​​За это время я провела множество исследований, проверила более 200 гипотез, выявила свыше 100 проблем и инсайтов. 

На момент написания статьи «Альфа-Босс» держит 75% retention. Пользователи возвращаются в приложение - и это лучший показатель того, что мы сделали что-то важное и нужное.

Что мы предложили пользователям? А что вырастил «Альфа-Босс» в исследователе?

Жизненный цикл программного обеспечения включает в себя множество этапов. Так в работе [1] выделяют активности по предпроектному обследованию, внедрению программного обеспечения и непосредственно пост-проекту имплементации. Этап поддержки и развития относится к пост-проекту внедрения и призван обеспечить непрерывное функционирование разработанной и запущенной в продуктивный режим работы программной системы. По большому счету, это именно тот результат, который изначально ожидается от реализации любого программного продукта: его постоянное и качественное функционирование для удовлетворения нужд пользователей и достижения стратегических целей предприятия.

Существует множество различных сводов знаний, применимых к комплексным программным системам: PMBoK для управления проектами, BABoK для бизнес-анализа, BPM CBOK для управления бизнес-процессам, EABoK для управления кооперативной архитектурой, а также SWEBoK по программной инженерии. Практически во всех сводах знаний делается акцент именно на внедрение и смежные активности, забывая про то, что имплементация программного продукта завершается его передачей в поддержку. Одним из немногих литературных источников по данной тематике является ITIL [2], описывающий четыре домена знаний, позволяющих осуществлять сопровождение решения после его реализации.

В контексте BABoK и расчета бизнес-кейса, выполняемого при предпроектном обследовании, довольно часто рассчитывается показатель TCO (Total Cost of Ownership, совокупная стоимость владения), демонстрирующий постоянные и переменные затраты, которые понесет компания при внедрении программного обеспечения. Одной из постоянных статей затрат является сумма поддержки и развития информационной системы. Таким образом, знание особенностей выполнения этапа поддержки и развития программной системы позволяет рационально планировать затраты и разумно ограничивать содержание проекта имплементации.

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

Прежде чем углубиться в детали, позвольте представиться. Меня зовут Анзар, я работаю фронтенд-разработчиком уже 9 лет, последние 3 из которых — в Ozon Tech, где я занимаю позицию тимлида. За это время я побывал на десятках, а может, и сотнях собеседований — и как кандидат, и как интервьюер. Кроме того, у меня за плечами многолетний опыт менторства и мне приходилось наблюдать, как различные факторы влияют на скорость роста. Все это заставило меня глубоко задуматься о системных проблемах найма разработчиков. Думаю, эта статья будет особенно полезна нанимающим менеджерам, рекрутерам и, возможно, HR-специалистам — она поможет пересмотреть подход к найму.

Привет, Хабра. Я — Вадим. Когда-то здесь рассказывал, как делал WhammyD — педальки-контроллеры для Digitech Whammy. Это была весёлая история, но закончилась она остановкой проекта, потому что устройства были, прямо скажем, мало кому нужны.

В этой статье расскажу про новый проект — Neko. Это гаджет, чтобы каждый человек мог кайфануть от игры на гитаре, реализовать свои музыкальные идеи и почувствовать себя музыкантом, даже если на это остаётся 15 минут после рабочего дня.

Лайфхаки для миграций, оптимизации и избегания граблей

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

• Не сломать прод при миграции.
• Избежать N+1 и других проблем SQL-запросов.
• Планировать откаты и работать безопасно на высоконагруженных БД.

Как торговать, если люди покупают импульсивно, а интернет-магазинам предпочитают агрегаторов? Как подстроиться под жесткий сезонный спрос и повышать рентабельность рекламы? Интернет-магазин воздушных шаров сместил фокус на срочный Поиск и сезонное жонглирование товарами. А когда отключили мобильный интернет и заказы обрушились, завоевал ТОП на выдаче. Заявки увеличили в 1,7 раз, ДРР снизили в 1,5 раза.

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

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

Система автоматизации квартиры управляет климатом, освещением и шторами. Мы получили от Константина, ее владельца, обратную связь после нескольких лет эксплуатации. И ею мы хотим поделиться.

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

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

Сегодня сложно представить технологическую компанию, которая бы всерьёз занималась разработкой и не использовала инженерные расчёты. CFD-, FEA-, тепловые, а также одномерные (1D) симуляции давно стали повседневными инструментами.

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

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

Если расчёты – это актив, то ими нужно активно управлять. Расскажу, как подойти к этому шаг за шагом.

Те, кто имел дело с покупкой и продажей недвижимости, знает, что просмотры — очень хлопотное занятие. Неудивительно, что для экономии времени появляются предложения посмотреть квартиру онлайн или с помощью 3D‑тура. О таких виртуальных экскурсиях мы сегодня и поговорим.

В сентябре Яндекс Недвижимость рассказала о 3D‑турах для новостроек. С момента начала тестирования в июле на сервисе было сгенерировано более четверти миллиона виртуальных экскурсий по строящимся квартирам. Чтобы это стало возможным, мы обучили нейросеть анализировать планировки и превращать их в трёхмерные визуализации. Но чтобы это стало возможным, нужно было проделать большую и кропотливую работу, чтобы нейросеть понимала, где отрисовывать окно или класть плитку на пол.

Меня зовут Катя Шибанова, я работаю архитектором краудсорсинговых решений (CSA) в службе разметки данных Yandex Crowd Solutions. Недавно к нам обратились коллеги из Яндекс Недвижимости: нужно было помочь с разметкой для обучения модели компьютерного зрения, которую используют для создания 3D‑туров. Об этом интересном проекте и будет мой рассказ. Я расскажу, чем опасны миллиметровые зазоры между полигонами в разметке, почему помимо типов помещений (кухня, спальня, санузел и тому подобное) нужно размечать структурно важные элементы — двери, окна, несущие стены, а также почему приоритизация геометрической согласованности важнее «средней» точности по пикселям.

В «Экспресс 42» — подразделении «Фланта», которое консультирует компании по DevOps-практикам, — решили проверить, как можно реализовать GitOps по модели BSA (Base, Service, Application) с помощью Argo CD. Чистый эксперимент на тестовом репозитории.

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

Привет, Хабр! Я — Алексей Григорьев, лид iOS-разработки продуктов Future Crew в MWS. Наша команда со стартап-вайбом: технологий свежих много, стек обновляется часто, требования к скорости внедрения — высокие. Нужны мотивированные сотрудники, но нет времени и сил искать готовых сеньоров. Поэтому мы ставим на рост внутри команды. Не просто не боимся брать стажеров и джунов — нам даже это интересно. От первого лица почитать историю о том, как мы вырастили джуна до мидла за год, можно тут. 

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

Прошлая статья про типизацию сотрудников по Герчикову «Ради чего люди ходят на работу» собрала 100+ комментариев — и оттуда напросилась тема для продолжения: как расставлять людей в команде, зная их ведущие мотивации?
 
 Краткое содержание прошлого сабжа: в первую очередь от работы нам, понятно, нужны деньги, но не только, каждому важно ещё что-то своё — и если знать, что это, то мы будем лучше понимать других людей, а менеджеры смогут избежать типичных ошибок.
 
 Теперь представьте, что вы делаете бизнес в ИТ или формируете команду в корпорате. Вам нужно расставить сотрудников по ролям, исходя из их ведущих мотиваций. Как мы уже знаем из первой статьи (в этой тоже напомним этот лор), инструментал любит чёткие инструкции и понятные KPI, профессионал — нестандартные вызовы и возможность делать новое, хозяину важно распоряжаться своим участком, патриоту — быть частью чего-то большего, ну а избегающему — тихо сидеть на окладе с минимальной ответственностью. Давайте разберём на двух примерах (стартап и корпорат) возможные правильные и неправильные расстановки. Спойлер: это не всегда очевидно. Поехали.

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

Начинали мы с нуля, с эскизов. Задача была реализовать систему, обладающую следующими функциональными и техническими требованиями:

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

В 2017 году объект TXS 0506+056 (блазар расположенный на небе недалеко от левого плеча созвездия Ориона) стал первым активным галактическим ядром, который был уверенно идентифицирован как источник экстремально высокоэнергетического нейтрино (IceCube-170922A). Архивные данные IceCube также показали усиление нейтринной активности из этого же региона в 2014–2015 годах. В 2021 и 2022 годах нейтрино вновь были зафиксированы детекторами Baikal-GVD и IceCube, что сделало TXS 0506+056 одним из главных кандидатов на роль источника астрофизических нейтрино. Одновременно с этим радиоастрономические наблюдения выявили необычные изменения в морфологии джета этого блазара. Радиоизображения, полученные при помощи сети радиотелескопов VLBA  (Very Long Baseline Array), демонстрировали сложную и неожиданную структуру джета на парсековых масштабах.

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

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

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

Задачи были такие: 1) проехать по известному «лабиринту» из двух комнат с фиксированными препятствиями, то есть запрограммировать фиксированный маршрут — кое‑кто бился над этим неделю и больше — но всё же решений около сотни; 2) проехать неизвестный лабиринт из стенок под прямыми углами — с этим справились вчетверо меньше команд; 3) проехать по змеевидной платформе, используя камеру глубины, и не упасть за край — мне известно примерно о двух с половиной решениях её.

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

Говоря о серьезных кластерах в компаниях, нам часто приходится взаимодействовать со сторонними отделами и их данными. И зачастую, когда речь идет об ad-hoc, самый эффективный инструмент - Trino. Он удобен тем, что в платформе данных можно добавить каталог, который позволит по сути избежать настройки коннекшена для конечного пользователя. Просто в запросе указываешь название каталога данных и трино сам понимает, что нужно взять данные со сторонней базы данных. Но все меняется, когда выразительности SQL нам перестает хватать для выполнения поставленных задач и мы переходим в Spark. Точнее, менялось. С релизом Spark 3.0 появилась возможность взаимодействовать с внешними источниками так же просто, как в Trino.