Elixir/Phoenix *

Около полутора лет назад мы написали внутренний инструмент для корпоративных анонсов. Изначально в нём использовался Phoenix для бэкенда и React для фронтенда. Тем самым мы получали преимущества Redux и каналов Phoenix при доставки обновлений в браузер в реальном времени.

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

Почему мы решили заменить React

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

От переводчика: «Elixir и Phoenix — прекрасный пример того, куда движется современная веб-разработка. Уже сейчас эти инструменты предоставляют качественный доступ к технологиям реального времени для веб-приложений. Сайты с повышенной интерактивностью, многопользовательские браузерные игры, микросервисы — те направления, в которых данные технологии сослужат хорошую службу. Далее представлен перевод серии из 11 статей, подробно описывающих аспекты разработки на фреймворке Феникс казалось бы такой тривиальной вещи, как блоговый движок. Но не спешите кукситься, будет действительно интересно, особенно если статьи побудят вас обратить внимание на Эликсир либо стать его последователями.

В этой части мы добавим поддержку ролей и начнём разграничивать права доступа. Ключевой момент данной серии статей — здесь очень много внимания уделяется тестам, а это здорово!

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

От переводчика: «Elixir и Phoenix — прекрасный пример того, куда движется современная веб-разработка. Уже сейчас эти инструменты предоставляют качественный доступ к технологиям реального времени для веб-приложений. Сайты с повышенной интерактивностью, многопользовательские браузерные игры, микросервисы — те направления, в которых данные технологии сослужат хорошую службу. Далее представлен перевод серии из 11 статей, подробно описывающих аспекты разработки на фреймворке Феникс казалось бы такой тривиальной вещи, как блоговый движок. Но не спешите кукситься, будет действительно интересно, особенно если статьи побудят вас обратить внимание на Эликсир либо стать его последователями.

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

Итак, определим диспозицию… Вы написали кусочек кода, который вы хотите использовать с большим количеством разных "вещей" — звучит не очень научно, но всё же. Эти разные вещи объединяет какое-то общее свойство, через которое они достигают одинакового результата на высоком уровне абстракции; только вот пути достижения результата могут быть совершенно разными.

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

Но разве я не могу выбрать конкретную реализацию и использовать её? Мне больше ничего и не надо....

Вы конечно можете. Но что случится, если вы поменяете своё мнение о "вещи", которую вы используете. Вдруг ваша конфетка без обёртки окажется не тем, чем кажется? А вдруг ещё хуже — вашу дивную "штучку" перестанут поддерживать? В этаких ужасных условиях было бы круто, если бы вы могли быстро поменять одно на другое, не меняя при этом вообще всё что мы написали. Прально?

От переводчика: «Elixir и Phoenix — прекрасный пример того, куда движется современная веб-разработка. Уже сейчас эти инструменты предоставляют качественный доступ к технологиям реального времени для веб-приложений. Сайты с повышенной интерактивностью, многопользовательские браузерные игры, микросервисы — те направления, в которых данные технологии сослужат хорошую службу. Далее представлен перевод серии из 11 статей, подробно описывающих аспекты разработки на фреймворке Феникс казалось бы такой тривиальной вещи, как блоговый движок. Но не спешите кукситься, будет действительно интересно, особенно если статьи побудят вас обратить внимание на Эликсир либо стать его последователями».

Перевод статьи Coding A.I. Techniques in Elixir: The Generate and Test Algorithm

В последнее время, я работал над проектом в области И.И. (искусственный интеллект). По моим ожиданиям, работа над этим проектом займет ещё значительное время. Цель состояла в том, чтобы написать проект 100% на языке Elixir, но прежде чем я смог принять это решение, мне нужно было удостовериться, что я смогу реализовать некоторые из самых популярных решений в области И.И. на Elixir. На протяжении нескольких дней я изучал некоторые из наиболее эффективных техник, которые применяют исследователи в области И.И. для решения проблем программными средствами.

В этой статье я сделаю краткое объяснение метода, называемого алгоритмом генерации и испытаний — Generate and test algorithm (он же проб и ошибок), а затем я буду использовать вариацию этого метода для решения простой задачи с использованием языка программирования Elixir.

В И.И. есть много областей, из которых наиболее известными на сегодняшний день являются машинное обучение, обработка естественного языка (natural language processing) и робототехника. Тем не менее, для меня моя любимая дисциплина в И.И. известна как автоматизированные рассуждения — Automated reasoning. Программа, которую я продемонстрирую попадет в эту область И.И.

Если разделять языки программирования по популярности, то они делятся на три эшелона. Первый эшелон включает мейнстрим-языки, такие как Java, JavaScript, Python, Ruby, PHP, C#, C++ и Objective-C. Несмотря на то, что некоторые из ведущих языков возможно увядают, вам лучше знать один или несколько из них, если вы хотите иметь возможность легко найти работу.

