Дмитрий

https://docs.oracle.com/javase/7/docs/api/java/lan...

https://stackoverflow.com/questions/4003989/upload...

Ты веcь такой кругом молодец, то знаешь, это знаешь. А теперь представь себе среднестатистический проект, который должен приносить бизнесу деньги. За две недели работы ты едва напишешь хлипкий CRUD для данных, неправильно смаппив бизнес-сущности в объекты ORM, ещё через месяц натянешь какой-то слайдер на jQ, попутно захватив 2мб JS кривых библиотек, а через два заказчик поставит тебе плохую оценку, потому что твой ценник он оплатил не за то, что ему нужно, а потому что ты знаешь монады, которые ему даром не сдались.

А теперь давай представим простого программиста. Из алгоритмов он с трудом вспоминает сортировку пузырьком, а двусвязный список — предел его знаний о структурах данных, и даже этим списком он пользовался два раза в жизни. Хаскель он никогда не видел в глаза, C++ учил только в школе, вместо этого пишет неэффективный код на PHP. И у него есть опыт. За день он распишет сущности, за второй сделает универсальный CRUD, на третий день поднимет фронт на React'е с SSR. Да, внутренности проекта будут "медленными". Вместо O(logN) что-то будет выполняться за O(N) или даже O(N^2), но всем похер. Пока всё работает на приемлемом уровне — бизнес радуется.

Кстати, к чему эта поучительная лапша? Я хотел сказать, что всеми этими модными словами можно пугать друзей и преподавателей, но в реальной жизни все алгоритмы уже реализованы, все типы данных уже подобраны оптимально. Знать их полезно для себя (чтобы мозг не атрофировался), но не для работы. Для работы тебе нужны такие навыки как:

* Оптимальный баланс между говнокодом и идеальным кодом
* Оптимальный баланс между скоростью разработки и оптимизацией кода
* Оптимальный баланс между поддерживаемым кодом и костылями
* Умение использовать те инструменты, с которыми ты работаешь. Опять же, для того, чтобы писать быстро, при этом имея минимальное количество говнокода и обеспечивая максимальную поддерживаемость (в пределах сроков). Например, можешь выкинуть в помойку свой Vim, как бы круто ты себя не чувствовал, разрабатывая в консольном редакторе, если продукты от JetBrains позволят за это же время сделать что-то лучше или чего-то больше
* Чувство "знаю больше менеджеров". Это то чувство, когда тебе кажется, что "вот эта фича скоро изменится" и надо сделать архитектуру заранее более гибкой. Или "вот эту фичу мы через месяц выпилим" и не надо тратить на неё силы — напиши костыль и через месяц с чистой совестью удали его
* Знания, как сделать ту или иную фичу. Потому что фичи повторяются (немного видоизменяясь) от проекта к проекту. И если ты сделал что-то за два дня, в следующий раз ты похожее сделаешь за три часа

Что касается инструментов, выбери любой полноценный фреймворк, который умеет решать 90%+ потребностей "из коробки": Symfony, Django, Laravel

Всякие "минималистичные" поделия вроде Falcon, Flask (в PHP не знаю, я на питоне пишу) оставь хипстерам. Пусть они говорят: "Мой фалкон такой быстрый, он написан на Cython". Тебя это не должно волновать, потому что бизнес с твоей скоростью разработки уже заработал достаточно денег, чтобы купить ещё десять серверов, пока фалконисты неделю гуглили, как прикрутить миграциии и запустить юнит-тесты на VPSке за пять баксов.

Ещё есть Tweaks, если установить, в ней есть Keyboard&Mouse, может быть там найдётся.

Статические члены существуют в одном экземпляре на всю программу. Зачем тебе отдельный пи на каждый твой объект?

Существует ли свежая литература по Java?
Стоит ли читать Thinking in Java?
Насколько актуально учить Java по книге Изучаем Java ( Кэти Сьерра и Берт Бейтс)?

логи, первым делом логи
так как опыта у вас мало - включите вывод ошибок в браузер

ini_set('error_reporting', E_ALL);
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);

для работы с файлами на сервере ВСЕГДА используются полные пути до папок, от корня сервера.

На вопрос невозможно дать однозначный ответ. Все перечисленные способы имеют право на жизнь в тех или иных ситуациях, но:
1) Я бы не советовал захламлять излишне таблицу user, получите огромную кашу.
2) Json я бы рекомендовал только в исключительном случае, все-таки это уход от нормальных форм.
3) Наиболее каноничным является вынесение настроек в отдельную таблицу вида user_settings(user_id, setting1, setting2, ...).

Касательно уведомлений - так как уведомления собой представляют чаще набор, то каждое отдельное уведомление вписывать в таблицу с настройками конечно можно и удобно, но не совсем по феньшую. Если пунктов уведомлений не так много, то можно их вписать прям в таблицу настроек, то есть вроде этого user_settings(user_id, setting1, setting2, ..., notification1, notification2, ...). Но этот вариант не является гибким, потому что к примеру для каждого отдельного уведомления могут в дальнейшем потребовать настройки(например приоритет уведомления). Поэтому наиболее правильным будет завести одну таблицу для настроек профиля как указано выше, а вторую таблицу для уведомлений вида user_notifications(user_id, notification_id, notification_name, priority, ...). Так все будет очень гибко и будет соответсвовать нормальным формам.

https://www.php.net/manual/ru/function.idn-to-utf8.php
либо google -> php punycode

после получения из гет номера страницы, ансетим пэйдж в гет, после чего в пэйджинге прибавляем

<a class="page" href="?page=2&<?=http_build_query($_GET)?>">2</a>

sscanf()

$str = '921205400655';
list($year, $month, $day) = sscanf($str, "%2d%2d%2d");
if ($year > 30) $year = 1900 + $year;
else $year = 2000 + $year;
$date = sprintf("%04d.%02d.%02d", $year, $month, $day);

echo $date; // 1992.12.05

Это называется клавиша delete

Попробуйте
$textrows = explode(PHP_EOL, $_POST['Имя поля']);
Получите массив. Переберете, добавите в БД уж сами

Постоянно гуглю ошибки, лезу в документацию

похвально

это отнимает много времени, бывает полчаса над ошибкой сижу...

нормально

Когда это закончится?

никогда

Сколько лет пройдёт

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

Чтоб ты всё понимал, что происходит и вообще ошибок не было никогда

недостижимо

Замечу, что ошибки должны со временем меняться и ошибки, которые вы допускаете сейчас через год у вас не должны появляться
Вам нужен опыт и наработка памяти на стандартные конструкции