ну дык про это и речь. Не коммитить тысячи файлов

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

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

? да для этого же менеджер зависимостей придумали? Чтобы там версионность сохранялась

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

У кого был вендор закоммичен - тот плечами пожал и продолжил работу

Но вот что мне каждый раз интересно

Что вы видите плохого в коммите вендора?

там есть недостатки

какие?

самый простой - в коммит попадают не только твои изменения, но и изменения в vendor

это может затруднять code review

а из менеджеров зависимостей есть только glide?

заливай вендора отдельно в пулл реквесте

это не всегда возможно

это не всегда возможно

а когда это не так?

например, твои изменения в коде требуют новую версию стороннего пакета. А старый код с новой версией не работает

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

так а в чем проблема в две ветки пулл реквестнуть?

дак не кидай ревест в девелоп )

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

причём здесь бранчи?

для зависимостей одна, для твоего кода вторая. Потом одновременно смержить

не так часто такое возникает

вы кажется не понимаете

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

поэтому коммитить по отдельности нельзя

а вендор тянуть со стороны можно?

вендор можно тянуть с локального форка

и в свой репозиторий только Gopkg.lock коммитить

при сборке делать dep ensure

разумеется, я не ратую за это как за единственно правильное решение. просто альтернатива

при этом вы отвязаны от внешних зависимотей локальным форком, а повторяемость билдов выполняется через gopkg.lock

Это все какашка, все эти воркэраунды, бояться удаления стороннего популярного репозитория - это то же самое что и бояться летать на самолетах. С такой же вероятностью ваш самолет упадет, с какой если удалят репозиторий, который вы используете, на который вы не сможете найти замену быстро, на которого у вас и ваших коллег не будет ни локальных копий, ни бекапов на серверах, ни менеджера зависимостей не сможет подтянуть данные из кеша, и ваше приложение не сможет жить без этого удаленного репозитория. По мне так это попахивает параноей после какого-то определенного случая, который врядли кого-то коснулся из зедсь присутствующих. Но я могу ошибаться, не ради холивара все это, а так, подытожить. Вообщем, я не нашел аргументов в пользу, кроме как "а вдруг все надъ**нется, а мы в пустыне и у нас нет интернета". А в остальном - вендоры в репе действительно затрудняют код ревью при апдейте зависимостей. Когда у тебя микросервисная архитектура и в каждом сервисе по 3 файла рабочих - репозитории могут напоминать свалку из кода, к которому никто не притронется на протяжении всей жизни приложения. Всем спасибо за ответы!

это не всегда возможно

с фига ли?

выше

Это все какашка, все эти воркэраунды, бояться удаления стороннего популярного репозитория - это то же самое что и бояться летать на самолетах. С такой же вероятностью ваш самолет упадет, с какой если удалят репозиторий, который вы используете, на который вы не сможете найти замену быстро, на которого у вас и ваших коллег не будет ни локальных копий, ни бекапов на серверах, ни менеджера зависимостей не сможет подтянуть данные из кеша, и ваше приложение не сможет жить без этого удаленного репозитория. По мне так это попахивает параноей после какого-то определенного случая, который врядли кого-то коснулся из зедсь присутствующих. Но я могу ошибаться, не ради холивара все это, а так, подытожить. Вообщем, я не нашел аргументов в пользу, кроме как "а вдруг все надъ**нется, а мы в пустыне и у нас нет интернета". А в остальном - вендоры в репе действительно затрудняют код ревью при апдейте зависимостей. Когда у тебя микросервисная архитектура и в каждом сервисе по 3 файла рабочих - репозитории могут напоминать свалку из кода, к которому никто не притронется на протяжении всей жизни приложения. Всем спасибо за ответы!

у меня для тебя плохие новости.

это может затруднять code review

Надо осилить .gitattributes, и они не будут

Это все какашка, все эти воркэраунды, бояться удаления стороннего популярного репозитория - это то же самое что и бояться летать на самолетах. С такой же вероятностью ваш самолет упадет, с какой если удалят репозиторий, который вы используете, на который вы не сможете найти замену быстро, на которого у вас и ваших коллег не будет ни локальных копий, ни бекапов на серверах, ни менеджера зависимостей не сможет подтянуть данные из кеша, и ваше приложение не сможет жить без этого удаленного репозитория. По мне так это попахивает параноей после какого-то определенного случая, который врядли кого-то коснулся из зедсь присутствующих. Но я могу ошибаться, не ради холивара все это, а так, подытожить. Вообщем, я не нашел аргументов в пользу, кроме как "а вдруг все надъ**нется, а мы в пустыне и у нас нет интернета". А в остальном - вендоры в репе действительно затрудняют код ревью при апдейте зависимостей. Когда у тебя микросервисная архитектура и в каждом сервисе по 3 файла рабочих - репозитории могут напоминать свалку из кода, к которому никто не притронется на протяжении всей жизни приложения. Всем спасибо за ответы!

https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/

Надо осилить .gitattributes, и они не будут

тут не в курсе, чем это может помочь

ну это то, из-за чего весь хайп? 2016-год?

Примерно раз в год что-то случается

тут не в курсе, чем это может помочь

А вот. Там можно запретить показывать дифф для определенных путей

Но

ну это то, из-за чего весь хайп? 2016-год?

это проблема, которая легко решается складированием у себя. Если проблема решается легко, то почему бы её не решить?

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

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

