Вступление

Привет, хаброжитель! Уже довольно давно я хотел написать статью о том, как у нас в Badoo устроена автоматизация тестирования. Хотелось написать о чем-то интересном и, в то же время, полезном. Поделиться опытом, который можно было бы легко интегрировать почти в любую систему. И вот, такая тема назрела…

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

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

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

Сегодня я расскажу о том, как на Badoo устроена регистрация и верификация через Facebook и о том, как мы научили selenium-тесты ее проверять.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

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

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

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

Итак, я знаю что ты любишь Todo списки, то есть, что тебе очень нравится писать Todo списки, поэтому мне хочется, чтобы ты создал один из них, используя новый, восхитительный и питательный («nutritious» прим. пер.) Flux фреймворк, Redux! Я желаю тебе только лучшего.

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

• Цельнозерновой рендеринг на сервере
• Расширенный роутинг, богатый Omega-3
• Маслянистая асинхронная загрузка данных
• Гладкое функциональное послевкусие

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

При создании любой компании можно наделать немало промахов, которые впоследствии могут похоронить весь бизнес. В каждой сфере есть свои специфические ошибки, в том числе и в IT. На тему того, как не бегать по граблям, в Технопарке рассказал Стас Щукин, обладающий 15-летним опытом работы с IT в таких компаниях, как «Ситроникс», «Связной», Tvigle Media и А1. Кроме того, шесть лет назад Стас основал собственную компанию, разрабатывающую заказные проекты, где периодически выступает в роли подрядчика, консультанта и основного разработчика. Текст выступления читайте под катом.

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

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

Поиск готовых решений практически не дал результатов, кроме одной публикации в клубе API Яндекс.Карт. В принципе, идея лежит на поверхности: определяем принадлежность адреса к области внутри МКАД, если адрес за МКАД, то прокладываем до него маршрут и считаем расстояние. В публикации товарищи решают проблему «в лоб», они в ручную сравнивают координаты границ МКАД и адреса. Я решил сделать более универсально и использовать только API Яндекс.Карт.

Настало время подробно рассказать, как работает наша реализация алгоритма распознавания номеров: что оказалось удачным решением, что работало весьма скверно. И просто отчитаться перед Хабра-пользователями — ведь вы с помощью Android приложения Recognitor помогли нам набрать приличного размера базу снимков номеров, снятых совершенно непредвзято, без объяснения как снимать, а как нет. А база снимков при разработке алгоритмов распознавания самое важное!

Как катушка ниток помогает проектировать и собирать сложные интерфейсы

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

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

“Это унылое диалоговое окно действительно нужно?”

В этой статье я изложил главные принципы Material Design и дал советы по их воплощению. Текст написан по следам мастер-класса для разработчиков, который мы, Роботы, устраивали совместно с российским офисом Google (Think Mobile).


Когда-то все продукты Google выглядели по-разному плохо. Даже один продукт на разных платформах выглядел неконсистентно.

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

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

В функционировании любого растущего бизнеса — не только в IT, но и в других областях — наступает момент, когда заброшенные в дальний угол и уже успевшие покрыться благородной патиной проблемы становится невозможно игнорировать. Их последствия дают о себе знать в самых неожиданных ситуациях. Есть не один десяток методик, позволяющих разобраться с проблемами и заставить бизнес работать, но начинать приходится всегда с одного и того же: анализа первопричин этих самых проблем. И сегодня Роботам хотелось бы поговорить об этом — не только переведя статью о методах поиска первопричин бизнес-тренера по IT и специалиста по Agile, Scrum и Kanban Хенрика Книберга — но и рассказав о том, как Роботы исправили несколько собственных поломок.

Руководитель QA-подразделения Redmadrobot Илья Горшков рассказывает, как выбирал инструментарий для работы с тест-кейсами.

Автор оригинальной статьи Ali Mese добавил ещё 100 новых бесплатных сервисов. Все 400 потрясающих сервисов доступны здесь. И еще подборку +500 инструментов от 10 марта 2017 г. смотрите здесь.

A. Бесплатные Веб-Сайты + Логотипы + Хостинг + Выставление Счета

• HTML5 UP: Адаптивные шаблоны HTML5 и CSS3.
• Bootswatch: Бесплатные темы для Bootstrap.
• Templated: Коллекция 845 бесплатных шаблонов CSS и HTML5.
• Wordpress.org | Wordpress.com: Бесплатное создание веб-сайта.
• Strikingly.com Domain: Конструктор веб-сайтов.
• Logaster: Онлайн генератор логотипов и элементов фирменного стиля (new).
• Withoomph: Мгновенное создание логотипов (англ.).
• Hipster Logo Generator: Генератор хипстерских логотипов.
• Squarespace Free Logo: Можно скачать бесплатную версию в маленьком разрешении.
• Invoice to me: Бесплатный генератор счета.
• Free Invoice Generator: Альтернативный бесплатный генератор счета.
• Slimvoice: Невероятно простой счет.

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

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

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

Disclaimer:
Данная статья представляет собой вольный художественный пересказ-перевод первой главы книги "App Savvy
Turning ideas into ipad and iphone apps customers really want"

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


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

Google Web Starter Kit — конструктор и шаблоны для быстрой разработки отзывчивых мобильных сайтов, которые хорошо работают на любой платформе и почти в любом браузере (кроме самых старых). Такие сайты везде выглядят, как нативные приложения.

Основные особенности:

• HTML-шаблоны, оптимизированные для мобильного применения;
• отзывчивый макет для разных мобильных устройств
• руководство по стилю визуальных компонентов;
• поддержка Guilp.js (по умолчанию), Node.js, Ruby и Sass.

В данном проекте запускаем своё iOS, Android или Web приложение, а также пишем (вернее, чуть дописываем) чат бот на питоне, который управляет розетками через радио модуль, подключенный к Raspberry Pi.

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

Интересно?

Будущее — это взгляд настоящего в прошлое



Эту статью я хотел бы посвятить вопросу власти и управления Интернет-сообществом. Интернет — это особая область, специфическая. Моря и океаны, земля, воздушное пространство, космос и… Интернет. Так кому же владеть Интернетом? Разделят ли власть национальные государства под эгидой ООН, захватят ли власть корпорации, либо же Интернет будет принадлежать людям? Но если людям — то как это будет выглядеть? Анархия? Свобода пиратства? Или власть организованного гражданского общества? Я опишу два варианта развития событий. И вам решать — какой из них станет реальностью. А также расскажу о новой социальной концепции — «профократии».

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

Этот короткий пост является продолжением предыдущего, более объёмного поста об универсальной электронной карте (УЭК).

UPD от 29.04.2013: Купил кард-ридер и почти получил ЭЦП. Оформил отдельным топиком.
UPD от 31.05.2013 Записал электронную подпись на УЭК. Новые возможности карты описал в новом топике тут.

Краткая предыстория

Оформил заявку на УЭК 9-го января 2013 года, 12-го февраля позвонили, сказали что нужно ждать ещё месяц. После месяца ожидания приехал в банк и там сказали, что ещё надо ждать. В итоге 4-го апреля мне позвонили и сказали, что можно забирать УЭК. 5-го апреля я получил УЭК.

Как выглядит реальная УЭК, какой функционал и какие проблемы

Уверен, что стоит начать с хорошего, но хорошего, если честно очень мало, поэтому опишу всё как было…