Мы регулярно пишем про голосовых ботов и автоматику входящих-исходящих звонков. Подтверждение доставки, заказов, угадывание и автоответ клиенту пока соединяемся с компанией — вся вот эта история. В комментариях мне резонно заметили, что про ботов я говорю много, а показываю мало. Это легко исправить! Хакатон S7 в Парке Горького в самом разгаре, 50 команд фигачат прототипы разного интересного — а у меня есть возможность попробовать уложиться в как можно меньшее количество строк кода. Минимализм в примерах — это круто.

Хочу рассказать вам о новом языке программирования, который называется Kotlin, и объяснить, почему вам стоит использовать его в своём следующем проекте. Раньше я предпочитал Java, но в последний год пишу на Kotlin везде, где только можно. И в данный момент я не представляю себе ситуации, в которой лучше было бы выбрать Java.

Kotlin разработан в JetBrains, и участие тех же людей в создании наборов IDE, таких как IntelliJ и ReSharper, хорошо заметно по самому языку. Он прагматичен и краток, благодаря чему написание кода превращается в приятный и эффективный процесс.

Хотя Kotlin компилируется в JavaScript и скоро будет компилироваться в машинный код, я сконцентрируюсь на его первичной среде — JVM.

Итак, несколько причин, почему вам следует полностью переходить на Kotlin (порядок случаен):

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

Современные же приложения стремятся использовать все имеющиеся ресурсы, в частности, все доступные CPU.

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

Однако, не взирая на всю технологическую мощь, заложенную в пакет java.util.concurrent, обработка информации потокобезопасными коллекциями возможна лишь в рамках одного компьютера, а это порождает проблему масштабируемости.

А что если нужно, в реальном времени, обрабатывать информацию о 100 миллионах клиентов,
когда датасет занимает 100Тб, а каждую секунду нужно совершить 100+ тысяч операций?
Вряд ли это возможно, даже на самом крутом современном железе, а если и возможно — только представьте себе его стоимость!

Намного дешевле добиться такой же вычислительной мощности объединив множество обычных компьютеров в кластер.

Остается лишь вопрос межкомпьютерного взаимодействия привычными средствами, схожими по API с потокобезопасными коллекциями из пакета java.util.concurrent и дающими те же гарантии, но не на одном компьютере, а на всем кластере.

Особенно нетерпеливых отсылаю сразу в конец статьи где будет ссылка на готовый .deb-пакет для установки.

А для всех остальных…

Что это такое и для чего это нужно

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

История номер один. (основано на реальных событиях)

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

Операционная система Android предоставляет мощный фундамент для разработки приложений, которые отлично работают на множестве разнообразных устройств и форм-факторов. Теперь, как говорится, мы услышали жалобы разработчиков: трудно создавать "безглючные" приложения в условиях сложных циклов жизни объектов и отсутствия рекомендованной архитектуры приложения.

Нам, создателям Android, надо сделать простым и веселым написание устойчивых приложений, чтобы перевести усилия разработчиков в те области, в которых можно создавать инновации. Сегодня мы аннонсируем путеводитель по архитектуре Android-приложений и превью библиотек Architecture Components. Вместо того чтобы изобретать колесо, мы признаем работу, сделанную авторами популярных сторонних Android-библиотек (прим. пер.: WAT?).

Долго меня мучала идея из старенького RPI сделать принт-сервер (удаленная печать и сканирование) и наконец я до этого добрался.

Исходим из того, что у нас есть набор из RPI, флешки с Raspbian, Wi-Fi адаптера, принтера HP LaserJet Pro 1102, МФУ HP Deskjet F2180 и usb-хаба. Основная машина (ББ), которая будет использовать принт-сервер живет на Linux (впрочем, отличия в использовании для Windows будут минимальны).

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

0. Предисловие

Все началось с очередного звонка пользователя, который с гордостью сообщил сообщил: — „Всё сломалось“, и с моих „потуг“ удаленно найти PC, на котором работает данный пользователь..

Решение планировало быть простым до безумия и собираться на коленке. Так-как большинство наших сотрудников работают под "виндой" и все рабочие станции входят в домен, был задан вектор поиска решения. Изначально, планировалось написать небольшой скрипт. В его задачу входило собрать базовую информацию о системе и сотруднике, который за этой системой работает. Набор информации минимальный. А именно: логин, название рабочей станции и ее ip. Результат работы сохраняем на сервере, а сам скрипт "вешаем" на пользователя через GPO.

