company_banner

Майский Python Meetup: машинное обучение и куда класть исходники

  • Tutorial
Всем привет! Мы хотим поделиться с вами записями выступлений с предыдущего Python Meetup. В этот раз мы обсуждали полезность сохранения исходного кода с Григорием Петровым и особенности применения машинного обучения с Андрем Гриненко.





Куда класть исходники / Григорий Петров

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






Машинное обучение и народное хозяйство / Андрей Гриненко

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






В июне мы празднуем двухлетие Python Meetup! В связи с этим мы перенесли пятничную встречу на субботу и подготовили интересную программу:

  • Как называть переменные / Григорий Петров / Москва
  • Сontainers. We need to go deeper / Филипп Кучерявый / Минск
  • World of Jenkins / Александр Жуков / Санкт-Петербург
  • Парное программирование. Удаленно / Сергей Алексеев / Минск
  • Знай и люби свой PyObject, ты же программист / Александр Кошкин / Санкт-Петербург


Также каждый участник митапа сможет продемонстрировать мастерство в написании идеального кода. В рамках июньской встречи мы проведем первый Coding contest на Python Meetup!

В анонсе вы найдете подробную программу и форму регистрации.

До встречи на Python Meetup!
Wargaming
Компания

Похожие публикации

Комментарии 13

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

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

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

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

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

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

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

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

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

                  0
                  Спасибо!

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

            Самое читаемое