Прочитал статью, увидел Тинькофф в качестве клиента, взял первую попавшуюся карту и и приложение Тинькова. Спустя 3 минуты мне надоедло прыгать с камерой. И рамка на месте. Так что, похоже, реклама разбилась о суровую действительность.
Он по-другому работает. Таска сама проверяет, что её попросили сдохнуть и делает всё для этого, а это насильное убийство. Нужно обычно как средство последнего шанса, но бывают ситуации, когда очень нужно.
При компиляции ворнинг будет, но изначально вопрос был в том — что просто поставили новый фреймворк и взяли старый код. Тут, похоже, будет очень неприятно.
Похоже, всё-таки не всё будет гладко.
Вот сейчас выяснил, что сломали Thread.Abort
Т.е. код начнёт эпично валиться в непредсказуемых местах. И вот сколько таких мест может быть?
Это я понимаю, но вопросы были в следующем:
1. Будет ли прирост производительности просто от подсовывания нового рантайма
2. Не вылезут ли проблемы из-за того, что совместимость именно что декларируется. Т.е. могут взять метод и убрать у него реализацию (типа у нас новые правила) или изменить реализацию, что приведёт к косякам. А то у нас был весёлый пример с использованием рантайма 2.2 при разработке на 2.1. Несколько недель поиска проблемы.
А что будет, если таргет будет старый (netstandard2.0, например), а рантайм новый? Плюшки по производительности будут? Или всё-таки IL-код оптимизируется ещё новым тулчейном?
Ну или совсем гулять — новым тулчейном компилять под netstandard2.0 и запускать на новом рантайме.
На всякий случай, отвечу на вопрос зачем: если не надо новых фич, то в целом повышать версию выглядит бессмысленно, бывает легаси и прочие замороженные проекты, которые нет смысла переводить на новый фреймворк, а зависимости свежие использовать хочется.
С учётом того, что шкала децибелл уже логарифмическая, добавлять к этому ещё нелинейные палки — это уже какая-то вторая производная. :)
Но палки да, рисуют от балды все.
Иногда бывает относительно абстрактный маппинг, иногда бывают языки со слабой типизацией. И после таких утверждений, что нет разницы, true или «true» люди с фамилией Null или номерным знаком NULL начинают испытывать проблемы. А щас погуглил, есть ещё люди с фамилией True :)
С проблемами типов при сериализации я встречался в JS, Python, .NET, когда умный парсер подставляет самый подходящий тип, а потом начинает ломаться. В .NET был, кстати, самый забавный случай, когда он строку, похожую на дату считал датой и портил её. И это функционал по умолчанию.
Не все и не всегда делают маппинг json/xml => объект. Бывают абстрактные десериализации, в абстрактный объект, бывает миграция версий, особенно для конфигов, когда хочется оставить поддержку старой версии. И всё может замечательно стрелять.
Можно придумать такой пример (стырил из nginx):
мы пишем прокси, и у нас в конфиге есть параметр proxy_redirect, который может принимать значения: true — делать редирект, переписывая хост автоматически. Нужно большинству пользователей. false — не делать, или строка, которая говорит, на какой хост редиректить. Мы не различаем false и «false» и всё работает до тех пор, когда у кого-то не оказался хост с названием false. Может даже как-то заработает, но могут появиться спец.эффекты.
Решение: две настройки, или воспользоваться типизацией.
Важно. Мне это в JSON тоже очень не нравится. Раньше была идея писать /Date(timestamp)/ — но тоже костыль и не прижилось.
Вообще сериализация и десериализация подразумевает сохранение значений в текстовой или бинарной форме. Любое примитивное значение так или иначе мепится в строку.
Вот вообще не так для бинарной формы. Посмотрите хоть на Message Pack.
То, что вам в JS оставили boolean и еще пару примитивных типов, и на базе которых склепали JSON, совсем не значит, что в нормальных ЯП нет других примитивных (и кастомных) типов, которые тоже надо как-то мэппить.
Есть другие типы, да. Но практически во всех языках есть понятия числа/строки/массива/словаря и это разумная и понятная база.
Отличие true от «true» — это очень важно. Также как и отличия «0042» от 0042.
1. отсутствие тега — это undefined, null — это явное указание. И да, это вполне может использоваться. Маркать элемент атрибутом о том, что он null — это костыль на мой взгляд.
2. тем, что это соглашение для строки.
3. Один элемент — это массив из одного элемента или просто строка? Отсутствие элементов — это null или пустой массив? Или будем заворачивать в ещё один элемент? Тогда как называть внутренности?
4. Тут в JSON примерно так же
5. А я считаю, что вполне могут быть
Зависимость от форматирования — как раз проблема XML, в JSON её нет, в зависимости от парсера, он может сохранить их или убрать, CDATA в целом ничего не добавляет. Т.е. уже грабли на ровном месте, в зависимости от того, что нам надо, и как нам прислали документ.
Так да, JSON Schema == XSD, если хотите, то можете использовать. Но разница в другом.
Давайте приведу аналогию, вы открываете сайт, и там есть текстовое поле с описанием «Я прочитал лицензионное соглашение». Вы догадаетесь что там надо ввести? Конечно, если вы не угадаете, то будет ошибка: «Необходимо ввести в это поле значение True/False» и станет понятно. Но в приличном обществе используют чекбоксы.
Вот и с XML та же подстава, отсутствует всякая типизация. А проверяется только строка на соответствие шаблону. И какой шаблон будет в конкретном случае — известно только разработчику данного формата. Может он сделает True/False, а может true/false или yes/no, 1/0, или вообще зафигачить всё в атрибут. Как вариант, сделать вложенный элемент <True/>. Есть множество способов, какие-то более распространённные, какие-то редкие. Но чтобы выяснить, что используется в конкретном случае, надо читать схему или пробовать методом научного тыка.
Если серьёзно, то с XML я достаточно давно работаю, ещё с тех пор, как это было прорывом и кровавый энтерпрайз радостно залез на него. Я и читал многостраничные талмуды по форматам и сам писал, и делал сложные схемы, использовал xsd и xpath.
Но… каждый раз это всегда боль, одни и те же задачи все решают по-разному, реальные документы не бьются с документацией, схемы валятся (и у тебя выбор — это переписка на неделю с объяснением, что ты не верблюд, или подсовывание костыля).
XML это очень сложно, у него безумное количество фич, при этом он совершенно беспомощный в базовых вещах. Проблемы решаются валидацией по схеме, но не здравым смыслом. То, что на JSON очевидно — в XML должно быть специально описано, и в каждом, блин, случае обязательно будет по-разному.
Я имел в виду начальные и конечные пробелы, типа " слово ". Но ваше уточнение ещё интереснее, т.е. если в тексте попадается 2 пробела, его надо заворачивать в CDATA. Это, блин, реально уже страшный формат получается. Т.е. такие нюансы надо иметь в виду, чтобы случайно не сесть в лужу.
А какие стандартные соглашения для XML существуют:
1. null
2. true/false
3. массивы
4. даты
5. отличия строк от чисел
А то в лоб я могу придумать кучу способов, но какие правильные?
Ну и бонусом вопрос, в XML правильно игнорировать или ведущие пробелы или нет?
Конфиг файл с необходимостью корректного поддерживания отступов — это мегавин и отличный способ отстрелить себе ноги. Конфиги могут правится левой пяткой на сервере, могут генериться кодом или скриптами, мёржиться, открываться в виндовом блокноте (у которого только недавно починили \n), и когда лишний пробел ломает конфигурацию (причём обычно так, что настройка просто не читается, но сразу всё не падает) — это дарит замечательные часы отладки.
В общем, на мой взгляд один из самых ужасных форматов конфигурации, который почему-то всюду засовывают.
Обновление прошивок — это отличный совет, особенно в связи с тем, что обычно выносится всё содержимое диска (или хотя бы не гарантируется его сохранность). А иногда ещё не работает, если диск основной. Т.е. покупаем второй SSD, грузимся с него, перепрошиваем первый и восстанавливаемся из бекапа. Очень удобно.
Ну так у него весьма древняя технология (34nm) и MLC, а сейчас норовят везде QLC засунуть, у которого запас перезаписей в стиле — чего вы волнуетесь, вам хватит*
(* если вы его не очень часто доставать с полки будете).
При компиляции ворнинг будет, но изначально вопрос был в том — что просто поставили новый фреймворк и взяли старый код. Тут, похоже, будет очень неприятно.
Вот сейчас выяснил, что сломали Thread.Abort
Т.е. код начнёт эпично валиться в непредсказуемых местах. И вот сколько таких мест может быть?
1. Будет ли прирост производительности просто от подсовывания нового рантайма
2. Не вылезут ли проблемы из-за того, что совместимость именно что декларируется. Т.е. могут взять метод и убрать у него реализацию (типа у нас новые правила) или изменить реализацию, что приведёт к косякам. А то у нас был весёлый пример с использованием рантайма 2.2 при разработке на 2.1. Несколько недель поиска проблемы.
Ну или совсем гулять — новым тулчейном компилять под netstandard2.0 и запускать на новом рантайме.
На всякий случай, отвечу на вопрос зачем: если не надо новых фич, то в целом повышать версию выглядит бессмысленно, бывает легаси и прочие замороженные проекты, которые нет смысла переводить на новый фреймворк, а зависимости свежие использовать хочется.
Но палки да, рисуют от балды все.
С проблемами типов при сериализации я встречался в JS, Python, .NET, когда умный парсер подставляет самый подходящий тип, а потом начинает ломаться. В .NET был, кстати, самый забавный случай, когда он строку, похожую на дату считал датой и портил её. И это функционал по умолчанию.
Не все и не всегда делают маппинг json/xml => объект. Бывают абстрактные десериализации, в абстрактный объект, бывает миграция версий, особенно для конфигов, когда хочется оставить поддержку старой версии. И всё может замечательно стрелять.
Можно придумать такой пример (стырил из nginx):
мы пишем прокси, и у нас в конфиге есть параметр proxy_redirect, который может принимать значения: true — делать редирект, переписывая хост автоматически. Нужно большинству пользователей. false — не делать, или строка, которая говорит, на какой хост редиректить. Мы не различаем false и «false» и всё работает до тех пор, когда у кого-то не оказался хост с названием false. Может даже как-то заработает, но могут появиться спец.эффекты.
Решение: две настройки, или воспользоваться типизацией.
Важно. Мне это в JSON тоже очень не нравится. Раньше была идея писать /Date(timestamp)/ — но тоже костыль и не прижилось.
Вот вообще не так для бинарной формы. Посмотрите хоть на Message Pack.
Есть другие типы, да. Но практически во всех языках есть понятия числа/строки/массива/словаря и это разумная и понятная база.
1. отсутствие тега — это undefined, null — это явное указание. И да, это вполне может использоваться. Маркать элемент атрибутом о том, что он null — это костыль на мой взгляд.
2. тем, что это соглашение для строки.
3. Один элемент — это массив из одного элемента или просто строка? Отсутствие элементов — это null или пустой массив? Или будем заворачивать в ещё один элемент? Тогда как называть внутренности?
4. Тут в JSON примерно так же
5. А я считаю, что вполне могут быть
Зависимость от форматирования — как раз проблема XML, в JSON её нет, в зависимости от парсера, он может сохранить их или убрать, CDATA в целом ничего не добавляет. Т.е. уже грабли на ровном месте, в зависимости от того, что нам надо, и как нам прислали документ.
Давайте приведу аналогию, вы открываете сайт, и там есть текстовое поле с описанием «Я прочитал лицензионное соглашение». Вы догадаетесь что там надо ввести? Конечно, если вы не угадаете, то будет ошибка: «Необходимо ввести в это поле значение True/False» и станет понятно. Но в приличном обществе используют чекбоксы.
Вот и с XML та же подстава, отсутствует всякая типизация. А проверяется только строка на соответствие шаблону. И какой шаблон будет в конкретном случае — известно только разработчику данного формата. Может он сделает True/False, а может true/false или yes/no, 1/0, или вообще зафигачить всё в атрибут. Как вариант, сделать вложенный элемент <True/>. Есть множество способов, какие-то более распространённные, какие-то редкие. Но чтобы выяснить, что используется в конкретном случае, надо читать схему или пробовать методом научного тыка.
Если серьёзно, то с XML я достаточно давно работаю, ещё с тех пор, как это было прорывом и кровавый энтерпрайз радостно залез на него. Я и читал многостраничные талмуды по форматам и сам писал, и делал сложные схемы, использовал xsd и xpath.
Но… каждый раз это всегда боль, одни и те же задачи все решают по-разному, реальные документы не бьются с документацией, схемы валятся (и у тебя выбор — это переписка на неделю с объяснением, что ты не верблюд, или подсовывание костыля).
XML это очень сложно, у него безумное количество фич, при этом он совершенно беспомощный в базовых вещах. Проблемы решаются валидацией по схеме, но не здравым смыслом. То, что на JSON очевидно — в XML должно быть специально описано, и в каждом, блин, случае обязательно будет по-разному.
1. null
2. true/false
3. массивы
4. даты
5. отличия строк от чисел
А то в лоб я могу придумать кучу способов, но какие правильные?
Ну и бонусом вопрос, в XML правильно игнорировать или ведущие пробелы или нет?
В общем, на мой взгляд один из самых ужасных форматов конфигурации, который почему-то всюду засовывают.
(* если вы его не очень часто доставать с полки будете).