Под катом перевод статьи Carsten Sørensen «This is not an article — just some food for thoughts on how to write one». В ней рассказывается на что нужно обращать внимание при написании научных статей. Если вы пишите диссертацию в области информационных технологий, то наверняка найдете что-то интересное для себя. Впрочем, и авторы популярных статей тоже могут найти что-то полезное.

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

Абстракция – это одна из основных техник в ИТ. Любой язык программирования или моделирования, любая парадигма программирования (процедурная, функциональная, ООП, …) дают ответ на вопрос, как и от чего нужно абстрагироваться. Причём, адепты каждого подхода предлагают какой-то свой вариант абстракции.

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

Также немного говорится про классы, примеси и смеси в JavaScript.

Примеры из статьи можно посмотреть тут.

Это третья статья об использовании Scala в тестировании. Сегодня будут рассмотрены примеры использования Apache Camel для создания тестовых заглушек, а также компонентов информационной системы.

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

Для разовой проверки интеграции мы бы использовали простое Java или Scala приложение, сценарий Apache JMeter или SoapUI. Но нам нужна система, которая постоянно работает, отвечает на запросы и не требует действий со стороны тестировщика — запустил и забыл. Для решения такой задачи мы можем создать приложение, основанное на фреймворке Apache Сamel.

Slick — это не только фамилия одной из величайших солисток всех времён, но и название популярного Scala-фреймворка для работы с базами данных. Этот фреймворк исповедует «функционально-реляционный маппинг», реализует реактивные паттерны и обладает официальной поддержкой Lightbend. Однако отзывы разработчиков о нём, прямо скажем, смешанные — многие считают его неоправданно сложным, и это отчасти обоснованно. В этой статье я поделюсь своими впечатлениями о том, на что стоит обратить внимание при его использовании начинающему Scala-разработчику, чтобы в процессе написания запросов случайно не открыть портал в ад.

8 апреля 2016 г. в Екатеринбурге состоялась шестая конференция уральских разработчиков DUMP: Development, Usability, Management, Practice. Традиционно конференция собирает более 1000 профессионалов IT-отрасли со всей России. Здесь можно поделиться опытом, послушать интереснейшие доклады, познакомиться с коллегами по цеху и просто получить удовольствие от посещения мероприятия. Компания «Центр ИТ» выступила спонсором конференции, а также представила актуальный доклад на тему «Умный компилятор в Java 9: насколько он умён?»

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

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

Это 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НФ и концептуальное моделирование.

Эта статья является продолжением 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) а для тех, кто о нём слышал, возможно, открыть новые способы его применения.

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

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

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

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

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

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

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

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

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