...

суббота, 21 ноября 2015 г.

Ручная верстка vs Storyboard/Nib

Большинство разработчиков для iOS знакомы со Storyboard. Apple предлагает использовать его. Но в последнее время, удобство этого инструмента вызывает у меня сомнения.

Ниже я хочу сравнить различные методологии с использованием Storyboard или набора Xib-фалов, с ручной верстой (с использованием autolayout и без). Не претендую на полноту раскрытия темы и буду рад, если вы укажете мне на ошибки и/или предложите другие методологии и критерии сравнения.

Пост не содержит экспериментов, академических вычислений и основывается на моих знаниях и опыте в области iOS разработки. Был бы рад узнать мнения экспертов!
С теми или иными оговорками, существуют следующие методологии разработки:

  • Один Storyboard и все в нем (минимум кода верстки в коде) — используется в небольших проектах; очень неудобен при разработке командой разработчиков.
  • Несколько Storyobard-ов и все в них.
  • Забываем про Storybaord, все UI-контролы помещаем в xib-файлы (см. этот пост).
  • Забываем про Storyboard и Xib, но используем autolayout — привет PureLayouts.
  • Забываем про все Storyboard/Xib/AutoLayouts и настраиваем всем View фреймы в ручную.
  • Забываем про UIKit — используем сторонние решения AsyncDisplayKit от Facebook или ComponentsKit. (Такого опыта у меня нет, поэтому ничего путного не скажу).

Storyboard и Xib

Проблемы:

  1. Код с анимациями туда не поместить.
  2. Если их несколько, то при переходе с одного на другой — создается нагрузка на main thread (NSKeyedArchiver должен распарсить сториборду, а он сам по себе медленный).
  3. Нельзя все сделать в Storybaord при все желании. Например, задать cornerRadius, shadowOffset и т.д.

Плюсы:
  1. User-story виден при просмотре.
  2. Мы абстрагируемся от типа перехода и для осуществления самого перехода достаточно знать segue identifier (см. RamblerSegues), также, при использовании автоматических dependency injection библиотек (см. typhoon), мы абстрагируемся от зависимостей.

Ручная верстка с использованием Autolayout-ов

Использовал различные тулы, наиболее, удобные — PureLayout и Cartography (для swift).

Проблемы:

  1. Больше кода (приблизительно в 1.2 раза).
  2. Ваши предложения?

Плюсы:
  1. Немного быстрей — экономим на парсинге Xib/Storyboard файла NSKyedArchiver-ом.
  2. Декларативно и все в одном месте (не нужно постоянно переключаться между Storyboard и текстом).
  3. Удобней делать анимации (например, pan).

Ручная верстка

Проблемы:

  1. При неправильной реализации — есть hardcoded-значения (при правильной, только padding-и и прочее; причем это можно вынести в отдельных header).
  2. Больше кода (приблизительно в 1.5 раза).
  3. Ваши предложения?

Плюсы:
  1. При правильной реализации все очень гибко.
  2. Работает быстрей.
  3. Можно рассчитать фреймы в background-потоке и просто их потом применить.

Итог

При отказе от каждого из [Stobyboard, Xib, Autolayout] работа усложняется и кода становится больше.

Имеет смысл не использовать Storyboard (не обязательно полностью), если:

  • Делаем сложные анимации (отпадает необходимость кидать кучу outlet-ов).
  • Время восстановления из архива становится критичным.
  • Возникает много костылей (обычно, большая их часть устраняется правильной архитектурой и/или method swizzling-ом).

Имеет смысл, требовательные к ресурсам TableView/CollectionView не делать ни в Storyboard, ни в Xib (мы теряем время на парсинге файла, теряем гибкость). При оптимизации, можно сначала сверстать с использованием autolayouts, но если лаги не проходят — замерить в инструментах, убедиться, что именно layout-ы тормозят, и потом уже переходить на ручной счет.

Иногда, похожее содержимое необходимо отображать как в TableViewCell так и в CollectionViewCell. При ручной верстке это не будет проблемой. А при использовании Xib-а решается, например, так: содержимое ячейки верстаем в xib-файле, а в init-е ячейки вызывать addSubview с данным view.

Буду рад комментариям!

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Новые кнопки «твитнуть» или прощай счётчик

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

Речь идёт об API расположенному по адресу: http://cdn.api.twitter.com/1/urls/count.json. Раньше, передав нужный url, можно было получить число твитов/ретвитов, в которых содержится ссылка на этот url. С сегодняшнего дня вместо привычного json, API возвращает ошибку 404.

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

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

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

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Вредоносное ПО для Android становится все более изощренным

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

Распространяется adware, о котором идет речь, вполне испытанным среди злоумышленников способом: перепаковываются обычные приложения от Twitter, Facebook или даже Okta (сервис двухфакторной аутентификации). Эти приложения с трояном загружаются не в каталог Google Play, а на сторонние ресурсы/каталоги, многие из которых также весьма популярны. С точки зрения пользователя, который пытается скачать какое-то из троянизированных приложений, все хорошо, при этом во многих случаях программа после установки работает, как нужно. Но во время установки на телефон жертвы устанавливается и мощное приложение-троян, которое использует эксплоиты для получения рута. Эксплоиты, найденные в трех семействах таких приложений (Shedun, Shuanet, и ShiftyBug) позволяют устанавливаться зловреду в качестве системного приложения с соответствующим статусом, который имеют только системные процессы.
«Для обычных пользователей получение такого вредоноса, как Shedun, Shuanet, или ShiftyBug может означать необходимость похода в магазин за новым телефоном», — говорит представитель компании по информационной безопасности Lookout, которая и занимается изучением вредоносного ПО для Android. И действительно, обычным образом удалить приложения не удастся — у них системный приоритет, поэтому не поможет ничего.

Злоумышленники, по словам экспертов, перепаковывают тысячи популярных приложений, размещая затем зараженные программы на сторонних download-ресурсах. Перепакованное ПО с упомянутыми выше троянами найдены на сайтах США, Германии, Ирана, России, Индии, Ямайки, Судана, Бразили, Мехико, Индонезии. Информации о том, что зараженные приложения попали в Google Play, пока нет.

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

