Почему работает только первый массив?

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

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

Почему работает только первый массив?

SHNM, оператор return есть и в js и в php, ведут себя они одинаково.

Где я писал, что у меня стаж в пхп 5-6 лет? Где? Я написал, у меня стаж 5-6 в php, html, css, js.

лолшто? Стаж - это когда вы этим на хлеб зарабатываете. Пока вы учите - это не стаж.
Если вы пишете:

Я написал, у меня стаж 5-6 в -->php<--, html, css, js.

Это значит, что используя знания этих языков вы зарабатываете уже 5-6 лет.
Тут и речи быть не может про незнание синтаксиса.

Бывают ли майнеры и тд на Linux?

температура видеокарты - это может быть и проблема с железом.
что касается обновления - у вас LTS версия ОС?

Как улучшить данный код?

Ramil_ Bayramov_, основная фишка jQuery - селекторы. На момент своего создания основной альтернативой был обход DOM через getElement*. Собственно в этом и был основной прорыв.

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

Как правильно сделать валидаци формы?

SHNM,

ну типо ты не понял, у меня стаж 5-6 лет в пхп, html, css, js :)

почему же?)) Мне все ясно и очевидно.

Вам по моим аргументам есть что противопоставить?))

Как правильно сделать валидаци формы?

SHNM,

ну я явно не с 2007 года :) у меня стаж 5-6 лет

Странно, через 5-6 лет опыта вопросов об необходимости валидации на фронте возникать не должно... Особенно в связи с тендециями развития фронта и повсеместной разработке SPA.

та и стаж тут не как не влияет, есть люди, которые занимаются разработкой 3 года и знают больше, чем другие выучили за 13 лет

Согласен, важно качество опыта, с 2011 года я занимался только долгоживущими веб-системами в продуктовых компаниях. Собственно по этой причине я не обращаю внимание на то меньше, или больше писать.
Действительно важные метрики для кода:
- читаемость
- изменяемость
- переносимость
- связность/зацепление
- производительность
- тестируемость
и только в последнюю очередь лаконичность.
Хотите писать код, за который вас потом не будут проклинать другие инженеры используйте - свод правил: https://github.com/index0h/php-conventions Этот список мягко говоря жесткий, он не для сайтиков, но он очень экономит время, нервы и кровь из глаз на длительных проектах.

Как правильно сделать валидаци формы?

SHNM,

а смысл? Это можно сделать и на бэкенде, зачем тратить личное время, чтобы написать это чушь и на фронте? Смысла тут 0

Смысл в том, что бы не заставлять пользователя вводить все, потом получать ошибки и требовать от него все исправить. Если фронт делает проверки сразу - пользователь сразу же исправляет косяки. А сервер не обрабатывает зарнее не валидные данные.
Если фронт проверку обойти - в чем проблема, бэк все равно вернет 400 ошибку. Много вы знаете леюдей, которые регулярно пользуются dev tools браузера, или курлом?
Я занимаюсь веб разработкой с 2007го, а вы?

Как правильно сделать валидаци формы?

SHNM,

а смысл их два раза проверять? Смысла та нет все равно, лучше 1 раз проверит на back-end'e и все.

Прочитайте внимательно

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

Как доп ачивка - можно упростит вывод ошибок.

Как правильно сделать валидаци формы?

SHNM, Автор, вам нужно узнать ответ на вопрос, или быть забаненным?
Если первое - пожалуйста умерьте свой пыл и возвращайтесь к культурному разговору.
Если второе - продолжайте в том же духе, но это будет не долго.

Как правильно сделать валидаци формы?

SHNM,

ну вроде как, проверки на фронте тоже херня еще та, спокойно можно её обойти, уже обходил, чисто для проверки пробывал

Верно, именно по этой причине они обязатльено дублируются на бэке. Зато мы можем съэкономить на запросах на сервер, а так же более-улучшить пользовательский опыт, сразу показав косяки ввода.

FanatPHP,

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

Валидатор - такая штука, которую лучше по возможности не расширять и не усложнять.

Если честно, то мне дико нравится ларавелевский - краткий, мощный, ёмкий, гибкий.

Все очень зависит от того, с чем вы сравниваете и по каким параметрам. В рамках ko-ko-ko/php-assert я очень сильно угорел по производительнсоти, если по сравнению с нейтивными проверками ларавелевский вариант медленее хотя бы в 40 раз - это отличный результат. Например статику я использовал не из соображений удобства, а что бы не тратить время на вызов конструктора.
Лично я пропагандирую обязательную валидацию аргументов в каждом методе, это люто упрощает поддержку, но сложные валидаторы (особенно с декларативными настройками) тут не применимы, это слишком медленно.

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

Как правильно сделать валидаци формы?

