• Самодокументированные микросервисы (ArangoDB + swagger)

      Поддержание документации к микросервисам в актуальном состоянии по прежнему требует предельной дисциплины при разработке, ну и больших трудозарат. Очень разумный подход к созданию документации предлагает, например, GraphQL, где документация неразрывно связана с программным кодом и этим гарантируется 100% соответствие документации и документируемых сервисов. Однако, непривычность подхода GraphQL для разработчиков, привыкших к REST-API, все еще затрудняет продвижение этой технологии в практическую разработку приложений. Тут же можно вспомнить и SOAP, который уже давно решил проблему соответствия документации и сервисов, но из-за переусложненности не прижился в широких массах разработчиков.

      Хотелось бы найти такой стек технологий для разработки микросервисов, который обеспечил такую же самодокументируемость программного кода при разработке «традиционных» REST-API микросервисов. И он, как оказалось, уже существует.
      Читать дальше →
    • Database as Сode. Копаем глубже


        В IT-проектах код пишут все. Инженеры с помощью нескольких строк управляют Kubernetes кластерами, разгоняют облака Terraform'ом и ворочают тонны конфигураций на Ansible, Chef и Puppet. QA пишут понятные бизнесу тестовые сценарии на Spock и Cucumber. Аналитики свободно, часто лучше разработчиков, разговаривают на SQL. Проектная документация в форматах Markdown, AsciiDoc или LaTEX "компилируются" в нужный формат на билд-сервере. Ну а сами разработчики, эти укротители кода, владеют сразу россыпью языков на каждый жизненный случай — клиентский, серверный, скриптовый, функциональный и пр.


        Код уже давно перестал быть загадочной тарабарщиной и теперь в том или ином виде доступен и понятен многим, даже премьер-министрам. И весь этот код участвует в стандартном жизненном цикле — находится под управлением VCS, подвергается code review, автоматизированному тестированию, CI, CD. Используются общие инструменты и подходы, метрики производительности и качества. А все вместе это носит гордое название — "Everything as code".


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

        Database as Code? Что за дичь?
      • DDIA book (книга с кабанчиком) — сделай level up в понимании баз данных

          Несколько месяцев назад на одной из ретроспектив мы решили попробовать совместное чтение.

          Наш формат:

          1. Выбираем книгу.
          2. Определяем часть, которую необходимо прочитать за неделю. Выбираем небольшой объем.
          3. В пятницу обсуждаем прочитанное.
          4. Читаем в нерабочее время, обсуждаем в рабочее.
          5. После окончания книги совместно выбираем следующую.

          Что дает:

          1. Мотивация на чтение и дочитывание.
          2. Развитие скиллов (в том числе на будущее).
          3. Выравнивание майндсета и терминологии в команде.
          4. Рост доверия.
          5. Лишний повод пообщаться.

          Одна из недавних книг, которую мы читали — Designing Data-Intensive Applications. Да-да, та самая книга с кабанчиком. И эта книга настолько всем понравилась, что я решил сделать здесь обзор, чтобы большее количество людей ее прочитали.


          Карта в исходном качестве
          Читать дальше →
          • +22
          • 9,5k
          • 8
        • Я не буду учить твой Garbage Query Language

          • Перевод

          Это будет немного напыщенная речь, но меня действительно раздражает софт, в котором люди пытаются изобрести очередной собственный язык запросов. У нас уже есть триллион различных ORM, еще триллион баз данных с собственным языком запросов каждая, и еще триллион SaaS-продуктов, для доступа к которым нужно освоить какой-нибудь очередной DSL, которые они придумали.


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


          Однако вместо этого мне приходится изучать целый ворох разных "garbage query language", потому что люди по-прежнему пытаются изобрести колесо заново.

          Читать дальше →
        • MongoDB и исследование рынка ИТ-вакансий

          Вы когда-нибудь анализировали вакансии?

          Задавались вопросом, в каких технологиях наиболее сильна потребность рынка труда на текущий момент? Месяц назад? Год назад?

          Как часто открываются новые вакансии Java-разработчиков в определенном районе Вашего города и как активно они закрываются?

          В этой статье я расскажу Вам, как можно достичь желаемого результата и построить отчетную систему по интересующей нас теме. Поехали!


          Источник
          Читать дальше →
          • +16
          • 5,1k
          • 2
        • Актуальна ли проблема инъекций в JavaScript?

          • Перевод
          В былые времена, когда веб разработка строилась на том, что серверные приложения направляли запросы в реляционные базы данных и выдавали на выходе HTML, часто встречался такой код:

          // ВНИМАНИЕ: Плохой пример!
          function popup(msg: string): string {
              return "<p class=\"popup\">" + msg + "</p>";
          }

          или такой:

          // ВНИМАНИЕ: Плохой пример!
          function getName(login: string): string {
              return "SELECT name FROM users WHERE login = \"" + login + "\"";
          }

          С тех пор мы научились использовать более безопасные подходы.

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

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


          Читать дальше →
        • Теория и практика использования HBase

            Добрый день! Меня зовут Данил Липовой, наша команда в Сбертехе начала использовать HBase в качестве хранилища оперативных данных. В ходе его изучения накопился опыт, который захотелось систематизировать и описать (надеемся, что многим будет полезно). Все приведенные ниже эксперименты проводились с версиями HBase 1.2.0-cdh5.14.2 и 2.0.0-cdh6.0.0-beta1.

            1. Общая архитектура
            2. Запись данных в HBASE
            3. Чтение данных из HBASE
            4. Кэширование данных
            5. Пакетная обработка данных MultiGet/MultiPut
            6. Стратегия разбивки таблиц на регионы (спилитинг)
            7. Отказоустойчивость, компактификация и локальность данных
            8. Настройки и производительность
            9. Нагрузочное тестирование
            10. Выводы
            Читать дальше →
          • NewSQL = NoSQL+ACID


              До недавнего времени в Одноклассниках около 50 ТБ данных, обрабатываемых в реальном времени, хранилось в SQL Server. Для такого объема обеспечить быстрый и надежный, да еще и устойчивый к отказу ЦОД доступ, используя SQL СУБД, практически невозможно. Обычно в таких случаях используют одно из NoSQL-хранилищ, но не всё можно перенести в NoSQL: некоторые сущности требуют гарантий ACID-транзакций.

              Это подвело нас к использованию NewSQL-хранилища, то есть СУБД, предоставляющей отказоустойчивость, масштабируемость и быстродействие NoSQL-систем, но при этом сохраняющей привычные для классических систем ACID-гарантии. Работающих промышленных систем этого нового класса немного, поэтому мы реализовали такую систему сами и запустили ее в промышленную эксплуатацию.

              Как это работает и что получилось — читай под катом.
              Читать дальше →
            • Миграция данных ElasticSearch без потерь


                Академическое проектирование хранилища данных рекомендует держать все в нормализованной форме, со связями между. Тогда накат изменений по реляционной математике даст надежное хранилище с поддержкой транзакций. Atomicity, Consistency, Isolation, Durability — вот это все. Иначе говоря, хранилище специально строится для безопасного обновления данных. Но оно вовсе не оптимально для поиска, особенно широким жестом по таблицам и полям. Нужны индексы, много индексов. Объемы разрастаются, запись замедляется. SQL LIKE не индексируется, а JOIN GROUP BY отправляет медитировать в планировщик запросов.

                Читать дальше →
                • +16
                • 3,5k
                • 2
              • Где же у него кнопка?! Как простому человеку выгрузить данные из Kibana и Elasticsearch и не напрягать при этом разрабов

                  Elasticsearch, Kibana и Logstash (ELK) – отличный набор инструментов для сбора и визуализации большого количества данных.

                  Логи, журналы, события – всё это довольно легко собирается, мапится и отображается в едином инструментарии. Logstash мапит данные, Elasticsearch хранит их, а Kibana отображает в виде графиков.

                  При всей мощи этой связки, естественно, есть задачи, которые невозможно реализовать через встроенные возможности.

                  Например, Kibana прекрасно показывает данные в рамках одной таблицы (индекса), но как только дело доходит до объединения разных индексов в одну выборку, она беспомощно разводит руки.

                  И единственный способ решить задачу в этом случае – выгрузить данные из Kibana и объединить их в любом другом средстве, например, в Excel.

                  Простой пример. Представьте, что Ваша Ёлка (ELK) собирает и хранит события Jira – по любому изменению любой из задач таск-трекера.

                  В этом случае в индексе Elasticsearch по одной задаче будет храниться несколько записей:


                  Читать дальше →
                  • +15
                  • 3,9k
                  • 8

                Самое читаемое