Привет, Хабр!

Приглашаем всех разработчиков, тестировщиков, мобильных разработчиков, дизайнеров и менеджеров разработки на супер it-событие весны — 8 апреля в Екатеринбурге пройдет шестая конференция DUMP. Доклады будут идти в 7 секциях: FrontTalks, Serverside, Mobile, Web-design, DevOps, Тестирование, Management.

Мы доделываем итоговую сетку и обговариваем детали последних докладов, но 80% программы готово. Билет сейчас стоит 4500 рублей, но уже через неделю будет дороже.

Welcome!

Сегодня напишем преобразование, которое создаёт преобразование. Лично мне это напоминает «Начало» Кристофера Нолана, где люди видели сны во снах.

Это 7-ая статья цикла по модельно-ориентированной разработке. Я уже полгода пытаюсь написать статью с серьёзным примером разработки, управляемой моделями. Но каждый раз пониманию, что сначала необходимо рассказать о технологиях в целом, разобрать какой-нибудь очень простой пример. Так и в этот раз, хотел только начать статью с «Hello World», а в итоге этот простой пример вырос в здоровенную статью.

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

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

Это 5-я статья цикла по разработке, управляемой моделями. В предыдущих статьях мы уже разобрались с метамоделями, валидацией моделей, некоторыми нотациями для моделей (диаграммы и таблицы). Всё это было в рамках пространства моделирования MOF. Сегодня мы построим мост в пространство моделирования EBNF – познакомимся с текстовой нотацией для MOF-моделей.

Это 4-я статья цикла по разработке, управляемой моделями. В предыдущих статьях мы познакомились с OCL и метамоделями, Eclipse Modeling Framework и Sirius. Сегодня научимся описывать метамодели в текстовой нотации (а не в виде диаграмм как раньше) и познакомимся с табличным представлением моделей в Sirius. Сделаем это на примере кризиса среднего возраста и метода анализа иерархий. Возможно, это пригодится вам при разработке ИИ в играх, при принятии решений или в работе.

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

Существует множество решений для автоматизации тестирования. Каждое их них имеет свои особенности, преимущества, недостатки, различаются порогом вхождения, удобством применения, эффективностью, универсальность, кругом задач, для которых хорошо подходит. Для задачи автоматизации интеграционного тестирования и мониторинга систем для одного из проектов удачным решением оказалось применение связки «Scala» + «ScalaTest» + «SBT»

Это третья статья цикла, посвященного разработке, управляемой моделями. В предыдущих статьях мы разбирались с OCL и метамоделями, создавали свою метамодель для языка Anchor с древовидным редактором. Сегодня сделаем редактор Anchor-диаграмм.

Это вторая статья цикла, посвященного разработке, управляемой моделями. Сегодня мы создадим метамодель, основанную на метаметамодели Ecore. Вскользь затронем моделирование данных, а именно Anchor, 6НФ и концептуальное моделирование.

Этим летом вышла очередная игра из серии Batman Arkham, в ПК версии которой оказалось столько багов, что было принято беспрецедентное решение снять её с продаж. Я решил посмотреть, что же там такого ужасного.

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

На скриншоте изображён этот момент: вместо того, чтобы лететь вперёд, Бэтмен повернулся вниз головой, демонстрируя полнейшее пренебрежение к происходящему. Аналогичный баг был в предыдущей игре (Arkham Origins), и он до сих пор не исправлен. Видимо тот же самый кривой код был перенесён в новую игру. Попробуем найти, какие ошибки делают программисты в играх такого уровня, и исправить их.

Эта статья является продолжением SpiderTest: Автотесты своими руками. Однако, первая часть обзора на это приложение была больше ориентирована на десктопный интерфейс. В этой же хотелось бы поговорить об экзотике: связи тестов с CI-server’ом и GitHub.
Может возникнуть вопрос: «Зачем вообще все это нужно? Мы написали тест, прогнали его в нужных браузерах и нам достаточно» и в целом он довольно обоснованный! Действительно, для обычного тестирования, запуска автотестов из самого приложения SpiderTest в большинстве случаев бывает достаточно. Но что делать, если мы хотим запустить тесты в IE9-11, Opera, FireFox и Google Chrome разных версий? На одной машине это сделать невозможно, а создавать кучу виртуальных машин и запускать по очереди в каждой утомительно (и вообще это костыль).
А если мы хотим провести дымовое тестирование? Или хотим запускать тесты не только в разных браузерах, но и в разных операционных системах (Windows OS, Linux OS)?
Самый оптимальный ответ на поставленные выше вопросы – использовать сервер непрерывной интеграции. В этой статье я рассмотрю настройку SpiderTest и Jenkins. Справедливости ради стоит сказать, что запускать тесты можно и на bamboo, и на teamcity, но Jenkins прост и бесплатен, поэтому рассмотрим его.

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

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

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

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

