Куда класть исходники / Григорий Петров
Григорий рассказал, как типовой проект вырастает из нескольких десятков строк кода в многомегабайтного монстра с сотней зависимостей, и что с этим делать, чтобы не было мучительно больно. Он поведал публике о безумной эволюционной теории развития программного обеспечения, привел множество примеров из жизни, в результате чего показал разработку крупных проектов с неожиданного ракурса.
Машинное обучение и народное хозяйство / Андрей Гриненко
Большой поиск и распознавание речи, кредитный скоринг и показ рекламы — все большее и большее число процессов и технологий оптимизируются с помощью современного анализа данных. Андрей говорил об основных принципах машинного обучения и приводил случаи его применения в реальной жизни.
В июне мы празднуем двухлетие Python Meetup! В связи с этим мы перенесли пятничную встречу на субботу и подготовили интересную программу:
- Как называть переменные / Григорий Петров / Москва
- Сontainers. We need to go deeper / Филипп Кучерявый / Минск
- World of Jenkins / Александр Жуков / Санкт-Петербург
- Парное программирование. Удаленно / Сергей Алексеев / Минск
- Знай и люби свой PyObject, ты же программист / Александр Кошкин / Санкт-Петербург
Также каждый участник митапа сможет продемонстрировать мастерство в написании идеального кода. В рамках июньской встречи мы проведем первый Coding contest на Python Meetup!
В анонсе вы найдете подробную программу и форму регистрации.
До встречи на Python Meetup!
Комментарии (13)
iroln
24.06.2015 17:15+2Все существующие VCS рассчитаны на установку прав для репозитория целиком.
Это, конечно, занудство, но я знаю как минимум одну VCS, правда централизованную, которая позволяет настраивать доступ к любым файлам в репозитории — Perforce. :)
eyeofhell
25.06.2015 08:42Настраивать позволяют почти все, включая subversion. Вопрос в том, что является «предпочтительным» workflow, а что — «приклееной сбоку функциональностью для маркетинга, которой никто не пользуется». Большинство популярных решений подразумевают права на репозиторий целиком. И при настройке прав внутри репозитория начинаются… назовем это «интересные ситуации».
iroln
25.06.2015 12:05+1В Perforce установка прав внутри репозитория является как раз «предпочтительным» workflow и используется чаще всего, так как depot обычно один общий на все проекты. В git и других распределённых VCS, конечно, нет, потому что подходы и модель совсем другая: репозиторий на проект. В этом случае разумно управлять правами внутри проекта разве что на уровне субмодулей.
eyeofhell
25.06.2015 12:21По перфорсу не могу ничего сказать — лично не работал. Слашал о нем… разное.
maxp
25.06.2015 07:55+5Первый доклад действительно не на высшем уровне.
Странно почти час слушать, как оратор рассуждая о проектах на много тысяч строк в то же время оперирует какими-то «дошкольными» понятиями. Причем, иногда с весьма спорными тезисами.eyeofhell
25.06.2015 08:47Наконец-то критика :). You are welcome! Я старался адаптировать, чтобы было интересно максимально широкой аудитории разработчиков. На ваш взгляд, где имеено я пофейлил и скатился на «дошкольные» понятия? За список спорных тезисов буду особо благодарен, возможно удастся что-то улучшить.
maxp
25.06.2015 10:29+2Не буду переслушивать еще раз, но попробую что-нибудь вспомнить по горячим следам :)
В целом, доклад довольно длинный, но по объему содержащейся информации его стоило бы сократить раза в два — восприятие улучшилось бы. (Это я сужу по тому, где находился бегунок в плеере, когда я пошел смотреть — «а не промотать ли немного подальше?»).
Как-то стоит конкретизировать примеры до частных случаев, так как если говорить в общем, то всегда найдется масса контрпримеров.
Когда говорите о чем-нибудь, например об npm, узнайте о его особенностях. Он как раз по дефолту складывает все чужие исходники в явном виде прямо к вам в директорию проекта. Мало того, он для каждого подмодуля может вытягивать свою отдельную версию какой-нибудь библиотеки. Кстати, эта часть у него идеологически лучше сделана, чем у Питона.
То, что править чужой отлаженный код — весьма ответственное занятие и надо перед этим сто раз подумать и передумать — это совсем другой вопрос, к количеству репозиториев никак не относящийся.
Проблемы деплоя в общем тоже весьма опосредованно связаны со структурой репозиторием и их количеством. Грубо говоря, если у вас проект класса hello-world, то там пофиг, как деплоиться. А если проект на десятки тысяч строк, то «rsync / ln -s» скорее всего будет последним по важности вопросом, над которым придется задумываться.
Аналогинчно насчет virtualenv — чтобы не стать поклонниками cargo-культа, надо понимать что и для чего нужно. К примеру, если вы не абстрактный веб-опенсорс разработчик, а делаете проект под конкретное стабильное окружение, то легко можно залить/поставить все себе без плясок вокруг virtualenv и т.п.
Очень странно звучит тезис в начале и в конце доклада о том, что «любой большой проект начинается с одного файла».
Это не так в подавляющем большинстве случаев, если это файл не readme, конечно :)
Если говорить о веб-опенсорс, то там гораздо более типична ситуация — «а версию 2.0 мы перепишем заново на Рельсах/Джанго/Ерганге/Кофескипте, перейдем с меркуриала на гит, переделаем деплоймент под Амазон и т.п.». И расклад кода по модулям/репозиториям происходит заново сам собой.
kmmbvnr
В первом талке про джангу не правда. В django.contrib — это не внешние либы, которые затащили и поменяли под себя. Это расширения основного проекта, батарейки которые в комплекте. В основном коде от contrib ничего не зависит.
eyeofhell
Пасиб за уточнение. Да, я некорректно выразился, не надо было их «внешними либами» называть. Но идея как раз в том, что после того как оно «проросло» внутрь ядра, пришлось прикладывать значительные усилися, чтобы основной код перестал от них зависить, см. историю изменений.