Connect with us

Программирование

Когнитивные искажения в программировании

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

Анна Гуляева

Опубликовано

/

     
     

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

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

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

Гиперболическое дисконтирование

Желание моментальной отдачи вместо большего результата позже

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

Эффект IKEA

Переоценивание вашего решения проблемы и недооценивание остальных решений

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

Преждевременная оптимизация

Оптимизация до того, как она нужна

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

Ошибка планирования

Оптимистичная недооценка времени, требуемого для завершения задачи

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

Не так страшны первые 90% проекта, как вторые 90% проекта.

Заблуждение новизны

Придание большей значимости недавним событиям, чем произошедшим давно

Заблуждение новизны часто настигает нас, когда нам нужно найти решение. Эй, мы только что решили похожую проблему, так что давайте используем то же решение, потому что оно сработало! Вы используете одни и те же шаблоны проектирования снова и снова? Если да, то вы, вероятно, смотрите на разные проблемы через одну и ту же линзу.

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

 

Анна Гуляева
Комментарии Facebook
Продолжить чтение
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Исследования

Самые нелюбимые языки программирования

Stack Overflow обобщил эту статистику и вывел Топ нелюбимых языков программирования.

Леонид Боголюбов

Опубликовано

/

В  разделе Stack Overflow Jobs вы можете разместить свою историю разработчика – показать достижения и карьерный рост. Там же можно указать технологии, с которыми вы хотите или не хотите работать.

Stack Overflow обобщил эту статистику и вывел Топ нелюбимых языков программирования. Он представлен на графике ниже и процент в нем означает соотношение отрицательных отзывов к общему количеству (50% значит, что количество лайков и дислайков равно, а 1% значит, что на 99 лайков приходится один дислайк).

Самые нелюбимые языки программирования – Perl, Delphi и VBA. Самые любимые – R, Kotlin и Typescript.

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

Самые любимые теги:

Интересная еще диаграмма противостояния – если человек любит А, то не любит Б. например, iOS и  Android, Unix и Windows:

 

 

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Медиа

Видео Droidcon NYC 2017

Опубликованы записи конференции Droidcon 2017, проходившей в Нью-Йорке.

AppTractor

Опубликовано

/

Автор:

Опубликованы записи конференции Droidcon 2017, проходившей в Нью-Йорке.

Всего 64 видео, среди которых, например:

  • Кодлаб: Прототипирование веселья с Android Things
  • Чистый дизайн приложения с Architecture Components
  • Кодлаб: Глубокие ссылки для Instant Apps
  • Многопотоковый рендеринг на Android (с Litho и Infer)
  • Нет интернета? Нет проблем!
  • GraphQL на Android

AppTractor
Комментарии Facebook
Продолжить чтение

Программирование

Как создать приложение для Google Home или Google Assistant

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

Анна Гуляева

Опубликовано

/

Разработчик в компании Azimo Мирек Станек рассказал о процессе создания простого приложения для голосовых интерфейсов Google.

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

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

Приложение WaterLog

Мы начнем с создания простой программы. WaterLog – это приложение, которое помогает нам отследить ежедневное потребление воды на основе разговора или переписки с Google Assistant. Первая версия приложения сможет отследить, сколько литров или миллилитров воды мы выпили за день. Для простоты мы пропустим теорию дизайна голосовых интерфейсов и сфокусируемся на технической стороне создания работающего приложения.

Вот возможные сценарии бесед:

Новый пользователь

Пользователь: Окей, Google, поговорить с WaterLog.

WaterLog: Добро пожаловать в WaterLog. Вы знаете, что вам следует пить около 3 литров воды в день, чтобы оставаться здоровыми? Сколько вы уже выпили?

Пользователь: Я выпил 500 миллилитров воды.

WaterLog: Ок, я добавил 500 миллилитров воды в ваш дневной журнал. В сумме вы выпили за сегодня 500 миллилитров воды. Дайте мне знать, когда вы будете пить воду в следующий раз! Увидимся позже.

Вернувшийся пользователь

Пользователь: Окей, Google, поговорить с WaterLog.

WaterLog: Добрый день! Сегодня вы выпили 500 мл воды. Какое количество воды мне добавить?

Пользователь: 100 мл.

WaterLog: Ок, я добавил 100 мл воды в ваш дневной журнал. В сумме вы выпили за сегодня 600 мл воды. Дайте мне знать, когда вы будете пить воду в следующий раз! Увидимся позже.

Вернувшийся пользователь спрашивает о записанной воде

Пользователь: Окей, Google, спросить WaterLog, сколько воды я сегодня выпил.

WaterLog: В сумме вы выпили за сегодня 600 мл воды. Дайте мне знать, когда вы будете пить воду в следующий раз! Увидимся позже.

