Загружаем мы не просто файлы, а программный код, которые нужно скомпилировать и выполнить, что может потянуть ещё зависимости. Многие модули зависят от других модулей и решают этот вопрос с помощью синхронного require.
Здесь ещё вот какой момент. Вызов require — синхронный. Так как он отложен и будет вызван неизвестно когда, скорее всего его вызов попадётся в асинхронном коде. Что доставляет следующие неприятности:
1. Ожидание файлового ввода-вывода, что порочит идею асинхронного кода.
2. exception в этом коде уронит ноду (приятной отладки).
Вызов синхронного кода во время работы сервиса (не консольной утилиты) — это всегда зло. Поэтому загружаем все модули на старте и если что-то не то, получаем просто не загрузившееся приложение, что быстро диагностируется и лечится.
В общем не дай бог я увижу проект с таким вот подходом…
Не подтверждаю. Белый цвет имеется, как белый.
Если дадите инструкции как правильно посмотреть на него (под солнцем или в полной темноте), чтобы он стал жёлтым, обязательно посмотрю.
Ну так и вставили бы его в обзор, чтобы обозначить недостатки и достоинства. Я, как писал в комментарии, за объективную картину. А телефон с батарейкой в 5000 мАч всё-таки эту картину дополняет, не находите?
Потребитель должен знать своих героев, а производитель должен бороться за потребителя. Разве не так?
Пользуюсь пока что всего 4 дня. Пытаюсь понять сколько будет работать при нормальном использовании (звонки, браузер пару часов в день в метро), чтобы не вырубать всё подряд (или переходить в экстремальный режим, т.е. только телефон).
Пока что понял только одно. Skype — зло. Сожрал 60% заряда при том что я всего-лишь пару раз написал сообщение и раз десять сообщения почитал. Вырубил его к чертям. Skype и смартфон, к сожалению, — не совместимы.
Поставил тёмную тему — она нормальная в плане дизайна, но более экономичная.
Отключил из автозагрузки приложения которыми не пользуюсь.
Второй день идёт — заряд больше 50%. По моим прогнозам, дня 4 продержится.
Когда закончу анализ, ещё покручу настройки, вероятнее всего отпишу подробный комментарий, прямо в блог highscreen`а здесь.
Забавная статья. Насколько я понял, OSI, кроме модели, которая описана в учебниках, ещё и разрабатывала непосредственно реализации протоколов для каждого уровня. Т.е. от деятельности OSI осталась только модель, а уже конкретные протоколы Интернета были предложены DARPA.
От статьи остаётся ощущение, что OSI провалилась полностью и покрыта забвением, и у меня вопрос:
Один из самых популярных стэков протоколов (Ethernet/IP/TCP/HTTP) разве не укладывается в модели OSI?
Здесь Ethernet нормально делится на два слоя (помимо MAC-адресации, есть ведь ещё какой-то протокол на уровне электрических сигналов), а HTTP просто объединил в себе три последних прикладных уровня.
За предыдущую статью поставил минус (без сожалений).
За эту плюс (недостатки есть, но прогресс очень приличный) и в карму плюс (за стремление к совершенству).
Лазать по DOM`у в поисках модели, да ещё и комментариях, которые оставляет angular — это просто жесть.
Если уж и хотите уделать зубров (которые не додумались до такого), примите как совет:
<ul ng-sortable="item in items" options="sortableOptions">
<li>{{ item }}</li>
</ul>
P.S. Я таким образом dropdown для css фреймворка делал.
<dropdown items="item in items" default-text="select items" on-select="onSelect(item)">
{{item.description}}
</dropdown>
Ставьте пакеты локально и пользуйтесь npx. Глобальные зависимости зло, не только js и npm касается.
Зачем это?
1. Ожидание файлового ввода-вывода, что порочит идею асинхронного кода.
2. exception в этом коде уронит ноду (приятной отладки).
Вызов синхронного кода во время работы сервиса (не консольной утилиты) — это всегда зло. Поэтому загружаем все модули на старте и если что-то не то, получаем просто не загрузившееся приложение, что быстро диагностируется и лечится.
В общем не дай бог я увижу проект с таким вот подходом…
Не подтверждаю. Белый цвет имеется, как белый.
Если дадите инструкции как правильно посмотреть на него (под солнцем или в полной темноте), чтобы он стал жёлтым, обязательно посмотрю.
Потребитель должен знать своих героев, а производитель должен бороться за потребителя. Разве не так?
Пока что понял только одно. Skype — зло. Сожрал 60% заряда при том что я всего-лишь пару раз написал сообщение и раз десять сообщения почитал. Вырубил его к чертям. Skype и смартфон, к сожалению, — не совместимы.
Поставил тёмную тему — она нормальная в плане дизайна, но более экономичная.
Отключил из автозагрузки приложения которыми не пользуюсь.
Второй день идёт — заряд больше 50%. По моим прогнозам, дня 4 продержится.
Когда закончу анализ, ещё покручу настройки, вероятнее всего отпишу подробный комментарий, прямо в блог highscreen`а здесь.
5000 мАч, 4 ядра, 1.3 ГГц, 16/1.5 память, LTE, 5" экран, Android 5.0
P.S. Я не от них, просто пользователь этого аппарата. Хотел бы видеть картину более актуальной, раз уж Вы это анонсировали.
req.post(...).then(...)
От статьи остаётся ощущение, что OSI провалилась полностью и покрыта забвением, и у меня вопрос:
Один из самых популярных стэков протоколов (Ethernet/IP/TCP/HTTP) разве не укладывается в модели OSI?
Здесь Ethernet нормально делится на два слоя (помимо MAC-адресации, есть ведь ещё какой-то протокол на уровне электрических сигналов), а HTTP просто объединил в себе три последних прикладных уровня.
Картинка для напоминания…
За эту плюс (недостатки есть, но прогресс очень приличный) и в карму плюс (за стремление к совершенству).
… разве это не лазить по DOM`у в поисках модели (её имени)?
и потом…
Если уж и хотите уделать зубров (которые не додумались до такого), примите как совет:
P.S. Я таким образом dropdown для css фреймворка делал.