«Тест зубной щётки» не позволил Google производить промышленных роботов

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

Что нового в DataGrip 2017.3

Мы пользуемся из Idea. Там есть пара подводных камней с конфигурацией JDBC и немного не хватает кликхаусных функций и прочих плюшек.

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

А зачем?
Даже если считать переезд с существующей инфраструктуры на докер бесплатным (а это не так), то это как минимум новые сервера.

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

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

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

Поправил.

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

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

Это мой косяк, но текст в котором на русском только междометия тоже выглядит инородно.

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

Тут все чуть сложнее.
Это дань моде если уже есть система развертывания, которая удовлетворяет всем требованиям. Тогда встает серьезный вопрос о том стоит оно того или нет.
Но если система строится с нуля, то Docker и вообще контейнеризация — это как минимум очень хороший вариант, хотя и всего лишь один из вариантов

OpenJDK: Project Panama

Ну Panama — это все же светлое будущее, так что рановато)

Дорогие стартапы, хватит задавать математические задачки, чтобы понять умею-ли я программировать

Языки разные. Скучный, вязкий и противный жестко статически типизированный Java и динамическое безумие JavaScript. Дело не только в платформе.

Kotlin и autoboxing

На всякий случай: вот тут есть небольшое выступление Жемерова о том как и во что компилируется Котлин.

Let the Holy War begin: Java vs С++

Сравним молоток и отвертку. И то и другое можно держать в руках. При желании отверткой можно забить гвоздь, а молотком если очень надо можно вкрутить саморез.
Ну вот примерно так же. Java медленнее супероптимизированного кода на плюсах. И никогда не сравнится с ним по скорости. Вот только никому не нужна супероптимизация на уровне всего проекта. Деление сдвигами, паддинг данных, прочие милые шалости. Обычно это нужно в редких сильнонагруженных отрезках кода.
Если критически важно быстродействие вы берете С и пишете что-то простое, но очень быстрое, если нужно навертеть спагетти из бизнес требований в стиле «здесь играем, здесь рыба, а вот этого клиента мы очень любим и даже на рыбе с ним играем», то вы берете инструмент, который позволит следующему за вами программисту не сойти с ума, разбираясь, что как и почему работает.

В итоге выходит, что из трех надо выбрать два:
— сложная бизнес логика,
— максимальное быстродействие,
— сохранение рассудка и желания жить к концу дня

Почему компании так упорно хотят иметь Fullstack разработчиков?

Есть еще проблема у работника «надоело одно и тоже, хочу чего-то нового»=)

Kotlin: без Best Practices и жизнь не та. Часть 1

Есть такая проблема.
Если послушать доклады Бреслава, он обычно говорит, что они стремились по максимуму все делать явно всегда, если только это не должно происходить в любом случае (например, автокасты).
В защиту можно сказать, что это далеко не новая проблема и в Котлине она стоит далеко не так остро, как в груви.
Ну и мои пять копеек: даже с именованными переменными стоит избегать многократно вложенных функций, оно плохо читается от природы.

Запускаем Node.js на JVM

Я могу понять людей, которые хотят перестать писать серверную часть на Java (хотя сам к ним не принадлежу), но выбор Js как языка, заменяющего Java, откровенно спорный, по крайней мере для меня.
Если у вас команда Js разработчиков, то все понятно, но зачем тащить Java рантайм и плюс к тому писать прокладки и подкладки на неродной Java, а если, наоборот, нужен сервер в JVM, но без Java, то кроме очевидных вариантов Groovy, Scala, Kotlin и т.д. есть довольно зрелые проекты, вроде JRuby.
Но мир велик, если у кого-то есть реальый юзкейс или был юзкей под который хорошо бы лег J2V8 — поделитесь=)

Как ускорить сборку с Maven

У идеи много своих проблем, на которые сильно влияют размеры проекта, но даже когда все работает именно так, как должно, есть проекты, которые используют кодогенерацию и/или другого рода костыли, на которые нет поддержки в IDE. И чем больше проект, тем больше костылей в процессе сборки=)

Как ускорить сборку с Maven

Profiler используете?
И еще awaitility очень помогает избавляться от разного рода sleep'ов в тестах.