RxJava — это реализация ReactiveX для Java — библиотеки для асинхронной обработки потоков данных. Паттерн observable на стероидах, как они сами пишут. В интернете, в том числе на Хабре, есть много «введений в RxJava». Я хочу привести несколько примеров реальных задач. Они не очень сложные, но возможно кто-то увидит какие-то сходства со своими и задумается.

Собственно, задачи:

1. Простое клиентское TCP-соединение. Есть протокол поверх TCP/IP, нужно сформировать сообщение, подключиться к удаленному узлу, если еще не подключился, передать сообщение и прочитать ответ. Плюс обработка ошибок, проверка таймаутов, повтор отправки в случае неудачи. Жестких требований к производительности нет, трафик не большой.

2. Есть двигатель и некоторый датчик. Нужно произвести сканирование — пройтись двигателем по заданной траектории: послать двигатель к точке, дождаться, когда он к ней приедет, снять показания датчика, отобразить точку на графике (в GUI потоке), поехать к следующей точке…

3. Полученные после сканирования данные нужно обработать (условно длительный вычислительный процесс) и засунуть в pdf-отчет (условно длительный процесс ввода-вывода) вместе с изображением графика и данными введенными пользователем (GUI поток).

На днях мне понадобилась информация о том, какая архитектура IoT является типовой (референсной). Такую информацию оперативно найти не удалось ни на «хабре», ни на других ресурсах. Оказалось, что первые попытки разработать стандарты в этом направлении были предприняты всего два года назад, и работы все еще находятся в стадии «проект». В этой статье вы найдете «срез» состояния разработки стандартов IEEE & ISO/IEC по описанию референсной архитектуры IoT (IoT Reference Architecture).


Источник

Безопасность в моде, как это и должно быть. Мы живем в мире, где данные — невероятно ценная валюта, которую вы всегда рискуете потерять. Поэтому вы должны сделать все, чтобы убедиться, что то, что вы держите на серверах и десктопах — в безопасности. Для этого администраторы и пользователи создают невероятно сложные пароли, используют менеджеры паролей и т.д. Но что, если я вам скажу, что вы можете логиниться на ваши серверы и десктопы Linux за два шага, вместо одного? Вы можете это делать благодаря Google Authenticator. Более того, это невероятно легко настроить.

Я собираюсь провести вас через процесс настройки двухфакторной аутентификации для использования ее на логине и sudo. Я продемонстрирую это на десктопной Ubuntu 16.04, но процесс также работает и для сервера. Чтобы справиться с двухфакторной стороной вещей, я буду использовать Google Authenticator.

Время от времени пентестерам приходится сталкиваться с Java-приложениями. Это могут быть различные серверы, клиенты или просто десктопные программы. И иногда возникает необходимость «пропатчить» такое приложение. Зачем это нужно? Каждый случай возникновения такой необходимости уникален. К примеру:

• Сложный протокол общения между сервером и клиентом. Чтобы отправлять произвольные запросы – патчим;
• Захардкожены настройки. Чтобы поменять – патчим;
• Для демонстрации последствий проблем типа «race condition» – патчим.

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

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

Так как мы буквально на прошлой неделе завершили большой Web-проект, в котором как раз стояла цель разработки удобного интерфейса, я решил осветить в статье, на какие основные моменты при проектировании интерфейса стоит обратить внимание, и привёл примеры нашего решения.

Привет Хабр! Я работаю RnD-художником в минском центре разработки Wargaming. А в свободное время даю волю своей инженерной фантазии. В этой статье я хочу поделиться своим опытом домашнего марсоходостроения.

Регистрация на конференцию PG Day’16 в разгаре, а мы продолжаем публиковать перевод статей Hubert Lubaczewski об explain и его основных компонентах.

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

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

Я часто собеседую разработчиков и часто задаю им простой, как кувалда, вопрос — как внутри работает JOIN в SQL? В ответ я обычно слышу бессвязное мычание про волшебные деревья и индексы, которые быстрее. Когда-то мне казалось, что каждый программист специалист должен знать то, с чем работает. Впоследствии жизнь объяснила мне, что это не так. Но мне все еще не понятно, как можно годами теребить базёнку, даже не догадываясь, а что там у нее «под капотом»?

Давайте проведем ликбез и вместе посмотрим, как же работают эти джойны, и даже сами реализуем парочку алгоритмов.

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

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



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

Всем привет. Эта статья продолжение 10к на ядро с конкретными примерами оптимизаций, которые были проделаны для повышения производительности сервера. С написания первой части прошло уже 5 мес и за это время нагрузка на наш продакшн сервер выросла с 500 рек-сек до 2000 с пиками до 5000 рек-сек. Благодаря netty, мы даже не заметили это повышение (разве что место на диске уходит быстрее).


(Не обращайте внимание на пики, это баги при деплое)

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

Нативный Epoll транспорт для Linux

Одна из ключевых оптимизаций, которую стоит использовать всем — это подключение нативного Epoll транспорта вместо реализации на java. Тем более, что с netty это означает добавить лишь 1 зависимость:

<dependency>
   <groupId>io.netty</groupId>
   <artifactId>netty-transport-native-epoll</artifactId>
   <version>${netty.version}</version>
   <classifier>linux-x86_64</classifier>
