Сравнивать float так, словно это int - опасно, очень опасно. Потому что возможна ситуация, когда они почти равны.
К примеру, есть у нас на проекте ресайзер/обрезчик картинок. Который давал очень всратую багу - иногда рамка, по которой нужно было обрезать изображение, внезапно переводилась в дефолтную позицию. После погружения под капот либы cropper.js, поверх которой был написан компонент, отвечающий за кадрирование изображений, выяснилось, что когда юзер тыкает на рамку кадрирования, та может на самую малость деформироваться.
На считанные доли пикселя.
Проблема в том, что потом эти доли пикселя участвуют в строгом сравнении фактического и предельного допустимого габарита рамки кадрирования. И могут не сойтись.
Сегодня, например, фактический размер составил 450.66, а допустимый - 460.52. Так что или округлять float-ы перед сравнением, или же сравнивать по относительной разности (когда |x2-x1|/x1 < eps). Увы и ах, но библиотечка сторонняя, и ее автор не подумал о такой мудрости древних. Так что мне пришлось костылить
Этим плохо научение школия говнокодингу на динамически-типированных языках. Только хардкор, только Pascal/Lazarus
fs.createReadStream / pipeАчо так медленно?
Отвечаем - потому что самое интересное происходит под капотом движка по обработки новых статей и сборки мастер-списка
Мастер-список нужен для поиск/выдача всех статей. В идеале для создания новой страницы нужно просто кинуть в специальную папку правильно отформатированный джсон и запустить скрипт обновления мастер-списка. Когда этот механизм взлетит - можно будет сфокусироваться на визуалах и интерактиве
Если кому-то кажыцо, что Browser Wars окончательно закончились со смертью Инфернет Эксплодера, то нихрена. Помимо Safari, в котором всегда своя атмосфера(в плохом смысле этого слова, без Омской Птицы) есть еще куча префиксных свойств, обычно связанных с отображением кусков UI. Долгое время в Хроме можно было клево так стилизовать скроллбары через псевдоэлементы ::-webkit-scrollbar, ::-webkit-scrollbar-thumb, ::-webkit-scrollbar-buttons. А для Фокса был фоллбек в виде scrollbar-width/scrollbar-color
И до последнего тут было все ок, но с некоторого момента W3C решыли, что было бы неплохо ввести унификацию. Так что при совместном применении вебкитных приблуд с "стандартным" scrollbar-width/scrollbar-color последний полностью переопределяет стиль скроллбара и глушит его напрочь. А в недавней 121-ой версии Хрома они эту идею применили на практике, так что старые стили, прописанные с вебкитовыми свойствами и фоллбеком, деграднули до уровня фоллбека.
Конечно, можно выпилить фоллбек, но тогда отрыгнет Файрефокс, а в обозримом будущем и сами вебкит-специфические стили. Бггг
Теперь мой коммент.
Человек, предвидевший АСГУCybersyn и предложивший смотреть на товары как материализованные джоули (не важно, пошли ли эти джоули на подъем воды на хлопковые поля или создание вольтовой дуги, переплавляющей кремниевый монокристалл) - имхо гений без всяких споров. Ну и упоминание "красного графа" Бартини - это отдельный, значимый лично для меня момент (в силу моего увлечения экранопланами)
Кстати, за новогодние праздники поменял охлад. GamerStorm Castle 360→Aorus Waterforce 360X.
Потому что охлад брался под i7-11700, а в итоге студить ему пришлось i7-13700, который на 7.5мм длиннее и впритык ложится на термоинтерфейс водоблока. При штатных нагрузках в виде VS Studio, Блендера или игрушек разница не особенно заметна. Но с Ансисом на 12-и ядрах - вылезает. Там, где раньше 4-5 ядер гарантированно выходили на 90-95, сейчас 1-2 на 85-90 и еще 2-3 на 75-85. (а еще новый охлад умеет выводить данные с термодатчиков на экран помпы).
А еще в части железа возникают мысли отн. i7-14700, который в том же сокете, что и тринашка, но ядер в нем больше (да, это дохлые energy-efficient cores, но дохлость у них относительная, 4 головы на 2.5-4.3ГГц - это дополнительный ноут под капотом ). И не просто в ту же цену, а дешевле предшественника на ~10килорублей
Я все равно обломался с четвертой плашкой памяти. Не лезет.
