В предыдущей статье я приводил следующий пример: ordersLabel = if ordersCount == 1 then "order" else "orders" Для того, чтобы перейти от частного случая с orders к более общему pluralize, нам необходимо оформить этот код в виде функции, которую мы сможем вызывать и не дублировать логику. Функции в Elm представляют собой повторно-используемую логику. Они не являются объектами и не хранят состояние. Все что они делают – принимают значения в качестве аргументов и возвращают значение.
Изучая Elm: Выражения
REPL Начать разбираться с основными конструкциями языка Elm можно через его REPL. Для этого необходимо предварительно установить Elm. На официальном сайте языка присутствует руководство для разных операционных систем, а также по конфигурированию популярных редакторов кода. Для macOS установка сводится к одной команде: brew install elm, если вы используете Homebrew. Для того, чтобы запустить REPL введите elm repl в вашем любимом терминале. В командной строке вы увидите подобный вывод: $ elm repl ---- Elm 0.
Изучая Elm: Выбор языка для проекта
Elm может быть как заменой JavaScript, так и дополнением к нему на вашем проекте. Elm код сохраняется в файлах с расширением .elm, компилятор языка прогоняет их через себя и на выходе выдает обычные .js файлы, которые могут быть выполнены браузером. При этом CSS стили будут работать с Elm так же, как они работают с JavaScript. Соотношение Elm и JavaScript кода может существенно зависеть от конкретного проекта. В одном случае имеет смысл большую часть реализовать на JavaScript, а Elm оставить бизнес логику и рендеринг; в другом – наоборот все написать на Elm, и только для специфических задач использовать JavaScript, экосистема которого в разы больше.
Изучая Elm: Предисловие
Пару месяцев назад я начал работать в качестве технического директора на небольшую компанию, которая занимается продуктовой разработкой в сфере блокчейна. И, как это часто бывает у маленьких компаний, CTO получает в распоряжение довольно ограниченное количество ресурсов и сам пишет код. В моем же случае на старте нового проекта я получил еще и полную свободу в выборе стека технологий. Так как я несколько лет писал на Ruby и в предыдущих компаниях всегда присутствовали причины не осваивать новый язык, я решил прервать этот порочный круг и выбрал Elixir.
Slack в распределенной команде
Вот уже около года я работаю удаленно, и все коммуникации в текущей компании мы строим на основе асинхронного подхода. Делаем мы это умышленно и стараемся предоставить сотрудникам возможность сфокусироваться на своих задачах, при этом не блокируя других членов команды, которые от них зависят.
Slack для нас – основной инструмент коммуникации. Он позволяет команде общаться в течение дня используя правильные каналы для организации диалогов. В Slack мы синхронизируем рабочий процесс, договариваемся о созвонах, или просто общаемся на отвлеченные темы. При этом, мы условились, что Slack не является:
- объектом постоянного мониторинга (каждый час, днем и ночью);
- местом для принятия важных решений;
- местом для хранения важных ссылок, документации и фидбека сотрудников.
Как и любой чат, Slack нельзя назвать асинхронным, что усложняет наше виденье распределенной команды. Основные причины этому – частые прерывания и многозадачность. Довольно быстро можно заметить, что, работая удаленно и используя чат по назначению, коллеги ожидают от вас почти немедленного ответа. При этом люди не учитывают и не знают заняты ли вы сейчас, общаетесь ли вы с другим членом команды, или же сделали небольшой перерыв. Подобное общение может вызывать стресс и мало отличаться от офисной трясины митингов, и снова возникает ощущение, что планируемая работа не завершена к концу дня.
Однако, при правильном подходе, которому придерживается вся команда и руководство, Slack тоже может быть асинхронным. Ниже я привожу несколько практик, которые направлены на создание такого процесса.