Это круто, что вы читаете.
Можете ссылку кинуть на то, где можно настрочить описание бага с подробностями? А то я репозиторий только на github видел. Или туда тоже норм?
Я не сказал, что нельзя завести, только сбилдить контейнер под rancheros. Вообще, было бы круто не билдить их самим, а взять, так сказать, проверенный авторами образ, особенно в свете того, что он зависит от билд-хоста. Но это уже капризы.
Под кубиком я не запускал, но образ в несжатом виде — 1.83Гб выглядит ужасающе для вытягивания с условного dockerhub. Хотя, там наверное сама IDE большую часть занимает. Тем не менее, если не запустится под неподготовленной системой (т.е. просто ставим докер, накатываем в кластер k8s), то для куба это решение будет сомнительным. Уверен, что есть поле для оптимизации размера образа.
Релизом я называю стабильную версию, с описанием от компании, а не "мужики, прикиньте что нашёл в закромах гитхаба и вроде рабочее". Но раз политика партии говорит "молчим", то наверное на то есть причины.
А если не секрет, с чем связана такая политика? С тем, что продукт не prod-ready или какие-то маркетинговые штучки?
Так, я поднял под Ubuntu 18.04 с docker. Можно прятать за ingress, но сам проект вообще не юзабельный. Поднимается кое-как с некоторыми недокументированными движениями только в строго определённых условиях, а значит в сам кубик такое засунуть будет сложновато. В хроме меню вообще куда-то вверх убегает, а значит невозможно выбрать ни один пункт. Периодические лаги, когда окно исчезает и весь интерфейс встаёт колом.
Сама идея — классная, шрифты красивые и не плывут, авторизацию всегда можно навесить, притом разными интересными способами. В принципе, если даже не получится завернуть в K8s, то ничто не мешает подготовить виртуалку со всем необходимым для разных гипервизоров. Но реализация пока сильно сырая, поэтому работать в таком поделии невозможно. Ждём официального релиза от JB.
Как идея (если нас читают JB): можно было бы реализовать что-то вроде тонкого клиента, либо PWA (это было бы вообще киллер-фичей).
Я честно пытался завести это под RancherOS, но сбилдить контейнер мне так и не удалось. Сегодня попробую под убунтой.
Вообще проблема странная: нехватка памяти, но у меня на вируалке 8vCPU/16GB. Попробую собрать образ на убунту, там проверю и надеюсь потом завести это под RancherOS.
Попробую тогда PyCharm развернуть в пн в docker-compose за haproxy или nginx с сертификатами и http2. Если заведется, тогда можно попробовать в кубик загнать. Если и там заведется, то вообще JetBrains-as-Service это неплохая затея. Жаль только тестированные версии староваты.
Что-то у меня с настроенным DoH пересылка запросов не пошла. А то что вы привели в качестве пруфа, говорит о том, что DoH в принципе теперь поддерживается.
Либо я не понимаю гениальности этих решений, либо автор и комментатор чего-то не понимают в джанго...
Либо вам чуждо понятие примера. Вместо .all() может быть любой фильтр и тогда первый пример сразу не подходит. Если параметров для поста довольно много, то можно получить не очень читабельный код, да и оптимизации это не прибавит — SQL будет либо таким же, либо около того.
Но если запрос тупо на всех авторов, которые имеют хотя бы один пост, то первый ваш пример самый читабельный. Если нужно отобрать только по содержимому заголовка, то второй тоже неплох. Но если говорить о реальном приложении, то очень редко происходит, что нужно получить данные не с уже имеющегося объекта qs.
Хотя конечно же нужно было мне написать пояснение к моему ходу мыли, чтобы неокрепшие умы не сломались. И вообще, оптимизировать надо исходя из задачи и т.д.
Он сделает обычный join или подзапрос — уже и не помню. Но движок бд всяко быстрее отработает + там скорее всего будет пагинатор использоваться, а значит такой вариант больше подойдёт. Ну и список авторов будет без всяких distinct выдавать только уникальные записи.
В п.3 наверное было бы проще сразу всех авторов получить у которых post__id в qs. На практике это обычно быстрее, потому что полностью одним запросом к СУБД делается, пусть и с подзапросом.
Ох, как же я вас понимаю.
У себя в команде хотел всех с PyCharm перекинуть на VSCode. Мы честно проработали почти полгода и я сам же сдался и поставил PyCharm. Теперь думаем Pro лицензии закупить, но придётся копить (под стартап не попадаем, потому что юр.лицо слишком давно сделали).
Из того что раздражало:
Навигация по коду ну очень медленная. Даже куча тонких настроек тормозили процесс работы очень сильно.
Запуски тестов и отладчик и быстрее, и удобнее.
Настройка разных окружений для проектов и подпроектов.
Не надо обращаться к гуглу, чтобы понять какие настройки есть и где их настраивать.
Правда были вещи в VSCode, которые успели понравиться:
Преднастроенные тесты реально можно положить в гит и они будут рабочими.
Не знаю как называется: на Ctrl+P команды быстрого запуска/поиска/ввода, которые удобны любителям консоли как я.
Запускается быстрее чем PyCharm даже с горой плагинов и ест меньше памяти.
Но в целом, работа на PyCharm выполняется быстрее и комфортнее. Цены бы ещё по коммунистичнее...
Поднимите мне после установки из коробки l2tp/ipsec по ключу с алгоритмами 3des-sha1-modp1024 / 3des-sha1 меньшим количеством действий, чем на винде. (СПОЙЛЕР: можете даже не пытаться, из коробки вообще не работает l2tp/ipsec).
Нифига себе "домохозяйки"! Нет, ну если серьёзно, фанатики форточек реально во всех спорах крайне непоследовательны (да не воспримут на свой счёт те, кому Windows реально более удобный и больше подходит). Почему-то когда вопрос встаёт о "домохозяйках", оказывается, что эти самые бедные женщины/мужчины поднимают VPNы, шарят в поиске драйверов, устанавливают такое топовое железо, что задаёшься вопросом — "а как часто тебе, бедная домохозяюшка, приходится устанавливать систему?".
Серьёзно, давайте быть последовательными. Для реальных домохозяек Linux очень даже хорошо подходит и в некоторых аспектах даже безопаснее. Что нужно "домохозяйке":
Браузер, который сам обновляется.
Чем просматривать киношки-видосики и слушать музычку.
Написать и открыть типовой документ .docx/.xlsx.
(бухгалтеры) Запустить 1Ску и "закрыть месяц".
Чтобы не нужно было переустанавливать всю систему.
Хранить и открывать фото-, видео-материалы и документики, так чтоб не пропали.
Всё. Остальное это ну никак не про домохозяек. По этим критериям определённые дистрибутивы на базе Linux очень даже подходят.
А вопросы в том, что домохозяйка не может поставить Linux сама, то это дичь дикая. Винду она тоже не поставит, а та что поставит, то и с Linux справится.
Ну вам равномерность придётся контролировать чем-то? Где-то консистентностью придётся пожертвовать, когда один сервер уже обновился, а другой запустился позже. Если в один поток запускать, то это действительно долго. Запустить в 100 потоков можно (там память нужна). Не вижу просто вообще никаких профитов от pull, кроме ресурсов на запуск.
Как нет? Или он по каким-то причинам на форточках не работает?
Кстати, а зачем именно Pull-режим? Чем обычный неустроил?
Есть мысли в направление перевести процессы внутрь k8s интеграцию с котором завезли в vmware, но тут есть опасения получить совсем монстрообразное что-то.
За k8s попробуйте посмотреть на Rancher: у них неплохая интеграция с VMWare и прочими. Т.к. используют docker-machine на деплоймент, то можно модуль легко даже самим написать. Мы взяли и допилили модуль для себя на Proxmox VE.
Ну и ещё посмотрите RancherOS ISO. Образ под себя тоже довольно просто собрать. Есть образ для hyper-v.
Отчасти соглашусь, что сильные изменения могут привести к нечитабельности. Но именно описанного в переводе функционала реально нехватало. Уродливые вложенные if или необоснованные вычисления выражения до проверки условий реально портят жизнь.
Я поднял нижний порог до Python 3.6, но реально жалею, что еще там этого функционала не реализовано. Придётся ждать ещё 3-5 лет, когда Python 3.8 будет во всех актуальных ОС. Пока что картину портит CentOS 7.
А насчёт читабельности, я бы не сказал, что этот синтаксис сложночитаем. Даже скорее наоборот.
Вообще я писал два разных вопроса :)
С гипервизором понятно — частое явление.
А вот с оркестровкой непонятно. Можно было использовать их штатный cloud-config. Для OpenStack'а есть Heat, чтобы вообще штатно всем рулить. А чтобы рулить через libvirt анзиблю даже не потребовалось бы PS запускать. Можно было бы вообще без Ansible.
Мне просто интересно для личного опыта как вы выбирали способ решения задачи и что сделали бы сейчас иначе.
Это круто, что вы читаете.
Можете ссылку кинуть на то, где можно настрочить описание бага с подробностями? А то я репозиторий только на github видел. Или туда тоже норм?
Я не сказал, что нельзя завести, только сбилдить контейнер под rancheros. Вообще, было бы круто не билдить их самим, а взять, так сказать, проверенный авторами образ, особенно в свете того, что он зависит от билд-хоста. Но это уже капризы.
Под кубиком я не запускал, но образ в несжатом виде — 1.83Гб выглядит ужасающе для вытягивания с условного dockerhub. Хотя, там наверное сама IDE большую часть занимает. Тем не менее, если не запустится под неподготовленной системой (т.е. просто ставим докер, накатываем в кластер k8s), то для куба это решение будет сомнительным. Уверен, что есть поле для оптимизации размера образа.
Релизом я называю стабильную версию, с описанием от компании, а не "мужики, прикиньте что нашёл в закромах гитхаба и вроде рабочее". Но раз политика партии говорит "молчим", то наверное на то есть причины.
А если не секрет, с чем связана такая политика? С тем, что продукт не prod-ready или какие-то маркетинговые штучки?
Так, я поднял под Ubuntu 18.04 с docker. Можно прятать за ingress, но сам проект вообще не юзабельный. Поднимается кое-как с некоторыми недокументированными движениями только в строго определённых условиях, а значит в сам кубик такое засунуть будет сложновато. В хроме меню вообще куда-то вверх убегает, а значит невозможно выбрать ни один пункт. Периодические лаги, когда окно исчезает и весь интерфейс встаёт колом.
Сама идея — классная, шрифты красивые и не плывут, авторизацию всегда можно навесить, притом разными интересными способами. В принципе, если даже не получится завернуть в K8s, то ничто не мешает подготовить виртуалку со всем необходимым для разных гипервизоров. Но реализация пока сильно сырая, поэтому работать в таком поделии невозможно. Ждём официального релиза от JB.
Как идея (если нас читают JB): можно было бы реализовать что-то вроде тонкого клиента, либо PWA (это было бы вообще киллер-фичей).
Я честно пытался завести это под RancherOS, но сбилдить контейнер мне так и не удалось. Сегодня попробую под убунтой.
Вообще проблема странная: нехватка памяти, но у меня на вируалке 8vCPU/16GB. Попробую собрать образ на убунту, там проверю и надеюсь потом завести это под RancherOS.
Попробую тогда PyCharm развернуть в пн в docker-compose за haproxy или nginx с сертификатами и http2. Если заведется, тогда можно попробовать в кубик загнать. Если и там заведется, то вообще JetBrains-as-Service это неплохая затея. Жаль только тестированные версии староваты.
Правильно ли я понимаю:
Получается можно завести все в Kubernates?
Видимо так же как и серые зарплаты.
Что-то у меня с настроенным DoH пересылка запросов не пошла. А то что вы привели в качестве пруфа, говорит о том, что DoH в принципе теперь поддерживается.
Либо вам чуждо понятие примера. Вместо
.all()может быть любой фильтр и тогда первый пример сразу не подходит. Если параметров для поста довольно много, то можно получить не очень читабельный код, да и оптимизации это не прибавит — SQL будет либо таким же, либо около того.Но если запрос тупо на всех авторов, которые имеют хотя бы один пост, то первый ваш пример самый читабельный. Если нужно отобрать только по содержимому заголовка, то второй тоже неплох. Но если говорить о реальном приложении, то очень редко происходит, что нужно получить данные не с уже имеющегося объекта qs.
Хотя конечно же нужно было мне написать пояснение к моему ходу мыли, чтобы неокрепшие умы не сломались. И вообще, оптимизировать надо исходя из задачи и т.д.
Он сделает обычный join или подзапрос — уже и не помню. Но движок бд всяко быстрее отработает + там скорее всего будет пагинатор использоваться, а значит такой вариант больше подойдёт. Ну и список авторов будет без всяких distinct выдавать только уникальные записи.
В п.3 наверное было бы проще сразу всех авторов получить у которых post__id в qs. На практике это обычно быстрее, потому что полностью одним запросом к СУБД делается, пусть и с подзапросом.
Я когда игрался обратил внимание в одном из видео, что нужно произвести манипуляции с VM, что-то с реестром сделать и т.д.
Ох, как же я вас понимаю.
У себя в команде хотел всех с PyCharm перекинуть на VSCode. Мы честно проработали почти полгода и я сам же сдался и поставил PyCharm. Теперь думаем Pro лицензии закупить, но придётся копить (под стартап не попадаем, потому что юр.лицо слишком давно сделали).
Из того что раздражало:
Правда были вещи в VSCode, которые успели понравиться:
Но в целом, работа на PyCharm выполняется быстрее и комфортнее. Цены бы ещё по коммунистичнее...
Я с Windows не работаю, но первое что приходит на ум это VDI для разработчиков. Там WSL2 уже будет вторым слоем.
Нифига себе "домохозяйки"! Нет, ну если серьёзно, фанатики форточек реально во всех спорах крайне непоследовательны (да не воспримут на свой счёт те, кому Windows реально более удобный и больше подходит). Почему-то когда вопрос встаёт о "домохозяйках", оказывается, что эти самые бедные женщины/мужчины поднимают VPNы, шарят в поиске драйверов, устанавливают такое топовое железо, что задаёшься вопросом — "а как часто тебе, бедная домохозяюшка, приходится устанавливать систему?".
Серьёзно, давайте быть последовательными. Для реальных домохозяек Linux очень даже хорошо подходит и в некоторых аспектах даже безопаснее. Что нужно "домохозяйке":
Всё. Остальное это ну никак не про домохозяек. По этим критериям определённые дистрибутивы на базе Linux очень даже подходят.
А вопросы в том, что домохозяйка не может поставить Linux сама, то это дичь дикая. Винду она тоже не поставит, а та что поставит, то и с Linux справится.
Ну вам равномерность придётся контролировать чем-то? Где-то консистентностью придётся пожертвовать, когда один сервер уже обновился, а другой запустился позже. Если в один поток запускать, то это действительно долго. Запустить в 100 потоков можно (там память нужна). Не вижу просто вообще никаких профитов от pull, кроме ресурсов на запуск.
RancherOS под vmware тоже есть.
Не совсем понял суть вашего кейса, из-за которого вам быстрее pull, но дело хозяйское.
Как нет? Или он по каким-то причинам на форточках не работает?
Кстати, а зачем именно Pull-режим? Чем обычный неустроил?
За k8s попробуйте посмотреть на Rancher: у них неплохая интеграция с VMWare и прочими. Т.к. используют docker-machine на деплоймент, то можно модуль легко даже самим написать. Мы взяли и допилили модуль для себя на Proxmox VE.
Ну и ещё посмотрите RancherOS ISO. Образ под себя тоже довольно просто собрать. Есть образ для hyper-v.
Интересно мнение ваше на этот счет.
Кстати, спасибо большое за вашу работу в этом направлении. Может хоть так начнут читать PEPы.
Отчасти соглашусь, что сильные изменения могут привести к нечитабельности. Но именно описанного в переводе функционала реально нехватало. Уродливые вложенные if или необоснованные вычисления выражения до проверки условий реально портят жизнь.
Я поднял нижний порог до Python 3.6, но реально жалею, что еще там этого функционала не реализовано. Придётся ждать ещё 3-5 лет, когда Python 3.8 будет во всех актуальных ОС. Пока что картину портит CentOS 7.
А насчёт читабельности, я бы не сказал, что этот синтаксис сложночитаем. Даже скорее наоборот.
Вообще я писал два разных вопроса :)
С гипервизором понятно — частое явление.
А вот с оркестровкой непонятно. Можно было использовать их штатный cloud-config. Для OpenStack'а есть Heat, чтобы вообще штатно всем рулить. А чтобы рулить через libvirt анзиблю даже не потребовалось бы PS запускать. Можно было бы вообще без Ansible.
Мне просто интересно для личного опыта как вы выбирали способ решения задачи и что сделали бы сейчас иначе.