Java *

Эта статья про Generics в Kotlin — особенности их использования, сходства и различия с Generics в Java.


Я разделю рассказ про Generics на две части: собственно Generics и использование Wildcards. Пока речь не заходит про Wildcards, использование Generics в Kotlin мало чем отличается от Java.

В четверг, 26 мая, в 20:00 в питерском офисе компании Luxoft состоится встреча JUG.ru с Андреем Паньгиным aka apangin, ведущим разработчиком Одноклассников. Тема встречи — особенности JDK, связанные с обходом Heap-a и стеками потоков.



Stack Trace и Heap Dump — не только инструменты отладки, но ещё и дверцы к самым недрам виртуальной машины Java. Презентация посвящена особенностям JDK, так или иначе связанным с обходом хипа и стеками потоков. В её основе лежат популярные вопросы про JVM со StackOverflow и реальные случаи из практики.

• Влияют ли стек-трейсы на производительность?
• Как снимать дампы в продакшне без побочных эффектов?
• Как устроены утилиты jmap и jstack изнутри?
• Почему все профайлеры врут, и как с этим бороться?
• Как сканировать хип средствами JVMTI и Serviceability Agent?

Участие бесплатное, регистрация — ТУТ.

Повышение производительности системы, улучшение впечатлений пользователей от работы с приложениями: вот направления, в которых развивается Android. В Android Marshmallow можно обнаружить множество новых функций и возможностей. В частности, речь идёт о серьёзных усовершенствованиях Android Runtime (ART). Они направлены на производительность, потребление памяти и многозадачность.

Вышел новый релиз платформы? Изменилась виртуальная машина Android? Любое из этих событий означает, что разработчику нужно срочно понять суть новшеств. А именно, надо разобраться с тем, какие методы, позволявшие достичь высокой производительности решений в прошлом, теперь уже не так эффективны. Нужно найти новые подходы к разработке приложений, способные дать наилучшие результаты. О подобных тонкостях почти не пишут, поэтому разработчикам приходится выяснять всё это методом проб и ошибок.

Перевод статьи опубликованной на Eventsourcing Publications. Статья описывает некоторые из идей примененных в проекте Eventsourcing.

Если вы читали статью Фаулера или подобные источники на тему event sourcing, у вас в мозгу могла остаться вот приблизительно такая картинка:



Общая идея такого подхода заключается в том, что пользователь (или любая другая внешняя система) генерирует команды, мы их обрабатываем, складывая полученные события в event store и обновляя «состояние мира» в базе данных, данные из которой запрашивает пользователь.

Этот подход выглядит просто и красиво. У нас есть достаточно данных чтобы «переигрывать» события, у нас есть откуда запрашивать данные о состоянии мира и мы можем использовать проверенные временем базы данных. С другой стороны, я обратил внимание что я хотел немного другого от концепции event sourcing. Мне хотелось избежать предугадывания будущего и эта модель как-то не очень подходила, потому что мне приходилось записывать обновленное состояние в мою базу данных «для чтения».

Одной из задач компании RTL-Service, которая занимается разработкой систем локального позиционирования с высокой точностью и обеспечением голосовой связи по зашифрованному каналу, является разработка веб-клиента:

Спустя два года присутствия на российском и года на мировом рынках платформа CUBA присоединяется к кругу свободно распространяемого программного обеспечения и переходит на лицензию Apache 2.0. Таким образом, широкий круг разработчиков Java, ориентирующийся на открытые технологии, получит возможность разрабатывать и распространять свои CUBA приложения абсолютно бесплатно, а также изменять и развивать платформу самостоятельно!

Кто не знаком с платформой, приглашаем вас ознакомится на наш сайт или прочитать первую статью о платформе на хабре.

На самом деле, я очень люблю логические игрушки. Не, «три в ряд», «найди похожий» и прочие «покорми собачку» меня мало интересуют. А вот по-настоящему сложная штуковина может спокойно утянуть на пару недель. Примерно так и случилось со мной в 2004-м году, когда ко мне в руки попал новенький мобильник от Sony. Способность этого T68I отлично звонить, показывать цветные картинки и, по слухам, даже отсылать свои контакты по BT прошли мимо меня незамеченными. А вот Q – нет. И сколько часов я просидел за маленьким дисплеем, судорожно гоняя шарики туда-сюда я уже и не помню. Зато, прекрасно помню, что, идея написать порт этой игры для какой-нибудь из современных платформ меня не отпускала со времен своего самого первого Hello World. Правда, все мои попытки склепать хоть какой-то игровой движок в те старые-добрые времена разбивались о… в общем обо что-то они разбивались. Зато теперь я давно и прочно пишу на Java, а с некоторых (совсем недавних) пор еще и для Android, так что идея порта игрушки наконец-то нашла возможность быть реализованной. Хотите посмотреть, что оно есть и как оно получилось? Тогда – под кат.

