Pull to refresh
31
0
Антон Куранов @Throwable

Пользователь

Send message

Как всегда, все приведенные аргументы мелкие и несерьезные: у нас есть фича A, а у вас ее нет, либо она хуже и вообще плохая. Я тоже писал проекты на Kotlin, но до сих пор предпочитаю Java, и вот почему:


  1. Синтаксис. Котлин сложнее и оперирует бОльшим количеством конструкций. Язык и API зачастую создают впечатление перегруженностью сахаром. Да, это позволяет писать более "лаконичный" код (за что и ставят плюс), однако совершенно противоположно действует на читабельность оного. Многабукав в Java совсем не значит, что это труднее читать.
  2. Полиморфность кода. Для большинства задач в Java уже предусмортен джентльменский набор стандартных решений и паттернов проектирования. В Котлине, благодаря его "широким возможностям", количество способов для одной и той же задачи увеличивается сразу в десятки раз. И выбор "правильного" метода лежит на сугубо на индивидуальных эстетических критериях каждого программиста. Кроме того обилие implicit-ов (extension methods, пакетные функции) делает конкретный фрагмент абсолютно нечитаемым без контекста. В итоге в проекте отсутствует всякая унификация кода, если у вас больше 1 девелопера, что называется "кто в лес, кто по дрова". Это ухуджает в разы поддерживаемость проекта.
  3. Экосистема. Чисто котлиновская сейчас очень мелкая, поэтому так или иначе приходится использовать джаву и интегрироваться с ней. Несмотря на то, что много кто сегодня поддерживает Котлин, всегда при интеграции возникают швы и костыли ввиде kotlin.jvm.* и прочих. Не слушайте всех, кто "не испытывают в котлине проблем с java-библиотеками" — они нагло врут, а в голове постоянно держат "в какой джава класс скомпилируется данный кусок кода". Ну или не пишут ничего сложнее микросервиса к базе, хотя и тут будут проблемы с Jackson binding-ом.
  4. Киллер-фичи. Наиболее разрекламированное "чудо" зачастую оказывается бесполезным, а иногда даже вредным. Все сталкивались, что во многих случаях nullability тупо мешает, нежели помогает, портя собой код. Все потому, что nullability в большинстве случаев — это не статическое свойство, а контекстно-зависимое: программист знает, что конкретно здесь оно точно никогда не null, а вот там иногда может быть. Но описать такую конструкцию в Котлине нельзя (а вот в Java это как бы из коробки). Что там еще? Корутины? Очень интрузивное и тяжелое изменение, которое заставляет код выполняться совсем не так, как написано, разрезая сверху до самого основания ваш код на suspendable и не-suspendable. Loom гораздо более элегантен и прозрачен. Желание "улучшить" джаву приводит к проблемам совместимости и соответствующим костылям ввиде all open gradle plugin… Из позитивных фич я бы отметил коллекции (хорошо неинтрузивно переработали и сделали immutable), и properties.
  5. Позиционирование языка. Не понятно целевое назначение. С одной стороны это "улучшенная джава", с другой он претендует на инструмент для multiplatform-разработки и суется в чуждые ему ниши. Однако в каждой из них приходится жестко конкурировать с уже устаканившимися языками: если вы пишите под JVM, для Java вам нужно знать только Java, для Kotlin вам нужно знать Kotlin и Java. Для JS-таргета приходится конкурировать с нативным Typescript, и юзать костыли для интеграции с JS-экосистемой, ну естественно, также приходится знать JS. Для native тоже котлин не в моде — там сейчас Rust. Остается Android, но и тут он теснится Flutter/Dart. Реально же проекты, где необходима мультиплатформенность с единой кодовой базой, в природе не встречаются.

Я имел ввиду именно написать калькулятор, а не продать его проект клиенту...

У них была халтура копипейстнутая, а не калькулятор. Накидать прототип и задизайнить несколько скинов — дело одного вечера. А персонально для Джобса разыграть трогательную историю создания, в которую он поверит и проникнется. Просто никто работать не хотел — сам босс зарубил, значит выпилим, и дело в шляпе.

Правильно ли я понял, что такой компании как Apple сложно найти ресурс для написания калькулятора?

Производители форменным образом извращаются над клавиатурами своих ноутов и соответственно пользователями. То раскладку сдвинут, то стрелки уменьшат, то клавишу Insert уберут, то половину нужных кнопок запихают под Fn, то вовсе перетасуют PgUp/PgDn,Home/End,Insert/Delete. Ну и конечно же засилие "полезных" медийных кнопок.

До выхода iPad оставалось всего несколько недель, Форстолл знал, что его команда не сможет создать новое приложение с нуля

Просто ради любопытства: сколько времени потребуется одному девелоперу, чтобы с нуля написать функциональный и удобный калькулятор?

Это конечно хорошо, что создатели Spring, наконец, поняли, что программная конфигурация намного проще и удобнее, нежели простыня xml или магические @заклинания ввиде аннотаций. И стоит отметить, что еще 13 лет назад Google Guice уже вовсю использовал оную, когда Spring-гуру уже считали данный подход безнадежно устаревшим.

На заметку. Несанкционированных митингов небывает. Точно также как и нелегальных. Бывают только согласованные и несогласованные митинги. Порядок согласования прописан в ст.31 конституции РФ и носит уведомительный характер с целью обеспечения органами исполнительной власти безопасности проведения мероприятия.


Любой виртуальный митинг не представляет угрозы безопасности граждан и их имуществу, не использует публичную инфраструктуру, подконтрольную органами исполнительной власти, соответственно согласование для этого мероприятия не требуется.

Если бы вы также язык для общения выбирали...


Baseline по скорости работы ПО.

Слова преимущественно одно-двусложные.


Особенности распространения и эксплуатации программы, например требование интерпретатора или возможность статической линковки.

Особенности письма, например требование использования как фонетической, так и идиографической азбуки.


Экосистема библиотек и компонентов, которые можно переиспользовать. Отмечу что важно не только количество библиотек, но и качество релевантных для вас.

Количество изданной литературы. И не разного рода беллетристики, а серьезных романов и документальных трудов.


Возможности параллельного/конкурентного/асинхронного исполнения программ, что может быть важным для многих систем.

Гибкая грамматическая основа, зависимость смысла от последовательности слов в предложении.


Сложность обучения людей выбранной технологии, что значительно влияет и на сообщество языка, и на перепрофилирование разработчиков.

Исключенность из широких групп языков, что сильно усложнит полиглотам овладевание.


Выразительность языка.

Куча эмоционально-этических подтекстов, сложные правила этикета.


У вас там наверное на японском все разговаривают.

Потом можете взять экзамены AWS, Oracle, Cisco и убедиться в том же самом.

В чем убедиться? Вот текущие сертификации от 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.


Теперь ваш вариант «кучи», пожалуйста.

Да пожалуйста. Вот стек всего лишь одного продукта:


  • 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% доказательства, равно как и хватать студента после прослушивания курса и сразу кидаться тестировать его на реальном производстве.

Именно. Поэтому то, что вам кто-то выдал водительские права, абсолютно не значит, что вы реально умеете водить.

1) Продавец дыма

Как правило исчезает сразу после начала разработки задачи и появляется вконце, когда уже дело почти сделано, демонстрируя от своего имени вашу работу начальству и клиентам.


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.

Для Backoffice UI также используется Vaadin?

Это правда. Когда ты действительно чего-то стоишь и можешь быстро и качественно делать реальные вещи, тебя очень быстро "берет в оборот" начальство, нагружая до тех пор, пока ты не перестанешь справляться. Поэтому работая в компании, важно вести свой собственный учет времени и тщательно регистрировать свою работу, хоть большинство девелоперов и не любит всю эту бюрократию. Мне очень помогло на ковре при разборе полетов: я представил отчет по трекеру, где моя загруженность за период составляла в среднем 300% — и все дальнейшие вопросы и обвинения отпали сами собой.

Там проблема не только в картинках, а в любых визуальных элементах. С rem так или иначе получаются дробные метрики, которые плохо ведут себя на мониторах с низкой DPI и могут оставлять артефакты на месте стыковок элементов по причине различий в округлении по целочисленным пикселям. Чтобы понаблюдать, попробуйте в настройках Windows задать scale 125%. Тогда как размер в пикселях как правило имеет всегда целочисленный scale factor.

