Java *

Быстрое развитие технологий и инструментов разработки ПО приводит к тому, что технологии, лежащие в основе информационной системы, теряют свою актуальность и становятся тяжелой ношей. Взять, к примеру, какую-нибудь разработку компании для автоматизации процессов, написанную на Visual Basic 6.0 или Delphi 7, которая, мягко говоря, не сочетается с новыми трендами “все в web, все в облака”, да и не соответствует амбициям разработчиков.

Проблема перевода старой ИС на новые технологии, доходя до руководства, традиционно упирается в деньги: “поживем и так...”. Для разработчиков, в свою очередь, уже перенос модели данных и шаблонное программирование стандартных экранов вызывает негатив. При этом зачастую все усложняется требованием сохранения работоспособности старой ИС на этапе разработки и внедрения новой. Так или иначе, по моему опыту, продукт либо умирает совсем, вызывая мучения как программистов, так и пользователей, либо все же приходит понимание, что обновление ИС — неотложная необходимость.

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

Под катом пошаговая инструкция, как модернизировать устаревшую систему с минимальными усилиями на перенос модели данных и стандартных CRUD экранов.

В данной заметке я хочу показать каким образом можно определять и устранять утечки памяти в Java на примере из моей повседневной работы. Мы не будем здесь рассматривать возможные причины появления утечек, об этом будет отдельная статья, так как тема достаточно обширная. Стоит заметить, что речь пойдет о диагностике именно Heap Memory, об утечках в других областях памяти будет отдельная статья.

Предлагаю вашему вниманию перевод оригинальной статьи Роберта С. Мартина.

За последние несколько месяцев я попробовал два новых языка. Swift и Kotlin. У этих двух языков есть ряд общих особенностей. Действительно, сходство настолько сильное, что мне стало интересно, не является ли это новой тенденцией в нашей языкомешалке. Если это действительно так, то это тёмный путь.

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

Проблема в том, что оба языка сделали ставку на сильную статическую типизацию. Кажется, оба намерены заткнуть каждую дыру в своём родном языке. В случае со Swift – это странный гибрид C и Smalltalk, который называется Objective-C; поэтому, возможно, упор на типизацию понятен. Что касается Kotlin – его предком является уже довольно строго типизированная Java.

Я не хочу, чтобы вы думали, что я против статически типизированных языков. Я не против. Есть определенные преимущества как для динамических, так и для статических языков; и я с удовольствием пользуюсь обоими видами. Я предпочитаю динамическую типизацию, и поэтому я иногда использую Clojure. С другой стороны, я, вероятно, пишу больше Java, чем Clojure. Поэтому вы можете считать меня би-типичным. Я иду по обеим сторонам улицы — если так можно выразиться.

Дело не в том, что меня беспокоит статическая типизация Swift и Kotlin. Скорее меня беспокоит глубина статической типизации.

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

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

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

---

Сага о том, как Java-разработчики должны тестировать свои приложения. Часть 1

---

Перед вами вторая часть Саги от Николая xpinjection Алименкова о том, как Java-разработчики должны тестировать свои приложения, речь в которой пойдет о TDD, BDD, тестировании FTP, UI, web-UI, JMS и баз данных.

Итак, шёл второй час…

Если вы все еще считаете, что пользы от докладов на конференциях нет, предлагаем вам почитать статью, подготовленную по мотивам доклада Николая xpinjection Алименкова (EPAM) на JPoint 2016. В почти двухчасовом докладе Николай подробно рассказывает о различных аспектах тестирования (а заодно и разработки) приложений под Java – от подходов к тестированию бизнес-логики до TDD, BDD и UI-тестирования, демонстрируемых на практических примерах из реального проекта.

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

Видеозапись доклада:

Good news everyone!
Futurama

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

Эволюция работает не только в животном мире, но и в любой подходящей среде. Впервые эта идея получила широкое распространение с выходом книги Ричарда Докинза «Эгоистичный ген» в 1976 году. В ней был введен знакомый каждому термин «мем», как пример эволюции в социальной и культурной среде. Языки программирования тоже эволюционируют. А значит их развитие подчиняется принципам эволюции, на основании которых можно сделать предположение о будущем их развитии.

