Java *

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

• Работает с бэкапами исключительно в памяти вне зависимости от размера бэкапа
• Не загружает весь бэкап в память
• Операции создания/восстановления бэкапа можно отменять

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

История по оптимизации образов для java приложений началась с выхода статьи в блоге спринга — Spring Boot in a Container. В ней обсуждались различные аспекты по созданию docker образов для spring boot приложений, в том числе и такой интересный вопрос, как уменьшение размеров образов. Для наших команд это было актуально в силу ряда причин, поэтому мы решили применить это решение к нашим приложениям.

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

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

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

Майкл Скотт — уже 34 года как профессор Computer Science в Рочестерском университетe, а в родном универститете Wisconsin–Madison был деканом в течение пяти лет. Он занимается исследованиям в области параллельного и распределённого программирования и дизайна языков и обучает этому студентов.

Мир знает Майкла по учебнику «Programming Language Pragmatics», а работа «Algorithms for scalable synchronization on shared-memory multiprocessors» получила премию Дейкстры как одна из наиболее известных в области распределённых вычислений. Также вы можете знать его как автора того самого алгоритма Майкла-Скотта.

Вместе с Дагом Ли разработал те неблокирующие алгоритмы и синхронные очереди, на которых работают библиотеки Java. Внедрение «dual data structures» в JavaSE 6 позволило в 10 раз улучшить производительность ThreadPoolExecutor.

Содержание:

• Начало карьеры, Рочестерский университет. Проект Charlotte, язык Lynx;
• IEEE Scalable Coherent Interface, блокировка MCS;
• Выживание в постоянно меняющемся мире;
• Становятся ли студенты глупее? Глобальные тренды, интернационализация;
• Эффективная работа со студентами;
• Как не отстать при подготовке новых курсов и книг;
• Связь между бизнесом и академией;
• Практическая реализация идей. MCS, MS, CLH, JSR 166, работа с Дагом Ли и многое другое;
• Транзакционная память;
• Новые архитектуры. Близкая победа транзакционной памяти;
• Энергонезависимая память, Optane DIMM, сверхбыстрые устройства;
• Следующий большой тренд. Dual data structures. Hydra.

• users.list
• chat.postMessage
• conversations.create
• files.upload
• im.open

GET /users.list HTTP/1.1
Content-Type: application/x-www-form-urlencoded

token=xoxp-1234567890-098765-4321-a1b2c3d4e5

Морис Херлихи — обладатель целых двух премий Дейкстры. Первая — за работу по «Wait-Free Synchronization» (Brown University) и вторая, более свежая, — «Transactional Memory: Architectural Support for Lock-Free Data Structures» (Virginia Tech University). Премию Дейкстры дают за работы, значимость и влияние которых были заметны на протяжении не менее десяти лет и, очевидно, Морис — один из самых известных специалистов в области. На данный момент он работает профессором в Брауновском университете и имеет множество достижений на целый абзац длиной. Сейчас он занимается исследованиями блокчейна в контексте классических распределенных вычислений.

Ранее Морис уже приезжал в Россию на SPTCC (видеозапись) и cделал отличную встречу сообщества Java-разработчиков JUG.ru в Питере (видеозапись).

Этот хабрапост  — большое интервью с Морисом Херлихи. В нем обсуждаются следующие темы:

• Взаимодействие академической сферы и индустрии;
• Фундамент для исследований блокчейна;
• Откуда берутся прорывные идеи. Влияние популярности;
• PhD под руководством Барбары Лисков;
• Мир в ожидании многоядерности;
• Новому миру – новые проблемы. NVM, NUMA и взлом архитектуры;
• Компиляторы против процессоров, RISC vs CISC, shared memory vs message passing;
• Искусство написания хрупкого многопоточного кода;
• Как обучить студентов написанию сложного многопоточного кода;
• Новое издание книги «The Art of Multiprocessor Programming»;
• Как изобреталась транзакционная память;   
• Почему стоит проводить исследования в области распределенных вычислений;
• Остановилось ли развитие алгоритмов, и как жить дальше;
• Работа в Брауновском Университете;
• Разница между исследованиями в университете и внутри корпорации;
• Hydra и SPTDC.

