Предположим, нам нужно выполнить какое-либо асинхронное действие для каждого элемента массива array. Пусть это асинхронное действие обернуто в некую функцию doSomething(), которая возвращает обещание выполнить это асинхронное действие. Шаблон того, как в этом случае выстроить цепочку обещаний, как это ни странно, основан не на использовании функции forEach, а на использовании функции reduce
Ну сомневаюсь что в хакатанскую работу взяли бы парсер для манги :) хотя смотря чем бизнес занимается.
А про оплачиваемое время, это у кого как, у нас это время не оплачивалось, но была жирная морковка до которой не все дотягивались.
Ну ни кто же вам не мешает, так же собрать людей в команду и запилить «пет-проект». Мы все исходим из своих жизненных опытов. Я вот сделал такой вывод и в хакатоне я вижу не отдушину для разработчиков, а возможность для бизнеса проверить максимальное кол-во идей за минимальные ресурсы. Как разработчик я с таким подходом не согласен и больше участвовать в этом не буду.
И вот убейте меня, я не понимаю почему люди должны тратить личное время на создание фич для рабочего проекта, а компания при этом вкладывается только на «пиццу и пиво». Хотите честный хакатон? Окей, оплачивайте мне время за эту работу. В общем я за равенство, ни кто не знает насколько те или иные фичи принесут пользу в конечном итоге, поэтому разделение вложений должно бытьо. Хакатанщики тратят личное время и силы, компания тратит деньги. Взлетело, хорошо, кто то потратил время и заработал почет и уважение, а кто то вложив немного денег, их приумножил. Не взлетело, ничего страшного.
Это все личное мнение, основанное на личном опыте со стороны разработчика.
Мое мнение что хакатоны должны проходить в рабочее время. А так это выглядит так, что те кто участвую в хакатоне выкладываются в овер 200% и единицы из команд получают приз, а компания устраивавшая хакатон с минимальными издержками проверяет кучу идей и получает работающие прототипы. Если говорить проще, то хакатон это такая большая морковка перед глазами работника, которая привязана к его же спине на хитроустроенной телескопической палке.
Из личного опыта я сделал вывод, что те же овер 200% усилий лучше потратить в свои идеи и проекты, в итоге затраченные ресурсы те же (ну только пиццу за свой счет придется покупать), а профита больше.
То что вы делаете в конфиге описывая руками какие файлы откуда тянуть это и есть ручное управление зависимостями. В больших проектах таки конфиги вырастают до неприличных 3к-5к тысяч строк и управлять всем этим становится не просто тяжело, а практически невозможно. Самый правильный и верный способ это описывать зависимости в коде и точка, не нравится amd паттерн который в requirejs, пишите commonjs модули, которые являются стандартом в мире nodejs. Не устраивает commonjs? Используйте новый стандарт Systemjs, но не выносите зависимости из кода иначе потом так и хлебнете что отмываться устанете.
Это костыль, хотя бы потому что вебпак при запуске в `watch` загружает все дерево в память и следит за изменением файлов и только теми которые реально используются в проекте и при их изменении он осуществляет сборку сразу а не начинает пересобирать все с нуля, как это сделано в вашем случае.
Про деплой и тесты это вы уже сами додумали, я ничего подобного не писал.
Или на русском: мы сообщаем Gulp за какими файлами нужно следить. Если кто-то из них обновился, то при помощи Webpack он соберёт скрипт из зависимостей и кусочков Js-кода и превратит Sass в Css. Дальше, он попросит браузер обновить страницу при помощи browserSync.
зачем этот костыль? Вебпак все это делает сам в том числе и сообщит клиенту какой модуль обновился и пришлет новый модуль, дальше останется только обработать это событие.
Вот так живешь живешь, а потом оказывается что в js массивы не по ссылкам передаются, а по значениям. Вы либо выразили свою мысль не правильно, либо несете что то из разряда фантастики.
По моему это ваша задача сделать так, что бы в ЦА попадало как можно больше людей. Вы не находите странным делая игру с маленькой целевой аудиторий, а потом жаловаться что нас не любят потому что мы из России. Я больше всего уверен, что геймерам совершенно все равно откуда вы, они даже могу не знать где эта Россия на карте.
Я видел, для меня это не проблема. Во первых это очень редкие случаи, а во вторых имеется нормальная поддержка IDE. В третьих если вы не пишите модуль, то проблему решает NODE_PATH.
1) Если у вас один конфиг на все случаи жизни, который работает по разному в зависимости от условий, то вы сами себе создали проблему. Я не знаю какие там проблемы у gulp и зачем он вообще нужен вместе с webpack'ом.
2) За все время работы я не сталкивался с проблемой написать полный путь к нужному мне файлу, а вот с проблемой таких хитрых загрузчиков сталкивался. С ростом приложения, все эти хитрые загрузчики только осложняют жизнь.
3) Объясните мне для чего нужны локальные модули?
Я три раза перечитал статью, но так и не понял какую проблему решает автор.
1) Много require в начале файлов -> создайте отдельный файл который будет возвращать объект с уже подключенными модулями и используйте его везде.
2) В чем смысл подключения модулей в nodejs только тогда когда они нужны? Экономии по памяти не выйдет, а лишняя логика добавляется, да и в некоторых ситуациях это может вызвать тормоза для первых обращений к таким методам.
3) Чем не устраивает стандартный метод «резолва» модулей через NODE_PATH?
а то что статьи в целом привлекают пользователей которые дают бабло через рекламу, вы почему не учитываете? Да и кому нужен корпаративный блог, если на нем нет пользователей? Так что здесь не все так однозначно.
Речь не идет о полном не знании jq, естественно о его существовании слышали все, но насколько глубоко знают люди апи jq? А самое главное, является ли это показателем уровня разработчика. Для меня большинство юзкейсов jquery это: получить элемент по селектору, снять/навесить обработчик, поманипулировать с dom и поставить снять класс. Но в jquery куда больше методов, только мне до них дела нет, и я их не знаю или не использую. А все то что чаще всего используется уже реализовано на уровне стандарта, так вот и вопрос, так ли он необходим этот jquery?
Основной проект у нас 100M+ пользователей, да на основном проекте используется jq, но он там встроен в вреймворк и больше является рудиментом, 99% кода который пишут фронтенд разработчики никак не связан с jq.
Так же есть ряд других проектов, в которых ситуация с jq такая же, а в некоторых он не используется вовсе.
Что касается моих наблюдений об интервьюируемых мной людях, то очень часто к нам приходят люди которые имеют большой опыт работы фронтенд разработки на jq и странным образом они не могут объяснить такие простые вещи, как: чем отличаются GET от POST запросы, не знают как работают куки, не могут объяснить как распространяются события в браузере и я уже молчу про такие вещи как, замыкания, прототипы, ссылочные типы. Так кто же все эти люди которые много лет программировали фронтенд на jq?
Мы вам говорим, что лично ваша статистика это не показатель дел в отрасли, у нас в компании jquery почти не используется и по лично моей статистике люди которые не знают jquery оказываются куда более компетентней людей которые его знают. Но Вы конечно и дальше можете тут биться в истерике и доказывать правоту вашей статистики.
Знали бы вы сколько мы отсеяли ведущих JS разработчиков, с 5+ годами работы, которые валятся на элементарных тестах на знание js. Мы скорее наймем человека который не знает jquery, потому что он реально что то знает и что то делал, а не гуглил последние 5ть лет нужный плагин в интернете.
Кидайте поменьше говна на вентилятор, есть проекты для которых jquery и нафиг не нужен, а с развитием новых стандартов эта тенденция только расширяется.
А разве не?
А про оплачиваемое время, это у кого как, у нас это время не оплачивалось, но была жирная морковка до которой не все дотягивались.
И вот убейте меня, я не понимаю почему люди должны тратить личное время на создание фич для рабочего проекта, а компания при этом вкладывается только на «пиццу и пиво». Хотите честный хакатон? Окей, оплачивайте мне время за эту работу. В общем я за равенство, ни кто не знает насколько те или иные фичи принесут пользу в конечном итоге, поэтому разделение вложений должно бытьо. Хакатанщики тратят личное время и силы, компания тратит деньги. Взлетело, хорошо, кто то потратил время и заработал почет и уважение, а кто то вложив немного денег, их приумножил. Не взлетело, ничего страшного.
Это все личное мнение, основанное на личном опыте со стороны разработчика.
Из личного опыта я сделал вывод, что те же овер 200% усилий лучше потратить в свои идеи и проекты, в итоге затраченные ресурсы те же (ну только пиццу за свой счет придется покупать), а профита больше.
Про деплой и тесты это вы уже сами додумали, я ничего подобного не писал.
зачем этот костыль? Вебпак все это делает сам в том числе и сообщит клиенту какой модуль обновился и пришлет новый модуль, дальше останется только обработать это событие.
https://gist.github.com/zxcabs/5d75c11f69445c4d9837
2) За все время работы я не сталкивался с проблемой написать полный путь к нужному мне файлу, а вот с проблемой таких хитрых загрузчиков сталкивался. С ростом приложения, все эти хитрые загрузчики только осложняют жизнь.
3) Объясните мне для чего нужны локальные модули?
1) Много require в начале файлов -> создайте отдельный файл который будет возвращать объект с уже подключенными модулями и используйте его везде.
2) В чем смысл подключения модулей в nodejs только тогда когда они нужны? Экономии по памяти не выйдет, а лишняя логика добавляется, да и в некоторых ситуациях это может вызвать тормоза для первых обращений к таким методам.
3) Чем не устраивает стандартный метод «резолва» модулей через NODE_PATH?
Основной проект у нас 100M+ пользователей, да на основном проекте используется jq, но он там встроен в вреймворк и больше является рудиментом, 99% кода который пишут фронтенд разработчики никак не связан с jq.
Так же есть ряд других проектов, в которых ситуация с jq такая же, а в некоторых он не используется вовсе.
Что касается моих наблюдений об интервьюируемых мной людях, то очень часто к нам приходят люди которые имеют большой опыт работы фронтенд разработки на jq и странным образом они не могут объяснить такие простые вещи, как: чем отличаются GET от POST запросы, не знают как работают куки, не могут объяснить как распространяются события в браузере и я уже молчу про такие вещи как, замыкания, прототипы, ссылочные типы. Так кто же все эти люди которые много лет программировали фронтенд на jq?
Мы вам говорим, что лично ваша статистика это не показатель дел в отрасли, у нас в компании jquery почти не используется и по лично моей статистике люди которые не знают jquery оказываются куда более компетентней людей которые его знают. Но Вы конечно и дальше можете тут биться в истерике и доказывать правоту вашей статистики.
Кидайте поменьше говна на вентилятор, есть проекты для которых jquery и нафиг не нужен, а с развитием новых стандартов эта тенденция только расширяется.