Привет! У нас тут накопился неплохой опыт в плане работы с конференциями со всех точек зрения — как организатора своих собственных событий, так и активного участия в больших регулярных IT-конференций. Собственно, им мы с вами и поделимся.

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

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

Вдруг нам всем вместе получится сделать мир отечественных IT-событий немного лучше.

Всем привет. Меня зовут Тирайр, я ведущий процессный аналитик в Спортмастер Лаб и менеджер проекта Со-Общество - базы знаний в Telegram, которая регулярно наполняется полезными материалами из области бизнес-анализа, цифровых технологий и менеджмента.

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

Это вторая статья из цикла. В первой части я рассказывал про самые базовые понятия Elasticsearch. В этом же посте разберем устройство анализа текста и немного пощупаем полнотекстовый поиск.

Несколько слов про анализ текста

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

Мы уже познакомились с некоторыми типами Elasticsearch, но в этом разделе будем рассматривать только два — keyword и text. Тип text анализируется для полнотекстового поиска. Тип keyword преимущественно остается без изменений для точного поиска, сортировки и агрегации.

Habr, привет! Меня зовут Евгений Федосеев. Я выполняю роль лидера BI-команды в рамках Data Office в крупном FMCG и отвечаю за развитие направления Self-Service BI. Но в этой статье я решил не говорить снова о данных, а хочу вместе с вами окунуться немного в мир личной эффективности. 

Поговорим о GTD. Наверняка многие слышали эту аббревиатуру. Скорее всего, кто-то даже уже пользуется этим подходом или применяет его практики неосознанно. Разберёмся вместе: для чего нужны эти заветные три буквы, как с помощью них организовать свою повседневную работу и повысить личную продуктивность. Кратко о чём поговорим в этой статье:

• разберёмся, что же такое GTD, кому он нужен, а кому точно не подойдёт;

• рассмотрим ключевые концепты системы или, можно сказать, подхода GTD;

• после теории расскажу вам о том, как я использую GTD в рамках работы с простым MS Outlook, и поделюсь приложениями для личной эффективности;

• в конце, по традиции, подведём итоги ?

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

В этом посте мы поговорим о том, как формат сообществ (чаптеров) помогает нам в работе. Для этого мы подробно побеседовали с Михаилом Благовым, лидером чаптера инженеров данных. Еще нам помогали Николай Безносов (чаптер Data Science) и Артём Смирнов (Data Analytics).

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

Перед менеджером продукта часто возникает потребность в оценке задачи до передачи ее в работу, то есть до проектирования с командой и декомпозиции. Например, от стоимости будущей разработки зависит решение о приоритизации таски (RISE, Value vs. Effort и прочее).

Я занималась разработкой и внедрением рекомендаций к оценке эпиков для product lead-ов (далее — PL) в Спортмастер Лаб и хочу поделиться выводами:

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

Поясню :)

Привет! Продолжаем цикл статей про тестирование не-REST-бэкенда, в прошлый раз мы говорили о GraphQL, теперь пришло время WebSocket.

Итак, что такое WebSocket?

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

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

Работу по WebSocket в обычной жизни можно представить примерно так.

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

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

ОК, что вам делать в такой ситуации?

Привет! Меня зовут Сергей Птушкин, в этом посте я поделюсь с вами нашим чеклистом для оперативного и безболезненного переезда в Kubernetes. У SM Lab очень много разных продуктов, а как следствие — разных команд разработчиков и администраторов. У всех своя архитектура, стек, любимые языки программирования, SLA и требования по нагрузке.

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

Итак, давайте разберем на примере нашей ситуации. Мы переезжали в Kubernetes из Mesos и Oracle Weblogic и знали, что разработчики тестируют приложения при помощи docker-compose или локально на станциях. Нам нужно было придумать единый подход для следующих возможностей:

Привет! 

Меня зовут Александр Маркачев, я 3,5 года работаю на позиции Data Engineer в билайне и люблю открывать для себя что-то новое и интересное в работе. Так случилось и с темой, которой я сегодня хочу с вами поделиться — со spill-ами.

Под катом мы поговорим о том, что такое Spill-ы в контексте Spark, и почему именно для Spark это не такая уж сильно плохая штука. Рассмотрим, из-за чего Spill-ы в принципе возникают, разберем несколько видов Spill-ов (и даже вызовем их намеренно), а затем будем решать эту проблему.

Что такое spill-ы в Spark

