• Вам действительно нужен Redux?

      Не так давно React позиционировал себя как "V in MVC". После этого коммита маркетинговый текст изменился, но суть осталась той же: React отвечает за отображение, разработчик — за все остальное, то есть, говоря в терминах MVC, за Model и Controller.


      Одним из решений для управления Model (состоянием) вашего приложения стал Redux. Его появление мотивировано возросшей сложностью frontend-приложений, с которой не способен справиться MVC.


      Главный Технический Императив Разработки ПО — управление сложностью

      Совершенный код

      Redux предлагает управлять сложностью с помощью предсказуемых изменений состояния. Предсказуемость достигается за счет трех фундаментальных принципов:


      • состояние всего приложения хранится в одном месте
      • единственный способ изменить состояние — отправка Action'ов
      • все изменения происходят с помощью чистых функций

      Смог ли Redux побороть возросшую сложность и было ли с чем бороться?

      Читать дальше →
    • Шпаргалка по OTP (Erlang)

      • Tutorial

      Наверное многим, кто начинал изучать Erlang и Open Telecom Platform (OTP), было непросто запомнить все возможные настройки супервизора или ген-сервера, а также порядок входящих аргументов и формат возвращаемых значений. Основная сложность заключается в том, что описание любого процесса, будь то инициализация супервизора или синхронный вызов ген-сервера, находится в разных частях одной страницы документации. В самом начале освоения OTP такая навигация приводит к потере контекста и замедлению обучения. Не найдя шпаргалки по OTP на просторах интернета, пришлось создать свою. Надеюсь, она поможет вам в изучении (все картинки на английском языке).

      Читать дальше →
    • Моки и явные контракты

      • Translation

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


      Ниже представлен вольный перевод статьи, в которой José Valim — создатель языка Elixir — высказал своё мнение на проблему использования моков, с которым я полностью согласен.




      Несколько дней назад я поделился своими мыслями по поводу моков в Twitter:



      Мок — полезный инструмент в тестировании, но имеющиеся тестовые библиотеки и фреймворки зачастую приводят к злоупотреблению этим инструментом. Ниже мы рассмотрим лучший способ использования моков.

      Читать дальше →
      • +9
      • 23.9k
      • 3
    • Интерфейс vs interface

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


        Часто сложность в понимании принципа "программируйте на уровне интерфейса" кроется в концентрации на инструменте, а не на смысле. Из-за наличия в Java ключевого слова interface, происходит искажение понимания принципа, и он превращается в "программируйте, используя interface". Так как в Python инструмент в виде ключевого слова interface отсутствует, некоторые питонисты пропускают этот принцип.


        В книге Банды Четырех примеры приводятся на Smalltalk и C++. Оба этих языка не имеют ключевого слова interface, но это не мешает авторам применять принцип, используя имеющиеся в распоряжении конструкции языка:


        У манипулирования объектами строго через интерфейс абстрактного класса есть два преимущества:

        • клиенту не нужно иметь информации о конкретных типах объектов, которыми он пользуется, при условии, что все они имеют ожидаемый клиентом интерфейс;
        • клиенту необязательно "знать" о классах, с помощью которых реализованы объекты. Клиенту известно только об абстрактном классе (или классах), определяющих интерфейс.


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

        Но даже приведенные в цитате преимущества не являются единственными, если посмотреть на принцип под более широким углом.

        Читать дальше →
        • +19
        • 20.8k
        • 7
      • Automation QA — это отдельная команда?

        "Конечно отдельная!", — ответит большая часть читающих. Такой ответ укладывается в их картину мира, потому что “так работали всегда”. 


        Так работали всегда


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


        Компания понимает, что обойтись без страховочной сети нельзя, поэтому создается QA-отдел, который обычно не обеспечивает качество продукта, а лишь контролирует его. С QA-отделом разработчик может спокойно заниматься любимым делом — писать код, ведь ответственность за качество теперь несет выделенный отдел! Происходит классическое “перебрасывание кода через стену” в отдел тестирования:


        Читать дальше →