думаю, для начала они обеспечили все-таки технологическое преимущество -- блокчейн не только для функций валюты, а все любые прочие применения (потенциально)-- и это создало у пользователей веру в его уникальность и перспективность и действительно появились не-валютные применения -- и валюта тоже раскрутилась до статуса "второй после"..
привет. ну "упаковка софта" -- не совсем то, о чем я говорю. для разработки, имхо, докер это в первую очередь "воспроизводимое окружение". поэтому, в самом начале статьи, мне действительно _стало понятно_, что это так или иначе, проблема конфигураций.. (далее все увлекательно и я дочитал даже, но интрига "как починить" для меня была раскрыта)) об этом и была шутка! (но, кажется, меня не все поняли).
а, вообще, я и правда считаю контейнеризацию одной из "серебрянных пуль" современной разработки. что же касается бд прода -- то, наверное, тогда уж managed (опять же в воспроизводимой среде).
документация "сверху" (как хотят) -- в конфлюенсах и вордах, а документация "снизу" (как есть) -- в репах и маркдаун. пока так практикуем.. вроде норм. PS: только plantUml сильно серьезно, в итоге оказалось, зато mermaid выручает быстро накидать схему, что происходит, какие-небудь sequence diagram и т.п.
ну и главное... мимикрировать под кого? под конкурентов, про которые уже достроверно известно об их тесном сотрудничестве с анб?) смешно. ни вотсапу ни сигналу доверия просто ноль. а вот телеграму -- больше ноля)
все так говорят ("избыточное доверие"), но подумайте, я вот прикинул -- ни разу не использовал защищенные чаты, однако выбираю телеграм за удобство и скорость/отзывчивость. мне кажется, большинство тоже.
аналогично, -- я хотел довольно сложную функцию на генераторах или итераторах в функциональном стиле, и с серией прототипов и уточняющих правок с моей стороны, все получилось, пожалуй, быстрее у нас вместе, чем если бы я писал "руками" самостоятельно.
ну, в смысле, строгая матмодель с эвристиками и формулами, по идее внутренней картины мира не имеет, точнее эта картина просто внешняя -- в голове автора(ов) матмодели. )
а любая нейросеть, да.. очередное подтверждение принципиального сходства с биологическими нс.
т.е. вывод -- выучивают. но, вроде бы, не только трансформеры!? разве для эффективно обученных сетей с другой архитектурой нельзя найти "срез", где будет видно выученное пространство состояний? вангую, что можно. в любой глубокой сети оно должно быть размазано по промежуточным слоям, но если есть свертки -- то в свертках (окнах фильтров) где-то должно просматриваться.. интуитивно кажется так.
Ну не знаю, не знаю.. ) Например, по моему опыту: * поиск PostGIS в Postgres по колонке типа мультиполигон с spatial-индексом, в итоге, прилично обгоняет поиск Elastic-а по geojson. У нас было ~80 млн полигонов, и в итоге даже до включения векторного кэширования мы отзывчиво выбирали окно и обновляли карту с сотнями/тысячами полигонов в поле видимости. * по часовой/против часовой -- довольно часто встречающаяся ошибки в данных -- некоторые полигоны (или их "дырки") от поставщиков неизбежно будут "битыми", "не в ту сторону" -- и это нужно все равно валидировать и конвертировать при индексации. оставить "на ответственности" поставщиков -- значит потерять контроль над качеством данных * в том же самом PostGIS из-коробки готовые высоко-оптимизированные реализации ST_simplify с тем же дугласом с пекером, (которые вы никогда не обгоните другими реализациями) и еще гора механизмов для развития гео-функционала в будущем, и использовать его было легко -- поэтому мы насколько помню симплифицировали "на лету", не теряя и не обрезая никаких данных (это грех, вообще))) * "такой контракт есть, он называется GeoJSON" -- смысл его в том, чтобы делиться данными, передавать их между системами. Это не формат для хранения или даже передачи во внутреннем апи на фронт, если речь о большой ГИС. Имхо. * стиль отображения? это же мусор. это пусть решается на фронтенде. зачем хранить/передавать это рядом с геоданными?)) плоские структуры всегда быстрее вложенных в глубину структурированных данных. разве нам не нужен перфоманс здесь?
и т.п... В общем, по моему мнению, это решение стратегически тупиковое.
Да, это понятно. Для меня JS не профильный язык, мне, скорее всего, не нужно будет это делать (разве что для пет-проектов).
Но само взвешивание -- "насколько это будет оправдано?", уже итак выглядит не очевидно..) Если я, проектируя апи, буду просить фронтенд-команду изменять все это поведение с десериализацией в проекте допустим с axios.. не знаю насколько это будет затратно. Скорее всего, как и в прошлый раз, мне скажут "давай строкой передавать, по-простому". И пока что, мне кажется, что будут правы.
Как я понял, предложение "висит", но там приведен пример workaround с использованием параметра reviver при вызове JSON.parse() / JSON.stringify() и там использовать JSON.rawJSON() -- жаль, только что вот он пока экспериментальный и таблица совместимости не слишком радует... но в хроме есть, уже хорошо.
но, конечно, нам срочно нужна мультимодальная opensource модель!.. потому что, грустно и бесперспективно теперь возиться с отдельными моделями, когда есть gpt-4o...)
скорее наоборот -- все остальные модальности обрабатываются "как язык". ведь именно трансформерная архитектура (родом из языковых моделей) -- дала возможность творить чудеса и с изображениями. как я понял, научились работать с механизмом внимания -- и вуаля. сначала применили на других модальностях, а теперь стала возможна и полная мультимодальность.
пишут, что нет.. как раз, в gpt-4o -- модель работает с модальностью звука -- а, значит, отображается в латентное пространство напрямую, и может улавливать интонации и прочие подобные вещи (так заявлено).
думаю, для начала они обеспечили все-таки технологическое преимущество -- блокчейн не только для функций валюты, а все любые прочие применения (потенциально)-- и это создало у пользователей веру в его уникальность и перспективность и действительно появились не-валютные применения -- и валюта тоже раскрутилась до статуса "второй после"..
привет. ну "упаковка софта" -- не совсем то, о чем я говорю. для разработки, имхо, докер это в первую очередь "воспроизводимое окружение". поэтому, в самом начале статьи, мне действительно _стало понятно_, что это так или иначе, проблема конфигураций.. (далее все увлекательно и я дочитал даже, но интрига "как починить" для меня была раскрыта)) об этом и была шутка! (но, кажется, меня не все поняли).
а, вообще, я и правда считаю контейнеризацию одной из "серебрянных пуль" современной разработки. что же касается бд прода -- то, наверное, тогда уж managed (опять же в воспроизводимой среде).
документация "сверху" (как хотят) -- в конфлюенсах и вордах, а документация "снизу" (как есть) -- в репах и маркдаун. пока так практикуем.. вроде норм.
PS: только plantUml сильно серьезно, в итоге оказалось, зато mermaid выручает быстро накидать схему, что происходит, какие-небудь sequence diagram и т.п.
не в докере?!!!) ну тогда все понятно.
ну и главное... мимикрировать под кого? под конкурентов, про которые уже достроверно известно об их тесном сотрудничестве с анб?) смешно. ни вотсапу ни сигналу доверия просто ноль. а вот телеграму -- больше ноля)
все так говорят ("избыточное доверие"), но подумайте, я вот прикинул -- ни разу не использовал защищенные чаты, однако выбираю телеграм за удобство и скорость/отзывчивость. мне кажется, большинство тоже.
аналогично, -- я хотел довольно сложную функцию на генераторах или итераторах в функциональном стиле, и с серией прототипов и уточняющих правок с моей стороны, все получилось, пожалуй, быстрее у нас вместе, чем если бы я писал "руками" самостоятельно.
это не может не работать).. если включить отбор)
ну, в смысле, строгая матмодель с эвристиками и формулами, по идее внутренней картины мира не имеет, точнее эта картина просто внешняя -- в голове автора(ов) матмодели. )
а любая нейросеть, да.. очередное подтверждение принципиального сходства с биологическими нс.
любого на основе статистики)
в смысле, везде там, где происходит отжиг, сжатие, оптимизация полной статистики в ее компактную форму.
т.е. вывод -- выучивают. но, вроде бы, не только трансформеры!? разве для эффективно обученных сетей с другой архитектурой нельзя найти "срез", где будет видно выученное пространство состояний? вангую, что можно. в любой глубокой сети оно должно быть размазано по промежуточным слоям, но если есть свертки -- то в свертках (окнах фильтров) где-то должно просматриваться.. интуитивно кажется так.
Ну не знаю, не знаю.. ) Например, по моему опыту:
* поиск PostGIS в Postgres по колонке типа мультиполигон с spatial-индексом, в итоге, прилично обгоняет поиск Elastic-а по geojson. У нас было ~80 млн полигонов, и в итоге даже до включения векторного кэширования мы отзывчиво выбирали окно и обновляли карту с сотнями/тысячами полигонов в поле видимости.
* по часовой/против часовой -- довольно часто встречающаяся ошибки в данных -- некоторые полигоны (или их "дырки") от поставщиков неизбежно будут "битыми", "не в ту сторону" -- и это нужно все равно валидировать и конвертировать при индексации. оставить "на ответственности" поставщиков -- значит потерять контроль над качеством данных
* в том же самом PostGIS из-коробки готовые высоко-оптимизированные реализации ST_simplify с тем же дугласом с пекером, (которые вы никогда не обгоните другими реализациями) и еще гора механизмов для развития гео-функционала в будущем, и использовать его было легко -- поэтому мы насколько помню симплифицировали "на лету", не теряя и не обрезая никаких данных (это грех, вообще)))
* "такой контракт есть, он называется GeoJSON" -- смысл его в том, чтобы делиться данными, передавать их между системами. Это не формат для хранения или даже передачи во внутреннем апи на фронт, если речь о большой ГИС. Имхо.
* стиль отображения? это же мусор. это пусть решается на фронтенде. зачем хранить/передавать это рядом с геоданными?)) плоские структуры всегда быстрее вложенных в глубину структурированных данных. разве нам не нужен перфоманс здесь?
и т.п... В общем, по моему мнению, это решение стратегически тупиковое.
ну, формат тут "невиновник"
Да, это понятно. Для меня JS не профильный язык, мне, скорее всего, не нужно будет это делать (разве что для пет-проектов).
Но само взвешивание -- "насколько это будет оправдано?", уже итак выглядит не очевидно..) Если я, проектируя апи, буду просить фронтенд-команду изменять все это поведение с десериализацией в проекте допустим с axios.. не знаю насколько это будет затратно. Скорее всего, как и в прошлый раз, мне скажут "давай строкой передавать, по-простому". И пока что, мне кажется, что будут правы.
О, спасибо, интересный вариант! Не находил его.
Как я понял, предложение "висит", но там приведен пример workaround с использованием параметра reviver при вызове
JSON.parse()/JSON.stringify()и там использоватьJSON.rawJSON()-- жаль, только что вот он пока экспериментальный и таблица совместимости не слишком радует... но в хроме есть, уже хорошо.но, конечно, нам срочно нужна мультимодальная opensource модель!.. потому что, грустно и бесперспективно теперь возиться с отдельными моделями, когда есть gpt-4o...)
скорее наоборот -- все остальные модальности обрабатываются "как язык". ведь именно трансформерная архитектура (родом из языковых моделей) -- дала возможность творить чудеса и с изображениями. как я понял, научились работать с механизмом внимания -- и вуаля. сначала применили на других модальностях, а теперь стала возможна и полная мультимодальность.
пишут, что нет.. как раз, в gpt-4o -- модель работает с модальностью звука -- а, значит, отображается в латентное пространство напрямую, и может улавливать интонации и прочие подобные вещи (так заявлено).
это необходимо и достаточно.