Connect with us

Статьи

Платежи в приложении через Google Pay: почему это важно

mCommerce становится еще привлекательней.

Surf

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

/

     
     

Владимир Макеев (Surf) поделился с нами своими мыслями по поводу запуска платежной системы Android Pay в приложениях.

На этой неделе произошло важное для m-commerce событие. Google позволил оплачивать физические товары картой, привязанной к Pay.

Почему этого не было раньше?

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

Почему сейчас все плохо?

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

pay-easy-online2

Так что сделал Google?

Покупки можно будет оплачивать «в один клик» картой, привязанной к Google Pay. Данные банковской карты при этом хранит Google. Больше не нужно договариваться с банками и платежными агрегаторами или получать PCI-DSS, а интеграция перестает быть громоздкой и будет занимать один день. Этим Google отнимает у банков комиссию в 1-2% со всех продаж в приложениях.

Когда это можно начать использовать?

Сейчас платежи через Google Pay доступны только в США. Google обещает в 2016 запустить сервис в Австралии и других странах. Надеюсь, к 2017 это дойдет до России.

mCommerce становится еще привлекательней.

Surf
Комментарии Facebook
Продолжить чтение
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Статьи

Применение инженерного подхода к собеседованиям

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

Анна Гуляева

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

/

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

  1. Какова ваша цель при проведении собеседования?
  2. Как вы оцениваете достижение этой цели?

Какова ваша цель при проведении собеседования?

От некоторых рекрутеров я слышал фразу “Хм, я не совсем знаю, кого мы ищем”, но обычно многие делятся на такие категории:

  1. Найти лучшего человека.
  2. Понять, подойдет ли кандидат для компании.
  3. Оценить, как хорошо кандидат сможет справляться с той работой, на которую он хочет попасть (это довольно редкий ответ).

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

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

Как вы оцениваете достижение цели?

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

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

Это лучше, чем ничего, но есть и вторая часть уравнения. Что насчет людей, которых вы не нанимаете? Люди часто говорят, что менее рискованно отвергнуть хорошего кандидата, чем нанять плохого, но я думаю, что это бессмысленно. Я постоянно слышу, что лучшие компании жаждут талантливых разработчиков и что на рынке труда их сложно найти, но те же самые компании отвергают множество людей, потому что они не там учились или они не так быстро решили тестовое задание. Даже если вы думаете, что менее рискованно сократить (и так уже маленький) пул людей, которых вы нанимаете, чем нанять неправильного человека, вам стоит быть уверенными, что вы ищете среди правильной группы людей.

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

Проведите ваше собеседование на существующих сотрудниках

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

Составьте “набор для оценки”

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

У этого подхода есть несколько проблем:

  1. Он необъективен к людям, у которых нет GitHub/Twitter/блога или другого присутствия онлайн.
  2. Существует много кандидатов, которые не умеют программировать, поэтому нахождение проблем в процессе собеседования может занять время.

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

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

Заключение

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

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

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

Разработка

Почему не надо патентовать идею мобильного приложения

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

AppCraft

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

/

Автор:

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

В этой статье мы тезисно перечислим причины этого не делать.

Что такое патент

Патент – это охранный документ, удостоверяющий исключительное право, авторство и приоритет изобретения, полезной модели либо промышленного образца. В случае с разработкой мобильного приложения, являющегося программным обеспечением, получить патент в России и Европе на алгоритмическую часть (непосредственно программу) не удастся: статья 52 европейской патентной конвенции прямо запрещает патентование программ для ЭВМ.

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

Это долго и дорого

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

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

Вы потратите минимум 50–100 тысяч рублей (если часть работы будете делать самостоятельно) и не меньше 3–4 месяцев, если делать все очень быстро.

После этого вы можете получить отказ на регистрацию от патентного бюро, потому что описание недостаточно детальное, не содержит инновационности, дублирует уже существующие патенты и т.д. Только 56% патентов регистрируется, соответственно, 44% – отклоняется.

При этом, по статистике, 97% (!) патентов генерируют прибыли меньше, чем стоимость их оформления.

Вы патентуете не то, что нужно

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

Пол Грэм, один из известнейших предпринимателей в IT и основатель Y Combinator, говорит, что по его опыту от 70 до 100% проектов имеют разные ключевые идеи на старте и через 3 месяца операционной работы.

Так происходит из-за того, что бизнес – это решение реальных проблем. Он развивается и растет в синергии с потребностями людей, которые:

  1. вам досконально неизвестны на стадии идеи;
  2. меняются со временем;
  3. решаются так, как хочется им, а не вам.

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

Забывается главное

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

Фокусируясь на защите идеи, вы сразу же отстаете в скорости ее развития и реализации.

Патент – не единственный способ защититься

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

  • Купите домен с именем продукта. Хорошее имя дает сильный эффект, а при решении любых споров покупка вашего домена в более ранний срок, чем оформление торговой марки конкурента, решает многие вопросы.
  • Создайте группы в социальных сетях с названием проекта. Как и в случае с доменом, хорошие названия имеют и хорошие поисковые позиции, и неплохо запоминаются, и становятся недоступны конкурентам.
  • Зарегистрируйте торговую марку. Это не быстро в некоторых юрисдикциях (например, в России), но во многих странах осуществляется в течение нескольких дней и с минимальными затратами.

Итого

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

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

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

Разработка

Программное обеспечение 2.0

Руководитель отдела искусственного интеллекта в Tesla Андрей Карпатый рассказал, почему нейронные сети — это не просто новый вид программного обеспечения, а совершенно новый этап в развитии вычислительной техники.

Анна Гуляева

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

/

