Продолжая тему оптимизации скорости загрузки сайта, хочу рассказать о новой технологии от Битрикс — композитный сайт. Как водится, все новое — это хорошо забытое старое, вот и эта технология в общем-то мало отличается от кеширования страниц целиком в том же phpbb или wordpress, разве что с рядом технических улучшений. Но, обо всем — по порядку.
Продолжая развивать тему кеширования, начатую в прошлом посте, хочу немного написать про тегированный кеш в битрикс. На самом деле технология нужная и правильная, правда ей почему-то редко кто пользуется.
Вкратце — как работает почти любая система кеширования:
Кеш — совокупность каких-то данных (структурированных или нет). Кеш имеет определенный период жизни и какой-то идентификатор (нечто, что уникально идентифицирует именно эту совокупность данных в каком-то контексте). Пока период жизни кеша не истек — нужно обращаться к кешу, а после истечения срока жизни кеша нужно его актуализировать и снова сохранить на указанный период.
Довелось мне поработать с разными проектами и разными людьми. Бывали проекты нагруженные в плане посещаемости, но бедные по функциональности. Бывали наоборот — 500 хитов в месяц, а сложность функционала — выше крыши. Но вот с чем не повезло — так это с разработкой. Разработать проект с нуля и до запуска мне приходилось буквально пару раз. В остальных случаях приходилось заниматься сопровождением существующего кода (написанного другими разработчиками) и внедрением новых функциональностей в него. Но я считаю это огромным плюсом моей работы. Во-первых — можно встретить множество решений, как интересных, так и откровенно говоря «поганых». Во-вторых, приходится задействовать огромное количество серого вещества с целью собрать воедино всю картину в голове, чтобы при внедрении каких-то доработок не развалились старые.
Поначалу мне не очень понравилась интеграция git в phpStorm. Наверно потому, что я ко времени первого своего знакомства с этим инструментом уже довольно долго работал с SourceTree. Последний — реально хорош, там есть все (почти все), что необходимо разработчику для ежедневной работы с гитом. Однако я решился, и заставил себя пользоваться инструментарием от jetBrains, и в принципе, нашел там определенные удобства.
Раньше, когда я не пользовался IDE, я частенько бегал в гугл. Держать в голове всю документацию php — нереально, никогда не запомнишь всего и вся. А чтобы найти нужную функцию или класс в доке — нужно: интернет, набрать в гугле запрос, перейти к функции и только после этого начать читать, потом прочитав — вернуться в редактор. В день таких операций может быть десятки, они могут отнимать в день достаточно много времени. Очень много. Если еще посчитать время, которое теряется при отвлечении от кода, то оно может измеряться десятками минут, и даже часами!
Не сохранилась половина статьи про исключения ….(( а написал много. Поэтому пока их отложу, а напишу про битрикс.
Несмотря на весь тот свод правил, которые предлагает нам битрикс, можно организовывать хранение своего кода по разному. В статье я постараюсь предложить варианты, который хотел бы видеть в проектах, с которыми работаю. Он не идеален, он не панацея, доступен для обсуждения, я всегда открыт для ваших предложений.
Продолжаем знакомиться с пространствами имен. В предыдущей статье мы узнали, что такое пространства имен, зачем они нужны, узнали что инклюдить файлы все равно придется, и рассмотрели пример о том, как же ими пользоваться, как определять и т.д.
В этой статье рассмотрим остальные аспекты пространств имен, которые не были затронуты ранее.
Продолжаем серию статей о фишках и возможностях php. На этот раз расскажу о возможности автоматической загрузки классов
В предыдущей статье я упоминал как раз о том, что буду писать про возможности автоматической загрузки. А догадливый Дима спросил, буду я писать про __autoload() или про spl_autoload_register(). Сначала я, было, ответил, что конечно же про spl_, ведь __autoload() признан устаревшим. Ан нет — не получится, придется рассказать про оба, чтобы у вас сформировалась полная и четкая картина про автоматическую загрузку.
С этого поста хочу начать цикл статей о возможностях языка, которые начинающие разработчики часто игнорируют, а потом в ежедневной суете не остается времени на их изучение или применение и часто люди избегают использования таких крутых возможностей языка, что становится странно. Все-таки php сейчас — один из самых динамично развивающихся языков, но иногда мне кажется, что многие разработчики просто застряли на эпохе зарождения php 5.
Все описанное ниже, а также далее в этой серии статей, будет иным трактованием официальной документации, и не более. Это просто очередная попытка донести до разработчиков необходимую информацию и не более.
В продолжение предыдущей статьи, хотел бы поведать о том, чем же он так круче остальных IDE и редакторов, какие именно его особенности позволяют мне ежедневно экономить время на разработке и работать эффективнее.