в условиях вида ввод > программа1 > сериализованные данные > программа2 потенциал инъекций существенно снижается, потому что разработчики вынуждены во время сериализации опускаться до максимально абстрактного уровня, во время работы с которым риск случайно породить скриптовый язык поверх данных снижается
Эхх. От описания ощущение, как от аэропортов, где только-только внедряются зарядные на usb 2a и это преподносится как вершина технологий. Или до сих пор рекламируемые в машинах cd-чейнджеры.
Попробую описать, от чего ощущение такое.
Беспроводная зарядка через qi. У меня лично и умные часы, и наушники, и телефон есть. "трудно попасть телефоном" — это прям печально, очень хотелось бы, конечно, чтобы можно было все кинуть на стол и оно бы заряжалось (хотя бы в одну из его частей). Тут вообще никак, судя по всему, зона зарядки маленькая.
Индукционный подогрев чашки. То, что только металлические можно заряжать — ладно, это можно понять, иначе риск спалить дерево или обжечься. Но необходимость включать по кнопке — не знаю, как-то странно. Хотя с другой стороны — ладно, и правда как-то еще трудно определить. Ноутбуки тоже металлические (их можно подвергнуть индукции для нагрева), греются до 80 градусов, могут давить ножкой столько же, сколько весит чашка… тут правда сложно, окей. Хотя в целом выглядит как фича ради фичи, чтобы продавать покрасивее.
провода и разъемы. Нету type-c. Нету power delivery, только самые дешевые 1/2A зарядники. Звучит так себе, если честно. Круто было бы, если можно было бы напрямую заряжать макбук или xps от стола. И type-c можно было бы напихать по всему столу вдоволь, хоть с шагом в 30 см — они маленькие, и не цепляются.
Отдельный вопрос про необходимость подключения в две розетки — это прям странно. Было бы классно, если бы просто в каждой ножке была вилка (или разъем для нее), и можно было бы запитаться с любой стороны, а не тянуть провода из жопки стола.
динамики (а точнее, отсутствие микрофона). Блин, ну ведь можно же было тут разгуляться. Вставить хорошие направленные динамики и микрофоны, обеспечить человеку шикарную конференц-связь — за столом почти всегда известно где человек сидит. Нет, не прокатило.
Говоря про динамики, еще два огорчения: действительно, как выше писали, их можно завалить бумагами. ну можно же было бы как-то придумать, чтобы они были снизу, например, нет?
и ничего не сказано про пейринг через nfc, подозреваю, его нет, и подключение к блютуз-столу будет кнопкой. А вот что можно было добавить и было бы классным — сенсорная панель слева или справа, позволяющая управлять музыкой и показывать текущий трек. Это сейчас почти любой гаджет умеет, стандартное api кучи устройств.
Даже без самих динамиков это было бы очень круто.
В общем, фич много, но без нареканий нет ни одной (кроме механизма подъема стола, который покупается у партнеров, а не делается самими ребятами)
Я видел по-настоящему читаемый код на большом количестве языков и парадигм, и он был очень разным.
Более того, я в какой-то момент занимался именно вопросами влияния код-стайла на эффективность команд.
Любой текст, в том числе код, имеет когнитивную сложность.
Когда мы начинаем оперировать интерфейсами, которые завязаны на доменную область (не внешние библиотеки), мы все больше и больше растим количество сущностей, которые удерживаем в собственной — не железной, а мясной — оперативной памяти.
Если мы пишем код, в который будут редко приходить и изменять, но могут натыкаться в процессе работы — правильно будет написать эффективный код, покрыть его тестами и забыть. Просто чтобы каждый раз, когда люди доходят до него — они смотрели, думали "вроде он делает это, дальше ковырять не буду" и уходили.
Если мы пишем код, который часто меняется — например, бизнес-логика — он, конечно, должен быть выразительным и оперировать представлениями бизнес-сущностей в коде в ущерб количеству строк, избыточности и перформансу.
код, который будет предельно понятен хаскеллисту, сломает мозг ООП-разработчику. сишника не поймет гофер. JS-ник сойдет с ума от современного C++.
читаемость относительна и контекстна.
И да, бывает.
Попробовал тоже набросать решение. 11 строк против 45, разница не в 30 раз, но 4x — тоже неплохой результат. и на мой вкус — мой вариант ощутимо более читаемый и понятный.
getRanges = ([head, ...tail], prefixFn = s => s) => {
let tip = head;
const toStr = () => prefixFn(head === tip ? `${head}` : `${head}-${tip}`);
while (tail.length > 0) {
if (tail[0] - tip !== 1) {
return getRanges(tail, s => `${toStr()},${s}`)
}
tip = tail.shift();
}
return toStr();
}
иии эта задача в таком виде начинает занимать O(n), где n — количество интервалов.
предполагаю, что задача оценивала в том числе способность к reduce с O(1), где на лету добавляются символы к строке.
К тому же — читаемость это спорный вопрос. Читать тридцать строк там, где можно примерно понять, что происходит всего за одну — то еще удовольствие.
все сюрфейсы с type-c заряжаются через power delivery.
можно проверить через зарядник от макбука — перетыкал несколько сюрфейсов с ним (вплоть до surface book 2), все отлично работает.
но да, телефонные зарядки не поддерживаются.
surface pro connector нужен для подключения клавиатуры, сам по себе стандарт неплохой, это их аналог lightning. просто не распространен.
surface neo будет работать на 4х ядерном atom(x86), так что работать будет почти все, что надо, это скорее претензия к surface pro x, который на ARM. впрочем, дум 2016 на нем уже показали, так что, похоже, большинство проблем уже решили.
Первая проблема: проект собирается каким-то древним минимизатором и использовать современный синтаксис js нельзя. Никаких () => {}, const res = [...data, subRes], async/await…
рискну предположить, что речь об Uglify — из старых популярных минификаторов есть только он и гугловый GCC, а GCC уже поддерживает ES6 довольно давно.
Я раза четыре в свое время уже спотыкался об это, и каждый раз только через пару недель вспоминал, что у него есть форк Terser (https://github.com/terser-js/terser). API вроде на 100% совместимое — надо просто подменить функцию, которая вызывается.
Тогда не понимаю, в чем разница в контексте публикации про ограничение бесплатной версии. Или это было просто криком души, не связанным с конкретным событием? :)
не очень понял, чем это хоть сколько-то может быть удобнее что в долгой, что в короткой перспективе чем, например, mdx-deck, построенный на уже хорошо разросшейся и проверенной экосистеме react, gatsby и mdx.
но основной вектор атаки же уже давно не подбор, а переиспользование с других сервисов, и заявление "подходит для чего угодно" равносильно "когда взломают любой сервис с моим паролем, все мои сервисы будут скомпроментированы"
честно скажу, под конец статьи, где-то на 70%, продираться стало сложно.
Я правильно понимаю, что вы переизобрели io-ts?
Если да — то не очень круто. Не потому что хуже или лучше, а потому что io-ts основывается на fp-ts, который основывается на fantasy-land (хотя и чуть отходит от него), спецификации, которая описывает взаимодействие алгебраических структур на JS. Иначе говоря, обеспечивает совместимость кучи библиотек.
в условиях вида ввод > программа1 > сериализованные данные > программа2 потенциал инъекций существенно снижается, потому что разработчики вынуждены во время сериализации опускаться до максимально абстрактного уровня, во время работы с которым риск случайно породить скриптовый язык поверх данных снижается
понимаю, что разговаривать с переводом смысла нет, но, кажется, это не единственный делореан за эту версию истории программирования.
1995 ...Java стала популярной как раз во время код ревью…
1996 Джеймс Гослинг изобретает Java...
ну, я лично заказал себе вот такой зарядник — https://www.iguides.ru/main/other/razbiraemsya_v_standartakh_bystroy_zaryadki_usb_power_delivery_i_qualcomm_quick_charge/. hyperjuice вроде ухитрялась делать абсолютно универсальные зарядные банки с quick charge-ем, так что, возможно, и нашли решение, и уже есть ответ "как надо заряжаться".
посмотрим, что сгорит, надеюсь, что ничего.
было бы здорово, если бы исходник этой страницы был на гитхабе, и каждый мог удобно подключиться и участвовать в ее редактировании.
мне лично кажется странным писать код ошибки транслитом, например, и я готов это обсудить.
И, возможно, стоит вести ссылку не на пост с инструкцией "как поставить ссылку", а на что-то, где человек сразу сможет прочитать о происходящем
Эхх. От описания ощущение, как от аэропортов, где только-только внедряются зарядные на usb 2a и это преподносится как вершина технологий. Или до сих пор рекламируемые в машинах cd-чейнджеры.
Попробую описать, от чего ощущение такое.
Отдельный вопрос про необходимость подключения в две розетки — это прям странно. Было бы классно, если бы просто в каждой ножке была вилка (или разъем для нее), и можно было бы запитаться с любой стороны, а не тянуть провода из жопки стола.
Говоря про динамики, еще два огорчения: действительно, как выше писали, их можно завалить бумагами. ну можно же было бы как-то придумать, чтобы они были снизу, например, нет?
и ничего не сказано про пейринг через nfc, подозреваю, его нет, и подключение к блютуз-столу будет кнопкой. А вот что можно было добавить и было бы классным — сенсорная панель слева или справа, позволяющая управлять музыкой и показывать текущий трек. Это сейчас почти любой гаджет умеет, стандартное api кучи устройств.
Даже без самих динамиков это было бы очень круто.
В общем, фич много, но без нареканий нет ни одной (кроме механизма подъема стола, который покупается у партнеров, а не делается самими ребятами)
так стоп, их просто двигают магнитами? это же не роботы тогда по идее
Мне кажется, с такой концепцией они не могли быть кем-то еще, это же божественный маркетинг на игре слов.
в европейском законе написано "и аналогичные технологии", никак трекать нельзя, они не привязывались к конкретной технологии
Я видел по-настоящему читаемый код на большом количестве языков и парадигм, и он был очень разным.
Более того, я в какой-то момент занимался именно вопросами влияния код-стайла на эффективность команд.
Любой текст, в том числе код, имеет когнитивную сложность.
Когда мы начинаем оперировать интерфейсами, которые завязаны на доменную область (не внешние библиотеки), мы все больше и больше растим количество сущностей, которые удерживаем в собственной — не железной, а мясной — оперативной памяти.
Если мы пишем код, в который будут редко приходить и изменять, но могут натыкаться в процессе работы — правильно будет написать эффективный код, покрыть его тестами и забыть. Просто чтобы каждый раз, когда люди доходят до него — они смотрели, думали "вроде он делает это, дальше ковырять не буду" и уходили.
Если мы пишем код, который часто меняется — например, бизнес-логика — он, конечно, должен быть выразительным и оперировать представлениями бизнес-сущностей в коде в ущерб количеству строк, избыточности и перформансу.
код, который будет предельно понятен хаскеллисту, сломает мозг ООП-разработчику. сишника не поймет гофер. JS-ник сойдет с ума от современного C++.
читаемость относительна и контекстна.
И да, бывает.
Попробовал тоже набросать решение. 11 строк против 45, разница не в 30 раз, но 4x — тоже неплохой результат. и на мой вкус — мой вариант ощутимо более читаемый и понятный.
иии эта задача в таком виде начинает занимать O(n), где n — количество интервалов.
предполагаю, что задача оценивала в том числе способность к reduce с O(1), где на лету добавляются символы к строке.
К тому же — читаемость это спорный вопрос. Читать тридцать строк там, где можно примерно понять, что происходит всего за одну — то еще удовольствие.
все сюрфейсы с type-c заряжаются через power delivery.
можно проверить через зарядник от макбука — перетыкал несколько сюрфейсов с ним (вплоть до surface book 2), все отлично работает.
но да, телефонные зарядки не поддерживаются.
surface pro connector нужен для подключения клавиатуры, сам по себе стандарт неплохой, это их аналог lightning. просто не распространен.
surface neo будет работать на 4х ядерном atom(x86), так что работать будет почти все, что надо, это скорее претензия к surface pro x, который на ARM. впрочем, дум 2016 на нем уже показали, так что, похоже, большинство проблем уже решили.
рискну предположить, что речь об Uglify — из старых популярных минификаторов есть только он и гугловый GCC, а GCC уже поддерживает ES6 довольно давно.
Я раза четыре в свое время уже спотыкался об это, и каждый раз только через пару недель вспоминал, что у него есть форк Terser (https://github.com/terser-js/terser). API вроде на 100% совместимое — надо просто подменить функцию, которая вызывается.
Если не угадал — ну… бывает)
а, ок. был уверен, что у spotify только платная версия есть.
Тогда не понимаю, в чем разница в контексте публикации про ограничение бесплатной версии. Или это было просто криком души, не связанным с конкретным событием? :)
Чтобы сразу было понятно, что надо платить?
Он же только по подписке вообще, без хоть какой-то бесплатной версии.
не очень понял, чем это хоть сколько-то может быть удобнее что в долгой, что в короткой перспективе чем, например, mdx-deck, построенный на уже хорошо разросшейся и проверенной экосистеме react, gatsby и mdx.
KeePass/LastPass/Dashlane/etc в помощь.
Это самое разумное, что может сделать ответственный пользователь
но основной вектор атаки же уже давно не подбор, а переиспользование с других сервисов, и заявление "подходит для чего угодно" равносильно "когда взломают любой сервис с моим паролем, все мои сервисы будут скомпроментированы"
честно скажу, под конец статьи, где-то на 70%, продираться стало сложно.
Я правильно понимаю, что вы переизобрели io-ts?
Если да — то не очень круто. Не потому что хуже или лучше, а потому что io-ts основывается на fp-ts, который основывается на fantasy-land (хотя и чуть отходит от него), спецификации, которая описывает взаимодействие алгебраических структур на JS. Иначе говоря, обеспечивает совместимость кучи библиотек.
Если нет — готов признать, что не осилил статью