Anadea

Андрей Кутейко
March 22, 2016

     Полнотекстовый поиск - одна из самых распространённых задач, с которой придётся столкнуться при разработке сайта. Такие популярные РСУБД как MySQL и PostgreSQL уже содержат встроенные поисковые механизмы. Но, к сожалению, их реализация оставляет желать лучшего. Простая разбивка на слова не подходит для языков с флексиями, таким как русский.

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

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

Традиционная схема работы с поисковым сервером такая:

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

Если же данные обновляются (а скорее всего так и есть), то индексы нуждаются в обновлении. И тут схема далека от идеала:

программа-индексатор строит новый индекс в промежуточных файлах;
посылается сигнал поисковой службе, и она переключается на новые индексы;
старые индексы удаляются.

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

К счастью, выход есть. Sphinx предлагает такую замечательную возможность, как real-time-индексы. Основное отличие RT-индексов в том, что они не требуют индексатора и позволяют добавлять, обновлять и удалять данные обращаясь непосредственно к поисковой службе.

В традиционной схеме индексатор самостоятельно обращается к базе данных. Здесь же приложение вынуждено обновлять данные. Нельзя ли совместить эти две схемы? Нельзя ли переложить эту работу на базу данных?

Оказывается, можно. Современные РСУБД позволяют отслеживать изменения в данных и реагировать на них соответственно (так называемые триггеры). То есть заботу об обновлении поискового индекса можно переложить на триггеры.

К несчастью триггеры не могут устанавливать сетевых соединений и всю чёрную работу придётся делать в пользовательских функциях (UDF — user-defined function). В случае PostgreSQL это потребует написания разделяемой библиотеки. Можно было бы написать например на Python, но мы же хотим максимальной производительности!

От слов к делу

Расширение pg-sphinx для PostgreSQL позволяет обновлять индексы непосредственно из триггеров, хранимых процедур и любых других мест, где возможен вызов функции. Например, нижеприведённый SQL-код обновляет (или вставляет, если её ещё не было) запись №3 в индексе blog_posts.

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

Итого

Что получилось?

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

Чего не хватает? Что не реализовано?

Сделано неявное предположение, что все данные хранятся в кодировке UTF-8 и поддержка других кодировок не сделана намеренно.
Подсветка найденных слов не реализована.
Перенастройка подключения к поисковому серверу требует перекомпиляции.
Не реализованы такие функции как транзакции (сейчас AUTOCOMMIT по-умолчанию) и пользовательские функции (нужно разворачивать выражения явно).
...

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

Анна Шапошникова
December 30, 2015

I believe in teamwork, based on passion, trust and respect…

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

Мы знаем, что в разработке ПО, заказчик\бизнес сами выбирают команду по разным критериям, руководствуясь подсказками sales-менеджеров, опираясь на резюме и рейтинг её участников. В этом плане стороне бизнеса несколько проще, т. к. делая свой выбор, они так или иначе знакомятся с командой. Команде же предстоит любить заказчика таким, какой он есть, изучать его и вместе с ним строить гармоничные партнёрские отношения. Прописной истиной является то, что невзирая на тип отношений, все они будут благополучны, если построены на доверии.

Доверие же не рождается с появлением команды, а достигается в процессе. Очень эффективным средством в развитии доверия является прозрачность.

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

Давайте рассмотрим схематично взаимосвязь между прозрачностью и доверием:

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

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

Если провести параллель с романтическими отношениями, то это своего рода "конфетно-букетный период" в рабочем процессе. Таким образом, мы плавно двигаемся к точке В. Здесь заказчик всё ещё испытывает некие сомнения, но уже начинает доверять команде, т.к. на данном этапе он уже является её частью. Он знает участников, понимает уровень и возможности каждого члена команды, видит кто за что отвечает и первые результаты совместного труда.

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

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

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

Кроме доверия мы также получаем дополнительные бонусы:

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

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

Станислав Синицкий, Александр Михальченко
August 16, 2016

