Использование калифорния в качестве источника нейтронов это была довольно распространенная практика. Сейчас где было можно от него отказались по причине ужесточения требований радиационной безопасности, дороговизны и сложности процедур замены.
Но даже в таком "оптимизированном" json'е есть шанс сориентироваться, хотя бы по содержимому полей. В бинарнике без знания структуры шансов практически нет.
По поводу "оптимизации" - сокращенные поля это еще не предел. Я, например, видел JSON внутри которого было поле в base64, в котором лежал xml сжатый zip ))). И это всё еще было лучше, чем бинарь.
Разница в 10%. И откуда такая уверенность, что gzip сильно нагружает cpu? Вы делали бенчмарки? Предполагаю, что гораздо дороже обходилась сериализация/десериализация JSON, но вы как-то с ней жили, судя по статье проблема именно в размере JSON, а не CPU (хотя реализация json в стандартной библиотеке не блещет производительностью)
Затраты CPU на компрессию зачастую компенсируются снижением времени на передачу данных (например content-encoding: gzip включен практически везде на крупных веб-ресурсах, видимо неспроста).
.
Основной минус ИМХО в том, что на выходе получается кусок непонятного бинаря, вместо самоаннотированных данных в JSON, которые потом можно прочитать чем угодно.
Ворчу, потому что сейчас как раз работаю над задачей чтения данных из легаси системы, где часть данных хранится в бинарниках с кастомной сериализацией (описание структур данных вендор не предоставил естественно )))
Есть стойкое ощущение, что 99% приложений, которые пишут на всяких Next.js можно спокойно наговнокдить на обычной vanilla js + пара тройка специфичных библиотек, которые решают узкие задачи... Проблема в том, что порог входа очень низкий. Поэтому на старте берем новый хайповый распиаренный фреймворк, который работает почти как надо из коробки. Вот в этом почти и кроется дьявол. Потому что дальше дальше остается лишь уповать на то, что создатели фреймворка (которые нам ничего не должны) хорошо сделали свою работу (не факт), продумали все сценарии использования, которые нам могут понадобиться (вряд ли) и будут осуществлять качественную поддержку и развитие своего продукта, добавляя нужные вам фичи (с чего бы?). Даже вендоры коммерческих приложений за много денег с оплаченной премиальной поддержкой не особо стремятся допиливать свой продукт под ваши хотелки, а тут что? Остается лишь ворчать в хабрике, показывая каких диких костылей пришлось наворотить, чтобы очередная гравицапа делала как надо.
Вероятность того, что в один день в одном городе родятся два человека с одинаковым ФИО тоже не нулевая. Видимо давать детям странные малораспростаненные имена скоро станет не шизой родителей, а вполне себе обоснованным решением. Одна знакомая с очень распространенными ФИО много лет бодалась с питерскими приставами, которые блокировали у нее счета, потому что ее тезка из питера наделала долгов.
Человеческий фактор, от него никуда не деться. Кстати, сам наблюдал такую вещь: пульт управления реактором, у оператора стоит отдельный компьютер с выход в интернет и танками. Сделано это для того, чтобы он от скуки не полез реактором управлять. Пусть лучше в танки играет)
SD2 (точнее ее производные) стала выдавать приличные результаты только благодаря длительной упорной работе сообщества энтузиастов. То, что 3-я в "стоке" превосходит MJ6 - ну очень сомнительно...
Судя по обилию матов в переписке на скриншотах, там не только нода 18+ )))
Использование калифорния в качестве источника нейтронов это была довольно распространенная практика. Сейчас где было можно от него отказались по причине ужесточения требований радиационной безопасности, дороговизны и сложности процедур замены.
Вот тут не понятно. Есть работающий проект, надо повторить один-в-один на hard-code. Куда уж четче?
Но даже в таком "оптимизированном" json'е есть шанс сориентироваться, хотя бы по содержимому полей. В бинарнике без знания структуры шансов практически нет.
По поводу "оптимизации" - сокращенные поля это еще не предел. Я, например, видел JSON внутри которого было поле в base64, в котором лежал xml сжатый zip ))). И это всё еще было лучше, чем бинарь.
Разница в 10%. И откуда такая уверенность, что gzip сильно нагружает cpu? Вы делали бенчмарки? Предполагаю, что гораздо дороже обходилась сериализация/десериализация JSON, но вы как-то с ней жили, судя по статье проблема именно в размере JSON, а не CPU (хотя реализация json в стандартной библиотеке не блещет производительностью)
Затраты CPU на компрессию зачастую компенсируются снижением времени на передачу данных (например content-encoding: gzip включен практически везде на крупных веб-ресурсах, видимо неспроста).
.
Основной минус ИМХО в том, что на выходе получается кусок непонятного бинаря, вместо самоаннотированных данных в JSON, которые потом можно прочитать чем угодно.
Ворчу, потому что сейчас как раз работаю над задачей чтения данных из легаси системы, где часть данных хранится в бинарниках с кастомной сериализацией (описание структур данных вендор не предоставил естественно )))
А вы пробовали просто писать JSON в zip? Подозреваю, что выигрыш мог бы получиться сопоставимый с вашим решением.
Так он и не тормозит, тормозят программисты, которые пишут на нем тормозящие программы.
У меня и для ноды вопросы не возникают. Да и вопрос ваш не очень понятен, если честно.
Не ведет. Разрабатывает. Точнее - уже разработал. И они тоже идеальные (т.е. см. последний пункт статьи)).
Для идеального языка программирования нужен идеальный процессор.
Идеального процессора не существует.
Какой из этого вывод?
Есть стойкое ощущение, что 99% приложений, которые пишут на всяких Next.js можно спокойно наговнокдить на обычной vanilla js + пара тройка специфичных библиотек, которые решают узкие задачи...
Проблема в том, что порог входа очень низкий. Поэтому на старте берем новый хайповый распиаренный фреймворк, который работает почти как надо из коробки. Вот в этом почти и кроется дьявол.
Потому что дальше дальше остается лишь уповать на то, что создатели фреймворка (которые нам ничего не должны) хорошо сделали свою работу (не факт), продумали все сценарии использования, которые нам могут понадобиться (вряд ли) и будут осуществлять качественную поддержку и развитие своего продукта, добавляя нужные вам фичи (с чего бы?).
Даже вендоры коммерческих приложений за много денег с оплаченной премиальной поддержкой не особо стремятся допиливать свой продукт под ваши хотелки, а тут что?
Остается лишь ворчать в хабрике, показывая каких диких костылей пришлось наворотить, чтобы очередная гравицапа делала как надо.
Вероятность того, что в один день в одном городе родятся два человека с одинаковым ФИО тоже не нулевая. Видимо давать детям странные малораспростаненные имена скоро станет не шизой родителей, а вполне себе обоснованным решением.
Одна знакомая с очень распространенными ФИО много лет бодалась с питерскими приставами, которые блокировали у нее счета, потому что ее тезка из питера наделала долгов.
Здравствуйте! Было бы неплохо указать лицензию, чтобы понимать, возможно ли его использование в коммерческих продуктах.
Что за файлообенник
Музыканты - накладывают кучу "ухудшайзеров", чтобы получить необычный звук.
Звукорежиссеры - пихают в мастер эквалайзер, компрессор, лимитер
Аудиофилы (включают лосслес) - Вау, теперь я слышу все детали!
Такая лотерея, где выигравший получает сознание, чтобы осознать что он выиграл ))
SD2 (точнее ее производные) стала выдавать приличные результаты только благодаря длительной упорной работе сообщества энтузиастов. То, что 3-я в "стоке" превосходит MJ6 - ну очень сомнительно...
Больше года? Это еще с windows 8 началось всё!
Лучше когда готово будет. Про выпекание багетов в домашних условиях уже была когда-то статья и она была в топе. )))