Доменный регистратор Reg.ru открыл приём предварительных заявок на регистрацию адресов в доменных зонах.FAIL и.WTF. Об этом сообщается в поступившем в редакцию ЦП пресс-релизе.

Reg.ru отмечает, что по запросам «юмористический сайт», «сайт приколов» и «сайт анекдотов» популярные поисковые системы выдают десятки тысяч тематических сайтов. Посещаемость самых популярных из них достигает 15 млн посетителей в месяц.

.WTF

Аббревиатура WTF (What the fuck) означает негодование и возмущение по поводу происходящего или употребляется в том случае, когда непонятно, о чем идет речь. С момента подачи заявки на создание этой зоны в рамках программы New gTLD на неё поступали жалобы от властей Саудовской Аравии и американских активистов, защищающих моральные ценности. Причиной было нецензурное слово в расшифровке аббревиатуры.

.FAIL

По информации Reg.ru, интерес пользователей к «фейлам» (в переводе с английского — неудача, провал) настолько высок, что на отдельных видеоканалах на YouTube формируются специальные подборки лучших «провалов» продолжительностью до нескольких часов. Всего на видеохостинге по запросу fail поиск выдаёт более 30 млн роликов.

Регистратор отмечает, что новые международные доменные зоны в первую очередь привлекут внимание администраторов и блогеров юмористической направленности. Открытая регистрация начнётся 6 августа, а с сегодняшнего дня на Reg.ru можно сделать предзаказ . Для этого необходимо внести полную стоимость домена. В случае отказа в регистрации, деньги вернутся на счёт пользователя.

Стоимость регистрации домена в зоне.WTF или.FAIL для розничных клиентов Reg.ru составляет 1965 рублей в год, а для участников партнерской программы — от 1575 до 1800 рублей.

Заявку на регистрацию может подать практически любая организация. Её стоимость составляет около $200 тыс. В ближайшее время

Чей домен.WTF и к какому виду доменов он относится. История возникновения доменной зоны.

Домен-провокация.WTF– один из немногих, чье полное название не принято произносить вслух в приличном обществе. На русский его можно перевести как «Что за ерунда происходит?», «Что за черт?», «Что за бред?» или «Невероятно!». gTLD .WTF открылся для предварительной регистрации 30 июля 2014 г., а спустя неделю – 6 августа – для общей. Регистратором компания «DonutsInc.» из США.

Характеристика доменной зоны WTF.

Регистрация домена в.WTF разрешается всем без каких-либо ограничений и дополнительных условий. Домен поддерживает следующие языки (IDN): китайский традиционный и упрощенный, французский, испанский, немецкий и английский. Купить домен могут и граждане России.

Требования при регистрации доменов.WTF.

Правила регистрации доменных имен в зоне.WTF:

• Допустимая длина доменного имени: 3 – 63 знака. По требованию ICANN все имена из 1 и 2 знаков резервируются заранее, хотя впоследствии могут освободиться для общей регистрации.
• Ограничения в имени домена: в.WTF разрешены тире, буквы и цифры. К регистрации принимаются только имена без пробелов, двух тире подряд и тире в начале или в конце.
• Когда возможно продление домена: в любой момент на 1– 10 лет.
• Порядок прекращения делегирования и удаления доменов WTF: домен перестает работать на следующий день по завершении оплаченного срока делегирования. Льготное продление (по стандартному тарифу) – 40 дней, затем в течение 30 дней можно продлить делегирование за дополнительные деньги. Если в последующие 5 дней владелец не оплачивает продление делегирования, домен удаляют.

Кому стоит зарегистрировать доменное имя WTF?

Как понятно из названия.WTF, эта зона станет идеальной платформой для:

• Провокационных молодежных ресурсов.
• Онлайн теле и радиоканалов для молодежи.
• Людей с нестандартным чувством юмора.
• Блогов и сайтов о невероятном и смешном.

• Юмористических изданий.
• Актеров юмористического жанра.
• Продавцов и производителей молодежных товаров.
• Телешоу.

Преимущества и недостатки доменной зоны WTF.

