Денис Пушкин, Head of Product Marketing в Skyeng, рассказал о том, что вдохновляет его на создание и развитие продуктов.



Давайте начнем с того, чем занимается менеджер продукта — это три известных всем области:

1. IT-продукты — в основном сайты и мобильные приложения.
2. Операционка — операционные процессы в любых сервисах, например, в колл-центре или доставке еды.
3. Человек. Самые модные ребята в продуктовой тусовке прокачивают себя как продукт.

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

В этой статье я продолжу тему компьютерного зрения.

См. предыдущие статьи: Простой алгоритм распознавания движений и алгоритм поиска смещения объектов на изображении. Напомню, что написать эти статьи меня сподвигло то, что когда я начал работать над магистерской диссертацией на тему «Анализ пространственной структуры динамических изображений», то столкнулся с проблемой, что очень трудно найти какие-то готовые примеры алгоритмов распознавания образов и движущихся объектов. Везде, и в литературе, и в Интернете одна только голая теория. С тех пор прошло довольно много времени, я успел успешно защитить диссертацию и получить красный диплом, а теперь пишу, чтобы поделиться опытом.

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

Введение в теорию

Обучение на ассоциативных правилах (далее Associations rules learning — ARL) представляет из себя, с одной стороны, простой, с другой — довольно часто применимый в реальной жизни метод поиска взаимосвязей (ассоциаций) в датасетах, или, если точнее, айтемсетах (itemsests). Впервые подробно об этом заговорил Piatesky-Shapiro G [1] в работе “Discovery, Analysis, and Presentation of Strong Rules.” (1991) Более подробно тему развивали Agrawal R, Imielinski T, Swami A в работах “Mining Association Rules between Sets of Items in Large Databases” (1993) [2] и “Fast Algorithms for Mining Association Rules.” (1994) [3].

Приветствую, читатель! Меня зовут Сергей, я являюсь инди-разработчиком компьютерных игр. В моем портфолио имеется уже несколько инди-проектов, часть из которых была самостоятельно выпущена в Steam. Игра «Свет» или «The Light», вышедшая в 2012 году, была моей первой пробой пера, открывшей путь в мир игровой разработки. Проект распространялся бесплатно, но реакция публики и отзывы игроков подарили мне серьезную мотивацию для дальнейшей работы. «The Light» стал для меня чем-то вроде философской притчи о человечестве и его судьбе. Сюжет абстрактен и не преследует каких-то конкретных целей, это лишь возможность поразмышлять на обширную тему.

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

Введение

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

В этой статье я расскажу о следующем:

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

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

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

2018 год принципиально изменил наш подход к разработке бизнес-процессов. Ниже — о том, как эволюционировал этот подход и как менялись мы.

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

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

Не мечта ли любого владельца компании управлять IT-продуктом так, чтобы поставлять продукт в срок, обгоняя конкурентов, и делать это с высоким качеством, радуя пользователей? Хотелось бы найти серебряную пулю для управления и, кажется, она есть. Не такая уж серебряная и не такая уж пуля, но довольно надежный и обкатанный годами подход к управлению, который можно назвать FFF: Fix Time and Budget, Flex Scope.

Почему и когда стоит выбрать FFF? Давайте посмотрим.

В 2013 году Коди Уилсон напечатал на 3D-принтере первый пластиковый пистолет, способный стрелять боевыми патронами.

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

Посмотрим, как изменилась ситуация вокруг 3D-печатного оружия за 7 лет. Спойлер: она стала только острее.

Под катом: 30 минут чтения, 9 пластиковых пушек, 7 видео, 3 научных исследования, 1 метаанализ и тема для эпичного холивара. Но ни одной инструкции или файла для печати. Извините, товарищ майор.

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

Если вы читаете это, то скорее всего так или иначе связаны (профессионально) с ИТ-сектором. Так уж получилось, что многие результаты нашей работы нельзя «пощупать руками». Да, за спиной могут быть годы опыта и свернутые горы кода, решённых задач, построенных инфраструктур… Но это всё — «где-то там». Лично мне очень не хватает ощущения, что я создал что-то, что могу осязать: просто взять в руки и потрогать, поставить на полку…

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

