Я ж не в плохом смысле, с чего здесь можно оскорбиться? Кембридж прекрасен, практически рай на земле.
Он настолько маленький, что мы смогли за 2 дня обойти пешком все улицы по всей сетке и даже заглянуть в наиболее отдалённые кампусы (в пределах возможного, потому что везде private land). Аэропорт там тоже совсем небольшой, для бизнес-джетов и лёгких одномоторных самолётов.
Точно. В Киеве упомянутых «проблем с метро» нет, но есть другие. Берлин якобы дешёвый, но и по зарплатам такой же. После налогов и аренды остаётся в 3 раза меньше денег чем сейчас у меня в Киеве, при этом цены на всё прочее там выше.
Прежде чем куда-то валить, посмотрите на стоимость местной жизни хотя бы здесь www.numbeo.com/cost-of-living, посчитайте местные налоги, посмотрите условия и стоимость местного рынка жилья и так далее. Я, например, отказался от варианта переезда в Берлин именно по финансовой причине, хотя очень хотел. Зарплаты там небольшие и денег в net остаётся слишком мало для комфортной жизни.
«на момент её написания» — это вы очень точно подметили. Гегель популярен у нас из-за форсирования идей диалектического материализма в советстком пространстве. Но это не означает, что его идеи корректны и тем более конечны.
На текущем проекте, в зависимости от приложения, Pyramid или aiohttp. На предыдущем была Tornado. В Pyramid и Tornado вьюхи в общем-то тоже на классах, но на самом деле это только точка входа для дальнейшей композиции функций. В aiohttp всё честно сразу :)
Я рисовал дерево наследования всех классов и миксеров Django как только CBV вообще появились. На более-менее простых проектах всё можно контролировать. На большом проекте и с большой командой контроль стремится к нулю. Я счастлив, что больше не приходится использовать ни CBV, ни Django в принципе.
CBV — это худшее, что есть в Django. Совершенно дурацкое усложнение, которое на ровном месте ставит палки в колёса композиции логики, а исследовать поведение методов иногда совершенно нетривиально из-за необходимости ходить туда-сюда по всему дереву наследования и удерживать в голове весь контекст переопределения. В принципе, это общая проблема множественного наследования, но в Django идея возведена в абсолют. 100500 вьюх, базовых вьюх, миксинов… при том, что в любом случае приходится переопределять подавляющее большинство их методов. При разрастании кодовой базы это всё какой-то ад для поддержки и модификации.
История изменений, возможность откатиться, залить код на какой-нибудь Гитхаб или Битбакет, вести учёт задач в Issues, сделать простой деплой на сервер… Это то, что сразу приходит в голову.
Читал другие ваши статьи, знаю, что вы тоже пробовали webtorrent+ipfs, поэтому наверняка сталкивались с теми же проблемами и может как-то удалось их обойти. Судя по всему, в этом клубе нас двое.
Я уже установил nginx в роли прокси, с кешированием. Мне это не особо помогло. Да и хочется быть ближе к основной идее — безсерверному ресурсу.
IPFS с range-запросами работает хорошо. Только падает в итоге :) Клиент у меня сначала пытается достучаться к локальному демону, если его нет — то к шлюзу на моём инстансе. В целом всё оно работает. Но ощущение общей сырости не даёт покоя. Или я что-то делаю не так, или Go-имплементация далека от стабильной версии.
Но если оставить в покое видео и стримить более лёгкий статический контент, то всё прекрасно. Что-то в этом есть.
Немного не по теме конкретно этой статьи, но есть вопрос по IPFS.
Я сейчас экспериментирую со связкой IPFS+Webtorrent и мне не очень нравится результат. Напрягает падение самого демона IPFS при высокой частоте запросов к нему. Webtorrent-плеер играет видео через webseed, пока ты первый, кто смотрит его. Webseed-урл в торрент-файле указывает как раз на IPFS-хеш. Всё работает нормально только какое-то время, пока количество range-запросов к IPFS не упирается в какой-то непонятный мне потолок и демон падает. Перезапускается супервизиром, но этот downtime останавливает стрим, плеер получает 502 и ничего больше не работает, нужна перезагрузка страницы. Опытным путём выяснил, что демон очень жадный и хочет весь CPU на моём бедном микроинстансе. Я увеличил CPU/RAM дроплета, стало лучше. Но это пока клиент стримит только одно видео. Моя идея ещё и в том, чтобы webtorrent продолжал раздавать медиа-файл уже своими средствами, в фоне, после переключения воспроизведения на что-то другое. В итоге вопрос — сколько ж нужно IPFS-демону для нормальной жизни, если я уже дважды увеличивал инстанс и больше (по бюджету) не хочу? И вдогонку — есть ли какой-то список публичных шлюзов, чтобы я как-то балансировал нагрузку? Спасибо.
Спасибо за библиотеку. Это набор функций, к которым всё равно так или иначе приходишь со временем, а у вас уже оформлено в пакет. Для себя утащил achain/ichain, comp и монады.
Нельзя отвергать хорошие идеи и паттерны из других языков только потому, что они не соответствуют чувству прекрасного авторов Python.
Он настолько маленький, что мы смогли за 2 дня обойти пешком все улицы по всей сетке и даже заглянуть в наиболее отдалённые кампусы (в пределах возможного, потому что везде private land). Аэропорт там тоже совсем небольшой, для бизнес-джетов и лёгких одномоторных самолётов.
Я уже установил nginx в роли прокси, с кешированием. Мне это не особо помогло. Да и хочется быть ближе к основной идее — безсерверному ресурсу.
IPFS с range-запросами работает хорошо. Только падает в итоге :) Клиент у меня сначала пытается достучаться к локальному демону, если его нет — то к шлюзу на моём инстансе. В целом всё оно работает. Но ощущение общей сырости не даёт покоя. Или я что-то делаю не так, или Go-имплементация далека от стабильной версии.
Но если оставить в покое видео и стримить более лёгкий статический контент, то всё прекрасно. Что-то в этом есть.
Я сейчас экспериментирую со связкой IPFS+Webtorrent и мне не очень нравится результат. Напрягает падение самого демона IPFS при высокой частоте запросов к нему. Webtorrent-плеер играет видео через webseed, пока ты первый, кто смотрит его. Webseed-урл в торрент-файле указывает как раз на IPFS-хеш. Всё работает нормально только какое-то время, пока количество range-запросов к IPFS не упирается в какой-то непонятный мне потолок и демон падает. Перезапускается супервизиром, но этот downtime останавливает стрим, плеер получает 502 и ничего больше не работает, нужна перезагрузка страницы. Опытным путём выяснил, что демон очень жадный и хочет весь CPU на моём бедном микроинстансе. Я увеличил CPU/RAM дроплета, стало лучше. Но это пока клиент стримит только одно видео. Моя идея ещё и в том, чтобы webtorrent продолжал раздавать медиа-файл уже своими средствами, в фоне, после переключения воспроизведения на что-то другое. В итоге вопрос — сколько ж нужно IPFS-демону для нормальной жизни, если я уже дважды увеличивал инстанс и больше (по бюджету) не хочу? И вдогонку — есть ли какой-то список публичных шлюзов, чтобы я как-то балансировал нагрузку? Спасибо.
Нельзя отвергать хорошие идеи и паттерны из других языков только потому, что они не соответствуют чувству прекрасного авторов Python.