Языки второго эшелона пытаются пробиться в мейнстрим, но ещё не добились этого. Они доказали свою состоятельность путем создания сильных сообществ, но они до сих пор не используются большинством консервативных IT-компаний. Scala, Go, Swift, Clojure и Haskell — языки, которые я бы отнёс ко второму эшелону. Некоторые компании используют эти языки для отдельных сервисов, но широкое применение встречается редко (за исключением Swift, который начинает обгонять Objective-C в качестве основного языка для iOS). Go и Swift имеют хорошие шансы на переход из второго эшелона в первый в течение ближайших двух-трёх лет.

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

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

Лексический анализ (токенизация) и парсинг — одни из наиболее важных концепцпий в информатике и программировании. Эти концепции базируются на огромном количестве теоретических знаний, но сегодня мы о них не будем говорить, потому что их действительно много. Кроме того, подход к парсингу через "науку" может вызвать жёсткое отвращение и напугать. Между тем, практическое применение очень простое и прямолинейное. Если хотите знать больше о теории — идите в Википедию (лексический анализ и парсинг), или читайте восхитительную книгу дракона (рекомендовано к прочтению вообще всем программистам).

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

Trello — одно из самых моих любимых приложений. Я пользуюсь им с момента появления, и мне очень нравится то, как оно работает, его простота и гибкость. Каждый раз, начиная изучать новую технологию, я предпочитаю создать полноценное приложение, в котором смогу применить на практике всё, что изучил, для решения реальных проблем, и проверить эти решения. Так что начав изучать Elixir и его Phoenix Framework я понял: я должен на практике использовать весь этот потрясающий материал, с которым познакомился, и поделиться им в виде руководства о том, как реализовать простое, но функциональное посвящение Trello.

В последнее время участились статьи и обсуждения на тему прощания с ООП и поиски смысла, который Алан Кэй изначально вкладывал в это понятие.


В связи с этими обсуждениями, часто всплывает мысль о том, что Erlang/Elixir очень хорошо удовлетворяют критериям, которые Кэй предъявлял к понятию «объектно-ориентированный». Но далеко не все знакомы с этими языками, поэтому возникает непонимание как функциональные языки могут быть более объектно-ориентированными, чем популярные C++, Java, C#.

В этой статье я хочу на простом примере с exercism.io показать как выглядит ООП на Elixir.

В мире Elixir, Plug представляет собой спецификацию, позволяющую различным фреймворкам общаться с различными web-серверами, работающими в Erlang VM.
Если вы знакомы с Ruby, то можете провести аналогию с Rack: Plug пытается решать те же проблемы, но только другим способом. Понимание основ работы Plug позволит лучше разобраться как с работой Phoenix, так и других web-фреймворков, созданных на языке Elixir.

6 лет я создавал приложения на языке Ruby и фреймворке Rails. Я щупал всякие новые языки программирования по мере их выхода, но Elixir – первый из них, который меня действительно увлёк.

В своё время Ruby уделал всех

Язык Ruby и фреймворк Rails полностью поменяли способ создания веб-приложений. Они дали начало религии ценностей для сообщества программистов. Они первые предложили идею, согласно которой инструменты программиста должны быть оптимизированы для продуктивной и радостной разработки.

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



Ruby прошёл путь от скромного положения невразумительного языка до одного из самых популярных языков, в основном из-за фреймворка Rails и огромного лидерского потенциала таких людей, как DHH, Wycats, Aaron Patterson, Jose Valim и множества других. Но периодически, и тут и там начинают вылезать артефакты, оставшиеся из-за такого скромного старта языка.

Убегающая память

Зед Шо [Zed Shaw] в посте "Rails – это гетто" разглагольствует на тему проблем со сборкой мусора, из-за которых первые приложения на Rails перезапускались каждые 4 минуты.

Один из самых популярных серверов для Rails сегодня – это unicorn. Моё веб-приложение – это приложение для Rails, оно довольно простое, по сравнению с другими приложениями, которые я разрабатывал. Я перенёс его на сервер с 512 Мб памяти, и после нескольких дней работы мой unicorn съел всю доступную память и приложение начало тормозить.

Решение? unicorn-worker-killer. Не слишком отличается от более ранних решений.

Совсем недавно я окунулся в мир роботики и решил запрограммировать собственного робота на основе RasPi. Для этого я использовал Elixir, сравнительно новый, к слову сказать, язык программирования, который компилируется в байткод для Erlang VM. У меня сразу же возникла трудность с управлением контактами GPIO. Тогда я нашел библиотеку, которая вроде бы решала все мои проблемы. Однако она была написана как Port, из-за чего каждый вызов ее функций занимал слишком много времени, что влияло на правильность работы моего робота.

Немного подумав, я все-таки решился переписать библиотеку в виде NIF. Так как я не нашел много информации по этому поводу, я решил поделиться своим опытом написания NIF в Elixir с вами. Как пример я буду использовать то, что я создал.