Comments 13
В первом талке про джангу не правда. В django.contrib — это не внешние либы, которые затащили и поменяли под себя. Это расширения основного проекта, батарейки которые в комплекте. В основном коде от contrib ничего не зависит.
+1
Все существующие VCS рассчитаны на установку прав для репозитория целиком.Это, конечно, занудство, но я знаю как минимум одну VCS, правда централизованную, которая позволяет настраивать доступ к любым файлам в репозитории — Perforce. :)
+2
TFS
0
Настраивать позволяют почти все, включая subversion. Вопрос в том, что является «предпочтительным» workflow, а что — «приклееной сбоку функциональностью для маркетинга, которой никто не пользуется». Большинство популярных решений подразумевают права на репозиторий целиком. И при настройке прав внутри репозитория начинаются… назовем это «интересные ситуации».
0
В Perforce установка прав внутри репозитория является как раз «предпочтительным» workflow и используется чаще всего, так как depot обычно один общий на все проекты. В git и других распределённых VCS, конечно, нет, потому что подходы и модель совсем другая: репозиторий на проект. В этом случае разумно управлять правами внутри проекта разве что на уровне субмодулей.
+1
В первом докладе как-то про ноду однобоко. На c# можно с помощью внутреннего nuget'а спокойно все настроить на мульти-репозитории.
+2
Первый доклад действительно не на высшем уровне.
Странно почти час слушать, как оратор рассуждая о проектах на много тысяч строк в то же время оперирует какими-то «дошкольными» понятиями. Причем, иногда с весьма спорными тезисами.
Странно почти час слушать, как оратор рассуждая о проектах на много тысяч строк в то же время оперирует какими-то «дошкольными» понятиями. Причем, иногда с весьма спорными тезисами.
+5
Наконец-то критика :). You are welcome! Я старался адаптировать, чтобы было интересно максимально широкой аудитории разработчиков. На ваш взгляд, где имеено я пофейлил и скатился на «дошкольные» понятия? За список спорных тезисов буду особо благодарен, возможно удастся что-то улучшить.
0
Не буду переслушивать еще раз, но попробую что-нибудь вспомнить по горячим следам :)
В целом, доклад довольно длинный, но по объему содержащейся информации его стоило бы сократить раза в два — восприятие улучшилось бы. (Это я сужу по тому, где находился бегунок в плеере, когда я пошел смотреть — «а не промотать ли немного подальше?»).
Как-то стоит конкретизировать примеры до частных случаев, так как если говорить в общем, то всегда найдется масса контрпримеров.
Когда говорите о чем-нибудь, например об npm, узнайте о его особенностях. Он как раз по дефолту складывает все чужие исходники в явном виде прямо к вам в директорию проекта. Мало того, он для каждого подмодуля может вытягивать свою отдельную версию какой-нибудь библиотеки. Кстати, эта часть у него идеологически лучше сделана, чем у Питона.
То, что править чужой отлаженный код — весьма ответственное занятие и надо перед этим сто раз подумать и передумать — это совсем другой вопрос, к количеству репозиториев никак не относящийся.
Проблемы деплоя в общем тоже весьма опосредованно связаны со структурой репозиторием и их количеством. Грубо говоря, если у вас проект класса hello-world, то там пофиг, как деплоиться. А если проект на десятки тысяч строк, то «rsync / ln -s» скорее всего будет последним по важности вопросом, над которым придется задумываться.
Аналогинчно насчет virtualenv — чтобы не стать поклонниками cargo-культа, надо понимать что и для чего нужно. К примеру, если вы не абстрактный веб-опенсорс разработчик, а делаете проект под конкретное стабильное окружение, то легко можно залить/поставить все себе без плясок вокруг virtualenv и т.п.
Очень странно звучит тезис в начале и в конце доклада о том, что «любой большой проект начинается с одного файла».
Это не так в подавляющем большинстве случаев, если это файл не readme, конечно :)
Если говорить о веб-опенсорс, то там гораздо более типична ситуация — «а версию 2.0 мы перепишем заново на Рельсах/Джанго/Ерганге/Кофескипте, перейдем с меркуриала на гит, переделаем деплоймент под Амазон и т.п.». И расклад кода по модулям/репозиториям происходит заново сам собой.
В целом, доклад довольно длинный, но по объему содержащейся информации его стоило бы сократить раза в два — восприятие улучшилось бы. (Это я сужу по тому, где находился бегунок в плеере, когда я пошел смотреть — «а не промотать ли немного подальше?»).
Как-то стоит конкретизировать примеры до частных случаев, так как если говорить в общем, то всегда найдется масса контрпримеров.
Когда говорите о чем-нибудь, например об npm, узнайте о его особенностях. Он как раз по дефолту складывает все чужие исходники в явном виде прямо к вам в директорию проекта. Мало того, он для каждого подмодуля может вытягивать свою отдельную версию какой-нибудь библиотеки. Кстати, эта часть у него идеологически лучше сделана, чем у Питона.
То, что править чужой отлаженный код — весьма ответственное занятие и надо перед этим сто раз подумать и передумать — это совсем другой вопрос, к количеству репозиториев никак не относящийся.
Проблемы деплоя в общем тоже весьма опосредованно связаны со структурой репозиторием и их количеством. Грубо говоря, если у вас проект класса hello-world, то там пофиг, как деплоиться. А если проект на десятки тысяч строк, то «rsync / ln -s» скорее всего будет последним по важности вопросом, над которым придется задумываться.
Аналогинчно насчет virtualenv — чтобы не стать поклонниками cargo-культа, надо понимать что и для чего нужно. К примеру, если вы не абстрактный веб-опенсорс разработчик, а делаете проект под конкретное стабильное окружение, то легко можно залить/поставить все себе без плясок вокруг virtualenv и т.п.
Очень странно звучит тезис в начале и в конце доклада о том, что «любой большой проект начинается с одного файла».
Это не так в подавляющем большинстве случаев, если это файл не readme, конечно :)
Если говорить о веб-опенсорс, то там гораздо более типична ситуация — «а версию 2.0 мы перепишем заново на Рельсах/Джанго/Ерганге/Кофескипте, перейдем с меркуриала на гит, переделаем деплоймент под Амазон и т.п.». И расклад кода по модулям/репозиториям происходит заново сам собой.
+2
Only those users with full accounts are able to leave comments. Log in, please.
Майский Python Meetup: машинное обучение и куда класть исходники