Pull to refresh
44
0.1
Валерий Вырва @valery1707

Java backend

Send message

Согласен с 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 (свежее на русском, причём в вашем же блоге):


  • Чистая Java
  • Spring
  • Нет специфических слоёв доступа к данным
  • Правда авторизацию, скорее всего, нужно будет писать самому, но один раз за проект и вообще можно из проекта в проект таскать

В общем как мне кажется, у Vaadin те же плюсы (и даже больше), зато нет минусов CUBA.

Создаются классы предметной области и на них ставятся аннотации @Table, @Entity и.т.д.
Затем эти классы регистрируются в файле persistence.xml.

Руками каждый класс? Или хотя бы можно ограничиться только пакетом?


Рекомендуется использовать аннотацию @NamePattern — аналог метода toString() для читабельного отображения сущностей в пользовательском интерфейсе.

А это есть в Lombok. В купе с прочим скрытием бойлерплейта.


Полезные маркер-интерфейсы, которые дают дополнительные возможности
Versioned, SoftDelete, Updatable, Creatable

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


Скрипты для создания и обновления БД генерируются автоматически при помощи CUBA Studio.

Так умеет Hibernate, но я считаю что ручное написание скриптов даёт не только больше контроля, но и на порядок больше возможностей…
Возьмите Flyway/Liquibase — и в перёд. Хоть чистый SQL, хоть XML с валидацией, хоть DSL.


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

И это умеет Spring Data JPA: Projections


Дополнительно нужно зарегистрировать сервисы в файле web-spring.xml в модуле Web.

А в Spring Boot xml-файлы уже давно не нужны.


Сейчас ведется борьба с уменьшением XML, переходим на аннотации там, где возможно.

Тут или логическая ошибка или вы не с тем боритесь.

После стольких лет существования дженериков в Java есть ещё не знакомые с темой?

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


  • это номер телефона
  • определённого профиля пользователя Хабра
  • в профиле есть ФИО (хотя и не полное), адрес (не точный)
  • к этому можно добавить ваш IP в момент указания телефона

И вот уже всё не так и просто.


Хотя я и не юрист — могу ошибаться.

нет транспарентности

А что помешало вам написать нет прозрачности?

А почему в README.md?
Как по мне, там нужны общая информация о проекте: что зачем и почему, и уж точно там не место описаниям всех коммитов.
Ладно бы ещё CHANGELOG, но и там не каждый коммит подробно расписывают, а ведут лог изменений.

набрать текст многим дольше чем нажать кнопку

А код они как набирают? :)

Я просто показывал что есть задачи которые удобнее выполнить в CLI.
Я нигде не призывал использовать только CLI.

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

А вот тут можно подробнее?
Если вы про скрипт — да, можно и так, но пока мне удобнее скопировать и вставить из файлика.
Или есть что-то более критичное?

Так и использование CLI не есть призыв отказаться от GUI :)

Ну в GUI вам названия веток всё равно нужны :)
Я не предлагаю отказываться от GUI, я абсолютно согласен с тем что многие вещи в GUI удобнее.
Просто некоторые вещи мне проще и быстрее сделать через CLI.

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

Да чего тут интересного-то?
Всего лишь ребейз ветки.
Но нужно:


  • отложить локальные незакоммиченные изменения (и вернуть их в конце назад)
  • обновить ту ветку на которую будем ребейзить
  • обновить ту ветку которую будем ребейзить (я иногда ребейз выполняю в отдельной папке чтобы не трогать текущую папку)
  • собственно прогнать ребейз
  • обновить таск-ветку на сервере
  • влить таск-ветку в RC-ветку и залить RC-ветку на сервер

Ничего сложного или интересного.
Но сделать это через 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

Расскажите как это накликать в GUI :)

У нас баги описывают правильно, с шагами, что ожидалось и что получилось. Формулировок «Ничего не работает» не пишут.

Вам повезло. Вот правда.


Разница между тикетом и коммитом состоит в том что


  • тикет может создать много кто (внутренний тестер, внешний тестер, разработчик, аналитик, заказчик) и не от всех можно ожидать (тем более требовать) полноценного описания
  • коммит пишет разработчик — вот от него нужно ожидать (как минимум!) возможность описать зачем он сделал эти изменения
  • в тикете может быть много обсуждений бага, даже корректно описанного (шаги воспроизведения, окружение, выбор решения проблемы и прочее (про меню это была гипербола, конечно))
  • в коммите описывается конечный результат
  • в тикете не всю информацию стоит раскрывать (показывать заказчику что у нас была огромная дырень в безопасности, которую мы закроем при обновлении через 2 месяца — вот он обрадуется прямо сейчас, ага)
  • коммит внутренний ресурс (обычно) и там можно писать всё что угодно

Писать кучу текста в коммит и дублировать в таск-трекер — вот такого не должно быть.

Я и не говорил про дублирование.
В тикете не всегда обязательно писать полное описание причин ошибки и методов её устранения.


У на это таск-трекер. Если у вас это коммиты, ну ок, хотя лично мне было бы неудобно, наверно.

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

О, а расскажите как, я скину, тому кто делал переход.

7 (семь!, боже как давно) лет назад я сделал это примерно так: https://github.com/valery1707/docs-linux/blob/master/vcs/git-svn-convert.txt


С тех пор много воды утекло — что-то могло и измениться, но не думаю что сейчас невозможно нормально мигрировать с TFS на GIT/HG/Whatever — скорее всего плохо искали.
Более того, я уверен что вам историю коммитов можно даже и восстановить, если остался доступ к TFS: сначала мигрировать корректно, а потом наложить все коммиты что вы создали позднее.

А про «А потом команда перешла с Jira на аналог и все ваши номера стали пустым местом» можно также ответить — плохо переходили, раз не смогли сохранить номера.

Можно, но тут сложнее.


Я когда переходил с SVN на GIT сохранил всю историю коммитов с комментариями авторами и датами.

Заметьте что тут я не говорил про идентификаторы коммитов — их невозможно сохранить.


Та же фигня будет и с тикетами:


  • сохранить сами тикеты можно в 99% случаев
    Куча примеров миграции с Google Code на Github тому подтверждение
  • сохранить автора тикета уже сложнее — для начала такого пользователя просто может не быть на момент миграции или вообще в организационной структуре
    Автор коммита же может быть хоть Дэвид блэйн
  • сохранить комментарии тоже скорее всего получится
  • сохранить автора/дату комментария уже сложнее — автора по причине выше, а дату не все системы позволят изменить задним числом через API, а в БД залесть можно только на self-hosted вариантах
  • а вот идентификатор тикета сохранить почти наверняка не выйдёт из-за специфики нумерации в исходной и целевой системах
    Jira требует указание уникального префикса и потом номера уникального в рамках префикса
    У кого-то номера уникальны в рамках всей системы
    И т.д. и т.п.

Самое важное в последнем пункте — в коммите ссылаются на идентификатор тикета, а вот идентификатор тикета сохранить очень сложно.
И в результате нумерация или:


  • съедет на N цифр с какую-то сторону (по определённого тикета, а потом опять будет совпадать — вот веселье-то)
  • вовсе не будет никогда совпадать (переехали с Jira на Github)

Information

Rating
3,764-th
Location
Воронеж, Воронежская обл., Россия
Date of birth
Registered
Activity