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

Главный вопрос этого поста: какие же изменения претерпевает agile коммуникация (и скрам, в частности), натягиваясь на распределенные команды?

Для этого, давайте сначала классифицируем коммуникацию:

1. стратегические митинги (планирование / ретроспектива)
2. ежедневную синхронизацию (в том числе daily standups)
3. прояснение рабочих вопросов

Давайте добавим еще одно измерение! Если попробуем наложить вышеприведенную классификацию на географию, то появляются дополнительные срезы для вышепреведенного:

В этой статье представлены бесплатные инструменты для проведения расследования инцидентов информационной безопасности.

Вам нужна аналитика.

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

Это пост о том, как создать аналитику в вашей организации. Речь пойдёт не о том, какие метрики отслеживать (об этом уже написано много хороших постов), а о том, как сделать так, чтобы ваш бизнес их генерировал. На практике выясняется, что на вопрос реализации —  как мне построить бизнес, который добывает данные для принятия решений? —  ответить гораздо труднее.

Собираюсь запускать несколько продуктов и понимаю, что нужно делать правильный запуск. И это не просто реклама в Директе и SEO-оптимизация, но и какие-то предстартовые действия. В одном из тренингов Лайк Центра я наткнулся на книжку «Запуск» (Launch) Джеффа Уокера. Её анонсировали как уникальный инструмент для успешного запуска продуктов, и я решил попробовать этот инструмент на себе. В нескольких статьях я расскажу, как это выглядит на практике. Но в этой статье только теория, т.е. конспект книги.

Джефф Уокер разработал уникальную методику запуска. Она состоит в том, что для запуска нужно произвести некоторую последовательность действий, которая поможет продать продукт и обеспечит доверие. Он назвал эту методику PLF: Product Launch Formula — формула запуска продукта. Она состоит из последовательностей, историй и триггеров.

Кто хочет нутром прочувствовать проблематику, — послушайте песню Uma2rmaH «Зависть».

Новогодние праздники — прекрасный повод попрокрастинировать в уютной домашней обстановке и вспомнить дорогие сердцу мемы из 2k17, уходящие навсегда, как совесть Electronic Arts.

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

Введение

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

1. Любой объект может стать частью конструкции (результат процесса синтеза), или быть разделенным на части (результат процесса анализа). При этом синтез и анализ можно делать разными способами. Это значит, что один и тот же объект может стать частью разных конструкций, или объект может быть поделен на части множеством способов.
2. Один и тот же объект может быть интерпретирован по-разному.
3. Любая модель может быть расширена с учетом смены точки зрения.
4. Мы не рассматриваем представления, созданные искусственным интеллектом и языки, созданные им для описания этих представлений. Мы не рассматриваем математические изощрения типа бутылки Клейна, или фракталов.

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



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

functools (это такая свалка для всяких ненужных мне вещей :-).
— Гвидо ван Россум

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

В статье заимствуются примеры и/или концепции из библиотеки funcy. Во-первых, она клевая, во-вторых, вы сразу же сможете начать ее использовать. И да, нам понадобится ФП.

Метод, которым пользуются Джефф Безос, Уоррен Баффет и Илон Маск

Джеффу Безосу часто задают вопрос, который мы все должны задать сами себе: «Что изменится в ближайшие 10 лет?»

Это непростой вопрос: мир меняется очень быстро, и принимаемые сегодня решения определяют нашу судьбу.

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

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

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

За последние несколько лет я познакомился с людьми, которые свою карьеру посвятили умелому предсказанию будущего: они вкладывали деньги на основе своих прогнозов, и год за годом получали солидный куш. Я заметил, что у них есть кое-что общее — противоречащий, на первый взгляд, здравому смыслу подход к вложению денег и времени, который переворачивает вверх ногами привычные представления. В этой статье я расскажу, как можно обеспечить себе будущее, используя методы, которые применяют добившиеся всего своим умом предприниматели-миллиардеры и инвесторы, такие как Джефф Безос, Рэй Далио, Говард Маркс и Уоррен Баффет.

Переведено в Alconost

Всем привет! Хочу рассказать про историю своей победы в ежегодном соревновании по написанию игровых ботов Russian AI Cup, в 2017. В финале бот выиграл 98% игр, что, как оказалось, наивысший результат по финалам среди всех годов проведения чемпионата. Также занял 1-е место в песочнице по завершению её работы, в пике переходя за 4000 очков рейтинга.



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

У этого перевода не совсем обычная история. Системы контроля версий далеки от моих профессиональных интересов. Для рабочих проектов они мне требовались нечасто, причем, разные, так что, каждый раз, когда возникала такая необходимость, я заново вспоминала, как в них делается та или иная операция. А для личных проектов мне хватало возможностей Dropbox, хранящей историю версий файлов.


^{Изображение из твиттера @girlie_mac}

Но вот однажды я на три незабываемых дня попала в роддом — это иногда случается с женщинами. Из развлечений у меня были новорожденная дочь и телефон с большим экраном. Дочь поначалу развлекала плохо (дома она быстро исправилась), а на телефоне помимо книг и фильмов обнаружился текст «Git from the bottom up», который оказался более чем годным… С тех пор прошло почти 3 года, подросшей дочке уже пора самой начинать использовать Git Git стал мейнстримом, если не сказать стандартом в современной разработке, а я с удивлением обнаружила, что перевода на русский этого чуда, полезного не только начинающим, но и продвинутым пользователям Git, до сих пор нет. Исправляю эту ситуацию.