Сейчас одна из разновидностей упомянутых выше приложений получила возможность загружать на телефон жертвы adware, даже если тот отказывается от установки, нажимая на соответствующую кнопку. Эта программа также относится к семейству Shedun, adware, распространяющихся уже указанным выше способом. Зловред обманывает жертву, используя Android Accessibility Service. После установки на телефон программа получает возможность показывать всплывающую рекламу со ссылками на adware. Даже, если пользователь отказывается от установки, Shedun, используя Accessibility Service, устанавливает adware.

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



P.S. Мы проводим второй этап акции специально для читателей Хабра. Пост с подробностями тут.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] Копают только вниз

Здравствуйте, уважаемые читатели.

В последнее время нас заинтересовала серия Зеда Шоу "The Hard Way", которую хотелось бы как минимум частично перевести на русский язык. Поскольку порой мы действительно не ищем легких путей, начать хотелось бы с книги о языке C:

Серия ориентирована в первую очередь на начинающих. Для тех, кто любит язык C, а также для их оппонентов, полагающих, что лучше стартовать с чего-нибудь попроще, мы публикуем немного сокращенную статью Эвана Миллера, написанную в конце прошлого года. Возможно, в зависимости от реакции на эту статью, мы решим дополнительно перевести и опубликовать отрывок из книги мистера Шоу либо даже его ответ на критику, высказанную Тимом Хентенааром, а пока приглашаем вас под кат, где, как нам представляется, изложены самые общие соображения в пользу актуальности этой книги.
Когда я учился водить машину (мне тогда было чуть больше 15), мама настаивала, чтобы я практиковался на отцовской Mazda Miata: это был серебристый двухдверный кабриолет с откидным верхом.

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

«Миата» отнюдь не была и самой безопасной машиной, причем компания «Mazda Motor Corporation» даже не пыталась утверждать обратное. Это была просто доступная машина, на которой приятно кататься, такая бюджетная BMW. Помню, отцовская «Миата» была такой узкой и приземистой, что когда я ездил на ней по федеральной магистрали, даже закрадывались мысли: «А если я попытаюсь проскочить на ней под полуприцепом, дальнобойщик что-нибудь заметит»?

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

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

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

С тех пор прошло много лет, и я заметил интересную закономерность. Мы, гордое меньшинство — закаленные мастера ручной передачи — оказались гораздо более умелыми, чем те, кто привык полагаться на коробку-автомат. Мы увереннее владели машиной, лучше представляли себе, как работает двигатель автомобиля. Даже если нам ни разу не доводилось заглянуть внутрь коробки передач, мы знали, что такое «повышающая передача» в автоматической коробке, как с ее помощью экономить бензин. Мы знали, что означают таинственные цифры 1 и 2 под надписью «Drive», какую службу они могут сослужить, когда съезжаешь по склону. И в каждый момент времени мы, вероятно, на интуитивном уровне лучше представляли себе, что происходит с машиной — лучше, чем приверженцы автоматической коробки.

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

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

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

Высказывая это мнение, я оказываюсь в меньшинстве, поэтому тем более хочу пояснить здесь мою точку зрения. Не так давно Python потеснил Java в качестве самого популярного вводного языка программирования, изучаемого в университетах. Эрик Рэймонд, автор программной статьи «How To be a Hacker» рекомендует Python в качестве первого языка. Его безусловно поддерживает Питер Норвиг в своей знаменитой работе “Teach Yourself Programming in Ten Years”. Пол Грэм даже рассказывает о специфическом «Парадоксе Python».

В наши дни, если вы увидите рекламу в духе «Как научиться программировать за X недель» — можете быть практически уверены, что вам предложат изучить Python.

Вопреки поверхностной привлекательности Python — его синтаксиса, интерактивности, библиотечной поддержки, широкого сообщества и превосходной документации — выбирая его в качестве первого языка программирования, вы сталкиваетесь с серьезной проблемой. Программист, знающий только Python, не обладает достаточными представлениями о работе компьютера. Он может воспринимать C в качестве мистического искусства, вызывающего смешанные чувства страха и неприязни. Страха — потому что программисту рассказали, что C сложен, а неприязни — потому, что сложности C якобы являются морально устаревшими пережитками более аскетичных времен. Появился даже новый трюизм: «человеческое время ценнее процессорного».

Но Python и C — не просто альтернативы друг другу, где один язык — более медленная и удобная замена другому. Python также нельзя считать безусловным технологическим прогрессом по сравнению с С. Лучше воспринимать Python и C как языки, сосуществующие в самостоятельных параллельных срезах реальности, где C на уровень ближе к машине.

Пол Грэм подобрал красивую метафору (как всегда, правда?) о потенциале языков программирования, который он описывает в качестве своеобразного вертикального континуума. Языки с минимальными возможностями расположены внизу, с максимальными — вверху. Где-то посередине находится гипотетический язык Blub, который чуть менее чем полностью напоминает C. Грэм считает, что пользователи Blub будут презирать все языки, лежащие ниже Blub в этом континууме — Cobol, машинный язык, т.д. — и просто не смогут понять возможности тех языков, что лежат выше.

Это великолепный образ, но давайте рассмотрим данную метафору с другой стороны. Возможно, Python лежит выше C, а Lisp подобен вишенке на торте абстракций, но изучение Python или Lisp не слишком помогает понять, как именно работает компьютер, на котором зиждется этот континуум. Таким образом, несмотря на то, что Lisp-программисты кажутся всеведущими небожителями, в иерархии языков программирования заглянуть «вниз» ничуть не проще, чем «вверх».

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

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

Беда в том, что равно как Lisp кажется вычурным и избыточным среднему Blub-программисту, так и C производит аналогичное впечатление на питонщика. Что это за указатели, о которых все говорят? «Звучит мудрено (размышляет питонщик) и если я до сих пор как-то работаю без этих указателей, обойдусь без них и дальше».

Поэтому питонщики в большинстве своем никогда не станут изучать C.

Бесспорно, можно сделать долгую и успешную карьеру в IT, не зная C. Однако культура программирования без изучения C дает ряд порочных эффектов, которые непосредственно связаны с тем, что человек знакомится с программированием на примере Python.