Не понятно. Я вот пытаюсь выяснить

Это все какашка, все эти воркэраунды, бояться удаления стороннего популярного репозитория - это то же самое что и бояться летать на самолетах. С такой же вероятностью ваш самолет упадет, с какой если удалят репозиторий, который вы используете, на который вы не сможете найти замену быстро, на которого у вас и ваших коллег не будет ни локальных копий, ни бекапов на серверах, ни менеджера зависимостей не сможет подтянуть данные из кеша, и ваше приложение не сможет жить без этого удаленного репозитория. По мне так это попахивает параноей после какого-то определенного случая, который врядли кого-то коснулся из зедсь присутствующих. Но я могу ошибаться, не ради холивара все это, а так, подытожить. Вообщем, я не нашел аргументов в пользу, кроме как "а вдруг все надъ**нется, а мы в пустыне и у нас нет интернета". А в остальном - вендоры в репе действительно затрудняют код ревью при апдейте зависимостей. Когда у тебя микросервисная архитектура и в каждом сервисе по 3 файла рабочих - репозитории могут напоминать свалку из кода, к которому никто не притронется на протяжении всей жизни приложения. Всем спасибо за ответы!

аргументы должны быть с другой стороны, с vendor в репозитории, для сборки проекта нужен go и репозиторий, при вашем подходе нужен go dep и время на выкачку зависимостей, папку vendor в код ревью можно пропускать, для микросервисов, на моей практике монорепы, vendor 1, и свалки нет

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

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

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

вут?

ну это гипотетически :)

гипотетический вут тогда :)

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

пускай закинет необходимую лицензию в стиле "нон фор комертион юз" или не выставляет свой код куда попало

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

Не понятно. Я вот пытаюсь выяснить

Всё по тем же причинам, по которым они ненавидят Голанг - because it challenges their identity, and other people are falling for it.

Да вот я связи между вендором и идентити увидеть не могу

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

Да вот я связи между вендором и идентити увидеть не могу

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

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

Ну - добавим секцию в Gopkg.toml

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

ой да ладно. vgo от сладкой жизни придумали, да?

везде свои проблемы

вот эта вот прибитая гвоздями структура pkg/bin/src

ERROR: S client not available

ой да ладно. vgo от сладкой жизни придумали, да?

gc тоже с каждой версией становится лучше, следует ли из этого сделать вывод что он плохой?

нет конечно. но в vgo подход то меняется

Нет пока никакого vgo

против этого аргумента не могу ничего сказать :)

Ребята, кто может подсказать требования к мидлу гоферу?

про мидла, и почему они везде разные: "оценка всегда зависит от оценивающего" (с)

Ребята, кто может подсказать требования к мидлу гоферу?

Могу ответить про джуниоров. Как показывает история канала (и смежных) - от них требуется микросервисная архитектура, параллельное программирование, понимание всех шаблонов проектирования, алгоритмики, архитектуры распределенки или хайлоада; 1-3 года опыта работы на go, ну и, конечно, этот язык должен идти в дополнение либо к питону, либо к жаве. Не считая всяких кубернетесов и прочих обвесов. Про мидлов , наверное, всё сложнее.

давайте "помериемся" задачками для мидла?

Могу ответить про джуниоров. Как показывает история канала (и смежных) - от них требуется микросервисная архитектура, параллельное программирование, понимание всех шаблонов проектирования, алгоритмики, архитектуры распределенки или хайлоада; 1-3 года опыта работы на go, ну и, конечно, этот язык должен идти в дополнение либо к питону, либо к жаве. Не считая всяких кубернетесов и прочих обвесов. Про мидлов , наверное, всё сложнее.

Мне кажется с теми же требованиями можно спокойно идти на middle.

имхо, это ирония была

давайте "помериемся" задачками для мидла?

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

имхо, это ирония была

Мда? Хорошо бы.

я предлагаю скинуть у кого какие есть, но не хочу делть это в одиночку

но начну

https://docs.google.com/document/d/1A_Se8kf3WPp3vC2GrnPR0tSWV38F4nEv-SCPB2XPYug/edit?usp=sharing

тут две части в задании, кандидат сам решает сколько он сделает

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

тут две части в задании, кандидат сам решает сколько он сделает

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

https://docs.google.com/document/d/1A_Se8kf3WPp3vC2GrnPR0tSWV38F4nEv-SCPB2XPYug/edit?usp=sharing

А это на какую вилку и ожидается, что за какое время будет сделано? Чтобы +/- понимать, как в Go дела обстоят.

А это на какую вилку и ожидается, что за какое время будет сделано? Чтобы +/- понимать, как в Go дела обстоят.

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

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

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

а что там в средних?

тогда будет много вопросов и длинное собеседование

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

Ну, если кандидат скажет, что ему надо 2 недели full time, понятно же, что это слишком много) даже если он сделает за эти две недели хорошее решение.

Ну, если кандидат скажет, что ему надо 2 недели full time, понятно же, что это слишком много) даже если он сделает за эти две недели хорошее решение.

разумеется, все нужно делать с умом

разумеется, все нужно делать с умом

Мне просто кажется логичным давать ещё ожидаемое время на задачу.

про мидла, и почему они везде разные: "оценка всегда зависит от оценивающего" (с)

все от вас зависит)

общение помогает понимать условия и выставлять требования