Преимущества домена WTF:

• Идентификация: если вы правильно определили аудиторию своего сайта, пользователи при первом взгляде на название.WTF поймут, что сайт посвящен прикольным, невероятным и провокационным моментам.

Основные недостатки:

• Кириллица: в названии имен не разрешается.
• Цена: домен стоит дороже привычных.COM или.RU.
• Тематичность: выражение, которое легло в основу названия домена.WTF, известно и понятно, в основном, молодежи, либо англоговорящей публике. Это нужно иметь в виду при определении целевой аудитории сайта.

Где лучше купить домен в зоне WTF?

Самое разумное – зарегистрировать имя в компании, которая продает доменные имена не меньше трех лет. Не забудьте посмотреть, как о ней отзываются клиенты на тематических форумах и на сайте самой фирмы.

Часто задаваемые вопросы про доменную зону WTF

При оплате тарифного плана «Бизнес», сроком на год и более - возможна регистрация домена стоимостью до 1000 рублей бесплатно (сроком на 1 год). Стандартная цена домена.WTF выше этой суммы, поэтому зарегистрировать его можно только по акции (если его цена составит менее 1000 рублей). Тарифы виртуального хостинга представлены . Через год доменное имя может быть продлено по стандартной цене для выбранной зоны.

Бывает, что мелкие регистраторы предоставляют более выгодные условия. Можно воспользоваться акциями, но не рассчитывать на оперативность техподдержки, если она вам понадобится. Самостоятельный переход от одного регистратора к другому, дело хлопотное, к тому же в некоторых компаниях существуют негласные инструкции по максимальному усложнению передачи домена (вплоть до личного визита в офис). Внимательно читайте условия соглашения. Если домен регистрируется на вас, как на физическое или юридическое лицо и ваши данные отображаются в регистрационной информации, это выгодное и интересное предложение. Если домен регистрируется на компанию, предоставляющую услуги, не стоит связываться – вы не будете являться владельцем домена.

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

Речь пойдет о практически любых системах, использующих для ввода информации формы. Обязательное поле - это поле формы, без заполнения которого система не примет у вас информацию. Среди подавляющего большинства разработчиков ПО бытует мнение, что обязательными полями должны быть:

1. Все необходимые с точки зрения предмета поля (например, ФИО и дата рождения человека, если речь о паспортном столе);
2. Все необходимые для функционирования системы поля (те, без которых не будут работать алгоритмы - например, дата, с которой начинается предоставление услуг, чтобы делать по ним начисления);
3. Важные поля - такие, которые не необходимо, но желательно заполнить (например, обоснование вносимого изменения) - с той мотивацией, что пусть лучше пользователь попотеет, когда не нужно, чем забудет ввести значение, когда будет нужно.

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

Традиционно программисты считают, что делают одолжение всему остальному миру, создавая для них такой замечательный продукт, как «подставьте любое название продукта». Их программа - это чуть ли не платоновский эйдос, чистейшая абстракция, математическая формула, вычислимая, естественно, строго на наборе параметров из своей области определения. С этой точки зрения обязательные поля - та досадная мелочь, которую приходится вставлять, чтобы обучить глупых и неотесанных пользователей, как правильно вводить информацию в систему, с которой они получили честь работать.

Считается также, что некорректные (неполные) данные настолько страшны, что даже хранить их в базе данных уже некорректно. Ну и лень, разумеется - с точки зрения разработчика легче проверить корректность данных на этапе ввода и послать пользователя перепроверять свои данные, чем писать обработку ошибок там, где в системе эти данные будут реально использоваться.

Что на это имеет сказать современная наука проектирования взаимодействия с пользователем? Во-первых, стало ясно (уж не знаю, кому и когда, но достаточно давно точно, см. и ), что все-таки программы разрабатываются для пользователей. В этом смысле программист уже не диктует условия, а скромно создает сугубо утилитарный продукт, инструмент, которым будут пользоваться люди для решения своих задач и достижения своих целей. Как утюг - если тебе нужно что-то погладить, ты его включаешь. Если он будет вместо того, чтобы гладить, модально предлагать скачать обновления из интернета, понятно, куда такой утюг полетит. Алан Купер рекомендует представлять пользователей вашего продукта как очень умных, но очень занятых людей. Они, мол, не тупые и поймут, как вашим продуктом пользоваться, главное, вы только не вставайте у них на пути.