Во-первых, все меньше и меньше людей, способных писать превосходные программы. Чтобы отлично программировать — для ПК, мобильных устройств, инопланетных кораблей — вы должны четко представлять, как компьютер и операционная система функционируют на самом низком уровне. Сколько структур данных умещается в кэш процессора? Почему код работает медленно, а встроенный профилировщик утверждает, что быстро? Когда я приказываю операционной системе что-либо сделать, что она действительно делает? Думаю, все эти вещи можно вызубрить, но ничто так не помогает приобрести необходимую интуицию, как написание и оптимизация большого количества кода на C.

Вы можете возразить, что в данный исторический момент важнее написать больше программ, чем больше качественных программ. Возможно, с экономической точки зрения так и есть. Технологии развиваются очень быстро, незачем писать филигранно сработанную программу, которая никому не нужна. Но культура «просто используй Python», «компьютеры сейчас достаточно быстрые» и «пусть проблему решает железо» приводят к глубокому системному кризису: когда в профессию входят через Python и третируют C, все меньше настоящих умников будут попадать в профессиональное программирование.

Умерьте гнев на минуточку и выслушайте мои аргументы.

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

Второй механизм описала моя знакомая, которая недавно записалась на воркшоп по Python. Она сказала, что с большим удовольствием учила циклы и функции. Они были маленькими, понятными, самодостаточными. Но потом преподаватель решил продемонстрировать «всю мощь Python» и потратил оставшуюся часть занятия на написание какой-то бесполезной программки с Python Twitter API.

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

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

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

**
Мотивация программиста бывает двоякой: либо как можно лучше решить задачу, либо понять, как работают те или иные вещи. Бесспорно, Python отлично подходит для решения задач. Об этом свидетельствует популярность Python на стартапах и университетских курсах (в том числе, по Data Science). Если вы собираетесь за всю жизнь изучить только один язык программирования, то Python — надежный, эффективный и разумный выбор.

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

В этом, полагаю, и заключается реальная проблема с «программированием без C» — а также с более глобальной идеей о том, что вводные языки программирования должны быть «выразительными» и «доступными для начинающих». Гильдия программистов теряет как раз тех людей, которые могли бы собой ее украсить.

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

Вкратце остановлюсь и на том, почему в университетах преподают именно Python (а раньше преподавали Java). Основная причина в том, что задача университетов – не в том, чтобы воспитывать программистов-асов. На большинстве факультетов стараются просто подготовить как можно больше успешных выпускников, которые пойдут в аспирантуру или найдут высокооплачиваемую работу. Ни то, ни другое не требует исключительного программерского мастерства.

С точки зрения преподавателя, язык программирования — это материал, на котором нужно изучить основы информатики: алгоритмы, структуры данных и т.д. Python — золотая середина, поскольку его легко изучить (профессора довольны), а еще он используется в коммерческих проектах (профессора просто ликуют). Добавьте сюда популярность Python в университетах, изобилие онлайновых материалов, а также повсюду цитируемое (и редко оспариваемое) утверждение, что Python — «хороший учебный язык». Ну что с ним может пойти не так?

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

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

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

Итак, если вы хотите научиться мастерски программировать — на любом языке — то не поддавайтесь на уговоры изучать Python или, упаси Бог, Lisp, а начинайте путь с C. Сверху открываются шикарные виды, но если вы хотите покорить гору, то взбираться на нее лучше всего снизу.

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

пятница, 20 ноября 2015 г.

Тревел-стартапы. Как программистов на триллионный рынок заманивают: кофаундеры, вакансии, хакатоны

image

Яндекс, Рамблер, Qiwi очертили флажками территорию в области тревел-сервисов. Движуха вокруг рынка путешествий набирает обороты, и многие не стесняются и используют выражение next big thing.

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

В качестве ДЗ — эта статья, чтобы за 10-20 минут понять, что востребовано в мире и какие ИТ-специалисты нарасхват.

Вот только некоторые идеи для тревел-стартапов, которые я нашел в ходе подготовки статьи: Uber для парусников, Airbnb для лодок, экскурсоводы-волонтеры, мобильные путеводители и ассистенты, билеты и заселение в последний час по скидкам, расшаривание своих маршрутов, нетворкинг для предпринимателей во время путешествий, виртуальный инкубатор тревел-стартапов, зарабатывание очков за поселение гостей, каршерринг для путешественников, уникальный User eXperience во время путешествий, гастрономические фичи, покупка товаров duty-free еще до прохождения паспортного контроля, дополненная реальность (владельцы смартфонов могут увидеть исторические достопримечательности такими, какими они были изначально), железячные стартапы (прикручивание GoPro к смартфону), кроссхостельские услуги и пр.

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

Тревел-стартапы

Y Combinator
Из 700 стартапов Y Combinator я откопал 9 тревел-стартапов:

  • 2015 Chariot — сервис для перевозок, пользователи которого могут самостоятельно организовывать новые маршруты.
  • 2014 Rocketrip — уменьшаем траты в дороге, повышаем культуру сотрудников. Персонализированные командировки.
  • 2014 FlyteNow — Uber для пилотов.
  • 2013 FlightCar — не плати за парковку в аэропорту, а сдай машину в аренду.
  • 2012 FlightFox — платформа-маркетплейс для краудсорсингового поиска авиабилетов.
  • 2011 Whereberry — помогаем сохранить список того, что вы планируете сделать в городе.
  • 2009 Flightcaster (Exited) — предсказывает задержки рейсов.
  • 2009 Adioso — приложение для поиска и бронирования.
  • 2009 Airbnb — без комментариев.

Топ-листы

Вакансии


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

image
Travel Startups Incubator. Global travel technology incubator.
CTO ($1,000-$3,000/month), 20-40 hrs/week, New York City. Node JS, Python/Django, Redis, PostgreSQL, MongoDB.

imageWanderu. Travel for the next generation.

  • Javascript Front-end Engineer ($80k — $120k) Full Time, Boston. Python, Javascript, jQuery, Django
  • DevOps Engineer ($80k — $110k) Full Time, Boston. Python, Cloud Computing, MongoDB, Node.js
  • Full Stack Engineer ($70k — $130k) Full Time, Boston. Python, Java, Javascript, noSQL

image
Zupp. Carpooling mobile application
Android Developer, Backend Engineer (₹500k — ₹1500k), Full Time, Mumbai.

image
MeTripping Technologies. The holy grail of travel — travel inspiration, trip planning & trip management
Founding Team Full-Stack Developer (₹0k — ₹1200k) Full Time, Bangalore. Python, C++, Java, Javascript.

