Для человеко-читаемого формата мне очень понравился toml. Но, Я всё-таки, понял, что речь идёт больше про API. И про накладные расходы на лишний синтаксис. В этом отношении msgpack лучше. И в целом, читаемый. Я вот более-менее бегло могу читать формат миди-файлов, хотя он тоже вполне так себе бинарный, да ещё и последовательный.
P.S. но вообще JSON хорош тем, что он простой как палка, и даже если ты никогда не видел JSON - ты всё равно его понимаешь.
Для того, чтобы читать а тем более, писать XML, cml, yaml, toml - надо хоть немного разобраться. А лучше иметь под рукой шпаргалку
Я думаю, здесь как с дисками в RAID1: пока они оба работают - вероятность отказа ниже 50%, но как падает 1 - вероятность того, что посыпится второй повышается.
Да все. (кроме, может, FB, не смотрел). Трон ещё куда ни шло, но, блин, попаданство в игры, вроде трона и лощины — это тоже скорее сеттинг, чем смысл.
Пытался сейчас вспомнить хоть что-то более-менее осмысляющее IT-шников и IT... Что-то в голову не приходит. Есть неплохой ситком IT-Guys (компьютерщики), но там предметки ещё меньше, чем физики в Big Bang Theory.
И ещё интересен образ Хардисона из Leverage (Воздействие). Там и психологический потрет очень точный, и подход к жизни, и даже «гикнутость». В одной из серий он для легенды компании рисует портрет «отца-основателя» маслом. Фишка в том, что этот портрет нарисовал актёр, который играл персонажа.
Ну и хвалили ещё силиконовую долину. Но я так и не посмотрел
Ой... Решил с телефона прикрепить картинку. Скриншот залил на habrastorage, вставил в MD. На телефоне всё выглядело ожидаемо. На десктопе — блямба в 2,5 экрана высотой((
Для меня самый главный недостаток приложения, который не позволяет им пользоваться от слова совсем - нет вкладок.
И это совсем не соответствует моей истории взаимодействия с Хабром. Проще говоря: у меня уже есть эксклюзивное приложение для Хабра - это Firefox. 90% использования браузера - это Хабр.
В минуту жизни трудную захожу на сайт, листаю насколько страниц главной и открываю все, что интересно. И потом читаю, пока статьи не закончатся.
Одностраничное приложение очень далеко от этого.
А ещё по той же причине я в свое время плевался от динамической загрузки. Особенно, динамической загрузки статей. Потому что, в 16-18 годах в метро на станции можно было загрузить статью и читать её в туннеле. А теперь нельзя: картинок не будет, текст - тоже не факт. Комментарии - нет.
Проблема решилась внезапно тем, что в метро всё завесили Z, понаставили рамок и пользоваться им стало невозможно.
Спасибо! Мне кажется, тенденции несколько более сложные, чем «уход старой гвардии».
Клавишные рабочие станции и AKAI-библиотеки, возможно, последний луч уходящего блеска диско 70-80-х: такого дрековского синтеза и сэмплинга, что он стал самобытной звуковой культурой. И дальнейшее развитие этих инструментов (и инструментов в более широком смысле — DAW, контроллеров и т.п.) ушло в элетронные\hip-hop стили.
А вот что касается, скажем так, акустического спектра: от Pop до академической музыки — то это стало историей про малый бюджет. Писать живых дорого, особенно, когда речь идёт о трейлерах и сериалах с их чисто функциональными паттернами, которые мало интересны музыкантам.
И, в общем и целом, индустрия воспроизводства звуков доросла до того состояния, в котором она нужна видео-индустрии. В июне я, допустим, играл оркестр для, скажем так, невысоко-бюджетного кино. Есть определённые дыры в нестандартных составах. Хотелось бы чуть более внятных соло-инструментов, но качество для сериалов — ОК.
Дальше, да, будет развитие в сторону автоматической композиции. В этом есть смысл:
как на масштабе «загрузить серию сериала в нейросеть, чтобы выдало MIDI», потом загрузить результат MIDI в другую нейросеть, чтобы она сыграла как надо на VSTi.
и как подспорье для живых композиторов. Сейчас есть целые студии «ноу-неймов», которые добивают до хронометража труды основного композитора. То есть, есть техническая работа по переработке материала, которую на себя может взять софт. А можно и как «рандомный генератор» использовать)
Вижу в этом только плюсы: малобюджетные проекты получают относительно годный саунд. Профессиональные музыканты не страдают х****й на бесконечных халтурах, которые часто берёшь под натиском «ну к кому мне ещё обратиться?». Плохо только начинающим композиторам, которым меньше малобюджетных проектов, на которых можно расписаться. Но проблема образования решаема)
А «программисты секвенсора» уже вполне так есть. Думаю, те артисты, которые играют в Digital сегменте с Waves SoundGrid держат программиста) Мой украинский коллега Саша Олейник для группы сына написал особый конфиг для Reaper, а потом скооперировался с системщиком, и они сделали TCP\IP аудио-интерфейс.
А вот живые музыканты и композиторы никуда не денутся, но это — тема для отдельнкой статьи, и, думаю, не на хабр)
Он нужен, как минимум, в первый раз, чтобы ввести параметризацию по этому параметру. Т.к. у нас нет никакого реального объекта, который принимал бы для конструирования ProbablyMutable — rust будет ругаться, что мы требуем обозначения этого параметра для структуры.
Потом PhatnomData тоже может пригодиться, если захочется более гибко обходиться с мутабельностью детей. Но я пока что заметил, что потом API получается лучше без дополнительных сущностей.
Зато столкнулся с ситуацией, когда пришлось брать на вход два иммутабельных объекта, и внутри для создания мутабельного коннектора между ними, кастовать родителя через mem::transmute. Грязноватый, небезопасный хак. Но, т.к. эти «пины» не мог изменять, никто, кроме коннектора — я решил, что это достаточно безопасно.
Я, когда для себя переводил «assotiated functions» и «assotiated types» решил, что, раз ассоциированные функции всё равно в 90% случаев легче называть методами (а в остальных 10%, хоть и не очень корректно — статическими методами). То и assotiated types, скорее всего всё-таки завтипы. Т.к. ассоциированные типы на русском я впервые читаю в вашем комментарии.
Раз уж вы здесь — расскажите, пожалуйста, чем завтипы отличаются от ассоциированных?
Я ради предсказуемой раскладки переехал на Linux)
https://stackoverflow.com/questions/72240945/can-not-use-keyboard-3rd-level-on-manjaro
Для человеко-читаемого формата мне очень понравился toml. Но, Я всё-таки, понял, что речь идёт больше про API. И про накладные расходы на лишний синтаксис. В этом отношении msgpack лучше.
И в целом, читаемый. Я вот более-менее бегло могу читать формат миди-файлов, хотя он тоже вполне так себе бинарный, да ещё и последовательный.
P.S. но вообще JSON хорош тем, что он простой как палка, и даже если ты никогда не видел JSON - ты всё равно его понимаешь.
Для того, чтобы читать а тем более, писать XML, cml, yaml, toml - надо хоть немного разобраться. А лучше иметь под рукой шпаргалку
https://msgpack.org/
Я думаю, здесь как с дисками в RAID1: пока они оба работают - вероятность отказа ниже 50%, но как падает 1 - вероятность того, что посыпится второй повышается.
Всё-таки, картиночки, шрифты и т.п. нужны: https://thebestmotherfucking.website/
Видимо, отредактировали, но не до конца))) Так — лучше, чем с картинкой, согласен
Ну, выглядит, как рабочий день на прототип + тестирование-доводка в рамках спринта.
статья — ещё часа 4.
Я думаю, что это отличный способ уйти от рабочей рутины на денёк, приятный и для программиста, и для пользователей, и для компании.
Да все. (кроме, может, FB, не смотрел).
Трон ещё куда ни шло, но, блин, попаданство в игры, вроде трона и лощины — это тоже скорее сеттинг, чем смысл.
Пытался сейчас вспомнить хоть что-то более-менее осмысляющее IT-шников и IT... Что-то в голову не приходит. Есть неплохой ситком IT-Guys (компьютерщики), но там предметки ещё меньше, чем физики в Big Bang Theory.
И ещё интересен образ Хардисона из Leverage (Воздействие). Там и психологический потрет очень точный, и подход к жизни, и даже «гикнутость». В одной из серий он для легенды компании рисует портрет «отца-основателя» маслом. Фишка в том, что этот портрет нарисовал актёр, который играл персонажа.
Ну и хвалили ещё силиконовую долину. Но я так и не посмотрел
Ой... Решил с телефона прикрепить картинку. Скриншот залил на habrastorage, вставил в MD. На телефоне всё выглядело ожидаемо. На десктопе — блямба в 2,5 экрана высотой((
Может, ограничивать картинки в комментах 100%?
Как много общего у фмш и ссмш)
Для меня самый главный недостаток приложения, который не позволяет им пользоваться от слова совсем - нет вкладок.
И это совсем не соответствует моей истории взаимодействия с Хабром. Проще говоря: у меня уже есть эксклюзивное приложение для Хабра - это Firefox. 90% использования браузера - это Хабр.
В минуту жизни трудную захожу на сайт, листаю насколько страниц главной и открываю все, что интересно. И потом читаю, пока статьи не закончатся.
Одностраничное приложение очень далеко от этого.
А ещё по той же причине я в свое время плевался от динамической загрузки. Особенно, динамической загрузки статей. Потому что, в 16-18 годах в метро на станции можно было загрузить статью и читать её в туннеле. А теперь нельзя: картинок не будет, текст - тоже не факт. Комментарии - нет.
Проблема решилась внезапно тем, что в метро всё завесили Z, понаставили рамок и пользоваться им стало невозможно.
Скрин
Добавил библиотеку для тестирования расширений, и написал в конец статьи пару слов о структуре интеграционных тестов.
Взаимно) Только я пианист ;)
Спасибо!
Мне кажется, тенденции несколько более сложные, чем «уход старой гвардии».
Клавишные рабочие станции и AKAI-библиотеки, возможно, последний луч уходящего блеска диско 70-80-х: такого дрековского синтеза и сэмплинга, что он стал самобытной звуковой культурой. И дальнейшее развитие этих инструментов (и инструментов в более широком смысле — DAW, контроллеров и т.п.) ушло в элетронные\hip-hop стили.
А вот что касается, скажем так, акустического спектра: от Pop до академической музыки — то это стало историей про малый бюджет. Писать живых дорого, особенно, когда речь идёт о трейлерах и сериалах с их чисто функциональными паттернами, которые мало интересны музыкантам.
И, в общем и целом, индустрия воспроизводства звуков доросла до того состояния, в котором она нужна видео-индустрии. В июне я, допустим, играл оркестр для, скажем так, невысоко-бюджетного кино. Есть определённые дыры в нестандартных составах. Хотелось бы чуть более внятных соло-инструментов, но качество для сериалов — ОК.
Дальше, да, будет развитие в сторону автоматической композиции. В этом есть смысл:
как на масштабе «загрузить серию сериала в нейросеть, чтобы выдало MIDI», потом загрузить результат MIDI в другую нейросеть, чтобы она сыграла как надо на VSTi.
и как подспорье для живых композиторов. Сейчас есть целые студии «ноу-неймов», которые добивают до хронометража труды основного композитора. То есть, есть техническая работа по переработке материала, которую на себя может взять софт. А можно и как «рандомный генератор» использовать)
Вижу в этом только плюсы: малобюджетные проекты получают относительно годный саунд. Профессиональные музыканты не страдают х****й на бесконечных халтурах, которые часто берёшь под натиском «ну к кому мне ещё обратиться?».
Плохо только начинающим композиторам, которым меньше малобюджетных проектов, на которых можно расписаться. Но проблема образования решаема)
А «программисты секвенсора» уже вполне так есть. Думаю, те артисты, которые играют в Digital сегменте с Waves SoundGrid держат программиста) Мой украинский коллега Саша Олейник для группы сына написал особый конфиг для Reaper, а потом скооперировался с системщиком, и они сделали TCP\IP аудио-интерфейс.
А вот живые музыканты и композиторы никуда не денутся, но это — тема для отдельнкой статьи, и, думаю, не на хабр)
Всё-таки, иногда phantom data нужен: если есть ограничение по трейту, а объекта нет.
Нужно прописать аннотацию вида
Вот так не скомпилируется. Для этого приходится добавлять
PhantomDataА. Может быть. Я не подумал, что можно просто аргумент в new() положить в структуру.
Он нужен, как минимум, в первый раз, чтобы ввести параметризацию по этому параметру. Т.к. у нас нет никакого реального объекта, который принимал бы для конструирования
ProbablyMutable— rust будет ругаться, что мы требуем обозначения этого параметра для структуры.Потом PhatnomData тоже может пригодиться, если захочется более гибко обходиться с мутабельностью детей. Но я пока что заметил, что потом API получается лучше без дополнительных сущностей.
Зато столкнулся с ситуацией, когда пришлось брать на вход два иммутабельных объекта, и внутри для создания мутабельного коннектора между ними, кастовать родителя через
mem::transmute. Грязноватый, небезопасный хак. Но, т.к. эти «пины» не мог изменять, никто, кроме коннектора — я решил, что это достаточно безопасно.Да, это следующее, что мне б хотелось научиться делать без паники...
Переименовал тред. Хотя, теперь мне меньше понятно, когда нужны зависимые типы. Особенно, если хочется побольше уверенности на этапе компиляции.
Хм. Пожалуй.
Я, когда для себя переводил «assotiated functions» и «assotiated types» решил, что, раз ассоциированные функции всё равно в 90% случаев легче называть методами (а в остальных 10%, хоть и не очень корректно — статическими методами).
То и assotiated types, скорее всего всё-таки завтипы. Т.к. ассоциированные типы на русском я впервые читаю в вашем комментарии.
Раз уж вы здесь — расскажите, пожалуйста, чем завтипы отличаются от ассоциированных?