Как веб-программирование отличается от программирования бэкенда?
Вы должны искать строку ://, (Положительный взгляд за спиной), если она входит в строку, значит, это домен, и вам нужно захватить все после этого. Имеет ли он @ или нет.
Случай 1
Захват всей строки после ://
Регулярное выражение: (?<=\:\/\/).* [1156 ]
Объяснение:
Positive Lookbehind (?<=\:\/\/) Assert that the Regex below matches \: matches the character : literally (case sensitive) \/ matches the character / literally (case sensitive)
[119 ] .* matches any character (except for line terminators) * Quantifier — Matches between zero and unlimited times, as many times as possible, giving back as needed (greedy)
Пример https://regex101.com/r/jsqqw8/1/ [ 1129]
Случай 2
Захват только домена после ://
Regex: (?<=:\/\/)[^\n|\/|:]+
Объяснение: Positive Lookbehind (?<=:\/\/) Assert that the Regex below matches
[1142] : matches the character : literally (case sensitive) \/ matches the character / literally (case sensitive) \/ matches the character / literally (case sensitive) Match a single character not present in the list below [^\n|\/|:]+ + Quantifier — Matches between one and unlimited times, as many times as possible, giving back as needed (greedy) \n matches a line-feed (newline) character (ASCII 10) [1121] | matches the character | literally (case sensitive)
] \/ matches the character / literally (case sensitive) |: matches a single character in the list |: (case sensitive)
Случай 3:
Захват домена после ://, если нет @ в тексте, и если @ присутствует в тексте, запишите текст после этого.
Регулярное выражение: (?!:\/\/)(?:[A-z]+\.)*[A-z][A-z]+\.[A-z]{2,}
Объяснение:
Negative Lookahead (?!:\/\/)
Assert that the Regex below does not match
: matches the character : literally (case sensitive)
\/ matches the character / literally (case sensitive)
\/ matches the character / literally (case sensitive)
Non-capturing group (?:[A-z]+\.)*
* Quantifier — Matches between zero and unlimited times, as many times as possible, giving back as needed (greedy)
Match a single character present in the list below [A-z]+
+ Quantifier — Matches between one and unlimited times, as many times as possible, giving back as needed (greedy)
A-z a single character in the range between A (index 65) and z (index 122) (case sensitive)
\. matches the character . literally (case sensitive)
Match a single character present in the list below [A-z]
A-z a single character in the range between A (index 65) and z (index 122) (case sensitive)
Match a single character present in the list below [A-z]+
+ Quantifier — Matches between one and unlimited times, as many times as possible, giving back as needed (greedy)
A-z a single character in the range between A (index 65) and z (index 122) (case sensitive)
\. matches the character . literally (case sensitive)
Match a single character present in the list below [A-z]{2,}
{2,} Quantifier — Matches between 2 and unlimited times, as many times as possible, giving back as needed (greedy)
A-z a single character in the range between A (index 65) and z (index 122) (case sensitive)
Пример :
https://regex101.com/r/jsqqw8/4
12 ответов
Веб-приложения обычно чувствуют себя подобно единственным потоковым приложениям как Вы - разработчик приложений - редко создает собственные потоки. В любом случае это на самом деле намного легче, потому что природа не сохраняющая состояние веб-транзакций означает, что необходимо загрузить данные для страницы каждый раз от базы данных. Поэтому Вы не должны волновать по поводу параллелизма, с тех пор 'независимо от того, что там', обычно достаточно хорошо.
Самой большой проблемой с веб-разработкой является все фоновое знание, что необходимо накапливаться со временем. Как Вы размечаете веб-страницы? Как Вы разрабатываете вещи с CSS? Как Вы получаете параметры от строки запроса? Как Вы проверяете значение поля в JavaScript? Все те вещи на самом деле действительно легко изучить, но существуют именно так многие из них, что это может быть реальная боль.
Самая сложная задача с веб-программированием имеет дело с состоянием. HTTP является протоколом без сохранения информации о состоянии. Это может сделать состояние поддержания более сложным, чем в настольном приложении. Веб-приложения имеют тенденцию иметь другой жизненный цикл из-за этого. Каждая платформа веб-разработки имеет дело с этим несколько по-другому, но они все должны иметь дело с нею в некотором роде.
Программирование бэкенда бесконечно легче, чем веб-программирование. (Вас предупредили!) Веб-программирование является самым легким представить всем.
Самые большие ловушки, которые я засвидетельствовал, что Разработчики приложений делают, когда перемещение в сеть не рассматривает затраты на их код. Или они злоупотребляют MySQL к слишком точке срывания RDBMS, они пишут код, который использует слишком много памяти, или они делают страницы фронтэнда, которые являются к большому для помещений в коммутируемый доступ/сотовые телефоны или нижний уровень broadband/dsl конвейер.
Иногда это не может быть, избегают в письменной форме мощной страницы, но соображения могут быть сделаны попытаться кэшироваться как можно больше или при записи страницы, которая будет поражена много, они не приложат усилия, чтобы представить и оптимизировать запросы, прежде чем они пойдут наружу.
Не, что эти люди глупы, просто отсутствие опыта и осведомленности, что они должны играть по правилам и написать код, это несколько минимизировано.
Большинство веб-сайтов имеет компонент бэкэнда также. Типичная структура будет чем-то как:
- UI - html/css/javascript
- Контроллер - при использовании MVC
- Бизнес-логика / Сервисы - это - бэкенд
- База данных - это - также бэкенд
Так создание веб-сайтов будет все еще означать большую работу бэкэнда. В отношении UI основное различие - то, что у Вас должен будет быть хороший глаз для дизайна и расположения, чтобы сделать это хорошо. Технология html/css довольно проста сам по себе.
HTML был на самом деле разработан, чтобы сделать доклады физики. Можно все еще видеть его в некоторых старых метатегах. Во всяком случае различием является веб-программирование, разработка и толстого клиента не сохраняющего состояние, не.
Поскольку Вы умело указали, все управляемые событиями. Истинный JavaScript испачкал веб-разработку немного путем создания иллюзии среды с сохранением информации, но в конце все сводится к простому HTML.
Его никогда не слишком поздний, чтобы начать учиться, я сказал бы, начинают делать некоторые статические страницы HTML и перемещают Ваш путь до Платформы MVC, я предлагаю Microsoft MVC Framework. Его довольно фантастическое, существуют другие, которых Вы могли использовать как Веб-формы ASP.NET, но Вы ничего не изучите путем перетаскивания вещей на разработчика ;).
сеть и приложения GUI взаимодействуют через интерфейс с людьми.. приложения бэкенда взаимодействуют через интерфейс с сервисами и базами данных.. Как таковой Ваши спецификации должны включать значительное рассмотрение умственной модели Вашего пользователя - то, чтобы заставлять вещи вести себя, поскольку люди ожидают их к. И делая это - понимающий, как пользователи думают - не всегда легко или логично. У Вас могут быть изящные алгоритмические решения, которым просто не удается участвовать, потому что люди не всегда думают логически. Много раз, довольно изящный UI чрезвычайно скручиваются мудрые кодированием.. который очень противоречит системе-> системное программирование
В зависимости от пространства задач большая часть этого может быть большим количеством искусства, чем наука.
Одно соображение (среди многих) с веб-программированием состоит в том, что пользователи только будут глупы (не, что они все, но всегда необходимо включать это в), они иногда будут (принимать всегда) быть совершенно злонамеренными и противными, и сделают все, что в их власти для уничтожения приложения, базы данных, выходные, исправность...
Будьте столь же параноиками как очень маленькая монахиня в охоте пингвина. Не доверяйте своим пользователям.
Другое соображение состоит в том, что программирование Бэкэнда согласно Вашему определению легче протестировать.
После того как Вы начинаете веб-программирование, Вы во власти различных интерпретаций различных браузеров того же кода. Плюс пользователь, с исходными данными мыши и клавиатуры, имеет множество способов повредить то, что Вы производите.
Веб-программирование не является программированием бэкенда. Это показывает материал на фронтэнде, сети.
Вы определяете его иначе?
Править
Веб-программирование вытягивает Вас в представление данных последовательно, визуально, всем. Кодирование бэкэнда означает создавать те данные, таким же образом для презентации, но не представлять его.
На основе Вашего определения "программирования бэкэнда", Ваш вопрос применяется не только к веб-приложениям, но и к любому приложению GUI.
Это отчасти зависит, о каком приложении GUI мы говорим. Например:
- Внутренние бизнес-приложения имеют тенденцию включать большую логику рабочего процесса бизнес-процесса, ведение учета и совместимость между отдельными системами. Никакое воображение alorithms или перемалывание чисел не необходимы. Ваша аудитория ограничена, таким образом, производительность не является грандиозным предприятием, но межплатформенная совместимость важна, таким образом, они имеют тенденцию быть веб-приложениями. Ваши основные проблемы помогают связать бизнес-системы и сохраняют API разделенным на уровни, чтобы гарантировать, чтобы код GUI не имел дело ни с одним кодом бизнес-логики.
- Общедоступные сайты (такие как этот) имеют тенденцию включать меньше формальной архитектуры, и больше менталитета "просто заставляет эту замечательную функцию работать так, мы можем получить больше посетителей". Снова, никакое перемалывание чисел или алгоритмы, если производительность не является проблемой. Производительность является большим количеством проблемы для в широком масштабе популярных сайтов как Slashdot или Google, поэтому при предупреждении быстрого роста, это платит для разработки для масштабируемости заранее.
- Общедоступные веб-сайты электронной коммерции отчасти похожи на оба из вышеупомянутого: функции и производительность важны, но одинаково важный структурированная архитектура под ним, которая связывает все коммерческие бизнес-системы (покупка, поставщик, корзина, платежные шлюзы, и т.д.)
Для фактической части GUI сложность приложения отчасти определяет, насколько сложный код GUI будет. Для очень сложных, вложенных графический интерфейсов пользователя, где Ваши требования часто изменяются, легко попасть в прерывание помещения слишком большого количества материала GUI в одну страницу. Скоро страница превышает порог сложности большинства людей, делая страницу очень трудной поддержать. Это платит для размышления заранее, как можно разделить различные части GUI в отдельные компоненты и затем связать их. Если Вы плохо знакомы с программированием GUI, прочитайте некоторые статьи о шаблоне Образцового Контроллера представления (MVC).
Для простых веб-сайтов, где большинство страниц довольно статично, эта проблема не подходит так, потому что каждую отдельную страницу легко поддержать.
Большая часть веб-программирования сделана в стиле, популярном в начале семидесятых, прежде чем Dijkstra 'goto рассмотренный вредным' был известен.