Pull to refresh
3
Karma
0
Rating

Простите, пользователи macOS, но Apple зашла слишком далеко

По первой части повторюсь: давно подсуетились и сделали всё что надо ещё с Мохави и первого анонса нового сервиса нотаризации. Как пользователь я только за такие меры, если мне надо запустить неподписанный софт, но я точно знаю и доверяю разработчику, то ПКМ+Открыть, и нет проблем.

В своей практике давно уже не использую 32 битный софт ни на одной из платформ, на работе и заказчикам как-то «плавно». Да и совместимость на уровне исходных кодов никто не отменял.

Простите, пользователи macOS, но Apple зашла слишком далеко

— 64 битам — уже «сто лет в обед»
— Приложения под Мак: распространяй в магазине — Xcode сделает почти всё сама, распространяй через свой сайт — Apple Notarization — просто автоматизировать либо же в build pipeline встроить, привет Гейткиперу
— Приложения под Windows: подпиши приложение — спи спокойно, привет Смартскрину
— Инсталляционные пакеты собрать под macOS, Windows, Linux давно не проблема

Нативные приложения под macOS и Windows плюс кроссплатформенный UI без проблем распространяются, также нет особых проблем и с Linux.

Вполне за вменямые сроки можно эти шаги и самому автоматизировать либо же в гугле есть рецепты.

Конкретно по macOS Catalina — подсуетились ещё во времена первых бета версий, сейчас уже всё работает как часы и всё отлично с Apple Notary Service.

В чём суть, простите, истерики — не понятно.

Кстати, Swift on Linux неплохо заходит.

Эдуард Медведев, CTO в Tungsten Labs: «Мы доросли до момента, когда технологии могут причинить массовый вред»

По поводу США и Европы из P.S., может это связано и совпало с кругами вашего общения и интересов. Нельзя сказать, что я живу в Европе или США, но своих кругах вопросы из статьи тоже поднимаются.

Эдуард Медведев, CTO в Tungsten Labs: «Мы доросли до момента, когда технологии могут причинить массовый вред»

Да, поднимаемые в статье вопросы относятся не только к разработчикам и ИТ-специалистам.

Метод бисекционного деления в тестировании

Метод золотого сечения — это по части макс. и мин. значений функции.

Метод бисекционного деления в тестировании

В курсах философии, прикладной математики, геометрии, честно говоря, такого ниразу не встречал. Вроде бы все слова и их смыслы знакомы, но такая комбинация воспринимается как нечто новое. Вероятно, это новые веяния в определениях.

Метод бисекционного деления в тестировании

В целом, подход хороший, как и любой инструмент следует применять в нужном месте в нужный час.

В частности, есть мнение, что существуют более классические названия, употребления и определения.

Метод половинного деления.
Метод деления отрезка пополам.
Метод бисекции.
В какой-то мере можно также использовать название: метод дихотомии.
По теме также: двоичный (бинарный) поиск.

Хм, Гугл подсказывает, что ещё есть «бисекционный поиск».

Как узнать реальную версию Windows из режима совместимости

Немного Си и половинного деления тут.

P.S.: На форумах Microsoft было обсуждение по поводу работы этой функции.
Причина такого «нововведения», вкратце: не правильно использовали — запретить.

Universal Binary JSON — ещё один бинарный JSON

Да, если значения только «да, нет» («вкл, выкл»), то обычно происходит упаковка в флаги, т.е. как по ссылке выше. Это стандартная практика.
Упаковка нескольких значений в тип достачного размера, тоже очень полезная вещь.

Относительно спецификации. Вопрос об включении подобных оптимизаций был, но решили отказаться, так как появляются вопросы, где надо принимать компромиссное решение (скорость или размер). В таких случаях разработчик/пользователь лучше знает или должен знать, что он делает.

Universal Binary JSON — ещё один бинарный JSON

Если необходимо хранить по сути табличные данные, то проще CSV использовать. Если данные фиксированных длины или типа, то можно и разделитель не использовать.

Universal Binary JSON — ещё один бинарный JSON

В разделе «Почему?» описаны основные поводы. Картинка хорошая. В данном случае есть вполне определённые цели.
Если результаты кому-то пригодятся, будем только рады. А там и реализации появятся ;)

Universal Binary JSON — ещё один бинарный JSON

Напишите, как можно подробнее, о своей реализации, возникших вопросах или пожеланиях Riyad Kalla по одному из его контактов. Любая информация будет полезной.
Набор тестов, насколько мне известно, в разработке.

Universal Binary JSON — ещё один бинарный JSON

Для более подрбной информации об условиях и относительной адекватности в результате.
То, что бралось для предварительных тестов, можно найти здесь.

Universal Binary JSON — ещё один бинарный JSON

Тут какое дело. Спецификация находится в статусе активной разработки. Всем, у кого есть время и желание поучаствовать, будем только рады.

Universal Binary JSON — ещё один бинарный JSON

Парсер выше съел поле data.

Universal Binary JSON — ещё один бинарный JSON

Конкретно по этой строке не было необходимости, не возникало как-то вопросов.

Universal Binary JSON — ещё один бинарный JSON

Вот это <type, 1-byte char>[<length, 1 or 4-byte integer>][] верный вариант.

Universal Binary JSON — ещё один бинарный JSON

Уменьшение размера данных — побочный положительный эффект.
Непосредственное манипулирование памятью довольно опасная штука.
Задачи, платформы, языки могут иметь разнообразнейшее внутреннее представление подобных внешне вещей. При обмене данными между системами одной платформы освещаемые вопросы обычно не стоят.

Universal Binary JSON — ещё один бинарный JSON

С чего это всё началось, насколько мне известно, есть вот ссылка. Предыстория всего мне не известна.
Лично для себя использование UBJSON было хорошим решением для внутреннего проекта. То, что бинарный формат, не смущало. В HEX виде всё довольно прилично смотрится.
Частные случаи мне известны. Они обычно очень специфические и узконаправленные. Тут надо смотреть и разбираться индивидуально.
Основные цели: соответствие JSON, совместимость, ускорение работы с данными на уровне спецификации. Ускорее на разных платформах, естественно будет зависить от реализации и «своих» доработках.

Universal Binary JSON — ещё один бинарный JSON

С тестами дела, как всегда, интереснее. Желательно знать конфигурацию аппаратной и программной частей, и саму структуру. С очень оптимизированнным кодом относительно стабильным результатом было ~6200 нс/оп или 161290 оп/с на С# и .NET 4.5 без каких либо манимпуляций с аппаратной частью. Структура бралась с jvm тестов. И всёравно возникали вопросы. Обычное количество операций для тестов бралось в 1000000.
1

Information

Rating
Does not participate
Registered
Activity