за все точно не надо. это недостижимая высота. но и сидеть в 2017 году на redmine при наличии средств перейти на Jira и главное все время повторяя, что перейдем… и даже из него не выжимая ничего кроме списка задач как в Excel. использовать Jenkins только для сборок и ни разу для тестирования — потому что так «истерически сложилось» (не фиксить тесты тоже сложилось). всерьез ставить вопрос «а давайте уберем нексус. лишний компонент вносит риск в систему»… это уже явный перебор.
ну а если новое не складывается — нечего будет писать в резюме) и развитие замрет само собой.
Я в Самаре когда-то уперся в потолок. В итоге перебрался в Москву года 4 назад. Платить чужим людям за съем, конечно, обидно, но с ростом навыка повышается оклад. Есть надежда, что к концу этого года будет уже свое жилье.
А утверждение, что «там все родственники»… в век самолетов родители сами будут рады, что вы свою жизнь устроите. еще и летать в гости будут.
Ни в коем случае не призываю писать с ходу заявление и ехать в слепую. Лично я составил резюме, напланировал встреч и поехал в отпуск в столицу) Попытаться в любом случае стоило. Удачи Вам.
Статья прекрасная. Полностью отражает текущий рынок IT с точки зрения backend-разработчика.
Единственное позволю себе дополнить утверждение о синдроме исполнителя. встречал руководителей, которые довольно не плохо разбираются в используемых фреймворках, но все новое встречают в штыки именно потому, что для поддержания компетенции им придется выучить что-то новое. Это уже не синдром, а банальная лень. Как печальный итог — вся команда сидит на старых артефактах и процессах и за слово «agile» могут облить бензином и поджечь.
Доказывать, что новые подходы в первую очередь будут экономить время и ресурсы бесполезно.
зато обещаний как у Колумба) «мы перейдем на Jira… мы перейдем на NoSQL...»
еще веселее с вью)
попробовал сейчас с Datagrip выполнить сравнение (хоть инструмент и сыроват местами, но чего ждать от недавно вышедшего продукта).
вместо вьюшки мне было предложено создать таблицу. не знаю, изобретался ли там велосипед — проблема может быть общей.
creates output with DDL statements that can be used to update old database schema to new one
даже на уровне только схемы часто возникают коллизии. как минимум большинство подобных инструментов (за данный конкретный не скажу) работают исключительно на добавление.
а есть еще данные, которые нужно как-то мержить между площадками.
если ветка отводилась на месяц — два (такое при крупных переработках случается часто) — это чревато большим количеством ручных операций. всегда можно что-то где-то недоглядеть. опасно. особенно если плохо налажено тестирование.
да, вы правы. тут у меня логическая ошибка. отслеживается результат второго выражения. подпилю.
за ссылки огромнейшее спасибо — ознакомлюсь то ли это.
атомарность миграции вещь полезная, но не обязательная. предложенный принцип работы таков, что все отрабатывает как с бусинками. нанизываются команды одна за другой. если встретим проблему — работа прекратится и продолжится со скрипта, который не прошел. хотя в случае обрыва связи вопрос. надо проверить опытом.
даунгрейд в текущей реализации не предусмотрен. хотя для себя я всегда держу rollback скрипты к каждому изменению (где это возможно, разумеется).
этот принцип работает для всех многомодульных приложений. так что вы тут абсолютно правы. но в статье нет завязки, что все изменения в базе должны быть немедленно отражены в коде. обратную совместимость никто не отменял.
ограничилось «я подумаю» месяца 3 назад.
ну а если новое не складывается — нечего будет писать в резюме) и развитие замрет само собой.
А утверждение, что «там все родственники»… в век самолетов родители сами будут рады, что вы свою жизнь устроите. еще и летать в гости будут.
Ни в коем случае не призываю писать с ходу заявление и ехать в слепую. Лично я составил резюме, напланировал встреч и поехал в отпуск в столицу) Попытаться в любом случае стоило. Удачи Вам.
Единственное позволю себе дополнить утверждение о синдроме исполнителя. встречал руководителей, которые довольно не плохо разбираются в используемых фреймворках, но все новое встречают в штыки именно потому, что для поддержания компетенции им придется выучить что-то новое. Это уже не синдром, а банальная лень. Как печальный итог — вся команда сидит на старых артефактах и процессах и за слово «agile» могут облить бензином и поджечь.
Доказывать, что новые подходы в первую очередь будут экономить время и ресурсы бесполезно.
зато обещаний как у Колумба) «мы перейдем на Jira… мы перейдем на NoSQL...»
попробовал сейчас с Datagrip выполнить сравнение (хоть инструмент и сыроват местами, но чего ждать от недавно вышедшего продукта).
вместо вьюшки мне было предложено создать таблицу. не знаю, изобретался ли там велосипед — проблема может быть общей.
даже на уровне только схемы часто возникают коллизии. как минимум большинство подобных инструментов (за данный конкретный не скажу) работают исключительно на добавление.
а есть еще данные, которые нужно как-то мержить между площадками.
за ссылки огромнейшее спасибо — ознакомлюсь то ли это.
атомарность миграции вещь полезная, но не обязательная. предложенный принцип работы таков, что все отрабатывает как с бусинками. нанизываются команды одна за другой. если встретим проблему — работа прекратится и продолжится со скрипта, который не прошел. хотя в случае обрыва связи вопрос. надо проверить опытом.
даунгрейд в текущей реализации не предусмотрен. хотя для себя я всегда держу rollback скрипты к каждому изменению (где это возможно, разумеется).