C>>при этом не больше 24 символов
У>Используй GUID lowercase'ом без тире
Это 32 символа.

Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, m2l, Вы писали:

m2l>>mystorageaccount — Просто оно в DNS используется, отсюда и требования к регистронезависимости, ограничение на спец-символы, и т.д.

C>В DNS можно использовать дефис и точки.

Точка — в качестве разделителя, что сразу вываливается в обработку дочерних зон и более сложную логику работы кода, который будет это поддерживать.
Дефис, не может быть в начале или конце ( -dns.example или dns-.example недопустимо). Что вываливается в ещё более экзотичные запреты к такому имени.

Здравствуйте, m2l, Вы писали:

m2l>Точка — в качестве разделителя, что сразу вываливается в обработку дочерних зон и более сложную логику работы кода, который будет это поддерживать.

Главное, чтобы мартышки ни на минуту не напрягались.

m2l>Дефис, не может быть в начале или конце ( -dns.example или dns-.example недопустимо). Что вываливается в ещё более экзотичные запреты к такому имени.

В каком месте они более экзотичные? Ну нельзя дефис в начале или конце. Ну и черт с ним.

Здравствуйте, Codealot, Вы писали:

C>Главное, чтобы мартышки ни на минуту не напрягались.

Как будто это что-то ужасное. Расслабься, прикинь как можно сделать, что бы твои трудозатраты были минимальны — и всё будет ок.

C>В каком месте они более экзотичные? Ну нельзя дефис в начале или конце. Ну и черт с ним.

Ну смотри, ты же сам начал с:

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

Ругаясь на ограниченный набор символов. Я боюсь даже предположить, как бы ты ругался, если помимо ограниченного набора символов, некоторые ещё и не во всех позициях можно было бы использовать.

Здравствуйте, ononim, Вы писали:

C>>>при этом не больше 24 символов
У>>Используй GUID lowercase'ом без тире
O>Это 32 символа.

Да, протупил, 16 это в двоичном виде

Здравствуйте, m2l, Вы писали:

m2l>Ругаясь на ограниченный набор символов. Я боюсь даже предположить, как бы ты ругался, если помимо ограниченного набора символов, некоторые ещё и не во всех позициях можно было бы использовать.

Вот если бы нельзя было 'a' или 't' в 3-й и 10-й позиции — да, есть на что жаловаться.
А с дефисом какие проблемы?

Здравствуйте, m2l, Вы писали:

m2l>>>mystorageaccount — Просто оно в DNS используется, отсюда и требования к регистронезависимости, ограничение на спец-символы, и т.д.

N>>Ничто не мешало при этом разрешить '_' не первым не последним не два подряд и при конверсии в DNS имя заменять на '-'. Зато уже было бы резко больше удобства людям.

m2l>Архитектурно это нежелательно делать. Эта схема API — будет существовать много лет, и тут вылезают риски, что рано или поздно эта замена вылезет боком.

Есть несколько мест (например, ЖЖ), где делается много лет и ничего не вылезло.
Почему у MS должно вылезти? MS хуже тестирует, чем какой-то рамблер или кому сейчас ЖЖ принадлежит?

m2l> Например порядок проверки при регистрации исказят или в одном месте замены будут, в другом нет — проблемы с безопасностью и просто баги.

Вот честно — ты считаешь, что это настолько сложная фича, что программисты не справятся?

Ну ладно, пусть в имени акаунта будет '-' напрямую, а не '_'. Что тогда проблемного?

m2l> В добавок путаница у простых программистов — если ты знаком с DNS, то есть люди которые в этом не разбираются и будут потом ходить по форумам плодить темы, "а почему в консоли не выполняется мой запрос"?

Они по любому будут ходить, например, "почему я не могу зайти с акаунтом ABC1234? С каких это пор MS обращает внимания на регистр букв, у меня все имена в DNS должны писаться заглавными?"

m2l>Общий принцип — минимизация трансформации данных. Если можно, что бы одна сущность (то что ты вводишь) была везде одинаковой (вплоть до байта) — то желательно так и делать. Меньше кода, меньше потенциальных ошибок, меньше странных вопросов, а почему запрещено.

Тогда почему нельзя '-'?

Здравствуйте, netch80, Вы писали:

m2l>>Архитектурно это нежелательно делать. Эта схема API — будет существовать много лет, и тут вылезают риски, что рано или поздно эта замена вылезет боком.

N>Есть несколько мест (например, ЖЖ), где делается много лет и ничего не вылезло.
Никто не говорит, что так делать нельзя или невозможно. Я говорю, что при прочих равных усложнять код нет причин.

N>Почему у MS должно вылезти? MS хуже тестирует, чем какой-то рамблер или кому сейчас ЖЖ принадлежит?
Почему именно у MS? Это у кого угодно со временем может вылезти.

