А если уж говорить про регулярку, то ее нужно просто правильно написать, сейчас похоже наугад накидали в нее что-то. Скорее всего нужно было так:
'/[а-яА-ЯЁёҚқӘәҺһІіҢңҒғҰұӨө\s]+/ui
Ну и как правильно заметели выше, зачем вообще это делать отдельно, а не сразу для всей строки?
User, просто следуйте правилу Single Responsibility. Выделяйте ответственности и заключайте их в отдельные классы.
Дмитрий, если придерживаться абрстракций при разработке, то все равно получится слой похожий на репозиторий.
Часто ли вам приходилось менять СУБД, если говорить про классические? В сложных проектах это в любом случае сложно, в простых нет нужды.
tukreb, Dark_Dante, вы договоритесь между собой. Всё таки === или == (он же empty), в новом коде, который автор пишет прямо сейчас. Что все таки выбрать?
Николай Савельев, в смысле алгоритмов и структур данных много. Допустим оценка сложности алгоритмов, это понятно, но по самим? К примеру:
1) Соискатель забыл сортировку пузырьком. Просто потому, что никогда ее не применял и применять не будет. Он не знает алгоритмы?
2) Соискатель имеет общее представление о B-Tree, но не вспомнил, чем она отличается от B+ Tree. Он не знает структуры данных?
3) Соискатель, писал парсеры математических выражений. Знает, что для перевода в постфиксную систему нужно использовать сортировочную станцию, но не смог воспроизвести ее алгоритм. Он не знает алгоритмы?
Вячеслав Правильный, разумеется хранить в собственной памяти приложения будет быстрее, чем обращаться к внешней СУБД. Другое дело, далеко не факт, что это будет узким местом. А узким местом может оказаться получение данных из внешних источником, даже при асинхронных неблокирующих запросах. А еще данные как-то надо отдавать дальше, причем пока не ясно как. И все это будет делать одно приложение. Вполне вероятно оно справится, если его правильно написать, но при необходимости масштабироваться, придется менять архитектуру.
LoliDeveloper, нет, так не получится. Для такого клиент должен уметь распараллеливать запросы, да еще и на разные интерфейсы, steam так делать не будет, впрочем, как и другие клиенты.
Оптимальное, что вы можете сделать, прописать явно маршруты для тяжёлого трафика на широкий канал, а все остальное на узкий. В этом случае steam сможет забить полностью канал в 6мбс, а 0.5мбс будете использовать для сёрфинга в инете, и они не будут друг на друга влиять.
Просто балансировщик ставить не стоит, из-за огромной разницы каналов будут проблемы.
Ничего, странного, в доке прямо написано, что переменные передаются по ссылке. Соответственно, если в foreach вы не будете переменную передавать по ссылке, все ваши bindParam свяжутся только с переменной foreach и все будут иметь значение одно и то же, последнее, которое foreach положит в эту переменную.
Реально. А что не получается то? Если не запрашивать номер дома, т.к. он у вас и так уже есть, то вообще элементарный запрос. Если запрашивать, то MySQL вполне сможет join по функции с json.
RobbyKey, ну вот, теперь уже arecord не может найти файл. Или формат неверный, исходя из сообщения. Если вдруг из консоли работает, значит проверяйте какие переменные окружения arecord задал дополнительно.
/bin/bash: /bin/bash: cannot execute binary file in crontab?
вы передаете в bash как параметр /bin/bash, т.е. бинарный файл, а он ожидает скрипт. Сложно сказать как вы этого добились, но лучше пропишите точный путь до bash:
*/2 * * * * /bin/bash /home/raspi/script.sh >> /tmp/script.log 2>&1
И как указано выше, внутри скрипта тоже укажите полные пути.
прежде чем читать про ajax прочитайте, что такое клиент-серверное взаимодействие, что является в вебе клиентом, что сервером, где выполняется php, где js, и как и где используется резултат работы первого и второго.
'/[а-яА-ЯЁёҚқӘәҺһІіҢңҒғҰұӨө\s]+/ui
Ну и как правильно заметели выше, зачем вообще это делать отдельно, а не сразу для всей строки?