Вы можете протестировать это приложение на своем устройстве.

Начало

Это приложение очень простое, но даже такой проект требует связи некоторых частей, чтобы он заработал. Хотя у нас много свободы в выборе платформы (мы можем создать приложение на разных языках и поместить его в разные облачные хранилища, такие как платформа Google Cloud или AWS), для начала мы возьмем самый распространенный стек:

  • Cloud Functions и база данных Firebase для бэкенда;
  • Dialogflow для понимания естественного языка и диалогов;
  • JavaScript/Node.js для кода приложения (на данный момент Firebase Cloud Functions поддерживает только этот язык);
  • Google Actions SDK для интеграции с Google Assistant (в будущем мы попробуем использовать платформы вроде Amazon Alexa или Facebook Messenger).

Я не буду подробно писать о том, как связать все это вместе. На сайте Google Actions есть хороший пошаговый гид об этом.

Если вкратце:

  1. Начните новый проект в консоли Google.
  2. Затем вас попросят выбрать инструмент или платформу для создания приложения для Assistant. Как я и сказал, это будет Dialogflow. Если вы сделаете все верно, ваши приложения Actions и Dialogflow будут соединены. Вы можете проверить это в настройках агента Dialogflow:

Агент Dialogflow

Первой большой частью вашего приложения станет агент для разговоров, в нашем случае он будет создан на платформе Dialogflow. Его самая важная роль – понять, что пользователь говорит приложению, и определить свойства, которыми может управлять наш код. Именно это делают Dialogflow Intents.

Согласно документации:

Intent (намерение) представляет собой связь между тем, что сказал пользователь, и действием, которое должно выполнить приложение.

Давайте определим наши намерения. Вот список предложений, которые мы хотим учесть:

Стандартный запасной вариант

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

welcome_user

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

— Config — 

Название действия: input.welcome

События:  WELCOME, GOOGLE_ASSISTANT_WELCOME  
(события - это дополнительные сопоставления, которые позволяют вызывать намерения по имени события вместо пользовательского запроса).

Выполнение: ✅ Use webhook - событие welcome_user будет отправлено в бэкенд.

log_water

Событие используется, чтобы сохранить, какое количество воды хочет записать пользователь во время диалога. Будет несколько вариантов, которыми мы хотели бы управлять одинаково. Вот некоторые из них:

 

  • Окей, Google, сказать WaterLog записать 1 литр воды – событие происходит сразу же, как только пользователь вызывает действие. В этом случае приветствие пропускается. Подробнее о вызове ассистента вы можете найти в документации.
  • Записать 500 мл воды – может быть сказано в середине диалога, когда приложение ждет ввода данных.
  • 500 мл – как ответ на вопрос ассистента.

 

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

Кроме того, нам необходимо комментировать фрагменты наших примеров, которые нужно обрабатывать особым образом, так наше приложение узнает нужное высказывание. Например: “Я выпила 500 миллилитров воды”. Высказывание содержит количество и единицы объема выпитой воды. Всё, что нам нужно сделать, это выделить фрагмент и выбрать нужный объект (смотрите документацию).

— Config — 

Название действия: log_water