Я вообще считаю, что каждому программисту (дизайнеру, менеджеру, аналитику) следует проделать медитацию, упомянутую Сергеем Бодровым-мл.:

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

Я, конечно, вовсе не хочу сказать, что программист - профессия ненужная, я сам программист и совсем так не считаю. Просто это неблагодарная профессия. Никто не придет и не похвалит за хорошо реализованный алгоритм. Если программа хороша, ей будут пользоваться без дополнительных вопросов. Так и должно быть, просто, чтобы быть программистом, надо к этому привыкнуть. А эти вот люди, которые идут по улице и сменяются на остановке - это ваши пользователи. Они используют вещи так, как они им нужны. В том числе и ваш продукт. Без вас. Они ничего о вас не знают, не хотят знать и никогда не узнают. Сергею Витальевичу, когда он в полярной тундре пытается вбить в систему снятые со счетчика показания, совершенно не интересно, почему система говорит ему, что сперва требуется указать какой-то там тип тарификации, даже если в момент проектирования вам казалось, что без типа тарификации ну уж никак не обойтись. А что касается примера про утюг, скачивающий обновления, то он взят совсем не из пальца - обратите внимание, как ведет себя при включении браузер Файерфокс.

Тут вообще будет что-нибудь про обязательные поля, спросит хабраюзер? Как раз сейчас начнется.

Штука в том, что реальный наш мир - это не математическая модель, параметры которой известны в любой момент времени. Для реальной жизни характерна скорее нехватка информации, чем ее наличие. У человека, заполняющего форму, требуемых данных может не быть - и не быть их может во всех обозримых пределах досягаемости, то есть не быть ваще. Эту проблему нельзя решить, просто сделав поле обязательным - значение из воздуха не возьмется. Вводя на формах обязательные поля в угоду целостности и полноте данных, мы на самом деле мешаем пользоваться системой . Столкнувшись с такой ситуацией, пользователь либо не станет заполнять форму (и не сможет работать с системой вовсе), либо заполнит недостающие данные рыбой - выдуманными или бессмысленными данными. И это свидетельствует не о том, что пользователь плохой или плохо старался, а лишь о том, что разработанная система недостаточно гибка для использования в условиях реального мира. То, что произошло во втором случае (ввод рыбы) - это вообще обман. Разработчик системы может сколько угодно делать вид, что все в порядке, но на самом деле в этом обмане виноват именно он. Причем непонятно, кто и что вообще выиграл - пользователь поимел головную боль, а в систему попали некорректные данные. Да попали так, что обнаружить, отфильтровать или подчистить их автоматически уже невозможно - в отличие от случая, если бы пользователь просто указал, что информация отсутствует.

Что же делать? Делать нужно хорошие программы. А именно, да, таки не ставить целостность схемы БД во главу угла, а ставить туда цели и задачи пользователей. Другими словами, принимать у пользователя неполные, а в некоторых случаях и некорректные данные, естественно, с возможностью исправить их в будущем. Вопреки заблуждению (да, еще одному) это возможно, это не так сложно и это даже работает. Кроме этого, нужно еще каким-то образом помогать, подсказывать пользователю, где, каких данных и для чего ему не хватает. Чтобы он видел и контролировал ситуацию.

Сколько обязательных полей должно быть на форме? В идеале, ноль. Всегда ли такое возможно? Для меня одним из примеров высшего пилотажа является операция создания папки в Виндоус. Казалось бы, уж меньше одного поля тут не сделаешь, однако нет, они умудрились реализовать создание так, что система не спрашивает ничего - даже несмотря на то, что технические ограничения не позволяют системе создать папку без имени. Это идеал, к которому нужно стремиться.