imageTripoto. The Global Community of Travelers (Tripadvisor 2.0 — Interactive, UGC Itineraries)

  • CTO ($30k — $70k) Full Time, New Delhi. Consumer Internet, Mobile Development, Web Applications, Mobile Application Development
  • Android Developer ($6k — $40k) Full Time, New Delhi. Android, Mobile Application Development
  • IOS Developer ($6k — $40k) Full Time, New Delhi.

imageRoadtrippers. Travel planning platform. Discovery, booking, and navigation all from the map

  • Mobile Developer iOS ($60k — $90k) Full Time, Cincinnati. Objective C, Android, iOS Development, Mobile Application Development
  • Full Stack Web Developer ($70k — $130k) Full Time, Cincinnati. Javascript, CSS, Node.js, Ruby

image
Oh Hey World. Open source location sharing platform

  • Community Builder ($12k — $24k) Contract, Seattle. Remote OK, Community Evangelism, Community Building, Community Outreach
  • Junior Web Engineer Internship, Seattle. Remote OK, Ruby on Rails

image
Ace Travel.
Reinventing travel through a high tech, high touch, 21st century planning platform.
Cofounder/Head of Technology ($70k — $150k) Cofounder, San Francisco. HTML, Node.js, Drupal, HubSpot

image
Rocketrip. Smarter business travel.
Senior Full-stack Software Engineer ($90k — $160k) Full Time, New York City. Python, HTML, jQuery, Django.

imageHeadout. HotelTonight for Tours & Travel Experiences

  • Software Engineer — Front End (₹1000k — ₹2500k) Full Time, Bangalore. Javascript, Graphic Design, HTML, CSS
  • Lead iOS Developer (₹1500k — ₹3000k) Full Time, Bangalore. Objective C, Javascript, HTML, CSS
  • Software Engineer — Full Stack (₹1000k — ₹3000k) Full Time, Bangalore. Java, Javascript, HTML, CSS

image
Zipkick. Personalize travel plans, instantly
CTO Cofounder, San Francisco. Back End Programming, Mobile Development, Databases, Front-End Development.

[Источник]

Хакатоны (прошедшие)

Emirates

294 hackers | 24 hours | 57 hacks
ТЗ: создать веб или мобильное приложение на любом языке и под любую платформу. Продукты должны быть в рамках тематики путешествий.
Сайт
Фотки с хакатона

Sabre Travel Network & 33entrepreneurs

£10,000 Grand Prize
Критерии оценки: Technical Quality: 25%, Design: 25%, Potential: 25%, Originality: 25%
ТЗ: Сделай что угодно (сайт, приложение, железяку), что «перевернет» рынок или способ путешествий.
Сайт

Skypicker and Tripomatic

ТЗ: создай рабочий прототип используя API big data от Skypicker и Tripomatic.
Сайт

Островок

Конкурс на создание рекомендательной системы. Приз — 15 000 руб (и три поощрительных приза по 5 000 руб)

#tceh
26 ноября мы пригласили представителей популярных российских туристических онлайн-компаний на открытое мероприятие, чтобы найти ответ на вопрос: что делать-то будем?

Спикеры:

Захар Корнеев —руководит направлением дистрибуции и работой с аффилиатными партнёрами в одном из самых бурно развивающихся и обсуждаемых сервисов по бронированию отелей Ostrovok.ru. Долгое время работал в отельной индустрии, сейчас занимается поиском партнеров Островка по всему миру и развитием компании.

Валентин Домбровский — серийный предприниматель, ведущий алхимик Travelabs. С 2011 года развивал тревел-стартап Travelatus, прошел с ним в акселератор StartupYard, в 2013 продал проект коллегам из Excursiopedia. Основатель сообщества Travel Startups и Travel Startups Intl.

СМИ про тревел-стартапы

70% опытных интернет-пользователей в России еще ни разу не пользовались услугами онлайновых туристических сервисов. Это осознали инвесторы, которые вливают многие миллионы в тревел-проекты.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Подпольный рынок кардеров. Перевод книги «KingPIN». Глава 17. «Pizza and Plastic»

Кевин Поулсен, редактор журнала WIRED, а в детстве blackhat хакер Dark Dante, написал книгу про «одного своего знакомого».

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

Квест по переводу книги начался летом в ИТ-шном лагере для старшеклассников — «Шкворень: школьники переводят книгу про хакеров», затем к переводу подключились и Хабраюзеры, и даже немного редакция.

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

Глава 17. «Пицца и Пластик»


(за перевод спасибо Ashot Ogoltsov)
На верхнем этаже небоскреба на Post Street, на полу из ламината, стоял компьютер Макса — тихий и холодный. Это была маленькая квартира, размером чуть больше тюремной камеры. Эту квартиру нашел ему Крис, и она соответствовала всем его запросам: маленькая площадь, огромное количество соседских Wi-fi сетей. Квартира была декорирована под светлое дерево, в ней стоял большой холодильник и была кровать-раскладушка, которая убиралась в стену.

Это была чистенькая квартирка площадью в 27 квадратных метров без каких-либо излишеств, где Макс скрывался после того как оставил свой пентхаус. Он получил неплохой навар с операции с Ситибанком и не занимался взломами уже несколько месяцев. Крису оставалось лишь приготовить поддельные документы для полугодовой аренды квартиры и заплатить депозит в размере 500$.

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

Как обычно он нацеливался на фродеров и для этого он разработал несколько новых методов кражи данных. Он был в курсе последних фишинговых атак, так как мониторил оповещения от организации под APWG (Анти-Фишинговая Группа www.antiphishing.org ). Оповещения включали адреса фишинговых сайтов и связанные имейлы. Этого было достаточно для Макса, чтобы проникать на сервера фишеров и перепохищать украденные данные. После чего он удалял информацию на серверах, чем крайне разочаровывал фишеров.

Другие атаки были менее нацелены, Макс всё еще входил в ряды white-hat хакеров, и присутствовал в адресатах частной имейл рассылки, где часто раскрывались 0-day уязвимости. Днями и ночами компьютеры Макса сканировали сервера в поисках уязвимостей. Однажды, Макс сканировал Windows сервер на предмет переполнения буфера и нашел то, что привело его в мир кардеров.
image