m2l>> Например порядок проверки при регистрации исказят или в одном месте замены будут, в другом нет — проблемы с безопасностью и просто баги.

N>Вот честно — ты считаешь, что это настолько сложная фича, что программисты не справятся?
Справятся. И всё будет работать.
Просто вот эта фича в одном месте, вот такая же в другом, вот справившиеся люди уволились и на их место пришли новые, вот они код решили порефакторить.... Подобные фичи не являются проблемой — они только увеличивают риск. А учитывая, что Azure всё-таки облако, с большин числом клиентов, обвесов и программистов, им желательна политика минимальных рисков.

Я вот даже с тобой бы был полностью согласен, если бы мы говорить, про какой-нибудь внутренний корпоративный софт. Где если ошибка и возникнет в итоге, ущерб от неё будет несоизмеримо меньше. Там оправданы все подобные фичи, максимально упрощающие работу конечного пользователя. В случае с Azure фокус упрощения работы, имхо, должен быть смещён именно в пользу программистов, как один из многих инструментов контроля сложности и уменьшения вероятности возникновения багов.

N>Они по любому будут ходить, например, "почему я не могу зайти с акаунтом ABC1234? С каких это пор MS обращает внимания на регистр букв, у меня все имена в DNS должны писаться заглавными?"

Ну DNS же регистронезависим, или я тебя как-то недопонял.

m2l>>Общий принцип — минимизация трансформации данных. Если можно, что бы одна сущность (то что ты вводишь) была везде одинаковой (вплоть до байта) — то желательно так и делать. Меньше кода, меньше потенциальных ошибок, меньше странных вопросов, а почему запрещено.

N>Тогда почему нельзя '-'?

Уменьшение сложности кода. Проше проверить, что имя включает только набор разрешенных символов, чем писать правило с дополнительными ветками, что эти символы допустимы, а эти не должны присутствовать в начале/конце.

Здравствуйте, m2l, Вы писали:

m2l>прикинь как можно сделать, что бы твои трудозатраты были минимальны — и всё будет ок.

Плохой программист Джон сделал ошибку в коде, из-за которой каждый пользователь программы был вынужден потратить в среднем 15 минут времени на поиск обхода возникшей проблемы. Пользователей было 10 миллионов. Всего впустую потрачено 150 миллионов минут = 2.5 миллиона часов. Если человек спит 8 часов в сутки, то на сознательную деятельность у него остается 16 часов. То есть Джон уничтожил 156250 человеко-дней ? 427.8 человеко-лет. Средний мужчина живет 64 года, значит Джон убил примерно 6 целых 68 сотых человека.

Как тебе спится, Джон — серийный программист?

m2l>Ругаясь на ограниченный набор символов.

Я ругался на невозможность использовать разделители, вообще-то.

m2l>некоторые ещё и не во всех позициях можно было бы использовать.

Черт с ним.

Здравствуйте, m2l, Вы писали:

m2l>Уменьшение сложности кода. Проше проверить, что имя включает только набор разрешенных символов, чем писать правило с дополнительными ветками, что эти символы допустимы, а эти не должны присутствовать в начале/конце.


Если постараться, то я могу представить себе мартышку, для которой "if (val.StartsWith('-') || val.EndsWith('-')) throw new ValidationException();" составляет какие-то сложности. Надо очень сильно постараться, но всё же можно.
Но вот каким образом подобная мартышка оказалась на работе в одной из богатейших компаний, которая на весь мир славится своими понтами и зубодробительными собеседованиями, и более того — ее оттуда не выкинули. Это уже за пределами любого разумного воображения.

m2l>Они чуть-чуть ужесточили правила к DNS, видимо, что бы уменьшить вопросы, а почему с минуса имя нельзя начать

Орден "Истязатель Совы" 1-й степени.

Ведь в нем переменных не 128 бит, а 122. И они как раз аккуратненько-плотненько влезают в сабжевые 24 символа с основанием 36 (совпадение?). Ну, кодировку, конечно же, придется не hex использовать.

Здравствуйте, Аноним931, Вы писали:

А>Ведь в нем переменных не 128 бит, а 122.
A> И они как раз аккуратненько-плотненько влезают в сабжевые 24 символа с основанием 36 (совпадение?). Ну, кодировку, конечно же, придется не hex использовать.

Не получится. Надо считать в другую сторону: поскольку у юзеров есть свобода выбирать себе идентификаторы для имён, нужно битовое пространство не уже, чем всё множество таких идентификаторов.
Поэтому сравниваем с 36**2+36**3+...+36**24. Чтобы это превзойти, следующая степень двойки — 2**125.
Во всех применяемых сейчас GUID (UUID) используется вариант 1, остаётся вроде бы 126 бит, но можем по факту использовать только типы 1 и 4, это 123 бита свободы.
Ну или нарушать правила выдачи UUID, что вместо них будет просто похожие идентификаторы.