FanatPHP, Для сложных форм, например с выбором либо поля А1 и А2, либо Б1, Б2 и Б3 вам так или иначе прийдется дополнять валидацию кастомщиной. В лучшем случае это будет в конкретном обработчике формы, в худшем - будем пытаться расширять валидатор.
В самом хреновом сценарии валидатор превратится в вундервафлю, содержащую и локализатор, и роутер, будет уметь в кэш сревера, сессии, какую-нить рекаптчу через гугловую либу, делать запросы для валидаци disposable почт, и т.д.

Как правильно сделать валидаци формы?

FanatPHP, часто фронт вполне резонно обязать выполнять базовые проверки введенных данных.
Полная проверка на бэке все равно будет присутствовать, но необходимость выводить список ошибок довольно часто пропадает. Пример: форма авторизации с логином и паролем часто требует не выводить ошибки типа "пользователь с таким логином не найден", или "не правильный пароль для пользователя", вместо этого с точки зрения безопасности правильней выводить "не правильный логин, или пароль". Для таких ситуаций вполне норм бросать исключение.
Если взять за основу пример автора, что у нас могут быть за ошибки? Не ожидаемые рассматривать не будем.
1. Не введена почта - фронт
2. Введенная почта не соответствует формату - фронт
3. Почта уже зарегистрирована - бэк
4. Почта в disposable списке - бэк
5. Не указано имя - фронт
6. Пароль не соответствует требованиям - фронт
7. Пароль не соответствует подтвержденному - фронт
Если на фронте обнаружена ошибка ввода - слать на бэк запрос не имеет смысла. Что имеем в итоге?
Ожидаемые ошибки на бэке (которых не на фронте) - это только проверка почты, одно поле. Для него добавить исключение вполне резенно. Если на бэке получили например не корректный пароль и почту - либо фронт не справился, либо кто-то с курлом играется, вполне нормально ответить первой обнаруженной ошибкой.

Как правильно сделать валидаци формы?

FanatPHP, не обязательно, это продуктовый вопрос, а не технический. Если продуктовое требование выводить все ошибки разом - действительно стоит выполнять полную проверку и аккумулировать ошибки. Если подобного продуктового требования нет - проще и лучше использовать исключения.

Как правильно сделать валидаци формы?

SHNM,

Вы хотите сказать, что это отличный вариант?

Не совсем, я бы исключения бросал. Для полей стоит выполнять проверку на существование, тип и уже дальше проверять значение.

Ведь можно так

Можно все что угодно. Правильно ли это - другой вопрос. Меньше писать - далеко не всегда лучше. DRY по которому бездумно текут многие инженеры тоже далеко не всегда стоит придерживаться.
min/max у вас не соотатствуют почте.

Как правильно сделать валидаци формы?

SHNM,

if (!isset($request['email']) || strlen($request['email']) == 0) {
        $errors[]['email'] = 'Email не указан';
    }

Рекомендую добавить еще одну проверку: is_string после isset. Следующий пример для 7ки бросит ворнинг, для 8ки - фатал.

?email[]=not&email[]=email

Что лучше выбрать для ведения базы клиентов - готовый движок или самопис?

Merk47, самопис часто значит как раз полностью на чем-то своем

Какого облачного провайдера выбрать в Украине?

Юрий, при том, что нет контроля и исполнения за тем, где именно хранятся данные юзверей, на територии страны, или нет.

Что должен включать в себя Framework?

66demon666,

надо досконально изучать нативный php

Это само собой разумеется

потерпел неудачу, ввиду неправильной архитектуры,

Вы не с той стороны едите шоколадный рогалик.
Архитектура строится на базе требований. Это не какая-то магия, которую делаешь и вдруг всем станет хорошо.

Пример 1 Роутер.
Роутинг по сути - это подбор экшна по пути.
Если путей всего пара штук - switch-case будет самым оптимальным решением.
Если путей много - строим дерево по ним и уже на этапе выбора экшна обходим дерево.
Если путей много, но хочется максимальной производительности - тут дорога в кодогенерацию, посмотрите symfony router.

Пример 2 Модель.
Модель буду рассматривать в контексте ORM.
Допустим вам требуются простенькие CRUD операции, тестами покрывать не нужно - берите ActiveRecord. Yii-шный. В ларке сделали очень пацавато. Главное - не делайте толстые модели и все будет хорошо.
Если вам нужно что-то по серьезней - берите Repository. Тут у вас уже выбор по меньше Doctrine, или Doctrine.

Может ли Golang заменить C/C++ в написании программ для железа?

P747

Например в PHP когда приходится дорабатывать чужой код особенно до версии 7, смотришь на метод в котором происходят операции с числами, понимаешь что сильно не хватает статической типизации.

Могу вас заверить, 5 летний код написанный на тяп-ляп на любом языке выглядит хреново)). До php7 юзались докблоки для описания типов.

Так же чтобы банально распараллелить приходиться использовать очереди.

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

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

В других языках на легаси были бы просто другие проблемы.

Как принимать оплату на сайте анонимно?

javedimka, многие ли мастера маникюрного сервиса работают по безналу через электронный магаз?))