Windows сервер, который он сканировал, находился в офисе ресторана Pizza Schmizza в Ванкувере, штат Вашингтон. Он знал это место, это было неподалеку от материнского дома. Изучив содержимое компьютера, он узнал что его использовали как бэкенд для POS терминалов ресторана. С помощью этого компьютера собирались данные по транзакциям с картами, а затем, раз в день, отправлялись в процессинговый центр одним заходом. Макс узнал, что файлы, содержащие информацию по транзакциям, а также полные данные с магнитной полосы карт, были некриптованы.

Более того, на системе сохранялся бэкап всех файлов с данными по транзакциям, начиная со дня установки систему — уже 3 года. Так Макс скопировал себе данные более чем 50,000 транзакций и удалил оригинал файлов. В конечном счете ресторану эти данные не нужны, да и хранение этих данных противоречило стандартам безопасности Visa. Майк отсортировал данные, убрав дубликаты и дампы просроченных карт.

Впервые у Майка появился основной источник чистых карт, которые практически гарантировано были прибыльными. До сих пор Крис жаловался, что некоторые дампы Макса были устаревшими, больше этого не будет. Когда клиент заказывал большой, семейный пирог в Pizza Schmizza, Макс получал дамп его карты до того как остаток пирога успевал остыть.

Макс закончил очистку полученных дампов и дал Крису протестировать, заметив, что дампы очень свежи, двухдневной давности.

Теперь Крис и его команда никак не могли «переварить» те 50 дампов в день которые Макс получал с Pizza Shmizza. Макс решил предпринять первые шаги в продаже на кардинговой сцене, Крис предложил ему обеспечивать продажи дампов за 50% навара.

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

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

Со временем, Джон Джианоне (John Giannone), подросток с Лонг Айленда, стал заменой Крису. Джианоне был умным пареньком из семьи среднего сословия, он немного баловался коксом и безумно желал стать жестким киберпанк-оторвой. Делишки, которые провернул Джианоне, откровенно говоря, ничуть не впечатляли, перед кардерами он хвастался, что зажал все кнопки в лифте и следующему зашедшему в лифт пришлось останавливаться на каждом этаже. Еще он хвастался, как в банке, на форменном бланке для заявлений написал «У меня бомба, гоните деньги, либо подорву всех» и поставил в стопку пустых бланков.

В 17 лет Джианоне присоединился к Shadowcrew и CarderPlanet под руководством МаркРича (MarkRich) и стал участвовать в маленьких операциях. Его репутация запятналась, когда он попался на подделке авиабилетов, поползли слухи, что он на постоянной основе подворовывал на форуме. Отчаявшись, Джианоне заплатил более успешному кардеру за эксклюзивное право быть под его опекунством. Под ником “Enhance” подросток стал более заметным, но это не сказывалось на его успешности.

В мае 2003, он попытался повторить схему шантажа, придуманную русскими хакерами. Джианоне одолжил у одного хакера ботнет и начав DDoS-ить авиакомпанию JetBlue, положив вебсайт на каких-то двадцать пять минут. Потом он отправил в авиакомпанию имейл с требованием выплатить ему 500,000$ за крышевание в киберпространстве. Однако компания решила не платить, и даже не признала действий кибергангстера, на следующий день компания заявила, что они перешлют имейл в соответствующий правоохранительный отдел и отметили что сайт упал по причине системных апгрейдов.

Макс нашел Джианоне с помощью своей программы Free Amex, парень делал свои дела с компьютера который находился в спальне его матери. Макс и Крис просмотрели данные по Джианоне, и решили, что он годился как партнер. Крис в частности видел в парне самого себя — молодой, балующийся коксом, косящий под гангстера. Джианоне часто бывал в Оранж Каунтри, он любил там понежится на солнышке. Крис тоже начал отдыхать в Оранж Каунтри и завел дружбу с Джианоне, своему подмастерью Крис дал кличку — «Пацан» («the Kid»).

Так получилось, что Макс знал о Джианоне всё, в то время как Джианоне не знал ничего о Максе. С точки зрения Макса это было идеальное условия для сотрудничества. Джианоне продал несколько дампов предоставленных Максом, а затем представил Макса в кругу других кардеров, которые были заинтересованы в покупках используя для связи ICQ. Макс работал под ником «Generous».

Работа с незнакомцами стала большим шагом для Макса, и он предпринял все необходимое для своей безопасности. Для переписки на форуме кардеров он использовал собственную частную сеть взломанных компьютеров, это гарантировало, что как максимум его могли бы отследить до взломанной соседской Wi-fi сети, но это было бы нелегко. Для большей безопасности, Макс сменил свой стиль письма, опасаясь что, кто-либо мог найти совпадение в стиле его сообщений на кардерском форуме с багтреками или постами, оставленными от имени Макс Вижн. ФБР уже обращало внимание на copious ellipses(???) в анонимном письме, которое Макс отправлял в лабораторию Lawrence Berkeley во время BIND атаки.

Прибыль со сделок Макс получал на анонимный e-gold аккаунт, привязанный к платежной карточке. Пацан зарегистрировал бизнес аккаунт в Bank of America, для регистрации он указал компанию по ремонту автомашин — A&W Auto Clinic, затем выслал Максу дамп магнитной полоски и PIN код. Макс сделал себе дубликат с помощью MSR206 (энкодер для записи магнитных банковских карт), теперь покупатели дампов могли делать наличный вклад на счет AW Auto Clinic в любом филиале Bank of America и Макс получал деньги на клонированной карточке.
Максу не были нужны деньги, он потратил большинство обналиченных денег с операции Citibank-а на подачки бомжам и покупку робопса Sony AIBO за 1500$.

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

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

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

примечания
Chapter 17: Pizza and Plastic

1 His scanning put him inside a Windows machine: Max, Jonathan Giannone, and
Brett Johnson each independently identified the Pizza Schmizza in Vancouver,
Washington, as the source of Max’s dumps in this period. The store manager said the
restaurant has since changed ownership, and she had no knowledge of a breach.

2 Max couldn’t help feeling cheated yet again: Interviews with Max.

3 Giannone was a smart middle-class kid with a coke habit: Giannone confirmed the
cocaine use and all the details of his relationship with Max and Aragon. He discussed
the elevator button pressing and the “bank robbery” prank in a chat with another
carder, a log of which was provided to the author. Giannone confirmed in an interview
that he discussed the bank robbery hoax but said it was an idle boast, and he didn’t
actually pull it off. He said he did not recall the elevator matter.