В такой реализации были существенные недостатки в виде:

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

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

Состоялся релиз версии 0.5 кросслплатформенного XAML UI фреймворка AvaloniaUI (раннее назывался Perspex). Фреймворк сделан по тем же принципам, что и WPF/UWP, т. е. используется XAML, биндинги и шаблонизированные элементы управления. На текущий момент это единственный способ сделать UI на настоящем XAML, который будет работать на Windows, OS X и Linux (так же имеется экспериментальная поддержка iOS и Android).

→ Каталог встроенных контролов (gif 3MB)

Начать работать с фреймворком можно скачав дополнение для Visual Studio 2017 и создав проект из шаблона. Так же стоит ознакомиться с документацией на wiki.

В этом релизе: Поддержка .NET Core, переход на GTK3 для *nix-систем, поддержка вывода через Linux fbdev, система расширений, исправлено множество ошибок.

Чтобы полностью раскрыть все преимущества Kotlin, пересмотрим некоторые подходы, которые мы используем в Java. Многие из них могут быть заменены на лучшие аналоги из Kotlin. Давайте посмотрим на то, как мы можем написать идиоматичный код на Kotlin.

В последнее время имена GridGain и Apache Ignite нередко мелькают в интернетах. Однако, судя по комментариям (например, здесь), мало кто понимает, что же это за продукт и с чем его едят.

В этой статье я попытаюсь доступным языком объяснить, и на примерах кода показать, что умеет Apache Ignite.

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

Сервис omg-img позволяет вставлять иконки вот так:

<img src="https://png.icons8.com/search">

Чувствуете, к чему я клоню? Сделали вставление иконок не выходя из IDE. Просто пишете URL, параметры вроде цвета и стиля — мы отрендерим иконку и отдадим через хороший, годный CDN.

Вместо search можно написать любое название иконки:

• home
• sheep-on-bike
• trump

Что Вы делаете, когда Ваше Java приложение потребляет 100% ЦП? Оказывается Вы легко можете найти проблемные потоки, используя встроенные Unix и JDK утилиты. Никакие инструменты профилирования не потребуются.
С целью тестирования мы будем использовать простую программу:

Думаю, не мне одному чрезвычайно надоели ресурсы, требующие регистрации по каждому поводу и без. С обязательной капчей, которая правильно введется только с пятого раза, с подтверждением по е-мейлу, которое обязательно свалится в спам и то — только через сутки. Придумывать каждый раз новую пару логин-пароль — забудется, вводить одно и то же на всех сайтах — небезопасно. Местами прокатывают пары вида «qwerty:qwerty» или «login:password», но, увы, далеко не везде. Надоело. Не счесть, сколько раз я, увидев надпись «только зарегистрированный пользователь может ****», просто кривился и закрывал вкладку, чтобы больше ни разу на этот сайт не заходить. Неужели администраторы ресурсов сами этого не понимают?

У нас накопилось много бесплатных материалов по работе с облаком, поэтому мы решили поделиться с вами самыми последними из них. Под катом вы найдёте описание 6 курсов и 12 книг/гайдов по обучению работе с Azure.

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

Люди часто спрашивают меня:
Зачем мне вообще использовать RxJava или Reactor, если то же самое можно сделать с помощью Streams, CompletableFutures и Optionals?

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

Давайте определим 8 критериев, которые помогут нам понять разницу между этими библиотеками и стандартными возможностями Java:

→ Первая часть тут

Анализ и описание процессов

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

Пару лет назад я наткнулся на проект Bartendro на Kickstarter. Мне понравилась идея, и я решил, что идеальное применение для моего недавно приобретенного Raspberry Pi найдено. Я прикинул какие детали понадобятся, и приступил к DIY реализации робота-бармена. Кратко расскажу что из этого получилось.

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

Моя цель показать Вам, как с помощью нескольких maven plugin-ов можно сделать вывод в лог Вашей java программы названия ветки и хэш коммита из Git. Это полезно при анализе логов, если у Вас давно не было деплоя и история Вашего инструмента CI затерлась.