Василий: так о wifi речи и нет, на нем никакие серийные уличные коптеры не работают в силу многих факторов. 2,4ггц это скорее всего просто авиамодельный программируемый пульт с проприетарным протоколом, а не wifi. Хотя автор не сказал, но те, что на wifi это с смартфона управление, для комнаты и дворика- вряд ли он мог потерять коптер в радиусе 20-30метров на открытом пространстве, да так чтобы радар искать для его поиска=))
Пересобирать это для извращенцев=) В принципе, думаю, перенаправление сработает. Тут еще не знаешь есть ли какой лимит на размер этого лога, вдруг он десятки мегабайт начнет жрать, а у меня виртуалка на роутере 64мб всего из 128 физических. Хотя по идее кто его собирал, но идиот...
Алексей Струков: ну вот по этому лучше искать крупных игроков рынка, они более склонны понимать профит от разделения труда по специальностях. Всякие веб студии в 90% случаев, это вообще только для html coder'ов. Человеку нужно знать все смежные технологии, чтобы быть на одной волне с разрабами других направлений, но все в разной степени глубины. Если есть отдельный верстальщик, это не означает что верстать не нужно уметь скажем js программисту, или не знать инструменты для сборки стилей, просто отдельный верстальщик делает свои задачи быстрее и эффективнее. Так само как эффективнее свою работу сделает архитектор бд, чем backend js || php dev.
Ну а меньше платить человеку, который будет исключительно знать только свою часть - неэффективно. КПД в них все ровно будет меньше чем у команды, где каждый специалист знает все, но с уклоном на свою область продукт будет сделан быстрее. Да и человека хоть как то можно подменить на время. Иначе придется резервировать еще каждого хомяка, чтоб не дай Бог ушел или заболел.
Алексей Струков: По сути то есть JS Dev. Это у нас с повелось из фронендера делать верстальщика и программиста, дабы сократить расходы компании, но иногда в больших компаниях, например, есть отдельный верстальщик например. ИМХО есть для такого сочетания код+верстка html coder, но там то не предполагается глубокие знания во всех аспектах. +Иногда вообще лепят фронтендеру и знание backend=full stack. Я тоже не сторонник лепить верстку и код на одного человека, с каждым днем обе темы сильно расширяются и держать хорошие склиллы по всех вопросах становится трудно.
Антон Старостин: ну считать в цифровых схемах мало есть чего. А часто вообще не глаз- уже помнишь типовые значения. Если бы речь шла о аналоговых, там например усилитель постоянного тока на транзисторах, то я бы понял проблемы с расчетами=) А так, использование резисторов для ограничения тока/напряжения да кондеров для сглаживания пульсаций или времени как бы сложностей не представляет. Брать и рассматривать всякие небольшие схемы и типовые узлы.
Если не жалко 100$, то можно от души затарится деталями, все что душа пожелает на taobao.com через посредника mistertao.com . Выбор намного больше, чем на aliexpress, т.е если что то существует, значит оно есть там и рассыпуха зачастую дешевле. Например 1000 smd транзисторов купил за 3$.
Один пример продавца (цены в юанях) - https://dianzi.world.taobao.com/
И насчет выбора мк- pic имхо самый убогий, в техникуме тоже их изучали, но в универе сразу же перешел на avr. И еще 3-й лидер для хобби есть - stm8, они и очень дешевые и богаче по периферии, минус - нет симуляции в протеус для них и они моложе avr и pic, соответственно и информации на форумах несколько меньше, но все аспекты использования покрыты. И у них же дешевые 32 битные мк на ARM ядре, дешевые средства разработки, чего о avr и pic не скажешь.
Антон Старостин: цепляете к каждому пину мк резистор на 470om, это будет 10мА, предел 40ма на ножку, 100ма на весь порт кажись. Так что ничего не спалите, если на плате нет напряжений более 5в. Но начали бы с симулятора.
xmoonlight: да что далеко ходить, замечали сколько грузится тот же gmail? SPA вытесняет классические сайты, а попробуйте реализовать даже небольшой классический портал на SPA? Я вот не знаю как это практически реализовать с текущими инструментами, если своего ничего не пилить. А приложения с каждым годом жиреют. Обостряют проблемы мобильный сегмент. Делать облегченные версии - опять лишнее телодвижения. Ну не может даже большому приложению в один момент времени требоваться все модуля.
C выгрузкой я давно уже экспериментировал, и это работало, но тогда вообще это никому не надо было, так как приложения совсем были скромные. Простой счетчик "ссылок" для каждого модуля, когда он становится пустым, модуль рекурсивно делает release зависимостям, зануляет ссылки, удаляет себя с кеша. А пользователю в код возвращается не сам модуль, а объект унаследованный от него, т.е свой экземпляр. упрощенно instance=Object.create(module) Т.е на каждый modules.get("").then(function(module){...})
нужно вызвать
module.release();
module=null;
и не заботится что там и как.
xmoonlight: RESTfull это уже взаимодействие клиента и сервера по обмену данными, я ее никак тут не касаюсь, только о подгрузке ресурсов для этого SPA.
А насчет сборки? тот подход, что Вы описали, это статическая сборка. Он подходит для совсем небольших приложений, и/или тех которым весь набор модулей нужен сразу. Т.е все собрали в один файл, минификация, сжатие подключили как один файл на клиенте и профит. Это просто, надежно, но при первом старте приложение будет долго думать, особенно на мобильных девайсах. В больших приложениях, где есть множество функционала, на каждый "фунционал" подгружает набор необходимых модулей по требованию, т.е динамически. И тут начинаются сложности- запрашивается либо каждый модуль и зависимость его отельным запросом, т.е десятки запросов, либо нужен опять сборщик который эти файлы проанализирует и опять все в один файл запихнет. Т.е будет несколько сборных файлов для каждой функционала SPA. Все это хорошо, но многовато телодвижений и не такая гибкость.
ну не знаю причем здесь REST API то?=) SPA тоже как бы не касался как такового. Только организации динамического загрузчика с минимизацией запросов, а не один запрос -один модуль.
1) Кеширование в localstorage это не отдельная "фишка", пункт 2 нереализовать без пункта 1.
Наитивные механизмы кэширования, в случае использования одного запроса для получения нескольких модулей, не получится использовать, а не для того чтобы просто переизобрести кеширования браузера. Ну вот, как бы мы делали такой запрос? где указывали бы какие модуля запрашиваются? В теле запроса POST? отлично, но url тогда будет не уникальным и при запросе разных наборов модулей он будет тот же (например /modules/), а значит кеширование не будет работать, так как кеш по уникальному url. Как то хитро склеивать имена модулей в url запроса типа /modules/module1.js__module2.js__module3.css - сработает, но только на точную комбинацию их. Выходит если потом я запрошу в другой комбинации, или и вовсе только один из них - кеш не сработает. Отсюда проблема, что просто так одним запросом несколько модулей не получить, так чтоб при этом они кешировались механизмами браузера. А именно множество запросов при использовании динамических загрузчиков неприятная проблема. И меня бы requireJS устроил если бы не она.
2) Webpack нужно мне исследовать, но на сколько я знаю с чтения хабра, там все ровно ручками делают слепки, ну в смысле на бекенде нужно webpack объяснять что да как, чтобы он сделал выдачу с нескольких. На сервере node я предполагаю просто ввести прослойку например для express, который бы просто обрабатывал обращения к public/js|css куда как обычно gulp скомпилил исходники и отдавал слепки, без всяких конфигов, делал кеш, либо в озу, либо в файловой системе, если предполагается, что там отдельные быстрый сервер отдачи для статики. Больше ему ничего не нужно. Как то так... В принципе для github code sample идея прям не нужна уникальная, но все же...
Артём Петренков: сложность минификации и трансляции с полифилами мягко говоря разная, изменения кода минимальны, инструменты куда более проверенны. Да и у минификации нет альтернатив, чтоб ее не использовать и она решает вполне конкретную задачу, а трансляция кода это баловство, а не необходимость.
Артём Петренков: Пару лет- это не сейчас. Для веба это огромный промежуток времени. Без "стрелочек" я 10 лет жил и 2 года еще проживу по возможности, это не критическое новшество, без которого жить не можно было, ведь раньше приходилось на пару символов больше набирать. Честно говоря именно стрелочки, мне читаемость только ухудшают, ведь глаз уже натаскан. Это фетишь кофейников, со своими визуальными шумами. ES6 на 90% это мелкие синтаксические удобства, а риски и поддерживаемость браузерами очень скудная, через 2 года- да все новые браузеры уже станут его нативно поддерживать, но что делать хотя бы с IE9-10+? Заказчик придет и скажет что мне до Ж как- но мне нужно чтоб это работало везде на 4-5 летних браузерах. И опять будут пляски с трансляторами и не дай Бог обнаружится баги, им порождаемые, то это подарит кучу бессонных ночей. Если не связываться с трансляторами, то вперед на ES6. На бекенде, конечно, почти есть / будет рай.
Артём Петренков: Ну то дело уже совсем потерянных извращенцев, читать им выдачу трансляторов со своих псевдо языков или нет... побалуются, подрастут и перестанут фигней заниматься.
Babel что то да решает, штука интересная, но более менее сложные/ большие вещи на нем писать опасно. Если не использовать совсем новые и сырые фичи, то то что остается в ES6 легко пишется на ES5 и без риска. Сейчас это просто следование моде и стадному инстинкту, мол все бросаем и прям сейчас все давайте на ES6 все пишем. В этом был бы смысл, если не было обратной совместимости с ES5, а так большинство нововведений это лишь синтаксический сахар, который видеться новичкам как спасение из за недостаточных знаний в ES5, к примеру, те же классы...
