Тяжелые sql запросы следует хранить в отдельных *.sql файлах. И вообще, ребята, давно уже надо использовать es6, а там есть замечательные шаблонные литералы — и пишите себе мультилайн строки без всяких массивных хаков.
Это вредный совет. Если функция должна принимать на вход sql query string, так чего это мы должны разрешать какой-то array, тем более если учесть, что первый пункт отпадает. Всегда желательно что бы функция была как можно конкретнее.
Для дебага в консоли сойдёт, но тут ещё можно добавить группировки и различны уровни логов, как глобальные, так и групповые.
В ноде большинство вызовов асинхронные, какие здесь могут быть try..catch? Если инстанс падает из-за ошибки — это баг, ошибка должна логироваться, а какой нибудь процесс-менеджер должен подымать процесс.
Как и с первым пунктом, конфигурация не относится к коду и не должна там находиться. И вместо json лучше используйте yml, например.
Подходит лишь для баш скриптов.
Сколько можно уже мусолить тему callback-ов. Сколько же ненавистников есть, хотя ничего сложного в них нет. А совет с интервал какой-то смешной. Если уж хотите по одному файлу обрабатывать, так нужно использовать очередь, а не какой-то хак с секундным подёргиванием.
Смысловой контекст — вот что имеет значение. Для простого выражения из примера делать отдельный метод нет смысла. Поэтому я сказал, что пример не корректный… Если будем говорить о других более сложных примерах, то `clone/text` нужно заменить на метод `create` с явным созданием элемента (не clone). Вместо `appendTo/prependTo` более гибким решением являются placeholder элементы. Если будем ещё усложнять то тогда уже играют большую роль фреймворки, которые за нас многое что сделают и помогут организовать логику. Поэтому >2 и >4 не релевантные.
>1: Цепочки разумеется сложнее в отладке, но опять же из примера на `clone/text/append/fadeIn` мне бы не пришлось ставить breakpoint. Там нечего высматривать, более того, в Chrome у меня jquery занесён в список и jquery код пропускается в «step into».
>3: Я всегда лишь полагаюсь на тесты, если я где-то ошибся с именем, то тест у меня тут же отвалится.
Конечно у цепочек есть свои недостатки, но так как у них «потоковая» логика, то читать и понимать код в разы проще.
Пример с appendTo/prependTo немного не верный. Цепочки вызовов всё же лучше — они и компактные и читать приятнее, а внедрить логику выбора функции всегда можно:
2) А обычные спрайты также решаются отдельными утилитами, которые а) собирают спрайт с исходников б) создают css-стили для каждой иконки. В результате, инклудим файл стилей в less и далее, как миксин, подключаем иконку к нужному стилю. И не нужно никаких цыклов, не нужно помнить индексы — лишь одно нужно помнить — имя иконки, которое будет соответсвовать имени стиля, со сгенерированной информацией о пути к спрайту и о позиции. Также добавлю ещё, что мы редко используем пути к картинкам в стилях, в основнпм генерируются нужные стили уже с путями и с размерами.
3) Я имел ввиду не lesshat использовать для keyframes, а autoprefixer — и о префиксах можно забыть. А для совсем сложных анимаций нужно использовать js библиотеку, которя использует те же анимации и css transitions.
Разумеется, я ни коим образом не умалаю мощь sass-a. Просто с less-ом и другими штуками можно получить на порядок больше профита.
1) Есть например lesshat. И можно писать например `.transition(transform scale 200ms linear);`, и все префиксы будут правильно проставлены. Так что это возможно. Хотя хорошей практикой является использовать autoprefixer, который с префиксами работает куда лучше less и sass.
2) Для спрайтовых анимаций лучше использовать js библиотеки, которые во-первых сами сгенерируют нужные css-стили, а во-вторых можно создавать более комплексные анимации. А в целом вы правы — циклов нет. Но нужны ли они?
3) Вытекает из первого пункта.
Заметил, что примеры не выдуманные, а реальные — но решаются они на другом уровне.
Единственное, что меня смущает, это если посмотреть на `import` с точки зрения любого из вариаций mvc. Разумеется мы будем выность весь javascript из тэгов <script></script> в отдельный контроллер напимер, и тогда у нас получится удивительная вещь: Шаблон загружает Контроллер. Я не утверждаю, что это недопустимо, но как-то это не привычно. В runtime более привычно, когда попадая в контроллер, он загружает нужный ему шаблон/вью, а также любые другие ресурсы и js модули. Я уже давно использую компонентный подход для построения приложений, и скажу, что `import` меняет поток загрузки ресурсов не в лучшую сторону.
Хороший код, тот которого нет. А в контексте приложения и концепта — логика как энергия, если она пропадает в одном месте, то обязательно должна появится в другом. А архитектура, наподобии некой философии, определяет основы "мироприложениездания" обозначая сущности и слои, награждая каждого своей логикой, ролью и обязаностью.
Если наделять html обьязанностями представления, тогда разумеется там же должна находится и логика связанная с предствалением. Где какие данные показывать(интерполяция), какие елементы обновлять при изменении модели(биндинг), какие комманды вызывать при неких действиях пользователя(сигналы/события) и т.д. Резумеется не любую логику можно описать в html, в силу специфики синтаксиса, но подобные простые вещи отлично ложатся на плечи html кода. А такие строки как this.bindElement( 'x', 'select.my-select' );) и this.on('click', '.mysuperselector', this.hello) создают ненужную зависимость контроллера от представления и раздувают сам контроллер.
Спасибо, понял, нода подключается к этой «исполнительной части» и запись/чтение производит по http транспорту. Пробежав код по диагонале, настоятельно рекомендую отрефакторить приложение. Используйте es6 — код станет чище. И с архитектурой немного беда, даже вот те же адаптеры — здесь можно действительно сам паттерн `Adapter` использовать, а не только само название. Работа с сокетом и вся другая техническая логика должна быть вынесена в базовый класс, скажем `Source` с однотипным интерфейсом. Дальше расширяем его на `CcuSource`, `HttpSource` и т.д. А потом уже адаптеры наследуются от нужного типа и реализуют абстрактные методы. В идеале gismeteo адаптер должен состоять лишь из определения каналов и метода который трансформирует полученные данные. И более того, хороший AdapterProvider следует парадигме `convention over configuration`.
А так отличный проект, на этом желаю вам успехов!
Простите, но с подобными системами не доводилось сталкиваться, поэтому извините за возможно глупые вопросы. Стало интересно, как устроена архитектура связи с датчиками. Я так понимаю нода у вас выступает клиентом для некого софта `HomeMatic`. A `HomeMatic` — это соответственно вендорный софт для управления датчиками и чтением их параметров и нода общается с ним через `http` протокол. Я правильно понимаю? Или `HomeMatic` это микроконтроллер с датчиками и веб сервером для управления на борту. Как настраиваются/подключаются датчики к `HomeMatic`; он поддерживает только датчики определённого типа?
Подытожу вопрос: Как и какие датчики подключаются и каким образом они управляются из под nodejs? Спасибо.
Массивы — компактные и на порядок производительнее. У нас также есть один парсер, и там мы боримся с каждой мс. Сейчас у нас дерево через обьекты представлено, a вот однажды пытались на массивы перейти. И всё было очень здорово — с индексами было удобно работать через константы:
// INode [type:int, tag:string, attributes:object, nodes:array]
var tagName = node[pos_TAG];
var children = node[pos_NODES];
В конечном разультате код стал быстрее и после минификации стал меньше. Но пришлось отказаться — хотелось давать конечным пользивателям непосредственный доступ к дереву. А вот там ему уже эти индексы нужно помнить, ведь `pos_*` скрыты внутри библиотеки, а выносить как свойства наружу — усложнит простую работу с деревом.
Хотя заметили, что в csscomb другая структура используется: [KEY, VALUE] и такой подход немного перемешивает массивы с обьектами; как по мне — довольно не корректно.
Отличный редактор, сам пользуюсь им уже лет 5 как. В основном использую для «JS&Co» разработки. Одна вещь которая меня просто намертво держит с этим редактором, так это то, что он базируется на gecko движке, макросы можно писать на javascript, и вот написал уже давно макрос, который исполняет выделенный текст в редакторе и результат возвращает в него же, или запускает gecko-вскую js консоль. Иногда очень удобно на ходу протесировать участки кода плюс встроенный калькулятор. Вот например нужно быстро узнать char code `Z`, пишем `'Z'.charCodeAt(0)`, выделяем участок, жмём hotkey и вуаля, char code сразу в редакторе. Вообщем грубо говоря — developer tools console непосредственно в открытом документе. Возможно знает кто-то похожие плагины/макросы для других IDE?
Кто бы что не говорил о node.js — но в нем имеется одно для нас важное преимущество: один язык и один фреймворк для клиента и сервера. Скорость разработки приложения увеличилась у нас в разы, когда бизнес логика, хэлперы, сервисы и прочее используются по обе стороны.
«Так то оно так», но здесь явно просматривается каскад проблем. А про каскад проблем при проектировании можно писать большие статьи. Но в любом случае, как я могу видеть данная проблема решается лишь на самом верхнем уровне: уровне концепта, то это явно очень большая проблема. Конечно, это возможно не в этой ситуации, но при реальном проекте — это было бы, можно сказать, катастрофическая трудность. Я просто уже много раз слышал фразу «это вообще не проблема поправить», а потом оказывается что, утрирую, нужно пол проекта перелопатить.
Смысловой контекст — вот что имеет значение. Для простого выражения из примера делать отдельный метод нет смысла. Поэтому я сказал, что пример не корректный… Если будем говорить о других более сложных примерах, то
`clone/text`нужно заменить на метод `create` с явным созданием элемента (неclone). Вместо`appendTo/prependTo`более гибким решением являются placeholder элементы. Если будем ещё усложнять то тогда уже играют большую роль фреймворки, которые за нас многое что сделают и помогут организовать логику. Поэтому >2 и >4 не релевантные.>1: Цепочки разумеется сложнее в отладке, но опять же из примера на `clone/text/append/fadeIn` мне бы не пришлось ставить breakpoint. Там нечего высматривать, более того, в Chrome у меня jquery занесён в список и jquery код пропускается в «step into».
>3: Я всегда лишь полагаюсь на тесты, если я где-то ошибся с именем, то тест у меня тут же отвалится.
Конечно у цепочек есть свои недостатки, но так как у них «потоковая» логика, то читать и понимать код в разы проще.
И вообще, тема со стайл гайдами довольно персональная и абсолютной истинны здесь быть не может, лишь советы — за что спасибо.
`2 * Math.pow(2, 5) === 64`$('#comment_7964683').find('.spoiler').length3) Я имел ввиду не lesshat использовать для keyframes, а autoprefixer — и о префиксах можно забыть. А для совсем сложных анимаций нужно использовать js библиотеку, которя использует те же анимации и css transitions.
Разумеется, я ни коим образом не умалаю мощь sass-a. Просто с less-ом и другими штуками можно получить на порядок больше профита.
2) Для спрайтовых анимаций лучше использовать js библиотеки, которые во-первых сами сгенерируют нужные css-стили, а во-вторых можно создавать более комплексные анимации. А в целом вы правы — циклов нет. Но нужны ли они?
3) Вытекает из первого пункта.
Заметил, что примеры не выдуманные, а реальные — но решаются они на другом уровне.
<script></script>в отдельный контроллер напимер, и тогда у нас получится удивительная вещь: Шаблон загружает Контроллер. Я не утверждаю, что это недопустимо, но как-то это не привычно. В runtime более привычно, когда попадая в контроллер, он загружает нужный ему шаблон/вью, а также любые другие ресурсы и js модули. Я уже давно использую компонентный подход для построения приложений, и скажу, что `import` меняет поток загрузки ресурсов не в лучшую сторону.Если наделять html обьязанностями представления, тогда разумеется там же должна находится и логика связанная с предствалением. Где какие данные показывать(интерполяция), какие елементы обновлять при изменении модели(биндинг), какие комманды вызывать при неких действиях пользователя(сигналы/события) и т.д. Резумеется не любую логику можно описать в html, в силу специфики синтаксиса, но подобные простые вещи отлично ложатся на плечи html кода. А такие строки как
this.bindElement( 'x', 'select.my-select' );) иthis.on('click', '.mysuperselector', this.hello)создают ненужную зависимость контроллера от представления и раздувают сам контроллер.А так отличный проект, на этом желаю вам успехов!
Подытожу вопрос: Как и какие датчики подключаются и каким образом они управляются из под nodejs? Спасибо.
В конечном разультате код стал быстрее и после минификации стал меньше. Но пришлось отказаться — хотелось давать конечным пользивателям непосредственный доступ к дереву. А вот там ему уже эти индексы нужно помнить, ведь `pos_*` скрыты внутри библиотеки, а выносить как свойства наружу — усложнит простую работу с деревом.
Хотя заметили, что в csscomb другая структура используется:
[KEY, VALUE]и такой подход немного перемешивает массивы с обьектами; как по мне — довольно не корректно.`'Z'.charCodeAt(0)`, выделяем участок, жмём hotkey и вуаля, char code сразу в редакторе. Вообщем грубо говоря — developer tools console непосредственно в открытом документе. Возможно знает кто-то похожие плагины/макросы для других IDE?