Проблема в том, что любая привязка к физическим единицам измерения длины практически никак не соотносится визуальным уголом обзора в современных устройствах. Восприятие "мелкого" или "крупного" текста — это именно угол, который занимает символ в поле визуального обзора глаза. И этот угол зависит от физического размера символа и расстояния до глаза человека. Все DPI в полиграфии рассчитывались из соображения, что текст читается на расстоянии порядка 25см, что более менее соответствует и мониторам (хотя как правило монитор стоит дальше, чем экран ноутбука), но не мобильным устройстам. Поэтому правильнее было бы ввести угловую единицу обзора, в которой бы указывался размер экрана устройства и все метрики отображаемых элементов, а разрешающая способность измерялась бы в точках на единицу угла, а не на дюйм.

Это вы сами придумали?

Признаюсь, я не вкурсе всех нюансов российского законодательства и судебной практики, но вроде как в статье написано:


  1. Заказчик вправе отказаться от исполнения договора возмездного оказания услуг при условии оплаты исполнителю фактически понесенных им расходов.
  2. Исполнитель вправе отказаться от исполнения обязательств по договору возмездного оказания услуг лишь при условии полного возмещения заказчику убытков.

В законодательстве большинства европейских стран расторжение контракта в одностороннем порядке равносильно невыполнению обязательств со стороны заказчика, и в этом случае сумма компенсации убытков идет на усмотрение судьи (работа впустую, упущеная выгода, и пр.). Поэтому в контрактах всегда прописывается все условия досрочного расторжения и случаев форс-мажора, в частности, что аванс служит компенсацией и не возвращается. Кроме того, должен быть соблюден паритет сторон: контракт должен прерывается любой из сторон на схожих условиях.

когда Заказчик разрывает договор и требует вернуть аванс.

Как это? Если заказчик прервал контракт в одностороннем порядке, тем более не предусмотренным данным контрактом, аванс не возвращается. Более того, вы вправе требовать возместить прочие убытки, связанные невыполнением обязательств с его стороны (аренда хостинга, работа "впустую", расходы, найм, ускользнувшие контракты — хотя шансов тут немного).

Поэтому нужно треботвать от заказчика Акт о выполнении работ. Для этого в контракте должны быть отражены следующие положения:


  1. Права интеллектуальной собственности (или лицензия на использование продукта) передаются заказчику в момент подписания Акта о выполнении работ. Без него он не вправе использовать софт никоим образом.
  2. После подписания Акта провайдер обязуется осуществлять гарантийную поддержку продукта втечение установленного срока, в которой корректирует найденные ошибки, в т.ч. убирает все закладки.
  3. Можно прямо прописать порядок релиза, что до Акта устанавливается демо-версия с ограниченным сроком действия — ничего в этом криминального нет. Еще лучшим вариантом будет тебование установки на продакшн только после подписания Акта.
  4. Акт о выполнении работ обязует заказчика осуществить оплату в жестко установленный срок. С Актом можно прямо идти в суд и ничего доказывать не надо — заказчик сам признался, что все выполнено как надо. А в случае задержки оплаты предусмотреть пенни.
  5. Также предусмотреть досрочный выход сторон из контракта — обычно штраф в размере задатка.

Ваши идеи с закладками не сработают на крупных заказчиках.

Как раз с крумными компаниями как правило меньше всего проблем. В крупных компаниях проекты ведутся менеджерами, которые платят не из своего кармана, а как правило по заранее заложенному бюджету. И уж поверьте, ни кому из них подставляться под легальное разбирательство совершенно нет никакой выгоды, равно как и экономить деньги компании, запланированные на проект. Если дело запахнет судом, уж будьте уверены — этот "экономный" менеджер получит от самой же компании по самое нехочу. Кроме того, у каждого из них есть начальство, с кем в случае разногласия можно урегулировать вопрос.


там пришла своя команда, они бы почистили код и всё бы заработало как надо.

То есть вместо того, чтобы заплатить за проект, дешевле будет нанять команду, которая будет ковыряться в чужом (откомпилированном) коде с негарантированным успехом и с нарушением всех прав, чтобы в итоге иметь работающий, но мертвый и неподдерживаемый код?

Information

Rating
3,870-th
Location
Madrid, Испания
Registered
Activity