не создает проблем с репликацией и резервированием БД из-за большого объема данных
Тут или картинки нам жизненно важны для бизнеса (и тогда пофиг на сложности с репликацией, она и так, и так будет), или их можно достаточно безболезненно потерять - и тогда пожалуйста храни на 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 знания становятся нужны. Но это уже как бы и не уровень джуна.
Не надо в 2022 использовать NetBeans. Стоит сразу привыкать к IDEA, она вроде как промышленный стандарт уже стала, тем более, что лучшее из NetBeans там есть. А уж что касается поддержки разных фреймворков...
И да, в IDEA можно собрать проект средствами IDE и ручным подключением библиотек, но зачем?
Про языки не знаю. Случай примерно следующий - класс X умеет обрабатыать что-то из множества A (т.е. множество - тип параметра функции), его наследник Y - умеет всё из A и ещё пару случаев. Хорошо бы расширить множество A в наследник B добавивив ещё пару вариантов и обрабатывать в Y уже его, чтобы получился статически проверяемый код, но нет. Я знаю, как такое собрать из static final членов того же класса + приватный конструктор, но это как раз из разряда извращений. И не поддерживается языковыми конструкциями
Не пора ли благородному дону в отпуск?
Пора. Уже года два как. Но некогда. И проблему говнокода из-за отсутствия фич это не решит - его проекте только прибавляется.
PS: Видимо пора коммитить в lombok - не ждать так сказать милостей от природы
Были бы именованные параметры - не было бы большинства с перегрузкой. И шаблон Builder бы не потребовался. И ещё дофига всего. Но нет, Java - она не такая. Хотя на момент её (Java) пелёнок это уже лет пятнадцать как было много где. А ещё я иногда хочу перегружать по возвращаемому результату. Однако хрен там. Там же, где и наследование enum. Зла не хватает. Язык, на котором пишется куча бизнес-логики... и который не очень-то для этого предназначался при разработке, судя по всему
Овощи. Нужны сырые овощи. Мы, безволосые обезьяны, приспособлены к поеданию сырой клетчатки, она нам полезна во всех местах - от чистки и укрепления зубов до улучшения работы выводящей системы. На перекусы прекрасно идёт сырая морковка - она есть готовая в палочках, или можно нарезать с утра в контейнер. Та, которая в магазине страшно выглядит и вся в глине - обычно самая вкусная. К морковке можно порезать полосками болгарские перцы. Отлично идёт белокочанная капуста, особенно кочерыжка. Хороша зелёная редька (её впрочем лучше потереть заранее и смешать с жареным луком). Репка. Огурцы, в конце концов.
Если вы живёте без таск-трекера - я иду к вам :)) Коммит мегаудобно начинать с идентификатора задачи из Jira / YT / RM, потом через пробел - описание, какую новую функциональность он добавляет, либо что лечит. Причём тут не нужно экономить строки - чем полнее, тем лучше, причём по возможности с точки зрения бизнеса. Дата и время попадают в коммит автоматически, вместе с автором, а если в таск-трекере настроены разные проекты на багфикс и разработку - то вам и тэг типа работы не нужен. Мы вот потом по нашим commit message почти автоматически release notes собираем. А IDEA вообще настроена на подсветку всех номеров веток в коммитах как гиперссылок, по которым сразу открывается описание задачи в YT со всей историей его изменений, комментирования и т.п.
Для Java не потребуется. Потребуется ojdbc-что-нибудь.jar для сборки, но он потом будет в образе лежать, который fat jar. Полный текст дескриптора нужен как рыбе зонтик, достаточно ip или доменного имени сервера, порта и SID. Если немного заморочиться, эти данные можно в коде программы добыть прямо из sqlnet.ora на целевой машине, благо известно, где его искать. Там много чего становится сразу можно :)
По заголовку в принципе было понятно, что будут страдания, но что настолько - я, честно говоря, не ожидал. Ладно бы статься была из 1995, тогда это вот всё, да. Но в 2021? Как research проект - может быть. Как решение реальной задачи - КМК overhead 146% по времени разработки и поддержки. Тем более, что в целевых системах - только свежая винда, ограничений по аппаратным ресурсам явно нет. Я не специалист в .Net, но вроде там какая-та версия библиотек прямо вместе с ОС ставится, т.е. собираете небольшой .exe на C# и ага, задача решена. Вариантов выстрелить в ногу в разы меньше будет. Можно вообще сразу посмотреть в сторону GraalVM / Java, там нативный образ из коробки будет и не только под винду, и даже OCI не потребуется - в JDBC уже есть всё, что нужно.
Процессинговая транзакция на 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 знания становятся нужны. Но это уже как бы и не уровень джуна.
Не надо в 2022 использовать NetBeans. Стоит сразу привыкать к IDEA, она вроде как промышленный стандарт уже стала, тем более, что лучшее из NetBeans там есть. А уж что касается поддержки разных фреймворков...
И да, в IDEA можно собрать проект средствами IDE и ручным подключением библиотек, но зачем?
Не этот. https://projectlombok.org/features/Builder + https://projectlombok.org/features/NonNull
Про языки не знаю. Случай примерно следующий - класс X умеет обрабатыать что-то из множества A (т.е. множество - тип параметра функции), его наследник Y - умеет всё из A и ещё пару случаев. Хорошо бы расширить множество A в наследник B добавивив ещё пару вариантов и обрабатывать в Y уже его, чтобы получился статически проверяемый код, но нет. Я знаю, как такое собрать из static final членов того же класса + приватный конструктор, но это как раз из разряда извращений. И не поддерживается языковыми конструкциями
Пора. Уже года два как. Но некогда. И проблему говнокода из-за отсутствия фич это не решит - его проекте только прибавляется.
PS: Видимо пора коммитить в lombok - не ждать так сказать милостей от природы
https://plugins.jetbrains.com/plugin/8215-youtrack-integration
Были бы именованные параметры - не было бы большинства с перегрузкой. И шаблон Builder бы не потребовался. И ещё дофига всего. Но нет, Java - она не такая. Хотя на момент её (Java) пелёнок это уже лет пятнадцать как было много где. А ещё я иногда хочу перегружать по возвращаемому результату. Однако хрен там. Там же, где и наследование enum. Зла не хватает. Язык, на котором пишется куча бизнес-логики... и который не очень-то для этого предназначался при разработке, судя по всему
Овощи. Нужны сырые овощи. Мы, безволосые обезьяны, приспособлены к поеданию сырой клетчатки, она нам полезна во всех местах - от чистки и укрепления зубов до улучшения работы выводящей системы. На перекусы прекрасно идёт сырая морковка - она есть готовая в палочках, или можно нарезать с утра в контейнер. Та, которая в магазине страшно выглядит и вся в глине - обычно самая вкусная. К морковке можно порезать полосками болгарские перцы. Отлично идёт белокочанная капуста, особенно кочерыжка. Хороша зелёная редька (её впрочем лучше потереть заранее и смешать с жареным луком). Репка. Огурцы, в конце концов.
Если вы живёте без таск-трекера - я иду к вам :)) Коммит мегаудобно начинать с идентификатора задачи из Jira / YT / RM, потом через пробел - описание, какую новую функциональность он добавляет, либо что лечит. Причём тут не нужно экономить строки - чем полнее, тем лучше, причём по возможности с точки зрения бизнеса. Дата и время попадают в коммит автоматически, вместе с автором, а если в таск-трекере настроены разные проекты на багфикс и разработку - то вам и тэг типа работы не нужен. Мы вот потом по нашим commit message почти автоматически release notes собираем. А IDEA вообще настроена на подсветку всех номеров веток в коммитах как гиперссылок, по которым сразу открывается описание задачи в YT со всей историей его изменений, комментирования и т.п.
Уверен, ПЦР был положительный. Второй должен быть на этой неделе, глядишь, выпустят из квартиры :|
Моего варианта тоже нет - вакцинировался дважды (спутником и чумаковской) и ещё через три месяца переболел (три дня температуры)
Для Java не потребуется. Потребуется ojdbc-что-нибудь.jar для сборки, но он потом будет в образе лежать, который fat jar. Полный текст дескриптора нужен как рыбе зонтик, достаточно ip или доменного имени сервера, порта и SID. Если немного заморочиться, эти данные можно в коде программы добыть прямо из sqlnet.ora на целевой машине, благо известно, где его искать. Там много чего становится сразу можно :)
По заголовку в принципе было понятно, что будут страдания, но что настолько - я, честно говоря, не ожидал. Ладно бы статься была из 1995, тогда это вот всё, да. Но в 2021? Как research проект - может быть. Как решение реальной задачи - КМК overhead 146% по времени разработки и поддержки. Тем более, что в целевых системах - только свежая винда, ограничений по аппаратным ресурсам явно нет. Я не специалист в .Net, но вроде там какая-та версия библиотек прямо вместе с ОС ставится, т.е. собираете небольшой .exe на C# и ага, задача решена. Вариантов выстрелить в ногу в разы меньше будет. Можно вообще сразу посмотреть в сторону GraalVM / Java, там нативный образ из коробки будет и не только под винду, и даже OCI не потребуется - в JDBC уже есть всё, что нужно.