Вообще, Spill — это термин для обозначения процесса перемещения данных из памяти на диск, а затем снова обратно в память. По крайней мере, именно так гласит официальная трактовка. Если проще, то дело вот в чем — когда у Spark не хватает ресурсов для обработки, он перемещает данные на диск.

В процессе обработки существуют разные участки — есть Executor Memory, есть Storage Memory, и когда эти участки оба целиком заполнены, то они начинают переполняться и вызывать утечку данных. Причем в отличие от утечки в C, Java или еще где-то, в Spark это преднамеренное действие для того, чтобы ваша задача не падала. Собственно, именно поэтому при нехватке ресурсов данные и «проливаются».

Можно ещё сильнее упростить аналогию.

Продолжаем разбор вопросов из Java-сертификации от Учебного центра IBS вместе с Игорем Судакевичем, сертифицированным Java-разработчиком, уполномоченным инструктором корпорации Oracle и платформы Udemy, Java-методистом c 15-летним опытом. В этой статье мы рассмотрим применение Threads и Executors и поможем вам подготовиться к тестированию.

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

Привет! Сегодня поговорим о разных способах организации хранения исторических данных в Oracle. Если вам известно более двух способов, то вы молодец и уже почти всё знаете, в чём вам и остаётся убедиться, просмотрев разделы статьи. 

ООП используется уже давно, оно применяется в большинстве программ. Но всегда ли ООП является правильным путём? Далеко нет.

Что такое ООП?

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

1. Сокрытие подробностей реализации

Благодаря использованию слоёв абстракций мы можем обеспечить приватность работы внутреннего устройства ПО. Абстрагирование помогает с безопасностью и удобством использования, так как другие разработчики не знают (и не должны знать) внутреннюю реализацию вашего ПО.

2. Разъединённые компоненты

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

• Отдавайте предпочтение полиморфизму, а не «if/else» и «switch»
• Код не должен знать о внутреннем устройстве объектов, с которыми он работает
• Функции должны быть маленькими
• Каждая функция должна выполнять одну задачу
• Принцип «DRY» — Don’t Repeat Yourself («не повторяйся»)

В 2022 году мы запустили новое мобильное приложение для iOS и Android, встроив в него дополнительные сервисы: «Медиа», «Трекер активности», «Live-трансляции», «Онлайн-тренировки» и другие. Они закрывают потребности наших клиентов, не связанные с покупками. Например, помогают следить за спортивными новостями, поддерживать физическую активность и быть частью сообщества единомышленников.

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

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

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

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

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

Привет! Недавно у нас в компании завершилось RnD по микрофронтендам, мы посмотрели подходы, протестировали некоторые идеи, и хотим поделиться с вами результатами. Если вы сейчас выбираете подход для использования микросервисов на фронтенде, этот пост может вам пригодиться как сводное сравнение особенностей, плюсов и минусов четырёх основных подходов.

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

И вот к чему мы пришли.

Мы выделили три основных потребности разработки на микрофронтенде.

1. разделить большие команды разработки фронтендов на несколько;

2. разрабатывать большие портальные приложения;

3. сократить порог входа в разработку для фронтенд‑разработчиков.

Подходов, которые мы рассмотрели, было четыре:

1. Single SPA,

2. Module Federation,

3. NPM modules,

4. Git Submodules.

Ещё не успело ИИ-сообщество оправится от набега ЛЛаМ и высвобождения GPT-4, подоспела новая напасть — 19го марта была выпущена китайская нейросеть ModelScope text2video от Alibaba, создающая короткие видеоролики по текстовому описанию.

Привет, Хабр! Эксперт комьюнити #Сарафан компании GlowByte Александр Долгих расскажет историю из личного опыта о том, как решалась задача интеграции целевого маркетинга и множества самых разных каналов в одном из ведущих банков России (спойлер: о создании собственной централизованной платформы). Все персонажи вымышлены и совпадения случайны (улыбка). 

1. Тёмная энергия, управляющая расширением Вселенной и доминирующая в нашем космическом энергетическом бюджете. Природа её до сих пор неясна.
2. Тёмная материя, которая не может состоять ни из одной из известных частиц Стандартной модели, но по массе перевешивает обычную (состоящую из атомов) материю в соотношении 5:1.
3. Асимметрия материи и антиматерии, которая заключается в том, что на каждые 1,4 миллиарда фотонов во Вселенной приходится 1 протон или нейтрон, но нет соответствующих антипротонов или антинейтронов несмотря на то, что нам не известно ни одной реакции, которая могла бы создать протонов и нейтронов больше, чем антипротонов и антинейтронов.