Если у меня есть один кэш (что актуально при разработке), то можно контролировать, чтобы он удалялся, но можно и автоматизировать его удаление.
Если это глобальная проблема, то к фреймворку она не относится.
Django написана на питоне. На С++ она была бы бесполезна, потому что он не удобен для веб-программирования (как и для высокоуровневого анализа данных).
Более того, множество вещей нельзя сделать на низкоуровневом языке. Там даже словаря с разными типами данных (о чём ты писал) зачастую нет.
"И наконец, твои x и x+1 — это проверка состоятельности данных. Как правило это уже делается в момент выполнения" — нет такого. Программа делает то, что ты ей напишешь. Надо самому следить за своим анализом в любом случае.
Я не понял, как связаны валидация с кэшированием. Кэширование — это вспомогательная вещь для производительности, которая никак не связана с правильностью передаваемых в кэш данных. Он должен работать (почти) при любых данных.
В моём опыте анализа данных проблема валидации типов не возникала. Человек может написать х вместо х+1, и никакая валидация типов здесь не поможет. Строка вместо числа питоном отловится. Поэтому да, нужно внимательно следить за своим анализом. В своём опыте я пришёл к выводу, что высокоуровневый язык гораздо больше подходит для сложных алгоритмов анализа данных, чем С++ — это моё предпочтение.
Как я писал здесь, дорогие вычисления лучше проводить тогда, когда всё работает. Сначала фреймворк легко позволяет использовать малое подмножество данных.
Я не понял большого отличия 2 и 1й «проблем», но 3я интересная и по делу.
Да, нужно работать также с неоднородными элементами, и фреймворк это делает (скорее в других частях раскрою другие примеры, но в данном примере Writer берёт только те значения, которые являются строками текста, и где в контексте есть output, а другие он пропускает далее, ничего с ними не делая).
Калибровки с данными я как раз анализирую фреймворком. Да, надо иметь несколько потоков данных. Это возможно, нужно действительно смешивать их в нужном месте. Глобальные переменные и состояния, к счастью, не требуются, всё в рамках этих потоков. Состояние элементов — так или иначе, конечно, есть (нужно же где-то хранить настройки и т.п.).
Про 1й вопрос сейчас скопирую комментарий из чата. Другие вопросы, конечно, можешь сразу задавать, или после того как я ещё несколько частей опубликую.
Вопросы про типы — это вопросы не про фреймворк, а про язык. Фреймворк не стремится быть лучше Питона. Что возможно — отлавливается в начале (при инициализации последовательностей). Питон — очень популярный язык, и лично мне он очень нравится, он простой, его синтаксис позволяет мне думать не о коде (где какой тип переменных объявлять), а об алгоритме. Его возможностей достаточно для моего анализа, поэтому я выбрал его. Гибкость и простота, скорость разработки в моих задачах важнее производительности.
Спасибо, я буду думать об этом. Я не понимаю в деталях, как это работает. У нас есть поток, генератор. Что значит передаём значение, когда его все запросят? Это всё равно управление не из пользовательской функции. Можно обсудить после того как я 2ю часть напишу, там тоже подобный подход. Управление в последовательности находится. В itertools есть подобный метод, как размножить генератор, но он его весь загружает в память.
Я вспомнил, что в питоне функции не являются reentrant, я прежде всего в этом смысле писал. Функция не closure.
В этом смысле да, как и генератор. Имеется в виду пользовательская функция, без дополнительных библиотек. Так и через класс можно организовать. Мне хотелось, чтобы пользователю не пришлось много для этого делать.
К сожалению, мне не удалось создать работающие ссылки внутри статьи. Хабр удаляет теги \<\a id="..."> в markdown (и здесь мне не очень удалось написать это текстом), а когда я пытался вставить html, возникали проблемы с форматированием кода. Если кто-то умеет делать нормальные перекрёстные ссылки здесь, то поделитесь, пожалуйста!
Задумка хорошая и полезная, но рейтинг продукта на Амазоне оказался 2.7 из 5. Люди жалуются, что сканер плохо работает.
Кроме того, за лицензию разработчика требуется отдать больше, чем стоит сам сканер (сейчас он не продаётся даже на сайте магазина — автора публикации).
Комментарий Ивана Бегтина из OpenDataRussiaChat https://t.me/opendatarussiachat: ynikitenko это полезно, спасибо, но когда страниц много у этого есть существенные ограничения. Есть похожий способ через сохранение файла в WARC файл интернет архива. wget и его более продвинутый аналог wpull умеют в него сохранять. После чего есть инструменты отображения страниц из сайта по аналогии с интернет архивом. Например, pywb. Если не сохранять в warc файл то при использовании wget'а и воспроизведении сайта через веб-сервер часто ломаются ссылки с кириллицей и ссылки которые отдают файлы с серверной логикой и через Content-disposition
Да, код, содержимое БД и медиафайлы.
С кодом вопросов нет, для него отдельный репозиторий.
Под кодом я имею в виду прежде всего сам код сайта на django (возможно, с парой вспомогательных вещей вроде requirements.txt). Однако я бы не хотел туда же отправлять код для разворачивания на сервере, т.к. он а) платформозависимый б) если сайтов несколько, то он может быть дублирован (в любом случае в отдельном репозитории должен быть код для разворачивания nginix на сервере и установки других системных пакетов — возможно, там же стоит хранить код для разворачивания отдельных сайтов).
Насчёт хранения БД в репозитории — я не могу сейчас ответить точно; есть мнение, что git хранит изменённые куски больших файлов (а .sql может восприниматься как бинарный файл). С другой стороны, насколько мне известно, git лучше всего подходит именно для текстовых файлов. Хранение именно кода или текста в репозитории мне кажется более "чистым" и "правильным" (тем более не хочется хранить каждую версию БД в отдельном файле, если можно хранить только изменения). В целом я не утверждаю что мой метод подходит для всех — вероятно, есть разные вкусовые предпочтения.
В предложенном методе плюсом является также то, что он подходит и для архивирования медиафайлов (картинки обычно не изменяются, хотя их тоже можно хранить в БД — но тогда и размер её будет существенно больше, чем у только текстовой).
Дело в том, что у меня несколько сайтов на django.
Я пользуюсь виртуальным выделенным сервером за 90 рублей в месяц. За эти деньги дают ОС Linux с root-доступом, 10 гигабайт дискового пространства и 256 мегабайт памяти.
При использовании этого тарифа хостер подчёркивает полный отказ от ответственности в случае потери данных.
Сайты работают с помощью django/uwsgi/nginx, сам контент меняется редко. Поскольку памяти очень мало, то удаётся запускать uwsgi с его worker-ами только для одного сайта, в то время как другие могут храниться в виде статических страниц и выдаваться только сервером nginx.
Что касается генераторов статических сайтов: их действительно много. Плюс этой статьи в том, что можно использовать для генерации статических страниц уже известные инструменты (если вы уже знаете django), не нужно выбирать генератор и учиться его конфигурировать.
Это некая промежуточная стадия: если хотим, то запускаем полноценный динамический сайт, а если хотим — легко его архивируем, убиваем соответствующие процессы (освобождаем память) и выдаём страницы с помощью nginx (который один на весь сервер).
Если у меня есть один кэш (что актуально при разработке), то можно контролировать, чтобы он удалялся, но можно и автоматизировать его удаление.
Если это глобальная проблема, то к фреймворку она не относится.
Django написана на питоне. На С++ она была бы бесполезна, потому что он не удобен для веб-программирования (как и для высокоуровневого анализа данных).
Более того, множество вещей нельзя сделать на низкоуровневом языке. Там даже словаря с разными типами данных (о чём ты писал) зачастую нет.
"И наконец, твои x и x+1 — это проверка состоятельности данных. Как правило это уже делается в момент выполнения" — нет такого. Программа делает то, что ты ей напишешь. Надо самому следить за своим анализом в любом случае.
Я не понял, как связаны валидация с кэшированием. Кэширование — это вспомогательная вещь для производительности, которая никак не связана с правильностью передаваемых в кэш данных. Он должен работать (почти) при любых данных.
В моём опыте анализа данных проблема валидации типов не возникала. Человек может написать х вместо х+1, и никакая валидация типов здесь не поможет. Строка вместо числа питоном отловится. Поэтому да, нужно внимательно следить за своим анализом. В своём опыте я пришёл к выводу, что высокоуровневый язык гораздо больше подходит для сложных алгоритмов анализа данных, чем С++ — это моё предпочтение.
Как я писал здесь, дорогие вычисления лучше проводить тогда, когда всё работает. Сначала фреймворк легко позволяет использовать малое подмножество данных.
Я не понял большого отличия 2 и 1й «проблем», но 3я интересная и по делу.
Да, нужно работать также с неоднородными элементами, и фреймворк это делает (скорее в других частях раскрою другие примеры, но в данном примере Writer берёт только те значения, которые являются строками текста, и где в контексте есть output, а другие он пропускает далее, ничего с ними не делая).
Калибровки с данными я как раз анализирую фреймворком. Да, надо иметь несколько потоков данных. Это возможно, нужно действительно смешивать их в нужном месте. Глобальные переменные и состояния, к счастью, не требуются, всё в рамках этих потоков. Состояние элементов — так или иначе, конечно, есть (нужно же где-то хранить настройки и т.п.).
Про 1й вопрос сейчас скопирую комментарий из чата. Другие вопросы, конечно, можешь сразу задавать, или после того как я ещё несколько частей опубликую.
Вопросы про типы — это вопросы не про фреймворк, а про язык. Фреймворк не стремится быть лучше Питона. Что возможно — отлавливается в начале (при инициализации последовательностей). Питон — очень популярный язык, и лично мне он очень нравится, он простой, его синтаксис позволяет мне думать не о коде (где какой тип переменных объявлять), а об алгоритме. Его возможностей достаточно для моего анализа, поэтому я выбрал его. Гибкость и простота, скорость разработки в моих задачах важнее производительности.
Я вспомнил, что в питоне функции не являются reentrant, я прежде всего в этом смысле писал. Функция не closure.
В этом смысле да, как и генератор. Имеется в виду пользовательская функция, без дополнительных библиотек. Так и через класс можно организовать. Мне хотелось, чтобы пользователю не пришлось много для этого делать.
Кроме того, за лицензию разработчика требуется отдать больше, чем стоит сам сканер (сейчас он не продаётся даже на сайте магазина — автора публикации).
Видеозапись, слайды.
Комментарий Ивана Бегтина из OpenDataRussiaChat
https://t.me/opendatarussiachat:
ynikitenko это полезно, спасибо, но когда страниц много у этого есть существенные ограничения. Есть похожий способ через сохранение файла в WARC файл интернет архива. wget и его более продвинутый аналог wpull умеют в него сохранять. После чего есть инструменты отображения страниц из сайта по аналогии с интернет архивом. Например, pywb. Если не сохранять в warc файл то при использовании wget'а и воспроизведении сайта через веб-сервер часто ломаются ссылки с кириллицей и ссылки которые отдают файлы с серверной логикой и через Content-disposition
Да, код, содержимое БД и медиафайлы.
С кодом вопросов нет, для него отдельный репозиторий.
Под кодом я имею в виду прежде всего сам код сайта на django (возможно, с парой вспомогательных вещей вроде requirements.txt). Однако я бы не хотел туда же отправлять код для разворачивания на сервере, т.к. он а) платформозависимый б) если сайтов несколько, то он может быть дублирован (в любом случае в отдельном репозитории должен быть код для разворачивания nginix на сервере и установки других системных пакетов — возможно, там же стоит хранить код для разворачивания отдельных сайтов).
Насчёт хранения БД в репозитории — я не могу сейчас ответить точно; есть мнение, что git хранит изменённые куски больших файлов (а .sql может восприниматься как бинарный файл). С другой стороны, насколько мне известно, git лучше всего подходит именно для текстовых файлов. Хранение именно кода или текста в репозитории мне кажется более "чистым" и "правильным" (тем более не хочется хранить каждую версию БД в отдельном файле, если можно хранить только изменения). В целом я не утверждаю что мой метод подходит для всех — вероятно, есть разные вкусовые предпочтения.
В предложенном методе плюсом является также то, что он подходит и для архивирования медиафайлов (картинки обычно не изменяются, хотя их тоже можно хранить в БД — но тогда и размер её будет существенно больше, чем у только текстовой).
Я пользуюсь виртуальным выделенным сервером за 90 рублей в месяц. За эти деньги дают ОС Linux с root-доступом, 10 гигабайт дискового пространства и 256 мегабайт памяти.
При использовании этого тарифа хостер подчёркивает полный отказ от ответственности в случае потери данных.
Сайты работают с помощью django/uwsgi/nginx, сам контент меняется редко. Поскольку памяти очень мало, то удаётся запускать uwsgi с его worker-ами только для одного сайта, в то время как другие могут храниться в виде статических страниц и выдаваться только сервером nginx.
Что касается генераторов статических сайтов: их действительно много. Плюс этой статьи в том, что можно использовать для генерации статических страниц уже известные инструменты (если вы уже знаете django), не нужно выбирать генератор и учиться его конфигурировать.
Это некая промежуточная стадия: если хотим, то запускаем полноценный динамический сайт, а если хотим — легко его архивируем, убиваем соответствующие процессы (освобождаем память) и выдаём страницы с помощью nginx (который один на весь сервер).