Обновить
36
0.1
Илья Сазонов@poxvuibr

Software developer

Отправить сообщение

Нет, я рассуждаю с позиции человека, который прежде чем делать что то новое изучает текущие решения.

Вот о том я и говорю. Сейчас то речь не о том, чтобы делать что-то новое, а о том, чтобы выбрать между двумя уже существующими решениями - Init Spring и start-spring-boot. И для выбора между двумя существующими решениями вы приводите аргументы, которые обычно используют, когда думают сделать что-то новое.

Ээээ... с чего вы это решили? [ Что я один из людей, которые выбирают софт потому что им нравится как он разрабатывается ]

Да вы сами так сказали, вот с чего я это решил. Вот сейчас я вас в очередной раз процитирую.

  • но я по прежнему буду использовать start-spring-boot т.к. сам придерживаюсь подобного подхода и уважаю такие решения где с помощью минимальных телодвижений можно дать максимально полный и стабильный функционал и которые привносят какуюто новую идею и подход.*

Ну как тут вас можно ещё понять, если вы говорите, что будете использовать start-spring-boot, потому что сами придерживаетесь подобного подхода? Вы же постоянно проговариваете про инженерный подход и всё такое. В ваших пяти недостатках плагина Init Spring нет вообще ничего про то, есть там какие-то возможности или их нет. Конечно я подумал, что для вас возможности плагина это не главное, что я ещё мог подумать?

Мы точно ходим по кругу. Я увидел только один аргумент - про валидацию артефактИд.

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

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

Если бы вы, например, сказали, что вам нравится, как браузер выглядит внутри IDE или что в Init Spring интерфейс получился хуже, чем в Spring Initlzr, я бы понял. Но вы говорите про какие-то другие качества, не имеющие отношения к тому, удобно пользоваться плагином, или нет.

Если интерфейс сделан на тулките, который использует IDE, он меньше бросается в глаза и на него приятнее смотреть. Если вы сами верстаете интерфейс, то вы можете сделать его лучше, чем в start.spring.io . А если вставили start.spring.io в IDE, то вот эти 100% - ваш потолок, сделать лучше вы не сможете ни за что и никогда.

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

Ещё раз проговорю, вы перечислили 5 минусов решения с точки зрения поддержки и разработки. А я указал на 1 минус с точки зрения того, удобно им пользоваться или нет. Неужели при выборе между двумя уже существующими плагинами вы будете руководствоваться тем, насколько сложно или просто их было разработать? Вы же сами написали, что нет. А если так, что почему 5 минусов, которые вы перечислили вообще имеют какой-то вес?

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

Для человека, который видит два плагина и хочет выбрать каким пользоваться, ресурсы, затраченные на разработку как правило не аргумент. Аргументом как правило является наличие фич и то самое субъективное удобство. А вы, обсуждая два уже разработанных плагина, почему-то делаете акцент на трудности разработки, а не на фичи и удобство. Рассуждаете так, как будто вам нужно сделать ещё один плагин и надо выбрать способ, который позволит достичь результата с наименьшими трудозатратами.

По моему это вы должны ответить на этот вопрос, а не я.

Нет, для того, чтобы отметить тот факт, что перечисленные вами минусы не касаются того, насколько удобно пользоваться плагином, не нужно отвечать на ещё какие-то дополнительные вопросы ))

Вы сами в своем ответе написали про "кусок браузера". Т.е. это не очевидно что он по умолчанию дает 100% возможностей от оригинала?

То, что он по умолчанию даёт 100% возможностей от оригинала очевидно, но что вы выбрали его именно поэтому - не очевидно. Особенно учитывая, что вы сами озвучили причины по которым вы его выбрали и среди них не было возможностей.

Есть много людей, которые выбирают софт не потому что в нём есть 100% возможностей, а потому что им нравится как он разрабатывается. Я подумал, что вы один из них.

Для меня он решает все проблемы.

Но теперь то вы всё-таки хотели сказать, что ваши проблемы решает не Init Spring, а start-spring-boot )) ? Или я опять ошибаюсь? А я как раз хотел спросить про Init Spring. Чего там не хватает? Какие ваши проблемы он не решает? Почему вы выбираете start-spring-boot, а не его?

Нет - мне трудно потомучто вы ничего по существу так и не пишете. Но все мои посты с конкретными аргументами кто то минусит.

Ваши аргументы это не аргументы за или против того, чтобы использовать плагин. Это аргументы за или против того, чтобы выбрать как разрабатывать плагин. Я бы очень хотел узнать конкретно почему вы не будете использовать Init Spring. Со мной и start-spring-boot всё понятно, я хотел бы видеть интерфейс IDE, а не браузера и я бы хотел поправить какие-то куски UX. А у вас получается, что вы привыкли к start-spring-boot, вот и всё.

Но ок - я вам верю, что это не вы.

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

Для этого нужны конкретные аргументы. А вы их так и не говорите. Мы ходим по кругу.

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

