Это все конечно хорошо и правильно, однако скорей всего на все свои вопросы вы получите стандартные малоформатные ответы по которым сложно будет понять что-то конкретное. С другой стороны шаблонные вопросы со стороны рекрутера должны у кандидата вызывать тревожный звоночек по общего впечатления о компании.
Я бы сказал не небесспорная, а как раз очень даже спорная, по которой уже 100 лет не утихают дебаты.
Главным камнем преткновения в дискуссии о лингвистическом релятивизме является проблема корреляции между языком и мышлением. Самой строгой формой корреляции является лингвистический детерминизм, который предполагает, что язык полностью определяет все возможные когнитивные процессы индивида.
и
Основной спорный вопрос формулируется так: являются ли высшие психические функции по большей части универсальными и врождёнными или же они представляют собой преимущественно результат обучения и, следовательно, являются субъектом по отношению к культурным и социальным процессам, которые варьируются в зависимости от места и времени.
На мой взгляд интерес к теме черезмерно раскручен ввиду ее коммерческой перспективности: вся рекламная индустрия и рынок основан на когнитивной лингвистике. А там где рынок, там и бабло водится. Поэтому очередные "исследования" щедро спонсируются заинтересованными физ- и юр-лицами. А чтобы поток денег не прекращался, никто не заинтересован поставить финальную точку в этом вопросе.
Если уж брать язык как средство коммуникации и записи мыслей в общем смысле, то он не ограничивается исключительно лингвистикой и речью, которые по сути очень примитивны. Есть более компактные и емкие способы изложения и восприятия информации, которыми люди пользуются в технических областях: язык математически, графики и диаграммы, чертежи, рисунки наконец. И естественно соответствующие специалисты за свою карьеру прокачивают в первую очередь свои технические навыки, нежели разговорные. Ну а если вам нужен кандидат со связной речью -- идите искать на филфак.
Ну это было высказано в качестве контраргумента исходному тезису :) По манере речи и письма можно сказать об общем культурном уровне и образовании человека, который в общем случае может коррелировать с техническими навыками. Кроме того, речь -- это такой же скилл, который при желании и необходимости можно прокачать.
Сбивчивая речь и непоследовательность в изложении мыслей
Извините за токсичность, но брехня и полная чушь!
при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи
Даже при восприятии и формировании устной речи задействованы совершенно разные участки мозга, это вам подтвердит любой физиолог или даже человек, изучающий иностранный язык. Понимать речь и владеть ею -- это совершенно разыне навыки. И при многих поражениях речевого аппарата у человека как правило сохраняется возможность понимать речь и уж тем более мыслить.
разработчик сначала придумывает абстрактное решение в голове, как раз используя логические функции мозга, а затем происходит перевод этой абстракции в фактический код.
Бред! Абстрактное мышление вообще практически никак не связано с речью. Мы мыслим не речью и даже не символами, а некими абстрактными образами. Никаких "логических функций мозга" на этот счет не существует.
Речь -- это строго упорядоченная во времени система сообщений, тогда как мыслительный процесс, реализуемый нашей головной нейросетью, по большей части параллелен, неупорядочен, и многоуровнен. Когда программист "в потоке", он в голове держит сразу огромное количество абстракций, которые в процессе детализирует, постоянно перемещая фокус внимания от одной к другой. И код мы пишем не как вы изложили выше -- "от забора и до обеда", а во многих местах сразу, не особо заботясь о последовательности написания. Кроме того в момент особой концентрации на задаче перестает хватать "ресурсов" мозга на задействование речевого аппарата. Плюс зачастую речь просто не поспевает за мыслью, о скорости которой уже издревле сложились мемы. Поэтому за столом мы как правило видим программиста, судорожно шепчущего под нос непонятные слова, а не оратора, вещающего трактат о решении задачи.
Так что именно затрудненная и непоследовательная речь будет скорей всего признаком хорошего программиста. И наоборот -- плавность и последовательность будет либо говорить о домашней заготовке, либо содержать наивные и поверхностные суждения, скорей всего ввиду ограниченности самого субъекта.
Сильные инженеры нередко оказываются хорошими спикерами — именно их вы чаще всего можете увидеть выступающими на тематических конференциях.
Однако, заведомо будет справедливо, что хороших инженеров, НЕ выступающих на конференциях, гораздо больше. Кроме того, излагать заранее подготовленный доклад -- совсем не то, что излагать свои мысли в реальной работе.
Основная проблема такого подхода состоит в том, что внесение любого
...и дальше идет типичная мантра карго культа микросервисов...
может потребовать множественных изменений в различных подсистемах
Если этого требует функционал, он и с микросервисами потребует тех же самых изменений. Только координировать их будет в сто раз сложнее. Наивно полагать, что бизнес изменение затронет только один малюсенький сервис -- скорей всего оно как серпом проедет сразу по всей системе на всех уровнях, требуя изменений и пересборки почти всего и сразу.
будет необходимо создавать дополнительные экземпляры всего монолита, что не всегда возможно, например если внутри запущенного процесса
Фигня! Запускайте столько монолитов, сколько душе угодно -- это будет дешевле и в разы меньше по ресурсам, чем микросервисы. Причем никто не запрещает выделять разные инстансы для разных задач. Но главное -- все инстансы взаимозаменяемые.
предоставляют общий механизм вызова удаленной функции (метода), аналогичный вызовам локальных функций (методов)
...настолько же быстрый, простой, надежный, контролируемый, легко тестируемый и поддерживаемый!
Но все же остается открытым вопрос - как оптимально разделить приложение на независимые фрагменты, чтобы уменьшить неизбежные расходы по производительности при передаче данных через сеть и при этом сохранить гибкость в масштабировании и замене компонентов.
Самый демагогичный на сегодняшгий день вопрос, на который существует миллион ответов и ни одного, признанного верным. В вашем случае не будет концептуально хуже, если вы соберете обратно все *-subsystem в единый System и запакуете все в единый .jar без лишнего геморроя.
Если есть определенный функционал, который как пятое колесо в телеге, и есть реальная необходимость вынести его в отдельный сервис -- выносите, кто вам мешает? Но бездумно следовать девопс религии и пилить все, к чему только можно прикрутить API -- это попахивает идиократией. Извините за присущую резкость.
Наверное единственный оставшийся серьезный юзер у свинга -- это Jetbrains :) Он же по совместительству и основной контрибьютор.
Вообще нынче модно делать локальные веб приложения и паковать их в электрон. Если нужна обязательно Java, взять какой-нибудь Vaadin или Kotlin Multiplatform...
Что такое “микросервис” технически и чем он отличается принципиально от “монолита”?
Хороший вопрос, не так ли?
У меня есть даже лучше вопрос: чем микросервисная архитектура принципиально отличается от сервисной (SOA), расхайпованной 10-15 лет назад? У меня только один ответ -- это то же самое, только собранное на коленке, реализованное на другом стеке, и игнорирующее всякие индустриальные стандарты.
Мартин Фаулер в 2012 году говорил о так называемой “слабой связности”. И “слабая связность” становится в микросервсиной архитектуре центральным понятием.
К сожалению, центральным понятием в микросервисной архитектуре на сегодняшний день являются именно все эти ваши докеры, кубернетисы, клауды, эджайлы, девопсы и прочие религиозные атрибуты. Сомневаюсь, что Мартин Фаулер в 2012 году имел именно это ввиду, говоря о слабой связанности.
Базы данных. “Слабая связность” в микросервисном подходе позволяет каждому отдельному микросервису иметь свою базу данных. А это значит, что её во-первых нужно спроектировать, а во вторых доходчиво для разработчика описать.
...а это значит, что ввиду отсутствия ACID у вас сразу теряется консистентность операций, и вам необходимо дополнительно искать искусственные способы обеспечения целостности данных, плюс по каждому предоставить доказательство, что в каждом данном сценарии целостность соблюдается. И на это будет тратиться львиная доля усилий архитектора решения.
Лет 5 назад было абсолютно нормальным говорить бизнесу о том, что ему надо. Теперь это не так. Бизнес теперь диктует ИТ, что ему нужно и сам предоставляет аналитику.
Это наверное в какой-то параллельной вселенной. Бизнес до сих пор требует одну большую кнопку: "сгенерировать прибыль" или "сделать красиво". На элементарные вопросы типа "что делать, если случиться то-то..." у бизнеса один ответ -- "мне лень об этом думать", или "ну вы там придумайте сами что-нибудь, я же плачу вам за это". Вся аналитика, которую я видел за свою карьеру в лучшем случае покрывает наивный самый оптимистичный сценарий, оставляя за кадром кучу кейсов. И что-то я не заметил, что ситуация сильно поменалась.
Вот теперь стало понятно, что нагромождение микросервисов плохо масштабируется и очевидно, микросервисы это не всегда хорошо. Так когда же нам стоит их использовать?
Тут можно добавить еще и организационный мотив: если над компонентом трудится более 5 разрабочиков, становится очень сложным координировать их работу, слияние веток, релизный цикл и т.д. Поэтому при возможности лучше разделить функциональные части и на каждую назначить свою небольшую команду.
И вот в этой единой точке входа мы складываем схемы (xsd или json). И вот по этим схемам должна осуществляться валидация данных.
И как это соответствует принципу слабой связанности иметь единый реестр сервисов? Это что-то типа UDDI из SOA?
Да, после пандемии рынок сильно меняется -- очень много офферов от зарубежных компаний. Однако, компании тоже не дураки -- предлагают условия исходя из твоего ПМЖ, особенно если компания имеет представительство в стране.
С налогами по законодательству, если проживаешь больше полугода, то должен платить налоги в месте проживания. Налоговая будет следить за деньгами, поступающими на счет в местном банке, с которых нужно будет декларировать прибыль. Если есть резиденство с разрешением на работу, то можно оформиться как ЧП (autonomo), сделать себе официальную зарплату, и государство будет доить тебя конскими налогами при минимальной отдаче.
Главное отличие испанцев (и европейцев в целом) от жителей развивающихся стран — в том, что они не гонятся за доходами и сверхдоходами. Местных низких зарплат достаточно для комфортной жизни.
Тем не менее в IT одни из самых низких зарплат по Европе. Выше установленной ставки нигде не прыгнуть, работай ты хоть за семерых. Поэтому большинство испанцев мечтает устроиться в большие компании, которые помимо стабильности могут предложить некоторые социальные бонусы и не сильно напрягать с обязанностями. С другой стороны низкие зарплаты в IT компенсируются низкой производительностью и качеством специалистов, т.к. реально хорошие профессионалы легко эмигрируют в другие страны, где их труд оценивается в выше 2-5 раз.
/sarcasm mode/ Наше дело маленькое: сказали светильник -- значит светильник. Верим, вопросов не задаем.
У меня одного впечатление, что способ изготовления этих артефактов больше похож на лепку, нежели на резьбу? Нет характерных резких граней, все переходы плавные, плоские части как-будто согнуты внутрь...
Возможно это так в других областях индустрии, но в IT все имеет свою негативную специфику. Во-первых, здесь технологии не развиваются, а по большей части деградируют: каждые несколько лет стек полностью заменяется на более примитивный и ресурсоемкий, компенсируя это ростом вычислительной мощности. При этом при кажущейся простоте и доступности новых средств разработки, а также более низком пороге вхождения, сама разработка и поддержка продукта никак не становится проще или дешевле.
Хайп раздувает не тот кто создает технологию.
Именно те, кто создает технологию и раздувают хайп вокруг нее. Более того, сама технология создается ради хайпа, а не наоборот. Сегодня все модные тенденции идут от гигантов индустрии, которые фактически диктуют моду и технологии. И делают это с конкретной коммерческой целью -- продвижение своих облачных платформ. А мода в свою очередь бездумно подхватывается адептами и создает эффект снежного кома.
Ценность определяет социум, людям нравиться значит все ок.
Ценность на 100% определяет маркетинг, задача которого максимально оправдать завышенную цену товара или сервиса при минимальных издержках на производство оного. Успешный товар -- это не лучший или качественный, а наиболее коммерчески оправданный. Конечные же потребители всегда ограниченны, а зачастую безальтернативны в своем выборе, а посему зачастую вынуждены хавать и плеваться разрекламированным низкокачественным ширпотребом.
Наконец-то человек со здоровой критикой. Подписываюсь под каждым пунктом! Блокчейн ведет к мировому энергетическому кризису. Material design - примитивное некрасивое и неудобное говнище: кнопка должна быть похожа на кнопку, а не быть раскрашеной полоской.
По поводу Agile: из изначально правильной идеи не мешать разработчику делать до конца свое дело сколотили целую религию с адептами, клириками и евангелистами, позиционируя ее как благодать и серебряную пулю от всех напастей. А на еретические претензии типа "вот мы внедрили эджайл, но сани быстрее не едут" всегда осаждают, что эджайл у вас неправильный, сами вы постоянно грешите и потому невидать вам благодати.
С DevOps-ом та же ситуация. Да, неплохо бы если разработчик понимал всю цепочку доставки и выполнения их кода. Однако это быстро переросло в целый фетиш из паравоза тулзов, где девопсеры меряются ЧСВ у кого их больше задействовано в проекте. И чем их больше, тем весомее становиться роль девопсера в проекте, при всем при том, что все это никак не добавляет value к самому проекту.
Я бы еще к хейту добавил Микросервисы. Распили свой монолит на микросервисы и будет тебе счастье! На самом деле получаешь лишь геморрой с кодовой базой, деплойментом, сборкой, координацией изменений и пр. А самый лютый дебилизм -- это неосознанный отказ от транзакций и ACID. То есть консистентность данных, которая шла из коробки, теперь заменяется на саги и прочие неработающие велосипеды. К сожалению, на сегодняшний день уже мало кто вообще понимает концепт транзакций.
Я думаю самый главный хейт, который лежит в основе всех новых IT-веяний -- это Культ Карго, религиозное мышление, отсутствие элементарной критики и постоянный поиск панацеи от всех проблем и серебряной пули от всех напастей. Поэтому очередной распиаренный термин быстро подхватывается миллионами и становится божественным откровением. То, что он имеет все признаки религии вы можете убедиться например по неаргументированным нападкам адептов в коментариях, сразу же переходящих на личности. Настоящий айтишник всегда должен критически относиться к своим средствам и методам разработки, уметь ими пользоваться, понимать их преимущества и недостатки, и оценивать их исключительно с позиции личной пользы.
А ничего удивительного. В Logback мы внезапно столкнулись с багом, который спровоцировал почти детективную историю поиска отказа в системе. Баг стоит в трекере ещё с 2014 года, но до сих пор не закрыт.
И да, и нет. Во-первых, автоматические инструменты достаточно "костные" -- вылезает стопицот случаев, где реально такое написание оправдано, однако нет возможности объяснить это аналайзеру. А во-вторых, они реагируют лишь на примитивные случаи подобно потенциальным ошибкам, оставляя за кадром более глобальные вещи как общий дизайн, стиль и читаемость кода, что например для меня является гораздо более важным аспектом, нежели наличие потенциальных ошибок, которые легко покрываются тестами.
Круто! У меня были подозрения, что весь процесс не достигает полного паралелизма выполнения либо по причине ограничения пулов, либо сам сайт не дает делать 100 запросов с одного хоста и ставит их в очередь. Интересно было бы посмотреть действительно ли все выполняется параллельно.
Насчет долгого SSL хендшейка есть предположение, что на сокете не выставлен TCP_NODELAY, однако я не нашел как его можно сконфигурировать в Java 9 HttpClient -- там настройки сильно ограничены.
Почему разница между Java и JavaScript почти трёхкратная?
Первое, что бросается в глаза -- это кондовый способ замера производительности:
var start = System.currentTimeMillis();
var contents = requestManyUrls(urls).get();
var time = System.currentTimeMillis() - start;
и что самое основное -- отсутствиепредварительного "прогрева". Это является причиной почему:
Если повторно запустить тот же код, общий размер будет близким, но не точно таким же. Предполагаю, что содержимое некоторых ссылок динамично.
То есть то, что аффтар тут намерял -- это работа http-клиента + класс лоадинг + динамическая оптимизация + создание новых статических инстансов -- т.е. сразу работу половины JVM.
Во-вторых, CompletableFuture.supplyAsync()использует дефолтный ForkJoinPool.commonPool(), поведение которого определяется внешними параметрами, железом и вендором Java-рантайма. В большинстве случаев размер дефолтного пула выбирается равеным количеству CPU core. То есть для 100 параллельных запросов из блокирующих операций использовалось всего 4-8 треда.
Далее:
Параллельные HTTP-запросы при помощи современного HttpClient
Формально работа HttpClient принципиально ничем не отличается от примера выше, за исключением того, что вместо ForkJoinPool.commonPool() используется java.util.concurrent.Executors.newCachedThreadPool(). В итоге то, что замерил аффтар -- это время выполнения запросов + время создания новых тредов для параллельной обработки. Поэтому если бы автор повторил тест сразу после первого прогона -- он был бы "сильно потрясен, весьма удивлен и крайне обескуражен".
Огромный код с современным HttpClient выглядит пугающе
Ну да, особенно если искусственно навтыкать цепочку ненужных преобразований :)))
Почему разница между Java и JavaScript почти трёхкратная?
Потому что у аффтара изначально таковой была задача.
Код на JavaScript сначала выполняет один за другим 105 HTTP-запросов. Когда приходит ответ, движок JavaScript помещает в очередь задач небольшой обратный вызов. После получения всех ответов единственный поток по очереди обрабатывает их.
Ну то есть все рассчитано на то, что все 105 запросов и ответов должны обязательно поместиться в память, что никто не будет скачивать и закачивать гигабайтные запросы/ответы, что все данные для отправки уже доступны во время вызова, и что каждый из 105 обработчиков отработает моментально, чтобы никаки не задерживать других.
В Java это работает совершенно иначе. Создаётся множество потоков, каждый из которых отправляет один HTTP-запрос.
Не в Java, а конкретно в Java 11 HttpClient. В TCP стеке для отсылки требуется: открыть сокет, записать запрос и прочитать ответ. В классической синхронной модели все три операции блокирующие, и поэтому на каждый запрос требуется тред, который их последовательно обрабатывает, учитывая что открытие сокета немоментально, буфер данных для отсылки ограничен и может быть много меньше размера запроса, ответ также может приходить порциями, а обработка никак не должна препятствовать и интерферировать с другими запросами.
А вот в Java как раз есть способ реализовать низкоуровнево полную асинхронную реализацию, используя Selectors и Channels. Кроме того, есть прекрасный стек Netty в котором это уже реализовано, равно как и куча надстроек к нему, напр. полностью асинхронный https://github.com/timboudreau/netty-http-client Ну и напоследок стоит упомянуть, что начиная с версии 17 в JVM добавлен project Loom, с виртуальными тредами, которые позволяют использовать классическую синхронную модель, не заботясь о масштабировании, и которая "под капотом" выполняется асинхронно и неблокирующе. Только реальных тредов будет не один, а сколько душе угодно.
P.S. забыл упомянуть: www.bbc.com наверняка контролирует количество параллельных запросов с одного хоста, поэтому все тесты со 100 реквестами можно сразу выкинуть в корзину.
Легко проследить, что такое определение не противоречит математической идеологии.
Легко заметить, что противоречит:
симметричным (для любых x, y выполняется: если x = y, то y = x)
String a = "Test";
String b = null;
a.equals(b) // false
b.equals(a) // NPE
Строгую математическую семантику соблюдает Objects.equals(). И именно его нужно было использовать с самого начала для оператора "==". Однако создателям Java казалось очень важным каждый обращать внимание пользователей на то, как они реализовали equals(), и что сравнивать строки при помощи "==" в их языке хоть и можно, но будет неправильно. Даром что ссылочное сравнение используется в одном случае из ста. Но уж теперь ничего не поделаешь.
Это все конечно хорошо и правильно, однако скорей всего на все свои вопросы вы получите стандартные малоформатные ответы по которым сложно будет понять что-то конкретное. С другой стороны шаблонные вопросы со стороны рекрутера должны у кандидата вызывать тревожный звоночек по общего впечатления о компании.
Я бы сказал не небесспорная, а как раз очень даже спорная, по которой уже 100 лет не утихают дебаты.
и
На мой взгляд интерес к теме черезмерно раскручен ввиду ее коммерческой перспективности: вся рекламная индустрия и рынок основан на когнитивной лингвистике. А там где рынок, там и бабло водится. Поэтому очередные "исследования" щедро спонсируются заинтересованными физ- и юр-лицами. А чтобы поток денег не прекращался, никто не заинтересован поставить финальную точку в этом вопросе.
Если уж брать язык как средство коммуникации и записи мыслей в общем смысле, то он не ограничивается исключительно лингвистикой и речью, которые по сути очень примитивны. Есть более компактные и емкие способы изложения и восприятия информации, которыми люди пользуются в технических областях: язык математически, графики и диаграммы, чертежи, рисунки наконец. И естественно соответствующие специалисты за свою карьеру прокачивают в первую очередь свои технические навыки, нежели разговорные. Ну а если вам нужен кандидат со связной речью -- идите искать на филфак.
Ну это было высказано в качестве контраргумента исходному тезису :) По манере речи и письма можно сказать об общем культурном уровне и образовании человека, который в общем случае может коррелировать с техническими навыками. Кроме того, речь -- это такой же скилл, который при желании и необходимости можно прокачать.
Извините за токсичность, но брехня и полная чушь!
Даже при восприятии и формировании устной речи задействованы совершенно разные участки мозга, это вам подтвердит любой физиолог или даже человек, изучающий иностранный язык. Понимать речь и владеть ею -- это совершенно разыне навыки. И при многих поражениях речевого аппарата у человека как правило сохраняется возможность понимать речь и уж тем более мыслить.
Бред! Абстрактное мышление вообще практически никак не связано с речью. Мы мыслим не речью и даже не символами, а некими абстрактными образами. Никаких "логических функций мозга" на этот счет не существует.
Речь -- это строго упорядоченная во времени система сообщений, тогда как мыслительный процесс, реализуемый нашей головной нейросетью, по большей части параллелен, неупорядочен, и многоуровнен. Когда программист "в потоке", он в голове держит сразу огромное количество абстракций, которые в процессе детализирует, постоянно перемещая фокус внимания от одной к другой. И код мы пишем не как вы изложили выше -- "от забора и до обеда", а во многих местах сразу, не особо заботясь о последовательности написания. Кроме того в момент особой концентрации на задаче перестает хватать "ресурсов" мозга на задействование речевого аппарата. Плюс зачастую речь просто не поспевает за мыслью, о скорости которой уже издревле сложились мемы. Поэтому за столом мы как правило видим программиста, судорожно шепчущего под нос непонятные слова, а не оратора, вещающего трактат о решении задачи.
Так что именно затрудненная и непоследовательная речь будет скорей всего признаком хорошего программиста. И наоборот -- плавность и последовательность будет либо говорить о домашней заготовке, либо содержать наивные и поверхностные суждения, скорей всего ввиду ограниченности самого субъекта.
Однако, заведомо будет справедливо, что хороших инженеров, НЕ выступающих на конференциях, гораздо больше. Кроме того, излагать заранее подготовленный доклад -- совсем не то, что излагать свои мысли в реальной работе.
...и дальше идет типичная мантра карго культа микросервисов...
Если этого требует функционал, он и с микросервисами потребует тех же самых изменений. Только координировать их будет в сто раз сложнее. Наивно полагать, что бизнес изменение затронет только один малюсенький сервис -- скорей всего оно как серпом проедет сразу по всей системе на всех уровнях, требуя изменений и пересборки почти всего и сразу.
Фигня! Запускайте столько монолитов, сколько душе угодно -- это будет дешевле и в разы меньше по ресурсам, чем микросервисы. Причем никто не запрещает выделять разные инстансы для разных задач. Но главное -- все инстансы взаимозаменяемые.
...настолько же быстрый, простой, надежный, контролируемый, легко тестируемый и поддерживаемый!
Самый демагогичный на сегодняшгий день вопрос, на который существует миллион ответов и ни одного, признанного верным. В вашем случае не будет концептуально хуже, если вы соберете обратно все *-subsystem в единый System и запакуете все в единый .jar без лишнего геморроя.
Если есть определенный функционал, который как пятое колесо в телеге, и есть реальная необходимость вынести его в отдельный сервис -- выносите, кто вам мешает? Но бездумно следовать девопс религии и пилить все, к чему только можно прикрутить API -- это попахивает идиократией. Извините за присущую резкость.
Наверное единственный оставшийся серьезный юзер у свинга -- это Jetbrains :) Он же по совместительству и основной контрибьютор.
Вообще нынче модно делать локальные веб приложения и паковать их в электрон. Если нужна обязательно Java, взять какой-нибудь Vaadin или Kotlin Multiplatform...
У меня есть даже лучше вопрос: чем микросервисная архитектура принципиально отличается от сервисной (SOA), расхайпованной 10-15 лет назад? У меня только один ответ -- это то же самое, только собранное на коленке, реализованное на другом стеке, и игнорирующее всякие индустриальные стандарты.
К сожалению, центральным понятием в микросервисной архитектуре на сегодняшний день являются именно все эти ваши докеры, кубернетисы, клауды, эджайлы, девопсы и прочие религиозные атрибуты. Сомневаюсь, что Мартин Фаулер в 2012 году имел именно это ввиду, говоря о слабой связанности.
...а это значит, что ввиду отсутствия ACID у вас сразу теряется консистентность операций, и вам необходимо дополнительно искать искусственные способы обеспечения целостности данных, плюс по каждому предоставить доказательство, что в каждом данном сценарии целостность соблюдается. И на это будет тратиться львиная доля усилий архитектора решения.
Это наверное в какой-то параллельной вселенной. Бизнес до сих пор требует одну большую кнопку: "сгенерировать прибыль" или "сделать красиво". На элементарные вопросы типа "что делать, если случиться то-то..." у бизнеса один ответ -- "мне лень об этом думать", или "ну вы там придумайте сами что-нибудь, я же плачу вам за это". Вся аналитика, которую я видел за свою карьеру в лучшем случае покрывает наивный самый оптимистичный сценарий, оставляя за кадром кучу кейсов. И что-то я не заметил, что ситуация сильно поменалась.
Тут можно добавить еще и организационный мотив: если над компонентом трудится более 5 разрабочиков, становится очень сложным координировать их работу, слияние веток, релизный цикл и т.д. Поэтому при возможности лучше разделить функциональные части и на каждую назначить свою небольшую команду.
И как это соответствует принципу слабой связанности иметь единый реестр сервисов? Это что-то типа UDDI из SOA?
Да, после пандемии рынок сильно меняется -- очень много офферов от зарубежных компаний. Однако, компании тоже не дураки -- предлагают условия исходя из твоего ПМЖ, особенно если компания имеет представительство в стране.
С налогами по законодательству, если проживаешь больше полугода, то должен платить налоги в месте проживания. Налоговая будет следить за деньгами, поступающими на счет в местном банке, с которых нужно будет декларировать прибыль. Если есть резиденство с разрешением на работу, то можно оформиться как ЧП (autonomo), сделать себе официальную зарплату, и государство будет доить тебя конскими налогами при минимальной отдаче.
Тем не менее в IT одни из самых низких зарплат по Европе. Выше установленной ставки нигде не прыгнуть, работай ты хоть за семерых. Поэтому большинство испанцев мечтает устроиться в большие компании, которые помимо стабильности могут предложить некоторые социальные бонусы и не сильно напрягать с обязанностями. С другой стороны низкие зарплаты в IT компенсируются низкой производительностью и качеством специалистов, т.к. реально хорошие профессионалы легко эмигрируют в другие страны, где их труд оценивается в выше 2-5 раз.
/sarcasm mode/ Наше дело маленькое: сказали светильник -- значит светильник. Верим, вопросов не задаем.
У меня одного впечатление, что способ изготовления этих артефактов больше похож на лепку, нежели на резьбу? Нет характерных резких граней, все переходы плавные, плоские части как-будто согнуты внутрь...
Возможно это так в других областях индустрии, но в IT все имеет свою негативную специфику. Во-первых, здесь технологии не развиваются, а по большей части деградируют: каждые несколько лет стек полностью заменяется на более примитивный и ресурсоемкий, компенсируя это ростом вычислительной мощности. При этом при кажущейся простоте и доступности новых средств разработки, а также более низком пороге вхождения, сама разработка и поддержка продукта никак не становится проще или дешевле.
Именно те, кто создает технологию и раздувают хайп вокруг нее. Более того, сама технология создается ради хайпа, а не наоборот. Сегодня все модные тенденции идут от гигантов индустрии, которые фактически диктуют моду и технологии. И делают это с конкретной коммерческой целью -- продвижение своих облачных платформ. А мода в свою очередь бездумно подхватывается адептами и создает эффект снежного кома.
Ценность на 100% определяет маркетинг, задача которого максимально оправдать завышенную цену товара или сервиса при минимальных издержках на производство оного. Успешный товар -- это не лучший или качественный, а наиболее коммерчески оправданный. Конечные же потребители всегда ограниченны, а зачастую безальтернативны в своем выборе, а посему зачастую вынуждены хавать и плеваться разрекламированным низкокачественным ширпотребом.
Наконец-то человек со здоровой критикой. Подписываюсь под каждым пунктом! Блокчейн ведет к мировому энергетическому кризису. Material design - примитивное некрасивое и неудобное говнище: кнопка должна быть похожа на кнопку, а не быть раскрашеной полоской.
По поводу Agile: из изначально правильной идеи не мешать разработчику делать до конца свое дело сколотили целую религию с адептами, клириками и евангелистами, позиционируя ее как благодать и серебряную пулю от всех напастей. А на еретические претензии типа "вот мы внедрили эджайл, но сани быстрее не едут" всегда осаждают, что эджайл у вас неправильный, сами вы постоянно грешите и потому невидать вам благодати.
С DevOps-ом та же ситуация. Да, неплохо бы если разработчик понимал всю цепочку доставки и выполнения их кода. Однако это быстро переросло в целый фетиш из паравоза тулзов, где девопсеры меряются ЧСВ у кого их больше задействовано в проекте. И чем их больше, тем весомее становиться роль девопсера в проекте, при всем при том, что все это никак не добавляет value к самому проекту.
Я бы еще к хейту добавил Микросервисы. Распили свой монолит на микросервисы и будет тебе счастье! На самом деле получаешь лишь геморрой с кодовой базой, деплойментом, сборкой, координацией изменений и пр. А самый лютый дебилизм -- это неосознанный отказ от транзакций и ACID. То есть консистентность данных, которая шла из коробки, теперь заменяется на саги и прочие неработающие велосипеды. К сожалению, на сегодняшний день уже мало кто вообще понимает концепт транзакций.
Я думаю самый главный хейт, который лежит в основе всех новых IT-веяний -- это Культ Карго, религиозное мышление, отсутствие элементарной критики и постоянный поиск панацеи от всех проблем и серебряной пули от всех напастей. Поэтому очередной распиаренный термин быстро подхватывается миллионами и становится божественным откровением. То, что он имеет все признаки религии вы можете убедиться например по неаргументированным нападкам адептов в коментариях, сразу же переходящих на личности. Настоящий айтишник всегда должен критически относиться к своим средствам и методам разработки, уметь ими пользоваться, понимать их преимущества и недостатки, и оценивать их исключительно с позиции личной пользы.
А все потому что не надо быть швейцарким ножом, ставя в приоритет количество фич над удобством и безопасностью.
А ничего удивительного. В Logback мы внезапно столкнулись с багом, который спровоцировал почти детективную историю поиска отказа в системе. Баг стоит в трекере ещё с 2014 года, но до сих пор не закрыт.
И да, и нет. Во-первых, автоматические инструменты достаточно "костные" -- вылезает стопицот случаев, где реально такое написание оправдано, однако нет возможности объяснить это аналайзеру. А во-вторых, они реагируют лишь на примитивные случаи подобно потенциальным ошибкам, оставляя за кадром более глобальные вещи как общий дизайн, стиль и читаемость кода, что например для меня является гораздо более важным аспектом, нежели наличие потенциальных ошибок, которые легко покрываются тестами.
Круто! У меня были подозрения, что весь процесс не достигает полного паралелизма выполнения либо по причине ограничения пулов, либо сам сайт не дает делать 100 запросов с одного хоста и ставит их в очередь. Интересно было бы посмотреть действительно ли все выполняется параллельно.
Насчет долгого SSL хендшейка есть предположение, что на сокете не выставлен TCP_NODELAY, однако я не нашел как его можно сконфигурировать в Java 9 HttpClient -- там настройки сильно ограничены.
Первое, что бросается в глаза -- это кондовый способ замера производительности:
и что самое основное -- отсутствие предварительного "прогрева". Это является причиной почему:
То есть то, что аффтар тут намерял -- это работа http-клиента + класс лоадинг + динамическая оптимизация + создание новых статических инстансов -- т.е. сразу работу половины JVM.
Во-вторых,
CompletableFuture.supplyAsync()использует дефолтный ForkJoinPool.commonPool(), поведение которого определяется внешними параметрами, железом и вендором Java-рантайма. В большинстве случаев размер дефолтного пула выбирается равеным количеству CPU core. То есть для 100 параллельных запросов из блокирующих операций использовалось всего 4-8 треда.Далее:
Формально работа HttpClient принципиально ничем не отличается от примера выше, за исключением того, что вместо ForkJoinPool.commonPool() используется java.util.concurrent.Executors.newCachedThreadPool(). В итоге то, что замерил аффтар -- это время выполнения запросов + время создания новых тредов для параллельной обработки. Поэтому если бы автор повторил тест сразу после первого прогона -- он был бы "сильно потрясен, весьма удивлен и крайне обескуражен".
Ну да, особенно если искусственно навтыкать цепочку ненужных преобразований :)))
Потому что у аффтара изначально таковой была задача.
Ну то есть все рассчитано на то, что все 105 запросов и ответов должны обязательно поместиться в память, что никто не будет скачивать и закачивать гигабайтные запросы/ответы, что все данные для отправки уже доступны во время вызова, и что каждый из 105 обработчиков отработает моментально, чтобы никаки не задерживать других.
Не в Java, а конкретно в Java 11 HttpClient. В TCP стеке для отсылки требуется: открыть сокет, записать запрос и прочитать ответ. В классической синхронной модели все три операции блокирующие, и поэтому на каждый запрос требуется тред, который их последовательно обрабатывает, учитывая что открытие сокета немоментально, буфер данных для отсылки ограничен и может быть много меньше размера запроса, ответ также может приходить порциями, а обработка никак не должна препятствовать и интерферировать с другими запросами.
А вот в Java как раз есть способ реализовать низкоуровнево полную асинхронную реализацию, используя Selectors и Channels. Кроме того, есть прекрасный стек Netty в котором это уже реализовано, равно как и куча надстроек к нему, напр. полностью асинхронный https://github.com/timboudreau/netty-http-client Ну и напоследок стоит упомянуть, что начиная с версии 17 в JVM добавлен project Loom, с виртуальными тредами, которые позволяют использовать классическую синхронную модель, не заботясь о масштабировании, и которая "под капотом" выполняется асинхронно и неблокирующе. Только реальных тредов будет не один, а сколько душе угодно.
P.S. забыл упомянуть: www.bbc.com наверняка контролирует количество параллельных запросов с одного хоста, поэтому все тесты со 100 реквестами можно сразу выкинуть в корзину.
5. На порядки меньше уровень миграции как внешней, так и внутренней.
Если нужен замороченный flow с одновременной поддержкой старой и новой моделей:
создаете новую таблицу
мигрируете данные со старой
синхронизацию изменений реализуете при помощи триггеров
следующий апдейт дропает старую таблу и триггеры
Легко заметить, что противоречит:
Строгую математическую семантику соблюдает Objects.equals(). И именно его нужно было использовать с самого начала для оператора "==". Однако создателям Java казалось очень важным каждый обращать внимание пользователей на то, как они реализовали equals(), и что сравнивать строки при помощи "==" в их языке хоть и можно, но будет неправильно. Даром что ссылочное сравнение используется в одном случае из ста. Но уж теперь ничего не поделаешь.