Front-end для регистрации на React и Redux

Оригинал

Предыдущую публикацию мы закончили созданием модели User с проверкой корректности и необходимыми для генерации зашифрованного пароля трансформациями набора изменений (changeset); так же мы обновили файл маршрутизатора и создали контроллер RegistrationController, который обрабатывает запрос на создание нового пользователя и возвращает данные пользователя и его jwt-токен для аутентификации будущих запросов в формате JSON. Теперь двинемся дальше — к front-end.

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

“Ускоренные вычисления” (Accelerated Computing) – модель вычислений, при которой в тандеме с традиционными CPU применяются узкоспециализированные сопроцессоры (“ускорители”). Основной задачей сопроцессоров является высокопараллельное выполнение интенсивной вычислительной нагрузки и высвобождение ресурсов CPU для других нужд приложения (“offloading”).

Хорошими примерами таких “ускорителей” могут служить GPU от NVIDIA или сопроцессоры Xeon Phi, без которых не обходится практически ни один проект в сфере научных или инженерных вычислений. Однако в корпоративном секторе подобные технологии практически не применялись (если не считать использование GPU в фермах виртуализации рабочих мест).

Полтора года назад адепты функционального программирования основали сообщество RuHaskell и с тех пор периодически собираются, и проводят митапы. Ну как периодически — уже два раза собирались. Мы тут, в «Лаборатории Касперского», вообще очень поддерживаем это начинание. Во-первых, потому что это интересно, во-вторых, потому что мы используем Haskell в процессе разработки наших решений, а в-третьих, потому что некоторые участники сообщества у нас работают. А потому мы решили собрать третий митап этого сообщества на нашей территории. 18 августа все заинтересованные могут прийти в наш московский офис (Ленинградское шоссе, д.39А, стр.2), послушать умных людей, обсудить Haskell, поделиться опытом, позадавать вопросы и пообщаться. Разумеется, предварительно следует зарегистрироваться вот на этой страничке.

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


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

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

Здравствуйте, дорогие читатели! Сегодня предлагаем вашему вниманию обещанную статью с обзором возможностей реактивного программирования. Приятного и плодотворного чтения.

Теоретические основы императивного программирования были заложены ещё в 30-х годах XX века Аланом Тьюрингом и Джоном фон Нейманом. Теория, положенная в основу функционального подхода, формировалась в 20-х и 30-х годах. В числе разработчиков математических основ функционального программирования — Мозес Шёнфинкель (Германия и Россия) и Хаскелл Карри (Англия), а также Алонзо Чёрч (США). Шёнфинкель и Карри заложили основы комбинаторной логики, а Чёрч является создателем лямбда-исчисления.

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

Но теория так и оставалась теорией, пока в начале 50-х прошлого века Джон МакКарти не разработал язык Lisp (1958), который стал первым почти функциональным языком программирования. На протяжении многих лет у Lisp не было конкурентов. Позднее появились функциональные языки программирования APL (1964), ISWIM (1966) и FP (1977), которые не получили столь широкого распространения.

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

Мы уже обсуждали сборку и развёртывание приложений Elixir(перев: с помощью exrm): как осуществлять миграции поверх релиза или как работать с переменными среды. Пришло время открыть для себя ещё один инструмент, который поможет развёртывать Elixir приложения.

Практика развёртывания Elixir приложений и дальнейшее отслеживание их работы на нодах с помощью Exrm позволяет нам чувствовать себя гораздо увереннее в вопросах управления релизами в production. Однако возникает следующий вопрос: как управлять самим процессом развёртывания? Конечно, мы можем воспользоваться Capistrano, особенно если в мир Elixir мы пришли из Rails. Но посмотрим на цитату из Edeliver README:

edeliver основан на доставке и предоставляет bash-скрипт для сборки и развёртывания Elixir и Erlang приложений, а так же позволяет совершать "горячее" обновление кода.

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

#!/bin/bash -ex

BRANCH=${1:-master};

mix edeliver build release --branch=BRANCH --verbose
mix edeliver deploy release to production --verbose
mix edeliver start production --verbose
mix edeliver migrate production up --verbose

Скорее всего Вам придётся подкрутить этот скрипт под собственные нужды. Мы используем его только для развёртывания в production, но Вы так же можете использовать его и для staging развёртываний. Описание того, как всё это работает — под катом.

В первой части мы показали как создать алгоритм работы на основе «конечных автоматов» в SimInTech и использовать его совместно с «классическими» алгоритмами в виде функционально блочных диаграмм.

Во второй части мы покажем как создать вложенные и параллельно работающие конечные автоматы и осуществлять обмен данными между ними.

В последнее время заметил статьи на тему «ООП крут vs процедурное программирование плохо» и «ООП плохо vs процедурное программирование круто» и «ООП и процедурное плохо vs будущее за XYZ принципами», где XYZ какое-то модно новое понятие.

Самое смешное в этих статьях то, что многие под ООП понимают некий принцип когда-то заложенный в C++. И редко кто реально понимает что такое ООП. Вдруг мне показалось что 99% программистов вообще плохо понимают что такое ООП. Но может быть я ошибаюсь? Давайте посмотрим…

