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

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

А при чем тут драконы, объясним под катом.

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

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

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

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

Пост написан при поддержке WD-40

От переводчика: проблема медленного программного обеспечения стала одной из главных тем обсуждения на Хабре и Hacker News в последние недели. Например, см. статью Никиты Прокопова «Моё разочарование в софте» и 2432 комментария к ней.

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

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

Пиксель-арт вечен, но это не значит, что инструменты и методики работы с ним должны оставаться на уровне 1993 года.

Британский разработчик игр Cardboard Sword работает над двухмерным стелс-платформером The Siege and the Sandfox, создаваемом в Unreal Engine 4 с Paper2D. Команда публикует серию дневников разработки, знакомящую других разработчиков с тем, как использовать эти инструменты в собственных играх.

Одна из основных технических особенностей The Siege and the Sandfox — использование отрисованных вручную тайлсетов и спрайтов с картами нормалей, позволяющих применять в этой игре с достаточно традиционным двумерным пиксель-артом способы трёхмерного освещения.

Один из арт-директоров Cardboard Sword Кейт Дюк-Кокс недавно рассказал Gamasutra, как компания пришла к использованию этой техники, о том, почему она подходит игре и как можно применить подобные техники в собственных 2D-играх.

Надеюсь, что смог привлечь ваше внимание таким провокационным (и, признаться, утрированным) заголовком. Хорошо. Теперь позвольте его переформулировать в чуть более изящном и менее завлекающем виде:

В принципе, софт можно написать либо вовремя, либо хорошо, но не то и другое одновременно*

* за исключением считанных случаев в сложившихся высокопроизводительных командах

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

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

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

Что такое DJI GO 4 знает каждый владелец квадрокоптера DJI. С помощью этой программы вы можете не только управлять своим дроном, но и изменять настройки камеры, сенсоров, отслеживать статус всех систем устройства и многое другое. Но, к сожалению, пока приложение не получило официальную русификацию. В связи с этим многие пользователи до сих пор не знают, за что отвечают различные пункты меню.

Предлагаю вашему вниманию перевод очень крутой статьи по анимации интерфейса.
The ultimate guide to proper use of animation in UX автора Taras Skytskyi.



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

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

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

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

Мне на глаза попался документ с правилами и рекомендациями по процессу ревью кода внутри компании. Я решил, что такой полезной информацией надо поделиться с внешним миром. С благословения автора я публикую работу.

Какой должна быть оптимальная дизайн-система в Figma? Что такое переиспользуемый компонент? Как понятнее и удобнее организовать структуру внутри панели Instance? Каковы этапы разработки подобного продукта? И так далее. Ответы на эти и многие другие вопросы я постараюсь дать в этой статье.

Дисклеймер от автора (автор — девушка): Я не разрабатываю движки баз данных. Я создаю веб-приложения. Я участвую в 4-6 разных проектах каждый год, то есть создаю много веб-приложений. Я вижу много приложений с различными требованиями и различными потребностями хранения данных. Я разворачивала большинство хранилищ, о которых вы слышали, и несколько, о которых даже не подозреваете.

Несколько раз я делала неправильный выбор СУБД. Эта история об одном таком выборе — почему мы сделали такой выбор, как бы узнали что выбор был неверен и как мы с этим боролись.Это все произошло на проекте с открытым исходным кодом, называемым Diaspora.

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

Традиционным уникальным преимуществом платформы Arduino называлось (да и сейчас иногда называется, хотя это уже неверно — и мы поговорим, почему) опускание порога входа в микроконтроллерную разработку до уровня базовых знаний C/C++ и электроники в маштабе «подключить светодиод в нужной полярности».

Спросите примерно у любого активного сторонника Arduino — и вам быстро объяснят, что можно, конечно, писать под STM32 или nRF52, но выгоды в том реальной никакой, зато вас ждут бессонные ночи над сотнями страниц даташитов и бесконечные простыни функций с длинными непонятными названиями.

Заслуги Arduino в снижении порога вхождения действительно трудно переоценить — эта платформа появилась на свет в середине нулевых годов, а после 2010 завоевала серьёзную популярность среди любителей. Особых альтернатив на тот момент ей не было — процессоры на ядрах Cortex-M только появились, по сравнению с AVR они были довольно сложны даже для профессиональных разработчиков, а отладочные платы у большинства вендоров стоили от сотни долларов и выше (и в общем в индустрии ценник за отладку на 5-долларовом контроллере в $500 никого сильно не удивлял).

Однако большая проблема Arduino в том, что её развитие за минувшие 10+ лет более всего напоминает некоторые модели АвтоВАЗа:


Так как дальше я планирую длинное вступление, то сейчас, чтобы вы представляли, в чём будет заключаться практическая часть, я приведу полный текст программы, включающий инициализацию процессора STM32 и мигание светодиодом. Программа написана для ОС ARM Mbed:

#include "mbed.h"
DigitalOut myled(LED1);

int main() {
    while(1) {
        myled = 1; // LED is ON
        wait(0.2); // 200 ms
        myled = 0; // LED is OFF
        wait(1.0); // 1 sec
    }
}

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

В конце 2017 года мы рассказывали истории о невозвратных затратах в разработке игр.

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

Вскоре после выпуска статьи разработчик Axiom Verge Том Хэпп предложил нам взглянуть на проблему с другой стороны: как насчёт хороших игр или функций, от которых отказались напрасно?

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

Хочу представить общественности свою разработку – приложение для удаленного управления рабочим столом Aspia. Проект является полностью бесплатным и с открытым исходным кодом (GPL 3.0).

На данный момент реализованы следующие возможности:

• Удаленное управление рабочим столом
• Удаленный просмотр рабочего стола
• Передача файлов
• Адресная книга с поддержкой шифрования и мастер-паролем (XChaCha20+Poly1305, 256-битный ключ)
• Возможность создавать пользователей с индивидуальными правами
• Шифрование всей передаваемой по сети информации (XSalsa20+Poly1305)

Я все еще не до конца понял, как так получилось, но в прошлом году я слово за слово подписался прочитать курс по Deep Learning и вот, на удивление, прочитал. Обещал — выкладываю!

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

Материалы курса были опробованы на студентах кафедры АФТИ Новосибирского Государственного Университета, поэтому есть шанс, что по ним действительно можно чему-то научиться.

Нейронными сетями уже никого не удивишь. Практически каждый человек знает, что такое машинное обучение, линейная регрессия, random forest. Каждый год тысячи людей проходят курсы по машинному обучению на ODS и Coursera. Любой школьник за пару недель теперь может освоить keras и клепать нейроночки. Но в нейронных сетях, как и во всем машинном обучении, помимо создания хорошего алгоритма, необходимы данные, на которых алгоритм будет обучаться.

Могут ли кнопки быть шестиугольными?

Google I/O 2018 оставила огромное количество материала для осмысления. Что нового? Как жить дальше? Устарело ли моё приложение? Могут ли кнопки быть шестиугольными? Дизайнеры снова больше не нужны? Осмысливать приятней не спеша и маленькими порциями. Эта порция — про дизайн.

В этой статье я расскажу, как мне удалось заработать первые 100$ на моих приложениях в Google Play Market. Какие стратегии более успешные и на что стоит обратить внимание новичку.

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


В основе статьи доклад Антонины Хисаметдиновой с Heisenbug 2017 Moscow, которая занимается проектировкой пользовательских интерфейсов в компании Собака Павлова.

Кроме того, на Медиуме есть цикл статей «Руководство по проектированию ошибок». Цикл еще не дописан до конца, но дает более полную и цельную картину по теме статьи.