• Чисто-функциональный REST API на Finagle/Finch

      Finch


      История библиотеки Finch началась около года назад «в подвалах» Конфеттина, где мы пытались сделать REST API на Finagle. Не смотря на то, что finagle-http сам по себе очень хороший инструмент, мы стали ощущать острую нехватку более богатых абстракциий. Кроме того, у нас были особые требования к этим самым абстракциям. Они должны были быть неизменяемыми (immutable), легко композируемыми (composable) и в тоже время очень простыми. Простыми как функции. Так появилась библиотека Finch, которая представляет собой очень тонкий слой функций и типов поверх finagle-http, который делает разработку HTTP (micro|nano)-сервисов на finagle-http более приятной и простой.

      Шесть месяцев назад вышла первая стабильная версия библиотеки, а буквально на днях вышла версия 0.5.0, которую я лично считаю pre-alpha 1.0.0. За это время 6 компаний (три из них еще не в официальном списке: Mesosphere, Shponic и Globo.com) начали использовать Finch в production, а некоторые из них даже стали активными контрибьюторами.

      Этот пост рассказывает о трех китах на которых построен Finch: Router, RequestReader и ResponseBuilder.
      Читать дальше →
    • Джо Армстронг об инструментах разработчика

      • Перевод
      Недавно на Erlang-mail листе проскочил следующий вопрос:
      Тулы, которые у нас есть для разработки на Erlang — просто мусор! Я прошу прощения, но сейчас 2014-ый, а мы все еще используем Vim и Makefile'ы. Да, есть Rebar. Но по сравнению с Maven, Gradle (или даже SBT) это студенческая поделка, которую кто-то выложил на GitHub. Про плагины для Eclipse и Intellij я вообще молчу. Они просто не работают. Поэтому я всегда возвращаюсь к Vim. Я просто хочу писать код, который решает мою задачу а не думать о том как написать Makefile со всеми зависимостями.

      Что ответил Джо этому нахалу?
    • Чисто функциональные структуры данных

        Признаюсь. Я не очень любил курс структур данных и алгоритмов в университете. Все эти стеки, очереди, кучи, деревья, графы (будь они не ладны) и прочие “остроумные” названия непонятных и сложных структур данных ни как не хотели закрепляться в моей голове. Как истинный “прагматик”, я уже на втором — третьем курсе свято верил в стандартную библиотеку классов и молился на дарованные нам (простым смертным) коллекции и контейнеры, бережно реализованные отцами и благородными донами CS. Казалось, все что можно было придумать — уже давно придумано и реализовано.

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

        И сейчас, я хочу показать вам небольшую частицу этого мира. Через замочную скважину, мы на секунду заглянем в этот удивительный мир, чтобы рассмотреть одного из наиболее ярких его обитателей — функциональное красно-черное дерево (КЧД).
        Читать дальше →
      • Работайте так, словно таланта у вас вообще нет

          Намедни наткнулся на замечательное высказывание талантливого боксера и невероятно сильного человека Роя Джонса. Он сказал: “Нужно работать так, словно таланта у тебя вообще нет”. Эти слова невероятно глубоко запали мне в душу. Я перечитал фразу раз двадцать и с каждым новым прочтением все больше понимал — “Да! Точно! Это именно то, чего мне не хватало.”

          Это высказывание подходит пожалуй к любой профессиональной деятельности, начиная от спортсменов заканчивая любыми представителями около-творческих профессий, где в той или иной форме требуется проявление таланта. Для меня программирование — искусное ремесло, которое требует от творителя неимоверной остроты ума, таланта и трудолюбия. Именно о талантливой составляющей в программировании я бы хотел порассуждать.
          Читать дальше →
        • Quipu — эзотерический язык программирования на основе узелковой письменности Инков

            Один мой друг, историк по профессии, подкинул мне замечательную идею об использовании древней мнемонической и счетной систем в современной криптографии. В процессе его рассказов об узелковой письменности Инков, я начал соображать, что все новое — хорошо забытое старое и было бы не плохо как-то применить древний опыт в современном мире. Первое, что пришло в голову — криптография. Это самое очевидное — просто сконвертировать узлы с ниток в байты и шифр готов. С одной стороны все казалось понятным, но потом я вспомнил про криптостойкость и другие параметры шифров и понял, что не обладаю достаточным опытом и знаниями в области криптографии, чтобы в одиночку разработать новый шифр.

            Дальше я решил попытаться представить некий эзотерический язык программирования, конструкции которого могут быть записаны с помощью узелковой письменности Кипу. Поначалу казалось, что это невозможно: я придумывал язык и пытался написать на нем программу вычисления факториала. Первые три черновика спецификаций ушли в урну: языки никуда не годились. Они выглядели как полагалось для эзотерических языков, но не помогали мне решать поставленную задачу, т.к. не были полными по Тьюрингу. Энтузиазм потихоньку угасал и эта задача казалась мне не по-плечу. Собравшись с силами, я решил, что если смогу написать программу вычисления факториала — то язык работает.

            Четвертая версия языка оказалось удачной: я написал факториал, затем генерацию последовательности Фибоначи и дюжину простых примерчиков аля “сумма чисел от 0 до 99”. Язык получился что надо: необычный и в тоже время с простой понятной идеей. Главное — язык может решить любую (ну или почти любую) задачу которую можно выразить в виде вычислимой функции.

            А теперь все по-порядку
          • Logy — логгер с человеческим лицом

              Некоторое время назад мне пришла в голову идея сделать логирование в Java более дружелюбным, простым и в тоже время достаточно гибким в настройке. Такие требования справедливы пожалуй, в средних и малых проекта, где можно обойтись без громоздкого log4j. Буквально за неделю, идея переросла в простенькую Java библиотеку с ни менее простым названием — logy.

              Использование:
              import static logy.Logy.*;
              
              public class Test {
                public void test() {
                  String s[] = {"a", "b"};
                  warn("Can't find", quote(upper("c")), "in", group(quote(upper(scalar(s)))));
                }
              }
              

              Вывод:
              29.06.2012 1:19:25 Test.test [WARN] :: Can't find "C" in ["A", "B"]

              Как по мне, выглядит очень читабельно, благодаря синтаксическому сахару, DSL-like API и динамическому определению параметров логирования в момент вызова (читай без дополнительных полей public static final Logger logger = ... в классе).
              Но и это еще не все.
            • Шаблоны проектирования в автоматном программировании


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

                В статье рассматриваются особенности применения шаблонов Visitor/Double Dispatch и State при реализации системы на основе конечного автомата. Кроме того, статью можно рассматривать как продолжение цикла публикаций о шаблонах проектирования на Хабрахабре.

                Читать дальше →
              • Мой open source велосипед

                  “Воин не бросит начатое.”
                  Мастер Шифу, м.ф. Кунг-фу Панда


                  Можно рассматривать этот топик не как технический, а как художественный. Тут не будет кусков кода, диаграмм классов и прочей ерунды. Будет история одного java open source проекта, который я разрабатываю уже около года.

                  Начало


                  Все началось, когда я был на четвертом курсе одного провинциального российского университета. С семестра, о котором ходили легенды на моей специальности, как о “семестре-убийце“ с его 55-ю лабораторными работами по графике, компиляторам и вычислительной математике (далее ВМ).
                  Читать дальше →
                • Идея реализации пакета I/O в Java


                    Совершенство достигается не тогда, когда уже нечего прибавить,
                    а когда уже ничего нельзя отнять.
                    Антуан де Сент-Экзюпери, Ветер, песок и звезды, 1939

                    Часто приходится проектировать и разрабатывать пакеты ввода/вывода для приложений на Java. С одной стороны есть java.io, которого бывает более чем достаточно. Однако, на практике редко удается обойтись набором стандартных классов и интерфейсов.

                    В статье, приводится практический пример идеи для реализации пакетов ввода/вывода на платформе Java.

                    Читать дальше →
                  • Правильный Singleton в Java

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

                      Кроме того, можно рассматривать статью как продолжение замечательного исследования, публиковавшегося на Хабрахабре ранее.
                      Читать дальше →
                    • История одной оптимизации



                        Аннотация


                        Статья раскрывает особенности высокоуровневых оптимизаций вычислительных алгоритмов на Java на примере кубического алгоритма перемножения матриц.

                        Шаг 0. Установи точку отсчета!


                        Определимся с окружением:
                        • Hardware: 1-socket/2-cores Intel Core 2 Duo T7300 2GHz, 2Gb ram;
                        • Java: HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing);

                        Читать дальше →
                      • Паттерн проектирования «Команда» / «Command»

                          Почитать описание других паттернов.
                          A

                          Проблема


                          Необходимо иметь эффективное представление запросов к некоторой системе, не обладая при этом знаниями ни об их природе ни о способах их обработки.

                          Описание


                          Существует по крайней мере три мотивации к использованию шаблона “Команда”:
                          • инкапсулирование запроса в виде объекта для последующего протоколирования/логирования и т.п.
                          • наделение сущности “вызов метода объекта” свойствами самостоятельного объекта;
                          • объектно-ориентированный обратный вызов (callback);

                          Читать дальше →
                        • Паттерн проектирования «Цепочка обязанностей» / «Chain of Responsibility»

                            Почитать описание других паттернов.


                            Проблема


                            Эффективно и компактно реализовать механизм обработки потока событий/запросов/сообщений в системах с потенциально большим количеством обработчиков.

                            Описание


                            Модель событие/обработчик широко применяется в программных системах из различных областей. В основном, это — графический интерфейс пользователя, где события, генерируемые от действий пользователя различным образом обрабатываются элементами интерфейса. Нельзя так-же забывать про WinAPI, который сплошь и рядом реализует такую модель. В большинстве источников эта модель имеет название Event Loop.

                            Читать дальше →
                          • Онлайн кинотеатр

                              Прочитав заголовок, многие подумают — «Такое давно уже есть, тьма примеров». Однако, предлагаемая идея стартапа заключается вовсе не в организации сервиса просмотра видеофильмов онлайн, коих на самом деле сейчас существует большое множество. Идея в другом.

                              Читать дальше →
                            • Загрузка классов в Java. Практика

                                Данная статья является продолжением статьи Загрузка классов в Java. Теория.

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

                                Код приложения не претендует на оригинальность, а лишь объясняет подходы и принципы написания пользовательских загрузчиков классов и методы инвокации динамического кода.
                                Читать дальше →
                              • Загрузка классов в Java. Теория



                                  Одной из основных особенностей платформы Java является модель динамической загрузки классов, которая позволяет загружать исполняемый код в JRE не перезагружая основое приложение. Такая особенность широко используется в серверах приложений, получивших последнее время высокую популярность.

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

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

                                    Почитать описание других паттернов.

                                    GRASP (General Responsibility Assignment Software Patterns) — шаблоны проектирования, используемые для решения общих задач по назначению обязанностей классам и объектам.

                                    Известно девять GRAPS шаблонов, изначально описанных в книге Крейга Лармана «Применение UML и шаблонов проектирования». В отличие от привычных читателю паттернов из Банды Четырех, GRAPS паттерны не имеют выраженной структуры, четкой области применения и конкретной решаемой проблемы, а лишь представляют собой обобщенные подходы/рекомендации/принципы, используемые при проектировании дизайна системы.

                                    Рассмотрим характеристики основных GRASP шаблонов.
                                    Читать дальше →
                                  • Паттерн проектирования «Заместитель» / «Proxy»

                                      Почитать описание других паттернов.

                                      Проблема


                                      Необходимо контролировать доступ к объекту, не изменяя при этом поведение клиента.

                                      Описание


                                      При проектировании сложных систем, достаточно часто возникает необходимость обеспечить контролируемый доступ к определенным объектам системы. Мотивацией для этого служит ряд приобретаемых преимуществ. Таких как, ленивая инициализация по требованию для «громоздких» объектов, подсчет количества ссылок на объект и т.д. и т.п. Однако, не всегда потребность в контролируемом доступе к объекту базируется только на преимуществах. Как правило, сложность процессов реального мира, ограничения вычислительных ресурсов просто не оставляют проектировщику выбора, нежели как воспользоваться паттерном «Заместитель» («Сурогат»).
                                      Читать дальше →
                                    • Паттерн проектирования «Приспособленец» / «Flyweight»

                                        Почитать описание других паттернов.

                                        Проблема


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

                                        Описание


                                        Как уже отмечалось, существует большое количество программных систем, предназначением которых, является конструирование сложных составных объектов из большого числа более мелких и простых объектов. При этом, гибкость и универсальность подобных систем, достигается за счет предоставления пользователю полного набора инструментов и примитивов. Важно понимать, что примитивами, в данном контексте являются элементарные объекты, из которых в последствии конструируются составные. Причем, уровень на котором, объект считается примитивным, на самом деле, определяет применимость и эффективность данной системы. Однако, не всегда существует возможность спроектировать систему вплоть до самых низких уровней абстракции. Затраты на память и низкая производительности системы, при прямом подходе, не позволяют этого сделать. Поэтому, при проектировании подобных систем, зачастую применяют паттерн «Приспособленец».
                                        Читать дальше →
                                      • Паттерн проектирования «Фасад» / «Facade»

                                          Почитать описание других паттернов.

                                          Проблема


                                          Минимизировать зависимость подсистем некоторой сложной системы и обмен информацией между ними.

                                          Описание


                                          При проектировании сложных систем, зачастую применяется т.н. принцип декомпозиции, при котором сложная система разбивается на более мелкие и простые подсистемы. Причем, уровень декомпозиции (ее глубину) определяет исключительно проектировщик. Благодаря такому подходу, отдельные компоненты системы могу быть разработаны изолированно, затем интегрированы вместе. Однако возникает, очевидная на первый взгляд, проблема — высокая связность модулей системы. Это проявляется, в первую очередь, в большом объеме информации, которой модули обмениваются друг с другом. К тому же, для подобной коммуникации одни модули должны обладать достаточной информацией о природе других модулей.

                                          Таким образом, минимизация зависимости подсистем, а также снижение объема передаваемой между ними информации — одна из основных задач проектирования.

                                          Один из способов решения данной задачи — использование паттерна «Фасад».
                                          Читать дальше →