N>Не получится.

Получится-получится. Легко и красиво.

N>Надо считать в другую сторону
N>поскольку у юзеров есть свобода
N>Чтобы это превзойти

Нет, ты совершенно не понял данный конкретный юзкейс. Повторяю исходный совет от удусекшл: "Используй GUID lowercase'ом без тире". Центральный поинт данного совета — без траты времени на раздумья сгенерить юзернейм, с очень высокой вероятностью не коллидирущий с уже имеющимся. И использование GUID с его 122 переменными битами эту задачу превосходнейше решает.

N>Во всех применяемых сейчас GUID (UUID) используется вариант 1, остаётся вроде бы 126 бит, но можем по факту использовать только типы 1 и 4, это 123 бита свободы.

Дааааа? А мужики-то и не знают:

The generated GUID contains 122 bits of strong entropy

N>Ну или нарушать правила выдачи UUID

Здравствуйте, Аноним931, Вы писали:

А>Нет, ты совершенно не понял данный конкретный юзкейс. Повторяю исходный совет от удусекшл: "Используй GUID lowercase'ом без тире".

Ну и зачем мне "понимать" именно такой вариант?
Если дословно, то это даст 32 символа base16 (0..9a..f), при лимите 24. Не работает.
Если перекодировать в base36, да, влезет. Но кому и зачем нужны именно такие идентификаторы?
Почему бы не сгенерировать тогда просто десяток-другой случайных символов из набора base36? Всё равно регистрировать надо.
И почему бы тогда не сгенерировать на полные 36**24, которое больше, чем 2**122?

A>Центральный поинт данного совета — без траты времени на раздумья сгенерить юзернейм, с очень высокой вероятностью не коллидирущий с уже имеющимся. И использование GUID с его 122 переменными битами эту задачу превосходнейше решает.

Ну так просто 24 рандомных символа ещё проще безо всяких промежуточных прохождений через какой-то GUID со сложной конверсией в base36 (которую ещё написать и отладить).

Но если ты хочешь серийно строить троллейбусы из буханок — вперёд, кто мешает?

N>>Во всех применяемых сейчас GUID (UUID) используется вариант 1, остаётся вроде бы 126 бит, но можем по факту использовать только типы 1 и 4, это 123 бита свободы.

А>Дааааа? А мужики-то и не знают:
А>

А>The generated GUID contains 122 bits of strong entropy

Даже перепевы от Мойши надо читать внимательно и понимая контекст. Этот конкретный метод генерирует вариант 1 тип 4, в нём действительно 122 бита случайности (6 фиксированы). А есть и другие типы, и лучше читать хотя бы такое более полное описание.

N>>Ну или нарушать правила выдачи UUID
А>

Более 90% применений знака facepalm на RSDN от тех, кто нихрена не понял в отвечаемом сообщении, но хочет показать, что он безусловно выше оппонента. Поздравляю, коллега, вы поддержали эту традицию.

Здравствуйте, m2l, Вы писали:

N>>Вот честно — ты считаешь, что это настолько сложная фича, что программисты не справятся?
m2l>Справятся. И всё будет работать.
m2l>Просто вот эта фича в одном месте, вот такая же в другом, вот справившиеся люди уволились и на их место пришли новые, вот они код решили порефакторить.... Подобные фичи не являются проблемой — они только увеличивают риск. А учитывая, что Azure всё-таки облако, с большин числом клиентов, обвесов и программистов, им желательна политика минимальных рисков.

Хмм, я таки не понимаю, на кого ты ориентируешься.
Если на внутренних программистов — у проекта размаха Azure должны быть средства обеспечения качества кода. Включая юнит-тесты и прочее.
Если на внешних... им одного replace недостаточно? Или я слишком хорошо думаю о людях, и они даже на такое не способны?

m2l>В случае с Azure фокус упрощения работы, имхо, должен быть смещён именно в пользу программистов, как один из многих инструментов контроля сложности и уменьшения вероятности возникновения багов.

Этот конкретный фактор минимально выглядит как сложность. jIMHO, конечно.

N>>Они по любому будут ходить, например, "почему я не могу зайти с акаунтом ABC1234? С каких это пор MS обращает внимания на регистр букв, у меня все имена в DNS должны писаться заглавными?"
m2l>Ну DNS же регистронезависим, или я тебя как-то недопонял.

Да. Но я передал не свою речь.

N>>Тогда почему нельзя '-'?

m2l>Уменьшение сложности кода. Проше проверить, что имя включает только набор разрешенных символов, чем писать правило с дополнительными ветками, что эти символы допустимы, а эти не должны присутствовать в начале/конце.

Мнэээ... Regex "^[a-z0-9](-?[a-z0-9]){1,23}$", по-моему, проще не бывает. Движки есть для любого языка вокруг (думаю, даже для Brainfuck кто-нибудь написал).