Что говорит пользователь (должно быть больше примеров, особенно для сложных приложений:


Выполнение: ✅ Use webhook

Google Assistant: ✅ End conversation - выберите это действие, чтобы Assistant знал, что здесь нужно закончить диалог.

get_logged_water

Событие, которое пользователь использует, чтобы узнать сколько воды он или она выпили в текущий день. Как и в случае log_water, есть несколько способов вызвать это событие:

 

  • Окей, Google, спросить WaterLog, сколько воды я выпил сегодня? – вызывать вместо приветственного события, когда действие известно;
  • Сколько я воды я выпила? – задается в середине беседы с приложением.

 

— Config — 

Название действия: get_logged_water

Что говорит пользователь:


Выполнение: ✅ Use webhook

Google Assistant: ✅ End conversation.

Это все для конфигурации Dialogflow. Если вы хотите увидеть полный файл конфигурации, вы можете скачать его и импортировать в агент из репозитория (WaterLog.zip).

Код

Если вы следовали гиду Google (Build fulfillment), у вас уже должна быть базовая структура кода, развернутое выполнение в облачных функциях Firebase и связь с агентом Dialogflow через конфигурацию выполнения.

Теперь давайте создадим код для приложения WaterLog. Репозиторий с финальным решением доступен на GitHub.

По сути нам нужно определить все Intents в приложении Dialogflow. Мы определим их в файле functions/assistant-actions.js:

module.exports = {
 ACTION_WELCOME: 'input.welcome',
 ACTION_LOG_WATER: 'log_water',
 ACTION_GET_LOGGED_WATER: 'get_logged_water'
};

Ядро нашего приложения – файл index.js, который также вызывает HTTP для Firebase Cloud Function (конечная точка):

//...
firebase.initializeApp(functions.config().firebase);
exports.waterLog = functions.https.onRequest((request, response) => {
 //Инициализировать зависимости приложений
 const dialogflowApp = new DialogflowApp({request, response});
 const userManager = new UserManager(firebase);
 const waterLog = new WaterLog(firebase, userManager);
 const conversation = new Conversation(dialogflowApp, userManager, waterLog);

//Определить схему Dialogflow Intents
 let actionMap = new Map();
 actionMap.set(Actions.ACTION_WELCOME, () => conversation.actionWelcomeUser());
 actionMap.set(Actions.ACTION_LOG_WATER, () => conversation.actionLogWater());
 actionMap.set(Actions.ACTION_GET_LOGGED_WATER, () => conversation.actionGetLoggedWater());
 
 //Принять запрос от Dialogflow 
 dialogflowApp.handleRequest(actionMap);
});

В нашей облачной функции мы определим связи Intents с функциями, которые должны быть вызваны для окончания беседы. Как пример рассмотрим conversation.actionLogWater()(выполнение намерения log_water).

const ARG_WATER_VOLUME = 'water_volume';

//...
class Conversation {
 
 //...
 
 actionLogWater() {
 //Получить аргумент из Dialogflow
 let waterToLog = this.dialogflowApp.getArgument(ARG_WATER_VOLUME);
 //Сохранить записанную воду в Firebase Realtime Database
 this.waterLog.saveLoggedWater(this._getCurrentUserId(), waterToLog);
 //Загрузить сумму воды для пользователя и ответить, 
 //сколько воды он/она записали. 
 //Закончить диалог.
 return this.waterLog.getLoggedWaterForUser(this._getCurrentUserId())
 .then(loggedWater => {
 this.dialogflowApp.tell(
 util.format(Str.WATER_LOGGED_NOW,
 waterToLog.amount,
 waterToLog.unit,
 loggedWater
 )
 );
 });
 }
}

Что происходит:

  1. Приложение получает аргумент, выделенный из высказывания Dialogflow. Для входных данных Записать 500 мл воды мы получим объект {“amount”:500,”unit”:”ml”} .
  2. Приложение сохраняет эти данные в базу данных Firebase.
  3. В конце приложение получает сумму записанной воды и отправляет её как ответ в объект dialogflowApp. Функция tell() отвечает пользователю и закрывает беседу (документация).

Полный код класса Conversation: conversation.js.

Остальное код не делает ничего интересного. Класс conversation несет ответственность за управление вводными данными пользователя. WaterLog сохраняет данные и извлекает их из базы данных Firebase. UserManager добавляет несколько хелперов для (анонимного) управления пользователями.

Юнит-тестирование

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

Все юнит-тесты для наших классов можно найти в директории functions/test/. В этом проекте тесты не были сложными (они используют библиотеки sinon.js и chai без расширений), но они во многом помогли сделать приложение за короткий срок.

Вот результат $ npm test :

Conversation
 actionWelcomeUser
 ✓ Should create new anonymous user
 ✓ Should greet new user
 ✓ Should greet existing user
 actionGetLoggedWater
 ✓ Should tell about logged water for given user
 actionLogWater
 ✓ Should save given amount of water and response with saved value

Cloud Functions
 waterLog

UserManager
 isFirstUsage
 ✓ Should return first usage when user doesnt exist in DB
 ✓ Shouldnt return first usage when user exists in DB
 saveAssistantUser
 ✓ Should save assistant user into DB
 ensureAuthUser
 ✓ Should authenticate anonymous user when user isnt authenticated
 ✓ Should return authenticated user

WaterLog
 saveLoggedWater
 ✓ Should save logged mililiters of water
 ✓ Should save logged liters of water
 getLoggedWaterForUser
 ✓ Should load logged water for given user and present data from recent day



14 passing (44ms)

Полный исходный код приложения с Firebase Cloud Functions, конфигурацией агента Dialogflow и необходимыми для распространения приложениями активами можно найти на GitHub.

 

Анна Гуляева
Комментарии Facebook
Продолжить чтение




Календарь

ноябрь

17ноя - 19Весь деньТИЛТЕХ МЕДХАК

24ноя - 26Весь деньWhat the hack?!

25нояВесь деньSmart Taler 2017

25нояВесь деньLadies Code: время технологий

30нояВесь деньSmart Cars & Roads 2017

декабрь

5дек18:30- 22:00Яндекс изнутри: глазами iOS-разработчика

8дек - 9Весь деньКубок СTF России

9дек - 10Весь деньGames Gathering 2017

9декВесь деньЛекционный день по игровой индустрии

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Наш Facebook

Популярное

X

Спасибо!

Теперь редакторы в курсе.