В продолжении предыдущей темы, что база программирования важнее самого языка, покажу на примере Turbo Pascal 7.0, что такое объекты в объектно-ориентированном программировании. (Чтобы было понятно, ООП в Паскале появился в 1989 году в версии TP 5.5.)

Если начинать изучать объекты, например с PHP, то не будет понимания, что это вообще такое. Зачем, например оператор new, что такое поля или методы? Такие вещи воспринимаются как часть языка, а всё что внутри — чёрный ящик, где происходят какие-то скрытые процессы. Вообще ООП — это парадигма, то есть описывает вроде как только общие принципы, а конкретная реализация зависит от языка. Но, на самом деле ООП в итоге всё равно превращается в обычный исполняемый код. На мой взгляд важно понимать откуда он берётся.

Тут ещё проблема в том, что изучение ООП обычно начинают с размусоливания про иерархию объектов на примере уточек, птичек и прочей живности. В итоге вместо технического описания, получается невероятная абстракция, которую нужно ещё как-то перенести в реальный код.

Для новичков, которые только задумываются об IT, вопрос выбора первого языка программирования (ЯП) стоит достаточно остро. И это понятно — ведь языков очень много, а критерии выбора не такие очевидные.

Эта тема, безусловно, холиварная, поскольку опытные программисты дают советы через призму собственного жизненного опыта. Масла в огонь подливают менеджеры и маркетологи многочисленных контор, которые занимаются обучением. Такие давно уже не стесняются давать объявления, где обещают сделать востребованным супер-пупер программиста за 1, 2, 3 (подставьте любое число) месяцев. В качестве первого языка предлагают что угодно, приводя в качестве аргументов некий рейтинг популярности или даже количество меток на StackOverflow.

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

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

В целом же работа с сессиями очень простая и если говорить с практической точки зрения, то есть очень мало задач, которые стоят перед программистом. Первая — это добавление и получение данных в сессию, и вторая — организация flash-сессий для создания «мигающих сообщений». Очень часто это так и называется «flash message». Простой пример: после обновления данных, нужно вывести сообщение для пользователя только один раз.

REST — это концепция для взаимодействия компонентов основанный на протоколе HTTP. Не хочу останавливаться на скучной теории (вики в помощь), а дам простое объяснение применительно к сайтам.

В Сети обмен происходит по протоколу HTTP: запрос - ответ. Для того, чтобы передать какие-то данные, их нужно как-то идентифицировать, то есть указать их «признак», «действие» или что-то подобное. И поэтому раньше данные требовалось оформить в виде какого-то сложного формата, обычно это XML или Json.

Так вот, REST говорит что этого делать не нужно. Данные передаём как есть, только у HTTP-запроса указывается метод (параметр) для этих данных. Обычно мы оперируем GET и POST, поскольку они работают «из коробки» в HTML и их поддерживает любой браузер. Но на самом деле, метод у HTTP может быть абсолютно любым. Есть некие общепринятые: PUT, DELETE, OPTIONS, PATCH, но это совсем не стандарт.

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

Есть стартовая страница — это то, что открывается по умолчанию для каждой новой вкладки. В хромовских браузерах для таких страниц делается интеграция с google-аккаунтом. Если посмотреть через html-код, то всё это обычная html-страница с кучей js-скриптов.

Лично я предпочитаю чистый about:blank (пустая страница), но такой вариант не предусмотрен разработчиками, а значит придётся редактировать файлы браузера. Думаю, что подобный трюк сработает и с настоящим Chrome, хотя я не проверял. Так что тут уж сами решайте. :-)