Иногда люди называют нейронные сети просто “ещё одним инструментом в наборе машинного обучения”. У них есть плюсы и минусы, они могут работать здесь или там, и иногда вы можете использовать их в соревнованиях Kaggle. К сожалению, эта интерпретация упускает нечто большее. Нейронные сети — это не просто ещё один классификатор, они представляют  фундаментальный сдвиг в том, как мы создаем программы. Они — Программное Обеспечение 2.0.

“Классический стек” программного обеспечения 1.0 — это то, с чем мы уже давно знакомы, он написан на языках вроде Python, C++ и так далее. Он состоит из четких инструкций для компьютера, написанных программистами. С каждой строкой кода программист указывает определенную точку в программном поле с нужным поведением.

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

Что читать, смотреть и где учиться машинному обучению

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

ПО 2.0 не заменит ПО 1.0 (большое количество инфраструктуры 1.0 необходимо для обучения и “компиляции” кода 2.0), но оно будет выполнять большую часть задач, за которые сегодня отвечает ПО 1.0. Давайте рассмотрим некоторые примеры этого перехода:

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

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

К речевому синтезу традиционно подходили при помощи различных механизмов сшивания, но сегодня современные модели представляют собой большие сверточные сети (например, WaveNet), которые генерируют выходной аудиосигнал.

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

Робототехника имеет давнюю традицию разбивать проблему на блоки восприятия, оценки поз, планирования, управления, моделирования неопределенности, используя явные, а не промежуточные представления и алгоритмы. Мы еще не совсем достигли это, но исследования в UC Berkeley и Google намекают на то, что ПО 2.0 может значительно улучшить работу всего этого кода.

Игры. Игровые программы существовали долгое время, но AlphaGo Zero (сверточная сеть, которая смотрит на состояние доски и делает ход) стала самым сильным игроком в игре. Я ожидаю, что мы увидим очень похожие результаты в других областях, например, в Dota 2 или StarCraft.

Искусственному интеллекту для игры в Го больше не нужны люди

Вы могли заметить, что множество ссылок включают работы Google. Это потому, что сейчас Google переписывает большую часть своей инфраструктуры на Код 2.0. Подход “Одна модель, чтобы править всеми” показывает, как это может выглядеть, когда статистические мощности отдельных областей объединены в одно непрерывное понимание мира.

Преимущества программного обеспечения 2.0

Почему мы предпочитаем переносить сложные программы в Software 2.0? Ясно, что простой ответ заключается в том, что они просто лучше работают. Тем не менее, есть много других причин, чтобы предпочесть этот стек. Давайте рассмотрим некоторые преимущества Software 2.0 (то есть, нейронных сетей) по сравнению с Software 1.0 (то есть, базой кода C++ на уровне продакшена). Программное обеспечение 2.0:

Гомогенно в вычислениях. Типичная нейронная сеть на первом уровне состоит только из двух операций: матричного умножения и приведения к нулю (ReLU). Сравните это с набором операций в классических программах, который является более разнородным и сложным. Поскольку вам нужно обеспечить реализацию Software 1.0 только для небольшого числа основных вычислительно простых элементов (например, умножения матрицы), то в этом случае гораздо проще гарантировать производительность.

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

Постоянная производительность. Каждая итерация типичного прохода нейронной сети занимает одинаковое количество FLOPS. По сравнению с разными путями выполнения C++ кода, у нейронных сетей нулевая изменчивость в производительности. Разумеется, у вас могут быть динамические вычислительные графы, но поток выполнения, как правило, все еще значительно ограничен. Таким образом, мы также почти гарантированно никогда не оказываемся в бесконечных циклах.

Постоянное использование памяти. В ПО 2.0 отсутствует динамически распределенная память, поэтому утечки памяти, которые вы должны выискивать в своем коде, маловероятны.

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

Высокая гибкость. Если у вас есть код на C++, и кто-то хочет, чтобы вы сделали его в два раза быстрее (пусть даже в ущерб производительности, если это необходимо), было бы очень нетривиально настроить систему под новые спецификации. Однако для ПО 2.0 мы можем взять нашу сеть, удалить половину каналов, переквалифицировать — и она будет ​​работать ровно в два раза быстрее и немногим хуже. Это магия. И наоборот, если вам нужно получить больше данных или провести больше вычислений, вы можете сразу улучшить свою программу, добавив больше каналов и переквалификацировав ее.

Модули могут объединяться в оптимальное целое. Наше программное обеспечение часто раскладывается на модули, которые взаимодействуют через публичные функции, API-интерфейсы или конечные точки. Однако, если два модуля ПО 2.0, которые были первоначально обучены отдельно, взаимодействуют, мы можем легко объединить их в целое. Подумайте о том, насколько это удивительно, если бы ваш веб-браузер мог автоматически перепроектировать низкоуровневые системные инструкции на десять шагов вглубь, чтобы повысить эффективность загрузки веб-страниц. С 2.0 это поведение доступно по умолчанию.

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

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

Ограничения ПО 2.0

Стек 2.0 имеет и свои недостатки. По завершении оптимизации у нас есть большие сети, которые хорошо работают, но нам сложно сказать, как они это делают. Во многих случаях у нас есть выбор между моделью с 90% точностью, которую мы понимаем, и моделью с 99% точностью, которую мы не понимаем.

Стек 2.0 может допускать постыдные ошибки, воспринимая предрассудки в данных для обучения, которые очень сложно обнаружить в таких больших объемах.

Наконец, мы все ещё изучаем некоторые специфические свойства этих программ. Например, существование враждебных примеров и атак показывает неинтуитивную природу этого стека.

Финальные мысли

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

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

А программное обеспечение 3.0? Он будет уже полностью зависеть от этого сильного искусственного интеллекта.

 

Анна Гуляева
Комментарии 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

Спасибо!

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