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

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



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

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

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

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

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

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

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

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

Отсутствуют материализованные дженерики (reified generics). Об этом не писал только ленивый, причём большинство комментариев свидетельствуют о непонимании сути затирания типов. Если Java-разработчик говорит: «Я не люблю затирание типов», то в большинстве случаев это означает «Мне нужен List int». Вопрос примитивной специализации дженериков лишь косвенно связан с затиранием, а польза от дженериков, видимых в ходе исполнения, сильно преувеличена молвой.

Беззнаковые вычисления (unsigned arithmetic) на уровне виртуальной машины. Отсутствие в Java поддержки беззнаковых арифметических типов вызывает недовольство разработчиков уже многие годы. Но это является обдуманным решением создателей языка. Наличие лишь знаковых вычислений существенно упрощает язык. Если сегодня начать внедрять беззнаковые типы, то это повлечёт за собой очень серьёзную переработку Java, что чревато массой больших и маленьких багов, которые будет трудно вылавливать. Заодно сильно возрастает риск дестабилизации всей платформы.

Длинные указатели для массивов. Опять же, внедрение этой функциональности потребует слишком глубокой переработки JVM с возможными неприятными последствиями, причём далеко не только с точки зрения поведения и семантики сборщиков мусора. Хотя нужно отметить, что Oracle ищет пути внедрения подобной функциональности с помощью проекта VarHandles.

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

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Привет всем. Продолжу о Фантоме. Для понимания полезно прочесть статью про персистентную оперативку, а так же общую статью про Фантом на Открытых Системах. Но можно и так.

Итак, мы имеем ОС (или просто среду, не важно), которая обеспечивает прикладным программам персистентную оперативную память, и вообще персистентную «жизнь». Программы живут в общем адресном пространстве с управляемыми (managed) пойнтерами, объектной байткод-машиной, не замечают рестарта ОС и, в целом, счастливы.

Очевидно, что такой среде нужна сборка мусора. Но — какая?

Есть несколько проблем, навязанных спецификой.

Во-первых, теоретически, объём виртуальной памяти в такой среде огромен — терабайты, всё содержимое диска. Ведь мы отображаем в память всё и всегда.

Во-вторых, нас категорически не устраивают stop the world алгоритмы. Если для обычного процесса остановка в полсекундны может быть приемлема, то для виртуальной памяти, которая, большей частью, на диске, это будут уже полчаса, а то как бы не полсуток!

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

Тут нужна оговорка. Вообще говоря, в системе, которая располагает парой терабайт виртуальной памяти, это не так уж критично — даже если не делать освобождение памяти полсуток, возможно, не так много и набежит — ну, например, истратится 2-3, ну 5 гигабайт, ну даже и 50 гигабайт — не жалко, диск большой.

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

Ок, итого у нас две задачи.

Меня зовут Дима и я разработчик. Живу в Минске, люблю посещать зарубежные конференции. Ну вот устал однажды ездить и решил сходить локально. Но выбора было мало. Поэтому вдвоём со своим верным товарищем решили сделать конференцию самостоятельно. Назвали JET. Потому что начинается с J, как и Java, а ещё можно сделать слоган "Let's fly to Java world". Ну что же, как это было?

Открытие

Началось все с выступления организаторов, где мы поделились тем, как зарождалась идея конференции. Рассказали о том, как мы прошли путь в 4 месяца подготовки, и что по итогу получилось. А получилось — 3 потока концентрированных знаний, 300 участников и первый кирпичик в фундаменте дома конференции JET.

Всего 8 недель осталось до крупнейшей в России Java-конференции JPoint 2016. Я уже рассказывал на хабре, что нас с вами ожидает:

• два дня под одной крышей в центре Москвы
• около 40 докладов в четырёх параллельных залах. Мы хотели сделать 36 докладов, как на Joker, но видимо всё же, уплотним сетку и сделаем 44 доклада
• море общения с коллегами — около 1000 Java-программистов приедут к нам отовсюду

Я попробую потихоньку рассказать про основные темы JPoint и начну с нашей любимой — производительность и многопоточность.

На эту тему уже анонсированы следующие доклады:

• Алексей Шипилёв, Oracle — Если не Unsafe, то кто: восход VarHandles
• Сергей Куксенко, Oracle — Quantum Performance Effects, level up. За пределами ядра
• Руслан Черёмин, Deutsche Bank — Escape Analysis и скаляризация
• Владимир Ситников, NetCracker — Ну и производительность у вашего OpenSource!
• Volker Simonis, SAP — HotSpot Intrinsics
• Алексей Шипилёв, Oracle — The Lord of the Strings: Two Scours
• Тагир Валеев — Stream API puzzlers
• Владимир Иванов, Oracle — Native код, Off-heap данные и Java
• Владимир Озеров, GridGain — (Почти) неблокирующая синхронизация

В Москве и Петербурге большой Java-конференцией никого не удивить: JPoint и Joker регулярно собирают множество зрителей и зазывают известных спикеров. Но теперь JUG.ru замахнулся ещё и на Новосибирск, проведя там JBreak (или, стилизованно, jbreak;).

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

Все ответы — в подробном тексте под катом.

Я люблю desktop-приложения. Признаваться в этом нынче, похоже, стыднее, чем в связях с иностранной разведкой, но это так. Нет, это не значит, что я не люблю интернет-технологии. Более того, некоторые я не только уважаю, а даже более-менее знаю. Но, тем не менее, я скучаю по тем временам, когда программа писалась на одном компьютере, потом компилировалась и запускалась на других, разных компьютерах. Тогда везде (почти) была одна система — Windows с одной и той же API, почти не было проблем совместимости на уровне приложений, никто не материл разработчиков браузеров — все берегли нервы на разработчиков WinAPI, которые умудрялись создавать конфликты даже внутри нее одной. Но это я, конечно, иронизирую, а если серьезно — иногда и сейчас хочется написать просто desktop-приложение, да так, чтобы работало оно на всех популярных системах. Трудно? Если подумать и покопать, то не очень.

Еще я люблю языки высокого уровня с аккуратной архитектурой и строгой типизацией. Мои фавориты — Java и C#. Оба они предоставляют разработчику множество преимуществ по сравнению с C++, оба избавляют от ряда забот. Чем приходится платить? Тем, что таскаешь за собой тяжелую колоду, которая называется Oracle JVM, .NET или mono. Все три колоды весят сотни мегабайт и лицензию имеют такую, что каждый пользователь вынужден качать эту штуку сам, не путая при этом разрядность своего компьютера, а главное — программа на Java не может быть совместима со всеми версиями JVM разом, не так ли? И вот — мы приходим к тому, что просто скинуть программку другу (или миллиону друзей) и не заботиться о том, что она у него не запустится, не выходит. Приходится делать хитрые сетапы, вбивать костыли, и это я еще не упомянул .NET — однажды я видел у друга сразу 3 установленных версии, причем все три были нужны разным приложениям…

Стоп! А давайте напишем программу на Java, но так, чтобы она не требовала установки на машину какой-либо JVM, чтобы одним касанием собиралась под Windows, Linux и OS X и чтобы при этом занимала совсем чуть-чуть; так, чтобы никто даже не понял, что она написана, скажем, не на C. Невозможно? Совсем наоборот! (И нет, я имею в виду не gcj, который лишает Java всех ее прелестей. Рефлексия будет работать и даже сторонние jar вы сможете запускать).

Как известно, в Java нет беззнаковых типов. Если в Си вы могли написать unsigned int (char, long), то в Java так не получится. Однако нередко возникает необходимость в выполнении арифметических операций именно с числами без знака. На первый взгляд кажется, что беззнаковые типы в принципе-то и не особо нужны (подумаешь, MaxInt для чисел со знаком меньше в два раза, если нужны числа больше, я просто возьму long и далее BigInteger). Но основное различие на самом деле не в том, сколько различных неотрицательных чисел можно положить в signed или unsigned int, а в том, как над ними производятся арифметические операции и сравнения. Если вы работаете с бинарными протоколами или с двоичной арифметикой, где важен каждый используемый бит, нужно уметь выполнять все основные операции в беззнаковом режиме. Рассмотрим эти операции по порядку:

Преобразование byte в short (int, long)

Обычный каст (int) myByte выполнит расширение до 32 бит со знаком — это означает, что если старший бит байта был установлен в 1, то результатом будет то же самое отрицательное число, но записанное в 32-битном формате:

0xff -> 0xffffffff (-1)

Часто это не то, чего бы мы хотели. Для того, чтобы выполнить расширение до 32 бит без знака и получить 0x000000ff, в Java можно записать:

int myInt = myByte & 0xff;
short myShort = myByte & 0xff;

Сравнение без учёта знака

Для беззнакового сравнения есть лаконичная формула:

int compareUnsigned(int a, int b) {
    return Integer.compare( a ^ 0x80000000, b ^ 0x80000000 );
}

Для byte, short и long, соответственно, константы будут 0x80, 0x8000 и 0x8000000000000000L.

От переводчика: автор этой заметки — Stephen Colebourne, автор библиотеки Joda Time и Java Time API.

---

Следует ли добавить вывод типов локальных переменных в Java? Как раз сейчас команда разработчиков языка Java задалась этим вопросом.

Вывод типов локальных переменных

JEP-286 предлагает добавить вывод типов локальных переменных, используя новое псевдоключевое слово (интерпретируемое как «зарезервированное наименование типа»):

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

^{Кадр из к/ф «Операция Ы и другие приключения Шурика»}

Как говорят, «кризис — пора возможностей». И поэтому сейчас самое время начать вкладывать в саморазвитие, осваивать новую профессию или повышать свою квалификацию. Займитесь изучением языков программирования, обретением навыков разработки, тестирования и вообще всячески прокачивайте свой IT-скилл. Ведь чем больше вы знаете, тем прочнее будете стоять на ногах. А чтобы вам было легче сориентироваться и выбрать направление, мы сделали подборку наших бесплатных образовательных материалов, курсов и инициатив за 2015–2016 годы.

Всем привет!

Бесплатные инструменты разработки от Microsoft, вопреки распространненому мнению, включают в себя не только многофункциональную и мощную IDE Visual Studio 2015 Community, но и ряд других полезных компонентов и продуктов. Например, Visual Studio Team Services имеет свое бесплатное предложение для команд не более 5 человек. Эти и многие другие предложения теперь доступны каждому разработчику по программе Visual Studio Dev Essentials.

Новая программа Visual Studio Dev Essentials, анонсированная в ноябре 2015 года, предоставляет централизованный доступ к основным бесплатным компонентам для разработчика на Visual Studio, а так же предлагает различные инструменты для обеспечения полного цикла создания ПО, включая инструменты и продукты сторонних компаний, например Parallels, Xamarin и т.д.

Так же по программе Dev Essentials в течение нескольких месяцев предоставляется доступ к обучающим материалам, таким, как Pluralsight, Xamarin University и т.д. А также возможность получения приоритетной поддержки на форумах.

Добрый день, это «Без слайдов». В гостях у меня побывал Роман Елизаров aka elizarov, Java Champion, эксперт по Java и многопоточности (а с недавнего времени — еще и по финансовой математике), спикер многочисленных конференций, председатель жюри Северо-Восточного Европейского региона ACM-ICPC, престижнейшей в мире олимпиады по программированию, лектор в ИТМО и, наконец, VP по технологиям в компании Devexperts. В общем, «человек и пароход».

В разговоре мы затронули следующие темы:

• что такое финансовая математика и как ее учить;
• как устроен софт для финансовой индустрии;
• как в компании Devexperts появилась исследовательская лаборатория по многопоточности;
• куда развивается Concurrency, и что будет в моде в ближайшее время;
• как всемирная олимпиада по программированию пришла в Россию.

Текстовая версия — под катом.

Рано или поздно IT-проекты сталкиваются со сложностями поддержания высокого качества кода и/или увеличивающимся временем доставки изменений в production. Lingualeo испытала на себе все проблемы роста и готова поделиться своей историей повышения эффективности разработки. О том, как это происходило, рассказал teamlead инфраструктурой команды Lingualeo Михаил Кабищев.


Как и любая другая технологическая компания, Lingualeo проходила через несколько этапов:

