Целью данной публикации не является полный анализ синхронизаторов из пакета java.util.concurrent. Пишу её, прежде всего, как справочник, который облегчит вхождение в тему и покажет возможности практического применения классов для синхронизации потоков (далее поток = thread).

В java.util.concurrent много различных классов, которые по функционалу можно поделить на группы: Concurrent Collections, Executors, Atomics и т.д. Одной из этих групп будет Synchronizers (синхронизаторы).



Синхронизаторы – вспомогательные утилиты для синхронизации потоков, которые дают возможность разработчику регулировать и/или ограничивать работу потоков и предоставляют более высокий уровень абстракции, чем основные примитивы языка (мониторы).

Как известно, в следующем январе сервис Parse будет закрыт. Большинство разработчиков ищут альтернативу для этого сервиса. В одном из проектов guthub собралось достаточно много альтернатив, со ссылками и описанием. Перед вами — перевод этой страницы.

Часть 1: универсальные сервисы

Провайдеры, предоставляющие информацию в реальном времени, помечены (*).

AnyPresence MBaaS (Mobile backend as a service). Упрощает процесс создания мобильных приложений предприятия, работающих на разных устройствах, не ущемляя гибкость средств, доступных разработчику. Легок в использовании даже для неопытных пользователей. Опытные разработчики получают доступ к исходникам всех компонентов.

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

Appcelerator Arrow (*) Состоит из двух основных компонентов, Builder и Cloud. Arrow Builder позволяет быстро создавать API, модели данных и соединители данных как через мастер настройки, так и через написание кода. Arrow Cloud – это эластичный облачный сервис, где выполняются API и происходит анализ их использования, плюс обеспечивается работа двух десятков смежных сервисов (гео, хранение фотографий и т.п.) с использованием ArrowDB

Appery.io Интегрированные сервисы MBaaS – чтобы разработчики могли сконцентрироваться на приложениях, не отвлекаясь на инфраструктуру.

Предлагаю вашему вниманию перевод статьи Ian Lake Intercepting everything with CoordinatorLayout Behaviors.

Вы не продвинетесь далеко в изучении Android Design Support Library, не столкнувшись с CoordinatorLayout. Множество View из Design Library требуют CoordinatorLayout. Но почему? Сам по себе CoordinatorLayout делает не так уж и много, если использовать его с View, входящими в состав Android фреймворка, то он будет работать, как обычный FrameLayout. Так откуда берётся вся его магия? Вот где на сцену выходит CoordinatorLayout.Behavior. Подключив Behavior к дочерней View у CoordinatorLayout, вы сможете перехватывать касания, оконные вставки (window insets), изменения размеров и макета (measurement и layout), а также вложенную прокрутку. Design Library широко использует Behavior чтобы добавить силу большинству функционалу, которую вы видите.

«Всякая строка кода рождается без причины, продолжается в слабости и удаляется случайно», — Жан-Поль Сартр программирует на ANSI C.

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

Чем больше у вашего API пользователей, тем больше кода приходится переписывать для введения новых изменений. Верно и обратное: чем больше вы полагаетесь на сторонний API, тем больше проблем испытываете когда он изменяется. Упорядочивание взаимодействия и взаимосвязей разных частей кода является серьезной проблемой в больших системах. И по мере развития проекта, растет и масштаб этой проблемы.

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

По данным Gartner, облачные технологии становятся все более востребованными. Если в 2012 году доля рынка IaaS составляла $6,1 млрд, то в 2015 году эта цифра выросла до $16 млрд. Более того, темпы роста популярности IaaS не снижаются.

Здравствуйте, уважаемые читатели!

Спасибо, что практически смели с полок нашу экспериментальную книгу по языку Swift. Серьезно обдумываем допечатку в апреле, консультируемся с автором насчет обновлений, а также подыскиваем другие, более фундаментальные книги. В ходе этих поисков довелось познакомиться с отличной статьей, которую можно было бы назвать «Что Swift грядущий нам готовит». Ее перевод найдете под катом.

Приятного чтения!

Приветствуем вас, уважаемые хабравчане!
Наш научный коллектив, который носит название Студенческого конструкторского бюро кафедры СУиИ Университета ИТМО, продолжает разработку курсов по робототехнике, и хочет поделиться одним из последних проектов на Lego NXT.

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

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

К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!

UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.

