• Фантастические плагины, vol. 1. Теория

      Жизнь с многомодульным проектом не так уж проста. Чтобы избежать рутины создания нового модуля мы создали собственный плагин для Android Studio. В процессе реализации мы столкнулись с отсутствием практической документации, перепробовали несколько подходов и откопали множество подводных камней. Получилось две статьи: “Теория” и “Практика”. Встречайте!


      image

      Читать дальше →
      • +20
      • 3.7k
      • 8
    • Как мы поддерживаем стабильность приложения Lamoda

        Всем привет!

        Меня зовут Виталий Бендик. Я тимлид команды разработки Android приложения в компании Lamoda. В 2018 году я выступал на Mosdroid Aluminium c докладом, расшифровкой которого хочу поделиться.

        image

        Речь пойдет о том, как мы поддерживаем стабильность мобильного приложения. Для нас это очень важно, так как наша мобильная аудитория составляет миллионы пользователей. Кроме того, по доле в заказах наших клиентов приложения давно обогнали сайты, desktop и mobile версии в сумме, а платформа iOS стала абсолютным лидером, опередив desktop сайт.

        В докладе я расскажу:

        1. что мы понимаем под стабильностью приложения;
        2. об архитектуре нашего мобильного приложения;
        3. о процессах, практиках и инструментах, которые мы используем.

        Читать дальше →
        • +16
        • 4.2k
        • 8
      • Подборка полезных слайдов от Джулии Эванс

        • Translation
        Перевели новую порцию слайдов. Права доступа в Unix, файловые дескрипторы, потоки, магия proc. И на закуску пара советов о том, как общаться, когда ты не согласен. А вдруг пригодятся =)



        Читать дальше →
      • Выпускаем Predator — предкомпилированные Data-репозитории

        • Translation


        Сегодня, команда Micronaut в Object Computing Inc (OCI) представила Predator, новый проект с открытым исходным кодом, цель которого — значительно улучшить время выполнения и производительность (по памяти) доступа к данным для микросервисов и serverless-приложений, при этом не потеряв в продуктивности по сравнению с такими инструментами, как GORM и Spring Data.

        Читать дальше →
        • +14
        • 4.6k
        • 3
      • Справочник начинающего подкастера

        Эта статья — краткое руководство для тех, кто хочет запустить свой собственный подкаст. Когда я вместе с моим нынешним соведущим год назад запускал подкаст “В бесконечность и далее”, я не смог найти ни одной по-настоящему всеобъемлющей статьи. Поэтому я решил попытаться заполнить этот пробел и написать руководство для себя из прошлого.


        Немного о структуре — это руководство содержит 4 статьи:


        1. Общая философия
          1.1. Зачем делать подкаст?
          1.2. Целевая аудитория
          1.3. Выбор жанра
          1.4. Формат
        2. Технический базис
          2.1. Что такое подкаст с технической точки зрения
          2.2. Аудио-формат
          2.3. Про динамики, наушники и ламповый звук
          2.4. Про тихое помещение
        3. Делаем покупки
          3.1. Покупаем микрофон
          3.2. Выбираем аудиоредактор
          3.3. Выбираем программу для записи звука
          3.4. Выбираем хостинг подкаста
          3.5. Сайт-визитка
        4. Записываем и выпускаем
          4.1. Запись выпуска
          4.2. Редактирование выпуска
          4.3. Про джинглы и звуковые схемы
          4.4. Про фоновый шум
          4.5. Про фильтры
          4.6. Про Show Notes, а также про то, зачем слушать свой подкаст
          4.7. Публикация подкаста
          4.8. Монетизация
          4.9. Темы, которые есть, но о которых мы не говорили

        Каждый раздел статьи содержит три блока


        • Суть раздела — основная мысль, изложенная тезисно
        • Детальное описание “что, зачем и почему”. Обычно — много букв, которые поясняют основную мысль, и находятся они в скрытой секции “Дополнительная информация”
        • Ответ, который нашли мы

        Интересно — читайте все. Нет времени — читайте первый и последний абзац.



        1. Общая философия


        1.1. Зачем делать подкаст?


        Ответ может быть любым, но только не “потом посмотрим”, ”ещё не думал” или “не знаю”. Если ответа нет, весьма высока вероятность что

        Читать дальше →
      • Выборка данных с ORM — это просто! Или нет?


          Введение


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


          Мартин Фаулер опубликовал интересную статью, одна из ключевых мыслей там: “ORM’ы помогают нам решать большое количество задач в энтерпрайз приложениях… Этот инструмент нельзя назвать симпатичным, но и проблемы, с которыми он имеет дело, тоже не милашки. Я думаю, что ORM заслуживают больше уважения и больше понимания”


          Мы очень интенсивно используем ORM во фреймворке CUBA, так что не понаслышке знаем о проблемах и ограничениях этой технологии, поскольку CUBA используется в различных проектах по всему миру. Есть много тем, которые можно обсудить в связи с ORM, но мы сосредоточимся на одной из них: выбор между “ленивым” (lazy) и “жадным” (eager) способами выборки данных. Поговорим о разных подходах к решению этой проблемы с иллюстрациями из JPA API и Spring, а также расскажем, как (и почему именно так) ORM используется в CUBA и какие работы мы ведем, чтобы улучшить работу с данными в нашем фреймворке.

          Читать дальше →
          • +13
          • 4.6k
          • 5
        • Производительность анимаций на сайтах

          • Tutorial

          image


          При разработке сайтов, выходящих за рамки условного бутстрапа, рано или поздно возникают вопросы, связанные с производительностью анимаций. Особенно важными они являются в дизайнерских сайтах, вроде тех, что попадают в каталоги Awwwards, FWA, CSS Design Awards и.т.д. При этом часто задача создания анимаций и последующей оптимизации, если она будет нужна, ложится на плечи не очень опытных разработчиков, которые даже не знают с чего начать. Обычно все это выливается в тормозящие сайты, которыми невозможно пользоваться, и последующее негативное отношение ко всему классу таких проектов. В этой статье мы постараемся разобрать, где находится граница приемлемой производительности анимаций, какие узкие места часто встречаются и куда смотреть в инструментах разработчика в первую очередь.

          Читать дальше →
          • +14
          • 8.9k
          • 3
        • Не заставляйте слушателей рефлексировать

            Введение



            В процессе разработки очень часто возникает необходимость создать экземпляр класса, имя которого хранится в конфигурационном XML файле, или вызвать метод, название которого написано в виде строки как значение атрибута аннотации. В таких случаях ответ один: “Используй reflection!”.


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

            Читать дальше →
            • +11
            • 3.5k
            • 3
          • Как настроить типы задач и не сойти с ума

              Вводная часть


              В предыдущем посте я писал как организовать процесс “грумминга” задач в системе JIra так чтобы “Менеджеру продукта” было удобно осуществлять навигацию по всему Беклогу продукта. Продолжая продуктовую тему напишу о том как я долго шел к пониманию того — что такое типы задач в Jira.

              Важно тут сказать что дальше структуру которую я буду предлагать подойдет именно для процесса развития продукта(ов), но вряд ли будет корректной для управления проектами. Кстати если Вас волнует вопрос почему Agile это в большей степени фреймворк для управления продуктами но почитайте об этом вот тут.

              Структура задач


              В системе Jira на уровне проекта есть три уровня задач, это: Epics, Stories/Tasks, Sub-task. Оригинал статьи тут. Jira позволяет достаточно сильно кастомизировать эти сущности — можно менять названия, картинки, настраивать под эти задачи свои workflow. В этом то и кроется корень зла! Чем больше ты “кастомизируешь” систему под свои потребности не имея согласованного понимания что есть что, тем больше это вызывает вопросов и в конечном счете отторжение от работы в данном приложении.
              Читать дальше →
              • +10
              • 2.7k
              • 4
            • Яндекс открывает ClickHouse

                Сегодня внутренняя разработка компании Яндекс — аналитическая СУБД ClickHouse, стала доступна каждому. Исходники опубликованы на GitHub под лицензией Apache 2.0.



                ClickHouse позволяет выполнять аналитические запросы в интерактивном режиме по данным, обновляемым в реальном времени. Система способна масштабироваться до десятков триллионов записей и петабайт хранимых данных. Использование ClickHouse открывает возможности, которые раньше было даже трудно представить: вы можете сохранять весь поток данных без предварительной агрегации и быстро получать отчёты в любых разрезах. ClickHouse разработан в Яндексе для задач Яндекс.Метрики — второй по величине системы веб-аналитики в мире.

                В этой статье мы расскажем, как и для чего ClickHouse появился в Яндексе и что он умеет; сравним его с другими системами и покажем, как его поднять у себя с минимальными усилиями.
                Читать дальше →
              • Стажёр Вася и его истории об идемпотентности API

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


                  Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.


                  image

                  Читать дальше →
                • Анализ данных на Scala — суровая необходимость или приятная возможность?

                  • Tutorial


                  Традиционными инструментами в сфере Data Science являются такие языки, как R и Python — расслабленный синтаксис и большое количество библиотек для машинного обучения и обработки данных позволяет достаточно быстро получить некоторые работающие решения. Однако бывают ситуации, когда ограничения этих инструментов становятся существенной помехой — в первую очередь, если необходимо добиться высоких показателей по скорости обработки и/или работать с действительно крупными массивами данных. В этом случае специалисту приходится, скрепя сердце, обращаться к помощи "темной стороны" и подключать инструменты на "промышленных" языках программирования: Scala, Java и C++.


                  Но так ли уж темна эта сторона? За годы развития инструменты "промышленного" Data Science прошли большой путь и сегодня достаточно сильно отличаются от своих же версий 2-3 летней давности. Давайте попробуем на примере задачи SNA Hackathon 2019 разобраться, насколько экосистема Scala+Spark может соответствовать Python Data Science.

                  Читать дальше →
                • Lock-in: правда или вымысел?

                  • Translation

                  Я много лет обсуждал с клиентами технологии и их поставщиков, и многие употребляют термин "lock-in", означающий барьер для смены поставщика или привязку к поставщику. Вопросы звучали так: "Не станем ли зависимы от поставщика из-за этого продукта?" или "Решение X для нас предпочтительнее, потому что не поставит нас в зависимость от поставщика". Я много думал над этим вопросом и делился своими мыслями с клиентами, но на написание этого поста меня спровоцировало обсуждение поста @nigelpoulton под названием VSAN and HW arrays, где упоминался lock-in.


                  Я заявил, что этой параноидальной страшилки IT-индустрии никогда не было и быть не могло.

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

                  • Tutorial
                  В продолжение серии топиков под названием «фундаментальные вещи о Java, которые стоит знать, но которые многие не знают». Предыдущий топик: Бинарная совместимость в примерах и не только

                  Модель памяти Java — нечто, что оказывает влияние на то, как работает код любого java-разработчика. Тем не менее, довольно многие пренебрегают знанием этой важной темы, и порой наталкиваются на совершенно неожиданное поведение их приложений, которое объясняется именно особенностями устройства JMM. Возьмём для примера весьма распространённую и некорректную реализацию паттерна Double-checked locking:

                  public class Keeper {
                      private Data data = null;
                      
                      public Data getData() {
                          if(data == null) {
                              synchronized(this) {
                                  if(data == null) {
                                      data = new Data();
                                  }
                              }
                          }
                          
                          return data;
                      }
                  }
                  

                  Люди, пишущие подобный код, пытаются добиться улучшения производительности, избегая блокировки, если значение уже было присвоено. К сожалению, эти люди не учитывают многих факторов, в результате проявления которых может случиться зомби-апокалипсис. Под катом я расскажу теорию и приведу примеры того, как что-то может пойти не так. Кроме того, как говорили в одном индийском фильме, «Мало знать, что не так. Нужно знать, как сделать так, чтобы было так». Потому и рецепты успеха вы также сможете найти дальше.
                  Читать дальше →
                • Чек-лист: что нужно было делать до того, как запускать микросервисы в prod

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


                    К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.


                    Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.


                    English version is also available.

                    Читать дальше →
                  • Дополнительные лекции курса «Проектирование высоконагруженных систем» (осень 2018) в Технополисе

                      image

                      Мы продолжаем публиковать лекции курса «Проектирование высоконагруженных систем», который читается студентам Санкт-Петербургского Политехнического университета командой инженеров из Одноклассников в рамках двухлетней программы «Java-разработчик высоконагруженных приложений» проекта Технополис (совместный проект Mail.Ru Group и СПбПУ). В 2017 году были прочитаны и выложены 10 лекций (30 часов видео), но тема Highload настолько обширна, что за один семестр невозможно охватить всё. Мы лишь ненадолго погрузились в основные аспекты Highload-разработки, каждый из которых достоин отдельного курса. В этом году мы продолжаем закрывать белые пятна и представляем вашему вниманию набор из шести лекций на новые темы: начинаем с параллельных вычислений и livecoding первого этапа студенческого курсового проекта, после чего погружаемся в средства мониторинга и диагностики JVM, а потом переходим к проблемам отказоустойчивости. А после лекции о продвинутых алгоритмах, актуальных в высоконагруженных проектах, завершаем цикл лекцией о существующих подходах к репликации и об их применимости к разным задачам.

                      Первые десять лекций.

                      Список новых лекций:

                      1. Actor Model. Future. Reactive Streams (Вадим Цесько incubos)
                      2. Livecoding второго этапа проекта (Вадим Цесько incubos)
                      3. Мониторинг и диагностика JVM (Андрей Паньгин apangin)
                      4. Site Reliability Engineering (Антон Иванов keyplayer)
                      5. «Современные» структуры данных (Дмитрий Щитинин dormidoncheg)
                      6. Репликация (Дмитрий Щитинин dormidoncheg)

                      Читать дальше →
                    • Три простых приема для уменьшения Docker-образов

                      • Translation
                      image

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


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

                      Читать дальше →
                    • Spring JPA репозитории в CUBA


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


                        Предпосылки


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

                        Читать дальше →
                      • AWS показал Open Source средний палец

                        • Translation

                        От переводчика: мне кажется, заголовок слегка неточный и на самом деле средний палец показали ребятам из MongoDB, которая теперь не очень то и Open Source.



                        Сегодня, Amazon AWS запустил продукт DocumentDB — новую базу данных, совместимую с API MongoDB. Компания описывает DocumentDB так — "быстрая, масштабируемая и отказоустойчивая документная база данных, разработанная так, чтобы быть совместимой с вашими существующими приложениями и инструментами на MongoDB". Фактически, это полная замена MongoDB, развёрнутая в AWS, которая не использует код MongoDB.


                        В AWS утверждают, что, хотя MongoDB отлично справляется со своими задачами, их клиентам всё же трудно создавать быстрые и высокодоступные приложения на платформе с открытым исходным кодом, которые смогут масштабироваться до нескольких терабайт и сотен тысяч операций чтения и записи в секунду. Поэтому компания создала свою собственную базу данных документов, но сделала ее совместимой с API MongoDB 3.6, распространяющимся под лицензией Apache 2.0.

                        Читать дальше →
                      • Моки, стабы и шпионы в Spock Framework

                        • Translation

                        Spock предоставляет 3 мощных (но разных по сути) инструмента, упрощающих написание тестов: Mock, Stub и Spy.



                        Довольно часто коду, который нужно протестировать, требуется взаимодействовать с внешними модулями, называющимися зависимостями (в оригинальной статье используется термин collaborators, который не очень распространён в русскоязычной среде).


                        Модульные тесты чаще всего разрабатываются для тестирования одного изолированного класса при помощи различных вариантов моков: Mock, Stub и Spy. Так тесты будут надёжнее и будут реже ломаться по мере того, как код зависимостей эволюционирует.


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


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

                        Читать дальше →
                        • +12
                        • 3.4k
                        • 3