Pull to refresh

Comments 13

В первом талке про джангу не правда. В django.contrib — это не внешние либы, которые затащили и поменяли под себя. Это расширения основного проекта, батарейки которые в комплекте. В основном коде от contrib ничего не зависит.
Пасиб за уточнение. Да, я некорректно выразился, не надо было их «внешними либами» называть. Но идея как раз в том, что после того как оно «проросло» внутрь ядра, пришлось прикладывать значительные усилися, чтобы основной код перестал от них зависить, см. историю изменений.
Все существующие VCS рассчитаны на установку прав для репозитория целиком.
Это, конечно, занудство, но я знаю как минимум одну VCS, правда централизованную, которая позволяет настраивать доступ к любым файлам в репозитории — Perforce. :)
Настраивать позволяют почти все, включая subversion. Вопрос в том, что является «предпочтительным» workflow, а что — «приклееной сбоку функциональностью для маркетинга, которой никто не пользуется». Большинство популярных решений подразумевают права на репозиторий целиком. И при настройке прав внутри репозитория начинаются… назовем это «интересные ситуации».
В Perforce установка прав внутри репозитория является как раз «предпочтительным» workflow и используется чаще всего, так как depot обычно один общий на все проекты. В git и других распределённых VCS, конечно, нет, потому что подходы и модель совсем другая: репозиторий на проект. В этом случае разумно управлять правами внутри проекта разве что на уровне субмодулей.
По перфорсу не могу ничего сказать — лично не работал. Слашал о нем… разное.
В первом докладе как-то про ноду однобоко. На c# можно с помощью внутреннего nuget'а спокойно все настроить на мульти-репозитории.
C# — nuget
java — maven
Python — тут уже сложнее
Первый доклад действительно не на высшем уровне.
Странно почти час слушать, как оратор рассуждая о проектах на много тысяч строк в то же время оперирует какими-то «дошкольными» понятиями. Причем, иногда с весьма спорными тезисами.
Наконец-то критика :). You are welcome! Я старался адаптировать, чтобы было интересно максимально широкой аудитории разработчиков. На ваш взгляд, где имеено я пофейлил и скатился на «дошкольные» понятия? За список спорных тезисов буду особо благодарен, возможно удастся что-то улучшить.
Не буду переслушивать еще раз, но попробую что-нибудь вспомнить по горячим следам :)

В целом, доклад довольно длинный, но по объему содержащейся информации его стоило бы сократить раза в два — восприятие улучшилось бы. (Это я сужу по тому, где находился бегунок в плеере, когда я пошел смотреть — «а не промотать ли немного подальше?»).

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

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

То, что править чужой отлаженный код — весьма ответственное занятие и надо перед этим сто раз подумать и передумать — это совсем другой вопрос, к количеству репозиториев никак не относящийся.

Проблемы деплоя в общем тоже весьма опосредованно связаны со структурой репозиторием и их количеством. Грубо говоря, если у вас проект класса hello-world, то там пофиг, как деплоиться. А если проект на десятки тысяч строк, то «rsync / ln -s» скорее всего будет последним по важности вопросом, над которым придется задумываться.

Аналогинчно насчет virtualenv — чтобы не стать поклонниками cargo-культа, надо понимать что и для чего нужно. К примеру, если вы не абстрактный веб-опенсорс разработчик, а делаете проект под конкретное стабильное окружение, то легко можно залить/поставить все себе без плясок вокруг virtualenv и т.п.

Очень странно звучит тезис в начале и в конце доклада о том, что «любой большой проект начинается с одного файла».
Это не так в подавляющем большинстве случаев, если это файл не readme, конечно :)

Если говорить о веб-опенсорс, то там гораздо более типична ситуация — «а версию 2.0 мы перепишем заново на Рельсах/Джанго/Ерганге/Кофескипте, перейдем с меркуриала на гит, переделаем деплоймент под Амазон и т.п.». И расклад кода по модулям/репозиториям происходит заново сам собой.

Only those users with full accounts are able to leave comments. Log in, please.