Конференция была на высоком техническом уровне, за что спасибо организаторам. Единственная беда — раздача плюшек за вопросы. В результате — куча левых вопросов, а действительно интересные вещи рассказывались в кулуарах.
Обратитесь к гейм-дизайнерам ваших игровых проектов — вам помогут придумать адекватную схему мотивации, чтобы стимулирование активности участников не мешало эффективному допрашиванию выступающих.
Подпишусь под всеми словами. Сам в особо сложных проектах пишу свой DSL. Но именно, где это оправданно. Когда надо сложнющую бизнес-логику описать так, чтобы она была понятна с первого взгляда. Пример в статье, по-моему, это злоупотребление подходом.
То же самое говорю и про фреймворки. Пока что-то делаешь типовое, всё ок. Вы не сталкивались с ошибками в коде на каком-нибудь Django? Когда что-то не работает, а что — непонятно. Ловить их — очень увлекательное дело. Сапожники покраснеют, если слушать будут. Тем не менее, их используют, чтобы не изобретать велосипеды.
Понятно, что можно писать, на чём угодно и с какими угодно абстракциями. Просто не факт, что от этого лучше будет. В этом деле важно не переборщить.
С точки зрения теории, ваши рассуждения в статье правильные, вопросов нет: убирается избыточность, явно описывается поток управления — всё красиво. Однако в проектах, где над кодом работает большая команда, такие штуки не работают — слишком сильно увеличивается порог вхождения в код. Чтобы дописать новую возможность или исправить ошибку, надо сначала разобраться с вашим подходом, понять все ваши абстракции, задать кучу вопросов коллегам и т.д. Пока пятый сотрудник научится этим добром пользоваться, первый уже застрелится.
Вы из элементарной и легко читаемой программы (пусть в 2 раза более длинной) сделали 4 строчки, которые можно понять, только чётко зная, что делают функции skip и retry, и приложив заметные усилия, чтобы слепить из map, filter, skip и retry картину в голове, что этот код должен делать.
Под линиями управления имел в виду те, которых у вас 5. Сам просто делаю себе квартиру на электронике собственной разработки, но у меня датчики и линии управления десятками меряются. Интересно было, насколько цена покупной электроники сдерживает фантазию :)
Хочу добавить, что последовательное выполнение чего-либо отлично реализуется при помощи async.series или async.forEachSeries, если этого очень хочется. А потом, глядишь, и какие-то шаги можно через parallel запускать — ещё и быстрее будет.
«Подумать, а потом сделать» — это универсальная формула. Если сначала думать, то всё получается хорошо и в SQL, и в NoSQL. А вот если не думать, то в SQL можно легко написать неэффективный запрос. А на NoSQL, когда вся «схема выполнения запроса» реализуется в самом приложении, более наглядно видно, что будет работать быстро, а что медленно. С оговорками, конечно, но есть и такое наблюдение.
Кстати, когда я учился, появились первые «быстрые» машины, где Delay корреткно не работал — Crt не мог откалибровать задержку. И вообще, надо было модуль патчить, чтобы при запуске деления на ноль не было. Сейчас уже пропатченная версия гуляет по сети?
Спасибо за ссылку. Там всё расписано про трёхфазный двигатель. Я так понимаю, что если делают двигатель с однофазным питанием, то две остальные фазы формируют искусственно на конденсаторах и индуктивностях?
И про скорость. Если момент упадёт, то при достаточном механическом сопротивлении упадут и обороты. Так ведь? Это, по идее, то, что и нужно — вентилятор будет меньше шуметь и меньше воздуха нагнетать. Я так понимаю, что при регулировке напряжением КПД будет невысоким, и это единственная проблема. Делают ведь регуляторы скорости на симисторном ключе, и ничего. Вот пример: www.electrotest.ru/file/sb002-instruction.pdf
Обратитесь к гейм-дизайнерам ваших игровых проектов — вам помогут придумать адекватную схему мотивации, чтобы стимулирование активности участников не мешало эффективному допрашиванию выступающих.
То же самое говорю и про фреймворки. Пока что-то делаешь типовое, всё ок. Вы не сталкивались с ошибками в коде на каком-нибудь Django? Когда что-то не работает, а что — непонятно. Ловить их — очень увлекательное дело. Сапожники покраснеют, если слушать будут. Тем не менее, их используют, чтобы не изобретать велосипеды.
Понятно, что можно писать, на чём угодно и с какими угодно абстракциями. Просто не факт, что от этого лучше будет. В этом деле важно не переборщить.
Вы из элементарной и легко читаемой программы (пусть в 2 раза более длинной) сделали 4 строчки, которые можно понять, только чётко зная, что делают функции skip и retry, и приложив заметные усилия, чтобы слепить из map, filter, skip и retry картину в голове, что этот код должен делать.
И про скорость. Если момент упадёт, то при достаточном механическом сопротивлении упадут и обороты. Так ведь? Это, по идее, то, что и нужно — вентилятор будет меньше шуметь и меньше воздуха нагнетать. Я так понимаю, что при регулировке напряжением КПД будет невысоким, и это единственная проблема. Делают ведь регуляторы скорости на симисторном ключе, и ничего. Вот пример: www.electrotest.ru/file/sb002-instruction.pdf