Я только сейчас заглянул сюда и прочёл комментарии. Доклад - как легко догадаться - мой. Наверное, справедливо будет написать несколько замечаний. Правда, переслушивать не стал, так что ориентируюсь на то, что помню. 0. Действительно, в докладе больше было деклараций, чем технических деталей. Ну что ж, так получилось. 1. Часть о взаимодействии с фронтом, действительно, неактуальна. Vue.js (и аналоги) вкупе с GraphQL решают эту проблему. Когда доклад делался, SPA-фронта у нас не было. 2. Сейчас я бы не стал уже рекомендовать Django как наилучшее известное мне решение для автоматизации. Когда доклад готовился, Django хорошо подходила под предметную область проекта. Позже проект вырос, это положение вещей изменилось. Сейчас остатки Django являют собой скорее мою головную боль, чем решение проблем. 3. Например, обработка потоковых данных, ETL, data warehouse, управление всяческими workflow - вещи, составляющие изрядную часть бизнес-автоматизации - в Django не укладываются. Она слишком монолитна и слишком специализирована под свою узкую задачу: создание веб-приложений; её архитектура совсем не обязательно хорошо подходит под автоматизацию с теми объёмами данных, которые надо перемалывать. 4. Особенно когда (и если! что немаловажно) появляется необходимость разбивать проект на микросервисы. 5. Надо бы ознакомиться, что есть нового за последние годы в Odoo и других open source (и не очень) ERP (или тех, кто называет себя так), доступных для малого и среднего бизнеса, а не только для супергигантов. 6. 1С не считаю вариантом. Сомневаюсь, что можно, хотя бы, выгрузить туда данные из parquet-файлов. На Python же написано великое множество библиотек под любые нужды. Именно поэтому, несмотря на недостатки (GIL, отсутствие JIT и некоторые странные изменения, случившиеся в последнее время) этот язык наверняка ещё долго будет - именно для бизнес-автоматизации - отличным выбором, пожалуй, лучшим из мне известных. Если бы я знал язык, который не то что не хуже, а однозначно 100% лучше для этой предметной области, то мигрировал бы. - Может быть, Kotlin и через него доступная экосистема Java? Не знаю; никак не могу перебороть в себе иррациональную нелюбовь к JVM и заняться изучением оного. - Rust мог бы - но для роли glue language он, боюсь, слишком сложен. Вот писать компоненты на Rust в тех местах, где нужна производительность - дело небесполезное. 7. Потому что главный способ ускорения разработки - это библиотеки и готовые продукты, которые можно встроить в свою систему. Если вы живёте в AWS и у вас уже есть библиотека, которая работает с каким-нибудь сервисом AWS на высоком уровне, так что вам не надо писать для этого свой код - вы сэкономили, может быть, сотни или тысячи часов разработки и тестирования. Браво, вы молодец. 8. Благодаря статической типизации, статическому анализу кода и более качественным методам тестирования качество проектов на Python растёт. Эволюционируем понемногу. Будем продолжать в том же духе.
Добрый день, подскажите интересует как можно сделать аналог списка\библиотеки sharepoint (если кратно то это универсальная структура для хранение табличных данных(до 128 колонок) или документов где только у 2х полей есть определённый тип данных, я остальную стр-ру описывает xml включая "математику" между полям\списками)
Я сам работал с SAP. Был даже в самой компании SAP AG в Германии. Начало берется не 80-х годов, а с 70-х. Тогда, действительно, это был прорыв. Переход от перфокарточного ввода данных на ввод данных с клавиатуры. Действительно, сейчас SAP - это ад. Ничего там, кроме слабо струтурированного хранилища и высоких цен нет. Ах, да! И стоимость консалтеров просто неприличная. И эти консалтеры сами не совсем понимают что и как работает. В количественном отношении внедрений очень и очень мало, особенно в Росси. В денежном эквиваленте бъет просто все немыслимые рекорды. Это объясняется очень просто. Практически все аудиторские компании скуплены этой фирмой и участвуют в разграблении компаний. Плюс откаты для тех, кто принимает решение о приобретении. Спасаются после приобретения тем, что пишут учет на других инструментах и вываливают данные в SAP. Я делал пару таких проектов. Для быстрого "прототипирования", как я считаю, в учетных системах быстрее, чем 1С, ничего нет.И питон здесь не исключение.
Чем он "хороший"? Не очень квалифицированный специалист вещает правду-матку? Потом после таких горе докладчиков неподготовленный слушатель, существует в каком-то надуманном сферическом вакууме. Польза отрицательная.
Какая разница на чем писать клиентскую часть? Vue, React, elm, ember. Бекенду глубоко фиолетово куда restapi запросы делать, и откуда их вызывать. Такое ощущение что люди не понимаю вообще как сейчас разработка происходит.
Внедрил на базе Odoo в компанию Учет рабочего времени. 1) там есть возможность создания модели из веб интерфейса, автор врет 2) она очень открытая, и xml ничего не усложняет, даже очень удобно, когда тебе кроме python и xml ничего знать не надо для автоматизации бизнеса ODOO лучше чем Django для бизнеса
Просто для постсоветского пространства это очень непривычный продукт. А так, доклад просто слабый. Набор каких-то фраз и призывов. Знание предмета нет. Даже критиковать не хочется. Нечего. Желаю новосибу поменьше таких "докладчиков"
Я только сейчас заглянул сюда и прочёл комментарии. Доклад - как легко догадаться - мой. Наверное, справедливо будет написать несколько замечаний. Правда, переслушивать не стал, так что ориентируюсь на то, что помню.
0. Действительно, в докладе больше было деклараций, чем технических деталей. Ну что ж, так получилось.
1. Часть о взаимодействии с фронтом, действительно, неактуальна. Vue.js (и аналоги) вкупе с GraphQL решают эту проблему. Когда доклад делался, SPA-фронта у нас не было.
2. Сейчас я бы не стал уже рекомендовать Django как наилучшее известное мне решение для автоматизации. Когда доклад готовился, Django хорошо подходила под предметную область проекта. Позже проект вырос, это положение вещей изменилось. Сейчас остатки Django являют собой скорее мою головную боль, чем решение проблем.
3. Например, обработка потоковых данных, ETL, data warehouse, управление всяческими workflow - вещи, составляющие изрядную часть бизнес-автоматизации - в Django не укладываются. Она слишком монолитна и слишком специализирована под свою узкую задачу: создание веб-приложений; её архитектура совсем не обязательно хорошо подходит под автоматизацию с теми объёмами данных, которые надо перемалывать.
4. Особенно когда (и если! что немаловажно) появляется необходимость разбивать проект на микросервисы.
5. Надо бы ознакомиться, что есть нового за последние годы в Odoo и других open source (и не очень) ERP (или тех, кто называет себя так), доступных для малого и среднего бизнеса, а не только для супергигантов.
6. 1С не считаю вариантом. Сомневаюсь, что можно, хотя бы, выгрузить туда данные из parquet-файлов. На Python же написано великое множество библиотек под любые нужды. Именно поэтому, несмотря на недостатки (GIL, отсутствие JIT и некоторые странные изменения, случившиеся в последнее время) этот язык наверняка ещё долго будет - именно для бизнес-автоматизации - отличным выбором, пожалуй, лучшим из мне известных. Если бы я знал язык, который не то что не хуже, а однозначно 100% лучше для этой предметной области, то мигрировал бы.
- Может быть, Kotlin и через него доступная экосистема Java? Не знаю; никак не могу перебороть в себе иррациональную нелюбовь к JVM и заняться изучением оного.
- Rust мог бы - но для роли glue language он, боюсь, слишком сложен. Вот писать компоненты на Rust в тех местах, где нужна производительность - дело небесполезное.
7. Потому что главный способ ускорения разработки - это библиотеки и готовые продукты, которые можно встроить в свою систему. Если вы живёте в AWS и у вас уже есть библиотека, которая работает с каким-нибудь сервисом AWS на высоком уровне, так что вам не надо писать для этого свой код - вы сэкономили, может быть, сотни или тысячи часов разработки и тестирования. Браво, вы молодец.
8. Благодаря статической типизации, статическому анализу кода и более качественным методам тестирования качество проектов на Python растёт. Эволюционируем понемногу. Будем продолжать в том же духе.
Добрый день, подскажите
интересует как можно сделать аналог списка\библиотеки sharepoint (если кратно то это универсальная структура для хранение табличных данных(до 128 колонок) или документов где только у 2х полей есть определённый тип данных, я остальную стр-ру описывает xml включая "математику" между полям\списками)
Я сам работал с SAP. Был даже в самой компании SAP AG в Германии.
Начало берется не 80-х годов, а с 70-х. Тогда, действительно, это был прорыв. Переход от перфокарточного ввода данных на ввод данных с клавиатуры.
Действительно, сейчас SAP - это ад. Ничего там, кроме слабо струтурированного хранилища и высоких цен нет.
Ах, да! И стоимость консалтеров просто неприличная. И эти консалтеры сами не совсем понимают что и как работает.
В количественном отношении внедрений очень и очень мало, особенно в Росси. В денежном эквиваленте бъет просто все немыслимые рекорды.
Это объясняется очень просто. Практически все аудиторские компании скуплены этой фирмой и участвуют в разграблении компаний. Плюс откаты для тех, кто принимает решение о приобретении. Спасаются после приобретения тем, что пишут учет на других инструментах и вываливают данные в SAP. Я делал пару таких проектов.
Для быстрого "прототипирования", как я считаю, в учетных системах быстрее, чем 1С, ничего нет.И питон здесь не исключение.
Хороший доклад.
Хороший и полезный доклад
Чем он "хороший"?
Не очень квалифицированный специалист вещает правду-матку?
Потом после таких горе докладчиков неподготовленный слушатель, существует в каком-то надуманном сферическом вакууме. Польза отрицательная.
Почему это он "не очень квалифицированный специалист"?
Какая разница на чем писать клиентскую часть? Vue, React, elm, ember. Бекенду глубоко фиолетово куда restapi запросы делать, и откуда их вызывать. Такое ощущение что люди не понимаю вообще как сейчас разработка происходит.
Звук( На первый вопрос ответить хочу - VUE :)
зы: Не нужно ничего дублировать на клиенте, это бред!
Внедрил на базе Odoo в компанию Учет рабочего времени.
1) там есть возможность создания модели из веб интерфейса, автор врет
2) она очень открытая, и xml ничего не усложняет, даже очень удобно, когда тебе кроме python и xml ничего знать не надо для автоматизации бизнеса
ODOO лучше чем Django для бизнеса
Просто для постсоветского пространства это очень непривычный продукт.
А так, доклад просто слабый. Набор каких-то фраз и призывов. Знание предмета нет. Даже критиковать не хочется. Нечего.
Желаю новосибу поменьше таких "докладчиков"