In some projects, the build script is playing the role of Cinderella. The team focuses its main effort on code development. And the build process itself could be handled by people who are far from development (for example, those responsible for operation or deployment). If the build script works somehow, then everyone prefers not to touch it, and noone ever is thinking about optimization. However, in large heterogeneous projects, the build process could be quite complex, and it is possible to approach it as an independent project. If however you treat the build script as a secondary unimportant project, then the result will be an indigestible imperative script, the support of which will be rather difficult.

In the previous post we looked at what criteria we used to choose the toolkit, and why we chose gradle/kotlin, and in this post we will take a look at how we use gradle/kotlin to automate the build of non-JVM projects. (There is also a Russian version.)

Introduction

Gradle for JVM projects is a universally recognized tool and does not need additional recommendations. For projects outside of the JVM platform, it is also used. For instance, the official documentation describes usage scenarios for C++ and Swift projects. We use gradle to automate the build, test, and deployment of a heterogeneous project that includes modules in node.js, golang, terraform.

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

В предыдущей заметке мы рассмотрели, по каким критериям мы выбирали инструментарий, и почему остановились на gradle/kotlin, а в этой заметке рассмотрим, каким образом используем gradle/kotlin для автоматизации сборки не-JVM проектов. (Есть также перевод на английский.)

Введение

Gradle для JVM-проектов является общепризнанным инструментом и не нуждается в дополнительных рекомендациях. Для проектов за пределами JVM он также используется. Например, в официальной документации описаны сценарии использования для C++ и Swift проектов. Мы используем gradle для автоматизации сборки, тестирования и развёртывания гетерогенного проекта, включающего модули на node.js, go, terraform.

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

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

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

Напишите функцию, выводящую список целых чисел от 1 до 100, но вместо каждого числа, кратного 3, она должна выводить «Fizz», а вместо каждого числа, кратного 5, выводить «Buzz». Вместо чисел, кратных и 3, 5, программа должна выводить «FizzBuzz»; все остальные числа должны выводиться без изменений.

1. Имеющие делитель 3, но не 5
2. Имеющие делитель 5, но не 3
3. Имеющие делитель и 3, и 5
4. Не имеющие делитель 3 и 5

• «Fizz», если $$ и $$ является взаимно простым с 5
• «Buzz», если $$ и $$ является взаимно простым с 3
• «FizzBuzz», если $$ и $$
• $$ во всех остальных случаях.

[(lambda n: { 1: n, 6: "Fizz", 10: "Buzz", 0: "FizzBuzz" }[n**4%15])(n+1) for n in range(100)]

(1..100).map{|n| {1 => n, 6 => "Fizz", 10 => "Buzz", 0 => "FizzBuzz"}[n**4%15] }

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

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

Недавно в корпоративном блоге Parallels выходила статья, где приводились размеры оплаты труда разработчиков на западе со словами "в любом случае российские зарплаты пока не дотягивают до европейских". Частое столкновение с тем, как люди очень выборочно сравнивают условия жизни поросенка Петра и тех, кто не уехал, побудили поделиться некоторыми наблюдениями о жизни в США изнутри. Цель данного поста — подтолкнуть подходить к вопросу комплексно и делать сравнение яблок с яблоками, а не точечно сравнивать то, что выгодно, и закрывать глаза на остальные важные аспекты. Если вам покажется, что в данной статье есть иные подтексты — прошу списать это на то, что "чукча — не писатель" и по возможности игнорировать их.

Разработка программ высокого качества подразумевает, что программа и её части подвергаются тестированию. Классическое модульное (unit) тестирование подразумевает разбиение большой программы на маленькие блоки, удобные для тестов. Либо, если разработка тестов происходит параллельно с разработкой кода или тесты разрабатываются до программы (TDD — test driven development), то программа изначально разрабатыватся небольшими блоками, подходящими под требования тестов.

Одной из разновидностей модульного тестирования можно считать propery-based testing (такой подход реализован, например, в библиотеках QuickCheck, ScalaCheck). Этот подход основан на нахождении универсальных свойств, которые должны быть справедливы для любых входных данных. Например, сериализация с последующей десериализацией должна давать такой же объект. Или, повторная сортировка не должна менять порядок элементов в списке. Для проверки таких универсальных свойств в вышеупомянутых библиотеках поддерживается механизм генерации случайных входных данных. Особенно хорошо такой подход работает для программ, основанных на математических законах, которые служат универсальными свойствами, справедливыми для широкого класса программ. Есть даже библиотека готовых математических свойств — discipline — позволяющая проверить выполнение этих свойств в новых программах (хороший пример повторного использования тестов).

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

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

Про ScalaCheck

Часть 1. Введение.

ScalaCheck — это комбинáторная библиотека, значительно облегчающая написание модульных тестов на Scala. В ней используется подход property-based тестирования, впервые реализованный в библиотеке QuickCheck для языка Haskell. Существует множество реализаций QuickCheck: как для Java, C, а так же других языков и платформ. Использование данного подхода позволяет значительно сократить время на разработку тестов.

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

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

Часть 1. Почему Parboiled?

• Часть 1. Почему Parboiled?
• Часть 2. Сопоставление текста
• Часть 3. Извлечение данных
• Часть 4. Суровая действительность

1. Преобразование числительных в число («десять» -> 10:Int)
2. и обратно (10:Int -> «десять» («десятый», «десяток» ...))
3. Преобразование числительных вместе с единицей измерения («десять рублей» <-> NumberWithMeasurement(10, RUB))
4. Неполный адрес («ул. Яблочная» <-> Address(street=«Яблочная»))
5. Адрес в пределах города («улица Яблочная дом сто двадцать три квартира сорок пять» <-> Address(street=«Яблочная», building=123, flat=45))
6. Телефон (256-00-21 («двести пятьдесят шесть ноль ноль двадцать один») <-> NumericalSequence(256,0,0,21))

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