4 Giannone joined Shadowcrew and CarderPlanet under the handle MarkRich:
Giannone’s transition through various handles was confirmed by Giannone in an
interview. Posts on the forums reviewed by the author confirm he gave up his original
handle after being suspected of informing on an associate while a juvenile.

5 launched a DDoS attack against JetBlue: Giannone also discussed this attack in
the abovementioned chat logs. He confirmed it in interviews with the author.

6 the teen was running his operations from the computer in his mother’s bedroom:
Interviews with Max.


Продолжение следует

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] Программирование на собеседованиях: Какие задачки следует давать разработчикам

Примечание переводчика: В наших блогах на Хабре и Мегамозге мы много пишем о построении облачного сервиса 1cloud, опыте по работе с инфраструктурой различных компаний и перспективных подходах к управлению ИТ-проектами.

Сегодня мы представляем вашему вниманию адаптированный перевод заметки Реджинальда Брэтуэйта (Reginald Braithwaite) из компании Pager Duty. Он написал в своем блоге материал о том, как несложные задачки на собеседованиях могут помогать находить хороших программистов, и как разработчикам следует к ним относиться.

Fizzbuzz-задачки


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

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

Напишите функцию merge, которая обрабатывает два сортированных списка и выдает сортированный список объединений элементов двух списков.


К примеру:
merge ([1, 7, 11, 17], [3, 5, 13])
  //=> [1, 3, 5, 7, 11, 13, 17]

merge([2, 3, 5, 7, 11], [2, 4, 6, 8, 10, 12, 14])
  //=> [2, 2, 3, 4, 5, 6, 7, 8, 10, 11, 12, 14]


Если использовать язык с удобной семантикой для работы со списками и особенно не задумываться об использовании памяти и общей производительности, то код решения будет простым:
function merge (originalA, originalB) {
  const merged = [],
        tempA = originalA.slice(0),
        tempB = originalB.slice(0);

  while (tempA.length > 0 && tempB.length > 0) {
    merged.push(
      tempA[0] < tempB[0] ? tempA.shift() : tempB.shift()
    );
  }
  return merged.concat(tempA).concat(tempB);
}


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

Больше сложности


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

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

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


Напишем код


В ECMAScript 2015 можно представить потоки, которые необходимо объединить, в качестве итераблов (Iterables). Мы напишем генератор, то есть функцию, которая создает значения. Генератор будет брать итерируемые элементы в качестве аргументов, и генерировать значения в корректном порядке.

Скелет кода может выглядеть так:

function * merge (...iterables) {

  // обработка

  while (our_iterables_are_not_done) {

    // найти итератор с наименьшим значением

    yield lowestIterator.next().value;
  }
}


Первая проблема заключается в обработке более чем двух итераблов. Вторая — для итерации итераблов, их нужно превратить в итератор. Тут все довольно просто — у каждого итерабла есть метод Symbol.iterator, который возвращает новый итератор для этого итерабла.
function * merge (...iterables) {

  const iterators = iterables.map(
    i => i[Symbol.iterator]()
  );

  while (our_iterables_are_not_done) {

    // найти итератор с наименьшим значением

    yield lowestIterator.next().value;
  }
}


Третья проблема посложнее: для того, чтобы выяснить, сколько значений может вернуть итератор (одно или больше) мы вызываем .next(). Но его использование удаляет значение и меняет состояние итератора.

Если мы напишем:

while (iterators.some(i => !i.next().done))


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

Так что придется написать класс адаптора итератора:

const _iterator = Symbol('iterator');
const _peeked = Symbol('peeked');

class PeekableIterator {
  constructor (iterator) {
    this[_iterator] = iterator;
    this[_peeked] = iterator.next();
  }

  peek () {
    return this[_peeked];
  }

  next () {
    const returnValue = this[_peeked];
    this[_peeked] = this[_iterator].next();
    return returnValue;
  }
}


Класс PeekableIterator «оборачивается» вокруг существующего итератора, и в дополнение к методу next, создает метод peek, который не изменяет итератор.

Теперь можно использовать PeekableIterator вместо чистых итераторов:

function * merge (...iterables) {

  const iterators = iterables.map(
    i => new PeekableIterator(i[Symbol.iterator]())
  );

  while (iterators.some(i => !i.peek().done)) {

    // найти итератор с наименьшим значением

    yield lowestIterator.next().value;
  }
}


Метод peek можно использовать и для поиска итератора с наименьшим значением. В таком случае мы возмьем итераторы, отфильтруем уже отработанные, отсортируем их по значению peek — первый итератор в списке будет иметь наименьшее значение:
function * merge (...iterables) {

  const iterators = iterables.map(
    i => new PeekableIterator(i[Symbol.iterator]())
  );

  while (iterators.some(i => !i.peek().done)) {

    const lowestIterator =
      iterators
        .filter(
          i => !i.peek().done
        ).sort(
          (a, b) => a.peek().value - b.peek().value
        )[0];

    yield lowestIterator.next().value;
  }
}


Полное решение

const _iterator = Symbol('iterator');
const _peeked = Symbol('peeked');

class PeekableIterator {
  constructor (iterator) {
    this[_iterator] = iterator;
    this[_peeked] = iterator.next();
  }

  peek () {
    return this[_peeked];
  }

  next () {
    const returnValue = this[_peeked];
    this[_peeked] = this[_iterator].next();
    return returnValue;
  }
}

function * merge (...iterables) {

  const iterators = iterables.map(
    i => new PeekableIterator(i[Symbol.iterator]())
  );

  while (iterators.some(i => !i.peek().done)) {

    const lowestIterator =
      iterators
        .filter(
          i => !i.peek().done
        ).sort(
          (a, b) => a.peek().value - b.peek().value
        )[0];

    yield lowestIterator.next().value;
  }
}


Для программистов, умеющих работать с итераторами и генераторами, здесь нет ничего сложного. Поскольку наша функция merge — это генератор, то мы можем легко итерировать ее содержимое для распределения элементов в массив. В принципе, реализация может заменять даже решение для массивом, нужно просто не забыть распределить результаты:
const primes = [2, 3, 5, 7, 11];
const evens = function * () {
  for (let n of [1, 2, 3, 4, 5, 6, 7]) {
    yield n * 2;
  }
}