19 серия культового соревнования начнётся в пятницу, 5 августа, в 0:00 UTC.

ICFP Programming Contest — международное соревнование по программированию, проводимое ежегодно летом с 1998 года. Результаты соревнования объявляются на Международной конференции по функциональному программированию. (с) Wikipedia

В 2015 году вы могли заметить перемены в способе разработки приложений на JavaScript. Разработчики уходят от непредсказуемой архитектуры с мутабельным состоянием в сторону более предсказуемой иммутабельной архитектуры приложений.

С такими фреймворками как Backbone, было принято синхронизировать сами данные и представление данных – для этого приходилось вручную подписываться на нужные события dom. Такой способ был подвержен ошибкам и вынуждал использовать слишком много типового кода. Пришел Angular и исправил это с помощью автоматизированного двустороннего биндинга.

Но сейчас все движется в другом направлении.

Ты слышал про парня, который попрощался с OOП?

О нет. Ещё один? Что же он сказал?

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

Ох. Да, я слышал всё это раньше...

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

Двигаться дальше к чему?

Ты чего? К следующему технологическому прорыву, конечно!

А, к этому… И что там у нас на очереди?

Процессы в Elixir (ну и в Erlang конечно же) идентифицируются с помощью уникального идентификатора процесса — pid.
Мы используем их, чтобы взаимодействовать с процессами. Сообщения посылаются как бы в pid, а виртуальная машина сама заботится о доставке этих сообщений в правильный процесс.
Иногда, впрочем, чрезмерное доверие к pid может приводить к значительным проблемам.
К примеру, мы можем хранить pid уже мёртвого процесса, или мы можем использовать Supervisor, который абстрагирует создание процессов от нас, поэтому мы даже не знаем, какой у них pid (пер: а ещё Supervisor можете перезапустить упавший процесс с другим pid, и мы об этом не узнаем никак).
Давайте создадим простое приложение и посмотрим: с какими проблемами мы можем столкнуться и как мы эти проблемы будем решать.

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

Привет, коллеги!

Я расскажу о библиотеке для Питона с лаконичным названием f. Это небольшой пакет с функциями и классами для решения задач в функциональном стиле.

— Что, еще одна функциональная либа для Питона? Автор, ты в курсе, что есть fn.py и вообще этих функциональных поделок миллион?

— Да, в курсе.

Причины появления библиотеки

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

В 2014 году группа профессиональных разработчиков на Clojure под руководством Дмитрия Бушенко провела первые и единственные онлайн-курсы по языку Clojure на русском языке.

Специально для курса мы записали 71 оригинальное видео общей продолжительностью 17 часов 25 минут и 44 секунды. Курс пользовался успехом — пришло более 200 человек, но материалы в открытом доступе не публиковались.

Этот сайт — те самые материалы.

Мы публикуем их в том виде, в каком они есть. Лекции сами по себе связные, полные и самодостаточные. Они даже почти не устарели (на июнь 2016-го), хотя, конечно, появилось и много нового. Задания тоже можете порешать — это ровно те файлы, которые выдавались на дом слушателям курса в 2014-м.

(мопед не мой)

Это седьмая статья из цикла «Теория категорий для программистов». Предыдущие статьи уже публиковались на Хабре:

• Теория категорий для программистов: предисловие
• Категория: суть композиции
• Типы и функции
• Категории, большие и малые
• Категории Клейсли
• Произведения и копроизведения
• Простые алгебраические типы данных

Функторы

За понятием функтора стоит очень простая, но мощная идея (как бы заезжено это ни прозвучало). Просто теория категорий полна простых и мощных идей. Функтор есть отображение между категориями. Пусть даны две категории C и D, а функтор F отображает объекты из C в объекты из D — это функция над объектами. Если a — это объект из C, то будем обозначать его образ из D как F a (без скобок). Но ведь категория — это не только объекты, но еще и соединяющие их морфизмы. Функтор также отображает и морфизмы — это функция над морфизмами. Но морфизмы отображаются не как попало, а так, чтобы сохранять связи. А именно, если морфизм f из C связывает объект a с объектом b,

f :: a -> b

то образ f в D, F f, связывает образ a с образом b:

F f :: F a -> F b

(Надеемся, что такая смесь математических обозначений и синтаксиса Haskell понятна читателю. Мы не будем писать скобки, применяя функторы к объектам или морфизмам.)

От автора: перевод статьи «Функциональное программирование непопулярно, потому что оно странное» вызвал бурное обсуждение. В нескольких комментариях весьма справедливо замечалось, что при обсуждении недостатков функционального программирования хорошо бы опираться на современные и развитые функциональные языки (в оригинальной статье примеры были на шаблонах C++) и что Хаскель, например, последние пять лет широко используется в индустрии. В связи с этим я хотел бы обратить внимание на две очень предметные статьи из другого блога (от автора книги F# for Scientists): (i) "Недостатки чистого функционального программирования" и (ii) "Почему Хаскель так мало используется в индустрии". Перевод первой из них я как раз и хотел бы представить ниже.

1. На чистых функциональных языках не существует эффективного неупорядоченного словаря и множества