Естественно, система должна быть минимально умной, спрашивая у пользователя только то, что имеет отношение к задачам пользователя, а не к потребностям самой системы. Система как инструмент, помните? Как раз про пример с Файерфоксом - Гугл Хром, например, решил проблему Файерфокса, обновляясь тихонько в тот момент, когда пользователь его перезагружает. Пользователю об этом знать совсем не нужно - он и не знает. Достойный пример для подражания. Я, признаться, даже сперва не понял, чегой-то он меня ни разу не спрашивал, когда ему обновляться?

Еще был миф о важных полях (это те, которые необязательны, но желательны к заполнению). Здесь все еще проще - принудительно заставить заполнить поле нельзя. Следовательно, хоть помечай поле как обязательное, хоть не помечай - все равно напишут рыбу, чушь, отписку, если не захотят заполнять. Интерфейсного решения у этой проблемы нет. Важность полей нужно доносить до сотрудников на местах. А разработчику пометить поле как необязательное. И позволить редактировать.

Литература:

1. Алан Купер об интерфейсе. Основы проектирования взаимодействия. Символ-Плюс, 2009 г.
2. Джеф Раскин. Интерфейс: новые направления в проектировании компьютерных систем. Символ-Плюс, 2005 г.

UPD: В комментариях и понятнее сформулировали основную мораль топика: речь о системе черновиков, о снятии требования ввести все данные сразу и непротиворечиво. То есть да, делать необязательными даже те поля, без которых система не будет работать. Естественно, она и не будет работать, но пусть хотя бы данные похранит.

UPD #2: Уточню еще одну вещь, которую я сам не осозновал ясно, когда писал топик. Я не обсуждаю здесь вопросов уместности тех или иных полей на форме (это важная, но все-таки немного другая тема, чем та, которую мне хочется донести). Я скорее предлагаю переосмыслить саму концепцию ввода информации с помощью форм, тот традиционный подход, когда нужно заполнить всю форму сразу и корректно. Вместо этого я предлагаю промежуточное состояние (неполное, некорректное, противоречивое) тоже позволять сохранять в БД, явным образом помечая такое состояние как неполное/некорректное/противоречивое . Таким образом все ситуации «я сейчас знаю не все, но завтра, может быть, узнаю», которые традиционно решаются записыванием на бумажку, можно обрабатывать с помощью информационной системы. Естественно, такие данные не нужно пускать в бизнес-процесс в силу их некорректности - тут все остается как раньше. Они просто полежат в БД до лучших времен - не пригодятся, ну и бог с ними.

01.03.2016

Всем привет!
Продолжаем изучать основы HTML. В этом уроке мы разберем, как проверить HTML форму на заполнение без использования языка программирования.
Да, именно так, проверку формы будем учиться делать на чистом HTML.
Когда-то нужно было для проверки форм использовать PHP или JavaScript. Но HTML на месте не стоит и на сегодняшний день добавлены новые возможности, одна из которых – проверка форм, которую мы и рассмотрим сегодня.

Таблица регулярного выражения

Выражение	Описание
\d	Одна цифра от 0 до 9.
	Любой символ кроме цифры.
	Пробел.
	Только заглавная латинская буква.
	Только латинская буква в любом регистре.
[А-Яа-яЁё]	Только русская буква в любом регистре.
	Любая буква русского и латинского алфавита.
	Три цифры.
	Не менее шести латинских букв.
{,3}	Не более трёх цифр.
	От пяти до десяти цифр.
^+$	Любое слово на латинице.
^[А-Яа-яЁё\s]+$	Любое слово на русском включая пробелы.
^[ 0-9]+$	Любое число.
	Почтовый индекс.
\d+(,\d{2})?	Число в формате 1,34 (разделитель запятая).
	Число в формате 2.10 (разделитель точка).
\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}

Предыдущая запись
Следующая запись

«Защитой от дурака» называется комплекс мер по пресечению ввода неправильной информации в форме. Например, если в поле требуется ввести положительное число от 0 до 10, то следует проверить, чтобы пользователь не ввёл текст или число, которое не лежит в указанном диапазоне, т.е. число не должно быть меньше нуля и больше десяти.