у вас в каждом абзаце одно и тоже почти - удобно/неудобно. а что не удобно так и не понятно

А мне непонятно почему вы выбираете не Init Spring, а start-spring-boot )) . А я вроде объяснил - мне не нравится видеть браузер в IDE и мне хочется немного поправить интерфейс

Я даже не представляю какие "колосальные нравственные страдания" надо испытать при создание проекта в https://start.spring.io/ чтобы об этом что то еще говорить.

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

Не очень понятно причем тут это?

Вы пишете, что код открыт. Понятно, что вас сразу спросят под какой лицензией )) .

Лизензия лишь запрещает открытое копирования и устанаваливает правообладателя - что по моему весьма логично.

Насколько я понимаю лицензия не стандартная, а какая-то особенная. Для того, чтобы понять, что имеется в виду под утверждением, что код открыт, судя по всему, нужен опытный юрист.

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

Странно что вы коментируете то, что я явно указал в своем исходном коментарии: "правда там нет лицензии. Но никто не мешает самому реализовать..."

Такое впечатление, что между словами вы хотели написать "Странно, что вы не комментируете", но пропустили "не". Я в своём комментарии хотел обратить внимание на то, что код плагина открытым считать не получается. А вы, видимо, считаете, что это в вашем тексте не главное и хотели бы в ответе увидеть объяснение, почему в плагине не реализован тот же подход, что в start-spring-boot. Но прямого вопроса вы не задали, поэтому я не понял, что надо на него отвечать ))

Чтобы так говорить, нужно сначала сказать чем неудобен и какую проблему не решает start-spring-boot

Чтобы обратить внимание на то, что среди перечисленных вами недостатков нет ничего, что касается удобства использования? Для того, чтобы можно было это сделать нужно сначала сказать чем неудобен и какую проблему не решает start-spring-boot?

Я же вам привел целых 5 минусов. Давайте говорить по существу.

Ещё раз повторюсь, что эти минусы не касаются того, насколько удобно пользоваться плагином, а касаются трудозатрат и всего такого. Я думаю, что эти аргументы хорошо прозвучали бы на какой-нибудь бизнес-встрече по планированию работ и оптимизации расходов. Там это разговор по существу. А тут, если хочется говорить по существу, имеет смысл указать на проблемы с которыми пользователь сталкивается, когда использует плагин.

Мне лично не нравится как выглядит start.spring.io в интерфейсе IDE, с моей точки зрения этого достаточно для того, чтобы выбрать не start-spring-boot, а Init Spring. Ну и, конечно, мне хотелось бы сделать интерфейс лучше, чем в start.spring.io. Например, там, если ввести artifactId с пробелом, в сгенерированном проекте пробел заменят на -, и пользователь узнает об этом только когда откроет сгенерированный проект. Можно было бы сразу в момент введения названия артефакта заменять пробел на - . Мелочи такого рода мне хотелось бы поправить.

Нет, я буду пользоваться им потомучто он на 100% идентичен оригиналу и решает ВСЕ проблемы.

Тогда почему вы не написали об этом раньше? Почему раньше вы написали, что будете использовать start-spring-boot т.к. сами придерживаетесь подобного подхода и уважаете такие решения? Кстати, какие проблемы сейчас не решает Init Spring?

все ресурсы на это тратит Спринг, а не мы. Именно это я и пытался донести в своем сообщении, но вы или не поняли или не хотите понять.

Да нет, я понял. Ещё раз обращу внимание, что вы рассматриваете ситуацию с точки зрения оптимизации ресурсов, а я предлагаю рассмотреть её с точки зрения удобства использования плагина. Я бы и про ресурсы поговорил, но тут, конечно, лучше подождать год-другой, чтобы увидеть сколько на самом деле усилий тратится на поддержку.

Но с вами трудно вести конструктивный диалог, учитывая реакцию под постами - минусы

Вам трудно вести конструктивный диалог, потому что вам кто-то в интернете поставил минус? Может быть вы думаете, что минус поставил я? Давайте созвонимся, я покажу экран, там будет видно, что минус поставил кто-то другой, я их редко ставлю.

вы по факту не назвали ни одного аргумента, а ограничились максимально абстрактными фразама - удобно/неудобно что 100% субъективщина.

Ну в общем, когда речь идёт об использовании плагина, то понятное дело речь пойдёт о том, удобно им пользоваться или нет. Странно, что вы об этом ничего не говорите ))

Explyt Spring, который также бесплатный и имеет открытый исходный код.

А какая лицензия у кода?

уже есть бесплтаная альтернатива, да еще и с открытым кодом, правда там нет лицензии

Правда нет лицензии. То есть код открыт не больше, чем скачанные с торрентов исходники Windows ))

А у решения что описано в статье полно недостаков:

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

но я по прежнему буду использовать start-spring-boot т.к. сам придерживаюсь подобного подхода и уважаю такие решения