for (let value of merge(primes, evens())) {
  console.log(value);
}
  //=>
    2
    2
    3
    4
    5
    6
    7
    8
    10
    11
    12
    14

[...merge(primes, evens())]
  //=> [2, 2, 3, 4, 5, 6, 7, 8, 10, 11, 12, 14]


Из плюсов здесь также наличие возможностей для дальнейшего обсуждения. Например, можно поговорить о следующих вещах:
  • Как наличие большого количества итераблов (сотни или тысячи) может повлиять на производительность?
  • Что произойдет, если у вас есть итерабл, который производит тысячи значений, а остальные производят не больше нескольких сотен? Проще говоря, что если существет обратная степенная зависимость между количеством итераблов и числом производимых ими значений?

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

А что, если я ненавижу такие паззлы?


Да, опытный кандидат, увидев подобную задачку может закатить глаза — это же «непрактичное программирование». Но является ли этот факт достаточным основанием для отказа от fizz-buzz задач на собеседованиях?

Тут можно пойти другим путем, и просто обернуть задачу в некую историю. Например:

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


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

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

Заключение


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

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

И есть вероятность, что ответ разработчика приятно удивит.

P.S. Мы в 1cloud считаем, что инженеры должны с самого начала иметь возможность понять, задачи какого уровня им предстоит решать в работе. В том числе поэтому мы подробно рассказываем о построении инфраструктуры нашего проекта в блоге на Хабре (список таких топиков представлен в конце этого материала).

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Из песочницы] Let's Twist: Путь в неизвестность

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

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

Главной задачей при создании идеи был поиск определенного издателя и целевой аудитории. Мы прекрасно понимали, что сделать что-то универсальное очень сложно. Руководствуясь ограниченностью ресурсов и времени, было принято решение сотрудничать с издателем Ketchapp, но, в тоже время, иметь пути отхода. Для этого мы предприняли попытку сочетать минималистичейский геймплей и красивый арт. Имея опыт работы с движком Unity, мы думали, что это лучший вариант. Из плюсов этого движка можно отметить быстроту разработки, графический интерфейс и кроссплатформенность.

Первый Этап


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

Скриншоты начальной версии:

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

Первоначальная версия одного из уровней:

Особое внимание хочу заострить на музыке. Начинающие разработчики могут поступить как мы: писать всем понравившимся музыкантам и спрашивать разрешение на использование их треков, с условием выдачи гонорара только в случае подписания контракта с издателем. На наши просьбы откликнулись многие. Были и те, кто запросил сумму вперед (лицензия на flat fee стоит от 300 до 500 евро). Подавляющее большинство отечественных исполнителей отнеслись к предложению более благосклонно, и выбор пал на талантливого композитора Manu Shrine, которому в итоге и посвятили игру (Вечная Память, Сергей...).

Manu Shrine
Сергей Деулин aka Manu Shrine родился и жил в городе Екатеринбурге. Писал музыку в жанрах: ambient, deep house, garage, deep dubstep, post-dubstep.



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

Думаю, мы не первые, кто столкнулся с подобным отношением, поэтому советую не останавливаться и писать всем издательствам — как отечественным, так и зарубежным — и продолжать улучшать игру насколько это возможно. В то время нас поддерживала только китайская мудрость: «Искушение сдаться будет особенно сильным незадолго до победы.” Кто бы мог подумать что это „незадолго“ растянется еще на 7 месяцев разработки.

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

  • Очень многие предвзято относятся к играм под Ketchapp. Некоторые вполне недвусмысленно писали это в письмах. Поэтому если вы делаете минималистичную игру в стиле Circe или ZigZag, будьте готовы к смене механики и усложнению геймплея.
  • Издателям Chillingo, FDG, PicPoc и Nevosoft игра очень понравилась, они расхваливали ее дизайн и атмосферу, но не решились взять под свое крыло из-за отсутствия уровней и невозможности сменить версию на платную. Трое из четырех в один голос сказали, что рынок перезаполнен, и тренд в скором времени сменится, а популярность free-to-play пойдет на спад.
  • Не надо ограничиваться только издателями. Пишите письма и обычным известным разработчикам. Многие захотели сотрудничать с нами и испытать себя в роли издателя.

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

Переосмысление


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

Основным требованием был контент. Так, игра состоящая из одного уровня и четырех элементов, разрослась в проект с 6-ю уровнями и 50 элементами, в которые входят персонажи из небезызвестных игр Darklings, Rop и Jelly Lab.

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

Режим ожидания


Первая большая задержка с релизом состоялась из-за желания добавить онлайн-составляющую для игры. Мы попали на период перехода движка Unity к новой версии и поэтому не могли воспользоваться услугами готового сервера. На самостоятельную технологию получения и отправки данных и синхронизацию с разными часовыми поясами ушло почти 2 месяца работы. Также пришлось поменять название игры на Let's Twist, так как при настройке аккаунта наше любимое название кто-то занял (ответ на вопрос о том, кто его занял, вы узнаете в конце статьи).
Тем временем...

Одновременно с Twist-ом мы разрабатывали и выпустили игру Neogen Fallout в App Store и Google Play и даже получили featuring в 46 странах на iOS платформе и продвижение в Mobango и Yandex магазинах. Какого же было наше разочарование, когда мы поняли, что даже подобный буст без вклада в маркетинг не принес финансовой стабильности, а андроид-версия заработала в 10 раз меньше „яблочной“. Думаю, это из-за того, что в игре на тот момент не было In-App покупок, а одна реклама не работает, если нет пары миллионов пользователей.


Вторая задержка состоялась по вине US Аpple. Мы сделали все по правилам и за 3 недели до релиза отправили Roadmap, на что европейский Apple ответил, что доволен игрой и даст featuring в день релиза. Однако в последний момент с нами связался американский отдел и намекнул, что если мы хотим продвижения в US зоне, то должны подождать еще полтора месяца, так как ноябрь является лучшим временем для релиза. Кроме того мы получили намек, что лучше сделать игру платной и отказаться от free 2 play модели с In-App-ми. В тот момент мы испытывали финансовые трудности, но продвижение в Америке — это мечта каждого разработчика, поэтому было принято решение сменить модель и дождаться новой даты релиза.

