Первая моя статья на Хабре за долгое время. Эта штука про Джаву, Скалу и IDE одновременно: это плагин для Идеи, который позволяет убежать от ужасов использования Hadoop, Spark и Zeppelin.
https://habr.com/ru/company/JetBrains/blog/517406/
https://habr.com/ru/company/JetBrains/blog/517406/
Хабр
Big Data Tools EAP 10: SSH-туннели, фильтрация приложений, пользовательские модули и многое другое
Только что вышла очередная версия плагина Big Data Tools — плагина для IntelliJ IDEA Ultimate, DataGrip и PyCharm, который обеспечивает интеграцию с Hadoop и Spark, позволяет редактировать и запускать...
Запилил ролик о том, как легко и просто написать простейший плагин для IntelliJ IDEA
https://www.youtube.com/watch?v=e1WexbV0veU
https://www.youtube.com/watch?v=e1WexbV0veU
YouTube
Как написать плагин для IntelliJ IDEA за пару минут
Многие боятся писать плагины для IDE потому, что кто-то их напугал, что это безумно сложно. Это не совсем так: простые плагины для себя написать вполне возможно.
В этом видео мы сделаем так, что при нажатии на Ctrl+T весь текст, выделенный в редакторе отправляется…
В этом видео мы сделаем так, что при нажатии на Ctrl+T весь текст, выделенный в редакторе отправляется…
Записал ролик про последнее обновление плагина Big Data Tools для IntelliJ IDEA, который разрабатывает на работе моя команда
Это мой превый ролик на английском языке. Промучался два дня фуллтайм. Это жесть. Единственная надежда на то, что скилл не пропьёшь, и каждый следующий будет немного быстрее и проще.
https://www.youtube.com/watch?v=x0vsLmN4FkM
Это мой превый ролик на английском языке. Промучался два дня фуллтайм. Это жесть. Единственная надежда на то, что скилл не пропьёшь, и каждый следующий будет немного быстрее и проще.
https://www.youtube.com/watch?v=x0vsLmN4FkM
YouTube
Big Data Tools EAP 10
I am pleased to announce that EAP 10 of the Big Data Tools plugin for IntelliJ IDEA Ultimate is finally out!Download the IntelliJ IDEA Ultimate:https://www.j...
Написал очень специфическую статью, которая может быть полезна разработчикам, использующим Zeppelin
Это пост про ZTools — довольно малоизвестный инструментарий, живущий в виде репозитория на GitHub компании JetBrains, который позволяет вытягивать нужную информацию из Zeppelin, даже если её нет в API. Весь код "серверной" части находится в открытом доступе под лицензией Apache License 2.0. Примерно 90% кода написано на Scala, а остальное — на Java.
https://habr.com/ru/company/JetBrains/blog/521030/
Это пост про ZTools — довольно малоизвестный инструментарий, живущий в виде репозитория на GitHub компании JetBrains, который позволяет вытягивать нужную информацию из Zeppelin, даже если её нет в API. Весь код "серверной" части находится в открытом доступе под лицензией Apache License 2.0. Примерно 90% кода написано на Scala, а остальное — на Java.
https://habr.com/ru/company/JetBrains/blog/521030/
Хабр
ZTools для Apache Zeppelin
Zeppelin — это интерактивный блокнот, очень полюбившийся дата-инженерам. Он умеет работать со Spark и отлично подходит для интерактивного анализа данных. Проект...
Forwarded from Маковкин (Иван Маковкин)
Nvidia выкатила алгоритм сжатия трафика для видеоконференций - в 10 раз
https://syncedreview.com/2020/12/02/nvidia-neural-talking-head-synthesis-makes-video-conferencing-10x-more-bandwidth-efficient/
"The approach dramatically reduces bandwidth requirements by sending only a keypoint representation [of faces] and reconstructing the source video on the receiver side with the help of generative adversarial networks (GANs) to synthesize the talking heads"
Как сделано?
"The proposed system first extracts appearance features and 3D canonical keypoints from the source image. These are used to compute source keypoints and generate keypoints for the synthesis videos. The system decomposes the keypoint representations into person-specific canonical keypoints and motion-related transformations, using the 3D keypoints to model both facial expressions and geometric signature to create a talking-head synthesis video with expression and head pose information. The rendering technique can also synthesize associated accessories in the source video, such as eyeglasses, hats, and scarves.
...
The researchers included a pretrained face recognition network and a pretrained head pose estimator to ensure that head poses and angles etc. in the generated images are accurate and visually acceptable."
https://syncedreview.com/2020/12/02/nvidia-neural-talking-head-synthesis-makes-video-conferencing-10x-more-bandwidth-efficient/
"The approach dramatically reduces bandwidth requirements by sending only a keypoint representation [of faces] and reconstructing the source video on the receiver side with the help of generative adversarial networks (GANs) to synthesize the talking heads"
Как сделано?
"The proposed system first extracts appearance features and 3D canonical keypoints from the source image. These are used to compute source keypoints and generate keypoints for the synthesis videos. The system decomposes the keypoint representations into person-specific canonical keypoints and motion-related transformations, using the 3D keypoints to model both facial expressions and geometric signature to create a talking-head synthesis video with expression and head pose information. The rendering technique can also synthesize associated accessories in the source video, such as eyeglasses, hats, and scarves.
...
The researchers included a pretrained face recognition network and a pretrained head pose estimator to ensure that head poses and angles etc. in the generated images are accurate and visually acceptable."
Synced
NVIDIA Neural Talking-Head Synthesis Makes Video Conferencing 10x More Bandwidth Efficient
The approach dramatically reduces bandwidth requirements by sending only a keypoint representation and reconstructing the source video on the receiver side with the help of generative adversarial networks to synthesize the talking heads.
Опять скрипит потертое седло!
Веду второй трек конференции SmartData.
Наконец-то докладчик говорит свой доклад и можно снять фоточку
Веду второй трек конференции SmartData.
Наконец-то докладчик говорит свой доклад и можно снять фоточку
Сейчас после конференции дошел до кровати, лег, полежал немного. Хочу сходить на кухню пожрать.
Резко встаю - и как будто на секунду залипаю как в киселе, а дальше снова легко. Смотрю себе на руки - и не вижу их! Ни рук, ни тела, ничего нет.
Думаю - что за фигня, я наверное отравился или заболел!
Иду на кухню, сворачиваю по коридору - та же фигня! Вначале как в киселе и тело видно, потом снова ничего нет. Даже не прозрачный - ничего.
Дошел до кухни, вынимаю пиццу из коробки - всё то же самое. Мне, прямо скажем, поплохело.
Вроде ночь уже, но я знаю, что в офисе кто-то есть. Одеваюсь, перехожу дорогу, и нахожу на рабочем месте нашего бога видеоинженерии - Артема Никонова. Рассказываю ему проблему - так и так, не вижу тела.
Артем говорит: "так а что ты хотел, это известная проблема. Самые важные события, "настоящие" лежат в I-фреймах, а всё что посредине - кодируется нейросеткой с частотой не ниже чем фреймрейт в DLSS, и промежуточные результаты складывает в B-фреймы. Там кроме B-фреймов ничего нет.
А тормоза случаются, когда сетка пытается отследить, что ты пиццу начал жрать или что-то такое. Надо квадратик вокруг тебя нарисовать, протречить его."
"Так" - говорю я - "так если всё считается с частотой фреймрейта, то почему меня нет посредине?"
"Ты у нас" - говорит Артем - "очень большой человек, много пиццы жрешь, поэтому не успеваем тебя обсчиать. Но нельзя же мир от этого останавливать, поэтому мы тебя по границам спайков в сложности просто не рисуем. Ты у нас отдельным слоем, это легко."
"Блядь" - говорю - "если первый я в первом I-фрейме и второй я во втором-айфрейме ничем вобще не соединены графически, ни единым вектором, то каким образом понять, что второй "я" - это всё ещё я, а не совсем другой человек?!"
"Олег, какой ещё "ты", очнись! Там только одни кадры, там больше ничего нету!"
===
Я проснулся и пошел жрать пиццу на кухню. Больше ничего не тормозит и тело всегда видно.
Одно меня беспокоит - как часто на самом деле стоят ключевые кадры и сколько на это тратится ресурсов. Ведь на самом деле в мире нет никого, там только одни кадры.
Надеюсь, там на верху нет никакого "райского Амазона", и мне потом не выставят счёт за весь потраченный GPU. Возможно, библейский грех "чревоугодие" имеет под собой куда более понятые и меркантильные мотивы - экономия денег на счёте облачного провайдера.
Резко встаю - и как будто на секунду залипаю как в киселе, а дальше снова легко. Смотрю себе на руки - и не вижу их! Ни рук, ни тела, ничего нет.
Думаю - что за фигня, я наверное отравился или заболел!
Иду на кухню, сворачиваю по коридору - та же фигня! Вначале как в киселе и тело видно, потом снова ничего нет. Даже не прозрачный - ничего.
Дошел до кухни, вынимаю пиццу из коробки - всё то же самое. Мне, прямо скажем, поплохело.
Вроде ночь уже, но я знаю, что в офисе кто-то есть. Одеваюсь, перехожу дорогу, и нахожу на рабочем месте нашего бога видеоинженерии - Артема Никонова. Рассказываю ему проблему - так и так, не вижу тела.
Артем говорит: "так а что ты хотел, это известная проблема. Самые важные события, "настоящие" лежат в I-фреймах, а всё что посредине - кодируется нейросеткой с частотой не ниже чем фреймрейт в DLSS, и промежуточные результаты складывает в B-фреймы. Там кроме B-фреймов ничего нет.
А тормоза случаются, когда сетка пытается отследить, что ты пиццу начал жрать или что-то такое. Надо квадратик вокруг тебя нарисовать, протречить его."
"Так" - говорю я - "так если всё считается с частотой фреймрейта, то почему меня нет посредине?"
"Ты у нас" - говорит Артем - "очень большой человек, много пиццы жрешь, поэтому не успеваем тебя обсчиать. Но нельзя же мир от этого останавливать, поэтому мы тебя по границам спайков в сложности просто не рисуем. Ты у нас отдельным слоем, это легко."
"Блядь" - говорю - "если первый я в первом I-фрейме и второй я во втором-айфрейме ничем вобще не соединены графически, ни единым вектором, то каким образом понять, что второй "я" - это всё ещё я, а не совсем другой человек?!"
"Олег, какой ещё "ты", очнись! Там только одни кадры, там больше ничего нету!"
===
Я проснулся и пошел жрать пиццу на кухню. Больше ничего не тормозит и тело всегда видно.
Одно меня беспокоит - как часто на самом деле стоят ключевые кадры и сколько на это тратится ресурсов. Ведь на самом деле в мире нет никого, там только одни кадры.
Надеюсь, там на верху нет никакого "райского Амазона", и мне потом не выставят счёт за весь потраченный GPU. Возможно, библейский грех "чревоугодие" имеет под собой куда более понятые и меркантильные мотивы - экономия денег на счёте облачного провайдера.
Начал разбираться в WebRTC. Пока что наблюдение за готовыми проектами - всё работает через жопу. Рвется связь, случаются дикие вещи вроде сплитбрейна, видео не работает в Сафари (а в других браузерах на iOS WebRTC вообще невозможен), и так далее, и тому подобное.
Вот ругаются на забагованность Киберпанка. А между тем, главная проблема музыки в России известна, и производители контента адаптируются к этому
Вряд ли у кого-то нет такого постоянного скребущего ощущения, что "еще неделя - и сделаем". И оно может длиться месяцами, годами. У меня на работе (на любой из всех что были) так было примерно постоянно - релизы сдвигались, сдвигались, сдвигались.
И у Киберпанка релиз сдвигался, сдвигался, сдвигался. И даже в самый последний момент, очевидно, им оставалось всего недельку-то доделать. И это нормально, у всех так. Что, создатели Киберпанка - не люди что ли?
Собственно, поэтому и придумали фреймворки со спринтами внутри (например, scrum). Планируем разработку на 2 недели или около того - один "спринт". После спринта разработчики останавливаются и смотрят на сделанное как на что-то чужое, самостоятельное и завершенное. И планируют следующий спринт как нечто совершенно новое, с чистого листа.
Имхо, это очень крутая психологическая установка. Можно например, считать каждый новый день своей жизни отдельным спринтом. Или каждый час. Или каждую таску в todo-листе. Насколько знаю, спортсменов учат делать такую перезагрузку восприятия каждую составную часть матча например, в баскетболе.
Проблема с играми типа Киберпанка в том, что широкая общественность почему-то не очень в курсе "аджайл" отношения к жизни. Им подавай фиксированную дату релиза, и чтобы к этой фиксированной дате вся игра целиком была готова. Но это же невозможно, и в результате раз за разом получается говно.
Не везде так, например, MMO и другие онлайн игры никогда не делаются до конца, и этот тренд был еще у WoW на старте. В мире фильмов, сериалы не снимаются до конца, и создатели зачастую не знают, что будет в следующем сезоне (а у особых экстрималов нет плана даже до конца этого сезона - седелали две серии и уже хорошо).
Было бы неплохо, если бы сюжетные игры тоже делали в формате сериала. Ну например, Telltale и делали, но куда-то сгинули. Life is Strange, опять же.
Но ведь и Киберпанк можно было открывать кусочками, например вначале выкатить один только пролог, который довольно неплохо работает.
И не было бы всех этих толп нытиков, у которых в зеркале иногда прическа не рисуется (да, у меня тоже иногда не рисуется, и что, это на что-то влияет?). И можно было бы использовать фидбек от сообщества, которое выступило бы в роли тестировщиков.
Вряд ли у кого-то нет такого постоянного скребущего ощущения, что "еще неделя - и сделаем". И оно может длиться месяцами, годами. У меня на работе (на любой из всех что были) так было примерно постоянно - релизы сдвигались, сдвигались, сдвигались.
И у Киберпанка релиз сдвигался, сдвигался, сдвигался. И даже в самый последний момент, очевидно, им оставалось всего недельку-то доделать. И это нормально, у всех так. Что, создатели Киберпанка - не люди что ли?
Собственно, поэтому и придумали фреймворки со спринтами внутри (например, scrum). Планируем разработку на 2 недели или около того - один "спринт". После спринта разработчики останавливаются и смотрят на сделанное как на что-то чужое, самостоятельное и завершенное. И планируют следующий спринт как нечто совершенно новое, с чистого листа.
Имхо, это очень крутая психологическая установка. Можно например, считать каждый новый день своей жизни отдельным спринтом. Или каждый час. Или каждую таску в todo-листе. Насколько знаю, спортсменов учат делать такую перезагрузку восприятия каждую составную часть матча например, в баскетболе.
Проблема с играми типа Киберпанка в том, что широкая общественность почему-то не очень в курсе "аджайл" отношения к жизни. Им подавай фиксированную дату релиза, и чтобы к этой фиксированной дате вся игра целиком была готова. Но это же невозможно, и в результате раз за разом получается говно.
Не везде так, например, MMO и другие онлайн игры никогда не делаются до конца, и этот тренд был еще у WoW на старте. В мире фильмов, сериалы не снимаются до конца, и создатели зачастую не знают, что будет в следующем сезоне (а у особых экстрималов нет плана даже до конца этого сезона - седелали две серии и уже хорошо).
Было бы неплохо, если бы сюжетные игры тоже делали в формате сериала. Ну например, Telltale и делали, но куда-то сгинули. Life is Strange, опять же.
Но ведь и Киберпанк можно было открывать кусочками, например вначале выкатить один только пролог, который довольно неплохо работает.
И не было бы всех этих толп нытиков, у которых в зеркале иногда прическа не рисуется (да, у меня тоже иногда не рисуется, и что, это на что-то влияет?). И можно было бы использовать фидбек от сообщества, которое выступило бы в роли тестировщиков.
К сожалению, в реальной игрушке WebRTC - это только часть, хотя и значительная. Похоже, пока не сделаешь платформу для экспериментов, о звуке можно забыть.
А для платформы основная часть - это объектная система и неткод синхронизации. Не так важно, как и каким движком рисуются участники, как синхронизация их местоположения на карте.
Если кому-то это интересно, могу посоветовать вот это видео с GDC трехлетней давности. Конечно, механика из Overwatch - это из пушки по воробьям для более простых применений, но там есть масса интересных идей.
Кстати, заметьте, какой крутой работодатель Blizzard. Они позволили пойти и рассказать обо всем этом наружу. Создатели мобильных донатных дрочилен из славного града Новосибирска скорее бы удавились насмерть, вывезли этого чувака в ближайший тёмный лес и заставили копать себе могилу, чем позволили вот так открыто рассказывать про их интеллектуальную собственность (c)(r)(tm)
https://www.youtube.com/watch?v=W3aieHjyNvw
А для платформы основная часть - это объектная система и неткод синхронизации. Не так важно, как и каким движком рисуются участники, как синхронизация их местоположения на карте.
Если кому-то это интересно, могу посоветовать вот это видео с GDC трехлетней давности. Конечно, механика из Overwatch - это из пушки по воробьям для более простых применений, но там есть масса интересных идей.
Кстати, заметьте, какой крутой работодатель Blizzard. Они позволили пойти и рассказать обо всем этом наружу. Создатели мобильных донатных дрочилен из славного града Новосибирска скорее бы удавились насмерть, вывезли этого чувака в ближайший тёмный лес и заставили копать себе могилу, чем позволили вот так открыто рассказывать про их интеллектуальную собственность (c)(r)(tm)
https://www.youtube.com/watch?v=W3aieHjyNvw
YouTube
Overwatch Gameplay Architecture and Netcode
In this 2017 GDC session, Blizzard's Timothy Ford explains how Overwatch uses the Entity Component System (ECS) architecture to create a rich variety of layered gameplay.
Register for GDC: https://ubm.io/2yWXW38
Join the GDC mailing list: http://www.gd…
Register for GDC: https://ubm.io/2yWXW38
Join the GDC mailing list: http://www.gd…
Кроме того, чтобы чесать языком в телеге, я имею счастье работать в команде Big Data Tools. Не могу не сообщить, что только что вышло новое крутое обновление, приглашаю попробовать.
Привезли Питон, баги напротив - увезли. Работает глобальный поиск по ноутбукам. Питон очень-очень сырой, но в следующих релизах (возможно) будет лучше.
https://habr.com/ru/company/JetBrains/blog/533370/
Привезли Питон, баги напротив - увезли. Работает глобальный поиск по ноутбукам. Питон очень-очень сырой, но в следующих релизах (возможно) будет лучше.
https://habr.com/ru/company/JetBrains/blog/533370/
Хабр
Big Data Tools EAP 12: экспериментальная поддержка Python, поиск по ноутбукам в Zeppelin
Только что вышло очередное обновление EAP 12 для плагина под названием Big Data Tools, доступного для установки в IntelliJ IDEA Ultimate, PyCharm Professional и...
Удручающее про события
Часть событий пользователь ожидает увидеть мгновенно: например, игрок выстрелил из хитскан пистолета по врагу. Но выстрел - это событие, и это событие ложится в общую очередь в самый конец. Чем больше событий, тем медленней очередь дойдёт до обработки этого конкретного, и получается, что от скорости железа на сервере и клиенте зависит качество происходящего. Это еще неинтересная часть.
Интересная часть, что таких событий может сгенериться 100500 в секунду, и всё это ощущается как куча мусора. Во-первых, ни в Java (сервер) ни в JavaScript (клиент) нету легких дата-классов, и каждое событие - это самый настоящий долбаный объект со всеми гарантиями. Во-вторых, вся эта орава оседает на сборщике мусора, который работает совсем даже не мгновенно, ну и жрет оперативку. В Java и JS нельзя просто взять и удалить объект, когда ты понимаешь, что его жизненный путь закончен. Ты можешь только намекнуть рантайму, а уж как он поймет твои намеки - зависит от тысячи и одной причины.
А тут у нас время жизни очевидное - длина кванта симуляции * размер истории. Кажется, тащить мусор дальше, и потом устраивать stop the world чтобы его вынести - полнейшее расточительство.
Допустим, для электронного магазина это вполне нормально. Даже для банка. Много ли банков проводят болше чем сотню транзакций в секунду одновременно? Если что-то у них тормозит, они могут просто закупить побольше серверов и всё. А что, имеют возможность, с >100 транзакциями в секунду-то. Но маленькая игрушка - это не сириус бизнес, человек не может закупить себе ещё десять ПК и три новый айфона. А нагрузки из событий она генерит дай боже.
И вот возникает дикая идея - а может на хрен эту Java и JS, а писать этот код на C++. Всё равно, обработка событий как мутации глобального состояния - это не "системный код" , это просто какое-то подмножество языка, оно не обязано быть сложным. Я не умею писать на C++, но уж "field = value" я написать могу в любом случае.
Но это не поможет на фронтенде. Там только JS и всё. Есть еще webassembly, но это какой-то ад, лучше туда не смотреть даже пока Кирилл не выпустит на публику свой движок.
Можно еще не выпендриваться, а использовать прямые вызовы методов вместо объектов-событий, но тогда код превращается в говно. Или можно использовать преаллоцированные пулы объектов, но тогда писать это очень сложно, меня к такому жизнь не готовила.
Получается, пользователь в браузере, исходя из устройства современного мира, обязан страдать и видеть, как всё лагает, срабатывает не совсем вовремя и жрёт оперативную память. Судьба такая, ничего не поделаешь.
Часть событий пользователь ожидает увидеть мгновенно: например, игрок выстрелил из хитскан пистолета по врагу. Но выстрел - это событие, и это событие ложится в общую очередь в самый конец. Чем больше событий, тем медленней очередь дойдёт до обработки этого конкретного, и получается, что от скорости железа на сервере и клиенте зависит качество происходящего. Это еще неинтересная часть.
Интересная часть, что таких событий может сгенериться 100500 в секунду, и всё это ощущается как куча мусора. Во-первых, ни в Java (сервер) ни в JavaScript (клиент) нету легких дата-классов, и каждое событие - это самый настоящий долбаный объект со всеми гарантиями. Во-вторых, вся эта орава оседает на сборщике мусора, который работает совсем даже не мгновенно, ну и жрет оперативку. В Java и JS нельзя просто взять и удалить объект, когда ты понимаешь, что его жизненный путь закончен. Ты можешь только намекнуть рантайму, а уж как он поймет твои намеки - зависит от тысячи и одной причины.
А тут у нас время жизни очевидное - длина кванта симуляции * размер истории. Кажется, тащить мусор дальше, и потом устраивать stop the world чтобы его вынести - полнейшее расточительство.
Допустим, для электронного магазина это вполне нормально. Даже для банка. Много ли банков проводят болше чем сотню транзакций в секунду одновременно? Если что-то у них тормозит, они могут просто закупить побольше серверов и всё. А что, имеют возможность, с >100 транзакциями в секунду-то. Но маленькая игрушка - это не сириус бизнес, человек не может закупить себе ещё десять ПК и три новый айфона. А нагрузки из событий она генерит дай боже.
И вот возникает дикая идея - а может на хрен эту Java и JS, а писать этот код на C++. Всё равно, обработка событий как мутации глобального состояния - это не "системный код" , это просто какое-то подмножество языка, оно не обязано быть сложным. Я не умею писать на C++, но уж "field = value" я написать могу в любом случае.
Но это не поможет на фронтенде. Там только JS и всё. Есть еще webassembly, но это какой-то ад, лучше туда не смотреть даже пока Кирилл не выпустит на публику свой движок.
Можно еще не выпендриваться, а использовать прямые вызовы методов вместо объектов-событий, но тогда код превращается в говно. Или можно использовать преаллоцированные пулы объектов, но тогда писать это очень сложно, меня к такому жизнь не готовила.
Получается, пользователь в браузере, исходя из устройства современного мира, обязан страдать и видеть, как всё лагает, срабатывает не совсем вовремя и жрёт оперативную память. Судьба такая, ничего не поделаешь.
Там HashiCorp выпустили Nomad. Это "архитектурно легковесная" замена Куберу. Кубер умеет всё в себе, а Номад - это один бинарник, который делегирует как можно больше функций другим продуктам HashiCorp (например, сервис дискавери делает Consul, а секреты хранит Vault).
https://www.nomadproject.io/
https://www.nomadproject.io/
Nomad | HashiCorp Developer
Explore Nomad product documentation, tutorials, and examples.
Стыдное признание - писал сегодня ручкой по бумаге, впервые за последние 15 лет.
Потому что надо рисовать диаграммки, в формате чего-то среднего между UML и комиксами.
Немного порисовал их в Визио сидя за компом и возненавидел всё на свете. Когда нет вообще никакого понимания, что ты собираешься нарисовать и как оно будет выгляедть - похоже, ручка лучше, чем Визио.
Пойду сейчас окончательно зашквариваться - куплю в книжном магазине несколько тетрадок и цветных ручек, буду писать и плакать, писать и плакать. Плакать потому, что бумажные заметки имеют все те же недостатки, по которым я не читаю бумажных книг.
Потому что надо рисовать диаграммки, в формате чего-то среднего между UML и комиксами.
Немного порисовал их в Визио сидя за компом и возненавидел всё на свете. Когда нет вообще никакого понимания, что ты собираешься нарисовать и как оно будет выгляедть - похоже, ручка лучше, чем Визио.
Пойду сейчас окончательно зашквариваться - куплю в книжном магазине несколько тетрадок и цветных ручек, буду писать и плакать, писать и плакать. Плакать потому, что бумажные заметки имеют все те же недостатки, по которым я не читаю бумажных книг.
То, что я называл для себя общим словом "Spring", потому что в Java-мире нет ничего лучше, во внешнем мире называется ECS - Entity Component System.
Системы - это всякие @Component (не считая репозиториев), энтити - это @Bean, стейт энтитей - это data transfer objects которые ты руками оформил как pojo. Каждая система точно так же на входе заявляет тупл зависимостей (@Autowired поля).
Так ведь можно рассказывать о Java какому-нибудь C++-нику, чтобы он меньше офигевал от набора сказанных жутких слов и меньше тебя ненавидел 🙂
Системы - это всякие @Component (не считая репозиториев), энтити - это @Bean, стейт энтитей - это data transfer objects которые ты руками оформил как pojo. Каждая система точно так же на входе заявляет тупл зависимостей (@Autowired поля).
Так ведь можно рассказывать о Java какому-нибудь C++-нику, чтобы он меньше офигевал от набора сказанных жутких слов и меньше тебя ненавидел 🙂
- Если вы заботитесь о своём пищеварении, мой добрый совет – не говорите за обедом о большевизме и о медицине. И – боже вас сохрани – не пишите до обеда на Java, JavaScript, Python и C++.
– Гм… Да но ведь других языков нет.
– Вот ни на каких и не пишите. Вы знаете, я произвёл 30 наблюдений у себя в клинике. И что же вы думаете? Поциенты, не пишущие на императивных языках, чувствуют себя превосходно. Те же, которых я специально заставлял писать тесты на Python, – теряли в весе.
– Гм… – с интересом отозвался тяпнутый, розовея от супа и вина.
– Мало этого. Пониженные коленные рефлексы, скверный аппетит, угнетённое состояние духа.
– Гм… Да но ведь других языков нет.
– Вот ни на каких и не пишите. Вы знаете, я произвёл 30 наблюдений у себя в клинике. И что же вы думаете? Поциенты, не пишущие на императивных языках, чувствуют себя превосходно. Те же, которых я специально заставлял писать тесты на Python, – теряли в весе.
– Гм… – с интересом отозвался тяпнутый, розовея от супа и вина.
– Мало этого. Пониженные коленные рефлексы, скверный аппетит, угнетённое состояние духа.