Сказка о попе и его работнике Балде. Только каковы были истинные цели сеошника, решившего поведать нам (с гуглом) эту историю, наполненную пылкими речами и драматизмом?
Если вы не нашли себя на карте, это еще не значит, что за вами не следят. ^) Новость лишь про то, что одна из соц. сетей размещает некоторую часть данных, собираемых приложением в паблике. Другие же просто не размещают. Современные девайсы на Android, iOS или Window (и это не только телефоны, но и прочая шибко «умная» бытовая техника) собирают и передают больше телеметрии, чем вы можете себе представить.
если вы изучали scrum, наверно должны это помнить. как вы понимаете, что ваш процесс не просто достаточно эффективен, чтобы укладываться в сроки (которые по предыдущей статье выставляют сами разработчики, и вероятно с учетом всех этих «активностей»), а в самом деле эффективен максимально?
поскольку product owner у вас не является частью команды, это не scrum. вы можете и дальше называть все эти активности словом «скрам», если видите в этом какую-то пользу, но это какой-то другой процесс. насколько он адекватен? очевидно, что решение инженерной задачи не сводится только лишь к написанию кода. поэтому вопрос не в наличии «активностей», как таковых, а в их эффективности. попробуйте для начала оценить хотя бы это.
Это «быстрорастворимый» доклад, содержательная часть которого изрядно разбавлена потоком слов. Но заходит хорошо, нескучно. :)
По-моему айтишные презентации на 40 минут с вопросами из зала, уже успели обзавестись своими канонами и правилами. Так что их давно пора относить к особому сценическому разговорному жанру (ну типа камеди клаб). А если прямо так нужно получить информацию кратко и по делу, то лучше профильные статьи почитать или переговорить с докладчиком tête à tête.
Строго говоря, Service Worker кэш не хранят. За хранение кеша отвечает Cache API, которому сервисворкеры делигируют хранение кеша. Cache API хоть и появился в спецификациях вместе с сервис воркерами, но фактически доступен отовсюду: из ServiceWorker, из любых других worker и, конечно, из window. Cache API вполне может использоваться самостоятельно.
В Chrome 42 добавили возможность кеширования байткода для JS скриптов. Фича применяется как для скриптов загружаемых обычным способом, так и извлекаемых из Cache API. https://blog.chromium.org/2015/03/new-javascript-techniques-for-rapid.html. Поэтому все предыдущие способы кеширования тоже в деле. Но есть отличие в политиках, когда code cache начинает применяться. Для скриптов, загружаемых обычным способом, байт код начинает кешироваться только при повторной загрузке. Для извлекаемых из Cache API — сразу.
Нюанс в том, что компиляция JS это достаточно тяжелая операция, а сайты куда пользователи заходят не слишком часто, или библиотеки из которых приложение использует лишь 5% функций это все реальность. V8 много делает для того, чтобы уменьшить время холодного старта. Поэтому старается запускать детальный парсинг и компиляцию лениво, когда код действительно выполняется. Хаки типа optimize-js и Cache API могут форсировать компиляцию и кеширование байт кода. Но надо понимать, что это будет негативно сказывается на времени первой загрузки (что Артем и получал, судя по графикам на слайдах при попытке положить в кеш все подряд).
Пока один пишет статью на хабр, а другой этот бессмысленный коммент к статье, кто-то успевает решать и опровергать решение задач тысячелетия. Дорогая редакция, пристрели мне карму, может тогда тоже сделаю что-то полезное.
Сожалею, что пример оказался путанным. Я имел ввиду задачи, где глядя на код, результат не совсем всегда очевиден. В случае map fibonacci и задачи нахождения оптимального пути в графе в хаскеле получается неожиданно плохая асимптотика. По-моему это ни чем не лучше, чем приколы с приведением типов в JS.
А рассматривали опыт аналогичных предшественников (gwt, например или jsjinja)? Предыдущие попытки пока заканчивались не очень из-за тормозов при выполнении, проблем с безопасностью и с отладкой генерированного кода.
Вообще основные заморочки с JavaScript ведь не в языке, а в большом количестве разнообразных неконтролируемых сред исполнения. Это не сразу бывает очевидно при переходе с бекенда. Каждый браузерный движок имеет свои особенности, которые необходимо учитывать.
Например, первое, что приходит на ум. На бекенде, в обычной среде исполнения ASP.NET MVC, дернуть из chtml метод, выполняющий запрос в базу, можно счесть и за шалость. При передаче такой имплементации на клиента, даже если решены все технические проблемы, это может стать дырой в безопасности. Аналогично получается со всеми сторонними зависимостями, библиотеками и т.п.
Поэтому писать в такой системе все равно придется с постоянной оглядкой на клиент-сайд, т.е. еще на любимом языке, но «как бы на JavaScript». Все бы ни чего, но это на порядок усложняет (удорожает) как задачу самого кодинга, так и последующей поддержки.
Асинхронность говорит лишь о порядке выполнения, который не важен, в отличие от синхронного, и больше ни о чем (о разновидностях многозадачности упоминать еще рано). Но это, вроде бы простое, свойство открывает ряд интересных возможностей для применения различных стратегий выполнения такого кода, что будет принципиальным образом сказываться на производительности и отзывчивости.
Прикол в том, что 2 потока отдельными тестами это имитация бурной деятельности. 2 потока в тесте и 20К потоков при эксплуатации могут давать совершенно разную картину для одной и той же сборки. А это, в свою очередь, резонно порождает отдельную пачку вопросов относительно практической полезности и экономической оправданности таких тестов в контексте раннего обнаружения класса багов, специфичного лишь для многопточного кода.
Выпад про интеграционные тесты, если честно, не понял. Мой тезис был конкретно про юнит, ибо это база. Для end-to-end тестов в условиях приближенным к боевым, существуют свои решения как для ручного так и для автоматического тестирования.
По-моему айтишные презентации на 40 минут с вопросами из зала, уже успели обзавестись своими канонами и правилами. Так что их давно пора относить к особому сценическому разговорному жанру (ну типа камеди клаб). А если прямо так нужно получить информацию кратко и по делу, то лучше профильные статьи почитать или переговорить с докладчиком tête à tête.
В Chrome 42 добавили возможность кеширования байткода для JS скриптов. Фича применяется как для скриптов загружаемых обычным способом, так и извлекаемых из Cache API. https://blog.chromium.org/2015/03/new-javascript-techniques-for-rapid.html. Поэтому все предыдущие способы кеширования тоже в деле. Но есть отличие в политиках, когда code cache начинает применяться. Для скриптов, загружаемых обычным способом, байт код начинает кешироваться только при повторной загрузке. Для извлекаемых из Cache API — сразу.
Нюанс в том, что компиляция JS это достаточно тяжелая операция, а сайты куда пользователи заходят не слишком часто, или библиотеки из которых приложение использует лишь 5% функций это все реальность. V8 много делает для того, чтобы уменьшить время холодного старта. Поэтому старается запускать детальный парсинг и компиляцию лениво, когда код действительно выполняется. Хаки типа optimize-js и Cache API могут форсировать компиляцию и кеширование байт кода. Но надо понимать, что это будет негативно сказывается на времени первой загрузки (что Артем и получал, судя по графикам на слайдах при попытке положить в кеш все подряд).
Много интересного по теме в статье JavaScript Start-up Performance.
Пока один пишет статью на хабр, а другой этот бессмысленный коммент к статье, кто-то успевает решать и опровергать решение задач тысячелетия. Дорогая редакция, пристрели мне карму, может тогда тоже сделаю что-то полезное.
Вообще основные заморочки с JavaScript ведь не в языке, а в большом количестве разнообразных неконтролируемых сред исполнения. Это не сразу бывает очевидно при переходе с бекенда. Каждый браузерный движок имеет свои особенности, которые необходимо учитывать.
Например, первое, что приходит на ум. На бекенде, в обычной среде исполнения ASP.NET MVC, дернуть из chtml метод, выполняющий запрос в базу, можно счесть и за шалость. При передаче такой имплементации на клиента, даже если решены все технические проблемы, это может стать дырой в безопасности. Аналогично получается со всеми сторонними зависимостями, библиотеками и т.п.
Поэтому писать в такой системе все равно придется с постоянной оглядкой на клиент-сайд, т.е. еще на любимом языке, но «как бы на JavaScript». Все бы ни чего, но это на порядок усложняет (удорожает) как задачу самого кодинга, так и последующей поддержки.
Выпад про интеграционные тесты, если честно, не понял. Мой тезис был конкретно про юнит, ибо это база. Для end-to-end тестов в условиях приближенным к боевым, существуют свои решения как для ручного так и для автоматического тестирования.