Что мы имеем сегодня

• Зоопарк дубовых VPS-хостингов.
• Дорогие IaaS и PaaS с гарантированным vendor lock in.
• Уникальные сервера-снежинки.
• Ворох устаревших зависимостей на неподдерживаемой операционке.
• Скрытые связи частей приложения.
• Незаменимый админ полубог на скейтборде.
• Радуга окружений: development, testing, integration, staging, production.
• Генерация конфигов для системы управления конфигами.
• Feature flagging.
  

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

Зачем это нужно?

В идеале, семантическая система «понимает» содержание обрабатываемых статей в виде системы смысловых понятий и выделяет из них главные («о чем» текст). Это дает огромные возможности по более точной кластеризации, автоматическому реферированию и семантическому поиску, когда система ищет не по словам запроса, а по смыслу, который стоит за этими словами.

Семантический поиск – это не только ответ по смыслу на набранную в поисковой строке фразу, а в целом способ взаимодействия пользователя с системой. Семантическим запросом может быть не только простое понятие или фраза, но и документ — система при этом выдает семантически связанные документы. Профиль интересов пользователя – это тоже семантический запрос и может действовать в «фоновом режиме» параллельно с другими запросами.

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

• вручную через интерфейс Zabbix;
• используя «Обнаружение» Zabbix;
• используя API Zabbix.

Добавление множества новых узлов вручную – рутинная задача, на решение которой уходит уйма времени. Хорошо, если новых узлов будет 5 – 10. А если 50 – 100 и больше? В этом случае вам поможет «Обнаружение». Настроив правила обнаружения и действия для обнаруженных узлов, Zabbix сам создаст новые обнаруженные узлы, подключит необходимые шаблоны, переместит созданный узел в нужную группу. Данный способ имеет недостаток.

Запустив наше облако, мы стали предоставлять сервис хранения, аналогичный S3 Амазона (с совместимым API, чтобы российские заказчики могли использовать стандартные клиенты для работы с S3, изменив только endpoint для подключения). Основная задача сервиса — хранение снапшотов виртуальных машин и различных файлов клиентов. Амазон был взят за образец, куда надо развиваться, и в начале 2014 года стало понятно, что имеющееся файловое хранилище устарело, заказчики требовали современных фичей, недоступных у нас и так нравящихся им у AWS. Но доработка существующего решения светила огромными трудозатратами, поэтому было принято решение построить новое S3-совместимое хранилище с нуля.

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

Это было чертовски долго, но всё прошло спокойно.

Jack (Java Android Compiler Kit) – это компилятор, преобразующий исходный код на Java в DEX-файлы Android. Jack – это набор инструментов, среди его возможностей – переупаковка, сжатие, обфускация и поддержка множественных DEX-файлов.

В Jack используются промежуточные библиотеки в формате .jack. Преобразованием существующих .aar/.jar файлов в этот формат занимается Jill (Jack Intermediate Library Linker).



Если для сборки используется Jack, то сначала Jill конвертирует внешние библиотеки, используемые в проекте, в .jack-файлы. Это подготавливает библиотеки к быстрому слиянию с другими .jack-файлами на следующем этапе, когда Jack и плагин Android Gradle, используя подготовленные ранее.jack-файлы и исходный Java-код, компилируют DEX-файл (или файлы). В ходе этого процесса Jack может выполнить минификацию кода (сжатие, обфускацию, или и то и другое вместе). На выходе получается APK-файл Android-приложения.

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

Большой мир генерирует большие данные. Вот и на нашу голову свалился большой граф. Настолько большой, что мы можем удержать в памяти его вершины, но не ребра. Кроме того, относительно графа приходят обновления – какое ребро добавить, какое удалить. Можно сказать, что каждое такое обновление мы видим в первый и последний раз. В таких условиях необходимо найти компоненты связности.

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

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

«Хмм… правдивого архитектора… А что, такие бывают? – спросите вы и подумаете. — Врет, поди! Сейчас будет нам рассказывать очередную концепцию „бла-бла-бла.2.0“. Знаем, плавали, видали мы „витающих в небесах архитекторов“ и их умозрительные конструкции».
И будете правы: нормальный «пацанский» архитектор — человек очень занятой, и времени писать статьи у него, как правило, нет… Но! Бывает, что настает момент – и желание человека поделиться опытом, рассказать о своих удачах и сложностях миру настолько высоко, что и время находится, и присущий нашему брату-технарю страх публичных высказываний отступает. К тому же коллеги по цеху давно призывали меня начать подобную деятельность.

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

