А зачем? Если это для удобства когда есть длинные функции и поставив курсор у одной скобки, чтобы выделилась скобка на другом конце, можно это делать в комментариях:
Конечно можно, но посмотрите, сколько лишних символов сразу появилось на экране. Очевидно, что визуально воспринимать код стало сложнее. Как я и писал выше - это костыль.
Просто на скриншоте выше цветовая схема выбрана не очень. Отображение невидимых символов многие включали давно и в других языках с фигурными скобками. С нормальной цветовой схемой подсветки проблем с чтением не возникает.
В данном случае точками помечаются только пробелы в конце строки. Табов тут нет, но помечаются они чуть по другому.
Так ведь в джанге не централизованно, в смысле не все роуты в одном месте. Есть главный роутер (root urlconf в терминологии джанги), а оттуда роуты могут инклюдиться. Например у подключённого модуля могут быть свои роуты, в таком случае инклюдитcя роутер этого модуля. При этом при необходимости роуты сторонних модулей можно переопределить, если хочется чтобы ссылки выглядели по другому. Получается очень гибко.
Не совсем. Допустим, у нас есть несколько страниц, где нужно вывести компонент, например bitrix:catalog.section с почти теми же настройками, но с разными кастомными шаблонами, либо просто с разными фильтрами. Сам компонент стандартный, не модифицированный, модифицировался только его шаблон.
И вот вместо того чтобы копировать одну и ту же простыню параметров этого компонента, можно массив параметров описать в каком нибудь файле local/components/.conf/configname.php, написать функцию getComponentConf(string $name, array $paramsToOverrride = []), которая при вызове getComponentConf('configname') подключает внутри себя соответствующий файл и возвращает массив, который и подставляется в includeComponent('bitrix:catalog.section', 'mytemplate', getComponentConf('configname')).
Но визуальный редактор параметров компонента это не любит и при попытке его отредактировать выдаёт ошибку. Но обычно это не проблема, т.к. туда что-то редактировать зачастую никто не лезет.
Но для кастомных так не получится, к ним нет подробной документации.
Смотря чей кастом. Да и в битриксе и так приходится нередко в код ядра заглядывать чтобы понять как он должен работать, документация не всё покрывает.
А в случае когда приходится использовать на разных страницах один и тот же компонент, но с разными шаблонами или с изменёнными парой параметров, то вместо копирования простыни параметров размещаю их в одном месте и просто переиспользую эти параметры. Да, это ломает редактирование параметров компонента из визуального редактора, но зачастую не предполагается что какой-то контент-менеджер будет вообще лезть что-то там править.
Ну, вариант с редактированием компонента на тестовой странице и последующим копированием кода компонента оттуда куда надо тоже ок, кому как удобнее.
Визуальным редактором не обязательно пользоваться. По задумке он для вебмастеров, которые не занимаются программированием, а у них есть CMS и они всё делают через её админку.
Тут надо думать. Если конкурс электронной музыки, то ещё надо определиться можно ли использовать сторонние семплы и если можно, то по идее только доступные по свободной лицензии типа Creative Commons. Нужно также определиться насчёт пункта "используя только опенсорсное ПО", должна ли под него подпадать операционная система или касается только ПО, участвующее в непосредственно в создании музыки (DAW, плагины). Хотя лично мне бы больше было интересно посмотреть на результаты творчества под Linux. В сети можно конечно найти такие поделки, но там качество такое себе, а вот благодаря таким конкурсам качество может возрасти, по идее.
Демосцена круто конечно, но по мне так уже приелась. Я больше по музыкальной части угарал, визуалом не особо интересуюсь. Хорошие музыкальные треки хотя бы переслушивать хочется. Но только не чиптюны (в т.ч. треки из семплов восьмибитных игр), это также приелось до раздражения.
Мне кажется демосцену стоит развить как фестивали компьютерного искусства дальше, зря зациклились на старом железе и идее выжать из 64K максимум. Например можно было бы дополнить рубрикой где нужно творить используя только опенсорсное ПО.
Про "заслуживает" сильно притянуто за уши. Линукс тоже не очень популярен и в нём многое далеко от идеала.
А проблема с Firefox больше в том что Open Source сообщество не в состоянии сделать форк и развивать его самостоятельно. (те мелкие форки, где тупо выпиливают "лишний" функционал, не в счёт)
А я люблю радио. С ним не надо заморачиваться "что бы сегодня послушать", там кто-то уже постарался отобрать более менее норм музыку, а не тупо алгоритм, пытающийся с переменным успехом угадать твой вкус. Правда это в основном частные энтузиастские интернет-радио, а не обычное эфирное радио с рекламой и одними хитами весь день.
Подкасты не совсем то, там есть перемотка, а когда есть перемотка, я постоянно на неё отвлекаюсь чтобы пропустить какой-то участок/трек.
А что это меняет? В отличие от точных наук, историю можно без ущерба улучшить, выдумав любые факты. Только не говорите что в официальной истории так никто никогда не делал )
Из этих трёх я предпочёл бы AppImage за его простоту. Snap и Flatpak какие-то overengineered вундервафли, излишне всё усложняющие. А sandboxing должен быть реализован отдельным инструментом, без привязки к пакетному менеджеру.
А вообще старые добрые тарбол-бандлы и так были ок. Вон как Mozilla свои продукты распространяет много лет со своего сайта. Ну подумаешь место на диске неэффективно используется, я предпочту пожертвовать этим.
Кстати, идея не нова, много лет уже был проект Zero Install https://0install.net/ и по мне так реализация получше Snap и Flatpak. Но за ним не стоит корпорация, поэтому без агрессивного навязывания известен только в узких кругах.
Ну и ещё по своему проблему решают в дистрах Nix, Gobolinux (не в курсе жив ли ещё) и прочих.
Это Гном небось 20ГБ отъел? У меня вон KDE Neon с двумя месяцами аптайма гораздо лучше себя чувствует, ресурсы отжирают в основном браузеры и кое какие проги на Electron. Сами кеды при этом потребляют вместе с системой где-то полгига всего.
Ну а что разработчики должны, вместо того чтобы использовать, например, libpng, писать свою собственную альтернативу этой библиотеки и юзать её? Так проблему это тоже не решит, просто вместо libpng будет свой велосипед.
Только у автора скорее проблема с bloated приложениями на фреймворках типа Electron, а не из-за dll'ок. Так-то это нормально использовать для определённой функции какую-то библиотеку, реализующую конкретную функцию.
А какие проблемы? Я видел код на других языках, где в одном файле смешивали отступы табами с пробелами, вот это действительно ад и ужас.
А зачем? Если это для удобства когда есть длинные функции и поставив курсор у одной скобки, чтобы выделилась скобка на другом конце, можно это делать в комментариях:
Просто на скриншоте выше цветовая схема выбрана не очень. Отображение невидимых символов многие включали давно и в других языках с фигурными скобками. С нормальной цветовой схемой подсветки проблем с чтением не возникает.
В данном случае точками помечаются только пробелы в конце строки. Табов тут нет, но помечаются они чуть по другому.
Так ведь в джанге не централизованно, в смысле не все роуты в одном месте. Есть главный роутер (root urlconf в терминологии джанги), а оттуда роуты могут инклюдиться. Например у подключённого модуля могут быть свои роуты, в таком случае инклюдитcя роутер этого модуля. При этом при необходимости роуты сторонних модулей можно переопределить, если хочется чтобы ссылки выглядели по другому. Получается очень гибко.
А мне не нравится роутинг через декораторы, не понимаю зачем многие фреймворки так делают, Flask тот же. Вот джанговский подход мне нравится.
Не совсем. Допустим, у нас есть несколько страниц, где нужно вывести компонент, например
bitrix:catalog.sectionс почти теми же настройками, но с разными кастомными шаблонами, либо просто с разными фильтрами. Сам компонент стандартный, не модифицированный, модифицировался только его шаблон.И вот вместо того чтобы копировать одну и ту же простыню параметров этого компонента, можно массив параметров описать в каком нибудь файле
local/components/.conf/configname.php, написать функциюgetComponentConf(string $name, array $paramsToOverrride = []), которая при вызовеgetComponentConf('configname')подключает внутри себя соответствующий файл и возвращает массив, который и подставляется вincludeComponent('bitrix:catalog.section', 'mytemplate', getComponentConf('configname')).Но визуальный редактор параметров компонента это не любит и при попытке его отредактировать выдаёт ошибку. Но обычно это не проблема, т.к. туда что-то редактировать зачастую никто не лезет.
Да.
Смотря чей кастом. Да и в битриксе и так приходится нередко в код ядра заглядывать чтобы понять как он должен работать, документация не всё покрывает.
А в случае когда приходится использовать на разных страницах один и тот же компонент, но с разными шаблонами или с изменёнными парой параметров, то вместо копирования простыни параметров размещаю их в одном месте и просто переиспользую эти параметры. Да, это ломает редактирование параметров компонента из визуального редактора, но зачастую не предполагается что какой-то контент-менеджер будет вообще лезть что-то там править.
Ну, вариант с редактированием компонента на тестовой странице и последующим копированием кода компонента оттуда куда надо тоже ок, кому как удобнее.
Визуальным редактором не обязательно пользоваться. По задумке он для вебмастеров, которые не занимаются программированием, а у них есть CMS и они всё делают через её админку.
Как мне кажется, большинство, кто занимается разработкой, увлеклись программированием ещё со школы. Вряд ли курсы способны поменять образ мышления.
Хотя, если человек этим действительно увлёкся, с фанатизмом, то всё возможно.
Тут надо думать. Если конкурс электронной музыки, то ещё надо определиться можно ли использовать сторонние семплы и если можно, то по идее только доступные по свободной лицензии типа Creative Commons.
Нужно также определиться насчёт пункта "используя только опенсорсное ПО", должна ли под него подпадать операционная система или касается только ПО, участвующее в непосредственно в создании музыки (DAW, плагины).
Хотя лично мне бы больше было интересно посмотреть на результаты творчества под Linux. В сети можно конечно найти такие поделки, но там качество такое себе, а вот благодаря таким конкурсам качество может возрасти, по идее.
Демосцена круто конечно, но по мне так уже приелась. Я больше по музыкальной части угарал, визуалом не особо интересуюсь. Хорошие музыкальные треки хотя бы переслушивать хочется. Но только не чиптюны (в т.ч. треки из семплов восьмибитных игр), это также приелось до раздражения.
Мне кажется демосцену стоит развить как фестивали компьютерного искусства дальше, зря зациклились на старом железе и идее выжать из 64K максимум. Например можно было бы дополнить рубрикой где нужно творить используя только опенсорсное ПО.
Про "заслуживает" сильно притянуто за уши. Линукс тоже не очень популярен и в нём многое далеко от идеала.
А проблема с Firefox больше в том что Open Source сообщество не в состоянии сделать форк и развивать его самостоятельно. (те мелкие форки, где тупо выпиливают "лишний" функционал, не в счёт)
Вот и я о том же, только не только тут, а вообще.
Не такая же. Если допустить ошибку в медицине, могут возникнуть серьёзные проблемы. Важность истории же сильно преувеличена.
А я люблю радио. С ним не надо заморачиваться "что бы сегодня послушать", там кто-то уже постарался отобрать более менее норм музыку, а не тупо алгоритм, пытающийся с переменным успехом угадать твой вкус.
Правда это в основном частные энтузиастские интернет-радио, а не обычное эфирное радио с рекламой и одними хитами весь день.
Подкасты не совсем то, там есть перемотка, а когда есть перемотка, я постоянно на неё отвлекаюсь чтобы пропустить какой-то участок/трек.
А что это меняет? В отличие от точных наук, историю можно без ущерба улучшить, выдумав любые факты. Только не говорите что в официальной истории так никто никогда не делал )
Из этих трёх я предпочёл бы AppImage за его простоту. Snap и Flatpak какие-то overengineered вундервафли, излишне всё усложняющие. А sandboxing должен быть реализован отдельным инструментом, без привязки к пакетному менеджеру.
А вообще старые добрые тарбол-бандлы и так были ок. Вон как Mozilla свои продукты распространяет много лет со своего сайта. Ну подумаешь место на диске неэффективно используется, я предпочту пожертвовать этим.
Кстати, идея не нова, много лет уже был проект Zero Install https://0install.net/ и по мне так реализация получше Snap и Flatpak. Но за ним не стоит корпорация, поэтому без агрессивного навязывания известен только в узких кругах.
Ну и ещё по своему проблему решают в дистрах Nix, Gobolinux (не в курсе жив ли ещё) и прочих.
Это Гном небось 20ГБ отъел? У меня вон KDE Neon с двумя месяцами аптайма гораздо лучше себя чувствует, ресурсы отжирают в основном браузеры и кое какие проги на Electron. Сами кеды при этом потребляют вместе с системой где-то полгига всего.
Ну а что разработчики должны, вместо того чтобы использовать, например, libpng, писать свою собственную альтернативу этой библиотеки и юзать её? Так проблему это тоже не решит, просто вместо libpng будет свой велосипед.
Только у автора скорее проблема с bloated приложениями на фреймворках типа Electron, а не из-за dll'ок. Так-то это нормально использовать для определённой функции какую-то библиотеку, реализующую конкретную функцию.
Тандербёрдом-то я пользуюсь много лет, но я не торчу за десктопом круглосуточно.
Кроме того, используются всякие утилиты типа ssmtp/msmtp для отправки себе уведомлений по событиям.
Впрочем, oauth не единственная проблема у гпочты.