Почему происходит ввод неправильной информации? Это в основном совершается по трём причинам.

1. Пользователь ошибся случайно, например, невнимательно прочитал, что ему требуется указать.
2. На веб-странице неоднозначно просят ввести данные, поэтому пользователю приходится гадать и делать предположение, что же в действительности от него хотят. При этом не всегда происходит совпадение мнений разработчика и пользователя.
3. Есть ряд людей, которые воспринимают инструкции как вызов и стараются поступить наоборот. Такие пользователи рассуждают примерно так: «Ага, меня просят ввести число. А что будет, если я укажу буквы?». После чего задают явно неправильную информацию и смотрят, к чему это приведёт.

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

Обязательное поле

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

Пример 1. Атрибут required

HTML5 IE 10+ Cr Op Sa Fx

Логин:

Пароль:

Обязательные поля должны быть заполнены перед отправкой формы, иначе форма на сервер не отправится и браузер выдаст об этом предупреждение. Вид сообщения зависит от браузера, например Chrome выводит всплывающую подсказку, как показано на рис. 1.

Рис. 1. Обязательное поле не заполнено

Корректность данных

Исходно имеется два поля, в котором вводимые пользователем данные проверяются автоматически. Это веб-адрес и адрес электронной почты. Браузер Chrome также проверяет на корректность поле с календарными данными, но только потому, что у него не предусмотрен интерфейс выбора календаря щелчком мыши. Для этих элементов характерны следующие правила.

• Веб-адрес ( ) должен содержать протокол (http://, https://, ftp://).
• Адрес электронной почты ( ) должен содержать буквы или цифры до символа @, после него, затем точку и домен первого уровня.

У браузеров несколько различается политика по проверке данных пользователя. К примеру, Opera подставляет протокол http:// перед введённым текстом автоматически, тогда как другие браузеры ждут его от пользователя. Chrome и Opera требуют, чтобы в почтовом адресе была точка, для Firefox она не обязательна.

В примере 2 показана форма с обязательными полями, в которой два поля проверяется браузером.

Пример 2. Корректность данных

HTML5 IE 10+ Cr Op Sa Fx

Заполните форму (все поля обязательны)

Имя:

Email:

Сайт:

Opera проверяет элемент формы только при наличии атрибута name.

Что происходит в Opera при вводе неверных данных показано на рис. 2.

Рис. 2. Предупреждение о неправильных данных

Шаблон ввода

Некоторые данные нельзя отнести к одному из видов элементов формы, поэтому для них приходится использовать текстовое поле. При этом их ввод происходит по определённому стандарту. Так, IP-адрес содержит четыре числа разделённых точкой (192.168.0.1), почтовый индекс России ограничен шестью цифрами (124007), телефон содержит код города и конкретное количество цифр часто разделяемых дефисом (391 555-341-42) и др. Браузеру необходимо указать шаблон ввода, чтобы он согласно нему проверял вводимые пользователем данные. Для этого используется атрибут pattern , а его значением выступает регулярное выражение . Некоторые типовые значения перечислены в табл. 1.

В примере 3 просят ввести шестнадцатеричное значение цвета (#ffcc00) и если оно не лежит в этом диапазоне, браузер выводит сообщение об ошибке.

Пример 3. Шаблон ввода

HTML5 IE 10+ Cr Op Sa Fx

Введите шестнадцатеричное значение цвета (должно начинаться с #)

На рис. 3 показано предупреждение в браузере Chrome.

Рис. 3. Введённые данные не соответствуют шаблону

Отмена валидации

Валидация не всегда требуется для формы, к примеру, разработчик пожелает использовать универсальное решение на JavaScript и дублирующая проверка браузером ему уже ни к чему. В подобных случаях необходимо отключить встроенную валидацию. Для этого применяется атрибут novalidate тега

. В примере 4 показано использование этого атрибута.

Пример 4. Отмена валидации

HTML5 IE 10+ Cr Op Sa Fx

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