Я пожалуй соглашусь с вами, при условии, что «более подробная» валидация не будет носить запрещающий характер. Мне очень понравилась ваша фраза «можно было бы подсказать, что с ними что-то не так». Если это будет именно подсказка, что-то в духе «ваш адрес выглядит странно, возможно вы допустили ошибку», и пользователь сможет нажать кнопку «нет, все правильно, это мой адрес», тогда можно сделать проверку на соответствие наиболее распространенным форматам адресов. И это будет действительно полезно и удобно. А вот строго запрещать адреса, не прошедшие валидацию — смысла я не вижу. Если человек не хочет вводить свой адрес, он всегда может ввести корректный с точки зрения стандартов, но несуществующий адрес, или чужой, или свой, но неиспользуемый. И даже без злого умысла, ввел, а потом обнаружилось что пароль от почты забыл. Так что если адрес действительно важен, то в любом случае нужно письмо с подтверждением слать. И периодически, хотя бы раз в полгода, спрашивать у пользователя, не изменился ли его адрес.
Ну и если уж речь зашла про конверсию, нужно учитывать, что сейчас многие люди вообще почтой не пользуются по назначению, и ящики заводят только для регистраций, потому что большинство сайтов требует почту. Человек конечно зайдет в почту, если ему надо восстановить пароль, но если вы хотите, чтобы пользователь оперативно получал ваши сообщения, надо просить у человека не мыло, а то, чем он активно пользуется: телефон, facebook, WhatsApp, Viber и т.д… Все, чем он согласится поделиться. Ситуацию с почтой сейчас только Google вытягивает, привязывая почту к Android аккаунту. Если у человека почта gmail и Adroid, то письма он хотя бы на мобильнике увидит. Если же он вам не gmail'овсую почту дал, то, с высокой вероятностью, он ее проверяет. только когда ждет очередного письма с подтверждением регистрации.
Ну, как вариант, конечно. Но это если изначально вы «стащили» откуда-то готовую регулярку. Или она досталась вам по наследству. А так, зачем изначально ее писать, если в итоге получается write-only код? То есть в случае необходимости изменения регулярки мы ее полностью выкидываем и пишем вместо нее процедуру, или другую регулярку. А если бы изначально была обычная понятная процедура, то мы бы могли ее не с нуля переписывать, а найти и исправить то место, которое не соответствует нашим требованиям.
З.Ы. Я не говорю, что вообще не надо использовать регулярные выражения. Просто, по моему мнению, в силу особенностей синтаксиса они не предназначены для реализации в одном регулярном выражении большой и сложной логики. Они должны оставаться маленькими и простыми. А для реализации более сложной логики можно комбинировать несколько регулярных выражений. То есть пишем процедуру, в которой часть обработки делаем через последовательное применение нескольких регулярок, а часть, возможно и с помощью иных строковых функций. Возьмем тот же пример со скобочками в адресе. Как верно подмечено в статье, в регулярках разбирать рекурсивные выражения довольно сложно. Но в данном случае нам достаточно прогнать строку по символам в цикле один раз, походу считая количество открывающих и закрывающих скобок, и как только количество закрывающих скобок совпало с количеством открывающих — закрылась самая внешняя скобка, удаляем все между этими скобками и так далее до конца строки. А потом получившуюся очищенную строку можно уже скормить регулярному выражению. Код получается простейший, его даже студент сможет понять и поддерживать.
Ну гугл транслейт как минимум, не очень надежен, т.к. это не переводчик, а по сути поисковик по словам из разных языков. Как перевод кусков текста, чтобы «так сказать, в общих чертах понять, что ему нужно.» — это еще нормально работает. Там хотя бы по контексту можно догадаться какой из предложенных синонимов правильный. Да и автоматический подбор неплох. А вот когда отдельное слово переводишь, там все не так однозначно. Нужно не просто отсортировать по частоте использования синонима, нужны именно примеры использования, с пояснениями. Вот простой пример: есть слово «параллельно» — по английски будет «parallel». А есть слово «одновременно» — «simultaneously». В общем-то очень близкие по смыслу слова, которые могут заменить друг друга в речи. То есть синонимы. И если у гугла спрашивать перевод отдельного слова, то он на запрос «параллельно» никогда не выдаст «simultaneously». Только «parallel». А вот когда вводишь фразу «запустить две задачи параллельно», то в вариантах перевода слова «параллельно» уже появляется и «simultaneously». З.Ы. Описанный пример актуален на момент написания комментария. Алгоритм у них со временем меняется, плюс есть функция «предложить исправление», так что со временем результат может измениться. И это, кстати, тоже добавляет веселья. Одна и та же фраза в разное время, в зависимости от фазы Луны, может переводиться по разному.
Наличка нужна хотя бы для того, чтобы возможности банков по контролю за деньгами и денежными операциями были хоть как-то ограничены. Иначе слишком большая власть у них будет. Это потенциально гораздо большая опасность для человеческого общества, чем терроризм. Европейские банки уже давно кстати ноют, мол давайте отменим наличку, а то отрицательные ставки толком не работают. Так что ни в коем случае нельзя отменять наличные деньги.
Лично я даже наличие точки проверять бы не стал. Если домен внутренний, точек у него может и не быть. Что-то типа: «ivanov_vv@rogaikopyta».
Если же по какой-то причине действительно нужно проверить соответствие адреса стандарту RFC, например вы пишете программу, которая проверяет адрес на соответствие этому стандарту, то пытаться сделать полную проверку с помощью регулярного выражения это как-то странно. Особенно если это выражение принимает такой монструозный вид, как пример из статьи. Даже если это регулярное выражение будет работать правильно, лучше от него отказаться и написать обычную процедуру. Нет, ну серьезно, вы только представьте, что у вас обнаружился баг и вы подозреваете, что проблема в регулярном выражении. И вот вам надо найти в нем ошибку. Сколько часов это займет?
Касаемо стандарта, из всего что описано в статье, плюсик кажется более-менее полезным. Хотя я бы эту задачу решил подключением нескольких разных адресов к одному почтовому клиенту. Или настроив перенаправление. Тогда тот, кому я дал свой рабочий адрес будет знать только его. Если же написать «vasyapupkin+work@example.com», то любой догадается что отбросив "+work" можно послать Васе письмо на основной ящик. А уж комментарии в адресе вообще не понятно зачем нужны. Если они никак не влияют на то, куда будет доставлена почта, то значит они и частью адреса, по сути, не являются. Если адреса «vasyapupkin(1)@example.com» и «vasyapupkin(2)@example.com» указывают на один и тот же ящик, то можно просто удалить все что находится в скобках. Вообще, давно пора написать новый стандарт, включив в него то, что реально используется на практике и отбросив все лишнее. И уже его дальше продвигать и поддерживать. К тому же, у меня есть подозрение, что полная поддержка стандарта RFC822 никогда и никем так и не была реализована. Поправьте, если я ошибаюсь.
А как насчет выживаемости колонистов при марсианском давлении? Там в любом случае придется делать герметичные помещения с земной атмосферой и давлением. Ферма будет таким же помещением. Просто если марсианский грунт не подойдет, то придется еще и грунт с собой везти. Выйдет дороговато. А так, на месте грунта накопал, от вредных элементов очистил, удобрений добавил, и выращивай что хочешь. По крайней мере это подходит для питания первых колонистов. Если же говорить о полноценном терраформировании, то я даже не представляю пока как на практике этого добиться. Попросту нет таких технологий пока.
Насколько я понимаю, это решит только проблему скорости. А что насчет точности? Впрочем и точность не главная проблема технологий вроде этой. Я тут пересмотрел ролик, посмотрел фото из статьи еще раз, свежим взглядом, и пришел в ужас. Ведь такое управление совершенно неудобно. Что если я поверну голову, отвернусь на время от рук? Руки так и надо держать в таком положении, как на фотке из статьи? Вот так вот держать кисти рук на уровне глаз, и если мне надо в игре повернуться, то поворачиваться всем корпусом, чтобы руки из поля зрения не ушли? Как-то хочется побольше свободы в движениях. В реальности мне не нужно смотреть на свои руки, чтобы они у меня были. В виртуальной реальности должно быть так же. Тем более этого вполне можно достичь. По моему, когда камера была отдельно, в фиксированном положении на столе, было даже лучше, а встроить ее в шлем — это полный провал. Это могло бы подойти для устройства вроде Google Glass, но это совершенно неудобно для игр. В мире и так уже достаточно устройств, с неудобным управлением для игр. Чего только стоит армия планшетов и смартфонов, на которых просто невыносимо играть в игры со сложным управлением. Да и геймпады современные совершенно не подходят для шутеров, и не очень-то удобны для игр со свободно вращающейся камерой. Похоже Leap Motion пополнит этот список.
Лично мне кажется, тут нужны перчатки. Во всяком случае, если использовать виртуальную реальность для игр, то нужен максимально быстрый отклик, и максимальная точность. Одна лишь оптика с таким не справится. Для дополненной реальности возможность работать без перчаток и каких-либо дополнительных датчиков, пожалуй, была бы актуальной. Но для игр это не главный приоритет. Нинтендо в 82-м мыслили в верном направлении. Возможно вариант без дополнительных датчиков станет отправной точкой, за счет меньшей себестоимости, но в дальнейшем понадобятся улучшения в плане скорости и точности, и в итоге все же придут к перчаткам. Плюс в перчатках есть возможность сделать тактильные ощущения, за счет тех же вибромоторчиков. Возможность не только увидеть, но и потрогать, вот это настоящая виртуальная реальность. Круче уже только нейроинтерфейс.
В любом случае, какая бы технология не выстрелила, одно можно сказать точно. Пока к виртуальной реальности не приделают руки она не взлетит. Надеть шлем и пожирать виртуальность глазами это здорово, но одним лишь созерцанием сыт не будешь. Геймера руки кормят.
Уже сам факт возникновения такого разбирательства является пиаром. Даже если Эппл проиграет и будет вынуждено сделать iOS Bruteforce Edition. Вы задумайтесь на секунду, как это выглядит в глазах рядового пользователя. Не гика, не параноика, не шифропанка. Ведь массовый потребитель это всегда Average Joe. И лишь небольшой процент этих Джо хотят быть неуловимыми. Задумайтесь, как это выглядит сейчас. Даже ФБР не может взломать айфон. Иначе бы они не стали просить Эппл о помощи. Для подавляющего большинства людей это означает, что коварный хакер не сможет получить доступ к их банковским картам, личной переписке или интимным фото. Даже если получит физический доступ к устройству. А следовательно он никак не сможет украсть их деньги или устроить шантаж.
С другой стороны, вся эта шумиха вовсе не означает, что в ФБР не могут самостоятельно взломать устройство. Крупные терракты происходят не каждый день. И тем более, их расследование не каждый раз зависит от взлома айфона. То есть это очень удобный предлог, чтобы потребовать инструмент, который упростит дальнейшую работу. А заодно и прецедент будет. То есть создается инструмент не только технический, но и юридический. И все одним махом.
Каким будет итог? Я думаю, все будет примерно так:
1) ФБР получит больше возможностей, как технических, так и юридических, для взлома айфонов, а затем и других смартфонов.
2) Айфоны станут менее популярны у террористов. Во всяком случае, они будут меньше полагаться на встроенное шифрование.
3) Как следствие, к Эппл будет меньше претензий по поводу, использования их продукции террористами.
4) Уверенность большинства пользователей в безопасности использования айфонов не упадет, а может и поднимется (ведь ФБР не смогли сами взломать, ага).
5) Поскольку возросшая уверенность пользователей будет беспочвенна, а новые инструменты вполне могут «уплыть» за пределы ФБР, пользователи станут более уязвимы.
Ну, я думаю понятно, кто здесь победил, а кто проиграл. В общем все как всегда. Действующей системе от террактов больше пользы, чем вреда. Наверное все террористы просто клинические идиоты, раз выбирают такие неэффективные методы. Или… Да нет, нет. Конечно же, они просто идиоты. Это все объясняет.
Ну и если уж речь зашла про конверсию, нужно учитывать, что сейчас многие люди вообще почтой не пользуются по назначению, и ящики заводят только для регистраций, потому что большинство сайтов требует почту. Человек конечно зайдет в почту, если ему надо восстановить пароль, но если вы хотите, чтобы пользователь оперативно получал ваши сообщения, надо просить у человека не мыло, а то, чем он активно пользуется: телефон, facebook, WhatsApp, Viber и т.д… Все, чем он согласится поделиться. Ситуацию с почтой сейчас только Google вытягивает, привязывая почту к Android аккаунту. Если у человека почта gmail и Adroid, то письма он хотя бы на мобильнике увидит. Если же он вам не gmail'овсую почту дал, то, с высокой вероятностью, он ее проверяет. только когда ждет очередного письма с подтверждением регистрации.
З.Ы. Я не говорю, что вообще не надо использовать регулярные выражения. Просто, по моему мнению, в силу особенностей синтаксиса они не предназначены для реализации в одном регулярном выражении большой и сложной логики. Они должны оставаться маленькими и простыми. А для реализации более сложной логики можно комбинировать несколько регулярных выражений. То есть пишем процедуру, в которой часть обработки делаем через последовательное применение нескольких регулярок, а часть, возможно и с помощью иных строковых функций. Возьмем тот же пример со скобочками в адресе. Как верно подмечено в статье, в регулярках разбирать рекурсивные выражения довольно сложно. Но в данном случае нам достаточно прогнать строку по символам в цикле один раз, походу считая количество открывающих и закрывающих скобок, и как только количество закрывающих скобок совпало с количеством открывающих — закрылась самая внешняя скобка, удаляем все между этими скобками и так далее до конца строки. А потом получившуюся очищенную строку можно уже скормить регулярному выражению. Код получается простейший, его даже студент сможет понять и поддерживать.
Если же по какой-то причине действительно нужно проверить соответствие адреса стандарту RFC, например вы пишете программу, которая проверяет адрес на соответствие этому стандарту, то пытаться сделать полную проверку с помощью регулярного выражения это как-то странно. Особенно если это выражение принимает такой монструозный вид, как пример из статьи. Даже если это регулярное выражение будет работать правильно, лучше от него отказаться и написать обычную процедуру. Нет, ну серьезно, вы только представьте, что у вас обнаружился баг и вы подозреваете, что проблема в регулярном выражении. И вот вам надо найти в нем ошибку. Сколько часов это займет?
Касаемо стандарта, из всего что описано в статье, плюсик кажется более-менее полезным. Хотя я бы эту задачу решил подключением нескольких разных адресов к одному почтовому клиенту. Или настроив перенаправление. Тогда тот, кому я дал свой рабочий адрес будет знать только его. Если же написать «vasyapupkin+work@example.com», то любой догадается что отбросив "+work" можно послать Васе письмо на основной ящик. А уж комментарии в адресе вообще не понятно зачем нужны. Если они никак не влияют на то, куда будет доставлена почта, то значит они и частью адреса, по сути, не являются. Если адреса «vasyapupkin(1)@example.com» и «vasyapupkin(2)@example.com» указывают на один и тот же ящик, то можно просто удалить все что находится в скобках. Вообще, давно пора написать новый стандарт, включив в него то, что реально используется на практике и отбросив все лишнее. И уже его дальше продвигать и поддерживать. К тому же, у меня есть подозрение, что полная поддержка стандарта RFC822 никогда и никем так и не была реализована. Поправьте, если я ошибаюсь.
В любом случае, какая бы технология не выстрелила, одно можно сказать точно. Пока к виртуальной реальности не приделают руки она не взлетит. Надеть шлем и пожирать виртуальность глазами это здорово, но одним лишь созерцанием сыт не будешь. Геймера руки кормят.
С другой стороны, вся эта шумиха вовсе не означает, что в ФБР не могут самостоятельно взломать устройство. Крупные терракты происходят не каждый день. И тем более, их расследование не каждый раз зависит от взлома айфона. То есть это очень удобный предлог, чтобы потребовать инструмент, который упростит дальнейшую работу. А заодно и прецедент будет. То есть создается инструмент не только технический, но и юридический. И все одним махом.
Каким будет итог? Я думаю, все будет примерно так:
1) ФБР получит больше возможностей, как технических, так и юридических, для взлома айфонов, а затем и других смартфонов.
2) Айфоны станут менее популярны у террористов. Во всяком случае, они будут меньше полагаться на встроенное шифрование.
3) Как следствие, к Эппл будет меньше претензий по поводу, использования их продукции террористами.
4) Уверенность большинства пользователей в безопасности использования айфонов не упадет, а может и поднимется (ведь ФБР не смогли сами взломать, ага).
5) Поскольку возросшая уверенность пользователей будет беспочвенна, а новые инструменты вполне могут «уплыть» за пределы ФБР, пользователи станут более уязвимы.
Ну, я думаю понятно, кто здесь победил, а кто проиграл. В общем все как всегда. Действующей системе от террактов больше пользы, чем вреда. Наверное все террористы просто клинические идиоты, раз выбирают такие неэффективные методы. Или… Да нет, нет. Конечно же, они просто идиоты. Это все объясняет.