То есть вы будете использовать start-spring-boot не потому что он удобнее, а из уважения к таким решениям ))

А так мы получаем очень много потенциальных затрат на поддержку, ради такого простого и маленького функционала.

Именно поэтому я, кстати, хочу ещё раз сказать спасибо Илье. Достаточно сложно делать плагин, когда тебе говорят, что уже есть плагин, который вставляет в IDE кусок браузера. И понимать, что хотя ты можешь сделать удобнее и красивее, ради этих последних 20% UX тебе придётся проделать ещё 80% работы, которую не факт что кто-то оценит.

По поводу плагина Init Spring хочу похвастаться, что на сегодняшний день Илья смёржил не два моих реквеста, а уже три! Большое спасибо Илье за Init Spring, я надеюсь силами сообщества мы доведём его до такого состояния, что новые спринговые проекты будут создавать только для того, чтобы посмотреть как красиво выглядит и как хорошо работает плагин ))

Призываю всех его попробовать и отписаться о найденных проблемах и о том, чего в плагине не хватает. Надеюсь это даст мне повод сделать ещё реквестов, а Илье выпустить ещё новых версий!

Что такого может рассказать спикер, чего не расскажет DeepSeek?

Расскажет что-то, по поводу чего вам не пришло в голову задавать вопросы )) .

чтобы потребитель мог не знать о реализации и не иметь зависимости от пакета с ней

А приём со структурой, который вы описали не даёт такой возможности?

Экспортируемые методы реализации это и есть контракт. Интерфейс тут ничего не улучшит.

А для чего тогда вообще интерфейсы нужны?

ну Михайл написал, что файнал можно менять всегда и любым способом

Всегда это в любой момент работы программы, а любым способом это на любое значение. Но может и правда тут преувеличение, которое может запутать.

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

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

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

Сложный вопрос. Но вот sun.misc.unsafe постепенно убирают насовсем, тут наверное та же история будет

кстати еще, долгое время существовал обычай финалить все поля у классов, что-бы гарантировать инициализацию без коллизий в многопоточке

Ну он никуда не делся ))

наверняка эти коды уже успели обрасти "решениями" всевозможных проблем на основе рефлексий и теперь они станут необновляемыми

Да, об этом есть замечание в статье

Но зато безопасники будут рады.

Безопасники вообще не знают что это всё такое. Рады будут разработчики, которые будут знать, что если они написали final, то это настоящий final, а не final курильщика

кстати, странно что для Михаила не стала откровением полная изменяемость ссылочных типов объявленных как final

Это не откровение потому что никто нам не помешает написать код, который поменяет значение полей объектов, даже если ссылка на объект записана в поле, на котором стоит final. А в том случае, котором мы говорим, нельзя написать код, который вписывает в final-поле новое значение и создаётся впечатление, что поменять значение этого поля вообще невозможно. А на самом деле это можно сделать с помощью рефлекшна.

кровавая история с десериализацией, возможно, связанна стем что final подразумевает однократную запись, т.е. она разрешена если ранее значение было не определено. Именно поэтому, мне кажется, он final а не const.

Когда мы говорим про десериализацию, то имеется в виду модификатор final на полях объектов, а не модификатор final на локальных переменных.

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

Статью надо было назвать Честный final!

Слово "integrity" можно перевести на русский по разному, но в разговорной речи оно чаще всего означает "честность". А в программировании его часто переводят как целостность и обычно это хорошо отражает смысл текста. Но тут был редкий случай перевести "integrity" как честность даже в контексте нашего любимого айти.

Integrity by Default в этой статье означает, что final в коде это действительно должен быть честный final, значение которого совершенно честно нельзя изменить никак и никому. Честность по умолчанию! Я бы перевёл так, жаль возможность упущена.

Хороший, кстати, вопрос. Можете кого-нибудь порекомендовать?

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

В холиваре же нельзя победить, на то он и холивар. Можно только лучше ознакомиться с чужой точкой зрения и лучше выразить свою. За это мы их и любим ))

Итого: final нужно тогда когда нужно.
Не final нужно тогда когда нужно.

Если так, то перед каждым классом или переменной нужно либо поставить модификатор non-final, либо final. Без модификатора код компилироваться не должен.

надо дизайнить так, чтобы оставлять возможность расширения и наследования

Это сложно, мало кто умеет. Поэтому ограничения в виде приватных классов и тому подобного можно встретить во многих популярных фреймворках. Вот с Спринге например

Нравится вам или нет, но наследование является неотъемлимым и одним из ключевых свойств ООП.

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

Ну когда я делал дома ремонт, то да, этого вполне достаточно

Внезапно

с учётом инженерного образования в вузе и базового знания электротехники и свойств материалов

Я думаю, что впринципе если ты умеешь программировать, то ты сможешь работать программистом, да )))

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

1
23 ...

Информация

В рейтинге
4 189-й
Работает в
Дата рождения
Зарегистрирован
Активность