User
Привет, Хабр! На связи команда направления прогнозирования промо в «Магните». В предыдущей статье «Магнитная аномалия: как предсказать продажи промо в ритейле» мы дали читателю общее представление о том, чем занимается наша команда. Теперь поговорим о конкретных сложностях и методах их решения, с которыми нам приходится сталкиваться в работе.
Чтобы лучше разобраться во внутренней кухне, предлагаем читателю вместе прогуляться по нашим «девяти кругам прогнозирования промо спроса».
Банковская карта — вещь такая же привычная, как смартфон: есть у большинства, и ей пользуются ежедневно миллионы людей. Впрочем, именно «карта» постепенно становится пережитком прошлого, уступая место тем же смартфонам в качестве платёжного средства. Но и пластиковыми кредитки были далеко не всегда. А какими были? Вернёмся в 1888-й — к самому началу.
Иван Чувашов, DBA Okko и Southbridge, поделился жизненными кейсами с PostgreSQL, которые помогут решить ваши проблемы.
Разберем случаи из PostgreSQL: запросы в статусе idle in transaction, выключенные контрольные суммы данных, переполнение int4, убивающие базу временные файлы и загрузку CPU.
Рекомендуемый минимум
Ниже приведены основные элементы для любого веб-документа (веб-сайта/приложения):
meta charset — определяет кодировку веб-сайта, стандартом является utf-8.
meta name="viewport" — настройки viewport, связанные с мобильной отзывчивостью
width=device-width — физическая ширина устройства (отлично подходит для мобильных устройств!)
initial-scale=1 — начальный масштаб, 1 означает отсутствие масштабирования
Элементы
Допустимые элементы <head> включают meta, link, title, style, script, noscript и base.
Эти элементы предоставляют информацию о том, как документ должен восприниматься и отображаться веб-технологиями, например, браузерами, поисковыми системами, ботами и так далее.
RPA (Robotic Process Automation) сейчас в некотором смысле напоминает старую добрую миниатюру Реввы: “Киииборги. Они заполонили всю планету!”. Про RPA говорят все чаще и чаще, появляются статьи и видео, рассказывающие о небывалом росте этого сегмента и многомиллионных экономиях тех, кто уже внедрил у себя RPA. Не то, чтобы и раньше этого не было, но сейчас стало уж совсем много.
Отзывов настоящих пользователей существенно меньше. Это не говорит о том, что RPA это плохо. Это просто факт, который и побудил меня написать эту статью и поделиться своими размышлениями.
Некоторое время назад, столкнувшись с определенными задачами, я выбирал средство для их решения и обратил внимание именно на RPA. Прорвавшись через миллион рекламных статей и восторженных видео от реселлеров, протестировав практически все, что доступно в trial / free версиях, я остановился на Automation Anywhere, который неплохо подходил под требования. Позже, к слову, я обнаружил что в нашей компании существует целый отдел, который занимается автоматизацией с помощью Blue Prism. Обратная, так сказать, сторона крупных корпораций - не всегда знаешь, что у нас уже есть…
Ну да речь не об этом. Не сразу, но через какое-то время я обнаружил, что самая сложная задача в RPA, это вовсе не написание роботов и не процесс их имплементации и сопровождения. Самое сложное - это управление ожиданиями на стороне менеджмента. Понимаете - они не инженеры, они управленцы. Они не понимают и не знают как, а главное почему, многие вещи работают так или иначе. Они читают такие же рекламные статьи и смотрят такие же рекламные видео как я в самом начале - и делают вывод: “Это же то, что нам нужно! Это решит все проблемы!”. И начинают интенсивно форсировать процесс внедрения. И хорошо, если есть внутренний инженерный ресурс, который этим вопросом будет заниматься и подскажет, что где и как. А вот если задача попадет к интеграторам - это может быть большой проблемой. Может быть не сразу, может быть в перспективе, но я думаю что обязательно будет, и вот почему:
Pulsar или Kafka — что лучше? Здесь мы обсудим плюсы и минусы, распространенные мифы и нетехнические критерии, чтобы найти лучший инструмент для ваших задач.
Обычно я рассказываю об Apache Kafka и ее экосистеме. О Pulsar за последние годы меня спрашивали только коммитеры и авторы Pulsar. Они задавали сложные технические вопросы, чтобы показать, что Kafka не идет ни в какое сравнение с Pulsar. На Reddit и подобных платформах разгораются яростные и очень субъективные споры на эту тему. Я поделюсь своей точкой зрения, основанной на многолетнем опыте работы со стриминговыми опенсорс-платформами.
В детстве практически каждый из нас ходил в кружки моделирования и пытался строить свои радиоуправляемые модели. Скажу сразу, ни одну управляемую модель я так и не собрал, хотя ракеты мои летали исправно и даже приземлялись на парашюте ("Илон, трепещи!"). Довольно много прочитал про это, но нелёгкая увела в сторону ИТ и моделирование забросил.
Лет 5 назад мне подарили дрон, ноунейм дрон. Это была очень простая копия DJI Phantom 1, которая не умела держать высоту, летать против ветра и снимать лучше кнопочного телефона 2002 года. В общем, один раз запустили, у него сели батарейки, да и больше не было желания к нему прикасаться. Зато вновь появился интерес к радиоуправляемым моделям (дронам).
Дальше мне подарили DJI Spark - мой первый нормальный дрон, который умел снимать вот так
Git – очень мощный инструмент, который практически каждый разработчик должен использовать ежедневно, но для большинства из нас git сводится к нескольким командам: pull commit push. Однако, чтобы быть эффективным, продуктивным и обладать всей мощью git, необходимо знать ещё несколько команд и трюков. Итак, в этой статье мы исследуем функции git, которые просто запомнить, применять и настроить, но которые могут сделать ваше время с git гораздо более приятным.
Кладите этот пост в закладки, если хотите быстро научить новичка (или просто неосведомлённого человека) умело пользоваться git.
Эта статья является конспектом материала Clarified CQRS.
Прежде чем начать разбираться с CQRS, нужно понять две основные движущие силы, стоящие за ним: сотрудничество и устаревание.
Сотрудничество относится к ситуациям, когда несколько участников используют или изменяют один и тот же набор данных независимо от того, действительно ли они намерены сотрудничать. Зачастую имеются правила, которые указывают какие пользователи могут выполнять модификации. И эти модификации могут быть приемлемыми в одном случае и неприемлемыми в другом. В качестве пользователя может выступать реальный человек или программное обеспечение.
Устаревание касается того факта, что в многопользовательских системах, как только данные были показаны пользователю, те же самые данные могут быть в дальнейшем изменены и стать устаревшими. Почти любая система, использующая кеширование, например, с целью улучшения производительности, работает с устаревшими данными. Это означает, что нельзя полностью доверять принятым решениям наших пользователей, поскольку они могли быть приняты на основе устаревших данных.
Стандартная многоуровневая архитектура не решает ни одну из этих проблем. Хотя размещение всех данных в одной БД может способствовать улучшению совместной работе, устаревание обычно усугубляется в такой архитектуре из-за использования кеширования в качестве средства повышения производительности.
Всем привет! Меня зовут Егор, я руковожу кластером App Platform в Авито. Мои команды в основном занимаются разработкой внутренних продуктов, инструментов и процессов — тем, что принято называть платформенной разработкой.
Год назад я рассказывал в этом блоге, как мы внедрили и используем performance review. Тогда я упоминал, что мы смотрим на него как на индикатор пользы, которую приносит компании каждый отдельный человек. Понимать это важно и полезно. Это помогает ответить на вопрос «насколько Вася молодец по сравнению с Петей?» и определить, какую премию кому выплатить. Но когда мы переходим на уровень команд, всё становится сильно интереснее. Здесь важно оценить конкретный результат команды и его влияние на успех компании. Высокое среднее значение перфоманса всех членов команды совсем необязательно значит, что команда достигла крутых результатов. Какая-то корреляция точно присутствует, но для оценки фактического вклада команды в успех компании этот инструмент использовать нельзя.
Для решения этой и ряда других проблем мы в Авито используем метод OKR — Objectives and Key Results. Он позволяет установить дерево понятных и легко измеримых целей во всей компании, связать результаты различных команд друг с другом и добиться достижения желаемых результатов.
С OKR мы живем вот уже почти три года. Начав с одной команды, мы масштабировали процесс до 130 разных структур — отдельных юнитов, вертикалей, кластеров, функций. В этой статье я сфокусируюсь на практических приемах того, как можно использовать OKR, чтобы получить от него пользу.
Данную статью пишу для думающих, стоит оно того или нет и начинающих построение своего умного дома, надеюсь она поможет сделать вам свой выбор. Для тех кто думает я не программист у меня ничего не получится, я тоже, хотя имею техническое (теплоэнергетик) образование, но никогда не работал в IT, не знаю не одного языка программирования. Дорогу осилит идущий. Начнем с рассуждений что такое умный дом, поверьте на слово он не решит все ваших бытовых и семейных проблем, но точно сделает жизнь немного комфортней. Что такое умный дом в моем представлении год назад: 1. Красивый планшет со схемой дома весящий на стане в прихожей с которого можно управлять всем в доме; 2. Управление всем чем можно голосом. Откровение через год планшет не нужен, так как бегать со второго этажа на первый что бы по управлять неудобно. Что бы хорошо работало голосовое управление, требуется установка умной колонки в каждую комнату, когда их две это одно. А когда значительно больше вопрос. Сейчас для меня умный дом это то, что работает само без моего участия, и не требует управления. Все о чем пойдет речь далее сделано мною лично, может можно сделать по другому, может проще и лучше. Но таков путь.
Полтора килограмма термоядерного Тринидадского Скорпиона я в итоге собрал с одного куста на гидропонике.
У меня было много довольно странных хобби. Некоторые приводили к странным эффектам, вроде массового домашнего производства домашнего порошка для посудомойки. В список к этому странному ряду я решил добавить еще один пункт. Теперь я развлекаюсь еще и с гидропоникой. Причем эффект получился еще более адовый, чем я ожидал.
Тема чудовищно огромная, охватить ее за один пост вряд ли получится, поэтому я постараюсь ограничиться описанием принципа, почему это вообще работает и дать максимально исчерпывающий мануал, чтобы каждый смог из желудей и спичек повторить мой эксперимент. В самом начале будет много теории. Можете ее проскочить и сразу перейти к нужным покупкам, а вернуться к ней позже.
В февральском наборе патчей для операционной системы Android закрыта уязвимость в Bluetooth-стеке (новость, бюллетень с обзором обновлений). Уязвимость затрагивает Android версий 8 и 9 (и, возможно, более ранние): на непропатченных смартфонах можно выполнить произвольный код с правами демона Bluetooth. Для эксплуатации достаточно знать MAC-адрес устройства и находиться на достаточно близком к жертве расстоянии. В Android 10 проблема также присутствует, но там она приводит только к падению отвечающего за Bluetooth софта, без выполнения кода.