А вот вы попробуйте открыть в какой-нибудь программе текстовый файлик на пару ГБ. Тут же окажется, что вообще редкая программа это может... А Far — может :)
Отличная статья, спасибо! Из нового узнал только про requestIdleCallback, но читалось легко (только «обещание» вместо «промиса» немного резало глаз).
Я бы ещё добавил про то, когда начинает исполняться код из промиса. В JS это совсем не так, как, скажем, в Python. В JS функция, переданная промису, начинает исполняться немедленно, без попадания в список таксов или микротасков. В отличие от кода в then, который выполнится в микротаксе даже в том случае, если код внутри промиса зарезолвится сразу, синхронно.
function foo() {
console.log('before promise');
const p = new Promise((resolve, reject) => {
console.log('inside promise');
resolve(3);
});
p.then((value) => console.log('then', value));
console.log('after promise');
}
foo();
// before promise
// inside promise
// after promise
// then 3
Если подробно, то я для изучения гита рекомендую такой «рецепт»:
Сначала потратить час и пролистать первые три главы gitbook: https://git-scm.com/book/ru/v2. Этот час окупится, так как будет понимание, что же происходит.
Использовать git для любых своих проектов и аккуратно коммитить изменения (объединяя их по сути).
Python c PyPi ещё, терпимо: в типичном среднем проекте 20-60 зависимостей. А вот экосистема javascript — это что-то... Смотрю наши проекты: приложение на vuejs — 3220 уникальных пакетов-версий, на реакте — 6386, бек на ноде — жалкие 772. Понятно, что с такими числами хотя бы минимально прикинуть, что за проекты ты используешь, нет никакой реальной возможности.
В питончике я стараюсь поглядывать, что попадает в полный список зависимостей, и всякий раз расстраиваюсь, когда после обновления список зависимостей расширяется.
Если честно, то я удивлён, что реальных атак по большому счёту так мало, так как при наличие целеустремлённости сначала внедрить зависимость на свою полезную мелкую библиотеку, а потом подновить её, добавив зловредной функциональности — не особо большой фокус. А ведь ещё можно бывают пакеты с бинарными артефактами...
У меня есть статья https://habr.com/ru/post/349860/ с миллионом просмотров и двумя тысячами закладок. В новом редакторе я бы даже не пытался её выложить на хабр. Я ещё с той версией ну просто задолбался редактировать вёрстку переносов строк, в такой большой статье это было ужасное мучение.
Статью писал сразу в html в WebStorm'е: там и горячие клавиши, и мгновенное обновление в соседнем окне. И замены регулярками (оформление отдельных деталей я несколько раз переделывал). Пустые строки бесили неимоверно, в остальном жить можно.
Сейчас открыл новый редактор — для меня это адок, я в нём статьи писать не буду. Хорошо, что старый работает.
PS. Для меня было бы идеально, если был бы формат «честный html с ограничениями» — можно использовать подмножество html (описанное в доках), добавлять некоторое количество стилей (описанное в доках), но никакой другой стилевой доработки не производится (стандартные стили — ОК). Без смеси html и маркдауна, с которой приходится всё время бороться.
Плюс формат маркдауна в духе гитхабовского (GitHub flavored Markdown, довольно много всего можно делать), но чур тоже стандартный, чтобы итоговый результат выглядел плюс-минус предсказуемо.
Не могу в полной мере согласиться с «с архитектурой что-то не то».
Давайте пример. Вот есть, скажем, карты. Давайте не будем резать, путь будет первый сервис. А есть такси — второй.
И теперь мы придумали супер-фичу для такси, которая требует доработок в картах (очевидно для такси нужны карты). Конечно же мы можем написать код так, чтобы это были фича-в-картах и фича-в-такси, которые можно катить вообще независимо друг от друга (и так и нужно делать с точки зрения кода). Но концептуально-то фича затрагивает два сервиса, а наше принудительное разрезание приводит к тому, что мы эту связь теряем.
Подозреваю, что тонкость в числе 10. Давайте поглядывая на слитый архив попробуем придумать фичу на 10 сервисов.
аналитика — новая фича легко может требовать новой аналитики
балансер — новая фича может добавлять хитрой асимметричной нагрузки
биллинг — хитрости с оплатой — легко
helpdesk — ну, хз. Фичи для поддержки где живут? Добавим пока сюда
карты — начинали с карт
мобилка — поменял карту — поменяй мобилку
такси — тоже с них начинали
Ну, 10 не натянулось, но 7 можно придумать.
По поему опыту работы в банке (в котором огромная куча изолированных систем) фича может легко затрагивать доработками 5-6 систем.
Читаю, и сразу на будущее хочется прикрутить «Graceful Degradation» — возможность контролируемо срезать нагрузку. В духе «упёрлись в базу» — сразу отключили «Воронеж» (в смысле самый неэффективный по выручке на один запрос регион/ресторан+источник (источник — мобилка или сайт). Потом — следующий, и так пока поднимется.
Очень крутой! Из его четырёхтомника мне очень нравится фрагмент вероятно из третьего тома про внешнюю сортировку данных на лентах. Грубо говоря, раньше данные хранились на лентах, никакого быстрого произвольного доступа, только последовательный. В такой ситуации очень естественно использовать сортировку слиянием. И вот после описания сортировки слиянием при помощи четырёх лент, там есть такой пассаж (по памяти).
Иногда хочется сортировать данные ещё быстрее, и XXX придумал, как это сделать. Однако с тех пор появились жёсткие диски, и этот алгоритм стал никому не нужен. Однако он настолько красив, что я его сейчас расскажу.
Да! И теперь для веб-разработчиков safari — это IE6 нового временим со своими плюхами. Только в отличие от всего IE работу в safari точно нужно поддерживать.
Есть ещё адок с полями для ввода номеров телефонов. Самая жесть — захардкодить +7 в начале, после чего оставлять ровно 10 символов из того, что ты вкопипастил. Так как номера у меня везде хранятся с префиксом +7, то обязательно обрезаются последние цифры. А если ты копируешь номер из условного телеграма, то там ещё будут и пробелы, поэтому весь хвост номера обрежется.
Ещё лютое — требование к паролю, когда одновременно а) нужно, чтобы в пароле была и маленькая буква, и большая, и цифры, и спецсимвол; б) нужно, чтобы длина пароля была строго до 16 символов. А-а-а-а, мой длинючий пароль из 20 символов не подходит, я должен его отрезать до 15, добавить в конец условный восклицательный знак, а потом это запомнить! (знаю про парольные менеджеры, но пароли банков в них не храню).
Вообще возможность ChatGPT корректировать свой ответ по результатам комментариев — очень крутая фича. Иногда ищешь что-нибудь в области, где все ключевые слова «загажены». Например, я недавно пытался найти, где же можно купить «болт М12 с отверстием под шплинт» — это такой почти обычный болт, у которого в конце резьбы отверстие, в которое вставляется проволочка, которая физически не даёт гайке раскрутиться. Нужно для соединений с высоким уровнем вибрации, но без сильной затяжки. И оказывается, что вся выдача загажена либо просто болтами, либо изредка чем-то про шплинты.
Получить продавца с таким товаром очень непросто. А так это могло бы выглядеть так: — болт М12 с отверстием под шплинт — болты М12 по 100р, болты цена, суперкрепёж продаёт болты — убери обычные болты — болты М12 с отверстием, ГОСТ, диаметр отверстия, ... — мне нужно купить — сбпкрепмагаз 100р, болты для ГАЗ 66 с отверстием, деталь IFS14-12
Сейчас полностью убрать категорию из поисковой выдачи в таких случаях очень сложно: ведь нужен и болт, и отверстие, и шплинт. И нужно, чтобы они соединились в одном товаре, а не на одной странице.
Когда я читаю ошибки chatGPT, которые здесь постят, я сразу вспоминаю анекдот:
К директору цирка приходит дрессировщик и показывает ему номер: под самым куполом медведь идет по канату и неплохо так играет на скрипке. — «Ну как?» — спрашивает дрессировщик. — «Да... Извините, но совсем не Паганини...»
Когда я вижу такой «плотный» по score топ, то сразу хочется добавить второй leaderboard — с ещё одним паком данных. И сравнить с первым leaderboard'ом. Есть ощущения, что совсем топ в достаточной мере случайным получается. И как раз будет видно, у кого хорошо стабилизирована модель, кто переобучился, а кого подкинула случайность.
Всё-таки, ИМХО, у гражданской авиации должен быть очень высокий уровень пассивной безопасности. У обычного керосина он довольно высокий: обычное давление, при обычной температуре, сам ну вообще не самовоспламеняется. Водород же в любом виде антоним слова «безопасность». В жидком виде нужны криогенные температуры или конские давления. Смесь же газообразного водорода с воздухом люто взрывоопасна. А уж в тех количествах, которые нужны самолёту — одним самолётом можно будет весь аэропорт взорвать.
А, ну и конкретно про 3.14. Для вычисления угла используется atan2, а для приближения справа
Math.atan2(0, -1) = 3.1415...Там есть вариант, когда оно играет в змейку вообще без промежуточного слоя: 4 входных и 3 выходных, то есть всё управление — это 15 весов.
Для змейки всегда есть положение «вперёд». Во входе «яблоко» угол от положения «вперёд» в радианах.
У меня вот есть такая интерактивная иллюстрация работы ма-а-а-аленькой сеточки, которая играет в змейку: https://shashkovs.ru/ai/
А вот вы попробуйте открыть в какой-нибудь программе текстовый файлик на пару ГБ. Тут же окажется, что вообще редкая программа это может... А Far — может :)
Размер бинаря же :)
Отличная статья, спасибо! Из нового узнал только про requestIdleCallback, но читалось легко (только «обещание» вместо «промиса» немного резало глаз).
Я бы ещё добавил про то, когда начинает исполняться код из промиса. В JS это совсем не так, как, скажем, в Python. В JS функция, переданная промису, начинает исполняться немедленно, без попадания в список таксов или микротасков. В отличие от кода в
then, который выполнится в микротаксе даже в том случае, если код внутри промиса зарезолвится сразу, синхронно.ИМХО, самый главный совет — в любой непонятной ситуации см. сюда: https://github.com/k88hudson/git-flight-rules/blob/master/README_ru.md
Если подробно, то я для изучения гита рекомендую такой «рецепт»:
Сначала потратить час и пролистать первые три главы gitbook: https://git-scm.com/book/ru/v2. Этот час окупится, так как будет понимание, что же происходит.
Использовать git для любых своих проектов и аккуратно коммитить изменения (объединяя их по сути).
В любой непонятной ситуации смотреть рецепт в git flight rules: https://github.com/k88hudson/git-flight-rules/blob/master/README_ru.md
Python c PyPi ещё, терпимо: в типичном среднем проекте 20-60 зависимостей. А вот экосистема javascript — это что-то... Смотрю наши проекты: приложение на vuejs — 3220 уникальных пакетов-версий, на реакте — 6386, бек на ноде — жалкие 772. Понятно, что с такими числами хотя бы минимально прикинуть, что за проекты ты используешь, нет никакой реальной возможности.
В питончике я стараюсь поглядывать, что попадает в полный список зависимостей, и всякий раз расстраиваюсь, когда после обновления список зависимостей расширяется.
Если честно, то я удивлён, что реальных атак по большому счёту так мало, так как при наличие целеустремлённости сначала внедрить зависимость на свою полезную мелкую библиотеку, а потом подновить её, добавив зловредной функциональности — не особо большой фокус.
А ведь ещё можно бывают пакеты с бинарными артефактами...
У меня есть статья https://habr.com/ru/post/349860/ с миллионом просмотров и двумя тысячами закладок.
В новом редакторе я бы даже не пытался её выложить на хабр.
Я ещё с той версией ну просто задолбался редактировать вёрстку переносов строк, в такой большой статье это было ужасное мучение.
Статью писал сразу в html в WebStorm'е: там и горячие клавиши, и мгновенное обновление в соседнем окне. И замены регулярками (оформление отдельных деталей я несколько раз переделывал). Пустые строки бесили неимоверно, в остальном жить можно.
Сейчас открыл новый редактор — для меня это адок, я в нём статьи писать не буду. Хорошо, что старый работает.
PS. Для меня было бы идеально, если был бы формат «честный html с ограничениями» — можно использовать подмножество html (описанное в доках), добавлять некоторое количество стилей (описанное в доках), но никакой другой стилевой доработки не производится (стандартные стили — ОК). Без смеси html и маркдауна, с которой приходится всё время бороться.
Плюс формат маркдауна в духе гитхабовского (GitHub flavored Markdown, довольно много всего можно делать), но чур тоже стандартный, чтобы итоговый результат выглядел плюс-минус предсказуемо.
Не могу в полной мере согласиться с «с архитектурой что-то не то».
Давайте пример. Вот есть, скажем, карты. Давайте не будем резать, путь будет первый сервис.
А есть такси — второй.
И теперь мы придумали супер-фичу для такси, которая требует доработок в картах (очевидно для такси нужны карты). Конечно же мы можем написать код так, чтобы это были фича-в-картах и фича-в-такси, которые можно катить вообще независимо друг от друга (и так и нужно делать с точки зрения кода).
Но концептуально-то фича затрагивает два сервиса, а наше принудительное разрезание приводит к тому, что мы эту связь теряем.
Подозреваю, что тонкость в числе 10. Давайте поглядывая на слитый архив попробуем придумать фичу на 10 сервисов.
аналитика — новая фича легко может требовать новой аналитики
балансер — новая фича может добавлять хитрой асимметричной нагрузки
биллинг — хитрости с оплатой — легко
helpdesk — ну, хз. Фичи для поддержки где живут? Добавим пока сюда
карты — начинали с карт
мобилка — поменял карту — поменяй мобилку
такси — тоже с них начинали
Ну, 10 не натянулось, но 7 можно придумать.
По поему опыту работы в банке (в котором огромная куча изолированных систем) фича может легко затрагивать доработками 5-6 систем.
Читаю, и сразу на будущее хочется прикрутить «Graceful Degradation» — возможность контролируемо срезать нагрузку. В духе «упёрлись в базу» — сразу отключили «Воронеж» (в смысле самый неэффективный по выручке на один запрос регион/ресторан+источник (источник — мобилка или сайт). Потом — следующий, и так пока поднимется.
Очень крутой!
Из его четырёхтомника мне очень нравится фрагмент вероятно из третьего тома про внешнюю сортировку данных на лентах.
Грубо говоря, раньше данные хранились на лентах, никакого быстрого произвольного доступа, только последовательный. В такой ситуации очень естественно использовать сортировку слиянием. И вот после описания сортировки слиянием при помощи четырёх лент, там есть такой пассаж (по памяти).
И дальше страниц 10-20 жёстких тонкостей.
Да! И теперь для веб-разработчиков safari — это IE6 нового временим со своими плюхами. Только в отличие от всего IE работу в safari точно нужно поддерживать.
Есть ещё адок с полями для ввода номеров телефонов. Самая жесть — захардкодить +7 в начале, после чего оставлять ровно 10 символов из того, что ты вкопипастил.
Так как номера у меня везде хранятся с префиксом +7, то обязательно обрезаются последние цифры. А если ты копируешь номер из условного телеграма, то там ещё будут и пробелы, поэтому весь хвост номера обрежется.
Ещё лютое — требование к паролю, когда одновременно
а) нужно, чтобы в пароле была и маленькая буква, и большая, и цифры, и спецсимвол;
б) нужно, чтобы длина пароля была строго до 16 символов.
А-а-а-а, мой длинючий пароль из 20 символов не подходит, я должен его отрезать до 15, добавить в конец условный восклицательный знак, а потом это запомнить! (знаю про парольные менеджеры, но пароли банков в них не храню).
Вообще возможность ChatGPT корректировать свой ответ по результатам комментариев — очень крутая фича.
Иногда ищешь что-нибудь в области, где все ключевые слова «загажены». Например, я недавно пытался найти, где же можно купить «болт М12 с отверстием под шплинт» — это такой почти обычный болт, у которого в конце резьбы отверстие, в которое вставляется проволочка, которая физически не даёт гайке раскрутиться. Нужно для соединений с высоким уровнем вибрации, но без сильной затяжки.
И оказывается, что вся выдача загажена либо просто болтами, либо изредка чем-то про шплинты.
Получить продавца с таким товаром очень непросто. А так это могло бы выглядеть так:
— болт М12 с отверстием под шплинт
— болты М12 по 100р, болты цена, суперкрепёж продаёт болты
— убери обычные болты
— болты М12 с отверстием, ГОСТ, диаметр отверстия, ...
— мне нужно купить
— сбпкрепмагаз 100р, болты для ГАЗ 66 с отверстием, деталь IFS14-12
Сейчас полностью убрать категорию из поисковой выдачи в таких случаях очень сложно: ведь нужен и болт, и отверстие, и шплинт. И нужно, чтобы они соединились в одном товаре, а не на одной странице.
Когда я читаю ошибки chatGPT, которые здесь постят, я сразу вспоминаю анекдот:
К директору цирка приходит дрессировщик и показывает ему номер: под самым куполом медведь идет по канату и неплохо так играет на скрипке.
— «Ну как?» — спрашивает дрессировщик.
— «Да... Извините, но совсем не Паганини...»
Когда я вижу такой «плотный» по score топ, то сразу хочется добавить второй leaderboard — с ещё одним паком данных. И сравнить с первым leaderboard'ом. Есть ощущения, что совсем топ в достаточной мере случайным получается.
И как раз будет видно, у кого хорошо стабилизирована модель, кто переобучился, а кого подкинула случайность.
Всё-таки, ИМХО, у гражданской авиации должен быть очень высокий уровень пассивной безопасности. У обычного керосина он довольно высокий: обычное давление, при обычной температуре, сам ну вообще не самовоспламеняется.
Водород же в любом виде антоним слова «безопасность». В жидком виде нужны криогенные температуры или конские давления. Смесь же газообразного водорода с воздухом люто взрывоопасна. А уж в тех количествах, которые нужны самолёту — одним самолётом можно будет весь аэропорт взорвать.
Да, мне только TTY-вариант.