Но все-таки, я пишу на Django еще с версии 0.9.6...
Круто, но к чему это?
Я сделал на нем много проектов
За все это время приходилось создавать проекты не более 10 раз
Вы либо путаетесь в показаниях, либо 10 раз считаете "много".
Новый проект это может быть один файл settings.py, а может быть пакет с заготовками, файлы tox.ini и заготовкой тестов, setup.py и setup.cfg (для тех кто хотел бы оформить это как пакет), Dockerfile+helmchart для тех, кто всё это хочет укомплектовать в Кубике (например, даже для AutoDevOps Gitlab) и ещё много чего.
Опять же, если вы единственный разработчик проектов, то руками можно спокойно создавать, но лично мне будет спокойнее, если я дам задание подчинённому создать проект и он разложит всё так, что другие участники будут понимать что и где лежит. Короче говоря то же самое, что написал kalombo.
Микро — не значит для одной задачи. Так что не соглашусь. Микросервисом может быть большой и сложный сервис одного ещё более огромного проекта.
А по теме: cp может нехватить, если имя пакета много где упоминается, а проект не состоит из одного .py. Так что если вам хватает, то это не обязательно правильно.
А зачем два если один мощнее двух?) По сути мало что топовую десктопную линейку отличает от серверной, кроме поддержки связи между камнями. Но ведь межпроцессорная связь медленнее чем внутрипроцессорная. Поэтому я вижу одни только преимущества.
Но если кто подкинет мне вариант шаси под него с двумя бп (с HOT SWAP, естественно), то было бы интересно)
Сходу гуглится корпус один и второй. Но если поискать, то можно найти что-то более экономное или просто лучше. Большая башня позволит нормальный теплоотвод поставить.
Тредриперы — это не серверные процы, а для рабочих станций.
А что вы вкладываете в это понятие? Чисто технически:
один тредриппер 3990X заменяет по количеству ядер 2 Xeon 8164 + ещё 8 ядер;
частота гораздо выше;
L3-кеш втрое больше;
поддерживает ECC DDR4 как и Интел (правда памяти втрое меньше).
В рамках поста мне кажется действительно неплохой вариант. Вендор всё равно оказался не преимуществом. Сложно было бы платформу подобрать в стойку, но по цене всё равно значительная разница.
Тут всё от преподавателей зависит. Если препод как большинстве ВУЗов РФ, то наверное действительно аудио-видео даже лучше + самостоятельная практика. Но если преподаватель работает с обратной связью и обучает через мышление и вопросы, то с этим ни одна книга не сравнится.
Ко всему очень влияет продуманность порядка подачи информации: все хотят сразу хардкор, пропуская базу, а образовательный процесс так работает не всегда хорошо.
Не смотря на некоторые недочёты в использовании apk и в целом использования, спасибо за этот перевод. Я как-то не задумывался, что, возможно, некоторые тормоза и непонятного происхождения ошибки могут быть из-за musl. Думаю это отличный повод для исследования.
Просто адепты JavaScript активно впихивают разработку на десктопе, а адептам десктопов нужно чем-то ответить.
Но в целом, если нужно быстро портировать десктопное приложение в веб, то вполне себе неплохой вариант — бизнес доволен сроками, ежики кактусами пользователи возможностями.
Здесь почитать. Здесь за вас уже что-то обернули. Знания нужны на уровне инклудов и указателей (хотя бы понимать что это и как работает). На гитхабе можно посмотреть что уже из стандартных библиотек обернуто и использовать.
Но… а если нам нужно читать другие конфиги, ну там json или yaml например, или все сразу. Конечно, есть json в стандартной библиотеке и pyyaml, но придётся написать кучу (ну, или не совсем) кода для этого.
По сравнению с тем что вы предложили, гораздо проще отнаследоваться от congigparser'а и перегрузить метод read, а там по расширению брать и подставлять стандартную реализацию или как вам предложили выше.
Я не осуждаю — сам написал собственный парсер, но цель была — б`ольшая производительность. А говорить, что стандартный парсер требует кучи кода (5 строк), а потом рекламировать самописку, которая действительно много требует — это странно.
Вообще Cython не только для числодробилок профит даёт. Ещё его можно использовать как простую обёртку над C-шными функциями, например, для работы с файлами. Профит проверенный опытным путём достигал одного порядка.
Я вот тоже не могу понять. Для построения клиента есть OpenAPI/CoreAPI. На крайняк просто формируешь ответ на HEAD или OPTIONS. А для приложений, которые интегрируются с этим интерфейсом, эта вся информация только лишняя нагрузка на сеть. Данных на сотню байт не наберётся, а для описания действий с ними ещё раз 10 по столько же. И ладно если раз запросил и используешь, но на каждый чих всю структуру вываливать как-то… стремно что ли.
Всё это — просто следствие плохого проектирования языка, нецелостность реализации. Здесь у нас в реализации можно менять значение, а здесь — нельзя. Tuple — вроде неизменяемое значение, но одновременно изменяемое.
В вашем утверждении банальная логическая ошибка. Tuple как состоял из одного массива, так и состоит. Этот массив всё тот же. Его состав изменился, но массив всё тот же.
Исходя из ваших домыслов вы делаете заключение, что язык плохо спроектирован, но больше похоже на то, что вы просто не хотите принимать того факта, что вы чего-то не поняли и просто пришли "со своим уставом в чужой монастырь".
Если в C++ классе объявить protected объект, то, насколько мне известно, в его инстансе можно вызывать любые public-методы из этого объекта, которые могут изменить внутренний состав. Это тоже плохо спроектированный язык получается по вашей логике.
Есть хорошая штука — __slots__, которая определяет, что новые атрибуты не должны появляться внезапно, есть наработки у Instagram, которые действительно выглядят удобными и полезными (очень хотелось бы увидеть эту функциональность в CPython).
Но то, что вы предлагаете нарушает саму логику CPython из-за чего многим это и не понравилось, судя по комментам и минусам.
Вы где-то выше/ниже писали, что мало пишите на Python, но развивать язык, который по сути не знаешь, мне кажется заведомо плохой идеей: либо вас никто не поймёт, либо вы протолкнёте свои идеи и возможно тем самым убьете или сильно обновите community языка (что тоже не всегда хорошо).
Я согласен с вами в том, что CPython нужны перемены (хотя одного перехода с мажорной версии хватило по уши), но нужны перемены типа strict-модулей, более продуманных импортов. Но в остальном Python прекрасный язык. Когда не хватает статической типизации, мы используем Cython, когда нужно сделать что-то очень быстрое, то мы используем C API, когда нужно что-то очень быстро реализовать, то мы используем CPython. Это одна из причин, почему его любят.
До 4х включительно можно точно — проверенно годами. Но уже это требует жесткого фильтра:
не запоминать и игнорировать бесполезную информацию;
требовать конкретики от окружающих;
задачи должны быть из разных сфер и проектов (пробовал на один — весь многопоток ломается и нужно потом время отдыха не меньше недели);
процессы можно навешивать только в тех областях, где реально шаришь или через фильтр того, кто в этой сфере шарит больше.
На 5ый поток уже сложнее заходить получается и мозги сильно устают. Эмоциональная выгрузка с 5и-месячным сыном тоже помогает переформатировать мозг, но иногда можно переборщить. Всё же мозг не игрушка и надо быть очень осторожным.
А вот "нервный тик", типа постукивания ручкой, как-то не зашёл у меня: людей раздражает не меньше, чем меня, а толку — 0. Сон — самый надёжный инструмент. Мне одно приложение в деталях приснилось вообще.
Ещё очень тормозит развитие незавершённость задачи: если не дошли до решения задачи (закрыли проект, например), то мозг будет выдавать решения, пока проект не забудется. Это очень тормозит очередь задач.
Лично меня и мою контору Django 2.2 вынудила дропнуть Python 2.7. Но пока не дропнули, казалось, что преимуществ особо нет, а поддержки маломальски адекватного Python 3.5 (а лучше 3.6) не было в большинстве дистрибутивов, используемых заказчиками.
Но сократив поддержку до 3.5 и поработав так полгода, хочется подняться уже до >=3.6. Куча костылей просто отсеялось, анотации вдохнули жизнь в IDE, избавились от части кода и его тестов. Теперь облизываемся на f-strings и поддержку async (из коробки). С чем-то пришлось расстаться, но ни разу не пожалели.
Да, наши проекты в среднем 10к строк. Это немного, но и команда у нас не 10к единиц.
Правда всё равно хочется адекватного LTS в языке. Я понимаю тех, кто остаётся на 2.7, потому что ему замены нет, ведь новые версии Python'а не имеют длительной поддержки, но, справедливости ради, не ломают старой функциональности (обычно).
Короче говоря legacy — зло (да, капитан), но хотя нет LTS, двигаться дальше надо.
Хоть это и не относится к теме поста, но зачем тогда собственный сервер Gitlab? Можно и публичный использовать. Тогда и Zabbix настраивать не пришлось бы. Разве что Gitlab runner, но там мониторить нечего особо.
Круто, но к чему это?
Вы либо путаетесь в показаниях, либо 10 раз считаете "много".
Новый проект это может быть один файл
settings.py, а может быть пакет с заготовками, файлы tox.ini и заготовкой тестов, setup.py и setup.cfg (для тех кто хотел бы оформить это как пакет), Dockerfile+helmchart для тех, кто всё это хочет укомплектовать в Кубике (например, даже для AutoDevOps Gitlab) и ещё много чего.Опять же, если вы единственный разработчик проектов, то руками можно спокойно создавать, но лично мне будет спокойнее, если я дам задание подчинённому создать проект и он разложит всё так, что другие участники будут понимать что и где лежит. Короче говоря то же самое, что написал kalombo.
Микро — не значит для одной задачи. Так что не соглашусь. Микросервисом может быть большой и сложный сервис одного ещё более огромного проекта.
А по теме: cp может нехватить, если имя пакета много где упоминается, а проект не состоит из одного
.py. Так что если вам хватает, то это не обязательно правильно.А зачем два если один мощнее двух?) По сути мало что топовую десктопную линейку отличает от серверной, кроме поддержки связи между камнями. Но ведь межпроцессорная связь медленнее чем внутрипроцессорная. Поэтому я вижу одни только преимущества.
Сходу гуглится корпус один и второй. Но если поискать, то можно найти что-то более экономное или просто лучше. Большая башня позволит нормальный теплоотвод поставить.
А что вы вкладываете в это понятие? Чисто технически:
В рамках поста мне кажется действительно неплохой вариант. Вендор всё равно оказался не преимуществом. Сложно было бы платформу подобрать в стойку, но по цене всё равно значительная разница.
P.S: Я не фанат ни красных, ни синих.
Блин, это я распарсил плохо предолжение и сам же себя запутал.
Что за выдумки? Никакой строгой типизации там не включали. Type hints != Строгая типизация
Тут всё от преподавателей зависит. Если препод как большинстве ВУЗов РФ, то наверное действительно аудио-видео даже лучше + самостоятельная практика. Но если преподаватель работает с обратной связью и обучает через мышление и вопросы, то с этим ни одна книга не сравнится.
Ко всему очень влияет продуманность порядка подачи информации: все хотят сразу хардкор, пропуская базу, а образовательный процесс так работает не всегда хорошо.
Не смотря на некоторые недочёты в использовании apk и в целом использования, спасибо за этот перевод. Я как-то не задумывался, что, возможно, некоторые тормоза и непонятного происхождения ошибки могут быть из-за musl. Думаю это отличный повод для исследования.
Просто адепты JavaScript активно впихивают разработку на десктопе, а адептам десктопов нужно чем-то ответить.
Но в целом, если нужно быстро портировать десктопное приложение в веб, то вполне себе неплохой вариант — бизнес доволен сроками,
ежики кактусамипользователи возможностями.Здесь почитать. Здесь за вас уже что-то обернули. Знания нужны на уровне инклудов и указателей (хотя бы понимать что это и как работает). На гитхабе можно посмотреть что уже из стандартных библиотек обернуто и использовать.
По сравнению с тем что вы предложили, гораздо проще отнаследоваться от congigparser'а и перегрузить метод read, а там по расширению брать и подставлять стандартную реализацию или как вам предложили выше.
Я не осуждаю — сам написал собственный парсер, но цель была — б`ольшая производительность. А говорить, что стандартный парсер требует кучи кода (5 строк), а потом рекламировать самописку, которая действительно много требует — это странно.
Интересненько. А как с пакетами это работает? Он содержимое всех пакетов выведет или как? Интересно django-приложение как отпрофилирует.
Вообще Cython не только для числодробилок профит даёт. Ещё его можно использовать как простую обёртку над C-шными функциями, например, для работы с файлами. Профит проверенный опытным путём достигал одного порядка.
Я вот тоже не могу понять. Для построения клиента есть OpenAPI/CoreAPI. На крайняк просто формируешь ответ на HEAD или OPTIONS. А для приложений, которые интегрируются с этим интерфейсом, эта вся информация только лишняя нагрузка на сеть. Данных на сотню байт не наберётся, а для описания действий с ними ещё раз 10 по столько же. И ладно если раз запросил и используешь, но на каждый чих всю структуру вываливать как-то… стремно что ли.
В вашем утверждении банальная логическая ошибка. Tuple как состоял из одного массива, так и состоит. Этот массив всё тот же. Его состав изменился, но массив всё тот же.
Исходя из ваших домыслов вы делаете заключение, что язык плохо спроектирован, но больше похоже на то, что вы просто не хотите принимать того факта, что вы чего-то не поняли и просто пришли "со своим уставом в чужой монастырь".
Если в C++ классе объявить protected объект, то, насколько мне известно, в его инстансе можно вызывать любые public-методы из этого объекта, которые могут изменить внутренний состав. Это тоже плохо спроектированный язык получается по вашей логике.
Есть хорошая штука —
__slots__, которая определяет, что новые атрибуты не должны появляться внезапно, есть наработки у Instagram, которые действительно выглядят удобными и полезными (очень хотелось бы увидеть эту функциональность в CPython).Но то, что вы предлагаете нарушает саму логику CPython из-за чего многим это и не понравилось, судя по комментам и минусам.
Вы где-то выше/ниже писали, что мало пишите на Python, но развивать язык, который по сути не знаешь, мне кажется заведомо плохой идеей: либо вас никто не поймёт, либо вы протолкнёте свои идеи и возможно тем самым убьете или сильно обновите community языка (что тоже не всегда хорошо).
Я согласен с вами в том, что CPython нужны перемены (хотя одного перехода с мажорной версии хватило по уши), но нужны перемены типа strict-модулей, более продуманных импортов. Но в остальном Python прекрасный язык. Когда не хватает статической типизации, мы используем Cython, когда нужно сделать что-то очень быстрое, то мы используем C API, когда нужно что-то очень быстро реализовать, то мы используем CPython. Это одна из причин, почему его любят.
В каждой шутке есть доля утки.Не настолько безумно, конечно, но при анализе задачи кучу лишнего приходится отметать.До 4х включительно можно точно — проверенно годами. Но уже это требует жесткого фильтра:
На 5ый поток уже сложнее заходить получается и мозги сильно устают. Эмоциональная выгрузка с 5и-месячным сыном тоже помогает переформатировать мозг, но иногда можно переборщить. Всё же мозг не игрушка и надо быть очень осторожным.
А вот "нервный тик", типа постукивания ручкой, как-то не зашёл у меня: людей раздражает не меньше, чем меня, а толку — 0. Сон — самый надёжный инструмент. Мне одно приложение в деталях приснилось вообще.
Ещё очень тормозит развитие незавершённость задачи: если не дошли до решения задачи (закрыли проект, например), то мозг будет выдавать решения, пока проект не забудется. Это очень тормозит очередь задач.
Лично меня и мою контору Django 2.2 вынудила дропнуть Python 2.7. Но пока не дропнули, казалось, что преимуществ особо нет, а поддержки маломальски адекватного Python 3.5 (а лучше 3.6) не было в большинстве дистрибутивов, используемых заказчиками.
Но сократив поддержку до 3.5 и поработав так полгода, хочется подняться уже до >=3.6. Куча костылей просто отсеялось, анотации вдохнули жизнь в IDE, избавились от части кода и его тестов. Теперь облизываемся на f-strings и поддержку async (из коробки). С чем-то пришлось расстаться, но ни разу не пожалели.
Да, наши проекты в среднем 10к строк. Это немного, но и команда у нас не 10к единиц.
Правда всё равно хочется адекватного LTS в языке. Я понимаю тех, кто остаётся на 2.7, потому что ему замены нет, ведь новые версии Python'а не имеют длительной поддержки, но, справедливости ради, не ломают старой функциональности (обычно).
Короче говоря legacy — зло (да, капитан), но хотя нет LTS, двигаться дальше надо.
Тёзка да ещё и тоже с Приморья — привет!
Так а как сейчас с работой? Так же в PHP стеке?
Хоть это и не относится к теме поста, но зачем тогда собственный сервер Gitlab? Можно и публичный использовать. Тогда и Zabbix настраивать не пришлось бы. Разве что Gitlab runner, но там мониторить нечего особо.