В прошлом году московская Java-конференция JPoint прошла с таким размахом (тысяча человек, четыре зала, именитые спикеры), что казалось, дальше расти некуда. Но JPoint 2016 показал: есть куда. Конференция оказалась настолько масштабнее, что даже на обработку фотографий с неё ушло много времени (поэтому наш текст запоздал настолько, что на Хабре раньше успел появиться обзор глазами участника от dbelob). Под катом — все подробности о том, как это было.

Автор: Sebastian Daschner
Оригинал: https://blog.sebastian-daschner.com/entries/stop_saying_heavyweight (09 апреля 2016)
Перевод: Семён Солдатенко

При разработке корпоративных Java приложений приходится выбирать – использовать Java EE или какой-нибудь другой «легковесный» фреймворк. Но что делает корпоративный фреймворк легковесным?

Мы как разработчики в основном должны заботиться о процессе разработки. Наше время драгоценно (и дорого) и чем меньше времени мы потратим на накладные расходы, тем лучше.

Пост будет о том, как сделать работу на Хадупе немного комфортнее.



В данной статье я хочу рассмотреть один из компонентов экосистемы Hadoop – HUE. Произносим правильно «Хьюи» или «Эйч Ю И», но не другими, созвучными с широко известным русским словом, вариантами.

На очередной встрече jug.msk.ru, прошедшей 4 мая 2016 года в офисе компании КРОК, Виктор Гамов рассказал об In-Memory Data Grids вообще и о Hazelcast в частности. Подробности и фотографии со встречи далее.

Автор: Константин Марс
Senior Developer @ DataArt,
Co-Organizer @ GDG Dnipro

Dependency Injection

Что, зачем и когда это нужно

Сегодня мы поговорим об инструменте, который помогает улучшить качество разработки для Android. Решить эту задачу можно с помощью Dependency Injection (DI). Обычно этот термин ассоциируется с инъекциями, шприцами и немножко с «зависимостями». На самом деле, Dependency Injection — паттерн проектирования, обеспечивающий реализацию принципа инверсии зависимостей и реализующий правила создания объектов и независимость реализаций.
Итак, у нас есть класс, у класса есть конструктор, и есть несколько членов класса. Когда вы создаете сущность этого класса, вам необходимо обеспечить класс инстансами тех самых типов, которые объявлены для его членов класса. В данном случае, это имя машины и тип двигателя Engine. Вы будете использовать ссылки на объекты, соответственно, ссылки внутри вашего класса не будут пустовать.
Таким образом, вы реализуете ОOП и можете создавать объекты.

Давным-давно, в далекой га…… начиналось всё с одного сервера, написанного на java. Данный сервер реализовывал полный спектр задач:

1. Коммуникация с “железками” — получение замеров, статусной информации, телеметрия, конфигурирование инфраструктуры и т.п.;
2. Realtime обработка поступивших данных;
3. Агрегирование полученных данных;
4. Высокоуровневый интерфейс с клиентским софтом на базу RMI (клиент в те стародавние времена тоже был на java/netbeans rcp).

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

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

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

22-23 апреля 2016 года в четвёртый раз прошла конференция JPoint, в т.ч. уже в третий раз подряд в Москве. В конференции приняли участие более 1000 Java-разработчиков, на 4 параллельных треках было прочитано 48 докладов. Далее приводятся подробности о прошедшей конференции.

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

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

• Галина Галкина — Расчет категории риска – подход к управлению регрессионной ТМ
• Дарья Ефремова — FMEA — подход к тестированию с ретроспективой
• Станислав Сидристый — Грамотное использование Groovy/Geb при автоматизации тестирования Web-приложений на Java
• Константин Нерадовский — Функциональный подход в разработке автотестов на Java
• Роман Иовлев — Jedi Power of Model-based testing
• Роман Иовлев — JDI — Future of UI Automation
• Алексей Белёв и Михаил Мациевский — Автоматизация тестирования или как мы с нуля всё поднимали
• Александр Шиповалов — Чем пахнут ваши авто-тесты
• Александр Шиповалов — BDD — Золотая книжечка, столь же полезная, сколь и забавная..
• Леншмидт Анастасия и Орлов Артур — Автотесты: QA vs Dev

Привет! Меня зовут Данил Перевалов, я работаю Android-разработчиком в компании «Лайв Тайпинг», и сегодня мне выпала честь открыть наш блог на Хабре. Дебютный материал посвящён типу классов Animator. Статья будет полезна и тем, кто только столкнулся с созданием анимаций, и тем, кому недостаточно уже имеющихся знаний по предмету. Тех же, кто давно знаком с темой, мы настойчиво просим делиться опытом в комментариях.

Что такое Animator?

Немного истории. С момента запуска платформы Android существовал фреймворк View Animation. Предназначался он, как следует из названия, для анимаций. Но производительность устройств в конце нулевых была настолько низкой, что о красивых анимациях никто особо не думал, поэтому фреймворк не был удобным и гибким. Он имел только четыре типа анимации (TranslateAnimation, AlphaAnimation, ScaleAnimation, RotateAnimation), класс, позволяющий их комбинировать (AnimationSet), а также способность работать только с классами, унаследованными от View.

В Android 3.0 появился куда более гибкий фреймворк Property Animation. Он умеет изменять любое доступное свойство, а также может работать с любыми классами. Его основным инструментом является Animator.

Animator — это тип классов, предназначенных для изменения значений выбранного объекта относительно времени. Грубо говоря, это инструмент для управления потоком заданной длительности, который изменяет определённое свойство от начального значения к конечному. Таким плавно меняющимся свойством в анимации может быть, например, прозрачность.

Идеологическое отличие классов Animator от View Animation в том, что View Animation изменяет «представление» объекта, не изменяя сам объект (исключением является использование setFillAfter(true), но с этим флагом объект изменяется в конце анимации). Animator же призван изменять свойства самого объекта.

Проблема, друзья. Реактивщина везде, её слишком много и уже никому от неё не спрятаться. Мы с вами все умеем написать ASyncTask, Service или ContentProvider (я в это верю!). Все можем повернуть битмапу или сгонять на сервер за данными. Это все довольно очевидно. Но ещё МЫ ДУМАЕМ, что можем готовить реактивищну правильно. Это далеко не всегда так.

Что такое правильное реактивное программирование на Android?



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

— Привет. Меня зовут Матвей Мальков (на хабре lNevermore ). Я Android-разработчик уже, наверное, лет 5-6. Конкретно сейчас я занимаюсь Scala-разработкой в одном стартапе. Стартап находится в Москве и о нём я говорить особо много не могу. Но суть в том, что это будет такая комьюнити-платформа, наподобие Телеграма. И её я, собственно, пишу под Android на Scala.

Первый проект, который я полностью перевел на RxJava, у меня был в компании 2GIS. Архитектура, база, работа с сетью — всё. После этого начал активно продвигать фреймворк RxJava и реактивный подход в целом на конференциях. Сейчас пишу на Scala, где использую вовсю функциональный подход, а в свободное время интересуюсь новостями реактивного мира.

– Пользователи Хабрахабра наверняка в курсе концепции реактивного программирования. Расскажи про особенности этой парадигмы на Android и про реактивные потоки данных.

– В программировании под Андроид довольно много особенностей, связанных с реактивным программированием. Я как раз хотел бы сказать о том, что не все принципы реактивного программирования, о которых мы попозже подискутируем, хорошо ложатся на Андроид. Чтобы не быть голословным: есть такое понятие как масштабируемость, под которой обычно понимается масштабируемость на большое количество нод, то есть это какая-то серверная масштабируемость. В Андроиде же это всего лишь масштабируемость на треды, что не есть «настоящая маштабируемость». И она не даёт такого большого мощного импакта на систему в целом. Хотя, конечно, всё равно даёт, но по-другому.

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

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

От автора

«Куда только не заведёт любопытство» — именно с этих слов и началась эта история.

Дело обстояло так.

Вернулся я из командировки из США, где провел целый месяц своей жизни. Готовился я Вам скажу я к ней основательно и прилично так налегал на английский, но вот не задача, приехав к заморским друзьям я понял что совершенно их не понимаю. Моему огорчению не было предела. Первым делом по приезду я встретился с другом, который свободно говорит по английски, излил ему душу и услышал в ответ: «… ты просто не те слова учил, нужно учить самые популярные… запас слов, который используется в повседневных разговорах не более 1000 слов...»

Хм, так ли это?, возник вопрос в моей голове… И пришла мне в голову идея проанализировать разговорный текст, так сказать, определить те самые употребляемые слова.

Исходные данные

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

Используемые технологии

• Java SE 8
• Eclipse Mars 2

Ожидаемый результат

Результатом нашего творчества станет jar библиотека, которая будет составлять лексический минимум для текста с заданным процентом понимания. То есть мы например хотим понять 80% всего текста и библиотека, проанализировав текст выдаёт нам набор слов, которые необходимо для этого выучить.