Строители против синтаксиса Java

Serializable

Валидно, но Я честно говоря не видел Serializable билдеров о_О

А с именованными аргументами есть другая проблема — наследование таких конструкторов.
Python, например, динамический и умеет *kvargs, но в Java такое не прокатит я думаю.

«Kubernetes во все поля!» – интервью с программным комитетом конференции DevOops

не, ну во-первых, не сам придёт а ты призвал ;)
Во-вторых, я вроде soft выпилился в прошлый раз и как бе не мешаю вроде, не? :)
Если рынок решает — я против шерсти не попру, тем более учитывая что jugru делают хорошие конференции и вообще няшки :)

Интеграционные тесты для Java с помощью TestContainers. Меньше безумия, больше порядка, и всё это автоматически

ты просто не с теми говоришь ;)

Интеграционные тесты для Java с помощью TestContainers. Меньше безумия, больше порядка, и всё это автоматически

P.S.S. только у нас не 5 лет истории, а чуть меньше, и первый коммит датируется 12м Апреля ;)
https://github.com/testcontainers/testcontainers-java/commit/bf37c505e7a6b5ce143fd0311209c5514a52b4f5

Интеграционные тесты для Java с помощью TestContainers. Меньше безумия, больше порядка, и всё это автоматически

olegchir тот момент когда один из главных разработчиков родом из России и в прошлом активно писал на хабр, но не додумался написать про TestContainers :D

Спасибо за перевод!
Надо бы мне мою https://medium.com/@bsideup/testing-your-docker-containers-with-testcontainers-and-groovy-3b9ef97ad1c2 тоже перевести.

P.S. ходят слухи что на Heisenbug 2017 Moscow так же будет доклад про TestContainers ;)

DevOops 2017 Piter: Новая конференция от JUG.ru Group, поговорим про DevOps

Может потому что это не job title, а процесс? ;)

IDEA пора закапывать?

вот ещё, на тему отзывчивости IDEA:
https://gyazo.com/9895e2bbeb933a6ede7841bfb97b2153

Никогда такого не видел в Atom или VS Code, даже на огромных проектах

IDEA пора закапывать?

https://blog.jetbrains.com/idea/2015/08/experimental-zero-latency-typing-in-intellij-idea-15-eap/

так-то давно уже собираются =)

IDEA пора закапывать?

1. Уже делают. Не с нуля. Вопрос времени, я думаю.
2. Для этого в LS есть понятие "Client". Тот, кто рисует результат анализа и позволяет его редактировать. И я хотел бы иметь возможность выбора, да.
3. Это простите как? Что тогда вы понимаете под отзывчивостью? Я просто очень известный в узких кругах неудачный юзер IDEA где у меня всё тормозит. Когда 200-300ms от нажатия кнопки до появление символа при редактировании Kotlin исходников например — это отзывчиво или нет?

IDEA пора закапывать?

Кидайтесь камнями, но я, не смотря на мою любовь (убывающую, правда) к IDEA, искренне верю в будущее Language Servers.

Когда IDE будут меряться рендером шрифтов, отзывчивостью и удобством (мне например очень понравился VS Code), а работу по анализу сорцов будут делать IDE независимые language server-а (как это у Haxe сделано например).

Имхо это прекрасное будущее разработки тулинга. У IDEA сейчас прекрасный анализ кода. Это заставляет открывать её вместо VS Code когда надо сделать рефакторинг. Но поправить пару строчек — проще открыть Atom, Code, Vim, Nano, etc…

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

json-api-normalizer: легкий способ подружить Redux и JSON API

