По первой части повторюсь: давно подсуетились и сделали всё что надо ещё с Мохави и первого анонса нового сервиса нотаризации. Как пользователь я только за такие меры, если мне надо запустить неподписанный софт, но я точно знаю и доверяю разработчику, то ПКМ+Открыть, и нет проблем.
В своей практике давно уже не использую 32 битный софт ни на одной из платформ, на работе и заказчикам как-то «плавно». Да и совместимость на уровне исходных кодов никто не отменял.
— 64 битам — уже «сто лет в обед»
— Приложения под Мак: распространяй в магазине — Xcode сделает почти всё сама, распространяй через свой сайт — Apple Notarization — просто автоматизировать либо же в build pipeline встроить, привет Гейткиперу
— Приложения под Windows: подпиши приложение — спи спокойно, привет Смартскрину
— Инсталляционные пакеты собрать под macOS, Windows, Linux давно не проблема
Нативные приложения под macOS и Windows плюс кроссплатформенный UI без проблем распространяются, также нет особых проблем и с Linux.
Вполне за вменямые сроки можно эти шаги и самому автоматизировать либо же в гугле есть рецепты.
Конкретно по macOS Catalina — подсуетились ещё во времена первых бета версий, сейчас уже всё работает как часы и всё отлично с Apple Notary Service.
По поводу США и Европы из P.S., может это связано и совпало с кругами вашего общения и интересов. Нельзя сказать, что я живу в Европе или США, но своих кругах вопросы из статьи тоже поднимаются.
В курсах философии, прикладной математики, геометрии, честно говоря, такого ниразу не встречал. Вроде бы все слова и их смыслы знакомы, но такая комбинация воспринимается как нечто новое. Вероятно, это новые веяния в определениях.
В целом, подход хороший, как и любой инструмент следует применять в нужном месте в нужный час.
В частности, есть мнение, что существуют более классические названия, употребления и определения.
Метод половинного деления.
Метод деления отрезка пополам.
Метод бисекции.
В какой-то мере можно также использовать название: метод дихотомии.
По теме также: двоичный (бинарный) поиск.
Хм, Гугл подсказывает, что ещё есть «бисекционный поиск».
P.S.: На форумах Microsoft было обсуждение по поводу работы этой функции.
Причина такого «нововведения», вкратце: не правильно использовали — запретить.
Да, если значения только «да, нет» («вкл, выкл»), то обычно происходит упаковка в флаги, т.е. как по ссылке выше. Это стандартная практика.
Упаковка нескольких значений в тип достачного размера, тоже очень полезная вещь.
Относительно спецификации. Вопрос об включении подобных оптимизаций был, но решили отказаться, так как появляются вопросы, где надо принимать компромиссное решение (скорость или размер). В таких случаях разработчик/пользователь лучше знает или должен знать, что он делает.
Если необходимо хранить по сути табличные данные, то проще CSV использовать. Если данные фиксированных длины или типа, то можно и разделитель не использовать.
В разделе «Почему?» описаны основные поводы. Картинка хорошая. В данном случае есть вполне определённые цели.
Если результаты кому-то пригодятся, будем только рады. А там и реализации появятся ;)
Напишите, как можно подробнее, о своей реализации, возникших вопросах или пожеланиях Riyad Kalla по одному из его контактов. Любая информация будет полезной.
Набор тестов, насколько мне известно, в разработке.
Уменьшение размера данных — побочный положительный эффект.
Непосредственное манипулирование памятью довольно опасная штука.
Задачи, платформы, языки могут иметь разнообразнейшее внутреннее представление подобных внешне вещей. При обмене данными между системами одной платформы освещаемые вопросы обычно не стоят.
С чего это всё началось, насколько мне известно, есть вот ссылка. Предыстория всего мне не известна.
Лично для себя использование UBJSON было хорошим решением для внутреннего проекта. То, что бинарный формат, не смущало. В HEX виде всё довольно прилично смотрится.
Частные случаи мне известны. Они обычно очень специфические и узконаправленные. Тут надо смотреть и разбираться индивидуально.
Основные цели: соответствие JSON, совместимость, ускорение работы с данными на уровне спецификации. Ускорее на разных платформах, естественно будет зависить от реализации и «своих» доработках.
С тестами дела, как всегда, интереснее. Желательно знать конфигурацию аппаратной и программной частей, и саму структуру. С очень оптимизированнным кодом относительно стабильным результатом было ~6200 нс/оп или 161290 оп/с на С# и .NET 4.5 без каких либо манимпуляций с аппаратной частью. Структура бралась с jvm тестов. И всёравно возникали вопросы. Обычное количество операций для тестов бралось в 1000000.
В своей практике давно уже не использую 32 битный софт ни на одной из платформ, на работе и заказчикам как-то «плавно». Да и совместимость на уровне исходных кодов никто не отменял.
— Приложения под Мак: распространяй в магазине — Xcode сделает почти всё сама, распространяй через свой сайт — Apple Notarization — просто автоматизировать либо же в build pipeline встроить, привет Гейткиперу
— Приложения под Windows: подпиши приложение — спи спокойно, привет Смартскрину
— Инсталляционные пакеты собрать под macOS, Windows, Linux давно не проблема
Нативные приложения под macOS и Windows плюс кроссплатформенный UI без проблем распространяются, также нет особых проблем и с Linux.
Вполне за вменямые сроки можно эти шаги и самому автоматизировать либо же в гугле есть рецепты.
Конкретно по macOS Catalina — подсуетились ещё во времена первых бета версий, сейчас уже всё работает как часы и всё отлично с Apple Notary Service.
В чём суть, простите, истерики — не понятно.
Кстати, Swift on Linux неплохо заходит.
В частности, есть мнение, что существуют более классические названия, употребления и определения.
Метод половинного деления.
Метод деления отрезка пополам.
Метод бисекции.
В какой-то мере можно также использовать название: метод дихотомии.
По теме также: двоичный (бинарный) поиск.
Хм, Гугл подсказывает, что ещё есть «бисекционный поиск».
P.S.: На форумах Microsoft было обсуждение по поводу работы этой функции.
Причина такого «нововведения», вкратце: не правильно использовали — запретить.
Упаковка нескольких значений в тип достачного размера, тоже очень полезная вещь.
Относительно спецификации. Вопрос об включении подобных оптимизаций был, но решили отказаться, так как появляются вопросы, где надо принимать компромиссное решение (скорость или размер). В таких случаях разработчик/пользователь лучше знает или должен знать, что он делает.
Если результаты кому-то пригодятся, будем только рады. А там и реализации появятся ;)
Набор тестов, насколько мне известно, в разработке.
То, что бралось для предварительных тестов, можно найти здесь.
Непосредственное манипулирование памятью довольно опасная штука.
Задачи, платформы, языки могут иметь разнообразнейшее внутреннее представление подобных внешне вещей. При обмене данными между системами одной платформы освещаемые вопросы обычно не стоят.
Лично для себя использование UBJSON было хорошим решением для внутреннего проекта. То, что бинарный формат, не смущало. В HEX виде всё довольно прилично смотрится.
Частные случаи мне известны. Они обычно очень специфические и узконаправленные. Тут надо смотреть и разбираться индивидуально.
Основные цели: соответствие JSON, совместимость, ускорение работы с данными на уровне спецификации. Ускорее на разных платформах, естественно будет зависить от реализации и «своих» доработках.