По версии TIOBE, Java стала языком программирования 2015 года, обойдя в гонке С, С++ и ещё 17 языков-номинантов, и по сей день не теряет позицию. Этот факт весьма занятен и интересен, учитывая 20-летний возраст языка и устоявшиеся стереотипы про него. О том, что такое Java, чем язык хорош, о мифах и реальности я пообщался с Александром Михальченко, Java-программистом в Anadea.

Привет, Саша!
Здравствуй.

По версии TIOBE индекса, Java получила звание "Языка Программирования 2015 года". Вот собственно, хотелось бы узнать, что это за зверь такой, Java?
Java - это больше платформа, нежели язык. В последнее время появляются языки, работающие в JVM, но по синтаксису отличающиеся от Java. Основное применение - это серверная часть приложений, веб- и не очень веб-приложений, всякие корпоративные системы - что-то крупное, тяжеловесное.

То есть, все банковские системы мира сидят на Java?
Не все, но многие. Если нужно разработать что-то большое, то выбирают Java, потому что во-первых, она быстрая (вопреки мифам, которые до сих пор ходят среди незнающих людей), сравнимая по производительности с С++, но при этом, стоимость разработки значительно меньше - это во-вторых. Java заточена под всякие энтерпрайзные штуки, и компания Sun, а позже и Oracle делали на это ставку, на серверные технологии и всё такое. В этом направлении они сделали очень многое, поэтому когда речь идёт о крупных системах вроде банковских, выбор падает на Java.

А может быть так, что Java выбирают ещё и потому, что она безопаснее чем, скажем, Ruby?
Не буду говорить про Ruby, но что касается Java, то безопасность данных - это один из ключевых её аспектов. Там хватает настроек, позволяющих ограничить выполнение определённого кода. Когда выходит очередная версия Java, то половина последующих патчей - это security-patch'и. Если какая-то компания предпочитает старую версию (например, седьмую) платформы новой (восьмой), а та уже ушла из поддержки, всегда есть возможность заказать платную поддержку у Oracle, и тогда они сделают вышедшие на 8-ю версию security-patch'и для 7-ой.

Что насчёт небольших проектов? Подойдёт ли им Java?
Это напрямую зависит от сложности бизнес-логики этих проектов. К примеру, это может быть трехстраничный сайтик, но этими тремя страницами могут быть какие-то архисложные отчёты, которые задействуют кучу данных. А если мы говорим о сайтах-визитках, то здесь использовать Java, конечно же, не имеет смысла. Стоимость серверов Java выше, чем PHP, поскольку Java требовательна к ресурсам. Она не медленная, но прожорливая - сколько памяти ей дашь, столько она и "скушает".

Сколько Java не корми, всё равно в RAM смотрит?
Именно! (смеётся)

Я читал, что к плюсам Java относится мультиплатформенность?
Да. Изначально задумывалась эдакая ультимативная кроссплатформенность. То есть написанный раз код можно было бы, по первоначальной задумке, запустить где угодно - на телефоне, десктопе, тостере… но в итоге так красиво не получилось из-за производителей виртуальных машин. Код-то мультиплатформенный, переносится, но вот некий производитель смартфонов взял и не включил какую-то фичу (я говорю не о современных устройствах, а про образцы 2005 года, а-ля телефоны на Symbian, Motorola со своей операционной системой, которые поддерживали Java). Поэтому люди, тогда писавшие игрушки и приложения, очень мучились с портированием даже в пределах мобильной платформы: запустить игру на Motorola и на Nokia - две разные задачи.

Что касается современных мобильных приложений - все Android-приложения, это дети Java?
Не все, но большинство. Конечно, есть возможность разработки нативных приложений на С++, но опять же - на Java получится дешевле. Ну и поддержки куда больше - как от самого Google, производителя операционной системы, так и от community Java. Кое-что проще разрабатывать. Игры со сложной 3D-графикой пишутся всё-таки на С++, т.к. Java не даст такой же производительности в этих вещах.

Кстати про игры - я слышал, нашумевший в своё время Minecraft полностью написан на Java?
Отчасти. Графика, которая там отрисовывается - это заслуга OpenGL. А это - нативный код. У Java есть возможность взять любое нативное приложение, написанное, к примеру, на С++, и вызвать из него определённые функции. Через мостик, соединяющий Java с нативными приложениями, и делается обращение к графической подсистеме. Т.е. все данные про мир игры и игровая механика написаны на Java, но графические вычисления отправляются в OpenGL.

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

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

