Jokerconf день первый

16 - 17 октября в Санкт-Петербурге прошло одно из самых ярких java мероприятий года - конференция Joker 2015. Я принял в нем участие в качестве удаленного слушателя и решил здесь оставить то, что осталось в голове после докладов.

В режиме онлайн в первый день я побывал на следующих докладах:

• Евгений Борисов - Spring Puzzlers: тонкости и нюансы работы Spring 
• Алексей Зиновьев - Как укротить буйного в отделении: смирительные Java-рубашки для MongoDB
• Алексей Рагозин - Что должен знать о сетях каждый Java-разработчик?
• Виктор Полищук - Legacy: как победить в гонке

Евгений Борисов - Spring Puzzlers: тонкости и нюансы работы Spring 

На мой взгляд это был самый интересный доклад. Свою роль сыграли как и способ изложения, так и, конечно, популярность темы доклада. Первая часть доклада была посвящена тонкостям использования BeanPostProcessor и аспектов, затем поговорили об особенностях использования проксированных объектов. В конце доклада было рассказано о том, почему нужно "любить" интерфейсы и об особенностях различных способах задания spring конфигурации. Мне очень понравился стиль изложения, этот доклад смотивировал меня поискать и посмотреть другие видеоролики с участием Евгения Борисова и самому открыть Idea, чтобы своими руками пощупать некоторые нюансы. 

Алексей Зиновьев - Как укротить буйного в отделении: смирительные Java-рубашки для MongoDB

Этот доклад был довольно далек для меня, т.к. я пока использовал только классические sql СУБД. Как видно из названия, доклад был посвящен различным инструментам для работы с MongoDB, а также что делать, если в проекте используется несколько СУБД, с которыми хочется работать как с одной. Алексей рассказал подробно о различных вариантах, об их особенностях. Забавно, что в конце он дал совет не использовать MongoDB, ну а уж если вляпались.... то доклад будет полезен:). 

Алексей Рагозин - Что должен знать о сетях каждый Java-разработчик?

В этом докладе было рассказано об особенностях работы с TCP в java. Основная мысль, что если мы что-то делаем в коде, связанное с TCP, то это не обязательно происходит мгновенно. Например, если закрыть сокет, то реально он закроется только тогда, когда отправит все данные, а пока соединение будет оставаться в буфере. Если существует лимит соединений, то можно попасть в плохую ситуацию, когда сокет старый вроде бы закрыт, а новый открыть невозможно.  То же самое с write, ОС не будут тут же отправлять тот байт, который записали в outputstream. К счастью, существуют настройки, которые могут установить желаемое поведение во всех вышеописанных случаях.

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

Затем Алексей привел интересную ситуацию, когда первый утренний запрос может проходить несколько минут, а второй уже обычное время. Дело в том, что TCP соединение бесконечно, причем для этого не обязательно даже обмениваться пакетами. Соответственно, если один конец падает, то второй об этом узнает только когда попытается отправить пакет, а точнее, когда после ожидания таймаута не получит ответ. Бывает так, что целый день работали, заполнили пул TCP соединений, а за ночь firewall их разорвал, поскольку никакие пакеты через них не передаются. Утром же мы по очереди берем соединения из пула, ждем таймаута, и только когда все соединения из пула закончатся, будет создано новое работающее соединение. Т.е. в итоге время ожидания будет таймаут*размер пула. Разумеется, зная причину, это проблему тоже можно решить.

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

Виктор Полищук - Legacy: как победить в гонке

Виктор заметил, что любой проект рано или поздно становиться legacy, но legacy бывает разным. Можно с нуля написать проект на известных старых технологиях, и он сразу же станет legacy, причем аккуратным, все понятным, работающим legacy. Другой вариант: написать на новых "хипстерских" технологиях, получая удовольствие от того, что ты первый, но потом эти технологии могут устареть, поменяться подход и в итоге это уже станет legacy, которого все будут сторониться. Но это не значит, что нужно всегда использовать устаревшие, проверенные технологии, ИМХО, зависит от проекта.

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

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