С моей прошлой публикации о распределенной базе данных CrateDB прошло около года. Проект на основе Elasticsearch и PrestoDB написан на Java. Он за это время активно развивался и обрастал новым функционалом в github репозитарии:

• поддержка outer join;
• case when… then… end в запросах;
• функции для работы с пространственными(Geospatial) данными;
• возможно отображение данных временных рядов (Time Series) в Grafana;
• ограниченная поддержка подзапросов;
• узлы кластера работающие в режиме только чтения;
• эмуляцией подмножества протокола PostgreSQL 9.5;

Приятной неожиданностью было обнаружить в github проекта, что в команде CrateDB есть русскоговорящий разработчик Руслан. Достаточно быстро получил от него ответ на вопросы про внутреннее устройство и зависимости проекта.

Уже давно определённые вещи из мира функционального программирования всё сильнее проникают в нефункциональные языки. Может показаться странным, что в Java смогли интегрировать лямбда-выражения, а вот оптимизацию хвостовой рекурсии (преобразование рекурсии в эквивалентный цикл) до сих пор не сделали, хотя она гораздо проще. Почему её нет?

Попробуем разобраться с причинами и посмотрим, что можно сделать своими руками.

За год, прошедший с релиза Kotlin 1.0, у языка произошли прорывы по многим фронтам: от поддержки в Gradle и Spring до выхода книги «Kotlin in Action». Число Kotlin-строк на GitHub возросло более чем вчетверо, превысив 10 миллионов. А теперь вышла версия 1.1, добавляющая компиляцию в JavaScript, и это выглядит громкой заявкой на новую долю рынка. Означает ли это всё, что вот теперь время Kotlin по-настоящему пришло, и нам всем пора активно использовать язык в продакшене?

Андрей Бреслав (JetBrains) и Антон Кекс (Codeborne) многое знают о Kotlin (и оба скоро выступят на JPoint с докладами о нём), но при этом смотрят на него с разных сторон: пока Антон разрабатывает на этом языке, Андрей работает над самим языком. Мы решили, что о настоящем и будущем Kotlin интересно поговорить с ними обоими сразу, получив полную картину. Начав с вопросов о бурном росте, затем успели обсудить ещё многое:

• Взаимодействие с разработчиками и процесс эволюции языка
• Компиляцию в JS, проект Kotlin Native и мультиплатформенность в общем
• Несовершенства
• Kotlin-паззлеры
• Ожидания и амбиции

Наверное, Eclipse давно уже не нуждается в особом представлении. Многие знакомы с Eclipse благодаря Eclipse Java development tools (JDT). Именно эта популярная open-source Java IDE ассоциируется у большинства разработчиков со словом “Eclipse”. Однако Eclipse – это и расширяемая платформа для интеграции средств разработки (Eclipse Platform), и целый ряд IDE, построенных на ее основе, в том числе JDT. Eclipse – это и Eclipse Project, проект верхнего уровня, координирующий разработку Eclipse Platform и JDT, и Eclipse SDK – поставляемый результат этой разработки. Наконец, Eclipse – это open-source Foundation с огромным сообществом проектов, далеко не все из которых написаны на Java или имеют отношение к средствам разработки (например, проекты Eclipse IoT и Eclipse Science). Мир Eclipse очень многообразен.

В данной статье, обзорной по своему характеру, мы попробуем рассмотреть некоторые основы архитектуры Eclipse как платформы для построения интегрированных средств разработки и дать начальное представление о компонентах Eclipse, образующих фундамент технологической платформы для «нового Конфигуратора» 1C: Предприятие, 1C:Enterprise Development Tools. Разумеется, такое рассмотрение неизбежно будет во многом поверхностным и довольно ограниченным, в том числе и потому, что мы ориентируемся не только на Eclipse-разработчиков в качестве целевой аудитории. Впрочем, надеемся, что даже опытные разработчики Eclipse смогут найти в статье интересную для себя информацию. Например, мы расскажем об одном из «секретов Eclipse», относительно новом и малоизвестном пока проекте Eclipse Handly, который был основан и поддерживается фирмой 1C.

