Ура! После почти месяца, проведенного на немецкой таможне, и разбирательств с UPS подарок от моего Деда Мороза наконец-то приехал!
Дед Мороз явно провёл ресёрч моих хобби, за это отдельный респект!
Что внутри
Книга и набор кистей — это прям 100% попадание, а игра пока всем своим видом и контентом спрашивает, не ханжа ли я — боюсь открывать и пока не очень понимаю, с кем в такое можно играть… Но идея интересная :)
Вообще, с международными отправлениями какая-то беда, конечно… Подарок для моего "внучка" тоже где-то затерялся, так что пришлось буквально за несколько дней до Нового года придумывать запасной подарок, который можно было отправить уже с территории России.
Привет! Согласна, что я как-то не совсем правильно выразилась.
Пришла в комментарии, чтобы раскрыть этот тезис :)
Наверное, мне надо было пояснить, что я начинала с маленьких сайтов-блогов на WordPress и Drupal, где особо не требовалось разбираться в архитектуре распределенных систем или, например, в оптимизации запросов к базам данных. Не нужно было глубоко копать в то, как устроены сами WordPress или Drupal. И было это лет 12-13 назад. Не исключаю, что сейчас ситуация с этими CMS/CMF совсем другая. Но это уже прям целые мемуары получаются :)
Так совпало, что когда я перешла в проекты, которые действительно можно было назвать не самыми простыми, в качестве основы использовались уже или самописные фреймворки, или, например, Yii.
Не пробовала так делать, но первое, что приходит в голову — инструкция replace. Из документации мне кажется, что если в vendor-mode работать, то результат должен быть как раз такой, как вы описываете.
Тоже сталкивалась с проблемами с VS Code, да. Обещают, что если включить gopls, то более или менее должно заработать. Но как-то gopls у меня не прижился пока.
В приципе, в некотором роде можно, но тогда уже не в самом файле go.mod. Можно через go get указывать бранчи, но опять же автоматически go get не будет следить за всеми обновлениями.
Тогда ваш процесс сборки приложения будет всегда из двух шагов состоять:
Вызывать go get github.com/sirupsen/logrus@master — при этом файл go.mod обновится автоматически
В файле go.mod. Если брать пример из статьи, то в строке
require github.com/sirupsen/logrus v1.4.2
вместо v1.4.2 можно подставить любую другую желаемую версию. После этого можно вызвать вручную go mod tidy и go mod download, чтобы обновить транзитивные зависимости и загрузить модули согласно этим обновлениям. Также можно просто перекомпилировать приложение (команды go mod при этом будут вызваны автоматически).
Соотственно, если вы разрабатываете бибилиотеку и выкладываете ее, например, на Github, имеет смысл использовать семантическое версионирование с тегами вида v1.2.3.
Если семантического версионирования нет, то версии будут выглядеть а ля v0.0.0-20190422165155-953cdadca894 (что-то вроде v0.0.0-дата-хэш).
Или вот например, с тем же logrus'ом: там сейчас есть коммиты в мастер, но тега v1.4.3 пока нет. И если посмотреть версии этой библиотеки на gocenter, помимо v1.4.2 там будут варианты а ля v1.4.3-0.20190807103436-de736cf91b92.
Сама я в продакшн пробовала только goose (как раз для PostgreSQL), встроить в приложение можно было, насчет локов точно не скажу, но да, в случае с несколькими инстансами проблем не было.
Вообще, я сейчас (вот прямо сейчас) как раз пишу управление миграциями для reform, но, думаю, пока там всё будет готово к продакшн, пройдет еще какое-то время.
Приходите к нам в русскоязычный слак — slack.golang-ru.com, у нас там есть канал #databases как раз для таких вопросов — может, кто что интересное посоветует из своего опыта.
Конкретно в этом случае defer ничего не даст — у нас очень простой тест, и мы просто считываем тело ответа и сразу его закрываем. Но, вообще, строго говоря, если делать defer resp.Body.Close(), то надо делать это не после чтения данных, а сразу после получения ответа и до первого возможного выхода из функции (в нашем случае — сразу после resp := w.Result()).
Интересный способ. По идее, каноны требуют использовать полные пути в качестве путей импорта. Но, наверное, если для конкретного проекта или конкретной команды удобнее от канонов отступить, то можно и так сделать.
Для себя я вижу пару проблем в случае, когда не используется полный путь импорта:
— если вендорить такой репозиторий в другой проект, то менеджер зависимостей может не разобраться, кто откуда растет и где какую зависимость искать
— в особо редких случаях получившийся путь может совпасть с путем импорта какой-нибудь стандартной библиотеки, и это может быть не очень приятно
Ну и в целом есть ощущение, что от отсутствия полных путей импорта головной боли будет больше, чем от их наличия. В случае, если полные пути импорта заданы, их всегда можно найти/заменить тем же sed'ом. А вот если захочется неполные пути потом изменить на полные, это будет, наверное, задача сложнее.
Чтобы работать с приватными репозиториями мы добавляем маленький хак в .gitconfig. По умолчанию go get тянет репозитории по http(s), мы подменяем на уровне git эту часть url'а на нужную нам. Наверное, не самое красивое решение, но оно работает. Примеры для github'а и абстрактного bitbucket'а:
А вот насчет второго вопроса, пожалуй, не всё так просто. У меня всего однажды был похожий случай, когда захотелось переехать на другой хостинг, но я просто пробежалась sed'ом по нужным репозиториям, перегенерила vendor и поправила пути импорта. Ну и путей импорта в коде, по-моему, все-таки не так уж много, как может иногда показаться :)
Ребята, а если я хочу найти вообще все места, где есть завтрак, что я должна сделать? Т. е. мне подходят и рестораны, и кафе, и суши-бары, лишь бы завтрак был. Куда жать? :)
Ну, 18+ на коробке меня несколько смущает :)
Ура! После почти месяца, проведенного на немецкой таможне, и разбирательств с UPS подарок от моего Деда Мороза наконец-то приехал!
Дед Мороз явно провёл ресёрч моих хобби, за это отдельный респект!
Книга и набор кистей — это прям 100% попадание, а игра пока всем своим видом и контентом спрашивает, не ханжа ли я — боюсь открывать и пока не очень понимаю, с кем в такое можно играть… Но идея интересная :)
Вообще, с международными отправлениями какая-то беда, конечно… Подарок для моего "внучка" тоже где-то затерялся, так что пришлось буквально за несколько дней до Нового года придумывать запасной подарок, который можно было отправить уже с территории России.
Привет! Согласна, что я как-то не совсем правильно выразилась.
Пришла в комментарии, чтобы раскрыть этот тезис :)
Наверное, мне надо было пояснить, что я начинала с маленьких сайтов-блогов на WordPress и Drupal, где особо не требовалось разбираться в архитектуре распределенных систем или, например, в оптимизации запросов к базам данных. Не нужно было глубоко копать в то, как устроены сами WordPress или Drupal. И было это лет 12-13 назад. Не исключаю, что сейчас ситуация с этими CMS/CMF совсем другая. Но это уже прям целые мемуары получаются :)
Так совпало, что когда я перешла в проекты, которые действительно можно было назвать не самыми простыми, в качестве основы использовались уже или самописные фреймворки, или, например, Yii.
Не пробовала так делать, но первое, что приходит в голову — инструкция replace. Из документации мне кажется, что если в vendor-mode работать, то результат должен быть как раз такой, как вы описываете.
Спасибо, Иван! Полезный кейс про open-source, да!
Тоже сталкивалась с проблемами с VS Code, да. Обещают, что если включить
gopls, то более или менее должно заработать. Но как-тоgoplsу меня не прижился пока.В приципе, в некотором роде можно, но тогда уже не в самом файле go.mod. Можно через go get указывать бранчи, но опять же автоматически
go getне будет следить за всеми обновлениями.Тогда ваш процесс сборки приложения будет всегда из двух шагов состоять:
go get github.com/sirupsen/logrus@master— при этом файлgo.modобновится автоматическиС мажорными версиями тоже отдельная история: мажорная версия должна быть указана в пути модуля.
В файле
go.mod. Если брать пример из статьи, то в строкевместо
v1.4.2можно подставить любую другую желаемую версию. После этого можно вызвать вручнуюgo mod tidyиgo mod download, чтобы обновить транзитивные зависимости и загрузить модули согласно этим обновлениям. Также можно просто перекомпилировать приложение (командыgo modпри этом будут вызваны автоматически).Соотственно, если вы разрабатываете бибилиотеку и выкладываете ее, например, на Github, имеет смысл использовать семантическое версионирование с тегами вида
v1.2.3.Если семантического версионирования нет, то версии будут выглядеть а ля
v0.0.0-20190422165155-953cdadca894(что-то вродеv0.0.0-дата-хэш).Или вот например, с тем же
logrus'ом: там сейчас есть коммиты в мастер, но тегаv1.4.3пока нет. И если посмотреть версии этой библиотеки на gocenter, помимоv1.4.2там будут варианты а ляv1.4.3-0.20190807103436-de736cf91b92.2. Ruby
3. Vertica (что это?)
4. Debian
5. Linux вообще (пингвины)
6. MySQL (дельфины)
7. Слон PHP (из контейнера)
8. Слон Postgres (идет по улице)
9. Котлин (флажок)
10. Python (заклинатель змей)
11. Docker (кит с контейнерами)
12. Kubernetes (штурвал на корабле и мужик в кепке)
13. GitHub (октокошка на корабле)
14. Sphinx (на киоске)
15. Кассандра (глаз)
16. Kibana (флажок)
17. TeamCity (TC)
18. React
19. JS
20. nSQ
21. Grafana
22. Prometheus (Прометей бежит)
23. RabbitMQ (заяц бежит)
24. Swift (розовая ласточка)
25. Avito (шарик на елке)
26. Go (синий гофер с длинными лапами)
27. Redis (редиска в вегетарианском магазине)
28. Шестиугольник на зеленом фоне… мм… Nomad?
29. Apple (огрызки яблок)
30. Android
31. VLC? :)
32. Lua (рядом с телескопом)
33. mongoDB (зеленый лист за углом)
34. Selenium? (Se)
Вижу еще логотипы, но не знаю, что они означают.
Вообще, я сейчас (вот прямо сейчас) как раз пишу управление миграциями для reform, но, думаю, пока там всё будет готово к продакшн, пройдет еще какое-то время.
Приходите к нам в русскоязычный слак — slack.golang-ru.com, у нас там есть канал #databases как раз для таких вопросов — может, кто что интересное посоветует из своего опыта.
deferничего не даст — у нас очень простой тест, и мы просто считываем тело ответа и сразу его закрываем. Но, вообще, строго говоря, если делатьdefer resp.Body.Close(), то надо делать это не после чтения данных, а сразу после получения ответа и до первого возможного выхода из функции (в нашем случае — сразу послеresp := w.Result()).Для себя я вижу пару проблем в случае, когда не используется полный путь импорта:
— если вендорить такой репозиторий в другой проект, то менеджер зависимостей может не разобраться, кто откуда растет и где какую зависимость искать
— в особо редких случаях получившийся путь может совпасть с путем импорта какой-нибудь стандартной библиотеки, и это может быть не очень приятно
Ну и в целом есть ощущение, что от отсутствия полных путей импорта головной боли будет больше, чем от их наличия. В случае, если полные пути импорта заданы, их всегда можно найти/заменить тем же sed'ом. А вот если захочется неполные пути потом изменить на полные, это будет, наверное, задача сложнее.
Чтобы работать с приватными репозиториями мы добавляем маленький хак в .gitconfig. По умолчанию go get тянет репозитории по http(s), мы подменяем на уровне git эту часть url'а на нужную нам. Наверное, не самое красивое решение, но оно работает. Примеры для github'а и абстрактного bitbucket'а:
[url "git@github.com:"]
insteadOf = https://github.com/
[url "ssh://git@my-secret-bitbucket-url:1234"]
insteadOf = https://my-secret-bitbucket-url/scm
А вот насчет второго вопроса, пожалуй, не всё так просто. У меня всего однажды был похожий случай, когда захотелось переехать на другой хостинг, но я просто пробежалась sed'ом по нужным репозиториям, перегенерила vendor и поправила пути импорта. Ну и путей импорта в коде, по-моему, все-таки не так уж много, как может иногда показаться :)
FROM scratch, вот примерно так :)Только если сертификаты надо перегенерить, отдельно разворчаиваем alpine и копируем нужные файлы, но это нечастое действие.
А если серьезно, очень-очень жду CodeFest, yeah! :)