Производители форменным образом извращаются над клавиатурами своих ноутов и соответственно пользователями. То раскладку сдвинут, то стрелки уменьшат, то клавишу Insert уберут, то половину нужных кнопок запихают под Fn, то вовсе перетасуют PgUp/PgDn,Home/End,Insert/Delete. Ну и конечно же засилие "полезных" медийных кнопок.
Это конечно хорошо, что создатели Spring, наконец, поняли, что программная конфигурация намного проще и удобнее, нежели простыня xml или магические @заклинания ввиде аннотаций. И стоит отметить, что еще 13 лет назад Google Guice уже вовсю использовал оную, когда Spring-гуру уже считали данный подход безнадежно устаревшим.
На заметку. Несанкционированных митингов небывает. Точно также как и нелегальных. Бывают только согласованные и несогласованные митинги. Порядок согласования прописан в ст.31 конституции РФ и носит уведомительный характер с целью обеспечения органами исполнительной власти безопасности проведения мероприятия.
Любой виртуальный митинг не представляет угрозы безопасности граждан и их имуществу, не использует публичную инфраструктуру, подконтрольную органами исполнительной власти, соответственно согласование для этого мероприятия не требуется.
Особенности распространения и эксплуатации программы, например требование интерпретатора или возможность статической линковки.
Особенности письма, например требование использования как фонетической, так и идиографической азбуки.
Экосистема библиотек и компонентов, которые можно переиспользовать. Отмечу что важно не только количество библиотек, но и качество релевантных для вас.
Количество изданной литературы. И не разного рода беллетристики, а серьезных романов и документальных трудов.
Возможности параллельного/конкурентного/асинхронного исполнения программ, что может быть важным для многих систем.
Гибкая грамматическая основа, зависимость смысла от последовательности слов в предложении.
Сложность обучения людей выбранной технологии, что значительно влияет и на сообщество языка, и на перепрофилирование разработчиков.
Исключенность из широких групп языков, что сильно усложнит полиглотам овладевание.
Выразительность языка.
Куча эмоционально-этических подтекстов, сложные правила этикета.
Да пожалуйста. Вот стек всего лишь одного продукта:
Linux
Firewall/Iptables & basic network security
Nginx
Docker
Java
Spring Boot
Html/Css/Javascript
React.JS
Oracle DB
ElasticSearch
Плюсом скилы agile, git, ci/cd, devops, english и естественно в самой предметной области.
И это примерный профайл разработчика, который сейчас требуется практически повсеместно. Сделайте одолжение, посчитайте самотстоятельно количество сертификатов. Нанимать отдельно сертифицированного спеца на каждую технологию ни у кого не хватит никакого бюджета, даже тупо потому, что вы никогда не займете его работой на 100%.
Исключение — если вы работаете с продуктом, у которого штат превышает несколько десятков разработчиков, где вся работа строго распределена по ролям. Тогда вас сертифицированного посадят на конвеер например клепать бесконечные формочки.
Смотреть портфолио? Прям исходняки? Очень интересная идея, минимум по двум причинам:
Да оспади, даже резюме сразу может о многом сказать, особенно деятельность в предудыщих проектах, несколько наводящих вопросов на собеседовании, плюс твиттер, гитхаб и общее представление о кандидате уже готово. Другое дело, что далеко не все HR-ы в состоянии адекватно оценить скилы и экспириенс кандидата, поэтому для них проще работать с сертифицированным товаром.
Мне кажется вы путаете три совершенно разных вещи — сертификацию специалистов, сертификацию процессов и сертификацию продуктов.
Я намеренно объединяю их в одно, ибо общие цели и методы у всех сертификаций практически одинаковые.
Давайте не будем демагогизировать. Все прекрасно понимают для чего используется большинство сертификатов: для работника — поднять свою цену или конкурентноспособность на рынке труда, для компании-провайдера — поднять коммерческую стоимость своих услуг или получить доступ к более выгодным предложениям на рынке, для компании-клиента — отсеять большинство мелких сошек из крупного тендера, а также налепить различных "certiried" плашек на финальный продукт, для сертифицирующей огранизации — тупо собрать со всех бабла за бумажку. Реально же ни одна сертификация никогда не гарантирует качество сертифицируемого материала, и лишь призвана создавать такое впечатление.
Да, не идеально, но намного дешевле для работодателя, чем рисковать живым проектом или устраивать многомесячные “испытательные сроки”.
Дешевле всего — посмотреть портфолио кандидата и увидеть то, что он уже делал в реальных условиях. Это скажет гораздо больше, о нем как о специалисте, нежели любые сертификаты. Кроме того "сертификационный бизнес" устроен так, что никогда не даст вам универсального сертификата "широкого плана" — только узконаправленный такого-то уровня по такому-то компоненту такого-то продукта такой-то технологии и такой-то версии. Поэтому чтобы подтвердить требуемые в типовом проекте скилы, вам придется иметь целый паровоз сертификатов, причем достаточно свежих, ибо они протухают со временем. И обойдетесь вы один мне такой сертифицированный как целая команда классных разработчиков.
И если читать сертификацию как она есть — то есть не “ой, пришел великий специалист с бумажкой”, а как положено
Читать следует так: на рынке существует такой же специалист, но без бумажки, который обойдется вам дешевле.
и не побоялся испытать себя и показать что он обладает минимальным набором собственных знаний и минимальной устойчивостью к стрессу
В первую очередь у него образовалось где-то куча свободного времени для своей сертификации, что уже настораживает. И не надо мешать сертификацию с обучением, ибо последняя идет всегда отдельно от первого и за дополнительную плату, которую кандидат надеется с лихвой отбить.
Одинаково глупо считать что сдача экзамена — это 100% доказательства, равно как и хватать студента после прослушивания курса и сразу кидаться тестировать его на реальном производстве.
Именно. Поэтому то, что вам кто-то выдал водительские права, абсолютно не значит, что вы реально умеете водить.
Как правило исчезает сразу после начала разработки задачи и появляется вконце, когда уже дело почти сделано, демонстрируя от своего имени вашу работу начальству и клиентам.
3) Специалист с сертификатами
Абсолютно бесполезный чел в реальной разработке. Сертификаты — это исключительно коммерческое изобретение дабы поднять цену "продукта". Любая сертификация — это зазубривание вопросов и искусственных кейсов, которые мало что имеют с реальными ситуациями. Будучи специалистом очень узкого плана, любую задачу пытается решить заученными шаблонными методами, мотивируя это best practice и ссылаясь на авторитет сертифицирующей огранизации, чем сильно мешает разработке.
5) Разработчик-теоретик
Не знаю этот ли тип разработчика, который на этапе планирования из газовой плиты пытается сделать ядерную станцию, наваливая всевозможные модные и фриковые технологические решения. Разобьем все на микросервисы, запакуем все в докеры, инсталлим через терраформ, деплоим через кубер, для логов подтащим эластик, сделаем репозиторий бинарников, поднимем дженкинса, испльзуем монгу для документов, мускул для данных, эластик для индекса, еще кассандру для трейсинга и полирнем все сверху кафкой. Как правило любит много рисовать, называя все это "архитектурой решения". Кодить не любит, еще меньше любит возиться со всем этим придуманным зоопарком. В проекте с самого начала создает проблемы на ровном месте.
9) Нарцисс
Как правило имеет хреновые либо сильно ограниченные навыки. Ибо нарциссизм сильно мешает прогрессировать.
Корень проблем JPA лежит не в технической, а парадигмальной плоскости. JPA пытается создать иллюзию отсутствия базы данных, в частности спрятать от программиста необходимость отражения изменений в БД.
Корень проблем в табличной модели RDB, которая вцелом плохо ложится на объектную.
Объекты должны быть изменяемыми
Сделайте сеттеры protected и получите неизменяемую entity. Кроме того, в некоторых JPA объект можно пометить ReadOnly ну или поставить на поле updatable=false.
Весь код становится кодом с побочными эффектами
JPA использует паттерн Active Object. Вся работа с объектами заключена внутри текущего UnitOfWork. Вне его объекты становятся detached но с вполне детерминированным состоянием.
Ленивая загрузка
Это как раз то почему объектная модель плохо совместима с RDB, где все есть таблица. Проблема n+1 запроса — это не проблема JPA как таковой, а вообще всех ORM, причем концептуальная. Тем не менее никто не запрещает добавить JOIN FETCH для массивного запроса. Многие JPA позволяют сократить загрузку с дочерними сущностями до двух запросов, используя для дочернего либо IN(родительские PKs), либо IN(родительский SELECT). В большинстве же ситуаций запросы, которые делает JPA — это загрузить объект по ID, которые выполняются очень быстро.
Дополнительный запрос для обновления сущности
Есть еще кеш и extended persistence context. Но вцелом первый вариант полностью оправдан. При массовом апдейте объектов их лучше сначала вытащить одним запросом. А JPA потом сгенерит один batch update. Кроме того, саму entity можно при желании использовать вкачестве DTO, а для обновления использовать простой merge().
Дополнительный запрос для вставки ссылки
Про EntityManager.getReference(Class<T> entityClass, Object primaryKey); не слышали?
Кэшировать JPA сущности нельзя.
Можно, но осторожно. Есть разные стратегии поведения кеша. Кроме того, при желании можно даже вручную управлять кешем: EntityManagerFactory.getCache().
Я практически везде использую EclipseLink, который предоставляет более полный набор средств для работы с базой, а также более стабилен и предсказуем в поведении.
Из реальных проблем JPA отметил бы отсутствие нормального type-safe DSL для запросов (Criteria API это просто ужас), достаточно убогий API и достаточно страшные аннотации для ORM. Поэтому в своих проектах часто приходится многое допиливать и делать различные надстройки и врапперы. Для упрощения разработки могу порекомендовать замечательные библиотеки QueryDSL и JINQ.
Это правда. Когда ты действительно чего-то стоишь и можешь быстро и качественно делать реальные вещи, тебя очень быстро "берет в оборот" начальство, нагружая до тех пор, пока ты не перестанешь справляться. Поэтому работая в компании, важно вести свой собственный учет времени и тщательно регистрировать свою работу, хоть большинство девелоперов и не любит всю эту бюрократию. Мне очень помогло на ковре при разборе полетов: я представил отчет по трекеру, где моя загруженность за период составляла в среднем 300% — и все дальнейшие вопросы и обвинения отпали сами собой.
Там проблема не только в картинках, а в любых визуальных элементах. С rem так или иначе получаются дробные метрики, которые плохо ведут себя на мониторах с низкой DPI и могут оставлять артефакты на месте стыковок элементов по причине различий в округлении по целочисленным пикселям. Чтобы понаблюдать, попробуйте в настройках Windows задать scale 125%. Тогда как размер в пикселях как правило имеет всегда целочисленный scale factor.
Проблема в том, что любая привязка к физическим единицам измерения длины практически никак не соотносится визуальным уголом обзора в современных устройствах. Восприятие "мелкого" или "крупного" текста — это именно угол, который занимает символ в поле визуального обзора глаза. И этот угол зависит от физического размера символа и расстояния до глаза человека. Все DPI в полиграфии рассчитывались из соображения, что текст читается на расстоянии порядка 25см, что более менее соответствует и мониторам (хотя как правило монитор стоит дальше, чем экран ноутбука), но не мобильным устройстам. Поэтому правильнее было бы ввести угловую единицу обзора, в которой бы указывался размер экрана устройства и все метрики отображаемых элементов, а разрешающая способность измерялась бы в точках на единицу угла, а не на дюйм.
Признаюсь, я не вкурсе всех нюансов российского законодательства и судебной практики, но вроде как в статье написано:
Заказчик вправе отказаться от исполнения договора возмездного оказания услуг при условии оплаты исполнителю фактически понесенных им расходов.
Исполнитель вправе отказаться от исполнения обязательств по договору возмездного оказания услуг лишь при условии полного возмещения заказчику убытков.
В законодательстве большинства европейских стран расторжение контракта в одностороннем порядке равносильно невыполнению обязательств со стороны заказчика, и в этом случае сумма компенсации убытков идет на усмотрение судьи (работа впустую, упущеная выгода, и пр.). Поэтому в контрактах всегда прописывается все условия досрочного расторжения и случаев форс-мажора, в частности, что аванс служит компенсацией и не возвращается. Кроме того, должен быть соблюден паритет сторон: контракт должен прерывается любой из сторон на схожих условиях.
когда Заказчик разрывает договор и требует вернуть аванс.
Как это? Если заказчик прервал контракт в одностороннем порядке, тем более не предусмотренным данным контрактом, аванс не возвращается. Более того, вы вправе требовать возместить прочие убытки, связанные невыполнением обязательств с его стороны (аренда хостинга, работа "впустую", расходы, найм, ускользнувшие контракты — хотя шансов тут немного).
Поэтому нужно треботвать от заказчика Акт о выполнении работ. Для этого в контракте должны быть отражены следующие положения:
Права интеллектуальной собственности (или лицензия на использование продукта) передаются заказчику в момент подписания Акта о выполнении работ. Без него он не вправе использовать софт никоим образом.
После подписания Акта провайдер обязуется осуществлять гарантийную поддержку продукта втечение установленного срока, в которой корректирует найденные ошибки, в т.ч. убирает все закладки.
Можно прямо прописать порядок релиза, что до Акта устанавливается демо-версия с ограниченным сроком действия — ничего в этом криминального нет. Еще лучшим вариантом будет тебование установки на продакшн только после подписания Акта.
Акт о выполнении работ обязует заказчика осуществить оплату в жестко установленный срок. С Актом можно прямо идти в суд и ничего доказывать не надо — заказчик сам признался, что все выполнено как надо. А в случае задержки оплаты предусмотреть пенни.
Также предусмотреть досрочный выход сторон из контракта — обычно штраф в размере задатка.
Ваши идеи с закладками не сработают на крупных заказчиках.
Как раз с крумными компаниями как правило меньше всего проблем. В крупных компаниях проекты ведутся менеджерами, которые платят не из своего кармана, а как правило по заранее заложенному бюджету. И уж поверьте, ни кому из них подставляться под легальное разбирательство совершенно нет никакой выгоды, равно как и экономить деньги компании, запланированные на проект. Если дело запахнет судом, уж будьте уверены — этот "экономный" менеджер получит от самой же компании по самое нехочу. Кроме того, у каждого из них есть начальство, с кем в случае разногласия можно урегулировать вопрос.
там пришла своя команда, они бы почистили код и всё бы заработало как надо.
То есть вместо того, чтобы заплатить за проект, дешевле будет нанять команду, которая будет ковыряться в чужом (откомпилированном) коде с негарантированным успехом и с нарушением всех прав, чтобы в итоге иметь работающий, но мертвый и неподдерживаемый код?
Замечу, что большая часть наших ребят — это разработчики, и мы понимаем что такое разработка. PHP, Python, Go, Node.js, *.js, Flutter — на всём этом мы пишем.
Возможно не получается именно потому, что на всем этом вы пишите. Сразу. У вас нет единой технологии, стратегии и стека решений, а соответственно и единой команды с хорошими экспертами в своей области. Кроме того, что многие вышеупомянутые вами языки нетипизированные (как например TypeScript, Java, Kotlin, C#) и годятся лишь для поделок на коленях. Принципы я изложил в посте выше — визуальная среда хуже справляется с разработкой нетиповых задач, но требует меньший порог вхождения.
№8 Давайте конкретно?
Конкретно все BPMS. Вам продают визуальный редактор и движок для выполнения процессов. Сам по себе этот движок ничего не делает и не умеет делать. Единственное, чем он занимается — это дерганием сторонних сервисов, которые и делают всю необходимую работу. Все это называется гордым словом Business Orquestration. Для каких-то специфических задач или других технологий связи вам продают отдельно "бизнес-коннекторы".
Это не расширение, а использование шаблона. Речь идет о возможности наследовать сам шаблон, например создать другой шаблон визарда на основе старого, добавив дефолтные экраны Greeting и Confirming (наследование). Или создать другой бизнес процесс на основе поведения старого, с определенными изменениями (полиморфизм). И все это мышкой.
№ 6: вам нужно попробовать оба подхода, чтоб экспертно заявлять.
Не хочу меряться бородами, я из эпохи Microsoft Access, Delphi, Visual Basic/C++… Кроме того почти 10 лет работал с различными BPMS. Так что визуальных инструментов для программирования насмотрелся достаточно. Все визуальные среды имеют одни и те же проблемы с копированием, редактированием, рефакторингом, поиском и поддержкой функционала. При отсутствии кода как такового усложняется контроль изменений, бекап, и переносимость. Кроме того, визуальные среды плохо справляются с промежуточным состоянием: в коде я проектирую и пишу в том порядке, как мне удобнее — до момента компиляции это абсолютно неважно. Визуальные же среды требуют строгую последовательность действий: нельзя выбрать компонент, который еще не существует и не описан. А ввиду ограниченности функционала все среды всегда имеют fallback в какой-то нативный язык программирования, но он как правило уже плохо связан с визуальным редактором — любое изменение мышкой уже не отражается автоматически в коде. И постепенно туда стекает весь функционал проекта.
№7: в этом есть доля правды т.к. каждый поставщик low code имеет свое видение
Я бы даже больше сказал — поставщику ровным счетом насрать на то, кто и как будет работать в этих визуальных средах, особенно об эргономике и удобстве разработки. Его основная задача — задвинуть недалекому клиенту свой продукт, продемонстрировав как просто и красиво там делается "Hello World". А клиент в свою очередь наймет чертей, которые и будут копошиться в этом дерьме.
В защиту low code нужно заметить что SC IDE на сегодня — шаблонная задача, которая решается также шаблонно. Low code IDE — задача более сложная и требует микро-взрыв мозга чтоб преодолеть шаблоны разработки.
Ну да, построить семантическую среду, которая бы распознавала текст программы, текущий контекст, подсвечивала бы в реальном времени ошибки компиляции, применяла бы эвристические методы анализа кода, корректировала бы программиста и подсказывала бы проблемные места и лучшие решения — это шаблонная задача. А некая визуальная среда состоящая из типовых элементов, блок-схем, формочек и комбобоксов требует, однако, взрыв мозга! Еще интересно какие шаблоны разработки она преодолевает? ФП и теория типов — вот это взрыв мозга и преодоление шаблонов! А то, что в визуальных редакторах — это лишь Basic XXI века.
№8: В этом сильная и слабая сторона low code. Эти системы лучше подходят для корпоративной разработки, когда вариативность UI ограничена, UI стандартен и порог вхождения в UI для посьзователя крайне низкий, чтоб любой новичок быстро освоился.
В этом вся суть. Такие среды позволяют линейно и методично клепать типовой функционал низкоквалифицированным персоналом. Только вот общие затраты почему-то на порядки превосходят традиционные решения.
Возражение № 5. Концепция LowCode не предназначена для абстрактных расширяемых компонентов и поведенческих паттернов, которые мы все так любим. Единственный паттерн наследования поведения в LowCode — это copy-paste, который используется повсеместно.
Возражение № 6. Написание текста программы на любом языке будет более продуктивно, нежели работа с GUI и мышью.
Возражение № 7. Хваленый стек визуальных инструментов на деле оказывается неудобоваримым глючным дерьмом, который даже близко по возможностям не доходит до любой IDE.
Возражение № 8. Концепция LowCode не самодостаточна. Такие системы несут в себе очень ограниченный набор строго определенного функционала, а посему быстро начинают обрастать различными самопальными велосипедами и сателитами.
Правильно ли я понял, что такой компании как Apple сложно найти ресурс для написания калькулятора?
Производители форменным образом извращаются над клавиатурами своих ноутов и соответственно пользователями. То раскладку сдвинут, то стрелки уменьшат, то клавишу Insert уберут, то половину нужных кнопок запихают под Fn, то вовсе перетасуют PgUp/PgDn,Home/End,Insert/Delete. Ну и конечно же засилие "полезных" медийных кнопок.
Просто ради любопытства: сколько времени потребуется одному девелоперу, чтобы с нуля написать функциональный и удобный калькулятор?
Это конечно хорошо, что создатели Spring, наконец, поняли, что программная конфигурация намного проще и удобнее, нежели простыня xml или магические @заклинания ввиде аннотаций. И стоит отметить, что еще 13 лет назад Google Guice уже вовсю использовал оную, когда Spring-гуру уже считали данный подход безнадежно устаревшим.
На заметку. Несанкционированных митингов небывает. Точно также как и нелегальных. Бывают только согласованные и несогласованные митинги. Порядок согласования прописан в ст.31 конституции РФ и носит уведомительный характер с целью обеспечения органами исполнительной власти безопасности проведения мероприятия.
Любой виртуальный митинг не представляет угрозы безопасности граждан и их имуществу, не использует публичную инфраструктуру, подконтрольную органами исполнительной власти, соответственно согласование для этого мероприятия не требуется.
Если бы вы также язык для общения выбирали...
Слова преимущественно одно-двусложные.
Особенности письма, например требование использования как фонетической, так и идиографической азбуки.
Количество изданной литературы. И не разного рода беллетристики, а серьезных романов и документальных трудов.
Гибкая грамматическая основа, зависимость смысла от последовательности слов в предложении.
Исключенность из широких групп языков, что сильно усложнит полиглотам овладевание.
Куча эмоционально-этических подтекстов, сложные правила этикета.
У вас там наверное на японском все разговаривают.
В чем убедиться? Вот текущие сертификации от Oracle:
https://education.oracle.com/es/oracle-certification-path/pPillar_2#path-p-prod-product_267
Только на Java есть 5 различных экзаменов на 3 уровня и 2 версии Java 8 и Java 11! Оставлю вам для самостоятельного ознакомления посчитать количество сертификатов, версий и уровней по Oracle DB.
Да пожалуйста. Вот стек всего лишь одного продукта:
Плюсом скилы agile, git, ci/cd, devops, english и естественно в самой предметной области.
И это примерный профайл разработчика, который сейчас требуется практически повсеместно. Сделайте одолжение, посчитайте самотстоятельно количество сертификатов. Нанимать отдельно сертифицированного спеца на каждую технологию ни у кого не хватит никакого бюджета, даже тупо потому, что вы никогда не займете его работой на 100%.
Исключение — если вы работаете с продуктом, у которого штат превышает несколько десятков разработчиков, где вся работа строго распределена по ролям. Тогда вас сертифицированного посадят на конвеер например клепать бесконечные формочки.
Да оспади, даже резюме сразу может о многом сказать, особенно деятельность в предудыщих проектах, несколько наводящих вопросов на собеседовании, плюс твиттер, гитхаб и общее представление о кандидате уже готово. Другое дело, что далеко не все HR-ы в состоянии адекватно оценить скилы и экспириенс кандидата, поэтому для них проще работать с сертифицированным товаром.
Я намеренно объединяю их в одно, ибо общие цели и методы у всех сертификаций практически одинаковые.
Давайте не будем демагогизировать. Все прекрасно понимают для чего используется большинство сертификатов: для работника — поднять свою цену или конкурентноспособность на рынке труда, для компании-провайдера — поднять коммерческую стоимость своих услуг или получить доступ к более выгодным предложениям на рынке, для компании-клиента — отсеять большинство мелких сошек из крупного тендера, а также налепить различных "certiried" плашек на финальный продукт, для сертифицирующей огранизации — тупо собрать со всех бабла за бумажку. Реально же ни одна сертификация никогда не гарантирует качество сертифицируемого материала, и лишь призвана создавать такое впечатление.
Дешевле всего — посмотреть портфолио кандидата и увидеть то, что он уже делал в реальных условиях. Это скажет гораздо больше, о нем как о специалисте, нежели любые сертификаты. Кроме того "сертификационный бизнес" устроен так, что никогда не даст вам универсального сертификата "широкого плана" — только узконаправленный такого-то уровня по такому-то компоненту такого-то продукта такой-то технологии и такой-то версии. Поэтому чтобы подтвердить требуемые в типовом проекте скилы, вам придется иметь целый паровоз сертификатов, причем достаточно свежих, ибо они протухают со временем. И обойдетесь вы один мне такой сертифицированный как целая команда классных разработчиков.
Читать следует так: на рынке существует такой же специалист, но без бумажки, который обойдется вам дешевле.
В первую очередь у него образовалось где-то куча свободного времени для своей сертификации, что уже настораживает. И не надо мешать сертификацию с обучением, ибо последняя идет всегда отдельно от первого и за дополнительную плату, которую кандидат надеется с лихвой отбить.
Именно. Поэтому то, что вам кто-то выдал водительские права, абсолютно не значит, что вы реально умеете водить.
Как правило исчезает сразу после начала разработки задачи и появляется вконце, когда уже дело почти сделано, демонстрируя от своего имени вашу работу начальству и клиентам.
Абсолютно бесполезный чел в реальной разработке. Сертификаты — это исключительно коммерческое изобретение дабы поднять цену "продукта". Любая сертификация — это зазубривание вопросов и искусственных кейсов, которые мало что имеют с реальными ситуациями. Будучи специалистом очень узкого плана, любую задачу пытается решить заученными шаблонными методами, мотивируя это best practice и ссылаясь на авторитет сертифицирующей огранизации, чем сильно мешает разработке.
Не знаю этот ли тип разработчика, который на этапе планирования из газовой плиты пытается сделать ядерную станцию, наваливая всевозможные модные и фриковые технологические решения. Разобьем все на микросервисы, запакуем все в докеры, инсталлим через терраформ, деплоим через кубер, для логов подтащим эластик, сделаем репозиторий бинарников, поднимем дженкинса, испльзуем монгу для документов, мускул для данных, эластик для индекса, еще кассандру для трейсинга и полирнем все сверху кафкой. Как правило любит много рисовать, называя все это "архитектурой решения". Кодить не любит, еще меньше любит возиться со всем этим придуманным зоопарком. В проекте с самого начала создает проблемы на ровном месте.
Как правило имеет хреновые либо сильно ограниченные навыки. Ибо нарциссизм сильно мешает прогрессировать.
Корень проблем в табличной модели RDB, которая вцелом плохо ложится на объектную.
Сделайте сеттеры protected и получите неизменяемую entity. Кроме того, в некоторых JPA объект можно пометить ReadOnly ну или поставить на поле updatable=false.
JPA использует паттерн Active Object. Вся работа с объектами заключена внутри текущего UnitOfWork. Вне его объекты становятся detached но с вполне детерминированным состоянием.
Это как раз то почему объектная модель плохо совместима с RDB, где все есть таблица. Проблема n+1 запроса — это не проблема JPA как таковой, а вообще всех ORM, причем концептуальная. Тем не менее никто не запрещает добавить JOIN FETCH для массивного запроса. Многие JPA позволяют сократить загрузку с дочерними сущностями до двух запросов, используя для дочернего либо IN(родительские PKs), либо IN(родительский SELECT). В большинстве же ситуаций запросы, которые делает JPA — это загрузить объект по ID, которые выполняются очень быстро.
Есть еще кеш и extended persistence context. Но вцелом первый вариант полностью оправдан. При массовом апдейте объектов их лучше сначала вытащить одним запросом. А JPA потом сгенерит один batch update. Кроме того, саму entity можно при желании использовать вкачестве DTO, а для обновления использовать простой merge().
Про
EntityManager.getReference(Class<T> entityClass, Object primaryKey);не слышали?Можно, но осторожно. Есть разные стратегии поведения кеша. Кроме того, при желании можно даже вручную управлять кешем:
EntityManagerFactory.getCache().Я практически везде использую EclipseLink, который предоставляет более полный набор средств для работы с базой, а также более стабилен и предсказуем в поведении.
Из реальных проблем JPA отметил бы отсутствие нормального type-safe DSL для запросов (Criteria API это просто ужас), достаточно убогий API и достаточно страшные аннотации для ORM. Поэтому в своих проектах часто приходится многое допиливать и делать различные надстройки и врапперы. Для упрощения разработки могу порекомендовать замечательные библиотеки QueryDSL и JINQ.
Для Backoffice UI также используется Vaadin?
Это правда. Когда ты действительно чего-то стоишь и можешь быстро и качественно делать реальные вещи, тебя очень быстро "берет в оборот" начальство, нагружая до тех пор, пока ты не перестанешь справляться. Поэтому работая в компании, важно вести свой собственный учет времени и тщательно регистрировать свою работу, хоть большинство девелоперов и не любит всю эту бюрократию. Мне очень помогло на ковре при разборе полетов: я представил отчет по трекеру, где моя загруженность за период составляла в среднем 300% — и все дальнейшие вопросы и обвинения отпали сами собой.
Там проблема не только в картинках, а в любых визуальных элементах. С rem так или иначе получаются дробные метрики, которые плохо ведут себя на мониторах с низкой DPI и могут оставлять артефакты на месте стыковок элементов по причине различий в округлении по целочисленным пикселям. Чтобы понаблюдать, попробуйте в настройках Windows задать scale 125%. Тогда как размер в пикселях как правило имеет всегда целочисленный scale factor.
Проблема в том, что любая привязка к физическим единицам измерения длины практически никак не соотносится визуальным уголом обзора в современных устройствах. Восприятие "мелкого" или "крупного" текста — это именно угол, который занимает символ в поле визуального обзора глаза. И этот угол зависит от физического размера символа и расстояния до глаза человека. Все DPI в полиграфии рассчитывались из соображения, что текст читается на расстоянии порядка 25см, что более менее соответствует и мониторам (хотя как правило монитор стоит дальше, чем экран ноутбука), но не мобильным устройстам. Поэтому правильнее было бы ввести угловую единицу обзора, в которой бы указывался размер экрана устройства и все метрики отображаемых элементов, а разрешающая способность измерялась бы в точках на единицу угла, а не на дюйм.
Признаюсь, я не вкурсе всех нюансов российского законодательства и судебной практики, но вроде как в статье написано:
В законодательстве большинства европейских стран расторжение контракта в одностороннем порядке равносильно невыполнению обязательств со стороны заказчика, и в этом случае сумма компенсации убытков идет на усмотрение судьи (работа впустую, упущеная выгода, и пр.). Поэтому в контрактах всегда прописывается все условия досрочного расторжения и случаев форс-мажора, в частности, что аванс служит компенсацией и не возвращается. Кроме того, должен быть соблюден паритет сторон: контракт должен прерывается любой из сторон на схожих условиях.
Как это? Если заказчик прервал контракт в одностороннем порядке, тем более не предусмотренным данным контрактом, аванс не возвращается. Более того, вы вправе требовать возместить прочие убытки, связанные невыполнением обязательств с его стороны (аренда хостинга, работа "впустую", расходы, найм, ускользнувшие контракты — хотя шансов тут немного).
Поэтому нужно треботвать от заказчика Акт о выполнении работ. Для этого в контракте должны быть отражены следующие положения:
Как раз с крумными компаниями как правило меньше всего проблем. В крупных компаниях проекты ведутся менеджерами, которые платят не из своего кармана, а как правило по заранее заложенному бюджету. И уж поверьте, ни кому из них подставляться под легальное разбирательство совершенно нет никакой выгоды, равно как и экономить деньги компании, запланированные на проект. Если дело запахнет судом, уж будьте уверены — этот "экономный" менеджер получит от самой же компании по самое нехочу. Кроме того, у каждого из них есть начальство, с кем в случае разногласия можно урегулировать вопрос.
То есть вместо того, чтобы заплатить за проект, дешевле будет нанять команду, которая будет ковыряться в чужом (откомпилированном) коде с негарантированным успехом и с нарушением всех прав, чтобы в итоге иметь работающий, но мертвый и неподдерживаемый код?
Возможно не получается именно потому, что на всем этом вы пишите. Сразу. У вас нет единой технологии, стратегии и стека решений, а соответственно и единой команды с хорошими экспертами в своей области. Кроме того, что многие вышеупомянутые вами языки нетипизированные (как например TypeScript, Java, Kotlin, C#) и годятся лишь для поделок на коленях. Принципы я изложил в посте выше — визуальная среда хуже справляется с разработкой нетиповых задач, но требует меньший порог вхождения.
Конкретно все BPMS. Вам продают визуальный редактор и движок для выполнения процессов. Сам по себе этот движок ничего не делает и не умеет делать. Единственное, чем он занимается — это дерганием сторонних сервисов, которые и делают всю необходимую работу. Все это называется гордым словом Business Orquestration. Для каких-то специфических задач или других технологий связи вам продают отдельно "бизнес-коннекторы".
Это не расширение, а использование шаблона. Речь идет о возможности наследовать сам шаблон, например создать другой шаблон визарда на основе старого, добавив дефолтные экраны Greeting и Confirming (наследование). Или создать другой бизнес процесс на основе поведения старого, с определенными изменениями (полиморфизм). И все это мышкой.
Не хочу меряться бородами, я из эпохи Microsoft Access, Delphi, Visual Basic/C++… Кроме того почти 10 лет работал с различными BPMS. Так что визуальных инструментов для программирования насмотрелся достаточно. Все визуальные среды имеют одни и те же проблемы с копированием, редактированием, рефакторингом, поиском и поддержкой функционала. При отсутствии кода как такового усложняется контроль изменений, бекап, и переносимость. Кроме того, визуальные среды плохо справляются с промежуточным состоянием: в коде я проектирую и пишу в том порядке, как мне удобнее — до момента компиляции это абсолютно неважно. Визуальные же среды требуют строгую последовательность действий: нельзя выбрать компонент, который еще не существует и не описан. А ввиду ограниченности функционала все среды всегда имеют fallback в какой-то нативный язык программирования, но он как правило уже плохо связан с визуальным редактором — любое изменение мышкой уже не отражается автоматически в коде. И постепенно туда стекает весь функционал проекта.
Я бы даже больше сказал — поставщику ровным счетом насрать на то, кто и как будет работать в этих визуальных средах, особенно об эргономике и удобстве разработки. Его основная задача — задвинуть недалекому клиенту свой продукт, продемонстрировав как просто и красиво там делается "Hello World". А клиент в свою очередь наймет чертей, которые и будут копошиться в этом дерьме.
Ну да, построить семантическую среду, которая бы распознавала текст программы, текущий контекст, подсвечивала бы в реальном времени ошибки компиляции, применяла бы эвристические методы анализа кода, корректировала бы программиста и подсказывала бы проблемные места и лучшие решения — это шаблонная задача. А некая визуальная среда состоящая из типовых элементов, блок-схем, формочек и комбобоксов требует, однако, взрыв мозга! Еще интересно какие шаблоны разработки она преодолевает? ФП и теория типов — вот это взрыв мозга и преодоление шаблонов! А то, что в визуальных редакторах — это лишь Basic XXI века.
В этом вся суть. Такие среды позволяют линейно и методично клепать типовой функционал низкоквалифицированным персоналом. Только вот общие затраты почему-то на порядки превосходят традиционные решения.
Возражение № 5. Концепция LowCode не предназначена для абстрактных расширяемых компонентов и поведенческих паттернов, которые мы все так любим. Единственный паттерн наследования поведения в LowCode — это copy-paste, который используется повсеместно.
Возражение № 6. Написание текста программы на любом языке будет более продуктивно, нежели работа с GUI и мышью.
Возражение № 7. Хваленый стек визуальных инструментов на деле оказывается неудобоваримым глючным дерьмом, который даже близко по возможностям не доходит до любой IDE.
Возражение № 8. Концепция LowCode не самодостаточна. Такие системы несут в себе очень ограниченный набор строго определенного функционала, а посему быстро начинают обрастать различными самопальными велосипедами и сателитами.