Что такое HTML, CSS, JavaScript и Bootstrap фреймворк сложно объяснять человеку который далек от IT. А что если нужен сайт на бесплатном хостинге, без привязки к онлайн конструкту именно этого хостинга?!



Как думаете, реально научить девушку обновлять свой сайт на GitHub Pages к Международному женскому дню?! Расскажу как мне это удалось с помощью генератора сайта, который доступен на Github и написан на Java + FreeMarker, к тому же старался автоматизировать публикацию контента в git репозитарий.

Работая в многомодульном maven проекте, зачастую приходится вносить изменения в несколько связанных модулей одновременно. И если хочется собрать только задетые модули, то к сожалению maven не предоставляет ничего автоматического. Если чуть погуглить, то на stackoverflow можно найти простое однострочное решение:

mvn install -amd -pl $(svn st | colrm 1 8 | sed 's /.*  ' | xargs echo | sed 's- -,:-g' | sed 's ^ : ')

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

Статья о реализации паттерна Builder с проверкой на уровне компиляции, реализованного с помощью параметрического полиморфизма. В ней мы поговорим о том, что такое полиморфизм, каким он бывает. Как устроена магия «оператора» =:= в scala, можно ли повторить ее в java и как используя эти знания реализовать Builder, не допускающий неполной инициализации создаваемого объекта.

Apache Ant должен быть знаком каждому Java-программисту: это популярный инструмент сборки ПО (build tool), полностью написанный на Java. Ant использует сценарий, который является обычным XML-файлом. Несмотря на его Java-направленность, веб-разработчики тоже используют этот инструмент.

Мы пройдём пять простых шагов, чтобы начать использовать Ant:

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

Также я опишу, как сделать maven проект, который генерирует артефакт, по совместительству являющийся библиотекой, и как подключить эту библиотеку к другому своему же maven проекту.

Эта статья для тех, кто только начинает осваивать java.

В моей предыдущей статье было сказано, что maven сам скачает все указанные в pom.xml зависимости. А вот что будет, если он какую-нибудь зависимость не найдёт? В таком случае maven скажет, что зависимость не обнаружена и прервёт процесс сборки с ошибкой. Что делать в этом случае?


Недавно я опубликовал свою первую статью на Хабре. И первый блин прилетел мне прямо в голову. 12к просмотров и плюс 4 звезды на гитхабе… Ладно, сам виноват, не надо было заниматься ерундой на уроках русского языка и литературы. Если я правильно понял, то проблема заключалась в том, что я сразу перешел к сути. Вывалил все в лоб. Не познакомился с родителями, так сказать. А что за Jeta такая, как она работает, что происходит за сценой? Магия какая я то… Никому ведь не нужна магия в проектах, так?

"От куда у тебя уверенность, что твоя библиотека вообще кому-то нужна?" спросит среднестатистический хаброчанин. Оттуда, что каждый день, вешая очередную аннотацию или просто смотря на код, я думаю "Боже, это прекрасно!". Кто от такого откажется?

Ладно, давайте сначала и по порядку.

До Java-конференции JPoint 2017 осталось пять недель, 75% докладов уже утверждены, оставшиеся 25% будут выбраны из имеющихся заявок к середине марта. В этом посте я расскажу вам о том, что у нас получилось.



Если темы всех докладов разделить по тематикам, то получится следующее:

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

Плюсом к основным блокам будут доклады на более специфические темы: Kotlin, trueOOP на Java от Егора, паттерны и, конечно, немного паззлеров!

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

Мы рады представить вам Kotlin 1.1, новую версию языка программирования Kotlin.

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

Привет, Хабр!

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

Посмотрите краткий обзор новой версии на английском языке: