GTRxShock

jQuery Ajax + PHP + PHPExсel(библиотека такая)

не знаю зачем тут пацаны советуют чистый код Р. Мартина
https://www.ozon.ru/context/detail/id/5011068/
вот что нужно на замену
https://www.ozon.ru/context/detail/id/138437220/
есть обе у меня, но красненькую купил раньше. в ней больше информации как внешне так и по сути.

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

во многих конвенциях о code-style указываются очень грамотные вещи, и они не просто так там находятся. в общем смысл такой - код должен быть самодокументируемым/самоописательным, а комментарии к коду не должны быть в стиле "моё почтение, капитан!".

• код должен напоминать хорошую прозу.
  
• комменты описывают намерение (зачем?) а не реализацию (как?).
• прими во внимание время жизни переменной. чем ближе переменная к "месту военных действий" тем лучше. перекликается со временем жизни переменной - чем быстрей "умирает" тем лучше, часто можно даже без переменной обойтись не в убыток читаемости.
  
• люди советуют тут ограничиваться конкретным числом строк. имхо - вредный совет. метод не должен ограничиваться. метод должен быть такой длины, которая требуется. иногда без "супер-методов" не обойтись (это не о функциях на 100500 входящих параметров), невозможно просто разбить тяжелую функцию на более мелкие куски, не умножив число запоминаемых переменных/других методов. метод может быть в 3 строки, может быть даже в одну, а может быть в сто-двести строк и более. если из метода ничего нельзя выбросить и нечего добавить - значит он в точности занимает столько сколько нужно.
  
• многословие приветствуется но без фанатизма. машине почти всё-равно какой длины у тебя функция (если вы понимаете о чем я), а для тех кому нет - есть минификаторы (для js например)
  
• название метода должно однозначно говорить о его назначении. спрашивай себя - зачем этот метод? зачем это свойство? если ты не можешь ответить значит и запомнить/вспомнить не сможешь, значит у метода/свойства нет конкретного предназначения и потом (через какое то время) будет сложно разобраться для чего он вообще нужен.
  
• визуально отделяй приватные/публичные методы. это тоже некоторая подсказка которая помогает разбираться в коде.
  
• следуй одному стилю как минимум в отдельно-взятом файле. (кемелкейс отдельно, лодаш отдельно).
  
• следуй принципу наименьшего удивления (программиста). т.е. поменьше роялей в кустах
  
• соблюдай абстракции. если класс это не просто набор статичных методов - значит он описывает какие то действия вполне определенного объекта. не раздувай и не разбивай на несколько классов одну цельную и четкую абстракцию. это поможет сосредоточиться на отдельном куске кода в один момент.
  
• старайся не писать рядом в одном классе методы, которые "проникают" во все аспекты приложения (антипаттерн - суперкласс/божественный объект).
  

вообще стоит почитать про паттерны и антипатеррны, это конечно не библия но знать хотя бы основные стоит.

на проектах от среднего. но! есть проблемы с серверным рендерингом. но судя по инфе это решаемо. в остальном нерешимых вопросов не заметил. скорость если уметь готовить можно поднять. тк из коробки там не настроено ничерта почему то. вообще пописав на фреймворке(не на библиотеке), понимаешь что сайт на чистом js или jq это треш, но кому то нравится. хотя судя по stackoverflow люди и на ангуларе треш умеют делать
видимость элементов это мелочь. роутер всего лишь разруливает навигацию по сайту . без нее банально никак. просто вынесено в отдельные модули чтобы люди выбирали кому какой нравится. но есть и резолвы и дочерние вью и еще разные плюшки

Энциклопедия профессора Фортрана

https://youtu.be/XQM0K6YG18s?t=16m46s смотреть с 16m46s

https://habrahabr.ru/post/231071/ Всё ещё актуально

Скажите, реально ли по codewars прокачаться по js

Реально.

Скажите, реально ли по codewars прокачаться по js до уровня среднестатистического front end разработчика?

Нереально, ибо к front end разработке он никаким боком не относится.

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

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

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

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

Теперь задумаемся о декомпозиции всего этого хаоса. Мы находим какую-то задачу, которую выполняет наш код (например какую функцию вызвать для обработки каждого конкретного запроса) и выносим это в отдельный объект. Отправка email-ов - отдельный объект. Весь SQL зашиваем в отдельный объект. Соединение с базой - объект. Пользователи - объекты. Все - объекты.