• Начало разработки продукта. Разработка и отладка происходит на одном-единственном сервере, где запущено все, что нужно проекту. Ошибки бывают часто, но это не страшно, т.к. это все лишь прототип, и живых пользователей там еще нет.
• Появление первых пользователей. Компания начинает ощущать цену ошибок и проблем на продакшене. Уже нельзя править все на продакшене, приходит понимание того, что нужно мыслить релизами. Разработчики внедряют workflow для работы с кодовой базой, появляется что-то вроде stage-сервера, на котором тестируются релизы.
• Рост проекта и команды. В разработке одновременно находится большое количество задач. Требования к процессу и качеству кода сильно возрастают. За всем очень тяжело следить: кто-то забывает запустить юнит-тесты, кто-то не знает, куда и как нужно задеплоить очередную задачу для тестирования.

В итоге рутинные операции начинают отнимать очень много времени, и компания думает, как автоматизировать эти процессы.

Неделю назад в Питере прошла встреча JUG.ru с разработчиками языка Kotlin Андреем Бреславом и Дмитрием Жемеровым. Как вы все наверняка знаете, Kotlin зарелизился пару недель назад, и теперь, спустя почти шесть лет разработки, пришла пора поговорить о том, что в итоге получилось.

В пятничный вечер 26 февраля народу в питерский офис Oracle набилось дофига, что очень обрадовало и нас и спикеров.



Встреча состояла из четырех частей:

• Введение. Что такое Kotlin?
• Kotlin: к релизу и далее
• Kotlin: самое сложное — совместимость
• Сессия вопросов и ответов про Kotlin

На Хабре, по меркам старожилов, я совсем недавно, всего два года, но пишу активно, по возможности каждый день. Так вот, читая статьи, да и просто прокручивая ленту свежих публикаций как на Хабре, так и на GT, я понял, что многие просто не могут совладать с версткой текста и, как следствие, достаточно часто годные публикации хоронятся их же авторами из-за нечитабельности текста. Или отпугивает кривая КДПВ, или еще что произойдет.

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

Картинка Для Привлечения Внимания и выравнивание по левому краю

Так уж сложилось, что вся лента Хабрахабра выровнена по левому краю. По этой причине опытные авторы небольшие изображения оставляют слева или используют картинки шириной в 800-1000 px. Отдельно хочется заметить, что чуть ли не лучшим является соотношение КДПВ 2 к 1, т.е. изображения 800х400 px. Подобная пропорция позволяет SMM-щику соц. сетей не изгаляться с вашей картинкой (а то и вовсе искать что-то другое, более подходящее по размерам), а использовать оригинал, не нарушая задумки автора.

Из опыта 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

Год подходит к концу, впереди длинные каникулы. Для многих каникулы — это отличная возможность посидеть и посмотреть вокруг, что же у нас нового и интересного происходит нынче в профессиональном джавовском мире.

В апреле в Москве мы провели в Москве большую Java-конференцию — JPoint 2015. Конференция собрала более тысячи разработчиков на площадке, еще несколько сотен — смотрели конференцию онлайн. Мы экспериментировали и с открытием (лекция Дмитрия Галкина о современном искусстве и программировании действительно шокировала многих) и с новыми форматами (круглые столы и экспертные дискуссии). Но ключевой темой конференции были и остаются доклады.

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

---

10 место

Сергей Walrus Куксенко, Oracle — Железные счётчики на страже производительности
Средняя оценка: 4.28



Этот доклад получил специальный приз жюри в номинации «аццкий хардкор». Общая идея доклада сводится к следующему: представьте, что вы уже наоптимизировали в своем приложении все, что можно — посмотрели на сеть, ОС, JVM и т.д. и поняли, что все уперлось в процессор. После этого мы попрофилировали, работать стало быстрее, но все равно процессор загружен на 100%. Что делать?

Оказывается, внутри процессора есть разные счетчики событий. Называется этот механизм Hardware Performance Counters. Архитектура современных процессоров очень сложна, в них может происходить очень много разного. Фокус в том, что мы можем включить некоторые счетчики внутри процессора, которые будут считать количество произошедших событий. То есть, некоторый железный профилировщик внутри процессора.

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



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