![image](https://habrastorage.org/getpro/habr/post_images/1f0/e2d/286/1f0e2d286cb386a809fecca76a956686.jpg)
В этом выпуске
— Автомобильный гигант вкладывает сотни миллионов долларов в Pivotal
— Akka уже не та
— Apache Spark придется потесниться
— Как добавить новый метод в java.lang.Runtime?
— Как получить исходную строку, зная только ее хэш?
… и многое другое
1. Тренды
1.1. Pivotal опять подняли бабла
Как стало известно, Microsoft и Ford вложили в Pivotal примерно 250 миллионов долларов. Мотивация Microsoft не особо интересна — айтишники вложились в айтишников. Куда интересней задачи Ford. Несколько комментариев CIO автогиганта, Marcy Klevron, которая присоединится к борде Pivotal:Our decision is part of our vision as we become both an auto and a mobility company.
We are re-positioning the company into a software world.Очень показательная ситуация. IT-технологии проникают во все большее количество отраслей реального сектора экономики, и имеют все шансы занять там ключевые позиции в перспективе нескольких десятилетий. Думаю, в 2100 году очень сложно будет сказать, какой отдел является наиболее важным для типичного автомобильного гиганта — конструкторы, дизайнеры или айтишники?
«800 лошадок, 1000км без подзарядки, спортпакет Android Microservices Edition, не бит, не крашен, торг у капота ...»
1.2. А где Akka?
Thoughtworks убрали Akka со своего радара, «заархивировав» эту технологию. Фактически это означает «Akka стала скучной». На мой взгляд, решение правильное. Про модель акторов и реактивное программирование уже сказано много слов, и написано много букв. Плюсы и минусы понятны, область применения тоже. Технология стала взрослой и обыденной.Парни из Scala-мира, разумеется, не очень довольны:
@snowcode I have wondered that myself. @thoughtworks, any insight?
— Jonas Boner (@jboner) 6 мая 2016 г.
1.3. Google нагоняет Spark
Встречайте новый проект в инкубаторе Apache — Apache Beam. Это набор интерфейсов для создания data processing pipeline. Вы пишете программу с помощью этих интерфейсов, а потом запускаете ее на конкретном движке, будь это Apache Spark или Google Cloud DataFlow.![image](https://habrastorage.org/getpro/habr/post_images/a23/f26/bab/a23f26babcd5a911b05096f94a859ecc.jpg)
Источник: shinetechblog.files.wordpress.com
Главный спонсор проекта (кто бы мог подумать?) — Google. Свой мотивацию они поясняют так: сделать кайфовый стандарт, перетащить на него много приложений, а потом подсунуть под эти приложения свою облачную платформу. Например, с помощью вот таких бенчмарков, хахаха. На самом деле, большая ставка сделана на опен-сорс в целом, и Apache в частности, как на наиболее влиятельное OSS-коммьюнити.
Очень своевременное движение, которое может дать Google хороший шанс оседлать нарастающий тренд бигдато-процессинга.
1.4. Какой энтерпрайз у вас?
Plumbr собрали статистику использования JEE контейнеров. Результаты вполне ожидаемы, больше всех жгут Tomcat и JBoss.2. Почитать
2.1. Azul влили Runtime.onSpinWait() в OpenJDK
Ссылка: https://www.azul.com/jep-285-small-perfectly-formed/Редкий случай, когда компания с именем отличным от Oracle, самостоятельно продвинула и спонсировала фичу, которая к тому же меняет базовый класс java.lang.Runtime.
Процесс был непростой. Особенно тяжело далось решение об именовании соответствующего метода. В процессе обсуждения нервы у людей уже начинали сдавать. Со стороны это может показаться бюрократическими издержками, но на практике правильное именование классов и методов фреймворка или платформы едва ли уступает по важности имплементации. Как лодку назовешь, так она и поплывет.
В конце концов все разрешилось благополучно. Теперь спиниться в JDK9 будет веселей.
2.2. Интересное обсуждение Java Mission Control
Ссылка: https://groups.google.com/forum/#!topic/mechanical-sympathy/uJqHLd_i2hEТред начался со скриптинга в JMC, но очень быстро ушел в офтоп, переключившись на обсуждение преимуществ и недостатков JMC, а так же его грядущих изменений в JDK9. Интересно.
2.3. Отличный доклад инженера Netflix об инструментарии SRE
Ссылка: http://www.brendangregg.com/blog/2016-05-04/srecon2016-perf-checklists-for-sres.htmlSRE — это site reliability engineering. Если кратко — это devops-ы, перфомансники и архитекторы в одном лице. Их задача — сделать так, что бы сервис а) работал; б) работал быстро; в) масштабировался. Задача интересная, но далеко не самая простая. По ссылке вы найдете доклад о том, какие инструменты используют парни из SRE отдела Netflix. Поучительно.
3. Мудрость
3.1. Про in-memory
Storing data in-memory does not automatically make a database fast. It may be faster if IO was bottleneck, but make no diff if not.
— DynomiteDB (@DynomiteDB) 3 мая 2016 г.
3.2. Про моки и слишком категоричные высказывания
Your reminder that mocks and stubs signal design problems, that when fixed, will enable you to remove the mocks.
— kenbot (@KenScambler) 5 мая 2016 г.
@KenScambler I often agree, but look at the tests for the Aeron protocol by @mjpt777, @toddlmontgomery, et al. Great counter example!
— Dean Wampler (@deanwampler) 5 мая 2016 г.
@deanwampler @KenScambler @toddlmontgomery Most tools have their place. A tool used badly, or out of context, is not the tools fault :)
— Martin Thompson (@mjpt777) 5 мая 2016 г.
3.3. Про «напишем все сами»
OH: "Want to keep from Vendor Lock in? Just build everything yourself. I mean EVERYTHING." :(
— DevOpsosaurous (@paulycomtois) 5 мая 2016 г.
Unfortunately, many fail to realize that it is the ultimate lock-in https://t.co/gw2ytv2oER
— Krish (@krishnan) 5 мая 2016 г.
3.4. Про throughput и latency
Not even God understands queuing theory.
— Eric Bowman (@ebowman) 6 мая 2016 г.
4. Юмор
4.1. Правильная обработка исключений
Просто добавляйте в сообщение ссылку на StackOverflow.Most productive exception handler ever pic.twitter.com/ymDoKVcQo5
— Marcos Besteiro (@MarcosBL) 6 мая 2016 г.
4.2. Получение строки по хэшу
[:|||||:]И смех, и грех: разработчик попросил помочь ему с алгоритмом хэширования строк. Главное требование — возможность получить исходную строку по хэшу. Ответ не заставил себя долго ждать:
#include <string>
int main() {
std::string s = "Hai!";
std::string* ptr = &s; // this is a pointer
std::string copy = *ptr; // this retrieves the original string
std::cout << copy; // prints "Hai!"
}
Повод задуматься тем, кому не нравятся фундаментальные вопросы на собеседованиях.
4.3. Стало известно, кто был прообразом Imp в первом Doom
[:|||||:]Это Phillip Heath:
![image](https://pbs.twimg.com/media/Chbl4BHWYAANeae.jpg)
Вывод: тягайте железо, и возможно когда-нибудь и с вас нарисуют персонажа очередного шутера.
Комментарии (12)
elusiveavenger
11.05.2016 06:30А Java разве не «он»? Язык же. Ну и «мир» тоже мужского рода вроде как.
Throwable
11.05.2016 13:14> 1.4. Какой энтерпрайз у вас?
Контейнеры Tomcat вместе с Jetty занимают почти 70%, что еще раз доказывает, что интырпрайз со всеми своими кровавыми EJB/JTA/JMS не нужен. JBoss — единственное из мира интырпрайза, что на чем можно хоть как-то разрабатывать и тестировать.
Причем, те, кто пользует Tomcat, по ходу не догадывается, что есть Spring Boot или что Jetty можно пускать в embedded-режиме и не заморачиваться с деплоями. Как альтернатива Jetty появился очень неплохой embedded-контейнер Undertow, который отпилен от Wildfly.terryP
11.05.2016 18:18+1Причем, те, кто пользует Tomcat, по ходу не догадывается, что есть Spring Boot
А как использование Spring Boot и Tomcat противоречит друг другу? У нас в проекте есть и то и другое.
Jetty можно пускать в embedded-режиме
А Tomcat можно пускать как плагин мавена и что? Я не против Jetty, но откуда такие данные про недогадываются? Чем вам tomcat не угодил-то?Throwable
11.05.2016 19:27У вас в проекте есть Spring Boot, который пускает embedded Tomcat с уже заряженным веб приложением. Это правильно, просто и удобно. Если же вы деплоите свое приложение на Spring Boot-е в Tomcat standalone, то мне вас просто жаль. Деплоймент — глупый и рудиментарный процесс, корнями уходящий в JEE.
> А Tomcat можно пускать как плагин мавена и что?
А то, что еще надо собрать и задеплоить в него свою поделку, и потанцевать с бубном при подключении дебаггера. И все это делать каждый раз. Мне лично лень. Особо продвинутые умеют пускать Tomcat из Eclipse WTP.
> Чем вам tomcat не угодил-то?
Во-первых, модель standalone сервер с деплойментом я не воспринимаю — если программа не пускается при помощи public static void main(String[] args), то это кусок гиковского дерьма. Хотя именно в такой модели используют Tomcat большинство людей.
Во-вторых, embedded-режим в Tomcat-е появился недавно и не слишком функционален. Jetty гораздо лучше модуляризирован, и очень гибок в плане программной конфигурации. Кроме того он шустрее пускается.terryP
12.05.2016 16:54А то, что еще надо собрать и задеплоить в него свою поделку, и потанцевать с бубном при подключении дебаггера. И все это делать каждый раз. Мне лично лень. Особо продвинутые умеют пускать Tomcat из Eclipse WTP.
Особо продвинутые используют Идею, которая и мавен проект соберет и в режиме отладки Tomcat запустит. Все можно делать одной кнопкой в Идее (включая отладку). Какие танцы с бубном при подключении дебаггера, если достаточно просто запустить as debug в идее?
если программа не пускается при помощи public static void main(String[] args)
У нас проект запускается как из main, так из плагина. В Идее вообще никакой разницы нет и то и то запускается одной кнопкой, а дебаг запускается второй кнопкой.
Во-вторых, embedded-режим в Tomcat-е появился недавно и не слишком функционален. Jetty гораздо лучше модуляризирован, и очень гибок в плане программной конфигурации. Кроме того он шустрее пускается.
Это все вкусовщина, у вас есть ссылки на конкретные возможности Jetty, которых нет в Tomcat и которые были действительно критичны?Throwable
12.05.2016 17:57Каждому критично свое. Для меня критична легковесность, модульность, гибкость, программная конфигурация (без простыней xml), отсутствие необходимости в сложном тулинге для разработки (Maven Tomcat Plugin, Idea Ultimate, Eclipse WTP, etc...)
В плане работы разницы нет: оба поддерживают стандарт Servlet 3.x, оба хорошо оттестированы на продакшне, оба достаточно зрелые.
madkite
12.05.2016 01:26> фичу, которая к тому же меняет базовый класс java.lang.Runtime.
А по ссылке на первоисточник написано, что java.lang.Thread.
leventov
4.1 для Java: https://github.com/OpenHFT/Exception-Handler