На самом деле, программист никогда не нанимается на работу. Он находит себе менеджров, бухгалтеров, директоров, чтобы выгодно продавать им своё время и не отвлекаться на юридические и экономические аспекты бытия.
Заказчик не требует от программиста исполнения обязательств, а просит сотворить рабочий продукт в установленные сроки, которые при хорошем к себе отношении программист срывает не более, чем в три раза.
Программист всегда дает уменьшенную оценку времени на задачу. Это происходит потому, что программист дает оценку в идеальных условиях, без учета подготовки, начальной медитации для «входа в поток» (в которую зачастую входит чтение Хабра), времени наступления подходящего настроения и психологической атмосферы. Эти факторы внешние и сильно зависят от обстановки в офисе, количества звонков, разговоров, прочего шума. Поскольку планирование в задачи программиста не входит, эти факторы должен понимать и учитывать менеджер.
Работа программиста всегда находится с ним в его голове. Даже в маршрутке и в постели перед сном программист обдумывает решение задач, хотя это время и не оплачивается. Поэтому программист никогда не опаздывает на работу, даже если приходит в обед.
Программист получает удовольствие от обучения, исследования, познания. Если ему поставить чисто техническую задачу, с которой он может справиться в два счета, он заскучает и скорее всего найдет себе способ чему-нибудь пообучаться между делом, например напишет «велосипед».
Около 80% работы программист делает за 20% времени. Поэтому, если программист сидит в социальной сети или чатится по скайпу — это он тратит те самые 80% времени, давая мозгу отдохнуть после тяжелых 20%, готовясь к новому рывку. Или, возможно, он ищет решения или совета. Поэтому, чтобы не отсрочить новый порыв вдохновения, лучше не трогайте его.
Код хорошего программиста наполнен гармонией, красотой и лаконичностью, это настоящее произведение искусства. Можно получать удовольствие от одного его чтения, а даже не от результата его работы. Хороший лаконичный код с документацией у программиста получается не сразу, в после неопределенного числа попыток рефакторинга. И стоит намного дороже. Однако, практически все менеджеры вынуждают оставить такой рабочий, но неотшлифованный вариант в продакшне. Это наводит на программистов грусть, особенно на тех, кто продукт развивает и поддерживает, и снижает их психологическую мотивацию.
Конечно, в третьей редакции схемы для типа object у каждого его поля указывается булевый параметр required, а в четвертой — один атрибут required для всего объекта со списком необходимых полей. Наличие дополнительных атрибутов блокируется параметром additionalProperties.
require может принимать пути к модулям как с расширением, так и без расширения. Может быть загружен либо модуль ядра, либо конкретный файл, либо файл с таким же именем и расширением ".js", либо файл в такой директории с именем index.js, либо подобным образом один из файлов внутри mode_modules, либо директория внутри node_modules. К слову, это делает удобным декомпозицию и эволюционное превращение некоторых подключаемых файлов в библиотеки в аккуратных директориях или даже в npm. Подробнее об алгоритме загрузки можно узнать из документации:
Порядок загрузки require
require(X) from module at path Y
1. If X is a core module,
a. return the core module
b. STOP
2. If X begins with './' or '/' or '../'
a. LOAD_AS_FILE(Y + X)
b. LOAD_AS_DIRECTORY(Y + X)
3. LOAD_NODE_MODULES(X, dirname(Y))
4. THROW «not found»
LOAD_AS_FILE(X)
1. If X is a file, load X as JavaScript text. STOP
2. If X.js is a file, load X.js as JavaScript text. STOP
3. If X.node is a file, load X.node as binary addon. STOP
LOAD_AS_DIRECTORY(X)
1. If X/package.json is a file,
a. Parse X/package.json, and look for «main» field.
b. let M = X + (json main field)
c. LOAD_AS_FILE(M)
2. If X/index.js is a file, load X/index.js as JavaScript text. STOP
3. If X/index.node is a file, load X/index.node as binary addon. STOP
LOAD_NODE_MODULES(X, START)
1. let DIRS=NODE_MODULES_PATHS(START)
2. for each DIR in DIRS:
a. LOAD_AS_FILE(DIR/X)
b. LOAD_AS_DIRECTORY(DIR/X)
NODE_MODULES_PATHS(START)
1. let PARTS = path split(START)
2. let ROOT = index of first instance of «node_modules» in PARTS, or 0
3. let I = count of PARTS — 1
4. let DIRS = []
5. while I > ROOT,
a. if PARTS[I] = «node_modules» CONTINUE
c. DIR = path join(PARTS[0… I] + «node_modules»)
b. DIRS = DIRS + DIR
c. let I = I — 1
6. return DIRS
Далее, путь к файлу, загружаемому через require, является уникальным идентификатором модуля. Это значит, что все переменные модуля будут доступны из всех мест, где этот модуль был загружен через require. Другими словами, если в одном файле загрузить модуль через require и изменить его внутреннее сосояние, то это смогут обнаружить другие файлы, загрузившие этот же модуль. Такое поведение бывает удобно при работе с сервисами, например при использовании модуля в качестве дрвайера кэша или драйвера базы данных.
Тело модуля — это тело функции, вызываемой один раз при инициализации модуля. Внутри этой функции существует переменная module, которая ссылается на этот самый загружаемый модуль. У module есть поле module.exports, именно эта переменная возвращается в качестве значения вызова require(). Помимо module доступна также переменная exports, которая является синонимом module.exports, что позволяет писать укороченные конструкции вида «exports.User = User». Однако переопределение значения переменной exports закономерно отвязывает её от module.exports, поэтому при том, что конструкция «exports.User = User» работать будет, конструкция виде «exports = User» работать уже не будет, и для экспорта целого объекта в качестве модуля следует писать «module.exports = User». Грубо говоря, чтобы понять как это работает, проще всего при написании модуля думать, что где-то в невидимой высоте присутствуют такие строчки:
var module = наш_модуль;
module.exports = {};
var exports = module.exports;
Так нельзя, тем более новичкам. Набор методов JS учится за пару дней, он не настолько сложен и суров, чтобы из-за нежелания изучить его использовать химеры. Зато после ознакомления с чистым натуральным JS, после понимания логики работы объектов, замыканий и прототипов, напротив, многие вещи получаются куда проще и лаконичнее. Плюс открывается взор на огромное количество библиотек и методик, которые используются в JS.
Интересно. Получается, что мозг постоянно занимается архивацией с потерями. Кстати, почему синапс рассматривается как бит информации? Если я правильно понял, он имеет весовой коэффициент, и его стоит рассматривать как число с плавающей точкой. Причем, после определения точности этого числа можно уже сказать о количестве бит, необходимых для его хранения. В итоге может получиться, что мозг хранит гораздо больше информации.
Пространственно-временные координаты. Интересно, как мозг вообще ощущает время? Ведь в нем нет генератора и счетчиков импульсов, аналогичных часам? Возможно, это как-то связано со скоростью химических реакций и скоростью распространения волн. Почему иногда мозг способен соблюдать интервалы времени с точностью до долей секунды, в то время как в другом случае ощущение времени совершенно теряется, вплоть до того, что человек не уверен, день на улице или ночь? Можно ли искусственно повлиять на восприятие времени?
Спасибо, с удовольствием прочту. Ещё бы хотел поднять такие темы, если они не выходят за рамки теории:
— Судя по всему, мозг не может находиться в электрохимическом состоянии покоя. Возможен ли анабиоз с полным сохранением личности и реанимацией в будущем?
— Как объяснить состояние отсутствия сознания, например во время комы, нокаута, обморока, клинической смерти? Отсутствует ли оно или лишь не может управлять телом? Мыслит ли при этом мозг, что происходит с воспоминаниями за этот период времени? И как восстанавливается нормальное мышление?
— Что такое сон, как он возникает и зачем он нужен? Почему сны более яркие и реалистичные, чем воспоминания в процессе сознательного мышления? Почему сны так плохо сохраняются в памяти?
— Судя по всему, в принципе, ничто не мешает существовать в одном мозгу нескольким высшим системам обработки информации, «сознаниям». Таким образом можно объяснить диссоциативное расстройство личности. Но почему в подавляющем большинстве случаев личность у человека только одна? Является ли это результатом «конкурентной борьбы» неразвитых «сознаний» за нейронное пространство на ранних этапах формирования мозга?
— Что такое волевое усилие и почему для волеизлияния и вообще ускорения умственной активности требуется усилие? Является ли это реакцией на истощение синапсов, с целью торможения принятия решений, или чем-то другим? Действительно ли волевое усилие требует энергозарат, например дополнительного притока АТФ?
Очень интересно, хотя признаться есть моменты, которые сложно «осилить». И конечно, возникли размышления и вопросы.
— Каким образом формируются предустановленные, врождённые паттерны, например критерий красоты самки, разного рода инстинкты? Возможно ли формирование предустановленных паттернов в период формирования мозга младенца в утробе, на основе информации из ДНК? Ведь для того, чтобы унаследовать «опыт предков» в ходе естественного отбора, нужно чтобы этот опыт был не приобретен путем запоминания и обучения, а «прошит» на генетическом уровне, возник в результате мутаций у наиболее успешных особей.
— Как на деятельность мозга влияет нагруженность умственной деятельностью? Какое оказывает влияние объем перерабатываемой информации, переутомление? Тренируется мозг или наоборот, засоряется? Какие из мер и методик, которые принимают для сохранения и стимуляции работоспособности мозга, имеют смысл и объяснение в рамках это теории, а какие нет?
— Какие физиологические изменения претерпевают нейроны со временем? Насколько зависит способность мозга к обучению и запоминанию от возраста нейронов?
На мой взгляд, нельзя однозначно говорить о том, хорошая штука ORM или вредная. Есть плюсы и есть минусы. Любая техника и абстракция призвана помогать программисту, ускорять и облегчать его работу, работу его команды, а так же его приемников. Этот подход, безусловно, имеет право на жизнь в открытых проектах, фреймворках и CMS, в первую очередь потому, что освобождает от привязки к конкретной СУБД.
Однако, на практике не всегда всё так гладко, как в теории. Моя дружба с ORM и другими query-билдерами была недолгой. Причина была в том, что самописные ORM и билдеры сильно завязаны на ведущего разработчика бекенда, и после его ухода, бекенд потихоньку умирал и обрастал костылями, это было печальное зрелище. Потом была Доктрина 2. Изначально показавшись красивой и мощной, она оказалась довльно сложна для понимания и громоздка, и иногда ее использование в простых проектах смахивало на инверсию абстракции (помимо SQL нужно знать еще DQL и особенности его работы, всякий «annotation mapping» и т.д.) и нередко возникало ощущение лишней, избыточной работы, особенно когда приходилось искать и курить маны в поисках решения задачи, которую можно за минуту решить модификацией запроса в базу.
Позже я перешел на узкоспециализированные проекты, в которых вся модель данных заключена в СУБД (реализована через хранимые функции, триггеры и события, и имеются готовые представления для отображения на страницах сайта). Таким образом, сущность «сайт» перестала быть ключевой и стала лишь отражением информационной системы, php стал выполнять роль шаблонизатора html и формирователя json из данных, полученных из кэша или из бд, а позже был заменен другой платформой. Не думаю, что ORM здесь сыграл бы положительную роль и помог бы как-то облегчить труд программистов.
Интересно. Всегда думал что это очевидно, и причина этому — защита от случайной маскировки курсора вертикальными и горизонтальными эементами интерфейса. Вроде как курсор «под углом» меньше сливается с нагромождением окон, особенно в условиях малого количества цветов и низкого разрешения. Это особенно ощутимо при попытке заменить «стрелку» на «крестик».
А я люблю простые текстовые письма без картинок. В них, конечно, рекламу вставить труднее, но если бы службы рассылки технических писем предоставляли выбор формата (text vs html), мир был бы чуточку прекраснее.
За свою практику могу выделить три основных уровня качества макета:
1. Самый слабый уровень. Жирный и линейный файл, или набор файлов для разных страниц. Все слои имеют названия по умолчанию (layer 1, layer 2..). Никакой группировки, многие элементы разбиты на несколько слоев, часть слоев скрыта (поди разберись какие к чему относятся), среди них присутсвуют эксперементальные скрытые мертвые слои, которые в окончательном варианте дизайна не используются. Повторяющиеся элементы скопированы в разных местах. Ужас, ад и содомия, и для верстальщика, и для руководителя проекта.
2. Средний уровень. Слои имеют названия и сгруппированы по страницам и логическим группам. Лишние и мертвые слои отсутсвуют. Задний фон всех элементов выполнен в виде отдельного слоя, поверх которого накладываются рамки и прочие детали с полупрозрачностью. Дизайнер, поставляющий такие макеты, вызывает уважение и желание продолжать сотрудничество.
3. Высокий уровень. Макет выполнен в виде единого и полноценного файла (Firewroks) со страницами и состояниями. Все элементы дизайна оформлены в виде символов, а не групп или слоёв, сами слои используются только для шаринга символов между страницами и их состояниями. Символы имеют иерархию (одни символы являются элементами других символов), дубликаты символов отсутствуют, все повторяющиеся элементы — экземпляры одного символа, даже несмотря на зумы. повороты и прочие эффекты. Для каждого символа существует отдельная подготовленная страница со слайсами для нарезки с указанием имени и типа файла для экспорта. Нарезка такого макета после изменений, не требующих изменения рамеров изображений, осуществляется в один клик. Изменение размеров элементов дизайна требует только изменения координат слайсов.
Дизайнер, делающий макеты последнего уровня — редкость, но если он умеет это делать — это не только повышает скорость внесения правок, это колоссально ускоряет работу верстальщика, избавляет его от рутинной нарезки и подгонки изображений. Качество дизайна такого уровня обычно выше, поскольку документ имеет четкую структуру, и сам дизайнер, изменяя символы, успевает без мучений опробовать много вариантов, сразу видя разультаты изменений и выбрать наиболее удачный из них.
Прошу прощения за столь длинный комментарий, но проблема наболевшая, и очень хочется пожелать всем начинающим и практикующим дизайнерам стремиться к этому уровню, вас будут любить, беречь, рекомендовать и хорошо оплачивать ваш труд.
Если не обращать внимания на душевную борьбу, поиск себя и оправдания своему эмоциональному решению, получается отличная реклама Гугла как работодателя.
Заказчик не требует от программиста исполнения обязательств, а просит сотворить рабочий продукт в установленные сроки, которые при хорошем к себе отношении программист срывает не более, чем в три раза.
Программист всегда дает уменьшенную оценку времени на задачу. Это происходит потому, что программист дает оценку в идеальных условиях, без учета подготовки, начальной медитации для «входа в поток» (в которую зачастую входит чтение Хабра), времени наступления подходящего настроения и психологической атмосферы. Эти факторы внешние и сильно зависят от обстановки в офисе, количества звонков, разговоров, прочего шума. Поскольку планирование в задачи программиста не входит, эти факторы должен понимать и учитывать менеджер.
Работа программиста всегда находится с ним в его голове. Даже в маршрутке и в постели перед сном программист обдумывает решение задач, хотя это время и не оплачивается. Поэтому программист никогда не опаздывает на работу, даже если приходит в обед.
Программист получает удовольствие от обучения, исследования, познания. Если ему поставить чисто техническую задачу, с которой он может справиться в два счета, он заскучает и скорее всего найдет себе способ чему-нибудь пообучаться между делом, например напишет «велосипед».
Около 80% работы программист делает за 20% времени. Поэтому, если программист сидит в социальной сети или чатится по скайпу — это он тратит те самые 80% времени, давая мозгу отдохнуть после тяжелых 20%, готовясь к новому рывку. Или, возможно, он ищет решения или совета. Поэтому, чтобы не отсрочить новый порыв вдохновения, лучше не трогайте его.
Код хорошего программиста наполнен гармонией, красотой и лаконичностью, это настоящее произведение искусства. Можно получать удовольствие от одного его чтения, а даже не от результата его работы. Хороший лаконичный код с документацией у программиста получается не сразу, в после неопределенного числа попыток рефакторинга. И стоит намного дороже. Однако, практически все менеджеры вынуждают оставить такой рабочий, но неотшлифованный вариант в продакшне. Это наводит на программистов грусть, особенно на тех, кто продукт развивает и поддерживает, и снижает их психологическую мотивацию.
require может принимать пути к модулям как с расширением, так и без расширения. Может быть загружен либо модуль ядра, либо конкретный файл, либо файл с таким же именем и расширением ".js", либо файл в такой директории с именем index.js, либо подобным образом один из файлов внутри mode_modules, либо директория внутри node_modules. К слову, это делает удобным декомпозицию и эволюционное превращение некоторых подключаемых файлов в библиотеки в аккуратных директориях или даже в npm. Подробнее об алгоритме загрузки можно узнать из документации:
1. If X is a core module,
a. return the core module
b. STOP
2. If X begins with './' or '/' or '../'
a. LOAD_AS_FILE(Y + X)
b. LOAD_AS_DIRECTORY(Y + X)
3. LOAD_NODE_MODULES(X, dirname(Y))
4. THROW «not found»
LOAD_AS_FILE(X)
1. If X is a file, load X as JavaScript text. STOP
2. If X.js is a file, load X.js as JavaScript text. STOP
3. If X.node is a file, load X.node as binary addon. STOP
LOAD_AS_DIRECTORY(X)
1. If X/package.json is a file,
a. Parse X/package.json, and look for «main» field.
b. let M = X + (json main field)
c. LOAD_AS_FILE(M)
2. If X/index.js is a file, load X/index.js as JavaScript text. STOP
3. If X/index.node is a file, load X/index.node as binary addon. STOP
LOAD_NODE_MODULES(X, START)
1. let DIRS=NODE_MODULES_PATHS(START)
2. for each DIR in DIRS:
a. LOAD_AS_FILE(DIR/X)
b. LOAD_AS_DIRECTORY(DIR/X)
NODE_MODULES_PATHS(START)
1. let PARTS = path split(START)
2. let ROOT = index of first instance of «node_modules» in PARTS, or 0
3. let I = count of PARTS — 1
4. let DIRS = []
5. while I > ROOT,
a. if PARTS[I] = «node_modules» CONTINUE
c. DIR = path join(PARTS[0… I] + «node_modules»)
b. DIRS = DIRS + DIR
c. let I = I — 1
6. return DIRS
Далее, путь к файлу, загружаемому через require, является уникальным идентификатором модуля. Это значит, что все переменные модуля будут доступны из всех мест, где этот модуль был загружен через require. Другими словами, если в одном файле загрузить модуль через require и изменить его внутреннее сосояние, то это смогут обнаружить другие файлы, загрузившие этот же модуль. Такое поведение бывает удобно при работе с сервисами, например при использовании модуля в качестве дрвайера кэша или драйвера базы данных.
Тело модуля — это тело функции, вызываемой один раз при инициализации модуля. Внутри этой функции существует переменная module, которая ссылается на этот самый загружаемый модуль. У module есть поле module.exports, именно эта переменная возвращается в качестве значения вызова require(). Помимо module доступна также переменная exports, которая является синонимом module.exports, что позволяет писать укороченные конструкции вида «exports.User = User». Однако переопределение значения переменной exports закономерно отвязывает её от module.exports, поэтому при том, что конструкция «exports.User = User» работать будет, конструкция виде «exports = User» работать уже не будет, и для экспорта целого объекта в качестве модуля следует писать «module.exports = User». Грубо говоря, чтобы понять как это работает, проще всего при написании модуля думать, что где-то в невидимой высоте присутствуют такие строчки:
— Судя по всему, мозг не может находиться в электрохимическом состоянии покоя. Возможен ли анабиоз с полным сохранением личности и реанимацией в будущем?
— Как объяснить состояние отсутствия сознания, например во время комы, нокаута, обморока, клинической смерти? Отсутствует ли оно или лишь не может управлять телом? Мыслит ли при этом мозг, что происходит с воспоминаниями за этот период времени? И как восстанавливается нормальное мышление?
— Что такое сон, как он возникает и зачем он нужен? Почему сны более яркие и реалистичные, чем воспоминания в процессе сознательного мышления? Почему сны так плохо сохраняются в памяти?
— Судя по всему, в принципе, ничто не мешает существовать в одном мозгу нескольким высшим системам обработки информации, «сознаниям». Таким образом можно объяснить диссоциативное расстройство личности. Но почему в подавляющем большинстве случаев личность у человека только одна? Является ли это результатом «конкурентной борьбы» неразвитых «сознаний» за нейронное пространство на ранних этапах формирования мозга?
— Что такое волевое усилие и почему для волеизлияния и вообще ускорения умственной активности требуется усилие? Является ли это реакцией на истощение синапсов, с целью торможения принятия решений, или чем-то другим? Действительно ли волевое усилие требует энергозарат, например дополнительного притока АТФ?
— Каким образом формируются предустановленные, врождённые паттерны, например критерий красоты самки, разного рода инстинкты? Возможно ли формирование предустановленных паттернов в период формирования мозга младенца в утробе, на основе информации из ДНК? Ведь для того, чтобы унаследовать «опыт предков» в ходе естественного отбора, нужно чтобы этот опыт был не приобретен путем запоминания и обучения, а «прошит» на генетическом уровне, возник в результате мутаций у наиболее успешных особей.
— Как на деятельность мозга влияет нагруженность умственной деятельностью? Какое оказывает влияние объем перерабатываемой информации, переутомление? Тренируется мозг или наоборот, засоряется? Какие из мер и методик, которые принимают для сохранения и стимуляции работоспособности мозга, имеют смысл и объяснение в рамках это теории, а какие нет?
— Какие физиологические изменения претерпевают нейроны со временем? Насколько зависит способность мозга к обучению и запоминанию от возраста нейронов?
Однако, на практике не всегда всё так гладко, как в теории. Моя дружба с ORM и другими query-билдерами была недолгой. Причина была в том, что самописные ORM и билдеры сильно завязаны на ведущего разработчика бекенда, и после его ухода, бекенд потихоньку умирал и обрастал костылями, это было печальное зрелище. Потом была Доктрина 2. Изначально показавшись красивой и мощной, она оказалась довльно сложна для понимания и громоздка, и иногда ее использование в простых проектах смахивало на инверсию абстракции (помимо SQL нужно знать еще DQL и особенности его работы, всякий «annotation mapping» и т.д.) и нередко возникало ощущение лишней, избыточной работы, особенно когда приходилось искать и курить маны в поисках решения задачи, которую можно за минуту решить модификацией запроса в базу.
Позже я перешел на узкоспециализированные проекты, в которых вся модель данных заключена в СУБД (реализована через хранимые функции, триггеры и события, и имеются готовые представления для отображения на страницах сайта). Таким образом, сущность «сайт» перестала быть ключевой и стала лишь отражением информационной системы, php стал выполнять роль шаблонизатора html и формирователя json из данных, полученных из кэша или из бд, а позже был заменен другой платформой. Не думаю, что ORM здесь сыграл бы положительную роль и помог бы как-то облегчить труд программистов.
1. Самый слабый уровень. Жирный и линейный файл, или набор файлов для разных страниц. Все слои имеют названия по умолчанию (layer 1, layer 2..). Никакой группировки, многие элементы разбиты на несколько слоев, часть слоев скрыта (поди разберись какие к чему относятся), среди них присутсвуют эксперементальные скрытые мертвые слои, которые в окончательном варианте дизайна не используются. Повторяющиеся элементы скопированы в разных местах. Ужас, ад и содомия, и для верстальщика, и для руководителя проекта.
2. Средний уровень. Слои имеют названия и сгруппированы по страницам и логическим группам. Лишние и мертвые слои отсутсвуют. Задний фон всех элементов выполнен в виде отдельного слоя, поверх которого накладываются рамки и прочие детали с полупрозрачностью. Дизайнер, поставляющий такие макеты, вызывает уважение и желание продолжать сотрудничество.
3. Высокий уровень. Макет выполнен в виде единого и полноценного файла (Firewroks) со страницами и состояниями. Все элементы дизайна оформлены в виде символов, а не групп или слоёв, сами слои используются только для шаринга символов между страницами и их состояниями. Символы имеют иерархию (одни символы являются элементами других символов), дубликаты символов отсутствуют, все повторяющиеся элементы — экземпляры одного символа, даже несмотря на зумы. повороты и прочие эффекты. Для каждого символа существует отдельная подготовленная страница со слайсами для нарезки с указанием имени и типа файла для экспорта. Нарезка такого макета после изменений, не требующих изменения рамеров изображений, осуществляется в один клик. Изменение размеров элементов дизайна требует только изменения координат слайсов.
Дизайнер, делающий макеты последнего уровня — редкость, но если он умеет это делать — это не только повышает скорость внесения правок, это колоссально ускоряет работу верстальщика, избавляет его от рутинной нарезки и подгонки изображений. Качество дизайна такого уровня обычно выше, поскольку документ имеет четкую структуру, и сам дизайнер, изменяя символы, успевает без мучений опробовать много вариантов, сразу видя разультаты изменений и выбрать наиболее удачный из них.
Прошу прощения за столь длинный комментарий, но проблема наболевшая, и очень хочется пожелать всем начинающим и практикующим дизайнерам стремиться к этому уровню, вас будут любить, беречь, рекомендовать и хорошо оплачивать ваш труд.