В том виде как описано здесь — это лож. Создание преград для отвлечения никак не относится к «проработайте ваши будущие действия».
Идея первой стратегии в том, что бы процесс достижения цели стал максимально прозрачен для мозга. Мозг не хочет работать с чем-то сложным. Он сохраняет сахар про запас.
Проработать будущие действия — это составить список небольших действий и уже понятных для мозга действий для достижения цели. Сегодня набрасываю сюжет. Разбиваю сюжет на главы. Пишу первую главу. Пишу вторую. Вычитываю первую. Пишу третью. Вычитываю вторую. Вношу правки исходя из первых трёх двух глав. И т.д.
Каждый раз мы знаем объём работ и часть сюжета. Можем влиять на изменение сюжета. Всегда есть отступ на корректировку не идеально выполненной работы. Мы можем не заморачиваться на идеальном тексте сразу и получить быстрый результат.
И я прекрасно понимаю, что это перевод. Мой пост автору, а не переводчику.
Попросили меня оптимизировать сайт на Битрикс. Посмотрел то что предлагает гугл. Понял что большая часть предложений бесполезна. Инлаин js в компонентах сломается если снести из заголовка библиотеки в конец страницы. Пожать инлаин js и css не получится. Объединить css и js файлы из заголовка не получится. Картинки можно оптимизировать, но работа с ними такая, что появятся новые не оптимизированные. Запросы к БД не оптимизировать. И т.д. и т.п. Проще замазать чем отодрать.
А ещё мне дали пощупать лендинг на Битрикс. Он загружается десяток секунд. Это песня.
Это правда, что под Битрикс не нужно разрабатывать, но всегда найдутся желающие получить деньги с неумных людей.
1. Не вижу хоть какой-то причины, что бы собирать подобное видео. Там не такой сложный интерфейс, что бы его протестировать не на реальных пользователях, а в компании.
2. Всегда выставленные ограничения по сбору данных можно изменить хотя бы временно, хотя бы в момент компании продвижения, хотя бы инсайдером или хакером и для чьих-то интересов не связанных с разработкой.
3. На основании двух верхних пунктов фитча должна быть обоснована, а она остаётся не обоснованной.
До определённого возраста стоит читать художественное.
Достоевского, Толстого, Бунина, Пушкина, Драйзера, Шекспира и т.д. я не исключаю, пока не наступает момент, когда ты сам становишься частью того, о чём читал. Тогда ты уже создаешь свою драму, комедию, трагедию. Художественное тогда уход от своих проблем, что их усугубляет.
У меня нет проблем с художественной литературой. Я её не читаю. Что-то публицистическое возможно.
До определённого возраста стоит читать художественное. Если столкнулся хорошо с реальностью, то это пустая обуза. И это не из-за эгоизма, а против тупости современной художественной литературы. Она бесполезна относительно радуги реальной жизни. И фантастика то же.
Но я не могу отобрать игрушку у детей. И не собираюсь. Им нужно дорасти до этого. До принятия реальности и решения своих проблем. Но многим нравится тешить своё я прикрываясь фантазией.
Ещё раз. Всё что есть — нужно, но на разных уровнях развития сознания. На каком-то и книги не нужны.
Повторно используемая библиотека, пакет модуль, плагин или фреймвок — это продукты.
Если вы пишите отдельное приложение, но не библиотеку, пакет модуль, плагин или фреймвок, то повторное использование кода возможно только на уровне самого приложения.
Всё это про «магию». Вечная борьба прямого кода и «магии», которую считают рефакторингом. Но последний делается по факту, а вот «магия» — это часто преждевременная оптимизация.
Автор, переведённой статьи, изобрёл один из небольших разделов «магии» согласно того с чем ему приходится сталкиваться. Она работает на простых проектах. Где модели не содержат сколько-то сложных агрегаторов.
Если принять то, что это «магия» и она может работать в какой-то группе приложения, то я соглашусь с её применением. Когда есть простые модели (контекст laravel, а не DDD) и их связи. Если разработчик один. Пусть.
Но бывает всё сложнее. Бывает нужно передать в сервис несколько репозиториев, а то ещё и другой сервис. После сервиса нужно выполнить нечто инфраструктурное, например, отправить почту и/или пуши, логировать и т.д. на основе успешности выполнения сервиса. Добавим в абстракцию сервиса подписку на события?
Может в сервисе потребоваться дополнительная валидация, так как она нужна не везде, а там где нужна и валидируются не только входящие данные запроса. Её то же повесим абстракцией на сервис?
Но главная проблема — это когда в проекте джуниор или условный мидл начинает писать код по аналогии увиденной «магии», не думая о её востребованности в его части задачи. Ведь понимание чьей-то «магии» так завораживает. Хочется то же стать «магом». Это приятно и побочные эффекты сразу не видны. Причём когда джуниор видит, что «магия» в конкретном случае не работает, то начинается его магия, например, с прямым доступом к моделям (контекст laravel).
Вот тогда задумываешься. С одной стороны можно быстро сделать прототип большой части проекта, а с другой загубить его в самой сложной части.
Может оставить такие вопросы какой-нибудь комиссии стандартизации.
В любом случае можно определится с «чистыми» URI касательно платёжных средств и т.д. Это как маркировка. Понятно что будет куча «не умных» пользователей и «хитрых» бизнесменов. Но можно отстранится от их игр.
Другой вариант подписывать сертификатами целые списки URI, а не только домены. И цветом выделять то что за гранью.
Не обязательно. Просто цветом выделять с когнитивной провокацией домен.Далее после привыкания пользователями к источнику информации можно, что-то более тонко регулировать.
Де факто — латиница уровень один.
Прочие, хоть как на своём языке. Думаю, что для сбера не проблема сайт на латинице.
Здесь дело в чём. Что не латиница — то красим. И пользователей учим, что если радуга — то это не официально.
Что проще всего? Выводить юникод символы цветными (жёлтый) и обозначить требование для серьёзных сайтов необходимость в латинице.
Разделяй, раскрашивай и властвуй через строку браузера!
История с Дарвином не имеет отношения к любопытству. Это чистой воды жадность. Любопытство проявилось, если бы он по очереди совал в рот разных насекомых ради нового опыта.
А мне всё равно. Я пошёл на реку.
Каждое существо своё страдание создаёт через своё сознание. Но мы уверены, что сознание других существ создаёт наше страдание.
В том виде как описано здесь — это лож. Создание преград для отвлечения никак не относится к «проработайте ваши будущие действия».
Идея первой стратегии в том, что бы процесс достижения цели стал максимально прозрачен для мозга. Мозг не хочет работать с чем-то сложным. Он сохраняет сахар про запас.
Проработать будущие действия — это составить список небольших действий и уже понятных для мозга действий для достижения цели. Сегодня набрасываю сюжет. Разбиваю сюжет на главы. Пишу первую главу. Пишу вторую. Вычитываю первую. Пишу третью. Вычитываю вторую. Вношу правки исходя из первых трёх двух глав. И т.д.
Каждый раз мы знаем объём работ и часть сюжета. Можем влиять на изменение сюжета. Всегда есть отступ на корректировку не идеально выполненной работы. Мы можем не заморачиваться на идеальном тексте сразу и получить быстрый результат.
И я прекрасно понимаю, что это перевод. Мой пост автору, а не переводчику.
Впрочем это вне разума.
А ещё мне дали пощупать лендинг на Битрикс. Он загружается десяток секунд. Это песня.
Это правда, что под Битрикс не нужно разрабатывать, но всегда найдутся желающие получить деньги с неумных людей.
2. Всегда выставленные ограничения по сбору данных можно изменить хотя бы временно, хотя бы в момент компании продвижения, хотя бы инсайдером или хакером и для чьих-то интересов не связанных с разработкой.
3. На основании двух верхних пунктов фитча должна быть обоснована, а она остаётся не обоснованной.
Достоевского, Толстого, Бунина, Пушкина, Драйзера, Шекспира и т.д. я не исключаю, пока не наступает момент, когда ты сам становишься частью того, о чём читал. Тогда ты уже создаешь свою драму, комедию, трагедию. Художественное тогда уход от своих проблем, что их усугубляет.
До определённого возраста стоит читать художественное. Если столкнулся хорошо с реальностью, то это пустая обуза. И это не из-за эгоизма, а против тупости современной художественной литературы. Она бесполезна относительно радуги реальной жизни. И фантастика то же.
Но я не могу отобрать игрушку у детей. И не собираюсь. Им нужно дорасти до этого. До принятия реальности и решения своих проблем. Но многим нравится тешить своё я прикрываясь фантазией.
Ещё раз. Всё что есть — нужно, но на разных уровнях развития сознания. На каком-то и книги не нужны.
Если вы пишите отдельное приложение, но не библиотеку, пакет модуль, плагин или фреймвок, то повторное использование кода возможно только на уровне самого приложения.
И не роутеры и свичи, а маршрутизаторы и коммутаторы.
Автор, переведённой статьи, изобрёл один из небольших разделов «магии» согласно того с чем ему приходится сталкиваться. Она работает на простых проектах. Где модели не содержат сколько-то сложных агрегаторов.
Если принять то, что это «магия» и она может работать в какой-то группе приложения, то я соглашусь с её применением. Когда есть простые модели (контекст laravel, а не DDD) и их связи. Если разработчик один. Пусть.
Но бывает всё сложнее. Бывает нужно передать в сервис несколько репозиториев, а то ещё и другой сервис. После сервиса нужно выполнить нечто инфраструктурное, например, отправить почту и/или пуши, логировать и т.д. на основе успешности выполнения сервиса. Добавим в абстракцию сервиса подписку на события?
Может в сервисе потребоваться дополнительная валидация, так как она нужна не везде, а там где нужна и валидируются не только входящие данные запроса. Её то же повесим абстракцией на сервис?
Но главная проблема — это когда в проекте джуниор или условный мидл начинает писать код по аналогии увиденной «магии», не думая о её востребованности в его части задачи. Ведь понимание чьей-то «магии» так завораживает. Хочется то же стать «магом». Это приятно и побочные эффекты сразу не видны. Причём когда джуниор видит, что «магия» в конкретном случае не работает, то начинается его магия, например, с прямым доступом к моделям (контекст laravel).
Вот тогда задумываешься. С одной стороны можно быстро сделать прототип большой части проекта, а с другой загубить его в самой сложной части.
И опять же, серебряной пули нет.
В любом случае можно определится с «чистыми» URI касательно платёжных средств и т.д. Это как маркировка. Понятно что будет куча «не умных» пользователей и «хитрых» бизнесменов. Но можно отстранится от их игр.
Другой вариант подписывать сертификатами целые списки URI, а не только домены. И цветом выделять то что за гранью.
Прочие, хоть как на своём языке. Думаю, что для сбера не проблема сайт на латинице.
Здесь дело в чём. Что не латиница — то красим. И пользователей учим, что если радуга — то это не официально.
Разделяй, раскрашивай и властвуй через строку браузера!