За неделю до релиза от Apple пришла заявка на создание Featuring Art, и мы за пару дней справились с задачей, так как понимали, что это шанс получить „Выбор Редакции“. Самым интересным был непосредственно день релиза. Не прошло и часа после нашего релиза, как в App Store появляется игра с названием Twist (издателем которой выступил Ketchapp). Совпадение? Не думаю. У них былo свыше 32 недель для релиза игры с таким названием, но даты идеально совпали. Кроме того, название было зарезервировано еще с мая месяца.

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

Выбор Редакции в 78 странах
Глобальное Продвижение в 135 странах(включая Америку и Великобританию).

Игра Let's Twist вышла 12 ноября в App Store. Старт выдался многообещающим и уже во всю ведутся работы по укреплению позиции и дорисовке нового контента. На днях будут готовы версии для Google Play и Amazon. На собранные средства мы собираемся сфокусироваться на создании полноценных Level Based играх. Спасибо за внимание. Надеюсь, статья пришлась вам по душе.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] Пиратские метрики: как создать email-кампанию по принципу AARRR. Часть 5

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

Деньги: введение


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

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

Легкий толчок: добавьте новые функции и займитесь брошенными корзинами


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

Недавно Baymard Institute провел мета-анализ данных о брошенных корзинах от огромного количества поставщиков. Среднее значение было довольно-таки высоким – 65%, то есть всего лишь каждый третий покупатель завершал заказ. Если бы вы удержали интерес половины [бросивших корзины] потенциальных клиентов, ваш доход возрос бы вдвое. Но как этого добиться?

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

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


Нашим первым собеседником стал Ноа Таубман (Noah Taubman), маркетолог, специалист по удержанию клиентов с помощью email-рассылок в MeUndies (бренд великолепного нижнего белья и одежды для дома). Мы поговорили об их брошенных корзинах.

С тех пор как MeUndies разработали свою версию писем о брошенной корзине, они тестируют каждое изменение в содержании письма, чтобы максимизировать его эффективность. Ноа говорит, что понял самое важное – и это не только знание того, какие темы [писем] нравятся людям (хотя и это тоже). Он сказал, что самым важном для них стало понимание того, что их пользователи – это умные покупатели, и, уважая их пожелания, Ноа смог увеличить общую заинтересованность и единение с брендом.

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

«Самый большой отклик получили кампании соответствовавшие нашему собственному уникальному стилю общения, который мы вырабатывали последние 2-3 года. В том числе мы полностью пересмотрели и видоизменили все типичные неэффективные кампании (например, письма о брошенных корзинах)».


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

Предполагайте лучшее


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

Есть еще одна интересная вещь в стратегии TeeSpring – у них есть ограничения по времени на решение о покупке. После того, как начинается кампания [рассылка], определяется конечная дата продажи. К сожалению, это не означает, что по истечении данного периода пользователю, оставившему заказ неоплаченным, автоматически предложат продлить акцию.

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


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

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

Не предлагайте скидку


Вы когда-нибудь звонили в компанию, предоставляющую вам услуги кабельного телевидения, пытаясь отменить подписку, а в результате получали те же услуги со скидкой 10 долларов в месяц и полгода бесплатного подключения к HBO? Затем вы оставляли себе напоминание позвонить снова и отказаться от бесплатного HBO, и все повторялось снова? Вы же не хотите быть похожими на эту компанию, не так ли?

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

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

Даже если мотивацией была цена, по словам Чада Уайта (Chad White), директора по исследованиям в Litmus: «Когда клиенты получают стимулирующие скидки, они привыкают откладывать покупки и становятся более восприимчивыми к цене».

Тем не менее, предоставление скидки – не всегда плохая идея, особенно, если вы совсем отчаялись, но рассмотрите и другие варианты (чтобы не формировать привычку у клиента). Отличный пример возврата клиента можно увидеть в письме от Instacart:

Бесплатная доставка от Instacart

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

Пусть письма будут «личными»


На тему использования ваших данных: в опросе Listrak проверили как раз то, что интуитивно кажется разумным: 71% клиентов предпочитают получать рекомендованные товары на основе того, что они ранее искали; 80% – «за» рекомендации на основе истории покупок. DonorsChoose, наш обожаемый клиент, прекрасно использует это на практике. Письма от этой компании создаются в духе ее ценностного предложения, которое гласит, что каждый может изменить к лучшему жизнь рядом с собой – вот, как это можно отразить в письме с рекомендациями проектов, которые пользователь может поддержать:

В DonorsChoose стараются использовать нестандартные приемы для оформления писем.

Нет ничего лучше, чем подарок


Говоря о благотворительности, никогда не стоит недооценивать ROI подарков (показатель окупаемости инвестиций). Этот прием работает одинаково эффективно и в SaaS, и в ecommerce. И это отличная возможность напомнить о покупках, которые ваш клиент еще не успел совершить или оплатить.

Нам нравятся примеры писем от различных брендов одежды, потому что они [письма], как правило, оформлены лучше других. Эй, SaaS-компании, включайтесь в игру и работайте над своей рассылкой!

Как превратить freemium в платную подписку?


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

Спрашивайте мнение пользователей


Один из способов заполучить потенциальных покупателей – это спросить их, что бы они хотели увидеть в вашем продукте. Поскольку им дешевле написать отзыв, чем решиться на установку [платного] обновления, вероятно, так вы больше узнаете о своих клиентах [и продвинете их вперед по воронке продаж]. Для стартапов на ранних стадиях это также отличный способ выявить возможных «евангелистов».

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

Но даже немного внимания к личности клиента поможет улучшить ситуацию:

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


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

Напомните им, что они теряют


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

Продавайте мечту


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

Письма-счета


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

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

2) Работайте над содержанием письма, не прикрепляйте к нему вложения

Пожалуйста, не присылайте свои квитанции в качестве вложенного PDF (кроме редких случаев, когда клиент заключил крупную сделку). Никто этого не любит.

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

Вложенные файлы – источник страданий

3) Используйте действующий адрес отправителя

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

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

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

4) Предложите скидку за повторный заказ

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

5) Попросите клиента написать отзыв

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

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

6) Планируйте варианты повторных покупок

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

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

Заключение


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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.