Текст доклада шик

Добрый день, подскажите интересует как можно сделать аналог списка\библиотеки sharepoint (если кратно то это универсальная структура для хранение табличных данных(до 128 колонок) или документов где только у 2х полей есть определённый тип данных, я остальную стр-ру описывает xml включая "математику" между полям\списками)

Лысый в красной кофте совсем не догоняет какой ресурс, какая статья и почему в урле глагол - это норм. И что такое вобще рест не догоняет (что это не протокол как http а просто подход к работе с http)

Тяжело понять суть. Вот вы показывали пример запроса json rpc. Не вижу отличия с rest запросов. Также есть тело запроса Json и тело ответа Json

А как найти модуль Сurses? В Pypi много пакетов с таким именем.

пиздец в красном свитере токсичный уебан сидит)

6:20 - чё за ЦЕЛЬНтрализация? Он что, издевается? Причём "пояснение" закрутил так, что от этого стало ещё менее понятно, что имеется в виду.

Так и не побуцкались 😐

По сути дела…Это сравнение библиотек написанных на С с тонкой обвязкой ввиде python с golang …

Спасибо за обзор, то что надо для старта работы с TUI.

Я только сейчас заглянул сюда и прочёл комментарии. Доклад - как легко догадаться - мой. Наверное, справедливо будет написать несколько замечаний. Правда, переслушивать не стал, так что ориентируюсь на то, что помню. 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 растёт. Эволюционируем понемногу. Будем продолжать в том же духе.

thank you for this

Ну в общем не смотря на то, что игра в видео написана с использованием модуля Ctypes всё-таки видео можно было назвать на какую-то более общую тему. Например, "Аспекты создания игры для steam с использованием Python" и т. п.