Есть мнение, что приложения, написанные на Java, не отличаются красивым дизайном. Правда или миф?
Это не касается веб-приложений, потому как такое приложение можно завернуть в какую угодно обёртку. Если мы говорим о нативных приложениях, то да, с этим у Java не очень сложилось. С этим связана одна история. На дебютной демонстрации Java - напоминаю, на дворе был 95 год - в браузере на веб-страничке крутился глобус. Тогда эти красивости не были тепло приняты из-за слишком медленного интернета. Посмотрев на это, люди сказали, мол, зачем нам этот крутящийся глобус, если и так нужно качать виртуальную машину весом в 100 мб, да ещё и сам апплет отдельно скачивать…

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

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

Есть такая вещь, как Look and Feel - у платформы, на которой работает VM, можно запросить набор стилей и компонентов, как они должны выглядеть на конкретной операционной системе. Всё снова зависит от производителей виртуальных машин, плюс нужно учитывать стремительное развитие дизайна операционных систем. Взять ту же Windows - между "семёркой" и "восьмёркой" ведь просто пропасть! За всеми дизайнерскими новшествами конечно же не поспеешь, но системный Look and Feel делает всё более-менее похожим.

В последнее время я наблюдаю за JavaFX. Когда-то эту технологию забросили за ненадобностью, но недавно за неё снова взялись и теперь активно возрождают. JavaFX позволяет писать десктопное приложение, но стилизовать его под веб-приложение. Точно также в игру вступает CSS, где можно указать, какого цвета будет такая-то кнопочка, с такими-то краями, задать расположение и так далее. С этой технологией можно делать приложения, которые будут выглядеть более нативно. Производительность устройств это уже позволяет - современные смартфоны давно обогнали в мощности компьютеры 1995 года.

На этом мои вопросы заканчиваются. Благодарю за интервью!
Обращайся.

Что ж, неудивительно, что Java победила в гонке с 19-ю другими языками. Взрослая платформа, для которой уже найдены практически все стандартные решения, с огромным сообществом, заточенная под серверные технологии, крупные проекты и мультиплатформенность, совместимая с нативными приложениями - разве это не заманчиво? Добавляет привлекательности и всё растущая популярность платформы благодаря Android-приложениям и проектам вроде Minecraft - глядя на такие результаты, можно с уверенностью говорить, что у Java есть все шансы ещё много лет оставаться языком программирования года.

Software for business

Станислав Синицкий, Александр Михальчук
July 12, 2016

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

Думаете, такое происходит только с вами? Увы, но нет. В наши дни стартап - занятие популярное, за него берутся очень многие. Кто-то пытается воплотить действительно стоящие идеи, а кто-то ступил на эту стезю лишь следуя модному веянию. Как выжить в такой конкуренции, не дать вашему делу затеряться, привлечь внимание инвесторов? Мне удалось пообщаться об этом с Александром Михальчуком, СОО Anadea. Ниже представляю вам запись нашей беседы.

Из 10 IT-стартапов по статистике выживают 1-2. Как считаешь, каковы причины этого? Где молодые предприниматели допускают ошибки чаще всего?
Начнём с того, что стартапы очень разные и их успех зависит от разных факторов. Конечно, если изначально люди придумали идею и начинают воплощать её в жизнь, то они понимают стартап как коммерческую затею, цель которой - приносить прибыль. В этом случае им нужно максимально сфокусироваться на продажах продукта или услуг. Если стартап строится как коммерческий проект, то на этом должен быть фокус, и его никогда нельзя терять. Из классических "граблей" вспоминаю ситуации, когда главными идеологами стартапа являются программисты, которых интересуют технические аспекты или они реализуют то, чего не хватало в работе. Они абсолютно не уделяют внимание области продаж, а потому проект ждёт фиаско.

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

Можешь вспомнить истории успешных стартапов?
Как положительный пример, могу привести Мэттью Даймлера и его проект, который изначально назывался Buyfolio, а позже - Agentfolio. Вначале это были просто живые таблицы. Позже это стало продуктом, позволявшем свести покупателей жилья в Нью-Йорке с продавцами и арендаторами. История этого стартапа началась с того, что Мэттью, как житель Нью-Йорка, столкнулся с проблемой - ему понадобились такие услуги. Существовавшие сервисы его не устроили. Изучив эту проблему, продумав, как можно помочь людям в этой области, зная изнутри, что там происходит, он построил модель стартапа. Он был тесно вовлечён в разработку, но не занимался техническим курированием - Мэттью сфокусировался на продвижении продукта. Писались статьи в газетах, выходили новости - стали приходить и клиенты, и агенты. Как результат, стартап работал, приносил прибыль, и у крупной компании появился интерес к этому стартапу. И она приобрела его.

То есть, молодому предпринимателю стоит начать с хорошей идеи, которая приносила бы пользу людям?
Стартап - это всегда идея. Что вообще есть стартап? Собрались несколько человек, у них есть идея (разной степени "убийственности"), они начинают её реализовывать, либо сами, либо привлекая кого-то (на начальном этапе - за свои средства). Потом они усиленно ищут финансирование. И получается, что это такой рынок, где есть люди с идеями, и есть люди с деньгами - так называемые "ангелы" - которые изучают стартапы на различных конференциях и стартап-инкубаторах, где молодым стартапам дают помещения и оборудование за небольшие деньги. Ангелы, естественно, оценивают идею. Если она им кажется интересной и жизнеспособной, они могут вложить туда деньги. Ангелы понимают, что идут на риск и в итоге может получиться пшик. Для них в порядке вещей профинансировать 10 стартапов, из которых 9 обвалится, но 10-й выстрелит и окупит все 10.

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

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

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

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

Какие трудности могут заставить закрыть стартап?
Финансовые. Если человеку не из чего платить команде, или даже не на что содержать семью - тут даже самой блестящей идее придётся подождать. Расчёт собственных сил, ресурсов, очень важен. Когда речь идёт о финансовом успехе, нужно понимать, что ты отдаёшь деньги, время и усилия сегодня, а начнёшь что-то получать взамен спустя какое-то время. Нужно сформировать план. Есть идея, есть люди, способные реализовать её в жизнь. Нужно сделать оценки: сколько времени потребуется на работу, сколько финансов понадобится на то, чтобы обеспечить работу на протяжении определённого периода времени команде стартапа. Но если план не реалистичен, то ни о каком стартапе не может быть и речи. К примеру, тебе потребуется 1000 долларов для работы на полгода, а у тебя в кармане всего 1 доллар… придётся подкопить, приятель. Нужно смотреть на вещи здраво. Можно отказаться от услуг специалистов и делать это самому. Не можешь делать сам? Ищи сторонников идеи. Демонстрируй её тем, кто может профинансировать (на Kickstarter, например). Или копи деньги.

Большое спасибо за беседу, Александр.
Всегда пожалуйста.

Итак, что мы выяснили:

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

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

Алексей Деркач
August 2, 2016

31 июля 2016 года в Минске успешно состоялась первая "Битва ботов", организованная компанией Anadea совместно со Space и dev.by. Участники получили большое удовольствие, сражаясь с другими командами, с техническими особенностями боевой площадки и с тренировочным ботом.

В упорной борьбе, опередив лидера первой половины турнира, победила команда "Humbert Humberk". Она и получила главный приз - билеты на конференцию "BuildStuff". Второе место за командой "True Burger", она же "Против рандома нет приёма". Их игровая стратегия была вознаграждена геймерскими наушниками. Третье место заняли ребята из команды "John Cena", которые теперь смогут заряжать все свои гаджеты мобильными аккумуляторами.

Отдельно стоит отметить, что специальный приз за первую победу над тренировочным ботом выиграла команда "Tesla Model S". Всего 6 команд смогли победить тренировочного бота за время турнира, но именно "Tesla Model S" сделали это первыми.

Победители турнира получили ценные призы, а все участники - памятные подарки от организаторов.

Евгений Краморенко, Владислав Дмитриев
March 11, 2016

На сегодняшний день одним из самых распространенных Scala фреймворков является Play. Он хорошо зарекомендовал себя в работе среди сотрудников нашей компании, поэтому мы решили стартовать новый проект именно на нём. Особенностью проекта являлась необходимость сделать отзывчивый frontend. Для выполнения данной задачи стандартных средств Twirl (шаблонизатор Play) оказалось недостаточно, поэтому было решено попробовать ныне модный React JS.

React JS - это популярная библиотека для рендеринга представлений, разработанная командой Facebook. Основными её преимуществами являются легковесность, скорость работы и компонентный подход.

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

Подключение через script

Самым простой и быстрый способ добавить React в проект - это подключить sbt-web плагин sbt-reactjs и добавить ссылки на два JS файла в заголовке вашей страницы:

<script src="https://fb.me/react-0.14.7.js"></script>

<script src="https://fb.me/react-dom-0.14.7.js"></script>

Преимущества данного подхода:

Простота.
Скорость.
Изолированность - можно внедрить React только на одной странице в любой момент работы над проектом. Это никак не повлияет на уже написанный код.

Недостатки:

Повторение кода - файлы React'а необходимо подключать на каждой странице.
"Ад зависимостей" - кроме двух файлов React'а вам нужно будет подключить как минимум ещё один файл с вашим JS-кодом. Кроме того, вам могут понадобится другие библиотеки - ещё несколько JS-файлов. В конечном итоге подключение этих зависимостей в правильном порядке станет трудоёмкой задачей.

Данный подход отлично выполнил цель ознакомления с React, но для постоянной разработки хотелось бы более автоматизированное решение.

Использование внешних сборщиков

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

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

Использовать SBT plugin. Например: SBT Play Gulp Plugin.
Написать свою интеграцию. В качестве примера можно использовать play-gulp-standalone.

Преимущества:

Автоматизация - решение полностью самостоятельно. Вы можете просто писать код и быть уверенными, что он сработает на странице.
Современность - такие сборщики, как Gulp используют в качестве платформы Node.js, который предоставляет разработчику простой доступ к NPM (Node Package Manager). В репозитории этого пакетного менеджера около четверти миллиона пакетов! Данное сообщество развивается гораздо быстрее чем sbt-web.

Недостатки:

Требует настройки - необходимо приложить время и усилия чтобы настроить процесс сборки.
Сложность - для сборки проекта необходимо изучить и использовать ещё один инструмент.

Вывод

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

Кирилл Мачухин
January 20, 2016
 

Рано или поздно в любом проекте нужно что-то автоматизировать - будь то web-приложение, мобильное, Android или iOS. К примеру, мы столкнулись со сложным для понимания workflow. В процессе написания, с заказчиком мы выяснили все требования и пожелания, поняли их и задокументировали. Однако, спустя пару-тройку недель очень сложно тестировать и вспоминать всякие тонкости. Поэтому, хорошо бы это автоматизировать.

Наш проект Hey Ya! - приложение на Android и iOS и web-сервер, работающий на Rails. Инструменты, которые предоставляет Интернет - это Calabash Android, MonkeyTalk, Robotium, Selendroid, UIAutomator для Android и Calabash iOS, Frank, UIAutomation, KeepItFunctional и ios-driver для iOS.

Какой же инструмент выбрать? Ведь все они хорошо работают, но не все подходят нашим критериям. А именно:

Сервер у нас на RoR.

• Необходима кроссплатформенность: у нас есть Android и iOS.
• Важно, чтобы framework регулярно обновлялся.
• И немаловажный фактор - запуск тестов на реальных устройствах, поскольку приложение основано на работе с камерой. А в iOS-симуляторе, как известно, работа с камерой невозможна.

Выбор пал на Calabash.

Почему? Плюсы инструмента:

• Он есть под Android-платформу, есть под iOS-платформу.
• Написан на Ruby.
• Имеет синтаксис Gherkin (Cucumber-style).
• Последнее обновление (на момент написания статьи) - месяц назад, т.е. обновляют его достаточно регулярно.
• Поддерживается запуск тестов на реальных устройствах.

Итак, приступим к установке.

Для начала необходим xcode. В нашем проекте устанавливаем gem и генерируем команду calabash-ios-setup. Команда calabash-ios-gen генерирует skeleton, который практически ничем не отличается от skeleton'a Cucumber, кроме того, что там свои launcher'ы. На скриншоте приведён launcher для iOS-приложения.

Команда calabash-ios-setup генерирует схему Calabash для iOS-проекта непосредственно в самом xcode, подключает Calabash framework к проекту. Выполняется всё просто - одной командой.

Для запуска тестов на реальном устройстве необходим bundle-kit нашего приложения, который можно легко достать из xcode и device end point. Device end point это ничто иное, как IP устройства, подключенного к Wi-Fi. Командой для запуска является просто Cucmber. Таким образом запускаются тесты. Переменную окружения нужно прописать в команде, а можно сразу указать её внутри launcher’а.

Android-установка практически такая же. Отличаются только launcher’ы в skeleton’e.

Запуск тестов на Android происходит командой calabash-android-run и указанием пути к нашему apk-файлу. На iOS нам необходимо заранее собрать (сбилдить) приложение на устройстве, чтобы мы смогли работать с ним. И собрать (сбилдить) именно со схемой Calabash, т.к. тестовый сервер устанавливается непосредственно в приложении.

Но вырисовывается такая ситуация, что у нас есть два проекта (iOS и Android). Возьмём какую-нибудь банальную feature вроде sign up. Всем известна структура Cucumber: у нас есть файл-feature, потом файл-steps и мы используем page_object_pattern, после чего происходит реализация функций, вызванных steps'ами. Выходит так, что до какой-то стадии получается одинаковый код: sign_up_features и sign_up_steps идентичны и в iOS, и в Android. Почему? Потому что дизайн наших приложений почти одинаковый. "Почти" потому, что некоторые вещи невозможно реализовать в Android, но можно в iOS и наоборот.

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

Решение банальное и простое: установить gem'ы на стороне сервера, т.е. выделить наш Calabash из мобильных проектов, разбить наш page_object на модули и склеить launcher'ы calabash_iOS и calabash_Android.

И теперь если в переменном окружении мы указываем клиент-платформу iOS, то мы будем подключать Cucumber. Если клиентская платформа - Android при запуске наших тестов, значит мы будем идти по пути Calabash Android и отображать нужные файлы и методы.

Немаловажным фактором является здесь запуск тестового сервера. Это означает, что мы не ходим нашим приложением на staging/production. Мы ходим им на локальный сервер. Тесты лежат вместе с сервером, на серверной части. Мы имеем доступ к серверу и нам не составляет труда его поднять. Мы его поднимаем на host 0.0.0.0, и в приложении указываем host, по которому будем ходить - IP.

Разбиваем на модули. Папка features содержит page_object_pattern и она стала содержать в себе Android и iOS. Вот пример одного модуля pages general - там содержится код, который выполняет наши iOS-actions. В папке Android находится всё, что относится к Android: pages и все необходимые методы.

Что мы получили при таком подходе? У нас есть один файл signup_feature, а не два и один файл signup_steps_rb. На этом шаге мы не делаем никакого разделения, так как у нас одинаковые шаги для iOS и Android. После файла steps мы идём по пути iOS или Android, используя iOS- или Android-модули. Команды для запуска выглядят следующим образом: указывается платформа, запускается с помощью команд cucumber или calabash-android run и проверяется.

Плюсы такой реализации в том, что мы не имеем повторяющегося кода, в файлах feature и steps_rb - эдак в полтора раза мы сократили написание и дублирование. Появилась возможность свободного доступа к объектам через ActiveRecord и эмуляции работы второго клиента на стороне сервера. В частности, наше приложение не имеет такой функции, как logout и порой необходимо проверить кейсы, где первый клиент что-то сделал, а вторым надо проверить. Таким образом, на стороне сервера мы эмулируем работу и клиентом просто проверяем.

Естественно, есть и минусы такого подхода, хотя здесь они сугубо визуальны - это различные команды запуска (cucumber, calabash-android run). А так же нет возможности работать в debug режиме предоставляемым calabash (спасает команда binding.pry) В нужном месте остановились, проверили в debug режиме, проверили что нам надо, нашли элемент нужный и продолжили работу. Эти минусы есть, но они не критические.