Большое спасибо за статью. Сейчас тоже в полный рост стоим перед выбором подсистемы кэширования. Пока в фаворе Ignite, собственно у нас на нём больше чем один проект уже, но в сторону Redis тоже посматриваем. Вы их случайно не сравнивали "углублённо"? А то про возможности в статье есть но текстом, а вот например результатов тестирования производительность / объём потребляемой памяти нет... А хочется... Потому что не хочется пилить этот стенд самим :)
Ходить и смотреть глазами я и сам могу :). Но время от времени хочется (и нужно) почитать "роман", особенно при анализе PR / MR, чтобы не держать контекст в голове
Нужно вообще запрещать вывод любых уведомлений на экран заблокированного телефона. Потому как уже есть реальные атаки, если правильно помню нужен только номер телефона жертвы и её же аппарат, на котором можно читать уведомления. Заблокированный годится.
О да! Особенно в связке с Lombok. Не далее как вчера - перестало собираться приложение. Ломбок не ломбочит, билдеры не найдены, 100 однотипных ошибок maven. Внятного сообщения об ошибке - нет. Стал разбираться, что менял. Оказалось - прибил одно поле, которое было явно прописано в mapper-е. В нём самом удалить забыл, это же просто аннотация со строковыми полями. MapStruct на этом предположительно молча падал, после чего не запускался следующий annotation processor. Нашёл только в логе ребилда в IDEA, по паттерну Unknown property .+ in result type, а там и догадался. Минус час жизни.
Всё хорошо в меру. Был у нас разработчик, который обожал разрезать имплементацию на минимальные кусочки, кусочки разложить по иерархиям, снабдить интерфейсами и припудрить Parameter Object, потому что иначе контекст вычислений не передать... И каждый раз, чтобы понять по логу что конкретно пошло не так, нужно было в голове всё это собирать. Потому что глядя на код программы - невозможно понять, при каких условиях какой кусочек кода будет использован. Там ещё и карта Command была до кучи, со строковыми ключами, если правильно помню. Я вот последнее время вообще начал мечтать, чтобы IDEA научилась на место вызова функции рендерить её код, чтобы можно было посмотреть весь контекст выполнения не прыгая по десяти файлам. Ну вроде как рефакторинг Extract method, только с точностью до наоборот, и только чтобы посмотреть. А в случае виртуальной функции - да, рендерить вот тот switch по необходимости
Виртуальные функции. В Java в явном виде их нет, но под капотом именно оно. Был где-то тест, где сравнивали с switch, последний работал ощутимо быстрее. Впрочем, зависит от того, в чём приложение проводит основное время. Где то и Optional имеет смысл выкидывать, потому что сравнение c null - чуть быстрее. Любой инструмент короче с умом применять нужно.
Ну вот я начну... Сделали сначала всё на классах. Не без иерархий на 5+ элементов, но там доменная модель не самая простая. 1С короче пытаемся написать, в своей предметной области естественно. Потом выяснилось, что один класс тащит две (три и больше) обязанностей. Но описывает один объект реального мира, просто с разных сторон. Можно конечно распилить на мелкие классы и каждый в свою таблицу. С учётом полиморфных ссылок на него из других сущностей - как раз появится эта связка в БД 1:1. Пока вот пытаемся выделять мелкие интерфейсы (и класс будет реализовывать несколько таких), а где нужно - использовать их в качестве параметров. Ну и куча мест, где класс должен реализовать строго один интерфейс, если он (класс) достаточно мелкий. А глобально получим некоторый бардак - ненавижу в параметрах функций классы и интерфейсы вперемешку. Поэтому наверно будем реализовать эту вашу... бест практис..., вот
И на одном номере телефона неожиданно могут оказаться пять человек (у которых он основной контактный) и две конторы, у которых он рабочий. Вполне себе кейс в кредитном антифроде
не создает проблем с репликацией и резервированием БД из-за большого объема данных
Тут или картинки нам жизненно важны для бизнеса (и тогда пофиг на сложности с репликацией, она и так, и так будет), или их можно достаточно безболезненно потерять - и тогда пожалуйста храни на shared storage. Хоть файлами, главное чтобы inode не кончились. Потому что добавление +1 решения для хранения картинок потребует железа для этого решения, репликации для этого решения, поддержки этого решения, мониторингу этого решения, и ещё вероятно распределённых транзакций. А, ну ещё чтобы бэкапы не разъехались, когда база у нас в статусе на пять часов утра вчера, а картинки в статусе на cемь тоже вчера, т.е. там есть то, о чем БД не в курсе. Наоборот - веселее...
+1 предложение - в принципе, даже на неисправном канате будет некоторое соотношение "нормальных" к "повреждённым" участкам. Соответственно, можно посчитать количество / протяженность разных фрагментов, и выбрать хорошие участки (они должны быть одинаковые и их должно быть много) на конкретном канате в качестве базы для обучения. Если в стандарте написано ...не допускается... - то любое изменение геометрии - это warning. Если допускается до ... на ... - то можно эти самые отклонения посчитать, и уже принимать решение. Канат, который изначально плох настолько, что на нём соотношения хороших участков к плохим перевёрнуто - не допускать к обучению мнением человека. Так можно чуть ли не индивидуальную настройку делать под конкретную камеру и конкретный канат.
Есть ещё одна тонкость... маленькая. EA дешевле, чем Visio. И умеет в совместную работу и генерацию документации. Хотя, если Ваши задачи закрываются существующим комплектом - это просто замечательно.
"Из коробки" - разумеется нет. Написать в нём скрипт, который создаёт примерно такое же - не сложно. Собственно, в статье описан похожий подход - здесь у нас shared данные, здесь их отображение в том или ином формате. Плагинами - меняем данные по изменению свойств картинок. EA ещё и новые данные в БД вставляет по мере рисования примитивов. Т.е. принцип то похожий. А дальше кто на что учился :)
Советую посмотреть Enterprise Architect от https://sparxsystems.com.au/, рисовать архитектуру (и не только) в нём откровенно удобно, так же как и генерировать по ней документацию в Word / HTML. Причём не важно какую - хоть архитектуру предприятия в терминах серверов и сервисов, хоть внутреннюю архитектуру конкретного микросервиса. При желании между этими двумя моделями можно построить tracebilty matrix, в которой будет явно видно, какой сервис какой порт на какой железке использует. Данные лежат в РСУБД, с понятной структурой, так что при желании можно организовать ETL в нужную сторону, как и запустить туда внешний BI. Ну и понятно "из коробки" уже есть 100500 функций, которые реально нужны в корпоративной среде, когда это становится мастер-системой данных какого-то домена. Есть и минусы - в частности, у нас откровенно не зашло управление требованиями в нём, но это скорее из-за недоразвитости внутренних процессов и компетенций конкретных сотрудников.
Какой-то у вас однобокой подход... Это тяжелое, то неудобное, здесь не пересядешь...IDEA community можно использовать для промышленной разработки. Подсказок и инспекций будет меньше конечно, но работать будет почти всё. А вот можно ли в предлагаемом подходе реализовать функции, которые используются просто вот постоянно и зависят именно от IDE и её возможностей по анализу AST? Например:
refactor: extract variable / method, также inline оных;
call hierarchy - посмотреть, откуда данный метод вообще может вызываться;
analyze data flow to here / from here - посмотреть на поток данных, в котором устанавливается значение аргумента;
проверить код инспекциями встроенными в IDEA и SonartLint и увидеть проблемы прямо в коде, без переключения / компиляции / прочих танцев с бубном, в т.ч. анализ @Nullable / @NotNull / @NonNull аргументов, если сделана разметка в коде. А если не сделана - то попросить IDEA разметить саму, с учётом паттернов использования;
java type renderers при отладке;
analyze stack trace;
ну и вишенка на торте - настройка цветовой схемы так, чтобы вызов метода класса, статического метода этого же класса и унаследованного метода - визуально различались. Это разумеется не всё, но тут отдельную статью писать надо, что и как можно выделять в коде, чтобы поменьше путаться в каком-нибудь bridge pattern на четыре ортогональных иерархии, который вот неожиданно внутри в command завёрнут...
Не далее как неделю назад печатал на LJ 5p, LPT, в него переходник LPT - USB. 10-ка увидела и сама подтянула дрова. Но скорость выхода листа да, впечатляет. Если много мелкого текста - минут пять грузится может. Каждый...
Lombok наше всё :) Мы вот попытались имитировать в проекте null-safe концепцию из Kotlin путём совместного использования @NonNull, @Nullable и Optional<>. Вместе со статическим анализом и хинтами IDEA получается очень даже ничего. NPE становится рабочим исключением и обычно ловится тестами
Понимание к сожалению наступит сильно позже. Потому что изучать в самом начале концепцию машинной памяти и как на неё отображаются структуры данных - это немного отличается от расстановки аннотаций и создания репозиториев. Причём второй путь зачастую быстрее приводит к желаемому результату, что в создании фич, что в прохождении собеседований. Но вот когда оно начинает упираться в производительность или объём памяти... тогда C-like знания становятся нужны. Но это уже как бы и не уровень джуна.
Большое спасибо за статью. Сейчас тоже в полный рост стоим перед выбором подсистемы кэширования. Пока в фаворе Ignite, собственно у нас на нём больше чем один проект уже, но в сторону Redis тоже посматриваем. Вы их случайно не сравнивали "углублённо"? А то про возможности в статье есть но текстом, а вот например результатов тестирования производительность / объём потребляемой памяти нет... А хочется... Потому что не хочется пилить этот стенд самим :)
Ходить и смотреть глазами я и сам могу :). Но время от времени хочется (и нужно) почитать "роман", особенно при анализе PR / MR, чтобы не держать контекст в голове
Две разные реализации под разные профили Spring?
Нужно вообще запрещать вывод любых уведомлений на экран заблокированного телефона. Потому как уже есть реальные атаки, если правильно помню нужен только номер телефона жертвы и её же аппарат, на котором можно читать уведомления. Заблокированный годится.
О да! Особенно в связке с Lombok. Не далее как вчера - перестало собираться приложение. Ломбок не ломбочит, билдеры не найдены, 100 однотипных ошибок maven. Внятного сообщения об ошибке - нет. Стал разбираться, что менял. Оказалось - прибил одно поле, которое было явно прописано в mapper-е. В нём самом удалить забыл, это же просто аннотация со строковыми полями. MapStruct на этом предположительно молча падал, после чего не запускался следующий annotation processor. Нашёл только в логе ребилда в IDEA, по паттерну
Unknown property .+ in result type, а там и догадался. Минус час жизни.Всё хорошо в меру. Был у нас разработчик, который обожал разрезать имплементацию на минимальные кусочки, кусочки разложить по иерархиям, снабдить интерфейсами и припудрить Parameter Object, потому что иначе контекст вычислений не передать... И каждый раз, чтобы понять по логу что конкретно пошло не так, нужно было в голове всё это собирать. Потому что глядя на код программы - невозможно понять, при каких условиях какой кусочек кода будет использован. Там ещё и карта Command была до кучи, со строковыми ключами, если правильно помню.
Я вот последнее время вообще начал мечтать, чтобы IDEA научилась на место вызова функции рендерить её код, чтобы можно было посмотреть весь контекст выполнения не прыгая по десяти файлам. Ну вроде как рефакторинг Extract method, только с точностью до наоборот, и только чтобы посмотреть. А в случае виртуальной функции - да, рендерить вот тот switch по необходимости
Виртуальные функции. В Java в явном виде их нет, но под капотом именно оно. Был где-то тест, где сравнивали с switch, последний работал ощутимо быстрее. Впрочем, зависит от того, в чём приложение проводит основное время. Где то и Optional имеет смысл выкидывать, потому что сравнение c null - чуть быстрее. Любой инструмент короче с умом применять нужно.
В Java класс без проблем замокировать. Кода нужно писать ровно одну аннотацию
Ну вот я начну... Сделали сначала всё на классах. Не без иерархий на 5+ элементов, но там доменная модель не самая простая. 1С короче пытаемся написать, в своей предметной области естественно. Потом выяснилось, что один класс тащит две (три и больше) обязанностей. Но описывает один объект реального мира, просто с разных сторон. Можно конечно распилить на мелкие классы и каждый в свою таблицу. С учётом полиморфных ссылок на него из других сущностей - как раз появится эта связка в БД 1:1. Пока вот пытаемся выделять мелкие интерфейсы (и класс будет реализовывать несколько таких), а где нужно - использовать их в качестве параметров. Ну и куча мест, где класс должен реализовать строго один интерфейс, если он (класс) достаточно мелкий. А глобально получим некоторый бардак - ненавижу в параметрах функций классы и интерфейсы вперемешку. Поэтому наверно будем реализовать эту вашу... бест практис..., вот
И на одном номере телефона неожиданно могут оказаться пять человек (у которых он основной контактный) и две конторы, у которых он рабочий. Вполне себе кейс в кредитном антифроде
Процессинговая транзакция на 300+ полей застенчиво улыбается
Тут или картинки нам жизненно важны для бизнеса (и тогда пофиг на сложности с репликацией, она и так, и так будет), или их можно достаточно безболезненно потерять - и тогда пожалуйста храни на shared storage. Хоть файлами, главное чтобы inode не кончились. Потому что добавление +1 решения для хранения картинок потребует железа для этого решения, репликации для этого решения, поддержки этого решения, мониторингу этого решения, и ещё вероятно распределённых транзакций. А, ну ещё чтобы бэкапы не разъехались, когда база у нас в статусе на пять часов утра вчера, а картинки в статусе на cемь тоже вчера, т.е. там есть то, о чем БД не в курсе. Наоборот - веселее...
+1 предложение - в принципе, даже на неисправном канате будет некоторое соотношение "нормальных" к "повреждённым" участкам. Соответственно, можно посчитать количество / протяженность разных фрагментов, и выбрать хорошие участки (они должны быть одинаковые и их должно быть много) на конкретном канате в качестве базы для обучения. Если в стандарте написано ...не допускается... - то любое изменение геометрии - это warning. Если допускается до ... на ... - то можно эти самые отклонения посчитать, и уже принимать решение. Канат, который изначально плох настолько, что на нём соотношения хороших участков к плохим перевёрнуто - не допускать к обучению мнением человека. Так можно чуть ли не индивидуальную настройку делать под конкретную камеру и конкретный канат.
Есть ещё одна тонкость... маленькая. EA дешевле, чем Visio. И умеет в совместную работу и генерацию документации. Хотя, если Ваши задачи закрываются существующим комплектом - это просто замечательно.
"Из коробки" - разумеется нет. Написать в нём скрипт, который создаёт примерно такое же - не сложно. Собственно, в статье описан похожий подход - здесь у нас shared данные, здесь их отображение в том или ином формате. Плагинами - меняем данные по изменению свойств картинок. EA ещё и новые данные в БД вставляет по мере рисования примитивов. Т.е. принцип то похожий. А дальше кто на что учился :)
Советую посмотреть Enterprise Architect от https://sparxsystems.com.au/, рисовать архитектуру (и не только) в нём откровенно удобно, так же как и генерировать по ней документацию в Word / HTML. Причём не важно какую - хоть архитектуру предприятия в терминах серверов и сервисов, хоть внутреннюю архитектуру конкретного микросервиса. При желании между этими двумя моделями можно построить tracebilty matrix, в которой будет явно видно, какой сервис какой порт на какой железке использует.
Данные лежат в РСУБД, с понятной структурой, так что при желании можно организовать ETL в нужную сторону, как и запустить туда внешний BI.
Ну и понятно "из коробки" уже есть 100500 функций, которые реально нужны в корпоративной среде, когда это становится мастер-системой данных какого-то домена.
Есть и минусы - в частности, у нас откровенно не зашло управление требованиями в нём, но это скорее из-за недоразвитости внутренних процессов и компетенций конкретных сотрудников.
Какой-то у вас однобокой подход... Это тяжелое, то неудобное, здесь не пересядешь...IDEA community можно использовать для промышленной разработки. Подсказок и инспекций будет меньше конечно, но работать будет почти всё. А вот можно ли в предлагаемом подходе реализовать функции, которые используются просто вот постоянно и зависят именно от IDE и её возможностей по анализу AST?
Например:
refactor: extract variable / method, также inline оных;
call hierarchy - посмотреть, откуда данный метод вообще может вызываться;
analyze data flow to here / from here - посмотреть на поток данных, в котором устанавливается значение аргумента;
проверить код инспекциями встроенными в IDEA и SonartLint и увидеть проблемы прямо в коде, без переключения / компиляции / прочих танцев с бубном, в т.ч. анализ
@Nullable/@NotNull/@NonNullаргументов, если сделана разметка в коде. А если не сделана - то попросить IDEA разметить саму, с учётом паттернов использования;java type renderers при отладке;
analyze stack trace;
ну и вишенка на торте - настройка цветовой схемы так, чтобы вызов метода класса, статического метода этого же класса и унаследованного метода - визуально различались. Это разумеется не всё, но тут отдельную статью писать надо, что и как можно выделять в коде, чтобы поменьше путаться в каком-нибудь bridge pattern на четыре ортогональных иерархии, который вот неожиданно внутри в command завёрнут...
Не далее как неделю назад печатал на LJ 5p, LPT, в него переходник LPT - USB. 10-ка увидела и сама подтянула дрова. Но скорость выхода листа да, впечатляет. Если много мелкого текста - минут пять грузится может. Каждый...
Lombok наше всё :) Мы вот попытались имитировать в проекте null-safe концепцию из Kotlin путём совместного использования
@NonNull,@NullableиOptional<>. Вместе со статическим анализом и хинтами IDEA получается очень даже ничего. NPE становится рабочим исключением и обычно ловится тестамиПонимание к сожалению наступит сильно позже. Потому что изучать в самом начале концепцию машинной памяти и как на неё отображаются структуры данных - это немного отличается от расстановки аннотаций и создания репозиториев. Причём второй путь зачастую быстрее приводит к желаемому результату, что в создании фич, что в прохождении собеседований. Но вот когда оно начинает упираться в производительность или объём памяти... тогда C-like знания становятся нужны. Но это уже как бы и не уровень джуна.