Ё маё .Чего только в интернете не встретишь.... Вот название видео Ctypes в.. бла бла бла. .. Я так полагаю это видео рассчитано на программистов. То есть на людей, которые программируют приложения на Python. Но есть одно но. Я полагаю, что в большинстве случаев тот, кто создаёт приложения, не имеет много времени. Ну и вообще любит конкретику. Я сужу по себе. Но для вас, авторов видео, я специально буду многословен. Так вот, я, как человек, который ищет ответ на конкретный вопрос, хочу его получить как можно быстрее. Не хочу получать лишнюю информацию, хочу сразу конкретный ответ на конкретный вопрос. Ну, чтоб без балабольства. И тут я натыкаюсь на это видео. А искал я, кстати, видео, которое даст мне представление о модуле Ctypes. Думал увидеть тут на примере использование данного модуля. Так вот. Я сегодня проснулся, где-то, около 6-ти часов утра. А сон это дело житейское. Вот кстати анекдот: Лейтенант после пьянки просыпается. Смотрит на часы, видит что проспал.... А ладно хер этим анекдотом. Нужно всё-таки по делу. Проснулся я, значит. На повестке дня у меня стоят несколько вопросов, с которыми я должен разобраться. Один из вопросов - Изучить обработчики событий в Blender Python API. Второй - научиться скрывать логику работы операторов, которые формируют трёхмерные объекты, рассчитывают параметры анимации и т.д. Просто не хочу, чтобы кто-то видел реализацию, расчёт положения точек в пользовательских трёхмерных объектах и т.д. Там, просто, реализованы функции из аналитической геометрии. А Python такая штука, хрен что скроешь. То есть защитить исходный код дополнения от просмотра его пользователем, скорее всего, невозможно. Этот факт делает меня менее ценным программистом. То есть я сейчас работаю, результатом моей работы являются скрипты, написанные на Python. Они, как я уже упоминал, не скрывают логику дополнения, которое я пишу. Ну вот и получается сегодня пишу я даю скрипты. Делюсь технологиями, на изучение которых у меня ушло уйму времени. Собираю знания в кучу. Потом, допустим, я ухожу. На моё место приходит другой человек. И спокойно изучает мои труды. Конечно же, у него уйдёт меньше времени и нервов, чем у меня, потому что всё, что нужно я уже собрал в кучу. Нет... Вы не подумайте. Я не жадный. Просто платят мне за это копейки. Так ещё и тот для кого я это делаю отчитывается, так как будто он сделал это вместе со мной или вообще сам. Мало того он может взять и распространить эти скрипты. А мне этого не хочется. Ведь я за них достойной оплаты не получал. Поэтому я не хочу, чтобы у того, с кем я делюсь результатами своей деятельности, было представление о том, что происходит в самой программе. И на тот случай если результаты попадут к третьим лицам, то они тоже не знали, что происходит внутри. А самое главное не имели возможность модифицировать мои наработки сами. Таким образом, если я скрою логику, то я как программист буду более ценен. Потому что мои знания будут значимы. А не так что, сегодня ты, а завтра мы сами разберёмся в том, что ты написал и тебя нах пошлём. С целью решения этой проблемы я решил писать некоторый функционал на языке С++. На данном этапе я реализовал расчётную работу одного оператора в виде исполняемого файла. На вход он принимает координаты четырёх точек в виде аргументов командной строки. Производит расчёт (там в зависимости от режима нужно сформировать либо 3D тело либо рёбра с полигонами) и возвращает строку, в которой структурированы данные о рёбрах, полигонах и точках создаваемого объекта. Далее средствами Python эта строка парситься и формирует соответствующие массивы. Однако есть в этом методе недостатки. Так, перед тем как передать параметры в исполняемый файл их нужно привести в строковый вид. Далее программа, написанная на C++ должна эти строки преобразовать в тип double произвести с ними расчёты. Вернёт она бинарную строку. Но всё же строку, а не данные (то есть там не числа, а строки в виде чисел). Это, отходя от темы тоже интересный вопрос для меня. Как всё-таки реализовать передачу бинарных данных, а не строку. Ну, чтобы Python мог превратить некие данные в число float или int,. Ведь в C++ имеется возможность сохранять, например, объекты класса в файл, и считывать эти объекты из файла. При этом цифры сохраняются конечно же в бинарном виде. Так вот вернёмся к реализации оператора, который вызывает исполняемый файл. Эту бинарную строку нужно разбить на массивы, предварительно преобразовав её в обычную (str), чтобы можно было работать с методом split. После чего массивы, содержащие числа в виде строк обрабатываются и их элементы преобразовываются в float и в int значения (ну для точек нужны float, а для рёбер и полигонов int). И на основании полученных массивов создаётся трёхмерный объект в модели Blender. Однако такой способ является весьма затратным. Так на расчёт положения точек с помощью Python уходит от 2 до 20 миллисекунд, а на расчёт средствами Python и С++ в среднем может уйти от 10 до 50 миллисекунд. При этом при первом запуске исполняемого файла уходит больше 100 миллисекунд. Такая разница в производительности обусловлена тем что, в трёх местах необходимо конвертировать то строки в числа, то числа в строк. Этот подход для меня не является приемлемым. Поэтому я решил искать способ, который позволил бы работать с динамическими библиотеками. В идеале даже с массивами (в Python списки). Ну и наткнулся я на модуль Ctypes. Начал его изучать решил сначала посмотреть видосики на Youtobe. И тут вы в результатах поиска первые. Но обзор модуля Ctypes в этом видео я не получил. Я увидел только немного кода, на который почти всегда был коммент типа «Ну тут всё просто»….

пожалуй единственный русскоязычный ролик про туи

Видно, что автор "плавает" в теме. Лучшне почитайте про дескрипторы в книге Лутца (2-ой том)

Ну-Ну Py-Py Go-Go

можете подсказать как правильно нужно настроить docker compose? пытаюсь разобраться с sentry, когда запускаю свое приложение django в докер контейнере sentry перестает работать использую github.com/getsentry/onpremise

аудитория -мамонты

Спасибо за видео, мне очень помогли! Я хотела спросить у вас совета, как можно соединить JSON\RPC c мульти-агентной системой JADE (Java Agent Development Framework)? Буду очень признательна за любую помощь)

Я так понял что на питоне игры не пишут ну т.е. писать можно но нет.

Зачем придумывать терминологию?

Сейчас начну смотреть. И предварительно задам вопрос. Есть ли листинги исходного кода к уроку?

Офигенная причёска.

Не рекомендую это смотреть. Начало хорошее. Далее рассказывает про Python, Django, пишет миграцию и сидинг данных, потом - а давайте придумаем цитату .... Зачем привязываться к языку? В подобных видео нужно рассказывать и показывать примеры по теме на любимом языке но не объясняя язык. Вы же про REST рассказываете, это независимый не от чего набор правил и ограничений.

Тема не раскрыта))