Клифф Клик — CTO компании Cratus (IoT сенсоры для улучшения процессов), основатель и сооснователь нескольких стартапов (включая Rocket Realtime School, Neurensic и H2O.ai) с несколькими успешными экзитами. Клифф написал свой первый компилятор в 15 лет (Pascal для TRS Z-80)! Наиболее известен за работу над С2 в Java (the Sea of Nodes IR). Этот компилятор показал миру, что JIT может производить качественный код, что стало одним из факторов становления Java как одной из основных современных программных платформ. Потом Клифф помог компании Azul Systems построить 864-ядерный мейнфрейм с софтом на чистой Java, который поддерживал паузы GC на 500-гигабайтной куче в пределах 10 миллисекунд. Вообще, Клифф успел поработать над всеми аспектами JVM.
 
Этот хабрапост — большое интервью с Клиффом. Мы поговорим на следующие темы:

• Переход к низкоуровневым оптимизациям
• Как делать большой рефакторинг
• Модель стоимости
• Обучение низкоуровневым оптимизациям
• Практические примеры улучшения производительности
• Зачем создавать свой язык программирования
• Карьера перформанс-инженера
• Технические челленжи
• Немного про аллокацию регистров и многоядерность
• Самый большой челленж в жизни

Интервью ведут:

• Андрей Сатарин из Amazon Web Services. В своей карьере успел поработать в совершенно разных проектах: тестировал распределенную базу данных NewSQL в Яндексе, систему облачного детектирования в Лаборатории Касперского, многопользовательскую игру в Mail.ru и сервис расчёта валютных цен в Deutsche Bank. Интересуется тестированием крупномасштабных backend- и распределённых систем.
• Владимир Ситников из Netcracker. Десять лет работает над производительностью и масштабируемостью NetCracker OS — ПО, используемого операторами связи для автоматизации процессов управления сетью и сетевым оборудованием. Увлекается вопросами производительности Java и Oracle Database. Автор более десятка улучшений производительности в официальном PostgreSQL JDBC-драйвере.

Всем привет! Лето — не только пора каникул, отпусков и прочих ништяков, но и самое время задуматься об обучении. О том самом обучении, которое научит самым востребованным языкам программирования, “прокачает” навыки, погрузит в решение реальных бизнес-проектов, ну и, само собой, даст старт успешной карьере. Да, вы все верно поняли — речь пойдет о нашей Школе программистов. Под катом расскажу об итогах 9-го выпуска и начале набора в 10-ый.

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

А что если бы можно было создать интерфейс, например, такой:

@Service
public interface GoogleSearchApi {
    /**
     * @return http status code for Google main page
     */
    @Uri("https://www.google.com")
    int mainPageStatus();
}

А затем просто внедрять его и вызывать его методы:

@SpringBootApplication
public class App implements CommandLineRunner {
    private static final Logger LOG = LoggerFactory.getLogger(App.class);

    private final GoogleSearchApi api;

    public App(GoogleSearchApi api) {
        this.api = api;
    }

    @Override
    public void run(String... args) {
        LOG.info("Main page status: " + api.mainPageStatus());
    }

    public static void main(String[] args) {
        SpringApplication.run(App.class, args);
    }
}

Такое вполне возможно реализовать (и не очень то и сложно). Дальше я покажу, как и зачем это делать.

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

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

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

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

android {
    compileSdkVersion 28
    defaultConfig {
        applicationId "com.habr.hello"
        minSdkVersion 20
        targetSdkVersion 28
    }
    buildTypes {
        release {
            minifyEnabled false
        }
    }
}

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

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