На наш взгляд, объектный язык ограничений (Object Constraint Language, OCL) должен знать каждый, кто занимается моделированием или кому интересна модельно-ориентированная разработка. Однако, он незаслуженно обделен вниманием в сети вообще, а, уж, в русскоязычном сегменте информации просто мизер. Что это за язык и зачем он нужен, описано в этой статье. Статья не претендует на фундаментальность, полноту охвата, точность определений и т.п. Её задача: 1) на простых примерах познакомить с OCL тех, кто никогда не слышал об этом языке, 2) а для тех, кто о нём слышал, возможно, открыть новые способы его применения.

Первоначально разработанная спецами из IBM, Архитектура управления неструктурированной информацией (UIMA) сейчас обитается в инкубаторе от Apache, являет собой образец открытого ПО и распространяется по апачевой лицензии.

Что это?

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

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

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

1. определяем язык текста;
2. находим границы предложений;
3. ищем именованные вхождения (имена, названия и т.д.).

Каждая операция выполняется определённым компонентом, связь между которыми обеспечивается фреймворком (доступны UIMA Java Framework и UIMA C++ Framework).

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

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

"Мама мыла раму":

(предложение
    (именная гр. (сущ мама))
    (глаг. гр. (глаг мыла)
        (именная гр. (сущ раму)))
    (. .)))

Это называется синтаксическим деревом предложения. В графическом виде его можно представить следующим образом (в упрощенном виде):

Довольно часто среди начинающих (и даже не очень) тестировщиков приходится слышать: «вот если бы я умел писать автотесты, я бы…». Как правило этим «если бы» ребята и ограничиваются. На вопрос: «А почему не учишься писать?» чаще всего отвечают: «Программирование это не мое». Действительно, тем для кого программирование темный лес, погрузиться в мир автотестов довольно затруднительно, ведь скрипт сам себя не напишет. В этой статье я хотел бы поговорить о том, как из ручного тестировщика стать крутым автотестером.

Любой маломальски опытный QA-инженер (или в простонародье тестировщик) сможет сходу назвать пяток различных видов тестов: удобство пользователя, дымовое, нагрузочное, регрессионное, конфигурационное, тестирование взаимодействия и т.д. Какие-то виды тестирования используются редко, например нагрузочное, почаще применяется тестирование удобства пользователя, о таких экзотических видах, как конфигурационное тестирование или тестирование взаимодействия, многие вообще слышали только в книгах Канера и Фолка «Тестирование программного обеспечения» и никогда не использовали в работе. Но есть вид тестирования, про который можно сказать совершенно четко: его делал каждый. Я говорю о регрессионном функциональном тестировании. Этот вид теста, пожалуй, является одним из наиболее важных, нудных и трудоемких.

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

К сожалению, универсальных правил прохождения и проведения собеседования нет и быть не может, потому что сотрудников подбирают не только по их техническим навыкам и личностным качествам, но и по совпадению с некоторым (зачастую неявным и очень субъективным) «профилем», который, по мнению интервьюеров, вписывается в их команду или компанию. Что же касается руководств из серии «как правильно проходить собеседования», то они обычно вызывают не меньше боли в комментариях, потому что очень субъективны и обязательно задевают чьи-нибудь болевые точки.

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

А что на собеседованиях раздражает или напрягает вас? Поделитесь в комментариях.

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

Внимание владельцам малых и средних IT-, интернет- и софтверных компаний! В цепкие руки Alconost попал еще один ценный доклад со столь же ценной IT-конференции ISDEF. В нем Александр Лысковский, сооснователь и CEO Alawar Entertainment, рассказал, как расти компании и что необходимо делать для ее успешного роста.

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

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

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

Портфель проектов -> Программа проектов -> Проект.

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