return fetch(fullUrl, options)
    .then(response => response.json()
      .then((json) => {

Вот тут по спеке Promise-ов можно избавиться от вложенности:

You can pass a lambda to then and if it returns a promise, an equivalent Promise will be exposed to the subsequent then in the method chain

return fetch(fullUrl, options)
    .then(response => response.json())
    .then((json) => {

А ещё можно вообще избавиться от Promise-ов и начать использовать RxJS с React-ом:
https://habrahabr.ru/post/309226/

Docker in production: «Когда ты это кушаешь, тебе, как минимум, не противно, особенно если знаешь, как готовить»

Он работает на RHEL 6.5 с ядром >= 2.6.32 в EPEL

Docker in production: «Когда ты это кушаешь, тебе, как минимум, не противно, особенно если знаешь, как готовить»

В статье появилась секция от меня, я там привожу ссылки на реальные цифры и исследования, в том числе про IO. В двух словах — на 2016ый год, Docker не влияет на IO — такой результат получили Percona в своём исследовании (ссылка прилагается)

Docker in production: «Когда ты это кушаешь, тебе, как минимум, не противно, особенно если знаешь, как готовить»

Согласен. Главное — знать меру и стараться не переводить названия, особенно когда оригинал на русском языке :)

Docker in production: «Когда ты это кушаешь, тебе, как минимум, не противно, особенно если знаешь, как готовить»

Поверьте мне, мы тут в ZeroTurnaround отлично знаем, какая версия Java уже не поддерживается :D Вот только наши покупатели всё равно до сих пор сидят на 6ой, а некоторые и на 5ой. И нежелание админов что-то менять — это очень популярная причина "почему".

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

Docker in production: «Когда ты это кушаешь, тебе, как минимум, не противно, особенно если знаешь, как готовить»

Docker — он, на самом деле, не про контейнеры. Он про tooling. Т.е. они не придумали особо ничего нового в мире контейнеризации, они написали отличный tooling вокруг неё — и стрельнуло.

Особенно это поняли те, кому приходилось работать с NS, cgroups, jails, zones, etc — когда это больше не боль, а что-то простое, вплоть до уровня хипстеров. Ведь дай хипстеру чистые cgroups и zones — он повесится в мануалах

Docker in production: «Когда ты это кушаешь, тебе, как минимум, не противно, особенно если знаешь, как готовить»

Я ни в коем случае не предлагаю использовать докер везде. Вот только не надо плодить безосновательных слухов о том, что он тормозит, что числодробилки лучше запускать говёньнким bash скриптом, и всё такое.

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

Docker in production: «Когда ты это кушаешь, тебе, как минимум, не противно, особенно если знаешь, как готовить»

Docker — это когда "жаль мы не можем использовать Java 8 потому что админ не хочет обновлять прод" звучит как боль из прошлого

Docker — это когда разработчикам видней, как тюнить JVM параметры

Docker — это когда Java Agent-ы уже не выглядят так страшно для интеграции

Docker — это когда мне не важно, какие порты будут заняты в моём окружении, я девелопер, я не хочу думать, я хочу 8080

Docker — это когда "мы переползли с Tomcat на Netty, а админ даже не заметил"

Docker in production: «Когда ты это кушаешь, тебе, как минимум, не противно, особенно если знаешь, как готовить»

Какой плохой, я б даже сказал вредный материал вы тут наваяли. В основном претензии к Андрей Филатов lincore:

Нет, мастер – большая железная машина: когда тебе нужно собрать что-то маленькое, запустить один-два билда, можно применять Docker, но у нас 20-30 процессов работают 24/7, и Docker не очень подходит, мы бы уперлись в производительность.

Это сами придумали, или проводили замеры? Потому что это откровенный Bullshit.
За год Jenkins-а в Docker-е в ZeroTurnaround у меня ни разу не было проблем с производительностью.

Пришлось, правда, для нескольких quality assurance инженеров написать на wiki подробную инструкцию, как скачать и поставить Docker-машину

Товарищи! Я конечно понимаю, что модно писать "Супир Сервис Лтд", но Docker-машина? Как прочитавший это newbie поймёт, что речь про Docker Machine, а не про вручную настроенную "bash скриптами" виртуалку?

Я думаю, в числодробилки его ставить не имеет смысла. Если у вас reporting-инструмент, который переваривает огромные объемы данных, то накладные расходы от Docker’а будут сказываться на производительности

А вы не думайте, а проверяйте. Я с Docker-ом с 2014 года, гонял везде, и дев, и билд системы, и прод. Docker показывает отличную производительность (и это не удивительно, если потратить хотя бы пол часа на изучение, как он работает и что это вообще такое)
У нас (ZeroTurnaround) сейчас активный проект — APM (application performance monitoring), всё бегает в Docker-е, чуть более чем быстро.

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

Ясно-понятно.

Дорогие JUG.ru, Вас слушают десятки тысяч разработчиков, пожалуйста, следите за качеством материала и проводите пост-модерацию. А то наплодите сотни таких вот экспертов.

P.S. извините, бомбануло.

RxConnect — когда React встречает RxJS

Если писать без долларов, то тогда тот же самый код будет выглядеть примерно так:

@rxConnect(() => {
    const search = new Rx.Subject();

    const articles$ = search
        .pluck(0) // нас интересует первый переданный аргумент
        .flatMapLatest(searchWikipedia)

    return Rx.Observable.merge(
        Rx.Observable.of({ search: (...args) => search.onNext(args) }),

        articles$.map(articles => ({ articles }))
    )
})

что имхо гораздо грязней