Внезапное молчание

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

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

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

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

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

Я даже предположил, что Elm MVU — это тот путь, который данные потребности закроет.

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

Под словом «естественный» я подразумеваю нечто, что коррелирует с языком, который мы используем в повседневной жизни. Функциональное программирование не всегда можно описать таким языком (например, несмотря на то, что монады, включая Observable streams, являются относительно простым понятием, мы вряд ли сможем выразить это понятие на таком языке). Я убедился, что программирование, которое лучше коррелирует с естественным языком — это многопарадигменное программирование, где вещи не строго OOP и не строго функциональны, а то или другое в зависимости от ясности и удобства работы.

После тестирования NVME over TCP, описанной тут https://habr.com/ru/companies/beeline_tech/articles/770174/, решили проверить, насколько хорошо iScsi в L3-сети работает по сравнение со специализированным решение на FC.

Настройки iScsi

TL/DR

Машина в Bios переведена на профиль HPC (был пустой).

На уровне OS и iscsid сделаны такие изменения

Всем привет!

Рады анонсировать начало нашего большого спецпроекта «SM Lab в лицах» о людях, которые работают в SM Lab. Мы хотим показать их не только как высококлассных профессионалов в IT, но и как творческих, интересных личностей, которые умело совмещают работу с разнообразными увлечениями. Из этого спецпроекта вы узнаете каково восстанавливать ретроавтомобиль,как работает мультиинструменталист, побываете в шкуре фотографа, познакомитесь с каргобайкерством и многое другое)

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

Следите за нашими обновлениями и вдохновляйтесь историями наших work-life balance героев! А начнем мы наш спецпроект с ретроавтомобилей. 

Привет. Меня зовут Николай Шувалов, я занимаюсь коммерческим программированием около семи лет, владею Rust, JavaScript, PHP. Сейчас я работаю в отделе данных билайна. Наша платформа позволяет делиться с партнерами данными, не раскрывая их. Например, можно расширить данные с помощью фильтра Блума. 

Arrow в сравнении со строковыми форматами

Возьмём простую таблицу, которая состоит из трех столбцов: телефона, даты и имени. Рассмотрим, как она будет выглядеть в строковом и столбчатом форматах. Для строкового формата мы возьмем csv и json, для столбчатого формата структура будет одинаковой. Если же таблица состоит, например, из миллиона строк, а нужно получить имя на строке с номером 10 000, то придется бежать по всей строчке. В json то же самое. А в столбчатом формате ситуация иная — значения привязаны к столбцам. Когда мы хотим получить имя на строке 10 000, то сразу обращаемся к этому столбцу и получаем все его данные. 

Существуют RA (random access) файлы, в которых можно пропускать заданное количество строк, но все равно парсеру нужно читать и анализировать пройденные строчки.

Всем добрый день!

Меня зовут Иван Хахарев и я работаю ведущим системным аналитиком в команде WEB Campaign, это внутренняя разработка Спортмастера для формирования маркетинговых логических цепочек. Я в команде уже полгода, и на момент моего прихода ребята уже почти год двигались к веб-версии. В команде на текущий момент семь человек, трое из которых — разработчики. 

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

Привет, Хабр! Меня зовут Сергей Евсеев, сегодня я расскажу, как в Apache NiFi настраивается ETL-пайплайн на задаче с JSON’ами. В этом мне помогут инструменты Jolt и Avro. Пост пригодится новичкам и тем, кто выбирает инструмент для решения схожей задачи.

Что делает наша команда

Команда работает с данными по рекрутингу — с любой аналитикой, которая необходима персоналу подбора сотрудников. У нас есть различные внешние или внутренние источники, из которых с помощью NiFi или Apache Spark мы забираем данные и складируем к себе в хранилище (по умолчанию Hive, но есть еще PostgreSQL и ClickHouse). Этими же инструментами мы можем брать данные из хранилищ, создавать витрины и складывать обратно, предоставлять данные внутренним клиентам или делать дашборды и давать визуализацию.

Описание задачи

У нас есть внешний сервис, на котором рекрутеры работают с подбором. Сервис может отдавать данные через свою API, а мы эти данные можем загружать и складировать в хранилище. После загрузки у нас появляется возможность отдавать данные другим командам или работать с ними самим. Итак, пришла задача — нужно загрузить через API наши данные. Дали документацию для загрузки, поехали. Идем в NiFi, создаем пайплайн для запросов к API, их трансформации и складывания в Hive. Пайплайн начинает падать, приходится посидеть, почитать документацию. Чего-то не хватает, JSON-ы идут не те, возникают сложности, которые нужно разобрать и решить.

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

Мы решили просто загружать все подряд — на месте разберемся, что нам нужно и как мы это будем грузить, потом пойдем к источникам с конкретными вопросами. Так как каждый метод API отдает свой класс данных в виде JSON, в котором содержится массив объектов этого класса, нужно построить много таких пайплайнов с обработкой разного типа JSON’ов. Еще одна сложность — объекты внутри одного и того же класса могут отличаться по набору полей и их содержимому. Это зависит от того, как, например, сотрудники подбора заполнят информацию о вакансии на этом сервисе. Этот API работает без версий, поэтому в случае добавления новых полей информацию о них мы получим только либо из данных, либо в процессе коммуникации.

По каждому из направлений в ИТ есть свои так называемые «приколы» и особенности в части поиска и обучения сотрудников, взаимодействия с софтом, заказчиками и так далее. В моей области, то есть в области информационной безопасности, все еще обсуждают такой вопрос: «Должен ли безопасник расти из программиста?». Имея 25+ лет в области ИТ и ИБ ответственно заявляю — должен. Для меня это не вопрос, но многие со мной не согласятся. Сегодня раскрою свою позицию и объясню, почему безопасникам жизненно необходимо быть программистами.

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

Всем привет! Делюсь очередным выпуском нашей рубрики «Открытый микрофон», тема этого выпуска — «Как написать свою первую спецификацию на REST API».

Спикером стала Мария Яковлева. Маша — ведущий аналитик Платформы Сфера, НОТА (Т1 Консалтинг). В интернете много описаний особенностей архитектурного стиля REST, но мало информации о том, как аналитику начать создавать качественные спецификации на REST-методы. Маша поделилась своим опытом и, что особенно ценно, ошибками, допущенными в работе. А ещё Маша систематизировала их, чтобы уберечь вас от них)

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

Привет, Хабр!

Меня зовут Тоня. В SM Lab я работаю старшим инженером по обеспечению качества в команде продукта Интра — занимаюсь ручным тестированием и написанием автотестов на Kotlin. В этой небольшой статье хочу рассказать, как я искала работу и проходила собеседования через One Day Offer. Под катом — муки выбора инструмента для поиска работы, этапы прохождения собеседования за один день, трудности, с которыми столкнулась, и причины, по которым выбрала SM Lab и не прогадала.

Шаг первый: где сейчас искать работу

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

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

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

Привет, Хабр!

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

Давайте представим, что у вас в компании большое количество моделей машинного обучения, каждая из которой может зависеть от нескольких десятков до нескольких тысяч признаков (фич). Причем разные модели могут зависеть от одних и тех же фич. Неожиданно случается несчастье, и одна из популярных фич ломается. Может произойти поломка на уровне подготовки данных, могут измениться внешние источники, отвалиться интеграции и прочее. Что делать с этим знанием? Конечно, бежать в продуктовые команды и кричать, что модели, которые зависят от этой фичи, могут деградировать, то есть их метрики качества могут снизиться. Вопрос только в том, какие модели могут деградировать и в какие команды бежать?

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

В рамках серии материалов о различных старинных счетных устройствах мы уже познакомились со сложными механизмами, в основном предназначенными для сложения чисел. Операции умножения во всех случаях требовали выполнения ряда сложных действий, но в одном из устройств (Считающие часы Вильгельма Шиккарда) этот процесс был упрощен благодаря устройству под названием «Палочки Непера» или «Кости Непера», которые в XVII веке изобрел шотландский математик Джон Непер. Сегодня мы уделим им особое внимание, а также поговорим про «Шпаргалку» — еще одно устройство Непера для облегчения расчетов.

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

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

Публикую расшифровку доклада и саму запись трансляции.

Также по теме мы подобрали экспертов, которые поделились своей экспертизой и мнением, их комментарии - ниже по тексту. 

Привет! Меня зовут Андрей Чучалов, я работаю в билайне, и в этом посте я расскажу про оптимизацию параметров запуска приложений в Spark, поиск проблем и повышение производительности. Разберем запуск приложений Spark в базовой и расширенной версиях, покажу методы расчёта основных параметров работы приложения для производительности и эффективности использования доступных ресурсов кластера. Бонусом — о том, как всё это привязано к деньгам, и где сэкономить можно, а где — не стоит.

Для чего это вообще нужно

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

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

Почему ты захотела стать программистом?