• Эволюция приложений или куда мы идем

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


      image

      Читать дальше →
    • Node.js и JavaScript вместо ветхого веба

        Вступление


        Эта статья про экспериментальный технологический стек общего назначения. Она не просто дублирует мой доклад на конференции ОдессаJS 2016, но содержит все то, что в доклад не поместилось из-за недостатка времени и исключительного масштаба темы. Я даже перезаписал доклад голосом по тексту статьи и это можно послушать, а не читать. С этой темой я уже выступил в Уханьском Университете (Китай), а в Киевском Политехническом Институте провел целую серию семинаров в 2015-2016 годах. Основная идея состоит в том, что проблемы фрагментации технологий могут быть решены, если спроектировать весь технологический стек, сконцентрировавшись на структурах данных, синтаксисе и протоколе взаимодействия компонентов. Большинство вопросов несовместимости, отпадет само собой. Пусть даже этот подход будет альтернативным и экспериментальным, но его задача будет выполнена, если он наметит путь и продемонстрирует принципиальную возможность создания простого и элегантного решения общего назначения. Эта идея является естественным продолжением подхода Node.js, когда мы сокращаем количество языков и технологий в системе, разрабатывая и клиент и сервер на JavaScript. Несмотря на экспериментальность, протокол JSTP уже используется в коммерческих продуктах, например, для интерактивного телевидения компанией SinceTV, где позволяет подключить одновременно десятки миллионов пользователей. Это решение получило приз за инновации в области телевидения на международном конкурсе Golden Panda Awards 2015 в Ченду (Китай). Есть внедрения в сфере управления серверными кластерами, готовятся решения для медицины, интерактивных игр, электронной торговли и услуг.



        Слайды / Аудио версия


        Читать дальше →
      • Примеры кода с летней школы по Node.js и JavaScript в КПИ

        • Tutorial

        Товарищи инженеры, докладываю вам об успехах в подготовке научно-технических кадров в области программной инженерии на Факультете ИВТ в Киевском политехническом институте и публикую интересные примеры кода, которые были написаны для учебного курса, но будут, надеюсь, интересны и с практической точки зрения. Идея, внедрить JavaScript и Node.js в учебный процесс, вызревала у меня уже несколько лет. Но для освоения базовых вещей в программировании мне больше нравится C, чтобы люди прочувствовали машину, научились контролировать себя и свой код. А вот для прикладных задач, в которых уровень абстракции C уже не достаточно иллюстративен, мультипарадигменный и гибкий JavaScript прижился. При помощи мощного и простого API Node.js можно писать концептуальный код прямо на паре. Кроме того, знания JavaScript обязательно пригодятся на практике любому инженеру, работающему в ИТ. Часть кода, разработанного студентами курса, уже попала в серьезные Open Source проекты и это прекрасная практика, которую может повторить каждый, ведь лабораторные работы мы постепенно выкладываем на github и будем делать это и дальше, снабжая их методическими указаниями и не заботясь о том, что студенты будут списывать из форков, ведь все это нужно в первую очередь им самим. Эти материалы были использованы при подготовке порядка 300 студентов политехнического ВУЗа за 2015-2016 учебный год. Примеры я еще раз разложу по полочкам на летней школе, которая проходит с 9 по 26 августа 2016 года в Киеве, и расписание которой можно найти тут. Итак, переходим к самым показательным примерам кода.

        Читать дальше →
      • Как исправить ошибку в Node.js и нечаянно поднять производительность в 2 раза

          Началось все с того, что я оптимизировал отдачу ошибки HTTP 408 Request Timeout в сервере приложений Impress, работающем на Node.js. Как известно, у нодовского http.Server есть событие timeout, которое должно вызываться для каждого открытого сокета, если тот не закрылся за указанное время. Хочу уточнить, что не для каждого запроса т.е. не для каждого события request, функция которого имеет два аргумента (req, res), а именно для каждого сокета. Через один сокет может последовательно поступить много запросов в режиме keep-alive. Если мы задаем это событие, через server.setTimeout(2 * 60 * 1000, function(socket) {...}) то должны сами уничтожать сокет socket.destroy(). Но если не установить свой обработчик, то http.Server имеет встроенный, который уничтожит сокет через 2 минуты автоматически. На этом самом таймауте можно отдать ошибку 408 и считать инцидент исчерпанным. Если бы не одно но… С удивлением я обнаружил, что событие timeout вызывается и для тех сокетов, которые подвисли и для уже получивших ответ и для закрытых клиентской стороной, вообще для всех, находящихся в режиме keep-alive. Это странное поведение оказалось достаточно сложным, и я расскажу об этом ниже. Можно было бы вставить одну проверку в событие timeout, но со своим идеализмом я не удержался и полез исправлять баг на уровень глубже. Оказалось, что в http.Server режим keep-alive реализован не то что не по RFC, а откровенно не дописан. Вместо отдельного timeout для соединения и отдельного keep-alive timeout, там все на одном таймауте, который реализован на быстрых псевдо-таймерах (enroll/unenroll), но задан по умолчанию в 2 минуты. Это было бы не так страшно, если бы браузеры хорошо работали с keep-alive и переиспользовали его эффективно или закрывали бы неиспользуемые соединения.
          Читать дальше →
        • Impress Application Server простыми словами

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

            Impress Application Server (IAS) — это сервер приложений для Node.js с альтернативной архитектурой и философией, не похожий на мэйнстрим разработки под нодой и призванный упростить и автоматизировать широкий круг повторяемых типовых задач, поднять уровень абстракции прикладного кода, задать рамки и структуру приложений, оптимизировать как производительность кода, так и производительность разработчиков. IAS покрывает сейчас только серверные задачи, но делает это комплексно, например, можно объединить на одном порту API, веб-сокеты, стриминг, статику, Server-Sent Events, проксирование и URL-реврайтинг, обслуживать несколько доменов и несколько приложений, как на одном сервере, так и на группе серверов, работающих в связке, как одно целое, как один сервер приложений.
            Читать дальше →
          • Краткая заметка про наследование в Node.js

              В JavaScript существует множество разных способов наследования, классового и прототипного, фабричного и через примеси, прямого и непрямого, а так же гибриды нескольких методов. Но у Node.js есть его родной способ с применением util.inherits(ChildClass, ParentClass). До недавнего времени я использовал нодовский способ только для встроенных классов (когда нужно сделать своего наследника для EventEmitter, Readable/Writable Stream, Domain, Buffer и т.д.), а для моделирования предметной области применял общеупотребительные для всего JavaScript практики. И вот, впервые, понадобилось реализовать собственную иерархию системных классов, не наследников от встроенных, но и не классов предметной области, а классов, массово поражаемых в системном коде сервера приложений Impress. И простого использования util.inherits уже как-то не хватило, поискал я статьи и не найдя полностью всего, что мне нужно, изучил примеры наследования в исходниках самой ноды, подумал и сделал пример родного нодовского наследования себе на память и написал эту небольшую заметку, чтобы она, надеюсь, помогла еще и вам. Сразу предупреждаю, что реализация вызова метода родительского класса из переопределенного в дочернем классе метода, мне не очень нравится из-за громоздкости, поэтому, приветствую альтернативные способы и приглашаю коммитить их в репозиторий или в комментарии к этой заметке.

              Читать дальше →
            • Метапрограммирование (с примерами на JavaScript)

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

                Популярное понимание метапрограммирования обычно очень размытое, и чаще всего, заканчивается такими вариантами:
                • Шаблоны и макросы, используемые при компиляции
                • Программа, которая изменяет саму себя
                • Программа, генерирующая другую программу

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

                Читать дальше →
              • Назад, к технологиям верхнего палеолита, от любимых всеми REST, STATEless, CRUD, CGI, FastСGI и MVC

                  «Только со смертью догмы начинается наука.»
                  // Галилео Галилей


                  «Я начал завидовать рабам. Они всё знают заранее. У них твёрдые убеждения.»
                  // х/ф Марка Захарова «Убить дракона» по мотивам пьесы Евгения Шварца


                  Уже пару лет и дня не проходит, чтобы я не услышал (или не прочитал) от людей, начинающих новые проекты, фразу типа «Возьмем серверный движок для REST API и MVC, и погнали». Сначала я думал, что у этих слов есть один источник, может книжку какую завезли во все магазины или где-то в топе поисковиков лежит статья, зомбирующая разработчиков. Если же выяснять у них, что они понимают под REST и MVC, то можно повредиться умом. Ну с MVC уже все ясно, об этом я уже давно писал, ничего не изменилось, только усугубилось, стоит набрать в Google Images «mvc» и мы увидим страшное, стрелочки в любые стороны. Ну а про REST отвечают следующее: ну как же, нам нужно из браузерного GUI и мобильного приложения вызывать серверные методы, например: setUserCity(userId, cityId) или calculateMatrix(data) или startVideoConverter(options, source, destination) а потом мы столкнемся с большой нагрузкой и архитектура REST все решит. Дальше я задаю вопросы, от которых глаза округляются уже у тех, кто недавно еще горел праведной верой, рвался в бой и точно знал, что к чему в этом мире. Теперь можно перейти к рассмотрению терминологической катастрофы, в эпицентре которой мы с вами пребываем.
                  Читать дальше →
                • Новая функциональность Impress Application Server для Node.js

                    Предоставляю вам краткий отчет об изменениях в Impress AS за последние несколько месяцев. Во-первых мы не пошли путем фреймворков, а ринулись в сферу серверов приложений, обеспечивая масштабирование в двух направлениях: (1) много приложений на одном сервере и (2) много серверов для одного приложения. Первое направление требовало развивать сендбоксинг (экранирования приложений друг от друга и от среды запуска), а второе направление предусматривало переход от кластера к многосерверному клауду. Тут нужно уточнить терминологию, в ноде кластером (cluster) принято называть способ многопоточного запуска приложений в режиме master/worker, поэтому, многосерверную инфраструктуру (с кластером на каждом сервере) мы будем называть клаудом (или прикладным облаком). Это облако ни как не связано с виртуализацией операционной системы, как это обычно ложно связывается в понимании широких масс. Облачные технологии совсем не обязаны быть организованы на базе технологий виртуализации, но другого простого способа масштабирования сейчас для массового потребления нет. Облачная виртуализация не гарантирует бесконечной виртуализации прикладных приложений, и всем разработчикам крупных высоконагруженных систем известно, что для сотен тысяч и десятков миллионов пользователей нужно создавать специальные прикладные решения, обеспечивающие прикладную виртуализацию, размазывающую задачи по серверам и объединяю их в одну, распределенно функционирующую, но централизовано управляемую систему. Именно эту задачу мы и взялись решать в Impress, надеюсь я отстоял терминологию и могу переходить к подробностям.
                    Читать дальше →
                  • О стандартах мыслей свежих несколько

                      Речь пойдет, о технических стандартах, т.е. протоколах, спецификациях, паттернах, конвенциях, интерфейсах, форматах данных, нотациях и других отраслевых и особенно внутренних нормах, которые мы используем или изобретаем при разработке программных систем. Очевидных вещей я не буду повторять, каждый знает, что стандарты — это хорошо и правильно, что они способствуют унификации и, следовательно, совместимости систем и их модулей. Надеюсь, мои обобщения опыта, в форме «заметок для себя», будут полезными и нетривиальными.
                      Читать дальше →
                      • +10
                      • 7,6k
                      • 4