Денис Сепетов

1. Это дополнительный источник истины - того, как должна работать программа.
А значит и меньше споров о том что является багом, а что фичёй, и почему что-то было сделано так, а не иначе.

2. Это упростит онбординг новых членов команды - вместо того чтобы тратить кучу времени на устный рассказ о продукте - можно просто показать инструкцию.

Сортировка настраивается посредством свойства sort дата провайдера

$dataProvider = new ActiveDataProvider([
     'query' => $query,
     'sort'=> [
     'attributes' => [
            'age',
            'name' => [
                'asc' => ['first_name' => SORT_ASC, 'last_name' => SORT_ASC],
                'desc' => ['first_name' => SORT_DESC, 'last_name' => SORT_DESC],
                'default' => SORT_DESC,
                'label' => 'Name',
            ],
        ],
 ]);

Заполните массив attributes параметрами по которым вам необходимо сортировать, и далее передавайте данные параметры через get строку запроса в виде ...?sort=-name

В целом, понимайте схемы как пространства имен. Схемы помогают логически организовать структуру БД. Различные приложения или компоненты приложений внутри себя имеют более высокую связность, чем между собой, тоже самое и с данными в БД - часто таблицы сами по себе организуются в логические группы, причем внутри группы связей довольно много (внешние ключи, какие-то общие хранимые процедуры и т.д.), а между этими группами - мало или нет вовсе.

Важно понимать, что различные БД плохо подходят для логического группирования, т.к. разбиение по базам данных нужно скорее для администраторов, а не для приложений. Плюс, в большинстве СУБД, где существует понятие схемы, возможно ставить внешние ключи на таблицы в другой схеме, но нельзя на таблицы в другой БД. Иными словами, отдельные БД удобно создавать тогда, когда вы разделяете данные абсолютно не связанных приложений или сервисов. Например, складского учета и форума поддержки пользователей. С другой стороны, если вы хотите логически разделить таблицы в соответствии с компонентами одного приложения (например, корпоративный портал: 4 таблицы для поддержки авторизации, 10 таблиц для поддержки форума, еще 5 для чата со службой поддержки или отделом продаж) - то именно схемы будут удобным механизмом для этого.

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

А что будет если несколько юзеров будут на одну public-схему коннектиться?

Помимо того, что схема - это пространство имен, в большинстве СУБД это еще и пространство безопасности. Даже в рамках одного многокомпонентного приложения имеет смысл ставить границы безопасности для ограничения возможных потерь и разрушений в случае компрометации одного из компонент.

Вот допустим, у вас есть отдельная схема для таблицы авторизации и аутентификации и отдельная - для корпоративного форума. Сервис авторизации у вас выполнен отдельно от форума (например, авторизация выдаёт токены пользователю, с которыми он потом может зайти на форум). С точки зрения безопаности было бы логичным выдать сервису авторизации и форума различных пользователей в базе - тогда, при взломе форума невозможно будет получить доступ к паролям в базе или изменить права на портале, подправив данные в таблице ролей. Конечно, многие СУБД разрешают ставить права на отдельные таблицы, однако схема в данном случае играет роль контейнера и позволяет проставить единые правила для всех таблиц внутри неё.

то есть при работе в постгре предпочтительнее вместо отдельных баз делать разные схемы в одной

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

Вот вам еще хороший пример. У вас есть приложение для ведения бухгалтерии и складского учёта на фирме. При этом сложилось так, что вам нужно хранить на одном сервере данные нескольких разных фирм (например, вы предоставляете готовый сервис под ключ нескольким клиентам). В этой ситуации более чем логично хранить данные разных клиентов в разных БД, а данные бухгалтерского и складского учета - в различных схемах в рамках одной БД конкретного клиента.

Все зависит от целей - для себя (если ты разработчик или занимаешься внедрением кем то написанного) и своего успокоения или для отчетности и сертификации.

Если первое - почему нет, есть компании, гугли, тем более твой проект достаточно маленький, есть даже фрилансеры, предлагающие такие услуги... качество результата в любом случае будет рандомное и почти не зависящее от стоимости (но можно поговорить с несколькими независимыми специалистами, так сказать брать количеством а не качеством). Так же потребуется соответствующий уровень знаний чтобы хотя бы понять ответ и главное сделать соответствующие выводы и выбрать последующие действия, что будешь делать если тебе скажут - 'код говно, дырявый, глючный, вот тут бизнеслогика сломается и т.п. проще переписать чем исправлять'?

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

Для хранения данных в браузере рекомендую использовать не localSrorage, а специальную обертку localforage:
https://html5.by/blog/localforage/
И тогда не придется загонять себя в 4 мегабайта, сможете записывать данных столько, сколько нужно.

По сайту же, вам по факту надо написать PWA приложение - это такой специальный веб-сайт, который может работать офлайн, без интернета. Подробнее здесь:
https://yandex.ru/search/?text=%D1%81%D0%BE%D0%B7%...

Вам нужно копать в сторону сервис воркеров и работы оффлайн с ними.

Валидация, масштабируемость и юзабилити, это как бы совсем разное.

Для юзабилити - валидация на фронте. Введя что-то невалидное пользователь должен видеть проблему сразу, а не когда закончит заполнение формы, и отправит всё на бэк.

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

Для гибкости - контроллер валидирует только соответствие структуры запроса (ругается что не хватает значений, или ожидали данные в одном формате, а пришли в другом). Сами данные в процессе обработки оборачивать в самовалидируемые ValueObjectы, которые при создании будут уже проверять данные на соответствие более специфичным требованиям.

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

И т.д. и т.п.

https://github.com/zadam/trilium или Mediawiki

нашел таки, черт его занет как, но может кому-то пригодится https://tech.yandex.ru/maps/doc/jsapi/2.1/dg/conce...

cd /etc/resolvconf/resolv.conf.d
sudo cp -p head head.orig  #backup
sudo nano head

дописал в конец:

nameserver 8.8.8.8
nameserver 8.8.4.4

ctrl+x

sudo resolvconf -u
проверить:
sudo vi /etc/resolv.conf

Раз тут все такие зануды - нашел решение сам:

С помощью iwconfig смотрим название своей сетевухи. Моя - wlp3s0.

root@ubuntu:~# iwconfig
wlp3s0    IEEE 802.11  ESSID:"xxx.ru"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 40:4A:03:78:19:E4
          Bit Rate=150 Mb/s   Tx-Power=20 dBm
          Retry short limit:7   RTS thr=2347 B   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=68/70  Signal level=-42 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:9   Missed beacon:0

enp0s7    no wireless extensions.

lo        no wireless extensions.

Скорее всего в роутере используется шифрование WPA/WPA2. Поэтому качаем и устанавливаем пакет wpasupplicant (sudo apt-get install wpasupplicant).
Создаем файл-конфиг с помощью touch /etc/wpa_supplicant.conf и вносим туда название вашей сетки и пароль к ней:

network={
    ssid="ssid_name"
    psk="password"
}

После пишем путь к вашему конфигу для пакета, который недавно установили: sudo wpa_supplicant -B -iwlan0 -c/etc/wpa_supplicant.conf -Dwext.

wext - в запросе выше это выбор драйвера. Вбейте wpa_supplicant -h и увидите варианты драйверов:

drivers:
  nl80211 = Linux nl80211/cfg80211
  wext = Linux wireless extensions (generic)
  wired = Wired Ethernet driver
  none = no driver (RADIUS server/WPS ER)

Подставляйте разные варианты драйверов в sudo wpa_supplicant -B -iwlan0 -c/etc/wpa_supplicant.conf -D до тех пор, пока ваши действия не подтвердятся успехом.

После пишем sudo dhclient wlp3s0, где wlp3s0 имя вашего устройства.

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

Оригинал мануала тут: https://askubuntu.com/questions/138472/how-do-i-co...

Фреймворков в целом, которые достигли должного уровня популярности и народного признания - не так уж много (если говорить о PHP-фреймворках).

Для начинающего, с целью понять сущность MVC, "пощупать" некоторые аспекты фреймворка, такие например, как загрузка библиотек и пр. подобности, я бы порекомендовал Вам CodeIgniter. Отличная документация, довольно много людей, кто сможет Вам ответить на возникающие вопросы, есть документация на русском. А так же, минимальное количество "лишнего" из коробки, например, шаблонизаторов (которые Вы можете самостоятельно подключить, если очень хочется).

После этого фреймворка, промежуточным, можно было бы считать Kohana, но, он что-то то "умирает", то снова "воскресает"... С документацией на него, по моему, всё так же плохо (читай "не очень хорошо") как и всегда... но, по нему есть несколько неплохих видео-уроков.

Суда же можно отнести Yii, на мой взгляд, он застрял где-то между "большими" и "маленькими" фреймворками. Маленьким его уже не назовёшь, по ряду признаков, а до большого и целостного - он ещё не дотягивает. Но, он довольно популярен на просторах бывшего СССР (по понятным для многих причинам), в виду чего имеет довольно большое русскоговорящее сообщество и целую толпу ярых фанатов.

Далее, в обязательном порядке будет идти Laravel - превосходная документация, примеры и фантастическое количество видео-уроков (если хорошо понимаете английский). Отличный фреймворк собранный на базе Symfony. Относится уже к "большим".

Ну а когда станете совсем матёрым программистом, и "лишний" код будет писать уже не в моготу, когда изучите все основные аспекты разработки, в том числе "сервис контейнеры", "внедрение зависимостей", будете понимать основные сетевые протоколы на низком уровне... а качество и разделяемость кода - будет одним из приоритетных условий - рекомендую обязательно ознакомиться с Symfony. Уроков по нему, довольно небольшое количество, вменяемого материала на русском языке - практически нет вообще... Но, достаточно легко изучается когда есть хороший багаж знаний и опыт работы с другими фреймворками.

P.S. Я понимаю, что Вы спрашивали "какой фреймворк учить первым?", а не какие они бывают вообще. Но, дабы предостеречь Вам от вопросов типа "какой фреймворк учить вторым?" или "почему Symfony в роли первого фреймворка так тяжело изучать?" и массы прочих подобных - озвучил одни из самых популярных фреймворков в мире веб-разработок в ракурсе PHP.

можно