Итак, попробуем поискать ответы на следующие вопросы.

• Что такое архитектура?
• Что такое целевая архитектура?
• Что такое архитектурные стандарты и фреймворки и зачем они нужны?
• Кто заказывает архитектуру, какие у нашего заказчика могут быть желания и потребности, высказанные и невысказанные?
• Какую архитектуру можно назвать хорошей архитектурой?
• Зачем нужны архитекторы? Какова их роль? Чего от них ожидать и почему?
• Когда компании нужно вкладываться в архитектуру? Что будет, если этого не делать?

Если вы когда-либо задавались подобными вопросами, и они представляют для вас интерес, то эта статья для вас — приглашаю поразмыслить вместе.

Некое продолжение статьи Go и Protocol Buffers толика практики (или быстрый старт, для тех кто ещё не знаком). Процессы кодирования/декодирования в определённые форматы в Go тесно связяны с рефлексией. А как мы с Вами, дорогой читатель, знаем — рефлексия — это долго. О том какие методы борьбы существуют эта статья. Думаю что, искушённые вряд ли найдут в ней, что-либо новое.

В субботу, 19 марта, мы впервые проведем Java-конференцию в Новосибирске. Называться она будет JBreak. Вот её сайт.

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

Почему Новосибирск?

Как многие из вас знают, за плечами у JUG.ru уже аж 6 Java-конференций — по 3 раза мы провели Joker и JPoint. Сначала это был Питер, а с 2014 года — и Москва.

Наши спикеры и участники давно говорили нам, чтобы мы сделали что-нибудь в Сибири. Мол, ехать в Питер или Москву из Сибири далеко и дорого, а Java-хардкора хотят не только в этих ваших столицах.Впервые этот разговор зашел за спикерским ужином после JPoint 2014, когда эту идею в явном виде озвучили нам Лёша Шипилев и Никита pjBooms Липский. Мол, Новосибирск — огромный город, в нем много джавистов, в нем сильная компиляторная школа, а главное, много людей, которым нужна сильная Java-конференция.

Поначалу мы отреагировали на это предложение без особого энтузиазма. Команда у нас была небольшая (я, real_ales и jetliner) и сил делать конференцию в далеком для нас городе мы в себе тогда не видели. А нынче погляди в окно многое изменилось. Наша команда выросла, укрепилась и наконец созрела. В какой-то момент мы смотрели гугловую аналитику на сайтах JUG.ru, Joker и JPoint и обнаружили, что в Новосибирске интерес к нашей деятельности действительно довольно велик: Top 5 городов выглядел так: Москва, Питер, Киев, Минск, Новосибирск. Стало понятно: нужно делать конфу в Новосибе!

В чем же особенности новой конференции?

Мы, компания Inoventica Services и наш партнер, Hewlett-Packard Enterprise, рады пригласить Вас в живую посетить наш уникальный облачный деревянный ЦОД в рамках юбилейного X Hi-Tech тура «HPE — в каждый дом!». Данное мероприятие проводится бесплатно, однако количество мест ограничено.

Время и место проведения: 18 февраля 2016 года, г. Владимир. Для участников тура организован автобусный трансфер из Москвы.

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

Разработчики Apache mesos заявляют, что mesos научился делать overprovisioning начиная с версии 0.23.0, вышедшей в сентябре прошлого года. Для этого ввели понятие отзываемых (revocable) ресурсов, и если приложение выполняется на отзываемых ресурсах — его всегда можно попросить освободить ресурсы частично (throttle) или полностью (kill). Определить, на каких ресурсах будет выполняться задача можно на этапе запуска, пометив некоторые (или все) запрошенные задачей ресурсы как revocable.

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

Несколько дней назад David Demaree, главный по Typekit в Adobe, издал крутую книжку "git для людей". Чтобы привлечь к ней внимание, он опубликовал выжимку самой, на мой взгляд, интересной главы — как оформлять коммиты чтобы и волки были целы, и овцы сыты, и песец не пришел. А я за эти выходные подготовил выжимку из выжимки — сокращенный и адаптированный перевод, чтобы можно было быстро прочитать и добавить в копилку своего опыта самое ценное.