Нет, Виталий, нельзя :) Я подумал, что это шутка была.
Если речь идет о валидации — условно можно.
С регуляркой из вашей статьи мы можем ошибиться с проверкой и отсечь верный email. Не особо страшно, тем более, что этот адрес будет достаточно экзотический.
С этой регуляркой мы почти все неверные адреса считаем верными. На мой взгляд такой подход — хуже.
Ну а если речь идет о поиске в тексте (как в вашей статье) — эта регулярка совсем не годится.
Я это к тому, что в погоне за «абсолютной правильностью» важно понимать, какую задачу мы решаем. И не подменять ее на другую, абстрактную.
Вы в статье рассматриваете абстрактные примеры валидации email, и именно в этом абстрактном контексте я и беседую. Поэтому не надо в рамках данной дискуссии подменять абстрактную задачу на какую-то конкретную.
Поясню. Примеры с Яндексом и т.д. совсем не в тему. Это примеры систем со своими требованиями и ограничениями к формату email адреса и именно эти свои требования они проверяют. Это пример как раз конкретной задачи с определенными ограничениями.
Поэтому если бы в вашей статье пример выглядел так: «Давайте проверим email пользователя Яндекс — логин может состоять из латинских символов, цифр, одинарного дефиса или точки. Он должен начинаться с буквы, заканчиваться буквой или цифрой и содержать не более 30 символов.»
то мне был бы понятен ваш аргумент, однако в таком случае и этой дискуссии бы не было.
Вы же в статье пишите о RFC
На самом деле есть RFC, который определяет правильность email. И есть “регулярки” по RFC — вот примеры.
и якобы (примеры по ссылке — тоже работают неправильно) существующей возможности проверки email адреса регулярным выражением. Без какой-то конкретики о постановке задачи. Абстрактно. Я вам указал на то, что это — ошибка и что тему «валидация email регулярным выражением» было бы правильно пометить в главу «Какие задачи не решаются регулярными выражениями».
Понятно, что это лишь пример. Просто новички часто берут примеры сразу в работу, не читая особо текст с предупреждениями о RFC и т.п… Случай email вообще — особенный. Казалось бы он достаточно нагляден, но
В дальнейшем, конечно, такие вещи, как работа с email или URL стоит гуглить, интересоваться стандартами и типовыми решениями.
Мой ход мысли:
У автора нет возможности скачать файл с сервера БД.
Как следствие — возможности залить файл на сервер БД тоже нет.
Как следствие — web приложение развернуто на другом сервере.
Как следствие — web приложение соединяется с удаленным сервером БД.
Как следствие — для того, чтобы сделать дамп базы, web приложение не нужно
Если фул-стек девелопер + опыт мобильных приложений + опыт докера — закидывай резюме на R&D девелопер. А если ещё и Бауманка… :-)
Вроде всему соответствую. И даже — Бауманка… :)
Знаете, почему статья не заставила даже задуматься о возможности такой работы? Вроде все правильно и красиво, свобода, все дела… Но два момента смутило.
Сейчас наша команда работает над одним проектом, и мы уже два месяца много обсуждаем, что же отличает нас, как работодателя, от других компаний?
Начало статьи шоковое. Два месяца «много обсуждать» свои отличия во время работы над проектом? Действительно — свобода.
Кто здесь из банков в последние год-два пытался внедрить роль Scrum-мастеров? Вы же знаете, какой хайп сейчас в стране на эту тему?
Хайп — хайпом, но тема не раскрыта. Вы подаёте пример так, как будто необходимость Agile и Scrum-мастеров — это данность, не подвергаемая сомнению. А на самом деле это вопрос спорный и решаемый в каждом случае индивидуально. Я понимаю, что главное в вашем примере — способ решения вопроса (и он хорош, реально хорош), но, честно говоря, для меня показательнее было бы описание условий, при которых вопрос необходимости scrum-мастеров вообще встал перед вами.
Кстати, мое начальство в свое время очень вдумчиво изучило этот вопрос и пришло к выводу, что agile нам не подходит, а scrum-мастера занимаются в основном профанацией за немалые деньги. Так и живем без agile. Значит ли это то, что я работаю в условиях меньшей «свободы»? Думаю, что нет.
Только вот на собеседованиях у нас почему-то принято требовать именно код, глядя на который потом какой-нибудь сеньор будет вам рассказывать какой код плохой и придираться к каждой неточности в синтаксисе.
По моему — вы все еще в заблуждениях. Не принято так в нормальных местах. Вам пытаются объяснить, что код в таких случаях — не главное, тем более — синтаксис.
Точно такая же в принципе ситуация с тестовыми заданиями — их чаще всего просят сделать вовсе не для того чтобы что-то там проверить и в чём-то там убедиться (как пишут комментаторы в этом посте), а для того чтоб было больше поводов придраться, даже если код полностью рабочий.
Это вообще за гранью…
Тестовые задания (простые, совсем простые) даются для того, чтобы появилась тема для разговора, не более. Гораздо легче обоим участникам процесса обсуждать особенности решения тестовой задачи, чем на пустом месте придумывать вопросы и отвечать на них.
Вообще, подумайте сами — это же абсурд! Зачем придумывать поводы придираться? Ведь компании нужен специалист. Компания заинтересована его найти в максимально короткое время и закрыть вопрос. А вы описывайте ситуацию так, как будто техническим специалистам работодателя больше делать нечего, как придираться и футболить соискателей.
Или у вас «в компании и команде» пишут код на бумажках, и потому вы это требуете от соискателей?
Нет, соискателя просят это сделать скорее потому, что такой способ позволяет с минимальными потерями времени оценить какие-то его качества (ход мысли, умение формализовать и защитить решение и т.п.) Это всего лишь один из способов оценки, проверенный и достаточно эффективный.
Ну а если кандидат считает для себя унизительным пользоваться ручкой или мелом, он всегда может сказать «До свидания» и искать другую компанию, более подходящую для его менталитета.
Если будет интерес, я поясню отдельные моменты подробнее
Необычное в вашем решении только одно — выбор стратегии кэширования. А именно — время жизни ответа в кэше определяется не на стороне сервера приложений, а в запросе клиента (live_time).
Было бы интересно рассмотреть этот момент подробнее.
Да. Но с одной маленькой поправкой, которую не все соискатели понимают. Если вас просят написать код на бумаге или доске, работодатель смотрит в первую очередь на ход ваших мыслей и умение их выразить, а вовсе не на код.
Кстати, а можете подсказать в каких современных Линуксах не встречается баш из-коробки, если не считать ембеддед варианты?
Коллега скорее всего просто напутал. bash везде есть, просто /bin/sh — не всегда линк именно на bash «из коробки». Скажем, в той же ubuntu — это линк на dash
Я не нашёл в сети целостной и эффективной программы становления специалистом. Но у меня было много идей на этот счёт. Поэтому решил написать данную статью.
Книги читайте. Я предполагаю, что по Дейкстре, Бруксу или Томасу с Хантом нет видеоуроков, но надо же когда-нибудь и напрячься.
Вообще, советуемый вами порядок получения информации (1. Видеоуроки, 2. Мультимедиа 3. Книги (тяжелы для восприятия, оставить на потом)) о многом говорит. К сожалению, новички могут принять это за чистую монету и поверить.
Да, безапеляционно, возможно. Но честнее и гораздо ближе к реалиям, чем слезливые истории успеха молодых стартаперов. И гораздо ближе к реалиям, чем статья, написанная человеком, считающим html языком программирования и дающего 100% гарантию успешного обучения по своему методу.
Если речь идет о валидации — условно можно.
С регуляркой из вашей статьи мы можем ошибиться с проверкой и отсечь верный email. Не особо страшно, тем более, что этот адрес будет достаточно экзотический.
С этой регуляркой мы почти все неверные адреса считаем верными. На мой взгляд такой подход — хуже.
Ну а если речь идет о поиске в тексте (как в вашей статье) — эта регулярка совсем не годится.
Вы в статье рассматриваете абстрактные примеры валидации email, и именно в этом абстрактном контексте я и беседую. Поэтому не надо в рамках данной дискуссии подменять абстрактную задачу на какую-то конкретную.
Поясню. Примеры с Яндексом и т.д. совсем не в тему. Это примеры систем со своими требованиями и ограничениями к формату email адреса и именно эти свои требования они проверяют. Это пример как раз конкретной задачи с определенными ограничениями.
Поэтому если бы в вашей статье пример выглядел так:
«Давайте проверим email пользователя Яндекс — логин может состоять из латинских символов, цифр, одинарного дефиса или точки. Он должен начинаться с буквы, заканчиваться буквой или цифрой и содержать не более 30 символов.»
то мне был бы понятен ваш аргумент, однако в таком случае и этой дискуссии бы не было.
Вы же в статье пишите о RFC
и якобы (примеры по ссылке — тоже работают неправильно) существующей возможности проверки email адреса регулярным выражением. Без какой-то конкретики о постановке задачи. Абстрактно. Я вам указал на то, что это — ошибка и что тему «валидация email регулярным выражением» было бы правильно пометить в главу «Какие задачи не решаются регулярными выражениями».
А правильные типовые решения скорее всего такие:
Невозможно проверить адрес e-mail на допустимость с помощью регулярных выражений
или
Прекратите проверять Email с помощью регулярных выражений!
"name with spaces"@example.comВообще, imho не надо учить новичков проверять email regexp-ами.
Мой ход мысли:
У автора нет возможности скачать файл с сервера БД.
Как следствие — возможности залить файл на сервер БД тоже нет.
Как следствие — web приложение развернуто на другом сервере.
Как следствие — web приложение соединяется с удаленным сервером БД.
Как следствие — для того, чтобы сделать дамп базы, web приложение не нужно
Вы нанимаете, он рисует, вам не нравится, но время потеряно.
Знаете, почему статья не заставила даже задуматься о возможности такой работы? Вроде все правильно и красиво, свобода, все дела… Но два момента смутило.
Начало статьи шоковое. Два месяца «много обсуждать» свои отличия во время работы над проектом? Действительно — свобода.
Хайп — хайпом, но тема не раскрыта. Вы подаёте пример так, как будто необходимость Agile и Scrum-мастеров — это данность, не подвергаемая сомнению. А на самом деле это вопрос спорный и решаемый в каждом случае индивидуально. Я понимаю, что главное в вашем примере — способ решения вопроса (и он хорош, реально хорош), но, честно говоря, для меня показательнее было бы описание условий, при которых вопрос необходимости scrum-мастеров вообще встал перед вами.
Кстати, мое начальство в свое время очень вдумчиво изучило этот вопрос и пришло к выводу, что agile нам не подходит, а scrum-мастера занимаются в основном профанацией за немалые деньги. Так и живем без agile. Значит ли это то, что я работаю в условиях меньшей «свободы»? Думаю, что нет.
Тестовые задания (простые, совсем простые) даются для того, чтобы появилась тема для разговора, не более. Гораздо легче обоим участникам процесса обсуждать особенности решения тестовой задачи, чем на пустом месте придумывать вопросы и отвечать на них.
Вообще, подумайте сами — это же абсурд! Зачем придумывать поводы придираться? Ведь компании нужен специалист. Компания заинтересована его найти в максимально короткое время и закрыть вопрос. А вы описывайте ситуацию так, как будто техническим специалистам работодателя больше делать нечего, как придираться и футболить соискателей.
Ну а если кандидат считает для себя унизительным пользоваться ручкой или мелом, он всегда может сказать «До свидания» и искать другую компанию, более подходящую для его менталитета.
Необычное в вашем решении только одно — выбор стратегии кэширования. А именно — время жизни ответа в кэше определяется не на стороне сервера приложений, а в запросе клиента (live_time).
Было бы интересно рассмотреть этот момент подробнее.
Да. Но с одной маленькой поправкой, которую не все соискатели понимают. Если вас просят написать код на бумаге или доске, работодатель смотрит в первую очередь на ход ваших мыслей и умение их выразить, а вовсе не на код.
Ну и там же хороший раздел «Client quorum in replica 2 volumes»
В общем с отказоустойчивостью как-то не очень получилось.
Вообще, советуемый вами порядок получения информации (1. Видеоуроки, 2. Мультимедиа 3. Книги (тяжелы для восприятия, оставить на потом)) о многом говорит. К сожалению, новички могут принять это за чистую монету и поверить.
Выясню завтра эту тонкость у нашего HR, если вам это действительно интересно.