^{Вот так люди видят вашу страницу}

Привет!
Проблема вот в чём. Если зайти на практически любой сайт интернет-магазина или компании с услугами, вы встретите контент. Точнее — отвратительные тексты, которые писали, кажется, маркетологи, воспитанные сеошниками.

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

По моим примерным подсчётам (усреднение с ряда позиций), конверсии для нас выглядят так:

• Только название и картинка — около 1,5%.
• С описанием от производителя — чуть более 2%.
• С описанием человека, который держал это в руках и знает правила — около 6%.

Ниже — рассказ про то, как мы доводили время на сайте от 3 минут сначала до 6:40, а потом до 20:48. Да-да, двадцати минут сорока восьми секунд для среднего посетителя. Честного среднего, с учётом отказов и по полной выборке.

Сейчас, в том числе и у нас на сайте, и в приложениях ivi, есть явная тенденция роста аудитории на мобильных устройствах. Также растет и доля покупок, совершаемых в интернете с мобильных устройств. В отличие от десктопа, помимо традиционных вариантов оплаты, доступны системы мобильных платежей, например Apple Pay, Android Pay, Samsung Pay. Эти системы можно использовать не только для оплаты в терминалах, принимающих банковские карты, но и для оплаты в приложениях и на веб-сайтах.

Внедрение мобильных платежей мы начали с веб-версии ivi и выбрали мобильный сайт и систему Apple Pay.

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

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

Сможете поставить ещё шесть? А найти все решения?
(картинка из статьи)

Далее, к сожалению, произошла какая-то совершенно невразумительная история из цепочки вот таких вот превращений:

• Отличная статья ---пресс служба университета---> невразумительный пресс-релиз.
• Пресс релиз ---занятный перевод---> непонятная статья на гиктаймс

Стоит отметить, что пять наугад открытых ссылок на русском ещё меньше проясняли картину происходящего.

Я тут подумал — надо бы кому-то эту странную цепочку прервать и нормальным языком изложить суть событий.

О чём пойдёт речь:

• История задачи
  
  • Латинский квадрат
  • Задача о восьми ферзях
• Три типа задачи "о ферзях"
  
  • Расстановка N ферзей
  • Подсчет числа решений
  • Дополнение до N ферзей
  • Вариации задачи
• Модели и сложность
  
  • Линейный поиск для N ферзей
  • Как считать число решений на практике
  • Дополнение до N
• Выводы

Михаил Трутнев, COO самого популярного в мире музыкального сервиса Ultimate Guitar c ежемесячной аудиторией более 30 млн человек, выступил на конференции по продуктовому маркетингу Epic Growth Conference.



На Epic Growth Conference исполнительный директор Ultimate Guitar поделился нестандартными подходами к организации бизнес-процессов, работе с командой и просто к жизни. Смотрите видео или читайте заметки ниже.

Хотя Discord — это приложение для голосового и текстового чата, каждый день через него проходит более ста миллионов изображений. Конечно, мы бы хотели, чтобы задача была простой: просто перенаправить картинки вашим друзьям по всем каналам. Но в реальности доставка этих изображений создаёт довольно большие технические проблемы. Прямая ссылка на картинки выдаст хосту с картинкой IP-адреса пользователей, а большие изображения расходуют много трафика. Чтобы избежать этих проблем, требуется промежуточный сервис, который будет получать изображения для пользователей и изменять их размер для экономии трафика.

Встречайте Image Proxy

Для выполнения этой работы мы создали сервис Python и креативно назвали его Image Proxy. Он загружает картинки с удалённых URL, а затем выполняет ресурсоёмкую задачу по ресайзингу с помощью пакета pillow-simd. Этот пакет работает удивительно быстро, используя где только возможно для ускорения ресайзинга инструкции x86 SSE. Image Proxy будет получать HTTP-запрос, содержащий URL, чтобы загрузить, изменить размер и, наконец, выдать окончательное изображение.

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

— Рома, я задолбался быть инженером. Всё, ухожу!
Он ласково улыбнулся и сказал:
— Хорошо. Будешь системным архитектором. Там только свет и чистота. Выспись и приходи, расскажу, что будешь делать.

Я был молодым и наивным. Выспался и пришёл. Тогда начал постепенно становиться архитектором (сейчас стал), и могу смело сказать: света и чистоты тут столько же, сколько в буднях инженера. А вот ответственности больше. Поэтому — нет, не надо быть архитектором, если вы не понимаете, на что идёте.

Но! Если понимаете — это будет очень увлекательное приключение.

У нас в Wrike есть традиция делиться с командой мыслями о книгах, которые прочитали. Мы давно думали, что было бы неплохо распространить эту инициативу и на наш блог на Хабрахабре, и вот подвернулся хороший случай — книга Фредерика Брукса «Мифический человеко-месяц».

Книгу можно назвать скорее классикой фольклора разработки, нежели реальным руководством по построению рабочего процесса. В ней отражены проблемы, с которыми Брукс столкнулся при организации работы над созданием операционной системы OS/360, и его подходы к их решению. Результат был далек от идеала, на что сам Брукс и указывает. Его целью было не научить как правильно, но поднять проблемы, требующие решения. Любопытно разобраться, что изменилось в разработке с 1960-х годов.


Фото из архива IBM