Java *

Наша команда, аналогично с автором статьи, уже почти как год перешла со Scala на Kotlin в качестве основного языка. Мое мнение во многом совпадает с автором, поэтому предлагаю вам перевод его интересной статьи.

Прошло прилично времени с того момента как я не обновлял блог. Вот уже как год я перешел со Scala, моего основного языка, на Kotlin. Язык позаимствовал много хороших вещей, которые мне нравились в Scala, сумев при этом избежать многих подводных камней и неоднозначности, которая есть в Scala.

Ниже я хочу привести примеры, которые мне нравятся в Scala и Kotlin, а также их сравнение в том, как они реализованы в обоих языках.

Введение

• стандартные листенеры не позволяют получить подробную информацию по всем подзапросам, прописанным в тест плане;
• стандартные листенеры выводят информацию в XML — формате, что осложняет дальнейший анализ логов средствами Excel и Pandas.

Прошли те дни, когда целые компании зависели от одного поставщика технологий. Даже маленькие фирмы и любители найдут оптимальное для себя решение, объединяя технологии в одном проекте. Долгое время Java держала первенство среди серверных технологий. Но сегодня Node.js повсюду.

Но даже с ростом популярности Node.js и JavaScript, Java не теряет силу. Кроме того, немногие организации могут позволить себе перенести всю платформу с JVM на Node.js. Это значит, что компания должна либо продолжать использовать текущий стек технологий, либо запускать несколько стеков, которые будут общаться через сетевое API. Однако есть и другой способ: запустить Node.js прямо в процессе JVM. И J2V8, наконец, сделала это возможным.

В этом посте речь пойдёт о реализации процедуры вычисления значения функции распределения Стьюдента без использования каких-либо специальных математических библиотек. Только Java (либо C/C++, код вполне универсален).

Spring Security — must-have компонент в Spring-приложениях, так как он отвечает за аутентификацию пользователя, а также за авторизацию тех или иных его действий в системе. Одним из методов авторизации в Spring Security является использование аннотации @PreAuthorize, в которой с помощью выражений можно наглядно описать правила, следуя которым модуль авторизации решает, разрешить ли проведение операции или запретить.

В моём REST-сервисе возникла необходимость предоставить точку доступа к описанию правил авторизации для всех методов контроллеров сервиса. Причём, по возможности, избежать раскрытия специфики именно SpEL-выражений (т.е., вместо permitAll нужно что-то вроде anybody, а principal избегать вовсе как избыточное выражение), но возвращать свои выражения, с которыми уже можно делать что угодно.

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

Примерно полгода назад тестов и задач стало столько, что наша маленькая ферма с Selenium в час пик стала буквально «захлебываться» от запросов на новую сессию Firefox или Chrome. Выглядело это примерно так: на Selenium grid образуется очередь из сессий, которые ждут свободный браузер. Пользователи продолжают запускать автотесты, и эта очередь продолжает расти, но браузеры заняты старыми задачами и сессии «отваливаются» с таймаутом.

В недавней статье про производительность Java разгорелась дискуссия на тему измерения производительности. Глядя на неё, с грустью приходится сознавать, что многие люди до сих пор не понимают, насколько сложно правильно измерить время выполнения того или иного кода. Кроме того, люди вообще не привыкли, что один и тот же код в разных условиях может выполняться существенно разное время. К примеру, вот одно из мнений:

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

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

Уже два десятилетия активно плодятся мифы о том, что приложениям на Java свойственны проблемы с производительностью. Одновременно с этим на Java создаются по-настоящему высоконагруженные системы. Кто же в конечном итоге прав? Чтобы составить мнение о том, как сейчас обстоят дела с производительностью Java, мы обратились к двум заинтересованным сторонам: создателям самой Java и клиентам, использующим Java в своих системах. На наши вопросы любезно согласились ответить Алексей Шипилёв (Oracle) и Олег Анастасьев (Одноклассники).