Вот вы знаете, что такое настоящий вселенский факап? Недавно я полностью ощутил это на своей шкуре. Надеюсь, текст будет полезен начинающим 3D печатникам, так как проблема не единичная, но найти решение было непросто и даже я, старый атеист, чуть не поверил в чудеса. Простите за изложение, так как я не писатель и не блогер, а простой инженер — фирмварщик.

Кроме того, текст рассчитан на людей, имеющих минимальный опыт с 3D печатью.

Исключительно по причине не раздувать статью и не объяснять назначение разных деталей и сленговых словечек. Начну с предыстории. Чуть меньше года назад купил себе недорогой 3D принтер. Один из самых популярных (не на правах рекламы, а что бы было понятно о чем речь) — Ender 3. Сборка была несложная, в Сети есть много рекомендаций. Конечно, собирая его по инструкции — получил бы нерабочий агрегат, но предварительно «покурив мануалы», удалось выполнить первую пробную печать на 5 с плюсом для такой простой машинки! Все было хорошо до определенного момента. Но дальше началось…


Если интересно что, добро пожаловать.

Анализ производительности и настройка — мощный инструмент проверки соответствия производительности для клиентов.

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

Go тут особенно хорошо подходит, поскольку у него есть инструменты профилирования pprof в стандартной библиотеке.

Источник

Считается, что есть три подхода к диагностике информационной безопасности: аудит, оценка уязвимостей и тесты на проникновение. Поговорим про аудит и оценку уязвимостей. Под катом мы рассмотрим вопросы, которые нужно решить в рамках аудита, и набор инструментов от Quest Software для выявления, предотвращения и расследования инцидентов информационной безопасности на основе машинного обучения (Change Auditor Threat Detection), сбора логов с объектов инфраструктуры (InTrust), аудита текущей конфигурации (Enterprise Reporter) и вывода данных аудита по всем перечисленным системам в одном интерфейсе (IT Security Search).

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

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

Но с такими возможностями часто приходит полное отсутствие уважения к участникам проекта других профессий. Это отсутствие уважения может оказаться настолько глубоким, что порождает в уме разработчика твёрдую уверенность, что он не только самый ценный участник программного проекта, но и необходим компании в целом. К сожалению, хотя лишь малое число разработчиков способны накапливать что-либо напоминающее богатство, многие ведут себя так, словно они следующие Марк Цукерберг, Билл Гейтс или Стив Джобс; хотя это очень далеко от истины. Это приводит к личностным проблемам, которые так же увлекательно наблюдать со стороны, как страшно созерцать в себе.

Существует два основных пути становления топ-менеджмента в IT-компаниях:

1. Менеджерский — когда менеджер проекта начинает управлять другими менеджерами.
2. Технарский — когда разработчик начинает управлять другими разработчиками и количество управляемого им персонала увеличивается.

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

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

Для начала представлюсь. Меня зовут Николай Шилкин, и я более 20-ти лет занимаюсь автоматизацией учета по МСФО. Прошёл путь от самой первой бухгалтерской программы под Windows, поддерживавшей МСФО, до самых последних флагманских продуктов фирмы 1С. В багаже — более 30 проектов в транснациональных корпорациях.

Ну, а теперь, собственно, по теме...

Несколько недель назад мне удалось успешно сдать сертификационный экзамен на статус PMP (Project Management Professional), и на самом деле в этом нет ничего особенного, кроме того, что я сдавала тест, не покидая собственной квартиры. Сегодня поделюсь особенностями онлайн-экзамена и очень надеюсь вдохновить тех из вас, кто давно собирался пройти сертификацию, но долгое время откладывал.

Я думал, что достиг желанного. Один из моих open-source проектов начал набирать небольшую аудиторию фолловеров на GitHub. Больше никакой нытливой неуверенности в себе, ведь около тысячи наблюдателей за звёздами следят за моим проектом — это всё, что нужно для подтверждения ценности. Это то, что можно вспоминать в моменты неуверенности. Напоминание, что я действительно достиг того, чего стою на самом деле. Никогда не думал, что звёзды могут отвернуться от меня.

* * *

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

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

В 2019 году на DUMP в Казани выступал Никита Соболев – технический директор компании wemake.services. И Никита на протяжении почти 40 минут пытался вскипятить мозги слушателей секции Backend, рассуждая о code review. Сегодня хотим привести расшифровку этого «взрывного» доклада, чтобы если уж мозги бурлили, то у всех сразу.

А вот, кстати, и сам Никита Соболев во время своего выступления.