Я бы сказал, что такое ограничение очень даже полезно, потому что, как по мне, такой код читать и использовать удобнее, когда есть определенный порядок. Если же функция может быть определена где-то ниже, то, иногда, это не очень удобно.
Говоря об удобстве… Я предпочитаю описывать функции в порядке убывания их значимости. То есть, функция, ради которой пишется весь модуль объявлена выше всех. А всякие helpers/wrappers болтаются в самом низу, работу таких можно предсказать и по названию функции. Ну, если использовать любую IDE, становится все равно, в каком месте определена функция, был бы к ней доступ. Не системные же утилиты пишете! Вроде бы, почти не осталось мамонтов, использующих vim/emacs для кодинга на javascript.
У функции в примере нет названия. Она присваивается именованной переменной.
Вы правы, именно это явление можно выяснить взглянув на код или в инспектор/отладчик. А если это не ваш код? Часто, чтобы избежать разногласий, пишут:
let a = (function a () {
...
});
console.log(a.name); // => a
Может быть, для браузеров код выглядит необычно, но, например, разбираться в чужих middleware, когда ~30% из них анонимные функции, похоже на ад. — И в итоге, все равно, нужно прочесть и разобраться во 100% кода приложения.
Часто бывает так, что функции вызывают друг друга, образуя неявную рекурсию. И, чтобы одна функция не была определена раньше другой, пришлось бы сначала объявить их всех через let, а ниже делать им описания, — что не очень удобно.
let a, b;
a = function () {
b ();
}
b = function() {
a ();
}
Пример надуманный, не ругайтесь. Ситуация довольно часто проявляется при обработки иерархических данных, например, при работе с файловой системой. Куда логичнее и проще:
Просмотрите внимательно содержание всех API. То есть, к чему приложение может иметь удобный доступ из js-песочницы.
Если кто-то еще программирует на Delphi-подобных инструментариях, советую попробовать для этого же самого js.
И в конце концов, обратите свое внимание на opensource-решения!
Я начал свои первые шаги в программировании на Си в 1997 за прошедшее время я успел поработать на всех языках из вашего списка, а также на многих, которые не вошли в ваш список.
С 2011 года фанат node.js. С 2014 фанат SpiderMonkey. Попробуйте меня переубедить, чем ваши языки более «нормальнее», чем JS.
Они обходят лишь в популярности по количеству лиц, на них программирующих. Но это далеко не означает, что те лица прямо на уровень выше тех, кто программирует на JS. За то, для сравнения, пакетный менеджер node.js содержит больше всех модулей (плагинов, пакетов — называйте, как хотите).
(Хотя на нем теперь и сервера и десктоп пишут помимо веб-апп).
Вы, однако, проснулись! На JS сегодня реализуются не только сайты (серверная и браузерная часть), node.js используют везде где требуется обработка i/o-steaming. Еще на нем пишут и просто скрипты, и все самые крутые парсеры, >60% интерфейсов мобильных приложений. Чёрт возьми, у меня даже оболочка ОС Gnome-Shell написана 100% на JS. Да, думаю и в последних версиях Windows, во всяких плиточных интерфейсах, тоже где-то существуют js-виджеты.
И речь не о том, что для каждой задачи свой ЯП, а о том, сколько людей пишущих на этих языках с радостью перешли на JS из-за таких ошеломляющих возможностей и перспектив.
Скажу по секрету, именно с этих ЯП С/C#/С++/Java/Python/PHP и переходят на JS. На JS переходят гораздо меньше людей, программирующих на perl, ruby, go, scala и проч. Но, последних по сравнению даже с аудиторией JS, — совсем меньшинство.
Заранее извиняюсь за занудство.
На самом деле, это не очень хороший пример, который хотелось бы демонстрировать новичкам JS. Нативные шаблоны — это гуд.
А вот укороченные стрелочные функции надо использовать осторожно, по крайней мере, в обычных незамысловатых ситуациях.
У них есть несколько ограничений:
Во-первых, стрелочная функция запускается всегда с контекстом того места, где она описана. То есть, .apply() и .call() использовать с такими функциями бесполезно.
Во-вторых, стрелочные функции не создают объекта arguments, который можно было бы использовать в теле стрелочной функции
В-третьих, несмотря на явное название функции sayHappyNewYear, она всегда остается анонимной.
В-четвертых, (не самое главное) определив функцию обычным образом function sayHappyNewYear(year) { ... }, например, в глобальном окружении, функцию можно использовать где угодно, хоть после определения, хоть до определения. Переменные, определенные через let, доступны для использования лишь после определения.
Про Array.isArray я в курсе. Как раз именно его util.isArray() использует в последних версиях.
Так, стандартное как раз я никогда не пытался заменить.
Самим node пользуюсь с версии 0.4.x. Могу, конечно, пропустить обновления в документации о deprecated-статусах.
Само использование util.isError() не выводит в stdout, что использую deprecated-функцию, в отличии от, например, util.exec(), который deprecated уже очень давно.
Ну а по поводу того, что расширил. Сами то исходники всего расширения в отдельном модуле. Так исторически получилось, что я назвал его util (можно было выбрать любое название). В работе просто подключаю его локально вместо стандартного util. В него стекались все простые функции абсолютно разного назначения, которых очень много. Чтобы не подключать букет всевозможных npm-модулей, все было собрано в один файл. Разумеется, ведь не в глобальный скоуп их подключать.
К сожалению, мы за деньги пишем пока только проприетарный код. Сами его используем. Сами разворачиваем. Сами поддерживаем. Ну, по разным понятным соображениям, публичным гитхабом пользоваться не стали. Недавно приняли решение об использовании приватного npm. Правда, дальше принятия решения дело не двинулось :) Ну, не до этого было.
Я, вроде бы, нигде не утверждал, что util нужен не в процессе изучения чужого кода.
В util использую чаще всего методы isArray(), isError() и проч.
На основе стандартного util, я его немного расширил, добавил методы isInt(), isGenerator() и проч., вот тот demandLoad() у меня util.demandLoad().
Еще пользуюсь util.inspect(), но это, опять же для дебага, в продакшене бесполезен.
Раньше пользовался util.inherits(), но он уже отходит с появлением классов в синтаксисе.
Вы преувеличиваете. Unit-тестами обычно покрывают свой исходный код, когда есть 100% понимание работы этого кода. console.log() не все используют только лишь в поиске ошибок.
Например, я его часто использую, когда разбираюсь в чужих исходных кодах.
При этом, сами чужие коды работают без ошибок.
Можно, конечно, подключить отладчик к IDE и выполнять скрипт step-by-step.
Но такой режим не очень подходит для изучения чужих исходных кодов и очень утомителен.
Ну, если в ES2016 появится ключевое слово util, то, так и так придется переписывать исходники, будь то:
var util = require('util');
или
global.util = require('util');
А иногда даже неявное необходимо больше явного.
Например, если мы хотим заменить стандартный console собственным логгером.
Например, мы хотим, чтобы console.log() выдавал в stdout не только строку, переданную параметром, а еще путь к файлу и номер строки, откуда этот console.log() был вызван.
С помощью global и ключа node --require это можно сделать прозрачно для самой программы, т.е. не исправляя исходный код самой программы.
И, вообще связка global + --require, собственно, существует для расширения стандартных возможностей node.
Вы правы. Но идеология распределения имен в node сама по себе не идеальна.
То есть, мы не против глобальных console и process.
Мы же не добавляем в шапку что-то вроде:
var console = require('console');
var process = require('process');
Почему разработчики node не сделали то же самое с модулем util?!
Ведь сам util всегда загружен, и его методами активно пользуется та же console.
Кроме того, например, у меня в самом большом проекте их подключено таким образом максимум штук 40. Это количество включает в себя некоторые стандартные модули, используемые npm-модули и локальные модули.
И никто не заставляет прописывать их все. Профит получается уже с часто используемых «util», «fs» и «path».
В целом, вы правы. Практика немного сыровата. Пользоваться или не пользоваться — дело индивидуальное. Но статья имеет место быть. Надеюсь, и вы научились для себя чему-то новому. Или вам жалко времени, убитого на прочтение статьи?
Работать другим модулям это не мешает. Переопределение любой переменной через let, const или var остается.
Другой вопрос, если в модуле используются заранее не определенные переменные. И алгоритм рассчитывает, что их значения заранее undefined. Но это не очень хорошая практика, и при использовании 'use strict'-режима может вызвать runtime-ошибку.
По опыту разворачивания node-web-приложений на недорогих VDS отмечу:
при конфигурации Restart=always сначала лучше запустить скрипт: systemctl start node-sample
А уже потом, если сервер не ушел в бесконечный перезапуск node-sample, выполнять: systemctl enable node-sample
Бывает, скрипт запуска сервера вылетает при запуске, например, при синтаксической ошибке.
systemd жрет весь процессор на перезапуск node-sample.
В случае зависания VDS, его хардверно можно перезагрузить и повторить попытку.
Если до этого был активирован сервис: systemctl enable node-sample
systemd будет повторять бесконечную перезагрузку node-sample и после перезагрузки всего VDS.
Objective-C (по крайней мере, по моим наблюдениям) теряет популярность уже года два.
А вот классический Си, наоборот, набирает популярность. Это обусловленно, в том числе, отсутствием аналогов.
На чем еще программировать контроллеры? Драйверы? Ядра ОС?
Прочитал статью, прочитал комментарии. Хочу оставить и свои размышления о МДП.
Забегая вперед паровоза, отмечу, что меня никогда не одолевала настоящая депрессия. В работе программирования я выделяю три стадии сессии программирования: маниакальщина, мудрость и апатия.
Для себя МДП я преодолел уже около 2 лет назад. Сейчас отмечаю в своем распорядке три вышеперечисленных стадии. Для себя я называю это сессией программирования.
При маниакальщине обычно все идет как по маслу. Даже, любые события, которые меня отвлекают, не приносят какого-либо расстройства. Хотя, при этом, все же, отвлечь от работы может любое личное обращение к вашей персоне. Тут надо иметь императорский подход, необходимо объяснить окружающим себя людям, что ты работаешь над сложной задачей и не обязан искать ответы на маловажные вопросы (такие вопросы обычно могут быть архи-важными для кого-то, но незначительными лично для вас, конкретно для решения конкретной задачи). Обычно маниакальная стадия для меня проходит от 20 до 45 часов.
Далее маниакальная стадия плавно сменяется стадией мудрости. Мысли в голове начинают играть в гонки (можно сопоставить с игрой NeedForSpeed). Одна мысль обгоняет другую, третья таранит первые две на полном ходу на крутом повороте, чтобы пробиться среди них вперед. При таком обстоятельстве дел сложно заниматься реализацией какого-нибудь узкого момента в проекте. При этом, каждая мысль может быть важной, необходимо успеть записать их все в том или ином виде, так как на следующее утро, скорее всего большинство из них сложно вспомнить. Такая стадия проходит от 2 до 8 часов. После небольших исследований, я выяснил, что большинство файлов/классов/интерфейсов были созданы именно в этой стадии. Стоит отметить, что все комментарии в коде /** todo ... */ мной создаются именно в этой стадии. Если сравнивать с другими состояниями, стадия мудрости является наиболее депрессивной. Сложно заниматься реализацией какого-либо узкого момента программы. За то легко представляется структура программы со стороны. И пусть, некоторые мысли, приходящие в стадии мудрости погут быть неверными. Но все они будут служить хорошим началом для выполнения следующей сессии.
После стадии мудрости, так или иначе, наступает сон. Сон может прийти не сразу после стадии мудрости. Но между мудростью и сном не происходит ничего. Вообще ничего.
Далее после сна наступает апатия. Тут вообще противно подходить к смартфону/планшету/компюьтеру. В такое время я, как бы не было смешно, люблю заниматься сельским хозяйством. Для меня сельхоз — отличный аналог медитации. Могу сутками наблюдать на колыхающиеся от ветра стебли и листья растений. И нет ничего круче, чем, собственные, хотя бы, три грядки съедобной культуры. Растения чувствуют мою к ним любовь и дают лучшие по возможности плоды. Данная стадия может длиться от 1 до 6 суток. Скорее всего, продолжительность апатии зависит от положения луны и остальных звезд относительно земли и конкретного субьекта — программиста.
Вот и вся сессия. На сегодня моя работа зацикленна, приблизительно, в этих стадиях.
Отвлекусь от темы, отмечу, не занимаюсь растениями уже почти 3 года. Около 4х лет назад из-за МДП решил полностью отойти от ИТ в пользу автоматизации с/х-труда. Но, со вторым ростом растений стало понятно, что системное создание идеальных условий для роста сказывается ничуть не положительно на собираемых мною плодах. Отсюда выяснил, также как и у растений, мыслящему человеку сложно адаптироваться под стандартную недельную итерацию (в простанародье, пятидневка).
В заключение отмечу несколько хинтов от себя (повторяться не буду):
— музыка! никогда не мог понять людей, которые не могут работать, или, даже, просто общаться, без какой-либо рядом играющей музыки. Если вы страдаете МДП, не торопитесь включать заученные в мозгу ритмы, стихи. Даже если вы работаете в офисе/дома один и вам скучно. Не стоит включать радио или ротацию новостей, например, по «Россия-24». Это, может, спасает от скуки, но отвлекает куда больше, чем приносит пользы. Если совсем скучно, поможет white noise (например, звук с автомобильной трассы, проникающий в помещение через приоткрытое окно).
— еда! плотный обед всегда ведет к непреодолимому засыпанию в конце рабочего дня. Я предпочитаю не есть горячие блюда в рабочие дни, и, вообще, по возможности отказываюсь от любых перекусов в течении рабочего дня. Такая установка позволяет работать 20 и более часов вподряд.
— сон! если вы постоянно чувствуете себя усталым, сонным и т.д., скорее всего, ваше состояние не связанно МДП. Для МДП больше характерна бессоница, нежеле тяга ко сну. Если вы постоянно чувствуете себя усталым, то наилучшим решением будет просто пойти проспаться, отправиться в отпуск, сменить работу или, временно, вообще сменить сферу деятельности.
На этом, пожалуй, закончу. Отмечу, что согласен со всеми комментариями выше текущего.
Говоря об удобстве… Я предпочитаю описывать функции в порядке убывания их значимости. То есть, функция, ради которой пишется весь модуль объявлена выше всех. А всякие helpers/wrappers болтаются в самом низу, работу таких можно предсказать и по названию функции. Ну, если использовать любую IDE, становится все равно, в каком месте определена функция, был бы к ней доступ. Не системные же утилиты пишете! Вроде бы, почти не осталось мамонтов, использующих vim/emacs для кодинга на javascript.
Вы правы, именно это явление можно выяснить взглянув на код или в инспектор/отладчик. А если это не ваш код? Часто, чтобы избежать разногласий, пишут:
Может быть, для браузеров код выглядит необычно, но, например, разбираться в чужих middleware, когда ~30% из них анонимные функции, похоже на ад. — И в итоге, все равно, нужно прочесть и разобраться во 100% кода приложения.
let, а ниже делать им описания, — что не очень удобно.Пример надуманный, не ругайтесь. Ситуация довольно часто проявляется при обработки иерархических данных, например, при работе с файловой системой. Куда логичнее и проще:
https://developer.mozilla.org/en-US/docs/Web/API
http://www.roojs.com/seed/gir-1.2-gtk-3.0/gjs/
Просмотрите внимательно содержание всех API. То есть, к чему приложение может иметь удобный доступ из js-песочницы.
Если кто-то еще программирует на Delphi-подобных инструментариях, советую попробовать для этого же самого js.
И в конце концов, обратите свое внимание на opensource-решения!
С 2011 года фанат node.js. С 2014 фанат SpiderMonkey. Попробуйте меня переубедить, чем ваши языки более «нормальнее», чем JS.
Они обходят лишь в популярности по количеству лиц, на них программирующих. Но это далеко не означает, что те лица прямо на уровень выше тех, кто программирует на JS. За то, для сравнения, пакетный менеджер node.js содержит больше всех модулей (плагинов, пакетов — называйте, как хотите).
Вы, однако, проснулись! На JS сегодня реализуются не только сайты (серверная и браузерная часть), node.js используют везде где требуется обработка i/o-steaming. Еще на нем пишут и просто скрипты, и все самые крутые парсеры, >60% интерфейсов мобильных приложений. Чёрт возьми, у меня даже оболочка ОС Gnome-Shell написана 100% на JS. Да, думаю и в последних версиях Windows, во всяких плиточных интерфейсах, тоже где-то существуют js-виджеты.
Скажу по секрету, именно с этих ЯП С/C#/С++/Java/Python/PHP и переходят на JS. На JS переходят гораздо меньше людей, программирующих на perl, ruby, go, scala и проч. Но, последних по сравнению даже с аудиторией JS, — совсем меньшинство.
А на деле использую стрелочные функции только в аргументах при вызове функций.
Еще иногда в
return. Например,В остальных случаях использую что-либо отличное от стрелочных функций.
classиconstructor.На самом деле, это не очень хороший пример, который хотелось бы демонстрировать новичкам JS. Нативные шаблоны — это гуд.
А вот укороченные стрелочные функции надо использовать осторожно, по крайней мере, в обычных незамысловатых ситуациях.
У них есть несколько ограничений:
.apply()и.call()использовать с такими функциями бесполезно.arguments, который можно было бы использовать в теле стрелочной функцииsayHappyNewYear, она всегда остается анонимной.function sayHappyNewYear(year) { ... }, например, в глобальном окружении, функцию можно использовать где угодно, хоть после определения, хоть до определения. Переменные, определенные черезlet, доступны для использования лишь после определения.Так, стандартное как раз я никогда не пытался заменить.
Самим node пользуюсь с версии 0.4.x. Могу, конечно, пропустить обновления в документации о deprecated-статусах.
Само использование util.isError() не выводит в stdout, что использую deprecated-функцию, в отличии от, например, util.exec(), который deprecated уже очень давно.
Ну а по поводу того, что расширил. Сами то исходники всего расширения в отдельном модуле. Так исторически получилось, что я назвал его util (можно было выбрать любое название). В работе просто подключаю его локально вместо стандартного util. В него стекались все простые функции абсолютно разного назначения, которых очень много. Чтобы не подключать букет всевозможных npm-модулей, все было собрано в один файл. Разумеется, ведь не в глобальный скоуп их подключать.
Выложил на pastebin
К сожалению, мы за деньги пишем пока только проприетарный код. Сами его используем. Сами разворачиваем. Сами поддерживаем. Ну, по разным понятным соображениям, публичным гитхабом пользоваться не стали. Недавно приняли решение об использовании приватного npm. Правда, дальше принятия решения дело не двинулось :) Ну, не до этого было.
В util использую чаще всего методы isArray(), isError() и проч.
На основе стандартного util, я его немного расширил, добавил методы isInt(), isGenerator() и проч., вот тот demandLoad() у меня util.demandLoad().
Еще пользуюсь util.inspect(), но это, опять же для дебага, в продакшене бесполезен.
Раньше пользовался util.inherits(), но он уже отходит с появлением классов в синтаксисе.
console.log()не все используют только лишь в поиске ошибок.Например, я его часто использую, когда разбираюсь в чужих исходных кодах.
При этом, сами чужие коды работают без ошибок.
Можно, конечно, подключить отладчик к IDE и выполнять скрипт step-by-step.
Но такой режим не очень подходит для изучения чужих исходных кодов и очень утомителен.
util, то, так и так придется переписывать исходники, будь то:или
А иногда даже неявное необходимо больше явного.
Например, если мы хотим заменить стандартный
consoleсобственным логгером.Например, мы хотим, чтобы
console.log()выдавал в stdout не только строку, переданную параметром, а еще путь к файлу и номер строки, откуда этотconsole.log()был вызван.С помощью
globalи ключа node--requireэто можно сделать прозрачно для самой программы, т.е. не исправляя исходный код самой программы.И, вообще связка
global+--require, собственно, существует для расширения стандартных возможностей node.То есть, мы не против глобальных
consoleиprocess.Мы же не добавляем в шапку что-то вроде:
Почему разработчики node не сделали то же самое с модулем
util?!Ведь сам
utilвсегда загружен, и его методами активно пользуется та жеconsole.И никто не заставляет прописывать их все. Профит получается уже с часто используемых «util», «fs» и «path».
В целом, вы правы. Практика немного сыровата. Пользоваться или не пользоваться — дело индивидуальное. Но статья имеет место быть. Надеюсь, и вы научились для себя чему-то новому. Или вам жалко времени, убитого на прочтение статьи?
let,constилиvarостается.Другой вопрос, если в модуле используются заранее не определенные переменные. И алгоритм рассчитывает, что их значения заранее undefined. Но это не очень хорошая практика, и при использовании
'use strict'-режима может вызвать runtime-ошибку.при конфигурации
Restart=alwaysсначала лучше запустить скрипт:systemctl start node-sampleА уже потом, если сервер не ушел в бесконечный перезапуск node-sample, выполнять:
systemctl enable node-sampleБывает, скрипт запуска сервера вылетает при запуске, например, при синтаксической ошибке.
systemd жрет весь процессор на перезапуск node-sample.
В случае зависания VDS, его хардверно можно перезагрузить и повторить попытку.
Если до этого был активирован сервис:
systemctl enable node-samplesystemd будет повторять бесконечную перезагрузку node-sample и после перезагрузки всего VDS.
А вот классический Си, наоборот, набирает популярность. Это обусловленно, в том числе, отсутствием аналогов.
На чем еще программировать контроллеры? Драйверы? Ядра ОС?
Забегая вперед паровоза, отмечу, что меня никогда не одолевала настоящая депрессия. В работе программирования я выделяю три стадии сессии программирования: маниакальщина, мудрость и апатия.
Для себя МДП я преодолел уже около 2 лет назад. Сейчас отмечаю в своем распорядке три вышеперечисленных стадии. Для себя я называю это сессией программирования.
При маниакальщине обычно все идет как по маслу. Даже, любые события, которые меня отвлекают, не приносят какого-либо расстройства. Хотя, при этом, все же, отвлечь от работы может любое личное обращение к вашей персоне. Тут надо иметь императорский подход, необходимо объяснить окружающим себя людям, что ты работаешь над сложной задачей и не обязан искать ответы на маловажные вопросы (такие вопросы обычно могут быть архи-важными для кого-то, но незначительными лично для вас, конкретно для решения конкретной задачи). Обычно маниакальная стадия для меня проходит от 20 до 45 часов.
Далее маниакальная стадия плавно сменяется стадией мудрости. Мысли в голове начинают играть в гонки (можно сопоставить с игрой NeedForSpeed). Одна мысль обгоняет другую, третья таранит первые две на полном ходу на крутом повороте, чтобы пробиться среди них вперед. При таком обстоятельстве дел сложно заниматься реализацией какого-нибудь узкого момента в проекте. При этом, каждая мысль может быть важной, необходимо успеть записать их все в том или ином виде, так как на следующее утро, скорее всего большинство из них сложно вспомнить. Такая стадия проходит от 2 до 8 часов. После небольших исследований, я выяснил, что большинство файлов/классов/интерфейсов были созданы именно в этой стадии. Стоит отметить, что все комментарии в коде
/** todo ... */мной создаются именно в этой стадии. Если сравнивать с другими состояниями, стадия мудрости является наиболее депрессивной. Сложно заниматься реализацией какого-либо узкого момента программы. За то легко представляется структура программы со стороны. И пусть, некоторые мысли, приходящие в стадии мудрости погут быть неверными. Но все они будут служить хорошим началом для выполнения следующей сессии.После стадии мудрости, так или иначе, наступает сон. Сон может прийти не сразу после стадии мудрости. Но между мудростью и сном не происходит ничего. Вообще ничего.
Далее после сна наступает апатия. Тут вообще противно подходить к смартфону/планшету/компюьтеру. В такое время я, как бы не было смешно, люблю заниматься сельским хозяйством. Для меня сельхоз — отличный аналог медитации. Могу сутками наблюдать на колыхающиеся от ветра стебли и листья растений. И нет ничего круче, чем, собственные, хотя бы, три грядки съедобной культуры. Растения чувствуют мою к ним любовь и дают лучшие по возможности плоды. Данная стадия может длиться от 1 до 6 суток. Скорее всего, продолжительность апатии зависит от положения луны и остальных звезд относительно земли и конкретного субьекта — программиста.
Вот и вся сессия. На сегодня моя работа зацикленна, приблизительно, в этих стадиях.
Отвлекусь от темы, отмечу, не занимаюсь растениями уже почти 3 года. Около 4х лет назад из-за МДП решил полностью отойти от ИТ в пользу автоматизации с/х-труда. Но, со вторым ростом растений стало понятно, что системное создание идеальных условий для роста сказывается ничуть не положительно на собираемых мною плодах. Отсюда выяснил, также как и у растений, мыслящему человеку сложно адаптироваться под стандартную недельную итерацию (в простанародье, пятидневка).
В заключение отмечу несколько хинтов от себя (повторяться не буду):
— музыка! никогда не мог понять людей, которые не могут работать, или, даже, просто общаться, без какой-либо рядом играющей музыки. Если вы страдаете МДП, не торопитесь включать заученные в мозгу ритмы, стихи. Даже если вы работаете в офисе/дома один и вам скучно. Не стоит включать радио или ротацию новостей, например, по «Россия-24». Это, может, спасает от скуки, но отвлекает куда больше, чем приносит пользы. Если совсем скучно, поможет white noise (например, звук с автомобильной трассы, проникающий в помещение через приоткрытое окно).
— еда! плотный обед всегда ведет к непреодолимому засыпанию в конце рабочего дня. Я предпочитаю не есть горячие блюда в рабочие дни, и, вообще, по возможности отказываюсь от любых перекусов в течении рабочего дня. Такая установка позволяет работать 20 и более часов вподряд.
— сон! если вы постоянно чувствуете себя усталым, сонным и т.д., скорее всего, ваше состояние не связанно МДП. Для МДП больше характерна бессоница, нежеле тяга ко сну. Если вы постоянно чувствуете себя усталым, то наилучшим решением будет просто пойти проспаться, отправиться в отпуск, сменить работу или, временно, вообще сменить сферу деятельности.
На этом, пожалуй, закончу. Отмечу, что согласен со всеми комментариями выше текущего.