</dependency>

и автозаменой по коду осуществить замену следующих классов:

• NioEventLoopGroup → EpollEventLoopGroup
• NioEventLoop → EpollEventLoop
• NioServerSocketChannel → EpollServerSocketChannel
• NioSocketChannel → EpollSocketChannel

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

• Метод selectedKeys() на каждый вызов создает новый HashSet
• Итерация по этому множеству создает iterator
• И ко всему прочему внутри метода selectedKeys() огромное количество блоков синхронизации

В моем конкретном случае я получил прирост производительности около 30%. Конечно же, эта оптимизация возможна только для Linux серверов.

Всем привет. Этот пост о серверном решении для интернета вещей, который я написал на асинхронных сокетах с использованием всем известной Netty. Я расскажу о задаче, которую мы ставили перед собой, о том почему я выбрал Netty, почему у нее нету альтернатив, какие у нетти недостатки и преимущества и как можно выжать максимум. Сейчас наш сервер в среднем обрабатывает 1.5 млрд сообщений в месяц и нагрузка с каждым месяцем растет на 20%. Для привлечения внимания — нагрузка на один продакшн сервер с 4-мя ядрами Xeon® CPU E5-2630L v2 @ 2.40GHz при лоаде в 500 рек-сек.



Итак, поехали.

Все началось около 2-х лет назад, когда мне подарили arduino. Я всегда мечтал сделать какое-то интересное устройство своими руками. Но все эти паяльники, резисторы, вольты-амперы меня постоянно отпугивали. Так было, пока не появились arduino. С ардуиной я смог наконец-то управлять электроникой. Сказать, что это было очень круто — не сказать ничего. Я был счастлив. Но, как это часто бывает, после освоения базовых навыков в микроконтроллерах, захотелось большего — управлять устройствами через интернет с телефона. Быстрый гуглинг показал (дело было 2 года назад), что на текущий момент нет ни одного решения, которое бы решало эту задачу. Не считая IoT облака с HTTP API, которые было не очень удобно использовать.

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

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

Да, для вертикального выравнивания в CSS есть специальное свойство vertical-align с множеством значений. Однако на практике оно работает совсем не так, как ожидается. Давайте попробуем в этом разобраться.

Это — аналоговое бумажное «приложение», вольвелла. То, что на фото — полетный портативный компьютер (относительно современная вольвелла)

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

Конечно, многие десятки, а то и сотни лет назад не было никаких экранов, тем более, сенсорных. Зато были так называемые вольвеллы, их вполне можно назвать предками современных приложений. Что такое вольвелла? Об этом давайте поговорим чуть ниже, а сейчас – представим, как определяли время в старину без наличия портативного часового механизма.

В этой статье я расскажу о Twitter Scalding – фреймворке для описания процесса обработки данных в Apache Hadoop. Я начну издалека, с истории фреймворков поверх Hadoop. Потом дам обзор возможностей Scalding. В завершение покажу примеры кода, доступные для понимания тем, кто знает Java, но почти не знаком со Scala.

Интересно? Поехали!

Добрый день, коллеги,

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

На видео ниже мы повесили мобильный маячок на простого робота и отправили его гулять по маршруту в виде восьмерки, чем он может и заниматься часами:



Или можно его отправить бегать по прямоугольнику:

День добрый, коллеги!

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

Из опыта code-review и ответов на StackOverflow набралось немало моментов, касающихся Java Collections API, которые мне казались очевидными, но другие разработчики о них почему-то не знали или знали, но не чувствовали уверенности их применять. В этой статье я собираю в общую кучу всё, что накопилось.

Содержание:

1. List.subList
2. PriorityQueue
3. EnumSet и EnumMap
4. Set.add(E) и Set.remove(E) возвращают булево значение
5. Map.put(K, V), Map.remove(K), List.set(idx, E), List.remove(idx) возвращают предыдущий элемент
6. Map.keySet() и Map.values()
7. Arrays.asList может быть ключом
8. Collections.max
9. LinkedList, Stack, Vector, Hashtable

Скажем прямо, русскому человеку планировать тяжело. Люди в России сильны импровизацией и умением собираться в критический момент, выдавая поразительные результаты. Но жизнь показывает, что команда программистов на подобной идеологии далеко не уедет. Героические усилия в одно время не смогут компенсировать пофигизм в другое.


Что общего у зомби-апокалипсиса и разработки ПО? Простые правила помогают пережить и то, и другое

Kudu был одной из новинок, представленых компанией Cloudera на конференции “Strata + Hadoop World 2015”. Это новый движок хранения больших данных, созданный чтобы покрыть нишу между двумя уже существующими движками: распределенной файловой системой HDFS и колоночной базой данных Hbase.

Существующие на данный момент движки не лишены недостатков. HDFS, прекрасно справляющаяся с операциями сканирования больших объемов данных, показывает плохие результаты на операциях поиска. C Hbase все с точностью до наоборот. К тому же HDFS обладает дополнительным ограничением, а именно, не позволяет модифицировать уже записанные данные. Новый движок, согласно разработчикам, обладает преимуществами обеих существующих систем:
— операции поиска с быстрым откликом
— возможность модификации
— высокая производительность при сканировании больших объемов данных