Согласен с APXEOLOG — собрать вместе Spring Boot, Hibernate, Flyway/Liquibase, REST занимает максимум вечер. Ещё чуть-чуть времени займёт авторизация.
Всё не так страшно как вы описываете.
За столько лет существования рифм уже написано много статей, книг и прочей литературы с полным разбором всего и вся.
И для Java Generics ситуация ровно такая же: есть и вводные курсы и подробное описание всё есть.
Зачем оно тут? Я вот даже не уверен что это 100% авторский контент — есть ощущение что эти примеры я уже видел.
Java Generics появились в JDK 1.5, которая вышла 30 сентября 2004 года — через пару месяцев им будет 14 лет. Знаете когда эта статья была полезна? 14 лет назад — вообще must have, ну лет 10 назад (хотя и так уже было много литературы).
А сейчас?
Есть свежие технологии — да хотя бы лямбды — им всего 4 года (четыре, не четырнадцать).
Ну и по ним уже есть много литературы, как англоязычной, так и русскоязычной.
Создаются классы предметной области и на них ставятся аннотации @Table, @Entity и.т.д.
Затем эти классы регистрируются в файле persistence.xml.
Руками каждый класс? Или хотя бы можно ограничиться только пакетом?
Рекомендуется использовать аннотацию @NamePattern — аналог метода toString() для читабельного отображения сущностей в пользовательском интерфейсе.
А это есть в Lombok. В купе с прочим скрытием бойлерплейта.
Полезные маркер-интерфейсы, которые дают дополнительные возможности Versioned, SoftDelete, Updatable, Creatable
Это всё умеет и Spring через аннотации, причём аннотации гибче интерфейсов — можно использовать удобные для тебя имена полей.
Скрипты для создания и обновления БД генерируются автоматически при помощи CUBA Studio.
Так умеет Hibernate, но я считаю что ручное написание скриптов даёт не только больше контроля, но и на порядок больше возможностей…
Возьмите Flyway/Liquibase — и в перёд. Хоть чистый SQL, хоть XML с валидацией, хоть DSL.
Концепция “представлений” в CUBA может показаться несколько непривычной, но она достаточно легко объясняется.
Представление — это декларативный способ объявления атрибутов, значения которых необходимо извлечь из хранилища данных.
Вот конкретно сейчас я бы сказал что это персональные данные.
Предполагается что в приложение пользователь вводит свой номер, и если применить это же предположение к вашему номеру, то получается что это уже не просто набор цифр:
это номер телефона
определённого профиля пользователя Хабра
в профиле есть ФИО (хотя и не полное), адрес (не точный)
к этому можно добавить ваш IP в момент указания телефона
А почему в README.md?
Как по мне, там нужны общая информация о проекте: что зачем и почему, и уж точно там не место описаниям всех коммитов.
Ладно бы ещё CHANGELOG, но и там не каждый коммит подробно расписывают, а ведут лог изменений.
Все приведенные тут остальные использования git, где командная строка клеится через && некорректны.
А вот тут можно подробнее?
Если вы про скрипт — да, можно и так, но пока мне удобнее скопировать и вставить из файлика.
Или есть что-то более критичное?
Ну в GUI вам названия веток всё равно нужны :)
Я не предлагаю отказываться от GUI, я абсолютно согласен с тем что многие вещи в GUI удобнее.
Просто некоторые вещи мне проще и быстрее сделать через CLI.
Ну значит у вас флоу не предполагает ребейза, а если кто и делает ребейз веток, то это не часто.
У нас вот флоу такой — может они и не идеальный, но тут решение принимал не я.
Но и наш флоу, прямо скажем, не уникальный.
Ну или вот есть задачка с которой я часто сталкиваюсь: пересортировка/объединение коммитов в ветке.
Через CLI это быстро: git stash && git rebase --interactive origin/RC/1.3.0 && git stash pop и там уже можно переставлять объединять коммиты как хочется.
Причём обычно это команда вызывает не один раз, а несколько: сначала переставить и проверить что оно отработало, потом уже объеденить.
Как это быстро делать через GUI я даже не скажу на вскидку.
А уж как разбить один коммит на несколько отдельных в GUI я вообще не знаю.
А такая задача встречается по нескольку раз в несколько месяцев.
В смысле — сначала собрал большой коммит и уже потом понял что лучше было разбить на несколько атомарных и вообще их пересортировать.
Вот у нас во флоу есть такая задачка: перед вливанием таск-ветки в RC-ветку её нужно отребейзить на RC-ветку.
Это, конечно, не ежедневная задача, но пару раз в неделю — легко.
Вот так это делается через CLI:
git stash && mvn clean -P coverage && git co master && git pull && git co RC/1.3.0 && git pull && git co CBRPIS-1052 && git pull && git rebase RC/1.3.0 && git push -f && git co RC/1.3.0 && git merge --ff-only CBRPIS-1052 && git push && git br -d CBRPIS-1052 && git stash pop
Ну можно выкинуть зачистку проекта и проход через master:
git stash && git co RC/1.3.0 && git pull && git co CBRPIS-1052 && git pull && git rebase RC/1.3.0 && git push -f && git co RC/1.3.0 && git merge --ff-only CBRPIS-1052 && git push && git stash pop
У нас баги описывают правильно, с шагами, что ожидалось и что получилось. Формулировок «Ничего не работает» не пишут.
Вам повезло. Вот правда.
Разница между тикетом и коммитом состоит в том что
тикет может создать много кто (внутренний тестер, внешний тестер, разработчик, аналитик, заказчик) и не от всех можно ожидать (тем более требовать) полноценного описания
коммит пишет разработчик — вот от него нужно ожидать (как минимум!) возможность описать зачем он сделал эти изменения
в тикете может быть много обсуждений бага, даже корректно описанного (шаги воспроизведения, окружение, выбор решения проблемы и прочее (про меню это была гипербола, конечно))
в коммите описывается конечный результат
в тикете не всю информацию стоит раскрывать (показывать заказчику что у нас была огромная дырень в безопасности, которую мы закроем при обновлении через 2 месяца — вот он обрадуется прямо сейчас, ага)
коммит внутренний ресурс (обычно) и там можно писать всё что угодно
Писать кучу текста в коммит и дублировать в таск-трекер — вот такого не должно быть.
Я и не говорил про дублирование.
В тикете не всегда обязательно писать полное описание причин ошибки и методов её устранения.
У на это таск-трекер. Если у вас это коммиты, ну ок, хотя лично мне было бы неудобно, наверно.
Удобство — понятие относительное.
Мне вот удобно всё видеть в коммитах потому что я могу прямо из среды разработки в offline в отпуске на Багамах в туалете понять что и зачем происходили в классе. Да хоть из консоли, лишь бы исходники были.
А вам исходников не достаточно — нужен доступ ещё и к таск-трекеру. Причём не только сетевой доступ, но и организационный. Ну ок.
С тех пор много воды утекло — что-то могло и измениться, но не думаю что сейчас невозможно нормально мигрировать с TFS на GIT/HG/Whatever — скорее всего плохо искали.
Более того, я уверен что вам историю коммитов можно даже и восстановить, если остался доступ к TFS: сначала мигрировать корректно, а потом наложить все коммиты что вы создали позднее.
А про «А потом команда перешла с Jira на аналог и все ваши номера стали пустым местом» можно также ответить — плохо переходили, раз не смогли сохранить номера.
Можно, но тут сложнее.
Я когда переходил с SVN на GIT сохранил всю историю коммитов с комментариями авторами и датами.
Заметьте что тут я не говорил про идентификаторы коммитов — их невозможно сохранить.
Та же фигня будет и с тикетами:
сохранить сами тикеты можно в 99% случаев
Куча примеров миграции с Google Code на Github тому подтверждение
сохранить автора тикета уже сложнее — для начала такого пользователя просто может не быть на момент миграции или вообще в организационной структуре
Автор коммита же может быть хоть Дэвид блэйн
сохранить комментарии тоже скорее всего получится
сохранить автора/дату комментария уже сложнее — автора по причине выше, а дату не все системы позволят изменить задним числом через API, а в БД залесть можно только на self-hosted вариантах
а вот идентификатор тикета сохранить почти наверняка не выйдёт из-за специфики нумерации в исходной и целевой системах
Jira требует указание уникального префикса и потом номера уникального в рамках префикса
У кого-то номера уникальны в рамках всей системы
И т.д. и т.п.
Самое важное в последнем пункте — в коммите ссылаются на идентификатор тикета, а вот идентификатор тикета сохранить очень сложно.
И в результате нумерация или:
съедет на N цифр с какую-то сторону (по определённого тикета, а потом опять будет совпадать — вот веселье-то)
вовсе не будет никогда совпадать (переехали с Jira на Github)
Согласен с APXEOLOG — собрать вместе Spring Boot, Hibernate, Flyway/Liquibase, REST занимает максимум вечер. Ещё чуть-чуть времени займёт авторизация.
Всё не так страшно как вы описываете.
За столько лет существования рифм уже написано много статей, книг и прочей литературы с полным разбором всего и вся.
И для Java Generics ситуация ровно такая же: есть и вводные курсы и подробное описание всё есть.
Зачем оно тут? Я вот даже не уверен что это 100% авторский контент — есть ощущение что эти примеры я уже видел.
Java Generics появились в JDK 1.5, которая вышла 30 сентября 2004 года — через пару месяцев им будет 14 лет. Знаете когда эта статья была полезна? 14 лет назад — вообще must have, ну лет 10 назад (хотя и так уже было много литературы).
А сейчас?
Есть свежие технологии — да хотя бы лямбды — им всего 4 года (четыре, не четырнадцать).
Ну и по ним уже есть много литературы, как англоязычной, так и русскоязычной.
А вообще лучше расскажите чем CUBA лучше чем Vaadin (свежее на русском, причём в вашем же блоге):
В общем как мне кажется, у Vaadin те же плюсы (и даже больше), зато нет минусов CUBA.
Руками каждый класс? Или хотя бы можно ограничиться только пакетом?
А это есть в Lombok. В купе с прочим скрытием бойлерплейта.
Это всё умеет и
Spring
через аннотации, причём аннотации гибче интерфейсов — можно использовать удобные для тебя имена полей.Так умеет Hibernate, но я считаю что ручное написание скриптов даёт не только больше контроля, но и на порядок больше возможностей…
Возьмите Flyway/Liquibase — и в перёд. Хоть чистый SQL, хоть XML с валидацией, хоть DSL.
И это умеет Spring Data JPA: Projections
А в Spring Boot xml-файлы уже давно не нужны.
Тут или логическая ошибка или вы не с тем боритесь.
После стольких лет существования дженериков в Java есть ещё не знакомые с темой?
Вот конкретно сейчас я бы сказал что это персональные данные.
Предполагается что в приложение пользователь вводит свой номер, и если применить это же предположение к вашему номеру, то получается что это уже не просто набор цифр:
И вот уже всё не так и просто.
Хотя я и не юрист — могу ошибаться.
А что помешало вам написать
нет прозрачности
?А почему в
README.md
?Как по мне, там нужны общая информация о проекте: что зачем и почему, и уж точно там не место описаниям всех коммитов.
Ладно бы ещё
CHANGELOG
, но и там не каждый коммит подробно расписывают, а ведут лог изменений.А код они как набирают? :)
Я просто показывал что есть задачи которые удобнее выполнить в CLI.
Я нигде не призывал использовать только CLI.
А вот тут можно подробнее?
Если вы про скрипт — да, можно и так, но пока мне удобнее скопировать и вставить из файлика.
Или есть что-то более критичное?
Так и использование CLI не есть призыв отказаться от GUI :)
Ну в GUI вам названия веток всё равно нужны :)
Я не предлагаю отказываться от GUI, я абсолютно согласен с тем что многие вещи в GUI удобнее.
Просто некоторые вещи мне проще и быстрее сделать через CLI.
Ну значит у вас флоу не предполагает ребейза, а если кто и делает ребейз веток, то это не часто.
У нас вот флоу такой — может они и не идеальный, но тут решение принимал не я.
Но и наш флоу, прямо скажем, не уникальный.
Да чего тут интересного-то?
Всего лишь ребейз ветки.
Но нужно:
Ничего
сложного
илиинтересного
.Но сделать это через GUI явно будет не так быстро и просто как через CLI.
И это даже не уникальная вещь, пример которой вы просили.
Самая обычная задачка.
Ну или вот есть задачка с которой я часто сталкиваюсь: пересортировка/объединение коммитов в ветке.
Через CLI это быстро:
git stash && git rebase --interactive origin/RC/1.3.0 && git stash pop
и там уже можно переставлять объединять коммиты как хочется.Причём обычно это команда вызывает не один раз, а несколько: сначала переставить и проверить что оно отработало, потом уже объеденить.
Как это быстро делать через GUI я даже не скажу на вскидку.
А уж как разбить один коммит на несколько отдельных в GUI я вообще не знаю.
А такая задача встречается по нескольку раз в несколько месяцев.
В смысле — сначала собрал большой коммит и уже потом понял что лучше было разбить на несколько атомарных и вообще их пересортировать.
Вот у нас во флоу есть такая задачка: перед вливанием таск-ветки в RC-ветку её нужно отребейзить на RC-ветку.
Это, конечно, не ежедневная задача, но пару раз в неделю — легко.
Вот так это делается через CLI:
Ну можно выкинуть зачистку проекта и проход через
master
:Расскажите как это накликать в GUI :)
Вам повезло. Вот правда.
Разница между тикетом и коммитом состоит в том что
требовать
) полноценного описанияЯ и не говорил про дублирование.
В тикете не всегда обязательно писать полное описание причин ошибки и методов её устранения.
Удобство — понятие относительное.
Мне вот удобно всё видеть в коммитах потому что я могу прямо из среды разработки в offline в отпуске на Багамах в туалете понять что и зачем происходили в классе. Да хоть из консоли, лишь бы исходники были.
А вам исходников не достаточно — нужен доступ ещё и к таск-трекеру. Причём не только сетевой доступ, но и организационный. Ну ок.
7 (семь!, боже как давно) лет назад я сделал это примерно так: https://github.com/valery1707/docs-linux/blob/master/vcs/git-svn-convert.txt
С тех пор много воды утекло — что-то могло и измениться, но не думаю что сейчас невозможно нормально мигрировать с TFS на GIT/HG/Whatever — скорее всего плохо искали.
Более того, я уверен что вам историю коммитов можно даже и восстановить, если остался доступ к TFS: сначала мигрировать корректно, а потом наложить все коммиты что вы создали позднее.
Можно, но тут сложнее.
Заметьте что тут я не говорил про идентификаторы коммитов — их невозможно сохранить.
Та же фигня будет и с тикетами:
Куча примеров миграции с Google Code на Github тому подтверждение
Автор коммита же может быть хоть Дэвид блэйн
Jira требует указание уникального префикса и потом номера уникального в рамках префикса
У кого-то номера уникальны в рамках всей системы
И т.д. и т.п.
Самое важное в последнем пункте — в коммите ссылаются на идентификатор тикета, а вот идентификатор тикета сохранить очень сложно.
И в результате нумерация или: