Системные API разрабатываются, в том числе и так, чтобы попытаться решить несовместимые задачи. Например, следующие задачи – предоставить возможность детального управления ресурсом системы, и в то же время, упростить работу с ресурсом для разработчика. Такие задачи/цели порождают, например, следующее системное противоречия – API должно быть минимальным для того, чтобы можно было им легко/безопасно/с минимальным количеством ошибок использоваться, и в то же время, API должно быть детальным для того, чтобы можно было использовать максимум возможностей для управления системными ресурсами.
User
Важность диалога между PM-ом и разработчиком
2 min
Рассматривается кейс разработки, определяются некоторые проблемы, формулируется необходимость диалога.
Кейс разработки
Разработчик «завис» над простой задачей. Занимался задачей две недели. По результатам двух недель работы внес в репозиторий изменений на 10-20 строк кода. В отчете по задаче множество технических деталей. В отчете выставил необходимость дополнительного времени на доработку задачи.
Если для вас кейс очевиден, то можно дальше и не читать.
Опуститься до уровня руководителя?
2 min
Мы, разработчики, создаем алгоритмы, программы, приложения. Они часто наполнены для программиста красотой технических решений, изяществом архитектурных подходов или проработанностью алгоритмического подхода. Мы получаем удовольствие от изящества, красоты. Мы часто отказываемся от проектов, где нельзя писать красивый код. В своем мире мы спорим до хрипоты о том или ином подходе, который делает программу более совершенной. Мы смеемся с программистских мемов о коде, он джунах, о сеньёрах, о многочисленной рутине кодинга.
Красота в наших глазах. Но руководитель часто далек от технических деталей. Часто очень сложно объяснить всю программистскую «кухню» на языке диаграмм Гантта. Когда штудирование документации и вычитывание кода библиотеки выливается в метрику +10 строк кода. (За половину месяца.) Ну ведь правда, как-то не солидно – 0.125 строк кода в день. (Это сколько символов в день? А в час?) Правда?
Мы правда должны опускаться до уровня руководителей?
Разрабатывайте приложение для друзей
7 min
Друг может растеряться, друг может не понимать программу. Друг не программист, не разработчик, он не работал долгие часы над программой и поэтому не знает все нюансы работы программы (Иногда и разработчики не знаю всех нюансов своей программы). В начальной стадии работы с приложением друг не знает как пользоваться приложением. Только с накоплением опыта работы с приложением пользователь повышает свой уровень владения приложением.
Позвольте другу быть уверенным в работе с вашим приложением, быть уверенным.
Друг может путаться в том, что сейчас происходит в программе. Это создает неуверенность друга в ходе его работы. Сделайте информацию о состоянии программы очевидной для друга, не программиста. Это даст уверенность в том, что сейчас делает приложение и тем самым позволит быть уверенным в своих действиях с приложением для вашего друга. Быть уверенным.
Создавайте сценарий логичного и очевидного общение друга с вашим приложением.
Друг выполняет некое действие, и приложение реагирует на действие. Предоставьте возможность обратной связи на действия друга с вашим приложением. Действительно ли действие выполнено или возникли некие ошибки, получил ли друг ожидаемый результат или только часть результата и от друга требуются иные действия? Какие действия? Знает ли друг об этих действиях? Не забыл ли друг об этих действиях?
Друг может нервничать, спешить или просто эта информация «выпала» на некий момент и не вспомнилась в данный момент другу.
Даёт ли приложение консистентные сообщения, чтобы друг ориентировался не только на сущность обратной связи, но и по внешним характеристикам обратной связи, мог многое понимать по внешним атрибутам? Не путают ли характеристики обратной связи друга в течении времени, в разных фрагментах приложения, при разных действиях?
Друг может быстро взглянуть на сообщение, на интерфейс, быть невнимательным, быть рассеянным.
Позволяет ли приложение давать такую обратную связь, которая целостна, которая не требует высокой концентрации, прощает ошибки друга? Знает ли друг о том, когда закончится выполнение очередного действия?
У друга могут быть другие дела. Друг может спешить, друг может хотеть планировать свою работу. А, возможно, друг хочет отвлечься на звонок или выпить чашечку кофе.
Архитектура нейронной сети для реализации алгоритма RL с возможностью задания одновременно выполняющихся действий
4 min
Одна из классических схем нейронной сети для реализации алгоритма RL выглядит следующим образом:
Где: inputs – входы в нейронную сеть; FC – (fully connected) архитектура скрытых слоев или CNN — FC – архитектура архитектура скрытых слоев (в зависимости о того, что подается на входы); outputs – выходы сети. Часто выходы сети это softmax слой, который выдает вероятность выполнения одного из действий из набора всех возможных действий.
Недостаток данной архитектуры, в том, что сложно реализовать выбор сразу нескольких одновременно выполняемых действий.
Для решения этой проблемы предлагается архитектура с слоем маски. Предлагаемая архитектура выглядит следующим образом:
Эта архитектура полностью соответствует классической архитектуре, но также включает слой маски действий. Выход у данной архитектуры один – это значение ценности действия (группы одновременно выполняемых действий). Слой маски действий может быть реализован в соответствии с псевдокодом ниже:
Где: inputs – входы в нейронную сеть; FC – (fully connected) архитектура скрытых слоев или CNN — FC – архитектура архитектура скрытых слоев (в зависимости о того, что подается на входы); outputs – выходы сети. Часто выходы сети это softmax слой, который выдает вероятность выполнения одного из действий из набора всех возможных действий.
Недостаток данной архитектуры, в том, что сложно реализовать выбор сразу нескольких одновременно выполняемых действий.
Для решения этой проблемы предлагается архитектура с слоем маски. Предлагаемая архитектура выглядит следующим образом:
Эта архитектура полностью соответствует классической архитектуре, но также включает слой маски действий. Выход у данной архитектуры один – это значение ценности действия (группы одновременно выполняемых действий). Слой маски действий может быть реализован в соответствии с псевдокодом ниже:
Расширение макроса assert() для реализации минимальной обработки ошибок
5 min
– Сир, я придумал защиту от дракона. Он нам больше не страшен! Она срабатывает от взмахов крыльев дракона и включает громкую сирену, так чтобы все слышали, что приближается дракон.
– Что-нибудь ещё эта защита делает?
– Нет, зачем? Мы будем предупреждены!
– Да… Съедены под вой сирены… И ещё… напомни, когда у нас плановые отключения электричества?…
Данный способ не претендует на концепцию обработки ошибок в комплексных и сложных проектах. Скорее это пример того, что можно сделать минимальными средствами.
– Что-нибудь ещё эта защита делает?
– Нет, зачем? Мы будем предупреждены!
– Да… Съедены под вой сирены… И ещё… напомни, когда у нас плановые отключения электричества?…
Описание проблемы
Данный способ не претендует на концепцию обработки ошибок в комплексных и сложных проектах. Скорее это пример того, что можно сделать минимальными средствами.
Прием для разработчиков для преодоления прокрастинации
3 min
Есть программисты, которые «живут» своей работой. Они думают о работе денно и нощно, они не отвлекаются на мелкие бытовые проблемы (они выше этого, «парят» над этим). Но такая ситуация не у всех программистов. Многим необходимо быть успешными и в работе, и дома, и на стадионе, и на скалодроме… Вы, наверное, понимаете. Вместе с тем, такая многозадачность приводит к тому, что нужно возвращаться к задачам на работе. И тут появляется психологическое сопротивление, которое приводит к прокрастинации. Для решения проблемы прокрастинации начала рабочего дня (или вообще начала/продолжения работы после перерыва) и предлагается данный прием.
Использование autoencoder-ов для построения рекомендационной системы
7 min
Как и во многих рекоммендационных системах у нас есть продукты, пользователи и оценки, которые выставляют пользователи (явно или не явно) продуктам. Наша задача предсказать оценки продуктам, которые ещё не оценил пользователь и тем самым предсказать те продукты, которые могут быть высоко оценены пользователями, или продукты, которые могут быть интересны пользователям. (В чем и состоит функция рекомендационой системы — найти продукты, которые могут быть потенциально интересны пользователю.)
Необходимо было разработать рекомендационную систему, которая бы:
Необходимо было разработать рекомендационную систему, которая бы:
- Была оптимальна с точки зрения скорости работы после обучения модели.
- Требовала бы минимальных затрат на обработку новых поступающих данных. Т.е. чтобы рекомендационной системе не требовалось бы полное переобучение или же дообучение после получения новых данных или же чтобы операции такого рода были бы минимальны (возможно, мы бы теряли в качестве работы, но при этом не требовалось бы существенных затрат на повторное построение модели).