Ну как раз канбан бывает вполне удобен для личных дел, когда нужно списки разбить по теме, статусу выполнения или времени. Я, например, использую списки типа "Нужно сделать", "Сегодня", "На этой неделе", "На следующей неделе", "На контроле".
Когнитивно этот "ago"-формат проще, чем цифровые значения, но, разумеется, не должен использоваться там, где важна точность. Где-то встречал вариант, где по тапу/клику меняется "3 дня назад" на конкретную дату и наоборот. Тоже неплохо, но заставляет выделять объект как кликабельный, иначе фича будет неочевидна.
Компиляцией SASS в CSS должен заниматься не Джанго, а бандлер на стороне фронтенда: Webpack или Vite. Даже в "монолитных" приложениях. То, что вы описали в статье - оверкилл и анти-практика.
Как там говорят? "Это частная компания и она вправе делать всё, что посчитает необходимым!". Или, перефразируя: наша тоталитарная цензура и их демократическое управление общественным мнением :)
Наверное, немаловажный нюанс - это область применения. JSON хорош там, где нужен стандартизированный и надёжный формат данных, т.е. почти везде. Тем не менее, в статье упоминается, что YAML задумывался как человекопонятный формат, который удобно писать руками, и есть масса рутинных ситуаций, где большинство описанных ТСом проблем никогда и не встретятся, а скорость и удобство ручной работы при этом в разы возрастёт.
Например, я работаю с October CMS, где CRUD'ы конфигурируются как раз простыми YAML-файлами. Изо дня в день приходится писать что-то вроде:
fields:
is_active:
label: 'foo.catalog::lang.products.fields.is_active.label'
type: switch
span: full
default: true
comment: 'foo.catalog::lang.products.fields.is_active.comment'
vendor_code:
label: 'foo.catalog::lang.products.fields.vendor_code.label'
type: text
span: auto
category:
label: 'foo.catalog::lang.products.fields.category.label'
type: relation
nameFrom: title
span: auto
emptyOption: 'foo.catalog::lang.products.fields.category.empty_option'
title:
label: 'foo.catalog::lang.products.fields.title.label'
type: text
span: auto
Аналогичный конфиг набивать руками в виде JSON или нативного массива в PHP гораздо сложнее и неудобнее. При этом за годы работы и тонны написанных конфигов я ни разу не встретился с каким-либо неочевидным поведением парсера YAML.
Мой вывод: каждый инструмент хорош на своем месте, если ты знаешь его особенности и можешь использовать его максимально эффективно.
При грамотной установке сертифицированного оборудования риск подобного стремится к нулю. При кустарной установке в гараже у Ашота, конечно же, может быть что угодно. Не в обиду Ашотам)
Всё это было до iPhone. Но Apple смогли сделать это всё юзабельным и активно продвинули на рынок. И, в общем-то, у них получился хороший продукт, который плотно занял свою нишу. Но без такого маркетинга он вполне мог бы попасть в один ряд со многими другими хорошими продуктами, которые "не выстрелили".
Граф Де Генерат.
Ну как раз канбан бывает вполне удобен для личных дел, когда нужно списки разбить по теме, статусу выполнения или времени.
Я, например, использую списки типа "Нужно сделать", "Сегодня", "На этой неделе", "На следующей неделе", "На контроле".
Что не так? Лингвистика - не наука или что?
"Экспаты" это очень громко сказано.
Плюсую, October это лучшее, что случалось с CMS.
А чем октобер не устроил? Лучшей админки не существует, имхо)
И все мы видим, к чему это привело.
>все свободы
Какие?
Только это больше про пост-капитализм, чем про социализм.
С другой стороны, у краткосрочной аренды есть и неоспоримые преимущества в тех случаях, когда арендуемая вещь нужна эпизодически и нерегулярно.
Конечно нельзя, это пока в принципе совершенно утопические фантазии.
>кроссплатформенные невзаимозаменяемые цифровые объекты и при этом передавать их в реальное, т.е. фактическое владение.И пока никто вменяемо не смог объяснить, что именно это означает и какова практическая ценность этого с примером из реального мира.
Как будто между сайтами-визитками и продуктами уровня OpenAI/Гугла больше ничего нет)
Когнитивно этот "ago"-формат проще, чем цифровые значения, но, разумеется, не должен использоваться там, где важна точность. Где-то встречал вариант, где по тапу/клику меняется "3 дня назад" на конкретную дату и наоборот. Тоже неплохо, но заставляет выделять объект как кликабельный, иначе фича будет неочевидна.
Это целый бандл, сейчас можно в проект тащить только используемые модули и компоненты, и конечный вес будет кратно меньше.
Швабоповесточка уже на Хабре, какая милота!
Компиляцией SASS в CSS должен заниматься не Джанго, а бандлер на стороне фронтенда: Webpack или Vite. Даже в "монолитных" приложениях. То, что вы описали в статье - оверкилл и анти-практика.
Как там говорят? "Это частная компания и она вправе делать всё, что посчитает необходимым!". Или, перефразируя: наша тоталитарная цензура и их демократическое управление общественным мнением :)
Наверное, немаловажный нюанс - это область применения. JSON хорош там, где нужен стандартизированный и надёжный формат данных, т.е. почти везде. Тем не менее, в статье упоминается, что YAML задумывался как человекопонятный формат, который удобно писать руками, и есть масса рутинных ситуаций, где большинство описанных ТСом проблем никогда и не встретятся, а скорость и удобство ручной работы при этом в разы возрастёт.
Например, я работаю с October CMS, где CRUD'ы конфигурируются как раз простыми YAML-файлами. Изо дня в день приходится писать что-то вроде:
Аналогичный конфиг набивать руками в виде JSON или нативного массива в PHP гораздо сложнее и неудобнее. При этом за годы работы и тонны написанных конфигов я ни разу не встретился с каким-либо неочевидным поведением парсера YAML.
Мой вывод: каждый инструмент хорош на своем месте, если ты знаешь его особенности и можешь использовать его максимально эффективно.
При грамотной установке сертифицированного оборудования риск подобного стремится к нулю. При кустарной установке в гараже у Ашота, конечно же, может быть что угодно. Не в обиду Ашотам)
Всё это было до iPhone. Но Apple смогли сделать это всё юзабельным и активно продвинули на рынок. И, в общем-то, у них получился хороший продукт, который плотно занял свою нишу. Но без такого маркетинга он вполне мог бы попасть в один ряд со многими другими хорошими продуктами, которые "не выстрелили".