очень мало контента по этой теме, спасибо!

тут лукасов надо кучу просто, единственный толковый гайд по этой херне на русском, много не понятного, я не профи, но по данной теме уже тонны инфы перелопатил нигде так подробно не рассказывают, в доках всё ещё мудрёней

Может кто подскажет? вот такой маршрут есть - path('formen/t-shirts/<str:slug>', Tovar.as_view(), name='m-t-tovar') И вот именно он не генерит bredcrumbs. Не понимаю, что нужно прописать в админке в поле URL. Пробовал так - 'm-t-tovar' и так 'm-t-tovar slug'. Если сделать вот такую строку - path('formen/t-shirts/', Tovar.as_view(), name='m-t-tovar') то все норм. Как сделать, чтоб давал хлебные крошки на странице конкретного товара?

Не надо это смотреть. На JSe можно легко написать за 1 минуту бекенд из 3 строк, твоё Го будет дольше компилироваться. Это вы просто ES6 не знаете.

трушный хиккан!

Джанга - шлак полный. Я хз чем надо упарываться чтобы на ней что-то делать.

36:29 AAAA! Чувак рассказал, как он посвятил месяцы проблеме асинхронности в питоне, и вдруг внезапно выясняется, что он в корне не понимает, как работает await. Лекцию к прослушиванию не рекомендую, докладчик некомпетентен.

Позорище...

Отличный доклад и ни одного комментария. Fixed.

как вариант - заходить с андроида в браузер и писать там на сервере

Lisij kloun eto ppc

Что за баран нахал на дискус? Парень вышел и рассказал свой кейс и про инструмент в контексте своих задач. Если что-то не понятно, то спросил и сел. Если с чем-то не согласен - подождал и потом подошел на тет-а-тет и обсудил. Этого было мало, надо было стоять и умничать) Быть может самооценка больная?)

Спасибо. Было интересно.

Кадрированное видео здесь - kzbin.info/www/bejne/kHaaiKakoqyNabc

37:30 - это решаеться если запускать через гуи, а в гуи можно стартовать после того как вы все машинки стартовали, да вот в cli мне тоже интересно как можно сделать

Мрак.

бесполезный семинар

Какой чудовищный язык, пока не выучит русский нельзя пускать к лекциям. Язык выдает отсутствие системного образования. Полный юайнй алерт. БЕЗГРАМОТНОСТЬ!!!

Хороший и полезный доклад

Нафиг эту Джангу, лучше Yii2 ))

дак все базы давно уже насколько я понимаю поддерживают эту хрень .. зачем её обходить в коде если БД это делает ???

Докладчик довольно поверхностно знает язык запросов и структуры баз даных. Отсюда совершенно потрясающие выводы по поводу джоинов и прочие утверждения, что что-то там гораздо проще и быстрее бла-бла-бла.... А что, без JS обойтись, в принципе, невозможно? Например, без Python, можно обойтись, используя только JS. Тогда нафига еще что-то искусственно добавлять? Просто пытаюсь понять, стоит-ли Pithon изучать. Повышение читаемости?

В стандартной библиотеке Go json сериализатор работает достаточно медленно из за того, что он активно использует рефлексию, интересно было бы посмотреть результаты с библиотекой easyjson, судя по бенчмаркам это очень эффективная библиотека

Я сам работал с SAP. Был даже в самой компании SAP AG в Германии. Начало берется не 80-х годов, а с 70-х. Тогда, действительно, это был прорыв. Переход от перфокарточного ввода данных на ввод данных с клавиатуры. Действительно, сейчас SAP - это ад. Ничего там, кроме слабо струтурированного хранилища и высоких цен нет. Ах, да! И стоимость консалтеров просто неприличная. И эти консалтеры сами не совсем понимают что и как работает. В количественном отношении внедрений очень и очень мало, особенно в Росси. В денежном эквиваленте бъет просто все немыслимые рекорды. Это объясняется очень просто. Практически все аудиторские компании скуплены этой фирмой и участвуют в разграблении компаний. Плюс откаты для тех, кто принимает решение о приобретении. Спасаются после приобретения тем, что пишут учет на других инструментах и вываливают данные в SAP. Я делал пару таких проектов. Для быстрого "прототипирования", как я считаю, в учетных системах быстрее, чем 1С, ничего нет.И питон здесь не исключение.