И главное, у каждого объекта есть своя область ответственности. UNIX way. Каждый объект делает что-то одно и делает это хорошо. Бывает так что ну... нужно сделать так что бы один объект делал две вещи. НЕ вопрос, мы можем его попросить сделать что-то сложное, а он будет как хороший менеджер тупо делегировать работу другим объектом. То есть он и сложную штуку сделает, и сам не будет знать как она делается.

А все безхозные функции, которые не пренадлежат никаким объектам (например функции порождающие объекты) можно вынести в статические методы. Главное что бы статичесих переменных у нас небыло (ибо это те же глобальные переменные). И поменьше публичного ибо черт его знает что эти разработчики будут использовать. Причем "те разработчики" это вы завтра.

Вообщем писав всё время на процедурке, сложно перейти на ооп.

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

Вы можете начать погружаться в ООП с того, что разобраться "почему глобальные переменные это плохо", почему "состояние порождает сложность" и что такое эта "сложность" (многие почему-то думают что сложность выражается в написании кода а не в его чтении или поддержке), почему "изоляция" (и как следствие инкапсуляция) - это хорошо. Как это все соотносится с декомпозицией. Что такое "ответственность", что такое зависимости, связанности

Подскажите, какой проект начать писать (гостевая, блог), или может начать изучать фреймворк.

Фреймворки универсальны, а значит чистого ООП там быть не может. Во всяком случае нет ни одного фреймворка на котором стоит учиться ООП.

Есть хорошие упражнения на развитие понимания объектно-ориентированного проектирования. Например вот: https://habrahabr.ru/post/206802/

Сразу хочу отметить что это крайности. Упражнения же. Они должны ограничивать вас что бы заставлять думать и задавать правильные вопросы.

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

Так вы научитесь делать один конкретный проект а на втором вы уже проиграете. Так дела не делаются. Надо разобраться с причинами появления идеи ООП. Ну то есть что было до. Можно еще с функциональным программированием попробовать разобраться. В PHP оно слабо применимо, но основные идеи очень тесно переплетаются с ООП и познав немного функциональщины ваше ООП будет лучше. Да и если про ООП вы можете найти много булшита, про функциональщину врут мало.

https://prerender.io/

Подойдёт?

Шаг 1, изучаем https://jwt.io/ - на настоящий момент стандарт для аутентификации.
Шаг 2. Каждое устройство должно иметь уникальный токен. Пользователь должен иметь возможность деавторизовать любое устройство. При смене пароля все токены автоматически стираются.

Организация хранения токена должна выглядеть примерно так:

tokens
- user_id
- device_id  - при авторизации через браузер можно подставить md5(User-Agent)
- device_name  - человеко-понятное имя девайса или название браузера
- token
- last_used
- expires_at

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

1. Никаких сеттеров. Entity всегда дожна быть валидной (установка значений через конструкторы, именованные контсрукторы). Если нужно менять состояние - делаем осмысленные методы, типа:
   

   public function updatePassword($plainPassword, EncoderInterface $encoder) {
       //...
   }
   public function updateProfile(UserProfile $profile) {
       //...
   }

   
   
2. Вадидация должна происходить в приложении на более высоких слоях. (Валидируем request, command и прочее).
   
3. Очень удобно использовать Embedded-object (doctrine-orm.readthedocs.io/projects/doctrine-orm/... в качестве Value-objects.
   
4. flush() всегда делаем в контроллере (в верхнем слое приложения) и забываем про такую конструкцию $em->flush($myEntity); Суть такая: наше приложение работает с бизнес-объектами (domain-objects), меняет их состояние, однако про сохранение (коммит изменений) слой модели не должен знать, это не его задача. Все изменения фиксируются в конце запроса.
   
5. Используйте Domain-events - очень удобная штука.
   
6. Иногда очень полезно отказаться от автогенерации доктриной id, можно использовать uuid.
   

И дострина многим не нужна, часто достаточно active-records.
Doctrine даёт большой профит только если доменна логика сложная, ну все это хорошо ложится на проектирование по модели (DDD).